블로그

KAAI INSIGHT

바이브 코딩을 시작하기 전에 써야 할 한 문장

기능 목록보다 먼저 사용자, 입력, 결과, 실패와 종료 조건을 한 문장으로 고정하면 바이브 코딩의 범위가 선명해진다. 비개발자와 개발자가 함께 쓸 수 있는 프로젝트 계약 작성법을 정리했다.

2026-09-09 · 수정 2026-09-09
바이브 코딩 요구사항부터 — AI 생성 개념 이미지
AI 생성 개념 이미지 · KAAI 실무 해설

바이브 코딩의 첫 단계는 긴 프롬프트가 아니다. 누가, 언제, 무엇을 입력해, 어떤 결과를 받고, 실패하면 어디로 돌아가는가를 한 문장으로 쓰는 일이다. 이 문장이 있으면 기능을 더할지 멈출지 판단할 기준이 생긴다. 한국인공지능활용협회(KAAI)의 개인 AI 실무·프로젝트 리포트 제01호도 개인 프로젝트의 완료를 기능 수가 아니라 다시 확인할 수 있는 상태로 정의한다.

요구사항은 기능 목록보다 작업의 끝을 먼저 적는다

‘메모 앱을 만든다’는 말만으로는 완료를 판정하기 어렵다. 누가 쓰는지, 어떤 입력이 필요한지, 결과가 무엇인지, 오류가 났을 때 사용자가 어디서 다시 시작하는지가 빠져 있기 때문이다. 반면 ‘개인 프로젝트 제작자가 프로젝트 이름과 핵심 작업을 입력하면 준비 상태와 다음 행동을 확인하고, 새로고침 뒤에도 입력을 복원한다’라고 쓰면 확인할 장면이 생긴다.

좋은 프로젝트 계약에는 다섯 요소가 들어간다.

  • 사용자: 이 일을 실제로 하는 한 사람이나 역할
  • 핵심 작업: 시작부터 결과까지 끝내야 하는 한 가지 일
  • 입력: 사용자가 제공하는 값과 허용 범위
  • 결과: 완료를 알아볼 수 있는 화면, 파일 또는 상태
  • 실패와 종료: 빈 값, 중단, 권한 거부 뒤의 복구 경로와 남길 증거

이 다섯 요소는 거대한 기획서를 대신하려는 양식이 아니다. 첫 버전에서 지킬 약속을 작게 만드는 경계다. 내부 학습용이라면 제한된 프로토타입에서 멈춰도 된다. 다만 ‘운영 가능한 서비스’처럼 더 큰 약속을 붙이려면 권한, 데이터, 비용, 복구, 인계와 모니터링 책임까지 증거 범위가 넓어져야 한다.

한 문장을 다섯 질문으로 검토한다

첫째, 사용자를 ‘모든 사람’으로 쓰지 않는다. 실제로 가장 먼저 쓸 사람을 한 명 또는 한 역할로 좁혀야 입력과 결과가 구체화된다. 둘째, 핵심 작업은 화면 이름이 아니라 동사로 적는다. ‘대시보드’보다 ‘이번 주 할 일을 입력하고 우선순위를 확인한다’가 테스트하기 쉽다.

셋째, 성공 화면만 상상하지 않는다. 빈 값을 넣거나 연결이 끊겼을 때 입력이 보존되는지, 다시 시도할 수 있는지, 도움을 받을 경로가 있는지 계약에 포함한다. 넷째, 저장 위치를 말할 수 있어야 한다. 브라우저의 Web Storage는 origin별로 분리되고 localStorage는 브라우저 세션을 넘어 유지될 수 있지만, 이것이 민감정보 보관에 적합하다는 뜻은 아니다. 이 동작 범위는 MDN Web Storage API 문서에서 확인할 수 있다.

다섯째, 종료 조건을 증거로 바꾼다. ‘잘 된다’ 대신 핵심 작업 재실행, 잘못된 입력의 오류 안내, 저장·복원, 초기화, 모바일 표시, 인계 설명처럼 다시 확인할 항목을 적는다. 생성된 코드나 예쁜 화면은 출발점일 수 있지만, 그 자체로 실행 증거는 아니다.

비개발자와 개발자의 기록은 깊이가 다를 뿐이다

비개발자는 템플릿, 노코드 설정, 데이터 내보내기, 공유 권한과 공개 주소를 더 많이 다룬다. 개발자는 저장소, 런타임, 의존성, 환경변수, 테스트와 되돌리기 명령을 더 깊게 기록한다. 도구는 달라도 두 경로는 같은 질문에서 만난다. 다른 사람이 같은 버전과 설정에서 핵심 작업을 다시 실행할 수 있는가.

따라서 도구 선택을 시작점으로 삼을 필요가 없다. 먼저 계약 한 문장을 쓰고, 그 문장을 실행하는 데 필요한 가장 단순한 도구를 고른다. 새 기능은 핵심 작업이나 실패 복구를 실제로 강화할 때만 추가한다. 이 순서를 지키면 ‘무엇을 더 만들까’보다 ‘현재 약속을 증명했는가’를 먼저 보게 된다.

기록은 제작자만 알아보는 메모에서 끝나면 안 된다. 사용한 버전과 설정, 다시 실행할 순서, 확인 날짜, 아직 검사하지 않은 범위를 함께 남긴다. 화면 캡처 한 장은 결과 모양을 보여 줄 뿐 재현 방법까지 설명하지 않는다. 반대로 짧은 절차와 범위가 있으면 다음 수정에서 무엇이 달라졌는지 비교할 수 있다.

오늘 바로 쓰는 프로젝트 계약

아래 빈칸을 한 번에 완벽하게 채우려 하지 말고, 첫 사용 장면을 떠올리며 한 줄로 적어 보자.

“[사용자]가 [상황]에서 [입력]을 제공하면 [핵심 결과]를 얻고, [실패 조건]에서는 [복구 행동]으로 돌아가며, [확인 증거]가 남으면 이번 버전을 끝낸다.”

문장을 쓴 뒤에는 기능 목록을 대조한다. 이 약속과 관계없는 기능은 다음 버전으로 넘기고, 약속을 확인하는 테스트와 기록은 이번 버전에 남긴다. 단계 이름은 순위가 아니라 독자에게 하는 약속의 크기다. 구체적인 완료의 네 문과 증거 구조는 KAAI 보고서 원문에서 확인할 수 있다.

보고서에서 더 자세히 읽기

바이브 코딩, 어디까지 만들면 완료인가 — 관련 근거와 실무 점검표를 전체 보고서에서 확인하세요.

전체 보고서 읽기 · 인쇄하기

함께 읽을 실무 해설 →

확인한 출처

  1. 바이브 코딩, 어디까지 만들면 완료인가
  2. developer.mozilla.org