리드 자동화 풀사이클 — PRD 구체화부터 릴리스까지

"바이어가 폼을 제출하면 확인 이메일을 자동으로 보낸다." 기획에서 받은 건 이 한 줄과 Figma 시안이었다. 코드는 마지막이었다 — 기획의 행간을 결정으로 바꾸고, 네 직군(PO·PD·BE·FE)이 같은 그림을 보게 만드는 일이 절반 이상이었다. 기능 하나를 처음부터 끝까지 끌고 간 과정을 남긴다.

시작 — 한 줄 스펙의 행간

딜러는 바이어 폼 접수 후 확인 메일을 수동으로 보내고 있었고, 응대가 늦으면 바이어가 이탈했다. 그래서 자동화. 방향은 명확한데 행간이 전부 미정이었다 — 발송 실패하면? 이메일이 없는 제출이면? 비활성화 중 제출된 건은? 토글을 껐다 켜면 소급 발송되나?

이 질문들을 안고 코드를 시작하면, 구현 중간마다 멈춰서 물어보고, 답을 기다리고, 갈아엎게 된다. 그래서 코드 전에 PRD를 다시 썼다.

PRD 구체화 — FE가 구현 가이드를 쓴 이유

기획서를 받아 적는 게 아니라, 구현 관점에서 빈칸이 드러나도록 재구성했다.

한 줄 요약 — "When(폼 제출) → If(이메일 유효성) → Then(발송/미발송)"의 고정 플로우를 시각적으로 편집·활성화하는 기능. "고정"이라는 단어가 중요했다 — v1에서 노드를 자유 배치하는 빌더가 아니라는 걸 전원이 합의하고 시작
가설 — 자동화를 켠 딜러는 안 켠 딜러보다 24시간 내 바이어 응답률이 개선된다
성공 지표 — 활성화율·발송 성공률·셋업 완료 시간을 목표값·측정 주기와 함께 정의. 출시 후 "잘 됐나?"를 감이 아니라 숫자로 답하기 위해

결정 테이블 — 확정 32, 보류 7

행간의 질문들을 전부 결정 항목으로 추출해 번호를 붙였다. 하나씩 PO·PD·BE와 협의해 확정하고, 백엔드 답변이 필요한 항목은 "보류"로 명시한 채 진행했다. 최종 집계가 확정 32개, 보류 7개.

이 테이블이 한 일:

같은 질문이 두 번 나오지 않는다 — "그거 D14에서 정했어요"로 끝남
보류가 명시돼 있으니 미결을 안고도 멈추지 않는다 — 보류 7건은 의존하지 않는 부분부터 병렬 진행
디자인 결정엔 "재논의 금지" 표시를 달아, 한 번 합의한 걸 다시 여는 비용을 막았다

백엔드와 병렬로 — MSW가 시간을 벌었다

MSW는 Orval을 들일 때 함께 도입해둔 도구다. 둘 다 스웨거 명세를 같은 계약으로 보기 때문에, API가 아직 없는 구간도 명세대로 모킹해 FE를 먼저 만들 수 있었다. 핸들러를 PRD의 결정대로 작성해두면 스웨거가 나왔을 때 생성 타입으로 교체만 하면 됐고, 발송 실패·빈 이메일 같은 엣지 시나리오도 모킹으로 먼저 화면을 검증했다. 백엔드를 기다리는 시간이 사라졌다.

QA — 문서가 아니라 협업 보드로

구현이 끝나갈 때 QA 체크리스트를 시나리오 ID 체계로 썼다.

- [ ] H-1-2. 리스트 최초 진입 시 시드 1건이 Inactive로 보인다 | 시드 없으면 빈 상태 대신 재시도 표시 확인
- [ ] H-1-4. 상세 → 뒤로가기 시 리스트의 페이지·정렬 상태 복원 | 페이지 2에서 진입 후 확인

형식이 핵심이었다 — 기대 동작 + 확인 방법 + 담당(FE/BE/FE+BE)을 한 줄에. 이걸 Notion DB로 옮겨 FE·PD·PO가 각자 확인 컬럼에 체크하게 하니, QA가 "개발자의 문서"가 아니라 세 직군이 같이 미는 보드가 됐다. 뒤로가기 상태 복원·실패 메일 재시도 같은 엣지는 이 보드에서 잡혔다.

체크리스트를 손으로만 쓰기엔 리소스가 빠듯해서 AI를 끼웠다. PRD의 결정 테이블을 먹여 시나리오 초안을 뽑고, 내가 실제 흐름을 따라가며 빠진 케이스를 보강하는 식 — QA 전담이 없는 팀에서도 엣지까지 훑는 밀도가 나왔다. 이 방식은 프롬프트째 디자이너에게도 공유했는데, 지금은 디자이너가 Figma에서 엣지케이스 화면을 잡을 때 같은 유즈케이스 체크리스트 방식으로 쓰고 있다. 프로세스가 직군을 넘어간 순간이었다.

릴리스, 그리고 끝나지 않는 기능

머지·릴리스 후에도 큐가 남았다 — 백엔드 후속 작업(추가 필드·정책)을 follow-up 목록으로 관리했고, 얼마 뒤엔 메일 클릭 추적이 필요해져 백엔드와 스펙을 함께 설계해 얹었다(추적 URL 경유 후 폼으로 리다이렉트, 제출에 토큰 동봉). 기능은 릴리스로 끝나지 않고 살아서 자란다 — 그걸 받칠 수 있는 건 결정 기록이 남아 있을 때였다.

남긴 것

FE가 PRD를 구체화하면 전체가 빨라진다. 행간을 코드 중간에 발견하면 모두가 멈추지만, 시작 전에 결정 테이블로 소거하면 네 직군이 병렬로 움직인다
보류를 숨기지 않고 번호 붙여 드러내는 것이 진짜 진행 관리였다 — "모르는 것"이 명시된 계획은 미결이 있어도 굴러간다
이 흐름(PRD 구체화 → 결정 협의 → MSW 병렬 → QA 보드 → 릴리스 → follow-up)은 이후 기능들에도 그대로 쓰는 우리 팀의 풀사이클 SOP가 됐다