한 분기 회고 — 5개월의 절반에서 합의한 것들

왜 분기 말이 아니라 중간에 멈춰 섰나

결제·정산 시스템을 운영하는 팀에게 분기 말 회고는 구조적으로 너무 늦다. 분기가 끝나는 시점엔 오류 건수, 정산 지연 시간, 배포 실패율 같은 숫자들이 이미 고정돼 있다. "왜 이랬나"를 분석할 수는 있어도 "이번 분기 안에 고칠 수 있는 것"은 사실상 없다. 회고가 평가 의식으로 전락하는 이유가 여기 있다. 결과를 놓고 모이면 반성이 되고, 과정 중에 모이면 조정이 된다.

우리 팀에서 분기 중반 회고를 처음 시도한 건 특별한 이유가 있어서가 아니었다. 5개월짜리 프로젝트 주기의 절반 지점에서 자연스럽게 "지금 어떻게 가고 있나"를 짧게 확인하자는 이야기가 나왔고, 그게 작동했다. 2~3개월 차가 되면 초기 설계의 빈틈이 실제 트래픽과 맞부딪히기 시작한다. 결제 요청이 몰리는 특정 시간대에 정산 배치 잡이 겹쳐 API 응답이 느려지거나, 새로 붙인 자동화 로직이 예외 케이스를 처리하지 못하는 현상이 이 시기에 표면으로 드러난다. 이걸 분기 말에 발견하면 기록으로만 남는다. 중간에 잡으면 남은 절반을 다르게 설계할 수 있다. 우리는 지금 분기 중반 60분짜리 회고와 분기 말 전체 회고를 병행하고 있다.

코드 리뷰 기준을 타협하지 않기로 한 진짜 이유

"바쁜 시기엔 리뷰를 빠르게 통과시키자"는 말은 언뜻 합리적으로 들린다. 결제·정산 코드에서 이 논리가 특히 위험한 건, 이 도메인의 버그가 단순한 기능 오류가 아니라 금액 오차나 이중 정산으로 직결되기 때문이다. 일반 서비스에서 버그는 UX 문제로 끝나지만, 정산 버그는 외부 정산 요청으로 이어지고 신뢰 문제가 된다.

우리 팀도 한 시기에 리뷰를 빠르게 넘긴 적이 있다. 당시 배포된 정산 집계 로직에서 소수점 처리 방식이 특정 금액대에서만 틀리는 버그가 석 달 뒤에 발견됐다. 직접 영향을 받은 건 수십 건이었고, 원인 분석부터 수동 재처리까지 팀 전체가 이틀을 썼다. "빠른 리뷰로 아낀 시간"이 "사후 처리에 쓴 시간"으로 돌아왔다. 이번 회고에서 리뷰 기준을 유지하기로 한 건 원칙의 문제가 아니라 비용 계산의 문제였다. 기준을 낮추는 것은 시간 절약이 아니라 부채 생성이라는 걸 우리는 숫자로 확인했다.

배포 주기를 잘게 가져간 후 실제로 달라진 것

변경 단위를 작게 하고 배포 빈도를 높이자는 결정은 이론적으로는 당연해 보이지만, 정산 시스템에서는 실행이 까다롭다. 정산 로직은 서로 의존하는 모듈이 많아서 "작은 배포"를 만들려면 인터페이스가 명확히 분리돼 있어야 한다. 그게 안 된 상태에서 배포 단위를 쪼개면, 실제로는 전체 변경을 한 번에 올리면서 배포 횟수만 늘어나는 형식적인 분리가 된다.

분기 중반 이후 우리가 실제로 바꾼 건 두 가지다. 하나는 배포 단위를 기능 단위가 아니라 변경 단위로 쪼개는 것이고, 다른 하나는 배포 전 자동화 검증 스크립트를 의무화한 것이다. 전자 덕분에 문제 발생 시 롤백 범위가 좁아졌고, 후자 덕분에 배포 후 정산 불일치를 탐지하는 시간이 기존 수 시간에서 배포 직후 15분 이내로 줄었다. 배포 빈도는 이전 대비 약 2.3배 늘었고, 배포당 변경 파일 수는 절반 이하로 줄었다. 배포 빈도가 늘면 리스크가 커진다고 생각하기 쉬운데, 변경 단위가 작으면 오히려 리스크가 분산된다.

스펙 문서를 코드 리포에 합친 이유

결제·정산 시스템에서 문서와 코드의 싱크가 맞지 않는 건 단순한 불편함이 아니다. 외부 PG사 연동 스펙이 바뀌었을 때 코드는 업데이트됐는데 위키의 API 명세가 그대로인 경우, 다음 담당자가 위키를 보고 잘못된 방향으로 구현을 시작한다. 우리 팀에서 실제로 이런 일이 있었다. 특정 PG사의 응답 포맷 변경이 코드에는 반영됐지만 문서에는 반영되지 않아서, 신규 연동 작업 시 이를 참고한 작업자가 잘못된 파싱 로직을 구현했다. QA 단계에서 발견됐으니 다행이었지만, 발견이 늦었다면 운영 오류로 이어질 수 있었다.

스펙 문서를 코드 PR에 포함시키면 리뷰어가 코드 변경과 스펙 변경을 동시에 볼 수 있다. 이건 문서 관리 방식의 변화가 아니라 리뷰 구조의 변화다. 리뷰 단계에서 "이 코드 변경이 스펙과 일치하는가"를 자연스럽게 확인하게 된다. 우리는 현재 /docs/spec/ 디렉터리를 코드 리포 안에 두고, 외부 연동 스펙 변경이 포함된 PR은 반드시 해당 디렉터리 파일도 함께 수정하는 것을 PR 체크리스트 항목으로 추가했다. 이 항목이 없으면 리뷰어가 병합 승인을 할 수 없다.

합의하지 못한 것도 기록이 된다

기술 부채를 어떻게 처리할 것인가라는 질문에 우리 팀은 아직 답을 내지 못했다. 스프린트마다 20~30%를 부채 해소에 할당하자는 의견과, 부채가 실제 문제를 일으킬 때 집중적으로 처리하자는 의견이 맞섰다. 결제·정산 도메인에서 이 논쟁이 특히 예민한 이유가 있다. 부채를 방치하면 기능 추가 속도가 점진적으로 느려지고, 어느 순간 작은 변경에도 전체 회귀 테스트가 필요해진다. 반면 부채 해소에 일정 비율을 고정하면 비즈니스 일정과 충돌하고, 급한 연동 요건을 소화하지 못하는 상황이 생긴다. 어떤 선택도 비용이 있고, 그래서 쉽게 합의가 되지 않는다.

우리가 이번에 한 건 합의를 강제하는 대신 논쟁의 내용을 기록해 두는 것이었다. 어떤 근거로 어느 쪽 의견이 나왔는지, 당시 팀의 컨텍스트가 무엇이었는지를 문서로 남겼다. 다음에 같은 주제가 나오면 "우리가 이전에 이 논쟁을 했고, 당시 합의하지 못한 이유는 이것이었다"는 출발점에서 시작할 수 있다. 기술 부채 논의는 팀 구성이나 프로젝트 단계에 따라 맥락이 바뀐다. 기록이 없으면 같은 논쟁이 매번 처음부터 반복된다. 미결 사항의 기록은 결정의 대체물이 아니지만, 반복적인 소모를 줄여준다.

지금 당장 적용할 수 있는 것들

회고 결과를 48시간 안에 이슈 티켓으로 전환하라. "배포 단위를 작게 한다"는 합의는 그 자체로는 아무것도 바꾸지 않는다. "다음 스프린트부터 PR당 변경 파일 10개 초과 시 반드시 분리 배포 검토"처럼 측정 가능한 기준으로 바꾼 뒤 티켓으로 만들어야 실행된다. 우리 팀은 회고 직후 30분을 써서 합의 사항을 모두 이슈로 전환하는 걸 원칙으로 하고 있다. 회고 결과가 회의록으로만 남으면 다음 회고 때 "그때 그 얘기 어떻게 됐어요?"로 시작된다.

분기 중반 회고는 60분, 주제를 세 가지로 제한하라. 분기 말 회고와 달리 중반 회고는 "남은 절반에서 바꿀 수 있는 것"에만 집중해야 한다. 이미 지난 것에 대한 평가는 분기 말로 미룬다. 60분 안에 "유지할 것 23개, 변경할 것 12개, 미결로 기록할 것 1개"를 정리하는 것을 목표로 잡으면 회의가 늘어지지 않는다. 주제가 그 이상 나오면 분기 말 회고 안건으로 옮긴다.

합의하지 못한 것을 명시적으로 기록하라. "나중에 다시 이야기하자"는 잊히는 것과 같다. 미결 사항은 "우리가 X를 논의했으나 Y와 Z 의견이 충돌해 합의하지 못했다. 다음 검토 시점은 Q3 말이다"처럼 이유와 다음 검토 시점을 명시해서 남긴다. 이게 있으면 다음 회고에서 같은 논의가 30분을 절약한다.

결제·정산 코드의 리뷰 기준은 도메인별로 분리하라. 모든 코드에 동일한 기준을 적용하는 것은 현실적이지 않다. 금액 계산, 외부 PG 연동, 상태 변경이 포함된 PR에는 더 엄격한 기준 — 예를 들어 반드시 두 명 이상의 승인, 자동화 검증 통과 필수 — 을 적용하고, 설정 변경이나 로그 개선 같은 저위험 PR은 기준을 달리 운영하는 것이 합리적이다. 기준을 "낮추지 않는 것"과 "어디에 어떤 기준을 적용할지 명확히 하는 것"은 다른 이야기다. 전자는 원칙이고 후자는 운영이다.

회고는 팀의 기억을 제도화하는 방식이다. 기억이 개인의 머릿속에만 있으면 사람이 바뀔 때 사라진다. 기록과 합의가 구조로 남아 있으면 팀이 바뀌어도 일하는 방식이 유지된다. 오류 하나가 금액 문제로 직결되는 결제·정산 도메인에서는 이 구조가 선택이 아니라 생존 조건에 가깝다.