PM으로 살아남기

개발자는 안 된다고 하고, 경영진은 무조건 하라고 할 때

PM의 삶은 화려한 기획보다 고달픈 '조율'의 연속입니다. 특히 가장 난처한 순간은 경영진과 개발팀 사이에서 '샌드위치'가 되었을 때입니다. 경영진은 "다음 달 이벤트 전까지 이 기능을 무조건 넣으세요"라고 압박하는데, 개발팀은 "구조적으로 불가능해요. 지금 넣으면 버그 터집니다"라고 맞섭니다.

오늘은 이 난감한 상황을 타개하고, 모두가 납득할 수 있는 최적의 합의점을 도출하는 PM만의 생존 협상법, 바로 '양방향 통역의 기술'에 대해 이야기해 보려고 합니다.

경영진에게: '기술적 제약'을 '비즈니스 리스크'로

먼저 경영진을 설득할 때 가장 중요한 것은 언어의 선택입니다. 경영진에게 "서버 아키텍처가 복잡해서 안 됩니다"나 "레거시 코드가 많아서 힘들어요" 같은 기술적 핑계는 통하지 않습니다. 그들은 기술이 아닌 '비즈니스'를 보는 사람들이기 때문입니다. 따라서 PM은 기술적 제약을 '비즈니스 리스크'와 '비용'의 언어로 번역해야 합니다.

예를 들어, "개발팀이 안 된대요"라고 말하는 대신 이렇게 말해보세요. "대표님, 일정에 맞춰 강제로 기능을 넣을 수는 있지만, 그렇게 되면 결제 오류가 발생할 확률이 20% 증가합니다. 이번 이벤트의 목표가 매출 극대화인데, 결제 실패로 인한 예상 손실액이 약 5천만 원으로 추산됩니다." 이렇게 기술적 부채를 돈과 신용의 문제로 환산해서 제시하면, 경영진은 무리한 요구를 철회하고 합리적인 의사결정을 내릴 수밖에 없습니다.

개발팀에게: '무조건적인 지시' 대신 '비즈니스 맥락'을

반대로 개발팀을 움직이는 힘은 '납득'에서 나옵니다. 개발자들이 가장 싫어하는 것은 영문도 모른 채 내려오는 '탑다운(Top-down) 지시'입니다. "위에서 까라면 까야죠"라는 식의 태도는 개발팀의 사기를 꺾고 방어적인 태도를 취하게 만듭니다. PM은 이 기능이 왜 필요한지, 회사가 처한 '비즈니스 맥락(Context)'을 투명하게 공유해야 합니다.

"대표님이 시켰어요" 대신 이렇게 접근해 보세요. "현재 우리 경쟁사가 치고 올라오고 있어서, 이번 달에 이 기능을 출시하지 못하면 점유율을 5% 뺏길 위기입니다. 완벽한 구조가 아닌 건 알지만, 이번 한 번만 '기술 부채'를 안고 빠르게 출시한 뒤 다음 스프린트에 리팩토링할 시간을 반드시 확보해 드리겠습니다." 이렇게 문제 해결의 파트너로서 도움을 요청하고 '부채 상환'을 약속한다면, 개발자들은 PM을 믿고 불가능해 보이는 일정에도 기꺼이 헌신해 줄 것입니다.

싸우지 않고 이기는 '제3의 대안' 제시하기

결국 샌드위치 PM이 살아남는 방법은 A안(경영진)과 B안(개발팀) 중 하나를 선택하는 것이 아니라, 창의적인 '제3의 대안(Trade-off)'을 만들어내는 것입니다. 경영진에게는 "일정을 맞추려면 기능 범위를 줄여야 합니다"라고 제안하고, 개발팀에게는 "일정을 늦출 순 없으니, 대신 이 부분은 하드코딩으로 일단 처리합시다"라고 조율하는 것입니다.

모든 것을 다 가질 수는 없음을 인정하고, '범위(Scope), 일정(Time), 품질(Quality)'이라는 세 가지 변수 중에서 무엇을 희생하고 무엇을 지킬지 협상하는 것, 그것이 바로 PM이 발휘해야 할 진정한 리더십입니다. 양쪽의 압박을 견디는 것을 넘어, 양쪽을 잇는 단단한 다리가 되어주세요.