사이드 프로젝트가 제품이 된 순간

결제·정산 팀의 사이드 프로젝트는 다른 지점에서 위기를 맞는다

모든 사이드 프로젝트가 제품이 되길 바라는 건 아니다. 배우고 싶어서, 혹은 직접 해결하고 싶어서 만드는 경우가 훨씬 많다. HEDVION에서 운영하는 도구들도 처음엔 그랬다. 정산 데이터를 빠르게 확인하려고 만든 대시보드, 반복적인 입금 확인 작업을 줄이려고 짠 자동화 스크립트, PG사 응답 파싱이 귀찮아서 올려둔 작은 파서—모두 "팀 내부에서만 쓸 용도"로 시작했다.

그런데 결제·정산을 직접 운영하는 팀의 사이드 프로젝트는 다른 도메인과 다른 지점에서 위기를 맞는다. 단순히 외부에 공개된다는 사실이 문제가 아니다. 돈과 직결된 데이터를 다루는 도구가 팀 외부로 나가는 순간, 에러 하나가 단순한 UX 불편이 아니라 금액 오차나 정산 지연으로 이어질 수 있다는 걸 온몸으로 실감했다. 이게 우리가 전환을 두 번 실패하고 나서야 제대로 이해한 전제다.

"이거 써도 되냐"는 질문이 결제 도메인에서 무거운 이유

전환점은 생각보다 조용하게 왔다. 우리가 내부적으로 쓰던 정산 대사(reconciliation) 자동화 도구를 거래처 담당자에게 데모로 보여줬을 때, 돌아온 반응이 그 한 마디였다. "이거 우리도 써도 되냐." 그 질문이 분기점이었다.

그때까지 해당 도구는 에러 처리가 없었다. PG사 API가 타임아웃을 내뱉으면 스크립트 자체가 멈췄고, 재시도 로직도 없었다. 설정 파일은 직접 수정해야 했고, 결과 파일은 로컬 디렉터리에 쌓였다. 우리가 쓸 때는 "뭔가 이상하면 내가 들어가서 고치면 되지"로 넘어갔다. 하지만 외부 사용자에게 이 도구를 넘기는 순간 그 논리가 붕괴된다. 상대방은 Python 환경이 없고, 로그를 볼 권한도 없고, 뭔가 잘못됐을 때 전화할 수밖에 없다—결제 데이터가 묶인 채로.

실제로 전환 초기에 이런 일이 있었다. 월말 정산 시점에 PG사 정산 파일 포맷이 미세하게 바뀌었다. 컬럼 하나가 추가된 수준이었다. 파서는 이를 조용히 무시하고 넘어갔다. 내부에서 쓸 때는 결과를 사람이 직접 검수했기 때문에 차이를 바로 잡아냈다. 하지만 그 시점에 외부 파트너에게 자동화된 결과를 이미 넘긴 상황이었다면? 약 340만 원 규모의 정산 건이 누락된 채 처리될 뻔했다. "이거 써도 되냐"에 가볍게 "응"이라고 했을 때의 리스크가 이 정도다.

사이드 프로젝트와 제품의 실질적 차이: 기능이 아니라 장애 시나리오

사이드 프로젝트와 제품의 차이를 흔히 "안정성"이나 "완성도"로 이야기한다. 맞는 말이지만 결제·정산 도메인에서는 더 구체적으로 정의해야 한다. 핵심 차이는 하나다. 장애가 났을 때 누가 원인을 추적하느냐.

사이드 프로젝트는 만드는 사람이 맥락을 다 알고 있다. 뭔가 이상하면 직접 들어가서 고치면 된다. 제품은 만드는 사람이 없는 시간에도 돌아가야 하고, 더 나쁜 경우엔 만드는 사람이 모르는 방식으로 쓰인다. 우리 팀이 전환 과정에서 가장 먼저 손댄 것도 기능이 아니었다. 에러 메시지였다. KeyError: 'amount'가 그대로 뜨는 걸 외부 사용자가 보면 뭘 해야 할지 모른다. 그 다음은 로그였다. 언제, 어떤 트랜잭션에서, 어떤 값이 들어왔을 때 실패했는지를 원격으로 볼 수 있어야 했다. 그러고 나서야 기능 추가 이야기가 나왔다.

기능보다 관측 가능성(observability)이 먼저라는 원칙은 당연해 보이지만, 사이드 프로젝트 감각으로 움직이면 자꾸 기능에 먼저 손이 간다. 특히 "저쪽에서 이 기능도 되면 좋겠다고 했다"는 말이 들어오기 시작하면 더 그렇다. 우리도 예외가 아니었다. 로그 인프라가 없는 상태에서 필터 기능을 먼저 추가했다가, 나중에 배 이상의 공을 들여 관측 계층을 다시 깔았다.

전환 과정에서 결제 팀이 반드시 해결해야 할 세 가지

첫째, 의존성 감사다. 사이드 프로젝트는 "일단 되면 된다" 식으로 라이브러리를 추가한다. 우리 정산 도구에는 실제로 쓰이지 않는 pandas 서브모듈이 임포트되어 있었고, 버전 고정도 없었다. 의존성 트리를 정리했더니 컨테이너 이미지 크기가 1.4GB에서 380MB로 줄었고, 콜드 스타트가 약 40% 단축됐다. 이건 단순한 최적화가 아니다. 월말 정산 마감 시간대에 스케일 아웃이 필요할 때 이 차이가 체감으로 나타난다.

둘째, 데이터 모델 조기 안정화다. 초기엔 스키마를 여러 번 바꿔도 문제없었다. 내가 직접 DB에 들어가서 바꾸면 됐으니까. 그런데 외부 사용자가 생기는 순간, 마이그레이션은 "공지 → 일정 조율 → 검증 → 롤백 플랜"이 딸려온다. 우리가 배운 교훈은 명확하다. 정산 원장 테이블의 핵심 컬럼—거래 ID, 정산 금액, 상태값, 생성 일시—은 첫 외부 사용자 온보딩 전에 반드시 확정해야 한다. 컬럼을 추가하는 건 나중에 해도 되지만, 기존 컬럼의 타입이나 의미를 바꾸는 순간 외부 연동이 조용히 깨진다.

셋째, 운영 비용의 현실화다. 사이드 프로젝트는 서버 비용이 월 2~3만 원 나와도 "실험이니까"로 넘어간다. 제품은 그렇지 않다. 우리 정산 도구의 경우, 파트너가 3곳일 때 월 운영 비용이 약 18만 원이었는데, 8곳으로 늘었을 때 단순 비례가 아니라 48만 원이 됐다. 배치 처리 비용과 스토리지 비용이 동시에 올라가는 구간이 있었기 때문이다. 이 계단을 미리 시뮬레이션해두지 않으면, 파트너가 늘어날수록 오히려 손해를 보는 구조가 된다.

우리 팀이 지금 이 순간 쓰는 기준

지금 HEDVION 팀 내부에는 비슷한 경계선에 놓인 도구가 두세 개 있다. 세금계산서 발행 매칭 자동화 스크립트, 특정 PG사 응답 정규화 모듈, 환불 케이스 분류 규칙 엔진이 그것이다. 이것들이 "이거 써도 되냐"를 들을 가능성은 충분히 있다.

그 질문을 받기 전에 우리가 먼저 통과시키는 기준은 세 가지다. 첫째, 이 도구가 실패했을 때 사용자가 스스로 원인을 파악할 수 있는가. 에러 메시지가 사람이 읽을 수 있는 수준인지, 어떤 데이터가 문제였는지 알 수 있는지. 둘째, 데이터 포맷이 바뀌었을 때—예를 들어 PG사 정산 파일 스펙 변경—도구가 조용히 잘못된 결과를 내지 않고 명확하게 실패하는가. 셋째, 이 도구를 한 달 더 운영했을 때의 예상 비용을 지금 계산할 수 있는가. 세 가지 중 하나라도 "모르겠다"라면, 그 도구는 아직 제품이 아니다. 이 기준은 두 번의 전환 실패를 겪고 나서 만든 것이어서 보수적으로 느껴질 수 있다. 하지만 결제·정산 도메인에서 "일단 내보내고 보자"의 비용은 코드 수정으로 끝나지 않는다.

지금 바로 써먹을 수 있는 전환 체크리스트 5단계

전환은 한 번에 이루어지지 않는다. 코드 한 줄 바꾼다고 제품이 되는 게 아니다. 사용자가 생기고, 그 사용자가 기대를 갖기 시작할 때부터 조금씩 제품이 된다. 하지만 그 과정을 더 빠르고 안전하게 만드는 구체적인 순서는 있다. 아래는 HEDVION 팀이 내부 도구를 외부로 내보내기 전 반드시 통과시키는 실전 체크리스트다.

1단계 — 실패 시나리오 먼저 쓰기: 도구가 정상 동작하는 케이스보다 실패하는 케이스를 먼저 문서화한다. PG사 응답이 없을 때, 파일 포맷이 바뀔 때, 금액이 0원일 때, 같은 거래 ID가 두 번 들어올 때. 이 시나리오마다 도구가 어떻게 반응하는지 확인하는 것이 출발점이다.

2단계 — 관측 계층 먼저: 기능 추가 전에 로깅과 알림을 먼저 붙인다. "어떤 입력이 들어왔을 때 실패했는가"를 사후에 추적할 수 있어야 한다. Slack 웹훅 하나라도 달아두는 것이 관측 계층의 시작이다. 이 순서를 바꾸면 나중에 두 배 이상의 공을 들인다.

3단계 — 데이터 모델 리뷰: 핵심 테이블의 컬럼 목록과 타입을 문서로 뽑아서, "이게 바뀌면 어떤 연동이 깨지는가"를 그린다. 이 다이어그램이 없으면 스키마 변경은 항상 예상보다 큰 파장을 만든다.

4단계 — 운영 비용 계단 시뮬레이션: 현재 사용량 기준 비용과, 사용자 3배·10배일 때 예상 비용을 계산한다. 계단이 어디서 생기는지 미리 파악해야 파트너 온보딩 속도와 가격 정책을 조율할 수 있다.

5단계 — 롤백 경로 확인: 도구를 오프라인으로 내릴 때 사용자가 수동으로 할 수 있는 대안을 명시한다. 결제·정산 도구는 "잠깐 점검 중"이 허용되지 않는 경우가 많다. 롤백 경로가 없는 도구는 제품이 아니라 의존성이다.

이 다섯 단계를 마치고 나서야 "이거 써도 되냐"는 질문에 자신 있게 "응, 이렇게 쓰면 돼"라고 답할 수 있다.

— by slecs