이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 시절 고객센터 시스템 개선 요구사항을 정리하는 작업을 맡았는데, CS팀에서 요청한 내용이 '처리 속도를 빠르게 해달라'는 수준이었습니다. 막연한 요청을 구체화하기 위해 CS팀원 3명과 직접 인터뷰를 진행해 어떤 유형의 문의가 가장 오래 걸리고, 어느 단계에서 병목이 생기는지를 파악했습니다. 인터뷰 결과를 As-Is 플로우차트로 그리고 나니, 답변 분류 단계에서 동일한 정보를 세 군데에 입력하는 중복 작업이 있다는 점이 드러났습니다. 이 중복을 제거하는 것만으로 처리 시간이 20% 줄어들 수 있다는 추정치를 뽑아 기획서에 담았고, 개발팀 검토에서 실현 가능성이 높다는 평가를 받았습니다. 복잡한 요구사항 구조화는 '무엇을 원한다'보다 '왜 불편한가'를 먼저 찾는 것에서 출발한다고 생각합니다.
복잡한 요구사항을 구조화할 때 제가 한 건 '무엇을 원한다'를 '왜 불편한가'로 바꾼 것입니다. CS팀이 '처리 속도를 빠르게'라고 했는데, 그건 해결책이지 진짜 문제가 아니었습니다. 그래서 어떤 문의가 가장 오래 걸리고, 어느 단계에서 병목인지를 인터뷰로 파고들었습니다. As-Is 플로우차트로 그리니, 답변 분류 단계에서 같은 정보를 세 군데 입력하는 중복이 드러났습니다. 막연한 요청을, 현황을 그려 구체적인 문제로 분해한 게 핵심이었습니다.
요청을 그대로 받으면 엉뚱한 걸 만들었고, 왜 불편한지를 찾으면 진짜 손댈 자리가 보였습니다. 구조화는 문제를 다시 정의하는 일이었습니다.
요구사항을 구조화하며 제가 의식한 건 어디까지 파고들지 정하는 것입니다. 모든 요청을 다 인터뷰하고 플로우로 그리면 정교하지만, 시간이 너무 들어 실행이 늦어졌습니다. 한 번은 완벽히 구조화하려다, 정작 개선 착수가 밀린 적이 있습니다. 그래서 영향이 큰 요청부터 깊이 파고, 나머지는 가볍게 다뤘습니다. 또 구조화 결과가 너무 복잡하면, 개발팀도 이해하기 어려웠습니다. 그래서 핵심 흐름은 또렷이, 드문 예외는 간단히 정리했습니다.
다 담으려다 아무도 안 읽는 문서가 되는 게 위험했습니다. 어디까지 정교하게 할지 선을 정하는 게, 구조화의 트레이드오프였습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.