이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
다양한 직군과 소통할 때 가장 먼저 하는 것은 상대방의 언어로 맞추는 것입니다. 기획자에게 기술 용어를 그대로 쓰거나, 개발자에게 비즈니스 목표만 전달하면 각자 자기 맥락에서만 이해하는 상황이 생겨 협업 효율이 떨어졌습니다.
기술 설명이 필요할 때는 왜 이 선택을 했는지를 비기술적 언어로 먼저 전달했습니다. 내부 구현 방식보다 그 결과로 어떤 사용자 경험이 달라지는지를 중심으로 설명하면 비개발 직군도 판단에 참여할 수 있었습니다.
의견 충돌이 생길 때는 공통 관심사를 먼저 확인하는 방식을 사용했습니다. 각자의 요구가 달라 보여도 결국 같은 사용자 문제를 해결하려는 방향인 경우가 많았고, 그 공통 목표를 기준으로 대화하면 합의 속도가 빨라졌습니다. 이 접근이 팀 내 마찰을 줄이는 데 실질적으로 도움이 됐습니다.
기획자와 함께 일할 때 "이 API를 바꿔야 한다"는 말이 기획자에게 어떤 의미인지 모를 때가 있었습니다. 반대로 기획자의 요구가 개발에서 어떤 비용인지 감이 없는 경우도 있었습니다.
이 간격을 줄이기 위해 기술 내용을 설명할 때 "무엇이 바뀌는가"보다 "화면에서 무엇이 달라지는가"로 바꿔 표현했습니다. 프로토타입을 빠르게 만들어 보여주는 방식이 말보다 훨씬 빠르게 이해를 만들었습니다. 공통 언어는 말이 아니라 "같이 보는 것"에서 나왔습니다.
이 경험으로 직군 간 소통의 핵심은 설명을 잘 하는 것보다 상대가 가진 언어로 접근하는 것이라고 생각합니다. 화면이 공통 언어가 될 수 있다는 걸 배웠습니다.
직군 간 소통 방식을 바꿨을 때 효과를 확인하는 기준이 없으면 나아진 건지 알기 어렵다고 느꼈습니다. 말이 줄어들거나 회의가 짧아지는 것이 실제로 이해가 빨라진 것인지 그냥 끝낸 것인지가 다르기 때문입니다.
제가 쓴 방법은 기획자가 개발 공수를 추정할 때 틀린 경우를 기록하는 것이었습니다. 추정 오차가 줄어드는 게 소통이 개선된 증거라고 봤습니다. 아직 측정을 체계적으로 하진 못하고 있지만, 의식적으로 기록하는 습관은 이어가고 있습니다.
이 경험으로 소통 개선은 느낌이 아니라 협업 결과가 달라지는 것으로 확인해야 한다는 걸 배웠습니다. 오차가 줄어드는 것이 소통이 나아진 가장 분명한 신호였습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 여기어때 경영기획 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.