이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
비즈니스 요구사항을 시스템으로 구현하는 과정에서 가장 중요한 건 요구사항을 시스템이 이해할 수 있는 형태로 변환하는 것입니다. 현업이 원하는 것과 개발이 구현하는 것 사이의 간극은 요구사항이 모호하거나 예외 케이스가 정의되지 않았을 때 생깁니다. 수업에서 IS 프로젝트를 진행할 때, 사용자 스토리 형식으로 요구사항을 작성하고 각 기능에 테스트 기준을 함께 정의했던 것이 개발과 소통할 때 유용했습니다.
기능이 완성됐을 때 어떤 상태인지를 미리 정의해두면 구현 방향을 맞추기 쉽습니다. 요구사항 문서는 구현 중 변경 사항을 반영하며 관리하는 것이 중요합니다. 비즈니스 요구와 기술 구현 사이의 언어를 맞추는 역할이 기획자의 핵심입니다.
비즈니스 요구사항을 시스템으로 구현하는 과정에서 혼자 해결하지 못하고 도움이 필요했던 자리가 있습니다. 요구사항을 기능 명세로 바꾸는 작업에서, 어떤 예외 케이스까지 정의해야 하는지를 판단하는 것이 혼자 하기 어려운 자리였습니다. 현업 담당자가 실제로 어떤 케이스를 다루는지를 알지 못하면, 기능 명세에서 빠진 자리가 생기는 것을 방지하기 어렵습니다.
개발자에게 직접 물어보는 것도 중요한 도움이었습니다. 기획 입장에서 당연하게 생각한 것이 구현 입장에서는 전혀 다른 의미를 갖는 경우가 있어서, 초안을 쓰고 나서 개발자와 한 번 검토하는 과정이 오해를 줄였습니다. 도움을 받는 것이 일의 약점이 아니라, 요구사항 명세에서 빈틈을 줄이는 실질적인 방법입니다.
비즈니스와 기술 사이의 언어 차이를 줄이는 것은 대화를 통해서만 가능한 자리라는 것을 알고 있습니다.
비즈니스 요구사항 구현 경험에서 이후 절차로 만든 자리가 있습니다. 요구사항이 구현 중에 변경되는 것을 경험하고 나서, 다음 프로젝트에서는 요구사항 문서 버전 관리 방식을 먼저 정하는 것이 자연스러운 다음 단계였습니다. 변경 이유와 날짜를 기록하지 않으면 나중에 왜 이 기능이 이 방식으로 구현됐는지를 추적하기 어려워지는 자리가 생겼습니다.
구현 완료 후에도 요구사항 문서를 현재 시스템 상태로 업데이트하는 것이 다음 변경 시 기준이 됩니다. 한 번 구현하고 문서를 닫는 것과, 문서를 시스템과 함께 살아있는 자료로 관리하는 것이 다른 결과를 만듭니다. 유지보수 단계에서 구 버전 요구사항 문서와 현재 시스템이 달라 혼란이 생겼던 경험이 이 절차를 만든 이유입니다.
요구사항 문서는 구현 전에 필요한 것이 아니라 시스템이 살아있는 동안 함께 관리되어야 하는 것이라는 것을 알고 있습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.