바이브코딩, 코딩 지식 없이 어디까지 할 수 있을까?

비개발자도 AI와 바이브코딩으로 서비스를 만들 수 있는 시대가 되었습니다.

저처럼 코딩을 모르는 사람이 바이브코딩을 해보면 초반에는 희열이 가득합니다. 이것도 되고 저것도 되고 알록달록한 페이지들이 손쉽게 만들어집니다. 딸깍 한 번으로 만들어지는 AI 유튜브 영상처럼 내 프롬프트 한 번에 만들어낸 결과에 스스로 감탄하며 금방 서비스 하나 만들 수 있을 것 같습니다.

그런데 막상 하나를 끝까지 만들어보면 금세 알게 됩니다. “만들 수 있다”와 “굴릴 수 있다”는 전혀 다른 문제라는 걸요. '나'만 '잠깐' 쓰는 수준이라면 대충 돌아가도 됩니다. 하지만 내가 진지하게 쓰는 순간부터, 다른 사람도 함께 쓰기 시작하는 순간부터는 머리가 아파집니다.

제 생각에는 코딩 지식 없이도 프로토타입이나 개인용 도구까지는 충분히 만들 수 있습니다. 하지만 다른 사람이 쓰는 서비스, 내가 계속 운영해야 하는 제품 수준으로 가는 순간부터는 최소한의 개발 지식이 필요해집니다.

내가 쓸 만한 수준(=상용 서비스)으로 기능도 고도화되어야 하고, 유지보수, 업데이트, 확장, 장애 대응까지 생각해야 합니다. 그러다 보면 결국 이 서비스가 대략 어떤 구조로 돌아가는지, 어디가 까다로운 부분인지, 뭘 고치면 어디까지 영향이 가는지, 당장 이 에러가 왜 나는지 알기 위해 내가 모르는 용어들을 '강제로' 공부하게 됩니다. 😅

어떻게 하면 잘 만들 수 있을까요?

설계: 구현 전 설계에 내가 할 수 있는 최선을 다하기

초반에 가장 경계해야 할 건 딸깍의 유혹입니다. AI가 화면도 만들어주고 기능도 붙여주니, 빨리 결과물이 나온다는 착각에 빠지기 쉽습니다. 그러나 초반에 구조를 대충 잡고 넘어가면, 나중에는 간단한 걸 수정하려 해도 진척이 되지 않고 다 갈아엎어야 하는 경우도 생깁니다.

처음부터 모든 걸 깊게 알 필요는 없어도, 최소한 이게 어떤 흐름으로 동작하는 서비스인지에 대한 감은 잡아야 합니다. 프론트엔드와 백엔드가 어떻게 나뉘는지, 데이터는 어디에 저장되는지, 로그인과 권한은 어떻게 처리되는지 정도의 큰 그림은 이해해야 합니다.

무엇보다 내가 뭘 만들고 싶은지, 그 서비스가 사용자에게 어떤 경험을 줘야 하는지, 어떤 방식으로 돌아가야 하는지를 스스로 설명할 수 있어야 합니다.

습작: 실패와 시행착오는 반드시 거쳐야 하는 과정

여기서 비개발자가 부딪히는 진짜 문제는 '사용자'로서의 감은 있지만 '만드는 사람'의 감은 없다는 점입니다. 어떤 앱이 편하다, 어떤 서비스가 답답하다 정도는 느껴도, 왜 어떤 구조는 잘 돌아가고 어떤 구조로는 안 되는지 감이 없습니다.

그래서 필요한 게 습작입니다. 작게라도 직접 만들어보고, 실행해보고, 고쳐보고, 때로는 버리는 과정이 필요합니다. 그 과정을 반복해야 내가 어디까지 알고 있고, 어디까지는 AI가 잘해주며, 어디부터는 사람이 직접 판단해야 하는지가 보이기 시작합니다. 저 같은 경우는 만들다 만 프로젝트들이 실제로 오픈한 것보다 최소 2배는 더 많은 것 같습니다.

원하는 게 많을수록 늘어나는 복잡도

만드는 것이 '제품 수준'으로 올라갈수록 점점 더 생각할 부분이 많아집니다. 그래서 저도 예전에는 생각 없이 계획 승인을 눌렀다면 요즘에는 계획을 뜯어보고 제가 아는 선에서 최대한 클로드/코덱스를 돕기 위해 노력합니다. 한 번 정해진 것이 수정도 되어야 하고, 수정 기록도 확인할 수 있어야 하죠. 관리자 화면에서는 어떻게 보일지, 보안상 이슈는 없는지, 너무 느리지 않은지, 설정을 바꾸거나 기능을 추가할 때 다른 부분이 틀어지지 않는지도 확인해야 합니다. 이때부터 바이브코딩은 '토이 프로젝트'가 아니라 제품 운영의 문제가 됩니다. (예전에 개발 단계에서 수정 요청을 드리면 왜 개발자분들이 난감해 하셨는지... 이제 더 와닿네요)

정리해보면 크게 설계, 논리, 예외 처리, 데이터 구조, 보안, 성능, 안정성이 중요해집니다. 이때부터는 병목은 코딩 속도가 아니라 생각의 구조인 것 같습니다.

결국 공부해야 한다

바이브코딩으로 무언가를 제대로 만들고 싶다면 초반에 시간을 아끼겠다는 마음부터 조금 버려야 합니다. 대충 만들고 나중에 고치겠다는 선택은 대부분 더 큰 비용으로 돌아옵니다. 작은 실험을 여러 번 하면서 구조를 익히고, 코드를 읽고, 실패를 반복하면서 레슨런을 쌓아야 합니다. 그렇게 하다 보면 내가 진짜 원했던 수준이 처음 생각보다 훨씬 높았다는 것도 알게 됩니다. 그리고 그 수준에 도달하려면 최소한의 개발 지식이 머릿속에 들어 있어야 한다는 사실도 자연스럽게 받아들이게 됩니다.

여전히 바이브코딩은 마법 같습니다

여전히 많은 사람들이 '딸깍'을 이야기합니다. 사실 '딸깍' 맞습니다. 예전엔 최소 3년은 공부해야 할 수 있는 것을, 두어 달 매달려야 했던 것을 일주일이면 만들어내니까 정말 예전의 노력에 비하면 바이브코딩은 '딸깍' 수준인 것이지요. 그런 점에서 보면 초기의 '딸깍' 도파민은 정말 소중합니다. 프로젝트를 끝까지 해내기 위한 마중물이 되어 주거든요. 그리고 프로젝트가 '내게 꼭 필요한 것'이어야 하는 점도 중요합니다. 그래야 어려운 지점이 왔을 때 동기를 잃지 않고 스스로를 끝까지 밀어붙일 수 있습니다.