1강에서 다룬 핵심이 “AI가 대신 다 만들어준다”가 아니라 “사람이 방향을 잡고 AI가 구현을 빠르게 돕는다”였다면, 2강의 핵심은 그 방향이 어떤 흐름 위에서 움직이는지 이해하는 것입니다. 바이브 코딩을 시작할 때 가장 흔한 실수는 곧바로 Cursor, Claude Code, Codex, ChatGPT에 “앱 만들어줘”라고 입력하는 것입니다. 운이 좋으면 그럴듯한 결과가 나오지만, 조금만 수정하려 해도 어디를 건드려야 하는지 알기 어려워집니다.

개발은 코드를 쓰는 행위 하나로 끝나지 않습니다. 무엇을 만들지 정하고, 현재 프로젝트 구조를 파악하고, AI에게 작업을 지시하고, 생성된 코드를 확인하고, 문제가 있으면 다시 수정 요청을 하는 과정이 반복됩니다. 마지막에는 만든 결과물을 실제 사용자가 접근할 수 있는 곳에 올리는 배포 단계가 필요합니다.

1. 개발은 코딩만이 아니다: 기획부터 배포까지 한눈에

서비스를 만든다는 말은 보통 다음 흐름을 포함합니다.

기획 → 구조 파악 → 작업 지시 → 코드 수정 → 검수 → 배포

이 순서를 꼭 한 번만 지나가는 것은 아닙니다. 실제 작업에서는 “작업 지시 → 코드 수정 → 검수”가 여러 번 반복됩니다. 버튼 하나를 추가할 때도, 로그인 기능을 붙일 때도, 화면 문구를 바꿀 때도 이 루프가 계속 돌아갑니다.

AI 코딩 도구는 이 흐름 중 특히 “작업 지시”와 “코드 수정”을 강하게 도와줍니다. Cursor는 프로젝트 안의 파일을 보며 수정 제안을 할 수 있고, Claude Code나 Codex 계열 도구는 터미널과 코드베이스를 함께 다루는 방식으로 작업을 진행할 수 있습니다. ChatGPT는 기획 정리, 요구사항 문장화, 오류 메시지 해석, 검수 체크리스트 작성에 유용합니다.

하지만 AI가 강력해질수록 사용자의 역할도 더 중요해집니다. AI는 사용자가 원하는 결과를 추측할 수는 있어도, 사업 목적이나 사용자 상황, 우선순위까지 정확히 알지는 못합니다. “무엇이 맞는 결과인지”를 판단하는 기준은 사람이 먼저 세워야 합니다.

2. 기획: 무엇을 만들지 먼저 정의하기

기획은 거창한 문서 작업이 아닙니다. 처음에는 아래 네 가지 질문에 답하는 정도면 충분합니다.

첫째, 누가 사용할 서비스인가.

둘째, 사용자는 어떤 문제를 해결하려고 들어오는가.

셋째, 첫 화면에서 무엇을 할 수 있어야 하는가.

넷째, 이번 작업에서 반드시 완성해야 할 범위는 어디까지인가.

예를 들어 “할 일 관리 앱”을 만든다고 하면 너무 넓습니다. AI도 넓게 해석합니다. 어떤 AI는 로그인부터 만들고, 어떤 AI는 데이터베이스를 붙이고, 어떤 AI는 디자인부터 구성할 수 있습니다. 이럴 때는 범위를 줄여야 합니다.

좋은 기획 문장은 이런 형태에 가깝습니다.

“로그인 없이 사용할 수 있는 간단한 할 일 관리 웹앱을 만든다. 사용자는 할 일을 추가하고, 완료 처리하고, 삭제할 수 있다. 새로고침해도 목록이 유지되면 좋지만, 이번 작업에서는 화면 동작이 먼저 완성되는 것을 우선한다.”

이 정도만 정리해도 AI의 답변 품질이 크게 달라집니다. 기능의 우선순위가 보이고, 당장 만들지 않아도 되는 부분이 분리되기 때문입니다.

반대로 피해야 할 지시는 너무 추상적인 문장입니다.

“예쁘고 완성도 높은 생산성 앱 만들어줘.”

이 문장은 사람이 보기에는 자연스럽지만, 개발 작업으로 바꾸기에는 정보가 부족합니다. 예쁜 디자인이 무엇인지, 생산성 앱의 핵심 기능이 무엇인지, 완성도 기준이 어디인지 정해져 있지 않습니다.

3. 구조 파악: AI가 프로젝트를 이해하게 하기

이미 만들어진 프로젝트를 수정할 때는 구조 파악이 먼저입니다. 사람도 처음 보는 건물에 들어가면 방 배치부터 확인하듯, AI도 프로젝트의 파일 구조와 역할을 알아야 안정적으로 수정할 수 있습니다.

초보 입장에서 모든 파일을 직접 이해할 필요는 없습니다. 다만 최소한 다음 정도는 구분할 수 있어야 합니다.

화면을 담당하는 파일이 어디에 있는지.

스타일을 담당하는 파일이 어디에 있는지.

데이터를 저장하거나 불러오는 로직이 어디에 있는지.

설정 파일이 어디에 있는지.

실행과 배포에 관련된 파일이 무엇인지.

Cursor나 Claude Code 같은 도구를 사용할 때도 “이 프로젝트 구조를 먼저 요약해줘”라고 요청하면 도움이 됩니다. 단, 요약을 받은 뒤 그대로 믿고 넘어가기보다는 실제 파일명과 폴더명을 함께 확인하는 습관이 필요합니다. AI가 프로젝트를 제대로 읽지 못했거나, 비슷한 일반 구조를 바탕으로 추측할 때도 있기 때문입니다.

작업을 시작하기 전에는 이런 식의 요청이 적절합니다.

“이 프로젝트의 폴더 구조를 기준으로, 주요 파일이 어떤 역할을 하는지 요약해줘. 아직 코드는 수정하지 말고 구조 설명만 해줘.”

이 요청의 장점은 명확합니다. 바로 코드를 바꾸지 않게 막고, 먼저 이해 단계에 머무르게 합니다. 바이브 코딩에서 중요한 것은 AI에게 일을 시키는 속도만이 아니라, 지금 어떤 단계의 일을 시키고 있는지 구분하는 능력입니다.

4. 작업 지시 → 코드 수정 → 검수의 반복 루프

기획과 구조 파악이 끝나면 실제 수정이 시작됩니다. 이때도 한 번에 큰 기능을 전부 맡기는 것보다 작은 단위로 나누는 편이 안전합니다.

예를 들어 할 일 관리 앱을 만든다면 순서를 나눌 수 있습니다.

1. 할 일 입력창과 추가 버튼 만들기

2. 입력한 할 일이 목록에 보이게 하기

3. 완료 상태를 바꿀 수 있게 하기

4. 삭제 버튼 추가하기

5. 새로고침 후 유지 여부 검토하기

이렇게 나누면 문제가 생겼을 때 원인을 찾기 쉽습니다. “방금 추가한 삭제 기능 이후에 오류가 생겼다”처럼 범위가 좁아지기 때문입니다.

AI에게 작업을 지시할 때는 세 가지를 함께 전달하는 것이 좋습니다.

현재 상태: 지금 어떤 화면 또는 기능이 있는지

원하는 변경: 무엇을 추가하거나 바꾸고 싶은지

제약 조건: 건드리지 말아야 할 부분이나 유지해야 할 동작

예시는 다음과 같습니다.

“현재 할 일 목록이 화면에 표시됩니다. 여기에 각 항목별 삭제 버튼을 추가하고 싶습니다. 기존 추가 기능과 완료 처리 기능은 유지해 주세요. 관련 파일을 수정하기 전에 어떤 파일을 바꿀지 먼저 설명해 주세요.”

여기서 중요한 문장이 “먼저 설명해 주세요”입니다. AI가 바로 수정하는 방식도 빠르지만, 초보 단계에서는 수정 계획을 먼저 받는 편이 안전합니다. 계획을 보고 이상한 부분이 있으면 그 자리에서 막을 수 있습니다.

코드 수정이 끝났다면 검수가 이어집니다. 검수는 전문가만 하는 일이 아닙니다. 만든 사람이 직접 사용해 보면서 요구사항대로 동작하는지 확인하는 과정입니다.

가장 기본적인 검수 질문은 다음과 같습니다.

원래 요청한 기능이 실제로 동작하는가.

기존에 되던 기능이 망가지지 않았는가.

오류 메시지가 화면이나 콘솔에 나타나지 않는가.

새로 추가된 기능이 너무 복잡하거나 불필요하지 않은가.

모바일 화면처럼 다른 환경에서도 크게 깨지지 않는가.

AI가 코드를 수정한 뒤 “완료했습니다”라고 말해도 검수는 생략하지 않는 편이 좋습니다. AI는 문법적으로 그럴듯한 코드를 만들 수 있지만, 실제 사용 흐름까지 항상 정확히 보장하지는 못합니다. 특히 버튼 클릭, 입력값 처리, 저장 여부, 화면 전환처럼 사용자가 직접 만지는 부분은 반드시 확인해야 합니다.

5. 배포: 완성한 결과물을 세상에 내보내기

로컬 환경이나 에디터 안에서만 실행되는 서비스는 아직 사용자에게 전달된 상태가 아닙니다. 배포는 만든 결과물을 외부에서 접근 가능한 주소로 올리는 단계입니다. 웹서비스라면 Vercel, Netlify, Render, Railway 같은 배포 플랫폼이 자주 사용되는 것으로 알려져 있습니다. 어떤 도구를 선택할지는 프로젝트 종류와 기술 스택에 따라 달라집니다.

초보 단계에서는 배포를 “개발의 마지막에 갑자기 등장하는 어려운 작업”으로 생각하기 쉽습니다. 하지만 흐름상으로는 자연스러운 마지막 단계입니다. 기획한 기능이 있고, 코드가 수정되었고, 검수를 통과했다면 이제 다른 사람이 접속할 수 있게 만드는 것입니다.

배포 전에 확인할 항목도 있습니다.

실행 오류가 없는지.

필요한 환경 변수가 빠지지 않았는지.

로컬에서만 동작하는 설정이 포함되어 있지 않은지.

테스트용 문구나 임시 버튼이 남아 있지 않은지.

사용자에게 보여도 되는 상태인지.

배포 이후에도 작업은 완전히 끝난 것이 아닐 수 있습니다. 실제 주소에서 다시 한 번 접속해 보고, 주요 기능을 눌러 보고, 화면이 예상대로 보이는지 확인해야 합니다. 로컬에서는 잘 되던 기능이 배포 환경에서 다르게 동작하는 경우도 있기 때문입니다.

바이브 코딩을 잘한다는 것은 AI에게 멋진 프롬프트 한 줄을 던지는 능력만 뜻하지 않습니다. 만들려는 것을 작게 정의하고, 프로젝트 구조를 파악하고, AI에게 단계별로 지시하고, 결과를 검수하고, 배포까지 이어가는 전체 흐름을 다루는 능력에 가깝습니다. 이 흐름을 알고 있으면 도구가 바뀌어도 흔들리지 않습니다. ChatGPT를 쓰든, Cursor를 쓰든, Claude Code나 Codex를 쓰든 작업의 기본 순서는 크게 달라지지 않습니다.

다음 작업을 시작할 때는 “무슨 코드를 써야 하지?”보다 먼저 “지금 나는 개발 흐름 중 어느 단계에 있지?”를 확인해 보시면 좋습니다. 그 질문 하나만으로도 AI에게 맡길 일과 사람이 판단할 일이 훨씬 선명해집니다.