self-hosted 와 SaaS 의 비용/시간 트레이드오프 표

결제·정산 팀에게 이 선택이 유독 복잡한 이유

결제·정산 시스템을 직접 운영하는 팀에게 self-hosted vs SaaS 선택은 단순한 비용 계산 문제가 아니다. 금융 데이터를 다루는 순간, 이 선택에는 컴플라이언스, 감사 추적 가능성, 장애 시 실제 금전적 손실이라는 변수가 추가된다. "편리함 대 통제권"의 문제가 아니라 "우리가 감당할 수 있는 위험의 종류"를 고르는 문제가 된다.

HEDVION이 운영하는 자동화 파이프라인 대부분은 외부 결제 게이트웨이 → 내부 정산 엔진 → ERP 연동의 흐름을 탄다. 이 흐름 어딘가에 SaaS 도구가 끼면, 그 도구의 장애는 곧 정산 지연으로 이어진다. 정산 지연 1시간이 파트너사 페널티 조항에 걸리는 계약 구조라면, 월 $50짜리 SaaS 플랜 하나가 수십만 원의 손실로 둔갑할 수 있다. 이 현실을 모르고 표면적인 가격표만 비교하면 반드시 잘못된 선택을 하게 된다.

비용의 진짜 구조: 보이는 숫자와 숨겨진 시간

SaaS의 가격표는 명확하다. Zapier Business 플랜 $99/월, Retool Cloud $10/유저/월, Datadog Pro $15/호스트/월. 숫자가 보이니 비교하기 쉽다고 착각하지만, self-hosted의 비용은 서버비만이 아니다. 설치·설정·마이그레이션·유지보수·돌발 장애 대응까지 전부 엔지니어 시간으로 환산해야 한다.

우리 팀이 Zapier에서 self-hosted n8n으로 전환하면서 실측한 시간 비용이다. Docker Compose 구성 및 초기 설치 3시간, SSL 인증서·리버스 프록시 설정 2시간, 기존 워크플로우 13개 마이그레이션에 팀원 2명이 이틀, 첫 달 버전 업데이트 충돌 대응 4시간. 합산하면 약 55시간. 시니어 엔지니어 시간당 비용을 5만 원으로 잡으면 초기 전환 비용만 275만 원이다. Zapier Business를 1년 구독하면 VAT 포함 약 145만 원 수준이다. 순수 비용만 보면 첫 해는 self-hosted가 더 비쌌다. 그런데 전환을 결정한 이유는 따로 있었는데, 그게 다음 섹션이다.

데이터 주권: 결제 데이터는 어디를 통과해야 하는가

Zapier나 Make(구 Integromat)를 쓰면 결제 이벤트 웹훅 데이터가 해당 SaaS 서버를 경유한다. 주문 ID, 결제 금액, 가맹점 코드 정도라면 검토 여지가 있다. 하지만 정산 자동화를 깊게 가다 보면 반드시 그 파이프라인 안으로 구매자 이름, 부분 마스킹된 카드 정보, 세금계산서 발행 데이터가 들어오는 순간이 온다. 이 시점부터 외부 SaaS 경유는 개인정보보호법·전자금융거래법 맥락에서 반드시 검토가 필요한 아키텍처 선택이 된다. "일단 쓰다가 감사 때 보자"는 태도는 결제 도메인에서 용납되지 않는다.

HEDVION은 이 기준을 '민감 데이터 접촉 여부'로 단순화했다. 파이프라인에 PII(개인식별정보) 또는 금융 식별자가 한 건이라도 흐를 가능성이 있으면, 그 구간은 self-hosted 또는 온프레미스 처리가 원칙이다. 반면 집계된 통계, 즉 오늘 결제 건수나 정산 총액 같은 집계값을 외부 대시보드로 쏘는 것은 다른 문제다. 원천 데이터가 아닌 집계값이라면 SaaS 시각화 도구를 써도 우리 기준상 문제없다. 이 경계를 명시적으로 그어두자, 매번 반복하던 논쟁이 사라졌다.

우리 팀의 실제 선택 시나리오: 정산 현황 대시보드

작년 말, 정산 현황을 실시간으로 볼 수 있는 내부 대시보드가 필요했다. 선택지는 세 가지였다. Tableau Online(SaaS, 약 60만 원/월), Retool Cloud($10/유저/월 × 4명 = $40/월), self-hosted Metabase(기존 서버에 Docker로 추가, 실질 추가 비용 거의 없음).

Tableau는 금액부터 탈락. Retool은 진지하게 검토했는데, 결제 DB에 직접 쿼리를 날리는 구조라 DB 크리덴셜을 Retool 서버에 등록해야 한다는 점이 걸렸다. 읽기 전용 계정으로 위험을 줄일 수 있지만, 결제 DB 접근 경로 자체가 외부 SaaS를 통한다는 사실은 보안 감사 항목이 된다. 결국 Metabase를 self-hosted로 구성했다. 이미 운영 중인 EC2 t3.medium 인스턴스에 Docker로 15분 만에 띄웠고, 추가 서버 비용 없이 원하는 대시보드를 완성했다. 여기서 트레이드오프는 명확하다. Metabase 버전 업데이트는 우리가 직접 챙겨야 한다. 실제로 보안 패치가 포함된 마이너 업데이트가 두 번 있었고, 각각 30분~1시간의 대응이 필요했다. 연간으로는 작은 숫자지만, "이런 일이 발생한다"는 사실을 팀이 사전에 받아들이지 않으면 self-hosted는 담당자 없는 좀비 서버가 된다.

판단 공식: 두 개의 임계점만 계산하면 된다

복잡하게 설명했지만, HEDVION이 실제로 쓰는 판단 로직은 두 개의 임계점으로 수렴한다.

손익분기 시간(BEP): (SaaS 연간 비용) ÷ (엔지니어 시간 단가) = self-hosted 전환 후 회수 가능한 시간. 초기 전환 시간 + 연간 유지 시간 합산이 이 값 이하면 self-hosted가 경제적이다. n8n 전환 사례에서 우리 계산 기준 손익분기는 약 14개월이었다. 2년 이상 쓸 도구라는 확신이 있었기 때문에 전환이 맞았다. 1년 이하로 쓸 도구라면 self-hosted 전환 비용이 회수되지 않을 가능성이 높다.

장애 허용 시간(RTO): 이 도구가 죽었을 때, 팀이 복구에 집중할 수 있는 시간이 얼마인가. 핵심 결제 파이프라인 연동이라면 RTO는 15분 이내여야 한다. 그 수준의 SLA를 self-hosted로 보장하려면 이중화·모니터링·온콜 체계까지 필요하고, 그 비용을 합산하면 대부분의 경우 전문 SaaS가 낫다. 반면 내부 대시보드나 개발 도구처럼 RTO가 몇 시간이어도 업무가 멈추지 않는 도구는 self-hosted로 충분히 감당할 수 있다.

바로 써먹을 의사결정 체크리스트

이론보다 실용이다. HEDVION이 새 도구를 도입할 때 실제로 쓰는 질문 순서를 그대로 공유한다. Notion 도구 도입 템플릿에 고정해뒀고, 제안이 들어오면 이 다섯 줄부터 채우게 한다.

1. 민감 데이터 접촉 여부 → 이 도구를 PII나 금융 식별자가 통과하는가? YES이면 self-hosted 우선 검토. NO이면 2번으로.

2. RTO 설정 → 이 도구 장애 시 허용 가능한 다운타임은? 1시간 이내라면 SaaS + 제공사 SLA를 확인할 것. 그 이상이면 self-hosted 범위.

3. 손익분기 계산 → (SaaS 연간 비용) ÷ (엔지니어 시간 단가)를 계산한다. 초기 전환 시간 + 연간 유지 시간 합산이 이 값 이하면 self-hosted.

4. 담당자 지정 가능 여부 → self-hosted를 선택했을 때, 업데이트·장애 대응을 명시적으로 맡을 사람이 지금 당장 있는가? 이름을 적지 못하면 SaaS가 현실적이다. 이름 없는 self-hosted는 결국 아무도 안 보는 서버가 된다.

5. 2년 사용 확신 → 2년 이상 쓸 도구인가? 아니라면 self-hosted 전환 비용이 회수되지 않을 가능성이 높다. 단기 프로젝트엔 SaaS가 맞다.

이 다섯 질문에 순서대로 답하면 대부분의 선택이 30분 안에 끝난다. "self-hosted가 더 쌀 것 같다"는 막연한 직관보다 훨씬 빠르고 정확한 결론이 나온다. 결제·정산 도메인에서는 틀린 선택보다 느린 선택이 낫지만, 이 체크리스트를 쓰면 빠르면서도 틀리지 않을 수 있다.