Chapter 3. 컨텍스트 엔지니어링의 부상
Chapter 3

컨텍스트 엔지니어링의 부상

위키 메타 카드 → synthesis/book-vbc-ch03-context-engineering

3.1 들어가며 — 한 번의 질문에서 시스템으로

Chapter 1 은 한 번의 질문 을 4 슬롯 (역할 / 맥락 / 형식 / 루프) 으로 정교하게 기록하는 자세를, Chapter 2 는 그 자세가 시간이 지나면서 컨텍스트 부패로 무너지는 메커니즘을 다루었다. 두 장이 던진 결론은 같았다 — 한 번의 질문 최적화 만으로는 부족하다. 우리에게 필요한 것은 시간을 가로질러 유지되는, 시스템 단위의 입력 통제 다.

본 장이 다루는 단어가 그 응답이다 — 컨텍스트 엔지니어링(Context Engineering) concept/context-engineering. 2024 년 말 안드레 카파시(Andrei Karpathy) 와 Tobias Lütke(토비아스 뤼트케, Shopify CEO) 가 X(트위터) 에 던진 짧은 한 줄에서 시작된 이 단어는, 이후 약 1 년 만에 산업 전체의 공식 어휘 가 되었다. 카파시는 이렇게 표현했다 — "우리가 모델에게 무엇을 말할 것인가에서, 모델이 그 말을 들을 때 무엇을 알고 있게 할 것인가로 관점이 이동했다." 이 한 문장이 프롬프트 와 컨텍스트 의 구분선이다.

본 장은 그 이동을 3 단계 로 따라간다. 첫째, 컨텍스트 엔지니어링의 정의와 7 가지 구성 요소. 둘째, 그 요소들의 역사적 원형 — DBMS(데이터베이스 관리 시스템) 의 인덱스, OS(운영체제) 의 가상 메모리 추상화, 마이크로서비스의 service mesh 가 어떻게 같은 패턴의 다른 시대 표현인지. 셋째, 실무 도구에서 이 원리가 어떻게 박혔는가 — RAG(Retrieval-Augmented Generation, 검색 증강 생성), MCP(Model Context Protocol, 모델 컨텍스트 프로토콜), 영구 지시어 파일(CLAUDE.md / AGENTS.md / .cursorrules).

3.2 핵심 개념 — 한 번의 질문 vs 시스템 입력 파이프라인

3.2.1 정의 — 모델이 듣는 순간 의 환경 통제

컨텍스트 엔지니어링 은 LLM 의 한정된 컨텍스트 윈도우 안에 — 응답 시점에 — 어떤 정보가 어떤 밀도로 기록되어 있게 할 것인가 를 시스템적으로 설계하는 기술이다 concept/context-engineering. 핵심 질문이 프롬프트 엔지니어링 과 다르다.

축프롬프트 엔지니어링컨텍스트 엔지니어링
단위한 번의 질문 (한 줄)전체 입력 파이프라인 (시스템)
핵심 질문모델에게 무엇을 말할 것인가모델이 그 말을 들을 때 무엇을 알고 있게 할 것인가
도구문장 최적화 (4 슬롯)시스템 프롬프트 + 히스토리 + RAG + MCP + 압축 + 영구 지시어 + 장기 기억
시간2022~2024 초2024 말~

이 표의 두 번째 열을 프롬프트의 4 슬롯이 시스템 단위로 펼쳐진 형태 로 읽으면 본 장의 절반은 끝난다. 역할은 시스템 프롬프트 가 되고, 맥락은 RAG + 히스토리 가 되며, 형식은 영구 지시어 파일 의 출력 규약 절이 되고, 루프는 MCP 도구 호출 사이클 이 된다. 4 슬롯이 문장 단위 였다면, 컨텍스트 엔지니어링은 시스템 단위 의 4 슬롯이다.

3.2.2 7 가지 구성 요소

concept/context-engineering 카드에 기록된 7 가지 요소를 차례로 본다.

첫째, 시스템 프롬프트(System Prompt) — 세션이 시작될 때 자동으로 로드되어 모델의 페르소나와 행동 규약 을 기록하는 메시지. 사용자에게는 보이지 않는 영역이지만 모든 응답의 첫 입력 이다. 둘째, 채팅 히스토리(Chat History) — 이전 대화의 축적. Stateless 모델 특성상 클라이언트가 매번 다시 보내는 부분이며, 컨텍스트 윈도우의 가장 큰 토큰 소비원이다. 셋째, 장기 기억(Long-term Memory) — 세션 외부에 기록된 사실 (예: 사용자 프로필, 프로젝트 상태). 클라이언트가 매 세션 시작 시 관련 부분만 골라 컨텍스트에 주입한다. 넷째, RAG(검색 증강 생성) — 외부 문서 코퍼스를 벡터 데이터베이스(Vector DB) 에 저장하고, 사용자 질문과 의미적으로 가까운 청크만 실시간 검색해 컨텍스트에 주입. 다섯째, MCP(모델 컨텍스트 프로토콜) — 외부 도구 (DB · API · 파일시스템 · 외부 서비스) 와 LLM 간의 표준 통신 프로토콜 term/mcp. 여섯째, 컨텍스트 압축(Context Compaction) — 누적된 컨텍스트의 일부를 요약본 으로 대체해 공간을 회수. 일곱째, 영구 지시어(Persistent Instructions) — CLAUDE.md / AGENTS.md / .cursorrules 같은 파일에 프로젝트 헌법 을 박아 매 세션 자동 리로드.

이 7 요소가 모두 한 가지 자세를 공유한다 — 모델은 stateless 이지만, 그 모델 주변의 환경이 stateful 해야 한다. 모델에게 기억을 주는 것이 아니라, 모델이 매번 다시 만나는 외부 시스템 이 기억한다. 이 분리가 본 장의 핵심 통찰이다.

3.2.3 더 깊은 원인 — 정보 검색 이론과 attention 의 만남

7 요소 중 RAG 만 따로 떼어 보면 그것이 사실 정보 검색 이론(Information Retrieval, IR) 의 50 년 전통이라는 점이 드러난다. TF-IDF(Term Frequency-Inverse Document Frequency) 와 BM25(Best Matching 25) 같은 sparse 검색에서, 1990 년대 LSI(Latent Semantic Indexing) 의 의미 검색으로, 2010 년대 Word2Vec 과 BERT 의 embedding 으로, 그리고 오늘의 벡터 데이터베이스 + 의미 유사도 로 이어진다. RAG 는 이 50 년 IR 역사가 LLM 의 attention 메커니즘 과 결합한 형태다. RAG 가 외부에서 가장 관련 있는 청크를 골라 컨텍스트에 주입하면, attention 이 그 청크의 토큰 중 가장 중요한 부분 에 가중치를 더한다. 외부 검색의 거친 필터 + attention 의 정밀 필터 가 이중으로 작동하는 셈이다.

MCP 는 또 다른 뿌리에서 왔다. OS 가 응용 프로그램과 하드웨어 사이에 시스템 콜(system call) 추상화 계층을 둔 것, 분산 시스템이 마이크로서비스 사이에 서비스 메시(service mesh) 를 둔 것, 데이터베이스가 응용과 저장 엔진 사이에 SQL 표준을 둔 것 — 이 셋이 모두 이질적 시스템 사이의 표준 인터페이스 라는 같은 패턴이다. MCP 는 LLM 과 외부 도구 사이 에 같은 패턴을 박은 것이며, 그래서 Anthropic 이 만들었지만 Anthropic 전용이 아닌 공개 표준이다. 이 점이 OpenAI 의 Function Calling 같은 벤더 종속 솔루션 과의 결정적 차이다.

3.3 역사적 · 기술적 맥락 — 2024 의 분기점과 그 이전의 50 년

3.3.1 카파시와 뤼트케 — 두 트윗의 무게

2024 년 말, 안드레 카파시가 X 에 한 줄을 던졌다 — "Context engineering is the new prompt engineering." (컨텍스트 엔지니어링이 새로운 프롬프트 엔지니어링이다.) 며칠 뒤 Tobias Lütke (Shopify CEO) 가 "+1, the term "prompt engineering" never landed for me." (덧붙이자면, 프롬프트 엔지니어링 이라는 말은 내게 한 번도 와닿지 않았다.) 라고 응답했다. 두 사람의 합산 트윗이 한 시대의 어휘를 바꿨다. 한 사람은 OpenAI 공동 창립자, 다른 한 사람은 시가총액 1,000 억 달러대 e-commerce 플랫폼의 CEO 였다. 산업 양쪽 끝에 있는 두 사람이 같은 결론에서 만난 것이다 entity/karpathy.

왜 두 트윗이 그렇게 무거웠는가. 프롬프트 엔지니어링 이 입력 한 줄을 다듬는 미시적 활동 으로 인식되던 시대에, 두 사람은 그것보다 큰 단위가 필요하다 는 진단을 내린 것이다. 그리고 그 큰 단위의 이름을 컨텍스트 엔지니어링 으로 박았다. 이름이 정해지자 산업이 빠르게 따라붙었다. Anthropic, OpenAI, Microsoft, GitHub 가 6 개월 안에 자기들의 도구에 이 어휘를 흡수했다.

3.3.2 RAG 의 부상 — 2020 년 논문에서 2024 년 산업 표준까지

RAG 라는 단어 자체는 2020 년 Meta(당시 Facebook) AI Research 의 논문 에서 나왔다. 그러나 산업 표준이 된 것은 그 5 년 뒤다. 사이에서 무슨 일이 있었는가. 벡터 데이터베이스의 상용화 (Pinecone, Weaviate, Qdrant, Chroma 등이 2022~2023 년 사이 폭발적으로 성장), embedding 모델의 품질 향상 (OpenAI text-embedding-3, Cohere embed-v3, BGE 등), 그리고 컨텍스트 윈도우의 비대칭 성장 (윈도우는 빨리 커졌지만 그 안을 어떻게 채울 것인가 는 풀리지 않은 문제로 남았다) 이 합쳐졌다. 2024 년이 되자 RAG 없이 LLM 앱을 만드는 것은 인덱스 없이 데이터베이스를 쓰는 것과 같다 는 정도의 합의가 자리잡았다.

3.3.3 MCP — Anthropic 의 2024 년 11 월 발표

같은 해 11 월, Anthropic 이 Model Context Protocol (MCP) 을 발표했다 term/mcp. 그 전까지 LLM 이 외부 도구를 호출하는 방식은 각 회사의 독자 규약 이었다. OpenAI 의 Function Calling, Google 의 Tool Use, Anthropic 의 Tool Definitions 가 모두 비슷하지만 다른 형태였고, 도구 하나를 만들면 각 LLM 마다 별도로 어댑터 를 짜야 했다.

MCP 는 이 파편화를 한 번에 정리했다. MCP 서버 가 도구를 표준 스키마로 정의하면, MCP 클라이언트 (Claude Code · Cursor 등) 가 자동으로 발견·호출한다. GitHub 의 issue, Linear 의 ticket, Notion 의 문서, 사내 DB 의 read-only 쿼리, 격리된 영역의 파일시스템 — 모든 것이 같은 형식의 도구 가 된다. 발표 한 달 안에 수백 개의 MCP 서버가 오픈소스로 공개되었고, 6 개월 안에 MCP 가 LLM 도구 통신의 사실상 표준 으로 자리 잡았다. 이 속도가 가능했던 이유는 단순하다 — 표준 인터페이스가 필요하다 는 압력이 누적되어 있었고, Anthropic 이 공개 표준 으로 박았기 때문이다.

3.3.4 영구 지시어 — CLAUDE.md 와 그 방언들

영구 지시어 파일은 세 도구가 독립적으로 같은 결론에 수렴 한 사례다. Anthropic 이 CLAUDE.md, OpenAI Codex 가 AGENTS.md, Cursor 가 .cursorrules 를 도입했다. 셋은 방언 이고, 그 위의 언어 가 term/persistent-instructions — 영구 지시어다. 이 파일에 프로젝트의 헌법 — 기술 스택, 코딩 컨벤션, 보안 규약, 사용 금지 패턴 — 을 박아두면, AI 가 매 세션 시작 시 자동으로 다시 읽는다. Chapter 2 에서 기록된 Kahan summation 의 보상 항 의 LLM 시대 표현이 바로 이 파일이다. 망각이 일어나는 자리에 매번 같은 보정 신호 를 자동으로 기록하는 것 — 같은 자세, 다른 시대.

3.4 도구의 관점 — 컨텍스트 파이프라인 한 컷

[[DIAGRAM:3-1]]

[[DIAGRAM:3-2]]

다이어그램 3-1 은 컨텍스트 엔지니어링의 7 요소가 하나의 입력 파이프라인 으로 어떻게 합쳐지는지를 보여준다. 사용자의 한 줄 질문이 들어올 때, 그 질문 뒤에 시스템 프롬프트와 영구 지시어가 자동으로 박히고, 앞에 RAG 가 검색한 관련 청크가 박히며, 옆에 MCP 도구 정의가 기록된다. 사용자는 한 줄 만 입력했지만, 모델이 받는 실제 컨텍스트는 수만 토큰의 정교한 묶음 이다. 다이어그램 3-2 는 이 묶음이 프롬프트의 4 슬롯과 어떻게 1:1 매핑 되는지를 보여준다 — 4 슬롯이 시스템 단위로 확대된 형태 가 곧 컨텍스트 엔지니어링이다.

여기서 한 가지 미묘한 점을 짚어둔다. 7 요소 중 어느 하나도 AI 가 자동으로 채워주지 않는다. RAG 의 청크 선택 정책, MCP 의 도구 권한 분리, 영구 지시어의 헌법 조항, 압축 전략 — 모두 사람이 설계한다. 컨텍스트 엔지니어링은 기술 이 아니라 자세 다. 도구가 제공 할 뿐, 결과 는 사용자의 설계에 달려 있다. 이 점이 본 책 전체에서 반복적으로 강조되는 AI-native 의 정의 와 다시 만난다.

3.4.1 실무 워크플로 — 새 프로젝트의 첫 30 분

추상 다이어그램만으로는 컨텍스트 엔지니어링이 실제로 어떻게 시작되는가 가 손에 잡히지 않는다. 그래서 한 명의 엔지니어가 새 프로젝트 를 시작할 때 따르는 첫 30 분의 7 단계 워크플로 를 한 컷으로 기록한다. 시나리오는 단순하다 — PostgreSQL 14 기반의 SaaS 백엔드 신규 프로젝트, 팀 인원 3 명, 인증·결제·관리자 콘솔 3 개 모듈 예정.

1 단계 — CLAUDE.md 초안 (5 분). 프로젝트 루트에 CLAUDE.md 를 만들고 헌법 6 항목 을 기록한다 — (1) 기술 스택 (Python 3.12 / FastAPI / SQLAlchemy / PostgreSQL 14), (2) 코딩 컨벤션 (black / ruff / 타입 힌트 필수), (3) 보안 규약 (인증 미들웨어 우회 ❌, secrets 는 환경 변수만), (4) 테스트 정책 (pytest, 커버리지 80% 이상), (5) 사용 금지 패턴 (raw SQL ❌ → ORM 만, print 디버깅 ❌ → logger), (6) 출력 규약 (코드 응답은 한 파일 단위로). 각 항목 1 ~ 2 줄. 이 파일이 Chapter 2 의 Kahan 보상 항 자리다.

2 단계 — 의존성 잠금 (3 분). pyproject.toml 또는 requirements.txt 에 정확한 버전 을 기록한다. AI 가 최신 버전 을 가정하고 코드를 짜다가 깨지는 경우 를 차단하기 위해. 깨끗한 컨텍스트 의 절반은 깨끗한 환경 정의 에서 온다.

3 단계 — RAG 인덱스 (5 분). 기존 코드베이스가 있다면 (없으면 건너뜀) embedding 모델 로 코드와 문서를 청크 단위로 벡터 DB 에 기록한다. 도구 선택은 가벼운 쪽 — 로컬은 ChromaDB, 클라우드는 Qdrant Cloud. 코드 청크 단위 는 함수·클래스 단위로 자르는 것이 일반적이다. 이 인덱스가 어제까지의 결정 에 대한 검색 가능 메모리가 된다.

4 단계 — MCP 서버 연결 (5 분). 첫 프로젝트라면 두 개로 시작하면 충분하다 — GitHub MCP 서버 (issue·PR 자동 생성·읽기) 와 파일시스템 MCP 서버 (격리된 작업 디렉토리 read/write). 사내 DB MCP 는 권한 분리 가 필요해 2 주차 이후 에 추가한다. 첫날부터 운영 DB write 권한을 AI 에게 주지 않는다.

5 단계 — 압축 정책 (3 분). 채팅 히스토리가 50 K 토큰을 넘기면 오래된 절반을 요약본으로 대체 하는 규칙을 기록한다. Claude Code · Cursor 모두 이 기능이 내장이지만 임계값 은 사용자가 설정한다. 너무 자주 압축하면 디테일을 잃고, 너무 늦게 하면 부패가 시작된다. 50K 가 일반적 시작점.

6 단계 — 장기 기억 폴더 (3 분). .ai/memory/ 같은 폴더를 만들어 세션 외부에 박힐 사실들 을 모아둔다 — 사용자 프로필, 클라이언트 요구사항, 합의된 아키텍처 결정 (ADR, Architecture Decision Records), 거절된 대안과 그 이유. 이 폴더는 RAG 인덱스의 부분집합 이지만 항상 고정 우선순위로 컨텍스트에 박히는 영역이다.

7 단계 — 첫 작업 한 줄 (6 분). 모든 준비가 끝나면 첫 실제 작업을 한 줄로 기록한다. 4 슬롯이 그대로 살아 있다 — 역할: "너는 PostgreSQL 14 시니어 백엔드 엔지니어다.", 맥락: (CLAUDE.md 가 자동 로드), 형식: "응답은 파일 단위 코드 + 짧은 설명.", 루프: "단계별로 검토하고 자가 평가 후 마무리." 이 한 줄이 Chapter 1 의 한 번의 질문 이고, 그 질문의 환경 전체 가 30 분 동안 박혀온 컨텍스트다.

이 30 분이 끝나면 컨텍스트 엔지니어링의 기본 골격 이 기록된다. 이 골격이 박히지 않은 채 시작한 프로젝트가 3 개월 뒤 무너지는 모습은 본 책의 다음 Part 2 가 자세히 보여줄 것이다.

3.5 닫으며 — 컨텍스트의 한계가 다시 다음 시대를 부른다

본 장의 결론을 한 줄로 정리하면 이렇다 — 컨텍스트 엔지니어링은 프롬프트의 4 슬롯이 시스템 단위로 펼쳐진 형태 다. 한 줄에서 시스템으로의 도약, 그리고 그 도약을 가능하게 한 7 요소 (시스템 프롬프트 / 히스토리 / 장기 기억 / RAG / MCP / 압축 / 영구 지시어). 이 도약 덕분에 우리는 시간을 가로질러 유지되는 자세를 갖출 수 있게 되었다.

그러나 다시 한 번 — 기술의 진보 가 사용자의 자세 진보 를 자동으로 끌고 가지 않는다. 컨텍스트 엔지니어링이 7 요소를 제공 하지만, 그 요소들을 어떻게 조합할 것인가 는 사용자의 설계 능력에 달려 있다. 그리고 잘못 조합된 컨텍스트는 오히려 모델 응답의 품질을 떨어뜨린다 — 이것이 본 책의 다음 도약을 부른다. 바이브 코딩(Vibe Coding) 의 시대는 컨텍스트 엔지니어링의 도구를 전부 갖추고 시작되었다. 그러나 그 도구를 어떻게 쓸 것인가 의 자세를 갖추지 못한 시대였다. 그래서 폭발적 확산 뒤에 3 개월의 벽으로 무너졌다.

다음 Chapter 4 (Part 2 의 시작) 는 그 폭발과 붕괴의 자리로 들어간다. 바이브 코딩의 폭발적 확산 — Lovable, Replit, v0, Bolt 가 어떻게 몇 분 만에 앱을 배포하는 마법 을 보여주었는지, 그리고 그 마법이 어떻게 컨텍스트 엔지니어링의 도구를 갖춘 채로 무너졌는지를 본다.

3.6 용어 정리

  • 컨텍스트 엔지니어링 (Context Engineering): LLM 의 한정된 컨텍스트 윈도우 안에 응답 시점에 어떤 정보가 어떤 밀도로 기록되어 있게 할 것인가 를 시스템적으로 설계하는 기술 — 2024 카파시·뤼트케 명명
  • 시스템 프롬프트 (System Prompt): 세션 시작 시 자동 로드되어 모델의 페르소나·행동 규약을 기록하는 메시지 — 사용자 비공개 영역
  • 장기 기억 (Long-term Memory): 세션 외부에 기록된 사실 (사용자 프로필·프로젝트 상태) — 매 세션 관련 부분만 컨텍스트에 주입
  • RAG (Retrieval-Augmented Generation, 검색 증강 생성): 외부 문서 코퍼스를 벡터 DB 에 저장 → 질문과 의미적으로 가까운 청크만 실시간 검색·주입 — 50 년 IR 전통의 LLM 시대 결합
  • 벡터 데이터베이스 (Vector Database): embedding 벡터를 의미 유사도로 검색하는 DB — Pinecone / Weaviate / Qdrant / Chroma 등
  • embedding (임베딩): 텍스트를 고차원 벡터 공간의 한 점으로 변환한 표현 — 의미적 유사도를 벡터 거리 로 측정 가능하게 함
  • MCP (Model Context Protocol): Anthropic 2024 발표. LLM 과 외부 도구 간 표준 통신 프로토콜 — Anthropic 이 만들었지만 공개 표준
  • MCP 서버 / MCP 클라이언트: 도구를 정의하는 쪽 / 도구를 발견·호출하는 쪽 (Claude Code · Cursor 등)
  • 컨텍스트 압축 (Context Compaction): 누적된 컨텍스트의 일부를 요약본 으로 대체해 토큰 공간을 회수
  • 영구 지시어 (Persistent Instructions): 프로젝트 헌법 을 박아 매 세션 자동 리로드. 도구별 방언 = CLAUDE.md / AGENTS.md / .cursorrules
  • TF-IDF / BM25: sparse 검색의 고전 — 단어 빈도와 문서 분포로 관련도 계산
  • Function Calling: OpenAI 의 벤더 종속 도구 호출 규약 — MCP 등장으로 점차 흡수
  • service mesh: 마이크로서비스 간 통신 표준 인프라 — MCP 의 분산 시스템 원형

3.7 더 읽을거리

위키 카드:

1차 출처:

  • Karpathy "Context engineering is the new prompt engineering." — X, 2024 말
  • Tobias Lütke 동의 트윗 (Shopify CEO)
  • Anthropic Model Context Protocol 발표 — 2024-11
  • Lewis et al. "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", Meta AI, 2020

Diagram 명세 블록

[[DIAGRAM:3-1]] 컨텍스트 엔지니어링의 7 요소 — 입력 파이프라인 한 컷

┌────────────────────────────────────────────────────────────────────┐
│ [Diagram 3-1] 컨텍스트 엔지니어링 — 한 줄 질문 뒤의 7 요소 파이프라인 │
├────────────────────────────────────────────────────────────────────┤
│                                                                      │
│         [사용자의 한 줄 질문]                                        │
│                  │                                                   │
│      ┌───────────┼───────────────┐                                  │
│      │           │               │                                   │
│      ▼           ▼               ▼                                   │
│  ① 시스템    ② 채팅          ③ 장기 기억                          │
│   프롬프트     히스토리        (사용자 프로필                       │
│  (페르소나)   (이전 대화)      / 프로젝트 상태)                     │
│                                                                      │
│      └───────────┬───────────────┘                                  │
│                  ▼                                                   │
│      ┌───────────────────────────┐                                  │
│      │ ④ RAG                     │  외부 문서 → 벡터 DB →           │
│      │   (검색 증강 생성)         │  의미 유사도 → 청크 주입         │
│      └───────────────────────────┘                                  │
│                  │                                                   │
│                  ▼                                                   │
│      ┌───────────────────────────┐                                  │
│      │ ⑤ MCP                     │  외부 도구 (DB · API · 파일      │
│      │   (Model Context Protocol) │  · GitHub · Linear · Notion)    │
│      └───────────────────────────┘                                  │
│                  │                                                   │
│                  ▼                                                   │
│      ┌───────────────────────────┐                                  │
│      │ ⑥ 컨텍스트 압축           │  누적 히스토리 → 요약본          │
│      │   (compaction)             │  → 토큰 공간 회수                │
│      └───────────────────────────┘                                  │
│                  │                                                   │
│                  ▼                                                   │
│      ┌───────────────────────────┐                                  │
│      │ ⑦ 영구 지시어             │  CLAUDE.md / AGENTS.md /         │
│      │   (Persistent Instructions)│  .cursorrules — 매 세션 리로드  │
│      └───────────────────────────┘                                  │
│                  │                                                   │
│                  ▼                                                   │
│         [모델이 받는 실제 컨텍스트 = 수만 토큰의 정교한 묶음]        │
│                                                                      │
│  ╳ 사용자 입력: 한 줄  →  모델 입력: 시스템 단위                     │
│  ╳ 7 요소 모두 *사람이 설계*. AI 가 자동으로 채우지 않음.            │
│                                                                      │
├───────────────────────────────────────────────────────────────