이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
기술 검토와 설계를 진행할 때 협업 부서와 소통하는 기준은 각자의 언어로 같은 것을 얘기하고 있는지를 먼저 맞추는 것입니다. 개발팀과 기획팀은 같은 기능을 놓고도 다른 용어와 기준으로 이해하는 경우가 있어서, 공통 용어를 문서로 정리해두는 것이 오해를 줄입니다. 기술 제약을 공유하는 타이밍도 중요합니다.
기획이 완성된 후에 기술 제약을 발견하면 처음부터 다시 해야 하는 비용이 생깁니다. 설계 초기에 가능한 것과 어려운 것을 함께 논의하면서 현실적인 방향을 잡는 것이 효율적입니다. 합의 방식에서는 결정 사항을 문서로 남기고 관련 부서가 확인하는 구조가 나중에 재협의를 줄입니다. 협업 소통은 전달이 아니라 이해를 맞추는 것입니다.
조별 프로젝트에서 기획을 맡은 저와 개발을 맡은 팀원 사이에 일이 어긋난 적이 있습니다. 제가 기획을 거의 완성한 뒤에야 개발 쪽에서 '이 기능은 지금 구조로는 어렵다'고 해, 처음부터 다시 짜야 했습니다. 그때 배운 건, 기술 제약은 기획이 끝난 뒤가 아니라 설계 초기에 꺼내야 한다는 점이었습니다. 그래서 그 뒤로는 기획 초안 단계에서 개발 팀원을 불러, 무엇이 가능하고 무엇이 어려운지를 먼저 함께 짚었습니다. 제가 원하던 기능 일부는 양보했고, 대신 꼭 필요한 핵심 흐름은 지켰습니다. 상대가 무엇을 부담스러워하는지를 그리고 나니 절충이 빨랐습니다. 다만 제 한계도 인정합니다. 기술 용어를 충분히 몰라 제약을 다 이해하진 못했고, 그땐 공통 용어를 문서로 정리해 메웠습니다. 이후로는 설계 초기에 제약을 함께 논의하는 걸 제 협업 원칙으로 둡니다.
기술 검토와 설계에서 협업할 때 제가 중요하게 보는 건, 같은 말을 서로 다르게 이해하고 있지 않은지 먼저 맞추는 일입니다. 개발 쪽과 기획 쪽이 같은 기능을 두고도 다른 용어와 기준으로 받아들이는 경우를 겪었습니다. 그러면 다 합의한 줄 알았는데 결과물이 어긋납니다. 그래서 저는 핵심 용어와 기준을 문서로 정리해 두고, 결정 사항도 글로 남겨 관련 부서가 확인하게 하는 방식을 씁니다. 말로만 끝낸 합의는 나중에 재협의로 돌아왔기 때문입니다. 협업은 전달이 아니라 이해를 맞추는 일이라고 봅니다. 다만 제 한계도 인정합니다. 문서로 다 적기 어려운 미묘한 합의도 있고, 적어 두어도 안 읽히면 소용이 없었습니다. 그래서 핵심만 짧게 남기고 중요한 결정은 직접 확인을 받는 식으로 보완합니다. 협업 소통은 같은 그림을 보고 있는지를 계속 점검하는 일이라는 시각을 두려 합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.