새 기능 만들기: PRD → Plan → Implement → Verify
기능 개발은 네 단계로 고정한다
Cursor로 새 기능을 만들 때 가장 위험한 습관은 "이거 만들어 줘"라고 바로 맡기는 것이다. Agent는 빠르다. 하지만 빠르기 때문에 잘못된 방향으로도 빠르게 간다. 기능 개발은 속도보다 순서가 중요하다.
이 장에서 사용할 표준 흐름은 단순하다.
PRD → Plan → Implement → Verify
먼저 무엇을 만들지 문서로 정한다. 그다음 코드베이스를 살펴 구현 계획을 세운다. 구현은 작은 단계로 나누어 진행한다. 마지막으로 테스트, 타입체크, 수동 확인, 리뷰, 문서화를 거쳐 끝낸다.
이 흐름을 한 번 익히면 기능 하나를 만들 때마다 같은 리듬으로 움직일 수 있다. 솔로 메이커에게 필요한 것은 매번 천재적인 판단을 하는 능력이 아니라, 실수를 줄이는 반복 가능한 절차다.
AI 생성 이미지
1단계: Agent 모드에서 PRD를 먼저 만든다
새 기능은 Agent 모드에서 PRD 초안을 만드는 것부터 시작한다. Cursor에서 Agent 입력창을 열고, 기능 아이디어를 짧게 설명한다. 이때 프롬프트 끝에 반드시 이런 문장을 붙인다.
명확히 하기 위한 질문을 먼저 해줘.
이 한 줄이 중요하다. Agent가 바로 문서를 완성하게 두면 기존 인프라, 사용자 흐름, 인증 방식, 데이터 저장 방식, 결제 정책 같은 제약을 임의로 채울 수 있다. 반대로 질문을 요구하면 Agent는 먼저 빈칸을 드러낸다. PRD Workflow 자료에서도 PRD 초안 작성 후 명확화 질문에 답해 기존 제약과 인프라를 반영하라고 권한다.1
예를 들어 "대시보드에 피드백 위젯을 추가하고 싶다"는 요청은 아직 부족하다. Agent는 다음을 물어야 한다.
로그인 사용자만 제출할 수 있는가?
익명 피드백을 허용하는가?
별점, 만족도, 자유 입력 중 무엇을 받는가?
중복 제출을 막아야 하는가?
제출 실패 시 사용자에게 무엇을 보여줄 것인가?
관리자 화면이나 알림은 이번 범위에 포함되는가?
이 질문에 답한 뒤 PRD를 정리한다. PRD에는 최소한 다음 항목이 들어가야 한다.
문제 정의
대상 사용자
사용자 흐름
포함 범위
제외 범위
수용 기준
오류 시나리오
비기능 요구사항
특히 제외 범위를 반드시 적어야 한다. "이번 작업에서는 관리자 통계 화면을 만들지 않는다", "이메일 알림은 포함하지 않는다", "기존 결제 플랜 정책은 변경하지 않는다"처럼 적는다. 제외 범위가 없으면 Agent는 친절한 척하면서 기능을 키운다.
수용 기준은 검증 가능한 문장으로 쓴다.
로그인한 사용자는 대시보드에서 만족도와 메시지를 제출할 수 있다.
메시지는 500자를 초과할 수 없다.
제출 성공 후 성공 메시지가 표시된다.
네트워크 오류가 발생하면 입력값은 유지되고 재시도 안내가 표시된다.
비로그인 사용자는 제출 API를 호출할 수 없다.
이 정도면 Agent가 "좋아 보이는 기능"이 아니라 "통과해야 할 기능"을 만들 수 있다.
2단계: Plan Mode로 코드베이스를 읽힌다
PRD가 준비되면 바로 구현하지 않는다. Plan Mode로 전환한다. Cursor의 Plan Mode는 Agent가 코드베이스를 분석하고, 관련 파일과 문서를 찾고, 후속 질문을 한 뒤, Markdown 기반 구현 계획을 만들도록 돕는다.2
이 단계의 프롬프트는 이렇게 쓴다.
이 PRD를 기준으로 아직 코드는 수정하지 말고 구현 계획만 세워줘.
관련 파일, 기존 패턴, 재사용 가능한 컴포넌트, 데이터 흐름, 테스트 위치를 찾아줘.
모호한 점이 있으면 계획 전에 질문해줘.
좋은 계획에는 다음이 포함된다.
수정할 파일 경로
참고해야 할 기존 코드
새로 만들 파일
데이터 모델 또는 API 계약
테스트 전략
구현 순서
위험 요소
수동 확인 항목
Plan Mode가 만든 계획은 그대로 받아들이지 않는다. 사용자가 직접 읽고 고친다. 우선순위를 바꾸고, 과한 리팩터링을 제거하고, 파일 범위를 줄인다. Cursor의 Plan Mode는 계획을 Markdown 파일로 만들고 사용자가 TODO를 추가하거나 삭제하며 편집할 수 있게 한다.2 가능하면 .cursor/plans/에 저장한다. 이 파일은 나중에 같은 기능을 다시 검토할 때도 좋은 컨텍스트가 된다.
계획을 검토할 때는 이 질문을 던진다.
이 계획을 동료 개발자에게 맡겨도 불안하지 않은가?
PRD의 수용 기준이 모두 작업 항목으로 연결되는가?
기존 패턴을 재사용하는가?
파일 변경 범위가 너무 넓지 않은가?
이번 작업의 제외 범위를 침범하지 않는가?
여기서 불안하면 구현으로 넘어가지 않는다. 계획을 고치는 시간이 가장 싼 시간이다.
3단계: 구현은 한 번에 맡기지 않는다
계획이 승인되면 Agent 모드로 돌아와 실행한다. 이때도 "이 계획대로 전부 구현해 줘"라고 맡기지 않는다. 기능을 작은 단계로 나눈다.
추천 순서는 다음과 같다.
문서와 테스트 초안
백엔드 또는 서버 로직
프론트엔드 UI
타입, 상태, 에러 처리 정리
문서와 변경 로그 업데이트
가능하면 TDD에 가까운 루프를 적용한다. 먼저 기능 설명과 테스트 전략을 만들고, 그다음 실패하는 테스트를 작성한다. 이후 Agent에게 "테스트를 통과하는 최소 구현"을 맡긴다. Agent Mode와 TDD를 함께 사용할 때는 문서 → 실패 테스트 → 테스트 실행기 → 구현 → 재실행의 흐름이 안전하다는 실전 사례도 있다.3
프롬프트는 이렇게 쓸 수 있다.
계획의 1단계만 진행해줘.
먼저 기존 테스트 패턴을 semantic search로 찾아 프로젝트 컨벤션을 확인해줘.
그다음 피드백 제출 기능의 테스트 전략을 짧게 제안하고, 내가 승인하면 테스트 파일을 작성해줘.
semantic search를 요구하는 이유는 간단하다. Agent가 자기 방식으로 새 구조를 만들지 않고, 현재 코드베이스의 관습을 따르게 하기 위해서다. 이미 있는 API 핸들러 패턴, 폼 검증 방식, 에러 메시지 처리, 테스트 유틸리티를 먼저 찾게 해야 한다.
백엔드 구현도 범위를 좁힌다.
계획의 백엔드 단계만 구현해줘.
새 인증 구조를 만들지 말고 기존 auth helper를 사용해.
DB 스키마 변경이 필요하면 먼저 제안만 하고 적용하지 마.
구현 후 관련 테스트만 실행해줘.
프론트엔드도 마찬가지다.
기존 대시보드 컴포넌트 패턴을 따라 피드백 위젯 UI만 추가해줘.
새로운 디자인 시스템이나 상태 관리 라이브러리는 추가하지 마.
loading, success, error, disabled 상태를 모두 처리해줘.
이렇게 단계별로 맡기면 Agent의 장점은 유지하면서 위험은 줄일 수 있다.
4단계: Agent가 스스로 검증하게 한다
다중 파일 변경이 필요한 기능은 Agent 모드가 잘 맞는다. 특히 3~10개 파일 정도를 건드리는 기능 구현, 테스트 추가, 제한된 리팩터링에는 효과적이다.4 다만 터미널 자동 실행은 신중하게 허용해야 한다.
허용해도 좋은 명령은 보통 다음과 같다.
테스트 실행
타입체크
린트
포맷 확인
빌드 확인
반대로 DB 삭제, 배포, 마이그레이션 적용, 패키지 설치, 외부 API 쓰기 작업은 자동 실행하지 않는다. 필요하면 반드시 승인 후 실행하게 한다.
핵심 루프는 이렇다.
Agent가 코드를 작성한다.
Agent가 테스트를 실행한다.
실패 로그를 읽는다.
원인을 설명한다.
최소 수정한다.
다시 테스트한다.
이 루프를 가능하게 하려면 출력이 너무 길어지지 않게 해야 한다. 테스트 로그가 길다면 마지막 실패 부분만 보게 하거나, 로그를 파일로 저장한 뒤 핵심 줄만 읽게 한다. 컨텍스트 창을 실패 로그로 가득 채우면 Agent의 판단력은 오히려 떨어진다.
단계 사이마다 멈춰서 diff를 읽는다
AI와 일할 때 가장 중요한 버튼은 실행 버튼이 아니라 멈춤 버튼이다. 각 단계가 끝날 때마다 diff를 읽는다.
확인할 것은 많지 않다.
계획에 없던 파일이 바뀌었는가?
수용 기준과 무관한 리팩터링이 섞였는가?
새 패키지가 추가되었는가?
인증, 권한, 결제, 삭제 로직을 건드렸는가?
테스트가 실제 요구사항을 검증하는가?
에러 처리가 사용자 흐름과 맞는가?
계획과 다른 변경이 보이면 즉시 중단한다. 계속 프롬프트로 달래기보다 변경을 되돌리고 계획을 수정한 뒤 다시 실행하는 편이 낫다. Agent Mode 실전 가이드에서도 결과가 의도와 다르면 변경을 되돌리고 계획을 좁혀 다시 실행하라고 권한다.4
수동 UI 확인도 빠뜨리지 않는다. 테스트가 통과해도 사용자가 보는 화면이 어색할 수 있다. 브라우저에서 정상 상태, 빈 상태, 오류 상태, 모바일 폭을 직접 본다. 콘솔 오류와 네트워크 응답도 확인한다.
완료는 코드 병합이 아니라 출시 준비다
기능이 동작한다고 끝난 것이 아니다. 마지막 루틴까지 고정해야 한다.
Cursor에게 다음 초안을 만들게 한다.
커밋 메시지
PR 설명
변경 로그
문서 업데이트
테스트 결과 요약
남은 제한 사항
프롬프트는 이렇게 쓸 수 있다.
이번 변경의 diff와 PRD를 비교해서 PR 설명 초안을 작성해줘.
포함할 것: 문제, 해결 방식, 주요 변경 파일, 수용 기준별 완료 여부, 실행한 테스트, 수동 확인 결과, 제외 범위.
과장하지 말고 실제로 확인한 것만 적어줘.
마지막으로 PRD의 수용 기준을 하나씩 체크한다. "테스트 통과"만 보지 말고 "처음에 만들기로 한 것이 실제로 만들어졌는지"를 확인한다. 수용 기준 중 하나라도 애매하면 완료가 아니다.
좋은 기능 출시 루틴은 다음 문장으로 요약된다.
문서로 의도를 고정하고, 계획으로 범위를 잠그고, 작은 구현으로 검증하고, diff와 테스트로 책임진다.
Cursor는 이 과정을 빠르게 만든다. 하지만 기능의 방향, 범위, 품질 기준을 정하는 일은 여전히 사람의 일이다.
참고
1PRD Workflow in Cursor | Developer Toolkit
3Mastering Cursor's Agent Mode: Test-Driven Development with AI | Scientific Witchery
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.