“저기, 개발자님... 이번 배포에 이거 하나만 더 넣으면 안 될까요? 대표님이 정말 중요하다고 하셔서...”

“안 됩니다. 지금 리소스 풀(Full)인 거 아시잖아요. 기획이 계속 바뀌면 저희는 어떡합니까?”

​회의실을 나오며 등 뒤로 느껴지는 싸늘한 시선.

메신저 창을 열어 뭐라 타이핑하다가 다시 지우기를 반복하는 오후 3시.

PM들에게 회의실은 때로 거대한 벽처럼 느껴집니다.

데이터로 논리 무장을 하고 들어가도, 경험 많은 동료들의 "현실적으로 불가능하다"는 한마디에 말문이 막히곤 하죠.

​안녕하세요. 2PM입니다.

​저 역시 그런 시절이 있었습니다.

의욕은 앞서는데 권한은 없고, 위에서는 쪼아대고 밑에서는 밀어내는 '샌드위치' 신세. 그때는 내가 말발이 부족해서, 혹은 기획이 완벽하지 않아서 무시당한다고 생각했습니다. 하지만 설득은 '말'로 하는 게 아니라, 그동안 쌓아온 '크레딧(Credit)'으로 하는 것이었다는 것을 깨닫게 되었습니다.

​

1. 우리는 왜 '설득'이 그토록 힘들까? : PM의 태생적 아이러니

설득의 과정에서 무력감을 느끼는 건 여러분의 실력 탓만은 아닙니다. PM이라는 직무 자체가 가진 구조적 모순 때문입니다.

1) 권한(Authority) 없는 책임(Responsibility)의 굴레

PM은 프로젝트의 성패를 온몸으로 책임지지만, 함께 일하는 동료들의 인사고과를 매길 권한은 대개 없습니다. 나에게 직접 보고하지 않는 사람들을 이끌어 성과를 내야 하는 '비선형적 리더십'을 요구받는 자리인 셈이죠. 명령할 수 있는 권력이 없다는 사실은 실무진 사이에서 늘 심리적 열세에 놓이게 만드는 근본적인 원인이 됩니다.

2) ​'부탁하는 사람'이 되어버리는 심리적 함정

강제할 권한이 없다 보니, 협조를 구할 때 나도 모르게 "미안하지만...", "한 번만 도와주시면..." 같은 표현을 쓰게 됩니다. 협업을 '비즈니스적 파트너십'이 아니라 '개인적인 부탁'으로 프레임 지으면서, 거절당했을 때의 타격감을 온몸으로 받아내게 됩니다.

​물론, 인사권이 있다고 해서 무리하게 지시하는 것은 더 위험합니다. 공포로 만든 동의는 결국 '태업'이나 '이탈'이라는 부작용을 낳기 때문입니다. 결국 PM에게 필요한 건 권력이 아니라, 권한 없이도 사람을 움직이게 만드는 '진짜 영향력'입니다.

3) ​지식의 비대칭성, '모르는 영역'에 대한 막연한 공포

"기술적으로 불가능합니다"라는 개발자의 한마디에 "왜요?"라고 묻고 싶지만, 혹시 무식해 보일까 봐 입을 닫게 됩니다. 내가 직접 구현하지 않는 영역에 대해 설득해야 한다는 압박감은 PM을 위축시키고, 결국 논리적인 설득 대신 상급자의 권위(ex. 대표님이 시켰어요)를 빌려오는 악수를 두게 만듭니다. 하지만 '이름 빌리기'는 내 실력을 갉아먹는 가장 빠른 길입니다.

하지만 기억하세요. 동료들이 당신을 따르는 이유는 당신의 직급 때문이 아닙니다. ‘저 PM이 가져온 일은 해볼 만하다’, ‘저 사람과 일하면 내 성과도 빛난다’는 믿음, 즉 크레딧 때문입니다.

​2. 기획자의 크레딧 : 보이지 않는 신용 통장의 입출금 내역

크레딧은 하루아침에 쌓이지 않습니다. 하지만 매일 반복되는 사소한 태도와 의사결정의 순간들로 조금씩 입금되거나, 단 한 번의 실수로 '신용 불량' 상태가 되기도 합니다.

📈 신뢰 입금 (Deposit) : "저 기획자는 내 시간을 아껴준다"

동료들의 크레딧을 얻는 가장 확실한 방법은 그들의 '업무 효율'을 높여주는 것입니다.

- ​디테일의 설계 (D3의 힘): "이건 에러 나면 어떻게 해요?"라는 질문이 나오기 전, 지난 글에서 강조한 예외 케이스와 리스크 대응안(Depth 3)이 포함된 문서를 내미는 것입니다. 개발자가 로직을 짜다 멈추고 PM을 찾아오는 시간을 0으로 만드는 것, 그것이 가장 큰 입금입니다.

- ​전략적 방패 역할: 위에서 내려오는 무리한 요구사항이나 불명확한 지시를 PM 선에서 1차로 필터링하고 명분을 만들어올 때입니다.

. ​방패 역할을 했다면, 슬쩍 생색을 내는 것도 기술입니다. "대표님은 이번 주까지 원하셨는데, 우리 구현 퀄리티를 위해 제가 다음 주 화요일로 협의해서 시간을 좀 벌어왔습니다"라고 말해 보세요. '나를 위해 싸워주는 사람'이라는 인식을 심어주는 순간, 보너스 크레딧이 들어옵니다.

- ​사전 차단: 회의 때 나온 기술적 제약이나 타 부서와의 협의 사항을 PM이 미리 해결해두어, 실무진이 코딩과 디자인에만 집중할 수 있는 환경을 만들어줄 때입니다.

- ​투명한 공유와 대안 제시: 일정이 늦어질 것 같을 때 "죄송합니다"만 반복하는 것이 아니라, "리소스 부족으로 A 기능은 다음 차수로 미루고 B 핵심 기능에 집중해 일정 내 배포하는 대안을 가져왔습니다"라고 가장 먼저 공유할 때입니다. 물론 이러한 대안과 일정들은 팀원들이 납득 가능하고 논리적이어야 합니다.

​📉 신뢰 출금 (Withdrawal) : "저 기획자와 일하면 피곤하다"

반대로 동료들이 당신을 '리스크' 그 자체로 인식하게 만드는 행동들입니다.

- ​추상적이고 모호한 지시: "일단 힙하게(?) 해주세요", "유튜브처럼 세련된 느낌 아시죠?" 같은 기준 없는 요구를 던지는 것입니다. 이는 동료의 상상력을 테스트하는 게 아니라, 그들의 시간을 '버리게' 만드는 행위입니다.

- ​기술적 무지와 마법적 사고: "이거 그냥 버튼 하나만 추가하면 되는 거 아니에요?"라며 기술적 부채(Technical Debt)*나 공수를 무시하고 쉽게 말할 때입니다. 동료는 당신이 자신의 전문성을 존중하지 않는다고 느낍니다.

* '기술적 부채(Technical Debt)'란?

​쉽게 말해, '내일의 개발 시간을 오늘 빌려 쓰는 것'입니다. 당장 빠른 출시(ASAP)를 위해 코드를 완벽하게 정리하지 않고 '일단 돌아가게만' 짜는 상황을 말하죠. 빚을 지면 이자가 붙듯, 기술적 부채도 방치하면 나중에 새로운 기능을 추가할 때 훨씬 더 많은 시간과 에러가 발생하는 '이자'를 치러야 합니다.

​이 빚을 모른 척하고 "버튼 하나인데 왜 이렇게 오래 걸려요?"라고 묻는 PM은 출금을, "그동안 쌓인 부채를 이번에 좀 갚으시죠"라며 리팩토링 일정을 챙겨주는 PM은 어마어마한 입금을 하는 셈입니다.

​비겁한 책임 회피: 문제가 터졌을 때 "저는 기획서에 그렇게 적었는데, 소통 과정에서 오해가 있었나 봐요" 혹은 "위에서 갑자기 시킨 거라 어쩔 수 없었어요"라며 동료나 상사 탓을 하는 것입니다. 이 한 마디는 쌓아온 크레딧을 단숨에 파산시킵니다.

​- ​만성적인 '긴급' 요청 (ASAP 남발): 모든 일이 다 급하다고 말하는 기획자는 사실 우선순위를 정할 능력이 없다는 뜻입니다. 계획 없는 긴급 요청이 반복되면, 동료들은 당신의 기획을 '대충 받아도 되는 소음'으로 취급하기 시작합니다.

​입금은 티끌 모아 태산이지만, 출금은 한 방에 잔고를 거덜 냅니다. 특히 '방패 역할'과 '책임지는 태도'는 저연차와 시니어를 가르는 가장 큰 차이점이자, 가장 강력한 입금 수단이라는 점을 잊지 마세요.

입금은 천천히 쌓이지만, 출금은 한 번에 잔고를 무너뜨립니다.

그렇다면, 이미 구조적 열세에 처한 PM은 어떻게 동료를 움직이게 만들 수 있을까요? 말발도 데이터도 안 먹히는 막막한 상황에서 판을 뒤집는 저만의 실전 전략을 지금 공개합니다.