일하는 방식
01 · 루틴
기획 문서 7단계 워크플로
기획 문서를 쓸 때마다 앞 문서와 뒤 문서가 어긋나는 것이 문제였습니다. 일곱 단계를 하나로 묶되 앞 단계가 검증되지 않으면 다음으로 넘어가지 않게 했습니다.
단계와 검토 지점
- 01 프로젝트 개요 — 무엇을 왜 만드는지 먼저 고정
- 02 PRD — 범위와 비범위를 나눠 적음
- 03 IA — 구조가 PRD 범위를 넘지 않는지 대조
- 04 유저플로우 — 예외 경로를 여기서 전부 꺼냄
- 05 기능명세 — input · output · API 규격 · 정책 · 예외
- 06 와이어프레임 — 명세에 없는 화면이 생기지 않게
- 07 QA 체크리스트 — 수정 후 전체 반영 여부 자가 점검
쓰다가 발견한 것
AI가 수정 사항을 조용히 빠뜨린다는 걸 알게 됐습니다. 한 곳을 고치면 다른 곳이 빠지고, 그걸 고치면 앞에서 되던 게 깨졌습니다. 그래서 수정을 요청한 뒤에는 전체에 반영됐는지 스스로 점검하게 하는 단계를 루틴으로 고정했고 누락이 눈에 띄게 줄었습니다.
결과
PRD 초안 3일 이상 → 하루 이내.
- 워크플로 설계
- AI 검증
- 문서 일관성
02 · 원칙
무엇을 AI에게 맡기지 않을지
AI 서비스에서 어려운 것은 모델을 부르는 일이 아니라 역할을 나누는 일이라고 생각합니다. 같은 원칙을 만든 것마다 반복해서 적용했습니다.
세 번의 적용
- 세무상담 AI — 법령 근거는 RAG, 세액 계산은 코드, 범위 밖 질문의 거절은 규칙
- 해커톤 어드민 — 계산과 임계 판정은 코드, 요약·문구는 AI, 최종 확정은 사람
- 마켓데스크 — 없는 숫자는 생성 금지, 추출한 숫자는 인용 페이지와 대조해 검증 플래그
만든 다음에
정확도를 올리는 것보다 틀렸을 때 알아낼 수 있는 장치를 함께 설계합니다. 세무상담 AI에서는 계산 코드에 버그 7종을 일부러 심어 테스트가 6종을 잡아내는지부터 확인했습니다.
AI로 공부하는 방식
AI에게 묻는 대신 AI가 저에게 주관식 질문을 던지게 만들었습니다. 물어보면 답은 나오지만 남지 않기 때문입니다.
- 역할 분리
- 가드레일
- 검증 설계
03 · 양식
기획서 다섯 항목 양식
처음에는 개발자와 디자이너에게 유저플로우와 구현 결과밖에 설명하지 못했습니다. 무엇을 만들지는 전달했지만, 어떤 조건에서 어떻게 동작하고 어떤 예외가 있는지는 전달하지 못했습니다.
그래서 만든 것
강의로 IT 기획을 독학해 기준을 스스로 정리한 뒤, 기획서를 input · output · API 규격 · 정책 · 예외 다섯 항목으로 고정하는 양식을 만들었습니다. 삼일회계법인·온라인팜 등 외부 네 개사의 API 정의서를 검토해 정책과 기능으로 옮기는 일도 맡았습니다.
받은 피드백
함께 일한 개발자들에게 “구현 중에 판단해야 할 것들이 문서에 정리되어 있어 편하다”는 말을 들었습니다.
배운 것
계산이 얽힌 서비스는 예외까지 적어야 정의가 끝납니다. 백엔드 개발자가 작성한 ERD를 기획서 규칙과 대조해 검토하는 것도 이때부터 습관이 됐습니다.
- 기획서 표준화
- API 정의서 검토
- ERD 검토