"컨텍스트 윈도우가 100만 토큰인데 RAG 파이프라인을 왜 유지해야 하지?" 3월 초, 팀 내 백엔드 개발자가 던진 질문이었다.
LLM 앱이 "잘 돌아가고 있다"고 생각했던 시간이 3개월이었다. 사용자 불만이 없으니까 괜찮은 줄 알았다.
지난 달, 고객 문의 챗봇에 function calling을 붙였다. 주문 조회, 환불 처리, 배송 추적 — 세 개 함수면 충분하다고 생각했다.
지난 6개월간 세 번의 파인튜닝 프로젝트를 진행했고, 그중 두 번은 결국 프롬프트 엔지니어링으로 되돌아왔다. 남은 한 번은 프로덕션에 잘 돌아가고 있지만, 그마저도 "파인튜닝이 정답이었나"를 매달 자문한다.
프로덕션 LLM 서비스를 운영하면서 가장 먼저 깨달은 건, 비용 문제는 모델 성능이 아니라 호출 패턴에서 터진다는 점이었다. 모델을 바꾸거나 프롬프트를 쥐어짜기 전에, 요청 자체를 들여다봐야 한다.
우리 팀이 LLM 기반 데이터 추출 파이프라인을 프로덕션에 올린 건 작년 말이었다. GPT-4o에 프롬프트로 "JSON으로 응답해줘"라고 쓰고, 응답을 json.
"모델을 GPT-4o로 바꿨는데도 답변이 이상해요." RAG 시스템 운영하다 보면 이 말을 정말 자주 듣는다.
"AI 에이전트 프로덕션 배포" 검색하면 튜토리얼이 수백 개 나온다. OpenAI AgentKit, Amazon Bedrock AgentCore, Claude Code Agent Teams까지.