작은 팀의 retrospective — 격주에 30분

결제·정산 현장에서 회고가 유독 미뤄지는 이유

결제·정산 업무를 하는 팀에서 회고가 특히 잘 안 된다. 역설적이게도, 회고가 가장 필요한 환경이 회고를 가장 꺼리는 환경이다. 오류 하나가 실제 돈에 직결되다 보니 "지나간 일"을 다시 꺼내는 게 심리적으로 무겁다. 장애가 발생하면 사후 분석(post-mortem)은 어떻게든 하게 되지만, "별 탈 없이 지나간 2주"에 대한 정기 회고는 항상 "다음에"가 된다.

HEDVION처럼 결제 수집·정산 자동화·파트너사 연동을 동시에 운영하는 세 명짜리 팀에서는 한 사람이 두세 역할을 겸한다. 정산 로직을 짠 사람이 CS 에스컬레이션도 처리하고, 개발자가 운영도 한다. 이 구조에서 "내가 아는 것"과 "팀이 공유하는 인식" 사이 간격이 은밀하게 벌어진다. 회고를 건너뛸 때마다 그 간격이 조금씩 더 넓어지고, 어느 순간 같은 문제를 두 번째로 겪는다. 결제·정산 도메인에서 같은 실수를 두 번 하면, 첫 번째보다 두 번째가 훨씬 비싸다.

우리가 선택한 형식과 그 근거

30분, 세 가지 질문, 문서 한 페이지. 우리가 쓰는 회고의 전부다.

잘 됐던 것 하나
바꾸고 싶은 것 하나
다음 두 주 안에 실제로 할 수 있는 것 하나

각자 5분씩 조용히 적고, 돌아가며 공유한 뒤, 3번 항목 하나를 합의한다. 나머지는 문서에 기록만 하고 넘어간다. 이 포맷을 선택한 핵심 이유는 "단순화"가 아니라 "실행 가능성"이다. 개선할 점을 다섯 개 나열하면 책임이 분산되고 아무도 추적하지 않는다. 단 하나를 고르면 2주 뒤에 "했냐 안 했냐"가 명확해진다. 이진(binary) 판단이 가능한 액션이어야 회고가 실제 변화로 이어진다.

주기를 격주로 고른 것도 의도적 선택이었다. 매주 시도했을 때는 "지난주와 다를 게 없어서"라는 이유로 형식적으로 흘렀다. 한 달에 한 번은 구체적인 사례 대신 감상 수준의 이야기가 나왔고, 흐릿해진 사건을 복원하는 데 시간을 낭비했다. 격주는 사건이 선명하게 남아 있으면서 충분한 변화가 쌓이는 시간이다. 정산 사이클이 월 단위인 환경에서도 일상적인 운영 리듬은 2주 단위로 끊는 것이 우리 체감상 가장 맞았다.

수치로 보는 트레이드오프: 1시간 vs 30분

세 명이 한 시간 회고를 하면 3인시(人時)를 쓴다. 연간 26회 격주 기준으로 78인시다. 같은 팀이 30분 회고를 하면 39인시로 절반이다. 이 차이를 단순한 시간 절약으로 보면 틀린다. 핵심은 회고의 품질이 길이에 비례하지 않는다는 점이다.

우리가 경험한 1시간짜리 회고에서 후반 30분은 대체로 앞 30분에 나온 이야기를 정리하거나, 실행 가능성이 낮은 개선안을 논의하는 데 쓰였다. 실제로 행동으로 이어진 것은 거의 항상 초반에 나온 이야기였다. 30분 포맷은 처음부터 "다음 두 주에 뭘 바꿀 것인가"라는 수렴 질문을 향해 설계되어 있어서 에너지가 분산되지 않는다. 소규모 팀에서 회고의 ROI는 회의 시간이 아니라 "합의한 액션 1개의 완료율"로 측정해야 한다. 30분 포맷으로 전환한 이후, 우리 팀의 액션 완료율은 체감상 절반 이하에서 80% 이상으로 올라갔다.

정산 자동화 팀의 실전 시나리오: silent failure를 잡은 사례

실제 사례를 하나 공개한다. 어느 회고에서 "바꾸고 싶은 것"으로 파트너사 정산 결과 검증 스크립트 문제가 올라왔다. 에러가 나도 Slack 알림이 없는 구조였다. cron job이 조용히 실패하면 아무도 모른다. 담당자가 매일 아침 수동으로 로그를 확인해야 했고, 한 번 빠뜨리면 당일 정산 오류를 다음 날에야 발견하는 식이었다. 직접적인 금전 피해는 없었지만, 하루 지연된 정산 오류는 파트너사와의 신뢰 비용으로 이어진다.

이를 "다음 두 주 액션"으로 잡고 Slack webhook 한 줄을 추가했다. 실제 작업 시간은 1.5시간이었다. 이 문제가 회고 전에 태스크 시스템에 올라가 있었냐 하면 그렇지 않았다. "다들 알고 있지만 급하지 않은 것"이었다. 회고가 없었다면 더 큰 사고 전까지 계속 뒤로 밀렸을 것이다. 결제·정산 자동화에서 진짜 위험은 눈에 보이는 장애가 아니라 소리 없이 쌓이는 구조적 결함이다. 장애 대응은 급하니까 어떻게든 하게 된다. 조용한 위험은 구조적으로 챙기지 않으면 아무도 안 챙긴다.

가장 약한 고리: 액션 추적 구조와 운영 원칙

30분 회고를 아무리 잘 해도, 2주 뒤에 "저번에 뭐 하기로 했더라"를 자동으로 확인하는 구조가 없으면 흐지부지된다. 우리가 쓰는 방법은 단순하다. 회고 문서 첫 번째 줄에 직전 회고의 액션 아이템을 복사해 두고, 완료 여부 확인으로 회고를 시작한다. 완료했으면 체크, 못 했으면 이유를 한 줄로 적고 이월할지 드랍할지 팀이 함께 결정한다. 드랍도 명시적인 결정이어야 한다. "잊어버린 것"과 "의도적으로 내린 결정"이 달라야 한다.

진행자를 고정하지 않는 것도 중요한 원칙이다. 돌아가며 진행하면 주도권이 분산되고, 같은 세 가지 질문도 다른 톤으로 흘러간다. 특정인이 매번 진행하면 그 사람의 관심사와 프레이밍이 회고 방향을 은근히 편향시킨다. 소규모 팀일수록 이 편향이 빠르게 구조화된다. 순번제 진행은 공평함이 아니라, 팀 전체의 시각이 번갈아 반영되는 장치다. 한 가지 솔직하게 남기는 한계: 이 포맷이 심리적 안전감을 만들어주지는 않는다. 불편한 이야기—특정 결정이 잘못됐다, 누군가의 판단이 문제였다—는 30분 형식 안에서도 여전히 꺼내기 어렵다. 포맷과 분위기는 별개의 문제다.

내일 당장 써먹을 실행 시사점

뜬구름 없이 실행 가능한 것만 추린다.

1. 다음 주에 30분으로 시작한다. 포맷이 완벽할 필요 없다. 세 가지 질문을 노션 페이지 하나에 적으면 충분하다. 준비에 에너지를 쏟다가 회고를 못 하는 팀이 많다. 일단 시작하면 포맷은 2–3회 만에 자연스럽게 자리를 잡는다.

2. 액션 아이템은 이진 판단이 가능한 형태로 만든다. "코드 품질 개선"이 아니라 "에러 핸들링 없는 API 엔드포인트 3개에 try-catch 추가". 결제·정산 도메인이라면 "cron job 실패 시 Slack 알림 추가", "정산 결과 불일치 임계값 설정" 같은 형태다. 2주 뒤에 "했냐 안 했냐"가 30초 안에 판단 가능해야 한다.

3. 회고 문서 첫 줄은 항상 직전 액션 확인이다. 못 했다면 이유 한 줄, 그리고 이월 또는 드랍을 명시적으로 결정한다. 드랍은 실패가 아니라 우선순위 재조정이다. 이 한 줄이 회고의 연속성을 만든다.

4. 진행자는 순번으로 돌린다. 어색하더라도 3회차부터 자연스러워진다. 진행을 맡은 사람이 더 많이 생각하게 되고, 그것이 회고 전체의 밀도를 높인다.

5. 30분이 되면 끊는다. 가장 중요한 규칙이다. 시간을 지키는 것 자체가 다음 회고를 "다시 해도 되겠다"고 느끼게 만드는 가장 강력한 장치다. 회고가 매번 40–50분으로 늘어나면, 다음번에 슬그머니 미루게 된다. 작은 팀의 회고는 지속 가능해야 의미가 있다.