이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
팀 프로젝트에서 기능 범위 결정을 놓고 개발팀과 조율하는 상황이 있었습니다. 기획 단계에서 잡은 기능 중 일부가 개발 기간 내 구현하기 어렵다는 이야기가 나왔습니다. 저는 각 기능의 사용자 가치와 구현 비용을 비교한 간단한 우선순위 표를 만들어서, 핵심 3개 기능만 먼저 개발하고 나머지는 다음 단계로 미루자고 제안했습니다.
팀원들이 근거가 있으니 설득이 됐고, 결국 기한 내 핵심 기능을 완성할 수 있었습니다. 협상에서 중요한 건 내가 원하는 것을 주장하기보다 상대도 납득할 수 있는 근거를 만드는 것이라는 걸 그때 배웠습니다. 데이터가 갈등을 협의로 바꿉니다.
제품 개발 과정에서 협상이 필요했던 상황에서, 제가 직접 담당했던 건 전체 협상을 이끄는 것보다 팀 내 우선순위 조율에서 의견을 중재하는 것이었습니다. 큰 협상보다 내가 실제로 영향을 줄 수 있는 범위를 파악하는 게 먼저였습니다. 학교 앱 개발 팀 프로젝트에서 디자이너와 개발자 사이에 기능 구현 우선순위를 두고 의견이 갈렸습니다. 디자이너는 UI 완성도를 우선하고 싶었고, 개발자는 기술 구현 가능 여부를 먼저 확인하고 싶어했습니다. 저는 양쪽 주장을 듣고 "MVP 범위에서 무엇을 먼저 내보내야 사용자 피드백을 받을 수 있는가"를 기준으로 정리해서 제안했습니다. 팀이 기준을 공유하니 논의가 빠르게 합의점으로 모였습니다. 아직 외부 파트너와 협상한 경험은 없습니다. 하지만 협상에서 내 손이 닿는 역할을 먼저 가르는 것이 효과적인 개입의 출발점이라는 감각은 생겼습니다.
제품 개발 과정에서 협상이 필요할 때, 제가 중요하게 생각하는 건 각자가 원하는 것과 포기할 수 있는 것을 먼저 파악하는 것입니다. 협상이 막히는 경우는 대부분 양쪽이 무엇을 지키고 싶은지 명확하지 않아서였습니다. 팀 프로젝트에서 UI 우선순위 논쟁이 생겼을 때, 각자의 입장만 반복하다가 시간이 많이 지나갔습니다. 제가 "어느 기능이 없으면 이번 발표가 의미 없는가"를 먼저 물었더니, 양쪽 모두 "핵심 플로우만 작동하면 된다"는 데 동의하는 부분이 있었습니다. 공통 기준이 생기자 어느 기능을 먼저 하고 어느 기능을 이번 버전에서 빼는지 빠르게 결정할 수 있었습니다. 아직 외부 관계자와의 협상 경험은 없습니다. 하지만 협상에서 각자가 지키려는 것을 먼저 꺼내면, 타협 가능한 범위가 보인다는 감각은 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 부산은행 공통직무·미지정 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.