모델은 바뀐다, 파이프라인은 버텨야 한다

핵심부터: 기업은 모델을 바꾼다, 그것도 자주

TechCrunch가 이번 주 보도한 데이터가 흥미롭다. OpenAI가 기업 고객 점유율에서 Anthropic을 다시 추격하고 있다는 내용인데, 숫자보다 더 눈에 띄는 대목이 따로 있다. "기업들은 새 모델이 나올 때마다 이쪽저쪽으로 이동한다"는 관찰이다. 이른바 스티키니스, 고객 고착성이 없다.

소규모 개발팀 관점에서 이 사실은 꽤 직접적인 질문을 던진다. 지금 우리 자동화 파이프라인이 특정 모델에 얼마나 묶여 있는가. 그리고 묶인 정도를 알고는 있는가.

단, 여기서 바로 "추상화 레이어를 만들어라"로 넘어가면 조급한 결론이다. 추상화에도 비용이 붙는다. 이 비용을 모르면 레이어가 해결책이 아니라 또 다른 유지보수 부담이 된다. 이 함정을 먼저 짚고 가야 한다.

수치로 직접 계산해보면

Sacra가 집계한 데이터 기준으로 Anthropic의 ARR은 약 44억 달러 수준이고, OpenAI는 그보다 크다. 그런데 이 수치가 분기마다 뒤집힐 수 있다는 게 보도의 핵심 메시지다. 기업들이 모델 성능이 좋은 쪽으로 빠르게 이동한다는 뜻이다.

소규모 팀에게 더 와닿는 숫자는 따로 있다. LLM을 실제로 교체할 때 드는 시간을 추산해보면, 봇 하나를 기준으로 프롬프트 재작성 + 출력 검증 + 엣지 케이스 재테스트를 합쳐 최소 반나절에서 이틀이 든다. 발행 봇이 12개가 넘으면 전체 전환 작업은 수 주가 된다. API 비용 절감이 크지 않은 이상, 전환 공수가 이득을 삼켜버린다.

구체적인 예를 들면 이렇다. 어떤 모델은 JSON 출력 시 키 순서가 불규칙하다. 다른 모델은 "300자 이내"라는 지시를 과하게 문자 그대로 따라서, 억지로 맞춘 어색한 문장을 뱉는다. 프롬프트를 그대로 옮겼는데 동작이 달라지는 건 피할 수 없다. 문제는 그 차이가 얼마나 큰지, 사전에 알고 있느냐다.

추상화 레이어가 커버하는 것과 못 하는 것

"claude_cli 헬퍼만 써라, SDK 직접 호출 금지" — 우리 팀 공통 규칙 중 하나다. 처음엔 그냥 코드 스타일 정책인 줄만 알았는데, 이 레이어 덕분에 모델 버전이 바뀔 때 각 봇 코드를 손댈 필요가 없었다. 실제로 haiku 버전 업그레이드 시 헬퍼 한 곳만 바꾸니 전 봇이 신버전을 쓰게 됐다.

추상화 레이어가 처리해주는 건 API 인터페이스 차이, 재시도 로직, 타임아웃, 에러 처리다. 벤더마다 request/response 구조가 조금씩 다르고, 에러 코드 체계도 다르다. 이걸 각 스크립트가 개별적으로 처리하면 나중에 파일마다 찾아다니며 고쳐야 한다.

그런데 추상화가 건드리지 못하는 영역이 있다. 프롬프트 자체다. Claude 스타일로 수개월 동안 조정된 프롬프트는 GPT 계열 모델에 그대로 쓰면 결과가 달라진다. Claude는 XML 태그 방식의 역할 지시에 잘 반응하는 반면, 다른 모델은 같은 구조를 다르게 해석하기도 한다. 추상화 레이어가 있어도 프롬프트 마이그레이션은 사람이 직접 해야 한다. 이 비용이 전환의 진짜 무게다.

AI가 어디에나 있는 시대, 파이프라인 의존도는 올라간다

요즘 "셀카가 AI 느낌이라는데"라는 말이 SNS에서 돈다. 스마트폰 카메라 후처리 자체가 AI 생성 이미지처럼 보이게 됐다는 얘기다. 개발 워크플로도 마찬가지 흐름 안에 있다. AI 도구가 일상화될수록 의존도는 자연스럽게 깊어진다.

도구가 일상화될수록 전환 비용은 눈에 안 보이게 쌓인다. 우리 팀의 발행 봇 시스템을 보면, 각 봇의 시스템 프롬프트가 수개월에 걸쳐 Claude의 응답 패턴에 맞게 조정됐다. 12개 봇에 각각 수백 자짜리 system prompt가 붙어 있다. 이걸 다른 모델로 이전하는 건 단순 복붙이 아니다. 검증 사이클 자체가 새로 돌아야 한다.

그렇다고 처음부터 모든 프롬프트를 벤더 중립적으로 쓰겠다는 건 실용적이지 않다. 벤더 중립 프롬프트는 대개 특정 모델의 강점을 포기하는 방향이고, 지금 당장 결과가 나빠진다. 현실적인 접근은 현재 최선의 선택을 하면서, 전환 시 드는 비용을 미리 계산해두는 것이다.

우리 팀이라면 이렇게 결정한다

가정해보자. 내년 초에 OpenAI가 Anthropic 대비 40% 저렴한 신모델을 냈다. 성능도 우리 use case에 비슷하거나 낫다. 바로 전환해야 하는가.

이 결정에는 세 가지 계산이 필요하다. 첫째, API 비용 차이가 전환 작업 시간을 얼마나 빨리 회수하는가. 월 API 비용이 만 달러 수준이라면 40% 절감은 연 5만 달러 차이다. 반면 12개 봇의 프롬프트 마이그레이션과 검증에 개발자 두 명이 3주를 쓰면 인건비만으로 전환 비용이 나온다. 회수 기간이 3개월 이내가 아니면 경제성이 없다. 둘째, 전환 후 검증 비용. 자동 리뷰 루프가 있다 해도 처음 몇 주는 이상 출력을 사람이 모니터링해야 한다. 셋째, 롤백 비용. 추상화 레이어가 제대로 설계되어 있으면 롤백은 환경변수 하나를 되돌리는 수준이다. 그렇지 않으면 각 봇을 다시 되돌리는 작업이 생긴다.

우리 팀 실제 전략은 주력 벤더를 현 상태로 유지하되, 새 모델이 나올 때 핵심 봇 두세 개로 A/B 비교를 돌리는 것이다. 전체 전환은 비교 결과가 명확하고 회수 기간이 3개월 이내일 때만 진행한다. 그 판단이 서기 전까지는 프롬프트 품질 개선에 시간을 쓰는 게 ROI가 훨씬 높다.

지금 바로 쓸 수 있는 시사점

자동화 파이프라인에서 LLM을 쓰는 모든 지점을 목록화해라. 봇, Cursor 규칙, 내부 스크립트를 포함해서다. 그 중 모델 특화 동작에 의존하는 프롬프트가 몇 개인지 파악한다. Claude의 XML 태그 지시어나 특정 출력 포맷에 맞게 짜인 파서가 있다면, 그게 전환 시 손볼 포인트다. 목록 자체를 만드는 것만으로도 전환 비용의 윤곽이 잡힌다.

API 호출은 반드시 한 곳에서 관리해라. 각 스크립트가 벤더 SDK를 직접 호출하는 구조라면, 지금 당장 전환 계획이 없어도 헬퍼 레이어 하나로 통합하는 걸 시작하는 게 낫다. 다음 번 모델 버전 업그레이드 때 유지보수 비용이 확연히 줄어든다.

마지막으로 전환 결정 기준을 미리 숫자로 정해두어라. "더 좋아 보이면 바꾼다"가 아니라, "회수 기간 N개월 이내이고 A/B 비교에서 X% 이상 차이가 날 때 전환한다"는 기준이다. 기준이 있으면 OpenAI가 새 모델을 냈다는 뉴스가 뜰 때마다 팀이 흔들리지 않는다. AI 모델 경쟁은 앞으로도 계속된다. 그 경쟁에서 우리가 관리해야 할 건 어떤 모델이 이기느냐가 아니라, 우리 파이프라인이 그 경쟁에 얼마나 노출되어 있느냐다.

원문: AI News & Artificial Intelligence | TechCrunch