목차
3. 개발자가 일정이 너무 부족하대요
💬 “이건 이번 스프린트에 다 못 넣을 것 같아요…”
(그런데 PO는 이번에 꼭 넣어야 한다고 생각했거든요)
📍 상황 예시
데이븐은 스타트업 PO로, 이번 스프린트에 꼭 넣고 싶은 기능이 있었다.
바로 ‘단체 예약 기능’.
기획서는 이미 완료됐고,
디자이너도 UI를 잘 정리해줬고,
개발자에게는 전달까지 마친 상태.
“이번 기능은 사용자의 예약 흐름을 크게 개선해줄 수 있어.”
“마케팅 팀도 이걸 기준으로 프로모션을 계획했어.”
그런데 개발 회의에서 개발자가 말했다.
“이거, 생각보다 좀 어려울 것 같은데요…
특히 인원 수별 조건 설정이랑 승인 로직은 이번 스프린트 안에 못 끝낼 것 같아요.”
말을 아끼던 다른 개발자도 덧붙였다.
“DB 쪽 스키마도 바꿔야 하고,
백엔드 API 새로 짜야 돼요. 이거 만만치 않아요.”
순간, 데이븐은 당황스러웠다.
“이 정도면 3~4일짜리 작업 아냐?”라고 생각했지만
막상 설명을 듣고 보니 꽤 복잡한 작업이었고,
이미 마케팅 일정은 잡혀 있는 상태였다.
🔍 왜 이런 문제가 생길까?
기획자와 개발자는 서로 다른 기준으로 복잡함을 판단한다.
역할 복잡함의 기준
| 역할 | 복잡함의 기준 |
| 기획자 (PO) | 화면 흐름, 사용자 인터랙션 |
| 개발자 | 데이터 구조, 시스템 연동, 코드 재사용성 |
기획자 입장에선 “화면이 단순하니까 빨리 끝나겠지”
개발자 입장에선 “이건 백엔드 구조까지 바꿔야 돼요”
이처럼 동일한 기능을 두고 서로 전혀 다른 부담을 느끼는 것이
일정 오차의 가장 흔한 원인이다.
🧠 이렇게 풀 수 있어요
✅ 1. 기획 단계에서부터 난이도를 함께 체크하자
기획자는 화면만 설계할 게 아니라,
기능 구조의 난이도까지 함께 예측해야 한다.
“이번 기능, 복잡한 로직이 필요한 부분 있을까요?”
“현재 API나 구조를 그대로 쓸 수 있을까요?”
이 질문을 개발자에게 미리 던지면,
시간을 아끼고, 일정 충돌을 피할 수 있다.
✅ 2. 기능을 나눠서 핵심만 먼저 구현하자
모든 기능을 다 넣는 게 아니라,
핵심 가치가 전달되는 기능부터 우선 구현하는 게 실무다.
예시: ’단체 예약 기능’을 분리
기능 요소 포함 여부 비고
| 기능 요소 | 포함 여부 | 비고 |
| 기본 예약 등록 | ✅ 이번에 포함 | 핵심 흐름 완성 |
| 인원 수별 조건 설정 | ❌ 다음 단계로 | 복잡한 로직 보류 |
| 관리자 승인 기능 | ❌ 다음 단계로 | 비즈니스 정책 확인 필요 |
“단순하지만 작동하는 흐름”을 먼저 만들어야
테스트도 되고, 마케팅도 연기되지 않는다.
✅ 3. PO는 ’일정 조율자’가 아닌 ’합의 설계자’여야 한다
개발자와 회의할 때
“이번에 꼭 넣어야 합니다!”
라고 말하는 건 갈등을 부른다.
대신 이렇게 제안하자:
“현재 구조 안에서 가능한 범위만 먼저 구현하고,
이후 확장하는 방향으로 설계하면 어떨까요?”
“이 기능 없이도 사용자 테스트는 가능한가요?
그럼 MVP 기준을 다시 조정해보겠습니다.”
기획자는 결정권자가 아니라,
팀의 현실과 목표 사이를 연결해주는 설계자여야 한다.
💬 PO의 한마디
“우리가 지금 만드는 건
완벽한 기능이 아니라, 작동하는 흐름이에요.
그 흐름부터 먼저 살아 있어야, 다음으로 나아갈 수 있어요.”
