문서를 들려줘도 AI가 헤매는 이유

업무 문서를 대량으로 밀어 넣은 RAG만으로는 부족한 이유를 짚고, '검색'에서 '맥락 설계'로 넘어가는 흐름을 살펴봅니다.

사내 문서를 전부 긁어모아 챗봇에 연결한 팀이 있습니다. 규정집, 매뉴얼, 회의록, 위키까지 수만 건을 벡터로 만들어 넣었습니다. 시연은 그럴듯했습니다. 그런데 막상 실무자가 "지난 분기 A상품 환불 규정이 어떻게 바뀌었죠?"라고 물으면, 챗봇은 개정 전 문서를 근거로 자신 있게 틀린 답을 내놓습니다. 조금 더 캐물으면 관련 없는 부서의 지침을 섞어 반쪽짜리 답을 내밀기도 합니다. 문서는 분명히 다 넣었는데, 정작 필요한 순간에 헤맵니다.

이런 장면은 생각보다 흔합니다. 그리고 최근 업계의 화두는 조용히 옮겨가고 있습니다. 'RAG를 어떻게 더 잘 검색하게 만들까'에서, '컨텍스트 엔지니어링(Context Engineering)', 즉 모델에게 건네는 맥락 자체를 어떻게 설계할까로 무게중심이 이동하는 중입니다. 이번 글에서는 세 가지를 차례로 짚어 보겠습니다. 왜 문서를 많이 넣은 RAG만으로는 부족한지, 컨텍스트 엔지니어링이 무엇을 바꾸는지, 그리고 그 토대가 결국 무엇인지입니다.

그 많은 문서를 넣었는데, 왜 헤맬까요

먼저 RAG가 무엇인지 간단히 짚겠습니다. RAG는 검색증강생성(Retrieval-Augmented Generation)의 약자입니다. 사용자가 질문을 하면 의미가 비슷한 문서 조각을 미리 만들어 둔 데이터베이스에서 찾아옵니다. 그리고 그 조각들을 질문과 함께 프롬프트에 붙여 모델에게 건넵니다. 모델은 자기 머릿속 지식이 아니라 방금 건네받은 문서를 근거로 답을 만듭니다. 최신 정보와 사내 지식을 다루게 하는 표준적인 방식입니다.

그런데 여기에 널리 퍼진 통념 하나가 있습니다. "문서를 많이 넣을수록 AI가 똑똑해진다"는 믿음입니다. 과연 그럴까요? 오히려 반대인 경우가 적지 않습니다. 문서를 무작정 늘리면 성능이 떨어지기도 합니다.

이유는 검색 방식 자체에 있습니다. 유사도 검색은 '질문과 관련 있어 보이는' 조각을 가져올 뿐, '이 질문에 진짜 필요한' 조각을 보장하지 않습니다. 표현이 비슷하면 엉뚱한 문서도 상위에 올라옵니다. 문서가 많아질수록 이렇게 그럴듯한 오답 후보도 함께 늘어납니다. 게다가 서로 어긋나는 문서, 개정 전후가 뒤섞인 문서까지 한꺼번에 딸려 오면 모델은 무엇이 맞는지 판단할 근거가 없습니다. RAG를 운영해 보면 이 패턴은 거의 예외 없이 반복됩니다. 넣은 문서의 양과 답변의 정확도는 비례하지 않습니다.

문제는 검색이 아니라 '무엇을, 어떻게 담느냐'입니다

RAG가 헤매는 상황을 뜯어보면, 원인은 대체로 세 갈래로 나뉩니다.

• 엉뚱한 조각을 가져오는 경우입니다. 검색 품질의 문제입니다. 질문의 의도와 다른 문서가 상위로 올라옵니다.
• 맞는 조각인데 맥락이 잘린 경우입니다. 문서를 조각내는 청킹(chunking) 과정에서 문장이나 표가 중간에 끊깁니다. "이 항목은 아래 예외를 따른다"는 문장에서 정작 '아래 예외'가 다른 조각으로 떨어져 나갑니다.
• 조각은 맞지만 서로 관계나 최신성이 어긋나는 경우입니다. 개정 전 규정과 개정 후 규정이 나란히 들어오거나, 부서별로 다른 기준이 뒤섞입니다.

세 번째가 특히 까다롭습니다. 문서 안에는 답이 있는데, 그 답을 해석할 열쇠가 문서 밖에 있기 때문입니다. 가령 어떤 통계 테이블 명세서에 STAT_CD라는 코드값이 등장한다고 해 보겠습니다. 문서에는 "STAT_CD = 03인 건을 집계한다"고만 적혀 있습니다. 그런데 03이 '반품 완료'를 뜻하는지 '반품 요청'을 뜻하는지는 별도의 코드 정의서에 있습니다. 이 정의서를 함께 건네지 않으면, 모델은 코드값을 그대로 읊을 뿐 의미를 알지 못합니다. 조각 하나하나는 정확한데, 그 조각들을 잇는 관계가 빠진 셈입니다.

여기서 문제를 다시 정의할 필요가 있습니다. 지금까지 우리가 손본 것은 대부분 '검색 엔진'이었습니다. 임베딩 모델을 바꾸고, 청크 크기를 조정하고, 검색 개수를 늘렸습니다. 하지만 진짜 무대는 그 뒤에 있습니다. 검색으로 고른 조각들이 지시문, 대화 이력, 도구 설명과 함께 뒤섞여 모델에게 최종적으로 전달되는 컨텍스트 전체입니다. 문제는 검색이 아니라, 모델의 책상 위에 최종적으로 무엇을 어떻게 올려두느냐입니다.

컨텍스트 엔지니어링이란 무엇인가

컨텍스트 엔지니어링은 바로 이 지점을 다룹니다. 모델이 하나의 과제를 수행하는 그 순간, 컨텍스트 윈도우(모델이 한 번에 읽는 입력 공간)에 무엇을 넣을지 설계하고 조립하는 일입니다. 검색은 그 재료 중 하나일 뿐입니다.

컨텍스트에 담기는 재료는 대체로 다음과 같습니다.

• 지시: 모델의 역할과 과제, 지켜야 할 규칙
• 검색 지식: RAG로 가져온 문서 조각
• 도구와 함수: 모델이 호출할 수 있는 기능의 설명
• 작업 기억: 지금까지의 대화 이력과 중간 결과, 상태(state)
• 출력 형식: 답을 어떤 구조로 내놓아야 하는지

이 재료들을 상황에 맞게 고르고, 순서를 잡고, 불필요한 것을 덜어내 하나의 완결된 맥락으로 조립하는 일이 컨텍스트 엔지니어링입니다. RAG와 어떻게 다른지 표로 견주어 보겠습니다.

정리하면 이렇습니다. RAG는 컨텍스트 엔지니어링의 부분집합입니다. 컨텍스트를 채우는 여러 재료 중 '검색 지식'을 조달하는 방법이 RAG인 것입니다. 그러니 컨텍스트 엔지니어링은 RAG를 대체하는 개념이 아닙니다. RAG를 포함하면서, 그 위에 '무엇을 함께 담을지'라는 더 큰 질문을 얹는 관점입니다.

'많이'가 아니라 '알맞게' — 컨텍스트의 경제학

여기서 두 번째 통념을 짚어야 합니다. 컨텍스트 윈도우가 넓으니 일단 많이 채우면 좋지 않겠느냐는 생각입니다. 그렇지 않습니다. 컨텍스트는 공짜가 아닙니다.

우선 비용이 듭니다. 넣는 토큰이 많아질수록 요금이 오르고 응답도 느려집니다. 더 중요한 문제는 성능 자체입니다. 맥락이 길어지면 모델이 가운데에 묻힌 정보를 놓칩니다. 정작 핵심 문장을 넣어 두고도, 앞뒤로 쌓인 정보에 파묻혀 모델이 그것을 제대로 참고하지 못하는 것입니다.

그래서 컨텍스트 엔지니어링의 핵심 기술은 역설적으로 '덜어내는 기술'입니다. 긴 문서를 요약해 압축하고, 검색 결과를 다시 순위 매겨(re-ranking) 진짜 상위만 남기고, 상충하거나 오래된 조각을 걸러내고, 질문 유형에 따라 참고할 소스를 나누는 라우팅이 그것입니다. 무엇을 넣을까만큼이나 무엇을 빼야 하는가가 중요해집니다.

물론 모델이 한 번에 읽을 수 있는 창은 계속 커지고 있습니다. 하지만 창이 크다고 아무거나 채워 넣으면, 브리핑은 오히려 산만해집니다. 회의에 필요한 자료 세 장 대신 서류 뭉치 300장을 통째로 올려두는 셈입니다. 담당자는 그 안에서 다시 헤맵니다.

좋은 브리핑은 '관계'와 '규칙'을 함께 건넵니다

여기까지 오면 자연스러운 물음이 생깁니다. 알맞은 맥락을 조립하려면, 그 재료가 처음부터 잘 정리돼 있어야 하지 않을까요? 맞습니다. 좋은 브리핑은 흩어진 조각을 모은 것이 아니라, 의미와 관계가 이어진 형태여야 합니다.

앞서 본 STAT_CD 예시로 돌아가 보겠습니다. 코드값이 무엇을 뜻하는지, 이 테이블이 어느 업무에서 어떻게 쓰이는지, 지금 보는 문서가 최신본인지를 함께 건네야 모델이 제대로 일합니다. 이런 정보를 데이터 곁에 붙여 두는 것이 메타데이터(데이터에 관한 데이터)이고, 어떤 데이터가 어디서 흘러와 어디로 가는지를 추적하는 것이 데이터 리니지(lineage)입니다.

관계를 다루는 데는 다른 도구가 필요합니다. "이 고객과 거래한 협력사 중 규제 대상과 연결된 곳"처럼 여러 단계를 타고 넘어야 답이 나오는 질문은, 문서 조각을 아무리 잘 검색해도 이어지지 않습니다. 이럴 때 쓰는 것이 그래프DB와 온톨로지입니다. 그래프DB는 데이터를 점과 선, 즉 개체와 개체 사이의 관계로 저장합니다. 온톨로지(ontology)는 그 개체와 관계가 무엇을 의미하는지 정의한 일종의 개념 사전입니다. 둘을 함께 쓰면, 흩어진 사실을 '관계'로 이어 답할 수 있습니다.

정리하면, 좋은 컨텍스트의 재료는 세 가지를 갖춰야 합니다. 조각의 의미(이 값이 무엇인지), 조각 사이의 관계(무엇과 이어지는지), 그리고 지켜야 할 규칙(어느 것이 최신이고 유효한지)입니다. 이것을 모아서 '데이터 맥락 지도'라고 부릅니다. 데이터가 무엇이고 서로 어떻게 연결되는지를 담은 지도입니다. 브리핑을 매번 사람이 손으로 짤 수는 없습니다. 자동으로 잘 짜려면, 이 지도가 먼저 그려져 있어야 합니다. 지도가 있어야 어느 자료를 골라 어떤 배경과 함께 올려둘지를 기계가 판단할 수 있습니다.

그래서 무엇을 점검해야 할까요

관점을 실무로 옮겨 보겠습니다. 지금 운영 중인 RAG가 '창고 열쇠'만 쥐여주고 있는지, '잘 짜인 브리핑'을 건네고 있는지 점검하는 다섯 가지 항목입니다.

1. 최신성 표시가 있는가. 검색 대상 문서에 개정일과 유효 기간, 버전이 메타데이터로 붙어 있는지 확인합니다. 없다면 모델은 개정 전 문서를 최신처럼 다룹니다.
2. 청킹이 의미 단위를 자르지 않는가. 표와 조건문이 중간에 끊기지 않는지, 조각만 떼어 읽어도 맥락이 통하는지 살펴봅니다.
3. 코드값과 약어의 의미가 함께 실리는가. STAT_CD 같은 값이 검색될 때 그 정의도 함께 컨텍스트에 들어가는지 점검합니다.
4. 상충·중복을 걸러내는 장치가 있는가. 재순위와 필터를 두어 어긋나는 문서와 낡은 조각을 덜어냅니다.
5. 관계형 질문에 답할 경로가 있는가. 여러 단계를 타고 넘어야 하는 질문에는 문서 검색만으로 부족합니다. 그래프나 온톨로지 경로를 마련했는지 확인합니다.

다섯 항목 모두 문서를 더 넣는 일이 아닙니다. 담긴 맥락을 다듬고 이어 주는 일입니다. 이 점검만으로도 답변 품질이 눈에 띄게 달라집니다.

브리핑의 질이 곧 AI의 질입니다

처음의 장면으로 돌아가 보겠습니다. 문서를 다 넣었는데도 챗봇이 헤맸던 이유는, 문서의 양이 부족해서가 아니었습니다. 모델에게 건네진 컨텍스트가 설계되지 않았기 때문입니다. 관련 있어 보이는 조각만 잔뜩 쥐여줬을 뿐, 무엇이 최신이고 어떤 코드가 무엇을 뜻하며 어느 규정이 유효한지는 함께 건네지 못했습니다. 그래서 RAG를 더 잘 검색하게 만드는 일에서, 모델의 책상 위 맥락 전체를 설계하는 컨텍스트 엔지니어링으로 초점이 옮겨가는 것입니다.

그러니 지금 우리 AI에게 '창고 열쇠'만 주고 있는지, 아니면 안건에 맞춰 필요한 자료와 배경, 주의사항까지 정리한 '잘 짜인 브리핑'을 건네고 있는지부터 점검해 보시길 권합니다. AI에게 무엇을 더 넣을지가 아니라, 무엇을 어떻게 담아 건넬지를 고민할 때입니다. 브리핑의 질이 곧 AI의 질입니다.