2강에서 개발 흐름을 먼저 잡아야 한다고 한 이유는, 프롬프트 작성에서도 그대로 이어집니다. AI 코딩 도구에 “앱 만들어줘”, “게시판 만들어줘”, “예약 서비스 만들어줘”라고 입력하면 뭔가 결과는 나옵니다. 문제는 그 결과가 내가 원한 서비스인지, 유지보수 가능한 구조인지, 실제로 실행되는 코드인지는 전혀 다른 이야기라는 점입니다.

바이브 코딩에서 프롬프트는 단순한 부탁 문장이 아니라 작업 지시서에 가깝습니다. ChatGPT, Claude Code, Cursor, Codex 모두 사용자의 말을 바탕으로 다음 작업을 예측합니다. 지시가 비어 있으면 AI는 빈칸을 추측으로 채웁니다. 이 추측이 많아질수록 결과물은 흔들립니다.

“만들어줘”가 망하는 이유: AI의 추측을 유발합니다

“할 일 관리 앱 만들어줘”라는 요청을 예로 들어보겠습니다. 사람 입장에서는 간단해 보이지만, AI 입장에서는 결정해야 할 것이 너무 많습니다.

웹앱인지 모바일앱인지, 로그인은 필요한지, 데이터는 브라우저에 저장할지 서버에 저장할지, 디자인은 어떤 느낌인지, 할 일에는 마감일이 있는지, 완료 상태만 있으면 되는지, 수정과 삭제가 필요한지 모두 불명확합니다.

이런 상태에서 AI는 대체로 “일반적인 예시”를 만듭니다. 가장 흔한 구조, 가장 무난한 UI, 가장 단순한 데이터 저장 방식을 임의로 선택합니다. 처음에는 그럴듯해 보이지만, 조금만 요구사항을 추가하면 구조가 꼬이기 쉽습니다.

예를 들어 처음에는 로컬 저장 방식으로 만들었는데, 나중에 “사용자별 로그인도 넣어줘”라고 하면 데이터 구조를 다시 바꿔야 합니다. 처음에는 단일 페이지로 만들었는데, 나중에 “관리자 화면도 필요해”라고 하면 라우팅과 권한 구조를 뒤늦게 얹어야 합니다. 바이브 코딩에서 가장 많은 시간이 낭비되는 지점이 바로 여기입니다. 처음 지시가 모호해서 AI가 잘못된 출발점을 잡는 경우입니다.

좋은 지시문의 구조: 맥락, 목표, 제약, 검증

좋은 프롬프트는 길기만 한 문장이 아닙니다. AI가 판단해야 할 범위를 줄여주는 문장입니다. 기본 구조는 네 가지로 나누면 충분합니다.

첫째, 맥락입니다. 지금 어떤 서비스를 만들고 있는지, 사용자는 누구인지, 현재 프로젝트 상태가 어떤지 알려줘야 합니다. 이미 만든 코드가 있다면 “기존 구조를 유지해 달라”는 말도 맥락에 포함됩니다.

둘째, 목표입니다. 이번 요청으로 무엇을 완성해야 하는지 명확해야 합니다. “예쁘게 만들어줘”보다 “회원가입 화면에서 이메일, 비밀번호, 닉네임을 입력받고 제출 버튼을 누르면 유효성 검사를 수행하게 해줘”가 훨씬 낫습니다.

셋째, 제약입니다. 사용하지 말아야 할 기술, 유지해야 할 파일 구조, 변경하면 안 되는 기능, 디자인 기준, 응답 방식 등이 여기에 들어갑니다. AI에게 자유를 많이 주는 것이 항상 좋은 것은 아닙니다. 특히 Cursor나 Claude Code처럼 실제 파일을 수정하는 도구에서는 제약이 중요합니다.

넷째, 검증입니다. 작업이 끝난 뒤 무엇을 확인해야 하는지 알려주는 단계입니다. “실행 방법도 함께 알려줘”, “변경된 파일 목록을 요약해줘”, “기존 기능이 깨질 가능성이 있는 부분을 짚어줘”처럼 결과 확인 기준을 넣으면 실패 확률이 줄어듭니다.

프롬프트를 구조화하면 다음과 같은 형태가 됩니다.

맥락:
현재 React로 만든 할 일 관리 웹앱을 작업 중입니다. 기존에는 할 일 추가와 완료 처리 기능만 있습니다.

목표:
할 일 항목에 마감일을 추가하고, 목록에서 마감일이 함께 보이게 해주세요.

제약:
기존 할 일 추가 기능과 완료 처리 기능은 깨지지 않아야 합니다.
새로운 라이브러리는 추가하지 말아주세요.
가능하면 현재 컴포넌트 구조를 유지해주세요.

검증:
수정한 파일 목록을 알려주고, 브라우저에서 어떤 동작을 확인해야 하는지 체크리스트로 작성해주세요.

이 정도만 작성해도 “마감일 기능 추가해줘”보다 결과가 훨씬 안정적입니다.

나쁜 지시문 vs 좋은 지시문 예시

나쁜 지시문은 대부분 짧고 편합니다. 하지만 편한 만큼 AI가 추측해야 할 내용이 늘어납니다.

로그인 기능 만들어줘.

이 요청에는 중요한 정보가 거의 없습니다. 이메일 로그인을 말하는지, 소셜 로그인을 말하는지, 백엔드가 있는지, 임시 화면만 필요한지, 실제 인증까지 필요한지 알 수 없습니다. AI는 임의로 구조를 만들 가능성이 높습니다.

같은 요청을 조금 더 좋은 형태로 바꾸면 이렇게 됩니다.

현재 Next.js로 만든 웹앱에 로그인 화면 UI를 추가하려고 합니다.

목표:
이메일과 비밀번호를 입력받는 로그인 페이지를 만들어주세요.
아직 실제 서버 인증은 연결하지 않고, 입력값 유효성 검사와 화면 구성까지만 구현해주세요.

제약:
새로운 인증 라이브러리는 설치하지 말아주세요.
기존 라우팅 구조를 유지해주세요.
비밀번호는 8자 이상일 때만 제출 가능하게 해주세요.

검증:
빈 값 제출, 잘못된 이메일 형식, 8자 미만 비밀번호 입력 시 각각 어떤 메시지가 보이는지 확인할 수 있게 설명해주세요.

여기서 핵심은 “로그인 기능”이라는 큰 덩어리를 “로그인 화면 UI”, “유효성 검사”, “서버 인증 제외”로 좁혔다는 점입니다. AI는 이제 실제 인증 시스템을 마음대로 붙이지 않아도 됩니다.

디자인 요청도 마찬가지입니다.

더 예쁘게 만들어줘.

이 문장은 거의 실패하기 쉽습니다. “예쁘다”는 기준이 사람마다 다르기 때문입니다. 대신 원하는 결과를 눈에 보이게 설명해야 합니다.

현재 대시보드 화면이 너무 빽빽해 보입니다.

목표:
카드형 레이아웃으로 여백을 늘리고, 주요 지표가 먼저 보이도록 화면을 정리해주세요.

원하는 느낌:
B2B SaaS 관리자 페이지처럼 차분하고 깔끔한 분위기였으면 합니다.
배경은 밝은 회색 계열, 카드는 흰색, 강조 색상은 파란색 계열로 사용해주세요.

제약:
기능 동작은 변경하지 말고 스타일과 레이아웃만 수정해주세요.
차트 라이브러리나 UI 라이브러리는 새로 추가하지 말아주세요.

검증:
변경 후 어떤 영역의 여백, 색상, 정렬이 바뀌었는지 설명해주세요.

이렇게 쓰면 AI가 “화려한 랜딩페이지”가 아니라 “차분한 관리자 화면”에 맞춰 작업할 가능성이 높아집니다.

한 번에 하나씩, 단계별로 쪼개 요청합니다

바이브 코딩에서 욕심을 내면 프롬프트가 길어지고, 프롬프트가 길어지면 작업 범위가 흐려질 수 있습니다. “회원가입, 로그인, 대시보드, 결제, 관리자 페이지까지 한 번에 만들어줘” 같은 요청은 초반에는 빠르게 보이지만, 실제로는 오류를 찾기 어려운 결과를 만들기 쉽습니다.

작업은 작은 단위로 나누는 편이 안전합니다. 예를 들어 예약 서비스를 만든다면 한 번에 전체를 요청하기보다 다음처럼 나눌 수 있습니다.

1단계:
예약 서비스의 핵심 화면 목록과 사용자 흐름을 먼저 설계해주세요.
아직 코드는 작성하지 말고 화면 이름, 목적, 이동 흐름만 정리해주세요.

2단계:
예약 목록 화면 UI만 구현해주세요.
데이터는 임시 배열을 사용하고, 서버 연동은 하지 말아주세요.

3단계:
예약 상세 화면을 추가하고, 목록에서 상세 화면으로 이동할 수 있게 연결해주세요.

4단계:
예약 생성 폼을 만들고, 입력값 유효성 검사를 추가해주세요.

5단계:
현재까지 구현된 기능을 기준으로 빠진 상태 처리와 오류 가능성을 점검해주세요.

여기서 중요한 점은 “코드 작성 전 설계”, “UI 구현”, “화면 연결”, “입력 처리”, “검수”를 분리했다는 것입니다. ChatGPT로 먼저 구조를 잡고, Cursor나 Claude Code에서 파일 수정을 진행하고, Codex로 특정 구현을 보완하는 식으로 역할을 나누기도 좋습니다. 다만 도구를 바꿔도 원칙은 같습니다. 요청 단위가 작을수록 확인이 쉽고, 문제가 생겼을 때 되돌리기도 쉽습니다.

특히 코드 수정 도구를 사용할 때는 “전체를 고쳐줘”보다 “이 파일의 이 컴포넌트에서 이 동작만 수정해줘”가 안전합니다.

src/components/TodoList.tsx 파일의 TodoList 컴포넌트만 수정해주세요.

목표:
완료된 할 일은 목록 하단으로 이동시키고, 텍스트에 취소선을 적용해주세요.

제약:
TodoItem 컴포넌트의 props 구조는 변경하지 말아주세요.
할 일 추가, 삭제 기능은 그대로 유지해주세요.

검증:
완료 버튼을 눌렀을 때 정렬 순서와 스타일이 어떻게 바뀌는지 설명해주세요.

파일명이나 컴포넌트명을 모르는 상태라면 먼저 “현재 구조를 분석하고 수정 계획만 제시해줘. 아직 파일은 수정하지 마”라고 요청하는 편이 좋습니다. AI가 곧바로 코드를 바꾸기 전에 어떤 접근을 하려는지 확인할 수 있습니다.

원하는 결과를 구체적으로 묘사합니다

좋은 프롬프트는 “무엇을 만들지”뿐 아니라 “어떤 상태가 성공인지”를 포함합니다. 성공 기준이 없으면 AI가 만든 결과를 평가하기 어렵습니다.

예를 들어 “검색 기능 만들어줘”보다 아래 요청이 더 명확합니다.

상품 목록 화면에 검색 기능을 추가해주세요.

동작 기준:
검색창에 키워드를 입력하면 상품명에 해당 키워드가 포함된 항목만 목록에 표시되어야 합니다.
검색어가 비어 있으면 전체 상품이 보여야 합니다.
대소문자는 구분하지 않게 처리해주세요.
검색 결과가 없으면 "검색 결과가 없습니다" 문구를 보여주세요.

제약:
서버 검색이 아니라 현재 화면에 로드된 상품 배열에서 필터링해주세요.
기존 상품 카드 UI는 변경하지 말아주세요.

검증:
"apple", "APPLE", 빈 문자열, 존재하지 않는 단어를 입력했을 때 각각 어떤 결과가 나오는지 확인 방법을 적어주세요.

이 요청에는 구현 기준과 테스트 기준이 함께 들어 있습니다. AI가 코드를 작성한 뒤에도 사용자가 바로 확인할 수 있습니다.

또 하나 유용한 방식은 “하지 말아야 할 것”을 쓰는 것입니다. 초보자는 원하는 것만 쓰는 경우가 많은데, 원하지 않는 변경을 막는 문장도 매우 중요합니다.

다음 작업에서는 스타일만 수정해주세요.
기능 로직, 상태 관리 방식, API 호출 코드는 변경하지 말아주세요.

또는 이런 식으로 범위를 제한할 수 있습니다.

아직 데이터베이스 연결은 하지 말아주세요.
우선 화면에서 사용할 임시 데이터 구조와 UI만 만들어주세요.

이런 제약은 특히 초기 기획이 완전히 굳지 않았을 때 유용합니다. 처음부터 데이터베이스, 인증, 배포까지 한꺼번에 붙이면 수정 비용이 커질 수 있기 때문입니다.

프롬프트를 잘 쓴다는 것은 말을 길게 하는 기술이 아닙니다. AI가 추측하지 않아도 되도록 필요한 판단 기준을 제공하는 작업입니다. 맥락을 주고, 목표를 좁히고, 제약을 걸고, 검증 기준을 붙이면 “만들어줘” 한마디보다 훨씬 안정적인 결과를 얻을 수 있습니다. 바이브 코딩의 속도는 프롬프트를 대충 쓸 때가 아니라, 작업을 작게 나누고 원하는 결과를 정확히 말할 때 가장 잘 살아납니다.