
프롬프트만 잘 쓰면 AI Agent를 만들 수 있을까요?
많은 사람이 Claude Code를
“코딩을 잘해주는 AI” 정도로 생각합니다.
하지만 실제 개발 환경에서 중요한 것은 프롬프트 하나가 아닙니다.
AI가 프로젝트의 규칙을 기억하고, 필요한 전문지식을 불러오고,
위험한 행동을 통제하고, 여러 작업을 분담하고,
그 구조를 팀 전체에 재사용할 수 있어야 합니다.
이를 이해하기 좋은 구조가 다음 5개 레이어입니다.
CLAUDE.md → Skills → Hooks → Subagents → Plugins
그리고 바깥에서 MCP Servers와 Agent Teams가 이 구조를 확장합니다.
① CLAUDE.md — Memory Layer “우리 프로젝트에서는 이렇게 일한다.”
CLAUDE.md는 단순한 설명 파일이라기보다 Claude Code가 프로젝트에서
따라야 할 지속적인 작업 지침과 컨텍스트를 담는 핵심 파일입니다.
예를 들어 다음 내용을 정의할 수 있습니다.
아키텍처 원칙 · 코딩 규칙 · 네이밍 규칙 · 테스트 기준 · 보안 요구사항 · 프로젝트 구조 · 금지사항
매번 프롬프트에 같은 내용을 반복해서 입력하는 대신 프로젝트 차원의 규칙을 문서화하는 것입니다.
쉽게 표현하면,
CLAUDE.md = Agent의 프로젝트 운영 헌법
이라고 이해하면 좋습니다.
② Skills — Knowledge Layer “필요할 때 전문지식을 꺼내 쓴다.”
모든 지식을 항상 컨텍스트에 넣으면 토큰도 낭비되고 중요한 정보가 묻힐 수 있습니다.
Skills는 특정 업무에 필요한 절차·지식·스크립트·템플릿·참고자료를 모듈화하여 재사용하는 방식입니다.
예를 들어 ISO Audit Agent라면
ISO 27001 심사 Skill
SoA 검토 Skill
부적합 판정 Skill
증적 분석 Skill
심사보고서 작성 Skill
처럼 전문 능력을 업무별로 나눌 수 있습니다.
핵심은 Always-On이 아니라 On-Demand입니다.
Skills = Agent에게 필요할 때 장착하는 전문지식 모듈
③ Hooks — Guardrail Layer “AI의 판단에 맡기지 말고 시스템으로 통제한다.”
프로덕션 환경에서는 이것이 특히 중요합니다.
Hooks는 특정 이벤트가 발생했을 때 정해진 검증이나 명령을 실행하여 품질·보안·정책을 코드 수준에서 강제할 수 있게 합니다.
예를 들면,
파일 수정 → 자동 Lint/Test
위험 명령 실행 → 차단
작업 완료 → 검증 수행
세션 시작 → 환경 확인
Agent 종료 → 로그·알림 처리
와 같은 구조입니다.
즉,
Event → Matcher → Validation/Command → Allow or Block
의 흐름입니다.
Hooks = “AI가 잘하겠지”를 “시스템이 반드시 확인한다”로 바꾸는 계층
이 지점에서 실험용 Agent와 운영용 Agent의 차이가 크게 벌어집니다.
④ Subagents — Delegation Layer “한 Agent가 모든 일을 하지 않는다.”
복잡한 프로젝트를 하나의 Agent에게 전부 맡기면 컨텍스트가 커지고 역할이 뒤섞이며 검증도 어려워집니다.
그래서 업무를 전문 역할로 분리합니다.
예를 들어,
Planner → 작업계획 수립
Researcher → 자료 조사
Developer → 구현
Security Reviewer → 보안 검토
Test Runner → 테스트
Auditor → 결과 검증
처럼 역할을 나눌 수 있습니다.
각 역할에 필요한 컨텍스트·도구·권한·모델을 다르게 설계하면 더욱 강력합니다.
Subagents = 한 명의 만능 AI가 아니라 전문 역할을 가진 AI 팀
⑤ Plugins — Distribution Layer “잘 만든 Agent 능력을 팀 전체가 재사용한다.”
한 프로젝트에서 잘 만든 Skills, Agents, Hooks, Commands를 다른 프로젝트에서도 반복해서 만들 필요는 없습니다.
재사용 가능한 구성요소를 패키지화하면 조직 전체가 동일한 개발 방식과 품질 기준을 사용할 수 있습니다.
개념적으로는 개발자에게 익숙한
npm package / Python package
와 비슷하게 생각할 수 있습니다.
Plugins = Agent의 능력과 운영방식을 패키징하여 배포하는 계층
MCP Servers — Agent와 외부 세계를 연결한다
Agent가 실제 업무를 수행하려면 LLM 내부의 지식만으로는 부족합니다.
MCP를 통해 다양한 외부 시스템과 연결할 수 있습니다.
GitHub · Database · API · 개발도구 · 사내 시스템 · 문서/데이터 서비스
즉,
LLM → MCP → Tool/Data → Real World
구조가 만들어집니다.
AI가 단순히 “답변하는 시스템”에서 실제로 업무를 수행하는 시스템으로 확장되는 중요한 연결 계층입니다.
Agent Teams — 여러 Agent가 협업한다
업무가 복잡해지면 단일 Agent의 순차 실행보다 역할을 나누고 병렬로 처리하는 구조가 유리할 수 있습니다.
병렬 실행 → 역할 분담 → 메시지 전달 → 결과 검증 → 통합
예를 들어 ISO/IEC 27001 심사 자동화라면,
Audit Planner → Document Reviewer → Evidence Analyst → Control Assessor → NC Reviewer → Report Writer
형태의 전문 Agent Team으로 확장할 수 있습니다.
결국 전체 구조는 이렇게 이해하면 쉽습니다
CLAUDE.md
↓
규칙을 정의한다
Skills
↓
전문지식을 제공한다
Hooks
↓
품질과 안전을 강제한다
Subagents
↓
전문가에게 일을 분담한다
Plugins
↓
완성된 능력을 팀에 배포한다
그리고
MCP = 외부 시스템 연결
Agent Teams = 다중 Agent 협업
이 전체를 둘러싸는 구조입니다.
가장 중요한 메시지
좋은 AI Agent는 좋은 프롬프트 하나로 만들어지지 않습니다.
프롬프트가 Agent에게 “무엇을 하라”고 알려준다면,
CLAUDE.md는 어떻게 일할지 규정하고,
Skills는 전문지식을 공급하며,
Hooks는 품질과 안전을 통제하고,
Subagents는 업무를 분담하며,
Plugins는 그 능력을 조직 전체로 확장합니다.
그래서 Claude Code를 제대로 활용하려면 Prompt Engineering을 넘어 Agent Architecture Engineering 관점으로 바라볼 필요가 있습니다.
페이스북 카드용 한 줄 카피
“프롬프트가 AI에게 일을 시킨다면, 아키텍처는 AI가 제대로 일하도록 만든다.”
또는 조금 더 기술적으로:
“Production AI Agent = Rules + Knowledge + Guardrails + Delegation + Distribution + Tools + Teams”
— 이춘곤(Mark) · ISC.studio · ISC출판 도서 안내
이 글은 저자의 Facebook에 처음 게시한 글입니다. Facebook 원문 보기
💬 댓글 (0)