AI 에이전트에게 엑셀 파일을 주고 “3월 매출을 찾아줘”라고 하면 어떻게 될까요? 대부분의 에이전트는 파일을 열어 모든 내용을 텍스트로 변환한 뒤 답을 찾으려 합니다. 그런데 이 과정에서 표 구조, 셀 위치, 시트 정보 같은 핵심 정보가 사라지죠. 마치 건물 설계도를 글자로만 설명하려는 것과 비슷합니다.

HxAI Australia의 Damon McMillan이 이 문제를 해결하는 새로운 접근법을 제안했습니다. 논문 제목은 “Structured Context Engineering for File-Native Agentic Systems”. 핵심은 간단합니다. 파일을 텍스트로 바꾸지 말고 원본 형태로 유지하되, LLM에게는 “어떤 파일인지” 설명하는 메타데이터만 제공하는 거죠. 이 방식으로 Claude Sonnet 3.5의 파일 작업 성공률을 33%에서 95%로 끌어올렸습니다.
출처: Structured Context Engineering for File-Native Agentic Systems – arXiv
기존 방식의 근본적 한계
대부분의 AI 에이전트는 “텍스트 우선” 접근을 사용합니다. 파일을 받으면 내용을 통째로 텍스트로 변환해 LLM 컨텍스트에 넣는 거죠. 엑셀이든 PDF든 JSON이든 모두 긴 텍스트 덩어리가 됩니다.
문제는 이 과정에서 파일의 구조가 무너진다는 겁니다. 엑셀의 경우 셀 A3, B5 같은 좌표 정보가 사라지고, 여러 시트가 하나로 뭉개지며, 수식이나 서식은 아예 증발합니다. JSON 파일도 마찬가지죠. 중첩된 객체 구조가 평면 텍스트로 펼쳐지면서 계층 관계를 파악하기 어려워집니다.
연구팀이 측정한 결과, Claude Sonnet 3.5에게 엑셀 파일을 텍스트로 변환해 제공했을 때 성공률은 33%에 불과했습니다. 간단한 “A열의 합계를 구해줘” 같은 작업도 자주 실패했죠.
파일 네이티브 접근: 구조화된 컨텍스트
연구팀의 해결책은 역발상에서 시작합니다. 파일 내용을 LLM에게 직접 보여주지 말자는 거죠. 대신 이런 식으로 작동합니다.
1단계: 메타데이터 추출
파일에서 구조 정보만 뽑아냅니다. 엑셀이라면 “Sheet1에 100행 5열, 헤더는 날짜/제품/수량/금액/고객”, JSON이라면 “최상위 배열 50개, 각 객체는 id/name/address 필드 포함” 같은 식이죠.
2단계: 구조화된 컨텍스트 생성
이 메타데이터를 LLM이 이해하기 쉬운 구조화된 형태로 제공합니다. 예를 들어 엑셀 파일이라면 “sales.xlsx는 3개 시트 포함. Sheet1: 날짜(A열), 제품명(B열), 수량(C열), 금액(D열). 총 500행” 같은 식이죠. 실제 셀 값은 빼고 구조만 설명하는 겁니다. 전체 내용이 아니라 “지도”만 주는 거예요.
3단계: 도구를 통한 접근
LLM은 실제 데이터가 필요할 때만 특정 도구를 호출합니다. “Sheet1의 A1:C10 범위 읽기” 또는 “JSON의 users 배열 필터링” 같은 식으로요. 파일은 원본 형태로 유지되고, 에이전트는 필요한 부분만 정확하게 꺼내 씁니다.
이 방식의 핵심은 “선택적 접근”입니다. 1만 행짜리 엑셀 파일 전체를 컨텍스트에 쑤셔넣는 대신, LLM은 메타데이터를 보고 “아, 3월 데이터는 D열에 있고 50-80행 사이구나”라고 파악한 뒤 그 부분만 가져옵니다.
95% 성공률과 실전 검증
연구팀은 FileGym이라는 벤치마크로 성능을 측정했습니다. 엑셀, JSON, PDF 같은 실제 파일들로 300개 작업을 테스트한 결과:
- 기존 방식 (텍스트 변환): 33% 성공률
- 파일 네이티브 방식: 95% 성공률
3배 가까운 개선입니다. 특히 복잡한 작업일수록 차이가 극명했죠. “여러 시트에서 조건부 합계” 같은 작업은 기존 방식으로는 거의 불가능했지만, 파일 네이티브 방식은 90% 이상 성공했습니다.
비용 측면에서도 이점이 있습니다. 전체 파일을 컨텍스트에 넣지 않으니 토큰 사용량이 줄어들고, 필요한 부분만 접근하니 처리 속도도 빨라집니다. 연구팀 측정으로는 평균 응답 시간이 40% 단축됐습니다.
컨텍스트 설계의 새로운 기준
이 연구가 시사하는 건 단순히 “파일 처리를 잘하자”가 아닙니다. LLM에게 무엇을 어떻게 제공할지에 대한 근본적 질문이죠.
지금까지는 “더 많은 정보를 컨텍스트에”가 정답처럼 여겨졌습니다. 긴 컨텍스트 윈도우가 경쟁 포인트가 된 이유죠. 하지만 이 연구는 정반대를 보여줍니다. 때로는 덜 주는 게 더 나을 수 있다고요.
특히 구조화된 데이터를 다룰 때 이 원칙이 빛을 발합니다. 데이터베이스 쿼리, API 응답 처리, 로그 분석 같은 작업들이 모두 여기 해당하죠. 전체를 텍스트로 덤핑하는 대신, 스키마나 메타데이터를 제공하고 필요시 선택적으로 접근하게 만드는 겁니다.
연구팀은 논문에서 여러 파일 형식별 최적 메타데이터 구조도 제안합니다. 엑셀은 시트 정보와 헤더, JSON은 스키마와 깊이, PDF는 섹션 구조와 페이지 레이아웃 같은 식이죠. 자세한 내용은 원문을 참고하세요.
참고자료:

답글 남기기