SI 프로젝트 착수 전, 담당자 인터뷰로 숨은 요구사항 찾는 질문법

“기능 목록은 적어 놨는데, 이 정도면 개발을 시작해도 될지 모르겠습니다.”

“담당자마다 설명이 달라서 누구 말을 기준으로 삼아야 할지 막막합니다.”

“개발이 시작된 뒤에야 꼭 필요한 예외 업무가 나올까 봐 걱정됩니다.”

숨은 요구사항을 찾는 핵심은 기능을 더 많이 받는 일이 아니라, 실제 업무 한 건의 시작부터 완료까지를 따라가며 예외와 판단 주체를 확인하는 일입니다. 인터뷰 결과를 업무 흐름, 권한, 예외, 검수 기준으로 바꿔야 개발과 검수의 공통 기준이 생깁니다.

저는 개발자로 시작해 제품 기획, 개발 총괄, PM과 법인 운영을 함께 맡으며 50건 이상의 SI 수탁개발을 수행했습니다. 착수 전 인터뷰에서는 “어떤 화면이 필요한가”보다 “이 업무가 지금 어떤 순서와 기준으로 처리되는가”를 먼저 확인합니다. 화면 구성은 바뀔 수 있지만, 누가 어떤 정보를 보고 판단하며 어디까지 책임지는지는 시스템 구조와 검수 조건에 계속 남기 때문입니다.

왜 기능 질문보다 업무 한 건의 흐름을 먼저 물어야 할까요?

인터뷰는 원하는 기능 목록이 아니라 실제 업무 한 건의 시작, 처리, 완료 흐름에서 시작해야 합니다. 그래야 입력값, 전달 과정, 승인 기준처럼 담당자가 당연하게 넘긴 조건을 요구사항으로 꺼낼 수 있습니다.

“신청 관리 기능이 필요하다”는 말만으로는 구현 범위를 판단하기 어렵습니다. 신청이 들어온 뒤 누가 처음 확인하는지, 누락 정보는 어떻게 보완하는지, 담당자가 바뀌면 누가 이어받는지, 완료는 무엇으로 판단하는지가 빠져 있기 때문입니다.

국내 네트워크시스템 구축 직무 소개에서도 프로젝트 초기 분석 단계에 고객의 요구사항과 업무 특성을 살피고 담당자와 인터뷰하거나 협업하는 방식을 언급합니다. 다만 이 자료는 네트워크시스템 구축 직무를 다룬 내용이므로, 모든 SI 프로젝트의 표준 절차로 넓혀 해석하기보다는 인터뷰 설계의 참고 사례로 보는 편이 적절합니다.

인터뷰에서는 추상적인 질문보다 최근 처리한 업무를 기준으로 순서를 묻는 편이 좋습니다.

1. 이 업무는 어떤 계기로 시작됩니까?
2. 최초 입력자는 누구이며, 어떤 자료를 확인합니까?
3. 다음 담당자에게 무엇을 어떤 방식으로 넘깁니까?
4. 정상 처리와 완료는 각각 무엇으로 확인합니까?
5. 중간에 멈추거나 되돌아가는 경우는 언제입니까?

이 질문을 따르면 “등록 화면”이나 “승인 화면”처럼 기능으로만 보이던 요구를 업무 규칙으로 바꿀 수 있습니다. 이후 개발팀은 화면 수보다 데이터가 생성되는 시점, 상태가 바뀌는 조건, 권한 범위를 먼저 검토할 수 있습니다.

숨은 요구사항은 어떤 질문에서 드러날까요?

숨은 요구사항은 정상 처리보다 예외 상황, 사람의 판단, 부서 간 인계 지점에서 드러납니다. 따라서 담당자가 어떤 기준으로 직접 결정하는지 묻는 질문이 필요합니다.

반복 업무를 하는 담당자는 자신이 따로 확인하는 파일이나 구두로 보완하는 절차를 시스템 요구사항으로 인식하지 못할 수 있습니다. “어려운 경우가 있습니까?”라고 넓게 묻기보다, 아래처럼 장면을 나눠 질문하면 답을 구현 조건으로 옮기기 쉬워집니다.

특히 “누가 최종 판단합니까?”와 “판단 근거를 나중에 다시 확인해야 합니까?”는 권한과 이력 설계로 연결됩니다. 구두 처리가 가능한 업무라도 시스템으로 옮길 때는 책임 범위와 기록 보관 여부를 정해야 합니다.

제가 업무 시스템을 설계할 때는 하나의 데이터 모델을 여러 화면에서 함께 쓰도록 구성하는 방식을 우선 검토합니다. 같은 고객 정보나 업무 상태가 화면마다 따로 관리되면, 인터뷰에서 합의한 기준도 운영 과정에서 달라질 수 있기 때문입니다. 다만 모든 판단을 시스템 규칙으로 고정할 필요는 없습니다. 명확한 규칙으로 처리할 영역과 담당자 검토를 남길 영역을 먼저 나누는 것이 중요합니다.

인터뷰 대상자의 답이 다르면 무엇을 기준으로 정해야 할까요?

답변이 다를 때는 다수결로 기능을 정하기보다, 실제 처리자와 업무 책임자의 역할을 구분하고 결정이 필요한 쟁점을 따로 기록해야 합니다.

현업 담당자는 처리 순서와 반복 작업을 잘 알고, 업무 책임자는 승인 기준과 우선순위를 정할 수 있습니다. 시스템 운영자는 계정, 권한, 데이터 관리 조건을 확인하고, 의사결정자는 구축 목적과 단계별 범위를 판단합니다. 한 사람의 인터뷰만으로 이 관점을 모두 대신하기는 어렵습니다.

예를 들어 처리자는 “승인은 한 단계면 된다”고 말하고 책임자는 “금액에 따라 이중 승인이 필요하다”고 말할 수 있습니다. 이때 필요한 것은 어느 한쪽의 의견을 즉시 채택하는 일이 아니라, 금액 기준, 승인자, 예외 권한을 결정 항목으로 분리하는 일입니다.

대규모 시스템 구축 사례를 다룬 보도에서는 고객 요구사항의 분석과 설계 결과를 다음 개발 단계로 넘기고, 사용자가 결과를 검토하고 승인하는 역할 구분을 소개합니다. 다만 이 사례만으로 이해관계자 간 충돌을 해결하는 일반 절차나 최종 결정권자 기록 방식까지 확인할 수는 없습니다.

실무에서는 인터뷰 문서에 확정 사항과 미결 사항을 섞지 않는 편이 좋습니다. 미결 사항에는 결정 담당자, 결정에 필요한 정보, 결정 시점을 함께 남기면 개발 중에 새 요구가 나왔을 때도 기존 합의와 구분하기 쉬워집니다.

인터뷰 내용을 개발 가능한 요구사항으로 바꾸려면 무엇을 남겨야 할까요?

인터뷰 직후에는 회의록만 남기지 말고 업무 흐름, 데이터, 권한, 예외, 검수 기준으로 다시 정리해야 합니다. 그래야 개발팀과 발주사가 같은 대상을 확인할 수 있습니다.

인터뷰 기록을 그대로 전달하면 발언은 남아도 구현 판단은 남지 않습니다. 다음 형식으로 재정리하면 누락을 점검하기 좋습니다.

• 업무 목적: 이 기능이 해결하려는 업무상 문제는 무엇인가
• 시작 조건: 어떤 입력이나 상태에서 업무가 시작되는가
• 처리 규칙: 자동 처리와 담당자 판단은 각각 어디까지인가
• 데이터 항목: 입력, 조회, 수정, 보관이 필요한 정보는 무엇인가
• 권한: 조회, 등록, 수정, 승인, 삭제를 할 수 있는 사람은 누구인가
• 예외 처리: 누락, 반려, 취소, 담당자 변경 시 어떻게 처리하는가
• 완료 기준: 어떤 상태와 결과를 확인하면 업무가 끝났다고 보는가
• 검수 방법: 누가 어떤 시나리오로 확인하는가

검수 기준은 개발 막바지에 덧붙이는 문서가 아닙니다. 인터뷰 중 “이 기능이 제대로 됐다고 어떻게 알 수 있습니까?”라고 물으면 모호한 요구를 확인 가능한 조건으로 바꿀 수 있습니다. 예를 들어 “편하게 관리할 수 있어야 한다”는 표현보다 “담당자는 자신에게 배정된 건만 조회하고 상태를 변경할 수 있다”는 조건이 검수에 적합합니다.

프로젝트 범위가 크다면 모든 내용을 한 번에 확정하기보다 첫 릴리스에서 검증할 업무 흐름을 먼저 정할 수 있습니다. 다만 핵심 업무가 불명확한 상태에서 개발을 서두르자는 뜻은 아닙니다. 첫 릴리스에 포함한 흐름의 시작, 예외, 완료 기준만큼은 인터뷰를 통해 확인해야 합니다.

최근 요구사항 분석 도구 활용 동향

최근 대규모 시스템 구축 사례에서는 고객 요구사항 문서를 분석하고, 설계, 코딩, 테스트 역할을 나눠 수행한 뒤 사용자가 결과를 검토하고 승인하는 접근이 소개되고 있습니다. 이는 인터뷰를 대신한다는 뜻이 아니라, 인터뷰로 확인한 기준을 이후 단계에서도 검토 가능한 형태로 남겨야 한다는 점을 보여줍니다.

해당 사례는 특정 기업의 플랫폼 소개를 바탕으로 한 보도이므로 모든 프로젝트에 같은 방식이 맞는다고 볼 수는 없습니다. 발주사 입장에서는 도구 도입 여부보다 먼저, 무엇을 자동 처리하고 어떤 판단을 사람이 승인할지 정리하는 일이 우선입니다.

결론

착수 전 담당자 인터뷰의 목표는 요구사항을 많이 모으는 일이 아니라, 실제 업무가 성립하는 조건을 확인 가능한 기준으로 바꾸는 일입니다.

기능 목록을 받은 뒤 바로 견적과 화면 논의로 들어가면, 담당자가 매일 처리하던 예외와 판단 기준이 뒤늦게 나타날 수 있습니다. 먼저 업무 한 건을 따라가고, 예외 상황을 묻고, 역할별 답변의 충돌을 결정 항목으로 남기세요.

인터뷰가 끝난 뒤에는 다음 세 가지만 확인하면 됩니다.

1. 시작부터 완료까지의 업무 흐름을 한 장으로 설명할 수 있는가
2. 누락, 반려, 변경, 담당자 부재 상황의 처리 기준이 있는가
3. 각 요구사항에 결정 담당자와 검수 방법이 연결되어 있는가

이 세 질문에 답할 수 있다면, 요구사항 문서는 기능 희망 목록이 아니라 개발과 검수를 위한 공동 기준이 됩니다.

자주 묻는 질문

인터뷰는 담당자 한 명과만 해도 되나요?

핵심 업무를 실제로 처리하는 담당자 한 명의 인터뷰는 출발점이 될 수 있지만, 승인과 운영 기준까지 확정하려면 책임자나 결정권자의 확인이 필요합니다. 업무 흐름과 우선순위를 한 역할의 설명만으로 단정하지 않는 편이 좋습니다.

요구사항 인터뷰 전에 화면 시안을 준비해야 하나요?

초기에는 화면 시안보다 업무 흐름과 확인할 질문을 준비하는 편이 우선입니다. 시안은 논의를 구체화하는 데 도움이 되지만, 업무 규칙이 정리되지 않았다면 화면 모양에만 대화가 쏠릴 수 있습니다.

현업 담당자가 모든 예외를 기억하지 못하면 어떻게 하나요?

최근 처리한 업무를 한 건씩 떠올리도록 질문하고, 인터뷰 뒤에 정리한 흐름을 다시 확인받는 방식이 현실적입니다. 처음부터 모든 예외를 찾으려 하기보다, 누락을 발견했을 때 요구사항 문서에 반영하는 절차를 정해 두는 편이 좋습니다.

인터뷰 결과가 계속 바뀌면 개발을 시작하면 안 되나요?

변경 자체보다 무엇이 확정됐고 무엇이 미결인지 구분되지 않는 상태가 문제입니다. 첫 단계에서 구현할 업무 흐름과 검수 기준이 합의됐다면 진행할 수 있지만, 미결 항목이 그 흐름을 바꾼다면 먼저 결정해야 합니다.

제 도움이 필요하시다면

크로플은 웹, 앱, 업무 시스템 수탁개발과 프로젝트 관리를 수행하며, 구축 전 업무 흐름과 요구사항을 구현 단위로 정리하는 일을 함께합니다.

다음 상황이라면 인터뷰와 요구사항 정리가 도움이 될 수 있습니다.

• 여러 부서의 요청이 섞여 첫 개발 범위를 정하기 어려운 경우
• 엑셀, 메신저, 기존 시스템에 흩어진 업무를 하나의 흐름으로 정리해야 하는 경우
• 기능 요구는 많지만 권한, 예외 처리, 검수 기준이 아직 불분명한 경우

관리형 연락 카드로 현재 업무 흐름과 고민을 알려주시면, 먼저 확인할 인터뷰 대상과 결정이 필요한 항목부터 살펴보겠습니다.