컨텍스트 엔지니어링: 프롬프트 엔지니어링을 대체하는 AI 설계법

핵심 메시지

• LLM은 기억이 없는 상태 비저장 상자로, 토큰을 넣으면 토큰을 내놓을 뿐이며 스스로 행동하지 못한다.
• 컨텍스트 창에는 사용자 메시지·시스템 프롬프트·도구·리소스·어시스턴트 메시지·도구 호출 기록의 6가지가 들어간다.
• 이 중 사용자·어시스턴트 메시지와 도구 호출 기록은 에이전트가 오래 돌수록 계속 늘어나 공간을 잠식한다.
• 컨텍스트 창은 꽉 채운다고 좋은 게 아니라 대략 60~70% 지점에서 최상의 결과가 나온다.
• 시스템 프롬프트 설계, 도구 설명, 데이터 검색, 장기 실행 관리라는 4가지 도구로 컨텍스트를 정교하게 설계해야 한다.

쉽게 이해하기

발표자는 프롬프트 엔지니어링이 늘 조금 우스운 것이었다며, 진짜 중요한 것은 '컨텍스트'라고 말문을 연다. 최대 100만 토큰 남짓한 창 안에 사업과 에이전트가 해야 할 일을 모두 담아야 하는데, 복잡한 실제 과제를 풀기에는 그 공간이 결코 넉넉하지 않다는 문제의식이다. 그래서 현대 에이전트 애플리케이션에서 컨텍스트를 이루는 구성요소를 이해하고, 이를 정밀하게 설계할 틀이 필요하다고 제안한다.

먼저 LLM의 본질을 상기시킨다. LLM은 토큰을 입력받아 '그럴듯한' 토큰을 출력하는 상태 비저장 상자로, 매우 똑똑하지만 아무것도 기억하지 못하고 인터넷에서 읽은 것만 알며 스스로 행동할 수 없다. 반면 우리가 만들고 싶은 에이전트는 사용자의 프롬프트를 입력받아 LLM을 여러 번 반복 호출하고, 도구를 불러 실제 세계에서 행동을 취한다. 이 반복과 장기 실행이 컨텍스트 관리라는 진짜 문제를 만든다.

발표자는 컨텍스트 창에 들어가는 것을 6가지로 정리한다. 사용자 메시지, 항상 존재하며 성격·가드레일을 정하는 시스템 프롬프트, 사용할 수 있는 도구의 설명, 기업 내부 문서처럼 LLM이 학습하지 못한 사적 데이터인 리소스, 모델이 되돌려주는 어시스턴트 메시지, 그리고 중간 단계로 부른 도구 호출과 그 응답 기록이다. 이 가운데 사용자·어시스턴트 메시지와 도구 호출 기록은 실행이 이어질수록 누적되고, 리소스는 애초에 큰 공간을 차지할 수 있다.

중요한 통찰은 '많을수록 좋은 게 아니다'라는 점이다. 예컨대 10만 토큰 창을 끝까지 채우면 오히려 성능이 떨어지고, 대략 용량의 60~70% 지점에서 가장 좋은 결과가 나온다는 연구 결과가 일관되게 관찰된다고 설명한다. 따라서 무엇을 넣을지 설계하는 도구가 필요하다.

그 도구는 네 가지다. 첫째 시스템 프롬프트는 너무 모호하지도 너무 규칙적이지도 않게, 결과와 넓은 접근만 정의하는 '골디락스' 균형이 핵심이다. 둘째 도구는 설명을 구체적으로 쓰고 입출력 스키마를 반드시 포함한다. 셋째 데이터 검색은 초기의 RAG를 넘어 MCP로 리소스를 필요할 때만 질의해 경제적으로 가져온다. 넷째 장기 실행에서는 압축(요약), 키-값 메모리 저장, 그리고 하나의 큰 에이전트를 여러 작은 에이전트로 분해하는 구성(composition)으로 창을 관리한다.

주요 인사이트

• LLM이 상태 비저장이라는 사실을 출발점으로 삼아야 컨텍스트 창을 왜 정교하게 설계해야 하는지가 분명해진다.
• 컨텍스트를 6개 구성요소로 나눠 보면, 100만 토큰짜리 큰 모델조차 복잡한 에이전트에는 넉넉하지 않다는 점이 드러난다.
• 컨텍스트 창을 꽉 채우는 것은 역효과이며 60~70% 지점이 최적이라는 경험칙은 리소스 선택에 절제가 필요함을 뜻한다.
• RAG만으로는 정밀하지 않으며, MCP 리소스처럼 모델이 필요하다고 판단한 것만 후속 호출에서 가져오면 창을 아낄 수 있다.
• 긴 사용자 레코드는 통째로 넣지 말고 사용자 ID만 준 뒤, 필요하면 도구·리소스로 상세를 요청하게 하는 식으로 데이터를 경제적으로 다뤄야 한다.

자주 묻는 질문

관련 AI 소식