프롬프트를 요구사항으로 바꾸는 방법: AI 개발의 첫 단계
바이브코딩에서 막연한 요청을 실행 가능한 요구사항, 체크리스트, 검증 기준으로 바꾸는 방법을 정리했습니다.
요약
바이브코딩에서 가장 중요한 첫 단계는 멋진 프롬프트를 쓰는 것이 아니라, 막연한 아이디어를 실행 가능한 요구사항으로 바꾸는 일입니다. “블로그를 예쁘게 만들어줘”라는 요청은 AI가 알아서 해석하기에는 너무 넓습니다. 반대로 “홈 화면의 메인 카피를 바꾸고, 소개 페이지와 메타 설명까지 같은 방향으로 맞춘 뒤, 빌드가 통과하는지 확인해줘”라고 말하면 결과가 훨씬 안정적입니다.
Futory를 만들면서 느낀 점은 AI가 일을 못하는 순간보다, 사람이 원하는 결과를 덜 명확하게 말한 순간에 문제가 더 자주 생긴다는 것입니다. 그래서 프롬프트는 명령문이라기보다 작업 계약서에 가깝게 다루는 편이 좋습니다.
좋은 요청은 결과를 먼저 말한다
AI에게 일을 맡길 때는 “무엇을 해줘”보다 “최종적으로 어떤 상태가 되어야 하는지”가 먼저입니다. 예를 들어 블로그 카피를 정리할 때도 단순히 후보를 나열하면 사용자는 선택해야 할지, 참고만 하면 되는지 헷갈릴 수 있습니다. 이때는 설명, 추천, 사용자가 결정해야 할 질문을 구분해야 합니다.
실제 작업에서는 다음 순서가 유용했습니다.
- 원하는 최종 화면이나 결과 설명
- 유지해야 할 제약 조건
- 바꿔도 되는 범위
- 검증 방법
- 배포 여부
이 다섯 가지가 있으면 AI 에이전트가 파일을 찾아 수정하고, 테스트를 실행하고, 결과를 설명하는 흐름까지 이어가기 쉽습니다.
요구사항으로 쪼개는 예시
“블로그를 애드센스에 맞게 정리해줘”라는 요청은 너무 큽니다. 이것을 요구사항으로 바꾸면 다음처럼 됩니다.
1. 승인 전에는 하나의 주제 블로그처럼 보이게 한다.
2. 메인 주제는 AI 개발, 자동화, 배포와 운영으로 잡는다.
3. 바이브코딩은 핵심 키워드로 유지한다.
4. 홈, 소개, 전체 글, 메타 설명의 문구를 통일한다.
5. 여러 카테고리를 크게 노출하지 않는다.
6. 수정 후 콘텐츠 검증과 빌드를 실행한다.
이렇게 바꾸면 AI는 무엇을 해야 할지 훨씬 분명하게 이해합니다. 사람도 결과를 검토하기 쉬워집니다.
검증 기준을 같이 적어야 하는 이유
바이브코딩에서 자주 생기는 문제는 “작업은 한 것 같은데 실제로 되는지 모르는 상태”입니다. 코드를 바꿨다고 끝이 아닙니다. Next.js 블로그라면 최소한 콘텐츠 검증, 빌드, 실제 URL 확인이 필요합니다.
예를 들어 Futory에서는 글마다 제목, 설명, 날짜, 카테고리, 태그가 있어야 합니다. FAQ 섹션도 있어야 하고, 글이 너무 짧으면 애드센스용 콘텐츠로 부족합니다. 이런 규칙을 스크립트로 만들어두면 사람이 매번 눈으로 확인하지 않아도 됩니다.
프롬프트 템플릿
실제로 쓸 수 있는 간단한 템플릿은 다음과 같습니다.
목표: 어떤 결과가 되어야 하는가
범위: 어떤 파일이나 화면을 바꿀 수 있는가
제약: 유지해야 할 정책, 문구, 디자인은 무엇인가
검증: 어떤 명령이나 URL로 확인할 것인가
보고: 내가 결정해야 할 내용과 네가 처리한 내용을 분리해서 알려줘
이 템플릿은 개발뿐 아니라 글쓰기 자동화, 서버 점검, 배포 작업에도 그대로 사용할 수 있습니다.
자주 묻는 질문
Q. 프롬프트를 길게 쓰면 무조건 좋은가요?
아닙니다. 길이보다 구조가 중요합니다. 배경 설명이 길어도 목표와 검증 기준이 빠지면 결과가 흔들립니다.
Q. 요구사항을 처음부터 완벽하게 써야 하나요?
그럴 필요는 없습니다. 처음에는 초안을 만들고, AI에게 빠진 조건과 위험한 부분을 질문하게 하는 방식이 좋습니다.
Q. 바이브코딩에서 사람이 해야 할 일은 무엇인가요?
방향 결정, 최종 검토, 위험한 명령 승인, 결과 품질 판단은 사람이 해야 합니다. AI는 실행 속도를 높여주는 도구에 가깝습니다.
결론
바이브코딩의 출발점은 프롬프트가 아니라 요구사항입니다. 사람이 원하는 결과와 검증 기준을 분명히 정하면 AI는 훨씬 안정적으로 움직입니다. Futory에서는 앞으로도 작업을 요구사항, 실행, 검증, 회고로 나누어 기록할 예정입니다.