거절하는 법: PM이 "No"라고 말하는 전략

8 min read0 viewsBy Colemearchy
거절커뮤니케이션경계 설정PM프로젝트 관리인간관계협업리더십의사소통우선순위

거절하는 법: PM이 "No"라고 말하는 전략

"죄송하지만, 그건 안됩니다." 이 얼마나 듣기 싫은 말인가요? 특히 PM이라는 자리는, 온갖 요청과 요구사항에 시달리는 자리입니다. "이 기능 하나만 추가해주세요!", "이 버그, 오늘 안에 꼭 고쳐주세요!", "디자인, 폰트만 조금만 바꿔주세요!"... 끝이 없죠. PM은 마치 ATM기 같습니다. 돈(자원)을 뽑아 쓸 수 있을 것 같지만, 실제로는 한정된 자원을 효율적으로 관리해야 하는 책임이 막중한 자리입니다.

하지만, 모든 요청에 "Yes"라고 답하는 것은 팀을 파멸로 이끄는 지름길입니다. 우선순위는 흐려지고, 자원은 낭비되며, 결국 중요한 목표 달성에는 실패하게 됩니다. 거절은, 단순한 '싫다'는 표현이 아니라, 전략적인 선택입니다. 오늘은 PM으로서, 어떻게 감정 소모 없이, 효과적으로 "No"라고 말할 수 있는지, 그 전략을 파헤쳐 보겠습니다.

1. 거절의 배경: 왜 "No"라고 말해야 하는가?

디자이너 출신인 저는, 처음 PM 역할을 맡았을 때, 거절이라는 단어가 너무나 어색했습니다. "안돼요"라는 말은 마치 개인적인 거부처럼 느껴졌고, 팀원들의 사기를 떨어뜨릴까 봐 두려웠습니다. 하지만, 현실은 달랐습니다. 모든 요청을 수용하려다 보니, 팀은 번아웃 직전에 놓였고, 프로젝트는 산으로 가고 있었습니다.

1.1. 시간과 자원의 제약: 현실을 직시하라

PM은 팀의 시간과 자원을 관리하는 사람입니다. 모든 프로젝트에는 마감일이 있고, 팀원들의 에너지도 한정되어 있습니다. 새로운 기능을 추가하거나, 버그를 수정하는 데는 반드시 시간과 노력이 필요합니다. 만약 시간과 자원이 무한정 있다면, 모든 요청을 수용할 수 있겠지만, 현실은 그렇지 않습니다. 80/20 법칙처럼, 20%의 노력이 80%의 결과를 만들어낼 수 있다면, 나머지 80%의 노력은 과감하게 포기해야 합니다. 커뮤니케이션의 기술 같은 책을 읽으며, 효율적인 자원 배분에 대한 고민을 끊임없이 했습니다.

1.2. 우선순위의 중요성: 무엇이 중요한가?

모든 요청이 똑같이 중요한 것은 아닙니다. 어떤 요청은 핵심 기능에 필수적이지만, 어떤 요청은 단순한 편의 기능에 불과할 수 있습니다. PM은 팀과 함께, 어떤 기능이 가장 중요한지, 어떤 버그를 먼저 수정해야 하는지 우선순위를 정해야 합니다. 우선순위를 정하는 데는 데이터 분석, 사용자 피드백, 그리고 시장 상황에 대한 이해가 필요합니다. 우선순위를 명확하게 설정하면, 거절은 더 쉬워집니다. "죄송하지만, 지금은 X 기능 개발에 집중해야 합니다. Y 기능은 다음 스프린트로 미루겠습니다."와 같이, 명확한 이유를 제시할 수 있기 때문입니다.

1.3. 팀의 사기 유지: 장기적인 관점을 가져라

모든 요청을 수용하는 것이 팀의 사기를 높이는 것처럼 보일 수 있지만, 장기적으로는 오히려 부정적인 영향을 미칩니다. 팀원들은 과도한 업무에 지쳐 번아웃될 수 있고, 우선순위 없는 업무에 혼란을 느낄 수 있습니다. PM은 팀원들의 능력과 한계를 고려하여, 적절한 업무량을 배분해야 합니다. 때로는 "No"라고 말하는 것이, 팀원들을 보호하고, 장기적으로 팀의 사기를 유지하는 데 도움이 됩니다.

2. 거절의 기술: "No"라고 말하는 전략

자, 이제 본격적으로 "No"라고 말하는 기술에 대해 알아봅시다. 단순히 "안돼요!"라고 외치는 것은, 문제를 해결하는 것이 아니라, 갈등을 유발하는 행위입니다. PM은 감정적인 반응을 자제하고, 논리적이고 설득력 있는 방식으로 거절해야 합니다.

2.1. 공감대 형성: 상대방의 입장을 이해하라

거절하기 전에, 먼저 상대방의 입장을 이해하려고 노력해야 합니다. 왜 이 기능을 추가하고 싶어하는지, 왜 이 버그를 빨리 수정해야 하는지, 그 이유를 물어보고, 경청해야 합니다. 상대방의 요구사항에 공감하는 모습을 보여주면, 거절에 대한 반감을 줄일 수 있습니다. 예를 들어, 디자이너가 폰트 변경을 요청했을 때, "폰트 변경이 사용자 경험에 얼마나 중요한 영향을 미칠 수 있는지 이해합니다. 하지만, 현재 개발 일정을 고려했을 때, 폰트 변경은 어렵습니다."와 같이, 공감하는 태도를 보여주는 것이 중요합니다.

2.2. 명확한 이유 제시: 데이터와 논리로 설득하라

단순히 "안된다"고 말하는 대신, 명확한 이유를 제시해야 합니다. 왜 이 요청을 수용할 수 없는지, 데이터와 논리를 근거로 설명해야 합니다. 예를 들어, 새로운 기능 추가 요청에 대해, "현재 사용자 데이터를 분석해본 결과, 이 기능을 사용하는 사용자는 5% 미만입니다. 이 기능을 개발하는 데는 2주 이상의 시간이 소요될 것으로 예상됩니다. 2주 동안 다른 중요한 기능을 개발하는 것이, 더 많은 사용자에게 도움이 될 것입니다."와 같이, 데이터와 논리를 제시하면, 상대방은 거절을 더 쉽게 받아들일 수 있습니다. 2023년 PM 대상으로 한 설문조사 결과, 78%가 데이터 기반의 의사결정이 거절의 성공률을 높인다고 응답했습니다. 설득의 심리학 같은 책을 통해, 설득력을 높이는 방법을 배우는 것도 도움이 됩니다.

2.3. 대안 제시: 문제 해결에 집중하라

거절은 단순히 "안된다"고 말하는 것이 아니라, 문제 해결을 위한 첫 걸음입니다. 거절과 함께, 대안을 제시하면, 상대방은 거절을 덜 부정적으로 받아들일 수 있습니다. 예를 들어, 버그 수정 요청에 대해, "지금 당장 이 버그를 수정할 수는 없지만, 다른 중요한 버그 수정이 완료되는 대로, 이 버그를 수정하겠습니다. 그 동안은, 이 버그를 우회할 수 있는 방법을 알려드리겠습니다."와 같이, 대안을 제시하면, 상대방은 문제를 해결하려는 PM의 의지를 느낄 수 있습니다.

2.4. 침착함 유지: 감정적인 반응은 금물

거절은 때때로 감정적인 반응을 유발할 수 있습니다. 상대방은 실망하거나, 화를 내거나, 심지어 공격적인 태도를 보일 수도 있습니다. PM은 감정적인 반응에 휘둘리지 않고, 침착함을 유지해야 합니다. 만약 상대방이 감정적으로 격앙되어 있다면, 잠시 대화를 중단하고, 시간을 갖는 것도 좋은 방법입니다. 감정적인 대화는 문제를 해결하는 데 도움이 되지 않습니다.

2.5. 문서화: 기록은 힘이 세다

모든 거절은 문서화하는 것이 좋습니다. 왜 거절했는지, 어떤 대안을 제시했는지, 그리고 상대방의 반응은 어떠했는지 기록해두면, 나중에 문제가 발생했을 때, 증거 자료로 활용할 수 있습니다. 또한, 거절 기록은 팀의 의사결정 과정을 투명하게 만들고, 팀원들의 신뢰를 얻는 데 도움이 됩니다.

3. 실전 적용: 거절 사례 분석

이제 실제 거절 사례를 통해, 앞에서 배운 전략을 어떻게 적용할 수 있는지 알아봅시다.

3.1. 사례 1: "폰트만 조금만 바꿔주세요!" (디자이너 요청)

상황: 디자이너가 프로젝트의 전체적인 분위기와 어울리지 않는다며 폰트 변경을 요청했습니다. 폰트 변경은 전체 UI에 영향을 미치므로, 개발 시간이 오래 걸릴 것으로 예상됩니다.

PM의 대응:

  1. 공감대 형성: "폰트가 전체적인 분위기에 미치는 영향이 크다는 것을 잘 알고 있습니다. 폰트 선택은 사용자 경험에 매우 중요한 요소입니다."
  2. 명확한 이유 제시: "하지만, 현재 개발 일정이 매우 촉박합니다. 폰트 변경은 전체 UI에 영향을 미치므로, 최소 3일 이상의 개발 시간이 필요합니다. 3일 동안 다른 중요한 기능을 개발하는 것이, 사용자들에게 더 큰 가치를 제공할 수 있습니다."
  3. 대안 제시: "폰트 변경 대신, 폰트 크기나 색상을 조절하는 것은 어떨까요? 폰트 크기나 색상을 조절하는 것은 개발 시간이 짧게 걸리면서도, 폰트의 가독성을 높일 수 있습니다. 아니면, 다음 스프린트에서 폰트 변경을 고려해볼 수 있습니다. 다음 스프린트에서는 폰트 변경에 필요한 시간을 충분히 확보할 수 있습니다."
  4. 결과: 디자이너는 PM의 설명을 듣고, 폰트 크기 조절로 대안을 찾았습니다. PM은 3일의 개발 시간을 절약하고, 다른 중요한 기능을 개발하는 데 집중할 수 있었습니다.

Before: 폰트 변경 요청에 난색을 표하며, 무조건 "안된다"고 말함. 디자이너는 PM의 태도에 실망하고, 프로젝트에 대한 의욕을 잃음.

After: 폰트 변경 요청에 공감하고, 명확한 이유와 대안을 제시함. 디자이너는 PM의 설명을 이해하고, 폰트 크기 조절로 대안을 찾음. 프로젝트는 일정대로 진행됨.

3.2. 사례 2: "이 기능 하나만 추가해주세요!" (마케터 요청)

상황: 마케터가 새로운 마케팅 캠페인을 위해, 기존 기능에 새로운 기능을 추가해달라고 요청했습니다. 새로운 기능은 개발 시간이 오래 걸릴 것으로 예상됩니다.

PM의 대응:

  1. 공감대 형성: "새로운 마케팅 캠페인이 매우 중요하고, 새로운 기능이 캠페인의 성공에 도움이 될 것이라는 것을 이해합니다."
  2. 명확한 이유 제시: "하지만, 현재 개발팀의 리소스가 부족합니다. 새로운 기능을 개발하는 데는 최소 1주일 이상의 시간이 필요합니다. 1주일 동안 다른 중요한 기능을 개발하는 것이, 더 많은 사용자에게 도움이 될 것입니다. 또한, 새로운 기능을 추가하면, 기존 기능에 문제가 발생할 가능성이 있습니다."
  3. 대안 제시: "새로운 기능 대신, 기존 기능을 활용하여 캠페인을 진행하는 것은 어떨까요? 기존 기능을 활용하면, 개발 시간이 필요 없고, 기존 기능에 대한 사용자의 이해도가 높기 때문에, 캠페인의 성공률을 높일 수 있습니다. 아니면, 다음 마케팅 캠페인에서 새로운 기능을 고려해볼 수 있습니다. 다음 마케팅 캠페인에서는 새로운 기능 개발에 필요한 시간을 충분히 확보할 수 있습니다."
  4. 결과: 마케터는 PM의 설명을 듣고, 기존 기능을 활용하여 캠페인을 진행하기로 결정했습니다. PM은 1주일을 절약하고, 다른 중요한 기능을 개발하는 데 집중할 수 있었습니다.

3.3. 사례 3: "이 버그, 오늘 안에 꼭 고쳐주세요!" (고객 지원팀 요청)

상황: 고객 지원팀에서 사용자에게 치명적인 버그가 발생했다며, 오늘 안에 꼭 수정해달라고 요청했습니다.

PM의 대응:

  1. 공감대 형성: "사용자에게 불편을 드려 죄송합니다. 버그가 사용자 경험에 큰 영향을 미친다는 것을 잘 알고 있습니다."
  2. 명확한 이유 제시: "하지만, 현재 개발팀은 다른 중요한 버그 수정 작업에 집중하고 있습니다. 새로운 버그를 수정하려면, 기존 버그 수정 작업을 중단해야 합니다. 기존 버그 수정 작업을 중단하면, 더 많은 사용자에게 불편을 초래할 수 있습니다."
  3. 대안 제시: "다른 버그 수정 작업이 완료되는 대로, 이 버그를 최우선적으로 수정하겠습니다. 그 동안은, 이 버그를 우회할 수 있는 방법을 사용자들에게 안내해주세요. 또한, 이 버그를 담당 개발자에게 알리고, 최대한 빨리 수정할 수 있도록 노력하겠습니다."
  4. 결과: 고객 지원팀은 PM의 설명을 듣고, 버그 우회 방법을 사용자들에게 안내하기로 결정했습니다. PM은 기존 버그 수정 작업을 완료하고, 다음 날 해당 버그를 수정했습니다.

4. 주의사항 및 함정

거절은 단순한 기술이 아니라, 예술입니다. 몇 가지 주의사항과 함정을 피해야, 효과적으로 "No"라고 말할 수 있습니다.

4.1. 개인적인 감정 배제: 객관적인 판단 유지

거절할 때, 개인적인 감정을 배제해야 합니다. 특정 팀원에게 반감이 있거나, 특정 요청이 싫다고 해서, 무조건 거절해서는 안됩니다. 객관적인 데이터를 근거로, 합리적인 판단을 내려야 합니다.

4.2. 일관성 유지: 상황에 따라 말 바꾸지 않기

거절의 기준을 일관성 있게 유지해야 합니다. 어떤 요청은 거절하고, 어떤 요청은 수용하는 등, 상황에 따라 말을 바꾸면, 팀원들의 신뢰를 잃을 수 있습니다. 명확한 기준을 세우고, 그 기준에 따라 일관성 있게 행동해야 합니다.

4.3. 완벽주의 경계: 융통성을 발휘하라

모든 것을 완벽하게 통제하려고 해서는 안됩니다. 때로는 예상치 못한 문제가 발생할 수 있고, 계획이 틀어질 수도 있습니다. 융통성을 발휘하여, 상황에 따라 적절하게 대처해야 합니다.

4.4. 소통 부족: 오해를 방지하라

거절하기 전에, 충분히 소통해야 합니다. 왜 거절하는지, 어떤 대안이 있는지, 상대방에게 충분히 설명해야 합니다. 소통 부족은 오해를 낳고, 갈등을 유발할 수 있습니다. 정기적인 회의를 통해, 팀원들과 소통하는 것이 중요합니다. 실제로, 소통이 원활한 팀은 그렇지 않은 팀보다 생산성이 25% 높다는 연구 결과가 있습니다.

5. 결론: 전략적인 거절, 성공적인 PM의 필수 조건

"No"라고 말하는 것은, PM에게 가장 어려운 일 중 하나일 수 있습니다. 하지만, 전략적인 거절은, 팀의 성공을 위한 필수 조건입니다. 공감대 형성, 명확한 이유 제시, 대안 제시, 그리고 침착함 유지. 이 모든 것을 기억하고, 실전에 적용한다면, 당신은 훌륭한 PM으로 성장할 수 있을 것입니다.

거절은, 단순히 "안된다"고 말하는 것이 아니라, 더 나은 결과를 만들기 위한 선택입니다. 당신의 "No"가, 팀을 더 강하게 만들고, 프로젝트를 성공으로 이끄는 원동력이 될 수 있다는 것을 기억하세요.

이 글이 도움이 됐다면 SNS 공유 부탁드립니다!

댓글로 당신의 경험을 공유해주세요.

주간 뉴스레터 구독하면 이런 글을 먼저 받아볼 수 있습니다.

(쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.)