에이전트 · 스킬 · MCP · 훅 — 5분이면 끝나는 용어 정리

AI 코딩 도구를 처음 켜면, 도구보다 용어가 먼저 사람을 막아섭니다. 튜토리얼 한 줄에 모르는 단어가 세 개씩 나오거든요. "서브에이전트에 MCP 붙여서 훅으로 자동화하면 됩니다" — 자, 이 문장에서 몇 개나 아시겠어요?

그런데 말이죠, 이 용어들이 어려운 게 아닙니다. 비유가 없어서 어려운 겁니다. 그래서 오늘은 비유 하나만 씁니다. 중간에 다른 비유로 갈아타지 않을 테니 안심하고 따라오세요.

이 글은 처음부터 끝까지 읽어도 되고, 막히는 용어만 찾아 읽어도 됩니다. 나중에 다른 글을 읽다가 "훅이 뭐였더라?" 싶을 때 다시 돌아오는 자리라고 생각해 주세요.

목차

1. 모델(LLM) — 결국 누가 생각하는 걸까?
2. 에이전트 — 챗봇과 뭐가 다를까?
3. 컨텍스트 — AI는 왜 앞부분을 까먹을까?
4. 토큰 — 왜 글자가 아니라 토큰으로 셀까?
5. 프롬프트 — 왜 매번 같은 말을 반복하게 될까?
6. CLAUDE.md / AGENTS.md — 규칙은 어디에 적어둘까?
7. 스킬(Skill) — 많이 깔면 느려질까?
8. 훅(Hook) — AI가 깜빡해도 실행되게 하려면?
9. MCP — 왜 '지시'가 아니라 '권한'일까?
10. 서브에이전트 — 왜 일을 나눠서 맡길까?
11. 헷갈리는 짝 세 개 — 한 줄로 구분하는 법
12. 지금은 몰라도 되는 것들

---

전체 지도

시작하기 전에 비유부터 세팅하겠습니다.

AI 코딩 도구를 쓴다는 건, 똑똑하지만 우리 회사를 전혀 모르는 신입 직원에게 일을 시키는 것과 같습니다.

이 직원은 머리가 아주 좋습니다. 전 세계 코드를 다 읽고 왔거든요. 그런데 우리 팀이 어떤 규칙으로 일하는지, 배포는 어떻게 하는지, 이 회사 DB 비밀번호가 뭔지는 하나도 모릅니다.

오늘 다룰 열 개 남짓한 용어는 전부 "이 직원에게 무엇을, 어떻게, 어디까지 알려줄 것인가"에 붙은 이름입니다. 그게 전부예요. 위 지도는 앞으로 계속 돌아올 기준점이니 한 번 훑어두시고, 각 섹션에서 지금 어디쯤인지 짚어드리겠습니다.

---

1. 모델(LLM) — 결국 누가 생각하는 걸까?

전체 지도에서 가장 왼쪽, 이 직원의 머리에 해당하는 부분입니다.

모델(LLM, 대규모 언어 모델)은 실제로 생각하는 부분입니다. GPT, Claude, Gemini 같은 이름들이 여기 해당하죠.

초보자가 가장 자주 헷갈리는 지점이 여기입니다. 모델과 도구는 다른 것이에요. Claude Code, Cursor, Codex 같은 건 도구(껍데기)이고, 그 안에서 생각하는 건 모델입니다. 같은 도구에 다른 모델을 끼울 수도 있고, 같은 모델을 여러 도구에서 쓸 수도 있습니다.

비유로 돌아가면, 모델을 고르는 건 어떤 사람을 뽑을지 정하는 일이고 도구를 고르는 건 그 사람에게 어떤 사무실과 장비를 줄지 정하는 일입니다. 머리 좋은 사람을 뽑아놓고 연필 한 자루만 쥐여주면 일을 못 하고, 좋은 장비를 갖춰놓고 아무나 앉혀도 결과가 안 나옵니다. 앞으로 나올 용어 대부분은 사실 "장비" 쪽 이야기입니다.

→ 더 깊게: (링크 예정)

참고: Claude Code 공식 문서

---

2. 에이전트 — 챗봇과 뭐가 다를까?

방금 뽑은 그 직원이 자리에서 일어나는 순간입니다. 지도 상단의 큰 인물 아이콘 자리예요.

이 한 문장이 초보자가 가장 먼저 넘어야 할 벽입니다.

• 챗봇은 "이렇게 하세요"라고 알려줍니다.
• 에이전트는 직접 파일을 열고, 고치고, 명령어를 실행합니다.

챗봇은 옆자리에 앉아 조언해 주는 선배라면, 에이전트는 내 자리에 앉아 키보드를 직접 치는 동료입니다. 실제로 Claude Code 같은 도구는 코드베이스를 읽고, 파일을 수정하고, 터미널 명령을 돌리고, 테스트까지 실행합니다.

차이가 커 보이지만 원리는 단순합니다. 모델에게 "파일 읽기", "파일 쓰기", "명령 실행" 같은 도구를 손에 쥐여주고, 결과를 보고 다음 행동을 정하게 반복시키는 구조예요. 생각 → 행동 → 결과 확인 → 다시 생각. 사람이 일하는 방식 그대로입니다.

그래서 무서운 점도 여기서 생깁니다. 조언은 틀려도 무시하면 그만이지만, 행동은 이미 파일을 바꿔놓습니다. 뒤에 나올 훅이나 권한 이야기가 왜 필요한지는 이 문장 하나로 설명됩니다.

→ 더 깊게: (링크 예정)

참고: Claude Code 공식 문서

---

3. 컨텍스트 — AI는 왜 앞부분을 까먹을까?

직원 옆에 놓인 책상입니다. 지도에서 머리 바로 아래에 붙어 있는 부분이죠.

컨텍스트(문맥)는 AI가 한 번에 책상 위에 올려둘 수 있는 서류의 양입니다. 여기 올라온 것만 보고 판단해요. 책상 밖에 있는 건 존재하지 않는 것과 같습니다.

"대화가 길어지면 AI가 앞을 까먹는다"는 말, 들어보셨죠? 책상이 꽉 차면 아래쪽 서류부터 밀려나기 때문입니다.

그런데 2026년 기준으로 사정이 좀 달라졌습니다. 100만 토큰 컨텍스트를 지원하는 모델이 열 개를 넘어섰거든요. 예전엔 자랑거리였는데 지금은 기본 사양에 가깝습니다. 문제는 책상이 넓다고 서류를 다 읽는 건 아니라는 것입니다. 여러 벤치마크에서 예외 없이 확인된 사실인데, 컨텍스트가 길어질수록 품질이 떨어지고, 대체로 광고된 최대치의 60~70% 지점부터 눈에 띄게 나빠집니다. 게다가 모델은 최근에 들어온 서류를 과대평가하는 버릇이 있어요.

정리하면 이렇습니다. 책상이 넓어졌으니 마음껏 쌓아도 된다가 아니라, 넓어진 책상일수록 정리해서 올려야 한다. 뒤에 나올 스킬과 서브에이전트는 결국 이 책상을 어떻게 아껴 쓸 것인가에 대한 답입니다.

→ 더 깊게: (링크 예정)

참고: AI Model Context Window Comparison 2026 — elvex

---

4. 토큰 — 왜 글자가 아니라 토큰으로 셀까?

방금 그 책상 위 서류 장수를 세는 단위입니다. 지도에서 책상 옆에 붙은 작은 숫자 표시라고 보시면 됩니다.

토큰은 AI가 글을 쪼개서 세는 단위입니다. 단어도 글자도 아닌, 그 중간쯤 되는 조각이에요.

정확한 계산법을 외울 필요는 없습니다. 감각만 잡으면 충분해요.

• 영어는 대략 단어 하나가 1토큰 안팎
• 한글은 한 글자가 대략 1~2토큰. 같은 내용을 써도 영어보다 토큰을 더 먹습니다

왜 알아야 하냐면, 토큰은 돈이고 시간이고 책상 공간이기 때문입니다. 요금도 토큰 단위로 매겨지고, 컨텍스트 한계도 토큰으로 잽니다. 매 대화마다 읽히는 규칙 파일에 500줄을 적어두면, 그건 모든 요청에 붙는 고정 비용이 됩니다.

그래서 이 글에서 딱 하나만 가져가신다면 이겁니다. 책상 위 공간은 공짜가 아니다. 다음 섹션부터 나오는 네 가지 도구는 전부 "그럼 뭘 어디에 적어둘 것인가"라는 질문에 대한 서로 다른 답입니다.

→ 더 깊게: (링크 예정)

참고: 토큰 이해 — Microsoft Learn

---

5. 프롬프트 — 왜 매번 같은 말을 반복하게 될까?

여기서부터 지도의 오른쪽, "어떻게 알려줄 것인가" 구역으로 넘어갑니다. 그 첫 칸이 프롬프트예요.

프롬프트는 지금 이 자리에서 하는 구두 지시입니다. "이 함수 리팩터링해 줘", "테스트부터 짜 줘" 같은 말이죠.

가장 쉽고, 가장 빠르고, 가장 잘 잊힙니다. 창을 닫으면 사라지거든요. 내일 다시 켜면 그 직원은 어제 내가 뭘 부탁했는지 전혀 모릅니다.

그래서 이런 일이 벌어집니다. "우리는 들여쓰기 2칸이야", "커밋 메시지는 영어로 써", "any 타입 쓰지 마"를 하루에 세 번씩 다시 말하고 있는 자신을 발견하게 되죠.

이 지점이 중요합니다. 같은 말을 세 번 이상 반복하고 있다면, 그건 프롬프트로 할 일이 아니라 어딘가에 적어둘 일이라는 신호입니다. 어디에 적어둘지가 다음 세 섹션의 주제고요.

→ 더 깊게: (링크 예정)

---

6. CLAUDE.md / AGENTS.md — 규칙은 어디에 적어둘까?

지도 오른쪽 구역의 두 번째 칸, 사원 수칙 책자가 놓인 자리입니다.

CLAUDE.md(또는 AGENTS.md)는 프로젝트 폴더에 두는 마크다운 파일입니다. 성격은 하나로 정리됩니다. 항상, 매번 읽힙니다.

신입 직원 책상에 올려둔 사원 수칙 책자를 떠올리세요. 출근할 때마다 첫 장부터 읽고 시작합니다. 그래서 여기 적을 내용은 딱 두 조건을 만족해야 해요. 항상 참이고, 짧을 것.

좋은 예시는 이런 것들입니다.

• "이 프로젝트는 Tailwind만 씁니다. CSS 파일을 새로 만들지 마세요."
• "빌드는 pnpm build, 테스트는 pnpm test."
• "커밋 전에 반드시 타입 체크를 돌립니다."

반대로 "DB 마이그레이션 7단계 절차" 같은 건 여기 적으면 안 됩니다. 한 달에 한 번 쓸 내용을 매번 읽히게 만드는 건 4번에서 말한 고정 비용이거든요. 그런 건 다음 섹션의 스킬로 보냅니다. 공식 문서도 파일 하나를 200줄 아래로 유지하라고 권합니다. 길어질수록 컨텍스트만 먹고 준수율은 오히려 떨어지거든요.

두 파일 이름이 왜 갈리는지도 짚고 넘어갈까요? CLAUDE.md는 Claude Code가 읽는 이름이고, AGENTS.md는 도구를 가리지 않는 공용 규격입니다. 6만 개가 넘는 오픈소스 프로젝트가 쓰고 있고 25개 이상의 코딩 에이전트·IDE가 지원하며, 현재는 Linux Foundation 산하 Agentic AI Foundation이 관리합니다. 팀에 여러 도구가 섞여 있다면 본문은 AGENTS.md에 두고, CLAUDE.md에서는 그 파일을 한 줄로 불러오는 방식이 깔끔합니다. 같은 내용을 두 번 관리하지 않아도 되니까요.

그리고 꼭 기억하실 것 하나. 수칙은 읽히는 것이지 강제되는 것이 아닙니다. 공식 문서도 "무조건 막아야 하는 일은 수칙이 아니라 훅으로 쓰라"고 못 박고 있어요. 8번에서 다시 만납니다.

→ 더 깊게: (링크 예정)

참고: AGENTS.md 공식 사이트 · Claude Code 메모리 문서

---

7. 스킬(Skill) — 많이 깔면 느려질까?

지도 오른쪽 구역의 세 번째 칸, 캐비닛이 서 있는 자리입니다.

스킬은 폴더 하나에 SKILL.md 파일을 넣은 것입니다. 그 안에 절차와 노하우를 적어둡니다. "우리 회사 DB 마이그레이션 7단계", "PR 리뷰 체크리스트", "디자인 시스템 컴포넌트 작성 규칙" 같은 것들이죠.

사원 수칙이 매번 읽히는 책자라면, 스킬은 캐비닛에 꽂힌 업무 매뉴얼입니다. 평소엔 등에 붙은 제목만 보여요. 그 업무를 할 때만 꺼내서 펼칩니다.

그럼 초보자가 가장 궁금해하는 질문. "많이 깔면 느려지나요?"

답은 "생각보다 훨씬 덜 부담됩니다"입니다. 스킬은 세 단계로 나눠서 열리거든요.

1. 시작할 때 — 이름과 한 줄 설명만 올라옵니다. 캐비닛에 붙은 라벨만 보는 셈이죠
2. 일이 걸렸을 때 — 그 스킬의 본문 전체를 꺼내 읽습니다
3. 실행할 때 — 필요하면 딸려 있는 스크립트나 참고 문서까지 펼칩니다

이걸 점진적 공개(progressive disclosure)라고 부릅니다. 500줄짜리 API 레퍼런스를 스킬로 넣어두면, 그걸 쓰기 전까지는 비용이 거의 0에 가깝습니다. 같은 내용을 CLAUDE.md에 넣으면 매 턴마다 500줄을 지불하게 되고요. 이 차이가 스킬의 존재 이유 전부입니다.

참고로 이 SKILL.md 형식은 특정 회사 전용이 아니라 개방형 표준으로 공개돼 있습니다. Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code 등 서른 곳이 넘는 도구가 같은 형식을 읽습니다. 한 번 써두면 도구를 갈아타도 따라옵니다.

→ 더 깊게: (링크 예정)

참고: Agent Skills 표준 문서 · Claude Code Skills 문서

---

8. 훅(Hook) — AI가 깜빡해도 실행되게 하려면?

지도 오른쪽 구역의 마지막 칸이자, 성격이 확 다른 칸입니다. 출입문 자동 검사대예요.

앞의 세 개는 전부 "알려주는" 방식이었습니다. 구두로 알려주거나, 수칙에 적어두거나, 매뉴얼로 꽂아두거나. 공통점이 있죠. 결국 그 직원이 읽고 판단해서 따라야 합니다. 사람도 그렇듯 AI도 가끔 깜빡합니다.

훅은 판단을 아예 빼버립니다. 정해진 시점에 무조건 실행되는 셸 명령이에요.

• 파일을 수정한 직후 → 포매터를 돌린다
• 커밋하기 전 → 린트와 타입 체크를 돌린다
• 위험한 명령을 실행하려 할 때 → 막는다

공항 검색대를 생각하시면 됩니다. 승객이 아무리 "저 괜찮은 사람이에요"라고 말해도 검색대는 그냥 작동합니다. AI가 "이번엔 포맷 안 해도 될 것 같은데요"라고 판단해도 훅은 그 판단을 듣지 않습니다.

이게 나머지 셋과의 결정적 차이입니다. 규칙을 부탁하느냐, 강제하느냐. 절대 틀리면 안 되는 것만 훅으로 내리세요. 다 훅으로 만들면 개발 속도가 검사대 통과 속도에 묶여버립니다.

(요즘은 판단이 필요한 조건을 위해 모델이 개입하는 훅도 생겼습니다만, 훅의 본질은 여전히 "무조건"입니다. 처음엔 이쪽만 기억하셔도 충분해요.)

→ 더 깊게: (링크 예정)

참고: Claude Code Hooks 가이드

---

9. MCP — 왜 '지시'가 아니라 '권한'일까?

여기서 지도의 바깥 구역으로 나갑니다. 회사 건물 밖으로 나가는 문에 붙은 카드 리더기 자리예요.

MCP(Model Context Protocol)는 AI가 외부 시스템에 연결되는 표준 규격입니다. 흔히 "AI 세계의 USB-C"라고 부르죠. 사내 DB, Slack, GitHub, 디자인 툴 같은 것들이 여기 붙습니다.

앞의 네 가지와 층위가 다르다는 점만 잡으면 됩니다.

• 프롬프트·수칙·스킬·훅 = 무엇을 할지 알려주는 것 (지시와 지식)
• MCP = 어디에 들어갈 수 있는지 정하는 것 (권한)

아무리 훌륭한 매뉴얼을 줘도 출입 카드가 없으면 그 방에 못 들어갑니다. 반대로 출입 카드만 주고 매뉴얼을 안 주면, 들어가서 뭘 해야 할지 몰라 헤맵니다. 둘은 대체재가 아니라 짝입니다.

역사도 짧게 짚고 갈까요. 2024년 11월 Anthropic이 공개했고, 2025년 3월 OpenAI가, 4월에는 Google DeepMind가 채택하면서 사실상 업계 표준이 됐습니다. 2025년 12월에는 Linux Foundation 산하 재단으로 넘어가 특정 회사 소유가 아니게 됐고요.

마지막으로 경고 하나. 출입 카드는 아무에게나 주는 물건이 아닙니다. 신뢰할 수 없는 MCP 서버를 붙이면 프롬프트 인젝션이나 데이터 유출 통로가 될 수 있다는 연구가 여러 차례 보고됐습니다. 붙이기 전에 누가 만든 서버인지 한 번은 확인하세요.

→ 더 깊게: (링크 예정)

참고: Model Context Protocol — Wikipedia · MCP 공식 문서

---

10. 서브에이전트 — 왜 일을 나눠서 맡길까?

지도 오른쪽 아래, 옆방에 책상이 하나 더 놓인 자리입니다.

서브에이전트는 본체 에이전트가 일부 작업을 통째로 맡기는 별도의 에이전트입니다. 핵심은 딱 하나예요. 자기 책상을 따로 갖습니다.

3번에서 책상이 꽉 차면 앞의 서류가 밀려난다고 했죠. 그런데 "테스트 전체 돌려보고 실패한 것만 알려줘" 같은 일은 출력이 어마어마하게 쏟아집니다. 이걸 내 책상에서 하면 정작 중요한 설계 논의가 밀려나요.

그래서 옆방에 인턴을 하나 붙입니다. 인턴이 자기 책상에서 로그를 산더미처럼 펼쳐놓고 뒤진 다음, 나에게는 "세 개 실패했고 원인은 이겁니다" 한 장만 들고 옵니다. 산더미는 그 방에 두고 오는 거죠.

이 인턴에게는 별도의 지시서, 별도의 도구 권한, 심지어 다른 모델을 붙일 수도 있습니다. "읽기만 가능하고 쓰기는 금지" 같은 제한을 걸어두면 사고 범위도 줄어듭니다.

쓰기 좋은 자리는 정해져 있습니다. 출력이 많은 일, 독립적으로 끝나는 일, 병렬로 돌려도 되는 조사 작업. 반대로 맥락을 계속 주고받아야 하는 일은 넘기지 마세요. 인턴에게 설명하는 시간이 더 듭니다.

→ 더 깊게: (링크 예정)

참고: Claude Code Subagents 문서

---

11. 헷갈리는 짝 세 개 — 한 줄로 구분하는 법

지도를 다 돌았습니다. 이제 서로 옆칸에 있어서 자꾸 헷갈리는 것들만 모아볼게요.

용어집의 진짜 가치는 정의가 아니라 구분선에 있습니다. 각 짝마다 딱 한 가지만 물어보면 갈립니다.

헷갈리는 짝	한 줄 구분법
스킬 vs CLAUDE.md	가끔 읽히나 / 매번 읽히나
스킬 vs 훅	AI가 판단해서 쓰나 / 무조건 실행되나
MCP vs 스킬	어디에 갈 수 있나(권한) / 무엇을 할지 아나(지식)

첫 번째 줄은 비용 문제입니다. 매번 읽히는 자리에는 항상 참인 짧은 규칙만, 가끔 쓰는 절차는 캐비닛으로.

두 번째 줄은 신뢰 문제입니다. "웬만하면 지켜줘"는 스킬, "예외 없이"는 훅.

세 번째 줄은 층위 문제입니다. 이 둘은 경쟁 관계가 아니라 짝입니다. Slack MCP를 붙였다고 해서 AI가 우리 팀 공지 규칙을 아는 건 아니에요. 카드는 MCP가 주고, 들어가서 뭘 할지는 스킬이 알려줍니다.

→ 더 깊게: (링크 예정)

---

12. 지금은 몰라도 되는 것들

마지막 칸입니다. 지도 맨 아래 "나중에" 상자에 담아둘 것들이에요.

용어집을 읽다 보면 아직 안 나온 단어들이 눈에 밟히죠. 그래서 여기 모아놓고 한 줄씩만 정리하겠습니다. 한 줄만 읽고 넘어가세요.

• 파인튜닝 — 모델 자체를 우리 데이터로 다시 훈련시키는 것. 신입을 가르치는 게 아니라 아예 다른 사람으로 만드는 일입니다
• RAG — 질문할 때마다 관련 문서를 찾아 책상 위에 올려주는 구조. 지금 쓰는 도구들은 대부분 알아서 해줍니다
• 벡터 DB — RAG가 문서를 빨리 찾기 위해 쓰는 저장소. RAG를 직접 만들 때 필요합니다
• 멀티에이전트 오케스트레이션 — 여러 에이전트를 지휘하는 설계. 인턴 한 명도 안 써봤다면 아직입니다
• 컨텍스트 엔지니어링 — 책상에 뭘 올릴지 설계하는 기술. 사실 이 글 전체가 그 입문편입니다

공통점이 보이시나요? 이것들은 도구를 만드는 사람의 용어입니다. 도구를 쓰는 사람의 용어가 아니에요.

다른 용어집들은 아는 걸 전부 쏟아내서 초보자를 더 불안하게 만듭니다. 저는 반대로 말씀드릴게요. 지금 몰라도 됩니다. 필요해지는 순간이 오면 그때 찾아도 전혀 늦지 않습니다. 그 순간이 오기 전까지는, 앞의 열 개만 제대로 구분해도 대부분의 튜토리얼이 읽힙니다.

→ 더 깊게: (링크 예정)

---

마무리 — 다음에 읽을 것

길게 왔지만 결론은 한 문장입니다. 오늘 다룬 용어는 전부 "신입에게 무엇을, 어디에 적어줄 것인가"에 붙은 이름이었습니다. 매번 읽힐 자리에 적을지, 캐비닛에 꽂아둘지, 아예 검사대로 만들지, 아니면 출입 카드를 새로 발급할지. 그 선택이 달라질 뿐이에요.

용어가 다시 헷갈리면 11번 표만 다시 보셔도 됩니다. 그 세 줄이 이 글의 압축판입니다.

• 어디에 적을지 고르는 법 — (링크 예정)
• 규칙 파일 직접 만들어보기 — (링크 예정)
• AI가 짠 코드 리뷰 체크리스트 — (링크 예정)

---