다음 5개월 — 팀이 합의한 3가지

결제·정산 현장에서 "팀 합의"가 더 무거운 이유

팀 운영 원칙에 관한 이야기는 어디서나 나온다. 하지만 결제·정산·자동화를 직접 운영하는 팀에게는 무게가 다르다. 우리가 다루는 코드 한 줄은 클라이언트의 정산 금액에 직접 닿는다. 웹훅 하나가 누락되면 실제 돈이 이상하게 기록된다. 자동화 파이프라인이 잘못 설계되면 수백 건의 트랜잭션이 오분류된 채로 장부에 쌓인다.

이 맥락에서 "방향이 흐트러지면 에너지가 분산된다"는 말은 단순한 생산성 얘기가 아니다. 분산된 집중력이 결제 로직 안으로 들어오면 그건 버그가 아니라 금전 오류다. 그래서 영상통화 두 시간 끝에 나온 세 가지 합의는 팀 문화 이야기인 동시에, 운영 리스크를 줄이는 구조 설계 이야기다.

첫째 합의 — 동시에 두 곳 이상 받지 않는다

이 규칙이 나온 건 직접 겪었기 때문이다. 두 클라이언트를 병행하던 시기, 한쪽은 PG사 연동 마무리 단계였고 다른 쪽은 정산 자동화 초기 설계 중이었다. 겉으로는 다른 도메인처럼 보이지만, 두 시스템의 결제 흐름을 동시에 머릿속에 올려두는 건 전혀 다른 부하다. A 클라이언트의 웹훅 이벤트 스펙과 B 클라이언트의 정산 테이블 구조를 동시에 세밀하게 생각하다 보면 뇌가 두 시스템의 경계를 흐리기 시작한다.

실제로 그 시기에 작지만 상징적인 일이 생겼다. A 클라이언트 코드에 B 클라이언트 정산 기준을 혼재한 주석을 달았다. 코드 자체는 동작했지만, 리뷰 과정에서 "이 로직이 왜 이렇게 됐는지" 설명하는 데 불필요한 시간을 썼다. 결제·정산 도메인에서 이 혼선이 로직 레벨로 내려오면 더 이상 사소하지 않다. Microsoft Research의 연구(2006)에 따르면 인터럽션 이후 원래 작업으로 완전히 돌아오는 데 평균 23분이 걸린다. 세 명 팀이 하루 6회만 문맥 전환해도 집중 복원 비용이 순수하게 2시간 이상이다. 전체 운영 시간의 25%다. 돈이 된다고 이 비용을 감당할 수 없다.

한 곳을 마무리하고 다음을 시작하는 구조를 지키는 이유는 완벽주의가 아니다. 결제 시스템에서 집중력 분산은 실제 금전 비용이기 때문이다. 겹치는 기간을 인수인계 수준으로만 허용하는 것도 같은 맥락 — 인수인계는 정보 전달이지 동시 설계가 아니다.

둘째 합의 — 기술 실험은 내부 프로젝트로만 한다

자동화·정산 인프라에서 새 기술을 클라이언트 환경에 처음 쓰는 건 단순히 "배울 시간이 부족해서" 위험한 게 아니다. 파악하지 못한 실패 모드가 돈에 직접 닿는 지점에서 처음 드러나기 때문이다.

구체적인 시나리오를 하나 들자. 메시지 큐 기반 정산 파이프라인을 신규 도입할 때, BullMQ를 내부에서 충분히 검증하지 않은 상태로 클라이언트 환경에 올렸다고 하자. Dead letter queue 처리를 제대로 설계하지 못한 채로 나갔을 경우, 정산 배치 중 일부 작업이 재시도 없이 조용히 실패한다. 모니터링이 이 실패를 잡지 못하면 클라이언트는 정산 오류를 며칠 뒤 장부를 맞추다가 발견한다. 우리가 지금 운영하는 내부 서버와 이 팀 블로그가 그 실험 무대다. 블로그 배포 파이프라인에서 GitHub Actions 신기능을 먼저 써봤고, 내부 정산 모니터링 도구에서 새 알림 채널을 먼저 돌렸다. 실패를 처음 당하는 쪽은 우리다. 클라이언트가 지불하는 개발 비용에 실험 비용이 암묵적으로 포함되어선 안 된다.

트레이드오프는 명확하다. 클라이언트 프로젝트에서 처음 쓰면 실제 제약 아래서 빠르게 배운다. 하지만 그 학습 비용은 클라이언트의 시간과 돈으로 치러진다. 우리가 선택한 건 배움의 속도를 약간 늦추되, 클라이언트에게 검증된 판단만 넘기는 것이다. 결제 시스템에서 "써봤더니 이런 문제가 있더라"는 말은 이미 늦다.

셋째 합의 — 결정은 그날 텍스트로 남긴다

구두 합의가 흐릿해지는 건 기억력 문제가 아니라 해석의 문제다. 같은 대화를 나눠도 각자 머릿속에 저장되는 맥락이 다르다. "다음 클라이언트는 좀 더 여유 있게 받자"는 말이 누군가에게는 "한 달 뒤 시작하자"이고, 다른 누군가에게는 "인수인계 2주면 된다"로 기억된다. 이 차이는 실제 계약 협상 테이블에서 드러난다.

결제·정산 도메인에서는 이 문제가 더 직접적이다. 이 영역의 팀 합의는 기능 스펙이나 아키텍처 결정과 연결되는 경우가 많다. "정산 기준은 결제 완료일 기준으로 한다"는 합의가 텍스트로 없으면, 3개월 뒤 클라이언트가 "결제 신청일 기준으로 다시 잡아달라"고 요청했을 때 우리가 그 결정을 왜 내렸는지 설명할 근거가 없다. 로그가 없는 시스템은 디버깅이 불가능하다. 팀 합의도 마찬가지다. 우리가 기록 형식으로 선택한 건 단순하다. 날짜 + 한 줄. "2026-05-02: 클라이언트 동시 두 곳 이상 받지 않기로 합의." 길게 쓰지 않는다. 대신 반드시 그날 쓴다. 하루가 지나면 맥락이 흐려지고, 사흘이 지나면 해석이 갈린다.

세 합의의 공통 구조 — 에너지 누수를 막는다

세 가지를 나란히 놓고 보면 설계 원리가 하나다. 모두 에너지 누수를 막는 구조다. 클라이언트 병행 금지는 집중력 누수를 막는다. 내부 실험 우선은 신뢰 비용 누수를 막는다. 텍스트 기록은 해석 논쟁 비용 누수를 막는다.

세 명짜리 팀에서 에너지 누수는 곧 팀 붕괴로 이어진다. 대기업은 프로세스가 비효율적이어도 인력으로 메울 수 있다. 우리는 그럴 수 없다. 세 명이 결제 시스템 하나를 제대로 만들려면 세 명의 집중력이 온전히 거기에 향해야 한다. 절반씩 두 곳에 향하는 것과 온전히 한 곳에 향하는 것의 결과물 차이는 50%가 아니라 그보다 훨씬 크다. 결제·정산 시스템의 복잡성은 선형적으로 증가하지 않기 때문이다. 환불 처리, 멱등성 보장, PG사별 에러 코드 처리, 월말 정산 배치 예외 케이스 — 이것들은 깊은 맥락에서만 제대로 다뤄지고, 깊은 맥락은 지속적인 집중에서만 나온다.

지금 바로 써먹을 수 있는 시사점

소규모 팀, 특히 결제나 자동화처럼 실수 비용이 높은 도메인을 다룬다면 아래 네 가지를 지금 적용할 수 있다.

1. 지금 동시에 진행 중인 프로젝트 수를 세어라. 두 개 이상이면 집중력이 얼마나 분산됐는지 이미 체감하고 있을 것이다. 다음 계약 협상에서 "현 프로젝트 마무리 후 시작" 조건을 명시적으로 제안해보라. 이 조건을 거절하는 클라이언트는 사실 우리 팀과 맞지 않는 클라이언트일 가능성이 높다.

2. 최근 3개월 안에 클라이언트 코드에 처음 써본 기술이 있다면 목록을 만들어라. 지금 문제없이 돌아가더라도, 엣지 케이스에서 문제가 생겼을 때 "익숙하지 않았던 기술"이 원인일 수 있다. 내부 프로젝트 우선 규칙을 지금부터 적용하면 다음 클라이언트부터 달라진다.

3. 지난 한 달 구두 합의 중 기억이 흐릿한 게 있다면 지금이라도 기록해라. 완벽하지 않아도 된다. "2026-06-04: 기억 불명확하지만 당시 합의로 기억하는 것 — 정산 기준은 결제 완료 기준." 이렇게라도 남기면 없는 것보다 낫다.

4. 팀 합의 파일 하나를 지금 만들어라. Notion이든 마크다운 파일이든 형식은 중요하지 않다. 날짜 + 한 줄 + 관련자가 들어가는 구조면 된다. 이 파일은 팀이 성장하거나 외부 사람이 합류할 때 온보딩 기준선이 된다. 그리고 5개월 뒤 회고를 쓸 때, 오늘의 합의가 텍스트로 남아 있다는 사실 자체가 이 규칙의 효과를 이미 증명하는 셈이다.