바이브 코딩 실전 마스터클래스 소개

많은 입문자는 바이브 코딩을 “AI에게 코드를 시키는 방법” 정도로 이해합니다. 하지만 실제로 생산성을 만드는 것은 코드 생성 그 자체보다, 어떤 목표를 세웠는지, 어떤 제약을 정의했는지, 언제 검증할지를 미리 정해 두는 작업입니다. 그래서 이 챕터는 코드보다 먼저 목표와 원칙을 이야기합니다.

비전은 “무엇을 만들 것인가”를 정하고, 철학은 “어떤 방식으로 만들 것인가”를 정하며, 결과물은 “무엇이 남아야 작업이 끝난 것인가”를 정합니다. 이 세 가지가 없으면 AI는 빠르게 움직일 수는 있어도, 방향이 흔들리기 쉽습니다. 반대로 세 가지가 선명하면 프롬프트가 조금 서툴러도 전체 흐름은 안정됩니다.

강의에서는 가드레일이 있는 작업 루프를 소개합니다. 목표를 잡고, AI에게 맥락을 주고, 작은 단위로 구현하고, 사람이 검증하고, 배포 후 다시 반복하는 구조입니다. 중요한 점은 AI가 모든 결정을 대신하는 것이 아니라, 사람이 기준을 쥐고 AI는 속도를 높이는 역할을 맡는다는 것입니다.

초급자가 AI와 협업할 때 가장 자주 겪는 문제는 “같은 얘기를 계속 다시 해야 한다”는 것입니다. 대부분은 문서 역할을 분리하지 않았기 때문에 생깁니다. AGENTS.md는 작업 규칙과 제약 조건을 담아야 하고, PRD는 제품이 무엇을 해야 하는지와 왜 필요한지를 담아야 합니다.

AGENTS 문서에는 스타일, 작업 범위, 금지 사항, 검증 기준처럼 “어떻게 일할 것인가”가 들어갑니다. 반대로 PRD에는 사용자 문제, 성공 기준, 핵심 흐름, 범위, 우선순위처럼 “무엇을 만들 것인가”가 들어갑니다. 두 문서를 섞으면 AI는 규칙과 요구사항을 같은 층위의 정보로 읽어 혼동하기 쉽습니다.

이 챕터에서는 초급자도 바로 쓸 수 있는 문서 템플릿 구조를 소개합니다. 중요한 것은 문서를 길게 쓰는 것이 아니라, 이후의 구현과 검증을 흔들리지 않게 만드는 최소 구조를 갖추는 것입니다. 문서는 AI를 위한 설명이면서 동시에 나중에 스스로를 위한 체크포인트이기도 합니다.

초급자가 MVP에서 가장 많이 저지르는 실수 중 하나는, 아직 검증하지도 않은 아이디어에 너무 많은 기술을 붙이는 것입니다. 인증, 실시간 처리, 마이크로서비스, 복잡한 인프라가 필요해 보일 수 있지만, 실제로는 제품이 증명해야 할 핵심 가설 하나만 먼저 통과하면 되는 경우가 많습니다. 그래서 이 챕터는 “무엇이 멋진가”보다 “무엇이 충분한가”를 묻습니다.

강의에서는 프로젝트 형태에 따라 프런트엔드, 백엔드, 인프라 후보를 좁히는 법을 보여 줍니다. 랜딩 페이지 중심인지, 대시보드형인지, 콘텐츠 중심인지, 자동화 중심인지에 따라 최소 조합이 달라집니다. 같은 Next.js라도 어떤 문제를 풀기 위해 쓰는지에 따라 비용과 복잡도가 완전히 달라질 수 있습니다.

비용 판단도 단순 월 요금 비교가 아닙니다. 클라우드 서비스는 개발 속도를 사는 것이고, Self-hosted는 운영 책임을 사는 것입니다. 초급자에게 중요한 것은 월 10달러 차이보다, 그 기술 선택 때문에 구현과 검증 속도가 얼마나 느려지는지까지 함께 보는 시야입니다.

초급자에게 가장 위험한 아키텍처는 “복잡한 아키텍처”가 아니라 “설명할 수 없는 아키텍처”입니다. AI와 협업할 때도 마찬가지입니다. 화면, API, 데이터 계층이 어디서 나뉘는지 명확하지 않으면 구현 단위가 흐려지고, 테스트 기준도 함께 흐려집니다. 그래서 이 챕터는 3-tier 구조를 예시로 삼아 경계를 명확하게 잡는 법을 설명합니다.

식당 주문 MVP 예제에서는 고객용 UI, API routes 또는 server actions, 그리고 주문·테이블·메뉴 데이터를 관리하는 백엔드를 분리해서 봅니다. 이렇게 나누면 사용자가 겪는 흐름과 시스템 내부 로직을 같은 문장에 섞지 않을 수 있고, AI에게도 한 번에 하나의 책임만 설명하기 쉬워집니다.

또한 강의는 구현 단위를 어떻게 자를지를 함께 다룹니다. 한 번에 “주문 시스템 전체를 만들어 줘”라고 요청하는 대신, 메뉴 조회, 주문 생성, 상태 변경, 관리자 대시보드처럼 작은 단위로 쪼개야 AI의 결과도 읽기 쉬워지고 실패 시 수정도 쉬워집니다. 작은 작업 단위는 곧 더 나은 검증 단위이기도 합니다.

많은 초급자는 “화면이 뜨고 API가 응답하면 끝났다”고 생각합니다. 하지만 실제 배포 직전에는 최소한 어떤 흐름이 실제 사용자 기준으로 통과해야 하는지, 어떤 비밀값과 권한 설정이 안전한지, 문제가 생기면 어디서 바로 롤백할지까지 함께 확인해야 합니다. 이 챕터는 그런 출시 직전 판단 기준을 다룹니다.

검증은 단순히 테스트 툴을 돌리는 행위가 아닙니다. 가장 중요한 사용자 시나리오를 정하고, 사람이 직접 한 번 더 통과시켜 보고, 실패했을 때 어디가 깨졌는지 추적할 수 있는 로그와 메모를 남기는 것이 함께 필요합니다. 특히 AI가 만든 코드일수록 “겉으로는 되는 것 같지만 조건이 하나 빠진” 상태가 자주 나오기 때문에 직접 확인이 중요합니다.

보안 체크는 거대한 보안 감사를 의미하지 않습니다. MVP 단계에서는 비밀값 노출 방지, 권한 경계, 입력 검증, 외부 API 사용 방식처럼 가장 큰 사고를 만드는 지점부터 줄여 가면 됩니다. 강의는 이 체크리스트를 작고 실용적으로 유지하는 법을 설명합니다.