AI 컨텍스트 엔지니어링은 에이전트를 둘러싼 정보, 제한, 지침을 모두 설계하여 에이전트가 무엇을 볼 수 있는지, 무엇을 해야 하는지, 새로운 상황이나 불완전한 데이터를 마주했을 때 어떻게 행동해야 하는지를 알도록 하는 것이다. Stack Overflow의 엔지니어링 디렉터 Doug Whitley와 제품 디렉터 Ash Zade의 설명에 따르면, 목표는 에이전트에게 이용 가능한 모든 데이터를 쏟아붓는 것이 아니라, 예측 가능한 결과를 내는 작업을 수행하는 데 필요한 구체적인 컨텍스트를 제공하는 것이다.
이 내용은 Stack Overflow Blog가 “No Dumb Questions” 시리즈의 일부로 게시한 대화에서 다뤄졌다. 대화에서는 컨텍스트 엔지니어링, 컨텍스트 인프라, 컨텍스트 엔지니어링의 차이와 함께 이러한 개념이 RAG 및 MCP 기술과 맺는 관계, 그리고 기업이 모든 것을 내부적으로 구축하는 대신 기성 솔루션을 구매하는 이유를 논의했다.
인프라에서 엔지니어링으로
Whitley는 컨텍스트 인프라와 컨텍스트 엔지니어링을 구분한다. 컨텍스트 인프라는 컨텍스트를 저장하고 표시하며 에이전트에게 제공하는 방식과 관련되고, 컨텍스트 엔지니어링은 시스템 설계와 구성 요소를 특정한 방식으로 조직하는 이유에 초점을 맞춘다. 실행적인 의미의 컨텍스트 엔지니어링은 알고리즘, 프로그래밍 언어, 사용하는 도구를 선택하는 등 시스템을 실제로 구축하는 것과 관련된다.
그는 RAG를 세 수준이 만나는 영역에 둔다. 인덱스, 컨텍스트 저장소, 검색 방식은 인프라 측면을 나타내고, .NET, Python 또는 Rust와 같은 언어로 시스템을 구축하는 과정은 엔지니어링 측면을 나타낸다. 반면 아키텍처는 시스템의 전반적인 형태와 작동 방식을 지배하는 규칙을 결정한다. Whitley는 MCP를 특정 요구 사항을 가진 프로토콜로 보지만, 이를 시스템에 통합할지, 어떤 언어를 사용할지, 어떤 기능을 지원할지는 모두 설계상의 결정이라고 말한다.
에이전트가 내리는 결정의 범위 줄이기
Zade는 자동차 타이어를 검색하는 예를 들어 이 개념을 설명한다. 에이전트를 도서관에 보내 “타이어”를 검색하게 하면, 요청한 단어와 일치하기 때문에 비행기, 자전거, 손수레에 관한 정보를 찾아낼 수도 있다. 하지만 잘 설계된 시스템은 처음부터 작업이 자동차 타이어, 또는 특히 스포츠카용 타이어와 관련된 것임을 지정하고, 이용 가능한 정보를 이 범위로 제한한다.
Zade는 이러한 지침을 텍스트 프롬프트에만 넣는다고 해서 에이전트가 이를 반드시 따르는 것은 아니라고 본다. 따라서 컨텍스트 엔지니어링에서는 에이전트가 접근할 수 있는 데이터를 통제하는 동시에, 불완전하거나 잘못된 정보를 마주했을 때 무엇을 할지도 정해야 한다. 이렇게 하면 에이전트의 결정에서 일부 변수가 제거되며, 에이전트가 정보의 신뢰성을 스스로 판단하거나 검색 범위를 넓힐지 결정하도록 내버려 두지 않게 된다.
이 시스템에는 에이전트의 메모리도 포함된다. 에이전트가 지금까지 수행한 일, 배운 것, 소통한 내용, 구축한 것을 보존하도록 하는 것이다. 여러 에이전트가 작동하거나 작업이 중단된 후 나중에 재개될 때 이러한 메모리는 더욱 중요해진다.
신뢰성, 권한, 인간의 개입
두 발표자에 따르면 Stack Internal은 컨텍스트를 신뢰성 시스템 및 전문가 검증 흐름과 연결하는 사례다. 지식은 높음, 중간, 낮음의 등급으로 분류된다. 등급이 중간이거나 낮으면 사용자를 해당 주제의 전문가에게 안내하여 정보를 검증하거나 부족한 부분을 보완할 수 있으며, 에이전트가 확실하지 않은 지식에 근거해 결정을 내리도록 하지 않는다.
데이터 보호는 에이전트가 특정 정보를 볼 수 있는지 여부라는 질문을 넘어선다. 사용자가 해당 정보에 접근할 수 있더라도 에이전트가 수행하는 작업에는 적합하지 않을 수 있다. 따라서 두 발표자는 다음과 같은 두 가지 통제 수준을 설명한다.
- 소스 권한: 에이전트는 Slack, MS Teams, Google Drive 또는 SharePoint와 같이 검색하는 시스템에서 사용자의 권한을 상속한다.
- 범위: 사용자는 더 넓은 데이터 집합에 접근할 권한이 있더라도 에이전트가 이용할 수 있는 데이터의 범위를 좁힐 수 있다.
- 새로운 데이터: 에이전트가 생성하거나 시스템에 반환하는 내용을 제한할 수 있다. 먼저 사용자에게 보내고, 일반 지식 베이스에 자동으로 추가하거나 팀과 공유하지 않도록 할 수 있다.
이러한 구분은 컨텍스트 관리가 단순히 검색에 관한 것이 아니라, 에이전트가 생성하는 메모리와 지식에 대한 통제도 포함한다는 점을 보여준다.
기업이 직접 구축하는 대신 솔루션을 구매할 수 있는 이유
Whitley는 컨텍스트 엔지니어링을 구축하는 것이 가능하지만, 과제가 코드 작성에만 국한되지는 않는다고 말한다. 기업이 Slack, MS Teams, Google Drive, SharePoint, Confluence, GitHub, Jira에서 데이터를 수집할 때는 이를 어떻게 인덱싱하고 정렬하며 재순위화할지, 그리고 충돌하거나 누락되었거나 잘못된 정보를 어떻게 처리할지를 결정해야 한다.
Zade는 작업의 상당 부분이 신뢰성 자체를 정의하는 것과 관련된다고 본다. 전문 사용자는 AI의 출력이 자신의 기대와 과거 경험에 부합할 때 이를 신뢰할 수 있지만, AI에게 작업을 요청하는 분야에 전문 지식이 없는 사람에게는 이러한 방식이 동일한 정도로 가능하지 않다. 따라서 시스템에는 정보를 수집하는 기술적 해결책뿐 아니라 무엇이 정보를 신뢰할 만하게 만드는지에 대한 논의도 필요하다.
Whitley는 기성 솔루션을 구매하면 다른 고객들이 겪은 문제에서 축적된 경험을 얻을 수 있다고 덧붙인다. 여기에는 엣지 케이스와 일상적인 문제가 포함되며, 그는 자신의 팀이 이를 약 20개 범주로 분류한다고 말한다. 그럼에도 두 발표자는 내부 구축을 배제하지 않는다. 사용 사례가 새롭거나 기업이 자체적인 설계 결정을 내려야 할 때는 내부 구축이 적합할 수 있다.
Whitley와 Zade에게 컨텍스트 엔지니어링의 품질은 시스템을 단일 작업으로 단순히 좁히는 것이 아니라, 시스템의 유연성과 일관되고 예측 가능한 출력을 제공하는 능력으로 측정된다. 또한 정보를 조기에 필터링하면 에이전트가 처리하는 토큰 수를 줄일 수 있다. 자동차 책을 검색하는 것이 도서관 전체를 검색하는 것보다 비용이 적고, 타이어 페이지를 검색하는 것이 책 전체를 검토하는 것보다 비용이 적은 것과 같다. 최종 목표는 에이전트가 예상된 작업을 수행하도록 하고, 넘어서는 안 되는 한계에 도달했을 때 멈추거나 인간의 도움을 요청하도록 하는 것이다.