길게 넣기, 그때그때 찾기, 자료 모양별 도구
작은 자료는 통째로 넣고, 긴 문맥의 한계를 알고, 에이전트와 MCP로 원본을 직접 읽으며, 표와 스캔과 말투는 다른 도구로 다루는 법.
On This Page
세 번째 흐름은 ‘미리 쪼개 저장한다’는 전제 자체를 버립니다. 자료가 작으면 통째로 넣고, 크면 에이전트가 필요한 만큼만 찾아 읽습니다. 어느 쪽이든 ‘모델에게 무엇을 보여 줄지’를 고르는 문제는 사라지지 않습니다.
작으면 그냥 다 넣기
앤트로픽은 지식 자료가 20만 토큰, 약 500쪽 미만이면 검색 시스템을 만들지 말고 전체를 프롬프트에 넣으라고 했습니다. 프롬프트 캐싱을 쓰면 반복 질문의 대기 시간은 절반 이하로, 비용은 최대 90%까지 줄어든다고 합니다.
학계에서는 이를 캐시 증강 생성(CAG)으로 정리했습니다. 관련 문서를 문맥에 미리 올려 두고 내부 계산을 캐시하면 검색 지연과 검색 오류가 사라집니다. 자료가 제한적일 때 기본 검색과 같거나 더 나은 결과가 보고됐습니다. 상용 API에서는 프롬프트 캐싱이 사실상 같은 역할입니다. 단점은 자료가 바뀔 때마다 캐시를 다시 만들고, 첫 요청 비용이 크다는 점입니다.
길수록 흐려집니다
크로마가 2025년 7월 발표한 문맥 부패 연구는 18개 최신 모델 모두가 입력이 길어질수록 성능이 떨어진다고 보였습니다. 숨은 문장 찾기 같은 단순 시험에서는 거의 만점이지만, 비슷하지만 틀린 방해 정보가 섞이거나 의미를 이해해야 하면 길이에 따라 정확도가 내려갑니다.
긴 문맥 중간에 묻힌 정보를 놓치는 중간 소실도 예전부터 알려져 있습니다. 앤트로픽은 이를 주의력 예산으로 설명합니다. 넣을 수 있다는 것과 잘 쓴다는 것은 다릅니다. 계약서 한 건을 통째로 분석하는 일에는 긴 문맥이 최적이지만, 대규모 지식 자료의 상시 대체재는 아닙니다.
저장해 두지 않고 그때그때 읽기
클로드 코드를 만든 보리스 체르니는 초기 판본의 벡터 저장소를 빼고, 에이전트가 파일 이름, 내용 검색, 파일 읽기로 필요할 때 찾아오는 편이 더 잘 되고 더 단순하며 보안·최신성 문제도 적었다고 밝혔습니다. 핵심 문서는 처음부터 문맥에 넣고, 나머지는 가벼운 참조만 들고 있다가 도구로 불러옵니다. 폴더 구조와 파일 이름, 수정 시각 자체가 ‘어디를 볼지’의 신호입니다.
대가도 있습니다. 실행 중 탐색은 미리 계산된 검색보다 느립니다. 안내가 부실하면 에이전트가 막다른 길을 헤매며 문맥을 낭비합니다. 같은 탐색을 매번 반복합니다. 한 발표의 예시에서는 매번 내용을 뒤져 읽는 데 약 6,300토큰이 든 반면, 저장된 조각 검색은 약 420토큰이었습니다. 예시일 뿐 통제된 시험 결과는 아닙니다.
그래서 업계가 모이는 지점은 ‘검색 대 에이전트’가 아닙니다. 에이전트가 키워드 검색, 의미 검색, 내용 검색, 데이터베이스 질의를 도구로 골라 쓰며 반복 탐색하는 구조입니다.
- 자기 점검형(Self-RAG). 검색이 필요한지 스스로 판단하고, 답을 쓰면서 근거를 점검합니다.
- 교정형(CRAG). 찾은 결과가 부실하면 질문을 바꿔 다시 찾거나 웹 검색으로 대체합니다.
- 에이전트형. 질문을 쪼개고, 자료원마다 다른 저장소를 골라 여러 차례 찾다가 충분하면 멈춥니다.
호출이 늘어 답이 늦어지고 비용이 커지며, 멈추는 조건이 없으면 무한 반복에 빠집니다. 쉬운 질문은 고정 흐름으로, 어려운 질문만 에이전트 길로 보내는 적응형 분기가 균형점입니다.
원본에 직접 연결하기
모델 컨텍스트 프로토콜(MCP)은 모델이 외부 시스템과 연결하는 공통 규약입니다. 드라이브, 고객 관리, 사내 데이터베이스, 노션을 도구로 열면 자료를 복사하지 않고 원본을 조회합니다. 항상 최신이고, 원본의 권한을 그대로 쓸 수 있습니다. 반대로 원본의 검색 품질과 호출 제한에 묶입니다. 자주 묻는 핵심 자료는 별도 저장소나 위키로 두고, 나머지는 직접 연결하는 혼합이 현실적입니다.
자료 모양이 다르면 도구도 다릅니다
| 자료·요구 | 맞는 접근 | 왜 | 주의 |
|---|---|---|---|
| 발표 자료, 스캔, 도표 | 페이지를 그림으로 찾는 ColPali 계열 | 글자 추출 단계에서 정보가 사라지는 문제를 건너뜀 | 쪽마다 벡터가 많아 저장이 큼 |
| 매출, 건수, 기간 합계 | Text-to-SQL | 검색은 세기와 합하기를 못 함 | 읽기 전용 계정, 지표 정의, 질의 검증 |
| 사람·조직·계약 | 직접 넣은 그래프 + 그래프 질의 | 관계가 이미 명확하면 뽑아 내는 것보다 정확 | 구조 설계와 동기화 비용 |
| 문체, 형식, 분류 기준 | 미세 조정 또는 예시 중심 지시 | 방식은 학습이 효과적 | 사실 주입에는 부적합 |
| 사용자 선호, 진행 중 작업 | 파일 기반 에이전트 메모리 | 대화를 넘어 상태를 유지 | 무엇을 저장하고 언제 지울지 규칙 필요 |
ColPali(2024, ICLR 2025)는 문서 쪽 전체를 그림으로 보고 그 의미로 찾습니다. 시각 문서 시험에서 글자 기반 흐름을 크게 앞섰습니다. 문서가 적으면 멀티모달 모델에게 쪽 그림을 직접 건네는 편이 더 단순할 수 있습니다.
가격, 재고, 일정, 합계는 조각으로 쪼개는 순간 정확도를 잃습니다. ‘지난달 지역별 매출 합계’는 SQL입니다. 읽기 전용 계정, ‘매출’의 정의를 적어 둔 층, 실행 전 질의 검증이 필요합니다.
미세 조정의 역할은 한 문장입니다. 검색은 지식을 주고, 미세 조정은 행동을 다듬으며, 긴 문맥은 작업 기억입니다. 형식, 말투, 분류 기준, 분야 특유의 판단 습관에는 이깁니다. 매주 바뀌는 사실을 외우게 하면 고칠 수 없고, 출처를 댈 수 없고, 사람별 권한을 걸 수 없습니다. 실무 조합은 대개 검색(사실) + 시스템 지시(정책) + 필요할 때만 가벼운 LoRA입니다.
본격적으로 만들 때는 최소한 이 개념을 나눠 보관합니다.
| 담는 것 | 꼭 둘 정보 |
|---|---|
| 문서 | 번호, 원본 주소, 판본, 내용 지문, 소유자 |
| 절 | 번호, 속한 문서, 제목 경로, 쪽 범위 |
| 조각 | 번호, 속한 절, 원문, 문맥 설명, 임베딩 |
| 사실·주장 | 번호, 주어, 관계, 목적어, 원문 위치 |
| 대상 | 번호, 대표 이름, 다른 표기, 종류 |
| 관계 | 출발, 도착, 종류, 근거 번호 |
| 위키 페이지 | 주제 번호, 요약, 근거 주장, 검토 상태 |
공통으로 조직 구분, 접근 정책, 만든 시각, 유효 시작·종료, 사용한 모델 판본, 추출 방식의 판본이 붙습니다. 그래프에서는 관계의 출처와 유효 시점이 특히 중요합니다.