앞선 장에서 우리는 AI의 성패를 프롬프트 한 줄만으로 설명할 수 없다는 사실을 보았다. 이제 한 걸음 더 들어가 보자. 실무에서 AI가 기대 이하의 결과를 내놓을 때, 사람들은 흔히 이렇게 말한다.
"이 모델은 원래 별로인가 봐."
물론 그럴 때도 있다. 모델 자체의 추론 능력, 최신성, 언어 처리 능력, 도구 사용 능력에는 분명 차이가 있다. 하지만 실무에서 벌어지는 많은 실패는 모델이 멍청해서가 아니라 잘못된 작업 재료를 받고 있기 때문에 생긴다.
같은 사람도 자료를 덜 받으면 틀리고, 오래된 문서를 읽으면 엉뚱한 결론을 내리고, 서로 모순되는 지시를 동시에 받으면 우왕좌왕한다. AI도 다르지 않다. 그래서 중요한 질문은 이것이다.
이 실패는 정말 모델의 한계인가, 아니면 컨텍스트 설계의 실패인가?
이 장의 목표는 바로 이 구분을 익히는 데 있다. 모델을 바꾸기 전에 먼저 무엇을 점검해야 하는지, 어떤 실패 패턴이 반복적으로 나타나는지, 그리고 왜 많은 문제의 시작점이 컨텍스트인지 이해하게 될 것이다.
모델 문제와 컨텍스트 문제는 어떻게 다른가
먼저 두 가지를 분리해서 보자.
모델 문제는 말 그대로 모델 자체의 능력 한계에서 오는 실패다. 예를 들어 복잡한 추론을 지속적으로 못 하거나, 특정 언어를 지나치게 약하게 다루거나, 긴 코드 수정 작업에서 일관성이 심하게 떨어지는 경우가 여기에 가깝다. 아무리 입력을 정리해도 일정 수준 이상 성능이 오르지 않는다면 모델 한계를 의심할 수 있다.
반면 컨텍스트 문제는 모델이 일을 잘할 수 있도록 필요한 정보와 규칙과 상태를 제대로 받지 못해서 생기는 실패다. 필요한 문서가 빠져 있을 수도 있고, 너무 많은 정보가 한꺼번에 들어왔을 수도 있으며, 최신 정책과 오래된 정책이 섞여 있을 수도 있다. 또는 출력 형식이 모호해서 결과가 들쑥날쑥할 수도 있다.
이 둘은 겉으로 보기에는 비슷하게 보인다. 둘 다 "이상한 답변"으로 나타나기 때문이다. 하지만 해결책은 완전히 다르다. 모델 문제라면 모델 교체, 모델 라우팅, 작업 분해 같은 접근이 필요하다. 컨텍스트 문제라면 입력 구조, 검색 방식, 메모리 정책, 우선순위 규칙, 도구 설명을 손봐야 한다.
실무에서 중요한 원칙은 단순하다.
결과가 이상하면 먼저 컨텍스트를 의심하고, 그다음 모델을 의심하라.
이 순서가 중요한 이유는 대부분의 시스템에서 컨텍스트는 우리가 직접 설계하고 통제할 수 있는 영역이기 때문이다. 반면 모델 자체는 바꾸는 비용이 더 크고, 바꾼다고 해서 문제가 곧바로 사라지지도 않는다.
실패는 보통 한 가지 이유로 일어나지 않는다
AI 실패를 너무 단순하게 보면 진단을 틀리기 쉽다. 예를 들어 고객지원 봇이 잘못된 환불 정책을 답했다고 해 보자. 이때 단순히 "모델이 환불 정책을 이해하지 못했다"라고 결론 내리면 원인을 놓친다.
실제로는 이런 일이 동시에 벌어졌을 수 있다. 최신 환불 정책 문서가 검색되지 않았고, 오래된 FAQ가 먼저 들어왔으며, 시스템 지시문에는 "모르는 내용은 추측하지 말라"는 규칙이 빠져 있었고, 답변 형식도 근거 표시 없이 자연어만 출력되도록 되어 있었을 수 있다.
즉, 실패는 종종 하나의 거대한 원인이 아니라 작은 설계 실수들이 겹쳐서 만들어지는 결과다. 그래서 우리는 실패를 볼 때 "무슨 기능이 없었나?"보다 "어떤 정보 흐름이 어긋났나?"를 물어야 한다.
가장 흔한 실패 패턴 1: 누락된 정보
가장 흔하고, 가장 과소평가되는 실패 원인은 정보 누락이다. 모델이 답을 못 하는 것이 아니라 답하는 데 필요한 재료를 받지 못한 것이다.
예를 들어 문서 작성 AI에게 "우리 서비스 소개서를 써 줘"라고 요청했는데 결과가 밋밋하고 추상적이라고 해 보자. 이때 많은 사람은 프롬프트를 더 길게 쓴다. "좀 더 설득력 있게, 좀 더 전문적으로, 더 구체적으로" 같은 말을 덧붙인다. 하지만 정작 빠져 있는 것은 다음과 같은 정보일 수 있다.
제품의 핵심 기능
목표 독자
경쟁사 대비 차이점
금지해야 할 표현
브랜드 톤과 예시 문장
이런 상태에서 AI가 좋은 결과를 내놓기란 어렵다. 요리를 잘하는 셰프에게도 재료가 없으면 훌륭한 식사는 나오지 않는다.
누락 문제는 특히 다음 상황에서 자주 나타난다.
RAG 시스템에서 검색이 실패했을 때
대화 기록 요약이 너무 공격적으로 압축되었을 때
작업 중간에 나온 중요한 결정 사항이 저장되지 않았을 때
도구 실행 결과가 다음 단계에 전달되지 않았을 때
사용자 의도는 분명하지만 조직의 정책 정보가 빠져 있을 때
누락된 정보의 무서운 점은, AI가 때로는 그 사실을 티 내지 않고 그럴듯하게 메워 버린다는 데 있다. 모르면 "모른다"고 말하기보다, 빈칸을 그럴듯한 말로 채워 넣는 것이다. 그래서 사용자는 모델이 실제로 알고 답한 것처럼 착각하기 쉽다.
가장 흔한 실패 패턴 2: 너무 많은 정보
많이 주면 더 잘할 것 같지만, 실제로는 그 반대인 경우가 많다. 컨텍스트가 길어진다고 해서 자동으로 성능이 좋아지지는 않는다. 오히려 중요한 규칙과 근거가 잡음 속에 묻혀 버릴 수 있다.
예를 들어 회의 요약 에이전트에 최근 3개월치 회의록 전체, 팀 채팅 일부, 과거 전략 문서, 무관한 첨부 파일까지 한꺼번에 밀어 넣었다고 생각해 보자. 사람도 그런 자료 더미 앞에서는 핵심을 찾기 어렵다. AI 역시 마찬가지다.
정보 과잉이 일으키는 문제는 크게 네 가지다.
핵심 규칙이 묻힌다.
관련 없는 정보에 주의가 분산된다.
오래된 정보가 최신 정보처럼 섞여 들어온다.
답변이 장황해지거나 애매해진다.
이 문제를 실무에서는 흔히 "다 넣었는데 왜 더 못하지?"라는 당혹감으로 만난다. 그러나 제한된 작업 공간에 모든 것을 우겨 넣는 것은 배려가 아니라 방해일 수 있다.
좋은 컨텍스트는 풍성한 컨텍스트가 아니라 필요한 것이 선명한 컨텍스트다.
가장 흔한 실패 패턴 3: 잘못된 형식
정보가 있다고 해서 충분한 것은 아니다. 정보가 모델이 쓰기 쉬운 형태로 정리되어 있어야 한다.
예를 들어 도구 호출 결과가 뒤죽박죽인 긴 로그 문자열로만 들어온다면, 모델은 그 안에서 중요한 값이 무엇인지 놓치기 쉽다. 문서 검색 결과도 마찬가지다. 제목, 출처, 날짜, 본문 조각, 관련도 정보가 구조적으로 나뉘어 있지 않으면 AI는 어떤 정보를 우선해야 할지 헷갈린다.
잘못된 형식의 전형적인 예는 이런 것들이다.
핵심 규칙이 긴 문단 속에 숨어 있음
도구 출력이 사람이 읽기 어렵게 덤프 형태로 제공됨
여러 문서가 출처 구분 없이 하나로 합쳐짐
최신 문서와 오래된 문서에 날짜 표기가 없음
출력 형식 요구가 모호해서 결과 구조가 매번 달라짐
쉽게 말해, 컨텍스트는 내용만 중요하지 않다. 배치와 구조도 성능의 일부다. 같은 정보를 주더라도 표, 섹션, 키-값 구조, 우선순위 구분, 요약 메모 형태로 정리하면 결과가 달라진다.
가장 흔한 실패 패턴 4: 충돌하는 지시와 근거
AI가 이상하게 오락가락할 때는 충돌을 의심해야 한다. 시스템 지시문은 간결하게 답하라고 하고, 사용자 요청은 자세히 설명해 달라고 하며, 내부 정책 문서는 매우 보수적인 표현만 허용하고, 예시 답변은 지나치게 친근한 톤을 보여 주는 식이다. 이렇게 서로 다른 방향의 신호가 한꺼번에 들어오면 모델은 어느 쪽을 더 따라야 할지 흔들린다.
이 충돌은 생각보다 자주 벌어진다. 특히 조직 안에서는 문서가 여러 팀에서 만들어지기 때문에 더 그렇다. 고객지원 정책 문서는 갱신되었는데 FAQ는 예전 버전일 수 있고, 제품 소개 자료는 새 메시지를 쓰는데 영업 스크립트는 옛 표현을 유지하고 있을 수 있다.
충돌 문제는 결과를 두 가지 방식으로 망가뜨린다. 하나는 모델이 임의로 한쪽을 선택하는 경우다. 다른 하나는 여러 규칙을 어설프게 타협해 어정쩡한 답을 만드는 경우다. 둘 다 실무에서는 치명적이다.
그래서 컨텍스트 설계에는 늘 우선순위가 있어야 한다. 예를 들어 시스템 규칙이 최상위인지, 최신 정책 문서가 예전 FAQ보다 우선인지, 사용자 요청이 내부 보안 규칙을 넘을 수 없는지 같은 기준이 분명해야 한다.
가장 흔한 실패 패턴 5: 컨텍스트 오염
이 장에서 특히 기억해야 할 개념이 있다. 바로 컨텍스트 오염이다. 오염은 단순히 정보가 많다는 뜻이 아니다. 컨텍스트 안으로 들어오지 말아야 할 신호가 들어와 판단을 흐리는 상태를 말한다.
오염은 여러 형태로 나타난다. 오래된 결정 사항이 계속 남아 현재 작업을 방해할 수 있고, 사용자의 추측이 사실처럼 저장될 수도 있으며, 도구가 반환한 오류 메시지가 다음 단계에서 진짜 지시처럼 작동할 수도 있다. 심지어 이전 작업의 잔여 메모가 새 작업으로 흘러들어와 전혀 다른 답을 만들기도 한다.
예를 들어 한 사용자가 "아마 우리 회사 환불 기간이 30일일 거예요?"라고 말했는데, 이 문장이 검증되지 않은 채 기억으로 저장되었다고 해 보자. 이후 챗봇은 공식 정책보다 그 기억을 더 쉽게 끌어와 잘못된 답을 반복할 수 있다. 이때 문제는 모델이 환불 규칙을 추론하지 못한 것이 아니라, 오염된 컨텍스트가 잘못된 확신을 공급한 것이다.
오염은 조용히 퍼진다. 한 번 잘못 저장된 정보가 이후 여러 응답의 근거가 되기 때문이다. 그래서 컨텍스트 오염은 단발성 오류가 아니라 시스템적 오류로 커지기 쉽다.
디스트랙션, 컨퓨전, 클래시로 보는 실패의 모습
실패를 조금 더 입체적으로 보기 위해, 실무에서 자주 쓰이는 감각적인 이름으로 정리해 보자.
디스트랙션: 주의가 엉뚱한 곳으로 가는 상태
디스트랙션은 말 그대로 산만해진 상태다. 필요한 정보는 분명 들어 있지만, 관련 없는 문장이 너무 많아서 모델의 주의가 흐트러진다.
예를 들어 사용자가 "이번 주 출시 노트만 정리해 줘"라고 했는데, 컨텍스트에는 지난달 회의 메모, 예전 출시 기록, 무관한 버그 토론, 내부 농담이 섞인 채팅 기록까지 함께 들어왔다고 하자. 그러면 모델은 중요한 최신 항목보다 주변 정보를 붙잡고 늘어질 수 있다.
이런 경우 답변은 완전히 틀리지 않을 수도 있다. 더 위험한 것은 부분적으로만 맞는, 그러나 초점이 흐린 답변이 나온다는 점이다.
컨퓨전: 어떤 정보가 진짜인지 헷갈리는 상태
컨퓨전은 정보 간 구분이 무너진 상태다. 공식 정책과 사용자 추측이 같은 무게로 놓여 있거나, 초안과 확정본이 섞여 있거나, 테스트 실패 로그와 성공 로그가 날짜 구분 없이 섞여 있으면 모델은 어떤 근거를 믿어야 할지 혼란스러워한다.
이때 모델은 완전히 엉뚱한 말을 하기보다, 모순된 내용을 한 답변 안에 함께 담는 식으로 실패하는 경우가 많다. 사람 눈에는 "왜 이렇게 말이 앞뒤가 안 맞지?"라는 느낌으로 보인다.
클래시: 지시가 정면으로 부딪히는 상태
클래시는 우선순위가 다른 규칙들이 직접 충돌하는 경우다. "간단히 답하라"와 "모든 근거를 자세히 설명하라", "절대 확신하지 말라"와 "명확하게 단정적으로 써라" 같은 지시가 동시에 존재하는 것이다.
클래시가 생기면 결과는 불안정해진다. 같은 질문에도 응답 스타일이 달라지고, 어떤 경우에는 형식을 지키고 내용을 잃고, 어떤 경우에는 내용을 지키고 형식을 무시한다.
이 세 가지를 기억해 두면, 막연히 "AI가 이상하다"라고 느끼는 순간을 좀 더 정확히 진단할 수 있다.
실패 사례를 보는 올바른 질문 순서
실패를 만났을 때는 감정적으로 모델을 탓하기 쉽다. 하지만 설계자는 순서대로 점검해야 한다. 다음 질문은 매우 실용적이다.
이 작업에 필요한 정보가 실제로 들어갔는가?
그 정보는 최신인가?
서로 충돌하는 규칙이나 문서가 섞여 있지 않은가?
관련 없는 정보가 너무 많지는 않은가?
정보가 구조적으로 정리되어 있는가?
도구 결과나 중간 산출물이 다음 단계에 제대로 전달되었는가?
기억에 저장된 내용 중 검증되지 않은 것이 없는가?
그다음에도 계속 실패하는가?
마지막 질문까지 왔는데도 문제가 계속된다면 그때 모델 한계를 진지하게 검토하면 된다. 즉, 모델 교체는 첫 번째 카드가 아니라 진단을 거친 뒤 꺼내는 카드여야 한다.
같은 모델도 왜 어떤 날은 잘하고 어떤 날은 못할까
현장에서 자주 듣는 말이 있다.
"어제는 잘했는데 오늘은 왜 이러지?"
이 현상 역시 많은 경우 모델 자체보다 컨텍스트 변화로 설명된다. 검색된 문서가 달라졌을 수 있고, 대화가 길어져 핵심 지시가 뒤로 밀렸을 수 있으며, 중간 요약이 부정확했을 수 있다. 혹은 이전 도구 호출의 실패 메시지가 이후 판단에 악영향을 줬을 수도 있다.
즉, AI는 완전히 고정된 시험문제를 푸는 기계가 아니다. 매 순간 다른 컨텍스트 위에서 일한다. 그래서 성능의 흔들림은 곧잘 입력 환경의 흔들림을 반영한다.
이 사실을 이해하면 실무 태도도 달라진다. 결과가 나빠졌을 때 막연히 "모델이 원래 그렇다"고 체념하는 대신, 이번 실행에서 어떤 컨텍스트가 조립되었는지 추적하게 된다. 이 태도 차이가 시스템 품질을 크게 갈라놓는다.
실패를 줄이는 가장 현실적인 방법
AI 실패를 완전히 없앨 수는 없다. 하지만 실패의 상당수는 컨텍스트 설계만 개선해도 줄일 수 있다. 핵심은 화려한 기법보다 기본기를 지키는 것이다.
첫째, 필요한 정보와 불필요한 정보를 구분해야 한다. 많이 모으는 능력보다 잘 고르는 능력이 중요하다.
둘째, 정보의 우선순위를 명시해야 한다. 무엇이 규칙이고, 무엇이 근거이며, 무엇이 참고 의견인지 구분해야 한다.
셋째, 컨텍스트를 구조화해야 한다. 긴 문단 더미보다 목적, 규칙, 입력 데이터, 참고 자료, 도구 결과를 나눠 주는 편이 낫다.
넷째, 오래된 정보와 검증되지 않은 기억을 관리해야 한다. 저장보다 삭제와 갱신이 더 중요할 때도 많다.
다섯째, 실패 사례를 모아 패턴으로 봐야 한다. 한 번의 이상한 답변을 운이 나빴다고 넘기면 같은 실수가 반복된다.
결국 AI 품질은 단지 모델의 IQ 같은 것으로 결정되지 않는다. 무엇을 보게 했는가, 무엇을 숨겼는가, 무엇을 믿게 했는가가 결과를 크게 좌우한다.
모델을 바꾸기 전에 먼저 의심해야 할 것
이 장의 핵심을 한 문장으로 압축하면 이렇다.
AI가 실패할 때는 모델보다 먼저 컨텍스트를 의심하라.
이 원칙은 모델을 무시하라는 뜻이 아니다. 좋은 모델 선택은 여전히 중요하다. 다만 실무에서 더 자주, 더 싸게, 더 빠르게 고칠 수 있는 것은 컨텍스트 쪽이라는 뜻이다.
필요한 정보가 빠졌는지, 너무 많은 정보가 들어갔는지, 형식이 엉망인지, 지시가 충돌하는지, 오염된 기억이 남아 있는지부터 살펴보면 의외로 많은 문제가 해결된다. 그리고 이런 점검을 반복하다 보면, AI 시스템을 보는 눈이 바뀐다. 결과만 보는 사람이 아니라 결과를 만드는 입력 조건을 읽는 사람이 된다.
바로 그 관점이 컨텍스트 엔지니어의 출발점이다.
다음 장부터는 이 실패를 줄이기 위한 재료들을 하나씩 자세히 살펴볼 것이다. 가장 먼저 다룰 것은 지시문이다. AI가 무엇을 해야 하고, 무엇을 하지 말아야 하며, 어떤 형식으로 답해야 하는지를 정하는 가장 기본적인 설계 재료부터 차근차근 다져 보자.
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.