바이브코딩, 「딸깍이면 된다」와 「말린다」 사이

바이브코딩, 요즘 사람들은 어떻게 이야기하고 있을까. 스레드에서 「바이브코딩」을 검색해 봤다. 글이 두 갈래로 갈렸다.

한쪽은 자랑이다. 바이브코딩으로 만든 앱을 보여 주고, 서비스를 연 지 두 달 만에 매출이 얼마가 됐다고 인증한다. 직접 만든 앱을 보여 달라는 글에는 반응이 뜨겁다.

다른 한쪽은 경고다. 오래 개발해 온 사람들이 묻는다. git은 아느냐, 데이터베이스는 아느냐, 개발용 서버와 실제 서버를 왜 나누는지 아느냐, 서버가 터지면 어떻게 할 거냐. 아무것도 모르고 딸깍 몇 번으로 서비스를 만들 수 있다고 믿는다면 말리고 싶다고 한다.

그 사이에 의심하는 글도 있다. 지금까지 본 바이브코딩 결과물은 그럴듯한 홈페이지 수준이지, 제대로 된 서비스는 못 봤다는 것이다.

어느 쪽이 맞을까. 이 사이트를 바이브코딩으로 만들어 보니, 둘 다 맞았다.

바이브코딩 뜻, 1년 반 사이 달라졌다

바이브코딩이라는 말은 AI 연구자 안드레이 카파시가 2025년 2월에 처음 썼다. 코드가 있다는 것조차 잊고 느낌에 맡겨 만든다는 뜻이었다. [출처: Wikipedia · Vibe coding] 처음에는 주말에 장난삼아 만드는 작은 프로그램 이야기였다.

반쯤 농담 같던 이 말은 그해 11월 콜린스 사전이 뽑은 올해의 단어가 됐다. 콜린스는 「자연어로 지시한 AI로 코드를 쓰는 것」이라고 풀었다. [출처: Collins · Word of the Year 2025]

1년 반 사이 이 말은 개발자의 장난에서 누구나 해 보는 일이 됐다. 코드를 한 줄도 모르는 사람이 앱을 만들고, 그걸로 돈을 벌었다는 글이 매일 올라온다. 말의 뜻도 조금 바뀌었다. 처음에는 「코드를 신경 쓰지 않고 만든다」였다면, 지금은 그냥 「AI에게 말로 시켜서 만든다」에 가깝다.

화면은 정말 쉬워졌다

자랑하는 쪽 말부터 맞다. 화면을 만드는 일은 정말 쉬워졌다.

이 사이트도 Claude Code와 대화하며 만들었다. 어떤 사이트를 만들고 싶은지, 누가 읽을 건지, 어떤 글을 올릴 건지를 말하면 페이지가 생긴다. 가이드북 두 권과 칼럼, 자료실, 수강생 게시판까지 지금 89쪽이다. 디자인이 마음에 안 들면 어디가 어떻게 이상한지 말하면 고쳐 준다. 폰에서 글자가 너무 작다고 하면 폰 화면만 따로 손본다.

몇 년 전이라면 개발자 몇 명이 몇 달 걸렸을 일이다. 지금은 혼자, 대화로 한다. 여기까지만 보면 딸깍이 맞다.

어려운 일은 코드 밖으로 옮겨 갔다

그런데 화면이 생긴 뒤부터 다른 일이 시작됐다. 이상하게도 그 일들은 대부분 코드가 아니었다.

화면은 금방 나오지만, 뒤에서 이어 붙일 것이 많다 — Gemini로 만든 그림

주소 붙이기. 도메인을 사서 사이트에 연결하고, www가 붙은 주소와 안 붙은 주소를 하나로 모으고, 예전 무료 주소로 들어온 사람도 새 주소로 넘어오게 했다. Claude가 순서는 알려 주지만, 도메인을 사고 결제하고 연결 버튼을 누르는 건 사람이다. 어느 주소를 대표로 쓸지도 사람이 정한다.

검색에 알리기. 구글과 네이버에 「이 사이트 주인이 나」라고 증명하고 페이지 목록을 건넸다. 구글은 도메인 설정에 확인용 글자 한 줄을, 네이버는 사이트 머리에 태그 한 줄을 넣으라고 했다. 넣는 건 Claude가 했지만, 구글과 네이버 화면에 들어가 확인 버튼을 누르는 건 내 몫이었다.

로그인 붙이기. 수강생만 들어오는 게시판을 만들려면 로그인이 있어야 한다. 로그인 코드를 메일로 보내려면 메일을 대신 보내 줄 곳부터 정해야 했다. 구글 계정에 들어가 앱 비밀번호를 따로 받아 와야 했고, 그 비밀번호는 한 번만 보여 주고 사라졌다. 명단에 없는 사람은 로그인 자체를 막는 장치도 넣었다.

숫자 보기. 오늘은 방문 분석(GA4)을 붙였다. 코드는 Claude가 한 번에 넣었다. 그런데 GA 화면에서 속성을 만들 때 시간대와 통화가 기본으로 미국에 맞춰져 있었다. 실시간 화면은 한 시간 가까이 「내부 오류」만 띄웠다. 방문자에게 알리려고 개인정보처리방침 문구도 먼저 고쳤다.

하나하나는 어렵지 않다. 하지만 어느 것도 「코드 짜 줘」로 끝나지 않는다. 다른 회사 화면에 들어가 버튼을 누르고, 비밀번호를 받아 오고, 무엇을 할지 정해야 한다. 바이브코딩에서 힘든 건 코딩이 아니라, 코드 바깥의 서비스들과 내 사이트를 잇는 일이다.

수익을 인증하는 글을 볼 때도 이걸 떠올리게 된다. 화면 캡처에는 앱만 보인다. 그 앱이 결제를 받고, 메일을 보내고, 가입한 사람의 정보를 지키기까지 뒤에서 이어 붙인 일들은 캡처에 찍히지 않는다.

모르면 위험한 것도 있다

말리는 쪽 말도 맞다. 몰라서 불편한 정도로 끝나지 않는 것도 있다.

2025년 봄, 한 보안 연구자가 바이브코딩 도구 러버블로 만들어 공개된 앱 1,645개를 살펴봤다. 그중 170개에서 로그인하지 않은 사람도 남의 이메일, 전화번호, 결제 정보까지 읽을 수 있는 구멍이 나왔다. 데이터베이스에 「누가 어떤 줄을 볼 수 있나」를 정하는 규칙이 빠져 있었기 때문이다. [출처: Matt Palmer · Statement on CVE-2025-48757]

앱은 잘 돌아갔다. 화면만 봐서는 아무 문제가 없었다. 만든 사람이 그 규칙이 있다는 걸 몰랐을 뿐이다. 문제는 그 사람이 아니라, 그 앱에 가입한 사람들이 떠안았다.

이 사이트의 수강생 게시판도 같은 규칙으로 막는다. 명단에 있는 사람만 글을 읽게 하는 줄이 데이터베이스에 따로 들어가 있다. AI가 알아서 넣어 준 게 아니다. 그 규칙이 필요하다는 걸 알았기 때문에, 처음부터 그렇게 만들라고 시켰다.

나만 쓰는 것과 남이 쓰는 것

말리는 글에 달린 댓글들이 더 흥미로웠다. 개발자들끼리도 의견이 반으로 갈렸다. 그중 한 갈래가 눈에 들어왔다.

나만 쓰는 것과 남이 쓰는 것은 다르다는 이야기다. 서버가 필요 없는 것, 내 일만 돕는 것을 만들면 망가져도 나만 손해다. 영상 편집 준비를 자동으로 해 두거나, 내 컴퓨터의 파일을 정리하는 프로그램이 그렇다. 이런 건 딸깍으로 시작해도 아무 문제가 없다. 바이브코딩이라는 말이 처음 나왔을 때 가리키던 것도 바로 이런 주말용 작은 프로그램이었다.

남이 쓰는 서비스는 다르다. 남의 이메일을 받고, 남의 돈을 받는 순간 망가졌을 때 손해 보는 사람이 내가 아니게 된다. 문제는 딸깍이라는 도구가 아니다. 「딸깍으로 서비스까지 된다」는 말이 문제다.

그러니 바이브코딩을 시작할 때 먼저 물어볼 건 「코드를 아느냐」가 아니라 「이건 누가 쓰나」다. 나만 쓰는 거라면 지금 바로 시작하면 된다. 남이 쓸 거라면, 아래 질문들이 그때부터 진짜 질문이 된다.

다 아는 사람에게 더 쓸모 있다

말리는 글에 나오는 질문들, 나는 다 안다. git으로 고칠 때마다 저장해 두고, 잘못되면 되돌린다. 내 컴퓨터에서 먼저 띄워 보고 괜찮을 때만 올린다. 데이터베이스에는 누가 무엇을 볼지 규칙을 건다. 이 칼럼도 지금은 내 컴퓨터에서만 보인다.

그런데 이 사이트를 만들면서 이 일들을 내 손으로 하지 않았다. 대화는 대개 이랬다.

• 「이건 이렇게 해야 하니까, 네가 직접 해 줘.」
• 「바로 가기 귀찮다. 열어 봐.」
• 「올리기 전에 폰 화면에서 깨지는 데 없는지 먼저 봐.」

무엇을 해야 하는지는 내가 알고, 손은 AI가 움직인다. 모르는 걸 해 달라고 한 게 아니다. 아는데 하기 귀찮은 일, 손이 많이 가는 일을 맡겼다.

그래서 생각이 바뀌었다. 바이브코딩은 아무것도 모르는 사람을 위한 도구라고들 하지만, 실제로는 많이 아는 사람에게 훨씬 더 쓸모 있다. 무엇을 시켜야 하는지 알면 한 번에 정확히 시킬 수 있다. 결과가 맞는지도 바로 알아본다. 틀린 방향으로 가면 중간에 멈춰 세운다. 아는 게 많을수록 맡길 수 있는 일도 커진다.

모르는 사람에게 AI는 답을 준다. 아는 사람에게 AI는 손을 준다.

그렇다고 모르면 시작하지 말라는 말은 아니다. 댓글 중에도 개발자라고 밝힌 사람이 그랬다. 하면서 배우는 게, 공부한다고 미루는 것보다 훨씬 낫다고. 모르면 물으면 된다. 이건 왜 필요한지, 안 하면 무슨 일이 생기는지. 그렇게 쌓인 만큼 다음에는 더 많이 맡길 수 있다.

그래서 딸깍인가

댓글 가운데 이 논쟁을 한 줄로 푼 말이 있었다. 말리는 사람들의 질문을 나눠 보면, git과 데이터베이스는 만들기에 필요한 것이고, 서버를 나누고 장애에 대응하는 건 운영하기의 일이라는 것이다. 바이브코딩이 낮춰 준 건 만들기의 문턱이지, 운영하는 사람이 져야 할 책임이 아니다.

그러니 「딸깍으로 서비스를 만든다」는 맞는 말이고, 「딸깍으로 서비스를 운영한다」는 틀린 말이다. 두 문장을 하나로 묶어 말하니 자꾸 싸움이 난다.

딸깍은 시작이다. 화면은 딸깍으로 나온다. 그 화면을 남이 쓰는 서비스로 굴리는 일은 딸깍이 아니다. 그 일을 해내는 건 결국 무엇을 해야 하는지 아는 사람이다.

아직 모른다면, 남에게 보여 주기 전에 AI에게 이 세 가지만 물어봐도 많이 달라진다.

1. 「이걸 남이 쓰려면 또 뭐가 필요해?」 — 주소, 로그인, 메일, 결제처럼 코드 밖의 일이 나온다
2. 「사람들 정보는 어디에 저장되고, 누가 볼 수 있어?」 — 보안 규칙이 빠졌는지 여기서 드러난다
3. 「망가지면 어떻게 되돌려?」 — 저장과 되돌리기 방법을 미리 만들어 둔다

그리고 그 벽들을 다 넘어도 하나가 더 남는다. 다 만든 서비스를 누가 찾아와 쓰느냐다. 오래 개발해 온 사람들이 댓글에서 짚은 것도 결국 이것이었다. 코딩보다 기획이, 기획보다 사람들이 무엇을 원하는지 아는 게 승부를 가른다. 코드는 AI가 대신 써 주지만, 누구에게 무엇이 필요한지는 대신 알아 주지 않는다.

딸깍이냐 아니냐는 이제 중요하지 않다. 아는 사람은 시키고, 모르는 사람은 묻는다. 바이브코딩으로 끝까지 가는 사람은 그 둘 중 무엇도 멈추지 않는 사람이다.