유능한 PM은 클라이언트의 친구가 아니다.
얼마 전 IT 커뮤니티에서 흥미로운 글을 하나 봤어요. 한 에이전시의 PM이 올린 글이었는데, 퇴근 후 저녁 8시에 클라이언트에게서 온 카카오톡 메시지로 시작된 하소연이었죠. "매니저님, 늦은 시간에 죄송합니다. 갑자기 좋은 아이디어가 떠올라서요."로 시작된 메시지는 끝없이 이어지는 좋은 아이디어로 밤을 꼴딱 새우게 만들었다고 해요. 더 큰 문제는, 다음 날 오전 그 클라이언트가 "어제 얘기된 것 반영해서 작업 진행하시는 거죠?"라며 슬랙을 보내왔다는 거였죠.
많은 주니어 PM분들이 이와 비슷한 경험을 하더라고요. 클라이언트와 좋은 관계를 가지는 게 우리 프로젝트에, 더 나아가 우리 회사에 도움이 될 거라는 막연한 생각, 혹은 최소한 불편한 사람이 되기 싫고 나 때문에 프로젝트가 엎어지지는 말아야 한다는 마음 때문에 프로페셔널한 선을 지키지 못하다가 오히려 프로젝트를 더 큰 수렁으로 빠뜨리는 경우 말이에요. 오늘은 ‘좋은 사람’이 되려다 ‘일 못 하는 사람’이 되지 않기 위해, 에이전시에서 일하는 PM으로서 클라이언트와 건강하고 프로페셔널한 관계를 맺는 법에 대해 이야기해 보려고 합니다.
1. “클라이언트는 잘 대해줘야지”라는 착각이 부르는 비극
프로젝트 초반, 우리는 클라이언트와 좋은 관계를 맺기 위해 노력하죠. 좋은 관계를 위해 클라이언트의 링크드인에 올라온 글에 댓글도 남기고, 회의가 끝나면 같이 커피도 마시고요. 물론 인간적인 유대를 쌓는 건 중요해요. 하지만 이 관계가 정말 친구 같은 사이로 변질되는 순간, 문제는 시작됩니다.
제가 본 어떤 주니어 PM이 처음으로 맡았던 프로젝트가 딱 그랬어요. 클라이언트 담당자분이 PM과 나이도 비슷하고 취미도 같아서 금방 친해졌죠. 그러고나니 회의록에 남기지 않은 수정사항을 메신저로 툭 던지거나, 퇴근 후에 전화해서 "OO 씨, 생각해보니까 이게 더 나을 것 같지 않아요?"라며 비공식적인 요청을 하는 일이 잦아졌어요. 그 주니어 PM은 처음엔 클라이언트와 좋은 관계를 유지하기 위해서라고 생각했는지 어떻게든 맞춰주려고 했죠.
결과는 어땠을까요? 디자이너와 개발자들은 계속되는 말 바꾸기에 지쳐갔고, 공식적인 히스토리가 없으니 책임 소재는 불분명해졌어요. 결국 프로젝트는 예상보다 3개월이나 딜레이되었고, 마지막엔 "분명히 그때 그렇게 해준다고 했잖아요!"라는 말에 그 주니어 PM은 아무런 반박도 하지 못한 채 고개를 숙여야 했습니다. 친밀함이 오히려 프로젝트의 발목을 잡는 독이 되어버린 순간이었죠.
이처럼 프로페셔널한 관계의 선이 무너지면 다음과 같은 문제들이 발생하더라고요.
비공식적 요청의 증가: 공식적인 절차(문서, 이메일)가 아닌 메신저, 전화 등 즉흥적인 요청이 늘어납니다.
히스토리 관리의 어려움: "언제, 누가, 왜" 요청했는지에 대한 기록이 남지 않아 나중에 문제가 생겼을 때 대응하기 어렵습니다.
PM의 권위 하락: 클라이언트의 모든 요구를 들어주는 사람으로 인식되어, 오히려 클라이언트에게 전문가로서의 의견이나 일정 조율 능력을 신뢰받지 못하게 됩니다.
팀원들의 혼란과 번아웃: 정제되지 않은 요구사항이 그대로 팀에 전달되면서 잦은 재작업이 발생하고, 팀원들은 PM에 대한 신뢰를 잃게 됩니다.
2. 프로페셔널의 첫 걸음, 기대치 관리하기
그렇다면 어떻게 이 선을 지킬 수 있을까요? 차갑고 딱딱한 사람이 되라는 말이 절대 아니에요. 오히려 프로젝트 시작 단계에서 서로 존중하며 일할 수 있는 규칙을 명확하게 세우는 것이 진짜 프로의 모습이죠.
제가 프로젝트를 시작할 때 반드시 지키는 3가지 원칙이 있어요.
원칙 1: 안 하는 일(Scope-out)부터 명확히 합의하기 킥오프 미팅 때 "이번 프로젝트에선 SNS 간편 로그인은 제외하고, 이메일 가입/로그인 기능만 구현합니다"처럼 이번 버전에서 '하지 않을 일'을 명확히 정의하고 회의록에 남겨두세요. 이건 나중에 "로그인 기능이면 당연히 소셜 로그인도 포함인 줄 알았어요" 같은 말을 방지하는 가장 강력한 방어막이 되어줄 겁니다.
원칙 2: 변경 요청 양식화하기 프로젝트 시작 전, 간단한 변경 요청서 양식을 만들어 클라이언트에게 공유하세요. "앞으로 모든 추가/수정 요청은 이 양식을 통해 공식적으로 접수해 주셔야 저희가 누락 없이 검토하고 영향도를 분석해 드릴 수 있습니다"라고요. 이건 PM 개인의 판단이 아니라, 시스템에 의해 일이 처리된다는 인식을 심어주는 아주 중요한 장치입니다.
원칙 3: "최종 결정권자의 확인을 꼭 받아주세요" 생각보다 많은 프로젝트가 실무자의 의견만 듣고 진행되다가, 뒤늦게 나타난 임원급의 한 마디에 전부 뒤집어지곤 해요. 클라이언트 측의 최종 의사 결정권자가 누구인지 반드시 확인하고, 중요한 의사결정 회의에는 꼭 그분이 참석해야 한다고 정중하지만 단호하게 요청해야 합니다.
3. 불편한 대화를 편안하게 만드는 소통의 기술
물론 이렇게 방어막을 세워도 클라이언트의 요청은 계속될 거예요. 방금 말했듯, 결국 실무자와 아무리 규칙을 잘 세워놔도 클라이언트 측의 최종 결정권자가 난입하기 시작하면 규칙은 쉽게 무시되곤 하니까요(ㅜㅜ). 이때 PM들이 섣부르게 "안됩니다"라고 말하는 건 최악의 대응이죠. 프로페셔널한 PM은 물론 클라이언트의 요청을 수락하기만 하는 사람이 아니지만, 쉽게 거절하는 사람도 아닙니다. 오히려 대안을 제시하고 클라이언트가 최적의 결정을 내리도록 돕는 협상가가 되어야 합니다.
만약 클라이언트가 갑자기 "요즘 앱들 보니까 다크 모드는 기본이던데, 우리도 추가해야 하지 않을까요?"라고 요청했다면 어떻게 대응해야 할까요?
Client: "PM님, 저번에 말씀 못드렸는데 우리도 다크 모드 추가해야 하지 않을까요? 다크모드는 필수 같은데."
Bad PM: "아... 그건 기획에 없던 거라 지금 추가는 좀 어렵습니다. 일정상 힘들어요." (Fact, 하지만 상대방을 김 빠지게 만든다)
Good PM: "아, 다크 모드 정말 좋은 아이디어네요! 요즘 사용자 경험에 중요한 부분이죠. 요청 주신 내용 저희가 공식적으로 접수해서, 이 기능을 추가했을 때 디자인과 개발에 어느 정도의 시간과 리소스가 더 필요한지 빠르게 분석해 보겠습니다. 내일 오전까지 구체적인 영향도와 함께 몇 가지 선택지를 가지고 다시 말씀드려도 괜찮을까요?"
차이가 느껴지시나요? 좋은 PM은 일단 상대의 의견을 긍정적으로 수용한 뒤, 불분명한 느낌이 아닌 분명한 프로세스와 데이터의 영역으로 대화를 가져옵니다. 그리고 다음 날, 이런 식으로 선택지를 제시하는 거죠.
Good PM: "어제 말씀 주신 다크 모드 적용 건 분석해 보았습니다.
1안: 현재 일정에 다크 모드까지 추가하면, 약 2주의 개발 기간이 더 필요해서 원래 오픈일보다 2주 정도 늦어질 것 같습니다.
2안: 만약 원래 일정대로 오픈하는 게 중요하다면, 우선순위가 조금 낮은 마이페이지 설정 기능을 다음 업데이트로 미루고 다크 모드를 먼저 개발하는 방법도 있습니다.
저희가 판단하기엔... (전문가 의견 제시) ...입니다. 이 프로젝트의 비즈니스 목표를 고려했을 때 어떤 선택이 더 좋을지 함께 논의해 보면 좋겠습니다."
이렇게 하면 클라이언트는 단순히 요청이 거절당했다고 느끼는 대신, 프로젝트의 목표를 위해 함께 고민하고 있다는 인상을 받게 됩니다. 불편할 수 있는 거절의 과정이, 오히려 신뢰를 쌓는 협상의 과정으로 바뀌는 마법이죠.
마무리하며: 이제 당신의 차례입니다
클라이언트와 프로페셔널한 관계를 맺는 것은 결코 차갑거나 딱딱하게 구는 것이 아닙니다. 오히려 프로젝트라는 배의 항해사로서, 최종 목적지까지 안전하게 항해하기 위해 모두가 따라야 할 항해 규칙을 명확히 세우고 꾸준히 소통하는 과정에 가깝습니다. 쉽게 클라이언트의 말을 들어주는 편한 PM은 당장은 좋을지 몰라도, 결국 프로젝트를 위험에 빠뜨릴 수 있습니다. 하지만 신뢰할 수 있는 파트너 PM은 때로는 불편한 진실을 마주하게 하더라도, 결국 프로젝트를 성공으로 이끌죠.
이 글을 읽고 고개를 끄덕이셨다면, 이제 직접 실천해 볼 차례입니다.
Action Items for Junior PMs:
변경 요청서 양식 만들기: 이번 주 내로 구글 설문지나 노션 페이지를 이용해 우리 팀만의 간단한 '변경 요청서' 템플릿을 만들어보세요. 그리고 다음 프로젝트 킥오프 미팅 때 클라이언트에게 이 프로세스를 직접 설명해 보세요.
동료와 실패 경험 공유하기: 동료 PM이나 커뮤니티에 "클라이언트와 관계 때문에 프로젝트가 힘들었던 경험"에 대해 이야기 나눠보세요. 서로의 실패담을 공유하는 것만으로도 엄청난 위로와 현실적인 노하우를 얻게 될 겁니다.
"검토 후 말씀드리겠습니다" 연습하기: 다음번에 클라이언트에게 예상치 못한 요청을 받으면, 즉시 답하지 말고 딱 한 번만 "좋은 의견 감사합니다. 검토 후 내일까지 말씀드리겠습니다."라고 말하는 연습을 해보세요. 그리고 하루동안 명확한 일정 영향도 분석을 가져오는 당신의 모습이 당신을 훨씬 더 현명한 전문가로 만들어 줄 겁니다.
목록으로