코딩 에이전트에서 토큰 효율과 응답 품질을 높이기 위해 필요한 맥락만 필요할 때 불러오는 ‘동적 컨텍스트 발견’ 패턴과 Cursor에서의 적용 사례를 소개합니다.
URL: https://cursor.com/blog/dynamic-context-discovery
코딩 에이전트는 소프트웨어가 만들어지는 방식을 빠르게 바꾸고 있습니다. 이러한 급격한 개선은 에이전트형 모델의 발전뿐 아니라, 모델을 원하는 방향으로 이끄는 더 나은 컨텍스트 엔지니어링 덕분이기도 합니다.
Cursor의 에이전트 하네스(agent harness)—즉, 우리가 모델에 제공하는 지침과 도구—는 우리가 지원하는 각 최신 프런티어 모델마다 개별적으로 최적화되어 있습니다. 하지만 컨텍스트를 수집하는 방식, 긴 작업 궤적에서 토큰 사용을 최적화하는 방식 등, 하네스 안의 모든 모델에 공통으로 적용할 수 있는 컨텍스트 엔지니어링 개선도 있습니다.
모델이 에이전트로서 더 뛰어나질수록, 처음부터 많은 세부 정보를 제공하기보다 에이전트가 스스로 관련 컨텍스트를 끌어오도록 하는 것이 더 성공적이라는 것을 발견했습니다. 우리는 이 패턴을 동적 컨텍스트 발견(dynamic context discovery) 이라고 부릅니다. 항상 포함되는 정적 컨텍스트(static context) 와 대비되는 개념입니다.
동적 컨텍스트 발견은 필요한 데이터만 컨텍스트 윈도우로 가져오기 때문에 토큰 효율이 훨씬 높습니다. 또한 컨텍스트 윈도우 안에 잠재적으로 혼란을 주거나 서로 모순될 수 있는 정보의 양을 줄여 에이전트의 응답 품질을 향상시킬 수도 있습니다.
다음은 Cursor에서 동적 컨텍스트 발견을 활용한 방식입니다:
도구 호출은 큰 JSON 응답을 반환하면서 컨텍스트 윈도우를 극적으로 늘릴 수 있습니다.
Cursor의 1st-party 도구(예: 파일 편집, 코드베이스 검색)에서는 똑똑한 도구 정의와 최소한의 응답 포맷으로 컨텍스트 팽창을 막을 수 있습니다. 하지만 3rd-party 도구(예: 셸 명령, MCP 호출)에는 기본적으로 같은 처리가 적용되지 않습니다.
코딩 에이전트들이 흔히 쓰는 접근은 긴 셸 명령이나 MCP 결과를 잘라(truncate) 버리는 것입니다. 이는 데이터 손실로 이어질 수 있는데, 그 안에는 컨텍스트에 필요했던 중요한 정보가 포함되어 있을 수도 있습니다. Cursor에서는 대신 출력을 파일에 기록하고, 에이전트가 그 파일을 읽을 수 있게 합니다. 에이전트는 tail을 호출해 끝부분을 확인한 뒤, 필요하다면 더 읽습니다.
그 결과 컨텍스트 한계에 도달했을 때 불필요한 요약이 발생하는 일이 줄었습니다.
모델의 컨텍스트 윈도우가 가득 차면, Cursor는 요약 단계를 트리거해 지금까지의 작업 요약본과 함께 에이전트에 새로운 컨텍스트 윈도우를 제공합니다.
하지만 요약은 컨텍스트를 손실 압축(lossy compression)하는 과정이기 때문에, 요약 이후 에이전트의 지식이 저하될 수 있습니다. 에이전트가 과제의 핵심 세부 사항을 잊어버릴 수도 있습니다. Cursor에서는 요약 품질을 개선하기 위해 채팅 기록을 파일로 사용합니다.

컨텍스트 윈도우 한계에 도달했거나 사용자가 수동으로 요약을 선택하면, 우리는 에이전트에게 기록 파일에 대한 참조를 제공합니다. 에이전트가 요약에서 빠진 추가 세부 정보가 필요하다는 것을 알게 되면, 기록을 검색해 그 정보를 복구할 수 있습니다.
Cursor는 Agent Skills를 지원합니다. 이는 코딩 에이전트를 전문화된 역량으로 확장하기 위한 오픈 표준입니다. 다른 유형의 Rules와 마찬가지로, Skills는 특정 도메인 작업에서 에이전트가 어떻게 수행해야 하는지를 알려주는 파일로 정의됩니다.
Skills에는 이름과 설명도 포함되며, 이는 시스템 프롬프트에 “정적 컨텍스트”로 포함될 수 있습니다. 그러면 에이전트는 grep이나 Cursor의 시맨틱 검색 같은 도구를 사용해 관련 스킬을 끌어오는 동적 컨텍스트 발견을 수행할 수 있습니다.
Skills는 작업과 관련된 실행 파일이나 스크립트를 함께 묶을 수도 있습니다. 어차피 모두 파일이기 때문에, 에이전트는 특정 스킬과 관련된 항목이 무엇인지 쉽게 찾아낼 수 있습니다.
MCP는 OAuth 뒤에 있는 보안 리소스에 접근하는 데 유용합니다. 예를 들어 프로덕션 로그, 외부 디자인 파일, 또는 기업 환경에서의 내부 컨텍스트와 문서 등이 될 수 있습니다.
일부 MCP 서버는 많은 도구를 포함하고 있으며, 종종 설명도 길어 컨텍스트 윈도우를 크게 부풀립니다. 이들 도구 대부분은 프롬프트에 항상 포함되는데도 실제로는 사용되지 않습니다. 여러 MCP 서버를 쓰면 이 문제는 더 커집니다.
모든 MCP 서버가 이 문제를 최적화하리라 기대하는 것은 현실적이지 않습니다. 우리는 코딩 에이전트가 컨텍스트 사용량을 줄이는 책임을 져야 한다고 믿습니다. Cursor에서는 도구 설명을 폴더에 동기화(synced)함으로써 MCP에 대한 동적 컨텍스트 발견을 지원합니다.
이제 에이전트는 도구 이름을 포함한 아주 작은 정적 컨텍스트만 받게 되며, 작업에 필요할 때 도구를 찾아보도록 유도됩니다. A/B 테스트에서 MCP 도구를 호출한 실행들에 대해, 이 전략이 총 에이전트 토큰을 46.9% 감소시키는 것으로 나타났습니다(통계적으로 유의미하며, 설치된 MCP 수에 따라 분산이 큰 편).

이 파일 접근 방식은 MCP 도구의 상태를 에이전트에 전달할 수 있는 능력도 열어줍니다. 예를 들어 이전에는 MCP 서버가 재인증이 필요하면 에이전트가 해당 도구들을 완전히 잊어버려 사용자가 혼란스러웠습니다. 이제는 에이전트가 사용자에게 선제적으로 재인증하라고 실제로 알려줄 수 있습니다.
Cursor는 터미널 세션 출력을 에이전트 입력으로 복사/붙여넣기할 필요가 없도록, 통합 터미널 출력을 로컬 파일시스템에 동기화합니다.
이렇게 하면 “왜 내 명령이 실패했지?”라고 물었을 때, 에이전트가 사용자가 무엇을 참조하는지 이해하기가 쉬워집니다. 터미널 기록은 길어질 수 있으므로, 에이전트는 grep으로 관련 출력만 찾아낼 수 있습니다. 이는 서버처럼 오래 실행되는 프로세스의 로그에서 특히 유용합니다.
이는 CLI 기반 코딩 에이전트가 이전 셸 출력이 컨텍스트에 있는 것을 보는 방식과 유사하지만, 정적으로 주입되는 것이 아니라 동적으로 발견된다는 점이 다릅니다.
파일이 LLM 기반 도구의 최종 인터페이스가 될지는 아직 명확하지 않습니다.
하지만 코딩 에이전트가 빠르게 개선되는 상황에서, 파일은 사용하기 단순하면서도 강력한 프리미티브였고, 미래를 완전히 예측할 수 없는 또 다른 추상화에 비해 더 안전한 선택이었습니다. 이 분야에서 공유할 흥미로운 작업이 훨씬 더 많이 있으니 기대해 주세요.
이러한 개선은 앞으로 몇 주 안에 모든 사용자에게 적용될 예정입니다. 이 블로그 글에서 설명한 기법들은 Lukas Moller, Yash Gaitonde, Wilson Lin, Jason Ma, Devang Jhabakh, Jediah Katz 등 많은 Cursor 직원들의 작업 결과입니다. AI를 사용해 가장 어렵고 야심찬 코딩 작업을 해결하는 데 관심이 있다면, 여러분의 이야기를 듣고 싶습니다. hiring@cursor.com으로 연락해 주세요.