RAG, 에이전트, 파인튜닝을 실제 서비스에 넣어본 이야기 — 삽질과 해결의 기록.
"컨텍스트 윈도우가 100만 토큰인데 RAG 파이프라인을 왜 유지해야 하지?" 3월 초, 팀 내 백엔드 개발자가 던진 질문이었다. 솔직히 반박하기 어려웠다. 우리가 쓰는 사내 문서는 전부 합쳐도 15만 토큰이 안 됐고, 청킹-임베딩-벡터DB-리랭킹으로 이어지는 파이프라인의 유지보수 비용은 매달 늘어나고 있었다. 그래서 실험했다. RAG를
LLM 앱이 "잘 돌아가고 있다"고 생각했던 시간이 3개월이었다. 사용자 불만이 없으니까 괜찮은 줄 알았다. 에러율 0.3%, 평균 응답 시간 2초대. 대시보드 지표만 보면 문제없었다. 그런데 LLM 옵저버빌리티 도구를 붙이고 나서 이 "괜찮음"이 착각이었다는 걸 깨달았다. #기존 모니터링으로는 뭘 놓치나 전통적인 APM
지난 달, 고객 문의 챗봇에 function calling을 붙였다. 주문 조회, 환불 처리, 배송 추적 — 세 개 함수면 충분하다고 생각했다. 데모에서는 정확도 98%. PM이 "이거 바로 배포하자"고 했고, 일주일 뒤 장애가 세 번 터졌다. #모델은 당신이 생각하는 것보다 함수를 못 고른다 데모에서 테스트할 때는 프롬프트가 깔끔하다.
지난 6개월간 세 번의 파인튜닝 프로젝트를 진행했고, 그중 두 번은 결국 프롬프트 엔지니어링으로 되돌아왔다. 남은 한 번은 프로덕션에 잘 돌아가고 있지만, 그마저도 "파인튜닝이 정답이었나"를 매달 자문한다. #첫 번째 시도: 고객 문의 분류 CS팀에서 들어오는 문의를 15개 카테고리로 자동 분류하는 게 목표였다. GPT-4 프롬프트로는 정
프로덕션 LLM 서비스를 운영하면서 가장 먼저 깨달은 건, 비용 문제는 모델 성능이 아니라 호출 패턴에서 터진다는 점이었다. 모델을 바꾸거나 프롬프트를 쥐어짜기 전에, 요청 자체를 들여다봐야 한다. #비싼 모델한테 잡일을 시키고 있었다 서비스를 론칭했을 때는 모든 요청을 GPT-4급 모델로 보냈다. 당연하다고 생각했다. 답변 품질이 곧 서비스 품질이니까.
우리 팀이 LLM 기반 데이터 추출 파이프라인을 프로덕션에 올린 건 작년 말이었다. GPT-4o에 프롬프트로 "JSON으로 응답해줘"라고 쓰고, 응답을 json.loads()로 파싱하는 단순한 구조. 테스트에서는 100번 돌려도 한 번도 안 깨졌다. 프로덕션에 배포한 첫 주, 에러율 2.3%. 2.3%가 뭐 대수냐고? 하루 요청 10만 건
프로덕션에 LLM 붙이고 3주 뒤에 전체 파이프라인을 뒤집어엎었다. 원인은 허무할 정도로 단순했다. 답변 품질을 측정할 방법이 아예 없었다. #데모 통과, 프로덕션 폭발 고객 문의 자동 응답 시스템이었다. RAG 달고, 프롬프트 좀 다듬고, 내부 데모에서 "오 괜찮은데?" 한마디에 바로 배포했다. 첫 주는 순탄했다. CS팀에서 "
"모델을 GPT-4o로 바꿨는데도 답변이 이상해요." RAG 시스템 운영하다 보면 이 말을 정말 자주 듣는다. 프롬프트 튜닝하고, 모델 업그레이드하고, 리랭커 달고. 그런데 정작 답변 품질이 안 올라간다. 왜? 2026년 초 여러 벤치마크에서 반복적으로 확인된 수치가 하나 있다. RAG 실패의 80%는 LLM이 아니라 인제스천·청킹 레이어
"AI 에이전트 프로덕션 배포" 검색하면 튜토리얼이 수백 개 나온다. OpenAI AgentKit, Amazon Bedrock AgentCore, Claude Code Agent Teams까지. 도구는 넘친다. 그런데 진짜 프로덕션에 올린 팀 얘기를 들어보면, 대부분 이렇게 시작한다. "처음 2주는 괜찮았어요." #&qu