이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
첫 요구사항 분석 업무를 맡았을 때 클라이언트가 말하는 것과 원하는 것이 다를 수 있다는 걸 빠르게 배웠습니다. "알림 기능 추가"를 그대로 구현했다가 원하는 건 실시간 알림이 아니라 일별 요약 이메일이었다는 걸 QA 단계에서 알게 된 경험이 있습니다. 이후 요구사항을 받으면 "어떤 시나리오에서, 누가, 어떤 결과를 기대하는가"를 유저 스토리 형식으로 정리하고 확인하는 단계를 넣었습니다. 모호한 요구사항은 와이어프레임 프로토타입을 먼저 만들어 검증하는 방식이 가장 빠른 오해 해소 방법이었습니다. 요구사항 문서에 완료 조건을 명시하면서 검수 기준도 명확해졌습니다.
요구사항 분석에서 처음부터 완벽한 요구사항이 나오는 경우는 드물다는 것을 경험으로 알게 됐습니다. 프로젝트 중반에 핵심 기능 스펙이 바뀌는 상황이 생겼는데, 변경이 얼마나 다른 기능에 영향을 미치는지 파악하는 것이 가장 먼저 할 일이었습니다. 이후부터는 요구사항을 받을 때 변경 가능성이 높은 부분과 확정된 부분을 구분해서 기록하는 방식을 쓰게 됐습니다.
변경 이력 문서를 만들어서 왜 바뀌었는지를 기록해두니, 같은 이유로 다시 논의가 나올 때 빠르게 맥락을 공유할 수 있었습니다. 요구사항은 시점에 따라 바뀌는 것이 자연스럽고, 변경을 관리하는 구조를 미리 갖추는 것이 더 중요하다는 것을 배웠습니다.
요구사항 분석에서 가장 자주 발생하는 문제는 '완성됐다'는 기준이 개발과 기획 사이에서 다른 경우였습니다. 개발 측에서는 기능이 동작한다고 보고했는데, 기획 측에서는 예외 케이스가 처리되지 않았다며 수정을 요청하는 상황이 반복됐습니다. 이후에는 요구사항 문서에 완료 조건(Acceptance Criteria)을 구체적인 시나리오 형태로 함께 작성하는 방식을 도입했습니다. '버튼을 클릭하면 모달이 열린다'가 아니라, '로그인 상태에서는 X가 노출되고, 비로그인 상태에서는 Y가 노출된다' 수준으로 작성하게 됐습니다.
완료 조건이 구체적일수록 개발과 기획 간 검수 기준이 같아지고, 재작업이 줄어든다는 것을 이 경험으로 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 품질보증 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.