AI 에이전트 컨텍스트 엔지니어링 실전 가이드: 시스템 프롬프트 조율부터 메모리 관리까지

핵심 메시지

• AI 에이전트가 연구 데모에서는 그럴듯하다가 실제 제품에서 무너지는 이유는 대체로 모델이나 도구가 아니라 컨텍스트 관리 실패다.
• 컨텍스트 엔지니어링은 프롬프트뿐 아니라 문서, 도구 설명, 도구 실행 결과, 메모리, 대화 기록, 중간 추론까지 추론 시점에 들어가는 모든 정보를 골라내는 일이다.
• 컨텍스트 창이 커져도 정보를 많이 넣을수록 정확도가 떨어지므로, 컨텍스트는 수확 체감이 있는 유한 자원으로 다뤄야 한다.
• 사용자 불만을 시스템 프롬프트에 if-else처럼 하나씩 박아 넣는 방식은 확장되지 않는다. 문제를 쪼개고 앞단에 라우터를 두는 편이 낫다.
• 언어 모델은 '이렇게 하지 마'라는 부정 예시보다 원하는 답의 형태를 보여 주는 긍정 예시를 훨씬 잘 따른다.

쉽게 이해하기

AI 에이전트를 둘러싼 기대는 여전히 뜨겁지만, 실제로 제품에 넣는 일이 얼마나 어려운지도 함께 드러나고 있다. 세계에서 손꼽히는 기업들조차 AI 기능을 제품에 붙이는 데 고전하고, 올해에는 내놓았던 AI 제품을 되돌린 사례도 나왔다. 발표자는 그 원인의 큰 부분이 컨텍스트에 있다고 본다. 문제는 모델도 도구도 에이전트 루프도 아니고, 규모가 커진 상황에서 컨텍스트를 다루는 일 자체가 어렵다는 것이다.

컨텍스트 엔지니어링은 Anthropic의 정의를 빌리면 '추론 과정에서 최적의 토큰 집합을 선별하고 유지하는 전략의 묶음'이다. 지난해의 화두가 프롬프트 엔지니어링이었다면 지금은 범위가 훨씬 넓다. 시스템 프롬프트와 사용자 메시지만 오가는 단순한 구조를 넘어, 문서와 도구와 메모리와 도메인 지식과 대화 기록까지 모델에게 줄 수 있는 모든 후보가 컨텍스트가 된다. 게다가 도구를 붙이면 모델은 최종 답 대신 도구 호출을 선택할 수 있고, 그 실행 결과가 다시 컨텍스트로 들어와 다음 판단의 재료가 된다. 이 루프가 열 번쯤 돌 수도 있다는 점까지 계산에 넣어야 한다.

컨텍스트 창이 계속 커지고 있는데도 정보를 많이 넣을수록 성능이 떨어지는 현상은 사라지지 않는다. 건초더미에서 바늘 찾기 식 실험을 보면, 정보를 조금만 준 모델은 사실을 완벽하게 뽑아내지만 책 한 권 분량을 주면 결과가 흔들린다. 모델에 따라 저하 곡선의 기울기는 다르지만 이 특성 자체는 모든 모델에서 나타난다. 그래서 컨텍스트는 수확 체감이 있는 유한 자원으로 취급해야 하고, 목표는 원하는 결과가 나올 가능성을 최대로 높이는 '가장 작은 고신호 토큰 집합'을 찾는 일이 된다.

실무에서 가장 흔한 실패는 시스템 프롬프트에서 시작된다. 처음에는 너무 두루뭉술하게 쓰고, 사용자 불만이 쌓이면 그 목록을 그대로 프롬프트에 박아 넣다가 결국 if-else 문에 가까운 지시서가 된다. 사례가 몇 개일 때는 통하지만 확장되지 않고, 어느 순간 컨텍스트가 부풀면서 모델이 규칙 일부를 무시하기 시작한다. 발표자가 권하는 방향은 두 가지다. 하나는 모델의 재량을 남겨 두면서 필요한 만큼만 구체적으로 쓰는 조율이고, 다른 하나는 프롬프트를 두 개의 하위 문제로 쪼갠 뒤 앞단에 라우터를 두어 문제 자체를 작게 만드는 것이다. 프롬프트 구조는 XML이나 마크다운으로 배경 정보, 지시, 도구 사용 지침, 출력 형식을 구분해 짧고 초점 있게 쓰는 방식이 권장된다.

컨설팅 현장에서 반복해 보이는 패턴은 또 있다. 부정 예시를 잔뜩 넣는 프롬프트, 데이터를 들여다보지 않고 고객 피드백을 그대로 코딩 도구에 던져 프롬프트를 고치게 하는 습관 같은 것들이다. 발표자는 대신 문제의 출처를 분석하고 긍정 예시를 주라고 말한다. 또 개발 초기부터 추적 도구를 붙여 시스템 프롬프트부터 도구 호출과 사용자 메시지까지 대화 전체 트리를 볼 수 있어야 한다고 강조한다. 대개 트레이스를 통째로 보면 오류의 출처가 곧바로 눈에 들어오기 때문이다. 마지막으로 워크플로와 에이전트를 구분할 것을 권한다. 진짜 에이전트는 모델이 도구를 루프로 자율 사용하는 코딩 도구 같은 부류이고, 대부분의 업무 자동화는 라우팅과 프롬프트 체이닝 같은 결정적인 워크플로가 훨씬 신뢰할 만하다.

주요 인사이트

• 에이전트가 실패하는 것은 추론을 못 해서가 아니라 나쁜 컨텍스트 위에서 추론하기 때문이다. 정보가 너무 많거나 너무 적거나, 서로 모순되거나 낡은 경우가 대부분이다.
• 메모리 문제는 개발 단계에서 잘 보이지 않는다. 짧은 대화만 테스트하기 때문에, 열 번째 턴에서 앞의 내용을 잊는다는 사용자 불만으로 뒤늦게 드러난다.
• 사람이 대화창에 함께 있는 챗 인터페이스는 사용자가 틀린 답을 바로잡을 수 있지만, 고객 응대나 백엔드 자동화는 한 번에 맞아야 해서 훨씬 강한 통제가 필요하다.
• 상태 머신으로 사용자의 단계를 추적하고 단계마다 다른 시스템 프롬프트를 꺼내 쓰면, 절차 전체를 하나의 거대한 프롬프트에 욱여넣는 일을 피할 수 있다.
• AI 시스템의 테스트 기준은 소프트웨어와 다르다. 한 번 통과하는 것으로는 부족하고 열 번째, 스무 번째 턴에서도 통과해야 한다.

자주 묻는 질문

관련 AI 소식