WeniVooks

1. 바이브 코딩을 위해 무엇을 왜 배워야 하는가?

바이브 코딩을 하기 위해서는 디렉터 또는 프로젝트 매니저(PM)가 되어야 합니다. 이미 기술적으로 훌륭히 해내는 조직이 있다고 생각하고 명확하게 명령을 하달할 수 있는 사람이 되어야 합니다. 경험이 많을수록, 아는 것이 많을수록 더 높은 수준의 결과물을 얻을 수 있습니다.

2. 바이브 코딩에서 AI와 사람의 역할

영화 촬영을 한다고 생각해보겠습니다. 여러분은 명령을 내리는 위치, 감독의 역할을 수행하게 될것입니다. 감독은 직접 연기를 하지 않습니다. 감독은 카메라를 직접 조작하지 않습니다. 조명 장비를 설치하지도 않습니다. 감독은 전체 그림을 보고, 각 장면이 어떤 느낌이어야 할지 상세히 알아야 합니다. 여기서 중요한 포인트 중 하나는 각 구성원이 모두 '전체 그림'을 이해할 필요는 없다는 것입니다. 오늘만 출연하는 사람이 결말까지 알 필요는 없습니다. AI도 오늘 지시한 것에 필요한 것만 이해합니다. 항상 모든 코드를 다 읽어보고 다음 코드를 작성하는 것이 아닙니다.

예시와 다른 점도 있습니다. 바로 간섭입니다. 예를 들어, 영화 촬영에 있어 배우는 감독이 지시한 대로 연기하지만 각본이 이상하다고 하여 감독이 해야 할 지시를 직접 하지 않습니다. 그러나 바이브 코딩 툴은 다릅니다. 여러분의 지시가 불명확하면 단순 보조의 역할을 넘어섭니다. 지시의 세부 사항을 다시 물어보지 않고 여러분이 채우지 않은 여백을 생성형 AI로 생성한 글로 채웁니다. 이것을 앞으로 간섭이라 부를 것입니다. 이러한 간섭이 많아질수록 여러분의 의도와는 먼 결과물이, 또는 의도 자체가 모호했기에 오히려 더 마음에 드는 결과물이 나올 수 있습니다. 불확실성이 커지는 것이죠.

가벼운 프로젝트에서는 단지 '애플 느낌이 나는 바이브 코딩 랜딩 페이지를 만들어줘'라고 하는 것으로 족합니다. 그것만으로도 아래와 같은 결과물을 만들 수 있습니다.

이 '애플 느낌이 나는 바이브 코딩 랜딩 페이지를 만들어줘'라는 프롬프트에는 배경색이 어떻게 되고, 페이지는 어떤 페이지로 구성되어 있어야하며, 로그인이나 로그아웃 등이 구현되어야 할지, 게시판이 있어야 할지, 반응형은 어떻게 해야할지 등의 내용이 없습니다. 그럼에도 훌륭히 결과물을 만들어내죠.

만약 기획한 것도 없고, 호기심에 시작한 프로젝트라면 그럭저럭 만족스러운 결과물일 수 있습니다. 그런데 만약 페이지 4개가 있어야하고, 메인 컬러는 보라색을 써야하고, 로그인과 로그아웃이 구현되어 있어야하며, 게시판도 있어야 한다면 어떨까요? 우리의 프롬프트는 더 구체적으로 체계화 해야하고, 프롬프트에도 전략이 필요하게 됩니다.

전략 없이 개발하는 예시를 들어보겠습니다. 여러분이 '로그인을 구현해줘'라고 한다면 클로드 코드는 여기에 로그인 서비스를 붙이기 위해 다른 백엔드 언어를 도입할 것입니다. 백엔드 언어가 도입되었으니 실행하는 법을 별도로 알아야 합니다. 여러분은 '실행하는 법을 정리해줘'라고 말할 것입니다. 실행하는 법을 알았으니 서비스를 테스트 해봅니다. 그런데 서비스를 테스트 해보다 보니 회원 관리가 필요합니다. '회원 목록을 볼 수 있는 페이지도 만들어줘'라고 말합니다. 그리고 조금 더 사용해보다보니 악성 사용자를 탈퇴시킬 기능도 필요하다는 것을 인지하게 되었습니다. '회원 관리를 할 수 있는 기능을 목록 페이지에 추가해줘'라는 것이죠. 이렇게 돌고 돌아 서비스를 만들면 어떤 결과물이 나올까요?

클로드 코드 바이브 코딩 부트캠프 2기에서 실제 있었던 일입니다. 게시판은 Flask로, 로그인은 FastAPI로 만들어져 있었습니다. 코딩을 처음 해보시는 분이었죠. 좀 더 쉽게 설명하자면 고객이 '가'라는 음식점에 가서 음식을 주문했습니다. 그런데 음료수는 '나'라는 음식점에서, 고기는 '다'라는 음식점에서, 야채는 '라'라는 음식점에서 서빙하는 상태가 된 것입니다. 음식만 '가'라는 음식점에서 먹게 된 것이죠. 이러면 운영자는 '가', '나', '다', '라' 이 모든 음식점을 개업한 상태여야 합니다. '가'라는 음식점이 다 할 수 있는데 말이죠.

왜 이런 일이 발생이 되었을까요? AI는 항상 모든 코드를 '전부' 읽지 않습니다. 필요한 코드를 찾고, 해결책이 그 코드 안에서 만들어지면, 다른 코드는 생각하지 않습니다. 앞에서 영화에 비유한 것처럼 오늘 하루 연기하시는 분이 결말까지 알 필요는 없는 상태인 것이죠.

따라서 우리에게 전체를 보는 눈이 필요합니다. 잘못된 길로 프로젝트가 가고 있으면 바로잡아줄 기준도 필요합니다. 프론트엔드와 백엔드는 무엇이고, Flask, FastAPI, Django, Express와 같은 단어들이 무엇을 뜻하고, DB는 무엇인지 알아야 합니다. 그리고 그것을 적절하게 사용하여 지시할 수 있어야 합니다.

다만 모든 것을 다 깊이 알 필요는 없습니다. 우리의 생성형 AI 활용은 코드를 생성하는 것 외에도 코드를 배우는 것에도 쓸 수 있기 때문입니다. 집요하게 물어보고, 적정기술인지 확인하고, 지금 이 프로젝트에 도입했을 때 내 수준에서 운영이 가능한지 등을 물어가며, 배워가며 개발할 수 있습니다.

그러니까 우리는 언제나 학생이면서 동시에 디렉터 역할을 하게 됩니다. 총칭하여 AI 디렉터, AI 프로젝트 매니저(PM)이라고 할 수 있을 것 같아요.

3. 무엇을 공부해 나가야 하는가?

아무것도 모르고 시작할 수도 있지만, 알면 더 견고한 결과물을 제작할 수 있습니다. 앞으로도 그럴까요? 만약 지금보다 AI가 2 ~ 3배 뛰어나진다면, 아무것도 모르고 원하는 결과물까지도 만들 수 있지 않을까요? 그러니 배울 필요가 없지 않을까요? 무엇을 공부할 것인지는 미래지향적인 일이기 때문에 우리는 미래의 상황을 가정할 필요가 있습니다.

아래 나열한 몇 가지는 그러한 사항을 가정한 것이기 때문에, 논리적 허점이 있거나 당위성이 부족하다 생각이 된다면 여러분들만에 공부 방법으로 공부를 하시는 것을 권합니다. 특히 이 책을 읽는 시점에서의 AI는 지금 제가 쓰고 있는 AI와 의미가 다를 수 있기에 현재 AI 수준에 맞춰 고민해보시면 좋을 것 같습니다.

첫 번째로, 바이브 코딩을 위한 프롬프트를 공부해야 합니다. 아무리 AI가 대단해진다고 해도 프롬프트 한 줄로 내가 원하는 결과물을 만들 수는 없습니다. 비전공자가 가벼운 랜딩페이지 정도는 프롬프트까지 학습해가며 개발하지 않아도 원하는 결과물을 만들 수 있지만, 규모있는 프로젝트에서는 어떠한 프롬프트로 어떠한 결과물을 만들어낼 수 있는지 충분히 학습되어 있는 편이 수월합니다.

이러한 학습은 단지 만드는 것에 그치지 않습니다. 무엇을 하지 말아야하는지도 정확하게 지시하고, 위험을 회피할 수 있는 프롬프트 기법도 제시되어야 합니다. 예를 들어, 코드는 수정해도 되돌릴 수 있으니 괜찮지만 데이터베이스는 그렇지 않은 경우도 많습니다. 특히 live 되고 있는 서비스라면 더욱 그렇습니다. 이러한 명확한 권한 구분이 없다면 오히려 생산성을 저하시킬 수도 있습니다.

두 번째로, 만들어진 코드를 어느정도는 이해할 수 있어야 합니다. 가벼운 랜딩페이지 정도라 하더라도 이해하고 쓰는 것과 모르고 쓰는 것은 유지보수에서 차이가 큽니다. 예를 들어, 태그를 알고, 개발자도구를 열고, 콘솔을 확인하는 등의 기본적인 학습이 되지 않은 상태에서는 프롬프트를 명확하게 작성하기 어렵습니다.

개발자라 한다면 AI가 개발한 그대로를 반영하지 않고 적어도 리뷰정도는 해보아야 합니다. 그렇지 않으면 유지보수하는 시간이 길어져 오히려 프로젝트 총 투입 시간은 더 들 수도 있습니다.

세 번째로, 배포에 대한 이해가 필요합니다. 배포까지 해주는 서비스가 나오고 있습니다. AI 풀스택이라고 합니다. 다만 이러한 서비스가 나오게 되면 플랫폼 종속적인 서비스가 나오기 때문에 프로젝트 규모, 지원, 회사 상황을 고려해보았을 때 적합하지 않을 수 있습니다. 따라서 AI가 모든 것을 다 해주는 순간이 온다고 하더라도, 배포환경과 배포 프로세스, CI/CD와 같은 이해와 구축이 앞으로도 중요할 것입니다.

네 번째로, 프로세스와 구조 등 PM이 하는 역할에 대한 이해가 필요합니다. 앞서 우리는 디렉터의 역할을 한다고 말씀드렸습니다. 따라서 PM이 하는 역할에 대한 이해가 되면, 좀 더 수월하게 AI와 업무를 할 수 있습니다. 스토리보드, 프로토타입, 웹 기획서, 디자인 등 각 단계별 산출물도 정리해두면 보다 견고한 프로세스를 정립할 수 있습니다. 다만 부분은 획일적인 정답이 없습니다. 이러한 단계를 거치지 않고, 요구사항 명세만으로도 충분히 수준 높은 결과물을 만들어 낼 수 있습니다.

다섯 번째로, 만약 창업을 하실 분들이라면 비즈니스와 법률 이해가 필요합니다. 이 부분은 이 책에서 다루지 않는 부분입니다. 가벼운 토이 프로젝트를 하실 분이면 상관이 없지만 실제 서비스로 런칭하기 위해서 알아야할 필수 지식들이 있습니다. 예를 들어, 채팅 서비스를 만들었는데 개발자가 채팅을 들여다보면 안되겠죠? 해당 데이터는 암호화 되어 있어야 할 것입니다. 이러한 법률적인 지식까지 이 책에서 모두 다루진 않습니다. 개인정보보호법, 정보통신망법 등 다양한 한국의 법을 이해하고, 런칭해야 합니다.

비즈니스 모델 등도 이 책에서 다루지 않습니다. 이 책은 '창업'을 위한 책이 아니라 '바이브 코딩'을 위한 책입니다. 물론 바이브 코딩으로 만든 서비스로 창업을 할 수 있습니다. 하지만 창업에는 기술 외에도 시장 분석, 고객 발굴, 투자 유치, 팀 빌딩, 마케팅 전략 등 수많은 요소가 필요합니다. 이런 부분들은 별도의 창업 관련 서적이나 강의를 통해 학습하시기를 권합니다.

4. 책에서 다루는 것

이 책은 위에서 언급한 것 중 서비스를 만드는 것에 집중합니다. 비개발자나 개발자가 아이디어를 실제 작동하는 서비스로 구현하는 과정, AI와 효과적으로 협업하는 방법, 프로젝트를 체계적으로 관리하는 노하우를 다룹니다.

또한 이 책은 단지 Claude Code의 사용법 뿐만 아니라 AI가 지금보다 2배, 3배 더 일을 잘 할 수 있는 환경을 가정해서 협업할 수 있는 부분을 작성하려 노력하였습니다. AI의 발전 속도는 너무나 빨라서 책이 출간되면 시장의 강자가 바뀌어 있을 수 있습니다. 또한 터미널이 아니라 무언가 대체되는 대체물이 나올 가능성이 있습니다. 브라우저나, VSCode의 Extension이요. 이러한 상황을 염두하고 글을 써내려갔습니다.

지금보다 AI가 2배 ~ 3배 더 좋아진다면 개발자든, 개발자가 아니든 AI와 소통하는 방법이 매우 중요하질 것입니다. 앞으로 AI가 더 발전하게 되면 생산된 Code의 자산가치가 급격히 하락하는 구간을 맞이하게 될 것이라 생각합니다. 프롬프트 자체가 자산이 되는 시대가 올 것이라 생각합니다.

이 책으로 앞으로를 함께 대비했으면 좋겠습니다.