이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
시스템 개발 요건을 도출하는 과정은 IT 수업과 실습을 통해 접했습니다. 현장 담당자가 실제로 어떤 불편을 겪는지를 먼저 파악하는 것이 요건 도출의 시작이라고 배웠습니다. 인터뷰만으로는 '현재 어떻게 하는가'만 나오고 '무엇이 근본 문제인가'는 별도 분석이 필요합니다. 발주 시스템이라면 발주 요청 → 승인 → 발행 → 납기 추적 흐름을 먼저 그려보고, 각 단계에서 수동 작업이 많은 구간과 오류가 자주 발생하는 지점을 파악하는 것이 우선입니다.
요건은 기능 목록이 아니라 해결할 문제라는 관점에서 정리해야 개발팀과 소통이 잘 됩니다. 아직 실무 경험은 없지만, 현업-IT 사이에서 요건을 연결하는 역할이 중요하다는 것을 이해하고 있습니다.
요건 도출에서 제가 가장 먼저 하려는 것은 지금 일이 실제로 어떻게 흘러가는지를 눈에 보이게 그리는 것입니다. IT 실습에서 한 업무 흐름을 정리할 때, 담당자 말만 듣고 정리했더니 정작 예외 처리 단계가 통째로 빠진 적이 있었습니다. 그래서 발주처럼 단계가 많은 업무는 데이터가 어디서 나와 어떻게 계산되고 누가 예외를 처리하는지를 단계별 그림으로 먼저 그리는 것이 중요하다고 배웠습니다. 이렇게 현재 흐름을 산출물로 만들어 두면 현업과 같은 그림을 보며 '여기가 빠졌다'를 짚을 수 있습니다. 요건은 말로만 주고받으면 사람마다 다르게 이해하기 때문에, 눈에 보이는 형태로 남기는 것이 재작업을 줄이는 출발점이라고 생각합니다.
요건을 도출할 때 제가 가장 조심해야 한다고 배운 것은 현업이 원하는 것과 실제로 필요한 것이 다를 수 있다는 점입니다. 담당자가 '이런 기능을 넣어 달라'고 말한 것을 그대로 사양으로 만들면, 정작 근본 문제는 안 풀리고 시스템만 복잡해지는 경우가 있다고 들었습니다. 그래서 요청을 받으면 그 기능이 어떤 불편을 풀려는 것인지를 한 단계 더 물어, 진짜 문제를 확인하려 합니다. 모든 요청을 다 정밀하게 반영하면 개발이 무거워지고 일정이 늘어나기 때문에, 개발 복잡도와 실제 효과를 견줘 우선순위를 정하는 판단이 필요하다고 봅니다. 핵심 발주 규칙은 반드시 현업 검수로 확정하되, 원하는 것을 그대로가 아니라 필요한 것으로 번역하는 일이 요건 도출의 핵심이라고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 배달의민족(우아한형제들) SCM·공급망 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.