에이전트가 컨텍스트 엔지니어링 (Context Engineering)을 위해 파일 시스템을 사용하는 방법

Nick Huang 작성

딥 에이전트 (Deep agents)의 핵심 기능은 일련의 파일 시스템 (Filesystem) 도구에 대한 접근 권한입니다. 딥 에이전트는 이러한 도구들을 사용하여 파일 시스템 내의 파일을 읽고, 쓰고, 편집하고, 목록을 나열하며, 검색할 수 있습니다.

이 포스트에서는 왜 우리가 에이전트에게 파일 시스템이 중요하다고 생각하는지 살펴볼 것입니다. 파일 시스템이 어떻게 도움이 되는지 이해하기 위해서는, 먼저 오늘날 에이전트가 어떤 부분에서 부족할 수 있는지부터 생각해보아야 합니다. 에이전트는 (a) 모델이 충분히 뛰어나지 않거나, (b) 적절한 컨텍스트 (Context)에 접근할 수 없기 때문에 실패합니다. 컨텍스트 엔지니어링 (Context engineering)은 "다음 단계를 위해 컨텍스트 윈도우 (Context window)를 딱 적절한 정보로 채우는 섬세한 예술이자 과학"입니다. 컨텍스트 엔지니어링을 이해하고, 이것이 어떻게 실패할 수 있는지를 파악하는 것은 신뢰할 수 있는 에이전트를 구축하는 데 매우 중요합니다.

컨텍스트 엔지니어링에 대한 관점

현대 에이전트 엔지니어의 업무를 바라보는 한 가지 방법은 컨텍스트 엔지니어링의 관점을 통해 보는 것입니다. 에이전트는 일반적으로 많은 컨텍스트(모든 지원 문서, 모든 코드 파일 등)에 접근할 수 있습니다 (have access to). 들어오는 질문에 답하기 위해서, 에이전트는 몇 가지 중요한 컨텍스트(질문에 답하는 데 필요한 컨텍스트를 포함하는 것)를 필요로 합니다 (needs). 해당 질문에 답하는 것을 목표로 하는 동안, 에이전트는 (자신의 컨텍스트 윈도우로 가져오기 위해) 특정 컨텍스트 뭉치를 검색합니다 (retrieves).

이러한 관점에서 볼 때, 에이전트에게 있어 컨텍스트 엔지니어링이 "실패"할 수 있는 방법은 여러 가지가 있습니다:

• 에이전트가 필요로 하는 컨텍스트가 전체 컨텍스트 내에 존재하지 않는다면, 에이전트는 성공할 수 없습니다. 예시: 고객 지원 에이전트가 질문에 답하기 위해 특정 문서 페이지에 접근해야 하지만, 해당 페이지가 인덱싱(indexed)되지 않은 경우.
• 에이전트가 검색(retrieves)한 컨텍스트가 에이전트에게 필요한 컨텍스트를 포괄(encapsulate)하지 못한다면, 에이전트는 올바르게 답변할 수 없습니다. 예시: 고객 지원 에이전트가 질문에 답하기 위해 특정 문서 페이지에 접근해야 하고 해당 페이지가 존재하며 인덱싱되어 있지만, 에이전트에 의해 검색되지 않은 경우.
• 에이전트가 검색한 컨텍스트가 에이전트에게 필요한 컨텍스트보다 훨씬 크다면, 에이전트는 낭비(시간, 토큰, 또는 둘 다)를 하고 있는 것입니다. 예시: 고객 지원 에이전트가 단 하나의 특정 페이지가 필요함에도 불구하고, 에이전트가 100개의 페이지를 검색하는 경우.

에이전트 엔지니어로서 우리의 역할은 **빨간색을 초록색에 맞추는 것(fit red to green, 즉 에이전트가 검색하는 컨텍스트가 필요한 정보의 가능한 한 작은 상위 집합(superset)이 되도록 보장하는 것)**입니다.

적절한 컨텍스트를 분리하려고 할 때 몇 가지 구체적인 과제들이 발생합니다.

너무 많은 토큰(retrieved context >> necessary context)

웹 검색(web search)과 같은 일부 도구는 매우 많은 토큰을 반환할 수 있습니다. 몇 번의 웹 검색만으로도 대화 기록(conversation history)에 수만 개의 토큰이 빠르게 쌓일 수 있습니다. 결국 성가신 400 Bad Request 에러를 마주하게 될 수도 있지만, 그보다 훨씬 이전에 LLM 비용이 폭증하고 성능이 저하됩니다.

대량의 컨텍스트 필요(necessary context > supported context window)

때때로 에이전트는 질문에 답하기 위해 실제로 아주 많은 정보가 필요할 수 있습니다. 이러한 정보는 보통 단 한 번의 검색 쿼리(search query)로 반환될 수 없으며, 이것이 많은 이들이 에이전트가 검색 도구를 반복적으로 호출하게 하는 "에이전틱 검색(agentic search)" 개념에 의존해 온 이유입니다. 이 방식의 문제는 컨텍스트의 양이 컨텍스트 윈도우(context window)에 모두 담을 수 없을 정도로 빠르게 증가한다는 점입니다.

니치 정보 찾기(retrieved context ≠ necessary context)

에이전트가 입력을 처리하기 위해 수백 또는 수천 개의 파일 속에 파묻힌 니치 정보(niche information)를 참조해야 할 수도 있습니다. 에이전트가 어떻게 그 정보를 안정적으로 찾아낼 수 있을까요? 만약 찾아내지 못한다면, 검색된 컨텍스트(retrieved context)는 질문에 답하는 데 필요한 내용이 아닐 것입니다. 시맨틱 검색 (semantic search)의 대안(또는 보완책)이 있을까요?

시간에 따른 학습 (total context ≠ necessary context)

때때로 에이전트는 질문에 답하는 데 필요한 컨텍스트에 접근할 수 없을 수도 있습니다 (에이전트가 가진 도구(tools)나 지침(instructions) 내에 없는 경우). 최종 사용자는 에이전트와의 상호작용 과정에서 해당 컨텍스트가 무엇인지에 대한 단서를 (암시적 또는 명시적으로) 자주 제공하곤 합니다. 에이전트가 이를 다음 반복(iterations)을 위해 자신의 컨텍스트에 추가할 수 있는 방법이 있을까요?

이것들은 모두 흔한 장애물들이며, 우리 대부분은 이전에 다양한 형태의 이러한 문제들을 겪어본 적이 있습니다!

파일 시스템이 어떻게 에이전트를 더 나아지게 만들 수 있을까요?

가장 간단한 용어로 설명하자면: 파일 시스템은 에이전트가 무한한 양의 컨텍스트를 유연하게 저장, 검색 및 업데이트할 수 있는 단일 인터페이스(single interface)를 제공합니다.

위에서 나열한 각 시나리오에서 이것이 어떻게 도움이 될 수 있는지 살펴보겠습니다.

너무 많은 토큰 (retrieved context >> necessary context)

모든 도구 호출(tool call) 결과와 메모를 유지하기 위해 대화 기록(conversation history)을 사용하는 대신, 에이전트는 이를 파일 시스템에 기록한 다음 필요할 때 **관련 정보(relevant information)**를 선택적으로 찾아볼 수 있습니다. Manus는 이 접근 방식에 대해 공개적으로 이야기한 첫 번째 기업 중 하나였으며, 아래 다이어그램은 그들의 블로그 포스트에서 가져온 것입니다.

웹 검색 도구를 사용하는 첫 번째 예시를 들어보겠습니다. 제가 웹 검색을 실행하면 도구로부터 10k 토큰의 가공되지 않은 콘텐츠(raw content)를 돌려받습니다. 그 콘텐츠의 대부분은 아마 항상 필요하지는 않을 것입니다. 만약 이를 메시지 기록에 넣는다면, 10k 토큰 전체가 대화 내내 남아있게 되어 Anthropic 비용을 상승시킬 것입니다. 하지만 이 거대한 도구 결과물을 파일 시스템으로 오프로드(offload)한다면, 에이전트는 특정 키워드에 대해 지능적으로 grep 검색을 수행한 다음, 필요한 컨텍스트만 대화로 읽어올 수 있습니다.

이 예시에서 에이전트는 파일 시스템을 **대규모 컨텍스트를 위한 연습장 (scratch pad for large context)**으로 효과적으로 사용하고 있습니다.

많은 양의 컨텍스트가 필요한 경우 (필요한 컨텍스트 < 지원되는 컨텍스트 창)

때때로 에이전트는 질문에 답하기 위해 많은 양의 컨텍스트를 필요로 합니다. 파일 시스템은 LLM이 필요에 따라 정보를 동적으로 저장하고 더 많은 정보를 가져올 수 있도록 하는 훌륭한 추상화 (abstraction)를 제공합니다. 이에 대한 예시는 다음과 같습니다:

• 장기적인 답변 (long horizon answers)을 위해, 에이전트는 계획을 세우고 이를 따라야 합니다. 해당 계획을 파일 시스템에 작성함으로써, 에이전트는 나중에 이 정보를 컨텍스트 창 (context window)으로 다시 불러와 자신이 무엇을 해야 하는지 상기할 수 있습니다 (예: "암송을 통한 주의력 조작 (manipulate attention through recitation)").
• 이 모든 컨텍스트를 샅샅이 살펴보기 위해, 에이전트는 하위 에이전트 (subagents)를 가동할 수 있습니다. 이러한 하위 에이전트들이 작업을 수행하고 무언가를 학습할 때, 단순히 학습한 내용을 메인 에이전트에게 답변으로 전달하는 대신, 대신 파일 시스템에 지식을 기록할 수 있습니다 (예: 전화기 게임 (game of telephone) 현상 최소화).
• 일부 에이전트는 작업 수행 방법에 대한 많은 지침 (instructions)을 필요로 합니다. 이러한 지침들을 단순히 시스템 프롬프트 (system prompt)에 모두 집어넣어 컨텍스트를 팽창시키는 대신, 파일로 저장하고 에이전트가 필요할 때 동적으로 읽을 수 있도록 할 수 있습니다 (예: Anthropic skills).

니치한 정보 찾기 (검색된 컨텍스트 ≠ 필요한 컨텍스트)

시맨틱 검색 (Semantic search)은 LLM 파동 초기 단계에서 컨텍스트를 검색하는 가장 인기 있는 접근 방식 중 하나였습니다. 일부 사용 사례에서는 효과적일 수 있지만, 문서의 유형(예: 기술 API 레퍼런스, 코드 파일)에 따라 텍스트 내에 시맨틱 정보가 부족할 경우 시맨틱 검색이 매우 부적절하게 작동할 수 있습니다.

파일 시스템은 에이전트가 ls, glob, grep 도구를 사용하여 지능적으로 컨텍스트를 검색할 수 있게 하는 대안을 제공합니다. 최근 Claude Code를 사용해 보셨다면, 그것이 필요한 적절한 컨텍스트를 찾기 위해 glob 및 grep 검색에 크게 의존한다는 것을 알 수 있을 것입니다. 이 기술이 성공적인 데에는 몇 가지 핵심적인 이유가 있습니다.

• 오늘날의 모델들은 파일 시스템 (filesystems)을 탐색하는 것을 이해하도록 특별히 학습되었습니다.
• 정보가 이미 논리적으로 구조화되어 있는 경우가 많습니다 (디렉토리).
• glob 및 grep을 사용하면 에이전트가 특정 파일뿐만 아니라 특정 줄과 특정 문자까지 분리할 수 있습니다.
• read_file 도구를 사용하면 에이전트가 파일에서 읽어올 특정 줄을 지정할 수 있습니다.

이러한 이유로, 파일 시스템을 사용하고(파일 시스템을 사용함으로써 얻는 검색 기능 포함) 더 나은 결과를 만들어낼 수 있는 상황들이 존재합니다.

시맨틱 검색 (semantic search) 또한 여전히 유용할 수 있다는 점에 유의하세요! 그리고 파일 시스템 검색과 병행하여 사용할 수 있습니다. Cursor는 최근 이 두 가지를 함께 사용하는 것의 이점을 강조하는 블로그를 작성했습니다.

시간에 따른 학습 (전체 컨텍스트 ≠ 필수 컨텍스트)

에이전트가 실수를 하는 큰 이유 중 하나는 관련 컨텍스트 (context)가 누락되었기 때문입니다. 에이전트를 개선하는 훌륭한 방법은 대개 에이전트가 올바른 컨텍스트에 접근할 수 있도록 보장하는 것입니다. 때로는 더 많은 데이터 소스 (datasources)를 추가하거나 시스템 프롬프트 (system prompt)를 업데이트하는 방식으로 이루어질 수 있습니다.

시스템 프롬프트를 업데이트하는 일반적인 관행은 다음과 같습니다:

• 에이전트에게 적절한 지침이 부족했던 사례를 확인합니다.
• 해당 분야의 전문가 (subject matter expert)로부터 관련 지침을 얻습니다.
• 해당 지침으로 프롬프트를 업데이트합니다.

종종 최종 사용자가 실제로는 최고의 분야 전문가인 경우가 많습니다. 에이전트와의 대화를 통해, 그들은 무엇이 올바르고 관련 있는 지침인지에 대한 중요한 단서들을 (암시적 또는 명시적으로) 제공할 수 있습니다. 그렇다면 이러한 점을 염두에 두었을 때, 위에서 언급한 세 번째 단계(해당 지침으로 프롬프트를 업데이트하는 것)를 자동화할 방법은 없을까요?

우리는 에이전트의 지침(또는 기술)이 에이전트가 작업하고자 하는 다른 컨텍스트와 다르지 않다고 생각합니다. 파일 시스템은 에이전트가 자신의 지침을 저장하고 업데이트하는 장소로 활용될 수 있습니다!

사용자 피드백이 제공된 직후, 에이전트는 자신의 파일에 내용을 작성하여 중요한 정보를 기억할 수 있습니다. 이는 이름, 이메일 또는 기타 선호 사항과 같이 사용자에게 특화될 수 있는 정보와 같은, 빠르고 일회성인 사실을 저장하는 데 매우 유용합니다.

이 방식은 아직 완전히 해결된 문제는 아니며 여전히 부상하고 있는 패턴(emerging pattern)이지만, LLM(Large Language Models)이 시간이 지남에 따라 자체적인 기술 세트(skillsets)와 지침을 확장하고, 향후 반복(iterations) 과정에서 필요한 컨텍스트(context)에 접근할 수 있도록 보장하는 흥미로운 새로운 방법입니다.

딥 에이전트(deep agent)가 파일 시스템을 어떻게 활용하는지 확인해 보세요

저희는 파일 시스템에 접근할 수 있는 에이전트를 빠르게 구축할 수 있는 Deep Agents (Python, TypeScript)라는 오픈 소스 리포지토리(repo)를 보유하고 있습니다. 파일 시스템을 사용하는 이러한 많은 컨텍스트 엔지니어링 (Context Engineering) 기법들이 이미 내장되어 있습니다! 앞으로 더 많은 패턴이 등장할 것이 거의 확실합니다. Deep Agents를 직접 사용해 보시고 여러분의 의견을 들려주세요!