에러 로그 없이 검색이 죽는다. tool call이 사라진다. 다른 사람의 문서가 섞여 나온다. 온프레미스 AI 구축 현장에서 실제로 발생한 네 가지 사일런트 장애 — 공통점은 로그에 아무것도 없었다는 것이다.
— RAG와 에이전트가 현장에서 부딪히는 보이지 않는 함정들
검색은 죽어 있는데 에러 로그는 없고, 모델은 더 똑똑해졌는데 에이전트는 더 느려진다. 테스트를 통과한 뒤에야 다른 사람의 문서가 보이기도 한다.
AI 시스템에서 가장 무서운 오류는 에러가 나지 않는 오류다. 이 글은 온프레미스 AI 구축 현장에서 실제로 발생한 네 가지 사일런트 장애를 다룬다. 공통점은 하나다. 에러 로그가 없었다.
금융그룹 D사의 AI 시스템은 복수의 분리된 네트워크 환경에서 운영되고 있었다. 임베딩 모델을 BGE-M3(1024차원)로 교체한 뒤, 검색 품질이 눈에 띄게 떨어졌다. 그런데 아무도 즉시 알아차리지 못했다.
DI(Data Ingestion) 파싱은 전부 성공이었다. 로그에 에러는 단 한 줄도 없었다. 모니터링 대시보드도 정상. 그냥 "검색 결과가 좀 이상한 것 같은데..." 수준이었다.
로그 반출 분석을 돌리고 나서야 원인이 나왔다.
The [dense_vector] field [vector] has more dimensions than defined in the mapping [512]
임베딩 모델은 1024차원 벡터를 생성하는데, Elasticsearch 인덱스 매핑은 이전 모델 기준인 512차원 그대로였다. 1024차원 벡터를 512차원 인덱스에 넣으려 하니 ES가 전부 거부했다. 그 상태로 358건의 벡터 저장이 실패했고, 시스템은 이를 드러내지 않은 채 RAG를 계속 돌리고 있었다. 관련 문서를 하나도 찾지 못하는 검색 엔진.
3개 망 전부 동일한 문제였다.
"이전에 덤프떠놓은 ES 인덱스 보니까 거기는 512차원의 vector값들이 있더라고요? 근데 그때 봤을 때 Triton에 떠있는 모델들은 512차원이 없었는데... 뭐로 어떻게 했었는지 파악도 좀 필요할듯해요"
임베딩 모델을 바꾸면서 인덱스 매핑을 같이 바꿔야 한다는 건 당연한 이야기다. 문제는 "당연한 걸 빼먹었을 때, 시스템이 아무 말도 하지 않는다"는 점이다.
그런데 벡터 정합성 문제는 에러 스파이크나 레이턴시 급등으로 나타나지 않는다. 임베딩 드리프트만으로도 6개월 내 검색 정밀도가 15~20%까지 하락할 수 있다는 보고가 있다 [2]. 에러도, 알림도, 레이턴시 변화도 없이 시스템이 점진적으로 부정확해진다 [3].
새벽 2시에 원인을 특정한 뒤, 먼저 3개 망의 faq_vector_adjust_method가 전부 bge_m3로 설정되어 있는지 확인했다. 그다음 ES 인덱스를 1024차원으로 재생성. 그리고 문서 전체 재파싱: 캐피탈망 246건, 그룹사망 314건. 재파싱이 끝나면 RAG 검색 테스트, 마지막으로 tool_call 이슈가 재현되는지 확인하는 순서다.
단순해 보이지만 3개 폐쇄망에서 이걸 각각 돌려야 했다. 인덱스 재생성은 기존 데이터를 날리는 작업이니 롤백 없다. 재파싱에서 실패가 나면 수동 확인이 필요하다. 캐피탈망 1건, 그룹사망 1건 실패가 나왔고, 각각 개별 확인 후 처리했다.
같은 금융그룹 D사. 복수의 분리된 네트워크 환경에서 Qwen3 계열 모델을 에이전트에 연결했다.
망 A에는 235B, 망 B와 C에는 80B. 두 모델 모두 enable_thinking의 기본값이 True다. Reasoning 모델("사고 과정을 출력하는" 모드)이 켜진 채로 에이전트에 투입됐다.
문제는 이랬다. 대형 모델에서는 태그가 응답에 섞여 나왔다. 모델이 도구를 호출하려는 건데, thinking 토큰이 tool call JSON을 오염시킨 거다. 소형 모델에서는 더 심했다. 도구를 강제로 쓰게 하지 않으면 아예 쓰지 않았고, 강제하면 32K 토큰 내에서 한 번도 호출을 완료하지 못하고 토큰 리밋 에러가 떴다.
파서를 바꿔봤다. hermes에서 qwen3_xml로.
"파서가 을 파싱은 성공했지만, 파싱 결과가: {'name': '', 'args': {}, ...}"
파싱은 됐는데 내용이 비어 있었다.
여기서 하루를 더 쓴 뒤에야 근본 원인이 나왔다.
"모델이 불필요하게 retrieve → retrieve → get_pages 반복 → max_supervisor_tool_calls 도달 → tools = [] → bind_tools([], tool_choice='auto') → 모델이 빈 tool call 출력"
파서 문제가 아니었다. 에이전트 프레임워크의 백엔드 로직 문제였다. 모델이 도구 호출을 반복하다가 최대 횟수에 도달하면, 프레임워크가 도구 목록을 빈 배열로 비워버렸다. 도구 목록이 비었는데 tool_choice='auto'는 그대로. 모델은 이전에 봤던 tool call 양식을 흉내 내서 빈 값을 뱉었다. 로그에는 파서 에러가 찍혔지만, 진짜 범인은 파서 뒤에 있었다.
이건 Qwen만의 문제가 아니다.
- Qwen3: 멀티턴 도구 호출 성공률 47%. QwQ-32B(76%)에서 29%p 하락 [4]. - OpenAI o1/o3: reasoning 모델에서 도구 호출은 순차만 가능. 225 토큰 응답 중 64 토큰이 reasoning [5]. - Anthropic Extended Thinking: tool_use와 충돌, thinking 블록 유실 보고 [6].
사고하는 AI와 도구를 쓰는 AI는 아직 같은 설정으로 돌릴 수 없다. 해결 전에 프로덕션에 넣으면, 위에서 본 것처럼 된다.
80B에서도 동일 증상이 확인됐다. 모델을 바꿔서 될 문제가 아니었다. 방향은 hermes 파서를 유지하되 백엔드에 방어 로직을 추가하는 쪽으로 잡았다.
enable_thinking: false도 테스트했다. 단일턴에서는 tool call이 정상 동작했다. 멀티턴에서는 다시 실패했다. thinking을 끄는 것만으로는 해결이 안 됐다.
결국 프롬프트를 수정해서 불필요한 도구 호출 반복 자체를 억제하는 방향으로 갔다. 핵심은 파서를 고치는 게 아니라, 프레임워크가 max_supervisor_tool_calls 도달 시 도구 목록을 비우는 로직, 그 설계 자체를 손봐야 했다는 점이다. 파서 에러 로그만 쫓았으면 하루를 더 날렸을 거다.
122개 리플라이가 달린 Slack 스레드. 실시간 디버깅이 며칠간 이어졌다.
AI 에이전트의 검색 도구에서 scope 필터링 로직에 빈틈이 있었다. 검색 범위를 지정하지 않거나 "공유 문서"로 설정했을 때, 다른 사용자의 개인문서함 문서까지 검색 대상에 포함되는 이슈.
RAG 검색 결과에 다른 사람의 개인 문서가 섞여 나온 것이다. 멀티테넌트 환경에서.
직접 원인은 ES 필터의 설계 미비였다. 개인문서함 검색을 활성화하는 조건에서, 필터가 user_id 필드의 존재 여부만 확인했다. 특정 사용자의 user_id 값으로 제한하지 않았다. 결과: 모든 사용자의 개인문서가 검색 대상에 포함.
"특정 시점에서 master로부터 분기한 이후에, 일부 commit만 체리픽해서 브랜치를 구성하다보니 버그가 좀 쌓인거 같네요..."
master 브랜치에는 이미 scoping 메커니즘이 구현되어 있었다. 그런데 온프레미스 브랜치가 그 커밋 이전에 분기됐고, 체리픽 과정에서 scoping 로직이 빠졌다. feature flag 커밋이 개인문서함 검색을 True로 열어버렸는데, 그 검색을 제한하는 필터는 아직 도착하지 않은 상태.
이 버그의 진짜 무서운 점: 본인 문서로 테스트하면 정상이다.
개발자가 자기 계정으로 검색 테스트를 하면 자기 문서가 나온다. 다른 사용자 계정으로 교차 테스트를 해야만 발견된다. 그리고 대부분의 QA는 그렇게 하지 않는다.
OWASP LLM Top 10(2025)은 LLM08로 "Vector and Embedding Weaknesses"를 신설했다 [7]. OWASP가 정의한 4가지 공격 벡터(Embedding Inversion, Retrieval Manipulation, Access Control Bypass, Poisoned Embeddings) 중 세 번째가 정확히 이 사례다. 벡터 데이터베이스가 여러 사용자의 민감 문서 임베딩을 담고 있을 때, 적절한 격리 없이는 비인가 검색이 가능하다 [8].
멀티테넌트 RAG에서 접근 제어는 "검색"과 "권한"이 만나는 지점이다. LLM이 아무리 잘 답해도, 보여주면 안 되는 문서가 소스에 들어가면 소용없다.
exists 필터를 term 필터로, 개인문서 status 일괄 마이그레이션ES 필터부터 고쳤다. {"exists": {"field": "user_id"}}를 {"term": {"user_id": 특정유저ID}}로 바꿨다. user_id 필드가 "있기만 하면" 통과시키던 필터를, 해당 사용자의 ID와 정확히 일치해야 통과하도록 고쳤다.
upload v2 client.py도 문제였다. 개인문서(is_personal=True)를 업로드할 때 request body에 status=false를 포함하지 않는 버그가 있었다. 이것 때문에 개인문서가 공개 상태로 저장됐다.
이미 잘못 저장된 데이터도 손봐야 했다. MongoDB와 ES에서 own_user_id가 있는데 status=True인 문서를 전부 찾아 False로 변경했다. 마이그레이션 스크립트에는 DRY_RUN = True가 기본값으로 박혀 있었다. 먼저 dry_run으로 대상 건수를 확인하고, 리스트를 검토한 뒤에 실행 모드로 전환했다. 멀티테넌트 보안 버그의 데이터 마이그레이션에서 "일단 돌려보자"는 선택지가 아니다.
3개 온프레미스 고객사에서 동시에 올라온 이슈. 48개 리플라이.
"온프레미스 고객사들의 HWP → PDF 변환 지원을 나가면서 생기는 이슈들을 바탕으로 코드 정리 및 플러그인 기반의 아키텍처를 고안했습니다"
한국 공공문서의 91% 이상이 HWP 포맷이다 [9]. 1990년대부터 30년 넘게 축적된 문서가 전부 한글 파일이다. 공공기관 기안문 시스템 자체가 아래아한글로 만들어져 있으니, 시스템이 바뀌지 않는 한 HWP도 바뀌지 않는다.
문제는 글로벌 AI 벤더 대부분이 HWP를 지원하지 않는다는 점이다. OpenAI, Anthropic, Microsoft 전부. 2025년 12월 Google Gemini가 HWP 직접 지원을 시작한 게 거의 유일한 예외다 [10]. 한국 기업이 글로벌 AI 도구를 도입하려 할 때 부딪히는 첫 번째 벽이 여기다.
현장에서 터진 문제들은 더 구체적이었다.
한글에는 일반용과 서버용이 있다.
"한글 서버는 윈도우 서버에 설치되어 있고, 한글 일반용이 아니라 서버용입니다!"
서버 버전에서는 기존 변환 코드가 아예 동작하지 않았다. 그리고 일정이 기다려주지 않았다.
"해당부분이 해결되야 프로젝트 데이터를 업로드 할 수 있어서 일정이 엄청 넉넉한 편은 아닙니다!"
빈 문서가 생성되는 현상도 있었다. win32.gencache.EnsureDispatch로 한글 객체를 생성한 뒤, 프로그램이 완전히 로드되기 전에 후속 작업이 실행된 거다. 오류 메시지는 없었다. 변환은 "성공"했는데 결과물이 비어 있었다. silent failure의 전형이다. 핫픽스는 sleep(1). 한글 프로그램 초기화를 1초 기다려주는 것. 우아하지 않지만 현장에서 작동했다.
이런 이슈들이 고객사마다, 한글 버전마다, 폐쇄망 환경마다 다르게 터졌다. 팀은 플러그인 기반 아키텍처로 전환했다. document_plugins 패키지에 코어를 구현하고, /opt/hwp_plugins/ 아래에 한글 버전별 플러그인을 추가하는 구조다. main.py에 전부 때려넣던 방식에서 벗어났다. 로딩 시점에 설치된 한글 버전을 감지해서 맞는 플러그인을 물린다.
폐쇄망에서는 로그 반출도 쉽지 않다. 현장 엔지니어가 CLI 한 줄로 상태를 확인할 수 있어야 한다.
python cli.py hwp app-info # 현재 한글 버전 확인
python cli.py hwp version # 현재 사용 플러그인 확인
python cli.py hwp info ./xxx.hwp # 파일 버전, 페이지수
python cli.py printers list # 프린터 목록
python cli.py printers detect # 기본 프린터
Claude Code에 "한글 버전에 대해서 플러그인 추가해줘"라고 요청하면 /opt/hwp_plugins/에 해당 버전의 플러그인이 자동 생성되는 구조도 만들었다.
공공기관 문서의 91%가 HWP다. PDF와 DOCX만 지원하는 글로벌 벤더의 파이프라인으로는 한국 공공기관 고객에 들어갈 수 없다.
네 가지 사례의 공통점이 하나 있다. 로그는 정상이었다.
영역점검 질문이 글의 사례데이터 정합성임베딩 모델과 인덱스 차원이 일치하는가?1024→512 잘림모델-프레임워크 호환Thinking 모드가 tool call과 충돌하지 않는가?enable_thinking접근 제어멀티테넌트에서 사용자 격리가 작동하는가?scope 필터링 누락데이터 포맷타겟 시장의 문서 포맷을 커버하는가?HWP데이터 정합성은 벡터 차원만의 문제가 아니다. 임베딩 모델을 업데이트하면 기존 벡터와 신규 벡터 사이에 의미적 정렬이 틀어진다(Embedding Drift). 그리고 이건 앞으로 더 자주 터질 문제다. reasoning 모델이 보편화되면 tool call 충돌은 어떤 벤더를 쓰든 OpenAI, Anthropic, Qwen 할 것 없이 피할 수 없다. 아직 아직 정리가 안 됐다. 접근 제어가 특히 무섭다. 이 글에서 본 것처럼, 개발자가 자기 계정으로 테스트하면 정상이다. 발견 자체가 구조적으로 막혀 있다.
공통점: 에러가 나지 않는다. 결과만 조용히 나빠지거나, 보안이 조용히 뚫린다.
프로덕션 AI 에이전트 중 성숙한 모니터링을 갖춘 비율은 5%다 [11]. 대부분의 기업은 AI를 전통 소프트웨어와 같은 방식으로 모니터링한다. 가동률, 레이턴시, 에러율. 시스템이 돌아가고 있는지는 알 수 있다. 답이 맞는지는 알 수 없다 [12].
1. 임베딩 모델을 교체할 때, 벡터 인덱스 차원도 함께 업데이트하는 프로세스가 있는가? 모델만 바꾸고 인덱스를 안 바꾸면 로그에는 아무것도 안 찍힌다. 검색만 조용히 죽는다. (확인: GET /{index}/_mapping API로 현재 dense_vector 차원 조회 → 모델 출력 차원과 대조)
2. Reasoning 모델을 에이전트에 적용할 때, thinking 모드와 tool call의 호환성 테스트를 했는가? enable_thinking 하나로 도구 호출 전체가 무력화될 수 있다. 단일턴에서 성공해도 멀티턴에서 실패한다. (확인: 멀티턴 tool call 테스트 스위트. 3턴 이상 연속 도구 호출 시나리오로 재현)
3. 멀티테넌트 환경에서 다른 사용자 계정으로 검색 테스트를 했는가? 본인 문서로 테스트하면 정상이다. 접근 제어 버그는 교차 테스트에서만 드러난다. (확인: 테스트 계정 2개로 교차 검색 QA. A 계정 문서가 B 계정 검색 결과에 노출되는지 검증)
4. 한국 고객사의 HWP 비율을 파악하고 있는가? 공공기관이면 91% 이상이 HWP다. PDF/DOCX만 지원하는 파이프라인으로는 고객사의 핵심 문서에 접근조차 못 한다. (확인: 고객사 문서 포맷 비율 샘플링. 최근 업로드 100건 중 HWP/PDF/DOCX 비율 집계)
5. 인프라 전환 시 하드코딩된 타임아웃 값을 전수 확인했는가? (시리즈 1편에서 다룬 인프라 장애 사례) Redis standalone에서 Sentinel로 전환할 때, brpop_timeout=5(하드코딩)와 socket_timeout=2(Sentinel 설정)가 충돌해서 WebSocket이 끊겼다. 코드에 박힌 숫자 하나가 3개 망 전체를 흔들었다. 설정 파일과 코드베이스 전체를 grep으로 훑어야 한다. timeout, _timeout, TIMEOUT, 이 세 패턴이면 된다.
이 5가지 중 3개 이상에 "아니오"라면, AI 시스템이 지금 조용히 실패하고 있을 가능성이 있다. 문제는, 조용한 실패는 사용자가 불만을 제기하기 전까지 아무도 모른다는 거다.
1편 인프라, 2편 보안, 3편 GPU와 비용 문제를 거쳐 이번 편에서는 RAG와 에이전트의 품질을 다뤘다. 에러 없이 358건이 사라진 벡터, 사고하는 AI와 도구를 쓰는 AI의 충돌, 다른 사람의 문서가 조용히 섞여 들어온 검색 결과, 30년 된 HWP 파일과의 씨름.
엔터프라이즈 AI는 모델 성능만으로 결정되지 않는다.
Gartner는 GenAI 프로젝트의 30%가 PoC 이후 폐기될 것으로 전망했다 [13]. 배포 12개월 내 측정 가능한 모델 성능 저하를 보고한 기업이 67%다 [14]. 이 숫자가 맞다면, 지금 AI를 쓰는 기업 셋 중 둘은 조용히 성능이 떨어지고 있다. PoC는 통과한다. 문제는 그 다음이다.
모델이 아무리 똑똑해도 벡터 인덱스 차원이 잘못되면 검색이 죽고, GPU가 아무리 많아도 접근 제어가 빠지면 보안이 뚫린다.
올거나이즈 엔지니어링 팀이 이 시리즈를 쓴 이유는, 이런 질문들에 답할 수 있는 팀이 얼마 안 된다는 걸 현장에서 봤기 때문이다. PoC 너머의 운영에서 막혔다면, 현장을 아는 팀과 이야기하는 게 가장 빠른 길이다.
다음 편 예고 — RAG와 에이전트의 품질 문제는 결국 "도구가 제대로 돌아가나"를 전제한다. 하지만 도구를 20개 연결해놓고 에이전트가 실제로 쓴 건 2개뿐인 현장이 있다. 서브에이전트가 보낸 결과를 메인이 한 건도 못 받은 현장도 있다. 다음 글에서는 에이전트 워크플로우가 프로덕션에서 부딪히는 벽 — 타임아웃, I/O 포맷, 비결정성, 그리고 "어디까지 자동으로 할 것인가"를 다룬다.
"로그에 에러가 없을 때, 시스템이 정상이라고 확신할 수 있습니까?"
올거나이즈는 금융, 공공, 제조 등 다양한 산업에서 폐쇄망 AI 플랫폼을 구축하고 운영한 경험을 보유하고 있습니다. PoC부터 운영까지, 이 글에서 다룬 문제들을 함께 해결합니다.
→ 도입 상담 요청하기
(이 글의 사례들은 온프레미스 AI 구축 엔지니어링 팀의 운영 경험에서 추출했습니다. 고객사명과 담당자명은 모두 익명입니다.)
출처
[1] Analytics Vidhya, "Silent Killers of Production RAG," 2025.7 (Anupama Garani, PIMCO GenAI 리드) — 엔터프라이즈 RAG 프로젝트 80% 장애 경험 (보조 참고: 저자 업무 경험 기반 추정, 설문 결과 아님)
[2] RAG About It, "The Silent Failure Loop," 2025 — 임베딩 드리프트로 6개월 내 검색 정밀도 15~20%까지 하락할 수 있다는 보고 (보조 참고: 커뮤니티 분석, 학술 검증 미완료)
[3] Glen Rhodes, "Data Freshness Rot as the Silent Failure Mode in Production RAG Systems," 2025 — "에러 스파이크도, 레이턴시 변화도, 알림도 없이 점진적으로 부정확해진다" (보조 참고: 개인 분석)
[4] HuggingFace Discussion, Qwen/Qwen3-235B-A22B #20, 2025 — Qwen3 멀티턴 도구 호출 성공률 47% (QwQ-32B 76% 대비 29%p 하락) (커뮤니티 사용자 테스트, 수백 건 기준, 비공식)
[5] OpenAI, Reasoning Function Calls Cookbook + API Guide, 2025 — reasoning 모델 순차 실행 필수, reasoning 토큰 컨텍스트 소모 (1차 출처: OpenAI 공식 문서)
[6] GitHub Issue #678, openai/openai-agents-python — Anthropic Extended Thinking + tool_use 충돌 (thinking 블록 유실) (1차 출처: GitHub Issue)
[7] OWASP, Top 10 for Large Language Model Applications, 2025 — LLM08 "Vector and Embedding Weaknesses" 신설 (1차 출처: OWASP 공식)
[8] Pillar Security, "Strengthening LLM Security: Insights from OWASP's 2025 Top 10 List," 2025 — 벡터DB 멀티테넌트 격리 리스크 (보조 참고: OWASP 기반 해석)
[9] 위성곤 의원실, '공공분야 AI 활용 현황' 설문조사 (n=14,208, 전국 행정기관 종사자), 2025 국정감사 보도자료; ZDNet Korea 2025.10.13 보도 — 공무원 91.1%가 AI 비인식 포맷(HWP·이미지PDF) 사용 (1차 출처: 국정감사 자료)
[10] 바이라인네트워크, "HWP 읽는 구글 제미나이," 2025.12.9 + Google Gemini 공식 지원 포맷 목록 — Google Gemini HWP 인식 지원 (2025.12~) (1차 출처 병기)
[11] Cleanlab, 2025 Production Survey — 프로덕션 AI 에이전트 중 성숙한 모니터링 보유 5%
[12] Beam AI, "Silent Failure at Scale," 2025 — "대부분의 기업은 AI를 전통 소프트웨어와 같은 방식으로 모니터링한다 — 시스템이 돌아가고 있는지는 알 수 있다. 답이 맞는지는 알 수 없다" (보조 참고: 업계 보고서)
[13] Gartner, "30% of GenAI Projects Will Be Abandoned After PoC By End of 2025," Gartner Newsroom, 2024.7.29 (1차 출처: Gartner 공식)
[14] Beam AI, "Silent Failure at Scale," 2025 — 배포 12개월 내 측정 가능한 모델 성능 저하 보고 기업 67% (보조 참고: 업계 보고서)
