2. 바이브코딩에서 AI에게 잘 말하는 법: 초보자 프롬프트 작성 가이드

왜 프롬프트가 중요한가

바이브코딩을 처음 해보면 이런 장면을 자주 겪습니다. AI에게 “간단한 앱 하나 만들어줘”라고 말했는데, 생각보다 너무 복잡한 결과가 나오거나, 겉보기엔 그럴듯한데 정작 내가 원한 핵심 기능은 빠져 있는 경우입니다. 이때 많은 사람이 먼저 모델 성능부터 의심합니다. 물론 도구마다 차이는 있습니다. 하지만 초보자 구간에서는 의외로 프롬프트, 즉 AI에게 주는 요청문이 결과를 흔드는 경우가 더 많습니다.

여기서 중요한 건 프롬프트를 무슨 비밀 주문처럼 생각하지 않는 것입니다. 입문자일수록 “특별한 표현을 써야 하나?”, “영어로 써야 더 잘되나?” 같은 쪽으로 먼저 신경을 쓰기 쉽습니다. 그런데 실제로는 말의 화려함보다 요구사항이 얼마나 분명한가가 더 중요합니다. 무엇을 만들고 싶은지, 어디까지가 이번 범위인지, 어떤 것은 일부러 빼고 싶은지, 이미 어디까지 해봤는지를 또렷하게 적어주는 편이 훨씬 도움이 됩니다.

쉽게 말하면 프롬프트는 글짓기라기보다 작업 지시서에 가깝습니다. 사람이 함께 일할 때도 “대충 예쁘게 만들어 주세요”보다 “모바일에서도 보기 편한 한 화면짜리 체크리스트를 원하고, 로그인 기능은 이번에는 빼고 싶다”가 훨씬 덜 헷갈리듯, AI와의 작업도 비슷합니다.

바이브코딩에서 이게 더 중요하게 느껴지는 이유도 분명합니다. 직접 코드를 한 줄 한 줄 쓰지 않는 대신, 방향을 잡는 역할이 훨씬 커지기 때문입니다. 결국 무엇을 타이핑하느냐가 곧 무엇을 만들게 하느냐에 가까워집니다.

핵심 한 줄
좋은 프롬프트는 말을 멋지게 쓰는 기술이 아니라, 만들고 싶은 결과의 범위와 조건을 분명하게 적는 습관에 가깝다.

---

좋은 프롬프트에 꼭 들어가는 6가지

좋은 프롬프트를 쓸 때 처음부터 길게 쓸 필요는 없습니다. 다만 아래 정보가 빠지면 AI가 빈칸을 자기 식으로 채우기 시작합니다. 그때부터 결과가 흔들립니다. 특히 초보자라면 아래 여섯 가지 정도만 의식해도 체감이 꽤 큽니다.

요소	왜 필요한가	짧은 예시
무엇을 만들지	결과물의 중심이 되는 목표를 분명하게 잡아준다	오늘 할 일을 추가하고 체크할 수 있는 단순한 웹앱
어디서 실행할지	웹페이지인지, 파이썬 스크립트인지에 따라 구조가 달라진다	브라우저에서 바로 실행되는 단일 HTML 파일
꼭 필요한 기능	핵심 기능을 먼저 고정해 불필요한 확장을 줄인다	추가, 삭제, 완료 체크만 있으면 된다
이번에는 뺄 것	로그인, 서버, 통계처럼 범위를 키우는 요소를 미리 막아준다	회원가입, 데이터베이스, 공유 기능은 넣지 말아줘
화면이나 사용 조건	초보자가 실제로 확인하기 쉬운 형태로 결과를 좁혀준다	모바일에서도 버튼이 너무 작지 않게 해줘
현재 상태나 문제	이미 만든 결과를 수정할 때 맥락을 제공한다	추가 버튼은 보이는데 빈 값도 그대로 등록된다

이 여섯 가지를 항상 전부 길게 적을 필요는 없습니다. 다만 적어도 무엇을 만들지, 꼭 필요한 기능, 이번에는 뺄 것 이 세 가지는 초보자에게 거의 필수에 가깝습니다. 이 셋만 분명해져도 “너무 많은 기능이 한꺼번에 붙는 문제”를 상당히 줄일 수 있습니다.

예를 들어 아래 두 요청은 비슷해 보여도 결과가 달라지기 쉽습니다.

간단한 가계부 앱 만들어줘.

브라우저에서 바로 실행되는 아주 단순한 가계부 웹앱을 만들어줘. 수입/지출 항목 입력, 금액 입력, 총합 표시만 있으면 돼. 회원가입, 차트, 통계 기능은 이번엔 넣지 말아줘. 초보자도 보기 쉽게 한국어 버튼 이름을 써줘.

두 번째 요청이 더 길어서 좋은 것이 아닙니다. 결정해야 할 핵심이 더 선명하기 때문입니다. AI는 이런 식으로 범위가 주어질수록 덜 흔들립니다.

• 무엇을 만들지는 한 문장으로 쓰는 편이 좋다.
• 핵심 기능은 처음엔 1~3개 정도로 줄이는 편이 낫다.
• 빼고 싶은 것을 같이 적으면 결과가 과해지는 걸 막기 쉽다.
• 현재 문제를 쓸 때는 “안 돼요”보다 “어떻게 안 되는지”를 적는 편이 낫다.

---

초보자가 자주 하는 요청 실수

프롬프트가 어렵게 느껴지는 이유는, 대부분 처음부터 엄청 못 써서가 아닙니다. 오히려 애매한 표현을 아무렇지 않게 쓰는 습관 때문에 결과가 흐트러지는 경우가 많습니다. 아래는 초보자에게 특히 자주 보이는 실수입니다.

자주 하는 요청	왜 문제가 되는가	조금 더 나은 요청
예쁘게 만들어줘	예쁘다는 기준이 너무 넓어서 AI가 임의로 판단한다	흰 배경에 단순한 카드 형태로, 글자는 너무 작지 않게 해줘
할 일 앱 만들어줘. 로그인, 달력, 통계, 공유도 넣어줘	처음부터 범위가 너무 커져서 초보자가 통제하기 어려워진다	먼저 추가, 삭제, 완료 체크만 되는 기본 버전부터 만들어줘
오류 고쳐줘	어떤 동작에서 무엇이 잘못됐는지 정보가 없다	입력 없이 추가 버튼을 누르면 빈 항목이 생성돼. 이 경우는 등록되지 않게 해줘
아까 그거 기준으로 수정해줘	도구가 현재 맥락을 정확히 잡지 못하면 엉뚱한 방향으로 간다	지금 코드에서 디자인은 유지하고, 삭제 버튼만 오른쪽으로 옮겨줘
더 똑똑하게 만들어줘	무엇이 더 좋아지는지 기준이 불명확하다	엔터 키를 눌러도 항목이 추가되게 해줘

이 표를 보면 감이 옵니다. 문제는 표현이 짧아서가 아니라, 판단 기준이 빠져 있다는 점입니다. “좋게”, “편하게”, “세련되게”, “똑똑하게” 같은 말은 사람끼리 대화할 때도 해석이 갈립니다. AI와 작업할 때는 더 그렇습니다.

특히 아래 세 가지는 의식적으로 줄이는 편이 좋습니다.

1. 형용사만 많은 요청
   예쁜, 깔끔한, 세련된 같은 말만 많고 실제 조건은 없는 경우
2. 한 번에 너무 많은 기능을 넣는 요청
   초안과 완성본을 한 번에 얻으려다 구조가 복잡해지는 경우
3. 현재 문제가 보이지 않는 요청
   어느 버튼에서, 어떤 입력으로, 무엇이 잘못되는지 설명이 없는 경우

오해 포인트
프롬프트를 잘 쓴다는 것은 문장을 그럴듯하게 길게 쓰는 일이 아니다. 애매한 단어를 줄이고, 확인 가능한 조건으로 바꾸는 일에 더 가깝다.

---

한 번에 시키지 말고 단계로 나누는 법

초보자가 바이브코딩에서 가장 빨리 지치는 이유 중 하나는, 첫 요청에 너무 많은 걸 담으려 하기 때문입니다. 하지만 실제로는 한 번에 완성본을 받으려는 방식보다 작동하는 기본 버전에서 조금씩 수정하는 방식이 훨씬 안정적입니다. AI도 이 흐름에서 더 덜 흔들립니다.

예를 들어 첫 프로젝트로 자주 선택하는 할 일 체크리스트를 만든다고 해보겠습니다. 아래처럼 4단계로 나누면 훨씬 다루기 쉽습니다.

1단계: 기본 동작만 있는 초안 만들기

처음에는 “돌아가는지”만 확인하는 버전이 중요합니다. 여기서 디자인 욕심을 많이 넣으면 오히려 핵심 기능이 흐려집니다.

브라우저에서 바로 실행되는 단일 HTML 파일로 아주 간단한 할 일 체크리스트를 만들어줘. 기능은 항목 추가, 완료 체크, 삭제만 있으면 돼. 로그인, 서버, 회원 기능은 넣지 말아줘. 먼저 동작하는 기본 버전부터 보여줘.

이 요청의 장점은 범위가 단순하다는 점입니다. 무엇을 만들지, 필수 기능이 무엇인지, 무엇을 빼는지가 한 번에 들어 있습니다.

2단계: 저장 기능처럼 핵심 보완 추가하기

기본 기능이 돌아간다는 걸 확인했다면, 그다음에야 한 가지씩 추가합니다. 예를 들어 새로고침하면 목록이 사라지는 문제가 있다면 그때 저장 기능을 붙이면 됩니다.

지금 버전에서 기존 기능은 유지하고, 새로고침해도 할 일 목록이 유지되도록 간단한 저장 기능을 추가해줘. 다른 구조는 크게 바꾸지 말아줘.

여기서 중요한 표현은 “기존 기능은 유지하고”입니다. 초보자가 수정 요청을 할 때 자주 놓치는 문장인데, 이미 잘 되는 부분을 괜히 다시 크게 바꾸지 않게 도와줍니다.

3단계: 예외 상황 처리하기

겉으로는 동작해 보여도, 예외 상황이 남아 있으면 실제로 써보는 순간 어색해집니다. 빈 입력, 너무 긴 입력, 중복 입력처럼 눈에 띄는 지점부터 잡는 편이 좋습니다.

입력창이 비어 있을 때 추가 버튼을 누르면 빈 항목이 생성되지 않게 해줘. 사용자에게는 짧은 안내 문구를 보여줘. 기존 UI는 최대한 그대로 유지해줘.

이 단계가 중요한 이유는, 바이브코딩이 “만들기”에서 끝나지 않고 검토와 보완으로 이어져야 한다는 감각을 익히게 해주기 때문입니다.

4단계: 마지막으로 화면을 다듬기

처음부터 화면을 너무 공들여 잡기보다, 기능이 어느 정도 안정된 뒤에 다듬는 편이 낫습니다.

모바일 화면에서 입력창과 버튼 간격이 너무 좁지 않게 해줘. 전체 디자인은 단순한 카드 형태로 정리하고, 글자는 너무 작지 않게 해줘. 기존 기능 로직은 바꾸지 말아줘.

이 순서를 지키면 “무엇을 바꾸다가 어디가 깨졌는지”를 비교하기 쉬워집니다. 반대로 기능과 저장과 예외 처리와 디자인을 한 번에 다 넣으려 하면, 잘못됐을 때 원인을 찾기 어렵습니다.

• 처음에는 동작하는 최소 버전을 만든다.
• 그다음에 핵심 보완 기능을 하나 추가한다.
• 이후 예외 처리를 붙인다.
• 마지막에 디자인과 사용성을 다듬는다.

---

복붙해서 쓰는 실전 프롬프트 템플릿

입문자 입장에서는 결국 “지금 당장 어떤 형식으로 쓰면 되는지”가 가장 궁금할 수 있습니다. 아래 템플릿은 화려한 비법이 아니라, 초보자가 기본 구조를 놓치지 않게 도와주는 최소한의 틀입니다. 괄호 안만 바꿔도 꽤 여러 상황에 적용할 수 있습니다.

1. 새 프로젝트를 시작할 때

(어디서 실행되는지)에서 돌아가는 (무엇을 만드는지)를 만들어줘.

꼭 필요한 기능:

(기능 1)

(기능 2)

(기능 3)

이번에는 넣지 않을 것:

(제외할 요소 1)

(제외할 요소 2)

추가 조건:

(모바일 여부, 언어, 화면 분위기 등)

먼저 동작하는 기본 버전부터 보여줘.

예를 들면 이렇게 바꿔 쓸 수 있습니다.

브라우저에서 바로 실행되는 단일 HTML 파일로 아주 간단한 지출 기록 웹앱을 만들어줘. 꼭 필요한 기능: 1) 항목 이름 입력 2) 금액 입력 3) 총합 표시 이번에는 넣지 않을 것: - 회원가입 - 차트 - 통계 대시보드 추가 조건: - 한국어 버튼 이름을 써줘 - 모바일에서도 입력창과 버튼이 너무 작지 않게 해줘 - 먼저 동작하는 기본 버전부터 보여줘.

2. 오류를 수정하고 싶을 때

지금 코드에서 (어떤 동작)을 하면 (어떤 문제가 생긴다).

원하는 동작은 (어떻게 되어야 하는지)다.
기존의 (유지하고 싶은 부분)은 그대로 두고,
문제가 되는 부분만 수정해줘.
가능하면 왜 이런 문제가 생겼는지도 짧게 설명해줘.

이 템플릿은 “오류 고쳐줘”보다 훨씬 낫습니다. 최소한 문제 상황, 원하는 결과, 유지하고 싶은 것이 들어가 있기 때문입니다.

3. 기존 결과를 조금만 바꾸고 싶을 때

현재 결과에서 (무엇)은 유지하고, (무엇)만 바꿔줘.

구체적으로는:

(변경 1)

(변경 2)

다른 구조나 기능은 가능하면 건드리지 말아줘.

이 템플릿은 디자인 수정이나 부분 기능 수정에 특히 유용합니다. 초보자는 수정 요청을 할 때 자꾸 전체를 다시 쓰게 만드는 표현을 쓰기 쉬운데, 그러면 이미 되던 부분까지 흔들릴 수 있습니다.

4. 설명을 먼저 받고 싶을 때

바로 코드를 다시 쓰기보다, 지금 구조에서 어떤 점이 문제인지 먼저 짧게 설명해줘. 그다음 최소 수정으로 고칠 수 있는 방향을 제안해줘. 이후에 수정된 코드를 보여줘.

이 방식은 코드를 잘 모르는 입문자에게 생각보다 유용합니다. 결과만 계속 바꾸다 보면 내가 무엇을 고친 건지 감이 안 오는데, 설명을 먼저 받으면 흐름을 따라가기 쉬워집니다.

실전 팁
프롬프트 템플릿은 “정답 문장”이 아니라, 빠뜨리기 쉬운 요소를 놓치지 않게 해주는 체크리스트처럼 쓰는 편이 좋다.

---

결과가 흔들릴 때 다시 요청하는 법

바이브코딩에서는 첫 결과보다 두 번째 요청, 세 번째 요청이 더 중요할 때가 많습니다. 처음 나온 결과가 완벽할 가능성은 높지 않습니다. 문제는 그다음입니다. 이때 “아니, 이게 아니라”라고만 말하면 AI는 또 빈칸을 추측하기 시작합니다. 그래서 다시 요청할 때는 적어도 네 가지를 같이 말해주는 편이 좋습니다.

• 무엇이 문제인지: 어떤 버튼, 어떤 화면, 어떤 입력에서 이상한가
• 무엇은 유지할지: 레이아웃, 기능, 문구 등 건드리지 않았으면 하는 부분
• 무엇을 바꿀지: 간격, 로직, 메시지, 순서 등 구체적인 변경점
• 어떤 방식으로 답하면 좋은지: 설명 먼저, 코드 먼저, 최소 수정 등

아래처럼 비교해 보면 차이가 더 분명합니다.

상황	아쉬운 재요청	더 나은 재요청
기능은 맞지만 디자인이 과함	좀 덜 과하게 해줘	기능은 그대로 두고, 그림자와 장식 요소를 줄여서 더 단순한 카드 형태로 바꿔줘
수정 후 기존 기능이 깨짐	다시 고쳐줘	저장 기능을 추가한 뒤 완료 체크가 동작하지 않아. 저장 기능은 유지하고 체크 로직만 다시 봐줘
코드가 너무 길고 복잡함	더 깔끔하게 해줘	현재 기능은 유지하되, 초보자가 읽기 쉽게 코드 구조를 단순화하고 주석은 필요한 곳만 남겨줘
오류 원인을 잘 모르겠음	왜 안 되는지 모르겠어	삭제 버튼 클릭 시 아무 반응이 없어. 먼저 원인을 짧게 설명하고, 그다음 수정된 코드만 보여줘
전체를 바꾸지 않고 일부만 바꾸고 싶음	다시 만들어줘	현재 레이아웃과 한국어 문구는 유지하고, 입력창 아래 안내 메시지 부분만 추가해줘

재요청에서 특히 중요한 표현은 아래와 같습니다.

기존 기능은 유지하고 이 부분만 수정해줘 디자인은 그대로 두고 로직만 다시 봐줘 바로 전체를 바꾸지 말고 원인부터 짧게 설명해줘 최소 수정으로 해결해줘

이 표현들은 결과를 “다시 처음부터 생성”하는 쪽이 아니라, 현재 상태를 기준으로 좁혀서 수정하는 쪽으로 유도합니다. 초보자에게 이 차이는 꽤 큽니다. 이미 괜찮은 부분을 살려두면서 고쳐 갈 수 있기 때문입니다.

중요한 감각
첫 프롬프트가 설계의 시작이라면, 재요청은 방향 조정에 가깝다. 바이브코딩에서는 이 방향 조정을 얼마나 침착하게 하느냐가 결과 품질을 많이 좌우한다.

---

마무리

바이브코딩에서 프롬프트는 단순한 입력창 문장이 아닙니다. 내가 무엇을 만들고 싶은지, 어디까지가 이번 범위인지, 무엇은 일부러 빼고 싶은지를 정리하는 과정에 더 가깝습니다. 그래서 프롬프트를 잘 쓴다는 말은 사실상 문제를 잘게 나누고, 확인 가능한 조건으로 말할 수 있다는 뜻과 거의 비슷합니다.

입문자라면 처음부터 완벽한 요청문을 쓰려고 애쓸 필요는 없습니다. 오히려 막연한 형용사를 줄이고, 핵심 기능을 적고, 이번엔 뺄 것을 함께 적고, 문제가 생기면 구체적으로 다시 설명하는 습관을 들이는 편이 훨씬 현실적입니다. 이 감각이 붙기 시작하면, 같은 도구를 써도 결과가 덜 흔들리고 작업 흐름도 훨씬 편해집니다.

결국 바이브코딩에서 중요한 건 “AI에게 뭔가 대단한 말을 하는 법”이 아니라, 내가 원하는 결과를 스스로 분명하게 만드는 법입니다. 이 부분이 잡혀야 작은 프로젝트도 끝까지 가져가기 쉬워지고, 나중에 더 큰 작업으로 넘어갈 때도 덜 헤매게 됩니다.