프롬프트보다 컨텍스트 엔지니어링: AI 에이전트가 자꾸 틀리는 7가지 이유

에이전트가 틀리면 프롬프트부터 고치는 팀이 많다. 문장을 더 길게 쓰고, "절대 실수하지 마"를 붙이고, 역할을 세세하게 설명한다. 잠깐 나아지는 듯하지만 다른 입력에서 다시 무너진다.

실패 원인이 지시문 밖에 있기 때문이다. 오래된 정책 문서를 읽었거나, 이전 단계의 상태가 사라졌거나, 도구가 예상과 다른 형식으로 값을 돌려줬을 수 있다. 이 문제를 프롬프트만으로 해결하기는 어렵다.

프롬프트 엔지니어링과 컨텍스트 엔지니어링의 차이

구분	주요 질문	예시
프롬프트 엔지니어링	무엇을 어떻게 지시할까?	역할, 작업 순서, 출력 형식, 예시
컨텍스트 엔지니어링	판단 순간에 무엇을 보여주고 무엇을 숨길까?	검색 문서, 메모리, 상태, 도구 결과, 권한, 예산

좋은 프롬프트는 여전히 필요하다. 다만 실제 업무에서는 프롬프트가 전체 입력의 일부일 뿐이다.

1. 목표가 작업 단위로 잘리지 않았다

"고객 지원을 잘해라"는 목표는 너무 크다. 무엇을 완료로 볼지, 어떤 범위까지 행동할지, 사람에게 언제 넘길지가 없다.

작업을 "새 문의의 유형을 6개 중 하나로 분류하고, 관련 정책 문서 2개를 찾아 답변 초안을 만든 뒤, 환불·법무·개인정보 건은 보류한다"처럼 자르면 평가와 운영이 가능해진다.

2. 검색된 지식이 틀렸거나 오래됐다

RAG를 붙였다고 사실성이 자동으로 생기지 않는다. 중복 문서, 폐기된 정책, 제목 없는 파일, 권한이 다른 문서가 함께 검색되면 모델은 그중 그럴듯한 내용을 고른다.

문서에는 소유자, 적용 범위, 버전, 시행일, 만료 여부가 필요하다. 검색 결과에도 문서 제목과 수정일, 원문 링크를 함께 넘겨야 사람이 근거를 확인할 수 있다.

3. 컨텍스트가 너무 많아 중요한 정보가 묻혔다

컨텍스트 윈도우가 커졌다고 모든 문서를 넣는 것이 좋은 설계는 아니다. 긴 회의록, 무관한 대화, 중복 정책이 섞이면 모델이 우선순위를 잃는다.

작업 단계마다 필요한 정보만 선택하자. 분류 단계에는 분류 기준을, 답변 단계에는 관련 정책과 고객 기록을, 승인 단계에는 위험 신호와 근거를 보여주는 식이다.

4. 이전 단계의 상태가 사라졌다

장기 업무에서 대화 기록만 메모리로 쓰면 어떤 일이 완료됐는지 모호해진다. 에이전트가 같은 조사를 반복하거나 이미 보낸 메일을 다시 초안으로 만들기도 한다.

상태를 구조화하면 해결이 쉽다. 예를 들어 new → researched → draft_ready → pending_review → approved → sent처럼 단계를 저장하고, 각 전환 조건과 책임자를 정한다.

5. 도구의 입력과 출력 형식이 모호하다

"CRM에서 회사를 찾아줘"라는 도구보다 입력과 출력 스키마가 분명한 도구가 안전하다. 회사명, 도메인, 국가 중 무엇이 필수인지, 결과가 없을 때 빈 배열을 주는지 오류를 내는지 정해야 한다.

도구 결과를 자연어 한 덩어리로 돌려주기보다 ID, 출처, 날짜, 신뢰도, 오류 코드를 구조화해 반환하면 다음 단계의 판단이 안정된다.

6. 권한과 승인 조건이 컨텍스트에 없다

모델이 답을 아는 것과 실행 권한이 있는 것은 다른 문제다. 외부 발송, 결제, 데이터 삭제, 민감 정보 조회는 별도의 정책으로 다뤄야 한다.

에이전트에게 현재 사용자의 역할, 허용된 도구, 금액 한도, 금지된 대상, 승인 필요 조건을 명시적으로 제공하자. 권한 검사는 모델의 자율 판단이 아니라 시스템 코드에서도 다시 해야 한다.

7. 실패 사례가 평가셋으로 돌아오지 않는다

운영 중 생긴 오류가 Slack 대화로만 끝나면 같은 실수가 반복된다. 실패 입력, 당시 컨텍스트, 모델 출력, 사람이 수정한 결과, 오류 유형을 저장해야 한다.

이 기록을 주간 평가셋에 추가하면 프롬프트, 검색, 도구, 정책 중 어디를 고쳐야 하는지 보인다. 모델 교체는 그다음이다.

RAG만으로는 부족한 이유

RAG는 필요한 지식을 검색해 넣는 기술이다. 컨텍스트 엔지니어링은 그보다 넓다. 검색 문서뿐 아니라 현재 작업 상태, 사용자 권한, 도구 결과, 남은 비용, 이전 실패, 출력 형식을 함께 다룬다.

사내 AI가 자꾸 틀린다면 벡터DB의 Top-K를 바꾸기 전에 아래 순서로 확인해 보자.

1. 완료 조건과 금지 행동이 명확한가
2. 현재 단계에 필요한 문서만 들어오는가
3. 문서의 버전과 출처를 확인할 수 있는가
4. 상태가 대화가 아니라 데이터로 저장되는가
5. 도구의 입력과 출력이 스키마로 검증되는가
6. 권한과 사람 승인 조건이 코드로 강제되는가
7. 실패가 평가셋으로 축적되는가

작은 팀을 위한 컨텍스트 설계 문서

거창한 플랫폼보다 한 장짜리 문서로 시작할 수 있다. 아래 항목을 업무별로 적는다.

• 작업 목표와 완료 조건
• 입력 데이터와 신뢰 수준
• 검색 가능한 지식과 소유자
• 상태값과 전환 조건
• 사용 가능한 도구와 권한
• 사람 승인 조건
• 출력 스키마와 오류 코드
• 평가셋과 운영 지표

이 문서가 있으면 개발자, 현업 담당자, 경영진이 같은 실패를 다른 언어로 설명하는 일을 줄일 수 있다.

공식 참고 자료

• Anthropic: Effective context engineering for AI agents
• Anthropic: Building effective agents
• Model Context Protocol 공식 문서