Custom Agent, Skill, MCP, Hook 차이: AI 코딩 도구 설정을 고르는 기준

AI 코딩 도구를 설정하다 보면 비슷한 이름이 한꺼번에 나옵니다. Custom Agent를 만들 수도 있고, Skill을 추가할 수도 있고, MCP 서버와 Hook을 연결할 수도 있습니다. 모두 에이전트의 능력을 바꾸는 기능처럼 보여서 같은 작업을 어디에 넣어야 할지 애매합니다.

Codex, Claude Code, GitHub Copilot은 비슷한 용어를 사용하지만 파일 위치와 실행 방식까지 같지는 않습니다. 특히 Custom Agent라는 역할 설정과 Subagent라는 실행 방식을 같은 뜻으로 보면 선택 기준이 흐려집니다.

구분은 기능 이름보다 네 가지 질문으로 할 수 있습니다.

어떤 역할, 모델과 도구 범위를 재사용할 것인가? → Custom Agent
어떤 절차를 반복해서 따라야 하는가? → Skill
기본 도구에 없는 어떤 데이터나 행동이 필요한가? → MCP
어느 이벤트에서 자동으로 검사할 것인가? → Hook

짧게 말하면 Custom Agent는 역할 설정, Skill은 작업법, MCP는 도구 연결, Hook은 실행 시점입니다. 별도 컨텍스트에 작업을 위임하고 싶을 때는 Custom Agent를 Subagent로 실행할 수 있습니다. 네 요소는 경쟁 관계가 아니며, 하나의 Agent가 Skill을 따라 MCP 도구를 사용하고 Hook이 그 과정의 앞뒤를 검사할 수 있습니다.

네 요소는 서로 다른 축을 바꾼다

요소	바꾸는 것	잘 맞는 문제	대표적인 결과물
Custom Agent	역할, 모델과 도구 범위	보안 리뷰, 문서 전담, 테스트 전담	역할별 Agent 정의
Skill	반복 절차와 전문 지식	릴리스, 코드 리뷰, 장애 분석, 글쓰기	`SKILL.md`, 참고 자료, 스크립트
MCP	기본 도구 밖의 데이터와 행동	GitHub, Figma, Sentry, 로컬 브라우저	MCP 서버 설정과 도구 목록
Hook	이벤트 전후의 자동 실행	비밀값 검사, 명령 차단, 린트, 감사 로그	이벤트와 명령을 연결한 설정

이 표에서 가장 중요한 차이는 무엇을 바꾸느냐입니다. Custom Agent는 역할과 도구 범위를 바꾸고, Skill은 현재 Agent가 따를 절차를 더합니다. MCP는 사용할 수 있는 데이터와 행동을 늘립니다. Hook은 모델이 기억해서 선택하기를 기다리지 않고 특정 이벤트에 맞춰 코드를 실행합니다.

Custom Agent는 재사용할 역할 설정이다

Custom Agent는 역할, 시스템 프롬프트, 모델과 도구 범위를 묶은 설정입니다. “코드 리뷰를 잘해라”라는 긴 프롬프트를 매번 붙이는 대신 읽기 전용 리뷰어처럼 반복해서 선택할 역할을 정의합니다.

Custom Agent가 항상 별도 컨텍스트에서 실행되는 것은 아닙니다. 메인 Agent로 직접 선택할 수도 있고, 다른 Agent가 작업을 위임하는 Subagent로 실행할 수도 있습니다. Custom Agent는 역할 정의이고, Subagent는 위임받은 작업을 격리된 컨텍스트에서 수행하는 실행 방식입니다.

GitHub Copilot의 Custom Agent는 이름, 설명, 프롬프트와 사용할 도구를 정의할 수 있고 Agent별 MCP 서버도 연결할 수 있습니다. Claude Code의 Subagent는 별도 시스템 프롬프트, 도구, 모델, 권한 모드와 Skill을 가질 수 있습니다. 제품마다 이름은 다르지만 역할 설정과 위임 실행을 구분해야 한다는 점은 같습니다.

다음은 읽기 전용 리뷰 역할을 표현한 최소 예시입니다. 이 형식은 GitHub Copilot agent profile을 기준으로 하며 다른 제품에 그대로 복사하는 설정은 아닙니다.

---
name: regression-reviewer
description: 변경된 코드에서 동작 회귀와 누락된 테스트를 찾습니다.
tools: [read, search]
---

변경 의도와 실제 제어 흐름을 비교합니다.
재현 가능한 문제만 검토 결과로 남기고 코드 파일은 수정하지 않습니다.

Custom Agent가 잘 맞는 신호는 다음과 같습니다.

같은 역할과 완료 기준을 여러 작업에서 반복합니다.
사용할 모델, 도구나 권한을 역할별로 제한해야 합니다.
조사량이 많아 메인 컨텍스트와 분리해야 한다면 Subagent로 위임합니다.

반대로 릴리스 순서나 리뷰 체크리스트만 재사용하고 싶다면 Agent까지 만들 필요가 없습니다. 역할은 그대로인데 작업법만 반복된다면 Skill이 더 작고 직접적인 단위입니다.

Skill은 반복해서 불러오는 작업법이다

Skill은 특정 작업을 수행하는 방법을 묶습니다. 지침만 담을 수도 있고, 참고 자료와 검증 스크립트를 함께 둘 수도 있습니다.

예를 들어 “PR을 리뷰해줘”라는 요청마다 다음 조건을 다시 설명한다고 가정해 보겠습니다.

요구사항과 diff가 맞는지 먼저 확인합니다.
실제 버그와 취향 차이를 구분합니다.
검토 결과마다 재현 경로를 적습니다.
마지막에 테스트 누락과 남은 위험을 요약합니다.

이 절차는 새로운 작업자가 필요한 것이 아니라 같은 리뷰 방법을 반복해야 하는 문제입니다. Skill로 만들면 메인 Agent도 사용할 수 있고, 리뷰 전담 Agent에 미리 넣을 수도 있습니다.

Codex의 Skill은 SKILL.md를 중심으로 선택적인 scripts/, references/, 에셋을 가질 수 있습니다. 처음에는 이름과 설명만 보여주고, 선택되었을 때 전체 지침과 필요한 참고 자료를 읽는 점진적 공개 방식입니다.

---
name: regression-review
description: 코드 변경에서 동작 회귀와 누락된 검증을 찾을 때 사용합니다.
---

1. 요청한 동작과 diff를 비교합니다.
2. 변경된 제어 흐름과 상태 전이를 추적합니다.
3. 재현 가능한 문제만 심각도와 함께 기록합니다.
4. 관련 테스트를 실행하고 남은 위험을 요약합니다.

Skill이 잘 맞는 신호는 다음과 같습니다.

같은 설명을 여러 대화나 저장소에서 반복합니다.
입력은 달라지지만 처리 순서와 완료 조건은 비슷합니다.
Agent를 바꾸더라도 같은 예시, 체크리스트와 작업법을 재사용해야 합니다.

Skill은 실행 권한을 새로 만들지 않습니다. “Sentry에서 오류를 찾아라”라는 절차를 Skill에 적어도 Sentry 데이터에 접근할 도구가 생기는 것은 아닙니다. 외부 능력이 필요하면 MCP 같은 연결을 따로 제공해야 합니다.

MCP는 기본 도구 밖의 능력을 연결한다

MCP는 Model Context Protocol의 약자입니다. 에이전트가 기본적으로 갖지 않은 데이터와 행동을 사용할 수 있도록 도구, 리소스와 프롬프트를 노출합니다. 원격 SaaS뿐 아니라 로컬 브라우저, 데이터베이스나 개발 도구도 MCP로 연결할 수 있습니다.

다음 요구는 Skill만으로 해결할 수 없습니다.

GitHub의 열린 이슈와 PR 댓글을 조회합니다.
Figma 프레임을 읽고 화면과 비교합니다.
Sentry의 실제 오류 이벤트를 확인합니다.
사내 문서 검색 시스템에서 최신 정책을 가져옵니다.
브라우저를 열어 로컬 화면을 조작합니다.

이 작업에는 외부 시스템과 통신하는 구현, 인증, 도구 스키마가 필요합니다. MCP 서버가 그 연결을 맡고, Skill은 어떤 순서로 도구를 사용할지 설명할 수 있습니다.

Codex에서는 로컬 프로세스로 실행하는 STDIO 서버와 URL로 연결하는 Streamable HTTP 서버를 설정할 수 있습니다. 다음은 구조를 보여주는 최소 예시입니다.

[mcp_servers.issue_tracker]
url = "https://mcp.example.com/mcp"
bearer_token_env_var = "ISSUE_TRACKER_TOKEN"
enabled_tools = ["search_issues", "get_issue"]
default_tools_approval_mode = "writes"

여기서 중요한 것은 연결 여부보다 노출 범위입니다. 조회만 필요한 Agent에게 이슈 수정과 삭제 도구까지 모두 줄 필요는 없습니다. 서버 단위로 enabled_tools를 제한하고, 쓰기 도구는 별도 승인을 받게 만들 수 있습니다.

MCP가 잘 맞는 신호는 다음과 같습니다.

필요한 데이터나 행동이 Agent의 기본 도구에 없습니다.
OAuth, 토큰 또는 별도 서버 연결이 필요합니다.
여러 Agent나 Skill이 같은 외부 기능을 공유해야 합니다.

MCP 서버의 설명에 긴 업무 절차를 모두 넣는 것은 피하는 편이 좋습니다. 서버 전체에 적용되는 제약과 도구 사용 조건은 MCP 지침에 둘 수 있지만, “장애를 분류하고 보고서를 작성하는 순서”처럼 하나의 작업에만 필요한 절차는 Skill로 분리해야 재사용과 수정이 쉽습니다.

Hook은 코드를 실행할 시점을 정한다

Skill과 Hook은 둘 다 작업 절차를 자동화하지만 실행 조건이 다릅니다. Skill은 Agent가 선택해 따르는 작업법입니다. Codex Hook은 세션 시작, 프롬프트 제출, 도구 호출 전후, 작업 종료처럼 정해진 이벤트가 발생할 때 실행되는 확장 지점입니다.

다음 요구는 Hook에 가깝습니다.

셸 명령을 실행하기 전에 금지 패턴을 검사합니다.
사용자가 보낸 프롬프트에 비밀값이 포함됐는지 확인합니다.
파일 수정 뒤 린트 결과를 Agent에게 돌려줍니다.
작업이 끝났을 때 검증 명령을 실행합니다.
세션 시작과 종료를 감사 로그로 남깁니다.

Codex Hook은 PreToolUse, PermissionRequest, PostToolUse, UserPromptSubmit, Stop 같은 이벤트에 명령을 연결할 수 있습니다. 다음 예시는 셸 도구 실행 전에 저장소 루트의 정책 스크립트를 호출하는 구조입니다.

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "/usr/bin/python3 \"$(git rev-parse --show-toplevel)/.codex/hooks/check_agent_command.py\"",
            "timeout": 10
          }
        ]
      }
    ]
  }
}

Hook이 잘 맞는 신호는 다음과 같습니다.

Agent가 기억해서 선택하기를 기대해서는 안 되는 검사입니다.
실행 시점이 명확합니다.
입력과 종료 코드로 결과를 판정할 수 있습니다.

Hook을 “작업이 끝나면 알아서 품질을 높여주는 프롬프트”로 사용하면 판단이 불투명해질 수 있습니다. 비밀값 패턴 검사, 특정 명령 차단, 포맷 검사처럼 기계적으로 판정 가능한 작업부터 Hook에 두는 편이 좋습니다.

Hook은 모델의 자발적인 선택보다 예측 가능하지만 실행을 절대 보장하지는 않습니다. 로컬 Hook이 꺼졌거나 신뢰되지 않은 프로젝트에서 건너뛰어질 수 있고, 제품과 실행 환경에 따라 지원 이벤트가 다를 수 있습니다. 병합을 막아야 하는 검증은 CI와 브랜치 보호 규칙에 남겨야 합니다. 권한 정책과 Hook의 경계는 AI 코딩 에이전트 자동 승인 기준에서 더 자세히 다룹니다.

같은 작업에서 네 요소를 함께 쓰는 방법

실제 작업은 하나의 요소로 끝나지 않을 수 있습니다. 처음에는 장애 분석 순서만 Skill로 만들 수 있습니다. 이후 Sentry 데이터가 필요해지면 MCP를 연결하고, 읽기 전용 역할을 반복해서 사용하게 되면 Custom Agent로 묶습니다. 탐색 결과가 메인 대화를 가득 채우기 시작하면 그 역할을 Subagent로 위임하고, 운영 명령 차단은 Hook으로 분리합니다.

오류 분석 Custom Agent (Subagent로 위임)
  └─ 장애 분석 Skill
       ├─ Sentry MCP로 오류 이벤트 조회
       ├─ GitHub MCP로 관련 이슈 확인
       └─ PreToolUse Hook으로 운영 변경 명령 차단

각 요소의 책임은 다음처럼 분리됩니다.

Custom Agent는 읽기 중심의 오류 분석 역할을 정의하고, Subagent 실행이 별도 컨텍스트를 제공합니다.
Skill은 증상 수집, 재현, 원인 후보, 검증 순서를 정의합니다.
MCP는 Sentry와 GitHub의 최신 데이터에 접근합니다.
Hook은 분석 Agent가 운영 변경 도구를 호출하지 못하도록 검사합니다.

이 구성이 좋은 이유는 교체가 쉽기 때문입니다. 오류 분석 절차를 바꿀 때는 Skill을 수정합니다. Sentry 연결 방식을 바꿀 때는 MCP 설정을 바꿉니다. 리뷰 역할을 추가할 때는 Agent를 추가합니다. 금지 정책을 강화할 때는 Hook이나 관리형 정책을 바꿉니다.

헷갈릴 때 쓰는 결정 순서

새로운 요구가 생겼다고 바로 Agent부터 만들 필요는 없습니다. 다음 순서로 판단하면 과한 설정을 줄일 수 있습니다.

1. 한 번만 필요한 지시인가

현재 작업에서만 필요한 조건이라면 프롬프트에 적습니다. 아직 반복되지 않은 절차를 Skill로 만들면 유지할 설정만 늘어납니다.

2. 모든 작업에 적용되는 저장소 규칙인가

빌드 명령, 디렉터리 구조, 모든 변경에 필요한 검증처럼 상시 규칙이라면 AGENTS.md나 제품의 project instructions가 먼저입니다. 특정 작업에서만 필요한 긴 절차를 상시 지침에 넣으면 컨텍스트가 커질 수 있습니다.

3. 반복되는 절차인가

릴리스, 리뷰, 장애 분석처럼 입력만 바뀌고 작업 순서가 반복된다면 Skill로 만듭니다.

4. 기본 도구에 없는 데이터나 행동이 필요한가

기본 도구에 없는 데이터나 API 작업이 필요하다면 MCP를 연결합니다. 이때 필요한 도구만 노출하고 읽기와 쓰기 승인을 구분합니다.

5. 별도 역할이나 컨텍스트가 필요한가

역할과 도구 범위를 반복해서 사용할 때는 Custom Agent로 정의합니다. 많은 파일을 탐색하는 조사나 병렬로 진행할 독립 작업처럼 컨텍스트 분리가 필요하면 Subagent로 위임합니다.

6. 실행 시점이 정해져 있는가

정해진 이벤트에서 실행할 검사나 감사 작업이면 Hook에 연결합니다. 로컬 Agent 세션의 추가 방어선은 Hook, 반드시 통과해야 하는 저장소 병합 조건은 CI가 더 적합합니다.

자주 생기는 잘못된 설계

모든 역할을 Agent로 만든다

테스트 실행 Agent, 커밋 메시지 Agent, 문서 맞춤법 Agent를 계속 추가하면 역할 정의와 유지 비용이 커집니다. 별도 역할이나 도구 제한이 필요하지 않은 짧은 절차는 Skill이나 일반 명령으로 충분합니다.

Skill에 외부 접속 방법까지 억지로 넣는다

Skill에 curl 명령과 토큰 전달 방식을 길게 적으면 인증과 도구 스키마가 작업 절차에 섞입니다. 외부 연결은 MCP나 별도 CLI로 제공하고 Skill은 그 도구를 사용하는 순서에 집중하는 편이 낫습니다.

MCP 서버에 업무 판단을 모두 넣는다

MCP 서버는 도구와 데이터 경계를 제공하는 데 강합니다. 팀의 리뷰 기준이나 릴리스 판단 전체를 서버 지침에 넣으면 다른 작업에서도 불필요한 규칙이 따라올 수 있습니다. 작업별 판단은 Skill이나 Agent 역할로 분리합니다.

Hook만 통과하면 안전하다고 생각한다

Hook은 실행 환경과 신뢰 상태에 영향을 받습니다. 또한 문자열 패턴만으로 셸 명령의 모든 부작용을 판정하기 어렵습니다. 권한 정책과 샌드박스를 먼저 두고 Hook을 추가 방어선으로 사용해야 합니다.

같은 규칙을 여러 곳에 복사한다

“운영 DB를 수정하지 않는다”는 규칙을 Agent, Skill, MCP 설명, Hook에 문장으로 반복하면 어느 것이 기준인지 흐려집니다. 사람과 모델이 알아야 할 정책은 지침에 두고, 기술적으로 강제할 수 있는 부분은 권한 설정과 Hook에 둡니다. 문장과 실행 장치의 책임을 구분해야 합니다.

최소 구성부터 시작한다

처음부터 네 요소를 모두 만들 필요는 없습니다. 작은 프로젝트라면 다음 순서가 충분합니다.

저장소 공통 규칙을 짧은 AGENTS.md에 둡니다.
두 번 이상 반복한 작업만 Skill로 분리합니다.
외부 시스템이 필요할 때 MCP를 하나씩 연결합니다.
조사량이나 권한 차이가 큰 역할만 Custom Agent로 정의합니다.
실제로 누락된 검증을 Hook 또는 CI로 강제합니다.

이 순서의 목적은 기능을 적게 쓰는 것이 아닙니다. 문제가 생겼을 때 어느 계층을 고쳐야 하는지 알 수 있게 만드는 것입니다.

Custom Agent가 잘못된 역할을 수행했다면 역할 정의를 봅니다. 절차를 빼먹었다면 Skill을 봅니다. 데이터를 가져오지 못했다면 MCP 연결과 도구 노출을 봅니다. 특정 검사가 실행되지 않았다면 Hook 이벤트와 CI를 봅니다.

결론

Custom Agent, Skill, MCP, Hook은 모두 AI 코딩 도구를 확장하지만 해결하는 문제가 다릅니다. Subagent는 이들과 같은 설정 종류라기보다 작업을 위임해 실행하는 방식입니다.

Custom Agent는 반복해서 사용할 역할, 모델과 도구 범위를 정의합니다.
Subagent는 위임받은 작업을 별도 컨텍스트에서 수행합니다.
Skill은 여러 작업과 Agent에서 재사용할 절차입니다.
MCP는 기본 도구 밖의 데이터와 행동을 제공하는 연결입니다.
Hook은 특정 이벤트에 맞춰 코드를 실행하는 확장 지점입니다.

헷갈릴 때는 “어디에 설정할까”보다 “역할, 절차, 외부 능력, 실행 시점 중 무엇을 바꾸려는가”를 먼저 물으면 됩니다. 답이 둘 이상이라면 억지로 한 기능에 넣지 말고 책임을 나누는 편이 오래 유지됩니다.