이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
수업 프로젝트에서 기술팀 역할과 기획팀 역할을 나눠서 협업할 때, 서로 다른 언어를 쓰는 것이 갈등의 주요 원인이라는 것을 경험했습니다. 기획팀은 '이 기능이 필요하다'고 말하고, 기술팀은 '구현이 어렵다'고 말하는 상황에서, 저는 두 팀 사이에서 '왜 이 기능이 필요한지'를 먼저 공유하는 역할을 했습니다. 목적이 공유되면 기술팀이 다른 구현 방법을 제안하거나 제약 조건을 설명하는 방향으로 대화가 바뀌었습니다.
기능 명세보다 사용자 문제를 먼저 기술하는 방식이 기술팀과의 소통을 부드럽게 만들었습니다. 갈등은 입장 차이가 아니라 목적 공유 부족에서 온다는 것을 그 경험에서 배웠습니다.
외부 조직과의 협업에서 제가 겪은 갈등은 서로 급하다고 여기는 일이 달랐던 것입니다. 프로젝트에서 우리 팀은 한 기능을 빨리 원했는데, 함께 일하던 기술 쪽은 다른 일정이 먼저라 우선순위가 부딪혔습니다. 저는 무작정 우리 것을 먼저 해달라고 밀기보다, 양쪽의 일정과 그 일이 각각 무엇에 묶여 있는지를 펼쳐놓고 함께 봤습니다. 그러자 우리 기능 중 일부는 늦어도 되고, 정말 급한 것은 작은 부분이라는 것이 드러났습니다. 그 작은 부분만 먼저 처리하기로 절충하니 양쪽 다 받아들였습니다. 갈등은 누가 옳은가의 문제가 아니라, 서로 무엇에 쫓기는지를 모를 때 커진다는 것을 배웠습니다. 그래서 저는 우선순위가 부딪히면 각자의 사정을 먼저 펼쳐 보입니다.
외부 조직과 일할 때 제가 의식하는 것은 그들도 그들 나름의 책임과 우려가 있다는 점입니다. 한 협업에서 기술 쪽이 우리 요청에 자꾸 난색을 보여 답답했는데, 알고 보니 그 변경이 그들이 관리하는 다른 시스템에 위험을 줄 수 있다는 우려 때문이었습니다. 우리 입장만 보면 비협조로 보였지만, 그들 입장에서는 정당한 걱정이었습니다. 그래서 저는 요청을 밀어붙이기 전에 상대가 무엇을 지켜야 하는지를 먼저 묻고, 그 우려를 덜 방법을 함께 찾는 쪽으로 바꿨습니다. 위험을 줄이는 조건을 붙이니 그들도 협조했습니다. 외부 협업의 갈등은 상대의 사정을 못 보고 우리 요구만 들이밀 때 생긴다는 것을 배웠습니다. 그래서 저는 늘 상대의 입장을 먼저 그려보려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.