한 줄 요약

지금까지 써 온 도구가 사실 에이전트였다는 것에서 시작해, 모델과 하네스, MCP, 스킬을 배우고 내가 쓸 스킬을 하나 만들었다.

1. 오늘 배운 것

지금까지 나는 AI에게 “이런 화면 만들어 줘”, “이 데이터 저장하게 해 줘”라고 시켜 왔다. 그런데 그 도구가 정확히 뭔지, 어떻게 하면 더 강하게 부릴 수 있는지는 아직 몰랐다. 오늘이 그 시간이었다.

순서 무엇에 답하는가
에이전트란 내가 써 온 도구는 정확히 무엇인가
모델 + 하네스 그 도구는 무엇으로 이루어져 있나
루프 어떻게 “스스로” 일하는가
MCP AI를 내 데이터에 어떻게 잇나
스킬 · 규칙 같은 설명을 반복하지 않으려면
하네스 고르기 쏟아지는 도구 중에 무엇을 쓰나

1-1. 에이전트란? 그럼 챗봇은 에이전트인가?

에이전트를 한 문장으로 줄이면 — 목표를 주면 필요한 도구를 골라 쓰고, 결과를 보며 다음 수를 정하기를 끝까지 반복하는 AI다.

내가 하는 건 “이렇게 저렇게 클릭해”가 아니라 “로그인 기능을 붙여 줘”처럼 목표를 주는 것뿐이고, 세부 단계는 AI가 알아서 짠다. 그리고 말로만 답하지 않는다. 파일을 고치고, 명령을 실행하고, 검색하며 실제로 움직인다.

그럼 챗봇은 에이전트인가? 칼로 자르듯 나뉘지 않고 정도의 차이였다.

  어시스턴트 (챗봇) 에이전트
하는 일 질문에 답, 다음 줄 추천 여러 파일 수정 · 명령 실행 · 반복
단계를 정하는 주체 사람 AI가 스스로
도구 사용 거의 없음 (텍스트 위주) 파일 · 터미널 · 검색 등
비유 곁에서 거드는 조수 일을 맡아 끝내는 일꾼

가르는 기준은 “스스로 단계를 정하고 도구까지 써서 일을 끝내느냐”다. 그래서 순수한 챗봇은 에이전트가 아니지만, 도구를 쓰고 반복하기 시작하면 그때부터 에이전트가 된다.

말 자체는 새롭지 않았다. 부동산 에이전트, 여행사 에이전트처럼 “나 대신 뛰어서 일을 처리해 주는 이”를 뜻하는 오래된 단어고, 어원도 라틴어 “행하다(agere)”다. AI 교과서의 고전(러셀·노빅, 1995)은 인공지능이라는 학문을 아예 “주변을 살펴보고 목표를 위해 스스로 행동하는 존재, 즉 에이전트를 연구하는 일”이라고 정의했을 정도다. 달라진 건 그 ‘머리’ 역할을 이제 LLM이 맡는다는 것뿐이다.

1-2. 하네스는 무엇인가

오늘 가장 알고 싶었던 게 이거였다. 공식은 이렇다.

에이전트 = 모델(model) + 하네스(harness)

  • 모델 — 언어·코드·이미지를 다루는 지능. Claude, GPT 같은 것
  • 하네스 — 그 지능을 감싸서 실제 일을 하게 만드는 실행 환경

하네스에 들어가는 것은 “읽고 → 고치고 → 실행하고 → 다시 반복”하는 루프, 파일 접근, 터미널, 안전장치 같은 것들이다. harness가 원래 말에 씌우는 마구를 뜻하는데, 딱 그 그림이다. 말(모델)의 힘을 붙들어 방향을 잡는 장비.

트랜스포머와 하네스의 관계도 여기서 정리됐다. 트랜스포머는 모델 쪽의 이야기다. 지금 쓰는 LLM들이 공통으로 쓰는 신경망 구조이고, 하네스와는 층이 다르다. 말하자면 트랜스포머는 엔진의 설계 방식이고, 하네스는 그 엔진을 얹어 실제로 굴러가게 만든 차체와 조향 장치다. 엔진이 좋아도 차체가 없으면 아무 데도 못 간다.

그래서 이 문장이 오늘의 핵심이었다.

같은 모델이라도 하네스의 도구 권한·검증·사용 흐름에 따라 결과가 크게 달라진다. 그러니 “모델이 다 비슷하다”고 단정하기보다, 내 작업에서 어떤 하네스가 모델을 안전하고 확인 가능하게 움직이는가를 비교해야 한다.

1-3. 어떻게 “스스로” 일하나 — 루프

챗봇과 에이전트의 결정적 차이는 반복(루프)이었다.

계획(Plan) → 실행(Act) → 관찰(Observe) → 반성(Reflect) → 다시 계획

이 네 단계를 목표를 이룰 때까지 반복한다. 이 발상을 연구자들은 ReAct(Reasoning + Acting)라고 부른다.

왜 한 번에 답하는 것보다 나을까. 계획은 파일의 실제 내용이나 명령의 오류를 모른 채 세운 추측일 수 있기 때문이다. “로그인이 안 된다”면 에이전트는 곧바로 코드를 고치지 않고, 먼저 오류 로그를 읽고(실행) → 401인지 환경변수 누락인지 확인하고(관찰) → 그 뒤에야 수정 방법을 고른다(계획). 추측을 검증 가능한 증거로 교체하는 것이 루프의 값어치다.

사실 새로운 발상도 아니었다. 품질관리의 PDCA, 공군 전략의 OODA 루프가 다 같은 모양이다. “계획하고, 해 보고, 결과를 보고, 고친다.” 에이전트는 이 오래된 지혜를 기계 속도로 돌리는 것이다.

그래서 좋은 지시는 “고쳐 줘”에서 끝나지 않는다. “먼저 관련 파일과 오류를 확인하고, 수정 뒤에는 테스트를 실행해 결과를 보고해 줘”처럼 관찰 지점을 요구하는 것이다.

곁가지 — 2023년 봄의 소동. “목표 한 줄만 주면 알아서 끝까지 해내는” AutoGPT가 화제가 되며 이 단어가 대중에게 퍼졌다. 그런데 돌려 보니 언제 멈춰야 할지 몰라 같은 일을 무한 반복하고, 엉뚱한 방향으로도 계속 호출해 요금이 커졌다. 그래서 오늘의 에이전트는 “완전 자율”보다 작은 작업 단위 · 명확한 권한 · 중간 확인을 더 중요하게 본다.

1-4. MCP — AI를 내 데이터에 꽂는 USB-C

아무리 똑똑한 AI도 기본적으로는 자기가 학습한 것만 안다. 내 DB, 내 파일, 우리 회사 문서는 모른다.

그때그때 복사해 붙여넣을 수도 있지만, 연결할 도구가 많아지면 “AI 3개 × 도구 5개 = 연결 15개”를 일일이 만들어야 하는 지옥이 된다. 이걸 M×N 문제라고 한다.

MCP(Model Context Protocol)는 이걸 푸는 표준 규격이다. 규격 하나만 맞추면 M+N개의 구현으로 줄어든다.

이름만 알아 두면 되는 세 가지를 건네준다.

  • 도구(Tools) — AI가 실행하는 기능 (검색하기, DB 조회하기)
  • 자원(Resources) — AI가 읽어 들이는 데이터 (파일, 문서, 기록)
  • 프롬프트(Prompts) — 미리 만들어 둔 요청 템플릿

흥미로운 건 경쟁사들이 같은 규격에 손을 얹었다는 점이다. Anthropic이 2024년 11월에 공개했는데 OpenAI와 구글이 잇따라 채택했고, 나중에는 여러 회사가 함께 관리하는 중립 재단으로 넘어갔다. 그래서 이건 특정 회사 기능이 아니라 업계 공용 약속이다 — 한 번 익히면 도구가 바뀌어도 계속 쓸 수 있다.

그런데 요즘 치명적인 단점이 지적된다. MCP는 편하지만 공짜가 아니다. 연결해 두면 AI가 그 도구 설명서를 미리 통째로 읽어 둔다. 서버 몇 개만 붙여도 대화를 시작하기도 전에 수만 토큰이 날아간다. 느려지고, 토큰을 많이 먹는다.

한 벤치마크에서는 같은 일을 하는 데 CLI가 약 1천 토큰, MCP가 약 4만 토큰을 썼다고 한다. 그래서 2026년 들어 반작용이 생겼다 — 무거운 MCP 서버 대신, AI가 원래 알고 있는 명령줄 도구(CLI)를 그냥 쓰게 하자는 흐름이다. GitHub 작업이라면 MCP 서버를 세우는 대신 gh 명령을 시키면 된다.

다만 “MCP는 무거우니 무조건 피하라”는 결론은 아니었다.

  • 도구 쪽에서도 이미 손보고 있다 — 연결된 MCP 도구를 처음부터 다 읽지 않고 필요할 때 검색해 불러오는 방식이 기본이 되어 가는 중
  • 여럿이 같이 쓰고 접근 권한·기록이 중요한 회사 환경에서는 MCP의 표준화된 관리가 여전히 강하다

정리하면 이렇다. 혼자 작은 걸 만들 땐 “이미 있는 CLI + 짧은 스킬”이 가볍고, 여럿이 쓰고 권한을 챙겨야 하면 MCP.

그리고 하나 더. MCP는 연결 규칙이지 안전 보장이 아니다. 플러그 모양이 같다고 모든 기기가 같은 권한을 갖는 건 아닌 것처럼. 공개된 MCP 서버는 수천 개로 급증했고 검증 안 된 것도 많으니, 회사가 직접 낸 공식 서버 위주로 시작하고 읽기 도구부터 연결하는 게 맞다.

1-5. 스킬 — 반복하는 일을 AI에게 외워 두기

AI에게 “우리 브랜드 톤으로 정리해 줘”를 매번 처음부터 설명하고 있다면, 지겹고 그때그때 결과도 달라진다. 이걸 재프롬프트 문제라고 한다.

스킬은 자주 하는 작업을 한 번 적어 두고 계속 꺼내 쓰는 설명서다. 기술적으로는 그냥 폴더 하나이고, 그 안의 SKILL.md에 “무엇을, 언제 쓰는지”를 적어 두면 AI가 관련된 일을 만났을 때 알아서 꺼내 쓴다.

파일 구조가 인상적이었다. 대시 세 개(---)로 나뉜다.

---
name: tone-polish
description: 사용자용 안내 문구를 우리 서비스 말투로 다듬을 때 사용
---

# 우리 서비스 말투로 다듬기

1. 한 문장은 40자 이내로 끊는다.
2. "~해야 합니다"보다 "~해 주세요"처럼 부탁형으로 쓴다.

위쪽 머리말이 이름과 설명, 아래쪽이 실제 지시다. 그리고 AI는 머리말을 우선적으로 읽는다. 평소에는 name과 description만(30~50 토큰 수준) 훑고 있다가, 지금 하는 일이 그 설명과 맞을 때만 본문 전체를 읽어 온다.

이걸 점진 공개(progressive disclosure)라고 부른다. 그래서 스킬을 수십 개 켜 둬도 평소엔 거의 공짜이고, 느려지지 않는다. 규칙에 맞춰 쓰면 토큰이 적게 드는 이유가 이 구조다.

여기서 자연스럽게 따라오는 결론이 있다. description을 잘 쓰는 것이 스킬의 절반이다. AI가 이 한 줄만 보고 “지금 이 스킬을 꺼낼까”를 판단하니까. 여기가 부실하면 스킬이 있어도 발동하지 않는다.

1-6. 헷갈리지 않기 — MCP · 스킬 · 규칙

셋이 비슷해 보이지만 역할이 다르다. 이 결정 규칙이면 충분했다.

내가 원하는 것 무엇을 쓰나
AI에게 새 능력·연결을 주고 싶다 (내 DB·도구에 붙이기) MCP
AI가 항상 이런 식으로 행동하게 하고 싶다 규칙 파일 (CLAUDE.md · AGENTS.md)
반복하는 다단계 작업을 자동화하고 싶다 스킬

한 문장으로 — 스킬은 선반에서 꺼내 쓰는 방법서, 규칙은 프로젝트의 상시 안내문, MCP는 도구를 꽂는 어댑터다. 경쟁이 아니라 함께 쓴다.

규칙 파일은 공식 설명이 재미있었다. “에이전트를 위한 README”라고 부른다. 여기에 적으면 좋은 것은 프로젝트 개요, 자주 쓰는 명령, 규칙·컨벤션, 그리고 “이 폴더는 건드리지 마” 같은 하지 말 것.

1-7. 어떤 도구를 고를까 — 하네스의 네 부류

하네스는 종류가 아주 많지만, 어디서 돌아가고 내가 얼마나 지켜보느냐로 크게 네 부류다.

부류 성격 예
터미널/CLI형 깊고 강력하지만 낯설다 Claude Code, Codex CLI, Aider
편집기(IDE)형 변경을 눈으로 보며 승인·취소 Cursor, Cline
브라우저형 문턱이 가장 낮다 (배포까지 한 번에) Lovable, Bolt, Replit
클라우드/비동기형 통째로 맡기고 결과만 검토 Devin, Jules

고르는 기준은 프레임워크 고를 때와 같았다 — 정답이 아니라 내 조건. 모델을 고를 수 있나, 비용 구조는 어떤가, 오픈소스인가, 터미널이 편한가, 맡길까 지켜볼까.

그리고 도구 이름을 외우는 건 의미가 적다는 게 결론이었다. 이름·가격·회사가 짧은 기간에도 바뀐다. 대신 에이전트 = 모델 + 하네스, MCP(연결), 스킬(반복 자동화) 이 개념을 잡아 두면, 새 도구가 나와도 “이건 하네스가 이렇구나, MCP 되나?”로 빠르게 판단할 수 있다.

권한 이야기도 새겨야 했다. 에이전트는 실제로 파일을 지우고 명령을 실행할 수 있는 존재다. 그래서 좋은 도구는 위험한 행동 전에 묻는다. 문제는 이게 반복되면 사람이 무심코 “예”만 누르게 된다는 점이다. 실제로 사용자들이 권한 요청의 약 93%를 그냥 승인한다는 조사가 있다고 한다.

안전 습관 세 가지.

  1. 중요한 폴더에서 자동 수락을 켜지 말 것
  2. 되돌릴 지점을 먼저 만들 것 (위험한 작업 전 커밋)
  3. “아무것도 안 물어봄”과 “중요한 것에 대한 전체 접근”을 동시에 켜지 말 것

5회차의 “AI 코드의 45%에 보안 결함”과 통하는 이야기다. 편함과 위험은 같이 온다.

왜 필요한가

내가 지금 하는 일을 돌아보면, 세부 작업 내용을 이해하지 못한 채 요구사항만 전달하고 있다. 그런데 오늘 배운 것은 그 요구사항을 더 정확히, 덜 반복해서 전달하는 방법이었다.

  • 같은 설명을 매번 하지 않으려면 → 규칙 파일
  • 반복하는 작업을 고정하려면 → 스킬
  • 내 데이터를 보고 답하게 하려면 → MCP 또는 CLI

이 셋을 갖추면 범용 AI가 내 서비스를 아는 전용 조수로 바뀐다. 단, 조수에게 권한을 준다고 검토 책임까지 넘기는 것은 아니다.

2. 실습 / 코드

지난 과제 완료 — Todo 앱

지난 회차의 과제였던 Todo 앱을 로컬에서 쓸 수 있게 만들었다. 데이터가 내 컴퓨터 파일에 저장되어 껐다 켜도 남는다.

솔직히 적어 두면, 세부 작업 내용은 이해하지 못한 상태다. AI와 대화하며 내가 원하는 요구사항만 전달하고 있고, 그 사이에 오가는 용어와 결정은 대부분 흘려보냈다. 그게 오늘 만든 스킬로 이어졌다.

과제 — 내가 실제로 쓸 스킬 하나 만들기

과제는 AI에게 자주 반복해서 시키던 일을 스킬 하나로 만들어 GitHub에 올리는 것이었다.

내가 만든 것은 AI 에이전트 분야의 용어를 설명해 주는 가이드 스킬이다.

왜 이걸 골랐나. 수업 중이든 작업 중이든 모르는 용어가 난무했다. 스키마, MCP, 하네스, 컨텍스트 윈도우… 문서 한 문단 읽는 데 검색을 세 번 하게 된다.

그런데 검색해서 나온 설명도 이해가 안 됐다.

스키마: 데이터베이스의 구조와 제약 조건에 관한 전반적인 명세를 기술한 메타데이터의 집합

이 문장을 이해하려면 “명세”와 “메타데이터”를 또 검색해야 한다. 어려운 말을 다른 어려운 말로 바꿔놓은 설명은 설명이 아니다.

AI에게 물어보면 훨씬 나았지만, 거기에도 불편이 셋 있었다.

  1. 매번 같은 요청을 다시 타이핑한다 — “쉽게 설명해줘. 비유도 들고. 예시도 하나. 근데 나 지금 AI 에이전트 공부 중이니까 그쪽 의미로 먼저.” 단어 하나 물어볼 때마다 이 문장을 반복했다
  2. 답변 형식이 매번 다르다 — 어떤 날은 정의만 길게, 어떤 날은 코드만 잔뜩. 나중에 다시 읽을 때 원하는 부분을 찾기 어렵고 용어끼리 비교도 안 된다
  3. 엉뚱한 분야로 튄다 — “스키마”를 물으면 심리학 이야기가, “하네스”를 물으면 등산 장비 이야기가 먼저 나온다

그래서 출력 구조를 5단계로 고정했다. 단어 하나만 던지면 항상 이 순서로 돌아온다.

단계 내용 없앤 불편
1. 한 줄 정의 초등학생도 통하는 한 문장 어려운 말을 어려운 말로 바꾸지 않음
2. 비유로 이해하기 저금통·충전기·식당 주문 같은 익숙한 것에 빗대기 감이 안 잡히던 개념에 손잡이가 생김
3. AI 에이전트 분야에서는 실제 쓰임과 필요한 이유 (가장 길게) 엉뚱한 분야로 튀지 않음
4. 예시 한국어 주석이 달린 코드나 실행 흐름 추상적인 설명이 손에 잡힘
5. 다른 분야에서는 다른 뜻은 마지막에 2~3줄만 알아두되 헷갈리지 않게

description을 길게 쓴 이유도 오늘 배운 것에서 나왔다. AI는 머리말만 보고 스킬을 꺼낼지 판단하니, “사용자가 단어만 적어 보내도 설명 요청으로 간주한다”까지 적어 두었다. 그러지 않으면 “스키마”라고만 보냈을 때 스킬이 발동하지 않고 되묻는다. 스킬 본문에도 “단어만 왔다고 되묻지 말 것 — 되물으면 공부 흐름이 끊긴다”를 명시했다.

가장 만족스러운 건 다른 부분이었다. 용어를 하나씩 따로 배우면 지식이 조각난다. 그래서 같은 대화에서 앞서 설명한 용어를 기억해 새 용어와 이어 붙이도록 했다. 다섯 번째 용어쯤 되면 낱개 단어 다섯 개가 아니라 지도 한 장이 남는다. 6회차의 스키마·SQLite와 7회차의 하네스·MCP가 한 그림에서 맞물리는 것이다.

그리고 이걸 만들면서 든 생각. 이 스킬의 출력이 그대로 블로그 용어 사전에 쓸 수 있다. 공부하다 막힌 단어를 설명받고, 그 결과를 다듬어 용어 글로 올리면 된다. 배우는 것과 남기는 것이 한 흐름이 되니 더 좋다.

앞으로 만드는 스킬도 같은 저장소에 계속 쌓을 생각이다.

스킬의 자세한 내용과 실제 출력 예시는 작업물 글에서 따로 정리한다.

3. 그림 / 스크린샷

에이전트는 모델을 하네스가 감싼 구조이며 계획 실행 관찰 반성 루프를 반복한다
그림 1. 에이전트 = 모델 + 하네스, 그리고 그 하네스가 돌리는 루프
표준이 없으면 연결이 M곱하기N개가 되지만 MCP를 따르면 M더하기N개로 줄어드는 구조
그림 2. MCP — 연결 하나를 다시 만들지 않기
SKILL.md의 머리말과 본문 구조, 평소에는 머리말만 읽고 필요할 때만 본문을 펼치는 점진 공개
그림 3. 대시 세 개로 나뉜 SKILL.md, 그리고 점진 공개
내가 만든 용어 설명 스킬의 5단계 고정 출력과 용어가 쌓이면 지도가 되는 구조
그림 4. 내가 만든 스킬 — 단어 하나에서 지도 한 장까지

4. 막혔던 점과 해결

막힌 지점 궁금했던 이유 정리한 답
챗봇은 에이전트인가? 둘 다 AI와 대화하는 건 같아 보였다 정도의 차이다. 가르는 기준은 “스스로 단계를 정하고 도구까지 써서 일을 끝내느냐”. 순수한 챗봇은 아니지만, 도구를 쓰고 결과를 보며 반복하기 시작하면 그때부터 에이전트다
하네스가 정확히 무엇인가? “모델 + 하네스”라는 말은 들었지만 하네스가 실체 없이 느껴졌다 지능을 감싸 실제로 일하게 만드는 실행 환경. 루프, 파일 접근, 터미널, 권한 승인이 다 여기 들어간다. 원래 뜻이 말에 씌우는 마구인데, 힘을 붙들어 방향을 잡는다는 점에서 정확한 비유다
트랜스포머와 하네스는 무슨 관계인가? 둘 다 AI 구조 이야기라 같은 층인 줄 알았다 층이 다르다. 트랜스포머는 모델 쪽의 신경망 구조이고, 하네스는 그 모델을 감싸는 바깥이다. 트랜스포머가 엔진 설계 방식이라면 하네스는 그 엔진을 얹은 차체와 조향 장치다
MCP가 표준이라면 왜 안 쓰는 흐름이 생기나? 편하고 표준이면 계속 쓰면 될 것 같았다 연결해 두면 설명서를 미리 통째로 읽어 두기 때문이다. 느려지고 토큰을 많이 먹는다. 그래서 혼자 작은 걸 만들 땐 CLI + 짧은 스킬이 가볍고, 여럿이 쓰고 권한·기록을 챙겨야 하면 MCP다. 그리고 도구 쪽에서도 필요할 때만 불러오는 방식으로 이 부담을 덜고 있다
스킬을 많이 켜 두면 느려지지 않나? 지시문이 쌓이면 당연히 무거워질 줄 알았다 점진 공개 때문에 그렇지 않다. 평소엔 머리말(이름·설명)만 읽고, 지금 일과 맞을 때만 본문을 펼친다. 대신 description이 부실하면 스킬이 있어도 발동하지 않는다

5. 스스로 확인하기

  • 어시스턴트와 에이전트를 가르는 기준 한 문장을 말할 수 있는가?
  • 하네스가 무엇이고, 왜 같은 모델이라도 결과가 달라지는지 설명할 수 있는가?
  • 트랜스포머와 하네스가 어떻게 다른 층인지 말할 수 있는가?
  • 루프의 네 단계를 순서대로 말하고, 왜 한 번에 답하는 것보다 나은지 설명할 수 있는가?
  • M×N 문제가 무엇이고 MCP가 그걸 어떻게 푸는지 설명할 수 있는가?
  • MCP의 단점과, 그럼에도 MCP를 쓰는 상황을 각각 말할 수 있는가?
  • SKILL.md의 구조와 점진 공개를 설명할 수 있는가?
  • MCP · 스킬 · 규칙 중 무엇을 쓸지 세 갈래로 판단할 수 있는가?
  • 에이전트에게 권한을 줄 때의 안전 습관 세 가지를 말할 수 있는가?

6. 더 알아볼 것

  • 만든 스킬을 실제로 며칠 써 보고 description을 다듬기 — 안 발동하는 경우를 찾아 고치기
  • 스킬 출력을 다듬어 블로그 용어 사전 글로 옮기기 (첫 후보: 하네스 · MCP · 스키마)
  • Todo 앱에 CLI를 붙이고 규칙 파일에 사용법을 적어 AI가 직접 데이터를 읽게 해 보기
  • 규칙 파일(CLAUDE.md)을 실제로 만들어 두고, 새 대화에서 자동으로 읽히는지 확인
  • 읽기 전용 MCP 서버 하나만 붙여 보고, CLI 방식과 체감 차이 비교
  • 지난 회차부터 밀린 숙제: PowerShell 기초, 비동기를 코드로 확인하기

참고 자료