핵심 요약

  • 바이브 코딩은 원하는 결과를 말로 설명하고 AI가 만든 코드를 실행·수정하며 소프트웨어를 만드는 방식이다.
  • 앤드루 첸은 제작 비용이 낮아지면 학생과 취미 창작자의 참여가 늘고, 개인의 작은 수요에 맞춘 소프트웨어도 많아질 것으로 예상한다.
  • 제작이 쉬워져도 꾸준한 창의성, 유통, 네트워크 효과는 제품이 성장하는 데 중요한 조건으로 남는다는 전망이다.
  • 복잡한 업무 규칙과 예외 상황, 보안·개인정보 문제는 코드를 생성하는 것만으로 해결되지 않는다.

코드에서 화면으로 옮겨갈 제작 방식

바이브 코딩이라는 표현은 안드레이 카파시가 사용했다. 그는 AI에 수정을 요청하고 오류 메시지를 다시 입력하는 식으로 프로젝트를 만든다고 설명했다. 직접 코드를 모두 읽지 않기 때문에 AI가 고치지 못하는 버그를 우회할 때도 있으며, 이런 방식은 주말에 만드는 일회성 프로젝트에 비교적 잘 맞는다고 했다.

첸은 현재의 바이브 코딩을 명령줄 인터페이스 단계에 비유한다. 그의 예상으로는 창작자가 원하는 화면과 결과를 보여주고 AI가 구현하는 시각적 방식이 더 널리 쓰일 수 있다. 디자인을 세밀하게 조정하거나 시안을 추가하는 도구는 남더라도, 일부 창작자는 프로그래밍 언어를 배우지 않고 소프트웨어를 만들 수 있다는 전망이다.

누가 만들고 무엇을 재사용할까

첸은 시간이 많은 학생과 젊은 창작자가 소프트웨어 제작에 더 많이 참여할 것으로 본다. 영상과 사진처럼 젊은 문화가 소프트웨어의 형태에도 영향을 줄 수 있다는 것이다. 기존의 버튼과 창, 스크롤 중심 설계와 다른 방식이 등장할 가능성도 제기한다.

AI가 필요한 코드를 그때그때 생성하면 오픈소스 라이브러리를 재사용할 필요가 줄어들 수 있다는 추정도 내놓는다. 다만 이는 확정된 변화가 아니다. 첸은 현재 새 프로젝트를 만드는 일이 기존 프로젝트를 수정하는 일보다 쉬운 경우가 있다고 관찰한다. 수정에는 기존 코드의 맥락과 복잡성을 파악해야 하기 때문이다.

제작 이후의 병목

소프트웨어를 쉽게 만들 수 있게 되면 차이를 만드는 요소도 달라진다. 첸은 새로운 아이디어를 꾸준히 내는 능력과 유통, 네트워크 효과를 꼽는다. 비슷한 제품 중 먼저 만들어진 것보다 먼저 규모를 확보한 제품이 유리할 수 있다는 주장이다.

그는 이용자 행동에 따라 스스로 바뀌는 소프트웨어도 상상한다. 예를 들어 제작자가 회원가입을 쉽게 하라는 결과를 지정하면, 이용자가 막히는 지점을 본 소프트웨어가 단계를 줄이거나 설명을 추가하는 방식이다. 현재 구현된 일반적인 기능을 설명한 것이 아니라, 제품 담당자가 원하는 결과를 지정하는 미래의 방식에 관한 전망이다.

작은 시장과 개발팀에 미칠 영향

첸은 스프레드시트가 비전문가에게 계산과 자동화 수단을 준 것처럼, 바이브 코딩이 규모가 작거나 성장 속도가 느린 산업의 종사자에게도 제작 수단을 줄 수 있다고 본다. 개발팀 구성은 단정하지 않는다. 글에서 제시한 일반적인 소프트웨어 회사의 엔지니어·디자이너·제품 담당자 비율은 5:1:1이다. 제작 비용이 낮아져 엔지니어 비중이 줄 수도 있지만, 더 많은 제품을 더 빨리 만들기 위해 오히려 수요가 늘 수도 있다는 반론을 함께 제시한다.

마케팅과 영업 역시 AI에 목표를 설명하면 실행 과정을 맡기는 형태로 바뀔 수 있다고 예상한다. 짧은 영상으로 앱을 알리는 계획부터 영업 대상 목록과 대본 작성까지 예로 들지만, 실현된 성과로 제시하지는 않는다.

낮은 완성도와 남는 복잡성

첸은 현재 바이브 코딩으로 만든 게임 중에는 기존 상용 게임과 비교해 완성도가 낮은 사례가 있다고 인정한다. 다만 AI 생성 기술의 발전으로 결과물의 수준이 높아질 수 있고, 품질이 다소 낮더라도 다양한 작은 수요를 채우는 많은 소프트웨어가 가치를 가질 수 있다고 본다. 이는 전망이지 품질 문제가 이미 해결됐다는 뜻은 아니다.

더 까다로운 문제는 업무 규칙과 예외 상황이다. 쿠폰 두 장을 동시에 쓸 수 있는지, 배달 기사에게 이미 대금이 지급된 뒤 환불은 어떻게 처리할지 같은 결정은 코드를 작성하는 일과 별개다. 공유 폴더를 한 사람이 삭제했을 때 상대방에게 어떤 일이 일어나야 하는지도 보안과 개인정보 문제로 이어질 수 있다.

비행 시뮬레이션 게임을 만든 NicolasZu의 사례는 제작 과정의 길이를 보여준다. 그는 게임 설계 문서와 단계별 구현 계획을 만든 뒤 각 단계를 직접 시험하고, 막히면 이전 변경으로 돌아가 다른 방법을 시도했다고 설명했다. Cursor에서 사용한 프롬프트는 3,000개가 넘는다고 했다. 첸의 전망처럼 제작의 문턱이 낮아지더라도, 원하는 결과를 정의하고 검증하며 복잡한 결정을 내리는 일은 남는다.