AI 라우팅이 인프라가 될 때 작은 팀에게 남는 역량

7조짜리 프록시가 증명하는 것

Stripe가 OpenRouter를 70억 달러 이상에 인수할 것이라는 보도가 나왔다. 핵심 함의는 단순하다. AI 모델 호출이 금융 인프라 수준의 추상화 레이어 뒤로 들어가는 순간, "어떤 모델 API를 쓸 줄 안다"는 역량의 시장 가치가 빠르게 낮아진다.

단, 그 자리를 채우는 역량이 무엇인지가 생각만큼 명확하지 않다. 작은 팀일수록 이 전환에서 놓치기 쉬운 함정이 하나 있는데, 그게 이 글을 쓰는 이유다.

OpenRouter는 Claude, GPT-4o, Gemini, Llama 등 수십 개 LLM을 단일 API 뒤로 감싸는 게이트웨이다. OpenRouter CEO가 자기 회사를 직접 "AI판 Stripe"라고 불렀는데, 이제 그 표현이 문자 그대로 현실이 됐다. 창업 2년 남짓의 스타트업에 7조 원. 제품이 아니라 위치를 샀다고 보는 게 맞다. AI 호출 트래픽이 지나가는 관문, 그 자리를.

LLM 호출이 금융 트랜잭션이 되는 구조

Stripe가 결제 시장에서 한 일을 떠올려보자. Visa, Mastercard, 은행 이체, PayPal — 이 모든 수단을 하나의 API 뒤로 숨겼다. 어떤 카드사가 뒤에서 처리하는지 개발자가 알 필요가 없어졌고, 결제 연동은 경쟁력이 아닌 기본 스펙이 됐다.

OpenRouter가 LLM 시장에서 정확히 같은 일을 한다. Claude 3.5, GPT-4o, Gemini Flash, Mistral — 어떤 모델이든 엔드포인트 하나, API 키 하나다. Stripe가 이를 품으면 AI 호출은 금융 트랜잭션처럼 추적되고 청구되고 감사된다.

역설이 여기서 생긴다. 문턱이 낮아지면, 거기서 먹고사는 역량의 가치가 줄어든다. "GPT API를 연결할 줄 안다", "Claude 프롬프트를 짤 줄 안다" — 이 수준이 채용 차별점이던 시대가 빠르게 닫히고 있다. 큰 팀은 이미 전담 ML 엔지니어가 있으니 상대적으로 둔감하다. 작은 팀이 더 빨리 읽어야 하는 이유가 거기 있다.

추상화 이후에 남는 것

Stripe 이전에는 Visa 가맹점 계약을 맺는 능력이 기업 역량이었다. Stripe 이후에는 그 계약 자체가 너무 쉬워져 역량이 아니게 됐다. 경쟁은 "어떤 상품을, 어떤 가격에, 어떤 고객에게"로 옮겨갔다.

AI 게이트웨이가 표준화되면 같은 이동이 일어난다. 모델 선택이 config 한 줄로 바뀌는 세계에서 개발자에게 남는 역량은 판단력이다.

어떤 태스크에 어떤 모델이 맞는가를 아는 것. 출력 품질을 정량적으로 평가하는 것. 모델이 틀렸을 때 빠르게 감지하는 것. 이 세 가지는 OpenRouter가 인프라가 돼도 자동화되지 않는다.

처음엔 비싼 모델이 무조건 낫다고 생각했는데, 실제로 수백 건 출력을 비교해보니 단순 포맷 생성에서는 가벼운 모델이 오히려 더 일관된 결과를 뱉는 경우가 있었다. API 연결은 30분이면 끝나지만 이 판단 기준은 데이터에서만 나온다. 외부 벤치마크로 대체할 수 없다. 우리 태스크, 우리 품질 기준, 우리 운영 환경에서 어떤 모델이 무엇을 잘하는지 — 이걸 아는 팀이 인프라 추상화 이후에도 실질적인 우위를 유지한다.

수치로 보는 모델 라우팅 트레이드오프

왜 이 판단력이 실질적인 가치를 갖는지, 비용 숫자로 보면 명확해진다.

현재 Claude Haiku 계열과 Gemini Flash 계열 사이에는 호출당 약 8~12배의 가격 차이가 있다. 판단·검수 단계에서 쓰는 Sonnet급 모델과 비교하면 20배 이상 벌어진다. 소규모 팀이 하루 12개 봇을 돌리고 각 봇이 1,500자 이상 본문을 생성한다고 하면, 생성 단계와 검수 단계의 모델 조합에 따라 월 LLM 비용이 몇 배 차이난다.

트레이드오프가 분명하다. 단순 포맷 반복 생성 — 보험 상품 설명, 로또 회차 요약, 정형화된 소개글 — 은 저렴한 모델로 라우팅해도 품질 차이가 크지 않다. 반면 검수·판단 단계에서 모델을 낮추면 오탐이 늘어 수동 확인 비용이 오히려 더 든다. HEDVION에서 review_loop에 Sonnet 이상을 쓰는 이유가 정확히 여기 있다. 그 경계선을 태스크마다 파악하고 있는 팀과 그렇지 않은 팀 사이에는, OpenRouter가 표준이 된 세계에서 실질적인 운영 비용 차이가 생긴다.

모델 라우팅을 config 한 줄로 바꿀 수 있어도, 어떤 config를 쓸지는 여전히 팀이 결정해야 한다.

작은 팀의 역량 구성을 다시 봐야 할 이유

AI 개발자 부트캠프 커리큘럼 대부분이 "API 연결 → 프롬프트 작성 → 결과 출력"에 머문다. 솔직히 지금도 이력서에서 "AI 부트캠프 수료" 항목만 보고 채용 판단을 하기가 점점 어려워지고 있는데, OpenRouter가 표준 인프라가 되는 순간 이 수준은 최저 기본값이 된다.

소규모 팀에게 실제로 필요한 역량은 세 축이다.

모델 독립 아키텍처 설계가 첫 번째다. 특정 모델 API에 코드가 의존하는 구조는 전환 비용을 만든다. claude_complete(model="haiku") 같은 패턴처럼 모델명을 호출 레이어에서 분리하고, 태스크 유형별로 라우팅 로직을 코드 레벨에 두어야 한다. 이게 없으면 모델 교체 실험을 하려 해도 코드 전체를 다시 써야 한다. 변경이 어려운 구조는 실험 자체를 막는다.

두 번째는 출력 평가 역량이다. 모델을 바꿀 수 있어도 결과가 괜찮은지 판단하지 못하면 최적화할 방법이 없다. 글자수 게이트, 내용 일관성 검사, 금칙어 탐지 같은 자동 평가 파이프라인이 이미 있다면, 거기에 "모델 A vs 모델 B 통과율 비교"를 추가할 수 있어야 한다. 이 사이클을 돌릴 수 있는 사람이 AI 개발자 부트캠프 수료생과 시니어 사이를 가르는 기준이 될 것이다.

세 번째는 LLM 비용 추적 습관이다. 호출 단위로 사용량을 로깅하지 않으면 라우팅 최적화 효과를 측정할 방법 자체가 없다. Stripe + OpenRouter 통합이 이 데이터를 결제 로그에 자동으로 넣어줄 날이 오겠지만, 그 전에 팀 안에서 먼저 이 데이터를 쌓아두는 게 낫다.

채용 기준도 따라가야 한다. "어떤 모델을 써봤나요?"보다 "두 모델을 같은 태스크에 돌려보고 어떤 차이를 발견했나요?"가 훨씬 유의미한 질문이다. 두 번째 질문에 구체적인 답이 나오는 사람이 이 판단력을 실제로 가진 사람이다.

지금 당장 실행할 수 있는 것

인수가 확정되고 통합이 마무리되는 데 최소 1~2년이 걸린다. 서비스 구조를 지금 당장 바꿀 이유는 없다. 하지만 팀 역량을 정비하는 건 지금 시작하는 게 맞다.

가장 먼저 할 수 있는 것: 각 LLM 호출마다 모델명과 입출력 토큰 수를 로그에 남겨라. Discord 카드나 내부 대시보드에 월별 집계가 보이면, 어느 봇이 비용을 많이 쓰는지 한눈에 보인다. 돈을 당장 아끼는 게 목적이 아니라, 모델 전환 실험을 할 수 있는 기반을 먼저 만드는 것이다. 데이터 없이는 실험할 수도, 검증할 수도 없다.

다음으로: 기존 봇 하나를 골라 다른 모델로 대체 실험을 해봐라. 지금 Haiku로 생성하는 콘텐츠를 Gemini Flash로 돌리고, 1,500자 게이트 통과율과 검수 통과율을 비교한다. 이 실험 사이클 자체가 팀에 모델 평가 역량을 쌓는 훈련이 된다.

채용 인터뷰에서는 모델 비교 경험을 묻는 질문을 하나 추가해라. AI 개발자 부트캠프 출신이라도, 이 경험이 있는 사람과 없는 사람의 실력 차이는 3개월 후에 분명히 갈린다. OpenRouter가 인프라가 된 세계에서 그 인프라를 제대로 활용하는 팀은, 라우팅 판단 기준을 이미 코드와 데이터로 쌓아온 팀이다.

원문: AI News & Artificial Intelligence | TechCrunch