8. 기획은 했는데 구현이 어렵대요.
💬 “이건 구조상 구현이 힘들 것 같아요…”
(기획서엔 다 정리해놨는데… 왜 또?)
📍 상황 예시
PO 데이븐은 ’마이페이지 개편 프로젝트’를 책임지고 있다.
이번 개편의 목표는 “사용자가 본인 활동 이력을 명확하게 파악하고,
관리 기능까지 스스로 처리할 수 있도록 하는 것”이었다.
그는 수일간 사용자 플로우를 그리고,
예외 조건들을 조율하고,
디자이너와 함께 와이어프레임도 완성했다.
노션 문서는 완벽했다.
- 기능 목록: 체크
- 정책 정의: 예외까지 상세히
- 데이터 흐름: UX 상에서 완벽하게 연결
- 피그마 시안: 커뮤니케이션 용어까지 반영
그리고 자신 있게 개발 리뷰에 들어갔지만,
개발자의 첫 피드백은 예상 밖이었다.
“이거 기존 마이크로서비스 구조에 안 맞아요.”
“지금 설계된 흐름이면 기존 API 전체를 수정해야 돼요.”
“DB 쿼리 성능 이슈가 생길 수도 있어요.”
“이게 왜 문제가 되지…?”
데이브는 당황스럽고 속이 울컥했다.
분명히 사용자 입장에서 기획했고,
내부 UX 피드백도 좋았는데…
🔍 왜 이런 문제가 생길까?
| 기획자(PO) 시야 | 개발자 시야 |
| 사용자 중심, 플로우 중심 | 시스템 구조, 성능, 보안 중심 |
| ’어떻게 쓰는가’를 설계 | ’어떻게 만들어지는가’를 판단 |
→ 결국 두 사람은 같은 기능을 보지만
→ 전혀 다른 관점으로 이해하고 있는 것
🧠 이렇게 풀 수 있어요
✅ 1. PO도 시스템의 최소 구조는 이해해야 한다
개발자가 말하는 “어렵다”는 단순한 귀찮음이 아니다.
- 기술 부채
- 구조 충돌
- 성능 저하 우려
→ 이 정도 개념은 PO도 알아야 한다.
✅ 2. 기획 초안 단계부터 ’공동 설계’하자
기획 다 끝난 후 피드백이 아니라,
초안 단계부터 기술적 시선을 반영하자.
“이 흐름에 기술적 부담 있나요?”
“이 방식보다 나은 구조가 있을까요?”
✅ 3. UX 이상주의에서 벗어나자
좋은 UX는 구현 가능한 UX여야 한다.
기능이 너무 복잡하거나,
비용 대비 효율이 낮다면
그건 ’멋진 이상’일 뿐이다.
✅ 4. 개발자의 “이건 어렵다”는 거절이 아니다
“어렵다”는 “불가능하다”는 뜻이 아니다.
그건 협상의 시작이다.
“가능한 대체안이 있을까요?”
“어디까지가 현실적으로 가능한지 알려주세요”
✅ 5. 개발 난이도까지 반영한 기획 우선순위 정리법
| 기능 | 사용자 가치 | 개발 난이도 | 우선순위 |
| 최근 활동 로그 | 중간 | 낮음 | ✅ 빠른 적용 |
| 전체 이력 타임라인 | 높음 | 높음 | ⚠︎ 단계적 적용 |
| AI 기반 개인화 추천 | 낮음 | 매우 높음 | ❌ 보류 |
💬 PO의 말 한마디
“기획은 문서가 아니라 합의 과정입니다.
그리고 그 합의는 기술과 사용자를 잇는
단 하나의 브릿지인 PO가 만들어야 하죠.”
