대부분의 사람들은 여전히 프롬프트(Prompt)를 작성하고 있습니다. 하지만 진짜 기술은 컨텍스트(Context)를 설계하는 것입니다. AI 에이전트(Agent) 컨텍스트에 대한 불편한 진실은 이것입니다: 병목 현상은 모델(Model)에서 발생하는 경우가 거의 없다는 점입니다. 바로 컨텍스트가 병목입니다. 저는 지난 6개월 동안 제가 "Rocha Family Home OS"라고 부르는 플랫폼을 구축하는 데 시간을 보냈습니다. 이는 GitHub Copilot에 의해 오케스트레이션(Orchestrated)되는 50개의 자율 AI 에이전트(AI agents)와 71개의 재사용 가능한 기술(skills)로 구성된 플랫폼입니다. 이 에이전트들은 가족 재정 및 식단 계획부터 콘텐츠 발행 및 주택 유지보수에 이르기까지 모든 것을 관리합니다. 이들은 cron 스케줄에 따라 실행되며, 세션(Session) 간에 통신하고, 지속적인 메모리(Persistent memory)를 유지합니다. 그리고 제가 개발한 단 하나의 가장 중요한 규율은 프롬프트 엔지니어링(Prompt engineering)이 아닙니다. 그것은 바로 컨텍스트 엔지니어링(Context engineering)입니다. 즉, 각 에이전트가 매 순간 무엇을 보고, 기억하고, 행동할지를 설계하는 예술이자 과학입니다. Andrej Karpathy가 "프롬프트 엔지니어링 (Prompt engineering)"보다 "컨텍스트 엔지니어링 (Context engineering)"을 공개적으로 옹호했을 때, 그는 이를 "다음 단계를 위해 컨텍스트 윈도우 (Context window)를 딱 적절한 정보로 채우는 섬세한 예술이자 과학"이라고 설명했습니다. 그 프레임워크는 제가 시스템을 구축하는 방식을 바꾸어 놓았습니다. 저는 올해 초에 컨텍스트 엔지니어링의 이론적 토대에 대해 글을 썼습니다. 이 글은 프로덕션(Production) 버전의 후속편입니다. 즉, 실제 세상에서 50개의 에이전트를 운영할 때 컨텍스트 엔지니어링이 실제로 어떤 모습인지에 대한 것입니다.

왜 컨텍스트 엔지니어링이 프롬프트 엔지니어링보다 더 중요한가
프롬프트 엔지니어링은 단일 턴(Single turn)을 위한 영리한 지침을 작성하는 것입니다. 컨텍스트 엔지니어링은 모델이 단 하나의 토큰(Token)을 생성하기 전에 무엇을 볼지를 결정하는 전체 정보 아키텍처(Information architecture)를 설계하는 것입니다. 이는 수많은 턴, 수많은 에이전트, 그리고 수많은 세션에 걸쳐 이루어집니다.

채팅의 범위를 넘어서게 되면 다음과 같은 차이점이 매우 중요해집니다:

구분	Prompt Engineering (프롬프트 엔지니어링)	Context Engineering (컨텍스트 엔지니어링)
범위 (Scope)	단일 요청 (Single request)	에이전트 전체 생명주기 (Entire agent lifecycle)
지속성 (Persistence)	상태 비저장 (Stateless)	멀티 세션 메모리 (Multi-session memory)
규모 (Scale)	하나의 모델, 하나의 턴 (One model, one turn)	50개의 에이전트, 71개의 기술, 공유 상태 (50 agents, 71 skills, shared state)
접근 방식 (Approach)	좋은 질문을 작성함 (Craft a good question)	모델이 무엇을 알고, 기억하며, 무엇을 할 수 있는지 설계함 (Design what the model knows, remembers, and can do)

Anthropic의 엔지니어링 팀은 컨텍스트를 "대규모 언어 모델 (Large-language model)에서 샘플링할 때 포함되는 토큰의 집합"으로 정의하며, 엔지니어링 과제를 "LLM의 내재적 제약 조건에 맞서 해당 토큰들의 유용성을 최적화하는 것"으로 정의합니다. 멀티 에이전트 시스템 (Multi-agent system)에서는 이 과제가 배가됩니다. 모든 에이전트는 서로 다른 작업, 서로 다른 도구, 그리고 서로 다른 지식 요구 사항을 가집니다. 단순히 50개의 좋은 프롬프트를 작성하는 것만으로는 부족하며, 50개의 컨텍스트 아키텍처 (Context architectures)를 설계해야 합니다. Google의 Agent Development Kit 블로그는 이를 완벽하게 설명합니다. 컨텍스트는 계속해서 추가하기만 하는 가변적인 문자열 버퍼 (Mutable string buffer)가 아니라, "더 풍부한 상태 유지 시스템 (Stateful system)에 대한 컴파일된 뷰 (Compiled view)"여야 합니다. 이것이 바로 제 플랫폼이 작동하는 방식입니다.

4단계 메모리 시스템 (The 4-Tier Memory System)

제가 공유할 첫 번째 컨텍스트 엔지니어링 패턴은 계층형 메모리 (Tiered memory)입니다. 제 플랫폼의 모든 상태 유지 에이전트 (Stateful agent)는 다음과 같은 4단계 메모리 시스템을 사용합니다:

data/agents/{agent-name}/
├── core.md # 1단계 (Tier 1) — 정체성, 규칙, 휴리스틱 (3-5KB)
├── working.md # 2단계 (Tier 2) — 현재 상태, 활성 컨텍스트 (최대 5KB)
├── long-term.md # 3단계 (Tier 3) — 과거 패턴, 교훈 (최대 10KB)
└── events.log # 4단계 (Tier 4) — 추가 전용 감사 추적 (Append-only audit trail) (무제한)

핵심 통찰은 모든 메모리가 컨텍스트 윈도우 (Context window) 공간을 차지할 가치가 있는 것은 아니라는 점입니다. 각 단계의 작동 방식은 다음과 같습니다:

1단계 (core.md) — 항상 로드됨. 에이전트의 정체성, 미션, 도메인 소유권 및 엄격한 규칙을 포함합니다. 제 금융 매니저의 core.md는 이를 "Rocha 가족의 재정적 중추 — 실용적이고, 군더더기 없으며, 가족의 자산을 보호함"으로 정의합니다. 이는 세션 간에 절대 변하지 않습니다.

2단계 (working.md) — 항상 로드됨. 현재 상태를 포함합니다 — 활성 청구서, 최근 거래 내역, 보류 중인 예산 항목 등.

이것은 에이전트의 단기 기억 (short-term memory)이며, 매 실행 시마다 업데이트됩니다. 3단계 (long-term.md) — 필요할 때 로드됨. 검증된 패턴과 과거의 교훈을 포함합니다. 에이전트가 특정 결정을 위해 과거 데이터가 필요할 때만 컨텍스트 (context)로 불러옵니다. 4단계 (events.log) — 일괄 로드되지 않음. 추가 전용 (append-only) 감사 추적 (audit trail)입니다. 에이전트는 여기에 기록을 남기지만, 전체 로그를 컨텍스트로 읽어들이지는 않습니다. 이러한 계층적 접근 방식은 각 에이전트의 기본 컨텍스트를 10KB 미만으로 유지하면서도, 필요할 때 심층적인 이력에 접근할 수 있게 해줍니다. 이 방식이 없다면, 모든 에이전트는 매 실행마다 전체 이력을 로드하게 될 것이며, 이는 무관한 컨텍스트에 토큰 (tokens)을 낭비하고 Anthropic이 말하는 "컨텍스트 부패 (context rot)"(컨텍스트 크기가 커짐에 따라 회상 정확도가 저하되는 현상)를 초래하게 됩니다. 계층적 메모리 (tiered memory)를 도입하기 전에는, 규칙들이 수천 토큰의 이력 아래에 묻혀 있었기 때문에 에이전트가 지침 초기에 명시된 규칙을 가끔 "망각"하곤 했습니다. 계층을 구현한 후에는 1단계 (core identity)가 항상 컨텍스트 창 (context window)의 최상단에 위치하므로 규칙 준수가 일관되게 유지됩니다.

재사용 가능한 컨텍스트 모듈로서의 기술 (Skills as Reusable Context Modules)
두 번째 패턴은 기술 (skills)입니다. 이는 어떤 에이전트라도 호출할 수 있는 재사용 가능한 컨텍스트 모듈입니다. 저는 .github/skills/ 경로에 71개의 기술을 보유하고 있으며, 각 기술은 YAML 프론트매터 (frontmatter)가 포함된 독립적인 마크다운 (markdown) 파일로 구성되어 있습니다:

---

name: memory-management
description: >
모든 상태 유지 에이전트 (stateful agents)를 위한 4단계 메모리 시스템 관리 — 메모리 파일의 로드, 저장, 가지치기 (pruning), 승격 (promoting) 및 유지 관리. 사용자가 "메모리 로드", "메모리 저장", "작업 메모리 업데이트", "메모리 가지치기" 또는 에이전트 메모리 생명주기 활동을 언급할 때 사용합니다.

메모리 관리 기술 (Memory Management Skill)

모든 상태 유지 에이전트에서 사용되는 표준 4단계 메모리 시스템...

기술은 컨텍스트 엔지니어링 (context engineering)의 결과물입니다. 50개의 모든 에이전트에 동일한 메모리 관리 지침을 임베딩 (embedding)하는 대신, 저는 해당 패턴을 하나의 기술로 한 번만 작성하고 다음과 같이 참조합니다: "memory-management 기술을 따르세요." 에이전트가 해당 기술을 호출하면, 정확히 필요한 시점에 적절한 지식이 컨텍스트 창으로 로드됩니다.

이것은 AI 컨텍스트 (Context)에 적용된 DRY (Don't Repeat Yourself, 반복하지 마라) 소프트웨어 엔지니어링 원칙입니다. 제가 보유한 기술 (skills) 중 일부는 다음과 같습니다:

• telegram-communication — 각 가족 구성원에게 메시지를 보내는 방법 (포맷팅, 방해 금지 시간, TTS 규칙)
• copilot-brand-safety — GitHub Copilot 또는 Microsoft를 언급하는 모든 콘텐츠에 대한 브랜드 보호 규칙
• child-safety-protocol — 아동 위치 추적 및 보호자 인계에 관한 안전 필수 규칙
• daily-briefing-format — 구조화된 아침 브리핑 컴파일 워크플로 (workflow)
• email-triage — 이메일 스캔, 분류 및 자율적 행동 패턴

기술 (skills)을 도입하기 전에는 15개 이상의 에이전트 정의 (agent definitions) 전반에 걸쳐 포맷팅 규칙이 중복되어 있었습니다. Telegram 메시지 형식을 변경해야 할 때마다 모든 에이전트를 업데이트해야 했습니다. 하지만 telegram-communication 기술을 추출한 후에는, 파일 하나만 업데이트하면 모든 에이전트에 새로운 동작이 적용됩니다. 대규모 환경에서의 컨텍스트 엔지니어링 (Context engineering)은 소프트웨어 엔지니어링이며, 추상화 (abstractions)가 필요합니다.

컨텍스트 계약 (Context Contracts)으로서의 에이전트 지침 (Agent Instructions)

제 시스템의 모든 에이전트는 컨텍스트 계약 (context contract) 역할을 하는 .agent.md 파일을 가지고 있습니다. 이는 해당 에이전트가 무엇을 알고, 무엇을 소유하며, 무엇을 할 수 있는지에 대한 완전한 정의입니다.

---

name: finance-manager
description: "가족 예산 및 청구서 — Rocha 가족의 예산 추적, 청구서 결제, 지출 분류, 저축 목표 및 부채 관리를 담당합니다."

Finance Manager — Rocha 가족 예산 및 청구서

헌법 (Constitution)

다른 무엇을 하기 전에, 가족 헌법을 읽으세요: data/constitution.md

메모리 (Memory) — 4단계 시스템 (4-Tier System) — memory-management 기술 참조

가장 먼저 로드: core.md (Tier 1) + working.md (Tier 2)
가장 마지막에 저장: working.md 업데이트, events.log에 추가

정체성 및 성격 (Identity & Personality)

당신은 Rocha 가족의 재정적 중추입니다. 실용적이고, 군더더기가 없으며, 가족의 자산을 보호합니다.

도메인 소유권 (Domain Ownership) ### 예산 관리 (Budget Management) - 모든 수입과 지출 추적 - 월간 예산 유지 - 예산 대비 실제 집행 보고서 실행 - 예산 초과 추세가 50% 및 80%에 도달한 카테고리에 플래그 표시 ## 의사결정 프레임워크 (Decision Framework) ### 즉시 실행 (확인 불필요) - 지출 및 수입 기록 - 청구서 알림 전송 ### 먼저 질문하기 - 주요 구매 결정 (>$200)

이 구조는 제가 '점진적 컨텍스트 로딩 (progressive context loading)'이라고 부르는 컨텍스트 엔지니어링 (Context Engineering) 패턴입니다. 에이전트는 모든 것을 한꺼번에 받지 않습니다. 에이전트는 다음을 받습니다:

정체성 (Identity) — 나는 누구인가? (즉시 로드됨)
헌법 참조 (Constitution reference) — 시스템 전반의 규칙은 무엇인가? (첫 번째 작업 시 로드됨)
메모리 참조 (Memory references) — 내가 현재 알고 있는 것은 무엇인가? (메모리 기술 (memory skill)에 따라 로드됨)
도메인 소유권 (Domain ownership) — 내가 관리하는 영역은 무엇인가? (항상 컨텍스트에 포함됨)
의사결정 프레임워크 (Decision framework) — 내가 자율적으로 할 수 있는 것은 무엇인가? (항상 컨텍스트에 포함됨)
기술 참조 (Skill references) — 특정 작업을 어떻게 수행하는가? (요청 시 로드됨)

이는 Google의 엔지니어링 블로그에서 말하는 '저장소와 표현의 분리 (separating storage from presentation)'를 반영합니다. 전체 지식 베이스 (knowledge base)는 파일로 존재하지만, 오직 관련 있는 부분만이 각 에이전트의 작업 컨텍스트 (working context)로 컴파일됩니다.

헌법 패턴 (The Constitution Pattern)
제 시스템에서 가장 강력한 컨텍스트 엔지니어링 패턴은 헌법 (constitution)입니다. 이는 모든 프로덕션 에이전트가 어떤 작업을 수행하기 전에 읽는 공유 문서입니다:

Rocha 가족 헌법

이 시스템 내의 모든 에이전트를 규정하는 근본적인 규칙입니다.

핵심 원칙

1. 태스크 우선 시스템 (Task-First System). 태스크 (Task)는 Hector의 주요 인터페이스입니다. 실행 가능한 모든 발견 사항은 태스크가 됩니다.
2. 먼저 실행하고, 나중에 보고하라. 감지(Detect) → 실행(Act) → 알림(Notify). 절대 "~해드릴까요?"라고 말하지 마십시오.
3. 가정 금지 — 명확한 확인 우선. 지식의 공백을 절대로 가정으로 채우지 마십시오. 추측하는 대신 명확화 태스크 (clarification task)를 생성하십시오.
4. 자녀 위치 — 안전 최우선 (SAFETY CRITICAL). 자녀의 위치를 현재 사실로 절대 단정 지어 말하지 마십시오.

헌법은 근본적인 멀티 에이전트 (multi-agent) 문제인 '행동 일관성 (behavioral consistency)'을 해결합니다. 헌법이 없다면, 각 에이전트는 어떻게 소통하고, 언제 행동하며, 무엇을 에스컬레이션 (escalate)해야 하는지에 대해 각자만의 해석을 발전시키게 됩니다.

공유된 헌법 (shared constitution)을 통해, 모든 에이전트는 각자의 도메인 전문 지식 (domain expertise)을 유지하면서도 동일한 핵심 원칙을 따르게 됩니다. 저는 왜 단일 프롬프트 (monolithic prompts)가 실패하는지에 대해 'Your God Prompt Is the New Monolith'에서 작성한 바 있습니다. 헌법은 그와 반대되는 패턴입니다. 즉, 공유된 단일 컨텍스트 (monolithic context) 없이도 공유된 거버넌스 (shared governance)를 구현하는 것입니다. 각 에이전트는 헌법을 읽고 원칙을 내재화한 다음, 자신의 도메인 내에서 독립적으로 작동합니다.

실제 전/후 사례

예시 1: 가정 (Assumption) 문제
컨텍스트 엔지니어링 (context engineering) 적용 전:
에이전트: "NICU(신생아 집중치료실)로 오후 5시 15분에 출발하세요 — 차로 20분 거리입니다."
에이전트는 제가 집에 있다고 가정했습니다. 실제로는 사무실에 있었고, 거리는 45분이 걸리는 곳이었습니다. NICU에 미숙아 쌍둥이가 있는 상황에서, 신뢰하는 AI의 잘못된 지시를 따르는 것은 실제적인 안전 문제 (safety concern)가 됩니다.

헌법에 '명확화 우선 (clarification-first)' 원칙을 추가한 후:
에이전트: "NICU 출발 시간을 계산하기 위해 현재 위치가 필요합니다. 작업 생성됨: '지금 어디에 계신가요?'"
이제 에이전트는 추측하는 대신 명확화를 위한 작업을 생성합니다. 공유된 헌법에 "가정 금지 (no assumptions)" 규칙을 추가한 이 단 한 번의 컨텍스트 엔지니어링 변화가 50개의 모든 에이전트에서 동시에 동작을 수정했습니다.

예시 2: 기술 추출 (Skill Extraction)
기술 추출 전:
저의 콘텐츠 제작 (content-creative) 에이전트에는 200줄 이상의 브랜드 안전 (brand safety) 규칙이 직접 삽입되어 있었습니다. 블로그 작성 (blog-writer) 에이전트는 다른 버전을 가지고 있었고, 콘텐츠 관리 (content-manager) 에이전트는 또 다른 버전을 가지고 있었습니다. 규칙을 업데이트해야 할 때, 하나를 놓치면 브랜드 일관성이 깨진 콘텐츠를 게시하게 되었습니다.

코파일럿 브랜드 안전 (copilot-brand-safety) 기술을 추출한 후:
세 에이전트 모두 하나의 정전 (canonical) 기술을 참조합니다. 브랜드 규칙은 한 곳에 모여 있어 항상 일관되며, 어떤 업데이트든 즉시 전파됩니다. 저는 에이전트 개발 성숙도 곡선 (agentic development maturity curve)에 관한 글에서 이 아키텍처 패턴을 다루었습니다. 즉, 전문가들은 재사용 가능한 패턴을 추출함으로써 단순함으로 돌아갑니다.

예시 3: 메모리 계층 최적화 (Memory Tier Optimization)
계층형 메모리 (tiered memory) 적용 전:
저의 데일리 브리핑 (daily briefing) 에이전트는 지금까지 생성했던 모든 브리핑의 전체 이력을 로드했습니다.

3주 차에 접어들자, 컨텍스트 (context)의 80%는 오래된 과거 데이터였고 20%만이 오늘의 실제 브리핑 내용이었습니다. 관련 정보가 파묻혀 버리는 바람에 캘린더 이벤트를 놓치기 시작했습니다. 4단계 시스템 (4-tier system)을 구현한 후: 브리핑 에이전트는 자신의 핵심 정체성 (Tier 1)과 오늘의 상태 (Tier 2)를 로드하며, 총량은 약 8KB입니다. 과거 패턴 (Tier 3)은 반복되는 이슈를 참조해야 할 때만 로드됩니다. 결과: 에이전트의 주의력 (attention)이 지금 당장 중요한 것에 집중되었기 때문에, 브리핑은 더 정확해졌고 생성 속도도 빨라졌습니다.

Context Engineering 체크리스트
AI 에이전트를 구축하고 있다면 — 그것이 한 개이든 50개이든 — 제가 시작할 때 가졌더라면 좋았을 체크리스트를 소개합니다:

아키텍처 (Architecture)
[ ] 정체성 (identity)과 상태 (state)를 분리하세요. 에이전트의 정체성 (내가 누구인지, 무엇을 소유하고 있는지)은 작업 상태 (지금 무엇이 일어나고 있는지)와 구별되어야 합니다.
[ ] 메모리 (memory)를 계층화하세요. 모든 것이 컨텍스트 윈도우 (context window) 공간을 차지할 가치가 있는 것은 아닙니다. 로딩 규칙이 있는 명시적인 계층을 설계하세요.
[ ] 재사용 가능한 패턴을 스킬 (skills)로 추출하세요. 두 에이전트가 동일한 기능이 필요하다면, 그것은 중복된 지침이 아니라 하나의 스킬이어야 합니다.
[ ] 공유된 헌법 (shared constitution)을 만드세요. 시스템 전반에 적용되는 규칙은 에이전트마다 복사해서 붙여넣는 것이 아니라 한 곳에 존재해야 합니다.

컨텍스트 품질 (Context Quality)
[ ] 중요한 규칙을 상단에 배치하세요. LLM은 최신성 편향 (recency bias)과 초두 효과 (primacy bias)를 가지고 있으므로, 중요한 지침은 맨 앞에 두어야 합니다.
[ ] 모든 계층에 크기 제한을 두세요. 컨텍스트 부패 (context rot)는 실제로 일어나는 현상입니다. 엄격한 제한을 설정하고...