Build Mode로 칼로리 계산 앱까지 만들어봤으니, 이번엔 그 연장선이다. “바이브 코딩”이라는 말을 검색하다가 계속 눈에 밟혔는데, 솔직히 처음엔 좀 웃겼다. 코딩을 느낌으로 한다고? 그게 말이 되나? 직접 해보고 나서 생각이 바뀌었다.
“바이브 코딩”이 뭔지부터 — 실제로 해보기 전까지 몰랐다
“바이브 코딩”이라는 단어를 처음 접한 건 구글 AI Studio 9편을 쓰고 나서였다. Build Mode 후기를 올리고 나니 댓글이랑 검색어에 이 단어가 계속 따라붙었다. 찾아보니 테슬라 전 AI 디렉터였던 Andrej Karpathy가 말하면서 퍼진 개념이라고 했다. 그 내용인즉슨 — “코드를 이해하려는 노력을 완전히 포기하고, AI에게 다 맡겨라.”
처음 읽었을 때 반응은 솔직히 “이 사람 뭔 소리야?” 였다. 뭔가를 만드는데 작동 원리를 모른다고? 그게 제대로 된 방법인가 싶었다. 디자이너 입장에서도 납득이 안 됐다. 내가 시안을 만들 때 색상 코드 모르면 포토샵을 못 쓰는 게 아닌데, 코딩은 그것보다 훨씬 더 블랙박스잖아.
그런데 AI Studio Build Mode를 써보고 나서 뭔가 단서가 잡혔다. 화면 오른쪽에 미리보기 창이 있고, 거기서 결과물을 실시간으로 볼 수 있다는 구조. 그 순간에 “아, 이래서 되는구나” 싶었다. 코드가 맞는지 볼 필요가 없다. 화면에 보이는 결과가 내가 원하는 모습인지만 판단하면 된다.
그 논리는 사실 디자인 작업이랑 비슷하다. 내가 브랜드 가이드를 만들 때 인쇄 방식이나 제본 기술을 몰라도 된다. 최종 결과물이 좋으면 되는 거니까. 그 관점으로 다시 읽으니까 Karpathy 말이 갑자기 말이 됐다.
1단계: 원하는 “느낌”을 그대로 쏟아내기
뭘 만들지 고민하다가 좀 웃긴 아이디어가 떠올랐다. “칭찬 가계부.” 지출을 기록하면 잔소리 대신 칭찬을 해주는 앱. 주변에 충동 소비 뒤에 자책하는 사람들 많아서 반응이 있을 것 같았고, 무엇보다 나도 쓸 것 같았다.
채팅창에 이렇게 썼다.
“배경은 산뜻한 파스텔 톤에 귀여운 이모지들이 쫙 깔려있고, 지출을 입력하면 버튼을 누를 때마다 팡파르가 터지면서 ‘오늘도 경제활동 하셨네요, 대단해요!’ 같은 칭찬 메시지가 뜨는 가계부 앱 만들어줘.”
기술 명세서 같은 거 없다. 내가 머릿속으로 그리는 화면을 그냥 말로 풀어쓴 거다. 디자인 브리프 쓰듯이, 클라이언트한테 내 비전을 설명하듯이.
그게 30초 만에 결과로 나왔다. 오른쪽 미리보기 창에 진짜 파스텔 배경에 이모지가 흩어져 있는 화면이 떴다. 반응 속도가 워낙 빠르다 보니 오히려 멈칫했다.
근데 색감이 내가 생각한 것보다 좀 진했다. 파스텔이라고 했는데 형광에 가까운 느낌이랄까. 그래서 바로 채팅창에 썼다.
“배경 색이 너무 진해. 좀 더 연하게.”
0.1초 만에 화면이 업데이트됐다. 아무것도 다시 실행할 필요 없이, 내가 타이핑을 끝낸 순간 이미 바뀌어 있었다. 이 반응 속도가 구글 Gemini 2.0 Flash 기반이라고 하는데, 피드백을 주고받는 체감이 대화랑 별 차이가 없었다.
이게 바이브 코딩의 사이클이다. 말하고 → 보고 → 반응하고 → 다시 말하고. 코드는 그 사이 어딘가에 알아서 생겨나고 있는 거고, 나는 거기에 신경 쓸 이유가 없었다.
2단계: 티키타카 피드백 — 이게 핵심이다
처음 결과가 나왔을 때 “오, 꽤 됐는데?” 싶었다가 바로 아쉬운 부분이 눈에 들어온다. 그 아쉬운 부분을 그냥 말하면 된다.
내가 실제로 주고받은 피드백을 그대로 옮기면 이렇다.
- “지출 금액 입력창이 너무 작아, 2배로 키워줘” → 바로 반영
- “칭찬 메시지가 너무 딱딱해, 더 친근한 말투로 바꿔줘” → 반영
- “합계 금액이 어디 있는지 모르겠어, 상단에 크게 보여줘” → 반영
- “버튼 색이 배경이랑 비슷해서 구분이 안 돼” → 반영
이걸 7~8번 반복했다. 중요한 건 이 과정에서 가운데 코드 창을 단 한 번도 쳐다보지 않았다는 거다. 오른쪽 미리보기 화면만 보면서 “내가 원하는 느낌인가?” 만 판단하면 됐다.
그러다 한 가지 순간에서 멈칫했다. 내가 요청하지 않았는데 금액 자동 포맷팅이 이미 들어가 있었다. 숫자를 입력하면 세 자리마다 쉼표가 자동으로 붙는 거다. AI가 알아서 넣은 거였다. 가계부 앱이면 당연히 필요하다고 판단한 것 같았다.
3단계: 말 한마디로 복잡한 기능 추가
앱 모양이 어느 정도 잡히고 나서 욕심이 생겼다. “오늘 지출 요약을 이메일로 받을 수 있으면 좋겠다”는 생각이 들었는데, 보통이라면 그 생각에서 끝이 났을 거다.
그냥 채팅창에 썼다.
“메일 전송 기능 추가해줘. 버튼 하나 누르면 오늘 지출 내역 요약이 내 이메일로 오게.”
이게 끝이다. 이걸 개발자가 직접 구현하려면 이메일 전송 서버(SMTP), 구글 클라우드 서버리스 함수, 인증 로직이 다 필요하다. 나는 그 세 가지 중에 아는 게 하나도 없다.
AI가 코드를 생성하기 시작했고, 잠깐 뒤에 오른쪽 화면에 “이메일 보내기” 버튼이 생겼다. 반신반의하면서 내 이메일 주소를 입력하고 눌렀다.
1분 뒤에 폰에 메일이 왔다.
오늘 테스트로 입력했던 금액들이 항목별로 정리된 요약 메일이었다. 그 순간 진짜로 멈췄다. 코드를 모르는 상태에서, 말 한 마디로, 이메일 전송 기능이 있는 앱이 만들어졌다.
Deploy — 10분 완성, 실제 URL 획득
수정이 다 끝나고 Deploy를 눌렀다. 9편에서 이미 한 번 해봤기 때문에 이번엔 덜 긴장했다. 구글 클라우드로 배포 프로세스가 돌아가는 동안 타이머를 켜두고 물 한 잔 마시고 돌아왔다.
이미 URL이 나와 있었다.
처음 Build 탭을 열었을 때부터 배포 URL을 받기까지 총 11분이었다. 기능 정리하고, 피드백 7~8번 주고받고, 이메일 기능 추가하고, 배포까지. 11분.
솔직한 평가 — 한계도 있다
좋은 얘기만 하면 광고처럼 보일 테니 솔직하게 쓴다.
복잡한 기능이 들어가기 시작하면 달라진다. 이메일 기능 추가할 때도 처음엔 화면에 버튼은 생겼는데 실제로 메일이 안 왔다. 세 번 만에 됐다. 복잡한 로직에서는 AI가 같은 유형의 오류를 반복하는 경우가 있다.
프로덕션 레벨 서비스를 이걸로 만들기엔 아직 무리다. 보안 처리나 예외 상황 대응이 기본 수준으로만 들어간다. 개인 프로젝트, 프로토타입, 아이디어 검증용으로는 완벽하다. 하지만 실제 사용자를 받는 서비스라면 별도로 검토가 필요하다.
Cursor와 비교하면 성격이 다른 도구다. Cursor는 개발 환경 안에서 AI가 코딩을 도와주는 방식이라, 어느 정도 개발 맥락을 아는 사람에게 맞다. Build Mode는 개발 환경 자체가 없어도 된다. 비개발자에게는 Build Mode가 훨씬 현실적인 선택이다.
마무리
바이브 코딩은 “코딩 공부를 안 해도 된다”는 말이 실제로 가능한 방식이다. 진입 장벽 없이, 자연어로, 작동하는 앱을 만들 수 있다는 경험은 해보기 전까지는 믿기 어렵다.
AI Studio 3연작을 여기서 마무리한다. 8편 기본 탐색, 9편 Build Mode, 그리고 이번 10편 바이브 코딩까지. 다음 11편에서는 완전히 다른 영역으로 넘어간다. 구글이 정식 출시 전 실험적인 아이디어들을 모아둔 공간, Google Labs다.
결론적으로 나는 이 도구를 아이디어 검증과 프로토타입 제작에 계속 쓸 것 같다. 완성된 서비스를 만드는 데는 아직 한계가 있지만, “이런 게 되면 좋겠는데”라는 생각을 실제로 확인하는 속도가 압도적으로 빠르다. 완벽하지 않아도, 그 속도 하나만으로 충분히 쓸 이유가 된다.