AI 코딩 PRD 프롬프트, 결과가 흔들릴 때 쓰는 7줄 템플릿

AI에게 코딩을 맡겼는데 첫 결과는 그럴듯하고, 두 번째 수정부터 화면이 무너지기 시작하는 경우가 많습니다. 원인은 모델 성능 하나로만 설명되지 않습니다. “로그인 화면 고쳐줘”, “예쁘게 바꿔줘”, “에러 없게 해줘”처럼 결과물, 범위, 완료기준이 비어 있는 요청을 넣으면 AI는 빈칸을 추측으로 채웁니다. 코딩사관학교 초보자에게 필요한 것은 더 긴 부탁이 아니라, 작업 전에 붙여 넣을 수 있는 짧은 PRD입니다.

developers.openai.com의 OpenAI 프롬프트 엔지니어링 문서는 작업 지시를 역할, 지침, 예시, 맥락처럼 구분해 주면 모델이 논리적 경계를 이해하기 쉬워진다고 안내합니다. 같은 도메인의 Codex CLI 문서도 로컬 디렉터리의 코드를 읽고, 바꾸고, 명령을 실행할 수 있는 코딩 에이전트라고 설명합니다. 그래서 AI 코딩 요청은 “무엇을 만들어줘”에서 끝나면 안 됩니다. 어떤 파일을 건드려도 되는지, 어떤 검증 명령을 실행해야 하는지, 성공 보고를 어떤 형식으로 받을지까지 먼저 써야 합니다.

수정 요청보다 PRD 7줄이 먼저입니다

AI 코딩에서 PRD는 거창한 기획서가 아닙니다. 한 화면이나 한 기능을 만들기 전에 목표, 사용자, 입력, 출력, 제약, 검증, 보고를 고정하는 작업 지시서입니다. 이 7줄이 있으면 AI는 “예쁘게”나 “알아서”를 해석하느라 범위를 넓히지 않고, 지금 필요한 결과물에 맞춰 움직입니다.

다음 코딩 작업을 PRD 기준으로 처리해 주세요.

목표: {무엇을 완성하거나 고칠 것인가}
사용자: {누가 어떤 행동을 해야 하는가}
입력: {사용자가 넣는 값, 기존 데이터, 현재 상태}
출력: {화면이나 기능에서 보여야 하는 결과}
제약: {바꾸지 말아야 할 파일, 디자인, 패키지, 데이터 구조}
검증: {실행할 명령, 확인할 화면, 성공 기준}
보고: {바뀐 파일, 검증 결과, 남은 위험을 짧게 정리}

예를 들어 회원가입 버튼이 눌리지 않는 문제라면 아래처럼 바꿔 쓸 수 있습니다.

다음 코딩 작업을 PRD 기준으로 처리해 주세요.

목표: 회원가입 화면에서 필수값을 입력하면 제출 버튼이 활성화되게 고쳐 주세요.
사용자: 새 계정을 만들려는 사용자가 이메일과 비밀번호를 입력하고 가입을 누릅니다.
입력: 이메일, 비밀번호, 비밀번호 확인 값입니다.
출력: 세 값이 유효하면 버튼이 활성화되고, 값이 부족하면 버튼이 비활성화됩니다.
제약: 화면 문구와 색상은 바꾸지 말고, 새 패키지는 추가하지 마세요.
검증: 가능한 테스트 명령을 실행하고, 없으면 수동 확인 절차를 적어 주세요.
보고: 수정 파일, 원인, 검증 결과, 남은 위험을 5줄 이내로 알려 주세요.

이렇게 쓰면 AI가 “회원가입 화면 전체 리디자인”으로 번지는 일을 줄일 수 있습니다. 수정 범위가 작은 과제일수록 PRD가 더 효과적입니다. 작은 기능은 한 줄이 흐려져도 전체 결과가 쉽게 바뀌기 때문입니다.

목표와 사용자를 분리하면 AI가 화면을 덜 상상합니다

초보자가 자주 하는 요청은 “관리자 페이지 만들어줘”처럼 대상이 넓습니다. 이 문장에는 누가 쓰는지, 무엇을 눌러야 하는지, 무엇이 보이면 성공인지가 없습니다. AI는 대시보드, 로그인, 표, 통계, 권한까지 한꺼번에 상상할 수 있습니다. 그 결과 과제보다 큰 코드가 생깁니다.

목표는 바꿀 결과를 말하고, 사용자는 행동을 말해야 합니다.

흐린 요청	PRD형 요청
관리자 페이지 만들어줘	관리자가 게시글 목록에서 발행 상태를 바꾸는 화면을 만들어줘
검색 기능 넣어줘	방문자가 키워드를 입력하면 제목과 요약에서 일치하는 글만 보이게 해줘
로그인 고쳐줘	이메일과 비밀번호가 맞을 때 세션이 생기고 홈으로 이동하게 해줘

목표와 사용자를 분리하면 AI가 필요한 컴포넌트와 상태를 좁혀서 판단합니다. “관리자”라는 단어 하나보다 “게시글 목록에서 발행 상태를 바꾸는 사람”이라는 문장이 더 강한 경계가 됩니다.

제약을 쓰지 않으면 AI는 해결책을 새로 만들려고 합니다

AI는 문제를 풀기 위해 새 파일, 새 패키지, 새 구조를 제안할 수 있습니다. 학습용 과제에서는 이 행동이 도움이 될 때도 있지만, 기존 프로젝트를 고치는 상황에서는 위험합니다. 특히 코딩사관학교 초보자는 “왜 새 라이브러리가 들어갔는지”, “왜 폴더 구조가 바뀌었는지”를 나중에 파악하기 어렵습니다.

제약 줄에는 아래 세 가지를 넣으면 충분합니다.

제약 종류	넣을 문장
파일 범위	관련 파일만 수정하고, 설정 파일은 필요할 때만 바꾸세요.
디자인 유지	기존 색상, 문구, 레이아웃은 요청한 부분 외에는 유지하세요.
의존성 제한	새 패키지를 추가하지 말고 현재 의존성 안에서 해결하세요.

제약은 AI를 막는 문장이 아닙니다. 검토할 후보를 줄여 주는 문장입니다. AI가 더 큰 변경이 필요하다고 판단하면 바로 수정하지 말고 “왜 필요한지 먼저 설명해 주세요”라고 붙이면 됩니다.

제약: 관련 파일만 수정하고, 새 패키지는 추가하지 마세요. DB 스키마 변경이나 환경변수 변경이 필요하면 먼저 이유와 대안을 설명하고 멈춰 주세요.

완료기준이 있어야 결과 보고를 믿을 수 있습니다

AI가 “완료했습니다”라고 말해도 실제로 빌드가 깨져 있을 수 있습니다. 그래서 PRD의 검증 줄은 가능한 구체적이어야 합니다. 명령을 모르면 AI에게 직접 찾게 하면 됩니다.

검증: package.json을 확인해서 이 프로젝트에서 실행 가능한 lint, test, build 명령을 찾고 가능한 범위에서 실행해 주세요. 실행하지 못한 명령은 이유를 적어 주세요.

작은 HTML 과제라면 명령 대신 화면 기준을 넣어도 됩니다.

검증: 브라우저에서 입력값을 비운 상태, 잘못된 이메일, 올바른 이메일 세 가지 상태를 확인하고 버튼 활성화 여부를 표로 정리해 주세요.

완료기준은 AI를 의심하기 위한 장치가 아닙니다. 사용자가 다음 행동을 결정할 수 있게 만드는 장치입니다. 성공했으면 다음 기능으로 넘어가고, 실패했으면 실패 로그를 바탕으로 다시 요청하면 됩니다.

결과가 마음에 들지 않으면 전체 요청을 다시 쓰지 않습니다

첫 결과가 빗나갔을 때 전체 프롬프트를 새로 쓰면 맥락이 길어지고, AI가 이미 잘한 부분까지 다시 바꿀 수 있습니다. 이때는 PRD의 7줄 중 흔들린 줄만 고쳐서 다시 요청하는 편이 안정적입니다.

증상	다시 붙여 넣을 수정문
관련 없는 파일까지 바뀜	이번 작업과 직접 관련 없는 변경을 되돌리지 말고 목록으로 분리해 주세요. 필요한 최소 파일만 수정하는 방향으로 다시 제안해 주세요.
디자인이 달라짐	기능 수정은 유지하되 기존 색상, 간격, 문구를 원래 스타일에 맞춰 되돌려 주세요.
검증 없이 완료라고 함	완료라고 말하기 전에 가능한 검증 명령을 실행하고, 실행할 수 없으면 이유와 수동 확인 절차를 적어 주세요.
새 패키지를 추가함	새 패키지 없이 해결하는 대안을 먼저 제시해 주세요. 꼭 필요하다면 이유와 영향 범위를 설명해 주세요.

수정 요청은 짧아야 합니다. “다시 잘해줘”보다 “제약 줄을 지키면서 검증 줄을 다시 실행해 주세요”가 낫습니다. AI가 어디서 벗어났는지 알 수 있기 때문입니다.

붙여 넣기 전 이 7줄만 확인합니다

아래 체크리스트를 채운 뒤에 AI에게 코딩을 맡기면 요청이 덜 흔들립니다. 처음부터 완벽하게 쓰지 않아도 됩니다. 빈칸이 보이면 그 빈칸이 AI가 추측할 자리라는 뜻입니다.

줄	확인 질문
목표	무엇을 완성하거나 고칠 것인가
사용자	누가 어떤 행동을 하는가
입력	어떤 값이나 데이터가 들어오는가
출력	화면이나 기능에서 무엇이 보여야 하는가
제약	바꾸지 말아야 할 것은 무엇인가
검증	어떤 명령이나 화면으로 확인할 것인가
보고	성공, 실패, 남은 위험을 어떻게 받을 것인가

AI 코딩은 코드를 대신 써 주는 기능이지만, 작업의 기준까지 대신 정해 주지는 않습니다. 코딩사관학교 학습자가 먼저 익혀야 할 습관은 코드 붙여 넣기보다 작업 기준을 고정하는 것입니다. 오늘 맡길 과제가 있다면 요청문을 길게 쓰기 전에 PRD 7줄을 먼저 채우세요. 그 다음 AI에게 코드를 맡기면 수정 루프가 짧아집니다.

AI 코딩이 계속 흔들릴 때 먼저 쓰는 PRD 프롬프트 7줄