AI에게 “쇼핑몰 만들어줘”라고 요청했다가 엉뚱한 코드와 끝없는 에러에 지쳐 포기하셨다면, 문제는 실력이 아니라 프롬프트의 구조입니다.
성과 마케팅 11년, 온라인 셀러 8년을 거치며 랜딩페이지 수정과 픽셀 세팅 같은 작업을 직접 AI에게 맡겨 왔습니다. 그 과정에서 확인한 것은 명확합니다. 코드를 읽을 줄 아느냐보다, 요청을 어떻게 쪼개서 전달하느냐가 결과를 좌우합니다. 이 글에서는 비개발자가 그대로 복사해 쓸 수 있는 프롬프트 4단계 공식과, 만든 코드를 실제 사이트에 적용하는 검증 절차까지 정리합니다.
바이브코딩 프롬프트란 무엇인가요?
바이브코딩 프롬프트는 코드를 직접 작성하는 대신, AI가 정확한 코드를 출력하도록 목표·제약·입출력 예시·단계 분할 네 가지를 구조화해 전달하는 요청문입니다. 직접 코드를 타이핑하는 기술이 아니라, 작업을 설계해 넘기는 기술에 가깝습니다.
이 글에서 다루는 4단계 공식은 다음과 같습니다.
- 1단계 목표 — 무엇을, 어떤 화면에서, 누구를 위해 만들 것인지 한 문장으로 특정
- 2단계 제약 — 사용 중인 플랫폼, 기존 코드, 건드리면 안 되는 영역, 금지 조건 명시
- 3단계 입출력 예시 — 입력했을 때 어떤 결과가 나와야 하는지 구체적 사례로 제시
- 4단계 단계 분할 — 한 번에 전체를 요청하지 않고, 검증 가능한 최소 단위로 쪼개 순서 지정
“쇼핑몰 만들어줘”가 실패하는 이유
AI 코딩 도구의 효과 자체는 이미 여러 차례 측정됐습니다. GitHub이 전문 개발자 95명을 두 그룹으로 나눠 진행한 통제 실험에서, 코딩 보조 도구를 쓴 그룹은 동일한 과제를 평균 1시간 11분에 마쳐 도구 없이 작업한 그룹(평균 2시간 41분)보다 약 55% 빠른 완료 시간을 기록했습니다. 과제 완료율도 78%로, 미사용 그룹의 70%보다 높았습니다.
다만 이 실험은 개발자를 대상으로 한 것이고, 과제도 “HTTP 서버 작성”처럼 범위가 명확히 정해져 있었습니다. 비개발자가 “쇼핑몰 만들어줘”라고 요청하는 상황과는 조건이 다릅니다.
뭉뚱그린 지시가 실패하는 이유는 세 가지입니다. 첫째, AI가 빠진 정보를 임의로 채웁니다. 결제 모듈도, 회원 관리도, 상품 등록도 각각 수십 가지 구현 방식이 있는데 그중 하나를 AI가 골라 버립니다. 둘째, 결과물이 너무 커서 어디가 잘못됐는지 특정할 수 없습니다. 셋째, 에러가 났을 때 “에러 났어”라고만 되돌려주면 AI는 또 다른 추측으로 답합니다. 이 순환이 흔히 말하는 무한 에러 루프입니다.
바이브코딩 프롬프트 4단계 공식
구조를 갖춘 프롬프트가 왜 유리한지는 모델 제작사 문서에서도 확인됩니다. OpenAI는 개발자 메시지를 정체성(Identity), 지시(Instructions), 예시(Examples), 맥락(Context) 순서로 구성할 것을 권장합니다. 4단계 공식은 이 구조를 비개발자 언어로 옮긴 것입니다.
| 단계 | 무엇을 쓰나 | 예시 문장 |
|---|---|---|
| 목표 | 기능 1개 + 위치 + 목적 | “상품 상세 페이지 우측 하단에 카카오톡 상담 버튼을 고정하고 싶습니다.” |
| 제약 | 플랫폼·기존 코드·금지 조건 | “카페24 스마트디자인이고, 기존 CSS는 수정하지 말고 추가 코드만 주세요.” |
| 입출력 예시 | 원하는 결과의 구체적 모습 | “모바일에서 스크롤해도 버튼이 우측 하단 20px 여백에 계속 떠 있어야 합니다.” |
| 단계 분할 | 검증 가능한 최소 단위 | “먼저 버튼이 화면에 보이는 것까지만 만들어 주세요. 링크 연결은 다음에 요청합니다.” |
세 번째 단계인 입출력 예시는 특히 효과가 큰 항목입니다. Anthropic은 잘 만든 예시 몇 개가 출력의 형식·톤·구조를 조정하는 가장 신뢰할 만한 방법이라고 설명하며, 최적 결과를 위해 3~5개의 예시를 포함할 것을 권합니다. “예쁘게 만들어 주세요” 대신 “이렇게 보여야 합니다”를 보여주면 재작업이 눈에 띄게 줄어드는 경우가 많습니다.
작게 시키고 자주 검증하기
비즈모멘텀이 강조하는 원칙은 하나입니다. 작게 시키고 자주 검증하는 것입니다. 한 번에 다섯 가지 기능을 요청하고 마지막에 확인하면, 문제가 생겼을 때 다섯 곳 중 어디가 원인인지 알 수 없습니다.
이 방식이 유리한 근거는 검증 단계의 성격에서 나옵니다. 소프트웨어정책연구소는 2024년 이슈리포트에서 소프트웨어 개발 과정 중 시험 단계가 시간이 오래 걸리고 반복 업무가 많아 생성형 AI 활용에 가장 효과적인 구간이라고 분석했습니다. 같은 보고서는 AI 도구의 생산성 효과가 개발 단계와 사용자 수준에 따라 편차가 크며, 환각으로 인한 잘못된 정보를 빠르게 판별할 수 있는 사람일수록 효과가 크다고 지적합니다.
비개발자에게 시사하는 바는 분명합니다. 판별 능력을 코드 실력으로 채울 수 없다면, 검증 단위를 잘게 쪼개서 채워야 합니다. 실제 작업 순서는 다음과 같습니다.
- 기능을 눈으로 확인 가능한 최소 단위로 쪼갠다 (예: 버튼이 보인다 → 클릭된다 → 링크로 이동한다)
- 1개 단위만 프롬프트로 요청한다
- 받은 코드를 적용하고 즉시 화면에서 확인한다
- 정상 작동하면 그 상태를 따로 저장(복사)해 둔다
- 다음 단위를 요청한다. 에러가 나면 저장해 둔 지점으로 되돌린다
4번의 저장 습관이 핵심입니다. 되돌아갈 지점이 없으면 에러 하나에 전체를 처음부터 다시 만들게 됩니다.
AI가 준 코드는 어디에 붙여넣어야 하나요?
상위 노출 글 대부분이 프롬프트 작성법에서 멈춥니다. 그런데 비개발자가 실제로 막히는 지점은 그다음, 받은 코드를 어디에 넣느냐입니다. 국내 주요 솔루션별 위치는 다음과 같습니다.
| 솔루션 | 코드 삽입 위치 | 주의점 |
|---|---|---|
| 카페24 | 디자인 관리 → HTML/CSS 편집 → 해당 화면 파일 | 수정 전 반드시 디자인 백업 생성 |
| 아임웹 | 사이트 설정 → 고급 설정 → 헤더/푸터 코드 삽입 | 스크립트는 푸터, 스타일은 헤더 권장 |
| 워드프레스 | 블록 에디터 → 커스텀 HTML 블록 (또는 자식 테마 파일) | 일반 단락 블록에 넣으면 태그가 글자로 표시됨 |
| 네이버 스마트스토어 | 상세페이지 에디터 (HTML 삽입 제한 있음) | 외부 스크립트 대부분 차단, 사전 확인 필요 |
프롬프트를 쓸 때 이 정보를 제약 단계에 미리 넣어야 합니다. “카페24 스마트디자인 기준으로, 상품 상세 화면 파일에 그대로 붙여넣을 수 있는 형태로 주세요”라고 지정하면, AI가 다른 환경을 전제로 한 코드를 내놓는 상황을 줄일 수 있습니다.
비개발자가 자주 하는 프롬프트 실수 3가지
첫째, 에러 메시지를 그대로 옮기지 않고 “안 돼요”라고만 전달합니다. 브라우저 개발자도구(F12) 콘솔에 뜬 빨간 글씨를 통째로 복사해 붙여넣는 것만으로도 해결 확률이 달라집니다.
둘째, 이전 대화 맥락을 믿고 새 요청을 시작합니다. 대화가 길어지면 초반 제약 조건이 흐려집니다. 새 기능을 요청할 때는 플랫폼과 금지 조건을 다시 한 문장으로 붙여 주는 편이 안전합니다.
셋째, 잘 작동하던 상태를 저장하지 않습니다. 앞서 언급한 4번 단계입니다.
HTML과 CSS를 배울 필요는 없습니다. 다만 태그가 열리고 닫힌다는 구조 정도만 눈에 익혀 두면, 에러가 났을 때 어느 부분을 잘라 물어봐야 하는지 스스로 판단할 수 있습니다.
자주 묻는 질문
바이브코딩이란 무엇인가요?
코드를 직접 작성하는 대신 자연어로 AI에게 요청해 소프트웨어를 만드는 방식을 가리키는 표현입니다. 결과물의 품질은 요청문의 구조에 크게 좌우됩니다.
코딩을 전혀 몰라도 AI로 쇼핑몰을 만들 수 있나요?
결제·회원 관리를 포함한 쇼핑몰 전체를 처음부터 만드는 것은 권장하지 않습니다. 다만 기존 솔루션에 버튼 추가, 배너 삽입, 추적 코드 적용 같은 부분 기능은 비개발자도 충분히 구현하는 경우가 많습니다.
클로드와 챗GPT 중 코딩에 더 좋은 AI는 무엇인가요?
모델별 강점은 버전에 따라 계속 바뀌므로 하나를 정답으로 단정하기 어렵습니다. 두 도구 모두 제작사가 프롬프트 구조화와 예시 제공을 권장한다는 점은 동일하므로, 도구 선택보다 요청 구조를 먼저 다듬는 편이 실익이 큽니다.
프롬프트 한 번에 기능을 몇 개까지 요청해도 되나요?
화면에서 눈으로 확인 가능한 결과 1개가 기준입니다. “버튼이 보인다”와 “버튼을 누르면 이동한다”는 서로 다른 요청으로 나누는 편이 검증에 유리합니다.
AI가 준 코드에서 에러가 났을 때 어떻게 질문해야 하나요?
에러 메시지 전문, 붙여넣은 위치, 기대했던 동작 세 가지를 함께 전달합니다. 세 정보가 모두 있어야 AI가 추측 대신 진단을 합니다.
HTML과 CSS를 꼭 배워야 하나요?
필수는 아닙니다. 태그의 열고 닫음, 스타일이 적용되는 위치 정도의 기초 구조만 알아 두면 에러를 쪼개서 질문하기가 훨씬 수월해집니다.
4단계 공식을 어디부터 적용해야 하나요?
지금 사이트에서 가장 사소한 기능 하나를 고르십시오. 버튼 색상 변경이나 문구 수정처럼 실패해도 손실이 없는 작업이 첫 연습 대상으로 적합합니다.
