에이전트가 컨텍스트 엔지니어링을 위해 파일시스템을 사용하는 방법
TMThttps://blog.langchain.com/how-agents-can-use-filesystems-for-context-engineering/
딥 에이전트의 핵심 기능은 파일시스템 도구 세트에 대한 접근입니다. 딥 에이전트는 파일시스템에서 파일을 읽고, 쓰고, 편집하고, 나열하고, 검색할 수 있습니다.
이 글에서는 에이전트에게 파일시스템이 왜 중요한지 살펴보겠습니다. 파일시스템이 어떻게 도움이 되는지 이해하려면, 오늘날 에이전트가 어디에서 부족할 수 있는지부터 생각해봐야 합니다. 에이전트는 (a) 모델 성능이 충분하지 않거나, (b) 올바른 컨텍스트에 접근하지 못할 때 실패합니다. 컨텍스트 엔지니어링은 “다음 단계에 꼭 필요한 정보만을 컨텍스트 윈도우에 정교하게 채워 넣는 기술과 과학”입니다. 컨텍스트 엔지니어링—그리고 그것이 어떻게 실패할 수 있는지—을 이해하는 것은 신뢰할 수 있는 에이전트를 구축하는 데 매우 중요합니다.
컨텍스트 엔지니어링의 관점
현대의 에이전트 엔지니어의 일을 컨텍스트 엔지니어링의 렌즈로 볼 수 있습니다. 에이전트는 일반적으로 많은 컨텍스트(모든 지원 문서, 모든 코드 파일 등)에 접근할 수 있습니다. 들어오는 질문에 답하기 위해, 에이전트는 필요로 하는 중요한 컨텍스트(질문에 답하는 데 필요한 컨텍스트를 포함)를 갖습니다. 질문에 답하려는 과정에서, 에이전트는 컨텍스트 윈도우에 끌어오기 위해 컨텍스트 일부를 검색하여 가져옵니다.
이 관점으로 보면, 에이전트의 컨텍스트 엔지니어링이 “실패”할 수 있는 많은 방식이 존재합니다:
- 에이전트가 필요로 하는 컨텍스트가 전체 컨텍스트에 없다면, 에이전트는 성공할 수 없습니다. 예: 고객 지원 에이전트가 특정 문서 페이지에 접근해야 하지만 그 페이지가 인덱싱되어 있지 않은 경우.
- 에이전트가 검색하여 가져오는 컨텍스트가 필요로 하는 컨텍스트를 포함하지 못한다면, 에이전트는 올바르게 답할 수 없습니다. 예: 고객 지원 에이전트가 특정 문서 페이지에 접근해야 하는데, 그 페이지가 존재하고 인덱싱되어 있지만 에이전트가 검색하여 가져오지 못한 경우.
- 에이전트가 검색하여 가져오는 컨텍스트가 필요로 하는 컨텍스트보다 훨씬 크다면, 에이전트는 시간과 토큰(혹은 둘 다)을 낭비하고 있는 것입니다. 예: 고객 지원 에이전트가 단 하나의 특정 페이지만 필요로 하는데, 100개의 페이지를 가져오는 경우.
에이전트 엔지니어로서 우리의 일은 **빨간색을 초록색에 맞추는 것(에이전트가 가져오는 컨텍스트가, 필요한 정보의 가능한 한 작은 상위집합이 되도록 보장하는 것)**입니다.
적절한 컨텍스트를 고립시키려 할 때 몇 가지 구체적인 과제가 발생합니다
- 너무 많은 토큰(가져온 컨텍스트 >> 필요한 컨텍스트) 일부 도구(예: 웹 검색)는 많은 토큰을 반환할 수 있습니다. 몇 번의 웹 검색만으로도 대화 기록에 수만 토큰이 빠르게 쌓일 수 있습니다. 결국 성가신 400 bad request 오류를 마주할 수 있지만, 그보다 훨씬 이전에 LLM 비용이 급증하고 성능이 저하됩니다.
- 많은 양의 컨텍스트가 필요(필요한 컨텍스트 > 지원되는 컨텍스트 윈도우) 때로는 에이전트가 질문에 답하기 위해 실제로 많은 정보를 필요로 할 수 있습니다. 이 정보는 일반적으로 단일 검색 쿼리로 반환될 수 없기에, 많은 이들이 “에이전틱 서치”—에이전트가 검색 도구를 반복적으로 호출하도록 하는 접근—로 기울었습니다. 문제는 컨텍스트의 양이 빠르게 증가하여 에이전트의 컨텍스트 윈도우에 모두 담을 수 없는 지점에 도달한다는 것입니다.
- 좁은 영역의 정보 찾기(가져온 컨텍스트 ≠ 필요한 컨텍스트) 에이전트가 입력을 처리하기 위해 수백 또는 수천 개의 파일 속에 묻혀 있는 니치한(좁은 영역) 정보를 참조해야 할 수 있습니다. 에이전트가 그 정보를 신뢰성 있게 어떻게 찾을 수 있을까요? 찾지 못한다면, 검색하여 가져온 컨텍스트는 질문에 답하는 데 필요한 것이 아닐 것입니다. 시맨틱 검색의 대안(또는 보완책)이 있을까요?
- 시간에 따른 학습(전체 컨텍스트 ≠ 필요한 컨텍스트) 때로는 에이전트가 질문에 답하기 위해 필요한 컨텍스트에 접근하지 못할 수 있습니다(도구나 지시사항에 없기 때문). 최종 사용자는 종종 에이전트와의 상호작용에서(암시적으로나 명시적으로) 그 컨텍스트가 무엇인지에 대한 단서를 제공합니다. 에이전트가 그 컨텍스트를 향후 반복을 위해 추가할 수 있는 방법이 있을까요?
이들은 모두 흔한 장애물이며, 대부분의 우리는 이전에 다양한 변주를 경험했을 것입니다!
파일시스템이 어떻게 에이전트를 더 좋게 만들 수 있을까?
가장 단순하게 말해: 파일시스템은 에이전트가 무한한 양의 컨텍스트를 유연하게 저장, 검색, 업데이트할 수 있는 단일 인터페이스를 제공합니다.
위에 나열한 각 시나리오에서 이것이 어떻게 도움이 되는지 살펴보겠습니다.
너무 많은 토큰(가져온 컨텍스트 >> 필요한 컨텍스트)
대화 기록을 사용해 모든 도구 호출 결과와 메모를 보관하는 대신, 에이전트는 이를 파일시스템에 기록하고 필요할 때 관련 정보를 선별적으로 조회할 수 있습니다. Manus는 이 접근에 대해 공개적으로 처음 이야기한 곳 중 하나였으며—아래 도표는 그들의 블로그 게시물에서 가져왔습니다.
첫 번째 예로 웹 검색 도구를 들어봅시다. 웹 검색을 실행하고 도구에서 원시 콘텐츠 10k 토큰을 돌려받습니다. 그 대부분은 항상 필요하지 않을 가능성이 큽니다. 만약 그걸 메시지 히스토리에 넣으면, 모든 10k 토큰이 전체 대화 동안 자리를 차지하며 Anthropic 청구서를 높입니다. 하지만 그 큰 도구 결과를 파일시스템으로 오프로드하면, 에이전트는 키워드로 지능적으로 grep 검색을 수행한 뒤, 필요한 컨텍스트만 대화에 읽어들일 수 있습니다.
이 예에서, 에이전트는 사실상 파일시스템을 대규모 컨텍스트를 위한 스크래치 패드로 사용하고 있습니다.
많은 양의 컨텍스트가 필요(필요한 컨텍스트 < 지원되는 컨텍스트 윈도우)
때로는 에이전트가 질문에 답하기 위해 많은 컨텍스트를 필요로 합니다. 파일시스템은 LLM이 필요에 따라 동적으로 더 많은 정보를 저장하고 불러올 수 있게 하는 깔끔한 추상화를 제공합니다. 이에 대한 예로는 다음이 포함됩니다:
- 장기 지평의 답변을 위해 에이전트는 계획을 세우고 이를 따를 필요가 있습니다. 그 계획을 파일시스템에 기록해두면, 에이전트가 나중에 컨텍스트 윈도우로 다시 끌어와 에이전트가 무엇을 해야 하는지(예: “반복 읽기를 통한 조작”) 상기시킬 수 있습니다.
- 이 모든 컨텍스트를 훑기 위해, 에이전트는 서브에이전트를 생성할 수 있습니다. 서브에이전트가 작업을 하고 무언가를 학습하면, 메인 에이전트에게 학습 내용을 답변으로 돌려주는 대신 파일시스템에 그 지식을 기록할 수 있습니다(예: 전달하면서 내용이 변질되는 것을 최소화).
- 어떤 에이전트는 일을 수행하는 방법에 대한 많은 지침을 필요로 합니다. 모든 지침을 시스템 프롬프트에 그냥 채워넣어(컨텍스트 비대화)두는 대신, 이를 파일로 저장하고 에이전트가 필요할 때 동적으로 읽을 수 있게 할 수 있습니다(예: Anthropic skills).
좁은 영역의 정보 찾기(가져온 컨텍스트 ≠ 필요한 컨텍스트)
시맨틱 검색은 LLM 물결 초기에 컨텍스트 검색을 위한 가장 인기 있는 접근법 중 하나였습니다. 일부 사용 사례에서는 효과적일 수 있지만, 문서 유형(예: 기술적 API 레퍼런스, 코드 파일)에 따라 텍스트에 시맨틱 정보가 부족해 시맨틱 검색이 매우 부적절할 수 있습니다.
파일시스템은 에이전트가 ls, glob, grep 도구로 컨텍스트를 지능적으로 검색할 수 있는 대안을 제공합니다. 최근 Claude Code를 사용해보셨다면, 필요한 컨텍스트를 찾기 위해 glob와 grep에 크게 의존한다는 것을 아실 겁니다. 이 기법이 성공적인 데에는 몇 가지 핵심 이유가 있습니다.
- 최근 LLM 모델은 파일시스템을 순회하는 것을 특별히 학습합니다.
- 정보가 보통 논리적으로(디렉터리) 이미 구조화되어 있습니다.
- glob와 grep은 에이전트가 특정 파일뿐만 아니라 특정 줄, 특정 문자까지도 고립시킬 수 있게 해줍니다.
- read_file 도구는 에이전트가 파일에서 어떤 줄을 읽어올지 지정할 수 있게 해줍니다.
이러한 이유로, 파일시스템(그리고 파일시스템을 사용함으로써 얻게 되는 검색 능력)을 사용하는 것이 더 나은 결과를 만드는 상황들이 존재합니다.
시맨틱 검색이 여전히 유용하다는 점에 유의하세요! 그리고 파일시스템 검색과 함께 사용할 수 있습니다. Cursor는 최근 블로그 글 (TMT 글1)에서 둘을 함께 사용했을 때의 장점을 강조했습니다.
시간에 따른 학습(전체 컨텍스트 ≠ 필요한 컨텍스트)
에이전트가 실수하는 큰 이유는 관련 컨텍스트가 부족하기 때문입니다. 에이전트를 개선하는 훌륭한 방법은 보통 올바른 컨텍스트에 접근할 수 있도록 하는 것입니다. 이는 때로 더 많은 데이터 소스를 추가하거나 시스템 프롬프트를 업데이트하는 것으로 나타납니다.
시스템 프롬프트를 업데이트하는 일반적인 방식은 다음과 같습니다:
- 에이전트에 적절한 지침이 부족했던 예시를 확인한다
- 주제 전문가에게서 관련 지침을 얻는다
- 그 지침으로 프롬프트를 업데이트한다
일반적으로 최종 사용자가 실제로 최고의 주제 전문가입니다. 에이전트와의 대화를 통해, 그들은(암시적으로나 명시적으로) 어떤 지침이 적절한 관련 지침인지에 대한 중요한 단서를 제공할 수 있습니다. 그렇다면 위의 세 번째 단계(그 지침으로 프롬프트를 업데이트하기)를 자동화할 방법이 있을까요?
우리는 에이전트의 지침(혹은 스킬)이 에이전트가 작업하고자 하는 다른 어떤 컨텍스트와도 다르지 않다고 생각합니다. 파일시스템은 에이전트가 자신의 지침을 저장하고 업데이트할 수 있는 장소가 될 수 있습니다!
사용자 피드백이 주어진 직후, 에이전트는 자신의 파일에 기록하여 중요한 정보를 기억할 수 있습니다. 이는 빠른 일회성 사실, 특히 사용자 이름, 이메일, 기타 선호와 같은 사용자 맞춤 정보에 매우 좋습니다.
이것은 아직 완전히 해결되지 않았으며 여전히 등장하는 패턴이지만, LLM이 시간이 지남에 따라 자체 스킬셋과 지침을 성장시켜, 향후 반복에서 필요한 컨텍스트에 접근할 수 있도록 하는 흥미로운 새로운 방법입니다.
딥 에이전트가 파일시스템을 활용하는 방법을 확인하세요
우리는 오픈 소스 저장소 Deep Agents(Python, TypeScript)를 운영하고 있으며, 파일시스템에 접근할 수 있는 에이전트를 빠르게 구축할 수 있게 해줍니다. 파일시스템을 활용하는 이러한 컨텍스트 엔지니어링 트릭 중 많은 것들이 이미 내장되어 있습니다! 앞으로 분명 더 많은 패턴이 등장할 것이며—Deep Agents를 사용해보고 의견을 알려주세요!