여섯 개의 폴을 가진 엔진 — 열 줄의 코드 신화

챗봇이 계속해서 지어내는 이유와 2026년 초에 누군가 시작한 다른 방향에 대한 6부 연재 심층 취재.

챗봇이 계속해서 지어내는 이유와 2026년 초에 누군가 시작한 다른 방향에 대한 6부 연재 심층 취재.

서론 — 여덟 개의 폴을 가진 엔진 (하지만 여섯 개였다)

2026년 3월, 밀라노. 한 관리자가 사내 챗봇을 열어본다. 이 챗봇은 IT 부서에서 큰 기대와 약간의 불신 속에서 "2주 만에" 만들어낸 것이다. 아주 간단한 질문을 던진다: "CMP40M 엔진은 폴이 몇 개입니까?". 챗봇은 대규모 언어 모델이 보여줄 수 있는 모든 자신감으로 대답한다: "CMP40M 엔진은 폴이 여덟 개입니다."

틀렸습니다. 6개입니다. 정답은 몇 달 전에 누군가가 벡터 데이터베이스에 최대한 신뢰하며 쏟아부었던 422페이지 카탈로그에는 없었습니다. 시스템이 "모든 것을 알게 될 것"이라고 믿었던 거죠. 그 데이터는 카탈로그에 전혀 없었습니다. SEW 기술자들의 이메일에 첨부된 PDF 파일에 있었고, 아무도 인덱싱할 생각을 하지 않은 폴더에 보관되어 있었습니다.

이러한 상황은 산업 및 방언의 차이는 있지만 수백 개의 이탈리아 사무실에서 반복됩니다. 약속은 간단하고 매혹적이었습니다. 기업의 모든 문서를 AI 어시스턴트에 제공하면 그에 대한 모든 질문에 답변할 수 있습니다. 현실은 훨씬 더 평범합니다. 챗봇은 읽지만 이해하지 못하고, 찾지만 찾지 못하며, 찾지 못하면 — 솔직하게 말하는 대신 — 지어냅니다. 유창하게, 완벽한 문법으로, 그럴듯한 숫자로 지어냅니다. 이는 답변하지 않는 것보다 훨씬 더 나쁩니다.

2024년 말부터 2026년 초까지 우리는 이러한 실패의 부검을 위해 몇 달을 보냈습니다. 논쟁을 조장하기 위해서가 아니라, 한 가지를 이해하기 위해서였습니다. 왜 그렇게 선형적인 아이디어 — "문서를 주고 질문하면 답을 얻을 수 있다" — 데모 무대를 벗어나 실제 서버 룸에 들어오면 그렇게 어려워지는 걸까요.

이 6부작 심층 기사는 우리가 발견한 내용을 담고 있습니다. 전체 카탈로그를 삭제하는 조용한 버그, 잘못된 점수를 가진 클라우드 재정렬기, 모델이 아닌 수년 전에 오염된 데이터에서 비롯된 환각, 모든 쿼리를 그 가치보다 비싸게 만드는 외발 청구서, 그리고 너무 많은 것을 요구하지 않는 한 10줄의 코드로 모든 것을 약속하는 "인기 있는" 프레임워크입니다. 그리고 마지막 장에서는 누군가가 2026 초에 조용히 시작한 다른 방향 — 검색 전략이 코드를 멈추고 회사 내 모든 사람이 읽고 수정할 수 있는 문서가 되는 아키텍처 — 를 다룹니다.

각 장은 독립적으로 읽을 수 있습니다. 342개의 테이블이 사라진 이야기나 거짓 재정렬기 이야기부터 시작하셔도 좋습니다. 하지만 전체 이야기는 마지막에 드러나는 교훈을 가지고 있습니다. 기업용 RAG — 즉, 검색 증강 생성을 의미하는 기술 약어, 즉 "먼저 검색한 문서를 기반으로 응답 생성" — 은 아직 완성된 제품이 아닙니다. 그것은 개척지입니다. 그리고 모든 개척지와 마찬가지로 지금까지는 주로 판매자가 이야기했습니다. 그 안에서 살아온 사람들의 이야기도 들어볼 때입니다.

제1장 — 10줄의 코드라는 신화

2023년부터 모든 AI 컨퍼런스에서 동일한 슬라이드가 등장합니다. "10줄의 코드로 귀사의 문서 지원 비서를 만드세요." 제목 아래에는 파스텔 색상의 Python 블록이 있는데, 이는 일반적으로 유명한 미국 오픈 소스 라이브러리(이름이 나무 사슬이나 티베트 라마를 연상시키는)로 PDF를 로드하고, 분할하고, 벡터 데이터베이스에 붙여넣고, 언어 모델로 쿼리합니다. 5분 만에 챗봇을 만들 수 있습니다. 5분 만에 박수를 받습니다. 5분 만에 이탈리아 중소기업은 문제가 해결되었다고 확신하고 IT 부서가 2주 안에 해낼 수 있다고 믿게 됩니다.

문제는 — 슬라이드가 말하지 않는 것 — 데모는 잘 구성된 PDF 세 개, 내용과 일치하도록 맞춤 제작된 질문, 실제 지연이 없는 무대, 그리고 발표자가 발표하기 전에 스무일곱 번 테스트한 것으로 구축되었다는 것입니다. 현실에서 기업 문서는 지질학적 재앙입니다. 스캔의 스캔, 텍스트 위에 겹쳐진 표, 단락에 끼어드는 각주, 청커가 단어로 생각하여 중간에 자르는 "RH1M"과 같은 영숫자 코드, 유용한 정보의 70%를 포함하지만 아무도 실제로 추출하지 않는 이미지, 그리고 파서를 넘어 고고학자를 필요로 하는 창의적인 레이아웃이 있습니다.

RAG — 이는 작동 원리입니다 — 훌륭한 아이디어입니다. 사용자 질문을 받아, 저장소에서 가장 관련성 높은 문서를 검색하여 언어 모델에 전달하고, 해당 문서에 기반한 답변을 받도록 하는 것입니다. 이론적으로는 환각 문제를 우아하게 해결합니다. 모델이 더 이상 답변을 "알" 필요가 없고, 단순히 제공된 조각에서 "읽기"만 하면 됩니다. 하지만 실제로는 체인의 모든 연결 고리 — 청킹, 임베딩, 검색, 재정렬, 최종 생성 — 가 고장날 수 있으며, 고장은 눈에 보이는 오류로 나타나지 않는 경우가 많습니다. 약간 잘못된 답변으로 나타납니다. 그리고 완전히 잘못된 답변으로 나타납니다. 그리고는 시스템이 인턴보다 지식이 부족한 이유를 궁금해하는 관리자로 나타납니다.

RAG를 대중화시킨 오픈 소스 프레임워크는 생산을 위한 것이 아니라 데모를 위한 것입니다. 각 레이어가 암묵적인 가정을 숨기는 우아한 추상화의 연결입니다. 즉, PDF에 괜찮은 OCR이 적용되어 있고, 사진은 이미 설명되어 있으며, 테이블은 규칙을 따르고, 임베딩 모델이 실제로 사용자의 언어를 이해하며(스포일러: 많은 모델이 영어만 잘합니다), 아카이브가 이미 중복 항목으로 정리되어 있다는 가정입니다. 이러한 가정 중 하나라도 깨지면(그리고 적어도 하나는 항상 깨지고, 거의 항상 세 개나 깨집니다) 시스템이 작동을 멈추는 것이 아닙니다. 더 나쁜 것은 시스템이 제대로 작동하지 않지만 계속해서 응답을 제공한다는 것입니다. 유창하고, 확신에 차 있으며, 종종 진실과는 동떨어진 응답입니다.

이 시스템을 직업적으로 구축하는 사람들 사이에서 떠도는 말과 튜토리얼에서는 절대 찾아볼 수 없는 문장이 있습니다. “RAG는 쉽게 만들 수 있지만, 제대로 만드는 것은 어렵습니다.” 첫 번째 데모와 프로덕션 서비스 사이에는 GPU를 추가하거나 모델을 변경해서는 채울 수 없는 심연이 있습니다. 불편한 진실을 이해함으로써 채울 수 있습니다. 기업용 RAG를 구축할 때는 코드를 작성하는 것이 아니라, 모든 편집적 선택을 포함하여 문서에 맞춤화된 작고 끈질긴 검색 엔진을 설계하는 것입니다. 무엇이 노이즈이고 무엇이 신호인지, 무엇을 두 번 인덱싱해야 하고 무엇을 버려야 하는지 말입니다. 튜토리얼의 열 줄 안에는 이러한 선택이 한 번만, 여러분의 문서를 본 적이 없는 누군가에 의해 대신 내려집니다. 그리고 거의 항상 여러분의 경우에 잘못된 선택입니다.