"난 개발 몰라서 못해요"라는 기획자를 설득하는 테크 리더의 무기: What/Rule vs How/Tech 프레임워크

📌 들어가는 글: 왜 기획자는 "개발을 모른다"며 방어 태세를 취할까?

IT 조직에서 프로젝트를 진행하다 보면 너무나 자주 목격되는 장면이 있습니다. 개발자가 예외 상황 처리에 대해 기획자에게 질문을 던질 때입니다.

👨‍💻 개발자: "PG사 결제 요청을 보냈는데 10초 넘게 타임아웃 응답이 오면 트랜잭션 예외 처리를 어떻게 할까요?"
👩‍💼 기획자: "어... 제가 개발을 잘 몰라서요. 그건 개발자님이 알아서 잘 처리해 주세요."

개발자는 답답해집니다. "개발을 해달라는 게 아니라, 유저한테 결제 실패라고 알려줄지 재시도를 시킬지 물어본 건데..."

기획자가 "난 개발을 몰라"라고 말하는 것은, 실제로 기술 지식이 부족해서가 아닙니다. '유저가 겪을 예외 상황에 대한 비즈니스 정책 결정'을 회피하거나, 개발자의 기술 용어 질의를 '코드나 아키텍처를 짜달라'는 요청으로 오해해서 방어 태세를 취하는 것입니다.

개발자는 아키텍처를 대신 설계해 달라는 것이 아닙니다. "이런 문제가 발생했을 때 우리 제품/서비스는 고객에게 비즈니스적으로 어떻게 반응해야 하는가?"를 묻고 있는 것입니다.

이 모호한 업무 경계선을 명확히 자르고, 기획자를 능동적인 정책 결정자로 끌어들이는 What/Rule vs How/Tech 프레임워크와 실무 설득 전략을 정리해 드립니다.

🗺️ 1. 명확한 역할 경계선: "What/Rule" vs "How/Tech"

기획자와 개발자의 역할 경계는 '코드를 작성하느냐 마느냐'가 아닙니다. 비즈니스 규칙(Rule)과 기술적 구현(Tech)으로 나누어 생각해야 합니다.

📊 역할 분담 핵심 비교표

기획자는 '비즈니스 규칙과 유저 경험(UX)'의 주인이고, 개발자는 '기술적 구현과 시스템 안정성'의 주인입니다. 개발자가 기획자에게 질문을 던질 때는 이 질문이 '비즈니스 규칙'에 속하는지 분명히 밝혀주어야 합니다.

💡 2. 기획자를 정책 결정자로 끌어들이는 3가지 실무 전략

기획자가 "개발을 모른다"며 회피하지 않고 적극적으로 정책을 정하게 만드는 3가지 커뮤니케이션 및 프로세스 전략입니다.

🔑 전략 1. "개발 언어"를 "입출력(Input/Output) 시나리오"로 번역하여 질문하기

개발 전문 용어(타임아웃, 트랜잭션, DB Lock 등)가 들어가는 순간 기획자는 뇌정지가 오며 방어 기제가 작동합니다. 질문의 형식을 유저가 눈으로 보고 경험하는 입출력(Input/Output) 선택지로 바꾸어 제시해야 합니다.

• ❌ 잘못된 질문 (개발 언어 그대로 질문):
  "PG사 서버에서 타임아웃(Timeout) 응답 오면 트랜잭션 에러 핸들링 어떻게 해요?"

• ⭕ 번역된 질문 (I/O 시나리오 질문):
  "PM님, 유저가 결제 버튼을 눌렀는데 PG사 응답이 10초 동안 안 오는 상황입니다. 이때 유저에게 [1] 무한 로딩 스피너를 계속 보여줄까요? 아니면 [2] '결제 진행 중입니다. 잠시 후 마이페이지에서 확인하세요' 팝업을 띄우고 창을 닫게 할까요? 비즈니스적으로 어떤 UX가 맞나요?"

질문이 유저 경험에 대한 선택지로 바뀌는 순간, 기획자는 비로소 자신의 도메인 지식을 활용해 의사결정을 내릴 수 있게 됩니다.

🔑 전략 2. "개발자가 임의로 결정할 때 생기는 리스크" 인지시키기

기획자가 예외 정책 정의를 포기하면, 개발자는 어쩔 수 없이 하드코딩이나 임의의 처리 방식을 선택하게 됩니다. 이것이 차후 '기술 버그'가 아닌 '기획 기형/CS 폭주'로 되돌아옴을 인지시켜야 합니다.

💬 설득 멘트 예시:
"PM님, 이 예외 케이스 정책을 지금 안 정해주시면 제가 임의로 '에러 팝업을 띄우고 입력값을 초기화'하도록 개발할 수밖에 없습니다.
하지만 나중에 유저가 결제는 정상 완료되었는데 화면이 초기화되어 재결제를 진행하면서 CS 문의가 폭주하게 된다면, 이것은 시스템 버그가 아니라 기획 정책 미비 문제가 됩니다.
코딩이나 아키텍처는 모르셔도 괜찮습니다. 유저에게 보여줄 비즈니스 동작 방식만 선택해 주세요."

이러한 설명은 기획자에게 책임을 전가하는 것이 아니라, 자신의 기획 권한과 영향력을 일깨워주는 정당한 커뮤니케이션입니다.

🔑 전략 3. 기획서 제출 기준(DoR)에 '예외 정책 표' 의무화

개인의 커뮤니케이션에만 의존하지 않고, 기획서 작성 시스템 자체에 [예외 흐름 / 정책] 항목을 필수 입력값으로 만들어 두어야 합니다.

개발팀에 일감이 넘어가기 위한 사전 조건(Definition of Ready, DoR)으로 다음 예외 정책 템플릿 작성을 공식적으로 요구하세요.

📋 기획자용 예외 정책 정의 템플릿 (PRD 필수 포함)

1. [입력값 오류] 사용자가 필수 항목을 안 채우고 제출을 누르면
   ➡️ (어떤 문구를 어디에 노출하며, 포커스는 어디로 이동하는가?)

2. [외부 시스템 장애] 카카오/네이버/PG 연동 실패 및 타임아웃 발생 시
   ➡️ (어떤 안내 화면/팝업을 보여주며, 재시도 버튼을 제공하는가?)

3. [중복 / 동시 요청] 사용자가 제출/결제 버튼을 연타하는 경우
   ➡️ (첫 번째 요청만 인정하고 화면 버튼을 비활성화하는가?)

4. [권한 / 상태 이상] 로그인 세션 만료 또는 탈퇴 계정으로 접근 시
   ➡️ (어디로 리다이렉트 시키며, 어떤 메시지를 보여주는가?)

🔄 3. 실무 요구사항 정제 협업 프로세스

구축된 R&R과 DoR 템플릿을 바탕으로 작동하는 실무 백로그 정제 프로세스입니다.

  1. 기획서 작성        2. DoR 검증           3. I/O 질문 번역       4. 최종 정책 확정
┌────────────────┐    ┌────────────────┐    ┌────────────────┐    ┌────────────────┐
│ PM: What/Rule  │ ─► │ 개발팀: 예외표 │ ─► │ 개발자: 기술용어│ ─► │ PM: 비즈니스   │
│ 중심 PRD 작성  │    │ 누락 여부 확인 │    │ I/O 선택지 번역│    │ 정책 최종 결정 │
└────────────────┘    └────────────────┘    └────────────────┘    └────────────────┘

1. 기획서 작성 (PM): 비즈니스 목적, 정상 유저 플로우, 기본 예외 정책 표 작성.
2. DoR 검증 (개발팀): 예외 정책 표 작성 여부 및 외부 API 연동 문서 확보 여부 확인.
3. I/O 질문 번역 (개발자): 정제 미팅 중 놓친 기술적 예외 상황을 유저 표면 시나리오(Input/Output)로 번역하여 질문.
4. 최종 정책 확정 (PM): 비즈니스 가치와 유저 경험을 고려하여 예외 동작 최종 확정.

🎯 맺음말: "개발을 모른다"는 말을 "규칙을 정하겠다"로 바꾸기

기획자가 "개발을 모른다"고 할 때, 우리는 이렇게 고쳐 말해주어야 합니다.

"개발을 해달라는 게 아닙니다. 우리 서비스가 고객에게 어떻게 동작해야 하는지 '비즈니스 규칙'을 결정해 달라는 것입니다."

기술 용어를 벗겨내고 "유저에게 무엇이 보이고, 무슨 일이 일어나야 하는가?"라는 비즈니스 질문으로 변환할 때, PM과 개발자는 비로소 각자의 전문성을 발휘하는 최고의 파트너가 될 수 있습니다.

오늘 개발팀 미팅에서 기술 용어로 가득 찬 질문을 유저 입출력 시나리오로 다듬어 던져보세요. 조직 전체의 협업 효율이 놀라울 정도로 달라질 것입니다.