MCP로 완성하는 책임 있는 바이브 코딩, 깃허브 유니버스 2025 정리

요즘 개발자들 사이에서 "바이브 코딩(vibe coding)"이란 말, 한 번쯤은 들어보셨을 거예요. AI 에이전트에게 "이런 느낌으로 만들어 줘"라고 말하고 흐름에 몸을 맡기는 코딩 방식이죠. 이번 GitHub Universe 2025 세션 "How to vibe code responsibly (with a little help from MCPs)"에서는 이 바이브 코딩을 어떻게 하면 안전하고 프로답게 활용할 수 있는지, 그리고 그 핵심에 Model Context Protocol(MCP)이 어떤 역할을 하는지 깊이 있게 다룹니다.

이 글에서는 영상 내용을 바탕으로:

바이브 코딩과 바이브 엔지니어링의 차이
책임 있는 AI 코딩의 3가지 원칙(파워·컨텍스트·컨트롤)
MCP가 왜 필요한지, 그리고 어떻게 쓰는지
GitHub MCP 서버와 ACP(Agent Client Protocol)를 활용해 위험을 줄이는 방법

을 하나씩 풀어서 설명해 보겠습니다. AI 코딩을 이미 쓰고 있든, 이제 막 시작했든 "어디까지 AI에게 맡겨도 될까?" 고민하는 분들께 꽤 실질적인 도움이 될 거예요.

바이브 코딩 vs 바이브 엔지니어링, 뭐가 다를까?

영상에서 가장 먼저 짚는 개념이 바로 "바이브 코딩"과 "바이브 엔지니어링"의 차이입니다. 얼핏 비슷해 보이지만, 개발자에게 주는 메시지는 완전히 다릅니다.

바이브 코딩은 말 그대로 AI와 함께 "느낌대로" 개발하는 경험에 가까워요. GitHub Copilot 같은 AI 에이전트에게 "이 기능 구현해 줘", "이 코드 리팩터링해 줘" 정도를 던지고, 제안해주는 대로 쭉 따라가며 코드를 완성해 나가는 방식입니다. 마치 능력 좋은 인턴이 옆에서 계속 코드를 써주는 느낌이죠.

문제는 이 과정에서 우리가 너무 편안해진 나머지, 의심 없이 '흐름을 타기'만 하면 안 된다는 데 있습니다. 영상에서 비유하는 것처럼, 이건 약간 "키보드를 든 이카루스"가 되는 길이에요. 에이전트가:

중요한 설정 파일을 덮어쓰거나
API 키를 그대로 노출하거나
실제로는 돌아가지 않는 코드를 멋지게 "환각"해서 만들어 낼 수 있습니다.

반대로 바이브 엔지니어링은 이 흐름을 즐기되, 설계자와 조종사로서의 역할을 포기하지 않는 접근입니다. AI가 제안하는 방향성을 적극 활용하되:

어떤 모델을 쓸지
어떤 컨텍스트를 줄지
어디까지 자동화 권한을 줄지

를 사람이 명확하게 통제하는 거죠. 정리하자면, 바이브 코딩이 "AI가 짜주는 대로 따라가는 코딩"이라면, 바이브 엔지니어링은 "AI를 고급 도구로 쓰면서 전체 설계를 사람이 쥐고 가는 코딩"에 가깝습니다.

이 세션의 핵심도 바로 여기에 있습니다. "그냥 맡기는 코딩"에서 "책임 있게 설계하는 코딩"으로 넘어가야 한다는 것, 그리고 MCP가 그 전환을 돕는 도구라는 점이죠.

책임 있는 AI 코딩의 3가지 원칙: 파워·컨텍스트·컨트롤

영상에서는 책임 있는 바이브 코딩을 위해 세 가지 키워드를 제시합니다. 이름은 간단하지만, 실제로 AI 코딩을 잘 쓰는 팀과 그렇지 못한 팀을 가장 확실하게 가르는 기준이에요.

첫 번째는 파워(Power)입니다. 어떤 LLM(대형 언어 모델)을, 어떤 용도로, 어느 정도 권한으로 쓸지 선택하는 문제죠. "일단 제일 큰 모델, 제일 강한 모델 쓰고 보자"는 생각은 의외로 위험합니다. 너무 강력한 모델에 너무 많은 권한을 주면, 실수도 그 스케일대로 커지거든요.

두 번째는 컨텍스트(Context)입니다. AI는 만능 천재가 아니라, '적절한 맥락을 잘 먹었을 때' 비로소 똑똑하게 움직이는 도구입니다. 필요한 정보가 부족하면 그 빈자리를 상상력, 즉 환각으로 채우기 시작합니다. 코드베이스, 이슈, 설정, 팀 규칙 등 필요한 맥락을 명확하게 주는 구조가 꼭 필요합니다.

세 번째는 컨트롤(Control)입니다. 아무리 똑똑한 에이전트라도, 사람이 완전히 손을 때고 "알아서 다 해줘"라고 방치해서는 안 됩니다. 에이전트를 어떻게 모니터링하고, 어디까지 자동으로 실행하게 둘지, 어떤 단계에서 반드시 사람의 승인을 거치게 할지 정해 두어야 하죠.

이 세 가지 원칙을 코드로, 시스템으로 풀어낸 것이 바로 MCP와 ACP 같은 프로토콜입니다. 단순한 이론이 아니라, 실제로 개발자가 IDE와 에이전트, 리포지토리를 연결해 안전하게 활용할 수 있게 해주는 구체적인 방법론인 셈이죠.

LLM 파워 선택법: "무조건 세다=좋다"는 아니다

AI 코딩을 쓸 때 가장 흔한 오해는 "더 큰 모델 = 더 좋은 코드"라는 생각입니다. 영상에서는 이 부분을 꽤 강조합니다. 파워는 선택과 설계의 문제지, 단순히 스펙 경쟁이 아니라고요.

예를 들어 단순 코드 자동완성, 주석 정리, 변수명 리팩터링 같은 작업에는 굳이 초거대 모델이 필요하지 않습니다. 상대적으로 가벼운 모델로도 충분히 높은 품질을 얻을 수 있고, 속도와 비용 측면에서도 훨씬 효율적입니다.

반대로:

복잡한 설계 변경
여러 서비스가 얽힌 아키텍처 수정
팀 규칙과 보안 정책을 모두 고려해야 하는 변경

같은 작업에는 더 강력한 LLM이 필요할 수 있습니다. 다만 이때는 반드시 더 정교한 컨텍스트와 더 엄격한 권한 설계가 따라야 합니다.

결국 중요한 건 "이 작업에 어떤 파워가 적당한가"라는 질문입니다. MCP와 같은 프로토콜을 쓰면, 서로 다른 모델과 도구를 상황에 맞게 조합하고, 어떤 요청이 어떤 모델을 쓰는지 명확하게 관리할 수 있습니다. 개발자는 "제일 센 거 하나"가 아니라 "목적에 맞는 조합"을 선택하는 설계자가 되는 것이죠.

컨텍스트가 부족하면 환각이 늘어난다: AI에게 '세부사항'을 먹여라

두 번째 축인 컨텍스트는, 사실 대부분의 실패한 AI 코딩 경험의 원인이기도 합니다. "Copilot이 이상한 코드 계속 짜요", "에이전트가 프로젝트 구조를 전혀 이해 못해요"라는 말 뒤에는 거의 항상 컨텍스트 부족이 숨어 있습니다.

AI는 우리가 보는 화면, 열려 있는 파일, 머릿속에 있는 생각을 알지 못합니다. 알려주지 않는 한, 이 리포지토리에 어떤 서비스가 있는지, 이 팀이 어떤 브랜치 전략을 쓰는지, 테스트는 어떻게 구성되는지 전혀 모릅니다. 그 상태에서 "유저 등록 버그 고쳐줘"라고 하면, AI 입장에서는 글자 그대로 추측의 잔치를 벌일 수밖에 없죠.

그래서 이 영상에서는 "AI에게 필요한 정보만 정확하게, 구조적으로 전달하는 법"이 매우 중요하다고 강조합니다. 예를 들어:

특정 디렉터리의 코드만 요약해서 전달한다든지
현재 열려 있는 이슈와 연결된 파일들만 보여준다든지
팀에서 정한 코딩 규칙이나 보안 정책을 시스템 메시지로 묶어둔다든지

하는 식의 컨텍스트 관리가 필요합니다. Model Context Protocol(MCP)은 이 컨텍스트 전달을 표준화해서, "어떤 도구에서 호출하든 AI가 일관되게 필요한 정보에 접근할 수 있게 해주는 역할"을 합니다.

Model Context Protocol(MCP)란 무엇이고, 왜 뜨는가?

이제 핵심 키워드인 MCP를 살펴볼 차례입니다. 영상의 중반부터는 MCP가 정확히 어떤 문제를 해결하는지, 왜 요즘 AI 코딩 워크플로우에서 필수 개념처럼 언급되는지 설명합니다.

쉽게 말해 MCP(Model Context Protocol)는 "LLM이 외부 세계와 안전하게 대화하는 규칙"입니다. LLM 혼자서는 파일 시스템에 접근할 수도 없고, GitHub 이슈를 만들 수도 없고, 데이터베이스를 읽을 수도 없습니다. 그 일을 대신해 줄 '도구들'을 정의하고, 그 도구를 AI가 표준화된 방식으로 사용할 수 있게 해주는 것이 MCP입니다.

MCP를 사용하면:

어떤 도구가 있는지(예: 이슈 생성, PR 조회, 코드 검색) 목록을 노출하고
각 도구가 어떤 입력을 받고 어떤 출력을 내는지 정해 두고
LLM이 이 도구들을 호출할 때 구조화된 형식으로 요청·응답을 주고받게 만들 수 있습니다.

결과적으로 개발자는 "AI야, 리포 전체를 쫙 스캔해서 알아서 해줘"라고 막연하게 시키지 않고, "이 MCP 도구를 사용해서, 이 리포에서 이런 정보를 가져와, 그다음 이 MCP 도구로 이슈를 만들어" 같은 식으로 흐름을 통제할 수 있습니다. 이 구조화된 통제가 곧 "책임 있는 바이브 코딩"의 기반이 됩니다.

GitHub MCP 서버로 할 수 있는 일들

영상에서는 GitHub MCP 서버의 능력도 간단한 데모와 함께 보여줍니다. 말 그대로 "GitHub를 AI가 이해할 수 있는 도구 세트로 포장해 놓은 서버"라고 생각하면 됩니다.

GitHub MCP 서버를 사용하면 에이전트는 MCP 도구를 통해:

특정 리포지토리의 이슈 목록을 조회하고
새로운 이슈를 생성하거나, 템플릿에 맞춰 내용을 채우고
Pull Request 정보를 확인하고
코드 파일을 읽고 요약하는

일들을 할 수 있습니다. 중요한 건 이 모든 접근이 MCP 규격에 따라 이루어진다는 점입니다. 즉:

어떤 필드를 보내야 하는지
어떤 권한이 필요한지
어떤 포맷으로 결과가 돌아오는지

가 명확하게 정의됩니다. 이 덕분에 개발자는 "에이전트가 GitHub를 마음대로 건드릴까 봐 불안한 상태"에서 벗어나, "이 도구들을 통해서만, 이 범위 안에서만 작동하게" 제한할 수 있습니다.

또 하나의 장점은, MCP 서버를 중심으로 여러 클라이언트(예: IDE, 에이전트 프레임워크, 별도 UI)를 붙일 수 있다는 점입니다. 같은 능력을 여러 곳에서 재사용할 수 있어서, 팀 차원의 AI 인프라를 만드는 데도 유리합니다.

실제 예시: MCP와 Goose로 GitHub 이슈 자동 생성하기

영상에서는 Goose라는 에이전트와 MCP를 사용해 GitHub 이슈를 만드는 데모도 보여줍니다. 이 부분은 "아, 이게 이렇게 돌아가는구나"를 직관적으로 이해하기 좋은 부분이에요.

흐름은 대략 이런 느낌입니다. 개발자가 에이전트에게 "에러 로그를 보고 적절한 버그 이슈를 만들어줘"라고 요청합니다. 그러면 에이전트는:

MCP 도구를 이용해 관련 코드를 읽고, 필요한 로그나 파일을 조회한 뒤
다시 MCP 도구를 호출해 GitHub 리포지토리에 새 이슈를 작성합니다.

이때 에이전트는 "적당히 HTTP 요청을 막 날리는 것"이 아니라, MCP에서 정의한 "CreateIssue" 같은 도구를 사용합니다. 이 도구는 필수 필드(제목, 내용, 라벨 등)와 형식을 정해 두었기 때문에, 에이전트가 일관된 형태의 이슈를 만들도록 유도할 수 있습니다.

덕분에 팀 입장에서는 다음과 같은 이득이 생깁니다.

이슈 템플릿이 깨지지 않고 유지된다.
중요한 필드를 빼먹지 않게 강제할 수 있다.
에이전트의 행동이 "예측 가능한 범위" 안에서 이뤄진다.

단순 자동화가 아니라, "AI를 팀의 규칙 안으로 끌어들이는" 느낌에 더 가깝습니다.

MCP UI로 팀 작업량 시각화하기

영상에서는 또 다른 데모로 MCP UI를 통해 팀의 작업량을 시각화하는 장면도 나옵니다. 이 부분은 프로젝트 매니저나 팀 리더에게 특히 유용한 시나리오입니다.

MCP UI는 쉽게 말해 "MCP 도구들을 사람이 보기 좋은 화면으로 보여주는 인터페이스"입니다. GitHub MCP 서버와 연결하면, 에이전트가 보는 정보뿐 아니라, 사람이 그 정보를 한눈에 볼 수 있는 대시보드처럼 활용할 수 있습니다.

예를 들어 MCP UI에서:

특정 팀원의 이슈 담당 현황
프로젝트별 작업량 분포
기간별 이슈 생성·해결 추이

등을 시각화할 수 있습니다. 이 정보를 다시 AI 에이전트에게 컨텍스트로 제공하면, "이번 스프린트에는 누구에게 어떤 이슈를 배정하는 게 좋을지" 같은 의사결정에도 도움을 줄 수 있죠.

핵심은 여기도 같습니다. MCP를 잘 활용하면 "사람이 보는 세계"와 "AI가 이해하는 세계"를 동일한 데이터 소스로 관리할 수 있다는 점입니다. 중간에 수작업으로 복붙하거나, AI에게만 따로 가공된 정보를 주지 않아도 되는 구조가 만들어집니다.

컨트롤의 핵심: ACP로 에이전트와 계속 대화하기

세 번째 원칙인 컨트롤(Control)은 Agent Client Protocol(ACP)이라는 개념과 연결됩니다. MCP가 "모델과 도구 사이의 규칙"이라면, ACP는 "에이전트와 사람(또는 클라이언트) 사이의 대화 규칙"에 가깝습니다.

영상에서 강조하는 부분은 이겁니다. 에이전트에게 일을 시키고, 그냥 결과만 기다리는 방식은 위험할 수 있습니다. 중간에 무슨 일이 벌어지는지, 어떤 선택지를 고민했는지 알 수 없기 때문이죠.

ACP를 활용하면:

에이전트가 어떤 액션을 실행하기 전에 "이렇게 진행할까요?"라고 묻도록 하거나
특정 범위 이상의 변경(예: 여러 파일 수정, CI 설정 변경 등)은 반드시 사용자의 확인을 거치게 하거나
에이전트의 계획(Plan)과 실제 실행(Act)을 단계별로 확인할 수 있게 만들 수 있습니다.

즉, "AI가 주도하는 자동화"가 아니라 "사람이 주도하는 협업"으로 흐름을 바꿔 줍니다. 이 구조에서는 설령 에이전트가 이상한 방향으로 계획을 세워도, 중간에 사람이 보고 수정하거나 중단할 수 있습니다.

이 방식은 특히 다음과 같은 작업에서 큰 차이를 만듭니다.

인프라 설정 수정
보안 관련 코드 변경
데이터 마이그레이션 스크립트 작성

AI에게 맡기더라도, 마지막 결정과 책임은 사람이 지는 구조를 시스템 차원에서 보장하는 셈입니다.

결국 당신이 파일럿이다: 안전하게 '바이브' 타는 법

영상의 마지막 메시지는 아주 단순합니다. "You are the pilot." 아무리 똑똑한 에이전트와 강력한 LLM이 있어도, 결국 조종간은 개발자에게 있다는 뜻이죠.

정리해 보면 책임 있는 바이브 코딩을 위한 핵심은 다음 세 가지 흐름으로 요약할 수 있습니다.

첫째, 파워를 설계해야 합니다. 어떤 LLM을 어떤 용도로 쓸지, 어느 정도 권한을 줄지, 팀과 프로젝트에 맞게 의도적으로 선택해야 합니다.

둘째, 컨텍스트를 제대로 먹여야 합니다. 코드베이스, 이슈, 규칙, 제한 조건 등 필요한 정보를 MCP 같은 프로토콜을 통해 구조적으로 제공해야 합니다. "AI가 몰라서 실수하는 상황"을 최소화하는 것이죠.

셋째, 컨트롤을 절대 놓지 말아야 합니다. ACP와 같은 메커니즘을 활용해 에이전트의 계획을 수시로 확인하고, 중요한 행동에는 반드시 사람의 승인을 거치게 해야 합니다.

개인적인 추천을 덧붙이자면, AI 코딩을 이미 사용하고 있다면 지금 내가 하고 있는 건 "바이브 코딩"인지, 아니면 "바이브 엔지니어링"인지 한 번 점검해 보시면 좋겠습니다. 그리고 팀 차원에서 다음 세 가지를 실험해 보세요.

간단한 MCP 서버를 하나 띄워 팀 리포지토리와 연결해보기
자주 하는 반복 작업(이슈 생성, PR 요약 등)을 MCP 도구로 정의해보기
에이전트가 변경하려는 내용을 항상 한 번 더 확인하는 ACP 스타일 워크플로우 만들어보기

이 세 가지만 도입해도 "AI가 짜준 코드"에서 "AI와 함께 설계한 시스템"으로 감각이 확실히 달라질 거예요. AI 시대의 코딩은 더 이상 혼자 키보드를 두드리는 일이 아니라, 여러 도구와 에이전트를 조율하는 '파일럿'의 일에 가깝습니다. MCP와 ACP를 이해하고 쓰기 시작하면, 그 조종석에서 훨씬 더 자신 있게, 그리고 책임감 있게 바이브를 탈 수 있을 겁니다.

출처 및 참고 :