5개월의 회고 — HEDVION 의 첫 분기

시작은 단순했다 — 그 단순함이 5개월을 버티게 했다

작년 12월, 슬렉스와 밍스, 그리고 나는 각자 다른 클라이언트의 결제·정산 업무를 따로따로 수행하고 있었다. 배포 자동화, 정산 배치 스크립트 오류 대응, 클라이언트 문의 처리. 문제는 각자 풀고 있는 게 거의 동일했다는 점이다. 아무도 혼자서 이 세 가지를 동시에 빠르게 처리하지 못했다. 셋이 따로 움직이면 각자 비슷한 실수를 반복했다.

팀을 만든 이유는 거창한 비전이 아니었다. 우리가 개별적으로 마주하던 비효율을 함께라면 줄일 수 있다는 실용적 판단이었다. HEDVION이라는 이름도 마찬가지다. 세 명이 납득할 수 있는 이름, 그 이상도 이하도 아니었다. 돌이켜보면 이 단순함이 의사결정 피로를 줄이고 5개월을 버티게 한 동력이었다. 비전보다 불편함이 더 강한 창업 동기였다.

우리가 틀렸던 것들: 경계는 생각보다 훨씬 흐릿했다

첫 번째 착각은 역할 분리였다. 프로젝트 단위로 백엔드·프론트엔드·인프라를 나누면 된다고 생각했다. 결제·정산 도메인에서 이 경계는 빠르게 무너졌다. 정산 배치 작업을 인프라 담당이 설정하면 배치 결과를 노출하는 백엔드 API 스펙이 바뀌어야 했고, 프론트에서 정산 내역 조회 화면을 짜다 보면 API 응답 구조 자체를 설계부터 다시 논의해야 했다. PG사 웹훅 재시도 처리 로직이 백엔드 소관인지 인프라 소관인지 결정하는 데 실제로 하루를 썼다. 그 하루가 클라이언트 정산 오류로 이어질 뻔했다.

두 번째는 문서화 공백이었다. 세 명이 다 알고 있으니 적을 필요가 없다는 논리는 딱 3개월까지 유효했다. 4개월 차에 밍스가 "이 정산 로직 왜 이렇게 돼 있어?"라고 물었을 때 아무도 기억하지 못했다. 결제 관련 비즈니스 룰은 변경 이력이 곧 감사 자료인데, 우리는 그걸 머릿속에만 저장하고 있었다. 세 번째는 납기 추정이다. 결정은 빠른데 실행 인원이 셋뿐이라 병렬 처리에 한계가 있었다. 정산 시스템 개편과 신규 클라이언트 온보딩이 겹쳤던 2월이 가장 힘들었다. 결국 한 작업을 2주 미루는 선택을 해야 했다.

결제·정산 현장에서 세 명이 감수해야 하는 리스크

이 도메인에서 소규모 팀이 갖는 가장 큰 리스크는 **단일 장애점(Single Point of Failure)**이다. 정산 배치 스케줄링의 전체 지식이 한 명에게만 있는 구조가 2개월간 지속됐다. 그 사람이 갑자기 빠지면 해당 기능의 맥락도 함께 사라진다. 우리는 결과적으로 운이 좋았을 뿐이다. 결제 시스템에서 배치가 멈추는 것은 데이터 정합성 문제로 직결되고, 그건 단순 장애가 아니라 클라이언트 신뢰의 문제가 된다.

트레이드오프는 분명하다. 작은 팀은 커뮤니케이션 비용을 아낀다. 슬랙에서 세 글자로 의도가 통하고, 대기업에서 이메일 쓰고 승인받던 결정이 15분 안에 내려졌다. 그러나 그 낮은 비용이 문서화를 미루는 핑계가 됐다. 수치로 말하자면, 운영 규칙을 텍스트로 남기기 시작한 이후 "이게 왜 이렇게 돼 있어?" 유형의 질문이 이후 3개월간 거의 나오지 않았다. 기술 선택 속도는 진짜 장점이었다. 이벤트 기반 정산 집계 파이프라인 실험을 2주 만에 프로토타입까지 냈는데, 대기업 구조였다면 아키텍처 리뷰 일정 잡는 데만 2주가 걸렸을 것이다. 단, 빠름에는 사후 검토 없는 기술 부채가 반드시 붙는다.

우리 팀이라면 이렇게 했을 것이다: 2월 과부하 시나리오

지금 시점에서 돌아보면 2월의 과부하를 막을 수 있었던 방법이 세 가지 있다.

지식 지도 방식의 소유권. 프로젝트 단위가 아니라 도메인 지식 단위로 소유권을 정하는 방식이다. "정산 배치 전체 로직을 이해하는 사람이 최소 두 명"이라는 규칙 하나만 있었어도 단일 장애점을 피할 수 있었다. 역할이 아니라 지식의 분포를 설계해야 한다. 지금은 이 원칙을 실제로 적용 중이다.

경량 ADR(Architecture Decision Record). 우리 규모에서 무거운 문서는 작성하지 않는다. 대신 Notion에 다섯 줄짜리 결정 로그를 남긴다. "왜 이걸 선택했는지, 무엇을 포기했는지, 언제 재검토할지." 결제 로직 변경 이력이 여기 쌓인다. 외부 감사나 클라이언트 문의가 오면 이 로그가 1차 대응 자료가 된다.

클라이언트 동시 수용 상한 설정. 한 번에 두 곳 이상 받지 않는다는 원칙을 세웠다. 정산 주기가 겹치는 두 클라이언트를 동시에 운영할 때 배치 오류가 겹치면, 세 명이 각각 하나씩 잡으면 남는 사람이 없다. 트리아지(triage)를 할 여력이 사라진다. 상한선은 팀 역량의 솔직한 선언이다.

블로그가 실제로 일의 품질을 바꿨다

처음엔 포트폴리오 겸 정리 용도로 글을 썼다. 6주쯤 지나 패턴을 발견했다. 글로 설명할 수 없는 결정은 우리가 아직 이유를 제대로 모르는 결정이었다. 정산 배치 에러 처리 로직을 블로그 포맷으로 정리하려고 앉았다가, 그 과정에서 엣지 케이스 두 개를 새로 발견했다. 코드는 돌아가고 있었지만 설계는 덜 된 상태였다.

이건 단순한 글쓰기 효과가 아니다. 결제·정산처럼 예외 케이스가 많고 비즈니스 룰이 복잡한 도메인에서, 언어로 설명할 수 없는 코드는 대개 설계가 덜 된 코드다. 글쓰기가 코드 리뷰의 역할을 일부 대체한 셈이다. 팀이 세 명이라 공식적인 리뷰 프로세스를 갖추기 어려운 상황에서, 블로그는 예상치 못한 품질 도구가 됐다.

다음 5개월: 지금 바로 가져갈 수 있는 시사점

팀 규모는 당분간 세 명으로 유지한다. 지금 구조가 우리한테 맞는지 검증되지 않은 상태에서 사람을 더 넣는 건 성급하다. 비슷한 규모의 팀을 운영하거나 시작하려는 사람이 이 회고에서 바로 가져갈 수 있는 것들을 정리하면 다음과 같다.

1. 역할 분리보다 지식 커버리지를 먼저 설계하라. 누가 어떤 코드를 쓰는지보다, 어떤 지식이 몇 명에게 있는지가 중요하다. "이 기능을 설명할 수 있는 사람이 최소 두 명"을 원칙으로 삼아라. 결제·정산처럼 운영 의존도가 높은 영역에서 지식이 한 명에게만 있으면 그 자체가 운영 리스크다.

2. 문서화는 팀 규모와 무관하게, 기억이 흐려지기 전에 해라. 세 명도 3개월 지나면 기억이 달라진다. 다섯 줄짜리 결정 로그면 충분하다. 날짜, 선택 이유, 포기한 것, 재검토 시점. 이 네 가지만 있으면 나중에 감사 대응도, 클라이언트 소명도 훨씬 쉬워진다.

3. 납기 추정에 실행 인원 계수를 반드시 넣어라. 팀이 작으면 결정은 빠르지만 실행은 느리다. 납기를 제시할 때 "세 명이 이것만 집중할 때"라는 전제를 명시해야 한다. 그렇지 않으면 계획은 항상 낙관적이고 현실은 항상 늦다.

4. 클라이언트 수용 한도를 숫자로 정하고 지켜라. "우리 역량 안에서"는 기준이 아니다. "동시에 두 곳"처럼 숫자로 정해야 실제로 지킬 수 있다. 초과하는 제안이 들어왔을 때 숫자가 방패가 된다.

5. 설명할 수 없는 결정은 결정이 아니다. 코드든 아키텍처든, 5분 안에 왜 그렇게 했는지 설명할 수 없다면 다시 생각해라. 결제·정산 도메인에서 "일단 돌아가니까"는 반드시 나중에 비용이 된다. 그 비용은 대개 클라이언트와의 신뢰로 치른다.

돌아보면 실패한 지점들이 더 선명하게 기억에 남는다. 그게 다음 5개월의 재료다.

— by slecs