1만 개 테이블도 길 잃지 않게: 파일 네이티브 에이전트 컨텍스트 엔지니어링
“LLM에게 스키마를 넣었는데 SQL이 엉망이에요.” 이 말, 데이터 팀이라면 한 번쯤 해보셨을 겁니다. 문제는 스키마가 길어서가 아니라, 에이전트가 ‘필요한 조각을 찾아 읽고, 확인하고, 고치고’ 하는 방식으로 컨텍스트를 다뤄야 하는데 그 설계가 허술한 경우가 많다는 점입니다.
최근 연구는 최대 10,000개 테이블 규모의 SQL 스키마를 다양한 포맷으로 제공하면서, 어떤 컨텍스트 구성 방식이 SQL 생성 성능과 비용(토큰/반복 횟수)에 영향을 주는지 9,649회에 걸쳐 비교했습니다1. 결론은 의외로 단순합니다. 포맷 싸움보다 “모델 선택 + 파일 기반 탐색 설계”가 더 큽니다. 그리고 토큰을 아끼려다 오히려 토큰을 더 쓰는 함정도 있습니다2.
구조화된 컨텍스트 엔지니어링이 왜 갑자기 중요해졌나
예전 프롬프트 엔지니어링은 “한 번에 잘 말하기”가 핵심이었습니다. 그런데 엔터프라이즈 데이터 환경은 스키마가 파일로 흩어져 있고, 테이블 수가 수천 개를 넘어가며, 용어도 팀마다 다릅니다. 이때 필요한 건 한 방의 프롬프트가 아니라, 에이전트가 컨텍스트를 ‘운영’하도록 만드는 컨텍스트 엔지니어링입니다.
그래프/메타데이터 관점에서도 업계는 같은 방향으로 움직입니다. 프롬프트를 예쁘게 다듬는 것보다, 데이터 카탈로그·관계·요약 같은 “컨텍스트 자산”을 만들고, 검색과 검증 루프를 설계하는 게 성능을 좌우한다는 이야기죠3.
실험이 보여준 진짜 변수: “포맷”보다 “모델”
이 연구는 SQL 생성 과제를 에이전트형 작업의 대리 지표로 두고, 11개 모델과 4개 포맷(YAML/Markdown/JSON/TOON)을 비교했습니다. 스키마 규모도 10개 테이블부터 10,000개까지 늘리며, 컨텍스트가 커질 때 어디서 막히는지 확인했죠1.
여기서 가장 큰 차이는 포맷이 아니라 모델에서 났습니다. 상위 상용 모델 계열이 전반적으로 더 안정적으로 맞는 테이블을 찾고, 관계를 해석하고, 틀리면 다시 고치는 “에이전트스러운 행동”을 잘 했다는 해석이 가능합니다1.
실무적으로는 이 한 줄로 요약됩니다. “우리 스키마 포맷을 뭘로 바꿀까?”를 고민하기 전에, “이 작업을 끝까지 해내는 모델이 뭔가?”를 먼저 봐야 합니다.
파일시스템 기반 retrieval: 잘 되는 모델은 더 잘 된다
대규모 스키마를 한 덩어리로 프롬프트에 밀어 넣는 건 현실적으로도 비효율적이고, 운영 면에서도 유지보수가 지옥이 됩니다. 그래서 요즘 에이전트 설계는 “파일을 탐색해서 필요한 것만 읽기”로 갑니다.
연구에서도 파일시스템 기반 컨텍스트 탐색(필요한 파일/조각을 찾아 읽는 방식)이 특히 상위 모델에서 유의미한 도움을 줬습니다1. 반면 오픈소스 모델은 같은 조건에서 개선 폭이 작거나 일관성이 약했습니다1.
이 차이가 무서운 이유는, 제품 환경에서 에이전트는 보통 이런 루프를 돌기 때문입니다. “스키마 파일 찾기 → 관련 부분만 읽기 → SQL 만들기 → 실행/검증 → 수정”. 모델이 이 루프를 안정적으로 수행하지 못하면, 포맷을 아무리 정리해도 결과가 출렁입니다. (터미널/에이전트 벤치마크에서 상위권이 특정 대형 모델에 몰리는 현상과도 결이 비슷합니다.)2
TOON의 함정: 토큰 절약이 ‘재확인 비용’을 부른다
TOON(Token-Oriented Object Notation)은 구조화 데이터를 더 짧은 토큰으로 표현해 비용을 아끼자는 아이디어에 가깝습니다. 직관적으로는 “짧으면 싸다”인데, 실험에서는 반대의 장면이 나왔습니다. 모델이 포맷에 익숙하지 않으면 내용을 다시 확인하고, 해석을 반복하면서 오히려 토큰을 더 쓰는 경우가 생겼습니다1. 연구는 이를 ‘grep tax’ 같은 비유로 설명합니다. 압축된 표기는 한눈에 읽기 어렵고, 결국 모델이 몇 번이고 훑어보며 확인하느라 비용이 늘어난다는 뜻이죠1.
이 지점에서 실무 KPI도 바뀌어야 합니다. 목표를 “최소 토큰”으로 두면 TOON 같은 선택이 매력적으로 보이지만, 실제 목표는 “최소 재시도(최소 반복 루프)”인 경우가 많습니다. 총비용은 토큰 수가 아니라, 실패로 인한 왕복 횟수에서 터질 때가 많거든요. TOON과 JSON 같은 포맷 비교 논의가 활발한 것도 같은 맥락입니다4.
1만 테이블 환경에서 바로 써먹는 설계 체크리스트
첫째, 모델을 먼저 고르세요. 대형 스키마 + 에이전트 루프는 단순 추론 테스트가 아니라, 탐색·선별·검증을 포함한 종합전이라서 모델 격차가 크게 납니다1.
둘째, “스키마 전체 주입” 대신 “파일 네이티브 탐색”을 기본값으로 두세요. 스키마를 도메인/서비스 단위로 쪼개 파일로 관리하고, 에이전트가 인덱스를 보고 해당 파일만 열게 하세요. 이 방식은 특히 상위 모델에서 효과가 뚜렷했습니다1.
셋째, 포맷은 ‘표준 + 디버깅 쉬움’이 우선입니다. YAML/JSON/Markdown처럼 사람도 바로 읽을 수 있는 형태는 디버깅이 쉽고, 모델도 대체로 친숙합니다. YAML은 사람 친화적 데이터 직렬화 포맷으로 널리 쓰이는 것도 장점입니다5.
넷째, 오픈소스 모델을 쓰면 보강재를 넣으세요. 스키마 인덱스(테이블 한 줄 요약), 관계 요약, 대표 쿼리 패턴, 자동 검증 규칙(실행 결과로 컬럼 존재/조인 키 확인)을 함께 제공하면 “길을 잃는 문제”를 줄일 수 있습니다. 구조화 출력/구조 이해 능력을 따로 측정하는 연구들이 나오는 것도, 이런 약점을 시스템으로 메워야 하기 때문입니다6.
시사점 내용 (핵심 포인트 정리 + 개인적인 생각 또는 실용적 조언)...
컨텍스트 엔지니어링은 이제 “프롬프트를 잘 쓰는 기술”이 아니라 “에이전트가 파일과 메타데이터를 다루는 운영 설계”에 가깝습니다. 이번 비교가 던지는 메시지도 명확합니다. 포맷 최적화는 마지막 20%고, 처음 80%는 모델과 탐색 방식입니다1.
팀에서 당장 할 수 있는 가장 현실적인 출발점은 이겁니다. 스키마를 한 덩어리로 넣고 결과를 탓하는 대신, 파일 단위로 쪼개고(관리 가능하게), 인덱스를 만들고(찾을 수 있게), 검증 루프를 붙이세요(틀리면 자동으로 고치게). 그리고 “토큰 절약”보다 “재시도 절약”을 비용 목표로 삼아보세요. 그 순간부터 1만 테이블도 ‘공포의 미로’가 아니라 ‘검색 가능한 지도’가 됩니다.
참고
1[2602.05447] Structured Context Engineering for File-Native Agentic Systems: Evaluating Schema Accuracy, Format Effectiveness, and Multi-File Navigation at Scale](https://arxiv.org/abs/2602.05447)
2파일 네이티브 에이전트형 시스템을 위한 구조화된 컨텍스트 엔지니어링
3Why AI Teams Are Moving From Prompt Engineering to Context Engineering - Graph Database & Analytics
6StructEval: Benchmarking LLMs’ Capabilities to Generate Structural Outputs