19P by spilist2 2달전 | ★ favorite | 댓글 4개

바이브 코딩 = AI에게 외주 맡기기

바이브 코딩은 본질적으로 AI에게 프로그램 외주를 맡기는 것

외주 개발 경험을 돌이켜보면 좋은 의뢰자는 이것들을 잘 하더라

  1. 내 문제를 풀기 위한 작업 정의
  2. 그걸 개발자가 잘 이해할 수 있게 의사소통
  3. 프로그램을 잘 만들기 위한 리소스 지원
  4. 만들어진 프로그램이 의도대로 작업을 대신해주는지 검수
  5. 이 과정에서 본인이 모르는 건 개발자에게 배워서 점차 스스로 할 수 있게 됨

바이브 코더 입장에 대입해보면

  1. PRD와 유저 플로우 정의
  2. 좋은 프롬프트와 지침(Cursor Rules 등) 사용
  3. 의도에서 어긋난 부분을 캐치하고 자동화된 테스트 실행
  4. 이 과정에서 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가지 이유로 아주 크다고 느낌
    1. 편리한 인터페이스 (챗봇 비서가 모두 알아서 해주는 게 궁극의 프로그램 아닐까?)
    2. 민감 작업에 대한 사용자 개입이 더 편리함
    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와 함께) 만들어보자

https://tech.kakao.com/posts/700 이 포스팅을 보고 Vibe Coding의 좋은 사례라 느꼈었는데, 맥락이 비슷한 거 같습니다. 저도 작성하신 내용에 공감합니다.

덕분에 재밌는 글 읽었네요! 감사합니다.

그러면 3은? -> 리소스 지원 얘기입니다.

위에 1, 2, 4, 5로 넘버링했는데 마크다운에서 자동으로 1234로 바뀌었네요.

바이브코딩 정도로는 외주라고 할수 없죠. 외주는 프로젝트 단위로 검수하지만 지금의 AI코딩 에이전트는 그보다는 작은 타스트 단위로 검수를 해야하니까요.

외주라면 일을 맡기고 나는 다른 일을 할 수 있어야 하는데… 아직은 너무 자주 돌봐줘야 합니다. 똑똑하지만 서투른 주니어 개발자 처럼…

머지않아… 외주까진 아니더라도 작은 개발팀 처럼 일할 수 있지 않을까… 생각합니다. 작업 지시하고 수시로 리뷰하고 고치고… 그러나 아직은 그 정도도 아닌 것 같네요.

어쩌면 제가 바이브가 부족해서 그럴지도…