티스토리 뷰

목차



    반응형

    스타트업에서 초보PO가 겪는 10가지 상황

     

    8. 기획은 했는데 구현이 어렵대요.

    💬 “이건 구조상 구현이 힘들 것 같아요…”

    (기획서엔 다 정리해놨는데… 왜 또?)

     


    📍 상황 예시

    PO 데이븐은 ’마이페이지 개편 프로젝트’를 책임지고 있다.

    이번 개편의 목표는 “사용자가 본인 활동 이력을 명확하게 파악하고,

    관리 기능까지 스스로 처리할 수 있도록 하는 것”이었다.

     

    그는 수일간 사용자 플로우를 그리고,

    예외 조건들을 조율하고,

    디자이너와 함께 와이어프레임도 완성했다.

    노션 문서는 완벽했다.

    • 기능 목록: 체크
    • 정책 정의: 예외까지 상세히
    • 데이터 흐름: UX 상에서 완벽하게 연결
    • 피그마 시안: 커뮤니케이션 용어까지 반영

    그리고 자신 있게 개발 리뷰에 들어갔지만,

    개발자의 첫 피드백은 예상 밖이었다.

    “이거 기존 마이크로서비스 구조에 안 맞아요.”

    “지금 설계된 흐름이면 기존 API 전체를 수정해야 돼요.”

    “DB 쿼리 성능 이슈가 생길 수도 있어요.”

     

    “이게 왜 문제가 되지…?”

    데이브는 당황스럽고 속이 울컥했다.

     

    분명히 사용자 입장에서 기획했고,

    내부 UX 피드백도 좋았는데…


    🔍 왜 이런 문제가 생길까?

    기획자(PO) 시야 개발자 시야
    사용자 중심, 플로우 중심 시스템 구조, 성능, 보안 중심
    ’어떻게 쓰는가’를 설계 ’어떻게 만들어지는가’를 판단


    → 결국 두 사람은 같은 기능을 보지만

    → 전혀 다른 관점으로 이해하고 있는 것


    🧠 이렇게 풀 수 있어요

    ✅ 1. PO도 시스템의 최소 구조는 이해해야 한다

    개발자가 말하는 “어렵다”는 단순한 귀찮음이 아니다.

    • 기술 부채
    • 구조 충돌
    • 성능 저하 우려

    → 이 정도 개념은 PO도 알아야 한다.

     

    ✅ 2. 기획 초안 단계부터 ’공동 설계’하자

    기획 다 끝난 후 피드백이 아니라,

    초안 단계부터 기술적 시선을 반영하자.

    “이 흐름에 기술적 부담 있나요?”

    “이 방식보다 나은 구조가 있을까요?”

     

    ✅ 3. UX 이상주의에서 벗어나자

    좋은 UX는 구현 가능한 UX여야 한다.

    기능이 너무 복잡하거나,

    비용 대비 효율이 낮다면

    그건 ’멋진 이상’일 뿐이다.

    ✅ 4. 개발자의 “이건 어렵다”는 거절이 아니다

    “어렵다”는 “불가능하다”는 뜻이 아니다.

    그건 협상의 시작이다.

    “가능한 대체안이 있을까요?”

    “어디까지가 현실적으로 가능한지 알려주세요”

     

    ✅ 5. 개발 난이도까지 반영한 기획 우선순위 정리법

    기능 사용자 가치 개발 난이도 우선순위
    최근 활동 로그 중간 낮음 ✅ 빠른 적용
    전체 이력 타임라인 높음 높음 ⚠︎ 단계적 적용
    AI 기반 개인화 추천 낮음 매우 높음 ❌ 보류

     


    💬 PO의 말 한마디

    “기획은 문서가 아니라 합의 과정입니다.

    그리고 그 합의는 기술과 사용자를 잇는

    단 하나의 브릿지인 PO가 만들어야 하죠.”

    반응형