외주 vs 내재화 — 우리가 처음 외주를 시도한 이유

왜 우리는 그토록 오래 내재화를 고집했나

결제와 정산을 직접 운영하는 팀에게 내재화는 단순한 선호가 아니다. 거의 생존 전략에 가깝다. 우리가 다루는 로직—정산 주기별 금액 합산, 수수료 계산, 오류 트랜잭션 보정, 자동화된 리컨사일리에이션—은 외부 사람이 맥락 없이 들여다보면 왜 이런 분기가 있는지조차 이해하기 어렵다. 거래 수단마다 다른 정산 기준, 특정 결제 수단의 취소·환불 흐름, 특수 케이스를 처리하는 예외 로직들은 그냥 코드가 아니다. 우리가 수년간 부딪혀가며 학습한 업무 지식 그 자체다.

그래서 "외부에 맡기면 안 된다"는 직관은 상당 부분 합리적인 근거가 있었다. 커뮤니케이션 비용이 더 든다는 것도 사실이고, 품질 컨트롤이 어렵다는 것도 사실이다. 그런데 우리가 진짜 피하고 싶었던 것은 따로 있었다. 핵심 로직에 대한 통제권 상실이다. 정산 오류가 발생했을 때 코드를 직접 뜯어볼 수 있는 사람이 팀 안에 반드시 있어야 한다—이 확신이 내재화 고집의 진짜 뿌리였다.

그 결정의 배경: 동시다발적 바쁨의 해부

문제는 특정 시점에 터졌다. 결제 게이트웨이 하나의 API 스펙이 바뀌면서 연동 수정이 필요했고, 동시에 정산 자동화 파이프라인에서 엣지 케이스가 발생해 보정 작업이 병행되고 있었다. 세 명이 각자 주도하는 영역이 있는데, 그 시기엔 세 영역이 전부 빨간불이었다. 팀 규모가 작을수록 이런 동시다발적 병목은 치명적이다. 누군가 한 명이 빠지면 그 영역이 통째로 멈춘다.

그 타이밍에 백오피스 화면 하나가 요청됐다. 파트너사 담당자가 특정 정산 건을 조회하고, 상태를 변경하고, 메모를 남길 수 있는 관리 인터페이스였다. 기능 자체는 CRUD에 가까웠다. 내부 운영용이라 디자인 요건도 낮았다. 그러나 우리 중 누가 이것을 맡으면 최소 2주, 넉넉히 잡으면 2.5주의 집중 작업이 필요했다. 그 기간이 지금 당장 우선순위인 게이트웨이 수정과 파이프라인 안정화를 실질적으로 밀어낸다. 기회비용이 너무 명확했다. 처음으로 외주를 진지하게 검토한 순간이었다.

외주의 실제 비용 구조: 우리가 틀린 부분

우리의 초기 계산은 이랬다. "명세서 작성 3일 + 외주 개발 2주 + 검수 3일 = 총 약 3.5주. 직접 하면 2.5주. 조금 더 걸리지만 우리의 집중을 아낄 수 있다." 단순하고 낙관적인 계산이었다. 실제로는 달랐다.

명세서 작성에 3일이 아니라 5일이 걸렸다. "단순한" 정산 건 조회 화면도 막상 문서화하려니 예외 케이스들이 줄줄이 튀어나왔다. 상태값이 7개였고, 각 상태에서 가능한 전환이 달랐으며, 특정 상태에서는 메모 작성 권한이 달라져야 했다. 첫 번째 결과물이 나왔을 때 상태 전환 흐름이 의도와 달랐다. 수정 사이클이 두 번 더 돌았고, 각 사이클마다 슬랙 스레드가 30개 이상 쌓였다. 총 커뮤니케이션 시간을 추산해보니 약 8~10시간이었다. "절약"했다고 생각한 시간의 상당 부분이 다른 형태로 돌아온 셈이다.

그럼에도 흥미로운 반전이 있었다. 커뮤니케이션에 쓴 그 8~10시간은 산발적이었다. 30분 답변하고 다른 작업 3시간, 피드백 확인 20분 후 또 다른 작업—이런 식이었다. 반면 직접 만들었다면 2.5주의 집중 블록이 통째로 묶였을 것이고, 그 기간 동안 게이트웨이 수정이 실질적으로 멈췄을 것이다. 이 경험에서 배운 핵심이 여기 있다. 외주의 진짜 이점은 "총 시간 절약"이 아니라 "집중 블록 분리"다. 핵심 우선순위 작업이 방해받지 않고 계속 돌아갈 수 있었다는 것이 우리가 실제로 얻은 가치였다.

결제·정산 로직은 왜 절대 외주가 아닌가

이 경험을 정리하면서 가장 명확하게 정비한 것은 경계선이다. 백오피스 UI는 외주가 가능했다. 하지만 그 화면 뒤에서 돌아가는 상태 전환 로직, 정산 금액 계산, 오류 처리 흐름은 단 한 줄도 외부에 나가지 않았다. 앞으로도 나가서는 안 된다.

이유는 세 가지다. 첫째, 결제·정산 버그의 비용은 즉각적이고 비대칭적이다. UI 버그는 사용자가 불편하고, 정산 버그는 돈이 잘못 간다. 외주 개발자가 "왜 이 조건에서 수수료를 이중 차감하면 안 되는가"를 이해하려면 우리가 겪어온 사례들을 전부 전달해야 한다. 그 컨텍스트 전달 비용이 개발 비용을 훨씬 초과한다. 둘째, 자동화 파이프라인의 에러 처리 방식은 운영 패턴과 깊이 결합되어 있다. 어떤 에러를 리트라이하고, 어떤 에러를 즉시 알림으로 올리고, 어떤 에러를 조용히 로깅만 할지—이 판단은 문서로 전달할 수 있는 것이 아니라 운영 경험에서 나온다. 셋째, 컴플라이언스와 감사 추적의 문제다. 결제 데이터를 다루는 모든 로직은 나중에 누가, 왜 이렇게 구현했는지 팀 내부에서 설명할 수 있어야 한다. 외주로 만들고 인수인계 없이 유지보수 상태로 들어간 코드는 그 "왜"가 팀 안에 없다. 감사 시점에 이것은 단순한 불편함이 아니라 실질적 리스크가 된다.

우리가 정한 기준과 실제 적용 시나리오

경험 이후 팀 내에서 정리한 기준은 다음과 같다. 완벽한 기준은 아니지만, 매번 처음부터 고민하는 것보다 의사결정 속도가 확연히 빨라졌다.

외주 검토 가능 조건 (세 가지 동시 충족 시):

비즈니스 로직이 해당 코드에 없거나, API 호출로 완전히 분리되어 있다
명세를 문서 하나로 완결 지을 수 있다 (예외 케이스 5개 이하, 상태 전환 단순)
결과물이 틀렸을 때 손상 범위가 UX에 국한된다 (돈·데이터 무결성에 영향 없음)

반드시 내재화하는 조건 (하나라도 해당 시):

정산 금액, 수수료, 환불 계산이 포함된 경우
자동화 파이프라인의 트리거·에러 처리 흐름
결제 수단별 분기 로직
외부 감사나 규제 대응에 직접 닿는 코드

실제 적용 사례를 하나 더 들면, 올해 초 운영 대시보드에 "파트너별 월별 정산 요약" 뷰를 추가할 때였다. 차트 컴포넌트, 날짜 필터, 테이블 렌더링은 외주 가능 조건을 충족했다. 단, 우리가 먼저 정산 집계 API를 완성하고 스펙을 확정한 뒤에 넘겼다. 외주 개발자는 API를 호출하는 UI만 건드렸고, 수정 사이클도 한 번에 끝났다. 명세를 단순하게 유지하기 위해 API 설계를 선행한 것이 결정적이었다. 이 순서만 지켜도 외주의 고질적 약점인 "커뮤니케이션 비용 폭발"을 상당 부분 통제할 수 있다.

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

우리와 비슷한 규모·도메인의 팀이라면 아래 다섯 가지를 그대로 가져다 써도 된다. 일반론이 아니라 우리가 직접 틀리고 고친 것들이다.

1. 외주 검토 전에 API 경계를 먼저 그어라. 외주 가능 여부는 "얼마나 단순한가"보다 "비즈니스 로직을 API 뒤로 완전히 숨길 수 있는가"에 달려 있다. 이 경계를 먼저 그어야 명세도 단순해지고 수정 사이클도 통제된다. 경계를 안 그은 채로 외주를 주면 외주 개발자가 도메인 로직을 추측해서 구현한다.

2. 명세서 작성 시간을 전체 일정의 20~30%로 잡아라. "단순한 작업"이라도 명세화에 생각보다 훨씬 많은 시간이 든다. 우리 케이스에서 명세 5일 + 커뮤니케이션 약 10시간 = 실질적으로 7~8일이 우리 시간으로 나갔다. 이를 모르고 시작하면 "외주가 왜 비효율적이냐"는 잘못된 결론으로 귀결된다. 외주는 비효율적인 게 아니라, 명세 비용을 포함해서 계산하지 않은 것이다.

3. 판단 기준은 "총 시간 절약"이 아니라 "집중 블록 해방"이다. 외주의 가치는 공수 절약이 아니다. 더 중요한 작업의 집중 블록을 지키는 것이다. 우리 팀에서 외주를 쓸 만한 신호는 "이걸 직접 하면 X가 3주 이상 밀린다"는 조건이 충족될 때다. 그 조건이 없으면 직접 하는 게 낫다.

4. 수정 사이클은 최소 2회, 간격은 3~5일로 역산하라. 1회 수정을 예상하면 3회가 돈다. 결제·정산 인접 도메인은 엣지 케이스가 많다. 이를 모르고 일정을 짜면 외주가 끝날 때쯤 원래 작업이 다시 밀리는 아이러니가 생긴다.

5. 첫 외주는 기준을 만드는 데 쓴다고 생각하라. 우리의 첫 시도는 완전한 성공이 아니었다. 하지만 그 경험이 없었다면 이후의 외주 두 번이 훨씬 거칠었을 것이다. 외주 경험 자체가 학습 자산이다. 첫 번째에서 기준을 뽑아내면 두 번째부터는 완전히 다른 게임이 된다.

— by slecs