NextFuture에 처음 게시됨

한 창업자 주도 소프트웨어 스튜디오의 dev.to 글에 따르면, Claude Sonnet 5는 7월 1일에 기본 무료 및 Pro 모델이 되었으며, 해당 팀은 그로부터 4일 뒤에 고객의 검색 파이프라인(retrieval pipeline) 내에서 이를 실행했습니다. 이는 벤치마크 실행이나 장난스러운 데모가 아닙니다. 약 40,000개의 지원 문서와 "지어내지 마시오"라는 엄격한 요구 사항을 가진 소규모 비즈니스 고객을 위한 실제 운영 중인 RAG 챗봇입니다.

이 타임라인은 마케팅 발표를 자연스러운 실험으로 바꾸기 때문에 중요합니다. 팀은 새로운 모델 출시를 실제 고객 파이프라인과 대조하여 테스트한다고 말하는데, 그 이유는 "그것만이 그것들이 정말 중요한지 알 수 있는 유일한 방법이기 때문"입니다. 유사한 스택을 운영하는 모든 이들에게 핵심적인 질문은 이것입니다: 생성 모델(generation model)을 업그레이드하는 것이 실제 운영 중인 RAG 시스템에서 환각(hallucinations)을 실제로 줄여주는가, 아니면 단순히 동일한 실패 모드(failure modes)를 다른 곳으로 옮길 뿐인가?

유사한 검색 증강 생성(Retrieval-Augmented Generation, RAG) 파이프라인을 운영하는 개발자들에게 이 사례 연구는 벤더의 벤치마크가 아니라는 점에서 매우 유용합니다. RAG 챗봇을 구축(또는 재구축)할지 여부를 평가하는 소규모 비즈니스 소유자에게는, 새로운 모델이 출시되었을 때 "지루한" 아키텍처가 제공하는 가치를 보여주는 드문 사례입니다. 즉, 플랫폼 재구축 프로젝트를 기다리는 대신 며칠 내에 실제 지원 티켓(support tickets)을 대상으로 테스트할 수 있는 옵션을 제공한다는 것입니다.

이 지루함을 위해 구축된 스택

팀은 자신들의 아키텍처를 직설적인 용어로 설명합니다: 검색(retrieval)을 위한 pgvector, 얇은 재순위화(re-ranking) 단계, 그리고 "인용(citations)과 함께 답변하는 마지막 단계에 위치한 어떤 LLM이든"입니다. 생성 모델은 하중을 지탱하는 벽이 아니라 교체 가능한 의존성(swappable dependency)으로 취급됩니다.

그러한 설계 선택이 동일 주 내의 교체를 가능하게 만들었습니다. 다음은 팀이 공유한 실제 차이점(diff)이며, 그대로 복사할 템플릿이라기보다는 그들의 설정 기반(config-driven) 설정을 보여주는 예시로 제시되었습니다:

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

저자가 언급했듯이, 제공자(provider)나 모델 버전을 교체하는 것은 단 한 줄의 변경만으로 이루어져야 합니다. 만약 그렇지 않다면, 그것은 모델의 문제가 아니라 아키텍처(architecture)의 문제입니다. 아래의 결과를 읽기 전에 이 관점을 충분히 숙고할 가치가 있습니다. 다음에 이어지는 평가(eval) 수치들이 의미를 갖는 이유는 나머지 파이프라인(pipeline)이 전혀 수정되지 않은 상태로 유지되었기 때문입니다.

이 패턴은 주의 깊게 일반화할 가치가 있습니다. 생성 호출(generation call)을 프롬프트 구성(prompt construction), 인용 형식 지정(citation formatting), 그리고 출력 파싱(output parsing)으로부터 분리(decoupling)하는 것이야말로, 새로운 모델 출시를 코드 재작성이 아닌 단 몇 시간의 테스트로 바꿔주는 핵심입니다. 프롬프트 문구를 특정 모델의 특이점에 맞춰 하드코딩하거나, 해당 모델의 형식 습관에 맞춰 조정된 정규 표현식(regex)으로 출력을 파싱하는 파이프라인은 이러한 선택권을 가질 수 없습니다. 교체하는 순간 다른 무언가가 먼저 고장 나기 때문입니다.

처음 48시간 동안 무엇이 변했는가

팀은 다른 어떤 변경 사항을 적용하기 전, 48시간 동안 기존 평가 세트(정답이 알려진 약 120개의 실제 고객 지원 질문)를 대상으로 Sonnet 5를 실행했습니다. 팀의 설명에 따르면 두 가지 결과가 눈에 띄었습니다. 아래의 수치는 독립적이거나 제3자의 벤치마크(benchmark)가 아닌 해당 팀의 내부 평가(internal eval) 결과이므로, 검증된 업계 결과라기보다는 한 팀이 스스로 보고한 전/후 비교로 취급해야 합니다.

팀은 지연 시간이나 비용 때문에 새 모델을 유지한 것이 아니라고 명시했습니다. 그들이 새 모델을 유지한 이유는 확신에 찬 오답의 감소 때문이었습니다. 그들의 표현을 빌리자면, 소상공인에게 실제로 비용 손실을 입히는 실패 모드(failure mode)는 도움이 되지 않는 챗봇이 아니라, 아주 당당하게 틀린 답을 말하는 챗봇입니다.

40,000개의 문서로부터 답변을 제공하는 지원 봇(support bot)의 경우, 자신 있게 내놓는 잘못된 답변은 답변을 아예 하지 않는 것보다 더 해롭습니다.

수치를 읽을 때는 적절한 주의 사항을 염두에 두어야 합니다. 120개의 질문으로 구성된 평가 세트(eval set)와 48시간의 테스트 기간은 명백한 성능 퇴보(regression)를 포착하기에는 충분하지만, 환각률(hallucination rate)을 인증하기에는 충분하지 않습니다. 여기에 언급된 그 어떤 것도 독립적으로 검증된 벤치마크(benchmark)가 아닙니다. 이는 하나의 팀이 하나의 문서 세트를 사용하여 하나의 유스케이스(use case)를 대상으로 진행한 내부 비교일 뿐입니다. 이를 고객에게 인용할 숫자가 아니라, 여러분 자신의 평가 세트(eval set)를 통해 재테스트해 볼 가치가 있는 신호(signal)로 취급하십시오.

모델 교체가 해결하지 못한 것

팀은 새로운 모델이 해결하지 못한 부분에 대해서도 똑같이 직설적입니다. 그들의 설명에 따르면, 모델 교체는 잘못된 청킹(chunking) 문제를 해결하지 못했으며, 이미 잘못된 문서를 반환하고 있던 검색(retrieval) 단계의 문제도 해결하지 못했습니다. 그들은 일주일 중 대부분의 시간이 "지루한 작업들", 즉 청크 크기(chunk size), 메타데이터 필터(metadata filters), 그리고 재순위화 임계값(re-ranking thresholds)에 소요되었다고 말합니다. 이는 마지막에 어떤 모델이 위치하든 모든 RAG 파이프라인(pipeline)에 필요한 동일한 튜닝(tuning) 작업입니다.

또한 팀은 이 상황을 더 넓은 논쟁의 관점에서 구성합니다. 그들은 팀들이 검토 없이 AI 에이전트(AI agents)에 의존하는 코드베이스에서 중복이 약 4배 증가하고 코드 변동(churn)이 늘어나고 있다고 보고한, 널리 인용되는 1억 5,300만 라인 규모의 분석을 인용합니다. 그리고 RAG 시스템에서도 동일한 패턴이 나타난다고 주장합니다. 즉, 팀들이 아무도 제대로 설계하지 않은 검색 계층(retrieval layer)을 가려줄 것이라 기대하며 더 화려한 모델로 교체한다는 것입니다. 그들의 표현을 빌리자면, RAG 챗봇이 환각(hallucinate)을 일으키는 이유 중 모델은 약 20%에 불과하며, 나머지 80%는 여러분이 모델에 입력하는 데이터에 달려 있습니다. 이는 팀의 프레임워크와 추정치일 뿐 독립적으로 측정된 수치는 아니지만, 48시간의 평가(eval)가 실제로 보여준 결과와 일치합니다. 모델 교체 후에도 청킹(chunking)과 검색(retrieval) 문제는 여전히 남아 있었습니다.

실질적인 교훈은 모델 업그레이드를 불신하라는 것이 아니라, 이를 올바른 순서로 진행하라는 것입니다. 청킹(chunking) 경계와 재순위화(re-ranking) 임계값을 먼저 수정하십시오. 왜냐하면 이 요소들은 어떤 모델이 질의에 답변하느냐와 상관없이 동일하게 작용하기 때문입니다. 검색(retrieval) 단계에서 올바른 문서가 반환된 이후에야, 모델 교체가 환각(hallucination) 비율에 대해 의미 있는 정보를 제공할 수 있습니다.

결론: 설정값인가, 마이그레이션 프로젝트인가?

팀의 자체적인 결론은 동일한 결정을 내리려는 독자들에게 진단 도구 역할도 합니다. 만약 당신의 RAG 파이프라인이 생성(generation) 모델을 하나의 설정값(config value)으로 취급할 수 있도록 설계되어 있다면, 모델 출시는 며칠 내로 실행할 수 있는 좋은 소식이지, 거대한 마이그레이션 프로젝트가 아닙니다.

그것이 바로 어떤 설정 파일(config file)을 건드리기 전에 실행해 볼 가치가 있는 테스트입니다. 만약 당신의 생성 호출(generation call)이 이미 하나의 함수 뒤에 위치하며, 프롬프트 구성(prompt construction), 인용 형식 지정(citation formatting), 출력 파싱(output parsing)이 특정 모델의 특이점으로부터 분리(decoupled)되어 있다면, Sonnet 5로의 교체는 이번 테스트와 마찬가지로 같은 주 내에 평가(eval)를 마칠 수 있는 작업입니다. 반면, 당신의 프롬프트가 특정 모델의 형식 습관에 맞춰 튜닝되어 있거나, 검색 레이어(retrieval layer)를 출시 이후 한 번도 건드리지 않았다면, 모델 교체는 가장 먼저 수정해야 할 중요한 작업이 아닙니다. 청킹(chunking), 메타데이터 필터(metadata filters), 그리고 재순위화(re-ranking) 임계값을 먼저 수정해야 합니다.

이 기사는 원래 NextFuture에 게시되었습니다. 더 많은 풀스택(fullstack) 및 AI 엔지니어링 콘텐츠를 보려면 저희를 팔로우하세요.