AI기술

컨텍스트 엔지니어링 완전 해설: AI에게 재료와 도구를 세팅하는 기술

마지막 업데이트: 2026-05-29

1. 누구에게나 잠재력 뛰어난 셰프가 주어졌다

1.1. AI를 키우는 3단계

1편에서 다룬 내용을 간결하게 요약합니다. 갓 태어난 잠재력 뛰어난 셰프(AI)를 키우는 3단계가 있습니다.

시리즈 "AI 엔지니어링의 진화" 3부작 中 2편. 1편은 프롬프트 엔지니어링, 3편은 하네스 엔지니어링을 다룹니다.

1단계는 요리를 가르치는 것입니다. 레시피를 어떻게 전달하느냐에 따라 맛이 달라집니다. 프롬프트 엔지니어링 완전 해설에서 자세히 다뤘습니다.

2단계는 재료와 도구를 세팅하는 것입니다. 레시피만으로는 부족합니다. 냉장고에 재료를 채우고, 칼과 불을 쥐여주고, 단골 손님 취향 노트까지. 셰프가 일하는 환경 전체를 설계하는 기술입니다. 오늘 다루는 주제입니다.

3단계는 식당을 운영하게 만드는 것입니다. 주문 접수부터 재료 조달, 위생 관리, 클레임 대응까지. 셰프 혼자서 식당이 돌아가게 만드는 전체 시스템이 필요합니다.

1.2. 정의

컨텍스트 엔지니어링(Context Engineering)은 LLM에게 들어가는 전체 입력을 설계하고 관리하는 기술입니다.

"전체 입력"이란 사용자가 타이핑한 질문만이 아닙니다. 시스템 프롬프트, 검색된 문서, 도구 목록, 대화 기록, 사용자 선호 정보. 이 모든 것이 LLM의 "컨텍스트 윈도우"라는 공간에 들어가고, 그 안에서 답변이 생성됩니다.

2025년 6월, Shopify CEO Tobi Lütke가 X에서 이 용어를 처음 제안했습니다. (Tobi Lütke, X)

같은 주, Andrej Karpathy가 동의하면서 용어가 업계 전반으로 확산되었습니다. (Andrej Karpathy, X)

Simon Willison은 이를 다듬었습니다. "어떤 정보를, 어떤 순서로, 어떤 형식으로 LLM에게 보여줄지를 의도적으로 설계하는 실천." (Simon Willison)

Anthropic은 이를 더 날카롭게 정의합니다. "가장 작은 고신호 토큰 집합을 찾아서 원하는 결과의 확률을 최대화하는 것." (Anthropic Engineering)

2. 프롬프트만으로는 왜 부족한가?

1편의 결론은 "프롬프트 엔지니어링은 기초 체력이다"였습니다. 기초 체력은 중요하지만, 기초 체력만으로 경기를 이길 수는 없습니다.

프롬프트 엔지니어링 완전 해설 (1편에서 이어집니다)

2.1. 근본 원인: 프롬프트는 정적 텍스트다

프롬프트 엔지니어링의 모든 기법(Zero-shot, Few-shot, CoT, ToT)은 공통점이 있습니다. 전부 "텍스트를 어떻게 구성할 것인가"의 변주입니다. 그런데 텍스트만으로는 해결할 수 없는 영역이 세 가지 있습니다.

2.2. 정보의 한계: 모르는 건 모른다

프롬프트는 작성 시점에 고정됩니다. 아무리 잘 써도, 작성자가 모르는 정보나 실시간으로 변하는 정보는 담을 수 없습니다.

셰프 비유로 돌아가면, 셰프의 레시피가 아무리 좋아도 냉장고에 재료가 없으면 요리를 못 합니다. 우리 회사 내부 DB, 오늘 주가, 1시간 전 나온 논문. 프롬프트 작성 시점에 존재하지 않았거나 작성자가 미처 담지 못한 정보는 "잘 쓰기"의 범위 밖입니다.

2.3. 기억의 한계: 대화가 길어지면 잊어버린다

LLM에는 컨텍스트 윈도우라는 물리적 상한이 있습니다. 이 창을 넘어가면 앞부분이 밀려나갑니다. 프롬프트를 아무리 잘 설계해도, 모델 아키텍처의 물리적 제약을 텍스트 기법으로 극복할 수 없습니다.

셰프의 조리대가 좁은 것과 같습니다. 재료를 50개 올려놓으면 앞에 놓은 재료가 밀려 떨어집니다.

2.4. 행동의 한계: 생각만 하고 실행은 못 한다

"주가를 조회해줘"라고 프롬프트를 써도, AI가 실제로 API를 호출하는 능력이 없으면 학습 데이터를 기반으로 추측합니다. 프롬프트 엔지니어링은 AI의 "생각"을 바꿀 수 있지만, "행동 능력"을 줄 수는 없습니다.

셰프한테 "오븐을 180도로 맞춰"라고 말해도, 셰프 손이 오븐에 닿지 않으면 아무 의미가 없습니다.

2.5. 세 한계의 공통점

세 한계 모두 "모델 바깥의 무언가"가 필요합니다. 외부 정보를 연결하고, 메모리를 관리하고, 도구를 쥐여주는 것. 프롬프트 텍스트 안에서 할 수 있는 일의 경계를 넘어선 설계가 필요했고, 그것이 컨텍스트 엔지니어링입니다.

3. 한계를 어떻게 극복했는가?

3.1. 정보의 한계 → RAG (검색 증강 생성)

셰프가 요리를 시작하기 전에, 필요한 재료를 냉장고에서 꺼내서 조리대 위에 올려놓는 것. 이것이 RAG입니다.

RAG가 없으면 AI는 학습 데이터 기반 추측에 의존합니다. RAG가 있으면 최신 IR 자료를 검색해서 첨부하고, 출처를 포함한 정확한 답변이 나옵니다. 핵심은 AI 모델 자체를 바꾸는 게 아니라, AI에게 들어가는 입력에 외부 정보를 끼워넣는 것입니다. 셰프의 실력을 올리는 게 아니라, 조리대 위에 신선한 재료를 올려놓는 겁니다.

🔬RAG 완전 해설: 검색 증강 생성의 구조와 실전

3단계 구조, 3세대 아키텍처 진화, 80%가 실패하는 6대 원인까지 실전 엔지니어가 해부합니다

→

3.2. 기억의 한계 → 메모리 시스템

조리대가 좁은 문제에는 두 가지 전략이 있습니다.

개념적 시각화. 실제 시스템에서는 두 전략을 동시에 사용합니다.

전략 A는 조리대 정리(컨텍스트 관리)입니다. 지금 요리에 필요한 재료만 올려놓고 나머지는 치우는 것입니다. 대화 요약(Compaction), 슬라이딩 윈도우(최근 N턴만 유지), 컨텍스트 압축(관련 부분만 추출)이 이 방식입니다.

전략 B는 메모장 만들어주기(외부 메모리)입니다. 조리대 옆에 메모장을 비치해서, 중요한 내용을 적어두게 하는 것입니다. 조리대가 좁아서 재료가 밀려 떨어져도, 메모장을 보면 "아, 아까 손님이 매운 거 싫다고 했지"를 다시 떠올릴 수 있습니다.

구체적인 예시로, Claude Code에서는 CLAUDE.md 파일이 장기 메모리 역할을 합니다. 세션이 시작될 때마다 자동으로 읽혀서 에이전트의 역할, 규칙, 권한이 주입됩니다. 대화가 길어지면 compact 명령어로 대화를 요약하고 핵심만 보존합니다.

Anthropic 공식 가이드에서는 이를 "Structured Note-taking"이라고 부릅니다. 에이전트가 정기적으로 컨텍스트 윈도우 밖의 메모리에 노트를 작성하고, 나중에 필요할 때 다시 컨텍스트에 불러오는 방식입니다. (Anthropic Engineering)

3.3. 행동의 한계 → Tool Use + MCP

셰프가 직접 오븐을 조작하고, 냉장고를 열고, 타이머를 누를 수 있게 도구를 연결해주는 것. 이것이 Tool Use입니다.

AI가 스스로 "이건 도구를 써야 하는 상황이다"라고 판단하고, 도구를 호출하고, 결과를 받아서 답변에 반영합니다.

그런데 도구마다 연결 방식이 달랐습니다. A 서비스의 도구를 B 서비스에서 쓸 수 없었습니다. 이 문제를 해결한 것이 MCP(Model Context Protocol)입니다. USB-C처럼 하나의 표준으로 모든 도구를 연결할 수 있게 만든 프로토콜입니다.

🔬MCP란 무엇인가? AI를 세상과 연결하는 오픈 표준 프로토콜

AI의 단절 문제, 이전 시도의 실패, MCP의 해결 방식, 실전의 벽까지 완전 해설합니다

→

3.4. 세 기법의 관계

세 가지는 독립적이 아니라 함께 작동합니다. 사용자가 질문하면, RAG로 관련 문서를 검색하고, 메모리에서 과거 맥락을 가져오고, Tool Use로 실시간 데이터를 조회해서, 이 모든 것을 하나의 컨텍스트로 조합하여 AI에게 전달합니다.

이 "조합하여 전달"하는 전체 설계가 바로 컨텍스트 엔지니어링입니다.

4. 컨텍스트 윈도우는 실제로 어떻게 생겼는가?

4.1. 컨텍스트 윈도우란

LLM이 한 번에 볼 수 있는 텍스트의 총량입니다. 토큰(token) 단위로 측정되며, 모델마다 크기가 다릅니다. 셰프의 조리대 넓이라고 생각하면 됩니다.

2019년 GPT-2의 1,024 토큰에서 시작해서, 2026년 현재 Claude는 100만 토큰까지 처리합니다. 7년 만에 약 1,000배 넓어졌습니다. (IBM, Context Window)

왜 이런 제약이 있을까요? LLM의 핵심 아키텍처인 Transformer는 입력 토큰 사이의 모든 관계를 계산합니다(Self-Attention). 토큰 수가 2배가 되면 계산해야 할 관계는 4배(O(n²))로 늘어납니다. 조리대를 넓히려면 비용이 기하급수적으로 증가하는 겁니다. 그래서 조리대 크기에는 물리적 상한이 있고, 그 안에서 무엇을 올려놓을지 설계하는 것이 핵심이 됩니다.

4.2. 컨텍스트 윈도우 안의 구조

AI에게 요청을 보낼 때, 컨텍스트 윈도우 안에는 여러 종류의 정보가 층층이 쌓여서 들어갑니다.

개념적 시각화. 실제 비율은 서비스마다 다르며, 컨텍스트 엔지니어링의 핵심은 각 층의 예산을 어떻게 배분하느냐입니다.

4.3. "대화"라는 환상

여기서 대부분의 사람들이 모르는 사실이 있습니다. AI와 대화할 때, 우리는 하나의 AI와 계속 대화를 이어가고 있다고 느낍니다. 어제 물어본 것을 오늘 기억하고, 10분 전에 합의한 것을 지금도 알고 있다고요.

환상입니다.

LLM은 매 요청마다 백지 상태에서 시작합니다. "기억한다"는 건 착각이고, 실제로는 서비스가 이전 대화 내용을 매번 다시 입력에 넣어주고 있는 것입니다.

Anthropic 공식 문서가 이를 명확히 합니다. "each new session begins with no memory of what came before." (Anthropic Engineering) 한 블로그는 이를 이렇게 요약합니다. "LLM의 모든 API 호출은 무상태(stateless)다. 기억도, 연속성도, 이전에 무슨 일이 있었는지에 대한 지식도 없다. 당신이 명시적으로 다시 제공하지 않는 한." (Medium)

왜 이것이 중요합니까? 같은 AI라도 컨텍스트를 어떻게 조합하느냐에 따라 완전히 다른 서비스가 됩니다. ChatGPT와 Claude와 Cursor가 동일한 수준의 LLM 기술 기반인데 전혀 다른 경험을 주는 이유가 바로 이것입니다. 모델이 다른 게 아니라, 뒤에서 돌아가는 컨텍스트 파이프라인이 다릅니다.

실제로 Cursor의 내부 구조를 분석한 자료를 보면, Cursor는 매 메시지마다 LLM에게 보내는 프롬프트 전체를 재구성합니다. 시스템 지시, 모델별 조정, 사용자 입력, 관련 채팅 기록, MCP 도구 메타데이터(최대 40개), 코드 스니펫. 이 모든 것을 매번 새로 조립합니다. (BuildSomethingAI, Cursor Context Management)

4.4. 왜 "배치"가 엔지니어링인가

컨텍스트 윈도우 공간이 유한하기 때문에, 무엇을 넣고 무엇을 빼고, 어떤 순서로 배치하느냐가 결과 품질을 결정합니다.

그래서 컨텍스트 엔지니어링은 네 가지를 설계합니다.

1. 무엇을 넣을 것인가. RAG 결과 중 상위 몇 개만? 대화 기록은 최근 몇 턴까지?
2. 어디에 배치할 것인가. 중요한 지시는 맨 위와 맨 아래에(Lost in the Middle 회피).
3. 언제 갱신할 것인가. 대화가 길어지면 요약? 오래된 도구 결과는 제거?
4. 얼마나 넣을 것인가. 각 층에 토큰 예산을 배분.

실제 서비스에서 총 예산 200K 토큰이라고 가정하면, 각 층에 아래와 같이 예산을 배분합니다.

비용도 무시할 수 없습니다. 한 연구에 따르면 20턴 대화가 5,000~10,000 토큰을 소비하지만, 실제 필요한 맥락은 500~1,000 토큰에 불과한 경우가 많습니다. 월 500만 건의 대화를 처리하는 기업에서 비효율적 컨텍스트 설계로 인해 연간 $400,000의 불필요한 비용이 발생한 사례도 있습니다. (Redis, Context Window Management)

5. 구체적으로 어떻게 하는 건데?

5.1. 3가지 레벨

레벨 1 일반 사용자는 ChatGPT를 쓸 때 대화 기록 관리, 메모리, 검색, 코드 실행이 자동으로 작동합니다. 컨텍스트 엔지니어링이라는 개념의 존재 자체를 모릅니다.

레벨 2 파워유저는 서비스의 자동 기능에 더해, 시스템 프롬프트와 메모리를 직접 설계합니다. Claude Code에서 CLAUDE.md를 설계하는 것, 에이전트 파일에 역할과 규칙을 정의하는 것, compact를 적절한 타이밍에 실행하는 것. 이 모든 것이 "장기 메모리를 수동으로 설계"하는 행위입니다.

레벨 3 개발자는 파이프라인 전체를 처음부터 설계합니다. ChatGPT를 쓰는 사람은 컨텍스트 엔지니어링을 몰라도 됩니다. 하지만 ChatGPT를 만드는 사람은 이 모든 것을 설계해야 합니다. "질문이 들어왔을 때 RAG로 몇 개의 문서를 검색할 것인가? 대화 기록은 몇 턴까지? 시스템 프롬프트에 뭘 넣을 것인가?"

이 글의 나머지 부분은 레벨 3, 즉 개발자 관점에서 컨텍스트 엔지니어링을 다룹니다.

5.2. 실전: HiveWorks Invest 기업 분석 AI 서비스

HiveWorks Invest는 기업 분석 전용 AI 서비스를 개발하고 있습니다. 사용자가 보는 것은 간단합니다. "SK하이닉스 지금 살 만해?" 라고 질문하면 5초 뒤 체계적인 분석 결과가 나옵니다. 이 5초 사이에 개발자가 설계한 컨텍스트 엔지니어링 파이프라인 전체가 작동합니다.

개념적 시각화. HiveWorks Invest 실제 구현을 단순화한 다이어그램입니다.

Step 1 의도 분류: "SK하이닉스 지금 살 만해?"를 "밸류에이션 + 매수 타이밍" 질문으로 분류합니다. 질문 유형에 따라 어떤 데이터를 가져올지가 달라집니다.

Step 2 데이터 수집(RAG + Tool Use, 병렬 실행): 내부 리서치 DB에서 SK하이닉스 분석 리포트를 검색하고, 재무 DB에서 최근 4분기 실적과 컨센서스를 가져오고, 주가 API와 뉴스 API를 동시에 호출합니다.

Step 3 컨텍스트 조립(토큰 예산 배분): 가져온 정보를 토큰 예산에 맞게 조립합니다. 시스템 프롬프트(분석 프레임워크, 법적 제약), 검색된 리서치, 실시간 데이터, 대화 기록, 현재 질문. 각각에 예산을 배분하고 중요도 순으로 배치합니다.

Step 4 LLM 호출: 조립된 컨텍스트를 LLM에 전달합니다. 사용자는 한 줄 질문했지만, AI가 실제로 읽는 것은 수만 토큰의 컨텍스트입니다.

Step 5 후처리: 출처 링크 삽입, 면책 문구 확인, 할루시네이션 체크.

6. 그런데 이것만으로 충분한가?

6.1. 한 명의 셰프가 모든 요리를 다 할 수 없다

기업 분석이라는 작업 하나만 봐도, 실제로는 여러 단계가 있습니다. 사업 구조 분석, 재무 데이터 수집, 밸류에이션 계산, 리스크 점검, 최종 판정. 각 단계마다 필요한 전문성, 참조해야 할 데이터, 사용해야 할 도구가 다릅니다.

하나의 프롬프트, 하나의 컨텍스트로 전부 처리하려고 하면 무리가 생깁니다. 한 명의 셰프가 전채부터 디저트까지 전부 만드는 것과, 전채 담당, 메인 담당, 디저트 담당이 분업하는 것의 차이입니다.

6.2. 요리 한 번이 아니라, 식당을 운영해야 한다

컨텍스트 엔지니어링까지 마스터하면, AI는 하나의 요리를 훌륭하게 만들 수 있습니다. 하지만 요리를 잘 한다고 사업을 할 수 있는 건 아닙니다.

실전 서비스는 한 번으로 끝나지 않습니다. 분석을 발행한 뒤 가정이 바뀌면 자동으로 감지하고 갱신해야 하고, 사용자 피드백이 들어오면 다음 분석에 반영되어야 하고, 에이전트가 실수하면 자동으로 재시도하거나 사람에게 에스컬레이션해야 합니다.

하네스 엔지니어링 완전 해설 (3편)