Prompt, Skill, MCP는 같은 자리를 두고 경쟁하지 않습니다. Prompt는 이번 요청의 목표와 맥락을 전달하고, Skill은 반복할 절차와 판단 기준을 묶으며, MCP는 호스트가 외부 서버의 도구·자료를 발견하고 호출하는 연결 규약입니다. 외부 시스템에 닿는 방법도 MCP만 있는 것은 아닙니다. 호스트가 승인한 CLI, SDK, 직접 HTTP API가 이미 있다면 그 경로로도 같은 데이터를 읽을 수 있습니다.
- 입력 확인사용자가 필요한 자료를 이미 제공했는지 먼저 봅니다.
- 반복 확인분류 기준과 출력 형식을 다음 작업에도 재사용할지 판단합니다.
- 연결 확인외부 최신 데이터가 필요하면 승인된 CLI·SDK·HTTP API·MCP 중 기존 경로를 확인합니다.
- 권한 제한읽기만 필요한 사례는 쓰기 도구와 외부 변경을 허용하지 않습니다.
먼저 답: 절차와 연결은 다른 축이다
Agent Skills 명세에서 Skill은 필수 SKILL.md와 선택적 scripts, references, assets로 구성됩니다. 본문 지침에는 단계, 입력·출력 예시, 예외를 담을 수 있고, 에이전트는 필요한 시점에 상세 자원을 읽습니다. 즉 Skill의 핵심은 재사용할 작업 방법입니다. allowed-tools 필드는 실험적이며 구현별 지원이 다르므로, Skill 파일을 둔 것만으로 외부 권한이 생겼다고 보면 안 됩니다. (Agent Skills 명세)
MCP 공식 아키텍처에서는 호스트가 클라이언트 연결, 권한과 수명주기, 사용자 승인 결정을 관리하고 서버가 tools, resources, prompts 같은 기능을 노출합니다. MCP는 연결 인터페이스를 표준화하지만 어떤 서버를 연결할지, 어떤 계정과 권한을 줄지, 호출 결과를 믿을지는 호스트와 사용자의 책임으로 남습니다. (MCP 아키텍처)
이 차이를 놓치면 “Skill이 있으니 GitHub 이슈를 읽을 수 있다”거나 “MCP를 연결했으니 분류 기준도 일관된다”는 잘못된 기대가 생깁니다. 전자는 별도 데이터 접근 권한이 필요하고, 후자는 반복 가능한 기준을 Prompt나 Skill로 명시해야 합니다.
같은 가상 이슈와 판정 기준
세 경로에는 아래 입력 하나만 사용합니다. 실제 사용자, 저장소, 장애를 가리키지 않는 가상 사례이며 어느 도구에도 전송하지 않았습니다.
가상 이슈 #482
제목: 결제 성공 알림 뒤 주문 내역이 비어 보임
환경: Windows 11, Chrome 140, 웹 앱 3.4.2
본문: 결제 성공 알림을 받은 뒤 주문 내역 화면이 빈 상태입니다.
새로고침 두 번 뒤 표시됐고 같은 현상 제보가 3건 있습니다.
첨부: 없음
출력: 유형(bug/question), 우선순위(P0-P3), 담당 영역, 근거,
누락 정보, 다음 행동
제약: 근거가 부족하면 잠정으로 표시하고 외부 시스템은 변경하지 않습니다.
공통 판정 기준도 고정합니다. 결제나 주문 데이터가 실제로 소실됐다는 증거는 없으므로 P0·P1로 단정하지 않습니다. 화면 표시가 지연된 잠정 bug, 우선순위 P2 후보, 주문 조회 영역, 재현 빈도·응답 코드·서버 로그가 추가로 필요하다는 형태가 문서 기반 예상 결과입니다. 세 방식의 차이는 이 결론을 더 그럴듯하게 꾸미는 데 있지 않고, 기준을 어디에 준비하고 어떤 권한으로 입력을 얻으며 다음 주에도 같은 절차를 반복할 수 있는가에 있습니다.
1. Prompt만 사용할 때
준비는 가장 적습니다. 위 이슈 본문과 판정 기준, 출력 형식을 한 Prompt에 함께 넣으면 됩니다. 사용자가 필요한 정보를 이미 제공했으므로 외부 저장소 연결이나 GitHub 권한이 필요하지 않습니다. 이 상황에서 MCP를 추가하면 분류에 쓰이지 않는 인증과 도구 선택 단계만 늘어납니다.
권한 경계도 단순합니다. Prompt 자체는 자격 증명이나 시스템 접근권을 부여하지 않습니다. 다만 호스트에 파일·셸·네트워크 도구가 이미 활성화돼 있다면 모델이 사용할 수 있으므로, 요청에 “외부 시스템을 변경하지 않는다”고 쓰는 것과 별도로 호스트 권한을 읽기 또는 거부로 제한해야 합니다.
반복성은 낮습니다. 다음 이슈에서도 같은 기준을 쓰려면 사용자가 Prompt 템플릿을 다시 붙여 넣고 누락 없이 갱신해야 합니다. 기준이 한두 번만 필요하거나 이슈 형식이 자주 바뀐다면 이 준비 비용이 가장 작습니다.
2. Skill로 반복할 때
Skill 경로에서는 이슈 입력은 그대로 두고, 유형·우선순위 기준과 출력 스키마, “근거 부족은 잠정”, “외부 변경 금지” 규칙을 SKILL.md에 옮깁니다. 매번 Prompt에는 이슈 사실만 전달하므로 분류 기준을 복사하는 수고가 줄어듭니다. Agent Skills 명세가 권장하는 단계·입출력 예시·예외 구조가 이 용도에 맞습니다. (Agent Skills 명세)
그러나 Skill은 계정 토큰이 아닙니다. 이 가상 이슈처럼 본문이 이미 입력에 들어오면 외부 권한 없이 분류할 수 있지만, “GitHub에서 #482를 가져와라”라고 바꾸면 호스트가 승인한 별도 연결이 필요합니다. Skill에 실행 스크립트가 포함돼도 호스트가 셸·네트워크 실행을 허용하지 않으면 외부 데이터를 읽을 수 없습니다.
반복성은 세 경로 중간입니다. 같은 버전의 Skill은 팀의 판정 순서와 출력 형식을 일정하게 유지하기 쉽지만, 모델의 판단이 항상 같다는 보장은 아닙니다. Skill 변경 이력과 예외 사례를 검토하고, 실제 라벨 적용은 사람 승인 뒤 별도 작업으로 남깁니다.
3. Skill과 MCP를 결합할 때
이 경로는 사용자가 이슈 본문을 복사하지 않고, 호스트가 승인한 읽기 전용 GitHub MCP 도구로 같은 #482의 제목·본문·현재 라벨을 가져온다는 가정입니다. Skill은 분류 기준과 출력 형식을 제공하고 MCP는 최신 이슈 데이터를 전달합니다. GitHub 원격 MCP 문서는 toolset별 URL과 read-only 경로를 설명하고, GitHub MCP 서버 구성 문서는 read-only 모드가 쓰기 도구를 제거하는 방식을 안내합니다.
준비 비용은 가장 큽니다. Skill 검토에 더해 서버 출처, OAuth 계정, 접근 가능한 저장소, 노출 도구, read-only 상태를 확인해야 합니다. “읽기 전용”은 라벨·댓글·이슈 수정 도구를 제거하는 경계이지, 계정이 읽을 수 있는 저장소 범위를 자동으로 줄이는 allowlist는 아닙니다.
반복성은 최신 이슈를 같은 절차로 분류해야 할 때 높아집니다. 다만 MCP 서버 상태, API 응답, 계정 권한, Skill 버전이 모두 결과에 영향을 줍니다. 연결 실패를 분류 실패로 숨기지 않고, 입력을 가져오지 못했으면 결과 대신 “조회 실패”를 반환하도록 절차를 정해야 합니다.
| 구분 | 역할 | 설명 | 예시 |
|---|---|---|---|
| Prompt | 준비: 입력과 기준을 한 번에 | 권한: 제공된 텍스트만 쓰면 외부 접근 없음. 반복성: 기준을 매번 다시 전달해야 합니다. | 가상 #482 본문과 판정 기준을 함께 붙여 넣기 |
| Skill | 준비: 기준을 SKILL.md로 분리 | 권한: Skill 자체는 자격 증명이 아님. 반복성: 같은 절차와 출력 형식을 재사용합니다. | 가상 #482만 입력하고 저장된 기준 적용 |
| Skill + MCP | 준비: 기준과 외부 연결을 모두 검토 | 권한: 호스트·OAuth·서버 도구 범위를 제한. 반복성: 최신 이슈 조회와 분류 순서를 함께 재사용합니다. | 읽기 전용 도구로 #482 조회 후 Skill 기준 적용 |
세 방식 모두 최종 라벨이나 댓글을 쓰지 않는 동일한 경계에서 비교했습니다. 쓰기까지 포함하면 준비·권한·실패 복구가 달라지므로 별도 설계가 필요합니다.
MCP 없이도 외부 시스템에 닿을 수 있다
외부 접근이 필요하다고 곧바로 MCP가 필요한 것은 아닙니다. 호스트가 특정 명령 실행을 승인했다면 GitHub CLI의 gh issue view로 이슈 제목과 본문을 JSON으로 읽을 수 있습니다. GitHub CLI 공식 문서는 --json 출력과 저장소 지정 옵션을 제공합니다. 아래 명령은 실행 기록이 아닌 문서 기반 예시입니다. (GitHub CLI gh issue view)
GitHub CLI를 설치하고 해당 저장소에 접근할 수 있는 계정으로 인증했다면 Windows PowerShell·macOS zsh·Linux bash에서 같은 명령을 사용합니다. OWNER/REPO와 이슈 번호는 조회할 대상으로 바꿉니다.
gh issue view 482 --repo OWNER/REPO --json title,body,labels
애플리케이션에 이미 GitHub 통합 코드가 있다면 Octokit SDK로 REST endpoint를 호출하거나, 승인된 HTTP 클라이언트로 GET /repos/{owner}/{repo}/issues/{issue_number}를 직접 요청할 수도 있습니다. GitHub REST 시작 문서는 CLI·curl·Octokit.js SDK 경로를 설명하고, Issues REST API는 이슈 조회 endpoint와 권한을 안내합니다. 어떤 경로든 필요한 토큰 권한, 저장소 접근, 응답 검증은 사라지지 않습니다.
MCP와 이 경로들의 차이는 “접근 가능/불가능”이 아닙니다. MCP는 호스트가 서버 기능을 발견하고 구조화된 도구 호출로 연결하는 공통 인터페이스를 제공합니다. CLI는 운영자가 승인한 명령과 출력 규약에, SDK는 애플리케이션 코드와 의존성에, 직접 HTTP는 endpoint·인증·오류 처리 구현에 책임이 놓입니다. 이미 안전하게 운영 중인 경로가 있다면 단지 MCP라는 이유로 교체할 필요는 없습니다.
MCP가 없어도 되는 경우
다음 조건이라면 Prompt나 Skill만으로 충분합니다.
- 이슈 본문처럼 필요한 자료가 입력에 이미 포함돼 있습니다.
- 외부 시스템의 최신 상태를 읽거나 바꿀 필요가 없습니다.
- 같은 분류가 반복돼도 사람이 입력을 제공하고 Skill은 판단 기준만 재사용합니다.
- 호스트가 승인한 읽기 전용 CLI·SDK·HTTP 통합이 이미 있고, 별도 MCP 서버를 운영할 이점이 작습니다.
반대로 여러 MCP 호스트에서 같은 외부 도구를 발견해야 하거나, resources와 tools를 공통 규약으로 노출해야 하거나, 연결 수명주기와 사용자 승인을 호스트에서 일관되게 관리하려면 MCP의 가치가 커집니다. MCP 공식 아키텍처는 호스트가 여러 클라이언트 연결과 권한을 관리하고 서버가 기능을 선언하는 구조를 설명합니다. (MCP 아키텍처)
반복 절차를 파일로 옮기기로 했다면 Agent Skill과 SKILL.md 작성법을, 외부 도구를 연결할 업무를 찾고 있다면 MCP의 SQL·브라우저·영상 작업 활용법을 이어서 살펴보세요.
어떤 경로를 선택할까
이번 가상 사례의 결론은 간단합니다. #482의 본문과 기준이 한 번만 주어졌다면 Prompt로 끝냅니다. 같은 분류 기준을 계속 쓴다면 Skill로 옮깁니다. 최신 GitHub 이슈를 반복해서 직접 읽어야 한다면 기존에 승인된 CLI·SDK·HTTP API가 있는지 먼저 보고, 여러 호스트에서 공통 도구 연결이 필요할 때 읽기 전용 MCP를 검토합니다.
선택 순서는 제공된 입력으로 해결 → 반복 기준만 Skill로 분리 → 기존 승인 연결 재사용 → 필요할 때 MCP 추가가 안전합니다. Skill은 품질 보증서가 아니고 MCP는 권한을 대신 설계하지 않습니다. 같은 입력과 같은 출력 축을 고정한 뒤, 준비 비용과 데이터 권한이 실제로 줄어드는 조합만 남기면 됩니다.
VIEW—
