바이브 코딩, 자동화, 그리고 MCP
(stdy.blog)바이브 코딩 = AI에게 외주 맡기기
바이브 코딩은 본질적으로 AI에게 프로그램 외주를 맡기는 것
외주 개발 경험을 돌이켜보면 좋은 의뢰자는 이것들을 잘 하더라
- 내 문제를 풀기 위한 작업 정의
- 그걸 개발자가 잘 이해할 수 있게 의사소통
- 프로그램을 잘 만들기 위한 리소스 지원
- 만들어진 프로그램이 의도대로 작업을 대신해주는지 검수
- 이 과정에서 본인이 모르는 건 개발자에게 배워서 점차 스스로 할 수 있게 됨
바이브 코더 입장에 대입해보면
- PRD와 유저 플로우 정의
- 좋은 프롬프트와 지침(Cursor Rules 등) 사용
- 의도에서 어긋난 부분을 캐치하고 자동화된 테스트 실행
- 이 과정에서 AI와 핑퐁하며 학습
그러면 3은? 이건 프로그램의 두 가지 측면에서 생각할 수 있음
- 첫째, 프로그램은 어딘가에서 실행되어야 한다. → 실행 및 배포 환경 결정
- 둘째, 프로그램은 '입력을 처리해서 출력하는' 코드 뭉치다. → 데이터와 API 제공
프로그램은 실행되어야 한다
- 개발 외주에서 개발자의 책임은 보통 코드 구현까지고 배포와 운영 책임은 의뢰자에게 있음
- 대신 개발자는 의뢰자가 이 프로그램을 실행할 수 있는 가이드를 제공
- 외주 의뢰자로서 AI에게 코드를 실행하고 배포하는 환경을 알려주면 아주 잘해줌.
- 특히 웹 브라우저 위에서 돌아가는 코드라면 더욱 그러함
- 예전에는 '정규표현식으로 마크다운 문서의 일부 문법을 지우는' 것과 같은 아주 간단한 스크립트조차 비개발자가 실행/배포하기 쉽지 않았음
- 이제는 클로드 아티팩트, 제미니 캔버스 같은 걸로 나만의 작은 프로그램을 뚝딱 만들어서 실행할 수 있음. 남들도 쓰게 하고 싶다면 러버블에서 만들어 배포하면 되고, 전부 순식간에 무료로 가능
- 바이브 코딩이라고 해서 꼭 '앱'을 만들 필요는 없음. 내 문제를 해결하고 반복 작업을 줄여주는 프로그램이라면 그게 앱이든, 스크립트든, GPTs든, 프롬프트든 상관없음
프로그램을 더 유용하게 만들어주는 API
- 하지만 작은 프로그램에는 한계가 있음
- 마크다운 리무버에는 DB도, API도, LLM도 연결되어있지 않음
- 그래서 텍스트 입력도 사용자가 직접 하고, 출력된 텍스트도 사용자가 직접 복사해서 다른 곳에 올려야 함
- 만약 사용자에게 '노션에 써둔 글을 정제해 SNS에 올리는' 목적이 있었다면?
- 입력: 노션 페이지 링크만 입력
- 처리: 가져온 글을 LLM에 넣어 SNS에 어울리게 요약 후 마크다운 문법은 제거
- 출력: 글 검토, 승인하면 내 SNS 계정에 자동으로 올려줌
- 빠른 응답 시간과 범용성을 포기하는 대가로, 해당 작업에 드는 사용자의 시간과 에너지를 많이 줄여줬을 것. 즉 특정 목적에 있어서는 더 '유용'해짐
- 결국 프로그램의 유용성은 입력/처리/출력 측면에서 사용자가 직접 해야 하는 일을 얼마나 줄여주는가에 달려있음
- 입력을 자동화하거나
- 처리를 더 복잡하게 하거나
- 출력을 자동화하거나
- 일반적인 프로그램에서는 API를 통해 (즉 다른 프로그램과 연결됨으로써) 입출력 자동화와 고도화된 처리가 가능
- 입력: 노션 권한 얻고 노션 API 호출해서 페이지 내용 가져옴
- 처리: LLM API로 시스템 프롬프트와 함께 노션 페이지 내용 넣어서 SNS에 맞게 응답 받음
- 출력: 쓰레드 권한 얻고 SNS API 호출해서 글 게시
- 그러나 이렇게 만드는 게 숙련된 개발자에게도 아주 쉬운 일은 아님. 특히 권한 부여가 까다롭기 때문
- 이걸 더 쉽게 할 수 있을까?
까다로운 API 연동을 대신해주는 자동화 도구와 MCP
- Zapier, Make 등 자동화 도구를 쓰면 API 연동을 직접 안해도 됨
- 예: 노션 DB에 새 아이템이 올라오면 -> ChatGPT 돌린 다음 -> 인스타그램에 업로드하는 Zap
- 원래 인스타그램 글 게시 API를 호출하려면 전용 앱을 만들어 심사까지 받아야 함
- Zapier나 Make에서는 인스타그램 업로드용 앱을 이미 만들아놨고, 권한을 얻어 데이터를 주고받는 플로우도 다 구현해두었음. 까다로운 권한 문제를 내가 신경쓸 필요 없음
- 그러나 어떤 사람들에게는 이렇게 '이거 다음 저거'를 구축하는 것조차 어렵고 귀찮을 수 있는데, 이런 사람들이 LLM 챗봇으로 다 할 수 있게 해주는 게 MCP/A2A 같은 것들임
- 일반적인 프로그램이 API를 통해 단순한 로직 이상을 수행할 수 있게 된 것처럼, LLM 챗봇이라는 프로그램도 MCP를 통해 다른 프로그램과 연결되어 단순한(?) 텍스트/이미지/보이스 출력 이상을 수행할 수 있게 됨
- 클로드에서 '내 노션 페이지 긁어서 요약한 다음 인스타그램에 올려줘'가 가능해진다는 뜻
- 물론 이렇게 하려면 적절한 MCP 서버(노션, 인스타그램)를 MCP 클라이언트(클로드)에 연결해야 함
- MCP 서버의 가장 큰 역할이 tool을 통해 API를 대신 호출하는 건데, 노션은 이미 공식 MCP 서버가 있지만 인스타그램은 없음
- 그러면 클로드가 인스타그램 API를 어떻게 호출하지?
- 여기서 다시 Zapier가 나옴. Zapier나 Make가 제공하는 MCP 서버를 통하면 인스타그램 업로드가 가능
- 즉 LLM 챗봇에 (이미 많은 연동을 갖춘) 자동화 도구를 MCP로 연결하면 매우 강력해짐
MCP의 잠재력과 한계
- 근데 이렇게 보면 왜 굳이 MCP를 쓰나 싶을 수도 있음
- 현재 챗봇 + MCP로 할 수 있는 작업은 거의 대부분 자동화 도구에서도 할 수 있기 때문
- 하지만 필자는 MCP의 잠재력이 3가지 이유로 아주 크다고 느낌
- 편리한 인터페이스 (챗봇 비서가 모두 알아서 해주는 게 궁극의 프로그램 아닐까?)
- 민감 작업에 대한 사용자 개입이 더 편리함
- 파일 시스템 제어, 브라우저 제어 등 내 로컬 PC에서 해야 할 일도 자동화할 수 있을 뿐더러 리소스, 프롬프트 템플릿 등 더 많은 정보도 제공할 수 있음
- MCP 사용시 신경쓸 것도 많음
- MCP에게 많은 걸 넘길수록 보안도 더 신경써야 함. 그래서 로컬보다는 공식 리모트 MCP 서버가 안전함
- LLM에 MCP 툴을 너무 많이 주면 내가 원하는 툴이 실행되지 않을 수 있고, 툴 정의가 모두 입력 토큰으로 넘어가므로 LLM 호출 비용과 시간도 늘어남
- LLM 특유의 무작위성도 상용 서비스에서는 언제나 주의해야 함
- 결국 내 프로그램에 API를 연결하든, 자동화 플로우를 설계하든, LLM 챗봇에 MCP를 붙이든 하는 일은 '내 일 대신해줘'로 같음
- Make, MCP 같은 키워드가 급부상한다고 스트레스받을 필요 없음. 나에게 편한 방식으로, 각 방식의 장단점을 파악해가며 내 일을 대신하는 프로그램을 만들면 됨
정리
- 바이브 코딩은 프로그램 개발 외주를 AI에게 맡기는 것이다.
- 내 작업을 잘 대행해주기만 한다면 웹앱, 코드 스니펫, 프롬프트 모두 유용한 프로그램이 될 수 있다.
- 프로그램이 더 유용해지려면 입출력 자동화와 고도화된 처리를 위해 API 연결이 필요하다.
- 자동화 도구들은 API 연결의 까다로움을 대신 해결해준다.
- LLM 챗봇이라는 프로그램도 MCP 연결을 통해 더 유용해질 수 있다. 특히 자동화 도구가 제공하는 MCP 서버를 연결하는 게 강력하다.
- API, 자동화, MCP를 하나만 쓸 필요도 없고 섞으면 더 간편하고 강력해짐 (예: 클로드에 노션 MCP만 붙이고, Zapier에 노션 to 인스타그램 설정해서 업로드 자동화)
- 장단점을 고려하여, 내게 맞는 방식으로, 내 문제를 해결하는 프로그램을 (AI와 함께) 만들어보자