답이 틀렸을 때, 프롬프트만 보지 말자
AI가 엉뚱한 답을 하면 가장 먼저 프롬프트를 고치려는 경우가 많다. 표현을 더 강하게 바꾸고, 금지 문구를 추가하고, 예시를 늘린다. 물론 프롬프트도 중요하다. 하지만 컨텍스트 엔지니어링 관점에서는 먼저 다른 질문을 해야 한다.
모델이 실제로 무엇을 보고 답했는가?
모델의 입력에는 사용자 질문만 들어가지 않는다. 시스템 지시, 개발자 지시, 대화 기록, 검색 결과, 메모리, 도구 설명, 이전 도구 호출 결과, 압축된 요약, 정책 문서가 함께 들어간다. 답변은 이 전체 묶음의 결과다. 따라서 잘못된 답을 디버깅하려면 최종 프롬프트 문장보다 최종 컨텍스트 묶음을 확인해야 한다.
컨텍스트 실패는 대체로 네 가지 모습으로 나타난다.
필요한 정보가 빠진다.
잘못된 정보가 들어간다.
불필요한 정보가 너무 많이 들어간다.
서로 충돌하는 정보가 동시에 들어간다.
이 네 가지를 구분하면 문제 해결 방식도 달라진다. 부족한 컨텍스트에는 검색과 질문이 필요하고, 오염된 컨텍스트에는 검증과 삭제가 필요하다. 산만한 컨텍스트에는 압축과 선택이 필요하며, 충돌하는 컨텍스트에는 우선순위 규칙이 필요하다.
불충분 컨텍스트: 정보가 없으면 모델은 빈칸을 메운다
불충분 컨텍스트는 모델이 답을 만들기 위해 필요한 핵심 정보를 받지 못한 상태다. 이때 모델은 종종 그럴듯한 추측을 한다. 우리가 흔히 말하는 환각은 모델 내부의 문제로만 생기지 않는다. 많은 경우 환각은 필요한 근거가 없는 상태에서 답변을 요구한 결과다.
예를 들어 사용자가 '지난달 매출이 왜 줄었는지 분석해줘'라고 요청했는데, 컨텍스트에는 매출 데이터만 있고 광고비, 재고, 가격 변경, 시즌 이벤트 정보가 없다면 모델은 일반적인 원인을 끌어온다. 경기 침체, 마케팅 효율 저하, 경쟁 심화 같은 말은 자연스럽지만 실제 원인일지는 알 수 없다.
이 실패는 다음과 같은 신호로 드러난다.
구체적 수치나 출처 없이 단정한다.
질문의 핵심 조건을 일반론으로 바꿔 답한다.
존재하지 않는 정책명, 문서명, 기능명을 만들어낸다.
답변은 유창하지만 검증 가능한 근거가 부족하다.
대응 전략은 단순히 '추측하지 마'라고 쓰는 것이 아니다. 모델이 추측하지 않아도 되도록 입력 구조를 바꿔야 한다.
첫째, 작업에 필요한 필수 정보 목록을 정의한다. 매출 분석이라면 기간, 비교 기준, 제품군, 채널, 가격 변화, 프로모션, 재고 상태가 필요할 수 있다. 이 목록을 컨텍스트 조립 단계의 체크리스트로 만든다.
둘째, 정보가 부족할 때는 답변보다 질문을 우선하게 한다. '현재 컨텍스트만으로는 원인을 확정할 수 없습니다. 추가로 필요한 데이터는 다음과 같습니다'라고 말할 수 있어야 한다.
셋째, 검색 기반 시스템이라면 검색 결과의 개수보다 필요 조건의 충족 여부를 본다. 문서 세 개를 찾았는지가 아니라, 질문에 답하는 데 필요한 근거가 들어 있는지를 확인해야 한다.
불충분 컨텍스트의 핵심은 이것이다. 모델이 모른다고 말하지 않는 것이 문제가 아니라, 모른다고 말할 수 있는 컨텍스트 구조가 없는 것이 문제다.
컨텍스트 포이즈닝: 잘못된 정보가 다시 입력으로 돌아온다
컨텍스트 포이즈닝은 틀린 정보가 컨텍스트 안에 들어가고, 이후 답변에 반복적으로 영향을 주는 현상이다. 한 번의 오류가 다음 오류의 재료가 된다.
발생 경로는 다양하다.
사용자가 잘못 말한 사실이 메모리에 저장된다.
모델의 이전 답변이 요약되어 이후 대화 기록으로 들어간다.
오래된 문서가 검색 인덱스에 남아 최신 문서처럼 사용된다.
검증되지 않은 도구 결과가 사실로 취급된다.
임시 추론 결과가 데이터베이스나 업무 기록에 저장된다.
특히 위험한 경우는 모델이 만든 내용을 다시 모델의 근거로 넣는 구조다. 예를 들어 고객 상담 요약을 모델이 작성하고, 그 요약이 고객 프로필 메모리에 저장된다. 그런데 요약에 잘못된 구매 이력이 들어갔다면 이후 상담에서 모델은 그 이력을 사실로 간주한다. 사용자가 정정하지 않으면 오류는 계속 살아남는다.
컨텍스트 포이즈닝을 막으려면 정보의 출처를 구분해야 한다. 모든 텍스트를 같은 등급으로 다루면 안 된다.
원본 시스템 데이터
검증된 공식 문서
사용자가 직접 입력한 주장
모델이 생성한 요약
도구가 반환한 임시 결과
이들은 신뢰도가 다르다. 컨텍스트에는 가능하면 출처, 생성 시각, 검증 상태, 만료 조건이 함께 붙어야 한다. '고객이 말했다'와 '결제 시스템에 기록되어 있다'는 전혀 다른 정보다.
또 하나의 원칙은 모델 출력물을 곧바로 사실 저장소에 넣지 않는 것이다. 모델이 만든 요약이나 분류는 편리하지만, 검증 없이 장기 메모리에 저장하면 오염원이 된다. 중요한 정보는 원본 링크를 함께 보관하고, 사용자가 정정한 내용은 이전 메모리를 무효화해야 한다.
포이즈닝 디버깅에서는 답변만 보지 말고 오류가 처음 들어온 지점을 찾아야 한다. 잘못된 답을 삭제해도, 그 답의 요약본이나 캐시가 남아 있으면 같은 문제가 반복된다.
컨텍스트 디스트랙션과 컨퓨전: 많다고 좋은 것은 아니다
컨텍스트 창이 커지면서 많은 팀이 더 많은 정보를 넣는 방향으로 움직인다. 문서를 통째로 넣고, 긴 대화 기록을 그대로 붙이고, 가능한 모든 도구 설명을 포함한다. 그러나 컨텍스트 창이 크다는 것은 많은 토큰을 넣을 수 있다는 뜻이지, 모델이 모든 정보를 같은 품질로 사용할 수 있다는 뜻은 아니다.
불필요한 정보는 모델의 주의를 흐린다. 이를 컨텍스트 디스트랙션이라고 부를 수 있다. 정보가 너무 많아 모델이 무엇을 중요하게 봐야 할지 헷갈리는 상태다. 여기서 한 단계 더 나아가면 컨텍스트 컨퓨전이 된다. 모델이 관련 없는 문서의 조건을 현재 작업에 적용하거나, 예전 대화의 요구를 현재 요청보다 우선해버린다.
대표적인 사례는 다음과 같다.
이미 해결된 과거 대화 기록이 계속 포함된다.
사용자의 현재 질문과 관련 없는 검색 결과가 함께 들어간다.
여러 도구의 긴 설명이 모두 포함되어 도구 선택이 흔들린다.
문서의 예외 조항이 본 규칙보다 더 강하게 반영된다.
압축 요약이 너무 추상적이라 중요한 조건이 사라진다.
이 문제는 프롬프트에 '중요한 것만 보라'고 쓰는 방식으로 해결하기 어렵다. 중요한 것만 들어오도록 컨텍스트를 조립해야 한다.
검색 결과는 많이 넣기보다 정확히 넣어야 한다. 상위 10개 문서를 무조건 넣는 방식보다, 질문 유형에 맞는 문서만 선택하는 방식이 낫다. 대화 기록도 전체를 보존하기보다 현재 작업에 필요한 사실, 결정 사항, 미해결 쟁점만 남겨야 한다. 도구 설명 역시 모든 인자를 길게 설명하기보다, 현재 에이전트가 선택해야 하는 도구 후보만 간결하게 제공하는 편이 좋다.
중요한 구분은 '보관'과 '주입'이다. 시스템은 많은 정보를 보관할 수 있다. 그러나 매번 모델에게 모두 주입해서는 안 된다. 컨텍스트 엔지니어링은 저장소를 크게 만드는 일이 아니라, 그중 지금 필요한 것만 꺼내는 일이다.
컨텍스트 클래시: 충돌하는 지시가 동시에 들어올 때
컨텍스트 클래시는 서로 모순되는 정보가 함께 들어온 상태다. 모델은 단순한 문장 생성기가 아니라 입력 안의 여러 지시와 근거를 조합해 답한다. 그런데 그 입력들이 서로 충돌하면 답변도 흔들린다.
예를 들어 시스템 정책에는 '할인율을 임의로 약속하지 말라'고 되어 있다. 그런데 오래된 영업 문서에는 '장기 고객에게는 20% 할인을 제안할 수 있다'고 적혀 있다. 사용자는 '지난번처럼 20% 할인해줘'라고 말한다. 이때 모델이 어느 지시를 따라야 하는지 명확하지 않으면 위험한 답을 할 수 있다.
충돌은 정책과 사용자 지시 사이에서만 생기지 않는다.
최신 문서와 오래된 문서가 서로 다르다.
법무 검토본과 초안 문서가 함께 검색된다.
사용자의 이전 요구와 현재 요구가 다르다.
시스템 지시와 도구 결과가 다른 결론을 낸다.
지역별 정책이 다른데 사용자의 지역 정보가 빠져 있다.
컨텍스트 클래시를 해결하려면 우선순위 규칙이 필요하다. 이 규칙은 모델에게 맡기기보다 컨텍스트 조립 단계에서 명시하는 것이 좋다.
예를 들면 다음과 같은 기준을 둘 수 있다.
안전 및 법적 정책은 일반 업무 문서보다 우선한다.
공식 승인 문서는 초안이나 회의 메모보다 우선한다.
최신 버전은 오래된 버전보다 우선한다.
현재 사용자 요청은 과거 대화보다 우선하되, 보안 정책을 넘을 수 없다.
출처가 불명확한 정보는 확정 근거로 쓰지 않는다.
이 규칙은 단순한 문구가 아니라 데이터 구조에 반영되어야 한다. 문서에는 버전, 승인 상태, 적용 지역, 만료일이 있어야 한다. 검색 시스템은 최신성이나 권한을 고려해야 한다. 모델에게 들어가는 컨텍스트에는 '이 문서가 왜 선택되었고 어떤 문서보다 우선하는지'가 드러나야 한다.
충돌이 해소되지 않을 때는 모델이 임의로 결정하지 않게 해야 한다. 답변은 '두 문서가 서로 다릅니다. 최신 승인 문서를 확인해야 합니다'처럼 멈출 수 있어야 한다. 좋은 컨텍스트는 답을 잘하게 만들 뿐 아니라, 답하면 안 되는 순간을 알게 한다.
디버깅은 최종 컨텍스트를 재현하는 일이다
컨텍스트 문제를 고치려면 먼저 재현 가능해야 한다. 같은 사용자 질문이라도 검색 결과, 메모리 상태, 시간, 권한, 도구 응답이 달라지면 모델 입력도 달라진다. 따라서 디버깅의 첫 단계는 당시 모델이 받은 최종 컨텍스트를 저장하는 것이다.
실무에서는 다음 순서가 유용하다.
캡처한다. 사용자 요청, 시스템 지시, 대화 기록, 검색 결과, 메모리, 도구 응답, 최종 모델 입력을 함께 남긴다.
분류한다. 실패가 부족, 오염, 산만함, 충돌 중 어디에 가까운지 판단한다.
줄여본다. 컨텍스트 블록을 하나씩 제거하며 답변이 어떻게 바뀌는지 확인한다.
최소 사례를 만든다. 오류를 재현하는 데 꼭 필요한 입력만 남긴다.
조립 규칙을 고친다. 프롬프트 문장보다 검색, 필터링, 압축, 우선순위 규칙을 수정한다.
회귀 테스트를 만든다. 같은 유형의 오류가 다시 생기지 않도록 평가 케이스로 남긴다.
이 과정에서 중요한 질문은 다음과 같다.
모델이 답에 필요한 정보를 실제로 받았는가?
받은 정보 중 틀린 사실은 없는가?
관련 없는 정보가 핵심 정보를 밀어내고 있지 않은가?
서로 충돌하는 지시나 문서가 있었는가?
모델이 충돌을 인식할 수 있도록 우선순위가 표시되었는가?
프롬프트 수정은 마지막 단계에 가까워야 한다. 컨텍스트 조립이 잘못된 상태에서 프롬프트만 강하게 만들면, 문제는 잠시 가려질 뿐이다. 오히려 더 복잡한 지시가 추가되어 새로운 충돌을 만들 수 있다.
실패를 줄이는 컨텍스트 운영 습관
좋은 컨텍스트 시스템은 한 번에 완성되지 않는다. 운영 중에 실패를 관찰하고, 실패 유형을 이름 붙이고, 조립 규칙을 계속 다듬어야 한다.
가장 기본적인 습관은 컨텍스트를 블록 단위로 보는 것이다. 시스템 지시, 사용자 요청, 검색 문서, 메모리, 도구 설명, 출력 형식을 각각 독립된 블록으로 관리한다. 그래야 어떤 블록이 문제를 일으켰는지 추적할 수 있다.
두 번째는 정보에 생명주기를 두는 것이다. 모든 메모리가 영구적일 필요는 없다. 모든 검색 문서가 항상 유효한 것도 아니다. 오래된 정보는 만료되어야 하고, 틀린 정보는 폐기되어야 하며, 임시 정보는 임시로만 남아야 한다.
세 번째는 모델의 답변보다 입력 품질을 먼저 평가하는 것이다. 좋은 답변은 좋은 컨텍스트에서 나온다. 답변 평가만으로는 원인을 찾기 어렵다. 입력된 컨텍스트가 충분했는지, 정확했는지, 간결했는지, 충돌하지 않았는지를 함께 평가해야 한다.
컨텍스트 실패는 피할 수 없는 운영 문제다. 중요한 것은 실패를 모델의 변덕으로만 보지 않는 것이다. AI가 엉뚱한 답을 했다면, 먼저 입력된 세계를 조사해야 한다. 모델은 그 세계 안에서 답한다. 우리가 해야 할 일은 그 세계를 더 정확하고, 더 작고, 더 일관되게 설계하는 것이다.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.