Claude Code Hooks vs Agent 2026, 자동 규칙과 전문 작업자를 언제 나눠 써야 할까

Claude Code를 굴리다 보면 결국 이 질문으로 돌아온다.

이건 hooks로 막아야 하나, 아니면 subagent 같은 전문 작업자로 빼야 하나?

겉으로는 둘 다 자동화처럼 보이지만, 실제 역할은 꽤 다르다. hooks는 자동 반사 신경에 가깝고, subagents는 작업을 맡는 전문 작업자에 가깝다.

2026년 4월 4일 기준 Anthropic 공식 문서를 다시 읽어보면 이 경계가 더 분명해진다. Claude Code는 agentic coding tool이고, hooks는 라이프사이클 이벤트에 붙는 자동 동작이다. subagents는 별도 프롬프트와 컨텍스트를 가진 특화 작업자다. 같은 자동화라는 말로 묶으면 오히려 운영이 꼬인다.

먼저 한 줄로 말하면,
hooks는 규칙을 자동으로 지키게 하는 장치고, subagents는 일감을 분리해서 맡기는 장치다.
막아야 할 일, 기록해야 할 일, 알림만 줘도 되는 일은 hooks가 낫고, 조사, 리뷰, 분리된 맥락이 필요한 일은 subagent가 낫다.

지금 결론

상황	더 맞는 것	이유
위험한 명령을 막고 싶다	hooks	이벤트 순간에 정책을 걸기 좋다
포맷터, 테스트, 로그를 자동으로 돌리고 싶다	hooks	반응형 규칙이 잘 맞는다
긴 조사나 복잡한 문맥 분리가 필요하다	subagent	별도 컨텍스트가 유리하다
리뷰어, 탐색원, 발행 담당을 나누고 싶다	subagent	역할을 분리하기 좋다
승인/차단 기준을 팀 규칙으로 남기고 싶다	hooks + settings	규칙과 실행을 같이 관리할 수 있다

한 줄로 줄이면 이거다.

hooks는 통제, subagent는 위임이다.

왜 이 구분이 중요하나

Claude Code 공식 문서에서 hooks는 특정 라이프사이클 이벤트에 붙는 자동화다. Subagents 문서는 별도 프롬프트, 별도 컨텍스트, 별도 도구 범위를 가진 작업자를 설명한다.

이 둘을 헷갈리면 다음 실수가 바로 나온다.

정책을 subagent가 대신 지키게 하려다 놓침
조사용 subagent가 너무 넓은 권한을 가져감
hooks가 너무 무거워져서 자동화가 아니라 자동 지연이 됨
같은 문제를 rules와 prompt와 hook에 중복으로 넣음

운영 관점에서 보면 hooks는 작동 조건, subagents는 작업 구조다.

역할 구분표

항목	hooks	subagent
본질	이벤트 반응 규칙	특화 작업자
강점	빠른 검사, 알림, 차단, 후처리	문맥 분리, 역할 분리, 조사 집중
약점	너무 무거우면 느려짐	너무 많이 쪼개면 지휘 비용 증가
적합한 일	포맷, lint, 로그, 승인 체크	리서치, 리뷰, 비교, 분할 작업
권한 감각	좁게	역할별로 나눔
실패 모드	자동 지연	과도한 분업

hooks가 잘하는 일

hooks는 Claude Code 라이프사이클에 붙는다. 공식 문서에는 command, http, prompt, agent 형태의 hook handler가 있고, SessionStart, SessionEnd, PostToolUse, PermissionRequest, Notification 같은 이벤트 축을 다룬다.

실전에서 좋은 일은 대체로 이렇다.

파일 수정 뒤 가벼운 테스트
세션 시작 시 상태 요약
승인 요청 시 정책 체크
세션 종료 시 로그 남기기
알림만 보내고 본작업은 계속 진행하기

hooks의 장점은 빠르다는 점이다. 대신 빠른 만큼 짧고 결정적이어야 한다.

subagent가 잘하는 일

subagent는 혼자서 생각할 수 있는 작은 작업자다. 공식 문서상 커스텀 subagents는 사용자/프로젝트 레벨에 둘 수 있고, Markdown 파일과 YAML frontmatter로 정의된다.

이 구조가 강한 이유는 명확하다.

메인 세션 문맥을 덜 오염시킨다
역할별로 책임을 나누기 쉽다
긴 조사나 리뷰를 끝까지 밀기 좋다
같은 작업을 여러 번 반복할 때 루틴화가 쉽다

즉 누가 이 일을 맡을까가 중요하면 subagent가 맞고, 어떤 순간에 막거나 처리할까가 중요하면 hooks가 맞다.

언제 무엇을 쓰나

hooks를 먼저 쓰는 경우

위험 명령을 막아야 할 때
파일 수정 후 반드시 해야 하는 후처리가 있을 때
세션 시작/종료에 공통 규칙을 붙이고 싶을 때
알림이나 경고처럼 짧은 반응이 필요할 때

subagent를 먼저 쓰는 경우

메인 세션이 너무 많은 일을 떠안고 있을 때
리서치와 실행을 분리하고 싶을 때
리뷰/탐색/발행 같은 역할 분담이 필요할 때
같은 타입의 작업을 반복적으로 맡길 때

둘을 같이 쓰는 경우

hooks로 안전선을 두고
subagent로 실제 작업을 분리하는 조합

이 조합이 제일 안정적이다. 쉽게 말하면 hooks가 울타리고 subagent가 일꾼이다.

실패 패턴

1. hooks로 복잡한 판단을 다 하려는 경우

정책이 길어질수록 훅은 무거워진다. 질문이 길어지면 hook이 아니라 작은 애플리케이션이 된다.

2. subagent로 정책 enforcement까지 맡기는 경우

전문 작업자는 판단을 잘할 수 있어도, 실행 순간의 강제력은 hooks보다 약하다. 막아야 할 일은 hooks 쪽이 더 낫다.

3. 둘 다 같은 규칙을 중복으로 넣는 경우

같은 금지선이 settings, prompt, hook, subagent에 중복되면 팀이 규칙보다 예외를 먼저 기억한다.

4. subagent를 너무 잘게 쪼개는 경우

분업은 좋아도, 너무 쪼개면 조율 비용이 더 커진다. 조사원 셋이 있으면 빨라질 것 같지만, 실제론 중간 보고만 늘어날 수 있다.

실전 예시

예시 1. 문서 작업

hooks: 저장 후 린트, 파일명 규칙 검사, 로그 남기기
subagent: 관련 노트 10개 모아서 비교표 초안 만들기

예시 2. 코드 작업

hooks: 테스트 통과 여부 확인, 위험 명령 차단
subagent: 버그 원인 탐색, 리팩토링 후보 조사

예시 3. 팀 운영

hooks: 비밀정보 접근 경고, 배포 전 체크리스트
subagent: 리뷰 전용, 발행 전용, 조사 전용 작업자 분리

내가 쓰는 기준

나는 이렇게 나눈다.

규칙이면 hooks
일감이면 subagent
둘 다 아니면 아직 안 넣는다

이 기준이 단순하지만, 실전에서는 꽤 강하다. 자동화 욕심이 커질수록 오히려 단순한 경계가 필요하다.

실수 TOP 5

1. hooks를 만능 자동화로 보는 실수

hooks는 자동 반응일 뿐이다. 전부를 해결하지 못한다.

2. subagent를 만능 직원으로 보는 실수

전문 작업자도 권한과 범위가 필요하다.

3. 위험 차단을 subagent에 맡기는 실수

차단은 hooks 쪽이 더 맞는다.

4. 가벼운 후처리를 subagent로 보내는 실수

짧은 후처리는 hooks가 더 효율적이다.

5. 둘 사이 경계선을 문서화하지 않는 실수

이게 제일 흔하다. 규칙이 아니라 기억에 맡기면 금방 흐려진다.

FAQ

Q1. hooks와 subagent 중 하나만 먼저 쓴다면?

대부분은 hooks부터다. 바로 체감되고, 안전선 만들기 좋다.

Q2. subagent는 언제부터 가치가 커지나?

작업이 길어지고, 문맥 분리가 중요해질 때다.

Q3. hooks가 너무 많아지면 어떻게 하나?

차단, 알림, 후처리 세 범주로 줄여라. 전부 붙이면 피곤해진다.

Q4. 둘을 같이 쓰는 가장 좋은 방식은?

hooks로 안전선을 세우고, subagent로 실제 작업을 나누는 방식이다.

공식 출처

한 줄 정리

hooks는 언제 막고 언제 자동 반응할지를 정하는 장치고, subagent는 누가 이 일을 맡을지를 정하는 장치다. 둘을 섞어 쓰되, hooks는 좁게, subagent는 역할별로 쓰는 쪽이 제일 덜 꼬인다.

Claude Code Hooks vs Agent 2026 — 자동 규칙과 전문 작업자를 언제 나눠 써야 할까