게임 조직에서 개발자와 디자이너(아트/UX/UI)는 같은 목표를 향해 움직이지만, 사용하는 언어와 중요하게 보는 기준이 다릅니다. 개발은 안정성과 구조, 일정과 리스크를 먼저 보고, 디자인은 경험과 맥락, 일관성과 퀄리티를 먼저 봅니다. 개발자는 논리적인 사고와 코드의 언어를 쓰고, 디자이너는 감성과 시각의 언어를 씁니다. 이 사이에서 PM이 해야 할 일은 “말을 예쁘게 하는 것”이 아니라, 서로 다른 기준을 같은 목표와 같은 일정 위에 올려놓고 실행되게 만드는 협업의 기술입니다. 2026년 라이브 서비스 환경을 기준으로, 실무에서 바로 적용 가능한 커뮤니케이션 스킬과 노하우를 정리합니다.
서로 다른 언어를 ‘같은 목표’로 번역하는 스킬
우리같은 PM의 커뮤니케이션이 어려운 이유는, 양쪽 모두 “틀린 말”을 하는 게 아니라 같은 이슈를 서로 “다른 시각”에서 보고 있기 때문입니다. 개발자는 기능을 구현할 때 기술적 오류, 성능, 데이터 구조, 예외 케이스, QA 범위를 먼저 떠올립니다. 반대로 디자이너는 화면 흐름, 시선 유도, 브랜드 톤, 유저 감정, 사용성 같은 체감 품질을 먼저 떠올립니다. PM이 중간에서 “둘 다 중요하니 알아서 적당히 타협하세요”라고 하면 대부분 실패합니다. 대신 PM은 두 기준을 ‘프로젝트 목표’로 번역해야 합니다. 예를 들어 이벤트 UI를 바꾸는 과제라면, 목표를 “전환율 1.5%p 상승, 튜토리얼 완료율 5%p 개선”처럼 정의하고, 개발에게는 “필수 이벤트 로그/성능 리스크 최소화”, 디자인에게는 “클릭 포인트 명확화/동선 단축”처럼 같은 목표를 각자의 언어로 풀어주는 방식입니다. 제 경험상 이 부분의 조율이 굉장히 중요한 이유가 서로 다른 시각의 사람들을 같은 목표로 바라보게 해야 진행이 된다는 점입니다.
만약 같은 목표로 바라보게 하는 것이 되지 않는다면 서로 간의 오해와 불신, 책임 회피 등의 이유로 더 나은 성공을 향한 프로젝트 방향으로 가기 힘들다는 점입니다. 이 과정을 성공적으로 가져가서 같은 목표로 바라보게 된다면 논쟁의 초점이 바뀝니다. “이 디자인이 예쁘냐”가 아니라 “이 디자인이 전환율을 올릴 수 있냐”로 이동하고, “이 구조가 깔끔하냐”가 아니라 “이 구조가 일정 안에 안전하게 배포되냐”로 이동합니다. PM은 회의 시작 전에 목표, 범위, 비범위(하지 않을 것), 일정의 제약을 먼저 깔아야 합니다. 그리고 개발과 디자인이 각각 원하는 선택지를 2~3개로 정리해, 장단점과 리스크를 표로 보여주면 의사결정이 빨라집니다. 결론적으로 PM의 첫 번째 스킬은 ‘언어의 통역’이 아니라 ‘기준의 정렬’입니다.
형용사 대신 레퍼런스로 하는 디자이너와의 소통
디자이너에게 "화려하면서도 심플하게 해주세요"라는 말은 "따뜻한 아이스 아메리카노 주세요"와 같습니다. 디자인은 주관적이기 때문에 말로 설명할수록 결과물은 산으로 갑니다. 따라서 레퍼런스 이미지를 활용하여 백 마디 말보다 한 장의 그림이 강력합니다. 핀터레스트(Pinterest)나 경쟁사 게임 스크린샷을 보여주며 "이 버튼의 질감이나 빛 효과를 참고해 주세요"라고 말하는 것이 가장 빠릅니다. 또한 영역을 존중해야 합니다. "여기를 빨간색으로 바꿔주세요"라고 구체적으로 지시하는 것은 자칫 디자이너의 전문성을 무시하는 것처럼 보일 수 있습니다. "이 배너는 '경고'의 의미가 강조되어야 하는데, 눈에 더 잘 띄게 할 방법이 있을까요?"라고 목적을 말하고 해결책은 전문가에게 맡기는 화법이 좋습니다.
제가 주니어 PM 시절일 때 UI 디자인을 PPT로 대략적으로 그리고 UX도 곁들여 설명하여 회의를 참석해서 요구를 한 적이 있었습니다. 지금 생각해보면 굉장히 디자이너를 무시하는 행동이었죠. 이러한 예는 잘못된 예로서 디자이너를 믿고 맡겨야하는 것이 원활한 프로젝트 진행을 위해서도 좋습니다.
실무 노하우: 요구사항 정리법, 결정 프레임, 그리고 ‘마찰 비용’ 줄이기
PM이 협업을 잘한다는 것은 결국 팀의 마찰 비용을 줄인다는 뜻입니다. 마찰 비용을 줄이는 가장 현실적인 방법은 요구사항을 “모호하지 않게” 만드는 것입니다. 예를 들어 ‘상점 개선’이라는 과제가 들어오면, PM은 이를 기능 단위로 쪼개야 합니다. 상품 리스트 정렬 기준, 추천 영역 노출 규칙, 가격 표기 방식, 할인/한정 배지, 결제 완료 후 안내, 구매 복구, 예외 케이스(네트워크 끊김/스토어 오류)까지 최소 요구사항을 명확히 하면 개발은 구조를 잡기 쉽고, 디자인은 화면을 일관되게 설계할 수 있습니다. 특히 게임은 플랫폼(안드로이드/iOS/PC)별 UI 제약이 다르므로, PM이 사전에 제약을 정리해주면 후반 리워크가 크게 줄어듭니다.
또한 PM은 결정 프레임을 갖고 있어야 합니다. 선택지가 갈릴 때 “누가 더 강하게 주장하느냐”로 결정되면 팀이 지칩니다. 추천 프레임은 간단합니다. 1) 유저 임팩트(체감), 2) KPI 임팩트(성과), 3) 개발 비용(기간/난이도), 4) 리스크(버그/성능/운영), 5) 재사용성(다른 기능에도 쓰이는가) 다섯 항목으로 점수를 매겨보는 것입니다. 점수화가 완벽하진 않지만, 논쟁이 감정이 아니라 구조로 이동합니다. 그리고 일정이 촉박할수록 PM은 필수와 선택을 명확히 나누고, 디자인에도 ‘필수 화면’과 ‘후속 개선’을 분리해서 제안해야 합니다. 이때 중요한 것은 약속입니다. 선택 항목을 뒤로 미뤘다면, 다음 스프린트에서 다시 검토하겠다는 트래킹(백로그)을 남겨야 신뢰가 유지됩니다. 제 경험상 절대로 절대로 하지 말아야 할 것은 선택지가 갈려 누가 맞느냐 누가 틀리느냐, 또는 누구의 말이 더 논리적이고 말싸움에 강하느냐 형식으로 가서는 안 됩니다. 이러한 예는 프로젝트를 진행하다보면 가장 흔하게 발생할 수 있는 상황이기 때문에 앞서 말한것처럼 명확한 기준을 가지고 접근하는 것이 좋다는 걸 명심해야 합니다.
마지막으로, “빠른 프로토타입으로 말 줄이기”입니다. 개발과 디자인의 커뮤니케이션 비용은 말이 길어질수록 늘어납니다. Figma 프로토타입, 간단한 와이어, 흐름도 하나가 회의 30분을 줄여줍니다. PM이 직접 만들지 못해도, 디자이너와 함께 ‘사용자 시나리오’를 화면 5장으로 정리하는 것만으로도 구현 오류가 크게 줄어듭니다. 또 개발 측에는 API/데이터 요구사항을 한 페이지로 정리해주면, 중간에 “이 데이터가 없는데요?” 같은 사고가 줄어듭니다. 협업은 결국 ‘예상치 못한 수정’의 횟수를 줄이는 게임이고, PM의 노하우는 그 수정의 원인을 사전에 제거하는 데 있습니다. 이는 전에도 언급을 한 적이 있듯이 타 직군과의 회의가 있다면 그 회의의 안건을 미리 생각하고 어떤 주제로 말들이 오고갈지 미리 시뮬레이션을 하고 트레이닝 하는 연습을 하면 도움이 더 됩니다.
결론
개발자와 디자이너 사이에서 PM이 해야 할 커뮤니케이션은 중재가 아니라 정렬입니다. 목표와 성공 기준을 합의하고, 문서와 회의 구조를 표준화하며, 취향과 본인의 성격이 아닌 명확한 기준으로 피드백하고, 요구사항을 모호하지 않게 쪼개면 협업의 마찰이 눈에 띄게 줄어듭니다. 좋아하는 게임의 UI 개선 과제를 하나 정해 목적과 KPI, 요구사항, 화면 흐름, 리스크를 한 장으로 정리해보세요. 그 한 장이 PM 커뮤니케이션 역량을 가장 설득력 있게 보여주는 포트폴리오가 됩니다