이 장에서는 바이브 코딩의 전체적인 작업 흐름을 소개합니다. 폴더 생성부터 배포까지의 과정을 이해하고, 왜 이런 프로세스가 권장되는지 그 이유를 알아봅니다.

1. 바이브 코딩 프로세스

위 다이어그램은 이 책에서 쓰는 바이브 코딩의 기본 흐름입니다. 앞선 책의 흐름과 비교하면 두 가지가 달라졌습니다. 첫째, '에디터 열기'와 '터미널에서 실행'이 '폴더 선택'으로 줄었습니다. 둘째, '프롬프트/요구사항 명세 작성'이 '한 문단으로 시키기'로 바뀌고, 대신 '검토'가 따로 한 칸을 차지합니다.

꼭 이 단계를 따라야 하는 것은 아닙니다. 저희 회사 디자이너는 피그마 메이크로 먼저 작업을 하고 다운로드를 받아 Code 탭으로 마무리하는 경우도 있고, 기획자는 채팅 탭에서 아이디어를 충분히 이야기한 다음 Code 탭으로 넘어가기도 합니다. 각자의 상황과 선호에 맞게 유연하게 적용하는 것이 중요합니다.

2. 왜 폴더부터 만드는가

Code 탭은 여러분이 지정한 폴더 안에서만 일합니다. 그 폴더가 Claude의 책상입니다. 폴더를 먼저 만들고 지정하는 데는 분명한 이유가 있습니다.

2.1 파일이 어디 있는지 항상 안다

개발 경험이 없는 분들이 가장 많이 겪는 문제 중 하나가 "내가 만든 파일이 어디 있지?"입니다. 폴더를 기준으로 작업하면 모든 결과물이 그 폴더 안에 생기기 때문에 파일의 경로를 찾지 못하는 일은 발생하지 않습니다. 결과물을 열어 볼 때도, 나중에 GitHub에 올릴 때도, 다른 사람에게 보낼 때도 그 폴더 하나면 됩니다.

2.2 토큰과 시간을 아낀다

토큰과 시간은 무한하지 않습니다. 만약 폴더를 지정하지 않고 '바이브 코딩 프로세스 이미지를 열어 텍스트로 변환해 홈페이지에 넣어줘.'라는 명령을 했다고 생각해볼게요. 폴더가 지정되지 않았기 때문에 폴더 검색을 해야 하고, 파일을 찾아야 합니다. jpg인지, png인지도 알려주지 않았기 때문에 확장자도 여러 개를 검색해봐야 합니다. 파일명이 '바이브 코딩 프로세스'인지도 확인을 하고, 못 찾으면 비슷한 파일명으로 다시 시도를 할 것입니다. 결국 간단한 작업 하나에 AI가 처리해야 할 일이 너무 많아집니다. 재료를 폴더에 넣어 두고 그 폴더를 지정하면 이 모든 탐색이 사라집니다.

2.3 프로젝트마다 폴더 하나

프로젝트가 바뀌면 폴더도 바꿉니다. 한 폴더에 랜딩 페이지와 가계부와 보고서를 섞어 두면 Claude도 헷갈리고 여러분도 헷갈립니다. 폴더 하나가 프로젝트 하나입니다. 이 습관이 5장에서 GitHub에 올릴 때 그대로 저장소 하나가 됩니다.

3. 왜 한 문단인가

앞선 책은 이 자리에 요구사항 명세서를 두었습니다. 이 책은 한 문단을 둡니다. 이유는 두 가지입니다.

첫째, AI가 충분히 좋아졌습니다. 이제 "카페 소개 랜딩 페이지를 만들어줘. 위에 신메뉴, 아래에 영업시간과 지도. 초록 계열로, 폰에서도 깨지지 않게. index.html 하나로."라는 한 문단이면 쓸 만한 결과물이 나옵니다. 문서를 길게 쓰는 시간에 결과물을 하나 더 볼 수 있습니다.

둘째, 어설프게 아는 것을 문서로 적으면 그 어설픔이 결과물에 그대로 들어갑니다. 개발을 모르는 상태에서 기술 스택, 폴더 구조, 데이터 구조를 적어 주는 것은 오히려 Claude의 손을 묶는 일이 될 수 있습니다. 모르는 것은 Claude에게 고르게 하고, 여러분은 아는 것, 즉 누가 쓸 것이고 무엇이 보여야 하고 무엇은 하지 말아야 하는지를 말하는 편이 낫습니다.

그렇다고 한 줄로 끝내라는 뜻은 아닙니다. 한 줄과 한 문단의 차이는 큽니다. 무엇을 담아야 하는지는 10장에서 자세히 다루고, 이 장의 실습에서 먼저 손으로 해봅니다.

4. 왜 검토가 따로 한 칸인가

4.1 AI도 완벽하지 않다

AI도 완벽하지 않습니다. Code 탭은 스스로 실행해보고 에러를 고치지만, 에러가 나지 않는다고 여러분이 원한 것이 나온 것은 아닙니다. 버튼이 엉뚱한 곳으로 가고, 폰에서 글자가 잘리고, 숫자가 틀리게 계산되는 일은 에러 없이도 일어납니다. 이것을 찾는 것은 여러분의 몫입니다. 결과물을 브라우저에서 열고, 눌러 보고, 창을 좁혀 보고, 숫자를 맞춰 보는 것이 검토입니다.

4.2 간단한 수정과 다시 만들기를 구분한다

검토 결과에 따라 갈림길이 있습니다. 색이나 문구처럼 간단한 것은 하던 대화에서 이어서 요청하면 됩니다. 반면 구조가 통째로 다르거나, 몇 번을 고쳐 달라고 해도 제자리라면 그 대화를 붙들지 말고 새 대화를 열어 한 문단을 다시 쓰는 편이 빠릅니다. 이때 앞선 대화에서 배운 것(이건 이렇게 말해야 알아듣더라)을 한 문단에 반영합니다. AI와 씨름하느라 30분을 보내는 것보다, 새로 시켜서 5분 만에 받는 것이 효율적일 때가 많습니다.

4.3 직접 고치는 것이 빠른 경우

모든 수정을 AI에게 맡길 필요는 없습니다. 웹페이지의 제목 한 단어를 바꾸는 일을 생각해보세요. 메모장으로 열어 고치면 10초면 끝날 일을, AI에게 요청하면 전체 폴더를 살펴보고 수정하는 데 1~2분이 걸리고 토큰도 씁니다. 아래 표는 직접 수정과 AI 요청에 걸리는 예상 시간을 간단히 비교한 것입니다.

다만 이 책의 독자는 처음에는 전부 AI에게 시켜 보시길 권합니다. 어느 파일의 어디를 고쳐야 하는지 감이 생기는 것은 몇 번 열어 본 뒤의 일이니까요. 8장을 지나면 간단한 텍스트 정도는 직접 고칠 수 있게 됩니다.