AI가 똑똑해졌는데도 왜 실패할까
요즘의 AI 모델은 몇 년 전과 비교하기 어려울 만큼 강해졌다. 긴 글을 읽고, 코드를 작성하고, 문서를 요약하고, 도구를 호출해 일을 처리한다. 그런데 현장에서 AI 파일럿을 운영해 보면 이상한 일이 자주 벌어진다. 모델은 충분히 똑똑해 보이는데 결과는 기대에 못 미친다.
고객 정보를 잘못 이해한다. 이미 말한 조건을 잊는다. 최신 정책을 모른다. 검색 결과를 가져왔지만 엉뚱한 문단을 근거로 답한다. 도구를 호출해야 할 때 호출하지 않거나, 반대로 필요 없는 도구를 반복해서 부른다. 겉으로는 "모델이 아직 부족하다"로 보이지만, 실제 원인은 다른 곳에 있는 경우가 많다.
핵심은 모델이 보는 정보다.
LLM은 추론 시점에 주어진 입력을 바탕으로 다음 토큰을 생성한다. 이때 모델 앞에 놓인 시스템 지시문, 사용자 질문, 대화 기록, 검색 문서, 도구 출력, 메모리, 업무 상태가 곧 모델의 작업 세계가 된다. IBM은 컨텍스트를 모델이 추론 시점에 접근하는 시스템 프롬프트, 사용자 질의, 외부 문서, 구조화 데이터, 대화 이력, 도구 출력까지 포함하는 것으로 설명한다1. 즉, AI가 실패할 때 우리는 먼저 이렇게 물어야 한다.
"모델은 이 일을 제대로 하기 위해 필요한 것을 실제로 보고 있었는가?"
프롬프트 엔지니어링의 성과와 한계
프롬프트 엔지니어링은 여전히 중요하다. 명확한 지시, 좋은 예시, 원하는 출력 형식, 역할 지정은 답변 품질을 크게 높인다. 단일 문서 요약, 문장 분류, 이메일 초안 작성처럼 범위가 좁고 필요한 정보가 입력 안에 이미 들어 있는 작업에서는 프롬프트만 잘 써도 충분히 좋은 결과를 얻을 수 있다.
문제는 AI 사용 방식이 바뀌었다는 점이다.
초기의 AI 활용은 대체로 한 번 묻고 한 번 답하는 방식이었다. "이 글을 요약해 줘", "이 문장을 번역해 줘", "이 코드를 설명해 줘" 같은 요청에서는 프롬프트 문장 자체가 큰 비중을 차지했다. 그러나 지금의 AI 시스템은 단순한 챗봇을 넘어 에이전트로 이동하고 있다. 에이전트는 여러 번 생각하고, 검색하고, 도구를 호출하고, 결과를 다시 읽고, 다음 행동을 정한다. 이 과정에서는 한 번의 멋진 문장보다 매 단계에서 어떤 정보를 모델에게 보여줄지가 더 중요해진다.
Anthropic은 컨텍스트 엔지니어링을 "LLM 추론 중 최적의 토큰, 즉 정보를 선별하고 유지하는 전략"으로 설명한다. 프롬프트 엔지니어링이 지시문 작성에 가깝다면, 컨텍스트 엔지니어링은 시스템 지시문, 도구, 외부 데이터, 메시지 이력, 상태를 포함한 전체 컨텍스트 상태를 관리하는 일이다2.
따라서 둘은 경쟁 관계가 아니다. 프롬프트 엔지니어링은 모델의 행동 방식을 정하는 중요한 계층이고, 컨텍스트 엔지니어링은 그 행동이 실행될 정보 환경을 설계하는 더 넓은 운영 문제다. 좋은 문장은 필요하다. 하지만 좋은 문장만으로는 부족하다. 올바른 사실, 최신 상태, 필요한 도구 설명, 이전 결정, 조직의 업무 규칙이 함께 들어와야 한다.
컨텍스트 엔지니어링은 무엇을 설계하는가
컨텍스트 엔지니어링은 "AI에게 무엇을 말할 것인가"보다 더 넓은 질문을 다룬다.
"모델이 지금 판단하기 위해 무엇을 봐야 하는가?"
이 질문에 답하려면 여러 요소를 함께 설계해야 한다.
시스템 지시문: 모델의 역할, 금지 사항, 우선순위, 출력 규칙
사용자 요청: 지금 해결해야 하는 문제
대화 이력: 최근 상호작용과 이미 합의한 조건
장기 메모리: 사용자 선호, 이전 결정, 반복되는 업무 정보
검색 결과: 문서, 데이터베이스, 지식 그래프에서 가져온 관련 지식
도구 명세와 출력: 어떤 도구를 언제 어떻게 쓰며, 그 결과가 무엇인지
업무 상태: 현재 단계, 완료된 작업, 대기 중인 승인, 권한 범위
예를 들어 "이번 고객에게 갱신 제안 메일을 보내 줘"라는 요청을 보자. 프롬프트 중심 접근은 좋은 메일 문장을 만드는 데 집중한다. 하지만 실제 기업 업무에서는 그것만으로 부족하다. 이 고객이 갱신 대상인지, 미수금이나 컴플라이언스 이슈가 있는지, 영업팀과 고객성공팀이 같은 고객을 같은 의미로 보고 있는지, 할인 권한은 누구에게 있는지, 최근 통화에서 어떤 약속을 했는지 알아야 한다.
이 정보가 없으면 AI는 그럴듯하지만 위험한 행동을 한다. 문장은 매끄럽지만 업무적으로 틀린 메일을 보낼 수 있다.
실패의 원인은 모델 밖에 있다
기업 AI 프로젝트가 파일럿 단계에서 멈추는 이유는 모델 성능 하나로 설명되지 않는다. 많은 경우 실패는 정보 환경에서 시작된다.
첫째, 맥락이 누락된다. 모델이 사용자의 초기 조건, 고객의 현재 상태, 이전 의사결정을 보지 못한다.
둘째, 지식이 오래된다. 모델의 학습 데이터에는 최신 가격, 재고, 정책, 장애 상황이 없다. 이를 외부에서 넣어 주지 않으면 모델은 추측한다.
셋째, 조직 데이터의 의미가 불명확하다. 같은 "활성 고객"이라도 영업, 재무, 고객성공 조직에서 정의가 다를 수 있다. 원천 데이터에 접근할 수 있다는 사실은 그 데이터의 의미를 이해한다는 뜻이 아니다.
넷째, 검색 결과가 부정확하다. RAG를 붙였다고 자동으로 정답이 나오지 않는다. 관련 없는 문서가 들어오거나, 중요한 문서가 빠지거나, 서로 충돌하는 문서가 함께 들어오면 모델은 흔들린다.
다섯째, 도구 사용 맥락이 부족하다. 도구 설명이 모호하거나, 비슷한 도구가 너무 많거나, 도구 출력이 정리되지 않으면 에이전트는 잘못된 API를 호출한다.
TechTarget은 기업 환경에서 컨텍스트 엔지니어링이 ERP, CRM, HR, 협업 도구에 흩어진 데이터를 단순 연결하는 문제를 넘어, 데이터가 무엇을 의미하는지와 업무 규칙을 AI가 사용할 수 있게 만드는 문제라고 설명한다3. 이 지점이 중요하다. AI에게 필요한 것은 데이터베이스 접속 권한만이 아니다. 데이터의 정의, 관계, 신뢰도, 최신성, 권한, 예외 규칙까지 포함한 의미 체계다.
컨텍스트 윈도우는 지식 창고가 아니라 RAM이다
많은 사람이 긴 컨텍스트 윈도우를 보면 "이제 모든 정보를 넣으면 되겠다"고 생각한다. 하지만 컨텍스트 윈도우는 무한한 지식 저장소가 아니다. 운영체제의 RAM에 가깝다. 지금 실행 중인 작업을 위해 임시로 올려 두는 제한된 작업 공간이다.
RAM이 크다고 해서 컴퓨터가 하드디스크 전체를 한꺼번에 올리지 않는 것처럼, AI도 모든 문서와 모든 대화와 모든 도구 출력을 한 번에 볼 필요가 없다. 오히려 너무 많은 정보는 판단을 흐린다. 관련 없는 문서가 많아지면 모델은 중요한 신호를 놓치고, 비용은 증가하며, 응답은 느려진다.
Anthropic은 긴 컨텍스트에서 모델이 집중력을 잃거나 혼란을 겪을 수 있으며, 컨텍스트는 한계가 있는 자원으로 다뤄야 한다고 설명한다2. 컨텍스트 윈도우가 커져도 문제의 본질은 바뀌지 않는다. 중요한 것은 "얼마나 많이 넣을 수 있는가"가 아니라 "다음 판단에 필요한 정보를 얼마나 정확히 넣는가"다.
컨텍스트 설계는 정확도, 비용, 지연시간을 동시에 좌우한다. 불필요한 토큰은 비용을 늘리고, 응답 속도를 늦추며, 모델의 주의를 분산시킨다. 반대로 필요한 정보가 빠지면 모델은 빈칸을 추측으로 채운다. 좋은 컨텍스트 엔지니어링은 이 두 위험 사이에서 균형을 잡는 일이다.
네 가지 기본 동작: 기록하고, 고르고, 줄이고, 분리한다
효과적인 컨텍스트 엔지니어링은 크게 네 가지 동작으로 이해할 수 있다.
Write는 중요한 정보를 외부 메모리나 스크래치패드에 기록하는 일이다. 사용자의 선호, 결정된 조건, 도구 호출 결과, 완료된 작업을 남기지 않으면 에이전트는 같은 질문을 반복하거나 이전 결정을 뒤집는다.
Select는 필요한 순간에 필요한 정보만 불러오는 일이다. 기억이 많아지는 것은 좋지만, 모든 기억을 매번 모델에게 보여주는 것은 좋지 않다. 현재 요청과 관련된 조건, 문서, 상태만 골라야 한다.
Compress는 긴 대화와 문서를 요약하고 구조화하는 일이다. 원문 전체를 넣는 대신 핵심 사실, 최신 상태, 남은 쟁점, 다음 행동을 짧고 명확하게 정리한다.
Isolate는 서로 다른 업무, 주제, 권한 범위를 분리하는 일이다. 여행 상담 맥락과 보험 상담 맥락이 섞이면 모델은 불필요한 연결을 만든다. 기업에서는 부서, 고객, 프로젝트, 보안 등급별로 컨텍스트를 나누는 일이 더 중요해진다.
이 네 가지는 단순한 팁이 아니다. 에이전트가 장기 작업을 수행하기 위한 운영 전략이다. 기록하지 않으면 이어갈 수 없고, 고르지 않으면 산만해지고, 줄이지 않으면 넘치고, 분리하지 않으면 오염된다.
챗봇에서 에이전트로 가는 길
챗봇은 질문에 답한다. 에이전트는 목표를 향해 상태를 바꾸며 움직인다. 이 차이는 컨텍스트 설계에서 나온다.
에이전트가 일을 하려면 자신이 무엇을 목표로 하는지 알아야 한다. 지금 어느 단계인지 알아야 한다. 이미 시도한 도구와 그 결과를 기억해야 한다. 실패한 이유를 다음 시도에 반영해야 한다. 사용자나 조직의 규칙을 넘지 않아야 한다. 필요할 때만 검색하고, 필요한 도구만 호출해야 한다.
이 모든 것은 모델 내부 지능만으로 해결되지 않는다. 모델이 매 순간 볼 수 있는 정보 환경을 설계해야 가능하다. 컨텍스트가 제대로 설계될 때 AI는 단순 질의응답 도구를 넘어, 목표와 상태와 기억을 이어받는 작업 시스템이 된다.
결국 컨텍스트 엔지니어링은 AI 시대의 새로운 "질문 기술"이 아니다. AI 시스템을 안정적으로 작동시키기 위한 정보 운영 능력이다. 모델이 더 똑똑해질수록 이 능력은 더 중요해진다. 같은 모델을 쓰더라도 어떤 조직은 더 정확하고 빠른 AI를 만들고, 어떤 조직은 그럴듯하지만 믿기 어려운 데모에 머문다.
차이는 모델이 아니라, 모델이 보는 세계에 있다.
참고
1IBM, What Is Context Engineering?
2Anthropic, Effective context engineering for AI agents
3TechTarget, Why context engineering is the next enterprise software priority
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.