바이브 코딩 강의와 AI 코딩의 함정 — 직접 해보니 앱보다 운영이 먼저 막혔다

유튜브에서 그런 영상 많이 본다. 코딩을 한 줄도 안 치는 것처럼 보이는 사람이 AI한테 몇 문장 던지니까 로그인 화면이 나오고, 버튼 누르면 모달이 뜨고, 심지어 결제 페이지 비슷한 것도 금방 붙는다. 영상 길이는 짧다. 8분, 12분, 길어야 20분. 보고 있으면 묘하게 기분이 달아오른다. 예전엔 이 정도 화면 하나 잡으려 해도 개발 환경 세팅부터 막혔는데, 이제는 말로 시키면 되는 것처럼 보이니까.

 

그 장면 자체는 거짓말이 아니다. 된다. 진짜 된다. 나도 해봤다. npx create-next-app으로 프로젝트 띄우고, AI한테 “랜딩 페이지 하나 만들어줘. 헤더 있고, 카드 3개 있고, CTA 버튼은 위에 배치해줘”라고 던지면 몇 분 안에 뭔가 그럴듯한 게 나온다. 예전보다 빨라진 것도 맞다. 이건 인정해야 한다. 괜히 부정하다가 이상한 고집만 남는다.

 

그런데 이상한 건, 사람을 끌어당기는 힘이 꼭 여기서 생긴다는 거다. 첫 화면이 나오고 나면 머릿속에서 자동으로 다음 문장이 이어진다. “어? 이 정도면 앱 하나 만들어서 뭔가 해볼 수 있겠는데?” 바로 여기. 나는 이 지점이 제일 위험하다고 본다. 왜냐하면 화면이 나오는 것과 서비스를 굴리는 건 완전히 다른 얘기인데, 영상은 둘 사이를 너무 부드럽게 이어붙이기 때문이다. 매끈하게 넘어간다. 보는 사람도 자연스럽게 속는다.

 

실제로 손을 대보면 속도가 꺾이는 순간이 생각보다 빨리 온다. 나도 처음엔 꽤 신났다. 화면 잘 나오고, 라우팅도 붙고, Supabase 같은 백엔드 서비스 물려서 로그인까지 흉내 내면 “이제 거의 다 왔는데?” 싶은 느낌이 든다. 그런데 꼭 그 다음에 빨간 글씨가 뜬다. Hydration failed because the initial UI does not match what was rendered on the server. 혹은 Cannot read properties of undefined (reading 'map'). 아니면 더 황당하게 Module not found가 뜬다. 분명 아까까지 되던 게, 한 군데 고쳤더니 딴 데가 무너진다.

 

이때 개발자는 보통 에러 메시지를 읽고 범위를 줄인다. 서버 컴포넌트 문제인지, 클라이언트 상태 문제인지, 데이터가 비동기로 들어오는 타이밍이 꼬였는지 대충 감이 온다. 그런데 비개발자 입장에선 다 같은 빨간 글씨다. 그래서 가장 자연스러운 행동을 한다. 에러를 그대로 복붙해서 AI에 넣는다. 그러면 AI는 또 뭔가 그럴듯한 패치를 준다. 여기서 한 번 고치면 괜찮을 것 같지? 잘 안 끝난다. 세 번째쯤 가면 더 이상 “수정”이 아니라 “누가 누구를 덮어쓰고 있는지 모르는 상태”가 된다. 이 지점부터는 앱을 만드는 게 아니라 대화 기록과 싸우는 일이 된다. 솔직히 좀 허무하다.

 

더 웃긴 건, AI가 틀리면서도 자신감은 넘친다는 점이다. 이게 제일 위험하다. “보안상 문제 없는 로그인 구현이야?”라고 물으면 꽤 단정적으로 답한다. 그런데 코드 보면 localStorage에 민감한 토큰을 그냥 넣고 있거나, 서버 검증 없이 클라이언트 상태만 보고 로그인 여부를 판단하는 식이다. 겉으로는 잘 된다. 클릭하면 넘어가고, 새로고침해도 유지되는 것처럼 보인다. 하지만 그건 기능이 돌아가는 거지, 안전하게 설계됐다는 뜻이 아니다. 실제 운영에서는 이 차이가 크다. 아주 크다. 사용자가 없을 때는 티가 안 나는데, 사람이 붙는 순간 문제의 성격이 바뀐다.

 

이런 말을 하면 가끔 너무 겁주는 것 아니냐고 하는데, 나는 오히려 반대라고 생각한다. 겁을 줘서가 아니라, 사람들이 너무 빨리 “운영”을 빼먹고 “제작”만 보고 있기 때문이다. 예를 들어 쇼핑몰 비슷한 걸 만든다고 치자. 상품 목록 나오고, 상세 페이지 뜨고, 장바구니 담기까지 된다. 여기까지만 보면 성공이다. 그런데 실제로는 품절 처리, 결제 실패 재시도, 주문 상태 동기화, 관리자 페이지 권한, 이미지 CDN, 환불 예외, 비정상 요청 차단 같은 게 줄줄이 따라온다. 이건 화면 시연 영상에는 잘 안 나온다. 보여주기 재미가 없으니까. 하지만 실제 서비스는 저 뒤쪽에서 무너진다. 앱이 아니라 운영에서 무너진다.

 

그래서 나는 바이브 코딩 강의가 이상하게 느껴질 때가 많다. 기술을 소개하는 척하면서 사실상 기대를 판매하는 경우가 꽤 많아서다. 구조는 늘 비슷하다. 처음에는 “코딩 몰라도 된다”는 식으로 입구를 넓힌다. 중간쯤 가면 데모가 나온다. 이 부분은 확실히 사람을 흔든다. 움직이는 화면은 언제나 강하다. 그리고 후반부에 가서 분위기가 바뀐다. “이런 시행착오를 줄이려면 커리큘럼이 필요하다”, “초보자는 혼자 하면 오래 걸린다”, “제가 실제로 쓰는 프롬프트와 워크플로를 정리했다.” 여기서 결제 링크가 붙는다. 물론 강의를 팔 수 있다. 그 자체가 문제는 아니다. 문제는 앞단에서 보여준 쉬움과 뒷단에서 실제로 필요한 역량 사이의 간극을 너무 얇게 보이게 만든다는 점이다.

 

이 간극을 이해하려면, 바이브 코딩을 도구로 봐야 한다. 결과가 아니라. 여기서 많이들 착각한다. 도구가 강력해졌으니 결과도 자동으로 따라올 거라고 생각한다. 그런데 도구는 속도를 높여줄 뿐이지, 판단을 대신해주지 않는다. 무슨 기능을 왜 넣는지, 어떤 순서로 만들지, 어디까지는 버리고 어디부터는 잡을지, 지금 나오는 에러가 구조 문제인지 단순 문법 문제인지… 이런 건 여전히 사람이 잡아야 한다. 그래서 비유를 하자면, 나는 바이브 코딩이 커피머신보다는 전동 공구에 더 가깝다고 본다. 드릴이 있으면 작업 속도는 빨라진다. 그렇다고 집이 저절로 지어지지는 않는다. 오히려 잘못 쓰면 벽부터 뚫는다.

 

또 하나. 사람들이 생각보다 쉽게 건너뛰는 질문이 있다. “내가 지금 만들고 싶은 게 진짜 필요한 서비스인가?” 이건 좀 불편한 질문이다. 왜냐하면 많은 경우 만들고 싶은 건 서비스가 아니라, 서비스 만들고 있는 내 모습이기 때문이다. 나도 그 유혹을 안다고 말하는 편이 정확하다. 화면 캡처 한 장 잘 나오면 꽤 뿌듯하다. 배포까지 붙으면 더 그렇다. 도메인 연결하고, 버튼 클릭 잘 되고, 친구한테 링크 보내서 “오, 이거 네가 만들었어?” 소리 들으면 기분 좋다. 여기까지는 아주 쉽다. 문제는 그 다음날이다. 이탈률 보고, 문의 들어오고, 뭔가 느린데 원인을 모르고, 로그를 봐도 모르겠고, 버전 올렸더니 어제 되던 게 오늘 안 된다. 그때부터는 캡처가 아니라 운영이다. 그리고 많은 프로젝트가 여기서 조용히 멈춘다. 실패했다는 글도 잘 안 올라온다. 그냥 레포지토리만 조용히 죽는다.

 

그래서 나는 바이브 코딩을 과소평가하지도 않고, 과대평가하지도 않으려고 한다. 프로토타입 단계에서는 진짜 엄청난 도구다. 이건 과장이 아니다. 예전엔 아이디어가 있어도 손대기 전에 피곤했는데, עכשיו는 일단 만들어볼 수 있다. 이 변화는 크다. 다만 그걸 근거로 “비개발자도 바로 수익화 가능”, “AI 코딩만 배우면 개발 외주 안 써도 된다” 같은 말까지 미끄러지듯 넘어가면 곤란하다. 그건 제작 도구의 발전과 사업 운영의 난이도를 한 줄로 묶는 거라서. 현실은 그렇게 안 붙는다.

 

만약 진짜 해보고 싶다면, 나는 오히려 더 작게 시작하라고 말하고 싶다. 전체 앱 말고, 화면 하나. 서비스 말고, 흐름 하나. “회원가입부터 결제까지”가 아니라 “입력 폼 하나와 저장 동작 하나.” 여기서 막히는 포인트가 보이면 그게 오히려 좋은 신호다. 내가 뭘 모르는지 보이기 시작한다는 뜻이니까. 반대로 처음부터 “이걸로 창업할 수 있나” 쪽으로 생각이 커지면, 대부분 중간에 감정만 먼저 소모한다. 기대치를 크게 먹고 들어가서, 막상 부딪히는 건 작은 에러들이기 때문이다. 사람 기운이 제일 이상하게 빠지는 방식이다.

 

그리고 솔직히 말하면, 강의 결제 전에 봐야 하는 건 데모 영상이 아니라 실패 기록이다. 세 번째 수정에서 왜 상태 관리가 꼬였는지, 배포 후에 왜 환경변수 때문에 로그인 콜백이 안 붙었는지, 왜 로컬에서는 되는데 서버에서는 500이 났는지. 이런 게 진짜 도움이 된다. 잘 되는 장면은 누구나 보여줄 수 있다. 막히는 장면을 어디까지 설명하는지가 그 사람의 깊이다. 이걸 안 보여주고 결과 화면만 보여주는 콘텐츠는, 정보라기보다 홍보에 더 가깝다.

 

바이브 코딩은 분명히 남을 거다. 더 좋아질 거고, 더 널리 쓰일 거다. 다만 그걸 둘러싼 말들이 너무 빨리 커졌다. “말만 하면 앱이 나온다”는 문장은 기술 데모로서는 맞지만, 현실 설명으로는 자주 부족하다. 그 사이에 빠진 것들이 있다. 운영, 판단, 구조, 책임. 결국 오래 남는 건 여기다.

 

해보면 안다. 앱이 먼저 나온다고 끝나는 게 아니었다는 걸. 오히려 그 뒤부터가 시작이었다는 걸.