컨트롤 플레인(Control Plane): LLM 에이전트의 설정 파일들
요약
LLM 에이전트 아키텍처에서 설정 파일들이 수행하는 '컨트롤 플레인(Control Plane)' 역할을 설명합니다. 설정 파일은 코드를 수정하지 않고도 에이전트의 지식, 추론 방식, 도구 사용 능력을 매개변수화하여 조절하는 핵심 계층입니다.
핵심 포인트
- 설정 파일은 에이전트의 동작을 제어하는 컨트롤 플레인 역할을 수행함
- 에이전트의 세 가지 조절 장치: 메모리, 추론, 도구 계층
- AGENTS.md, CLAUDE.md 등은 시스템 프롬프트에 병합되어 추론 방식을 결정함
- 컨트롤 플레인과 데이터 플레인의 분리를 통해 에이전트 아키텍처를 구조화함
AGENTS.md, CLAUDE.md, MEMORY.md, SKILLS.md, 슬래시 명령어(slash commands), 훅(hooks), MCP 서버, 그리고 settings.json과 같은 파일들이 에이전트 아키텍처에 어떻게 연결되는지에 대하여.
1. 핵심 개념
설정 파일은 새로운 아키텍처 계층이 아닙니다. 이들은 _컨트롤 플레인(control plane)_으로, 에이전트의 코드를 변경하지 않으면서 기존 계층(인터페이스, 오케스트레이터, LLM, 메모리, 도구, 환경)을 **매개변수화(parameterize)**하는 병렬적인 아티팩트(artifacts) 세트입니다.
이 용어는 네트워킹 및 분산 시스템에서 빌려온 것입니다. **데이터 플레인(data plane)**은 런타임에 트래픽을 처리하는 반면, **컨트롤 플레인(control plane)**은 데이터 플레인이 수행하는 작업(경로, 정책, ACL)을 개별 패킷 경로에 참여하지 않고 _설정(configures)_하는 모든 것을 의미합니다. 이러한 분리는 소프트웨어 정의 네트워킹(SDN)과 Kubernetes에서 표준적인 방식입니다. (§7에서 이 비유를 더 자세히 설명합니다.)
유용한 교육적 프레임워크(표준 문헌 용어는 아니며, 이 노트에서 동일한 자료를 정리하는 방식일 뿐입니다)를 사용하자면, 에이전트에는 **외부에서 돌릴 수 있는 세 가지 노브(knobs, 조절 장치)**가 있습니다:
- 무엇을 아는가: 메모리(memory) 계층 (사실, 이력, 문서).
- 어떻게 행동하는가: 추론(reasoning) 계층 (지침, 관례, 스타일).
- 무엇을 할 수 있는가: 도구(tool) 및 오케스트레이터(orchestrator) 계층 (도구, 권한, 훅, 런타임 제한).
모든 설정 파일은 이 노브 중 하나에 해당합니다.
2. 매핑: 파일에서 계층으로
추론 계층 (Reasoning layer, 시스템 프롬프트의 일부가 됨)
| 파일 | 목적 |
|---|---|
AGENTS.md / CLAUDE.md / .cursorrules | 프로젝트 수준의 관례, 권장/금지 사항, 출력 스타일. 세션 시작 시 한 번 로드되어 시스템 프롬프트(system prompt)에 병합됩니다. |
| ... |
이것들은 LLM이 단 하나의 사용자 메시지를 보기 전에 _LLM이 생각하는 방식_을 형성합니다.
AGENTS.md는 OpenAI Codex, Amp, Jules (Google), Cursor, Factory에서 시작되어 현재 Linux Foundation 산하의 Agentic AI Foundation에서 관리하는 작고 주관적인(opinionated) 벤더 간 규격(agents.md)입니다.CLAUDE.md는 Claude-Code 전용 대응 파일로,AGENTS.md보다 먼저 등장했으며, Claude Code는 발견된AGENTS.md를 대신하는 것이 아니라 그와 더불어CLAUDE.md를 읽습니다.
메모리 계층 (LLM이 읽는 지속적인 컨텍스트)
| 파일 | 목적 |
|---|---|
MEMORY.md | 지속적인 메모리(persistent memories)의 항상 로드되는 인덱스 |
| ... |
시스템 프롬프트(system-prompt) 파일과의 차이점: 메모리는 사실적 (무엇이 사실인지, 무엇이 일어났는지)이며,
AGENTS.md스타일의 파일은 행동적 (어떻게 행동할지)입니다.
도구 계층
| 파일 | 목적 |
|---|---|
.mcp.json (MCP 서버 레지스트리) | 외부 MCP 도구 서버를 선언하며, 해당 도구들을 호출할 수 있게 됩니다. |
| ... |
오케스트레이터 계층 (LLM이 아닌 루프)
이 파일들은 하네스 (harness) (오케스트레이터 런타임)에 의해 읽힙니다. LLM은 이 파일들을 절대 볼 수 없습니다.
| 파일 | 목적 |
|---|---|
settings.json | 모델 선택, 권한 모드, 최대 단계(max steps), 환경 변수(env vars), 캐싱, 비용 제한. Claude Code 설정을 참조하세요. |
| ... |
훅(Hooks)은 특별합니다. 훅을 사용하면 LLM이 수행하도록 신뢰하지 않고도 루프에 결정론적(deterministic)인 행동을 주입할 수 있습니다. 오케스트레이터는 이벤트 발생 시 훅을 트리거하며, LLM은 이를 절대 보거나 호출하지 않습니다. 이것이 §5에서 설명하는 "하네스 전용(harness-only)" 로딩 전략입니다.
환경 계층
| 파일 | 목적 |
|---|---|
| Sandbox 설정 | 컨테이너(Containers), Jail, 휘발성 워크트리(ephemeral worktrees) |
| ... | |
 |
3. 기술 (Skills): 흥미로운 사례
기술 (Skills)은 추론 (Reasoning)과 도구 (Tools) 사이의 경계를 가로지릅니다. 이는 순수한 프롬프트도, 순수한 도구도 아니며, **필요할 때 호출되는 프롬프트 확장 (prompt expansions)**입니다.
- 메타데이터 (metadata) (YAML frontmatter:
name,description,when_to_use)는 항상 도구 카탈로그 (tool catalog)에 포함되어 있어, LLM이 해당 기술이 존재함을 알 수 있게 합니다. - 본문 (body) (실제 지침)은 기술이 호출될 때만 (Skill 도구를 통하거나 자동 매칭을 통해) 컨텍스트 (context)에 주입됩니다.
이것이 바로 영리한 부분인 **지연 로딩 (lazy loading)**입니다. 50개의 기술을 사용할 수 있게 설정하더라도 컨텍스트에는 약 50줄의 메타데이터만 포함됩니다. 전체 본문은 관련이 있을 때만 들어옵니다. 이를 통해 프롬프트 예산 (prompt budget)을 초과하지 않으면서도 역량을 확장할 수 있습니다.
기술 (Skills)은 이제 벤더 간 개방형 표준이 되었습니다. 원래 Claude Code의 기능이었던
SKILL.md형식은 Anthropic에 의해 오픈 Agent Skills 사양 (agentskills.io)으로 공개되었으며, Cursor, GitHub Copilot, VS Code, Gemini CLI, OpenAI Codex, OpenHands, Goose, Letta, JetBrains Junie, Factory, Amp, Kiro, OpenCode, Spring AI, Mistral Vibe, Snowflake Cortex, Databricks Genie, Laravel Boost 등이 이를 채택했습니다. 따라서 이 섹션의 나머지 부분에서는 Claude Code의 용어를 사용하지만, 그 원형 (도구 카탈로그 메타데이터를 통해 발견 가능한 지연 로딩된 프롬프트 확장)은 MCP 도구 서버와 마찬가지로 생태계 전반에서 이식 가능합니다. 사양은 agentskills.io/specification에서, 소스 코드는 github.com/agentskills/agentskills에서 확인할 수 있으며, Anthropic의 참조 예시 기술들은 github.com/anthropics/skills에 있습니다.
슬래시 명령어 (Slash commands)도 유사하게 작동하지만, 도구 호출 (tool call)로 실행되는 대신 *사용자 메시지 (user message)*로 확장됩니다. 공식 설명은 Claude Code skills 및 Claude Code slash commands에서 확인할 수 있습니다.
4. 모델 로딩: 각 아티팩트(Artifact)가 컨텍스트에 진입하는 시점
| 아티팩트 (Artifact) | LLM이 이를 보는가? | 로딩 시점 |
|---|---|---|
AGENTS.md / CLAUDE.md | 예 | 세션 시작 시, 항상 |
| ... | ||
| 하단 절반이 중요한 차이점입니다: 하네스(Harness)는 이를 읽지만, LLM은 절대 읽지 못합니다. 특히 훅(Hooks)은 LLM이 직접 수행하도록 신뢰하지 않고도, LLM | ||
| '주변(around)'에서 무언가를 실행하게 만드는 방법입니다. |
5. 세 가지 로딩 전략
- 항상 로딩 (Always loaded): 매 턴마다 시스템 프롬프트(System Prompt)나 컨텍스트(Context)에 위치합니다. 비용: 컨텍스트 창(Context-window) 공간. 용도: 절대 건너뛰어서는 안 되는 규칙.
- 지연 / 온디맨드 (Lazy / on-demand): 호출, 검색 또는 참조될 때만 컨텍스트에 진입합니다. 비용: 도구 호출(Tool call) 또는 검색(Retrieval) 단계. 용도: 항상 필요하지는 않은 방대한 양의 기능(Capability).
- 하네스 전용 (Harness-only): LLM 컨텍스트에 전혀 진입하지 않습니다. 런타임(Runtime)이 이를 결정론적(Deterministically)으로 실행합니다. 비용: 컨텍스트 비용 없음. 용도: LLM이 건너뛰거나, 무시하거나, 환각(Hallucination)을 일으키지 않기를 원하는 모든 것.
에이전트 설정의 기술은 각 요소에 적합한 전략을 선택하는 것입니다. 핵심 안전 정책 → 하네스 전용 (훅). 관련 있을 때 LLM이 선택하는 기술 → 지연 로딩. 프로젝트 컨벤션(Conventions) → 항상 로딩.
6. 멘탈 모델 (Mental model): 세 가지 노브(Knobs)
(표준 용어는 아니며 교육적 프레임워크입니다. §1 참조.)
| 노브 (Knob) | 조정하는 레이어 (Layer) | 파일 |
|---|---|---|
| 무엇을 아는가 (What it knows) | 메모리 (Memory) | MEMORY.md, 메모리 파일, 문서, RAG 소스 |
| ... | ||
| 기술(Skills)은 특별합니다. 기술은 어떻게 행동하는가 (How it acts) 노브를 _지연 방식(Lazily)_으로 조정하므로, 필요할 때까지 기능(Capability)이 컨텍스트 비용을 발생시키지 않습니다. |
7. 왜 "컨트롤 플레인(Control Plane)"인가?
네트워킹과 시스템에서 사용하는 용어를 빌려오자면: **데이터 플레인 (Data Plane)**은 요청을 차례대로 처리하는 런타임(runtime)입니다 (agent-architecture.md의 아키텍처 참조). **컨트롤 플레인 (Control Plane)**은 데이터 플레인에 직접 참여하지 않으면서 데이터 플레인을 *설정(configure)*하는 모든 것을 의미합니다: 정책(policies), 기능(capabilities), 권한(permissions), 프롬프트(prompts), 훅(hooks) 등이 이에 해당합니다. 이는 소프트웨어 정의 네트워킹(SDN), Kubernetes (kube-apiserver + 컨트롤러 vs kubelet + CNI), 그리고 서비스 메시(service meshes)에서 사용하는 것과 동일한 분리 방식입니다.
잘 설계된 에이전트는 다음과 같이 깔끔하게 분리되어 있습니다:
- **데이터 플레인 (Data Plane)**은 범용적입니다: 프로젝트와 상관없이 동일한 루프(loop), 동일한 LLM, 동일한 오케스트레이터(orchestrator)를 사용합니다.
- **컨트롤 플레인 (Control Plane)**은 프로젝트별로 특화됩니다:
AGENTS.md, 활성화된 MCP 서버들, 설치된 훅(hooks), 추가된 기술(skills) 등이 포함됩니다.
이것이 바로 Claude Code와 같은 단일 도구가 프로젝트마다 완전히 다른 에이전트가 될 수 있는 이유입니다 — 데이터 플레인은 같지만, 컨트롤 플레인이 다르기 때문입니다.
8. 실질적인 시사점 (Practical implications)
- 컨트롤 플레인에 속해야 할 동작을 코드에 넣지 마세요. 프로젝트에서 에이전트의 동작 방식을 바꾸기 위해 하네스(harness)를 포크(fork)하고 있다면, 대신 훅(hook),
AGENTS.md규칙, 또는 기술(skill)을 사용하는 것이 적절할 것입니다. - 중요한 규칙을 LLM이 따를 것이라고 믿지 마세요. 중요한 정책은 시스템 프롬프트(system prompt, LLM 제안 방식)가 아니라 훅(hook, 하네스 강제 방식)에 포함되어야 합니다.
- 지연 로딩(Lazy loading)을 적극적으로 활용하세요. 모든 것을
AGENTS.md에 넣으면 컨텍스트(context)가 낭비됩니다. 크기가 크거나 상황에 따라 필요한 콘텐츠는 기술(skill)이나 메모리(memory)로 옮기세요. - 컨트롤 플레인을 코드처럼 취급하세요. 버전 관리(versioning)를 하고, 리뷰하고, 테스트하세요. 특히 훅(hooks)은 매우 큰 영향을 미칠 수 있습니다.
9. 요약 (TL;DR)
런타임 아키텍처는 에이전트가 작동하는 방식입니다. 컨트롤 플레인은 당신의 컨텍스트에서 에이전트가 어떻게 작동하도록 지시할 것인가입니다. 각 설정 파일은 세 가지 로딩 전략(항상 로드 / 지연 로드 / 하네스 전용) 중 하나를 사용하여 특정 레이어에 연결됩니다. 핵심은 각 요소에 적합한 전략을 선택하는 기술입니다.
참고 문헌 (References)
프레이밍에 관한 노트 (Notes on framing)
위에서 사용된 몇 가지 프레이밍(framing)은 저자의 교육용 도구이며, 표준 문헌 용어가 아닙니다. 독자가 교과서에서 이 용어들을 찾으려 하지 않도록 여기서 별도로 표시해 둡니다:
- "The harness" (하네스): 학술 논문이 아닌 산업계에서 "LLM을 감싸는 오케스트레이터 런타임 (orchestrator runtime)"(Claude Code, Aider, OpenHands, Devin 등)을 지칭할 때 흔히 사용됩니다.
- "Three knobs" (세 개의 노브) (무엇을 아는가 / 어떻게 행동하는가 / 무엇을 할 수 있는가): 이 노트에 특화된 교육용 도구입니다. 카테고리 자체는 표준적인 아키텍처 계층(architectural layers)에 대응하며, 오직 이 *삼중 프레이밍 (triplet framing)*만이 독창적인 방식입니다.
- "Control plane / data plane" (컨트롤 플레인 / 데이터 플레인): 네트워킹과 Kubernetes (쿠버네티스)에서 빌려온 용어입니다. 이는 비유일 뿐, 에이전트 내부 구조에 대한 심도 있는 주장은 아닙니다.
- "Always loaded / lazy / harness-only" (항상 로드됨 / 레이지 / 하네스 전용): 기술적인 설명용 라벨입니다. 근본적인 메커니즘은 표준적이지만, 이 세 가지로 분류하는 방식은 이 노트 내부의 분류 체계(taxonomy)입니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기