화요일에 무너져버린 파이프라인

2026년 6월, Anthropic의 Claude가 수출 통제 규정에 따라 여러 지역에서 20일 동안 서비스 이용이 중단되었습니다. 만약 당신이 anthropic.messages.create()에 대한 단일 하드코딩 호출로 고객의 RAG 챗봇을 구축했다면, 그 고객의 지원 봇은 작동을 멈췄을 것입니다. 모델이 나빠졌기 때문이 아닙니다. 벤더(Vendor)가 사라졌기 때문입니다.

우리는 미국 외 지역을 포함한 여러 B2B 고객을 위해 RAG 시스템을 구축하는 작은 스튜디오를 운영하고 있으며, 이것이 바로 우리가 현재 설계 시 대비하고 있는 정확한 시나리오입니다. 가설로서가 아니라, 이에 대한 계획을 세우지 않았던 팀들에게 이미 실제로 일어났던 일로서 말입니다.

대부분의 RAG 챗봇 구축은 잘못된 것을 맞게 하고 있다

대행사가 "RAG 챗봇 개발" 프로젝트를 제안할 때, 데모는 항상 똑같습니다: 문서를 임베딩(Embedding)하고, 벡터 스토어(Vector Store)를 연결하고, 모델 하나를 호출하면 끝입니다. 영업 미팅에서는 질문에 답변을 잘 합니다. 하지만 다음과 같은 상황이 발생했을 때 무엇이 일어날지에 대해서는 아무도 스트레스 테스트(Stress-test)를 하지 않습니다:

• 벤더가 하룻밤 사이에 가격 정책을 변경할 때
• 벤더의 API가 고객의 국가에서 수출 제한을 받을 때
• 벤더가 당신이 프롬프트(Prompt)를 작성했던 모델을 지원 중단(Deprecate)할 때

우리는 LLM 호출을 스택(Stack)에서 가장 불안정한 부분으로 취급하며, 이를 교체하는 것이 재작성이 아닌 설정 변경(Config change)만으로 가능하도록 다른 모든 것을 설계합니다.

우리가 실제로 구축하는 것

검색 레이어(Retrieval layer)와 모델 호출 사이에 얇은 프로바이더 인터페이스(Provider interface)를 둡니다. 검색(Retrieval), 청킹(Chunking), 리랭킹(Reranking), 그리고 인용(Citation) 로직은 벤더의 SDK에 직접적으로 닿지 않습니다.

class LLMProvider:
 def generate(self, prompt: str, context: list[str]) -> str:
 raise NotImplementedError
...

이것은 영리한 방식이 아닙니다. 그것이 핵심입니다. 지루한 추상화(Abstraction)야말로 벤더의 서비스 중단 상황에서도 살아남는 것입니다.

오픈 웨이트(Open-weight) 모델이 계산법을 바꾼 이유

LongCat-2.0은 이번 달 완전한 MIT 라이선스 하에 출시되었습니다. 지역적 제한이 없으며, 미세 조정 (fine-tune) 및 재배포가 자유롭습니다. 미국산 모델이 3주 동안 사라지는 것을 목격한 외국인 고객에게 이것은 단순한 호기심의 대상이 아니라, 하나의 대비책 (fallback path)입니다. Claude를 버리라는 말이 아닙니다. 6월 30일에 출시된 Sonnet 5는 우리가 실제 운영 환경 (production)에서 사용해 본 모델 중 진정으로 가장 날카로운 에이전트 모델 (agentic model)이며, 추론 중심의 검색 (reasoning-heavy retrieval) 작업에는 여전히 우리의 기본 모델입니다. 우리가 말하고자 하는 것은, 단일 벤더가 고객의 고객 지원 데스크나 내부 지식 베이스 (knowledge base)의 단일 장애점 (single point of failure)이 되게 하지 말라는 것입니다.

아무도 가격에 반영하지 않는 신뢰의 격차

이번 주에 떠도는 통계가 있습니다. 개발자의 84%가 현재 AI 코딩 도구를 사용하고 있지만, 감독 없이 결과물을 신뢰하는 비율은 29%에 불과합니다. 우리는 RAG에서도 동일한 분열을 목격합니다. 고객들은 데모가 보여주는 기능에는 열광하지만, 곧이어 "고객 앞에서 틀린 답을 내놓으면 어떻게 되나요?"라고 묻습니다. 솔직한 답변은 이렇습니다. 가끔은 틀릴 것이며, 여러분의 아키텍처에는 단순히 더 큰 프롬프트 (prompt)가 아니라, 인간의 검토 단계와 인용 경로 (citation trail)가 필요합니다.

이것이 바로 피칭(pitch) 단계에서 데모에만 치중하고 실패 모드 (failure mode)를 간과할 때 생략되는, 소규모 비즈니스를 위한 AI RAG 시스템 통합 (AI RAG system integration)의 핵심입니다.

프로젝트 범위를 산정할 때의 의미

B2B 작업을 위해 RAG 챗봇 개발 대행사를 평가하고 있다면, 정확도에 대해 묻기 전에 두 가지를 먼저 물으십시오. 모델 벤더가 약관을 변경하면 어떻게 되는지, 그리고 검색 (retrieval) 코드를 건드리지 않고도 동일한 파이프라인을 다른 모델로 연결할 수 있는지입니다. 만약 답변이 "다시 구축해야 합니다"라면, 여러분은 시스템이 아니라 데모를 사고 있는 것입니다.

우리는 최근 모든 RAG 프로젝트에 이러한 벤더 유연성 패턴 (vendor-flexible pattern)을 구축해 오고 있습니다. 부분적으로는 이것이 좋은 아키텍처이기 때문이며, 또 다른 이유는 지난 한 달간의 상황이 미국 외 지역에서 운영되는 고객들에게 이것이 선택 사항이 아님을 증명했기 때문입니다.

이와 같은 프로젝트의 범위를 산정하고 있다면, duskel.com/services에서 우리의 접근 방식을 확인하거나, hello@duskel.com으로 이메일을 보내 무엇을 만들고 있는지 알려주세요.