스펙 문서에 "날짜 필터 추가" 한 줄을 적었다. 기획 검토 회의에서 나온 피드백이었고, 그 자리에서 개발 리드가 고개를 끄덕였다. 그런데 다음 날 슬랙에 메시지가 왔다. "이거 2주 더 필요합니다."
한 줄인데? 필터 하나인데?
개발자가 보는 "한 줄"은 PM이 보는 "한 줄"이 아니다
PM에게 날짜 필터는 UI 위의 드롭다운 하나다. 캘린더 피커가 열리고, 시작일과 종료일을 고르면 끝. 하지만 개발자 입장에서 그 한 줄은 이런 질문들로 분해된다.
기존 API가 날짜 범위 파라미터를 지원하는가? 안 하면 백엔드부터 손대야 한다.
타임존 처리는 어떻게 할 것인가? 서버는 UTC인데 사용자는 KST.
날짜 필터가 기존 필터(상태, 카테고리)와 조합될 때 쿼리 성능은 괜찮은가?
캐시를 쓰고 있었다면, 날짜 필터가 추가되면서 캐시 키 구조를 바꿔야 할 수도 있다.
QA는? 경계값(윤년, 12월 31일→1월 1일), 빈 결과, 역순 입력 등 테스트 케이스가 갑자기 불어난다.
PM이 한 줄로 적은 건 사용자 관점의 요구사항이다. 개발자가 2주를 말하는 건 시스템 관점의 작업량이다. 이 간극을 좁히는 게 PM의 핵심 역량 중 하나인데, 많은 PM이 여기서 실수한다.
"그거 얼마나 걸려요?"라는 질문의 함정
신입 PM 시절, 나는 회의 중에 이 질문을 정말 자주 했다. 개발자가 "글쎄요, 확인해봐야..."라고 하면 "대충이라도 감 잡아주세요"라고 밀어붙였다. 그리고 그 "대충"을 스프린트 플래닝에 박았다.
문제는 "대충"이라는 답이 PM에게는 약속처럼 들린다는 점이다. "3일 정도?"라고 한 말이 로드맵에 올라가고, 이해관계자에게 전달되고, 출시일 계산의 근거가 된다. 개발자는 아직 코드를 열어보지도 않았는데.
이런 패턴이 반복되면 개발팀은 방어적이 된다. 모든 견적에 버퍼를 넣기 시작하고, PM은 "왜 이렇게 오래 걸리냐"고 느끼고, 신뢰가 깎인다. 양쪽 다 합리적으로 행동하는데 결과는 점점 나빠지는 구조적 문제다.
스펙 변경의 비용을 줄이는 세 가지 습관
완벽하게 해결할 수는 없다. 하지만 몇 가지 습관은 확실히 도움이 됐다.
첫째, "이거 영향 범위가 어디까지야?"를 먼저 묻는다. "얼마나 걸려?"가 아니라. 영향 범위를 파악하는 것은 일정 산출의 전제 조건이다. 날짜 필터가 API 변경 없이 프론트에서만 처리 가능한 건지, 백엔드 스키마까지 건드려야 하는 건지에 따라 답이 완전히 달라진다.
둘째, 스펙 변경은 가능하면 스프린트 시작 전에 끝낸다. 당연한 소리 같지만 현실에서는 잘 안 된다. 스프린트 중간에 "아 그리고 이것도 넣자"가 가장 비용이 높은 변경이다. 이미 설계가 끝난 상태에서 끼워 넣으면 단순 추가가 아니라 재설계가 되기 때문이다. 설계 단계에서 한 시간이면 해결될 논의가, 구현 중간에 터지면 이틀짜리 작업이 된다.
셋째, 개발자와 함께 스펙을 쓴다. 기획서를 완성해서 넘기는 게 아니라, 초안 단계에서 기술적 제약을 같이 논의한다. "이 기능 이렇게 하면 어때?"라고 물었을 때 "그건 쉬운데, 이 부분은 좀 까다로워요"라는 피드백이 오면 스펙 자체를 조정할 수 있다. 완성된 기획서에 빨간 줄이 그어지는 것보다 훨씬 낫다. 공동 작성이 처음엔 느린 것 같지만, 뒤에서 터지는 재작업을 생각하면 총 비용은 오히려 줄어든다.
결국 커뮤니케이션 문제가 아니다
"PM이랑 개발자가 소통을 잘 하면 된다"는 말은 맞긴 한데, 너무 뭉뚱그린다. 소통이 안 되는 게 아니라 서로 다른 추상화 수준에서 같은 단어를 쓰고 있는 것이다. PM이 "필터"라고 하면 유저 스토리를 떠올리고, 개발자는 데이터베이스 쿼리를 떠올린다.
이 간극은 소통 빈도를 늘린다고 줄어들지 않는다. PM이 기술적 맥락을 조금이라도 이해하거나, 최소한 "내가 모르는 복잡도가 있을 수 있다"는 전제를 갖고 있어야 줄어든다. 겸손이라기보다는 직업적 판단력에 가깝다.
스펙 한 줄의 무게는 그걸 적는 사람이 아니라 구현하는 사람이 결정한다. 그 사실을 체감하는 데 나는 2년이 걸렸다.