고객에게 환불 금액을 계산해서 메일까지 보내는 에이전트를 만들었다. 주문 DB 조회 → 환불 정책 API 호출 → 금액 계산 → 이메일 발송, 네 단계.
자동화의 꿈은 이랬다. 모델이 응답을 생성하면 다른 모델이 점수를 매기고, 점수가 기준 이하면 자동으로 재생성.
사내 문서 검색 시스템에 RAG를 붙였다. OpenAI의 text-embedding-3-large, Pinecone, GPT-4o — 스택은 나무랄 데 없었다.
RAG 파이프라인 비용이 하루 20만 원을 찍었을 때 첫 번째 반응은 당연히 캐시였다. 같은 질문에 같은 문서 조합이면 LLM 호출을 또 할 이유가 없으니까.
고객사 CS 분류기를 만들고 있었다. 카테고리 47개, 정확도 기준 92%.
파인튜닝 데이터가 500개 필요한데 우리가 가진 건 고작 73개, 석 달 기다릴 여유는 없었다. 그래서 당연히 떠오른 선택지 — LLM한테 만들어달라고 하면 되지 않나?
스트리밍 붙이면 빨라진다는 말을 곧이곧대로 믿었다. GPT-4o 기반 사내 검색 챗봇에 SSE 스트리밍을 달고, 프론트엔드에 타이핑 애니메이션까지 입혀서 배포했다.
파인튜닝을 해야 한다는 결론이 나오는 건 보통 빠르다. 프롬프트 엔지니어링으로 안 되는 게 쌓이고, few-shot 토큰비가 한 달에 수백만 원 나오기 시작하면 팀 회의에서 "우리도 파인튜닝하면 되잖아"라는 말이 나온다.
구글이 200개 넘는 에이전트 배포 사례를 분석한 보고서가 올해 나왔다. 핵심 발견: 출시 후 엔지니어링 시간의 60%가 에이전트 행동 디버깅에 쓰이고 있었다.
프로덕션 LLM 기능에 프롬프트 변경을 배포하는 과정에 eval 게이트를 처음 달던 날, 우리 팀은 지난 두 달간 머지한 프롬프트 변경의 52%가 실제로는 품질 저하였다는 사실을 발견했다.
API 비용 청구서를 보다가 자괴감이 든 적 있다면 LLM 라우팅이라는 개념을 한 번쯤은 접했을 거다. 간단한 질문은 싼 모델로 돌리고, 복잡한 건 비싼 모델로 보내면 비용이 절반 이하로 떨어진다는 이야기.
올해 1분기, 우리 팀은 RAG 파이프라인을 걷어내기로 했다. 이유는 단순했다.
금융권 프로젝트에서 RAG 기반 고객 상담 보조 시스템을 데모했다. 고객 문의가 들어오면 내부 약관과 상품 설명서에서 관련 내용을 검색해서, 상담사에게 답변 초안을 제안하는 구조였다.
우리 팀 AI 챗봇에 좋아요/싫어요 버튼을 단 게 올해 초다. 기획자가 "피드백 루프 만들어야죠"라고 했고, 개발자 셋이 3일 만에 구현했다.
PM이 "좀 더 친절하게"라는 피드백 한 줄을 남겼고, 누군가 시스템 프롬프트에 "항상 긍정적으로 응답하세요"를 추가했다. 다음 날 아침 CS 티켓이 평소의 세 배로 쌓여 있었다.