"개발 몰라요"라는 무책임 뒤에 숨은 PM 걸러내기: 면접 검증법부터 조직 프로세스 방화벽까지

작성자: 테크 리더십 & 조직 효율성 인사이트
태그: #PM채용 #테크리더십 #Ownership #DoR #프로세스개선 #개발문화 #Agile #개발자와PM

📌 들어가는 글: 코딩 지식이 아니라 '주인의식'의 문제다

"아... 제가 개발을 몰라서 그러는데, 알아서 예쁘게 처리해 주세요."

개발 현장에서 테크 리더와 엔지니어의 맥을 가장 크게 짚이게 만드는 한마디입니다. 정작 자기 사업이고, 자신이 기획한 기능인데 "이럴 땐 유저에게 어떻게 동작해야 하나요?"라는 본질적인 질문에 들어가면 "개발을 모른다"는 핑계 뒤로 숨어버리는 기획자나 사업 담당자를 쉽게 찾아볼 수 있습니다.

하지만 차분히 따져봐야 합니다. 개발자가 기획자에게 물어본 것은 코딩 언어 사양이나 DB 인덱싱 구조가 아닙니다. "유저가 결제 버튼을 누르고 네트워크가 튕겼을 때, 우리 사업은 고객에게 어떤 경험을 제공할 것인가?"라는 비즈니스 규칙과 유저 경험(UX) 정책입니다.

기획자가 "개발을 모른다"고 말하는 진짜 이유는 기술 지식이 부족해서가 아니라, 자신이 만든 기획에 대한 '논리적 주인의식(Ownership)'과 '예외 케이스를 고민하는 최소한의 성의'가 없기 때문입니다.

이 무책임한 관성을 면접 단계에서 사전에 차단하는 3대 채용 검증법과, 이미 구축된 조직에서 이 핑계를 물리적으로 무력화하는 시스템 및 프레임워크를 다룹니다.

🔍 1. 면접에서 "개발 몰라요" 유형을 100% 걸러내는 3대 검증법

기획자나 PM, 사업 담당자를 채용할 때 개발 코딩 테스트를 볼 필요는 전혀 없습니다. 대신 "자신의 기획에 대한 예외 케이스를 고민해 본 적이 있는가?"를 검증해야 합니다.

① 경험 검증: "예외 상황을 개발자에게 짬처리해 본 적 있는가?"

❓ 질문: "기획서나 제안서를 작성한 후, 개발팀에서 생각지도 못한 예외 상황(Edge Case)에 대해 질문을 받았던 경험이 있나요? 그때 어떻게 해결하셨나요?"

• 🚩 Red Flag (낙방 대상):
  • "개발자님이 알아서 세부적인 건 처리해 줬습니다."
  • "그런 기술적인 부분은 개발팀 영역이라 제가 관여할 수 없었습니다."
• 🟢 Green Flag (합격 대상):
  • "제가 미처 생각하지 못한 예외 흐름이어서, 유저 관점에서 A안과 B안 중 어떤 게 비즈니스적으로 맞는지 고민한 뒤 정책을 다시 정리해서 전달드렸습니다."

② 책임 태도 검증: "장애와 버그의 원인을 어디서 찾는가?"

❓ 질문: "본인이 진행했던 프로젝트에서 라이브 배포 후 예상치 못한 버그나 유저 컴플레인이 터졌던 경험이 있나요? 원인이 무엇이었고 어떻게 개선했나요?"

• 🚩 Red Flag (낙방 대상):
  • "개발팀이나 QA에서 테스트를 제대로 안 해서 버그가 났습니다." (전형적인 남 탓과 책임 회피)
• 🟢 Green Flag (합격 대상):
  • "제가 기획할 때 예외 케이스 정책(예: 네트워크 지연 시 처리, 중복 클릭 방지 등)을 꼼꼼히 챙기지 못해 발생했던 문제입니다. 그 이후로는 기획서 작성 시 예외 처리 체크리스트를 반드시 포함시킵니다."

③ 즉석 실기 테스트 (10분 현장 과제)

면접장에서 종이 한 장을 주고 아주 단순한 상황을 던져봅니다.

📝 과제: "유저가 쇼핑몰에서 상품을 구매하려고 결제 버튼을 눌렀습니다. 이때 발생할 수 있는 '비즈니스적 예외 상황' 3가지와 각 상황별 유저 안내 정책을 적어보세요."

• 평가 기준:
  • 코딩 용어나 기술 사양을 적을 필요가 전혀 없습니다. '재고 부족', '결제 중 창 닫음', '이중 결제 발생' 같은 유저 시나리오를 떠올릴 수 있는가?
  • 만약 면접자가 *"저는 개발을 몰라서 결제 예외는 잘 모르겠습니다"*라고 답변한다면 그 자리에서 바로 감점/탈락입니다. 이것은 개발 지식이 아니라 '유저 경험에 대한 상상력'이기 때문입니다.

🧠 2. 왜 비즈니스 담당자는 자기 사업의 디테일을 모를까?

자기 사업이고 자기 프로젝트인데 정작 세부 로직을 물어보면 막히는 기괴한 현상이 반복되는 이유는, 비즈니스 직군이 "비전(Outcome)"과 "메커니즘(Process)"을 착각하기 때문입니다.

┌────────────────────────────────────────────────────────────────────────┐
│ [ 비즈니스/사업 담당자의 착각 구조 ]                                       │
│                                                                        │
│ 1. Outcome(결과/판타지)에만 몰두                                          │
│    "이 기능을 붙이면 매출이 올라도 유저가 좋아할 것이다."                    │
│                                                                        │
│ 2. Process(현실/메커니즘)의 부재                                         │
│    "재고가 0개일 때 결제 버튼을 누르면 어떤 에러 문구를 노출할 것인가?"      │
│                                                                        │
│ 3. 무책임한 외주화                                                       │
│    "아이디어는 던졌으니 99가지 지저분한 예외 처리는 똑똑한 개발팀이 알아서"    │
└────────────────────────────────────────────────────────────────────────┘

1. '결과'만 팔아왔기 때문: 사업/제안 파트는 "매출 증가", "유저 가치" 같은 상위 레벨의 판타지(Outcome)만 이야기하는 데 익숙합니다. 하지만 개발은 지저분한 예외 상황(Process)을 다루는 영역입니다.
2. '디테일'을 개발자의 몫으로 외주화했기 때문: "내가 아이디어를 냈으니 세부 정책은 개발자가 알아서 만들어주겠지"라는 무책임한 관성이 몸에 밴 것입니다.
3. '행복 회로(Happy Path)'만 상상했기 때문: 머릿속에 '정상 성공하는 1가지 시나리오'만 존재할 뿐, 시스템 장애나 중복 요청 같은 99가지 예외 상황은 애초에 생각조차 해본 적이 없는 경우가 태반입니다.

🛡️ 3. 기존 조직에서 "개발 몰라요"를 무력화하는 3대 시스템

이미 뽑아놓은 구성원들이 "개발 몰라요"를 치트키처럼 사용할 때, 이를 물리적으로 차단하는 시스템 구축법입니다.

① "개발 질문"이 아니라 "유저 질문"이라고 명칭 교정하기

상대방이 "나 개발 몰라"라고 말하는 순간, 그 자리에서 즉각 프레임을 전환시켜야 합니다.

• 💬 상황 예시:
  • PM: "아... 저 개발 몰라서 그런데 알아서 처리해 주시면 안 돼요?"
  • Tech Lead: "PM님, 코딩해 달라는 게 아닙니다. 유저가 버튼을 눌렀는데 네트워크 에러가 나면 유저한테 뭐라고 팝업을 띄울지 '유저 경험(UX)'을 정해달라는 겁니다. 이것도 개발 영역인가요? 유저 경험을 정하는 건 PM님의 본업입니다."

② '문서 빈칸 = 개발 착수 불가' 물리적 규칙(DoR) 세우기

티켓(Jira, Asana 등)이나 PRD 양식에 [예외 케이스 처리 정책] 항목을 필수 입력값(Required Field)으로 만들어 두세요.

• 이 칸이 비어있으면 개발팀 백로그에 올리지 않거나 우선순위에서 제외합니다.
• "개발을 몰라서 못 적겠다"고 하면 "그럼 이 일감은 개발 착수 준비(Definition of Ready)가 안 된 것이니 준비되면 가져오세요"라고 정당하게 입고를 거부합니다.

③ '알아서 해주세요' 금지: Two-Option Rule (양자택일 손실형 질문)

질문이나 요청을 가져올 때 최소한 본인이 고민한 A안과 B안을 가져오지 않으면 질문을 받지 않는 문화를 만드세요.

특히 주관식 질문 대신 당신이 선택하지 않으면 회사가 이런 손해를 본다는 양자택일 손실형 질문을 던져야 비로소 고민을 시작합니다.

• ❌ 주관식 질문 (피할 수 있는 여지를 줌):
  • "이 결제 타임아웃 예외 상황 정책 어떻게 할까요?" ➡️ "개발 몰라요 / 알아서 해주세요"
• ⭕ 양자택일 손실형 질문 (손실 의사결정 강제):
  • "PM님, 카카오 결제 후 타임아웃이 났을 때 [A안: 유저한테 에러 띄우고 수동 환불 처리하기 ➡️ CS 폭주 리스크]로 갈까요, 아니면 [B안: 일단 결제 성공 처리하고 밤마다 재시도 로직 돌리기 ➡️ 장부 불일치 리스크]로 갈까요? 어느 쪽 리스크를 감수하시겠어요?"

📈 4. 상식 없는 조직을 바꾸는 테크 리더의 3대 현실 전략

"이건 개발의 상식입니다"라고 접근하면 상대는 개선의 필요성을 느끼는 게 아니라 '나를 무식하다고 비난한다'고 느껴 방어 태세를 취합니다. 상식을 현실적인 비즈니스 언어와 시스템으로 번역해야 합니다.

1️⃣ '상식'을 '돈과 손실(Risk)'의 언어로 번역하기

• ❌ 상식의 언어: "요구사항 정제하고 세부 Task 쪼개는 게 개발 상식입니다."
• ⭕ 돈과 리스크의 언어: "기획 정제 단계 없이 들어가면 개발 도중 기획이 뒤엎어져 개발자 3명이 한 달간 재작업을 해야 합니다. 프로젝트당 인건비 1,500만 원씩 버리는 셈인데, 수주 후 1주일만 정제 기간을 가지면 이 비용을 100% 아낄 수 있습니다."

2️⃣ 의식 개조를 포기하고 '물리적 승인 Gate'로 가두기

사람의 마인드를 바꾸는 것은 불가능합니다. "기획서에 예외 정책이 비어있으면 개발 티켓 생성 버튼이 안 눌러지는 시스템"을 구축하세요.

3️⃣ 혼자 회사를 바꾸려 하지 말고 '내 울타리'부터 치기 (Quick Win)

회사 전체를 바꾸려다가는 번아웃이 옵니다.

• 개발팀 내부 선언: "요구사항 정제가 안 된 일감은 백로그에 올리지 않는다."
• Quick Win: 가장 협조적인 PM과 작은 프로젝트 하나를 잡아 [정제 ➡️ 공수산정 ➡️ 버퍼 반영] 체계로 완벽히 끝내고, "재작업 비용 0원으로 일정 내 완수했다"는 데이터를 만들어 경영진에게 보고하세요.

🎯 맺음말

"개발을 모르는 것"은 죄가 아니지만, "자신이 만든 서비스에서 유저가 겪을 예외 상황을 고민하지 않는 것"은 직무 유기입니다.

테크 리더의 역할은 단순히 코딩하는 것이 아니라, 비즈니스의 구멍을 메워주고 조직의 최소 수용 기준(DoR)을 세워 주도권을 가져오는 것입니다.

회사 전체를 바꿀 필요 없습니다. 오늘 당장 개발팀으로 넘어오는 일감에 '예외 정책 미작성 시 개발 착수 불가'라는 울타리 하나를 치는 것부터 시작해 보세요.

본 가이드가 도움이 되셨다면 조직 내 PM, Tech Lead, 엔지니어링 리더 분들과 공유해 보세요!