AI 코딩 범위를 고정하는 7칸 PRD 프롬프트

로그인 버튼 하나를 고쳐 달라고 했는데 두 번째 수정부터 문구, 색상, 다른 화면까지 함께 바뀌는 경우가 있습니다. 이때 요청을 더 길게 다시 쓰기보다 한 작업의 목표와 바꾸지 않을 범위부터 고정해야 합니다. 아래 7칸 PRD를 채우면 AI가 무엇을 바꿨는지, 어디까지 검증했는지 같은 기준으로 결과를 확인할 수 있습니다.

수정 요청보다 7칸 PRD가 먼저입니다

PRD는 여기서 긴 기획서가 아닙니다. 한 화면이나 한 기능의 목표, 사용자, 입력, 출력, 제약, 검증, 보고를 한두 문장씩 적는 작업 카드입니다. 먼저 아래 입력문을 복사하세요.

다음 코딩 작업을 아래 PRD 범위 안에서 처리해 주세요.

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

범위 밖 변경이 필요하면 바로 수정하지 말고 이유와 대안을 먼저 알려 주세요.

회원가입 버튼이 눌리지 않는 상황이라면 이렇게 채울 수 있습니다.

목표: 필수값이 유효할 때 회원가입 버튼이 활성화되게 고쳐 주세요.
사용자: 새 계정을 만들려는 사용자가 이메일과 비밀번호 확인값을 입력합니다.
입력: 이메일, 비밀번호, 비밀번호 확인 값입니다.
출력: 세 값이 유효하면 버튼이 활성화되고, 부족하면 비활성화됩니다.
제약: 화면 문구와 색상은 유지하고 새 패키지는 추가하지 마세요.
검증: 가능한 테스트를 실행하고 빈 값, 잘못된 이메일, 올바른 값 세 상태를 확인하세요.
보고: 수정 파일, 원인, 검증 결과, 실행하지 못한 확인을 알려 주세요.

OpenAI의 Prompt engineering 안내는 명시적 지시, 예시, 관련 맥락을 나눠 제공하는 방식을 설명하고, 코딩 작업에는 테스트와 패치 검증을 요구하도록 안내합니다. 이 7칸은 모델 성능을 보장하는 공식 양식이 아니라, 그 원칙을 한 작업 단위로 바꾼 실무용 입력문입니다.

목표와 사용자는 바꿀 결과와 행동을 나눕니다

“관리자 페이지를 고쳐 주세요”에는 무엇이 바뀌어야 하는지와 누가 무엇을 하는지가 섞여 있습니다. 목표에는 결과 하나를, 사용자에는 행동 하나를 적어야 합니다.

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

원하는 화면을 처음 설명하는 단계라면 코딩 초보가 원하는 화면을 AI에게 맡기는 5줄 프롬프트로 화면 목적과 상태부터 정리할 수 있습니다. 이미 프로젝트가 있고 수정 범위를 잠가야 한다면 지금의 7칸 PRD가 더 적합합니다.

목표에서 사용자와 작업 범위를 거쳐 검증으로 이어지는 AI 코딩 PRD 흐름

제약은 유지할 것과 멈출 조건을 적습니다

제약 칸에는 “하지 마세요”만 늘어놓지 말고 유지할 것과 멈출 조건을 함께 씁니다. 관련 파일 밖 변경, 새 패키지, DB 스키마, 환경변수처럼 영향이 커지는 지점을 고르면 됩니다.

제약 종류	복사할 문장
파일 범위	요청과 직접 관련된 파일만 수정하고 나머지는 목록으로만 알려 주세요.
디자인 유지	기능 수정 외의 문구, 색상, 간격, 레이아웃은 유지하세요.
의존성 제한	새 패키지 없이 먼저 해결하고, 필요하면 이유와 대안을 설명한 뒤 멈추세요.
데이터 경계	DB 스키마나 환경변수 변경이 필요하면 실행 전에 영향 범위를 알려 주세요.

AGENTS.md로 프로젝트 지침을 계층화하는 OpenAI 안내처럼 저장소 규칙이 따로 있다면 제약 칸에 “프로젝트 지침을 먼저 읽고 따르세요”도 넣으세요. 다만 지침을 읽었다는 말만 믿지 말고, 결과 보고에서 실제로 적용한 규칙을 확인해야 합니다.

검증 칸은 완료 보고를 확인 가능한 결과로 바꿉니다

“완료했습니다”는 검증 결과가 아닙니다. 명령을 안다면 정확한 명령을 적고, 모른다면 프로젝트에서 가능한 검증을 찾아 실행하도록 요청하세요.

검증: package.json과 프로젝트 문서를 확인해 실행 가능한 lint, test, build 명령을 찾으세요. 가능한 검증은 실행하고, 실행하지 못한 항목은 이유와 수동 확인 절차를 적어 주세요. 브라우저 화면은 요청 전후 상태를 각각 확인하세요.

현재 Codex 개요 (OpenAI)는 Codex가 프롬프트나 명세에서 시작해 저장소를 탐색하고 파일을 편집하며 명령과 테스트를 실행할 수 있다고 설명합니다. 실제로 무엇을 실행할 수 있는지는 도구의 권한과 프로젝트 환경에 따라 달라집니다. 테스트를 못 했으면 완료가 아니라 미검증 상태로 보고하게 하세요.

결과가 빗나가면 틀린 칸만 다시 보냅니다

첫 결과가 거의 맞는데 전체 요청을 다시 보내면 잘 된 부분도 다시 바뀔 수 있습니다. 증상과 연결된 칸만 고쳐 재요청하세요.

증상	수정 프롬프트
관련 없는 파일까지 바뀜	목표는 유지하고 제약을 다시 적용하세요. 범위 밖 변경은 추가 수정하지 말고 파일 목록과 이유만 알려 주세요.
디자인이 달라짐	기능 수정은 유지하되 기존 문구, 색상, 간격을 원래 상태와 비교해 되돌리세요.
테스트 없이 완료라고 함	검증 칸의 명령을 실행하고 결과를 표로 보고하세요. 못 한 항목은 미검증으로 표시하세요.
에러 원인이 불명확함	추측으로 고치지 말고 재현 단계, 전체 오류 문구, 관련 파일 후보를 먼저 정리하세요.

오류 로그가 나온 상태라면 에러 로그만 붙였을 때 AI가 헤매지 않게 하는 수정 지시 5줄로 재현 조건과 원문을 묶어 보내세요. 핵심은 이미 맞은 칸은 유지하고, 어긋난 칸만 다시 쓰는 것입니다.

붙여 넣기 전 7칸을 한 번 더 확인합니다

목표가 한 화면 또는 한 기능으로 좁혀졌는가
사용자의 행동이 한 문장으로 보이는가
입력과 출력이 실제 값과 상태로 적혔는가
유지할 파일, 디자인, 데이터 경계가 있는가
테스트 명령과 화면 확인 기준이 있는가
변경 파일, 검증 결과, 남은 위험을 보고하게 했는가
범위 밖 변경이 필요하면 먼저 멈추게 했는가

빈칸이 있다면 그 자리가 AI가 추측할 가능성이 큰 부분입니다. 오늘 맡길 작업 하나를 7칸으로 채운 뒤, 변경 파일과 검증 결과를 확인하세요. diff·테스트·실제 화면을 사람이 확인하기 전에는 다음 수정으로 넘어가지 않는 것이 마지막 기준입니다.

AI 코딩 수정 뒤 다른 기능까지 바뀌었다면, 다음 요청에서 범위부터 잠그세요