요구사항 정의, 기업 솔루션 성패를 가르는 첫 질문

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

같은 솔루션을 도입했는데도 어떤 기업은 업무 시간이 줄고, 어떤 기업은 엑셀과 메신저를 다시 꺼냅니다. 차이는 기능 수보다 요구사항을 얼마나 구체적인 업무 언어로 정의했는지에서 생깁니다. GMDW가 기업 서비스 설계와 프로젝트 진단을 담당해 온 전문가 ‘프로세스 아키텍트 이준서’에게 실무자가 반드시 물어야 할 질문을 들었습니다.

요구사항 정의가 왜 솔루션 선택보다 먼저인가요?

Q. 필요한 기능부터 목록으로 만들면 충분하지 않습니까?

A. 기능 목록은 출발점일 뿐입니다. 예를 들어 ‘전자결재 기능 필요’라고만 쓰면 결재 단계, 대결 권한, 반려 후 재상신 방식, 모바일 승인 범위가 빠집니다. 공급사는 해당 기능이 있다고 답하지만, 도입 후 현업은 자신이 기대한 흐름과 다르다는 사실을 발견합니다.

요구사항은 기능의 이름이 아니라 누가, 어떤 상황에서, 무엇을 처리해, 어떤 결과를 얻어야 하는지를 표현해야 합니다. 서비스라는 개념 자체도 단순한 제품 제공보다 고객이 얻는 효용과 과정에 가깝습니다. 기본 개념은 네이버 지식백과의 서비스 정의를 참고하면 기업 전문 서비스가 기능 납품만으로 끝나지 않는 이유를 이해하는 데 도움이 됩니다.

따라서 솔루션 검토 전에 현재 업무의 시작점과 종료점, 담당자, 예외 상황을 먼저 기록해야 합니다. 이 작업을 생략하면 시연 화면은 화려해도 실제 운영에서는 수작업이 남고, 추가 개발비가 예상보다 커질 가능성이 높습니다.

• 기능 요구: 시스템이 수행해야 하는 동작
• 업무 요구: 조직이 해결하려는 문제와 기대 성과
• 운영 요구: 권한, 장애 대응, 교육, 변경 관리 방식
• 제약 조건: 예산, 일정, 보안 정책, 기존 시스템 연동 범위

“좋은 요구사항은 원하는 화면을 설명하는 문서가 아니라, 도입 후 달라져야 할 업무 장면을 합의하는 문서입니다.”

현업의 불만을 어떻게 검증 가능한 문장으로 바꾸나요?

Q. ‘업무가 너무 불편하다’는 의견도 요구사항이 될 수 있나요?

A. 그대로는 어렵지만 중요한 단서가 됩니다. 인터뷰에서 불편하다는 말을 들었다면 어느 업무가, 얼마나 자주, 몇 분씩 지연되는지 되물어야 합니다. ‘고객 정보를 찾기 어렵다’는 불만은 ‘상담원이 고객 번호를 입력하면 3초 이내에 최근 상담 이력과 계약 상태를 확인한다’는 검증 가능한 문장으로 바꿀 수 있습니다.

이때 담당자의 해결책을 곧바로 요구사항으로 채택하지 않는 것이 중요합니다. 현업이 “대시보드를 만들어 달라”고 말해도 실제 문제는 데이터 갱신 지연일 수 있습니다. 왜 필요한지 세 번 정도 질문하면서 표면적인 요청 아래의 원인을 찾아야 불필요한 개발을 줄일 수 있습니다.

Q. 인터뷰에서는 어떤 순서로 물어야 합니까?

A. 평상시 업무, 예외 상황, 손실 규모의 순서가 효율적입니다. 먼저 실제 처리 과정을 보여 달라고 요청하고, 오류나 긴급 요청이 들어왔을 때 무엇이 달라지는지 확인합니다. 마지막으로 재작업 시간, 고객 대기 시간, 누락 건수처럼 측정 가능한 영향을 질문합니다.

1. 최근 처리한 실제 사례 하나를 처음부터 재현하게 합니다.
2. 복사·붙여넣기, 이중 입력, 별도 메모가 발생하는 지점을 표시합니다.
3. 월별 처리량과 오류 빈도를 확인해 문제의 크기를 계산합니다.
4. 개선 후 기대 상태를 시간, 건수, 비율 중 하나로 표현합니다.
5. 인터뷰 내용을 당사자에게 다시 보여 주고 사실 여부를 확인합니다.

예컨대 월 2,000건의 주문 중 15%를 두 시스템에 중복 입력하고 건당 4분이 든다면 월 20시간이 소요됩니다. 이런 수치가 있어야 기업 컨설팅 과정에서 자동화 우선순위를 정하고, 솔루션 도입 효과도 나중에 검증할 수 있습니다.

부서마다 다른 요청은 누가 어떤 기준으로 결정하나요?

Q. 영업과 재무의 요구가 충돌하면 어떻게 합의합니까?

A. 직급이나 목소리 크기가 아니라 공통 평가 기준으로 판단해야 합니다. 영업은 입력 단계를 줄이고 싶어 하고 재무는 증빙과 승인 절차를 늘리고 싶어 할 수 있습니다. 양쪽 요청을 그대로 합치면 사용하기 어렵고 복잡한 시스템이 만들어지므로, 고객 영향과 법적·재무적 위험, 사용 빈도, 구현 비용을 함께 비교해야 합니다.

의사결정 구조도 문서에 남겨야 합니다. 실무 담당자는 사실과 사용 시나리오를 제공하고, 프로세스 책임자는 부서 간 기준을 조정하며, 최종 책임자는 예산과 위험을 고려해 범위를 승인합니다. 외부 컨설팅 업체는 결정을 대신하기보다 선택지별 영향과 근거를 명확하게 제시하는 역할을 맡는 편이 바람직합니다.

Q. 우선순위 표는 어떻게 구성하나요?

A. 아래처럼 네 단계로 나누되 모든 요청을 ‘필수’로 표시하지 못하도록 제한합니다. 필수 항목에는 법적 의무, 핵심 거래 중단 방지, 개인정보 보호처럼 제외할 수 없는 이유가 붙어야 합니다. 이유를 쓰지 못한다면 높은 우선순위가 아니라 선호 기능일 가능성이 큽니다.

• 사용 빈도와 영향을 각각 1~5점으로 평가합니다.
• 보안이나 법적 위험은 별도 가중치를 적용합니다.
• 개발 난도는 공급사의 추정 근거와 함께 검토합니다.
• 최종 제외 항목도 이유를 기록해 반복 논쟁을 막습니다.

맞춤형 솔루션 범위는 어디까지 구체화해야 하나요?

Q. 화면 설계까지 끝낸 뒤 업체를 만나야 합니까?

A. 모든 화면을 미리 확정할 필요는 없습니다. 지나치게 상세한 화면 설계는 전문 솔루션 기업이 제안할 수 있는 더 나은 방식을 막기도 합니다. 대신 핵심 사용자, 업무 시나리오, 반드시 보존할 통제 기준, 필요한 데이터, 성공 조건은 업체 상담 전에 준비해야 합니다.

특히 ‘기존 시스템과 연동’이라는 한 줄은 위험합니다. 어떤 데이터를 어느 방향으로 보내는지, 실시간인지 배치 방식인지, 실패했을 때 재처리 주체는 누구인지까지 정의해야 합니다. 고객 코드처럼 두 시스템에 공통으로 존재하는 값은 어느 쪽을 원본으로 인정할지도 결정해야 합니다.

Q. 제안의 여지를 남기면서도 견적 차이를 줄이는 방법은요?

A. 요구사항마다 목적과 수용 기준을 쓰고 구현 방식은 제안 항목으로 남기면 됩니다. 예를 들어 ‘모바일 앱 개발’이라고 지정하기보다 ‘외근 직원이 별도 PC 없이 견적을 승인하며, 승인 결과가 1분 안에 영업 시스템에 반영되어야 한다’고 씁니다. 공급사는 반응형 웹, 기존 협업 도구 연동, 전용 앱 가운데 비용 효율적인 방식을 제안할 수 있습니다.

• 범위에 포함: 사용자 역할, 핵심 시나리오, 데이터 항목, 연동 대상, 성능 조건
• 제안 요청: 기술 구조, 화면 구성, 구축 방법론, 단계별 일정
• 별도 견적: 데이터 정제, 추가 교육, 야간 작업, 외부 API 사용료
• 명시적 제외: 향후 검토 기능과 타 부서 확장 범위

산업 변화에 대응하는 교육과 융합 역량이 함께 논의돼 왔다는 사례는 4차 산업혁명 대비 융합전공 관련 기사에서도 확인할 수 있습니다. 기업 솔루션 역시 기술만 설치해서는 변화가 정착되지 않으며, 사용자 역량과 업무 방식 전환을 범위에 포함해야 합니다.

견적서에서 추가 비용이 생기는 지점은 무엇인가요?

Q. 같은 요구사항인데 업체별 금액 차이가 큰 이유는 무엇입니까?

A. 보이지 않는 전제 조건이 다르기 때문입니다. 한 업체는 표준 기능 설정만 계산하고, 다른 업체는 데이터 이전과 사용자 교육, 안정화 지원까지 포함할 수 있습니다. 총액만 비교하면 저렴한 제안처럼 보였던 계약에 추가 작업이 붙어 오히려 비용이 커질 수 있습니다.

일반적인 중소·중견기업 프로젝트에서도 단순 진단 워크숍은 수백만 원대부터 시작할 수 있지만, 여러 부서의 프로세스 재설계와 데이터 통합, 맞춤 개발이 포함되면 수천만 원 이상으로 확대됩니다. 이는 확정 가격표가 아니라 범위에 따른 예시입니다. 사용자 수, 연동 개수, 보안 심사, 데이터 상태에 따라 차이가 크므로 단가보다 산출 근거와 포함 범위를 확인해야 합니다.

Q. 비용 항목을 어떤 단위로 나눠 봐야 하나요?

A. 구축비와 운영비를 분리하고, 일회성 비용과 반복 비용을 다시 나눕니다. 초기 금액이 낮아도 사용자당 구독료, 저장 공간, 외부 API 호출료, 기술 지원 등급이 매년 누적되면 3년 총비용이 달라집니다. 계약 종료 시 데이터 추출 비용도 놓치기 쉬운 항목입니다.

• 사전 단계: 현황 진단, 요구사항 워크숍, 프로토타입 비용
• 구축 단계: 설정, 맞춤 개발, 연동, 테스트, 데이터 이전 비용
• 전환 단계: 교육, 매뉴얼, 병행 운영, 현장 지원 비용
• 운영 단계: 라이선스, 유지보수, 모니터링, 장애 대응 비용
• 종료 단계: 데이터 반환, 문서 인계, 계정 폐기 비용

“견적 비교표에 ‘포함 여부를 알 수 없음’ 열을 추가해 보세요. 추가 비용은 대개 비싼 항목보다 설명되지 않은 항목에서 발생합니다.”

제안 발표와 PoC에서는 무엇을 직접 확인해야 하나요?

Q. 업체가 준비한 시연만 봐도 판단할 수 있습니까?

A. 준비된 시연은 제품의 장점을 파악하는 데 유용하지만 우리 회사의 예외 업무까지 검증하지는 못합니다. 실제 사용자들이 자주 겪는 복잡한 사례 두세 개를 익명화해 제공하고, 해당 흐름을 솔루션에서 어떻게 처리하는지 보여 달라고 요청해야 합니다. 정상적인 한 건보다 반려, 취소, 담당자 변경, 연동 실패 상황에서 제품과 업체의 역량 차이가 잘 드러납니다.

PoC, 즉 개념검증의 목적도 완성품을 미리 만드는 것이 아닙니다. 기술적 불확실성과 운영 위험이 큰 가설을 짧게 시험하는 과정입니다. 기간은 범위에 따라 다르지만 보통 핵심 시나리오와 평가 기준을 제한해야 판단 가능한 결과를 얻을 수 있습니다. 이것저것 모두 체험하면 담당자의 인상만 남고 객관적인 비교가 어려워집니다.

Q. 시연 점수는 누가 매겨야 하나요?

A. 관리자만 참석시키지 말고 실제 입력 담당자, 승인자, 운영 관리자, 보안 또는 IT 담당자가 각자의 관점에서 평가해야 합니다. 같은 기능도 입력 담당자는 클릭 수를, 관리자는 추적 가능성을, IT 담당자는 장애 복구와 연동 구조를 중요하게 보기 때문입니다.

1. 업체에 동일한 시나리오와 제한 시간을 제공합니다.
2. 평가자는 사용성, 적합성, 통제, 확장성 항목을 따로 채점합니다.
3. ‘가능하다’는 답변에는 표준 기능인지 추가 개발인지 표시합니다.
4. 오류 발생 시 복구 절차와 로그 확인 방법을 직접 요청합니다.
5. 평가 종료 후 점수보다 의견 차이가 큰 항목부터 토론합니다.

예를 들어 고객 등급 변경 이력을 보여 달라는 요청에 현재 값만 조회된다면 기능 유무보다 감사 추적 요구가 충족되지 않은 것입니다. 이런 차이를 발견하려면 평가표에 ‘보였다’가 아니라 누가 어떤 조건에서 어떤 기록을 확인했는지를 적어야 합니다.

요구사항은 계약 뒤에도 바꿀 수 있나요?

Q. 프로젝트 중 현업 요청이 달라지면 실패로 봐야 합니까?

A. 변경 자체는 실패가 아닙니다. 인터뷰만으로 몰랐던 예외 업무가 프로토타입에서 발견되거나, 법규와 조직 구조가 달라질 수 있습니다. 문제는 변경을 금지하는 것이 아니라 비용과 일정, 품질에 미치는 영향을 확인하지 않은 채 구두로 추가하는 데 있습니다.

가장 실용적인 방법은 변경 요청서를 짧고 자주 운영하는 것입니다. 요청자는 변경 이유와 기대 효과를 쓰고, 수행 업체는 추가 공수와 일정 영향, 대안을 제시합니다. 업무 책임자와 프로젝트 책임자가 이를 승인하거나 다음 단계로 미루면 범위가 조용히 팽창하는 현상을 막을 수 있습니다.

Q. “작은 수정인데 그냥 해주면 안 되나요?”라는 요청은 어떻게 처리하나요?

A. 화면 문구 하나는 작아 보여도 다국어 파일, 사용자 매뉴얼, 테스트 시나리오와 연결될 수 있습니다. 반대로 큰 요청처럼 들려도 설정 변경만으로 해결되는 경우가 있습니다. 따라서 요청자의 표현이 아니라 영향 분석 결과로 판단해야 합니다. 30분 이내 처리 가능한 경미한 변경을 월별 허용량에 포함하는 등 계약 단계에서 운영 규칙을 정하면 관계도 훨씬 부드러워집니다.

• 변경 이유와 영향을 받는 사용자 집단을 기록합니다.
• 기존 요구사항을 대체하는지 추가하는지 구분합니다.
• 비용, 일정, 보안, 테스트 범위의 변화를 함께 산정합니다.
• 즉시 반영, 다음 배포, 향후 과제 중 하나로 결정합니다.
• 승인된 변경은 요구사항 문서와 교육 자료에도 동시에 반영합니다.

긴급 요청이라면 먼저 임시 운영 절차로 위험을 낮춘 뒤 정식 변경 여부를 판단할 수도 있습니다. 모든 요청을 즉시 개발하는 것보다, 왜 필요한지와 사용 기간을 확인하는 편이 기업의 솔루션 투자 효율을 높입니다. 결국 계약 후 변경이 가능한가보다 중요한 질문은 누가 근거를 확인하고 어떤 기준으로 승인하는가입니다.