정산 로직 안에 AI 라우터를 심는 시대가 왔다

핵심부터: Stripe는 AI 특이점 때문에 OpenRouter를 산 게 아니다

공식 발표에서 Stripe CEO는 "특이점(singularity)"을 언급했다. TechCrunch는 바로 비틀었고, 나도 같은 생각이다.

진짜 이유는 결제 의사결정 레이어의 수직 통합이다. OpenRouter는 300개 이상의 AI 모델 사이를 중개하는 미들웨어인데, Stripe 입장에서 이게 탐날 수밖에 없는 이유는 자기네 비즈니스 구조를 보면 즉각 나온다. 결제 승인 하나에도 수십 가지 판단이 붙는다. 이 거래는 사기인가, 이 사용자는 고위험인가, 이 금액은 어떤 처리 경로로 보낼 것인가. 지금까지는 규칙 기반(rule-based) 엔진이 이 결정을 해왔다.

AI가 들어오면 판이 달라진다. 근데 AI 모델은 하나가 아니다. 그리고 Stripe는 어떤 AI를 고를 것인가를 남한테 맡기고 싶지 않았던 것.

단, 여기까지 읽고 "우리 팀 규모에서 무슨 상관"이라고 넘기면 놓치는 게 있다. 이 거래가 소규모 결제·정산 팀에 실질적으로 영향을 미치는 경로는 생각보다 구체적이고 빠르다.

결제 결정은 이미 프롬프트다

결제 파이프라인 안에서 판단이 필요한 지점을 세어본 적 있나.

정산 흐름 하나만 봐도 그렇다. PG에서 정산 데이터가 내려오면 내부 장부와 매칭하고, 불일치 건을 걸러내고, 환불·취소 반영 여부를 판단하고, 잔차 처리를 결정한다. 우리도 초반에 이 매칭 로직을 규칙으로 짜다가, 예외 케이스가 쌓이면서 코드가 스파게티가 됐던 경험이 있다. 결국 "이 불일치 건, 왜 생긴 건지 설명해줘"를 Claude에 던지는 게 훨씬 빠르다는 걸 깨달았는데 — 그게 본질적으로 프롬프트다.

문제는 그 프롬프트를 모두 같은 모델로 보낼 필요가 없다는 것.

"이 금액이 맞나요" 수준의 단순 체크는 Claude Haiku($0.25/백만 토큰)로 충분하다. "이 패턴의 분쟁 건들이 왜 클러스터링되는지 분석해줘"는 Sonnet급이어야 한다. 비용 차이는 현재 기준으로 10배 이상이다. OpenRouter가 하는 게 정확히 이 분기 — 어떤 질문을 어떤 모델로 보낼지 관리하는 레이어다.

Stripe가 이 레이어를 소유하려는 구조적 이유

단순히 "AI를 잘 쓰려고" 라우터를 산 게 아니다.

Stripe 위에서 돌아가는 수백만 개의 비즈니스들이 결제 인텔리전스를 쓰게 되면, 그 AI 레이어를 누가 쥐고 있느냐가 플랫폼 지배력을 결정한다. OpenRouter를 소유하면 Stripe는 "Stripe AI"라는 형태로 AI 결제 인텔리전스를 상점들에게 팔 수 있다. AI 모델 경쟁은 Stripe 아래에서 일어나고, Stripe는 라우팅 레이어만 관리하면 된다.

여기에 구글이 자체 AI 칩 개발에 본격 돌입했다는 소식을 얹으면 그림이 더 선명해진다. 인퍼런스 비용이 지금보다 크게 떨어지는 시점이 오면, 결제 파이프라인 안에서 AI 호출을 아끼는 논리 자체가 사라진다. Stripe는 그 변곡점에 이미 레이어를 장악한 상태가 되는 셈이다.

Adyen, Square가 비슷한 움직임을 보이기 시작할 것이다. 결제사들이 AI 라우팅 레이어를 내재화하는 건 방향이 확정된 흐름이다.

우리 팀이라면 지금 이렇게 한다

시나리오를 하나 그려보자. 정산 불일치 건 처리가 예시로 좋다.

매일 오전 정산 데이터가 들어온다. 자동 매칭 후 잔존 불일치 건이 예를 들어 20~30건 발생한다. 지금은 이걸 사람이 하나씩 본다.

여기에 AI 라우팅 레이어를 넣으면 달라지는 게 있다. 1단계로 Haiku를 쓴다. "금액 차이가 100원 이하인가, 타임스탬프 오프셋 패턴인가" 같은 단순 분류다. 이 수준에서 걸러지면 자동 처리 대기열로 넣는다. 2단계로 Sonnet을 쓴다. "이 건의 취소-재결제 패턴이 정상인지, 어떤 이상 징후가 있는지"를 판단한다. 그래도 남은 것만 사람 리뷰 대기열로 넘긴다.

불일치 건 30개 중 사람이 봐야 할 건 5~8개로 줄어든다. Haiku 30건 호출 비용은 토큰 규모로 보면 0.01달러 수준이다. 사람 30분 절약과 비교할 게 없다.

다만 주의할 점이 있다. AI 판단을 자동 처리 트리거로 직접 연결할 때, 오판 케이스에 대한 롤백 경로가 없으면 금전 피해로 이어진다. 처음 2주는 실제 처리를 연결하지 않고 시뮬레이션만 돌려서 오판율을 재는 게 안전하다. 직접 해보면 생각보다 오판이 나오는 케이스가 있는데, 대부분 인풋 데이터 포맷 문제지 모델 문제가 아니다.

지금 바로 써먹을 수 있는 시사점

정산 흐름 안에서 "판단이 필요한 지점" 목록을 먼저 뽑아라. 자동화 가능성 기준이 아니라, AI가 1차 의견을 낼 수 있는 지점 기준으로. 불일치 분류, 환불 승인 사전 심사, 이상 거래 플래그 중에 반복성이 높은 것부터 골라라.

모델 선택을 작업 복잡도로 분기해라. "맞다/틀리다" 수준은 Haiku, "왜 그런지"가 필요한 건 Sonnet. 지금 우리 claude_cli에서 model 파라미터 하나 바꾸는 수준의 일이다. 이걸 함수 레벨에서 routing_tier = "simple" | "complex"로 관리하면, 나중에 모델이 바뀌어도 코드 수정이 한 줄이다.

AI 결정 로그를 정산 DB 안에 같이 박아라. reconciliation_decisions 테이블 하나 만들어서 AI가 뭘 보고 어떤 결론을 냈는지 남긴다. 이게 쌓이면 오판 패턴이 보이고, 거기서 규칙을 뽑을 수 있다. Stripe가 OpenRouter로 쌓으려는 것도 결국 이 레이어별 결정 데이터다.

Stripe의 인수는 결제 업계가 AI 라우팅을 인프라로 인식하기 시작했다는 신호다. 우리 규모에서 그 인프라를 직접 만들 필요는 없다. 하지만 어떤 결제·정산 결정에, 어떤 수준의 AI를 붙일 것인가를 지금 설계해두지 않으면, 결제사가 그 레이어를 완전히 장악하는 시점에 우리 선택지가 좁아진다. 그때 가서 설계하면 결국 Stripe가 파는 것을 그냥 사게 된다.

원문: AI News & Artificial Intelligence | TechCrunch