요구사항이 많을수록 엔지니어링 프로젝트는 더 쉽게 실패한다

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

발주서가 두껍고 기능 목록이 길면 프로젝트가 안전해 보입니다. 그러나 현장에서는 요구사항을 많이 적어 둔 프로젝트가 오히려 일정 지연, 추가 비용, 사용자 외면이라는 세 가지 문제를 동시에 겪곤 합니다.

원인은 요구사항의 개수가 아니라 왜 필요한지, 누가 사용할지, 어떤 조건에서 성공으로 판단할지가 빠져 있기 때문입니다. 기술의 일반적인 개념과 범위는 지식백과의 기술 정의에서도 살펴볼 수 있지만, 실제 엔지니어링 성과는 기술 자체보다 문제를 구체적으로 규정하는 과정에서 갈립니다.

기능을 빠짐없이 적었는데 현장에서는 아무도 쓰지 않았다

사용자 대신 기능 목록을 주인공으로 만든 실패

한 제조사는 설비 이상 알림, 모바일 대시보드, 자동 보고서, 원격 제어를 모두 포함한 운영 솔루션을 구축했습니다. 시연에서는 기능이 매끄럽게 작동했지만 가동 후 한 달이 지나도 작업자 이용률은 낮았습니다. 조사해 보니 현장 담당자는 장갑을 낀 상태로 작은 모바일 버튼을 누르기 어려웠고, 알림이 너무 자주 발생해 중요한 경고까지 무시하고 있었습니다.

이 사례에서 개발 기능은 계약서와 일치했습니다. 문제는 기능 요구사항은 있었지만 사용 맥락이 없었다는 점입니다. 작업자의 이동 동선, 교대 시간, 소음, 통신 음영 구간, 승인 권한을 확인하지 않은 채 화면과 기능부터 설계하면 기술적으로 성공하고 운영에서는 실패하는 역설이 생깁니다.

• 하지 말아야 할 일: 부서장 인터뷰만으로 최종 사용자 요구를 대신하는 방식
• 확인할 질문: 사용자는 언제, 어디서, 어떤 장비로 이 기능을 실행합니까?
• 관찰할 항목: 장갑 착용, 화면 확인 시간, 네트워크 상태, 기존 수기 기록의 이유
• 성공 기준: 기능 완료율이 아니라 경보 확인 시간, 입력 누락률, 재작업 감소율로 설정

특히 AI나 자동 판정 기능은 데이터만 연결하면 된다고 생각하기 쉽습니다. 하지만 소리로 가축의 질병 징후를 판단하는 토종 AI 사례처럼 실제 신호와 현장 문제를 구체적으로 연결해야 활용 가치가 생깁니다. 무엇을 감지할 수 있는가보다 감지 결과로 누가 어떤 행동을 할지가 먼저입니다.

현장 팁: 요구사항 회의 전에 작업자 한 명의 업무를 30분만 따라가 보십시오. 문서 열 장보다 한 번의 관찰에서 더 중요한 제약 조건이 발견될 수 있습니다.

모든 요청을 받아준 친절한 컨설팅이 예산을 무너뜨렸다

우선순위 없는 요구사항은 약속이 아니라 부채가 됩니다

프로젝트 초기에 영업, 생산, 품질, 안전, IT 부서의 요청을 모두 수용하면 합의가 잘된 것처럼 보입니다. 하지만 각 요청에는 화면 개발뿐 아니라 데이터 수집, 권한 설정, 테스트, 교육, 유지보수 비용이 따라옵니다. 작은 항목 열 개가 추가되었는데 전체 일정이 그대로라면 누군가는 품질 검증 시간을 줄이게 됩니다.

대표적인 실패는 ‘있으면 좋은 기능’을 필수 범위에 넣는 것입니다. 다국어 화면, 세분화된 통계, 개인별 알림, 외부 시스템 자동 연동은 각각 유용하지만 핵심 문제와 무관하다면 초기 구축을 방해합니다. 기술 컨설팅의 역할은 모든 요청에 동의하는 것이 아니라 가치와 비용을 보이게 만드는 것입니다.

요청을 네 가지 칸으로 나누는 방법

1. 각 요구사항 옆에 요청자 이름과 실제 사용자를 따로 적습니다.
2. 요구사항이 해결할 손실을 시간, 금액 또는 위험도로 표현합니다.
3. 구축비뿐 아니라 연간 유지비와 데이터 관리 부담을 함께 계산합니다.
4. 이번 단계에서 제외할 항목도 공식 문서에 남겨 반복 논의를 막습니다.

비용 검토에서는 금액을 하나로 단정하지 마십시오. 사용자 수, 연동 대상, 데이터 정제 수준, 보안 검증 범위에 따라 견적이 크게 달라집니다. 따라서 ‘총예산 얼마’보다 핵심 기능 비용, 연동 비용, 검증 비용, 운영 전환 비용을 분리해야 비교와 조정이 쉬워집니다.

완벽한 요구사항 문서를 기다리다 변화 대응에 실패했다

서명받은 문서를 현실보다 더 믿은 실수

요구사항을 한 번 확정하면 바꾸지 않아야 일정이 지켜진다는 믿음도 위험합니다. 생산 품목이 달라지거나 설비 제어 방식이 변경되고, 데이터 품질이 예상보다 낮게 나타나면 최초 문서의 전제부터 무너질 수 있습니다. 그런데 변경을 실패로 간주하는 조직에서는 현장에 맞지 않는 기능을 그대로 완성하는 데 시간과 비용을 씁니다.

반대로 요청이 들어올 때마다 무조건 반영하는 것도 해답은 아닙니다. 변경은 허용하되 근거와 영향을 기록해야 합니다. 좋은 요구사항 관리는 고정이 아니라 통제된 학습 과정이며, 변경 전후의 성과 지표와 추가되는 테스트 범위를 함께 확인해야 합니다.

• 나쁜 변경: 임원의 구두 지시만으로 화면과 데이터 구조를 즉시 수정
• 검증 가능한 변경: 사용자 불편 사례, 발생 빈도, 개선 효과를 근거로 요청
• 숨은 영향: 기존 연동 규격, 접근 권한, 교육 자료, 장애 대응 절차의 수정
• 보류 기준: 효과가 불명확하거나 핵심 일정에 직접적인 위험을 주는 요청

해외 실증이나 새로운 산업 환경에서는 이런 학습 구조가 더욱 중요합니다. K-디지털 글로벌 실증사업 성과 사례가 보여 주듯 기술은 실제 환경에서 검증될 때 경쟁력을 증명합니다. 사내 회의실에서 만든 가정만으로 요구사항을 고정하지 말고, 작은 범위의 실증 결과를 다음 설계에 반영해야 합니다.

변경 요청서에는 다섯 줄이면 충분합니다

1. 현재 어떤 사용 장면에서 문제가 발생하는지 적습니다.
2. 발생 빈도와 손실 규모를 숫자로 기록합니다.
3. 변경 후 기대하는 행동과 측정 지표를 정합니다.
4. 일정, 비용, 보안, 연동에 미치는 영향을 표시합니다.
5. 승인자와 검증 책임자, 반영 시점을 지정합니다.

이 절차가 번거롭다고 느껴질 수 있습니다. 그러나 기록 없이 수정한 기능은 나중에 왜 만들었는지 설명하기 어렵고, 장애가 발생했을 때 되돌릴 기준도 사라집니다. 짧은 변경 기록은 개발자를 통제하기 위한 문서가 아니라 조직의 판단을 보존하는 장치입니다.

전문가 조언: 변경 횟수를 줄이는 것보다 근거 없는 변경의 비율을 줄이십시오. 필요한 수정까지 막으면 솔루션은 납품 시점부터 낡기 시작합니다.

내일 회의에서 요구사항 한 줄을 삭제해 보십시오

추가가 아니라 삭제 실험으로 프로젝트를 진단합니다

요구사항 품질을 높이기 위해 거창한 시스템부터 도입할 필요는 없습니다. 현재 문서에서 가장 모호한 문장 하나를 골라 보십시오. ‘사용하기 쉽게 구성한다’, ‘실시간으로 제공한다’, ‘다양한 통계를 지원한다’처럼 사람마다 다르게 해석할 수 있는 표현이 좋은 대상입니다.

그 문장을 바로 구체화하기 전에 일단 삭제했을 때 누가 곤란해지는지 질문하십시오. 아무도 구체적인 손실을 설명하지 못한다면 우선순위가 낮거나 목적 없는 요구일 가능성이 큽니다. 반대로 생산 중단, 품질 판정 지연, 안전 위험 같은 상황이 나온다면 해당 요구는 유지하되 측정 가능한 조건으로 다시 써야 합니다.

• ‘실시간 알림’은 이상 감지 후 10초 이내 담당자 단말에 전달처럼 씁니다.
• ‘편리한 화면’은 주요 작업을 세 번 이내의 조작으로 완료처럼 바꿉니다.
• ‘데이터 연동’은 대상 시스템, 전송 주기, 실패 시 재처리 방식을 명시합니다.
• ‘보안을 강화한다’는 사용자 권한, 기록 보존 기간, 승인 절차로 나눕니다.
• ‘자동화한다’는 자동 처리 범위와 사람이 개입해야 할 예외 조건을 적습니다.

그다음 요구사항 옆에 사용자, 사용 장면, 성공 수치, 검증 담당자 네 칸을 추가하십시오. 네 칸 중 두 개 이상이 비어 있다면 개발 착수보다 질문이 먼저입니다. SDEC와 같은 기술 컨설팅·엔지니어링 파트너를 활용할 때도 솔루션 제품명보다 이 네 가지를 먼저 공유하면 제안 범위와 비용의 정확도가 높아집니다.

30분 안에 실행하는 한 문장 재작성

1. 요구사항 문서에서 ‘쉽게, 빠르게, 효율적으로, 다양하게’가 들어간 문장 하나를 찾습니다.
2. 실제 사용자 한 명에게 그 기능이 필요한 순간을 물어봅니다.
3. 현재 걸리는 시간이나 오류 빈도를 확인합니다.
4. 목표 수치와 확인 방법을 넣어 문장을 다시 작성합니다.
5. 개발자와 현장 담당자가 같은 장면을 떠올리는지 서로 설명하게 합니다.

예를 들어 ‘설비 상태를 빠르게 확인할 수 있어야 한다’를 ‘보전 담당자가 태블릿에서 30초 안에 정지 설비의 오류 코드와 최근 10분 센서 추이를 확인한다’로 바꿔 보십시오. 지금 문서에서 모호한 요구사항 한 줄을 골라 이 문장으로 재작성하는 것, 그것이 실패 비용을 줄이기 위해 오늘 바로 할 수 있는 가장 작은 엔지니어링 행동입니다.