기획서가 내려왔다. "쿠폰 시스템을 만들어주세요. 관리자가 쿠폰을 생성하고, 사용자가 적용할 수 있어야 합니다."

바로 코드를 쓰기 시작했다. 쿠폰 생성 API, 적용 API, 관리자 페이지, 사용자 UI. 2주 만에 완성했다. 기획서에 적힌 대로 동작했다.

그런데 출시 후 문제가 생겼다. 마케팅팀이 "특정 상품에만 적용되는 쿠폰"을 원했다. 기획서에는 없었지만, 비즈니스 관점에서 당연히 필요한 기능이었다. 쿠폰 모델의 설계를 처음부터 바꿔야 했다.

기획서를 받았을 때 "왜 쿠폰 시스템이 필요한가?"를 물어봤다면, "이번 프로모션에서 특정 카테고리 할인을 하려고요"라는 답을 들었을 거다. 그러면 처음부터 카테고리/상품 필터를 고려한 설계를 했을 거다.

What vs Why#

기획서는 대부분 "What"을 알려준다. 무엇을 만들어야 하는지. 그런데 개발자가 "Why"를 모르면, 기획서에 명시되지 않은 중요한 요구사항을 놓친다.

What: 사용자 프로필 페이지에 "활동 뱃지"를 보여주세요
Why: 사용자 이탈이 늘고 있어서, 활동에 대한 보상감을 주려는 거예요

Why를 알면 생각이 달라진다. "뱃지를 그냥 보여주는 것"이 아니라, "뱃지를 획득했을 때 성취감을 줘야 한다"로 목표가 바뀐다. 그러면 획득 순간의 애니메이션, 알림, 공유 기능을 제안할 수 있다. 기획서에 없더라도.

질문하는 법#

PM에게 "왜요?"라고 대놓고 물으면 도전적으로 들릴 수 있다. 질문의 프레이밍이 중요하다.

"이 기능의 성공 지표가 뭔가요?" 이 질문 하나로 비즈니스 목표가 명확해진다. "DAU를 높이려는 건지, 결제 전환율을 올리려는 건지"에 따라 기술적 접근이 달라진다.

"사용자가 이 기능을 가장 많이 쓸 상황이 어떤 건가요?" 사용 맥락을 이해하면, UI 설계와 성능 최적화의 우선순위가 보인다.

"이 스펙에서 꼭 있어야 하는 것과 나중에 추가해도 되는 게 뭔가요?" MVP 범위를 명확히 한다. 이걸 안 물어보면 전부 필수인 줄 알고 과도하게 만들게 된다.

기술적 판단으로 기획을 바꾸기#

때로는 개발자의 기술적 판단이 기획을 더 좋게 만든다.

기획서에 "실시간 알림"이 적혀 있다고 하자. WebSocket을 붙이면 되지만, 요구사항을 자세히 보니 "주문 상태가 바뀌면 알림을 보내줘야 한다"는 거다. 주문 상태 변경은 평균 1시간에 한 번 정도. 이걸 위해 WebSocket 연결을 계속 유지할 필요가 있을까?

"폴링으로 30초마다 체크하면 충분하고, WebSocket보다 구현과 운영이 훨씬 단순합니다. 사용자 경험 차이도 거의 없습니다."

이렇게 제안하면 PM도 동의하는 경우가 많다. 불필요한 복잡도를 줄이면서 같은 사용자 경험을 제공할 수 있으니까.

반대로, 기획서에는 "정적 페이지"로 되어 있지만 기술적으로 "사실 이건 ISR로 하면 관리자가 직접 수정할 수 있게 됩니다. 개발 요청 없이도요"라고 제안할 수도 있다. PM은 기술적 가능성을 다 알지 못한다. 개발자가 가능성을 보여주면 더 좋은 프로덕트가 나온다.

스펙을 줄이는 용기#

PM이 가장 고마워하는 개발자는 일정을 잘 지키는 사람이 아니라, "이건 안 만들어도 됩니다"라고 말해주는 사람이라는 걸 알게 됐다.

기능이 추가될수록 복잡도가 올라가고, 일정이 밀리고, 버그가 늘어난다. "이 기능은 사용률이 낮을 것 같은데, 출시 후 데이터를 보고 추가해도 되지 않을까요?"라는 제안은 PM에게 의사결정 근거를 주는 것이다.

물론 이건 신뢰가 쌓인 후에 할 수 있는 이야기다. 신입이 첫날부터 "이거 필요 없는 것 같은데요"라고 하면 곤란하다. 먼저 요청받은 일을 잘 해내서 신뢰를 쌓고, 그 위에서 제안해야 받아들여진다.

코드만 잘 쓰는 개발자는 많다. 비즈니스를 이해하고, 기획에 기여하고, 불필요한 일을 줄여주는 개발자는 드물다. 그 차이가 시니어와 주니어를 가르는 기준 중 하나다.