이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
제품 요구사항을 작성할 때 가장 중요하게 생각하는 건 왜 이 기능이 필요한지를 먼저 적는 것입니다. 무엇을 만들어야 하는지만 적으면 개발 중에 방향이 흔들리는 경우가 생깁니다. 팀 프로젝트에서 요구사항을 기능 목록으로만 만들었다가, 개발 중에 어떤 게 더 중요한지 판단이 안 되는 상황이 반복됐습니다. 이후엔 이 기능이 어떤 사용자 문제를 해결하는지를 먼저 쓰는 방식으로 바꿨습니다. 이유가 명확하면 개발 중 결정이 필요할 때 기준이 생기고, 불필요한 범위 확장도 줄었습니다. 요구사항은 무엇보다 왜가 먼저라고 생각합니다.
이유가 명확한 요구사항이 개발 중 결정의 기준이 됩니다.
요구사항에서 중요하게 생각하는 또 다른 요소는 예외 케이스를 명시하는 것입니다. 정상 흐름만 적으면 개발자가 예외 상황을 만났을 때 어떻게 처리할지를 알 수 없습니다. 팀 프로젝트에서 로그인 요구사항을 작성했을 때, 잘못된 비밀번호를 여러 번 입력하면 어떻게 되는지를 빠뜨렸습니다. 개발자가 각자 다르게 구현했고, 나중에 동작이 일관되지 않아서 다시 맞추는 작업이 필요했습니다. 요구사항은 정상 시나리오뿐 아니라 예외까지 담아야 온전한 문서라는 걸 그때 배웠습니다.
예외까지 담아야 온전한 요구사항 문서라는 걸 그때 배웠습니다. 정상 시나리오만 있는 문서는 절반밖에 안 된 문서입니다.
좋은 요구사항 문서의 기준은 처음 보는 사람이 구현할 수 있을 만큼 명확한가라고 생각합니다. 모호한 표현이 들어가면 구현하는 사람마다 다르게 해석하는 경우가 생깁니다. 수업 프로젝트에서 화면에서 버튼을 눌렀을 때 처리한다고만 썼더니, 처리가 즉시인지 비동기인지 팀원들이 다르게 이해하고 있었습니다. 이후엔 동작 방식과 조건, 결과 상태를 구체적으로 적는 것을 원칙으로 삼았습니다. 요구사항 작성은 나중에 커뮤니케이션 비용을 줄이는 가장 앞선 투자라고 느꼈습니다. 요구사항을 잘 쓰는 것이 나중에 생기는 커뮤니케이션 비용을 줄이는 가장 앞선 투자입니다.
명확한 문서가 나중의 혼선을 막는 가장 효율적인 방법이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 휴젤 프로덕트 매니저 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.