10강에서 다룬 프로젝트 규칙은 “AI가 우리 프로젝트 안에서 어떤 방식으로 일해야 하는가”를 정하는 장치였습니다. 규칙이 코드 스타일, 폴더 구조, 네이밍, 금지 패턴을 잡아준다면, 11강의 핵심인 MCP와 Skills는 한 단계 더 나아갑니다. AI가 프로젝트 바깥의 도구와 데이터를 사용할 수 있게 만들고, 반복되는 작업 방식을 하나의 능력처럼 재사용하게 만드는 개념입니다.

바이브 코딩이 처음에는 “프롬프트를 잘 써서 코드를 생성하는 일”처럼 보일 수 있습니다. 하지만 실제 프로젝트가 커질수록 필요한 것은 단순 코드 생성이 아닙니다. 이슈를 확인하고, 데이터베이스 구조를 참고하고, 디자인 문서를 읽고, API 문서를 비교하고, 테스트 결과를 반영하고, 배포 환경까지 고려해야 합니다. MCP와 Skills가 중요해지는 이유가 여기에 있습니다.

1. MCP: AI를 외부 도구·데이터에 연결하기

MCP는 Model Context Protocol의 약자로, AI 도구가 외부 시스템과 연결되는 방식을 표준화하려는 프로토콜입니다. 쉽게 말하면 AI가 혼자 대화창 안에서만 추측하는 것이 아니라, 필요한 도구와 데이터에 접근해 더 정확하게 작업하도록 돕는 연결 방식입니다.

예를 들어 AI에게 “회원가입 오류 고쳐줘”라고 말했을 때, AI가 코드만 보고 추측하는 경우와 다음 정보를 함께 확인할 수 있는 경우는 결과가 크게 달라집니다.

- GitHub 이슈에 적힌 재현 방법

- 데이터베이스 테이블 구조

- 로그 수집 도구에 남은 에러 메시지

- Notion이나 문서 도구에 정리된 정책

- Figma에 있는 화면 구성

- 로컬 파일 시스템의 특정 문서

- 사내 API 문서나 OpenAPI 명세

MCP는 이런 외부 자원을 AI 도구가 일정한 방식으로 읽고 사용할 수 있게 해주는 연결층에 가깝습니다. AI에게 무작정 “우리 서비스 구조를 이해해”라고 말하는 대신, 필요한 자료가 있는 곳을 연결해 주는 방식입니다.

Claude Code, Cursor, ChatGPT, Codex 같은 도구들은 각자 외부 도구 연동 방식이 다르고, MCP 지원 범위도 시점과 플랜에 따라 달라질 수 있는 것으로 알려져 있습니다. 그래서 MCP를 도입할 때는 “이 도구가 MCP를 지원하는가”, “어떤 MCP 서버를 연결할 수 있는가”, “읽기만 가능한가, 쓰기 작업도 가능한가”를 먼저 확인해야 합니다.

중요한 점은 MCP가 AI를 더 똑똑하게 만드는 마법이 아니라는 것입니다. MCP는 AI가 참고할 수 있는 맥락과 도구를 넓혀주는 역할을 합니다. 연결된 데이터가 부정확하거나 권한이 과도하면 오히려 위험해질 수 있습니다.

2. Skills: 반복 작업을 능력으로 저장

Skills는 반복되는 작업 절차를 AI가 다시 사용할 수 있는 형태로 저장해 두는 개념입니다. 도구마다 이름과 구현 방식은 다를 수 있지만, 핵심은 비슷합니다. 매번 긴 설명을 새로 입력하지 않고, 특정 업무에 필요한 규칙, 절차, 참고 기준을 묶어 하나의 작업 능력처럼 사용하는 것입니다.

바이브 코딩에서 반복되는 작업은 생각보다 많습니다.

- 새 API 엔드포인트 만들기

- 기존 화면 스타일에 맞춰 컴포넌트 추가하기

- 버그 리포트 형식에 맞춰 원인 분석하기

- 테스트 케이스 작성하기

- PR 설명문 만들기

- 린트 오류 수정하기

- 기획서를 기준으로 화면 요구사항 분해하기

- 배포 전 체크리스트 점검하기

이런 작업을 매번 프롬프트로 길게 설명하면 누락이 생깁니다. “우리 프로젝트에서는 API 응답 형식을 이렇게 맞춰야 하고, 에러 처리는 이렇게 하고, 테스트는 이 폴더에 추가하고, 문서도 함께 고쳐야 해”라는 설명을 매번 반복해야 합니다.

Skills는 이 반복 설명을 줄여줍니다. 특정 작업을 수행할 때 필요한 절차와 기준을 미리 정리해 두면, AI가 그 패턴을 따라 더 일관되게 움직일 수 있습니다. 10강의 Cursor Rules가 프로젝트 전반의 규칙에 가깝다면, Skills는 특정 업무 단위의 실행 절차에 더 가깝다고 이해하면 쉽습니다.

예를 들어 “버그 수정 Skill”에는 다음과 같은 절차가 들어갈 수 있습니다.

- 먼저 재현 조건을 확인한다

- 관련 파일을 검색한다

- 원인 후보를 2개 이상 제시한다

- 수정 범위를 최소화한다

- 기존 테스트가 있으면 먼저 확인한다

- 수정 후 영향받는 기능을 적는다

- 사용자가 승인하기 전 대규모 리팩터링은 하지 않는다

이런 절차가 저장되어 있으면, AI가 버그 수정 요청을 받았을 때 곧바로 코드를 바꾸기보다 진단과 검수 흐름을 먼저 따르게 만들 수 있습니다.

3. 프로젝트별 능력 확장의 의미

바이브 코딩에서 가장 큰 변화는 “AI가 코드를 생성한다”에서 “AI가 프로젝트 맥락에 맞게 일한다”로 이동하는 데 있습니다. 초반에는 ChatGPT에 기획을 물어보고, Cursor에서 코드를 고치고, Claude Code나 Codex로 큰 작업을 맡기는 것만으로도 충분해 보입니다. 하지만 프로젝트가 누적될수록 다음 문제가 생깁니다.

같은 로그인 기능이라도 프로젝트마다 인증 방식이 다릅니다. 어떤 서비스는 이메일 로그인만 쓰고, 어떤 서비스는 소셜 로그인을 함께 씁니다. 어떤 프로젝트는 Supabase를 쓰고, 다른 프로젝트는 자체 백엔드를 씁니다. 관리자 권한 구조, 결제 정책, 파일 업로드 방식, 에러 메시지 톤도 모두 달라집니다.

이때 MCP와 Skills는 프로젝트별로 AI의 작업 능력을 확장하는 역할을 합니다.

MCP는 “이 프로젝트에서 참고해야 할 실제 자료”를 연결합니다. 예를 들어 데이터베이스 스키마, API 문서, 이슈 트래커, 디자인 시스템 문서에 접근하게 만들 수 있습니다. Skills는 “이 프로젝트에서 반복되는 작업 방식”을 저장합니다. 예를 들어 새 페이지를 만들 때의 폴더 구조, API 호출 방식, 테스트 작성 기준, PR 설명 형식을 정해둘 수 있습니다.

둘을 함께 쓰면 AI가 단순히 일반적인 정답을 말하는 수준에서 벗어납니다. 프로젝트의 실제 문맥을 보고, 그 프로젝트에 맞는 절차를 따라 작업하게 됩니다.

물론 모든 입문자가 처음부터 MCP와 Skills를 구성할 필요는 없습니다. 작은 개인 프로젝트라면 기획서, README, Cursor Rules 정도만으로도 충분한 경우가 많습니다. 다만 프로젝트가 길어지고, 여러 도구를 함께 쓰고, 반복 업무가 많아질수록 MCP와 Skills의 가치는 빠르게 커집니다.

4. 실제 활용 예시

가장 현실적인 예시는 이슈 기반 개발입니다.

커뮤니티 서비스에서 “댓글 수정 시 간헐적으로 저장이 안 된다”는 이슈가 등록되었다고 가정해 보겠습니다. MCP 없이 작업하면 사용자가 이슈 내용을 복사해 AI에게 붙여넣고, 관련 파일을 직접 찾아 설명해야 합니다. AI는 제한된 정보 안에서 원인을 추측합니다.

MCP로 GitHub 이슈와 저장소, 로그 문서가 연결되어 있다면 흐름이 달라집니다. AI는 이슈의 재현 조건을 참고하고, 관련 컴포넌트와 API 라우트를 찾고, 최근 변경 내역을 확인하는 방식으로 접근할 수 있습니다. 여기에 “버그 수정 Skill”이 적용되어 있다면 곧바로 수정부터 하지 않고 원인 후보, 수정 범위, 검증 방법을 먼저 제시하게 만들 수 있습니다.

두 번째 예시는 디자인 시스템 기반 화면 추가입니다.

새로운 “내 활동 내역” 페이지를 추가해야 한다고 합시다. Figma나 디자인 문서가 MCP로 연결되어 있고, 프로젝트에 “새 화면 생성 Skill”이 있다면 AI는 기존 레이아웃, 버튼 스타일, 카드 컴포넌트 사용 방식, 라우팅 규칙을 함께 고려할 수 있습니다. 단순히 예쁜 화면을 새로 만드는 것이 아니라, 이미 존재하는 프로젝트 구조에 맞춰 화면을 추가하는 쪽으로 작업이 정렬됩니다.

세 번째 예시는 문서와 코드의 동기화입니다.

API 응답 형식이 바뀌었는데 문서가 그대로 남아 있으면 나중에 큰 혼란이 생깁니다. MCP를 통해 API 문서나 내부 문서에 접근할 수 있고, “API 변경 Skill”에 문서 업데이트 절차가 포함되어 있다면 AI에게 다음과 같은 작업을 맡기기 쉬워집니다.

- 변경된 응답 타입 확인

- 프론트엔드 호출부 수정

- 관련 테스트 수정

- 문서에서 예시 응답 갱신

- 변경 영향 범위 요약

이런 흐름은 바이브 코딩에서 매우 중요합니다. AI가 코드를 빠르게 고치는 것보다, 고친 뒤에 무엇이 함께 바뀌어야 하는지 놓치지 않는 것이 실제 서비스 운영에서는 더 중요할 때가 많습니다.

5. 도입 시 주의점

MCP와 Skills는 강력하지만, 무조건 많이 연결하고 많이 만들어두는 방식은 좋지 않습니다. 연결이 늘어날수록 권한, 보안, 유지보수 문제가 함께 커집니다.

먼저 권한 범위를 최소화해야 합니다. 읽기만 필요하다면 쓰기 권한을 주지 않는 편이 안전합니다. 이슈 확인만 필요한데 저장소 전체 수정 권한까지 부여할 필요는 없습니다. 데이터베이스를 연결할 때도 운영 데이터 접근은 특히 조심해야 합니다. 민감 정보, 개인정보, 결제 정보, 인증 토큰이 AI 도구의 작업 맥락에 노출되지 않도록 제한해야 합니다.

두 번째로, 연결된 정보의 신뢰도를 확인해야 합니다. 오래된 문서가 MCP로 연결되어 있으면 AI는 그 문서를 기준으로 잘못된 코드를 만들 수 있습니다. Skills도 마찬가지입니다. 예전 프로젝트 구조에 맞춰 만든 Skill을 계속 사용하면 현재 구조와 맞지 않는 작업이 반복될 수 있습니다. 능력을 저장하는 것만큼 주기적으로 갱신하는 일이 중요합니다.

세 번째로, 자동 실행 범위를 조절해야 합니다. AI가 외부 도구를 사용할 수 있다는 말은 편리함과 위험을 동시에 의미합니다. 파일 수정, 이슈 댓글 작성, 배포 관련 작업, 데이터 변경처럼 되돌리기 어려운 작업은 사용자의 확인 단계를 두는 편이 안전합니다. 특히 입문 단계에서는 “제안은 AI가 하고, 실행 승인은 사람이 한다”는 원칙을 유지하는 것이 좋습니다.

네 번째로, Skills를 너무 크게 만들지 않는 것이 좋습니다. “서비스 개발 전체 Skill”처럼 범위가 넓으면 오히려 모호해집니다. 대신 “버그 수정”, “새 API 추가”, “컴포넌트 생성”, “PR 설명 작성”, “테스트 추가”처럼 작업 단위를 작게 나누면 재사용성이 높아집니다.

마지막으로, MCP와 Skills는 기획서와 프로젝트 규칙을 대체하지 않습니다. 기획서가 무엇을 만들지 정하고, 프로젝트 규칙이 어떤 방식으로 만들지 정한다면, MCP는 무엇을 참고할지 넓혀주고, Skills는 반복 작업을 어떻게 수행할지 안정화합니다. 네 가지가 함께 맞물릴 때 AI 코딩 도구는 단발성 코드 생성기가 아니라 프로젝트 협업 도구에 가까워집니다.

바이브 코딩의 입문 단계에서는 모든 기술을 한 번에 도입하려고 하기보다, 반복해서 설명하고 있는 일이 무엇인지부터 찾는 편이 좋습니다. 매번 같은 문서를 붙여넣고 있다면 MCP 연결 후보입니다. 매번 같은 절차를 설명하고 있다면 Skills 후보입니다. 이 기준으로 접근하면 도구 설정 자체보다 프로젝트에 실제로 필요한 능력 확장부터 판단할 수 있습니다.