Claude Sonnet 5는 7월 1일에 기본 무료 및 Pro 모델이 되었습니다. 우리는 그로부터 4일 뒤, 고객의 검색 파이프라인(retrieval pipeline) 내에 이를 적용했습니다. 이는 단순한 데모용 장난감이 아니라, 약 40,000개의 지원 문서와 "절대로 내용을 지어내지 말 것"이라는 엄격한 요구 사항을 가진 소규모 비즈니스 고객을 위한 실제 운영용 RAG 챗봇이었습니다.

무엇이 실제로 변했고, 무엇이 변하지 않았는지 소개합니다.

설정 (The setup)

이 고객은 자신의 데이터를 기반으로 RAG 시스템을 구축하기 위해 개발자를 고용하려는 많은 소규모 비즈니스들이 그러하듯 우리를 찾아왔습니다. 쌓여있는 PDF 파일들, 공유 드라이브, 그리고 매일 똑같은 30가지 질문이 반복해서 들어오는 고객 지원 편지함이 전부였습니다. 기업용 예산도, 사내 ML(머신러닝) 팀도 없었으며, 그저 매일 똑같은 이메일에 답변하는 일을 멈춰야 한다는 실질적인 필요성만 있었습니다.

이번 프로젝트를 위한 우리의 스택은 의도적으로 평범하게 구성했습니다. 검색(retrieval)을 위한 pgvector, 가벼운 재순위화(re-ranking) 단계, 그리고 마지막에 인용(citation)과 함께 답변을 제공하는 LLM(대규모 언어 모델)입니다. 마지막 부분은 코드 재작성이 아닌 설정값(config value)일 뿐입니다. 제공업체나 모델 버전을 교체하는 것은 단 한 줄의 변경만으로 이루어져야 합니다. 만약 그렇지 않다면, 모델이 아니라 당신의 아키텍처(architecture)가 진짜 문제입니다.

const generationModel = {
  provider: 'anthropic',
  model: 'claude-sonnet-5', // 기존에는 claude-sonnet-4-6 이었음
...

개선된 점

기존 평가 세트(정답이 알려진 약 120개의 실제 고객 지원 질문)를 대상으로 한 초기 48시간의 테스트에서 두 가지가 눈에 띄었습니다.

• 확신에 찬 오답의 감소. Sonnet 5는 서로 관련 없는 두 개의 정책 섹션을 그럴듯하게 섞어서 답변하는 대신, "문서에 해당 내용이 포함되어 있지 않습니다"라고 말하는 데 훨씬 더 능숙했습니다. 챗봇이 도움이 되지 않는 것보다, 챗봇이 아주 당당하게 틀린 답을 내놓는 것이 소규모 비즈니스에 실제로 비용 손실을 입히는 실패 유형입니다.
• 압박 상황에서의 검색된 컨텍스트(retrieved context) 활용 능력 향상. 쿼리가 모호할 때 발생하는 흔한 실제 상황을 가정하여, 의도적으로 34개가 아닌 810개의 청크(chunk)를 입력했을 때, 답변 품질이 이전 모델보다 더 잘 유지되었습니다. "첫 번째 청크만 선택하고 나머지는 무시하는" 현상이 줄어들었습니다.

지연 시간 (Latency)은 거의 일정했습니다. 쿼리당 비용 (Cost per query)도 일정했습니다. 두 가지 모두 모델을 교체한 이유가 되지 못했습니다.

변하지 않은 것들

모델 교체가 잘못된 청킹 (Chunking) 문제를 해결해주지는 않았으며, 이미 잘못된 문서를 반환하고 있던 검색 (Retrieval) 단계의 문제도 해결하지 못했습니다. 우리는 여전히 일주일 중 대부분을 지루한 작업들, 즉 청크 크기 (Chunk size), 메타데이터 필터 (Metadata filters), 그리고 재순위화 임계값 (Re-ranking thresholds) 설정에 소비했습니다. 이는 소규모 비즈니스 고객을 위한 RAG 챗봇 개발 과정에서 벤더의 피치 덱 (Pitch deck)에는 절대 등장하지 않는 부분입니다. 왜냐하면 이는 스크린샷으로 찍어 보여줄 수 있는 '기능'이 아니기 때문입니다.

현재 AI가 작성한 코드의 품질에 대해 실질적인 반발이 일고 있습니다. 이번 주에 널리 인용된 1억 5,300만 라인 규모의 분석에 따르면, 리뷰 없이 에이전트 (Agent)에 과도하게 의존하는 팀들의 경우 코드 중복이 약 4배 증가하고 코드 변경 (Churn)이 늘어나고 있는 것으로 나타났습니다. 우리는 RAG 시스템에서도 동일한 패턴을 목격합니다. 팀들은 더 화려한 모델로 교체하면 아무도 제대로 설계하지 않은 검색 계층 (Retrieval layer)의 결함을 덮어줄 것이라 기대합니다. 하지만 그렇지 않습니다. RAG 챗봇이 환각 (Hallucination)을 일으키는 원인 중 모델이 차지하는 비중은 아마 20% 정도일 것입니다. 나머지 80%는 당신이 모델에 무엇을 입력하느냐에 달려 있습니다.

실제 교훈

만약 당신의 RAG 파이프라인 (Pipeline)이 생성 모델을 단순한 설정 값 (Config value)으로 처리할 수 있도록 설계되어 있다면, 새로운 모델의 출시는 거대한 마이그레이션 (Migration) 프로젝트가 아니라 며칠 내로 실행할 수 있는 좋은 소식이 될 것입니다. 만약 그렇지 않다면 — 즉, '모델 교체'가 6개의 서로 다른 파일에 있는 프롬프트 템플릿 (Prompt templates)을 수정해야 함을 의미한다면 — 이번 분기에 어떤 모델이 가장 똑똑한지 걱정하기 전에 그 구조부터 고치는 것이 가치 있는 일입니다.

우리는 얼굴 없는 대행사가 아니라 창업자가 이끄는 소프트웨어 스튜디오이며, 새로운 모델 출시를 실제 고객의 파이프라인에 적용하여 테스트합니다. 그것만이 모델이 정말로 유의미한지 알 수 있는 유일한 방법이기 때문입니다. 만약 당신이 엔터프라이즈 예산이 아닌 소규모 비즈니스로서, 자신의 데이터를 기반으로 RAG 시스템을 구축할 개발자를 채용하려 한다면, duskel.com/services에서 우리가 어떻게 범위를 산정하는지 확인하거나 hello@duskel.com으로 문의해 주세요.