AI Agent, 넌 누구냐 1 - Tool, MCP, Skill, Harness는 무엇인가

요약: AI Agent를 사용하기에 앞서 미리 알아두면 좋을 개념들에 대해 설명합니다.

💡 리뷰어 한줄평

hoult.jun AI 도구를 사용하기에 앞서 어떤 내용들을 먼저 학습하면 좋을지 안내해주는 글 입니다. 급변하는 AI 시대 속에서 새로운 내용을 학습하기를 멀리하게 되고 마냥 새로운 도구들만 사용하기 마련인데 이 글이 좋은 지침이 될 것 같습니다.

시작하며

안녕하세요. 카카오페이에서 FE 개발을 하고 있는 마쉬입니다.

최근 개발 생태계에서 가장 뜨거운 화두를 꼽으라면 단연 AI Agent(에이전트)가 아닐까 싶습니다. Codex, Claude Code, GitHub Copilot 등 이미 많은 분이 사용해 보셨을 텐데요. 프로젝트 규모가 커지면서 AI에게 단순 코드 작성을 넘어 “이 기능 통째로 구현해 줘” 같은 거대한 미션을 맡기기 시작합니다. 이때 구조적인 한계와 모호함에 부딪히는 분들이 많아졌습니다.

“내가 쓰던 ChatGPT랑 Agent는 뭐가 다르지?”, “MCP, Skill, Harness… 이 수많은 키워드는 다 뭐고 어디에 위치해야 하는 걸까?”

저 역시 같은 고민을 거쳤기에, 오늘은 AI Agent를 개발 워크플로우에 처음 도입하려는 분들이 반드시 알아야 할 핵심 개념과 아키텍처적 키워드들을 제 나름대로 정리해 공유해 보려고 합니다.

1. LLM과 AI Agent: ‘머리’와 ‘몸’의 차이

Agent를 이해하기 위한 첫걸음은 기존에 쓰던 LLM 챗봇과의 차이를 명확히 인지하는 것입니다.

LLM (Large Language Model) — 사람으로 따지면 머리

방대한 데이터를 학습해 인간의 언어를 이해하고 요약, 번역, 생성하는 대규모 언어 모델입니다. OpenAI의 GPT 계열(ex. GPT-5.6), Anthropic의 Claude 계열(ex. Claude Sonnet 5), Google의 Gemini 계열(ex. Gemini 3.1 Pro) 등이 있습니다.

• 작동 방식: 입력을 받아 출력을 내는 함수입니다. 상태(State)가 없습니다.
• 자주 하는 오해: “LLM은 단발성이고 Agent는 대화를 기억한다”는 설명을 종종 보는데, 정확하지 않습니다. 일상에서 쓰는 챗봇도 여러 차례 이어지는 대화를 잘 합니다. 다만 그건 모델이 기억하는 게 아니라, 매 호출마다 이전 대화 기록 전체를 다시 보내주기 때문에 기억하는 것처럼 보이는 것입니다. 모델 자체는 매번 백지 상태에서 시작합니다.
• 한계: 스스로 정보를 검색하거나 내 로컬 컴퓨터의 파일을 수정할 수 없습니다. 질문에 대답은 해주지만, 직접 실행할 수는 없습니다.

AI Agent — 사람으로 따지면 몸

목표(Goal)만 주면 알아서 계획을 짜고, 필요한 도구를 써서, 처음부터 끝까지 업무를 완수하는 AI 일꾼입니다. Codex, Claude Code, Gemini CLI 등이 여기에 속합니다.

• 작동 방식: 목표를 실행 가능한 작업으로 쪼갠 뒤, 도구를 호출해 결과를 관찰하고 다음 행동을 정하는 반복 동작입니다. 중간에 정보를 넣어 주지 않아도 스스로 굴러갑니다.
• 한계: 스스로 판단하는 만큼 통제가 필요합니다. 루프가 길어지면 컨텍스트가 차오르고 비용이 누적되며, 권한을 좁혀 두지 않으면 건드리면 안 되는 것까지 건드립니다.

2. Agent는 어떻게 작동할까? (feat. ReAct 패턴)

Agent가 동작하는 핵심 메커니즘은 목표 설정 ➔ 정보 획득 ➔ 작업 구현의 순환 구조입니다.

• 목표 설정: 유저에게 목표를 받으면, Agent는 이를 실행 가능한 작은 작업(Task)들로 쪼개고 순서를 배치합니다.
• 정보 획득 & 구현: 작업을 하다가 지식이 부족하면 외부 세상과 소통합니다. 질문을 받은 Agent는 LLM을 통해 먼저 추리(Reasoning)를 합니다. 내 지식으로 답할 수 없다면 등록된 Tool들의 설명(Description) 텍스트를 읽고, “인터넷 검색 툴을 써야겠네!” 하고 행동(Action)을 취하죠.

가져온 정보를 분석해 답변이 부족하면 다시 질문을 정의하고 다른 툴을 호출합니다. 추리하고 → 행동하고 → 결과를 보고 → 다시 추리하는 이 구조를 ReAct(Reasoning + Action) 패턴이라고 부릅니다. 2022년 논문에서 제안된 추론 단계와 행동 단계를 분리해 품질을 높이는 패턴인데, 지금 도구들이 그대로 쓰지는 않습니다. 요즘은 모델이 함수 호출을 네이티브로 지원해서(tool calling) 구현 방식은 달라졌지만, “판단 → 행동 → 관찰 → 재판단”이라는 뼈대는 그대로입니다. 오늘날 Agent 루프의 원형이라고 보시면 됩니다.

루프에는 멈추는 기준이 있어야 합니다. 없으면 무한히 돌거나, 반대로 다 끝나기 전에 멈춥니다.

• 모델이 스스로 완료 선언 — 가장 흔하지만, 다 안 됐는데 됐다고 하는 경우가 있습니다
• 최대 반복 횟수 / 토큰 예산 초과 — 실행이 폭주하지 않게 막는 안전장치입니다.
• 외부 검증 통과 — 테스트가 통과하면 종료. 가장 신뢰할 만합니다

토큰과 컨텍스트 윈도우

기본적으로 AI Agent를 사용할 때 필수로 알아야 하는 2개의 키워드입니다.

• 토큰(Token): 모델이 텍스트를 처리하는 최소 단위입니다. 글자 수도 단어 수도 아닌, 모델의 토크나이저가 쪼개 놓은 조각의 개수입니다. 처리 속도와 비용을 가늠하는 기준이 됩니다.

여기서 주의할 점은 이 ‘최소 단위’의 크기가 언어마다 다르다는 것입니다. 대부분의 토크나이저는 영어 데이터를 기준으로 학습되어 있어서, 영어는 자주 쓰이는 단어 하나가 토큰 하나로 잡히는 경우가 많습니다. 반면 한글은 흔한 단어가 아니면 음절 단위, 심하면 바이트 단위까지 쪼개집니다. 다음은 정확한 수치는 아니고 참고용 예시입니다.

"tokenization"        → token / ization             (2 토큰)
"토큰화"               → 토 / 큰 / 화 또는 그보다 더 잘게    (3 토큰 이상)

즉 같은 의미를 담은 문장이라도 한글로 쓰면 영어보다 토큰이 몇 배로 늘어날 수 있습니다. 정확한 수치는 모델과 토크나이저 버전에 따라 다르니, 비용이 민감한 작업이라면 각 모델이 제공하는 토큰 카운팅 API로 직접 재보는 편이 확실합니다.

과금 기준도 짚어둘 필요가 있습니다. API를 직접 호출할 때는 입력 토큰과 출력 토큰에 각각 다른 단가가 붙는 토큰 단위 과금이 일반적입니다. 다만 이게 유일한 방식은 아닙니다. 월 정액 구독형 요금제는 토큰이 아니라 사용량 한도로 제한을 걸고, 이미지나 음성처럼 텍스트가 아닌 입력은 장수나 재생 시간이 기준이 되기도 합니다. 프롬프트 캐싱처럼 같은 토큰을 읽어도 단가가 달라지는 옵션도 있습니다. 그래서 “토큰을 줄이면 비용이 줄어든다”는 대체로 맞지만, 실제 청구서는 사용하는 요금제와 입력 형태에 따라 달라집니다.

• 컨텍스트 윈도우(Context Window): 모델이 한 번의 호출에서 볼 수 있는 토큰의 총량입니다. 시스템 프롬프트, 대화 기록, 도구 목록, 도구 실행 결과, 그리고 생성할 답변까지 이 한 번의 호출 안에 전부 들어가야 합니다.

컨텍스트가 많아지면 세 가지 문제가 차례로 나타납니다.

첫째, 비용과 응답 시간이 늘어납니다. 앞서 이야기했듯 모델은 매 호출마다 이전 대화 기록을 처음부터 다시 받습니다. 대화가 10턴까지 이어졌다면 10번째 호출에서는 앞선 9턴의 내용을 다시 읽는 셈입니다. 주고받는 횟수가 늘어날 때마다 한 번에 읽어야 하는 양도 같이 불어나기 때문에, 대화가 두 배 길어지면 전체 비용은 두 배보다 훨씬 많이 듭니다. 도구 실행 결과가 계속 쌓이는 Agent 루프에서는 이 격차가 더 벌어집니다. 프롬프트 캐싱으로 반복해서 읽는 앞부분의 비용을 낮출 수는 있지만, 읽어야 하는 양 자체가 줄어드는 것은 아닙니다.

둘째, limit를 넘으면 앞부분이 잘려 나갑니다. 이때 대부분의 도구는 에러를 내는 대신 오래된 대화부터 알아서 버리거나 요약해서 대화를 이어갑니다. 문제는 이 정리가 조용히 일어난다는 점입니다. 작업 초반에 합의했던 요구사항이나 코딩 규칙이 요약 과정에서 사라져도 사용자는 알 수 없습니다. Agent가 갑자기 아까 정한 규칙을 어기기 시작한다면 대개 이것이 원인입니다.

셋째, limit에 닿기 전에도 품질이 떨어집니다. 컨텍스트에 담긴 내용이 길어지면 모델은 앞부분과 끝부분은 비교적 잘 참고하지만, 가운데에 묻힌 내용은 흘려보내는 경향이 있습니다. 그래서 “아직 limit까지 여유가 있으니 괜찮다”고 보기는 어렵습니다. 지금 하는 작업과 상관없어진 내용은 그때그때 덜어내는 편이 좋습니다.

3. 확장성을 위한 아키텍처 키워드

지금까지 Agent가 어떻게 작동하는지 알아봤다면, 이제 그 도구들을 실제로 어떻게 사용할 수 있는지 알아보겠습니다. Agent를 실무 프로젝트에 제대로 녹여내려면, 이 ‘일꾼’들이 움직이는 인프라 구조를 이해해야 합니다.

Tool - 외부 세상과 연결되는 창구

실시간 주가나 최신 문서처럼 LLM이 모르는 최신 데이터가 필요할 때, 구글 검색 엔진이나 Yahoo Finance API 같은 외부 애플리케이션에 접근할 수 있게 연결해 둔 인터페이스를 뜻합니다.

동작 원리는 단순합니다. AI 모델에게 “이런 함수들이 있고, 각각 이런 일을 하고, 이런 인자를 받는다” 는 명세와 설명(Description)을 넘겨줍니다. AI 모델은 그걸 읽고 사용하기로 결정한 함수 이름과 인자를 텍스트로 agent에게 전달합니다.

로컬 파일을 읽는 read_file 도구를 예로 들어보겠습니다. Agent는 세션을 시작할 때 아래와 같은 명세를 모델에게 함께 넘깁니다.

{
  "name": "read_file",
  "description": "주어진 경로의 파일 내용을 UTF-8 텍스트로 반환한다",
  "input_schema": {
    "type": "object",
    "properties": {
      "path": { "type": "string", "description": "읽을 파일의 경로" }
    },
    "required": ["path"]
  }
}

앞에서 말한 세 가지가 그대로 들어 있습니다. name이 “이런 함수가 있고”, description이 “이런 일을 하고”, input_schema가 “이런 인자를 받는다”에 해당합니다.

여기서 짚어둘 점은 모델이 이 함수를 직접 실행하지 않는다는 것입니다. 모델이 내놓는 것은 “이 함수를 이 인자로 불러 달라”는 요청 텍스트뿐이고, 실제로 디스크를 읽는 주체는 Agent입니다.

그래서 description을 어떻게 쓰느냐가 중요합니다. 모델이 어떤 도구를 고를지는 이 설명 텍스트를 읽고 판단하기 때문에, 설명이 모호하면 엉뚱한 도구를 부르거나 필요한 도구를 지나칩니다. 반대로 도구를 수십 개씩 등록해 두면 명세만으로 컨텍스트를 상당히 차지합니다. 지금 하는 작업에 필요한 도구만 켜두는 편이 좋습니다.

MCP (Model Context Protocol) — 표준화된 연결 규약

MCP는 개발자와 Tool 제공자가 스펙을 일일이 맞출 필요 없이, 업계 표준 프로토콜로 소통하도록 만든 오픈소스 규약입니다.

프레임워크(LangChain, CrewAI 등 — Agent를 직접 코드로 구성할 때 쓰는 대표적인 오픈소스 라이브러리)가 늘어나고 Tool이 많아지면, 각각의 SDK를 따로 만드느라 개발 관리 부담이 엄청나게 커집니다. AI 클라이언트가 M개, 붙이고 싶은 도구가 N개면 연동 작업이 MxN개 필요합니다. Slack 연동을 Codex용으로 만들고, Claude Code용으로 또 만들고, 다음 도구가 나오면 또 만들고… 도구 제공자도 클라이언트도 양쪽 다 지칩니다.

MCP는 이 사이에 표준 규약을 하나 끼워 넣어 MxN을 M+N으로 줄입니다. MCP 규격에 맞춰 서버를 하나 만들어두면, Claude든 Codex든 코드 수정 없이 플러그처럼 꽂아서(Plug & Play) 내 컴퓨터 파일이나 슬랙, DB를 AI에게 연결할 수 있습니다. MCP는 실행 가능한 함수(Tools)뿐 아니라 읽기 전용으로 참조할 자료(Resources), 재사용할 프롬프트 템플릿(Prompts)까지 규정합니다. 도구 연결뿐 아니라 “모델에게 무엇을 건네줄 것인가” 전반을 다루는 규약인 셈입니다.

Skill (스킬) — 도구 활용 매뉴얼

단순히 도구(Tool)만 쥐여준다고 집을 지을 수 없겠죠? Agent가 특정 목표를 위해 Tool들을 어떤 순서로, 어떻게 조합해서 써야 하는지 담아둔 가이드라인이나 프롬프트 파일을 의미합니다. 도구를 다루는 ‘판단력과 워크플로우’가 바로 스킬입니다.

규격이 꽤 구체적으로 잡혀 있는데, 폴더 하나에 SKILL.md 파일을 두고 이름과 설명을 적는 구조입니다. 핵심 설계는 점진적 공개(Progressive Disclosure)입니다.

1. 세션 시작 시점에는 이름과 설명만 컨텍스트에 올라갑니다.
2. Agent가 필요하다고 판단하면 본문 전체를 읽습니다.
3. 본문이 참조하는 상세 문서는 정말 필요할 때만 읽습니다.

📌 규칙 파일(CLAUDE.md, AGENTS.md) vs Skill

규칙 파일은 항상 읽히고, 스킬은 필요할 때만 읽힙니다. 그래서 “이 프로젝트는 pnpm을 쓴다” 같은 상시 규칙은 규칙 파일에, “PDF에서 표를 추출하는 방법” 같은 특정 작업 지식은 스킬에 넣습니다. 규칙 파일은 최대한 짧게 유지하는 게 좋습니다. 규칙 파일에 모든 걸 몰아넣으면 매 세션 컨텍스트를 낭비하기 때문입니다. 여기 넣은 내용은 쓰든 안 쓰든 매 세션 비용으로 청구됩니다.

Plugin (플러그인) — 기능 확장 패키지

특정 서비스나 기능을 AI가 바로 쓸 수 있도록 관련 Tool, Skill, MCP 서버 등을 하나로 묶어놓은 밀키트/가구 조립 키트 같은 것입니다. “슬랙 연동해 줘”라고 했을 때, 일일이 세팅할 필요 없이 ‘슬랙 플러그인’을 딸깍 설치하면 메시지 읽기/전송 기능과 가이드라인이 통째로 AI에 탑재됩니다.

Marketplace (마켓플레이스) — AI 전용 앱스토어

전 세계 개발자들이 만들어 올린 플러그인, MCP 서버, AI 스킬들을 다운로드하거나 구매할 수 있는 허브입니다. 스마트폰의 App Store처럼, 이제 내 Agent에게 줄 새로운 도구와 전문 지식을 쇼핑하는 공간인 거죠. (예: Cursor Marketplace, Smithery 등) 다만 남이 만든 스킬과 MCP 서버를 설치하는 건 남의 코드를 실행하는 것과 같습니다. 심사 절차가 있는 앱스토어와는 다르니, 공식 제공처나 신뢰할 만한 제작자의 것을 사용하세요.

4. 엔터프라이즈급 개발을 위한 안전장치와 제어 장치

이렇게 도구를 갖췄다면, 이제 이 도구들을 실무 규모에서 안전하게 굴리는 방법이 필요합니다. Agent에게 수천 줄짜리 프로젝트를 통째로 맡기면 컨텍스트에 과부하가 걸려 품질이 떨어지는 코드를 짜기 시작합니다. 이를 방지하기 위한 시스템적 보완 장치들입니다.

Multi-Agent Orchestration (멀티 에이전트 오케스트레이션) — AI 지휘자와 팀플레이

혼자 다 하려던 AI에게 전문 분야를 가진 AI 팀원들을 붙여주고 협업을 지휘하는 패턴입니다. 플러그인 형태로 패키징된 것도 있지만, 직접 구성할 수도 있습니다.

같은 모델에 서로 다른 지시를 줘서 “깐깐한 아키텍트”, “손 빠른 주니어”, “악독한 QA” 같은 페르소나로 역할을 나눕니다. Main Agent가 명령을 쪼개어 작업 큐(Queue)와 흐름을 제어합니다. 대화 중 맥락이 유실되지 않게 중심에서 공통 메모리(State)를 관리합니다.

Main Agent는 Subagent에게 작업을 넘기고, 그 결과만 받아서 최종 처리를 합니다. 이 “결과만”이 핵심입니다. Subagent는 자기만의 컨텍스트 윈도우를 씁니다. 파일 20개를 뒤지고 검색을 다섯 번 돌렸어도, 메인에게 돌아오는 건 정리된 결론 한 덩어리뿐입니다. 탐색 과정의 잡음이 메인 컨텍스트를 오염시키지 않는 거죠. 앞에서 컨텍스트가 차오르면 품질이 떨어진다고 했었죠. Subagent는 일을 나누는 장치이기 이전에 컨텍스트를 격리하는 장치입니다. 탐색이나 조사처럼 과정은 지저분하고 결론은 짧은 작업일수록 효과가 큽니다.

Supervisor (슈퍼바이저) & Hook (훅) — AI 감독관

Supervisor는 작업하는 Agent를 관찰하다가 무한 루프에 빠지거나 같은 실패를 반복하면 개입하는 별도의 Agent입니다. 보통 상대적으로 무거운 모델이 실무를 처리할 때, 가볍고 빠른 모델을 감독관으로 세워 모니터링하다가 정체되면 깨우고(Nudge), 안 되면 인간에게 에스컬레이션(Escalate)합니다. 모니터링을 가벼운 모델로 시켜도 괜찮은 이유는 코드의 옳고 그름을 판단하는 역할이 아니라 진행 상태를 체크하는 역할을 하기 때문입니다.

Hook은 “파일을 저장할 때”, “커밋 직전에” 같은 시점에 자동으로 실행되는 스크립트입니다. 린터를 돌리거나 테스트를 실행하거나 금지된 파일 수정을 차단합니다. LLM의 판단에 의존하지 않는다는 점이 장점입니다. 프롬프트로 “커밋 전에 항상 테스트를 돌려”라고 지시하면 대개 지키지만 가끔 잊습니다. Hook으로 걸면 조건이 맞을 때 무조건 실행됩니다. 그래서 지켜야 하는 규칙은 프롬프트가 아니라 Hook으로 강제하는 편이 낫습니다.

Harness Engineering (하네스 엔지니어링) — Agent를 안전하게 굴리는 제어 구조

하네스는 원래 말에 채우는 마구를 뜻합니다. 말의 힘을 억누르는 물건이 아니라, 그 힘을 원하는 방향으로 쓰기 위한 장치죠. 모델을 더 똑똑하게 만드는 대신, 모델이 일하는 환경을 설계하는 패턴입니다.

앞에서 Subagent가 컨텍스트를 격리하는 장치라고 했었죠. 하네스는 그 위층입니다. 격리된 컨텍스트 안에서 무슨 일이 벌어지든, 결과물이 통과해야 할 관문을 미리 깔아두는 것. 일을 어떻게 나눌지가 오케스트레이션이고, 나뉜 일이 무엇을 통과해야 하는지가 하네스입니다.

앞에서 본 Hook, Supervisor와 Subagent는 따로 노는 기법이 아니라, 하나의 구조를 이루는 부품이었습니다. 세 가지를 동시에 맡습니다.

핵심 규율은 하나입니다. Agent가 실수하면 프롬프트를 고치지 않습니다. 그 실수가 구조적으로 불가능해지는 장치를 만듭니다. “반드시 XYZ 해라”라고 대문자로 써두는 건 확률이지만, 어기면 빌드가 깨지는 건 보장입니다.

하네스는 Agent를 통제하는 장치이기 이전에, 실패를 자산으로 바꾸는 장치입니다. 프롬프트 수정은 그 세션에서 끝나지만 검증 스크립트는 남습니다. 모델이 새롭게 출시되어도 하네스는 재사용할 수 있습니다.

마치며

어떠신가요? 이제 어디서 이 키워드들을 마주치더라도 Agent의 능력을 넓히는 쪽인지, 실행을 통제하는 쪽인지 정도는 구분되실 겁니다. 이렇게 개념들을 제자리에 놓고 통제하는 것이, 앞으로의 AI 협업 개발에서 생산성을 가르는 핵심 역량이 될 거라고 생각합니다.

다만 한 번에 다 도입하려 하면 지치기 쉽습니다. 시작은 가볍게, 마켓플레이스에서 플러그인 하나 설치해 Tool부터 붙여보세요. 더 좋은 모델을 기다리는 것보다, 지금 쓰는 도구의 실행 환경을 다듬는 쪽이 훨씬 빠릅니다.

이상으로 AI Agent를 사용하기에 앞서 Tool, MCP, Skill, Harness가 각각 무엇인지 정리해 보았습니다. 지금까지 읽어주셔서 감사합니다.