클로드 코드 서브에이전트 완전정복 (총 9편) | 3편 서브에이전트 vs 도구 호출 vs 워크플로 — 헷갈리는 개념 완벽 정리

시리즈: 클로드 코드 서브에이전트 완전정복 (총 9편) | 3편

서브에이전트 vs 도구 호출 vs 워크플로 — 헷갈리는 개념 완벽 정리

서브에이전트, 도구 호출, 워크플로, Agent Teams, Skills, Hooks까지 비슷해 보이는 개념이 너무 많아서 헷갈리죠. 이 글 하나면 각각의 핵심 차이점이 뭔지, 실전에서 언제 뭘 써야 맞는 건지 상황별 판단 기준까지 깔끔하게 정리할 수 있어요.

Summary

• 서브에이전트는 "판단하는 작업자", 도구는 "규격화된 실행 단위", 워크플로는 "실행 순서를 정하는 제어 구조"예요
• Agent Teams는 여러 세션을 오케스트레이션하는 상위 개념이에요
• Skills/Commands/Hooks는 역할 수행이 아니라 행동 유도와 이벤트 개입에 해당해요
• 실전에서는 서브에이전트(판단) + 도구(수집/검증)의 혼합이 가장 효과적이에요

이 글의 대상

• 서브에이전트와 도구 호출의 차이가 아직 헷갈리는 분
• Claude Code의 여러 개념을 전체적으로 정리하고 싶은 분
• "이 작업엔 뭘 써야 하지?"라는 판단 기준을 세우고 싶은 개발자

목차

• 왜 이 개념들이 헷갈리는지
• 서브에이전트 vs 도구 호출 — 판단자 vs 실행 단위
• 서브에이전트 vs 워크플로 — 작업자 vs 제어 구조
• 서브에이전트 vs Agent Teams — 위임 단위 vs 오케스트레이션
• 서브에이전트 vs Skills, Commands, Hooks
• 전체 비교 — 한눈에 보는 표
• 실전 조합 — 서브에이전트 + 도구의 혼합이 최적인 이유
• 상황별 선택 가이드
• 핵심 정리
• FAQ
• 참고 자료
• 다음 편 예고

---

왜 이 개념들이 헷갈리는지

한 줄 요약: 모두 "AI가 뭔가를 자동으로 해준다"는 공통점이 있어서 겉보기에 비슷해 보여요.

솔직히, 서브에이전트, 도구 호출, 워크플로, Agent Teams... 처음 접하면 다 비슷해 보여요. "AI가 알아서 해주는 거 아냐?" 싶죠.

헷갈리는 근본 이유는 이거예요:

• 모두 자동화와 관련 있어요
• 모두 AI의 행동을 다루고 있어요
• 실제로 같이 쓰는 경우가 많아요

하지만 각각의 역할과 관점이 완전히 달라요. 비유를 들면, 요리사(서브에이전트), 칼(도구), 레시피(워크플로)가 모두 요리에 필요하지만 완전히 다른 존재인 것처럼요. 하나씩 비교해 볼게요.

---

서브에이전트 vs 도구 호출 — 판단자 vs 실행 단위

한 줄 요약: 서브에이전트는 "스스로 판단하는 역할자"이고, 도구는 "시키면 하는 규격화된 기능"이에요.

이게 가장 많이 헷갈리는 비교예요. 핵심 차이를 바로 짚어볼게요.

기준	서브에이전트	도구 (Tool/Function Call)
핵심 성격	역할 기반 판단 주체	스키마 기반 I/O 실행 단위
자율성	스스로 판단하고 여러 단계를 거침	입력 → 처리 → 출력, 한 번에 끝
컨텍스트	독립 컨텍스트에서 역할에 맞게 사고	중앙 컨텍스트에서 호출, 결과만 반환
권한	서브에이전트별 별도 권한 설정	중앙에서 일괄 통제
메모리	자체 메모리 접근 가능	없음 (상태 비저장)
유연성	상황에 따라 다르게 판단	항상 동일한 규격으로 동작
병렬 처리	여러 서브에이전트 동시 실행 가능	도구 자체가 병렬/재시도 가능

쉽게 말하면:

• 도구: "이 파일 읽어와", "이 API 호출해" → 시키는 대로 하고 결과를 돌려줘요
• 서브에이전트: "이 코드에 보안 문제 있는지 검토해봐" → 뭘 봐야 할지 스스로 판단하고, 여러 파일을 읽고, 분석하고, 의견을 내놓아요

도구는 손이고, 서브에이전트는 전문가인 거예요.

---

서브에이전트 vs 워크플로 — 작업자 vs 제어 구조

한 줄 요약: 서브에이전트는 "일하는 사람"이고, 워크플로는 "일의 순서와 규칙을 정하는 설계도"예요.

이것도 많이 헷갈려요. 특히 "서브에이전트가 순서대로 실행되면 그게 워크플로 아냐?"라는 의문이 생기거든요.

기준	서브에이전트	워크플로
역할	작업자 (판단 주체)	제어 구조 (실행 순서/의존성/재시도/승인)
비유	요리사	레시피
관심사	"무엇을 어떻게 판단할까"	"누가 언제 무엇을 할까"
변경 시	역할 정의나 프롬프트 수정	단계 순서나 조건 수정
예시	코드 리뷰어, 문서 작성자	Research → Write → Verify → Approve

워크플로는 서브에이전트를 어떤 순서로, 어떤 조건에서 실행할지 정하는 거예요.

예를 들어볼게요:

워크플로: 코드 품질 검사
├── 1단계: 린트 검사 서브에이전트 실행
├── 2단계: 보안 검사 서브에이전트 실행
├── 3단계: 1, 2단계 통과 시 → 테스트 서브에이전트 실행
├── 4단계: 실패 시 → 재시도 또는 사람에게 에스컬레이션
└── 5단계: 전부 통과 → 승인 서브에이전트 실행

여기서 각 서브에이전트는 "작업자"이고, 전체 흐름(순서, 조건, 재시도, 에스컬레이션)이 "워크플로"예요. 둘은 같이 쓰는 거지, 같은 게 아니에요.

---

서브에이전트 vs Agent Teams — 위임 단위 vs 오케스트레이션

한 줄 요약: 서브에이전트는 같은 세션 안에서의 위임이고, Agent Teams는 여러 세션에 걸친 오케스트레이션이에요.

2편에서 서브에이전트가 메인에 의해 호출되는 구조라고 했죠. Agent Teams는 그보다 한 단계 위의 개념이에요.

기준	서브에이전트	Agent Teams
범위	같은 세션 내 위임	여러 세션에 걸친 분업
호출 방식	Task 도구로 즉시 호출	세션 간 오케스트레이션
컨텍스트	독립 컨텍스트 (1단계)	각 에이전트가 완전히 별도 세션
적합한 상황	하나의 작업 흐름 안에서 역할 분리	대규모 프로젝트에서 병렬 분업
복잡도	상대적으로 단순	상대적으로 복잡

비유하자면:

• 서브에이전트: 한 사무실에서 옆 동료한테 "이것 좀 봐줘" 하는 거예요
• Agent Teams: 다른 부서, 다른 팀과 협업하면서 각자 맡은 파트를 진행하는 거예요

Agent Teams는 서브에이전트를 포함할 수 있는 더 넓은 개념이에요. 서브에이전트를 먼저 이해해야 Agent Teams를 제대로 활용할 수 있죠.

---

서브에이전트 vs Skills, Commands, Hooks

한 줄 요약: 서브에이전트는 독립 컨텍스트에서 역할을 수행하고, Skills/Commands/Hooks는 행동을 유도하거나 이벤트에 개입하는 장치예요.

이 세 가지도 비교해 둘 필요가 있어요.

기준	서브에이전트	Skills/Commands	Hooks
핵심 역할	독립 컨텍스트에서 역할 수행	정해진 행동 패턴을 유도	이벤트 발생 시 자동 개입
자율성	높음 (스스로 판단)	중간 (템플릿화된 행동)	낮음 (규칙 기반 반응)
트리거	메인 에이전트가 Task로 호출	사용자가 명시적으로 호출	시스템 이벤트에 자동 반응
컨텍스트	독립 (격리됨)	현재 세션 공유	세션 외부에서 실행
비유	전문가를 불러서 일 맡기기	매크로 실행하기	센서가 감지하면 알람 울리기

이 개념들은 경쟁 관계가 아니라 보완 관계예요. 예를 들면:

• Hooks가 코드 변경을 감지하면
• 서브에이전트가 리뷰를 수행하고
• 그 결과를 Skills의 정해진 포맷으로 출력하는 식이죠

---

전체 비교 — 한눈에 보는 표

한 줄 요약: 6개 개념을 핵심 질문 기준으로 한 번에 비교해요.

개념	"뭘 하는 거야?"	"누가 판단해?"	"독립 컨텍스트?"
서브에이전트	역할 기반 전문 작업 수행	서브에이전트 스스로	O (격리)
도구 호출	규격화된 단일 기능 실행	메인 에이전트가 결정	X (중앙 통제)
워크플로	실행 순서/조건/의존성 관리	설계자가 사전 정의	해당 없음 (구조임)
Agent Teams	여러 세션 간 병렬 분업	각 에이전트 독자 판단	O (세션 단위)
Skills/Commands	템플릿화된 행동 패턴 실행	패턴에 따라	X (세션 공유)
Hooks	이벤트 기반 자동 반응	규칙에 따라	X (외부 실행)

---

실전 조합 — 서브에이전트 + 도구의 혼합이 최적인 이유

한 줄 요약: 서브에이전트가 판단하고 합성하고, 도구가 근거를 수집하고 정형 검증하는 혼합 구조가 가장 효과적이에요.

실전에서는 이것들을 따로 쓰는 게 아니라 섞어서 써요. 특히 서브에이전트 + 도구 조합이 강력해요.

왜냐면:

• 서브에이전트가 잘하는 것: 판단, 합성, 검증, 맥락 기반 의사결정
• 도구가 잘하는 것: 데이터 수집, 정형화된 검사, API 호출, 파일 조작

이걸 조합하면:

서브에이전트: 보안 리뷰어
├── [도구 호출] 코드 파일 읽기 (Read)
├── [도구 호출] 의존성 목록 가져오기 (Bash)
├── [도구 호출] 알려진 취약점 DB 조회 (MCP)
├── [서브에이전트 판단] 수집된 정보 종합 분석
├── [서브에이전트 판단] 위험도 평가
└── [결과 반환] 보안 리뷰 보고서

서브에이전트가 "뭘 볼지, 어떻게 판단할지"를 결정하고, 실제 데이터 수집은 도구를 시켜서 하는 거예요. 전문가가 도구를 활용해서 일하는 것과 똑같죠.

---

상황별 선택 가이드

한 줄 요약: "이 작업엔 뭘 써야 할까?"에 대한 실전 판단 기준이에요.

상황	추천	이유
API를 호출해서 데이터를 가져와야 할 때	도구	규격화된 I/O, 재시도 가능
코드 품질을 종합적으로 판단해야 할 때	서브에이전트	맥락 기반 판단 필요
여러 단계를 순서대로 실행해야 할 때	워크플로 + 서브에이전트	순서 제어 + 각 단계 판단
대규모 코드베이스를 팀으로 나눠 작업할 때	Agent Teams	병렬 세션 분업
파일 저장 시 자동으로 포맷팅하고 싶을 때	Hooks	이벤트 기반 자동 반응
자주 쓰는 작업 패턴을 재사용하고 싶을 때	Skills/Commands	템플릿화된 행동
수집한 데이터를 분석해서 보고서를 만들 때	서브에이전트 + 도구	도구로 수집, 에이전트가 합성

---

핵심 정리

1. 서브에이전트 = 판단하는 전문가 (역할 기반, 독립 컨텍스트)
2. 도구 = 시키면 하는 기능 (스키마 기반 I/O, 중앙 통제)
3. 워크플로 = 순서와 조건을 정하는 설계도 (제어 구조)
4. Agent Teams = 여러 세션에 걸친 오케스트레이션 (상위 개념)
5. 최적의 조합: 서브에이전트(판단·합성) + 도구(수집·검증)의 혼합

---

FAQ

Q. 서브에이전트 대신 그냥 도구를 많이 만들면 안 되나요?

A. 정형화된 작업이라면 도구가 더 나아요. 하지만 "상황에 따라 다르게 판단해야 하는" 작업은 도구로 커버하기 어려워요. 도구는 입력이 같으면 항상 같은 결과를 내지만, 서브에이전트는 맥락을 고려해서 다른 판단을 내릴 수 있거든요.

Q. 워크플로 없이 서브에이전트만 써도 되나요?

A. 단순한 위임(하나의 작업을 맡기는 것)이면 워크플로 없이도 괜찮아요. 하지만 여러 서브에이전트가 순서를 지켜야 하거나, 조건 분기가 있거나, 실패 시 재시도가 필요하면 워크플로가 있는 게 훨씬 안정적이에요.

Q. Agent Teams와 서브에이전트를 동시에 쓸 수 있어요?

A. 네, Agent Teams 안에서 각 에이전트가 자기 서브에이전트를 가질 수 있어요. Agent Teams가 큰 그림의 분업이고, 각 에이전트 안에서 서브에이전트가 세부 역할을 나누는 구조예요.

Q. Hooks와 서브에이전트가 충돌하는 경우는 없나요?

A. Hooks는 시스템 이벤트에 반응하는 거고, 서브에이전트는 메인의 의도적 위임이라 역할이 달라서 충돌할 일은 거의 없어요. 오히려 Hooks가 트리거 → 서브에이전트가 실행되는 보완적 패턴이 일반적이에요.

Q. Skills와 서브에이전트의 경계가 모호해요. 어떻게 구분하죠?

A. 핵심 차이는 컨텍스트 격리 여부예요. Skills는 현재 세션의 컨텍스트를 공유하면서 정해진 패턴대로 동작해요. 서브에이전트는 독립된 컨텍스트에서 자기만의 시스템 프롬프트로 판단해요. "정해진 대로 하면 되는 일"은 Skills, "판단이 필요한 일"은 서브에이전트가 맞아요.

Q. 이 개념들을 다 알아야 서브에이전트를 쓸 수 있나요?

A. 아니에요. 서브에이전트와 도구의 차이만 이해해도 실전에서 쓰기엔 충분해요. 나머지는 필요할 때 하나씩 추가로 익히면 돼요. 이 글은 전체 그림을 보여주기 위한 거지, 다 외워야 한다는 뜻은 아니에요.

Q. 결국 뭘 먼저 배워야 해요?

A. 이 순서를 추천해요: (1) 도구 호출 이해 → (2) 서브에이전트 이해 → (3) 둘의 조합 연습 → (4) 워크플로 설계 → (5) Agent Teams. 이 시리즈가 딱 이 순서로 진행되고 있으니 따라오시면 돼요.

---

참고 자료 (References)

데이터 출처

출처	설명	링크
Claude Code 서브에이전트 문서	서브에이전트 개념과 사용법 공식 가이드	공식 문서
Tool Use Overview	Claude API 도구 호출(Tool Use) 공식 가이드	공식 문서
Claude Code Agent Teams	Agent Teams 오케스트레이션 공식 가이드	공식 문서
Claude Code Hooks	Hooks 기반 이벤트 자동화 가이드	공식 문서
Anthropic 자율 에이전트 블로그	Claude Code 자율 에이전트 운영 관련 블로그	블로그 포스트

핵심 인용

"The best pattern is a hybrid: sub-agents for judgment, synthesis, and verification; tools for evidence gathering and structured validation."
— 서브에이전트 + 도구 조합 원칙 요약

---

다음 편 예고

[4편] 서브에이전트 설계 원리 — 좋은 프롬프트보다 좋은 경계가 중요한 이유

• 서브에이전트 설계에서 프롬프트보다 경계가 더 중요한 이유를 알아봐요
• 역할, 권한, 도구의 경계를 나누는 실전 원칙을 세워봐요
• 좋은 설계와 나쁜 설계의 차이를 구체적 예시로 비교해 봐요