컨텍스트 엔지니어링이란 무엇인가
컨텍스트 엔지니어링은 AI 모델이 작업을 잘 수행하는 데 필요한 모든 것을, 모델이 실행되기 전에 결정하고 조립해 전달하는 실천입니다. 시스템 프롬프트, 첨부하는 문서, 모델이 당신에 대해 기억하는 내용, 호출할 수 있는 도구, 그리고 대화에 이미 쌓여 있는 내용이 전부 여기에 들어갑니다. 프롬프트 엔지니어링은 문장 하나를 다듬습니다. 컨텍스트 엔지니어링은 입력 스택 전체를 다듬습니다.
현재 통용되는 정의 중 가장 압축적인 것은 Anthropic의 것입니다. "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference"(LLM 추론 과정에서 최적의 토큰, 즉 정보 집합을 큐레이션하고 유지하기 위한 전략의 총체). 이들이 제시한 지침은 외워둘 만합니다. 제대로 하고 있는지 판별하는 시험지 역할도 하기 때문입니다. "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome"(원하는 결과가 나올 가능성을 극대화하는, 가능한 한 가장 작은 고신호 토큰 집합)을 찾으라는 것입니다. (Anthropic, 2025)
새로 합류한 컨설턴트에게 브리핑하는 장면을 떠올려 보십시오. 나쁜 브리핑은 한 줄짜리 이메일입니다. 좋은 브리핑에는 회사 배경, 관련 이력, 필요한 파일, 이해관계자가 누구인지, 성공의 모습은 무엇인지, 범위 밖은 어디까지인지가 담깁니다. 뛰어난 컨설턴트를 데려와도 브리핑이 부실하면 결과물은 평범해집니다. AI도 똑같습니다.
정의에 들어 있지 않은 것에 주목하십시오. 바로 '영리함'입니다. 마법 같은 표현도, 더 좋은 모델을 불러내는 비밀 단어도 없습니다. 이 일은 주문을 외는 것보다 편집에 가깝습니다. 대화가 시작되기 전에 무엇을 그 방 안에 들일지, 그리고 그만큼 중요하게도 무엇을 들이지 않을지를 결정하는 일입니다.
이름을 붙인 트윗
2025년 6월 19일, Shopify의 CEO인 Tobi Lütke는 X에 "프롬프트 엔지니어링"보다 "컨텍스트 엔지니어링"이라는 용어를 선호한다고 올렸습니다. 그는 이를 "the art of providing all the context for the task to be plausibly solvable by the LLM"(LLM이 그럴듯하게 풀어낼 수 있도록 작업에 필요한 모든 컨텍스트를 제공하는 기술)이라고 표현했습니다. 엿새 뒤, AI 분야에서 가장 존경받는 목소리 중 하나인 Andrej Karpathy가 이 용어를 널리 퍼뜨렸습니다. 그의 정의는 한층 날카로웠습니다. "context engineering is the delicate art and science of filling the context window with just the right information for the next step"(컨텍스트 엔지니어링은 다음 단계에 딱 맞는 정보로 컨텍스트 윈도우를 채우는 섬세한 기술이자 과학이다). (Karpathy, 2025)
표현 자체가 새로운 것은 아니었습니다. 자율 코딩 에이전트 Devin을 만든 팀인 Cognition의 Walden Yan은 일주일 앞선 6월 12일에 "Don't Build Multi-Agents"를 발표하면서, 컨텍스트 엔지니어링을 "effectively the #1 job of engineers building AI agents"(사실상 AI 에이전트를 만드는 엔지니어의 1순위 업무)라고 불렀습니다. 다만 이 라벨이 주류로 올라선 계기는 Lütke와 Karpathy의 게시물이었습니다. 그다음 달 Gartner는 "Lead the Shift to Context Engineering as Prompt Engineering Fades"라는 제목의 보고서를 냈고, 요약 문장은 직설적이었습니다. "Context engineering is in, and prompt engineering is out."(컨텍스트 엔지니어링이 들어오고, 프롬프트 엔지니어링은 나갑니다.) 함께 실린 Gartner의 전망은 이렇습니다. 2028년까지 AI 애플리케이션을 만드는 데 쓰이는 소프트웨어 도구의 80퍼센트에 컨텍스트 엔지니어링 기능이 내장되고, 에이전틱 AI의 정확도가 최소 30퍼센트 향상된다는 것입니다. (Gartner, 2025)
일어난 일은 리브랜딩이 아니었습니다. 교정이었습니다. AI 커뮤니티는 "프롬프트 엔지니어링"이라 불리던 기술이 사실은 처음부터 더 큰 무언가의 부분집합이었고, 이제 그 부분집합은 더 이상 흥미로운 부분이 아니라는 사실을 조용히 인정했습니다. 프롬프트는 구성 요소 하나입니다. 컨텍스트는 방 전체입니다.
이것이 중요한 이유는 지식 노동자들이 2년 동안 엉뚱한 것을 배워왔기 때문입니다. 프롬프트 템플릿을 외웠습니다. "궁극의 프롬프트" 트위터 스레드를 모았습니다. 프롬프트를 주문처럼 다뤘습니다. 그 노력이 쓸모없지는 않지만, 이제 그것만으로는 부족합니다. 질문은 요청을 어떻게 표현하느냐가 아닙니다. 질문은 요청 옆에 무엇을 놓느냐입니다.
프롬프트 엔지니어링은 정말 죽었나
짧게 답하면, 직함은 죽었고 기법은 죽지 않았습니다.
이 변화를 옛것은 전부 틀렸다는 식의 세대교체로 다루기 쉽습니다. 게으른 프레이밍입니다. 사고의 연쇄(chain-of-thought), 소수 예시(few-shot), 역할 부여, 명시적인 출력 형식은 모두 여전히 효과가 있고, 잘 설계된 컨텍스트 안에도 그대로 등장합니다.
바뀐 것은 천장입니다. 2023년에는 잘 다듬은 프롬프트 하나가 응답 품질을 두 배로 끌어올릴 수 있었습니다. 기반 모델이 모호함에 쉽게 흔들렸기 때문입니다. 문장 구조만 잘 잡으면 GPT-3.5를 어리바리한 인턴에서 조리 있는 분석가로 바꿀 수 있었습니다. 그 격차는 실재했고, 프롬프트 엔지니어링은 그 격차를 파고들었습니다.
2026년의 프론티어 모델에는 그렇게 손을 잡아 이끌어 줄 필요가 없습니다. Claude Opus 5, GPT-5.6, Gemini 3.1 Pro는 모호한 요청도 상당히 잘 처리합니다. 표현을 다듬는 데서 오는 한계 수익은 떨어졌습니다. 반면 관련 원자료, 범위가 정해진 메모리, 잘 고른 예시를 공급하는 데서 오는 한계 수익은 가파르게 올랐습니다. 지렛대가 옮겨간 것입니다.
비교를 정리하면 다음과 같습니다.
| 구분 | 프롬프트 엔지니어링 | 컨텍스트 엔지니어링 |
|---|---|---|
| 무엇을 다듬는가 | 요청의 표현 | 모델에 투입되는 입력 스택 전체 |
| 기본 단위 | 문장 하나 | 묶음: 시스템 프롬프트, 문서, 메모리, 도구, 대화 기록 |
| 누구를 위한 것인가 | 채팅창을 쓰는 모든 사람 | 결과물 품질이 AI에 달린 모든 사람 |
| 필요한 역량 | 좋은 글쓰기, 패턴 인식 | 큐레이션, 정보 설계, 판단력 |
| 실패하는 지점 | 모델이 지시를 오해합니다 | 모델은 잘 이해했지만 답할 사실, 예시, 이력이 없습니다 |
| 막혔을 때의 해법 | 다시 쓰기, 예시 추가, 출력 형식 지정 | 맞는 자료 추가, 틀린 자료 제거, 메모리 조정, 검색 범위 축소 |
| 전성기 | 2022년부터 2024년까지 | 2025년 이후 |
마지막 행을 눈여겨보십시오. 프롬프트 엔지니어링은 틀려서 죽은 것이 아닙니다. 병목이 다른 곳으로 옮겨갔기 때문에 죽었습니다.
컨텍스트 엔지니어링도 죽었나
짧게 답하면, 라벨은 흐려지고 있고 실천은 그렇지 않습니다.
반발은 하나의 장르가 될 만큼 뚜렷합니다. Joe Reis는 2026년 3월 "Gartner Declares 2026 The Year of Context™"를 발표하며, 컨텍스트 엔지니어를 "data engineer, ontologist, librarian, corporate anthropologist, and therapist"(데이터 엔지니어, 온톨로지스트, 사서, 기업 인류학자, 그리고 심리 상담사)의 혼합물로 묘사하면서 실제 업무는 "updating a YAML file"(YAML 파일 업데이트)이라고 비꼬았습니다. 농담을 걷어내면 세 가지 반론이 남고, 그중 둘에는 진실이 담겨 있습니다.
"모델이 알아서 흡수할 것이다." 이제 에이전트 하네스가 압축, 검색, 메모리를 자동으로 처리하므로 사람이 컨텍스트를 신경 쓸 필요가 없다는 주장입니다. 여기에는 실질이 있습니다. 자동 압축과 적시(just-in-time) 검색은 수작업의 한 범주를 실제로 제거했습니다. 하지만 자동화는 일을 없앤 것이 아니라 옮겼습니다. 메모리 파일에 무엇을 넣을지, 검색기가 어떤 소스를 건드려도 되는지, 에이전트에게 무엇을 무시하라고 말할지는 여전히 사람이 정합니다. 배관은 자동화되었습니다. 판단은 그렇지 않았습니다.
"결국 좋은 입력을 뜻하는 유행어일 뿐이었다." 절반은 맞습니다. 입력을 잘 고르는 일은 새로운 아이디어가 아니고, 컨텍스트 제품을 파는 업체들이 이 용어를 거의 모든 것에 갖다 붙인 것도 사실입니다. 하지만 이름을 붙이면 사람들이 그것을 대하는 태도가 달라집니다. 2023년에는 아무도 자신의 AI 입력을 체계적으로 점검하지 않았습니다. 지금은 많은 팀이 그렇게 하고, 그 이유는 이름이 실천에 형태를 주었기 때문입니다.
"컨텍스트 부식이 있으니 엔지니어링으로 빠져나갈 수 없다." 이건 거꾸로 된 주장입니다. 입력이 커질수록 모델이 나빠진다는 사실은 의도적인 컨텍스트 작업을 반대하는 근거가 아니라 찬성하는 근거입니다. 컨텍스트가 많을수록 늘 좋다면 큐레이션은 무의미할 것이고, 전부 쏟아부으면 그만일 것입니다.
2026년 중반 시점의 정직한 판단은 이렇습니다. 이 표현은 과열의 정점을 지났고, 독립된 "컨텍스트 엔지니어" 직함은 표준이라기보다 이제 막 생겨나는 중입니다. Adobe는 정확히 그 이름의 직무를 채용 공고에 올리지만, 대부분의 회사에서는 이 일이 기존 AI, 데이터, 플랫폼 엔지니어링 직무 안에 들어가 있습니다. 그 아래에 깔린 실천은 그 어느 때보다 자리를 잡았습니다. 라벨은 "반응형 디자인"이 그랬듯 배경으로 스며들며, 유능한 작업의 기본 정의 안으로 흡수될 것입니다.
컨텍스트의 여섯 계층
컨텍스트 엔지니어링을 의도적으로 하려면 자신이 무엇을 설계하고 있는지 알아야 합니다. 현대의 모든 AI 상호작용은 당신이 의식하든 하지 않든 여섯 개 계층에서 재료를 끌어옵니다. 기술이란 그중 어느 것을 조정할지 아는 일입니다.
| 계층 | 역할 | 예시 |
|---|---|---|
| 시스템 프롬프트 | 모델이 누구이고, 어떤 규칙을 따르며, 어떤 어조를 쓰는지 정의합니다 | 저장소에 둔 claude.md 파일, Cursor의 .cursorrules, 또는 "너는 시니어 에디터다. 능동태를 선호해라. 엠 대시(em-dash)는 절대 쓰지 마라." 같은 커스텀 GPT 지시문 |
| 지속 메모리 | 대화를 넘어 모델이 당신에 대해 기억하는 것 | 직업, 글쓰기 스타일, 진행 중인 프로젝트를 저장하는 ChatGPT의 메모리 기능 |
| 검색 (RAG) | 필요할 때 더 큰 지식 베이스에서 관련 조각을 끌어옵니다 | AI에게 "지난달에 네트워크 효과에 대해 내가 뭘 하이라이트했지?"라고 묻고 정확한 구절을 받아오는 것 |
| 도구 사용 | 모델이 행동을 하거나 실시간 데이터를 가져오게 합니다 | 모델이 계산기를 호출하고, 코드를 실행하고, 웹을 검색하고, 캘린더를 조회하는 것 |
| 첨부 | 이번 세션에만 올린 파일, 이미지, URL | 검토받으려고 올린 PDF 계약서, 디버깅하려고 붙여넣은 스크린샷 |
| 대화 기록 | 이 스레드에서 이미 오간 내용 | 현재 메시지 위쪽의 주고받음, 앞서 나온 수정 요청과 선호까지 포함 |
잘 설계된 컨텍스트는 여섯 계층을 모두 의도적으로 씁니다. 잘못 설계된 컨텍스트는 모든 것을 한 계층(대개 첨부, 자주 대화 기록)에 쏟아붓고 모델이 알아서 정리해주기를 바랍니다.
대부분의 지식 노동자가 저지르는 실수는 AI를 채팅 인터페이스로 대하는 것입니다. 실제로는 컨텍스트 조립기인데 말입니다. 답을 결정하는 요소는 당신이 타이핑을 시작하는 시점에 이미 거의 다 정해져 있습니다.
개인의 정보 설계가 AI의 유용성을 어떻게 좌우하는지에 대한 관련 논의는 개인 컨텍스트 관리를 참고하십시오.
컨텍스트 윈도우가 커지면서 왜 더 나빠졌나
2023년에는 100K 토큰 컨텍스트 윈도우가 이례적이었습니다. 2026년에는 100만 토큰이 평범한 기준선입니다. GPT-5.6이 약 1,050,000, Gemini 3.6 Flash가 1,048,576, Claude Opus 5가 1,000,000입니다. Llama 4 Scout은 1,000만을 내걸고 있습니다. 전쟁과 평화 전문을 한 프롬프트에 여러 번 넣을 수 있습니다. 그러니 컨텍스트 엔지니어링이 쉬워지고 있다고 생각하는 것도 자연스럽습니다. 공간이 넉넉해졌으니 선별할 일도 줄어들 것 같지 않습니까?
아닙니다. 더 어려워졌습니다.
이 분야의 기초 논문은 TACL에 실린 Liu et al. (2024)의 "Lost in the Middle: How Language Models Use Long Contexts"입니다. 연구진은 긴 컨텍스트 안에서 특정 정보가 어느 위치에 놓이느냐에 따라 모델이 그것을 찾아 쓸 수 있는지를 시험했습니다. 결과는 불편했습니다. 성능은 U자 곡선을 그립니다. 모델은 컨텍스트의 맨 앞과 맨 뒤에 있는 정보에 가장 많은 주의를 기울입니다. 가운데에 있는 정보는 체계적으로 과소평가되고, 때로는 아예 무시됩니다. (Liu et al., 2024)
50페이지짜리 문서 한가운데에 결정적인 지시를 넣어두면, 모델은 그것을 본 적조차 없는 것처럼 행동할 수 있습니다. 프롬프트를 고쳐서 빠져나갈 수 있는 종류의 결함이 아닙니다.
이어서 2025년 7월, Chroma는 Kelly Hong, Anton Troynikov, Jeff Huber가 쓴 "Context Rot: How Increasing Input Tokens Impacts LLM Performance"를 발표했습니다. GPT-4.1, Claude 4, Gemini 2.5, Qwen3을 포함해 프론티어 모델 18개를 시험했습니다. 결과는 모든 모델에서 일관됐습니다. 입력이 커질수록 성능이 떨어졌고, 그것도 컨텍스트 윈도우가 차기 한참 전이었습니다. 모델은 자신의 컨텍스트를 균일하게 쓰지 않습니다. 정확도는 대략 10,000 토큰에서 100,000 토큰 사이에서 수십 퍼센트포인트 미끄러졌는데, 100만 토큰 모델에서는 윈도우의 첫 10분의 1에 해당하는 구간입니다.
결정적인 지점은 이 임계값이 윈도우 대비 비율이 아니라 절대 토큰 수를 따라간다는 사실입니다. Databricks는 Llama 3.1 405B에서 정확도가 32,000 토큰 부근부터 떨어지기 시작하고, 더 작은 모델에서는 그보다 일찍 떨어진다고 측정했습니다. 더 큰 윈도우를 산다고 이 숫자가 움직이지는 않습니다. 100만 토큰 윈도우는 쓸 수 있는 토큰 100만 개를 사주지 않습니다. 문제를 더 키울 공간을 더 사줄 뿐입니다. Meta는 Llama 4 Scout의 1,000만 토큰 전 구간에서 거의 완벽한 건초더미 속 바늘 찾기 검색 성능을 공개하지만, 심어둔 사실 하나를 찾아내는 것과 그 말뭉치 전체를 놓고 추론하는 것은 다른 일이며, 그 길이에서 추론 품질이 유지된다는 것을 보여준 공개 벤치마크는 없습니다.
Anthropic은 근본 원인을 해법이 자연히 따라 나오는 방식으로 설명합니다. 컨텍스트는 "a finite resource with diminishing marginal returns"(한계 수익이 체감하는 유한한 자원)이며, 모델은 "attention budget"(주의 예산) 위에서 작동하는데 "every new token introduced depletes this budget by some amount"(새로 들어오는 토큰 하나하나가 이 예산을 얼마간 갉아먹는다)는 것입니다. 아키텍처가 그 이유를 설명합니다. 트랜스포머는 n개 토큰에 대해 n²개의 쌍별 관계를 계산해야 하므로, 입력이 커질수록 주의는 옅어집니다. (Anthropic, 2025)
이것이 100만 토큰 시대의 숨은 비용입니다. 윈도우는 모델이 그것을 활용하는 능력보다 빠르게 자랐고, 그 결과 "무엇을 빼야 할까?"가 이 스택에서 가장 값진 질문이 되었습니다. 이 문제의 아키텍처 측면과 언제 검색으로 갈아타야 하는지에 대해서는 Context Rot, RAG, 그리고 롱 컨텍스트를 참고하십시오.
컨텍스트가 실패하는 네 가지 방식
컨텍스트 오염(context pollution)은 들어가서는 안 될 재료 때문에 컨텍스트가 망가진 상태를 뭉뚱그려 부르는 말입니다. 쓸모 있는 표현이지만 진단으로는 쓸모가 없습니다. 컨텍스트가 오염됐다는 사실만으로는 무엇을 빼야 할지 알 수 없기 때문입니다. 가장 유용한 분해는 2025년 6월 22일 "How Long Contexts Fail"을 발표한 Drew Breunig에게서 나왔습니다. 그는 컨텍스트 오염을 네 가지 뚜렷한 실패 유형으로 나눴고, 이 분류가 살아남은 이유는 각각의 해법이 다르기 때문입니다.
| 실패 유형 | 무엇인가 | 알아채는 신호 | 해법 |
|---|---|---|---|
| 컨텍스트 중독 | 환각이나 오류가 컨텍스트에 들어와 반복해서 참조됩니다 | 준 적 없는 사실을 모델이 자신 있게 되풀이합니다 | 새 스레드를 시작합니다. 메모리에 들어가는 것을 검증합니다 |
| 컨텍스트 산만 | 컨텍스트가 너무 길어져 모델이 거기에 과도하게 집중하고 학습으로 익힌 것을 소홀히 합니다 | 답이 같은 말을 되풀이하고, 모델이 추론 대신 과거 행동을 재사용합니다 | 압축하거나 요약한 뒤 다시 시작합니다 |
| 컨텍스트 혼동 | 불필요한 내용이 응답 생성에 쓰여 품질이 떨어집니다 | 무관한 도구가 호출되고, 주제와 상관없는 세부가 결과에 나타납니다 | 도구 목록과 자료 목록을 쳐냅니다 |
| 컨텍스트 충돌 | 새 정보나 도구가 컨텍스트에 이미 있던 정보와 충돌합니다 | 모델이 얼버무리거나, 앞뒤가 안 맞거나, 엉뚱한 지시를 고릅니다 | 모순을 제거합니다. 규칙을 한 번만 다시 말합니다 |
뒤에 깔린 사례는 구체적입니다. 중독의 경우, Breunig은 포켓몬을 플레이하던 Gemini 2.5 에이전트를 예로 듭니다. 이 에이전트는 게임 상태를 환각으로 지어내 목표 섹션에 적어 넣었고, 그 뒤로 한참 동안 달성이 불가능한 목표를 좇았습니다. 산만의 경우에는 앞 절의 근거가 된 Databricks 결과를 그대로 인용합니다. 윈도우가 그보다 몇 배나 큰 모델에서도 정확도는 32,000 토큰 부근부터 미끄러지기 시작합니다.
혼동에는 가장 실행 가능한 증거가 있습니다. Breunig의 요약에 따르면 Berkeley Function-Calling Leaderboard에서 "every model performs worse when provided with more than one tool"(도구가 하나를 넘어가면 모든 모델의 성능이 떨어진다)이며, 모델은 이따금 요청과 아무 상관 없는 도구를 호출합니다. GeoEngine 벤치마크 테스트에서는 양자화된 Llama 3.1 8B가 도구 46개를 받았을 때 과제에 실패했고, 19개를 받았을 때 성공했습니다. 같은 모델, 같은 과제, 더 적은 선택지였습니다.
충돌에 대해서는 Breunig이 Microsoft와 Salesforce의 "샤딩된(sharded)" 프롬프트 연구를 인용합니다. 같은 정보를 한 번에 주지 않고 여러 메시지에 흩어 놓은 경우입니다. 성능은 평균 39퍼센트 떨어졌고, o3는 해당 과제에서 98.1에서 64.1로 내려앉았습니다.
여기서 몸에 새겨둘 만한 패턴이 있습니다. 이 네 가지 중 셋은 컨텍스트를 더할수록 악화됩니다. 나아지는 것은 정말로 빠진 사실이 있는 경우, 단 하나뿐입니다. 이 비대칭이 큐레이션을 지지하는 논거의 전부입니다.
연구는 무엇을 말하는가: 중요한 문헌들
여기서는 네 편의 문헌이 대부분의 무게를 감당하며, 이것만 읽어도 온라인에서 이 주제로 논쟁하는 거의 모든 사람보다 앞서게 됩니다. 중심축은 2025년 7월 17일 제출된 "A Survey of Context Engineering for Large Language Models"(arXiv:2507.13334)입니다. 166페이지에 걸쳐 인용 논문 1,411편을 훑기 때문에, 이 분야가 가진 지도에 가장 가까운 문헌입니다.
이 서베이의 틀은 컨텍스트 엔지니어링이 "transcends simple prompt design to encompass the systematic optimization of information payloads for LLMs"(단순한 프롬프트 설계를 넘어 LLM을 위한 정보 페이로드의 체계적 최적화까지 포괄한다)는 것입니다. 저자들은 이 분야를 기초 구성 요소(컨텍스트 검색과 생성, 컨텍스트 처리, 컨텍스트 관리)와 그 위에 세워진 시스템 구현(RAG, 메모리 시스템, 도구 통합 추론, 멀티 에이전트 아키텍처)으로 나눕니다. RAG가 컨텍스트 엔지니어링과 어떤 관계인지 궁금했다면 답은 이것입니다. 검색은 더 큰 분과 안에 놓인 기계 하나입니다.
가장 흥미로운 발견은 저자들이 "a defining priority for future research"(향후 연구의 결정적 우선순위)라고 짚은 간극입니다. 좋은 컨텍스트 엔지니어링으로 보강된 모델은 "demonstrate remarkable proficiency in understanding complex contexts"(복잡한 컨텍스트를 이해하는 데 놀라운 숙련도를 보인다)지만, "exhibit pronounced limitations in generating equally sophisticated, long-form outputs"(그에 걸맞은 정교한 장문 결과물을 생성하는 데는 뚜렷한 한계를 드러낸다)는 것입니다. 쉽게 말하면, 우리는 모델에 정보를 먹이는 일에서는 훨씬 나아졌지만 길고 품질 높은 결과물을 되받아내는 일에서는 그만큼 나아지지 못했습니다. AI가 훌륭한 요약을 내놓은 직후 평범한 3,000단어 초안을 내놓는 장면을 본 사람이라면 이미 몸으로 느껴봤을 것입니다.
전문을 읽어볼 만한 다른 문헌은 2025년 9월 29일 발표된 Anthropic의 "Effective context engineering for AI agents"입니다. 지금 대부분의 도구가 쓰는 실무 어휘를 실무자들에게 건네준 문서입니다.
- 적시 검색(just-in-time retrieval): 모든 것을 미리 올려두는 대신, 가벼운 식별자(파일 경로, 쿼리, 링크)만 컨텍스트에 두고 실제 데이터는 실행 시점에 불러옵니다.
- 압축(compaction): 대화가 윈도우 한계에 가까워지면 요약한 뒤 새 윈도우로 다시 시작합니다. Anthropic은 어려움이 전적으로 선별에 있다고 지적합니다. "overly aggressive compaction"(지나치게 공격적인 압축)은 중요성이 나중에야 드러나는 미묘한 컨텍스트를 잃어버리기 때문입니다.
- 구조화된 메모 작성: 에이전트가 컨텍스트 윈도우 바깥의 지속 메모리에 메모를 쓰게 하고, 필요할 때 다시 읽어오게 합니다.
- 서브에이전트 아키텍처: 초점이 좁은 과제를 깨끗한 컨텍스트 윈도우를 가진 전용 에이전트에 맡기고, 총괄 에이전트가 결과를 종합하게 합니다.
이 네 기법은 자율 에이전트를 위해 설계되었습니다. 그리고 네 가지 모두 사람이 채팅창에서 손으로 돌릴 수 있는 대응물이 있으며, 그것이 다음 두 절의 주제입니다. 이 아이디어들이 일상적인 에이전트 도구에서 어떻게 나타나는지는 스킬, 서브에이전트, 훅을 참고하십시오.
아무도 이름 붙이지 않은 기술: 큐레이션
컨텍스트 부식이 문제라면 큐레이션이 해법입니다. 그리고 큐레이션은 대부분의 지식 노동자가 그 이름을 붙이지 않은 채 이미 실천하고 있는 기술입니다.
기사에서 한 구절을 하이라이트할 때마다 당신은 큐레이션을 하고 있습니다. 이것이 중요하다고 말하는 것입니다. 나머지는 배경입니다. PDF에 주석을 달거나, 논문을 북마크하거나, 인용을 저장할 때도 같은 일을 합니다. 텍스트로 가득한 세상 위에 신호 대 잡음 필터를 세우는 일입니다.
최근까지의 문제는 이 큐레이션이 갇혀 있었다는 점입니다. 하이라이트는 한 앱 안에 있었습니다. Kindle 노트는 다른 앱에 있었습니다. 웹 리서치는 브라우저 기록에 있었습니다. AI에게 브리핑하려고 앉으면 그중 무엇도 컨텍스트 윈도우로 효율적으로 끌어올 수 없었습니다. 결국 모든 것을 다시 읽거나, 더 나쁘게는 원본 자료를 그대로 붙여넣고 잘되기를 바랐습니다.
분과로서의 컨텍스트 엔지니어링에는 정확히 이 지점에 커다란 구멍이 있습니다. 기업들은 내부 지식 베이스와 RAG 파이프라인을 만들어 해결했습니다. 하지만 개인 지식 노동자에게는 엔지니어링 팀이 없습니다. 같은 문제(원자료는 너무 많고 신호는 부족한 문제)는 있는데 인프라는 하나도 없습니다.
그래서 하이라이트를 오래 남게 붙잡아 두는 독서 도구들이 조용히 AI 인프라가 되었습니다. Glasp의 웹 하이라이터는 정확히 이것을 풀기 위해 존재합니다. 당신의 독서를 구조화되고 다시 꺼낼 수 있는 컨텍스트로 바꿔줍니다. 블로그 글에서 한 문단을 하이라이트하면, 그 하이라이트는 나중에 어떤 AI에게든 건넬 수 있는 컨텍스트 조각이 되고, 주제별, 출처별, 날짜별로 걸러낼 수 있습니다.
장문 독서에도 같은 원리가 적용됩니다. Kindle 하이라이트는 무엇이 당신에게 중요한지에 대해 당신이 만들어낸 가장 품질 높은 신호라고 해도 무방합니다. 하이라이트할 만큼 오래 주의를 기울였다는 뜻이기 때문입니다. 값비싼 필터인데, 그 하이라이트가 닫힌 시스템 안에 방치되면 전부 낭비됩니다.
개인을 위한 컨텍스트 엔지니어링 (엔지니어만의 것이 아닙니다)
컨텍스트 엔지니어링에 관한 글은 대부분 개발자를 향합니다. 프로덕션 AI 시스템을 만드는 이야기, 즉 코딩 에이전트의 시스템 프롬프트를 어떻게 짤지, 검색을 위해 문서를 어떻게 나눌지, 도구 호출을 어떻게 연결할지에 관한 이야기입니다. 소프트웨어를 출시한다면 유용합니다. 더 나은 AI 결과물을 원하는 컨설턴트, 연구자, 작가, 분석가, 학생에게는 덜 유용합니다.
하지만 같은 분과가 그대로 적용됩니다. 다만 손으로 돌릴 뿐입니다.
당신은 이미 시스템 프롬프트를 설계하고 있습니다. 다만 비공식적으로 합니다. 만들어 둔 모든 커스텀 GPT, 모든 Claude Project, 모든 claude.md 형식의 지시 파일이 곧 시스템 프롬프트입니다. "너는 내 리서치 어시스턴트다, 나는 재생에너지 정책을 다룬다, 회의적인 요약을 선호한다"라고 쓰는 순간 시스템 프롬프트를 설계하는 것입니다. 그러니 의도적으로 하십시오.
당신은 메모리를 관리합니다. ChatGPT의 메모리 기능과 Claude의 프로젝트는 대화를 넘어 유지되는 사실을 고정할 수 있게 해줍니다. 대부분의 사람은 이것을 무시하거나(연속성을 잃습니다) 전부 쏟아붓습니다(잡음을 만듭니다). 옳은 선택은 이력서를 다듬듯 메모리를 큐레이션하는 것입니다. 매번 모델이 쓰기를 바라는 것만 남기십시오.
당신은 검색을 손으로 합니다. 알맞은 기사를 채팅창에 붙여넣는 것이 수동 RAG입니다. 문제는 그 "알맞은 기사"가 어디서 나오느냐입니다. 브라우저 기록을 허둥지둥 훑어서 나온다면 당신에게 검색 시스템은 없는 것입니다. 이미 흥미롭다고 표시해둔 구절들의 라이브러리에서 나온다면, 있는 것입니다.
당신은 첨부를 의도적으로 올립니다. 책 전체를 올리고 싶은 유혹이 있습니다. 더 나은 선택은 실제로 하이라이트한 40페이지를 올리는 것입니다. 상류에서 걸러냄으로써 컨텍스트 부식을 우회하는 셈입니다.
여기에 더해 Anthropic의 플레이북에 나온 네 가지 에이전트 기법이 있고, 각각에는 손으로 돌리는 버전이 있습니다.
| 에이전트 기법 | 오늘 바로 손으로 돌릴 수 있는 버전 |
|---|---|
| 적시 검색 | 출처 링크 목록만 스레드에 두고, 모델이 정말 필요로 할 때만 전문을 붙여넣습니다 |
| 압축 | 스레드가 길어지고 답이 반복되기 시작하면 지금까지의 결정을 요약해달라고 한 뒤, 그 요약을 맨 위에 얹고 새 채팅을 시작합니다 |
| 구조화된 메모 작성 | 프로젝트의 현재 상태를 채팅 바깥의 문서에 유지하고, 스크롤백에 의존하는 대신 최신 버전을 다시 붙여넣습니다 |
| 서브에이전트 | 하나의 거대한 스레드 대신 하위 과제마다 별도의 채팅을 돌리고, 결론만 모아서 합칩니다 |
압축은 대부분의 사람이 놓치고 있는 항목입니다. 긴 스레드는 시간이 갈수록 나빠지는데, 오래된 메시지가 컨텍스트를 쓸데없이 지배하기 때문이며 이는 앞의 표에 나온 산만 실패 유형 그 자체입니다. 새 하위 과제를 깨끗한 브리핑과 함께 새 스레드에서 시작하는 편이 대개 거대 스레드를 이어가는 것보다 낫습니다.
이 중 어느 것도 엔지니어링 역량을 요구하지 않습니다. 좋은 연구자와 좋은 기자가 이미 갖고 있는 바로 그 역량을 요구합니다. 무엇을 넣고, 무엇을 자르고, 어디서 무엇을 끌어올지 아는 능력입니다.
당신의 하이라이트가 곧 당신의 경쟁 컨텍스트입니다
여기서부터가 과소평가된 대목입니다.
대부분의 사람은 자신의 노트와 하이라이트를 기억 보조 장치로 취급합니다. 언젠가 다시 들춰볼 것들입니다. 2010년에는 말이 되는 관점이었습니다. 다시 들춰보는 것이 그것을 쓰는 유일한 방법이었기 때문입니다. 2026년에는 낡은 관점입니다.
당신의 하이라이트는 이제 AI에게 건넬 수 있는 피드입니다. 표시해둔 모든 구절, 저장해둔 모든 인용, 남겨둔 모든 주석이 컨텍스트 조각입니다. 그리고 주의를 기울여 만들어낸 것이기 때문에, 웹에서 무작위로 긁어온 어떤 것보다 신호가 강합니다.
이것이 경쟁 측면에서 무엇을 뜻하는지 생각해 보십시오. 두 지식 노동자가 같은 AI 모델을 씁니다. 한 사람에게는 3년치의 구조화된 독서와 하이라이트가 있습니다. 다른 사람에게는 다시는 열어보지 않은 3년치 브라우저 탭이 있습니다. 두 사람이 AI에게 같은 질문을 던질 때, 첫 번째 사람은 자기만의 큐레이션된 말뭉치를 함께 건넬 수 있습니다. 두 번째 사람은 모델의 일반적인 학습 데이터와, 기억나는 대로 붙여넣을 수 있는 것에 갇힙니다. 이 격차는 프롬프팅 격차가 아닙니다. 컨텍스트 격차입니다.
그래서 Glasp는 스스로를 설명하는 방식을 바꿔왔습니다. 처음의 소개는 소셜 웹 하이라이터였습니다. 하이라이트하고, 다른 사람이 무엇을 하이라이트했는지 보고, 독자로서의 정체성을 쌓는 것이었습니다. 그 설명은 지금도 전부 사실입니다. 다만 이제 더 깊은 가치는 모든 하이라이트가 쓰이기를 기다리는 컨텍스트 토큰이라는 데 있습니다. 당신의 독서 이력은 한 문단씩 쌓여 개인용 RAG 말뭉치로 복리처럼 불어납니다.
여기에 Glasp의 AI 채팅을 더하면, 작업 흐름은 엔지니어들이 자기 회사를 위해 구축하는 것에 가까워집니다. 읽으면서 하이라이트합니다. 나중에 질문하면 AI는 일반적인 웹 인덱스가 아니라 당신이 실제로 신경 쓴 것에서 재료를 끌어옵니다. 그것이 컨텍스트 엔지니어링입니다. 다만 그 컨텍스트가 당신 자신의 서재일 뿐입니다.
이 변화가 독서와 AI의 관계를 어떻게 뒤집는지에 대해서는 AI 독서 어시스턴트를 참고하십시오.
모든 AI 작업에 쓸 수 있는 간단한 컨텍스트 설계 프레임워크
이론은 이만하면 충분합니다. 다음번에 채팅창을 열 때 그대로 돌릴 수 있는 구체적인 절차입니다.
1단계: 타이핑하기 전에 일을 정의하십시오. 한 문장이면 됩니다. 완료된 상태는 어떤 모습입니까? "주 4일제에 반대하는 세 가지 핵심 논거를 요약한 500단어 메모를, 회의적인 COO를 독자로 삼아 초안 작성." 이것이 일입니다. "이 글 좀 도와줘"는 일이 아닙니다.
2단계: 자료를 모으고, 그다음 쳐내십시오. 그 일에 실제로 걸리는 자료를 끌어옵니다. 해당 주제에 하이라이트가 있다면 전체 기사가 아니라 거기서 시작하십시오. 메모리를 설정해두었다면 쓸 만한 배경이 이미 들어 있는지 확인하십시오. 곁가지로만 관련된 것은 빼두십시오. 컨텍스트 부식은 실재합니다.
3단계: 역할과 규칙을 정하십시오. 작업 전에 모델에게 자신이 누구이고 어떤 규칙이 적용되는지 알려주십시오. "너는 회의적인 COO를 독자로 삼아 편집한다. 전문 용어 금지. 얼버무리기 금지. 형용사보다 숫자를 먼저." 이것이 시스템 프롬프트 계층입니다. 10초면 되고, 뒤따르는 모든 것의 어조를 바꿔놓습니다.
4단계: 과제와 자료 묶음을 순서대로 투입하십시오. 가장 중요한 컨텍스트를 앞에, 과제를 맨 뒤에 두십시오. Lost in the Middle 효과 때문에, 지시와 가장 날카로운 자료는 맨 앞과 맨 뒤에 있어야 합니다. 가운데는 늪입니다.
5단계: 반복하기 전에 진단하십시오. 결과가 나쁘면 프롬프트를 열두 가지 방식으로 고쳐 쓰고 싶은 충동을 참으십시오. 대신 네 가지 실패 유형을 체크리스트로 돌리십시오. 자꾸 되돌아오는 틀린 사실이 들어 있습니까(중독)? 스레드가 길고 답이 반복됩니까(산만)? 하나면 충분한데 자료를 세 개 붙였습니까(혼동)? 서로 어긋나는 지시를 두 개 주었습니까(충돌)? 각각의 해법이 다르고, 그중 어느 것도 표현을 다시 쓰는 것이 아닙니다.
이것을 몇십 번만 해보면 반사적으로 몸에 붙습니다. "이걸 어떻게 프롬프트하지?"라고 묻는 대신 "모델이 답하기 전에 무엇을 봐야 하지?"라고 묻게 됩니다. 그 전환이 이 분과의 전부입니다.
자주 묻는 질문
컨텍스트 엔지니어링을 쉽게 말하면 무엇인가요?
AI 모델이 답하기 전에 무엇을 보게 할지 결정하는 일입니다. 여기에는 당신이 주는 지시, 첨부하는 문서, 모델이 당신에 대해 기억하는 것, 쓸 수 있는 도구, 그리고 지금까지의 대화가 모두 들어갑니다. 프롬프트 엔지니어링은 요청의 표현만 다루는데, 그것은 여러 입력 중 하나일 뿐입니다.
프롬프트 엔지니어링은 정말 죽었나요?
표현이 은퇴하는 중입니다. 그 아래에 있는 기법들은 여전히 작동합니다. 사고의 연쇄, 소수 예시, 명확한 출력 형식은 모두 지금도 유용합니다. 죽은 것은 표현만 잘하면 훌륭한 결과가 나온다는 생각입니다. 2026년에 표현은 작은 지렛대입니다. 컨텍스트 조립이 큰 지렛대입니다. 사람들이 "프롬프트 엔지니어링은 죽었다"고 말할 때 뜻하는 바가 이것입니다.
컨텍스트 엔지니어링도 죽었나요, 아니면 그냥 유행어인가요?
이 용어는 과열의 정점을 지났고, 독립된 "컨텍스트 엔지니어" 직함은 표준이라기보다 이제 생겨나는 중입니다. Adobe는 정확히 그 이름의 직무를 공고에 올리지만, 대부분의 회사에서는 이 일이 기존 AI, 데이터, 플랫폼 엔지니어링 직무 안에 들어가 있습니다. 실천 자체는 그 어느 때보다 자리를 잡았고, 사라지는 것이 아니라 평범한 AI 업무 안으로 흡수되는 중입니다. 최신 에이전트 도구의 자동 압축과 자동 검색이 수작업 몇 단계를 없앤 것은 맞지만, 무엇을 메모리에 넣을지, 모델이 어떤 자료를 봐도 되는지는 여전히 사람이 정합니다. 그 결정이 곧 이 일입니다.
컨텍스트 오염이란 무엇인가요?
들어가서는 안 될 재료 때문에 컨텍스트가 망가진 상태를 가리키는 일반 용어입니다. Drew Breunig의 분류는 컨텍스트 오염을 네 유형으로 나눕니다. 중독(오류가 들어와 반복됨), 산만(컨텍스트가 너무 길어져 모델이 거기에 과의존함), 혼동(무관한 내용이 답을 끌어내림), 충돌(두 컨텍스트가 서로 모순됨)입니다. 어느 쪽인지 진단하는 일이 중요한 이유는 해법이 서로 다르기 때문입니다.
컨텍스트 엔지니어링에 관해 읽을 만한 논문은 무엇인가요?
논문 1,411편을 검토한 166페이지 리뷰인 "A Survey of Context Engineering for Large Language Models"(arXiv:2507.13334)에서 시작하십시오. 롱 컨텍스트 실패의 증거로는 TACL에 실린 Liu et al. (2024) "Lost in the Middle"과 Chroma의 2025년 "Context Rot" 기술 보고서를 읽으십시오. 실무 적용이라면 Anthropic의 "Effective context engineering for AI agents"(2025년 9월)가 학술 문헌이 아닌 것 중 가장 쓸모 있습니다.
컨텍스트 엔지니어링과 RAG는 어떻게 다른가요?
RAG(retrieval-augmented generation, 검색 증강 생성)는 컨텍스트 엔지니어링의 한 계층, 정확히는 검색 계층입니다. 필요할 때 지식 베이스에서 관련 조각을 끌어오는 장치입니다. 컨텍스트 엔지니어링은 RAG에 더해 시스템 프롬프트, 메모리, 도구 사용, 첨부, 대화 기록까지 포함하는 더 넓은 분과입니다.
컨텍스트 윈도우가 더 커지면 결국 해결되지 않을까요?
지금까지는 그러지 않았고, 증거는 앞으로도 그렇지 않으리라는 쪽을 가리킵니다. Liu et al. (2024)은 모델이 긴 컨텍스트의 가운데를 무시한다는 것을 보였습니다. Chroma의 2025년 연구는 시험한 프론티어 모델 18개 전부가 윈도우가 차기 훨씬 전에 성능이 떨어진다는 것을 보였습니다. 1,000만 토큰을 내건 윈도우들은 바늘 찾기 검색 결과는 있지만, 그 길이에서 추론 품질이 유지된다는 공개 벤치마크는 없습니다. 병목은 윈도우 크기가 아닙니다. 윈도우 안에서의 주의 배분입니다.
컨텍스트 엔지니어링을 하려면 기술적인 사람이어야 하나요?
아닙니다. 엔지니어링이라는 비유 때문에 헷갈리는 분들이 있지만, 그것은 우연에 맡기지 말고 의도적으로 하라는 뜻일 뿐입니다. 브리핑을 준비하는 컨설턴트, 기사를 취재하는 기자, 에세이를 위해 자료를 정리하는 학생 모두 형태만 다른 컨텍스트 엔지니어링을 하고 있습니다. 핵심 역량은 큐레이션과 판단입니다.
AI의 "메모리" 기능과는 어떤 관계인가요?
메모리(ChatGPT의 지속 메모리나 Claude의 프로젝트 같은 것)는 컨텍스트의 한 계층입니다. 세션을 넘어 모델이 당신에 대해 아는 것입니다. 컨텍스트 엔지니어링은 메모리를 포함하되 그보다 넓습니다. 메모리는 항상 켜져 있는 계층입니다. 검색, 첨부, 시스템 프롬프트는 과제마다 달라지는 계층입니다. 좋은 컨텍스트 엔지니어는 이것들을 함께 씁니다.
결국 그럴듯하게 포장한 노트 필기 아닌가요?
일부는 그렇습니다. 차이는 전통적인 노트 필기가 당신이 자기 노트를 다시 읽는 것에 최적화되어 있다는 점입니다. 컨텍스트 엔지니어링은 모델이 당신의 노트를 소비하는 것에 최적화되어 있습니다. 형식 요건은 다르지만(구조, 원자성, 검색 가능성이 훨씬 중요해집니다) 기억할 가치가 있는 것을 붙잡아 둔다는 바탕의 실천은 같습니다. 노트를 잘 쓰는 사람은 이 분야에서 출발선이 앞에 있습니다.
결론: 새로운 문해력
컴퓨팅의 모든 시대에는 아마추어와 진지한 사용자를 갈라놓는 문해력이 있었습니다. 2000년대에는 Google을 잘 검색하는 법을 익히는 것이었습니다. 2010년대에는 Notion이나 Airtable 같은 앱에서 정보를 구조화하는 법을 익히는 것이었습니다. 2026년에는 AI를 위해 컨텍스트를 설계하는 법을 익히는 것입니다.
이것을 알아낸 사람들은 그러지 못한 사람들을 크게 앞지를 것입니다. 더 좋은 모델을 쓸 수 있어서가 아니라(모델은 모두에게 같습니다) 매번 더 좋은 재료를 들고 나타나기 때문입니다. 무엇을 넣어야 하는지 압니다. 무엇을 빼야 하는지 압니다. 어떤 주제에 대한 자기 최고의 자료가 어디에 있는지 압니다. 몇 달 전에 굳이 붙잡아 두었기 때문입니다.
그래서 큐레이션은 조용히 AI 시대의 가장 값진 메타 역량이 되어가고 있습니다. 저장하는 모든 하이라이트, 주석을 다는 모든 구절, 실제로 소화한 모든 독서가 개인 컨텍스트 엔진에 넣는 예치금입니다. AI 생산성의 미래는 비밀 프롬프트를 가진 사람들의 것이 아닙니다. 사려 깊은 서재를 가진 사람들의 것입니다.
당신은 이미 읽고 있습니다. 무엇이 중요한지에 대한 견해도 이미 있습니다. 남은 질문은 그중 무엇이라도 미래의 당신에게, 그리고 당신 곁에서 일하는 AI에게 쓸모 있을 만큼 오래 남아 있느냐입니다. 도구는 이미 있습니다. 어려운 것은 습관입니다.
오늘 읽을 가치가 있는 것을 하나 고르십시오. 중요한 부분을 하이라이트하십시오. 그것이 컨텍스트 엔지니어링입니다. 나머지는 전부 기법입니다.
