AX란 무엇인가 (2)
AX 여정기 (2) : RAG의 환상 너머, GIGO와의 정면승부
가장 먼저 ‘거버넌스와 가드레일’이라는 튼튼한 검집을 만들고 나니(1편 참고), 조직의 시선은 자연스럽게 다음 혁신의 궤도로 향했다. 그 방아쇠를 당긴 것은 사내 최초로 고객 접점인 AICC(인공지능 컨택센터)에 적용한 RAG(검색 증강 생성, Retrieval-Augmented Generation) 기반 챗봇의 등장이었다.
LLM의 고질적인 환각(Hallucination) 현상을 잠재우고, 복잡한 사내 규정과 매뉴얼을 바탕으로 척척 대답해 내는 첫 사례가 안착하자 그 파급력은 상상을 초월했다. 순식간에 사내에는 'RAG 유행'이 일어났다. 전사의 수많은 본부와 현장 지점들이 앞다투어 "우리 부서만의 고유한 지식을 대답해 주는 전용 챗봇을 만들어 달라"며 기대감을 쏟아내기 시작한 것이다.
1. 빗발치는 제안서 속 서늘한 진실 : 파편화된 RAG의 저주
사내 수요가 폭발하자, 당연히 수많은 IT 벤더사들이 화려한 아키텍처 다이어그램과 제안서를 들고 문을 두드렸다. 그들은 당장이라도 우리 회사의 수만 장 짜리 낡고 복잡한 규정집들을 AI가 완벽히 소화해 낼 수 있다고 호언장담했다. 하지만 나는 매사를 지독할 정도로 계획적으로 접근하고, 겉으로 보이는 현상보다 구조의 밑바닥을 뜯어보는 것을 선호하는 사람이다. 산더미처럼 쌓인 제안서들을 검토하며, 나는 등골이 서늘해지는 끔찍한 위화감을 느꼈다.
그들의 제안에는 한 가지 소름 돋는 공통점이 있었다. 'AI'라는 마법의 단어 포장지 안에 무조건 비싼 고급 검색 엔진(Vector DB)과 복잡하고 정교한 파싱(Parsing) 기술만을 앵무새처럼 강조할 뿐이었다. 정작 비즈니스를 근본적으로 바꾸는 ‘원본 문서 자체의 체질 개선’과 조직이 일하는 방식을 혁신하는 ‘비즈니스 AX(AI Transformation) 변화관리’에 대해서는 그 누구도 입을 열지 않았다.
엔터프라이즈 리더의 눈에는 재앙에 가까운 미래가 선명하게 그려졌다. 만약 각 부서가 업체들의 제안에 휘둘려, 본질(원본 문서)은 방치한 채 제각각의 스타일과 비표준화된 양식으로 파편화된 RAG를 덜컥 구축하도록 내버려 둔다면 어떻게 될까?
각 부서의 문서 양식이 조금만 바뀌어도 파싱 룰을 땜질식으로 수정해야 하고, 결국 챗봇 하나당 매년 수억 원에 달하는 막대한 운영 및 유지보수 비용이 전사적인 청구서로 날아올 것이 뻔했다. 게다가 하루가 다르게 더 가볍고 뛰어난 글로벌 범용 솔루션이 쏟아지는 지금의 기술 속도를 감안할 때, 특정 벤더와 무거운 아키텍처에 얽매인 레거시 시스템을 훗날 걷어내고 교체하려면 또다시 천문학적인 매몰 비용과 전환 비용을 치러야만 한다. 이것은 혁신이 아니라 거대한 '기술 부채'의 늪으로 걸어 들어가는 짓이었다.
2. PoC의 기만 : 아무도 ‘진짜 길’을 건드리지 않는다
결국 지속 가능한 AX를 위해서는, 업체의 화려한 기술 시연에 취할 것이 아니라 컴퓨터 공학의 가장 오래되고 냉혹한 절대 원칙, GIGO(Garbage In, Garbage Out, 쓰레기를 넣으면 쓰레기가 나온다)와 정면승부를 벌여야만 했다.
업체들이 수십 번의 RAG PoC(개념 증명)를 하면서도 굳이 원본 문서를 건드리지 않고 복잡한 IT 기술로 땜질하려 했던 이유는 명백하다. 수십 년간 부서마다 제각각 만들어온 화려한 2단 레이아웃, 기하학적으로 얽힌 병합 표, 텍스트 대신 캡처해서 붙여 넣은 이미지들. 이 파편화된 문서를 "AI가 읽기 좋게 현업에서 직접 다 뜯어고치세요"라고 비즈니스 부서에 요구하는 순간, 거센 저항에 부딪히고 프로젝트는 피곤해지기 때문이다.
그래서 쓸데없이 GIGO의 뇌관을 건드리기 싫은 사람들은 본질을 외면한 채, 엉망진창인 쓰레기 데이터를 억지로 기계의 입에 쑤셔 넣기 위해 시스템만 기형적으로 고도화시킨다. 계속 문서를 땜질식으로 파싱하고 매번 룰을 바꾸다 보니, 결국 사람은 지치고 시스템에는 아무런 표준 규칙도 남지 않는 소모전이 반복된다.
3. 기계는 소박하다 : 오버 엔지니어링의 저주
사람들은 AI가 복잡한 문맥과 기형적인 표를 찰떡같이 이해해 주길 기대하며 대단히 정교한 규칙이 필요할 것이라 지레 겁을 먹는다. 하지만 기계는 그렇게 복잡함을 요구하지 않는다.
AI가 원하는 것은 그저 위에서 아래로 흐르는 일관된 구조, 1단계로 정돈된 리스트, 그리고 ‘셀 병합이 없는’ 단순화된 표일 뿐이다. (최근 멀티모달 기술의 발전으로 표 안의 이미지 인식 등도 점점 해결되는 추세지만, 뼈대가 되는 문서의 정규화는 여전히 타협할 수 없는 0순위 과제다.) 사람들은 이 단순한 ‘사내 문서 규칙’을 정의하는 것을 두려워한다. 그 도피처로 OpenSearch 같은 무거운 검색 엔진에 기대거나, HyDE, Query Rewriting(질의 재작성), Hybrid Search(어휘+의미 검색), Reranking(재정렬) 등 고도화된 2차, 3차 가공 기법들을 잔뜩 이어 붙인다.
단언컨대, 문서가 깨끗하게 정제되어 있다면 저런 복잡한 기법 없이도 RAG의 성능은 사실상 어느 정도 무조건 보장된다. 화려한 파이프라인보다, 해당 기업만의 전문 용어나 사내 약어 등의 동의어/유의어 사전(Dictionary) 정도만 충실히 관리해 주는 것이 훨씬 강력하고 비용 효율적인 무기다.
오히려 시스템에 너무 많은 기술적 개입(기교)이 들어가면 치명적인 부작용이 발생한다. 훗날 반드시 적용해야 할 ‘Human-in-the-loop(인간 개입)’ 체계에서 오류 추적을 불가능하게 만든다는 점이다. 질의가 내부적으로 여러 번 변형되고 재조합되면, 오답이 나왔을 때 도대체 어디서부터 꼬인 것인지 원인을 찾을 길이 없어진다. 화려한 복잡성은 결국 시스템의 통제권 상실을 의미한다.
4. 블랙박스를 해체하는 관리자의 나침반
수많은 챗봇을 비용 효율적으로 관리해야 하는 RAG 비즈 어드민(관리자) 입장에서는 속을 알 수 없는 벤더사의 블랙박스보다, [질문/답변/참고문서]를 직관적으로 대조하며 "왜 문제가 발생했는가?"에 대한 명확한 가이드가 있는 편이 차라리 좋다.
나는 사내 RAG 오류의 원인을 다음 8가지로 직관적으로 구조화했다.
Lack of Data : 검색 결과로 인한 데이터 부족은 정확한 답변을 어렵게 함
Data Quality : 부정확하거나 최신화되지 않은 데이터는 챗봇의 잘못된 응답을 유발함
Invalid Data : 병합된 표나 깨진 양식 등 비정상적인 데이터는 부적절한 답변을 초래함
Technical Issue : 시스템 오류 등 기술적 문제로 인해 정확한 답변이 어려울 수 있음
Basic Knowledge Conflict : 지식 충돌이 일관성 없는 답변을 유발할 수 있음
Model Performance : 모델 성능 저하는 답변의 질을 낮출 수 있음
Search Engine Problems : 검색 엔진의 동의어, 유의어 처리 문제는 오답을 발생시킬 수 있음
Input Question Quality : 불명확한 질문은 정확한 답을 도출하기 어렵게 함
에러가 났을 때 IT 부서나 벤더사에 "수억 원짜리 검색 엔진 좀 고쳐주세요"라고 모호하게 의존하는 것이 아니다. 위 기준표를 보고 원인을 분류하면, 문제의 80% 이상이 결국 모델이나 엔진이 아니라 '데이터 자체의 결함(1~3번)'에 있음이 투명하게 드러난다. 이것이 복잡한 기술에 종속되지 않고 주도권을 쥐는 진짜 '운영'이다.
5. 역발상의 변화관리 : AI의 밥상은 AI가 차리게 하라
그렇다면 어떻게 그 수많은 현업 부서가 이 귀찮고 고통스러운 GIGO의 본질(문서 정제)을 스스로 건드리게 할 것인가? 단순히 "앞으로 모든 사내 문서는 이 엄격한 룰에 맞춰 직접 클렌징하세요"라고 지시하는 것은 변화관리의 완벽한 실패 공식이다.
진짜 도움을 줄 수 있는 리더의 묘수는 비즈니스에 노동을 강요하는 것이 아니라, "AI에게 줄 먹이를 정제하기 위해, 역으로 AI를 도구로 쥐여주는 것"이다. 나는 사내 문서 표준 룰(단일 레이아웃, 셀 병합 금지 등)을 명확히 세워두고, 비즈니스 부서에 이 룰이 완벽히 프롬프팅 된 맞춤형 AI 클렌징 툴(OpenAI의 myGPT나 Google Gemini의 Gems 레벨)을 제공했다. 현업 담당자가 기존의 엉망인 공지사항이나 복잡한 매뉴얼을 이 툴에 대충 던져 넣으면, 1차적으로 AI가 사내 RAG 표준 양식에 맞춰 문서를 싹 재구조화해 준다. 사람은 그저 마지막으로 내용의 왜곡이 없는지만 확인하는 '클렌징 효율화 프로세스'만 거치면 된다.
여기서 얻을 수 있는 통찰이 있다. "새로운 시대의 코딩은 바로 '좋은 문서 작성'이다." 인간은 최종 승인자(Reviewer)로만 남고 귀찮은 정규화 노동은 AI가 대신할 때, 직원들의 피로도 없이 사내 전체 문서가 비로소 표준화된다. 더 놀라운 것은, AI가 읽기 좋게 문서를 정규화하는 훈련을 하다 보면 역설적으로 사람 간의 모호한 업무 지시와 커뮤니케이션 오해까지 완벽하게 사라진다는 점이다.
6. 자동 평가의 환상과 ‘진짜’ 평가 시스템의 조건
마지막으로 짚고 넘어가야 할 것은 RAG 시스템의 '정확도 평가(Evaluation)'에 대한 맹점이다. 최근 Ragas나 LangSmith 같은 자동화된 RAG 평가 툴이 유행처럼 번지며, 이것으로 모든 걸 해결하려 든다. 하지만 나는 단호하게 이를 경계했다.
이러한 자동 평가 툴의 본질은 결국 'LLM의 답변을 또 다른 LLM이 채점하는 것'에 불과하다. 치밀하고 복잡한 사내 규정이 존재하거나 현장 상담원들이 깐깐하게 고객을 응대하는 엔터프라이즈 환경에서, 기계가 매긴 "정확도 95%"라는 숫자는 현실 세계의 체감 지표와 끔찍할 정도의 괴리를 가진다. 따라서 초기 시스템의 기준선을 잡는 평가는 언제나 해당 도메인의 최고 전문가가 직접 땀 흘려 검수한 'Golden Dataset(정답 데이터셋)'을 기반으로 이루어져야 한다.
그리고 런타임 이후 운영에서 발생하는 수많은 불확실성에 대해서는, 앞서 언급한 '자체 관리자 평가 시스템'을 비즈니스 로직 깊숙이 박아 넣어 ‘Human-in-the-loop’가 숨 쉬듯 자연스럽게 따라올 수 있도록 아키텍처를 구축해야 한다. 기계가 초안을 내고, 사람이 8가지 에러 원인을 분류하며 교정하고, 그 피드백이 다시 문서 원본을 똑똑하게 만드는 선순환 궤도를 그리는 것. 이것이 비싼 검색 엔진 교체나 벤더 종속 없이도 성능을 영속적으로 우상향 시키는 유일한 정답이다.
맺음말 : 화려한 스포츠카를 사기 전에, 아스팔트부터 깔아라
AX 여정의 두 번째 단계를 지나며 나는 확신하게 되었다. RAG 시스템은 요술 지팡이가 아니다. 그것은 우리 조직이 가진 지식과 데이터의 민낯을 그대로 비추는 '가장 투명하고 냉혹한 거울'이다.
각 부서의 파편화된 요구사항과 벤더사의 화려한 기술 제안에 휘둘려 챗봇을 난립시키는 것은, 결국 거대한 기술 부채와 천문학적인 매몰 비용을 낳는 지름길이다. 향후 등장할 혁신적인 글로벌 범용 AI 솔루션을 가볍고 유연하게 갈아 끼우기 위해서라도, 기업이 단단하게 쥐고 있어야 할 가장 강력한 무기는 복잡한 파이프라인이 아니라 '정규화된 표준 데이터'다.
AI라는 화려하고 강력한 스포츠카를 사기 위해 거액을 쓰는 기업은 많지만, 그 차가 달릴 험준한 비포장도로를 평평한 아스팔트로 포장하는 지루한 작업에 기꺼이 땀방울을 흘리는 기업은 드물다. 도로가 엉망이면 아무리 비싼 차도 제 속도를 낼 수 없고, 부서마다 제각기 다른 모양의 험로를 깐다면 훗날 찻길을 다시 내는 데 회사의 기둥이 뽑힌다. 복잡한 검색 기술로 쓰레기(Garbage)를 포장하려 하지 마라. 대신 단호하게 규칙을 세우고, AI의 도움을 받아 본질적인 데이터의 체급을 올려라. 표의 병합을 풀고, 문서의 레이아웃을 단순화하고, 에러 원인을 명확히 분석하여 매일 피드백을 남기는 일.
가장 볼품없고 투박해 보이는 이 '기본기'야말로, 무한정 증식하는 운영비의 늪을 막아내고 거대 조직을 진정한 AI 시대로 이끄는 가장 파괴적인 혁신이다.