토스 러너스 하이 2기 4주차 회고
드디어 러너스 하이가 끝을 향해간다. 4주차는 코드를 더 붙여서 기능을 키우기보다는, 지금까지 만든 걸 오픈소스로 공개하고, 그 과정을 성장 일지 형태로 정리하는 데 대부분의 시간을 썼다.
왜 오픈소스로 공개했나
이번 결정은 단순히 “오픈소스가 멋있어서”가 아니었다. 내가 속한 생태계 자체가 오픈소스 기반이고, 실제 업무를 하면서도 커뮤니티에 공개된 코드들이 계속 도움이 됐다. 나도 가능한 선에서 꾸준히 기여해 왔고, 이번 프로젝트도 그 연장선으로 보고 싶었다.
또 하나는 현실적인 이유였다. 운영 환경 제약 때문에, 지금 결과물을 당장 프로덕션에 올려 적용하는 건 어렵다. 그래서 더더욱 “내 환경 밖”에서 한 번 공개 가능한 형태로 만들고 싶었다. 기능을 더 키우기 전에, 최소 기능이라도 엔드투엔드로 동작하는 흐름을 먼저 보여주고 싶었다.
커뮤니티 공유는 이렇게 했다
커뮤니티에는 내가 느낀 불편을 그대로 적었다.
장애가 나면 결국 로그를 모으고 → 전달하고 → 정리하는 데 시간이 다 쓰인다. 문제 분석 이전에 “로그 전달 과정”이 병목이 되는 게 늘 불편했다.
그래서 tk-*.log를 감시하다가 ERROR/CRITICAL 패턴이 감지되면, 로그를 묶어서 자동으로 티켓을 생성하고 첨부까지 올려주는 도구를 MVP로 만들어 공유했다.
I made a log collector toolkit app that auto-creates tickets
소스를 공개할 때 가장 신경 쓴 부분은 내 환경에서만 돌아가는 코드가 되지 않게 만드는 것이었다. 프로덕션 적용 전 단계인 만큼 범위를 줄이고, 누구나 읽고 수정할 수 있는 최소 단위로 정리했다.
핵심은 이 정도로 잡았다.
- 로그 스캔/추적
- 에러 감지
- 엔진 단위 묶음 생성
- 실행 환경 정보 수집
- 티켓 생성/첨부 업로드는 “최소 동작”만 두고, 교체 가능한 인터페이스로 분리
그리고 README에는 설치/설정, 스크린샷, 제한 사항을 명시했다.
커뮤니티 반응
생각보다 반응이 빨리 달렸다.
처음부터 이 프로젝트는 What(무엇을 만들지)보다 Why(왜 불편한지)에서 시작했다. “장애가 나면 결국 로그 전달 과정이 병목이다”라는 그 불편이 출발점이었고, 나는 이게 내 상황만의 문제는 아닐 거라고 생각했다. 비슷한 환경이면 다들 한 번쯤 겪었을 거라고..
커뮤니티 반응을 보니까 그 추측이 크게 틀리지 않았던 것 같다. “공유해줘서 고맙다”, “이런 거 있으면 시간 많이 줄겠다” 같은 피드백이 바로 달렸고, 내가 만든 레포에 스타도 찍히고 포크도 생기니까 더 실감이 났다. 실제로 누군가는 가져가서 써볼 수도 있겠다는 생각이 들었다.
성장 일지 작성
4주차는 코드보다 문서 작업이 더 큰 비중을 차지했다. 제출물은 결국 성장 일지 하나다. 이게 “내가 뭘 했는지”보다 “내가 어떤 문제를 어떻게 정의하고 끝까지 정리했는지”가 보이는 형태여야 한다고 생각했다.
성장 일지 초안은 Google Docs로 작성했고, 디자인과 퍼블리싱은 Figma로 진행했다. 코드 설명을 길게 늘어놓기보다는 “왜 이걸 하게 됐는지”라는 배경부터 시작해, 독자가 자연스럽게 흐름을 따라올 수 있도록 만들려고 노력했다.
이번 작업을 하면서 취준생 시절 책을 출간했던 경험이 많은 도움이 됐다. 당시에도 글을 쓰는 것만큼이나, 편집·구성은 물론 디자인과 퍼블리싱까지 책임지며 독자가 읽을 수 있는 결과물로 완성하는 과정이 핵심이었다. 성장일지 편찬도 본질은 같다고 생각한다.
성장 일지
한 달 플래닝과 프로젝트 관리 방식
이번 한 달은 그때그때 생각나는 대로 하기보다는, 시작할 때 흐름을 먼저 잡아두고 가려고 했다.
- 한 달 목표를 먼저 대충 잡고
- 주차별로 쪼개서 계획을 세우고
- 작업은 이슈 단위로 쪼개서 처리하고
- 진행 상황은 로그로 남겨두는 방식
러너스 하이 전용으로 프라이빗 레포를 하나 파서, 플래닝/진행 상황을 계속 적어뒀다. 나중에 회고 쓸 때 기억에 의존하지 않게 하려는 목적이 컸다.
플래닝은 GitHub Issue로 정리했다. 러프한 주차 계획부터 커뮤니티 공유 준비, 피드백 반영까지 내가 필요하다고 판단한 것들은 전부 이슈 단위로 쪼개 적어두었다.
이렇게 하니까 한 달 프로젝트가 큰 덩어리로 느껴지지 않고, 할 일들이 좀 더 선명해졌다. (그리고 “완료”가 쌓이는 게 생각보다 꽤 동기부여가 된다.)
아쉬운 점
이번 한 달이 계획대로만 흘러가지는 않았다. 최대한 시간을 내서 러너스 하이에 몰입하고 싶었지만, 12월 말 보안 취약점(몽고블리드) 이슈가 터지면서 내가 맡고 있는 시스템도 영향권에 들어갔다. 사이드 이펙트를 파악하고 업그레이드 계획을 세우고, 배포 스크립트를 작성하는 등 긴급 조치가 필요했고, 결과적으로 한 주 정도는 러너스 하이에 제대로 시간을 쓰지 못했다.
원래는 커뮤니티에 공개하는 데서 끝내지 않고, 가능하다면 프로덕션에 일부라도 적용해 운영 관점의 내용을 성장일지에 담고 싶었다. 실제 환경에서 돌려보면서 “어디서 깨지는지”, “어떤 정책이 필요한지”, “운영자의 액션이 어떻게 바뀌는지”까지 확인하고 싶었는데, 그 단계까지 가지 못한 점이 가장 아쉽다.
그럼에도
- 현장에서 반복되는 불편을 ‘느낌’이 아니라 ‘구조’로 관찰했고
- 불편했던 점(병목)을 설명 가능한 형태로 문제 정의했으며
- 최소 기능으로 엔드투엔드 흐름을 구현해 검증했다.
- 그리고 공개 가능한 형태로 정리해 밖으로 내놓았다.
이 과정 자체가 이번 한 달의 결과라고 생각한다. 나는 이 경험을 토대로 앞으로도 문제를 ‘느낌’이 아니라 ‘정의’로 바꾸고 ‘해결하는 사람’으로 성장해 나가고 싶다.
Leave a comment