기술 컨설팅은 요구사항 정의서가 프로젝트 성패를 가른다

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

같은 설비 문제를 두고도 생산팀은 가동률을, 품질팀은 불량률을, 경영진은 투자 회수기간을 먼저 봅니다. 이 차이를 정리하지 않은 채 기술 컨설팅을 발주하면 제안서는 화려해도 실제 현장에서는 쓸 수 없는 결과가 나오기 쉽습니다.

좋은 엔지니어링 솔루션은 제품 선정이 아니라 요구사항의 우선순위를 합의하는 데서 시작합니다. 아래 점검 항목은 컨설팅 업체에 연락하기 전부터 제안서 검토, 계약, 착수까지 단계별로 활용할 수 있습니다.

발주 전에는 문제와 원하는 결과를 분리해야 합니다

장비 이름보다 현장의 손실을 먼저 적습니다

“센서를 추가하고 싶다”거나 “자동화 시스템이 필요하다”는 문장은 구매 품목일 뿐 요구사항이 아닙니다. 먼저 어느 공정에서 어떤 손실이 얼마나 자주 발생하는지 적어야 기술 컨설턴트가 계측, 제어, 소프트웨어 개선 가운데 적절한 해법을 검토할 수 있습니다. 기술의 일반적인 개념과 적용 범위가 모호하다면 지식백과의 기술 정의를 참고해 내부 용어부터 통일하는 것도 좋습니다.

예를 들어 “포장라인을 자동화한다”보다 “교대당 평균 35분 발생하는 라벨 위치 조정 시간을 10분 이하로 줄인다”가 훨씬 유용합니다. 전자는 공급사가 자신 있는 장비를 제안하게 만들지만, 후자는 현재 공정의 병목과 개선 효과를 검증하게 만듭니다. 현재값, 목표값, 측정 방법, 달성 기한이 함께 있어야 요구사항으로 기능합니다.

현장 인터뷰에서는 해결책을 곧바로 묻지 말고 작업자가 반복해서 우회하는 절차를 확인하세요. 수기로 다시 입력하는 데이터, 알람이 울려도 확인하지 않는 화면, 특정 숙련자만 조정할 수 있는 설정값이 숨어 있는 요구사항을 드러냅니다.

• 문제 위치: 공정명, 설비 번호, 작업 단계까지 특정합니다.
• 발생 조건: 품종 변경, 온도 상승, 교대 전환 등 재현 조건을 기록합니다.
• 손실 규모: 정지 시간, 폐기량, 재작업 인원, 납기 지연을 수치화합니다.
• 목표 기준: 개선 후 합격으로 판단할 값을 정합니다.
• 제외 범위: 이번 투자에서 변경할 수 없는 설비와 업무를 밝힙니다.

현장에서 가장 비싼 요구사항은 어려운 기능이 아니라, 프로젝트 중간에 뒤늦게 발견된 필수 기능입니다.

제안 요청서에는 기능보다 운영 조건을 구체화해야 합니다

정상 상황과 예외 상황을 함께 질문합니다

제안 요청서에는 필요한 화면과 기능뿐 아니라 실제 운전 환경을 담아야 합니다. 하루 생산시간, 품종 전환 횟수, 분진과 진동, 세척 방식, 네트워크 단절 가능성, 작업자의 숙련도는 솔루션 구조와 견적을 크게 바꿉니다. 같은 데이터 수집 시스템이라도 사무실 서버에서만 운영하는 경우와 24시간 멈출 수 없는 생산라인에 적용하는 경우에는 이중화와 복구 설계가 달라집니다.

특히 “자동 저장”, “실시간 감시”, “기존 시스템 연동”처럼 해석 범위가 넓은 표현은 수치로 바꿔야 합니다. 실시간이 100밀리초인지 10초인지, 데이터 보관이 3개월인지 5년인지, 연동 대상이 파일 전송인지 양방향 제어인지에 따라 필요한 기술과 비용이 달라집니다. 구매 담당자만 작성하지 말고 생산, 품질, 설비보전, 정보보안 담당자가 함께 검토해야 누락을 줄일 수 있습니다.

외부 실증이나 해외 공장 확장까지 염두에 둔다면 현지 통신 환경, 인증, 언어, 원격 지원 방식도 초기 요구사항에 넣으세요. 국내 기술의 해외 실증 사례를 다룬 K-디지털 글로벌 실증사업 관련 보도처럼 기술 구현과 현장 검증은 서로 다른 단계입니다. 국내에서 작동했다는 사실만으로 다른 운영 환경에서도 같은 성능이 보장되지는 않습니다.

1. 운영 시간: 계획 정지 가능 시간과 허용 가능한 최대 장애시간을 기재합니다.
2. 사용자 조건: 사용자 수, 권한 단계, 교육 가능 시간, 외국어 지원 여부를 확인합니다.
3. 데이터 조건: 수집 주기, 보관 기간, 예상 용량, 백업 및 삭제 기준을 적습니다.
4. 연동 조건: PLC, MES, ERP, 센서의 제조사와 통신 규격을 목록화합니다.
5. 환경 조건: 온습도, 방진·방수, 전원 품질, 설치 공간, 안전구역을 점검합니다.
6. 예외 처리: 통신 단절, 센서 고장, 잘못된 입력, 수동 운전 시 동작을 요구합니다.

견적서는 총액이 아니라 가정과 검수 기준으로 비교해야 합니다

싼 견적에 빠진 항목부터 찾습니다

기술 컨설팅 견적은 공급사마다 포함 범위가 달라 총액만 비교하면 판단이 왜곡됩니다. 한 업체는 현장조사와 시운전, 교육을 포함하고 다른 업체는 기본 설계만 제시할 수 있습니다. 하드웨어 가격이 낮아 보여도 별도 라이선스, 통신 모듈, 제어반 개조, 야간 작업, 출장비가 추가되면 최종 비용은 역전됩니다.

견적 비교표에는 금액 옆에 산출물, 투입 인력, 작업 횟수, 고객 제공 조건, 변경 비용을 나란히 적으세요. 예산은 보통 사전 진단과 기본 설계, 상세 설계와 제작, 설치와 시운전, 교육과 안정화 지원으로 구분하면 관리하기 쉽습니다. 정확한 가격은 설비 규모와 정지 제약에 따라 달라지므로 현장을 보지 않고 제시한 일괄 금액은 참고값으로만 다루는 편이 안전합니다.

검수 기준은 계약 전에 합의해야 합니다. “정상 작동” 같은 표현 대신 8시간 연속 운전, 데이터 누락률, 알람 전달 시간, 목표 생산속도, 불량 검출률처럼 시험 가능한 기준을 사용합니다. 성능이 나오지 않을 때 재시험 횟수와 보완 책임, 검수 지연 중 비용 부담까지 명시하면 분쟁을 줄일 수 있습니다.

• 제안 금액에 부가세, 운송, 설치 부자재, 안전관리 비용이 포함됐는지 확인합니다.
• 고객이 제공해야 하는 전원, 네트워크, 작업 인력과 생산 샘플을 계산합니다.
• 요구사항 변경 시 시간당 단가 또는 변경 견적 절차를 계약서에 넣습니다.
• 소스코드, 설계도, 계정, 데이터의 소유권과 인도 형식을 확인합니다.
• 최종 대금은 문서 제출이 아니라 합의된 성능시험 통과와 연결합니다.

제안서의 장점보다 ‘이 견적이 성립하는 가정’을 먼저 읽으면 숨은 추가비용과 일정 위험이 더 빨리 보입니다.

계약 후 변경과 현장 예외는 별도 통제선이 필요합니다

착수회의에서 결정권과 변경 절차를 고정합니다

계약이 끝났다고 요구사항이 고정되는 것은 아닙니다. 실제 배선을 확인하면서 도면과 다른 부분이 발견되거나 운영자가 새로운 화면을 요청할 수 있습니다. 모든 요청을 즉시 반영하면 일정과 예산이 무너지므로, 요청 접수부터 영향 분석, 승인, 반영, 재검수까지 하나의 변경 절차로 관리해야 합니다.

착수회의에서는 고객과 공급사 양쪽의 의사결정자를 한 명씩 지정하세요. 현장 작업자의 의견은 중요하지만, 구두 요청만으로 설계를 바꾸면 품질팀과 보안팀의 기준을 놓칠 수 있습니다. 변경 요청서에는 요청 이유, 기대 효과, 추가 비용, 일정 영향, 기존 기능에 미치는 위험을 기록하고 승인된 버전의 요구사항 문서를 기준선으로 보관합니다.

다만 이 점검표가 모든 프로젝트를 포괄하지는 않습니다. 방폭 구역, 의료·식품 공정, 기능안전 대상 설비, 국가핵심기술이나 개인정보를 다루는 시스템은 별도의 법규와 인증 검토가 필요합니다. 긴급 고장 복구처럼 요구사항 문서를 충분히 작성할 시간이 없는 상황에서는 우선 안전한 임시조치를 시행한 뒤 원인 분석과 영구 개선 범위를 분리해야 합니다.

1. 착수 직후: 최신 도면, 프로그램 백업본, 설비 이력과 담당자 연락망을 인계합니다.
2. 설계 승인 전: 화면, 제어 로직, 데이터 항목과 장애 대응 시나리오를 검토합니다.
3. 제작 중: 주요 부품의 단종 가능성, 납기, 대체품 승인 절차를 확인합니다.
4. 현장 투입 전: 작업허가, 잠금표찰, 백업 및 원복 계획을 승인합니다.
5. 시운전 중: 정상 조건뿐 아니라 정전, 통신 장애, 센서 이상을 시험합니다.
6. 인수 전: 수정 도면, 설정값, 계정, 교육 기록, 예비품 목록을 실제 파일로 받습니다.

• 규제 대상 여부가 불분명하면 설계 확정 전에 인증기관이나 분야별 전문가에게 확인합니다.
• 기존 설비의 프로그램을 확보할 수 없다면 개조보다 독립형 보완 설비가 안전할 수 있습니다.
• 생산 중단 비용이 설치비보다 크다면 단계별 전환이나 병렬 운전 기간을 별도 설계합니다.
• 신기술 실증은 즉시 전면 적용하지 말고 제한된 공정에서 성공 기준과 중단 기준을 함께 설정합니다.