전체 요약
Agent가 Context를 바탕으로 Plan을 세우고, Tool/MCP를 사용해 실행하고, Hook과 Skill로 품질을 제어하고, 인간이 감독한다.
Agent & Sub-Agent : 계층적으로 위임하고 병렬로 실행한다.
Context Engineering : 에이전트에게 줄 정보를 전략적으로 설계한다.
Tool & MCP : 표준화된 도구 에이전트의 행동 반경을 넓힌다.
Hook & Skill : 자동 안전장치와 전문 지식으로 품질을 제어한다.
Planning & HITL : 계획-실행-검증 루프를 돌리되, 인간이 감독함
Agent & Sub-Agent
목표를 해석하고 계획을 세우고 도구를 사용해서 자율적으로 실행하는 주체
챗봇과의 차이는 목표 해석 -> 계획 -> 실행 -> 평가 루프
에이전트는 스스로 오류를 감지하고 수정함
하나의 컨텍스트 윈도우 안에서 복잡한 작업 (백, 프, 문서 작성 ...)을 하면 컨텍스트가 길어질수록 효율이 떨어짐
그래서 등장한 것이 Multi-Agent 오케스트레이션
Orchestrator Agent
ㄴSub-Agent (프론트엔드)
ㄴSub-Agent (백엔드)
ㄴSub-Agent (DB 설계)
ㄴSub-Agent (테스트)
ㄴSub-Agent (문서 작성)
Orchestrator Agent가 작업을 분해해서 각 Sub-Agent에게 위임함
과정 : Fan-out(작업 분배) -> 병렬 실행 -> Fan-in(결과 통합)
Context Engineering
프롬포트 엔지니어링은 어떻게 물어볼까에 집중하고 질문을 잘 쓰면 답이 잘 나온다. 또한 단일 상호작용에 최적화 되어 있다.
반대로 컨텍스트 엔지니어링은 어떤 정볼를 제공할까에 집중하고 무엇을, 언제, 어떤 형태로 넣을지 체계적으로 설계함. 또한 전체 시스템 최적화에 특화되어있음
컨텍스트 3가지 레이어
System Context
: 에이전트가 항상 참조하는 기본 설정
ex. Claude.md, 프롬프트 규칙, 아키텍처 문서
Conversation Context
: 대화 과정에서 누락되는 정보
ex. 이전 대화, 실행 결과, 사용자 피드백
Tool & Environment Context
: 도구 실행으로 얻는 실시간 정보
ex. 파일 내용, API응답, 테스트 결과, MCP 데이터
왜 컨텍스트 설계가 중요할까?
3중 압박을 받고 있시 때문임
1. 비용과 지연 폭발
컨텍스트가 커질수록 비용과 응답시간이 급증함
2. 신호 약화
관련 없는 정보가 넘치면 모델이 핵심을 놓침
(컨텍스트 중간 정보 회상률 급락)
3. 캐시 효율성
같은 정보를 반복 전달하면 두 번째부터는 10분의 1비용
(바뀌지 않는 정보를 앞에 고정한다면 캐시 효율이 극대화됨)
클로드 코드에선 CLAUDE.md에 가장 잘 나타낼 수 있음
프로젝트, 스타일, 테스트, DB, 규칙 을 잘 써두어야함
1. 매번 프로젝트 설명 반복이 불필요
2. 에이전트가 프로젝트 맥락 파악한 상태로 시작할 수 있음
3. 일관된 코딩 스타일을 유지함
Tool, Plugin & MCP
Tool
: 개별 함수(파일 읽기, 터미널 실행, 웹 검색)
Plugin
: Tool 묶음 (Github 플러그인(PR 조회 + 생성 + 리뷰))
MCP
: 표준 프로토콜 (모든 Tool/Plugin을 표준화한 인터페이스 연결)
해당 Tool들을 가지고 있어야지 Agent가 적절한 업무를 실행할 수 있음.
툴 설계 4 원칙
최소 권한 원칙
: 필요한 Tool만 노출 (너무 많으면 혼란)
검증 가능성
: Tool 호출 결과를 인간이 쉽게 확인 (투명해야 신뢰할 수 있음)
에러 핸들링 내장
: 실패 시 대안 경로 선택 가능 (ex. GitHub API 무응답 -> 로컬 캐시 사용)
보안 경계 설정
: 읽기 전용 vs 쓰기 가능 Tool을 명확 구분 (DB보호를 위해서 ,,)
Hook & Skill
-> 행동을 제한하는 것.
Hook
: 에이전트의 워크플로우의 특정 지점에서 자동으로 실행되는 인터셉터
-> 이런일이 일어나면 자동으로 어떤일을 해라
Pre-action : 에이전트가 행동하기 전 해라
Post-action : 에이전트가 행동한 후 해라
Validation : 에이전트 출력의 품질 검증
Notification : 특정 조건 충족 시 인간에게 알림
ex. 파일 변경 시 관련 테스트 자동으로 실행해라
Skill
: 에이전트가 특정 작업을 수행할 때 참조하는 문서. Skill.md
ex. 프레젠테이션 만들어줘 -> Skill.md에 가이드라인을 적어주면 이거에 맞춰서 만들어줌. 없다면 일반적인 결과물이 나오겠지
- 현재는
정적Skill임. 인간이 수동으로 작성한 고정 가이드라인만 가지고 함 - 지금 개발중인 내용은
동적Skill, 즉, 에이전트가 경험을 통해 스스로 진화시키는 가이드라인임. - 마지막으로 미래의
공유Skill은 팀/조직 단위로 공유되는 표준화된 Skill 라이브러리
Hook + Skill
ex. 훅이 보안 코드 변경을 감지하면 스킬은 보안 리뷰 체크리스트 자동 적용함
비유하자면
- Hook은 맞춤법 자동 검사 (글을 쓰는 순간 자동으로 오류 감지. 빨간 밑줄로 즉시 피드백)
- Skill은 글쓰기 스타일 (특정 상황에선 어떻게 써라, 베스트 프랙티스 참조)
Planning & HITL
: 계획 실행 검증 루트 (단순한 챗봇과 구분짓는 가장 큰 특징임)
단계
- 목표 분해
- 계획 수립
- 도구로 실행
- 결과 평가
- 재계획 (1로 다시 반복)
위임의 스펙트럼
LEVEL 1. 완전 자율
사람은 결과만 확인하고, 계획~실행 전부 에이전트가 함
리팩터링에 가장 적합함
LEVEL 2. 감독 위임
사람은 계획 승인 후 위임. 에이전트는 계획 + 실행을 함
새 기능을 만들거나, 버그를 수정할 때 사용
Claude Code의 Plan모드가 예시같음
LEVEL 3. 협업
사람은 핵심 결정 개입을 하고, 에이전트는 실행과 보조 역할을 함
아키텍쳐나 보안코드와 같이 큰 주제나 민감한 내용에 대해 적합
LEVEL 4. 인간 주도
인간이 직접 설계하고 지시함. 에이전트는 구현을 보조함
성능 크리티컬이나 신규 패턴에 적합
아직 학습이 적은 신규 패턴이나 성능 크리티컬이 높은 부분은 인간의 주도 하에 코딩을 진행해야함
내가 결과를 빠르게 확인 가능하다면 위임의 권한을 주는 것
- 리팩터링
- 테스트 작성
- 버그 재현
내가 결과를 빠르게 검증할 수 없다면 직접 해야함
- 아키텍처 결정
- 보안 민감 코드
- 성능 크리티컬
