비동기 협업이 실패한 5가지 케이스

비동기 협업이 결제·정산 현장에서 더 위험한 이유

비동기 협업이 나쁘다는 이야기가 아니다. 비동기의 전제 조건이 갖춰지지 않은 상태에서 형식만 따라 하면, 유연성이 아니라 무질서가 생긴다는 이야기다. 일반적인 프로덕트 팀에서는 이 무질서가 "느린 팀"으로 끝난다. 결제·정산·자동화를 직접 운영하는 환경에서는 다르다. 정산 배치는 매일 특정 시각에 실행된다. 의사결정 루프 하나가 배치 타이밍을 놓치면 다음 정산 사이클까지 기다려야 하고, 가맹점 정산 지연은 계약 조건과 신뢰 문제로 곧장 연결된다. 알림 하나가 소음에 묻히면 장애가 14시간 동안 조용히 진행되고, 낡은 문서를 믿은 구현이 QA를 통과한 뒤에야 정산 금액이 틀렸다는 걸 발견한다.

HEDVION은 결제 처리, 일 단위 정산 자동화, 외부 PG 연동을 직접 운영하는 작은 팀이다. 팀원 수가 적고 시차도 없는데 완전 비동기를 몇 차례 시도했고, 그 과정에서 비슷한 실패를 반복했다. 이 글은 그 다섯 가지 실패 패턴을 기록한 것이다. 정산이 틀리거나, 자동화 파이프라인이 멈추거나, 알림이 묻혔을 때 생기는 실제 비용을 경험한 뒤에 바꾼 것들이다.

케이스 1·2: 결정 루프와 컨텍스트 없는 리뷰가 만드는 연쇄 손실

정산 배치 스크립트 수정 중에 슬랙에 이런 메시지가 올라왔다. "이 수수료율을 고정값으로 박아도 될까요, DB에서 읽어야 하나요?" 담당자는 다른 작업 중이었고, 두 시간 뒤 "DB에서 읽어야 합니다"라고 답했다. 그 답변이 "그럼 어느 테이블이요?"를 낳았다. 단순한 구현 결정 하나가 다음 날 오전까지 이어졌고, 당일 배포 예정이었던 정산 로직 변경이 하루 밀렸다. 하루 밀림이 작아 보여도, 배치 타이밍을 놓기면 다음 정산 사이클까지 대기해야 하는 구조에서는 그 하루가 운영 공백으로 직결된다.

우리는 결정 권한을 명시적으로 문서화해서 이 루프를 끊었다. "정산 배치 내부 구현 방식(스키마 설계 제외)은 담당자가 자율 결정, 머지 후 스레드에 사후 공유"처럼 구체적으로 썼다. 합의를 줄인 게 아니라, 합의가 필요한 것과 그렇지 않은 것을 구분한 것이다. 이 변경 이후 구현 결정 관련 슬랙 메시지가 체감상 60% 이상 줄었다. 컨텍스트 없는 리뷰도 비슷한 구조의 손실을 만든다. 환불 처리 로직 PR에서 특정 케이스만 반올림 방향이 달랐는데, 설명이 없어 리뷰어가 "일관성 없음"으로 지적했다. 실제로는 특정 가맹점 유형에 계약상 다른 반올림 규칙이 있었던 것인데, 맥락 없이 수정됐고 해당 가맹점의 정산 금액이 소액씩 틀리기 시작했다. 발견까지 3일, 원인 파악까지 반나절, 재처리까지 포함하면 4일을 날렸다. 이후 결제·정산 관련 PR에 세 가지 필수 항목을 만들었다: 왜 이 방향인가, 어떤 케이스를 고려했는가, 하드코딩이 있다면 그 이유는. PR 설명 작성에 10분이 더 걸리지만, 리뷰 라운드가 평균 2.3회에서 1.1회로 줄었다.

케이스 3: 알림 과잉이 14시간 정산 지연을 만든 날

우리 팀은 한때 슬랙 채널 하나에 모든 알림을 넣었다. PG사 웹훅 수신 로그, CI/CD 빌드 결과, 이슈 트래커 업데이트, 정산 배치 실행 결과, 팀 잡담까지 한곳에. 하루에 200~300개 알림이 쌓였고, 두 달이 지나자 아무도 채널을 제대로 보지 않게 됐다. 이건 사람의 문제가 아니다. 신호와 소음의 비율이 망가지면 뇌는 채널 전체를 소음으로 처리하도록 학습된다.

실제로 문제가 터졌다. 정산 배치가 특정 예외 조건에서 조용히 실패하는 버그가 있었고, 그 실패 알림이 다른 알림 사이에 묻혔다. 당일 정산이 실행되지 않은 채 다음 날 오전에 담당자가 수동 확인하다 발견했다. 약 14시간 지연. 가맹점 정산 지연 통보, 수작업 재처리, 원인 분석까지 반나절이 더 걸렸다. 금전 손실보다 신뢰 손실이 컸다. 이후 채널을 세 계층으로 나눴다: #alert-critical(즉각 응답 필요, PagerDuty 연동), #alert-ops(당일 확인, 정산·배치 결과), #dev-notify(참고용, CI·이슈 업데이트). 채널 설계는 30분이면 된다. 진짜 어려운 건 기존 습관을 바꾸는 것이다. 채널을 만들어도 사람들이 기존 채널에 계속 보내면 의미가 없다. 우리는 2주 동안 직접 틀린 채널 알림을 이동하면서 팀 전체가 새 구조를 체감하게 했다.

케이스 4·5: 문서 신뢰와 비동기 강박이라는 조용한 함정

비동기 협업이 잘 돌아가려면 문서가 커뮤니케이션의 기반이 돼야 한다. 그런데 결제·정산 시스템은 PG사 정책 변경, 수수료율 업데이트, API 버전 변경이 수시로 일어난다. 새 팀원이 입사해서 정산 정책 문서를 보고 환불 처리 로직을 구현했는데, 그 문서가 6개월 전 마지막 업데이트였다. 실제 정산 규칙은 그사이 PG사 정책 변경으로 두 번 바뀌어 있었다. 구현이 완료되고 QA까지 통과한 뒤에야 실제 정산 결과와 차이가 발생했다. 재작업 포함 3일을 날렸다. 이후 원칙을 두 가지로 정했다. 첫째, 문서는 맥락이고 정답은 코드다. 정산 로직 구현 시 문서는 참고점으로만 쓰고, 실제 동작 중인 코드와 테스트를 먼저 읽도록 온보딩에 명시했다. 둘째, 정책 변경 시 문서 업데이트를 작업 완료 조건(Definition of Done)에 포함시켰다. "코드+테스트+문서"가 함께 완료돼야 작업이 끝난 것으로 처리된다.

비동기를 기본 모드로 설정하면 동기 대화가 예외처럼 느껴지기 시작한다. 이것이 가장 문제가 되는 건 장애 대응과 설계 초기다. 결제 게이트웨이 연동 장애가 발생했을 때, 슬랙 스레드에서 원인 분석·가설 제시·확인 요청이 비동기로 오가다 30분이 지나도 "지금 누가 뭘 하는지"가 공유되지 않았다. 누군가는 로그를 보고, 누군가는 PG사에 연락 중이고, 누군가는 롤백을 고민하는 세 갈래가 조율 없이 각자 돌았다. 화상 통화 5분 만에 정리됐다. 그 5분이 25분을 아꼈다. 지금 우리는 동기 전환 조건을 명시해두었다: 결제 흐름에 영향을 주는 장애이거나, 설계 결정이 세 개 이상의 컴포넌트에 걸쳐 있을 때는 동기 대화를 먼저 제안한다. 비동기를 포기하는 게 아니라, "이건 동기가 더 빠르다"는 판단을 주저하지 않는 것이다.

내일 바로 쓸 수 있는 운영 기준

다섯 가지 실패에서 공통으로 발견한 것은 하나다. 비동기는 전제 조건이 갖춰진 뒤에야 유연성이 된다. 슬랙·노션·지라가 있어도 결정 권한이 모호하고, 컨텍스트 공유 관행이 없고, 알림이 정리되지 않으면 비동기는 속도를 낮추는 방향으로 작동한다. 아래는 우리가 실제로 운영하는 기준이다. 도입 순서대로가 아니라 손실이 컸던 순서대로 정렬했다.

① 결정 권한 매트릭스를 1페이지로 문서화하라. "이거 해도 되나요?"가 반복되는 도메인을 분류하고, 영역별로 누가 최종 결정권을 갖는지 명시한다. "자율 결정 후 사후 공유" 영역을 명확히 두는 것만으로 루프성 메시지가 눈에 띄게 줄었다. ② PR 설명 템플릿에 '왜'를 강제하라. 특히 결제·정산·자동화 코드는 변경 의도가 빠지면 리뷰어가 표면만 본다. '왜 이 방향인가', '어떤 케이스를 고려했나', '하드코딩 여부와 이유'를 세 항목으로 고정하면 리뷰 라운드가 절반 가까이 줄어든다. ③ 알림 채널을 즉각·당일·참고 세 계층으로 나눠라. 설계보다 어려운 건 첫 2주간 직접 틀린 채널 알림을 이동해서 팀 전체가 구조를 체감하게 하는 것이다. ④ 동기 전환 조건을 명시하라. 조건 없이 "비동기가 기본"만 있으면 매번 개인 판단에 맡겨지고 기준이 사람마다 달라진다. "결제 흐름 영향 장애" 또는 "세 개 이상 컴포넌트에 걸친 설계 결정"처럼 구체적인 트리거를 정해두면 된다. ⑤ 문서 업데이트를 완료 조건에 포함하라. 정책·API·정산 규칙 변경 시 코드 수정과 문서 업데이트를 같은 작업 단위로 묶는다. "코드는 됐는데 문서는 나중에"가 반복되면 새 팀원이 낡은 정보를 믿게 된다.

우리 팀 규모에서 이 구조를 만드는 데 한 달이 걸렸다. 그 한 달이 이후 수개월의 혼선을 줄였고, 그 혼선이 결제·정산 환경에서는 단순 불편이 아니라 실제 운영 손실로 연결된다는 걸 이미 경험했기 때문에 투자할 만했다.

— by mings