컨텍스트 엔지니어링: AI 에이전트가 피해야 할 네 가지 실패 유형

URL: https://www.youtube.com/watch?v=E8zCcv2HcbI
날짜: 2026-10-20
채널: Tech Bridge

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==AI 에이전트가 긴 작업을 더 신뢰성 있게 수행하려면 컨텍스트 창을 무작정 키우기보다, 각 단계에 필요한 정보만 남기고 잘못되거나 불필요한 정보를 검증·압축·선별·정리해야 한다.==

• 최근 연구에서 프런티어 모델 18종 모두 컨텍스트 창이 커질수록 신뢰성이 낮아졌다.
• 컨텍스트 안의 모든 토큰은 유한한 주의(attention) 자원을 두고 경쟁한다.
• 컨텍스트 실패는 포이즈닝(poisoning), 디스트랙션(distraction), 컨퓨전(confusion), 클래시(clash) 네 유형으로 나타나며, 각각 검증(validate), 압축(compact), 큐레이션(curate), 정리(prune)로 다룬다.

AI 에이전트에게 백만 토큰 이상의 컨텍스트 창(context window)을 제공하면 더 많은 지시와 도구 결과를 담을 수 있지만, 정보량 증가가 성능 향상을 보장하지 않는다. 오히려 오래된 이력, 잘못 기록된 결론, 과도한 도구 선택지, 서로 모순되는 상태가 한 창에 쌓이면 에이전트의 판단이 흔들린다. 컨텍스트 엔지니어링(context engineering)은 에이전트 실행의 매 단계마다 무엇을 창 안에 넣을지 결정하는 일이며, 네 가지 실패 유형에 대응하는 공통 원리는 필요한 정보에 집중하도록 불필요한 정보를 버리는 것이다.

1. 컨텍스트 창이 커져도 신뢰성이 저절로 높아지지 않는다

에이전트의 장기 작업 성능은 컨텍스트의 크기보다 그 안에 들어간 정보의 품질과 구성에 좌우된다.

1.1. 컨텍스트 로트(context rot)의 등장

1. 더 큰 창이 만든 기대와 실제 결과

   1. 용량의 급격한 확장: 컨텍스트 창은 수천 토큰 수준에서 백만 토큰 이상으로 커졌고, 이에 따라 더 많은 지시·도구 결과·문서를 넣을 수 있게 됐다.
   2. 성능에 대한 직관: 정보를 더 많이 넣으면 장시간 작업도 더 잘할 것이라는 기대가 생기지만, 큰 창 자체가 에이전트의 신뢰성을 보장하지는 않는다.

2. 프런티어 모델 18종의 관찰 결과

   1. 신뢰성 저하: 최근 연구는 프런티어 모델 18종을 살펴봤으며, 조사한 모든 모델에서 컨텍스트 창이 커질수록 신뢰성이 떨어졌다.
   2. 컨텍스트 로트라는 이름: 토큰이 늘어날수록 창 안의 개별 정보를 모델이 덜 안정적으로 사용하는 현상을 컨텍스트 로트(context rot)라고 부른다.

3. 컨텍스트 엔지니어링의 역할

   1. 단계별 구성 결정: 컨텍스트 엔지니어링은 에이전트 실행의 각 단계에서 실제로 무엇을 컨텍스트 창에 넣을지 결정하는 일이다.
   2. 문제의 초점: 창의 최대 크기를 키우는 것만이 아니라, 그 순간의 작업에 맞는 정보만 모델이 읽고 활용하게 만드는 것이 핵심이다.

1.2. 데이터베이스 드라이버 교체 에이전트의 컨텍스트 구성

1. 작업에 앞서 주어지는 지시와 설정

   1. 시스템 프롬프트(system prompt): 에이전트가 일반적으로 어떻게 동작해야 하는지를 정하는 상시 지침이 컨텍스트 앞부분에 들어간다.
   2. 작업 프롬프트(task prompt): 오래된 코드베이스를 새 데이터베이스 드라이버로 이전하라는 실제 업무 지시는 짧게는 몇 줄로 주어질 수 있다.
   3. 프로젝트 지침: AGENTS.md 같은 파일은 특정 프로젝트의 구성과 작업 규칙을 알려준다.
   4. 도구 정의(tool definitions): 에이전트가 호출할 수 있는 각 도구의 설명도 실제 사용 여부와 무관하게 컨텍스트에 포함될 수 있다.

2. 실행 중 쌓이는 이력과 결과

   1. 메시지 이력(message history): 에이전트가 수행한 단계와 주고받은 메시지가 실행 로그처럼 누적되며, 한 시간 동안 작업하면 상당한 분량이 된다.
   2. 도구 결과(tool results): 파일 내용, 테스트 출력, 오류 로그, 데이터베이스 스키마 덤프 같은 결과가 대량으로 쌓이고, 대개 컨텍스트에서 가장 큰 부분을 차지한다.
   3. 정보량의 편중: 실제 업무를 지시하는 프롬프트는 앞쪽의 몇 줄에 불과할 수 있지만, 이후에는 작업 중 쌓인 기록과 결과가 컨텍스트 대부분을 차지한다.

3. 에이전트가 스스로 남긴 메모의 위험

   1. 메모의 내용: 새 드라이버는 실패한 연결을 자동 재시도하므로 기존 재시도 코드를 삭제해도 된다는 메모가 컨텍스트에 들어 있다.
   2. 이후에 드러날 오류: 이 메모는 드라이버 문서를 대충 훑고 잘못 해석해 만든 결론이며, 뒤에서 포이즈닝 사례와 클래시 사례의 공통 원인이 된다.

1.3. 주의(attention)는 무한하지 않다

1. 컨텍스트는 데이터베이스 조회와 다르다
   1. 행 단위 검색이 아님: 모델은 컨텍스트에서 필요한 내용을 데이터베이스가 행을 찾듯 정확히 조회하지 않는다.
   2. 토큰 간 경쟁: 창 안의 모든 토큰이 유한한 주의 자원을 두고 경쟁하므로, 창에 백만 토큰이 들어가도 그 모든 정보를 똑같이 잘 활용할 수는 없다.

2. 에이전트 컨텍스트를 망가뜨리는 네 가지 실패 유형

컨텍스트 실패는 잘못된 사실, 과거 이력의 과도한 영향, 불필요한 도구 선택지, 상충하는 기록으로 나뉜다.

2.1. 컨텍스트 포이즈닝(context poisoning): 오류가 사실처럼 굳어짐

1. 틀린 결론이 컨텍스트에 들어오는 과정

   1. 잘못된 문서 해석: 에이전트가 새 데이터베이스 드라이버 문서를 대충 읽고, 실패한 연결은 자동으로 재시도된다고 잘못 이해한다.
   2. 오류의 기록: 에이전트는 그 오해를 자기 메모로 저장해 기존 재시도 코드를 삭제해도 된다고 결론 내린다.
   3. 자기 메모에 대한 과신: 모델에게 자신이 작성한 메모도 근거 자료처럼 보이므로, 틀린 메모가 검증된 사실인 것처럼 취급된다.

2. 후속 작업으로 번지는 피해

   1. 정상 코드의 삭제: 새 드라이버가 실제로 재시도를 제공하지 않는데도 에이전트는 코드 파일마다 기존 재시도 로직을 제거할 수 있다.
   2. 실수의 지속성: 잘못된 결론이 컨텍스트 안에 남아 후속 판단의 전제가 되면서 한 번의 오독이 연속적인 코드 변경으로 번진다.

2.2. 컨텍스트 디스트랙션(context distraction): 긴 이력이 판단을 끌고 감

1. 과거 행동의 패턴이 강해지는 이유

   1. 패턴 이어쓰기 성향: 언어 모델은 본질적으로 앞선 패턴을 이어 가는 기계이며, 한 시간 동안의 에이전트 행동 이력은 컨텍스트에서 매우 강한 패턴이 된다.
   2. 학습된 추론을 압도하는 이력: 쌓인 과거 행동이 학습 과정에서 얻은 추론보다 다음 행동을 더 강하게 이끌 수 있다.

2. 현재 목표에서 벗어나는 결과

   1. 다음에 필요한 일보다 과거의 연장: 에이전트는 작업에 지금 무엇이 필요한지 판단하기보다 메시지 이력에서 이미 했던 행동을 더 수행할 수 있다.
   2. 제자리걸음: 이 상태의 에이전트는 같은 작업을 다시 훑거나 이미 지나간 영역을 반복하는 데 갇힐 수 있다.

2.3. 컨텍스트 컨퓨전(context confusion): 도구가 너무 많아 선택이 어려워짐

1. 사용하지 않는 도구 정의도 선택지를 늘린다

   1. 넓은 도구 연결: 데이터베이스 이전 에이전트에 버전 관리, 데이터베이스 콘솔, 티켓 관리 시스템 등 여러 도구가 연결될 수 있다.
   2. 실사용 여부와 무관한 노출: 각 도구 정의가 실제로 쓰이지 않더라도 컨텍스트 창에 들어가며, 도구가 많아질수록 올바른 도구를 고르기 어려워진다.

2. 도구 수에 따른 벤치마크 차이

   1. 46개 도구 조건: 한 벤치마크에서 모델은 도구 46개가 제공된 조건에서 작업에 실패했다.
   2. 19개 도구 조건: 같은 모델이 같은 작업을 도구 19개만 제공받은 조건에서는 통과했다.
   3. 도구 팽창(tool sprawl): 이 차이는 작업과 관계없는 도구까지 한꺼번에 노출하는 것이 수행을 방해할 수 있음을 보여준다.

2.4. 컨텍스트 클래시(context clash): 서로 모순되는 정보가 함께 남음

1. 정정된 사실과 낡은 메모가 공존함

   1. 실행에서 오류가 드러남: 자동 재시도된다는 메모와 달리 실제로 재시도가 일어나지 않으면 에이전트는 기존 결론이 틀렸음을 알아차릴 수 있다.
   2. 정정 기록의 추가: 에이전트가 메시지 이력에 메모가 잘못됐다는 사실을 적더라도, 원래의 잘못된 메모는 창에 그대로 남을 수 있다.

2. 모순된 상태가 판단을 어렵게 함

   1. 두 버전의 동시 노출: 컨텍스트에는 재시도가 자동으로 된다는 정보와 그렇지 않다는 정보가 동시에 존재한다.
   2. 포이즈닝과의 차이: 포이즈닝은 잘못된 결론이 사실처럼 저장되는 문제이고, 클래시는 서로 다른 시점의 정보가 함께 남아 서로 충돌하는 문제다.

3. 네 가지 실패에 맞춘 네 가지 정리 방법

각 실패 유형에는 정보가 들어오거나 쌓이고 노출되는 방식을 바꾸는 대응이 있으며, 모두 컨텍스트에서 무언가를 덜어낸다.

3.1. 포이즈닝에는 검증(validate)을 적용한다

1. 기록 전 근거 확인

   1. 실제 자료와 대조: 결론을 컨텍스트에 기록하기 전에 문서나 동작처럼 확인 가능한 근거와 맞는지 검사한다.
   2. 빠른 연결 시험: 새 드라이버의 재시도 동작을 한 번 간단히 연결 시험으로 확인했다면, 자동 재시도를 잘못 믿는 메모를 남기지 않았을 것이다.

2. 오류가 후속 행동의 전제가 되지 않게 함

   1. 사실과 추측의 분리: 확인되지 않은 해석을 확정된 사실처럼 저장하지 않는다.
   2. 연쇄 삭제 방지: 기록 전 검증을 거치면 잘못된 메모를 근거로 기존 재시도 코드를 지우는 연쇄 실수를 막을 수 있다.

3.2. 디스트랙션에는 압축(compact)을 적용한다

1. 긴 이력을 짧은 상태로 바꿈

   1. 요약으로 새로 시작: 메시지 이력이 지나치게 길어지면 전체 로그를 버리고 그 내용을 요약한 짧은 버전에서 작업을 이어 간다.
   2. 목표와 진행 상황 보존: 압축은 전체 대화를 유지하는 대신 현재 작업을 이어 가는 데 필요한 핵심 상태를 남긴다.

2. 요약의 손실과 외부 보관

   1. 정보 손실: 압축은 손실이 있는 변환이며, 요약을 다시 요약하면 복사본을 거듭 복사한 것처럼 내용이 조금씩 달라질 수 있다.
   2. 영속 파일 활용: 상세 기록은 가능한 한 컨텍스트 밖의 영속 파일에 보존한다.
   3. 필요할 때만 불러오기: 파일에 보존한 세부 정보는 실제로 필요해지는 시점에 컨텍스트로 가져온다.

3.3. 컨퓨전에는 큐레이션(curate)을 적용한다

1. 작업에 필요한 도구만 노출

   1. 선택지 축소: 데이터베이스 이전에 46개 도구가 필요하지 않다면 업무에 필요한 몇 개만 우선 제공한다.
   2. 필요한 도구의 지연 제공: 처음부터 모두 노출하는 대신, 다른 기능이 실제로 필요해졌을 때 추가 도구를 가져오게 한다.

2. 정확한 도구 선택을 돕는 구성

   1. 도구 팽창 억제: 작업과 관련 없는 정의를 컨텍스트에서 제외하면 불필요한 선택 부담을 줄인다.
   2. 유연성 유지: 처음 제공하는 도구를 줄여도 필요할 때 추가로 불러올 수 있으므로 업무 범위를 좁게 출발할 수 있다.

3.4. 클래시에는 정리(prune)를 적용한다

1. 대체된 정보를 제거

   1. 낡은 버전 삭제: 어떤 정보가 새 정보로 대체되면 두 버전을 함께 남기지 말고 이전 버전을 삭제한다.
   2. 모순의 근원 제거: 자동 재시도에 대한 잘못된 메모를 완전히 없애면 기존 기록과 정정된 기록이 충돌하지 않는다.

2. 정정된 상태로 새 창을 시작

   1. 깨끗한 컨텍스트 구성: 더 확실한 방법으로는 새 컨텍스트 창을 시작하고, 수정된 현재 상태만 다시 적는다.
   2. 오염된 이력 차단: 이전 창에 남은 잘못된 정보는 새 창에 옮기지 않아 상충하는 옛 전제를 차단한다.

주요 발언 모음

“창에는 백만 토큰이 들어갈 수 있지만, 그 토큰들에 퍼지는 주의는 유한하다.”

“에이전트는 더 적은 것을 보유함으로써 긴 작업을 더 잘할 수 있다.”

“작업이 필요로 하는 것보다 도구가 많다면 그것은 컨퓨전이며, 해결책은 큐레이션이다.”

핵심 데이터 & 수치

• 프런티어 모델 18종: 조사한 모든 모델에서 컨텍스트 창이 커질수록 신뢰성이 낮아졌다.
• 백만 토큰 이상: 최근 컨텍스트 창의 크기를 설명하며, 용량 증가가 주의 자원의 무한함을 뜻하지는 않는다.
• 도구 46개 대 19개: 한 벤치마크에서 모델은 46개 도구 조건의 작업에 실패하고, 같은 작업을 19개 도구 조건에서는 통과했다.
• 한 시간의 실행 이력: 에이전트의 메시지 이력이 작업 중 커져 과거 행동이 강한 패턴으로 작용할 수 있는 예시다.
• 한 번의 연결 시험: 새 드라이버의 재시도 여부를 검증해 잘못된 메모를 막을 수 있는 간단한 확인 방법이다.

결론 및 시사점

1. 포이즈닝은 검증한다: 결론을 기록하기 전에 실제 문서와 동작을 확인해 잘못된 메모가 사실로 굳지 않게 한다.
2. 디스트랙션은 압축한다: 긴 이력은 필요한 상태만 요약하고, 상세 기록은 외부 파일에 둔 뒤 필요할 때 불러온다.
3. 컨퓨전은 큐레이션한다: 당장 필요한 도구만 제공하고 나머지는 필요가 생길 때 추가한다.
4. 클래시는 정리한다: 폐기된 정보를 제거하거나 정정된 상태만 담은 새 컨텍스트를 시작한다.
5. 적게 보유해 더 잘 수행한다: 네 가지 대응은 모두 불필요하거나 해로운 정보를 버려 에이전트가 현재 작업에 집중하도록 만든다.
6. 경험을 공유한다: 각자가 에이전트 컨텍스트를 가볍게 유지하는 방법을 찾아 나누는 것이 다음 개선으로 이어질 수 있다.