새 모델이 나올 때마다 반복되는 고민
LLM 기반 서비스를 운영해본 분이라면 공감하실 텐데요. 새 모델이 나올 때마다 '갈아타야 하나, 말아야 하나' 고민이 시작되거든요. 벤치마크 점수야 늘 좋아졌다고 하지만, 내 서비스에서도 잘 동작할지는 직접 돌려보기 전까지는 아무도 모르는 일이라서요. 그래서 실제 운영 환경에서 모델을 교체해본 팀의 후기는 언제나 귀한 자료인데요. 최근 Ploy라는 팀이 실제 고객이 쓰고 있는 AI 에이전트를 GPT-5.6으로 마이그레이션한 경험을 공개했어요. 결과만 먼저 말씀드리면, 작업 처리 속도는 2.2배 빨라졌고 비용은 27% 줄었다고 해요.
여기서 '프로덕션'이라는 단어가 중요한데요. 이게 뭐냐면, 데모나 사내 실험용이 아니라 실제 고객이 매일 쓰고 있는 서비스라는 뜻이에요. 실험 단계에서는 모델을 바꿨다가 이상하면 되돌리면 그만이지만, 운영 중인 서비스는 모델을 바꾸는 순간 고객이 받는 답변의 말투, 정확도, 속도가 한꺼번에 바뀌어요. 그래서 프로덕션 마이그레이션 후기에는 벤치마크 표에서는 절대 안 보이는 현실적인 교훈이 담겨 있거든요.
모델 교체는 '모델명 한 줄 바꾸기'가 아니에요
겉에서 보면 API 호출 코드에서 모델 이름 문자열만 바꾸면 끝일 것 같잖아요? 그런데 실제로 해보면 전혀 그렇지 않아요. 모델마다 프롬프트를 해석하는 '성격'이 다르거든요. 이전 모델에서는 잘 따르던 지시를 새 모델은 다르게 받아들이기도 하고, 반대로 예전 모델의 버릇을 고치려고 프롬프트에 덕지덕지 붙여놨던 문구들, 예를 들어 '반드시 JSON으로만 답하세요, 절대 다른 말을 붙이지 마세요' 같은 경고문이 새 모델에서는 오히려 과잉 반응을 일으키기도 해요. 그래서 마이그레이션의 상당 부분은 사실 '프롬프트 다이어트' 작업이에요. 오래된 프롬프트일수록 이전 모델의 약점을 보완하려던 임시방편이 지층처럼 쌓여 있거든요.
에이전트라면 변수가 하나 더 붙어요. 에이전트는 모델이 스스로 판단해서 검색, 코드 실행, DB 조회 같은 도구(툴)를 골라 호출하는 구조인데, 모델마다 도구를 쓰는 습관이 달라요. 어떤 모델은 필요한 도구 여러 개를 한 번에 병렬로 부르고, 어떤 모델은 돌다리를 두드리듯 하나씩 순서대로 부르거든요. 같은 작업이라도 이 습관 차이 때문에 왕복 횟수가 달라지고, 그게 전체 응답 시간과 비용에 그대로 반영돼요.
'2.2배 빠르다'의 진짜 의미
여기서 짚고 넘어갈 부분이 있는데요. 에이전트에서 '빠르다'는 건 단순히 글자가 화면에 빨리 찍힌다는 뜻이 아니에요. 에이전트의 체감 속도는 크게 세 가지가 결정해요. 첫째는 초당 토큰 생성 속도, 둘째는 답을 내놓기 전에 모델이 속으로 고민하는 추론(reasoning) 토큰의 양, 셋째는 작업 하나를 끝내는 데 필요한 도구 호출 왕복 횟수예요. 새 모델이 더 영리해져서 시행착오 없이 한 번에 맞는 도구를 부르고 불필요한 고민을 줄이면, 토큰 생성 속도가 비슷해도 전체 작업은 두 배 넘게 빨라질 수 있어요.
비용도 같은 원리예요. 토큰 단가표만 보고 '더 비싸졌네, 싸졌네'를 판단하면 안 되고, '작업 하나를 끝내는 데 든 총비용'으로 계산해야 하거든요. 단가가 조금 올라도 시행착오가 줄어 전체 토큰 사용량이 확 줄면 청구서 금액은 오히려 내려가요. 27% 절감이라는 숫자도 이런 '작업당 비용' 관점에서 나온 결과라고 봐야 자연스러워요.
진짜 교훈은 평가 인프라에 있어요
한 발 물러서서 업계 흐름을 보면요, 이제 주요 모델 제공사들이 몇 달 간격으로 새 모델을 쏟아내고 있어요. OpenAI, Anthropic, Google이 서로 앞서거니 뒤서거니 하면서요. 그러니 모델 교체는 몇 년에 한 번 있는 대공사가 아니라 분기마다 돌아오는 일상 업무가 됐어요. 이때 빠르게 갈아탈 수 있는 팀과 무서워서 못 갈아타는 팀을 가르는 건 딱 하나, 평가(eval) 셋의 유무예요. 평가 셋이 뭐냐면, 우리 서비스에 실제로 들어오는 대표적인 요청들을 모아놓고 '이 정도 답이 나와야 합격'이라는 기준과 함께 자동으로 채점하는 테스트 모음이에요. 백엔드 개발자에게 익숙한 회귀 테스트의 LLM 버전이라고 생각하시면 돼요. 이게 있으면 새 모델이 나왔을 때 하루 만에 '우리 서비스 기준으로 좋아졌는지'를 숫자로 확인할 수 있거든요.
한국 개발자에게 주는 시사점
지금 LLM 기능을 하나라도 운영하고 계시다면, 오늘 해볼 일은 모델 교체가 아니라 평가 셋 만들기예요. 거창할 필요 없이 실제 사용자 로그에서 대표 사례 30~50개를 뽑아서 기대 결과와 함께 저장해두는 것부터 시작하면 돼요. 그리고 코드에서 모델명을 하드코딩하지 말고 설정값으로 빼두세요. 이 두 가지만 해둬도 다음 모델이 나왔을 때 '남들 후기 기다리기'가 아니라 '우리 데이터로 직접 검증'이 가능해지거든요. 속도가 2배 빨라지고 비용이 4분의 1 넘게 줄어드는 기회는, 준비된 팀에게만 하루짜리 작업이에요.
마무리
핵심은 한 줄이에요. 모델 마이그레이션의 성패는 새 모델의 성능이 아니라, 우리 팀이 '좋아졌는지 나빠졌는지'를 측정할 수 있느냐에 달렸다는 것. 여러분 팀은 모델을 바꿀 때 무엇을 기준으로 판단하세요? 평가 셋을 운영하고 계시다면 어떻게 만드셨는지도 궁금하네요.
🔗 출처: Hacker News