코딩을 세 번 배우려다 세 번 다 그만뒀어요. 그러다 어느 날 만들고 싶은 앱을 그냥 말로 설명했더니, AI가 전부 코드로 짜줬고 실제로 작동했어요. 타이핑을 단 한 줄도 하지 않았는데요. 그 순간에 지금은 이름이 생겼어요. 이름이 좀 우스꽝스러운 건 의도된 거예요.
타이피스트가 아니라 감독이 되는 거예요.
코더는 모든 줄을 손으로 직접 써요. 하지만 바이브 코딩에서는 그러지 않아요. 원하는 것을 평범한 말로 설명하면 AI가 실제 코드를 작성하고, 결과물을 보면서 반응하면 돼요. 너무 복잡하다. 버튼 크게 해줘. 그 색 별로다. 감각으로 방향을 잡는 거예요. 방을 꾸며달라고 할 때처럼요. '아니, 소파 왼쪽으로, 그건 더 별론데, 조금 뒤로.' 망치를 한 번도 들지 않아도 돼요. 그냥 좋다 싫다를 말하다 보면 완성돼요.
변화의 핵심이 바로 이거예요. 실력의 기준이 코드를 쓸 수 있느냐에서 결과물을 보고 좋고 나쁨을 판단할 수 있느냐로 바뀌어요.
작업 세션이 실제로 돌아가는 방식이에요. 루프 구조이고, 속도가 빨라요.
설명해요. '사람들이 사진을 올리고 설명을 붙일 수 있는 페이지를 만들어줘.'
결과를 봐요. AI가 만들어요. 열어서 직접 눌러봐요.
반응해요. '업로드 버튼이 숨겨져 있고, 폰에서 안 된다.'
다시 돌려요. 고치고, 보고, 반응해요. 마음에 들 때까지 반복해요.
코드를 읽는 게 아니에요. 결과를 읽는 거예요. 감각이 곧 핸들이에요.
왜 바이브 코딩이 비개발자가 드디어 무언가를 만들 수 있는 방식인가요. 이전에 그만둘 때마다, 아이디어가 없어서 그만둔 게 아니었어요. 자잘한 장벽들 때문이었어요. 개발 환경 세팅. 마법의 단어를 요구하는 설정 파일. 유용한 것 하나 쓰기도 전에 한 시간씩 날리는 설정 싸움. 바이브 코딩은 그런 것들을 전부 AI에게 넘겨요. 나를 막던 지루한 벽은 이제 다른 누군가의 일이고, 처음부터 신경 썼던 것, 즉 아이디어에만 집중할 수 있어요.
안내문에 아무도 안 적어놓는 부분이에요.
안전망 없이 바이브 코딩을 하면 주말을 통째로 날릴 수 있어요. 코드를 읽을 수 없으면, AI가 세 단계 전에 저지른 작은 실수를 발견하지 못해요. 전체가 서서히 망가지는 느낌만 오고, 어떤 변경이 문제를 만들었는지 알 수가 없어요.
그래서 여기에 붙여놓고 싶은 규칙 하나가 있어요.
반드시 버전 관리를 깔고 바이브 코딩을 해야 해요.
이게 작업하면서 프로젝트를 스냅샷으로 저장해주는 시스템이에요. 감각이 어긋나는 순간이 오면, 그리고 분명히 와요, 읽지도 못하는 코드를 디버깅하며 앉아있지 않아도 돼요. 마지막으로 잘 작동했던 버전으로 되감으면 돼요. 나쁜 한 시간이 없었던 것처럼요. 그리고 더 나은 방향으로 다시 나아가면 돼요.
몇 가지 솔직한 가드레일이 있어요. '그냥 설명하면 된다'는 말 뒤에 감춰진 날카로운 부분이 있거든요.
- AI는 가끔 확신에 차서 틀려요. 버그를 실제로 고쳤을 때와 똑같이 차분한 목소리로 고쳤다고 말해요. 직접 눌러보고 확인해야 해요. '완료!'를 그냥 믿으면 안 돼요.
- AI가 건드리는 범위를 파악해야 해요. 앱이 닿는 곳이 많을수록, 즉 내 데이터, 라이브 사이트, 실제 돈, 변경 사항을 적용하기 전에 실제로 확인해야 해요. 연습용 토이 프로젝트에서는 자유롭게 해도 돼요. 실제 서비스라면 속도를 늦춰야 해요.
- 작은 요청이 큰 도약보다 나아요. '스토어 전체 만들어줘'는 AI가 백 가지 방향으로 헤맬 여지를 줘요. '작동하는 결제 버튼 추가해줘'는 10초 안에 보고 판단할 수 있는 거예요. 작은 요청, 잦은 확인, 그게 리듬이에요.
바이브 코딩은 'AI가 다 하고 나는 잠'이 아니에요. 감각을 손에 쥐고 감독 의자에 앉아, 마음에 들 때까지 좋다 싫다를 말하는 거예요. 코드를 쓸 필요는 없어요. 좋은 것을 봤을 때 알아볼 수 있어야 하고, 아닐 때를 위한 되감기 버튼이 필요해요.