이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
요구사항 분석 실습에서 처음에 설문지 방식으로 데이터를 모았는데 응답이 너무 추상적이어서 설계에 반영하기 어려웠습니다. 반정형 인터뷰로 방식을 바꿨더니 현업이 실제로 막히는 지점을 구체적으로 얘기해 줬습니다. 이 경험으로 요구사항 도출에서 질문의 구조가 얼마나 중요한지 알게 됐습니다. 그 뒤로는 '현재 어떻게 하고 있나요', '어디서 가장 오래 걸리나요' 같은 현황 중심 질문을 먼저 던집니다. 인터뷰 내용은 업무 흐름 다이어그램으로 정리해 이해 관계자에게 확인을 받고 나서야 기능 명세로 옮깁니다. 한 번은 다이어그램 검토 중 고객이 미처 말하지 않은 예외 케이스 2개를 직접 발견한 적도 있었습니다. 지금도 요구사항 분석은 현황 인터뷰부터 시작합니다.
요구사항 분석에서 초기에 파악한 내용이 틀릴 수 있다는 걸 경험했습니다. 업무 흐름 다이어그램을 그려서 고객에게 확인을 받았는데, 합의한 줄 알았던 항목 중 하나가 실제 운영 시 다르게 적용돼야 한다는 피드백이 구현 단계에서 들어왔습니다. 초기 인터뷰에서 확인하지 못한 예외 케이스가 있었던 것이었고, 실제 데이터로 테스트하기 전까지 드러나지 않았던 요구였습니다. 이후 다이어그램 검토 시 '이 흐름에서 예외적으로 달라지는 경우가 있는지'를 별도로 확인하는 절차를 추가했습니다. 요구사항 분석에서 확인된 것보다 확인하지 않은 것이 더 위험하다는 걸 그때 이해했습니다.
요구사항 분석에서 고객이 명시하지 않는 요구사항이 구현 이후 문제가 되는 경우가 있다는 걸 배웠습니다. SAP 관련 실습에서 기능 요구사항은 잘 정리됐는데 성능 조건이 명세에 없었습니다. 테스트 데이터로 확인할 때는 문제없었는데, 실제 운영 데이터 규모로 실행하니 처리 시간이 허용 범위를 넘는 상황이 생겼습니다. 기능이 맞더라도 얼마나 빠르게, 얼마나 많이, 어떤 조건에서 작동해야 하는지를 초기에 확인하지 않으면 나중에 큰 재작업이 생기는 걸 이해했습니다.
비기능 조건을 기능 요구사항과 함께 먼저 파악하는 것이 설계 리스크를 줄이는 방법이라는 것도 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SPC그룹 테크니컬 PM 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.