논문 요약: 구조화된 컨텍스트 엔지니어링을 위한 파일 네이티브 에이전트 시스템

제목: 구조화된 데이터에 대한 컨텍스트 엔지니어링 평가: 스키마 정확도, 포맷 효과성 및 대규모 다중 파일 탐색
저자: Damon McMillan (HxAI Australia)

이 논문은 대규모 언어 모델 (LLM) 에이전트가 외부 시스템 (예: 데이터베이스) 을 프로그래밍 방식으로 조작할 때, 에이전트가 소비하는 컨텍스트를 어떻게 구조화해야 하는지에 대한 실증적 지침을 제공합니다. 연구는 SQL 생성을 프로그램적 에이전트 작업의 대리 변수 (proxy) 로 사용하여, 11 개의 모델, 4 가지 포맷, 2 가지 아키텍처, 그리고 10 개에서 10,000 개의 테이블에 이르는 스키마 크기를 대상으로 9,649 회 실험을 수행했습니다.

1. 문제 정의 (Problem)

LLM 에이전트가 외부 시스템을 제어하는 능력이 향상됨에 따라, 에이전트가 시스템의 스키마, 관계, 제약 조건 및 의미론적 의미를 얼마나 잘 이해하느냐가 핵심 과제가 되었습니다. 기존 연구는 주로 프롬프트 엔지니어링이나 임베딩 기반 검색 (RAG) 에 집중했으나, 최근 개발자들은 에이전트가 grep 및 read 와 같은 네이티브 파일 도구를 통해 구조화된 문서 (YAML, JSON, Markdown 등) 를 직접 읽는 파일 네이티브 (File-Native) 아키텍처를 채택하는 추세입니다.

그러나 현재까지 파일 기반 컨텍스트 전달이 에이전트 성능에 미치는 영향, 파일 포맷의 효과, 그리고 대규모 스키마에서의 확장성에 대한 체계적인 실증 연구는 부족했습니다.

2. 방법론 (Methodology)

연구는 다음과 같은 실험 설계로 진행되었습니다.

• 실험 규모: 총 9,649 회 실험 (SQL 생성 정확도 8,401 회, 스키마 탐색 928 회, 엔터프라이즈 탐색 320 회).
• 평가 모델 (11 개):
  • 최상위 tier (Frontier): Claude Opus, GPT-5, Gemini Pro 등.
  • 최상위 실험실 tier (Frontier Lab): Claude Haiku, GPT-5 Mini, Gemini Flash 등.
  • 오픈 소스 tier: DeepSeek, Kimi, Llama, Qwen 등.
• 아키텍처 비교:
  1. 파일 에이전트 (File Agent): 에이전트가 필요 시 grep 과 read 도구를 사용하여 파일에서 스키마 정보를 검색.
  2. 프롬프트 베이스라인 (Prompt Baseline): 전체 스키마 (~6,000 토큰) 를 시스템 프롬프트에 직접 주입.
• 포맷 조건 (4 가지):
  • YAML: 계층적 구조, grep 친화적.
  • Markdown: 문서화 스타일, 자연어 포함.
  • JSON: 기계 파싱 가능, 다소 장황함.
  • TOON (Token-Oriented Object Notation): LLM 컨텍스트 효율성을 위해 설계된 자체 압축 포맷 (파일 크기 약 25% 감소).
• 데이터 및 복잡도: TPC-DS 벤치마크 기반 쿼리 사용. 복잡도 1 단계 (단순 조회) 에서 5 단계 (다중 단계 추론) 까지, 스키마 크기는 10 개에서 10,000 개 테이블까지 확장.
• 평가 지표: 생성된 SQL 결과와 정답 (Ground Truth) 간의 Jaccard 유사도 (0.9 이상을 성공으로 간주).

3. 주요 기여 및 발견 사항 (Key Contributions & Results)

R1: 아키텍처 선택은 모델에 의존적임 (Model-Dependent)

• 최상위 모델 (Frontier): 파일 네이티브 검색이 프롬프트 주입보다 정확도가 2.7% 높음 (p=0.029).
• 오픈 소스 모델: 전체적으로 파일 네이티브 방식이 정확도가 7.7% 낮음 (p<0.001). 특히 Qwen(-21.9%) 과 Llama Maverick(-13.9%) 에서 성능 저하가 두드러졌으나, Kimi 와 Llama Scout 는 차이가 미미함.
• 결론: 파일 기반 아키텍처는 최상위 모델에는 유리하지만, 오픈 소스 모델에서는 도구 사용 훈련 부족으로 인해 역효과가 날 수 있음.

R2: 포맷은 전체 정확도에 큰 영향을 미치지 않음

• 집계된 정확도 차이는 통계적으로 유의미하지 않음 (Chi-squared p=0.484).
• 단, 모델별 민감도 존재: 오픈 소스 모델은 포맷에 따라 정확도 편차가 큼 (Spread 9.8%20.1%). 반면 최상위 모델은 편차가 작음 (1.6%5.4%).
• 최적 포맷: YAML 이 5 개 모델에서 가장 좋았으며, Markdown 이 4 개 모델에서 우수함. TOON 은 어떤 모델에서도 최우선 선택이 되지 않음.

R3: 모델 능력 (Capability) 이 가장 중요한 요인

• 모델 간 성능 격차가 포맷이나 아키텍처 효과보다 훨씬 큼.
• 최상위 tier vs 오픈 소스 tier: 정확도 차이가 21%p에 달함.
• 복잡도가 높아질수록 (L5) 최상위 모델은 64% 정확도를 유지하는 반면, 오픈 소스 모델은 27% 로 급격히 하락.

R4: 대규모 스키마에서의 확장성

• 10,000 개 테이블: 도메인 기반 파티셔닝 (Domain-partitioned schemas) 을 사용하면 파일 네이티브 에이전트가 높은 탐색 정확도를 유지하며 확장 가능.
• 단일 파일 방식은 1,000 개 테이블까지 정확도가 유지되나, 파티셔닝을 통해 10,000 개까지 확장 가능.

R5: 효율성과 'Grep Tax' 현상

• 토큰 효율성: YAML 이 가장 효율적임. Markdown 은 grep 결과의 텍스트 양이 많아 토큰 소비가 60% 까지 증가.
• Grep Tax (그립 세금): TOON 과 같은 압축 포맷은 파일 크기는 작지만, 실제 실행 시 토큰 소비가 38% 더 많음.
  • 원인 1 (토큰 밀도): 압축 포맷은 한 줄에 더 많은 정보를 담고 있어 grep 결과 하나가 더 많은 토큰을 소모.
  • 원인 2 (패턴 불친숙): TOON 과 같은 커스텀 키워드는 모델 학습 데이터에 없어, 모델이 잘못된 패턴 (DDL, JSON 등) 을 반복 시도하며 토큰을 낭비함.
  • 이 현상은 모델 능력에 따라 달라지며, 오픈 소스 모델에서 더 심각하게 나타남.

4. 실무적 시사점 및 권장 사항 (Significance & Recommendations)

이 연구는 "만능 최적화"가 존재하지 않으며, 모델 능력에 맞춰 컨텍스트 엔지니어링 전략을 조정해야 함을 강조합니다.

1. 아키텍처 선택 가이드:
   • 최상위 (Frontier) 모델: 파일 에이전트 (File Agent) 사용 권장.
   • 오픈 소스 모델: 프롬프트 엔지니어링 (전체 스키마 주입) 이 더 안전하고 정확함.
2. 포맷 선택 가이드:
   • 토큰 효율성: YAML 추천.
   • 가독성: Markdown 추천.
   • 프로그램 생성: YAML 또는 JSON.
   • 커스텀 포맷 (TOON 등) 사용 시: grep 패턴에 대한 프롬프트 가이드를 제공하여 'Grep Tax'를 줄여야 함.
3. 확장성 전략:
   • 엔터프라이즈 규모 (수천~수만 개 테이블) 에서는 도메인별 파티셔닝을 적용하여 컨텍스트를 제한해야 함.
4. 핵심 통찰:
   • 포맷 최적화보다 모델 능력 (Tier) 향상이 성능에 더 큰 영향을 미침.
   • 파일 네이티브 에이전트는 최상위 모델과 함께 사용할 때 가장 효과적이며, 오픈 소스 모델에서는 도구 사용 능력 부족으로 인해 성능 저하가 발생할 수 있음.

결론

이 논문은 LLM 에이전트 시스템 설계에 있어 구조화된 컨텍스트 엔지니어링의 중요성을 실증적으로 규명했습니다. 특히 파일 기반 컨텍스트 전달이 모든 모델에 유리한 것이 아니며, 모델의 도구 사용 능력과 학습 데이터에 따른 포맷 친숙도가 성능을 결정짓는 핵심 변수임을 보여주었습니다. 향후 연구는 비-SQL 작업으로의 확장, 멀티턴 평가, 그리고 압축 포맷의 grep 효율성 최적화 등을 다룰 필요가 있습니다.