결제 전문가가 정산 레이어를 포기했다 — 우리 파이프라인 점검 포인트

결제를 가장 잘 아는 사람들이 결제 인접 툴을 버렸다

Ramp는 기업 카드와 청구서 결제를 처리하는 핀테크다. 그 안에서 결제 데이터를 매일 만지던 엔지니어들이 나와 처음 만든 게 "광고 지출 추적·최적화 툴"이었다. 결국 그걸 전면 폐기하고 AI 크리에이티브 플랫폼으로 피벗해 $20M을 조달했다.

그냥 "스타트업 피벗 스토리"로 읽히기 쉽다. 근데 결제·정산을 직접 운영하는 팀 입장에서 보면 다른 신호가 보인다. 광고비 지출 최적화는 본질적으로 정산 문제다. 수백 개 채널로 나가는 마케팅 예산을 추적하고, 채널별로 집계하고, 성과와 비용을 매칭하는 작업 — 결제 테이블에 쌓인 데이터를 리포팅 레이어로 끌어올리는 것과 구조가 같다. 그걸 버렸다. 이게 의미심장한 지점이다.

광고비 최적화가 결국 정산 문제인 이유

마케팅 팀이 매달 Google Ads, Meta, 네이버, 카카오에 각각 수백만 원씩 집행하면, CFO 입장에서 그건 수십 건의 출금 트랜잭션이다. 어느 채널에서 얼마가 나갔는지 집계하고, 채널별 정산 기준일에 맞춰 결산하고, 실제 집행 금액과 청구 금액의 차이를 맞추는 게 광고비 관리의 절반이다. Melius가 처음 만든 제품이 이 레이어를 정확히 타겟으로 했다.

그들이 그걸 버린 공식 이유는 "CFO 문제가 아니라 마케터 문제를 풀고 싶었다"는 것이다. 나는 이걸 조금 다르게 읽는다. 광고비 집계·정산 레이어 자체가 이미 플랫폼이 해결해주는 영역이 됐다는 것. Google, Meta 모두 광고 계정 내 지출 리포팅을 꽤 잘 해준다. 거기에 독립 툴로 끼어들어봤자 차별화가 없었을 것이다. 우리가 운영하는 결제·정산 파이프라인에서도 PG사들이 정확히 같은 방향으로 움직이고 있다.

인프라가 발전할수록 자체 코드가 짐이 된다

처음엔 단순했던 정산 로직이 어느새 복잡해지는 경험은 결제를 직접 운영해본 팀이라면 다 안다. 주문 상태 하나가 추가되면 예외 처리 로직이 붙고, PG사를 하나 더 연동하면 정산 기준일 계산이 달라지고. 그게 쌓이면 로직이 2000줄이 되고 테이블이 10개가 넘는다. 직접 해보니 실제 문제는 코드 양이 아니었다 — 어떤 코드가 "우리 비즈니스 규칙"이고 어떤 코드가 "인프라가 원래 해줘야 하는 것"인지가 뒤섞여버린 게 문제였다.

트레이드오프를 수치로 보면 명확해진다. Stripe Revenue Recognition은 2023년 이후 상당히 정교해졌다. 자체 수익 인식 로직을 직접 구현했던 팀들이 이걸 도입하려 하면 기존 코드와 충돌이 생긴다. 자체 정산 레이어가 두꺼울수록, 플랫폼 기능을 도입하는 비용이 비선형으로 커진다. Melius 팀이 첫 제품을 폐기하면서 피한 게 정확히 이 구조였다. 자기가 만든 것과 플랫폼 발전 방향이 겹치기 시작하는 순간, 버리는 타이밍이 지연될수록 전환 비용이 눈덩이처럼 불어난다.

AI 개발 속도 조절론 — 결제 코드에서는 역방향이어야 한다

Melius가 첫 제품을 빠르게 만들고 빠르게 버렸다는 스토리는, AI 코드 생성이 일상화된 지금 시대의 전형적인 패턴과 맞물린다. 빠르게 프로토타이핑하고, 안 되면 버리고, 되면 조달받는 사이클. SaaS나 크리에이티브 툴에서는 합리적이다. 광고 크리에이티브가 잘못 나와봤자 CTR이 낮아지는 정도다.

결제 코드는 다르다. 환불 로직에 버그가 있으면 돈이 중복으로 나간다. 정산 집계가 틀리면 발견이 수 주 뒤에야 된다. "빠르게 만들고 나중에 고친다"는 접근이 결제 파이프라인에 그대로 들어오면, "나중에 고친다"가 아니라 "나중에 수습한다"가 된다. AI가 코드를 빠르게 뽑아주는 시대일수록, 결제 관련 코드는 오히려 리뷰 게이트를 더 명확하게 유지해야 한다. 속도를 줄이는 게 아니라 코드 생성과 검증 단계를 분리해야 한다는 얘기다.

우리 파이프라인에 대입하면

Melius 사례를 우리 상황에 직접 대입해보자.

시나리오: PG사 정산 파일을 받아 주문 테이블과 매칭하고, 불일치 건을 플래그하는 배치가 있다. 이 배치의 어떤 부분이 "Melius가 버린 레이어"에 해당하는가.

정산 파일 파싱, PG사별 포맷 변환, 기본 합산 집계 — 이건 Toss Payments, NHN한국사이버결제 모두 정산 API와 대시보드로 점점 더 잘 해주는 영역이다. 우리가 여기에 자체 코드를 두껍게 쌓았다면, 그 코드는 시간이 지날수록 짐이 된다. PG사 API가 개선돼도 우리 코드가 그 위에 얹혀 있으면 쉽게 못 갈아탄다.

반면 "이 불일치 건이 환불인가, 주문 상태 오류인가, 아니면 멱등성 중복인가"를 판단하는 로직은 완전히 다른 차원이다. 우리 운영 정책이 들어간다. PG사도, 어떤 플랫폼도 우리 비즈니스 컨텍스트 없이는 이 판단을 해줄 수 없다. 코드 복잡도가 집중돼야 하는 곳이 여기다. 다른 곳에 두껍게 쌓인 코드는 Melius의 첫 번째 제품과 같은 운명을 마주하게 된다 — 인프라가 그 문제를 삼켜버리는 날이 온다.

바로 써먹을 수 있는 판단 기준

결제·정산 파이프라인에서 무엇을 직접 유지하고 무엇을 외부로 넘길지 구분할 때 실용적으로 쓸 수 있는 기준이다.

비즈니스 규칙이 들어간 부분은 직접 유지해야 한다. 어떤 케이스에서 자동 환불을 허용하고 어떤 케이스는 수동 검토로 올릴지, 정산 예외를 어떻게 처리할지 — 이건 외부 어디도 대신해주지 않는다. 반면 PG사가 표준 API로 이미 제공하는 것들, 웹훅 수신·정산 파일 파싱·기본 합산 집계에 자체 코드가 두껍다면 Melius가 경험한 상황과 구조적으로 같다. 인프라가 발전할수록 그 코드는 부채다.

버릴 신호는 두 가지다. 해당 코드가 마지막으로 실제 의사결정에 사용된 게 분기 이상 됐는데 유지보수 시간은 여전히 들어간다면 첫 번째 신호. "이게 없으면 어떻게 되나?"라는 질문에 팀원 중 아무도 즉답을 못 한다면 두 번째 신호. Melius는 그 답이 명확해지자마자 버렸다. $20M 조달을 앞두고도.

결제 전문가들이 결제 인접 툴을 버렸다는 아이러니 — 그들이 $20M으로 산 교훈을, 우리는 이 기사 한 줄로 얻었다.

원문: AI News & Artificial Intelligence | TechCrunch