프롬프트 엔지니어링을 넘어, 컨텍스트 엔지니어링으로
같은 AI인데 결과가 다른 이유는 모델에게 무엇을 보여주느냐에 있습니다. 프롬프트 다음 단계인 컨텍스트 엔지니어링의 개념과 함께 당장 실무에 적용할 수 있는 다섯 가지 설계 원칙을 실무 사례와 함께 정리했습니다.
Jul 20, 2026
2026년 7월 9일, GPT-5.6과 Grok 4.5, 그리고 OpenAI의 업무 에이전트 ChatGPT Work가 시중에 공개됐습니다. 같은 주에 Meta는 100만 토큰 컨텍스트 윈도우를 갖춘 에이전트 모델 Muse Spark 1.1을 내놓았습니다. 과거와 달리, 장편소설 열 권 안팎의 텍스트를 한 번에 읽는 모델들이 일주일 사이에 쏟아졌습니다. 그러나 이같은 획기적인 변화에도 현장의 고민은 줄지 않고 오히려 늘었습니다. AI를 통해 회사 문서 수백 장을 통째로 넣을 수 있게 된 환경이 되었지만, 인풋과 정보를 넣을수록 답이 좋아지기는커녕 흐려지는 경험을 하는 실무자가 적지 않기 때문입니다. 어제까지 잘 답하던 챗봇이 문서 몇 개 이상을 첨부하자 오래된 수치를 끌어다 쓰기 시작하고, 한 시간째 돌아가던 에이전트가 처음 지시를 잊은 듯 엉뚱한 파일을 수정하는 등. 이미 여러 기업과 조직에서 빈번하게 일어나고 있는 일들입니다. 이런 상황에서 흔한 대응은 프롬프트를 바꿔 보는 것입니다. 문구를 다듬고, 어조를 바꾸고, 중요하다는 말을 세 번 반복해 봅니다. 그래도 결과가 비슷하다면, 모델이 보고 있는 정보 전체를 점검할 차례입니다.
AI의 성능 발전이 점점 더 비대해지면서, 넣을 수 있는 정보가 많아지게 되었지만 그럴수록 무엇을 넣고 무엇을 뺄지 정하는 판단이 성능을 좌우하게 됐습니다. 그리고 이 판단을 체계적으로 다루는 기술이 컨텍스트 엔지니어링(Context Engineering)입니다. 해외 개발자 커뮤니티에서 '프롬프트 엔지니어링의 다음 단계'라는 이름으로 이 개념이 오르내리기 시작한 것이 2025년 하반기, 학술 논문과 제품 설계에 본격적으로 반영된 것이 올해 상반기입니다. 질문 문장을 다듬는 것만으로 결과를 끌어올리던 시기가 저물면서, 컨텍스트 엔지니어링이 AI 활용 역량의 중심으로 이동하고 있습니다.
질문을 다듬는 기술에서, 맥락을 설계하는 기술로
컨텍스트 엔지니어링은 AI 모델이 답을 만들 때 참조하는 입력 전체를 설계하고 관리하는 작업입니다. 여기서 입력 전체란 시스템 프롬프트, 검색으로 가져온 문서, 도구 호출 결과, 대화 이력, 저장된 메모리까지를 모두 포함합니다. 사용자가 대화창에 입력하는 질문은 이 가운데 한 조각일 뿐입니다. 모델 입장에서 보면 질문과 첨부 문서와 검색 결과는 모두 하나의 긴 입력으로 이어져 들어옵니다. 그 입력의 총합이 컨텍스트이고, 그 총합을 다루는 기술이 컨텍스트 엔지니어링입니다.
구성 요소를 두 갈래로 나눠 보면 관리 대상이 뚜렷해집니다. 하나는 작업이 바뀌어도 유지되는 고정 정보입니다. 회사의 용어집, 보고서 양식, 지켜야 할 규칙 같은 것들입니다. 다른 하나는 작업마다 달라지는 가변 정보입니다. 검색으로 가져온 문서, 도구가 반환한 데이터, 직전 대화의 흐름이 여기에 속합니다. 고정 정보는 한 번 잘 만들어 계속 쓰면 되지만, 가변 정보는 매 작업마다 무엇을 얼마나 실어 보낼지 결정해야 합니다. 실무에서 품이 드는 쪽은 후자이고, 사고가 나는 쪽도 대부분 후자입니다. 뒤에서 다룰 실무 원칙들도 결국 가변 정보를 어떻게 고르고, 어디에 두고, 언제 버릴 것인가에 대한 이야기입니다.
프롬프트 엔지니어링과의 관계부터 정리하겠습니다. 2023년과 2024년에는 저마다의 '비법같은 프롬프트' 모음이 커뮤니티마다 돌았습니다. 역할을 부여하라, 단계별로 생각하게 하라, 예시를 먼저 보여줘라. 물론, 이 기법들은 지금도 유효합니다. 문제는 질문을 아무리 정교하게 써도 모델이 함께 읽는 나머지 정보가 어긋나 있으면 답이 흔들린다는 데 있습니다. 회의에 빗대면 프롬프트 엔지니어링은 좋은 질문을 던지는 기술이고, 컨텍스트 엔지니어링은 회의 전에 참석자에게 어떤 자료를 몇 페이지로 추려 배포할지 정하는 기술입니다. 질문이 같아도 배포 자료가 다르면 회의의 결론이 달라지듯, 같은 프롬프트라도 컨텍스트 구성에 따라 모델의 답은 달라집니다. 계약서 검토를 예로 들면, '위험 조항을 찾아 달라'는 요청 문장은 누구나 쓸 수 있습니다. 결과를 가르는 것은 회사의 표준 계약 기준을 함께 넣었는지, 이전 검토 사례를 붙였는지, 검토 범위를 어느 조항까지로 한정했는지입니다. 두 기술은 대체 관계가 아니라 포함 관계에 가깝습니다. 프롬프트는 컨텍스트를 이루는 여러 재료 중 하나이고, 컨텍스트 엔지니어링은 그 재료 전체의 구성을 다룹니다.
이 구분이 2026년 들어 부쩍 중요해진 배경에는 두 가지 변화가 있습니다.
첫 번째는 컨텍스트 윈도우의 확대입니다. 2023년의 주력 모델들은 한 번에 수천에서 수만 토큰을 읽는 데 그쳤습니다. 당시에는 제한된 공간에 필요한 정보를 압축해 넣는 것이 기술이었고, 무엇을 넣을지 고민할 여지 자체가 크지 않았습니다. 지금은 사정이 다릅니다. 100만 토큰급 모델이 잇따라 나오면서 웬만한 사내 위키 전체를 통째로 넣을 수 있게 됐습니다. 그런데 전부 넣는 쪽이 오히려 손해입니다. 관련 없는 정보는 모델의 주의를 분산시키고 답의 정확도를 깎습니다. 토큰 단위로 과금되는 API 환경에서는 비용 문제이기도 합니다. 읽히지도 않을 문서 수십 장을 매 요청마다 넣으면 품질은 내려가고 비용은 올라가는 이중 손실이 생깁니다. 넣을 수 있는 양이 늘어난 만큼, 무엇을 골라낼지 판단하는 일이 성능과 비용 양쪽의 병목이 된 것입니다.
두 번째는 AI 에이전트의 확산입니다. OpenAI가 7월 9일 공개한 ChatGPT Work는 1,400개가 넘는 앱에 연결해 문서와 데이터를 끌어옵니다. Anthropic의 협업 에이전트 Claude Cowork는 60만 개 이상의 조직에서 120만 건의 세션이 실행됐다는 사용 데이터를 공개한 바 있습니다. 에이전트는 작업 중에 파일을 읽고, 웹을 검색하고, 도구를 호출합니다. 그 결과가 전부 컨텍스트에 쌓입니다. 사람이 한 문장을 입력하는 동안 에이전트는 수만 토큰 분량의 중간 산출물을 스스로 만들어 냅니다. 도구 호출이 열 번을 넘어가면 사용자가 처음에 준 지시가 검색 결과 더미에 밀려나는 일이 생깁니다. 대화창의 프롬프트로 통제할 수 있는 범위는 이 흐름의 일부에 그칩니다. 나머지 전체, 그러니까 에이전트가 무엇을 읽고 무엇을 기억한 채 다음 판단으로 넘어가는지를 관리하는 일이 컨텍스트 엔지니어링의 몫입니다.
연결 가능한 정보원 자체도 늘고 있습니다. 에이전트를 외부 도구와 연결하는 개방 표준인 모델 컨텍스트 프로토콜(Model Context Protocol, MCP)은 공개 16개월 만에 SDK 다운로드 9,700만 건을 넘었고, 국내에서도 금융 데이터 기업 쿠콘이 7월 MCP 기반 상품 30종 출시를 예고했습니다. 연결할 수 있는 데이터가 늘어난다는 것은 곧 컨텍스트에 올릴 후보가 늘어난다는 뜻이기도 합니다. 표준이 연결의 문제를 풀어 주는 동안, 무엇을 연결해 어떤 정보를 올릴지는 여전히 사용하는 조직의 몫으로 남습니다. 후보가 많아질수록 고르는 기준이 필요해집니다.
컨텍스트 엔지니어링의 효과를 보여주는 수치들
머신러닝 분야의 국제 학술대회 ICLR의 2026년 발표작 가운데 Zhang 연구진의 '에이전틱 컨텍스트 엔지니어링(Agentic Context Engineering, ACE)' 논문은 이 기술의 효과를 수치로 보여줬습니다. 연구진은 모델 자체를 바꾸지 않고 컨텍스트 구성 방식만 개선해 코딩 과제 성능을 10.6%, 금융 추론 성능을 8.6% 끌어올렸습니다. 새 모델을 기다리거나 파인튜닝에 비용을 들이지 않고도, 같은 모델에서 무엇을 어떻게 보여주느냐만 바꿔 이 정도 격차를 만들 수 있다는 뜻입니다. 모델 교체 없이 얻는 개선이라는 점에서, 도입 비용을 따져야 하는 조직에는 우선순위가 높은 선택지가 됩니다.
이 연구를 포함해 최근 논의에서 반복적으로 확인되는 관찰은 세 가지로 정리됩니다.
먼저 양보다 품질입니다. 컨텍스트에 정보를 더할수록 성능이 오르는 것이 아니라, 관련 없는 정보가 섞이는 순간부터 내려갑니다. 지난 분기 실적을 요약해 달라는 요청에 3년 치 회의록을 함께 넣으면, 모델은 오래된 수치를 최신 수치와 섞어 인용하기 시작합니다. 사람이라면 문서 날짜를 보고 걸러낼 정보를, 모델은 눈앞에 있다는 이유로 답에 반영합니다.
다음은 배치입니다. 모델은 컨텍스트의 앞부분과 끝부분에 놓인 정보를 상대적으로 잘 반영하고, 중간에 묻힌 정보를 자주 놓칩니다. 해외 연구진이 '중간에서 길을 잃는다(lost in the middle)'라는 이름으로 보고한 이래, 긴 컨텍스트를 다루는 연구에서 반복적으로 확인되어 온 현상입니다. 같은 지시라도 문서 더미 한가운데 끼워 넣으면 무시될 확률이 올라갑니다. 지시의 내용만큼 지시의 위치가 결과를 바꾸는 셈입니다. 보고서 양식을 지키라는 규칙을 첨부 문서 다섯 개 사이에 끼워 넣었다가 무시당한 경험이 있다면, 규칙의 위치부터 의심해 볼 필요가 있습니다.
마지막은 누적 오염입니다. 에이전트 작업이 길어질수록 도구 호출 결과와 중간 산출물이 쌓이면서 컨텍스트가 흐려집니다. 30분 넘게 실행되는 에이전트 작업에서 초반 지시가 잊히는 현상은 이 때문에 생깁니다. 코딩 에이전트가 버그를 고치다 실패한 시도의 로그가 컨텍스트에 그대로 쌓이면, 모델이 이미 틀렸다고 확인된 접근을 다시 꺼내 드는 일도 생깁니다. 실패 기록을 지우거나 요약으로 바꿔 주는 것만으로 같은 실수의 반복이 줄어듭니다. 오래 실행되는 에이전트일수록 이런 정리 작업이 필요해지고, 이 정리를 시스템이 대신해 주는 기능이 최근 에이전트 제품들의 경쟁 지점이 되고 있습니다.
제품 설계에서도 같은 원리가 확인됩니다. Anthropic의 코딩 에이전트 Claude Code는 프로젝트 규칙을 담은 CLAUDE.md라는 파일을 매 세션의 컨텍스트에 자동으로 포함합니다. 개발자가 같은 지시를 매번 반복하는 대신, 항상 보여줄 정보를 파일 하나에 고정해 둔 설계입니다. ChatGPT Work가 1,400개 앱의 데이터를 필요한 작업 단위로만 불러오는 방식도 어떤 정보를 언제 컨텍스트에 올릴지 시스템이 관리하겠다는 접근입니다. 두 회사가 서로 다른 경로로 같은 문제를 풀고 있습니다. 컨텍스트 엔지니어링은 이미 제품 경쟁력의 조건이 되어 있습니다.
비용 측면의 압력도 이 기술을 밀어 올리고 있습니다. 7월 들어 Anthropic이 최상위 모델의 과금을 토큰 사용량 기반으로 전환하는 등, 프론티어 모델의 사용 비용은 넣는 만큼 내는 구조로 이동하는 중입니다. 컨텍스트에서 군더더기를 덜어낼 이유가 품질에 더해 하나 더 생겼습니다.
컨텍스트 엔지니어링, 어떻게 시작하면 될까요
실무에서 컨텍스트 엔지니어링은 새 인프라 없이 시작할 수 있습니다. 도구를 새로 사거나 개발팀의 지원을 받을 필요도 없습니다. 다음 다섯 가지 원칙이 출발점입니다.
필요한 정보와 불필요한 정보를 먼저 가립니다. 작업을 시작하기 전에, 이 작업에서 모델이 반드시 알아야 할 것과 몰라도 되는 것을 나눠 봅니다. 판단 기준은 하나면 충분합니다. 이 정보가 빠지면 답이 달라지는가. 달라지지 않는다면 빼는 쪽이 낫습니다. 실적 요약을 시키면서 회사 연혁 문서까지 첨부할 이유는 없습니다. 이 구분은 한 번 해 두면 같은 유형의 작업에 계속 재사용할 수 있습니다. 첨부하기 전에 10초만 들여 이 질문을 던지는 습관이, 프롬프트 문구를 다듬는 데 쓰는 10분보다 결과를 크게 바꿉니다.
검색 결과는 추려서 넣습니다. 사내 문서 검색(RAG)을 연결한 시스템에서 흔한 실수가 검색 상위 20개 문서를 전부 넣는 것입니다. 많이 넣을수록 안전하다는 직관 때문인데, 실제로는 반대로 작동합니다. 관련도가 낮은 문서가 섞이면 모델이 엉뚱한 근거를 인용하는 빈도가 올라갑니다. 상위 서너 개로 줄이고, 대신 그 서너 개의 관련도를 높이는 데 공을 들이는 편이 결과가 좋습니다. 검색이 부정확하다면 문서를 더 넣을 것이 아니라 검색 자체를 고쳐야 합니다.
중요한 지시는 앞과 끝에 둡니다. 지켜야 할 규칙은 컨텍스트 앞부분에, 판단 기준은 질문 바로 앞에 배치합니다. 중간에 묻힌 지시는 앞서 본 대로 자주 무시됩니다. 문서를 여러 개 첨부할 때도 가장 중요한 문서를 맨 앞이나 맨 뒤에 두는 것만으로 반영률이 달라집니다. 긴 요청문을 쓸 때는 요구사항을 마지막 문단에 한 번 더 적어 주는 방법도 통합니다. 비용이 들지 않는 개선이라는 점에서 가장 먼저 시도해 볼 만한 원칙입니다.
원문 대신 요약을 씁니다. 100만 토큰이 들어간다고 해서 다 넣을 이유는 없습니다. 문서 전체 대신 핵심 단락을, 코드베이스 전체 대신 관련 함수만 추려 넣으면 비용이 줄고 정확도는 올라갑니다. 긴 대화가 이어질 때 중간 결론을 한 번 요약해 새 대화로 옮기는 것도 같은 원리의 응용입니다. 대화가 길어질수록 초반의 오해와 수정 과정까지 컨텍스트에 남아 모델을 헷갈리게 하므로, 정리된 결론만 들고 새로 시작하는 쪽이 깨끗합니다.
결과가 나쁘면 프롬프트보다 컨텍스트를 먼저 봅니다. 답이 이상할 때 질문 문장을 고쳐 쓰는 데 시간을 쓰기 쉽지만, 원인은 대개 모델이 못 본 정보에 있습니다. 모델에게 무엇을 보여줬는지 목록을 확인하고 빠진 정보를 채우는 쪽이 질문을 열 번 고치는 것보다 빠릅니다. 점검 순서를 바꾸는 것만으로 문제 해결 시간이 줄어듭니다.
다섯 원칙이 실제로 어떻게 작동하는지 장면 하나로 확인해 보겠습니다. 마케팅팀 실무자가 주간 성과 보고 초안을 챗봇에게 맡긴다고 해 보겠습니다. 처음에는 광고 대시보드에서 내려받은 파일 여섯 개와 지난 보고서 열두 개를 전부 첨부하고 '이번 주 보고서를 써 달라'고 요청합니다. 돌아온 결과물은 지난달 캠페인 수치가 이번 주 성과로 둔갑해 있는 보고서입니다. 원칙을 적용하면 준비가 달라집니다. 이번 주 데이터 파일 하나와 직전 주 보고서 하나만 남기고, 보고서 양식 규칙은 요청문 바로 앞에 붙이고, 지난 분기의 맥락은 세 줄 요약으로 대체합니다. 첨부 목록을 정리하는 데 드는 시간은 5분이 되지 않지만, 완성된 보고서에서 수치 오류를 찾아 고치는 데 드는 시간은 대개 그보다 깁니다. 같은 도구, 같은 질문에서 준비만 바꾼 결과입니다. 결과물을 고치는 사후 편집에서 재료를 고르는 사전 준비로, 힘을 쓰는 지점을 옮기는 것이 요령입니다.
이 다섯 가지는 개발자만의 이야기가 아닙니다. 챗봇 대화창에 문서를 첨부하는 사무직 실무자도 같은 원칙을 적용할 수 있습니다. 어떤 파일을 첨부하고 어떤 파일을 뺄지, 긴 문서에서 어느 부분만 발췌할지 정하는 순간마다 이미 컨텍스트 엔지니어링을 하고 있는 셈입니다. 이름이 붙기 전부터 해 오던 일에 체계가 생겼다고 보는 편이 정확합니다.
같은 AI, 다른 결과: 컨텍스트 엔지니어링이 성능을 가르는 이유
2024년의 AI 활용 역량이 좋은 질문을 만드는 능력이었다면, 2026년의 역량은 좋은 맥락을 만드는 능력으로 옮겨 가고 있습니다. 모델은 계속 커지고, 컨텍스트 윈도우는 계속 늘어나고, 에이전트는 더 많은 도구를 연결할 것입니다. 그럴수록 사람에게 남는 일은 분명해집니다. 모델이 무엇을 보고 판단하게 할지 정하는 일입니다. 국내에서도 에이전트 도입을 검토하는 조직이 빠르게 늘고 있는 만큼, 이 역량의 유무가 같은 도구를 쓰는 조직 사이의 격차로 나타날 가능성이 큽니다. 같은 모델을 구독하더라도 자기 조직의 데이터를 잘 추려 보여주는 쪽이 더 정확한 답을 받게 됩니다. 모델 접근성이 평준화될수록, 격차는 준비에서 생깁니다.
시작은 크지 않아도 됩니다. 개인 차원에서는, 지금 쓰고 있는 AI 도구에서 결과가 기대에 못 미쳤던 작업을 하나 골라 질문을 고치기 전에 모델에게 보여준 정보의 목록부터 다시 살펴보시기 바랍니다. 빠진 정보는 없었는지, 넣지 않아도 될 문서가 섞여 있지는 않았는지, 중요한 지시가 중간에 묻혀 있지는 않았는지. 팀 차원에서는 자주 반복되는 작업마다 '항상 넣을 정보'와 '넣지 말아야 할 정보'의 목록을 문서 한 장으로 정리해 두는 것부터가 출발점입니다. 정리 전과 후로 같은 작업을 한 번씩 돌려 결과를 비교해 보면, 이 기술이 조직에 얼마나 필요한지도 가늠할 수 있습니다. 컨텍스트 엔지니어링은 그 점검 한 번에서 시작됩니다.
참고 문헌
- Zhang et al., 'Agentic Context Engineering(ACE)', ICLR 2026
- OpenAI, ChatGPT Work 공개 발표 (2026.7.9)
- Anthropic, Claude Cowork 사용 데이터 공개 (2026.7)
Share article