스타트업 답지 않은 우리의 운영 원칙

결제·정산 현장에서 "빠르게 부수기"가 통하지 않는 이유

스타트업 생태계에서 가장 자주 인용되는 조언 중 하나는 "빠르게 움직이고 뭔가를 부수어라(Move fast and break things)"다. 초기 사용자 피드백을 모으고, 빠르게 피벗하고, 일단 출시해서 반응을 본다. 소비자 앱이나 SaaS 프로덕트 맥락에서는 이 철학이 실제로 작동한다. 버그가 생겨도 다음 릴리즈에서 고치면 되고, 기능이 별로면 내리면 된다. 그런데 HEDVION이 다루는 결제·정산·자동화 시스템에서는 이 접근법이 직접적인 금전 손실로 번역된다.

우리가 다루는 작업의 성격을 구체적으로 보자. PG사 API 연동, 거래 데이터 정산 자동화, 세금계산서 발행 파이프라인, 정산 보고서 생성. 이 시스템에서 잘못된 로직은 예외를 던지고 멈추는 게 아니라, 틀린 숫자를 조용히 데이터베이스에 쓴다. 월 거래액 1억 원 규모의 클라이언트에서 부가세 처리 로직에 0.3% 오류가 있다고 가정하자. 월 30만 원, 분기에 90만 원의 차이가 만들어진다. 더 심각한 건, 이 오류가 분기 감사 때까지 발견되지 않는다는 것이다. 소급 정정은 현재 시점 수정보다 몇 배 더 많은 리소스를 소모하고, 클라이언트 신뢰는 그 이상으로 손상된다. "일단 배포하고 나중에 고친다"는 선택지가 이 도메인에서는 처음부터 없다.

동시 클라이언트 2곳 제한 — 작은 숫자에 담긴 큰 논리

HEDVION은 동시에 활성 클라이언트를 두 곳 이상 받지 않는다. 외부에서 보면 성장 의지가 없거나 소극적으로 보일 수 있다. 그러나 이 숫자는 결제·정산 프로젝트의 실제 구조를 역산한 결과다. 각 클라이언트는 각자 다른 PG사를 사용한다. KG이니시스와 토스페이먼츠의 API 스펙은 완전히 다르고, NHN KCP는 또 다른 인증 방식과 오류 코드 체계를 갖는다. 정산 주기도 다르다. D+1 정산, D+3 정산, 월 정산이 섞인 경우도 있다. 여기에 각 클라이언트의 세금계산서 발행 조건, 환불 처리 정책, 예외 거래 분류 기준이 각각 다르다.

이 컨텍스트를 동시에 세 곳 이상 유지하면서 오류 없이 운영하는 것은 3인 팀에게 현실적으로 불가능하다. 구체적으로 계산해보면 더 명확하다. 결제·정산 프로젝트 하나를 안정 운영 수준까지 올리는 데는 평균 2-3주의 초기 구축 작업이 필요하다. 이후에도 주 1회 이상의 예외 케이스 대응, 월별 정산 검증, PG사 API 변경 대응이 지속적으로 필요하다. 이 상시 유지보수 부하만으로도 한 사람이 안정적으로 담당할 수 있는 수는 두 곳이다. 세 번째를 추가하면 누군가는 반드시 50% 미만의 주의력을 받게 된다. 그 클라이언트에서 오류가 발생했을 때 "리소스가 부족했다"는 변명은, 처음부터 받지 말았어야 했다는 자인에 불과하다.

기술 부채가 정산 시스템에서 더 비싸게 돌아오는 이유

소프트웨어 개발에서 기술 부채는 늘 "나중에 갚으면 된다"는 암묵적 합의와 함께 쌓인다. 일반적인 웹 서비스에서 이런 부채는 개발 속도를 늦추는 결과에 그친다. 결제·정산 자동화 시스템에서는 다른 종류의 결과가 기다린다. 이 시스템의 기술 부채는 소리 없이 틀린 결과를 생산하는 메커니즘이 된다.

직접 목격한 사례가 있다. 자동화 스크립트에서 면세 거래 항목의 부가세를 0으로 처리해야 했는데, 초기 구현 당시 예외 조건 분기가 복잡하다는 이유로 일단 10%를 일괄 적용하고 TODO 주석을 남겼다. 해당 거래 유형의 빈도가 낮아 QA를 통과했고, 6개월 뒤 분기 감사에서 발견됐다. 소급 수정 작업에 사흘이 걸렸고, 클라이언트에 이를 설명하는 과정은 그보다 훨씬 길었다. 이 경험이 만든 결론은 하나다. 정산 로직에서 "일단 넘어가자"는 선택은 존재하지 않는다. 처리하거나, 처리하지 않을 것임을 명시적으로 문서화하거나 — 둘 중 하나다. 금전적 부채도 같은 원칙이다. 투자 유치를 위해 실제보다 부풀린 성장 지표를 만들지 않고, 수입이 없는 달이 있어도 버틸 수 있는 구조를 유지한다. 빚을 지지 않는 것은 결국 미래의 의사결정 자유도를 지키는 일이다.

"싫다"는 말이 전문성을 증명한다

모든 프로젝트 요청을 수락하는 팀은 기회에 적극적으로 보인다. 그러나 결제·정산 도메인에서 무리한 수락이 만드는 실제 비용은 겉으로 보이는 수익 기회보다 훨씬 크다. 가장 흔한 압박 패턴은 납기다. "2주 안에 PG 연동을 완료해달라"는 요청이 들어온다. 실제 소요 기간을 역산하면 이렇다. API 분석 및 연동 구현 5일, 예외 케이스·에러 핸들링 구현 5일, 스테이징 환경 검증 5일, 실결제 환경 테스트 및 안정화 모니터링 7일. 최소 22일이다. 이 납기를 맞추려면 어딘가를 건너뛰어야 한다. 가장 먼저 희생되는 것은 스테이징 검증이고, 그 결과는 실결제 환경에서 직접 오류를 경험하는 것이다.

이 요청을 거절할 때 우리가 쓰는 방식은 단순한 "안 됩니다"가 아니다. 각 단계의 소요 기간과 그것이 왜 필요한지를 명시적으로 설명하고, 어떤 단계를 클라이언트가 함께 조율할 수 있는지 역제안한다. 이렇게 납기를 협의하는 과정에서 "왜 그 시간이 필요한지"를 이해한 클라이언트들이 장기 파트너가 됐다. 반대로, 어떤 설명도 듣지 않고 납기만 고집하는 요청은 프로젝트 전반에서 같은 패턴이 반복된다는 신호로 본다. 거절은 우리 자신을 지키는 행위인 동시에, 클라이언트에게 "이 작업이 얼마나 정밀해야 하는지"를 전달하는 전문가로서의 책임 표명이다.

안전망이 원칙을 지킨다 — 구조의 문제

HEDVION의 운영 원칙이 선언에 그치지 않는 이유는 팀 구조에 있다. 세 명 모두 이 팀 외에도 생계를 유지할 수 있는 수입 기반이 있다. 이것이 "원칙을 선택할 수 있는 권한"을 만든다. VC 투자를 받은 스타트업은 런웨이(runway) 압박 아래에 있다. 투자금이 소진되기 전에 성장 지표를 만들어야 한다는 구조적 압박이 모든 의사결정을 왜곡한다. 맞지 않는 클라이언트도 수락하고, 현실적이지 않은 납기도 맞추려 하고, 기술 부채를 알면서도 쌓는다. 원칙이 있어도 지키기 어려운 구조다. 만약 HEDVION 팀원 세 명의 유일한 생계 수단이 이 팀이었다면, 지금 이 원칙들 중 몇 개는 이미 깨져 있었을 것이다. 이것은 솔직한 인정이다.

이 구조는 트레이드오프이기도 하다. 생존을 위한 성장 드라이브가 없다는 것은 스케일이 느리다는 뜻이기도 하다. 같은 도메인에서 투자를 받고 빠르게 팀을 키운 곳이라면 지금쯤 더 많은 클라이언트와 더 넓은 시장을 갖고 있을 것이다. 우리는 그 방향을 의도적으로 선택하지 않았다. 5개월을 돌아보면, 합의한 원칙을 깨야 할 만큼 절박한 순간이 오지 않았다. 재계약률은 100%였고, 신규 문의의 절반 이상이 기존 클라이언트 소개(레퍼럴)를 통해 들어왔다. 숫자로 보여주기 어려운 것들이 실제로 작동하고 있다는 우리의 간접 지표다.

지금 당장 써먹을 수 있는 시사점

이 원칙들은 HEDVION의 특수한 사정에서 나왔지만, 결제·정산·자동화를 다루는 소규모 팀이라면 지금 바로 적용할 수 있는 항목이 있다.

동시 활성 클라이언트 수의 상한선을 팀 내에서 명시적으로 합의하라. "몇 곳이 적정한가"를 역산하는 방법은 단순하다. 한 클라이언트에서 긴급 이슈가 발생했을 때 나머지 클라이언트의 SLA를 정상적으로 유지할 수 있는 수가 최대치다. 이 숫자를 합의하지 않으면 상한선 없이 부하가 쌓이고, 뒤늦게 감당하게 된다.

납기 요청에는 단계별 역산으로 역제안하라. "안 됩니다" 대신 "API 분석 5일, 예외 처리 5일, 스테이징 검증 5일, 실환경 안정화 7일로 최소 22일 필요합니다. 어떤 단계를 함께 조율할 수 있는지 검토합시다"가 전문가의 거절이다. 이 방식은 거절이 아니라 협상의 시작점이 되고, 결과적으로 품질과 관계를 동시에 지킨다.

정산 로직의 기술 부채는 코드 주석이 아닌 별도 문서로 관리하라. 예외 처리를 미룬 항목, 하드코딩으로 임시 처리한 로직, 향후 PG사 정책 변경에 영향받을 가능성이 있는 부분을 날짜·영향 범위·우선순위가 명시된 별도 파일(tech-debt.md 등)에 기록하라. 침묵하는 오류는 기록되지 않은 부채에서 나온다.

분기마다 각 클라이언트 관계를 팀 내에서 재검토하라. 수익 때문에 관성적으로 유지되는 관계가 팀 원칙을 서서히 갉아먹는다. 3개월에 한 번, 각 클라이언트 관계가 처음 합의한 작업 범위와 방식을 유지하고 있는지 팀 내 체크인을 루틴으로 만들어라. 이것이 장기적으로 원칙을 지키는 구조적 장치가 된다.