팀이 처음 만난 날부터 100일

100일을 코드 히스토리로 증명한다는 것

팀이 생겼다는 사실은 슬랙 채널 개설이나 노션 페이지 하나로 선언할 수 있다. 하지만 실제로 "팀이 됐다"는 감각은 다른 데서 온다. 우리 HEDVION 세 명이 같은 저장소에 처음 커밋을 올린 날을 기준으로 하면, 이제 막 100일이 넘었다. 연초 회고에서 나온 이야기를 여기에 남기는 이유는 기념 때문이 아니다. 결제·정산·자동화를 직접 운영하는 작은 팀이 초기 100일을 어떻게 구성하느냐에 따라, 이후 시스템의 신뢰도와 팀의 속도가 갈린다는 것을 몸으로 배웠기 때문이다.

첫 커밋 날짜를 기준으로 집계하면, 우리는 100일 안에 약 340건의 커밋, 67개의 PR, 그리고 정산 자동화 파이프라인 2개를 만들었다. 숫자 자체보다 중요한 건 그 숫자들이 어떤 기반 위에 쌓였는가다. 초반 2주를 기반 규칙 합의에만 할애했는데, 그 2주가 나머지 86일의 속도와 품질을 결정했다.

도구 합의가 결제·자동화 팀에서 더 중요한 이유

커밋 메시지 컨벤션 이야기부터 시작하자. 팀 내에서 처음에 의견이 갈렸다. 한쪽은 "메시지는 개발자 재량"이라는 입장, 다른 쪽은 "Conventional Commits 기준으로 먼저 정하자"는 입장이었다. 일반적인 서비스 팀이라면 어느 쪽을 선택해도 큰 차이가 안 날 수 있다. 하지만 결제·정산 시스템에서는 다르다. 우리가 운영하는 정산 파이프라인은 외부 PG사 webhook 이벤트를 받아 내부 상태를 업데이트하고 일정 주기로 정산 파일을 생성한다. 이 파이프라인에서 버그가 생기면 금전적 불일치가 발생하고, 그 불일치를 추적하려면 코드 이력 탐색이 필수다.

fix(settlement): PG webhook 중복 처리 제거는 수정함과 비교도 안 될 만큼 이력 추적 속도를 높인다. 실제로 우리 팀은 초반 컨벤션 합의 덕분에 특정 정산 오류의 원인을 git log --grep으로 7분 만에 찾아낸 적이 있다. 컨벤션 없이 자유롭게 썼더라면 어땠을지는 모르지만, "빠른 커밋이 나중에 느린 디버깅을 만든다"는 공식은 결제 도메인에서 더욱 선명하다. 브랜치 전략도 마찬가지다. 긴급 픽스를 main에 직접 push하는 게 편한 순간이 있다. 하지만 자동화 파이프라인이 main 브랜치를 바라보고 있다면, 미검증 코드가 즉시 프로덕션에 반영된다. 우리는 hotfix/* 브랜치 + 최소 1인 리뷰 규칙을 초기에 정했고, 이 규칙 덕분에 급박한 상황에서도 파이프라인이 의도치 않게 이상 동작하는 사고를 방지할 수 있었다.

비동기 작업과 결제 장애의 교차점

세 명이 항상 같은 시간에 일하지 않는다. 각자 집중 시간대가 다르고 병렬 작업이 많다 보니, PR 리뷰와 의견 교환은 자연스럽게 비동기로 흘러갔다. 처음에는 이게 불편했다. 빠른 피드백을 기대하고 올린 PR이 몇 시간씩 조용히 있으면, 마치 혼자 작업하는 것 같은 느낌이 든다. 그런데 결제 도메인에서 비동기 리뷰는 사실 더 안전하다. 충동적으로 LGTM을 누르는 것보다, 리뷰어가 자신의 집중 시간대에 코드를 정독하고 코멘트를 다는 것이 결제 로직의 엣지 케이스를 잡아낼 확률이 높다.

실제로 우리 팀은 비동기 리뷰 도중 "이 조건에서 환불 금액이 음수가 될 수 있다"는 코멘트를 받은 적이 있다. 동기 리뷰였다면 분위기상 빠르게 넘어갔을 가능성이 높다. 그 한 줄 코멘트가 잠재적 정산 오류 하나를 사전에 막았다. 물론 한계는 명확하다. 텍스트로 30분을 주고받아도 풀리지 않는 설계 논의가 있다. 외부 API 연동 스펙 해석이나 정산 예외 케이스 결정은 10분 통화가 30분 텍스트를 대체한다. 우리 팀이 정한 기준은 단순하다: 메시지 왕복이 3번을 넘어가면 동기 미팅을 잡는다. 이 규칙 하나로 불필요한 지연과 즉흥적 LGTM 사이에서 균형을 잡을 수 있었다.

리팩터링의 현실: 무엇이 살아남았나

100일 동안 코드는 많이 바뀌었다. 초반에 빠르게 만들었던 구조 일부는 이미 리팩터링됐고, 처음에 중요하다고 생각했던 기능이 실제로는 거의 안 쓰인다는 것도 알게 됐다. 구체적으로, 초반에 공을 들인 "수동 정산 조정 UI"는 운영 중 거의 열리지 않았다. 실제 정산 차이가 발생하면 UI보다 DB 직접 조회나 파이프라인 로그가 훨씬 빠르기 때문이다. 반면 생각보다 훨씬 자주 쓰이는 건 "특정 거래 ID의 상태 변이를 타임라인으로 보는 기능"이었다. 사이드로 빠르게 만든 거였는데, 결제 이슈 대응 시 거의 매번 꺼내게 된다.

트레이드오프를 정리하면 이렇다. 초기에는 UX 완성도를 높이는 방향으로 시간을 썼지만, 실제 운영에서는 "지금 이슈 대응 중에 실제로 열게 되는가" 가 내부 도구의 가치를 결정한다. 멋진 UI보다 CLI 스크립트 하나가 더 자주 쓰일 수 있다. 이 경험 이후 우리는 내부 도구 우선순위를 "있으면 좋겠다" 기준이 아니라 "온콜 중 실제로 손이 가는가" 기준으로 재편하고 있다.

팀 암묵지를 코드로 굳히는 법

100일이 지나면서 팀에는 명시적으로 문서화되지 않은 암묵지가 생겼다. PR을 어떻게 쪼갤지, 리뷰 댓글은 어느 수준까지 달지, 긴급 픽스는 어떻게 처리할지. 작은 팀일수록 이 암묵지의 밀도가 높고, 동시에 그것이 팀의 속도를 결정한다. 문제는 암묵지가 오직 사람에게만 있을 때다. 팀원이 교체되거나 외부 기여자가 합류하는 순간, 암묵지는 온보딩 마찰이 된다.

우리가 다음 100일 동안 집중하려는 건 이 암묵지를 코드와 설정으로 굳히는 작업이다. 커밋 컨벤션은 이미 .commitlintrc로 강제하고 있다. PR 체크리스트는 GitHub 템플릿으로 넣을 예정이고, 정산 파이프라인의 핵심 불변 조건(예: 정산 금액은 음수가 될 수 없다, 동일 거래 ID는 두 번 정산될 수 없다)은 assertion 코드로 남길 계획이다. 사람의 기억보다 .eslintrc가 더 오래 살아남는다.

다음 100일을 시작하는 팀을 위한 실행 가능한 시사점

100일 회고를 정리하면서 가장 실용적으로 꺼내 쓸 수 있다고 판단한 것들을 정리한다. 결제·정산·자동화를 운영하는 소규모 팀에게 특히 해당된다.

커밋 컨벤션은 코딩 전에 정하라. fix(settlement):, feat(webhook): 같은 prefix는 이력 추적과 자동 changelog 생성 모두에 즉시 효과가 난다. 팀 전체가 익숙해지는 데 3일이면 충분하고, 효과는 첫 번째 버그 추적 때 바로 나타난다.

비동기 리뷰 전환 기준을 딱 한 문장으로 명시하라. "메시지 왕복 3회 초과 시 동기 미팅" 같은 단순한 규칙 하나가 불필요한 지연과 즉흥적인 승인 사이에서 균형을 잡아준다.

내부 도구 우선순위는 "온콜 중 실제로 여는가"로 판단하라. 정산 불일치 대응, 거래 상태 추적, webhook 재처리 — 이것들이 먼저다. 관리 UI는 그다음이다.

팀 암묵지를 linter·PR 템플릿·assertion으로 코드화하라. 기억은 흐릿해지지만 설정 파일은 남는다. 특히 금전적 불변 조건은 반드시 코드 레벨에서 강제해야 한다. 리뷰어의 주의에 의존하는 것은 언제든 뚫린다.

초기 100일의 기반이 탄탄할수록, 이후 확장의 속도와 안전성이 달라진다. 다음 100일이 지났을 때 이 글을 다시 읽으면서, 우리가 얼마나 더 명시적인 팀이 됐는지 확인해보려 한다.

— by slecs