ShipHero를 80시간으로 갈아엎고 연 $20K 절감 — TRMNL이 보여준 운영 SaaS 회수의 시대

핵심 요약 (TL;DR)

TRMNL 창업자 Ryan Kulp가 ShipHero(외주 OMS)를 Claude CLI + Superpowers 프레임워크로 80~100시간 만에 자체 OMS로 갈아엎었습니다. 30K+ 패키지/년 기준 연 $20K 절감, 본인 추정 유지보수 들어가면 2~3배 더 떨어진다고 합니다. 다창고·라벨·관세·페이롤·펌웨어 프로비저닝까지 1주 현장 디버깅으로 라이브에 올렸습니다.

"운영 SaaS 갈아엎고 싶은데, 통합이 무서워서"

D2C 셀러라면 익숙한 풍경이 있죠. 매달 자동 갱신되는 운영 SaaS 청구서. ShipHero, 카페24 OMS, 아임웹, 고도 같은 일체형 솔루션 — 비용은 패키지당 단가로 계속 올라가는데, 갈아엎자니 UPS·FedEx 같은 배송사 API, 다창고 디스패치, 4x6 라벨 인쇄, HS 코드 관세 인보이스를 전부 다시 짤 엄두가 안 납니다.

TRMNL의 Ryan Kulp가 5월 15일에 올린 Vibe Coding a $20k/Year Enterprise Logistics Platform은 정확히 그 두려움을 80~100시간으로 박살낸 사례입니다. ShipHero 계약 갱신 마감(5월 1일)이 다가오자 Ryan과 동료 Liz는 ShipHero를 통째로 자체 OMS로 옮기기로 결정했습니다. 도구는 Claude CLI + Jesse Vincent의 Superpowers 프레임워크 + Claude Design + 네트워크 프린터용 Swift 유틸 + WebSocket.

"spec과 test에 90% 노력을 쏟았다"

Ryan이 Show HN 스레드에서 "코드 리뷰·테스트가 부족하지 않냐"는 비판에 답한 한 줄이 핵심입니다. "우리는 90%의 노력을 specs와 tests에 쓴다." 80~100시간이라는 숫자가 "AI가 다 짜줬다"는 환상이 아닌 이유가 여기 있는 거죠. 바이브코딩이 빠른 건 코드 타이핑 속도가 빨라져서가 아니라, AI가 잘 따를 수 있는 사양을 사람이 단단하게 짜놨기 때문입니다. 거꾸로 말하면, 사양이 없으면 AI는 가장 빠르게 실패합니다.

만든 것도 단순하지 않습니다. 주문 hold/메모, 미국 조지아·독일 베를린 다창고 디스패치, UPS·FedEx·DHL·USPS 직접 통합(원문은 "라이브 API 통합", 정식 계정 통합인지 sandbox인지 본문 명시 없음 — 그래도 일상 운영에서 라벨 인쇄까지 돌고 있는 건 확인), Python·Ruby·Node 사용자 코드가 돌아가는 자동화 룰엔진, HS 코드/관세 인보이스 포함 SKU 관리, 역할 기반 권한, 페이롤 자동화, 그리고 자신들의 e-ink 디바이스를 위한 PCB/펌웨어 프로비저닝 워크플로까지. 80~100시간 + 1주 현장 디버깅으로 라이브에 올렸습니다.

연 $20K 절감의 진짜 의미

30K+ 패키지/년 × 약 $0.76/패키지 ShipHero 단가 기준입니다. 원문 제목에 "$20K"가 박혀 있지만, 본문에서 명시적인 $20K 청구서를 적시하진 않고 패키지 단가에서 도출된 추정값이라는 점은 짚고 가야겠죠. 그래도 메시지는 명확합니다. 본인 표현으로 "유지보수 들어가면 2~3배 더 떨어진다". ShipHero의 페이지 로드, 라벨 인쇄 속도, 필터링, UI 디자인까지 자체 시스템이 낫다고 평가하면서요.

핵심은 비용이 아닙니다. "매년 자동 갱신되는 SaaS"가 더 이상 영구 부동산이 아니라는 신호인 거죠. 통합 비용 = 갈아엎기 비용. 그 통합 비용이 LLM으로 떨어진 만큼, 운영 SaaS의 락인은 무너지기 시작했습니다.

한국 D2C 셀러를 위한 5단계 체크리스트

1. 자동 갱신되는 SaaS 청구서를 다 적어보세요 — 카페24, 아임웹, 고도, 풀필먼트 위탁비용까지.
2. 그중 "통합 복잡도" 때문에 못 옮긴 것 1개를 고르세요 — 보통 배송사 API, 결제 API, 부가세 신고가 핵심입니다.
3. 갈아엎기 전에 사양부터 먼저 쓰세요 — Ryan의 90% 룰. 화면 단위로 입출력·예외·실패 케이스를 명세하면 AI가 따라옵니다.
4. Claude CLI나 Codex로 한 화면씩 짜고 매일 라이브 테스트 데이터로 돌려보세요 — 시뮬레이션 데이터로는 안 보이는 버그가 진짜 데이터에선 24시간 안에 튀어나옵니다.
5. 현장 디버깅 1주를 일정에 미리 박아두세요 — Ryan도 이 1주가 핵심이었다고 합니다.

FAQ

Q. 비개발자도 이걸 할 수 있나요?
A. Ryan은 8년 B2B SaaS 창업 경력자입니다. 비개발자라기보다 "개발 가능한 창업자"였죠. 다만 그조차도 "LLM 없이는 이 통합을 손으로 짤 엄두를 못 냈다"고 직접 적었습니다. 진짜 핵심은 코딩 가능 여부보다 사양을 단단하게 쓰는 능력입니다.

Q. 운영 중인 SaaS를 정말 갈아엎어도 되는 시점인가요?
A. 비용 회수 기간을 계산해보세요. 80~100시간의 시간 비용(한국 시급 환산) + 1주 디버깅 위험 vs 연간 SaaS 청구서. 자체화 후 유지비가 SaaS 청구서의 30% 이하로 떨어진다면 갈아엎기가 합리적입니다.

Q. 통합 부분에서 SaaS 노컴피트/리버스 엔지니어링 조항 위반 위험은요?
A. Show HN 댓글에서도 똑같은 우려가 나왔습니다. 운영 SaaS의 ToS를 다시 읽어보고, 마이그레이션은 "기능 모방"이 아니라 "내 데이터를 가지고 나간다"의 관점에서 설계하는 게 안전합니다.

운영 SaaS는 갈아엎을 수 있는 비용대로 내려왔습니다. 이제 질문은 "할 수 있는가"가 아니라 "어느 SaaS부터 갈아엎을 것인가"입니다.