들어가면서
Cursor 오토메이션에 PRD와 MR 맥락을 넣고, 문서 품질과 구현 일치도를 한 번에 훑어보는 실험을 했다.
프롬프트는 처음부터 완성이 아니었고, 몇 번 돌리면서 “근거만”, “추측은 확인 필요” 같은 원칙을 고정했다. usage CSV로 대략 잡으면, 그날 저녁 8시 이후 구간만 합쳐도 사 딸라 근처였다. (성공·실패·재시도 포함. 실패도 토큰은 나간다.)
이 글에서는 결과의 세부(어떤 파일, 어떤 AC) 는 일부만 예시로 두고, 무엇을 시키는 프롬프트였는지와 비용 감각, 그리고 실제로 나온 산출물의 형태를 공개한다.
무엇을 시켰나 — 역할과 원칙
모델에게 주는 첫 문장은 대략 이런 식이었다.
역할: 당신은 29CM 프로덕트 조직의 PRD 품질 검토와 PRD 대비 구현 일치도(alignment) 점검을 하는 시니어 PM·테크 리드.
문서·코드에 없는 내용은 추측하지 않는다. 근거가 없으면 「확인 필요」.
그 아래에 작업 원칙을 숫자로 박아 둔다. 내가 쓴 버전은 요지가 이렇다.
- 근거 우선 — 문서/코드/디프에 있는 사실만
- 추측 금지 — 유추면 「확인 필요」
- 보안 — 개인정보·카드·토큰 인용 금지
- 입력 부족이면 과감히 중단
- 구현 비교는 입력이 있을 때만
입력 폼은 Git/MR, PRD(제목·URL·본문), 구현물(diff 요약 등) 을 나눠 두었고, 구현 입력이 없으면 파트 B는 생략이라고 못 박았다.
파트 A / B — 채점은 이렇게 쪼갰다
파트 A는 “이게 우리가 말하는 PRD냐” 쪽이다. 29PRODUCT 기준으로 배경·목표·AC·예외·영향 같은 항목이 문서에 확인 가능한지 보고, 완성 PRD / PRD 초안 / PRD 아님으로 분류하게 했다.
점수는 A~E 다섯 축(각 1~5) 으로 두고, 문서에 적힌 모호함(E) 은 점수가 낮을수록 모호하다는 뜻으로 뒤집어 넣는 식으로 0~100 환산도 적어 두었다. (수식은 프롬프트에 그대로 있다.)
파트 B는 입력 3이 있을 때만. AC·시나리오 ↔ 구현 근거를 표로 매핑하고, 갭을 언더빌드 / 오버빌드 / 불일치 / 비기능 같은 꼬리표로 나눈다. Alignment_score는 근거 있는 항목만 넣으라고 했다.
출력 순서도 고정했다 — 메타 → 파트 A → 파트 B(있을 때) → 종합 한 줄. 리뷰어가 읽을 때 스크롤이 줄어들게.
제약과 자동화 쪽 지시
PRD가 링크만 있고 본문이 없으면 “판단 불가” 문구를 그대로 내보내게 했고, diff에 시크릿이 의심되면 마스킹 후 재제출을 요구하게 했다.
끝부에는 PR 코멘트 등록을 “필수”로 두었다. 성공하면 posted: true와 URL, 실패하면 붙여넣기용 마크다운 전체를 출력하라고 했다. 이 부분은 우리 CI/토큰 환경과 엮여 있어서, 블로그에 전문을 그대로 올릴지는 한 번 더 생각할 지점이다. (원리만 공유할지, 팀 레포나 비공개 gist에 둘지.)
비용과 가치 — 사 딸라면
이 정도 구조의 프롬프트를 돌리는 데, 그날 기준 사 딸라면 나는 할 만하다고 본다.
사람이 PRD·Confluence·MR을 번갈아 열고 같은 표를 채우는 시간을 생각하면, 단가는 이쪽이 싸게 느껴진다.
다만 이건 E2E 테스트나 장애 복구를 대체하는 도구가 아니라, 스펙과 코드의 정합성을 빨리 드러내는 층이다. 생산성과 함께 “문서와 구현이 어긋난 지점을 일찍 보이게 하는 것” 이 안정성에 가깝다고 느꼈다.
실제로 나온 것 — 커버리지 표가 핵심이다
비용 이야기만 하면 “싸다/비싸다”로 끝난다. 이 실험을 글로 남기려는 이유는 숫자가 아니라 산출물의 형태다.
파트 B를 켜 두면 모델은 PRD의 AC·시나리오를 한 줄씩 줄이고, 구현 쪽 근거를 파일·훅 단위로 붙이고, 충족 / 부분 / 미구현 / 확인 필요로 상태를 찍는다. 리뷰어는 표만 따라가도 “어디까지 증명됐는지”가 보인다.
아래는 공개해도 되는 수준으로 가공한 예시다. (내부 도메인·민감 경로는 빼거나 일반화할 수 있다.)
커버리지 매핑 (B-1 요지)
정확한 내용은 회사 밖이라 Dummy 내용으로 대체한다
| PRD의 AC 또는 시나리오 (요약) | 구현에서 대응하는 근거 (추상) | 상태 |
|---|---|---|
| 주문 흐름에서 카드 혜택이 금액·조건에 맞게 반영된다 | 주문 데이터를 만들 때 카드·주문 조건을 함께 고려하는 로직이 있음 | 충족 |
| 결제 직전 단계에서 프로모션·혜택이 결제 쪽으로 넘어간다 | 결제 준비 단계에 혜택 정보를 실어 보내는 경로가 있음 | 충족(세부 검증 필요) |
| 결제수단·할인·카드 선택이 서로 엇갈리지 않게 맞춰진다 | 선택 상태를 동기화하거나 되돌리는 처리가 일부 들어가 있음 | 부분 |
| 가입·등록·발급 상태에 따라 안내 후 다음 단계로 보낸다 | 사용자 상태에 맞춰 안내·외부 절차로 이어지는 분기가 있음 | 충족 |
| 계정 설정·관리 화면에서 관련 메뉴에 닿을 수 있다 | 마이 영역에서 결제·카드 쪽으로 이어지는 진입이 마련됨 | 충족 |
| 계정 전환·통합 이후에도 카드 정보 화면으로 자연스럽게 이어진다 | 계정 맥락이 바뀐 뒤에도 동일 목적지로 안내하는 흐름이 있음 | 충족 |
| 주문이 끝난 뒤 혜택 요약이 한눈에 보인다 | 완료 화면·응답에서 할인·혜택을 묶어 보여 주는 형태가 있음 | 충족 |
| 주문 완료 직후 추가 안내·유도가 있다 | 완료 이후 한 번 더 설명하거나 다음 행동을 제안하는 UI가 있음 | 충족 |
| 상품을 고르는 화면에서 카드 혜택이 드러난다 | 탐색·상세 단계에 카드 관련 설명 블록이 존재함 | 충족 |
| 구매 정보 영역에 포인트·적립이 함께 보인다 | 가격·혜택 근처에 포인트·적립 한 줄이 붙는 구조 | 충족 |
| 캠페인·안내용 랜딩에서 신청·다음 단계로 이어진다 | 콘텐츠형 페이지에서 본문·행동 유도가 이어짐 | 충족 |
| 주문 이후 상세·변경 화면에서도 결제·혜택 맥락이 이어진다 | 주문 뒤 화면까지 동일 정보가 자연스럽게 노출되는지는 이번 범위만으로는 불명확 | 확인 필요 |
| 다른 채널·고객 지원 터치포인트와 문구·정책이 맞는다 | 앱·웹·CS 등 바깥 채널과의 정합은 별도 범위로 보는 편이 낫다 | 미구현(본 범위 기준) |
이 표 자체가 “추측하지 말고 근거를 달라”는 프롬프트와 맞물린다. 근거가 없으면 확인 필요나 미구현으로 박히고, 그게 오히려 솔직하다.
종합 한 줄 (그날 나온 요약 예시)
구현 일치도 68점 — 주문/결제 핵심 경로는 상당수 반영됐지만, mock 잔존·배너 TTL 불일치·일부 범위(29커넥트/주문상세) 근거 부족으로 릴리즈 전 정합성 확인이 필요합니다.
점수 하나만 보면 심플하지만, 표와 한 줄이 같이 있어야 “68이 왜 68인지”가 읽힌다. 나는 이 쌍을 보여주는 게 이 글의 핵심이라고 생각한다.
전체 프롬프트를 공개할까
나는 원칙·구조·채점 축은 글로 풀고, 팀 내부 링크·토큰·봇 지시가 길게 붙은 부분은 저장소나 gist로 빼는 쪽을 선호한다. 프롬프트는 자주 고칠 테니까.
그래도 “그대로 복사해 쓰게” 주고 싶다면, 아래에 내가 실제로 쓴 프롬프트 전문을 붙인다.
프롬프트 전문 (펼치기)
# 역할 당신은 29CM 프로덕트 조직의 **PRD 품질 검토**와 **PRD 대비 구현 일치도(alignment)** 점검을 수행하는 시니어 PM·테크 리드다. **문서·코드에 없는 내용은 추측하지 않는다.** 근거가 없으면 반드시 **“확인 필요”**로 남긴다. --- # 작업 원칙 (필수) 1. 근거 우선: 문서/코드/디프에 있는 사실만 사용 2. 추측 금지: 유추가 필요한 내용은 “확인 필요” 3. 보안 준수: 개인정보/카드번호/토큰 등 민감정보는 인용 금지 4. 입력 부족 시 과감히 중단: 판단 불가를 명확히 표기 5. 구현 비교는 입력이 있을 때만 수행 --- # 입력 (사용자가 아래를 채움) ## 1) 출처 (Git / MR) - **MR/PR 번호 또는 링크**: (선택) - **코멘트에서 가져온 PRD 링크**: (Confluence URL, 필수면 본문도) - **브랜치/커밋 범위** (구현 비교 시): 예) `main...feature/foo` 또는 주요 커밋 메시지 요약 ## 2) PRD - **제목**: - **URL**: - **본문**: 마크다운/텍스트 붙여넣기 (링크만 있고 본문이 없으면 아래 [제약] 규칙 적용) ## 3) 구현물 (선택 — “개발한 것과 비교”할 때만) 아래 중 **하나 이상** 제공 시 구현 대비 검증 수행: - 변경 파일 목록 / git diff 요약 (민감정보 제거) - 구현 요약 (5~15줄) - 스크린/플로우 설명 (텍스트 가능) > 본문·diff가 없으면 **PRD 점수만** 내고, 구현 비교 단계는 > **“입력 없음으로 생략”**이라고 명시한다. --- # 파트 A — PRD 정의 충족 여부 (기준) 29PRODUCT에서 말하는 **PRD**로 인정하려면 아래 1~8이 문서에서 확인 가능해야 한다. 일부만 있으면 **「PRD 초안」**으로 분류한다. 1. 배경·문제 2. 목표·비목표 3. 대상 사용자·채널 4. 핵심 시나리오 5. 수용 기준(AC) 6. 데이터·API·정책 (미정이면 “미정” 명시) 7. 예외·실패 8. 영향 범위·회귀 (플래그·롤백 포함 가능 시) **PRD가 아닌 것**: - 템플릿/Sync-up/링크 모음 전용 - Deprecated/Archiving 사본 - 1~8이 비어 있는 스텁 ## 파트 A 채점 축 (각 1~5, 정수) - **A. 구현 명확성** — AC·예외로 태스크 분해 가능한가 - **B. 범위 고정** — In/Out·“이번에 안 함”이 있는가 - **C. 부작용·회귀 위험** — 주문/결제/가격 등 고위험 도메인에 대한 영향 분석이 문서에 있는가 (점수 **높을수록** 위험이 **문서에 잘 드러남**) - **D. 의존성 명시** — BE/API/디자인/외부사/릴리즈 순서 - **E. 모호성** — WIP/TBD/상충 (점수 **낮을수록** 모호함 많음) **PRD 품질 점수(요약)**: - 숫자형: `PRD_score = round((A + B + D + (6 - E)) / 4 * 20)` (0~100) - 또는 서술형: 준비도 **상/중/하** (상=개발 착수 가능, 하=PRD 보완 필수) --- # 파트 B — 구현 vs PRD 일치도 (입력 3이 있을 때만) ## B-1. 커버리지 매핑 | PRD의 AC 또는 시나리오 (요약) | 구현에서 대응하는 근거 (파일/컴포넌트/동작 요약) | 상태 | |---|---|---| | … | … | 충족 / 부분 / 미구현 / 문서에 없음 | ## B-2. 갭(Gap) 유형 (해당 시만) - **언더빌드**: PRD·AC에 있는데 코드에 없음 - **오버빌드**: 구현은 있는데 PRD에 없음 (스코프 크리프 의심) - **불일치**: PRD 문구와 실제 동작 다름 (확인 필요) - **비기능**: 로깅/플래그/에러처리/접근성 등 PRD 근거 부족으로 판단 유보 ## B-3. 구현 관점 리스크 - 회귀 가능 영역 (주문/결제/가격 등) - PRD에 없어 QA 기준이 애매한 부분 ## B-4. 일치도 점수 (선택) - **Alignment_score (0~100)**: PRD에 명시된 범위 대비 구현 반영 정도 - 반드시 근거가 있는 항목만 반영 --- # 출력 형식 (반드시 이 순서) ## 1. 메타 - PRD 제목, URL, (있으면 MR/PR 참조) ## 2. 파트 A 결과 1) **한 줄 요약** (무엇을 위해 무엇을 바꾸는가) — 본문 없으면 “판단 불가” 2) **점수표** — A, B, C, D, E (1~5) + **PRD 품질 점수(0~100 또는 준비도 상/중/하)** 3) **PRD 유형**: `완성 PRD` | `PRD 초안` | `PRD 아님` 4) **누락·모호 항목** — 불릿 (근거: 문서 인용 또는 “문서에 없음”) 5) **구현 전 필수 질문** — 최대 7개 (Yes/No 가능하게) 6) **추천** — 아래 중 하나만 - `즉시 구현 가능` - `PRD 보완 후 구현` - `스코프 축소 후 스파이크` - `참고·보관만` ## 3. 파트 B 결과 (입력 3 있을 때만) - B-1 표, B-2 갭, B-3 리스크, (선택) Alignment_score ## 4. 종합 한 줄 - 예: “PRD 72점, 구현 일치도 80점 — AC 중 ○○ 미구현, △△는 PRD에 없음” --- # 제약 (엄수) - PRD **본문이 없고 링크만** 있으면 아래 문구를 그대로 출력: - **“본문 없이는 파트 A·B 모두 판단 불가. Confluence에서 본문 붙여넣기 또는 핵심 섹션 요청”** - diff에 키/토큰/시크릿 의심 문자열이 보이면 아래 문구를 출력: - **“diff에 민감정보 포함 의심 — 마스킹 후 재제출”** - 민감정보(개인정보/카드정보/토큰/시크릿) 재현·인용 금지 --- # 자동화 실행 지시 (**필수: PR 코멘트 등록**) - 본 작업은 PR 코멘트 봇 환경으로 간주한다. - 분석 완료 후 **반드시 PR 코멘트 등록을 시도**한다. - PR 번호/저장소 정보가 있으면 해당 PR에 코멘트를 게시해야 한다. - 코멘트 등록 시도 시, 사용 가능한 인증 정보(예: `GITHUB_TOKEN`, `GH_TOKEN`)가 있으면 이를 사용한다. - 등록 성공 시 아래를 반드시 출력한다: 1) `posted: true` 2) 코멘트 URL 3) 게시한 본문 요약 1줄 - 등록 실패 시 아래를 반드시 출력한다: 1) 실패 사유 1줄 2) 재시도 여부(최소 1회 재시도 권장) 3) **붙여넣기용 코멘트 본문 전체(markdown)** - “가능하면”, “선택” 같은 비강제 표현을 사용하지 않는다. - 코멘트 본문에도 민감정보를 포함하지 않는다. --- # Git 코멘트용 짧은 요청 템플릿 (사람이 MR/PR에 남길 때) 아래 PRD와 구현 변경 기준으로 1) PRD 품질(A~E, 1~5 + 100점 환산), 2) PRD 유형(완성/초안/아님), 3) 구현-PRD 커버리지 표(B-1), 4) 갭 유형(언더/오버/불일치), 5) Alignment_score(0~100) 를 근거 기반으로 리뷰해줘. 추측은 금지하고, 근거 없으면 “확인 필요”로 표시해줘.요약: 공개는 가능하고, 다만 전부 vs 요약+전문 접기 중에서 고르면 된다. 나는 후자를 추천한다.