같은 도구, 같은 AI. 프롬프트 하나로
결과물의 품질이 갈린다.
바이브 코딩에서 가장 흔한 실수는 "잘 만들어줘"라고 말하는 것이다. AI는 "잘"이 뭔지 모른다. "전문적으로 만들어줘"도 마찬가지다. AI에게 이런 프롬프트를 주면 가장 평균적인 결과물을 내놓는다. 평균이 나쁘진 않지만, 당신이 원하는 것은 평균이 아닐 것이다.
흥미로운 연구 결과가 있다. "코딩 잘하는 사람이 바이브 코딩도 잘하는 것은 아니다." 프로그래밍 실력과 프롬프트 작성 능력은 별개의 스킬이다. 10년차 개발자가 "로그인 기능 만들어줘"라고 쓰고, 코딩 경험 없는 기획자가 정교한 프롬프트를 쓰면 후자의 결과물이 더 나을 수 있다.
프롬프트는 코드가 아니다.
프롬프트는 설계도다.
좋은 프롬프트에는 공통된 구조가 있다. "한 문장으로 던지기" 대신, 프롬프트를 4개의 블록으로 나눠서 쓴다. 컨텍스트, 태스크, 가이드라인, 제약조건이다.
지금 무엇을 만들고 있는지, 어떤 기술 스택을 쓰고 있는지, 프로젝트의 현재 상태가 어떤지를 알려준다. AI에게 "배경지식"을 주는 것이다.
지금 당장 해야 할 구체적인 작업을 명시한다. "로그인 기능 만들어줘"가 아니라 "이메일+비밀번호 로그인 폼을 만들어줘"처럼 구체적으로.
스타일이나 방식에 대한 선호를 알려준다. "Tailwind CSS를 써라", "한국어로 에러 메시지를 써라", "모바일 우선으로 만들어라" 같은 지시.
하지 말아야 할 것을 명시한다. "jQuery를 쓰지 마라", "이 파일은 수정하지 마라", "외부 라이브러리를 추가하지 마라" 같은 금지 사항.
이 구조를 따르면 AI의 "해석 여지"가 줄어든다. 해석 여지가 줄면 엉뚱한 결과가 나올 확률도 줄어든다. 프롬프트 엔지니어링에서는 이것을 "모호성 제거"라고 한다.
이론은 그만. 실제 프롬프트를 나쁜 버전과 좋은 버전으로 비교한다. 같은 AI, 같은 모델에서 결과가 얼마나 달라지는지 확인하라.
바이브 코딩의 가장 흔한 실패 패턴은 "한 번에 전체 앱을 만들어달라"고 요청하는 것이다. "쇼핑몰 만들어줘"라고 하면 AI는 뭔가를 만들어내지만, 그것은 겉만 번지르르한 껍데기일 확률이 높다.
대신 단계별로 쪼개서 요청한다. 한 번에 하나의 컴포넌트, 하나의 기능, 하나의 페이지만 요청한다. 각 단계가 완료되면 확인하고, 다음 단계로 넘어간다.
"쇼핑몰의 폴더 구조와 라우팅만 먼저 설계해줘. 코드는 아직 쓰지 마." 전체 그림을 먼저 잡고, AI와 합의한다.
"상품 목록 페이지의 UI만 먼저 만들어줘. 데이터는 하드코딩으로." 기능과 디자인을 분리해서 하나씩 확인한다.
"상품 목록에 검색 기능을 추가해줘. 기존 코드의 상품 배열을 필터링하는 방식으로." 기존 코드 위에 점진적으로 쌓는다.
"검색 결과가 0건일 때 '결과 없음' 메시지를 보여줘. 검색어가 2글자 미만이면 검색하지 마." 엣지 케이스를 명시적으로 지시한다.
"지금까지 만든 코드에서 중복되는 부분을 정리해줘. 하지만 기능은 바꾸지 마." 동작을 유지한 채 코드 품질을 올린다.
매번 같은 컨텍스트를 반복해서 쓰는 건 비효율적이다. 프로젝트의 규칙, 기술 스택, 코딩 컨벤션을 파일 하나에 정리해두면 AI가 매번 참조할 수 있다. 이것을 규칙 파일이라고 한다.
도구마다 이름이 다르다. Cursor는 .cursorrules, Claude Code는 CLAUDE.md, GitHub Copilot은 .github/copilot-instructions.md를 사용한다. 하지만 핵심은 같다 — AI에게 "이 프로젝트에서는 이렇게 해라"를 알려주는 문서다.
규칙 파일의 위력은 누적에서 나온다. 프로젝트가 진행될수록 규칙이 구체화되고, AI의 결과물 품질도 함께 올라간다. 한 번 쓰면 프로젝트가 끝날 때까지 효과가 지속된다.
좋은 프롬프트는 좋은 질문에서 시작된다. 도구가 아무리 발전해도, 무엇을 만들지 정의하는 것은 여전히 사람의 몫이다.