문서로서의 전략 — 제7장

제6장 — 코드가 아닌 문서로서의 전략

2023년 이후 RAG를 구축해 온 사람들의 이야기에서 가장 많이 반복되는 통찰에 도달했습니다. 바로 "첫날부터 이해하고 싶었던 것"입니다.

전통적인 프레임워크들은 검색 전략을 Python 코드로 취급합니다. 기술 카탈로그의 경우, 먼저 제품 코드로 검색하고, 다음으로 키워드로, 그다음으로 의미론적 벡터로 검색한 다음, 마지막에 답변을 생성하고 싶습니까? 함수를 작성합니다. 사진 앨범의 경우, 전통적인 의미론적 검색을 완전히 건너뛰고 이미지 전문 리랭커에 의존하고 싶습니까? 또 다른 함수를 작성합니다. 회사 비디오의 경우, 오디오와 시각적 트랙을 분리하고, 각각 전사하여 별도의 소스로 처리한 다음, 최종 답변에 다시 구성하고 싶습니까? 또 다른 함수입니다. 모든 유형의 콘텐츠, 모든 도메인, 모든 고객은 결국 다른 것들과 분기되는 코드 브랜치를 생성하게 되며, 전략을 수정하려면 소프트웨어 릴리스, 코드 검토, 테스트 주기, 배포가 필요합니다. "기술 매뉴얼 검색을 개선할 아이디어가 생겼다"와 "아이디어가 프로덕션에 있다" 사이의 시간은 몇 주 단위로 측정됩니다. 아이디어 하나하나마다 말입니다.

대안적인 통찰은 말하기에는 평범하지만 그 결과는 심오합니다. 탐색 전략은 코드가 아닙니다. 문서입니다. 모든 편집자가 30분 정도의 교육을 받으면 읽을 수 있는 구조화된 텍스트 형식인 JSON이 다음과 같이 말합니다. "먼저 이것을 시도한 다음 저것을 시도하고, 첫 번째가 실패하면 세 번째로 이동하고, 이렇게 재정렬하고, 이 모델로 응답하십시오." 이 문서는 저장소가 아닌 데이터베이스에 존재합니다. 풀 리퀘스트가 아닌 인터페이스에서 수정됩니다. 버전 관리되고, 복사되고, 도메인별로 특화됩니다. 기술 카탈로그를 위한 전략, 사진 앨범을 위한 전략, 설치 매뉴얼을 위한 전략, 비디오를 위한 전략, 오디오를 위한 전략, 법률 계약을 위한 전략, 재무제표를 위한 전략이 있습니다. 모두 동일한 시스템에서 공존합니다. 모두 실시간으로 수정할 수 있습니다.

이 접근 방식을 사용해 본 사람들은 이를 Meta-RAG라고 부르는데, 단순한 엔지니어링 이상의 속도 변화를 이야기합니다. "CMP40M 또는 RH1M과 같은 약어를 포함하는 제품 코드에 대한 특정 검색을 추가해주세요."와 같은 일반적인 고객 요청은 더 이상 2주짜리 개발 티켓이 아닙니다. 이는 스테이징 환경에서 즉시 테스트되고, 오후에 프로덕션으로 승격되는 JSON 프로시저에 추가되는 새로운 단계입니다. "사진에는 현재 텍스트에 사용되는 것과 다른 재랭커를 사용하면 어떻게 변경되나요?"라는 질문은 구성 한 줄을 수정하여 답변할 수 있습니다. 실험 비용은 들지 않고, 롤백 비용도 들지 않습니다(이전 문서 버전을 복원하기만 하면 되므로). 그리고 축적된 지식, 즉 특정 유형의 콘텐츠에 대해 무엇이 잘 작동하는지는 암묵적인 지식이 아니라 버전 관리되고 이전 가능한 자산이 됩니다. 특정 코드 브랜치를 작성한 사람이 휴가 중인 경우에도 말이죠.

흥미로운 사회적 효과도 있는데, 이 접근 방식을 채택하는 조직에서 나타납니다. 전략을 문서로 활용하면 "개발자"와 "숙련된 사용자"의 경계가 흐려집니다. 디지털 사서, 기업 아키비스트, 도메인 전문가 — 기술 사무소장, 문서 책임자, 고객의 진정한 질문을 누구보다 잘 아는 제품 관리자 — 는 전략을 읽고, 무엇을 하는지 이해하고, 변경 사항을 제안하고, 때로는 직접 작성할 수 있습니다. 개발 티켓 퍼널을 거칠 필요도 없고, 개발자가 알지 못하는 것을 설명할 필요도 없습니다(그것은 개발자의 직무 영역이 아니기 때문입니다). RAG는 소비하는 제품이 아니라 조직의 지식에 맞춰 모델링하는 도구가 됩니다. 이 점은 경험해 본 사람들의 증언에 따르면, 지표의 수치보다 먼저 프로젝트의 사기를 변화시킵니다.

마법도 아니고, 비용이 따르는 일입니다. 이러한 전략-문서(strategy-as-document)를 효율적이고 안전하게 실행할 엔진이 필요합니다. 실제 사례를 포괄할 만큼 풍부하면서도 또 다른 튜링 완전(Turing-complete)한 형태로 위장하지 않을 만큼 간결한 설명 언어가 필요합니다. 버전 관리, 테스트, 롤백 도구도 필요합니다. 하지만 이 모든 것은 엔진을 구축하는 사람의 문제이며, 한 번만 구축하면 모든 사용자가 활용할 수 있습니다. 최종 고객이 보는 것은 단 하나, 소프트웨어 릴리스 주기 속도가 아닌 생각의 속도로 검색 전략을 발전시킬 수 있다는 점입니다. 그리고 이것은 업계 잡지에서 아직 그 이름을 찾지 못한 조용한 혁명입니다.

마무리 — 7번째 장, 몇 달 후

2026년 초, 이전 장들의 교훈, 즉 손실되는 테이블, 거짓말하는 재정렬기, 상속된 환각, 가치보다 빠르게 증가하는 클라우드 요금, 유망하지만 경직된 프레임워크 등을 종합한 결과, 이탈리아에서 누군가가 다른 RAG 서버를 구축하기 시작했습니다. Python으로 작성되었으며, 접근 가능한 하드웨어에서 실행되도록 설계되었고, 필요할 때 클라우드 모델과 통신하고, 개인 정보 보호가 필요하거나 비용이 합리적이지 않을 때는 로컬 모델과 통신할 수 있습니다. 검색 전략이 수정 가능한 문서이고, 재정렬기는 GPU에서 로컬 프로세스이며, 테이블은 1급 시민으로 취급되어 손실되지 않고, 사진은 다른 시대의 낡은 아카이브에서 객체를 상속받지 않으며, 쿼리당 비용(금전 및 제3자에게 유출되는 데이터 모두)을 센트 단위까지 파악하고 제어할 수 있는 서버입니다.

프로젝트 이름을 밝히지는 않겠습니다. 지금이 그럴 시기가 아니고, 조사를 광고로 만들고 싶지 않습니다. 하지만 이전 장들이 여러분이 겪고 있는 상황을 인식하도록 만들었다면 — 잘못된 질문에 자신 있게 답변하는 기업용 챗봇, 몇 달째 이륙하지 못하는 RAG 프로젝트, 효용보다 빠르게 증가하는 클라우드 청구서, 여러분의 기밀 문서가 알 수 없는 곳으로 이동하고 있다는 점점 커지는 의심 — 그렇다면 다른 길이 있다는 것을 알아두는 것이 좋습니다. 이 길은 이탈리아에서 누군가가 걸어왔고, 2026년에 2023년에 기대했던 첫 번째 답변을 얻기 시작했습니다.

좋은 소식은 기업용 AI가 드디어 데모 단계를 벗어나고 있다는 것입니다. 좋지 않은 소식은 이 과정에서 모든 상처를 끌고 나온다는 것입니다. 부풀려진 프레임워크, 공급업체 의존성, 모놀리식 아키텍처, 더러운 데이터, 조용한 버그, 그리고 문제를 이해하기도 전에 솔루션을 판매하는 업계의 경향이 있습니다. 우리는 6개의 장에서 이 이야기를 들려드렸습니다. 7번째 장 — 누군가가 인내심을 가지고 이탈리아어로, 오픈 소스로 마침내 제대로 일을 해냈을 때의 이야기 — 는 곧 더 신중하지 않은 이름과 더 많은 숫자를 가지고 작성할 것입니다.

한편, 여기까지 읽어오셨다면 이미 현재 기업용 챗봇 계약을 체결하면서 이 장들을 읽으면서 스스로에게 던졌던 질문들을 전혀 하지 않은 의사 결정자들의 90%보다 훨씬 더 많은 자가 진단을 하신 것입니다. 이는 그들이 시작했던 것보다 더 나은 출발점입니다. 그리고 앞으로 몇 달 안에, 이러한 질문을 던진 사람과 던지지 않은 사람의 차이는 청구서와 고객에게 AI가 제공하는 답변에 매우 뚜렷하게 나타날 것입니다.

본 조사는 2024년 말부터 2026년 초까지 18개월간의 기업용 RAG 시스템 설계, 구축 및 최적화 경험을 바탕으로 2026년 4월에 작성되었습니다.