이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
프로젝트 초기에 요구사항을 수집할 때는 이해관계자 인터뷰를 통해 직접 무엇을 원하는지를 확인하는 것이 가장 기본입니다. 문서나 이메일보다 직접 대화에서 숨겨진 요구가 드러나는 경우가 많습니다. 인터뷰에서는 원하는 기능이 아니라 어떤 문제를 해결하고 싶은지를 먼저 묻는 것이 중요합니다. 기능을 구현해도 본래 문제가 해결되지 않는 경우를 피할 수 있습니다. 수집된 요구사항은 꼭 있어야 하는 것, 있으면 좋은 것, 나중에 고려할 것으로 구분해 관리합니다.
처음부터 모든 것을 담으려 하면 범위가 통제되지 않습니다. 요구사항은 프로젝트가 진행되면서 바뀌는 것이 정상이라서 변경 시 영향 범위를 확인하는 체계를 초반에 만드는 것이 중요합니다.
프로젝트 초기에 요구사항을 수집할 때 방법론을 아는 것보다 본인이 실제로 어떤 자리에서 어떻게 수집했는지를 말하는 것이 더 무게 있는 방식이 됩니다.
수업 팀 프로젝트에서 기획을 시작할 때 팀원들에게 '어떤 기능이 필요한가'를 먼저 물었다가 방향이 너무 다양해서 좁히기 어려운 자리가 생겼습니다. '이 서비스를 쓰지 않는 이유가 무엇인가'로 질문을 바꾸면서 해결해야 할 핵심 문제가 훨씬 더 빠르게 좁혀지는 방식이 됐습니다. 본인이 어떤 방식으로 수집했는지를 구체적으로 말하는 자리가 있어야 경험의 무게가 전달되는 방식이 됩니다.
요구사항 수집은 방법론보다 본인이 직접 어떤 질문으로 어떻게 수집했는지를 말하는 것이 더 무게 있는 방식이라고 생각합니다. 직접이 있어야 무게가 됩니다.
지금도 요구사항 수집은 무엇을 원하는지보다 왜 지금 문제가 생기는지를 먼저 파악하는 자리가 더 중요한 방식이라고 생각합니다. 원인이 있어야 방향이 됩니다.
프로젝트 초기에 요구사항을 수집한 경험을 말할 때 한 번 했다고 끝나는 것이 아니라 그 과정에서 어떤 체계를 만들어 다음에 쓸 수 있게 됐는지를 말하는 자리가 있어야 더 완결된 방식이 됩니다.
수업 팀 프로젝트에서 초기 요구사항 수집이 너무 산만했던 경험을 바탕으로, 이후 프로젝트에서는 '있어야 하는 것·있으면 좋은 것·나중에 고려할 것'을 먼저 나눠서 수집하는 방식을 체계로 만들었습니다. 이 체계가 있으면 수집 후 정리 시간이 줄어들고 팀 간 합의도 빠르게 이루어지는 방식이 됩니다. 경험을 체계로 남기는 자리가 있어야 경험이 다음에도 쓰이는 방식이 됩니다.
요구사항 수집은 한 번 잘 하는 것보다 그 과정에서 어떤 체계를 만들어 반복할 수 있게 됐는지를 말하는 자리가 있어야 더 완결된 방식이라고 생각합니다. 체계가 있어야 반복이 됩니다.
지금도 요구사항 수집은 방법을 아는 것보다 그 방법을 다음 프로젝트에서 어떻게 쓸지를 생각하는 자리가 더 가치 있는 방식이라고 생각합니다. 전이가 있어야 가치가 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 스마일게이트 기획 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.