들어가며
AI 에이전트로 업무를 자동화하고 싶다는 요구가 늘고 있다. 하지만 막상 시작하려면 용어부터 헷갈린다. 에이전트, MCP, 스킬, 워크플로우… 이것들이 어떤 관계인지, 실제로 뭘 만들어야 하는지 명확하지 않다.
더 혼란스러운 건 도구 선택이다. Claude Code를 쓸지, n8n 같은 워크플로우 도구를 쓸지, 아니면 직접 개발할지. 각각 뭐가 다르고 언제 뭘 써야 할까?
이 글에서는 AI 자동화를 구축할 때 알아야 할 핵심 개념들의 관계와 환경별 개발 전략, 그리고 도구 선택 기준을 정리했다.
핵심 개념 정리
에이전트 (Agent)
에이전트는 자율적으로 작업을 수행하는 AI 시스템이다. 단순히 질문에 답하는 것이 아니라, 목표를 이해하고 계획을 세우고 도구를 사용해 작업을 완료한다.
에이전트의 핵심은 오케스트레이션이다. “다음에 뭘 할지 판단하고, 도구를 호출하고, 결과를 보고 다시 판단하는” 루프를 실행하는 것이 에이전트의 본질이다.
MCP (Model Context Protocol)
MCP는 에이전트가 외부 서비스와 소통하는 표준 프로토콜이다. Jira, Slack, Notion, GitHub 등 외부 시스템과 연동할 때 사용한다.
MCP = 외부 서비스와 연결하는 "표준 플러그"
스킬 (Skill)
스킬은 특정 작업을 잘 수행하기 위한 지침서다. 문서 작성, 코드 리뷰, 데이터 분석 등 각 작업 유형별 베스트 프랙티스가 담긴다.
스킬 = 작업별 "레시피북"
워크플로우 (Workflow)
워크플로우는 MCP와 스킬을 조합해 특정 목표를 달성하는 실행 흐름이다.
워크플로우 = MCP + 스킬의 조합 + 실행 순서
개념들의 관계
┌─────────────────────────────────────────────────────┐
│ 에이전트 │
│ (오케스트레이션 담당) │
│ │
│ ┌───────────────────────────────────────────┐ │
│ │ 워크플로우 │ │
│ │ (실행 흐름 + 조합 로직) │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ MCP │ │ 스킬 │ │ │
│ │ │ (외부 연결) │ │ (노하우) │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ └───────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
| 계층 | 역할 | 비유 |
|---|---|---|
| 에이전트 | 판단하고 실행 지시 | 요리사 |
| 워크플로우 | 실행 순서와 조건 | 조리 순서 |
| MCP | 외부 도구 연결 | 주방 기기 |
| 스킬 | 작업 노하우 | 레시피 |
환경별로 만들어야 할 것
중요한 점은 환경에 따라 만들어야 할 것이 다르다는 것이다.
Claude Code 환경
Claude Code는 그 자체가 이미 에이전트다. 오케스트레이션, 기본 도구, 메모리가 모두 내장되어 있다.
┌─────────────────────────────────────┐
│ Claude Code (에이전트) │
│ │
│ ✅ 오케스트레이션 - 내장 │
│ ✅ 기본 도구 - 내장 │
│ ✅ 메모리 - 내장 │
│ │
│ ⚠️ MCP - 필요시 추가 │
│ ⚠️ 스킬 - 필요시 작성 │
└─────────────────────────────────────┘
만들어야 할 것: MCP + 스킬만 추가하면 됨
n8n + Claude 환경
n8n에 Claude API 노드와 MCP 서버 노드가 추가되면서, n8n 자체가 에이전트 프레임워크 역할을 할 수 있게 되었다.
┌─────────────────────────────────────┐
│ n8n (오케스트레이션) │
│ │
│ ├── Claude API 노드 (판단/추론) │
│ ├── MCP 서버 노드 (외부 연동) │
│ └── 기타 노드들 (로직, 분기 등) │
└─────────────────────────────────────┘
만들어야 할 것: n8n 워크플로우 설계 + MCP 서버 + (필요시) 프롬프트
직접 개발 환경 (Python, Node 등)
프레임워크 없이 직접 개발하면 모든 것을 만들어야 한다.
┌─────────────────────────────────────┐
│ 직접 개발 │
│ │
│ 🔨 오케스트레이션 - 직접 구현 │
│ 🔨 도구 호출 로직 - 직접 구현 │
│ 🔨 에러 처리 - 직접 구현 │
│ 🔨 MCP 연동 - 직접 구현 │
│ 🔨 스킬/프롬프트 - 직접 작성 │
└─────────────────────────────────────┘
만들어야 할 것: 전부 다
환경별 비교
| 환경 | 오케스트레이션 | MCP | 스킬 | 난이도 |
|---|---|---|---|---|
| Claude Code | 제공됨 | 추가 | 추가 | 낮음 |
| n8n + Claude | n8n이 담당 | 추가 | 프롬프트 | 중간 |
| 직접 개발 | 직접 구현 | 직접 구현 | 직접 작성 | 높음 |
Claude Code vs n8n + Claude: 무엇이 다른가?
둘 다 AI 에이전트를 구축할 수 있다. 핵심 차이는 오케스트레이션을 누가 하느냐다.
Claude Code
사용자 요청
↓
Claude가 상황 판단
↓
Claude가 도구 선택
↓
실행
↓
Claude가 결과 보고 다음 행동 결정
↓
반복 또는 완료
- LLM이 매 순간 판단
- 자연어로 제어
- 흐름이 유동적
n8n + Claude
트리거 발생
↓
n8n이 정해진 순서대로 실행
↓
판단 필요한 노드에서 Claude API 호출
↓
결과 받아서 다음 노드로
↓
정해진 흐름대로 완료
- n8n이 흐름 제어
- GUI로 설계
- 흐름이 시각화됨
비교표
| 구분 | Claude Code | n8n + Claude |
|---|---|---|
| 오케스트레이션 | Claude가 알아서 | n8n이 명시적으로 |
| 흐름 제어 | 자연어 기반 | GUI로 시각화 |
| 판단 주체 | 매 순간 LLM | 설계된 지점에서만 LLM |
| 디버깅 | 어려움 | 쉬움 (노드별 확인) |
| 유연성 | 높음 | 중간 (설계한 만큼) |
| 예측 가능성 | 낮음 | 높음 |
| 진입 장벽 | 낮음 | 중간 |
| 비개발자 수정 | 어려움 | 가능 |
선택 기준
| 상황 | 추천 |
|---|---|
| 흐름이 매번 다르고 판단 필요 | Claude Code |
| 흐름이 고정되고 반복적 | n8n + Claude |
| 빠른 프로토타이핑 | Claude Code |
| 팀에서 시각적으로 관리 | n8n + Claude |
| 비개발자도 수정 가능해야 함 | n8n + Claude |
| 복잡한 예외 처리 필요 | Claude Code |
| 실행 이력 추적 중요 | n8n + Claude |
혼합 사용
둘 중 하나만 써야 하는 건 아니다.
n8n (정형화된 흐름)
├── 트리거: 매일 9시
├── 노드1: 데이터 수집
├── 노드2: Claude API (분석 및 판단) ← 판단이 필요한 부분만
├── 노드3: 결과에 따라 분기
└── 노드4: Slack 알림
정형화된 흐름은 n8n이 처리하고, 판단이 필요한 부분만 Claude를 호출하는 방식이 효율적일 수 있다.
개발 방법론: 탑다운과 바텀업
AI 자동화를 구축할 때는 탑다운과 바텀업을 조합하는 것이 효과적이다.
탑다운 (Top-Down): 기획 단계
전체 그림을 먼저 그리는 방식이다.
장점
- 전체 구조를 먼저 파악할 수 있음
- 도메인 지식을 체계적으로 정리
- 팀원 간 커뮤니케이션 수월
- 누락된 요구사항 조기 발견
- 우선순위 결정에 유리
활용 시점
- 프로젝트 초기 기획
- 어떤 MCP/스킬이 필요한지 식별
- 워크플로우 전체 흐름 설계
바텀업 (Bottom-Up): 구현 단계
작은 단위부터 만들어 올라가는 방식이다.
장점
- 빠른 검증 가능
- 실패 비용 적음
- LLM의 예측 불가능성에 대응
- 점진적 개선 가능
- 실제 동작하는 결과물을 빨리 볼 수 있음
활용 시점
- MCP 개별 구현 및 테스트
- 스킬 작성 및 검증
- 워크플로우 조합 및 반복 개선
조합 전략
┌─────────────────────────────────────────────┐
│ 탑다운 (기획) │
│ │
│ 1. 해결할 문제 정의 │
│ 2. 구체적 시나리오 도출 │
│ 3. 필요한 MCP/스킬 목록 식별 │
│ 4. 전체 워크플로우 설계 │
│ 5. 우선순위 결정 │
└─────────────────┬───────────────────────────┘
↓
┌─────────────────────────────────────────────┐
│ 바텀업 (구현) │
│ │
│ 1. MCP 하나씩 개발 + 단독 테스트 │
│ 2. 스킬 작성 + 검증 │
│ 3. 워크플로우 조합 │
│ 4. 통합 테스트 │
│ 5. 관찰 → 개선 → 반복 │
└─────────────────────────────────────────────┘
MCP/스킬 설계 원칙: 재사용성
MCP와 스킬은 재사용 가능하게 설계해야 한다. 워크플로우는 언제든 바뀔 수 있지만, 잘 만든 MCP/스킬은 여러 곳에서 활용할 수 있다.
나쁜 예: 특정 시나리오에 종속
MCP: "PR 머지되면 Jira Done으로 바꾸기"
- 하나의 워크플로우에만 사용 가능
- 시나리오 바뀌면 버려야 함
좋은 예: 범용적 설계
MCP 1: "Jira 이슈 상태 변경" (상태값은 파라미터)
MCP 2: "GitHub PR 상태 조회" (PR 번호는 파라미터)
- 여러 워크플로우에서 조합 가능
- 다른 시나리오에도 재활용
설계 원칙
| 원칙 | 설명 |
|---|---|
| 단일 책임 | 하나의 MCP = 하나의 기능 |
| 입출력 명확 | 범용적인 파라미터 설계 |
| 비즈니스 로직 배제 | 조합 방식은 MCP 밖에서 결정 |
설계 예시
Jira MCP
├── 이슈 조회 (issueKey) → 이슈 정보
├── 이슈 생성 (project, summary, type) → 새 이슈
├── 이슈 상태 변경 (issueKey, status) → 결과
└── 이슈 코멘트 추가 (issueKey, comment) → 결과
GitHub MCP
├── PR 조회 (repo, prNumber) → PR 정보
├── PR 목록 (repo, state) → PR 리스트
├── 브랜치 목록 (repo) → 브랜치 리스트
└── 커밋 히스토리 (repo, branch) → 커밋 리스트
이렇게 잘게 쪼개 놓으면 어떤 워크플로우든 조합해서 사용할 수 있다.
시나리오에서 도구 식별하기
“어떤 MCP나 스킬이 필요한지 모르겠다”는 흔한 고민이다. 해결책은 Use Case 기반 접근이다.
1단계: 구체적 시나리오 정의
❌ 추상적: "Jira 연동 자동화 만들자"
✅ 구체적: "PR이 머지되면 Jira 이슈를 Done으로 변경하고 Slack에 알림"
2단계: 수동으로 먼저 해보기
에이전트 없이 해당 작업을 직접 수행해 본다.
- 어떤 시스템에 접근하는가? → MCP 후보
- 어떤 데이터를 조회하는가? → MCP 기능
- 어떤 판단을 내리는가? → 스킬 또는 LLM 호출 지점
- 어떤 액션을 취하는가? → MCP 기능
3단계: 목록화 및 우선순위
필요한 MCP:
1. GitHub - PR 상태 조회 (필수)
2. Jira - 이슈 상태 변경 (필수)
3. Slack - 메시지 전송 (필수)
필요한 스킬:
1. PR 설명에서 Jira 이슈 키 추출 규칙
4단계: 개별 구현 + 테스트 + 조합
1. GitHub MCP 만들기 → 단독 테스트
2. Jira MCP 만들기 → 단독 테스트
3. Slack MCP 만들기 → 단독 테스트
4. 워크플로우로 연결 → 통합 테스트
정리
핵심 개념 관계
에이전트 > 워크플로우 > MCP/스킬
(오케스트레이션) (실행 흐름) (개별 기능)
환경별 개발 범위
| 환경 | 만들어야 할 것 |
|---|---|
| Claude Code | MCP + 스킬 |
| n8n + Claude | 워크플로우 + MCP + 프롬프트 |
| 직접 개발 | 전부 다 |
도구 선택 기준
| 상황 | 선택 |
|---|---|
| 유동적이고 판단 필요 | Claude Code |
| 정형화되고 시각적 관리 필요 | n8n + Claude |
| 둘 다 필요 | 혼합 사용 |
개발 방법론
기획 = 탑다운 (전체 그림)
구현 = 바텀업 (작게 시작, 점진적 확장)
설계 원칙
MCP/스킬 = 재사용 가능한 레고 블록
워크플로우 = 블록 조립