담당자님이 통합제어 시스템 구축 비용 견적서를 세 군데 공급사로부터 받았습니다. 같은 회의실, 같은 도면, 같은 요구사항으로 요청했는데 총액 차이가 상당했습니다. 가장 싼 곳과 가장 비싼 곳의 항목 구성 자체가 달랐습니다. 어느 쪽이 빠진 건지, 어느 쪽이 과하게 잡은 건지 판단할 기준이 없었습니다.

저는 이런 상황을 여러 번 봤습니다. 그리고 매번 원인은 장비가 아니라 견적서를 받기 전 단계에 있었습니다. 요구사항을 어떻게 정리했는지, 계약 조건에 무엇을 명시했는지, 유지보수를 어떤 기준으로 산정했는지 — 이 세 가지가 견적서의 항목 구성 자체를 바꿔놓습니다. 스펙표만 보고는 절대 안 보이는 부분입니다.

이 글은 공급사로부터 공식 견적서를 받기 전, 담당자가 먼저 정리해둬야 할 항목들에 관한 이야기입니다. 이 순서를 지키면 견적서를 받은 뒤 “이게 왜 이렇게 갈렸지”라고 되묻는 시간을 줄일 수 있습니다.

통합제어 시스템 구축 비용, 견적서 세 장을 받았는데 왜 숫자가 다 다를까요

세 공급사가 같은 도면을 보고도 다른 항목을 잡는 이유는 대부분 하나입니다. 발주 담당자가 넘긴 요구사항이 공급사마다 다르게 해석될 여지를 남겼기 때문입니다.

저도 이 일을 처음 시작했을 때는 “회의실 3개, 터치패널로 조작, 화상회의 연동” 정도면 충분한 요구사항이라고 생각했습니다. 실제로는 이 문장 하나에서 공급사마다 완전히 다른 시스템을 상상합니다. 어떤 곳은 룸당 독립 프로세서를 잡고, 어떤 곳은 중앙 제어 서버 하나로 세 개 방을 묶습니다. 두 방식은 초기 구성부터 다르고, 견적 항목 자체가 달라집니다.

모호한 요구사항은 공급사 입장에서 리스크입니다. 범위를 확정할 수 없으니 각자 나름의 방식으로 여유를 견적에 반영합니다. 그 여유가 항목마다 다르게 붙어서, 담당자 눈에는 “왜 이렇게 항목이 다르지”로 보이는 겁니다. 이 문제는 공급사를 바꾼다고 해결되지 않습니다. 요구사항을 다시 쓰지 않으면 다음 견적서도 똑같이 갈립니다.

말로 설명한 요구사항은 견적서에서 다르게 읽힙니다 — RFP 7단계, 저도 처음엔 생략했습니다

이사업체에 견적을 받아본 분이라면 비슷한 경험이 있으실 겁니다. “짐이 좀 많아요”라고만 말하면 업체마다 트럭 대수를 다르게 잡습니다. “3톤 트럭 1대, 냉장고 1대, 박스 40개”라고 말하면 견적이 거의 일치합니다. 통합제어 시스템도 똑같습니다. 정성적 표현이 정량적 수치로 바뀌지 않으면 공급사마다 다른 그림을 그립니다.

체계적인 RFP(제안요청서)는 보통 이런 흐름을 거칩니다. 이해관계자 인터뷰로 요구사항을 모으고, 상충하는 부분을 조율하고, 기능·비기능·기술 요구사항으로 분류하고, 각 항목에 측정 가능한 기준을 붙이고, 전문가 검토로 일관성을 확인한 다음, 표준 양식으로 최종 정리해 승인받습니다. 저는 예전에 이 과정을 생략하고 바로 도면과 대화 내용만으로 발주를 진행한 적이 있습니다. 결과는 위에서 말한 것과 똑같았습니다 — 견적서가 세 갈래로 갈렸고, 항목을 다시 맞추느라 2주가 더 걸렸습니다.

핵심은 상세화 단계입니다. “터치패널로 편리하게 조작한다”는 표현 대신 “회의실 진입 후 10초 이내 프리셋(조명·스크린·오디오)이 동시 실행되고, 화상회의 시작 버튼은 터치 3회 이내로 도달한다”처럼 측정 가능한 기준을 써야 합니다. 이 정도로 구체적이어야 공급사가 같은 기준으로 견적을 잡습니다.

요구사항을 정량화하는 작업은 담당자 혼자 하기 어렵습니다. 실제 회의실을 쓰는 실무진, 화상회의 시스템을 관리하는 IT 담당, 예산을 승인하는 임원 — 이 세 그룹의 의견이 서로 다를 때가 많습니다. FGI(초점집단면접) 형태로 먼저 모아두면, 나중에 공급사가 “이 요구사항은 저 요구사항과 충돌합니다”라고 지적하는 상황을 사전에 줄일 수 있습니다. AV 시스템 도입 완전 가이드에서 발주 초기 단계 전반을 더 확인하실 수 있습니다.

터치패널 화면 하나 만드는 게 왜 이렇게 비쌀까요 — 프로그래밍은 별도 견적입니다

터치패널 견적서를 처음 받아본 담당자님들이 자주 묻는 질문입니다. “패널 하드웨어는 그렇다 쳐도, 화면 프로그래밍이 왜 이렇게 별도 항목으로 잡히나요?”

이유는 명확합니다. 터치패널 UI와 제어 로직은 하드웨어가 아니라 소프트웨어입니다. Crestron 계열은 SIMPL Windows나 SIMPL#Pro로, Q-SYS 계열은 Q-SYS Designer 스크립트와 플러그인으로 각 버튼의 동작·프리셋 순서·피드백 로직을 직접 코딩합니다. 회의실이 3개면 프리셋 조합도 3배가 아니라 그 이상으로 늘어납니다. 룸 컴바인(Room Combine)처럼 두 회의실을 하나로 합쳐 쓰는 기능을 넣으면, 합쳐졌을 때와 분리됐을 때 각각 다른 제어 로직을 새로 짜야 합니다.

이 작업은 국내 공공·민간 SW 사업 대가 산정에서도 별도 개발비 항목으로 다뤄지는 영역입니다. 기능 단위로 산정하는 방식(기능점수 방식)이 존재하고, AI 기반 최적화 로직처럼 난이도가 높은 커스터마이징 작업은 유형별로 개별 산정하는 것이 원칙입니다. 하드웨어 카탈로그 가격만 보고 “패널 몇 개니까 이 정도겠다”라고 어림잡으면, 프로그래밍 범위가 넓은 프로젝트에서 견적이 크게 벗어날 수 있습니다.

프로그래밍 범위를 미리 확정하는 방법은 단순합니다. 프리셋 개수, 룸 컴바인 여부, 화상회의 플랫폼별 자동 전환 여부를 요구사항 단계에서 숫자로 못 박는 것입니다. “터치패널 UI 편리하게”가 아니라 “프리셋 5종, 룸 컴바인 2개 조합, Zoom·Teams 자동 감지 전환”처럼 써야 프로그래밍 견적도 비교 가능해집니다.

계약서에 이 네 줄이 빠지면 나중에 반드시 문제가 됩니다

견적서 자체보다 계약 조건이 실제 분쟁을 만드는 경우가 더 많습니다. 국내 공공·민간 SW·시스템 통합 사업에서 반복적으로 명시해야 하는 조건이 몇 가지 있고, 통합제어 시스템 발주에도 그대로 적용됩니다. 다만 발주 주체가 공공기관인지 민간기업인지에 따라 법적 구속력이 다르다는 점은 구분해서 봐야 합니다 — 공공기관 발주라면 소프트웨어 진흥법에 따라 법적으로 적용되고, 민간기업 발주라면 법적 의무는 아니지만 통합제어 시스템 계약에서도 참고할 만한 업계 표준 관행입니다.

• 인력 산정 방식: 제안요청서에 투입 인력의 구체적인 맨먼스(M/M) 수치를 원칙적으로 못 박지 않습니다. 대신 핵심 기술 인력의 자격 요건만 명시하고, 실무 인력 산정은 공급사 자율에 맡기는 방식이 표준입니다.
• 하도급 비율 상한: 공공기관 발주 사업의 경우 하도급 비율은 전체 계약 금액의 50%를 넘을 수 없고, 재하도급은 원칙적으로 금지됩니다(소프트웨어 진흥법). 민간기업 발주 계약에는 이 조항이 법적으로 적용되지 않지만, 하도급 비율이 10%를 넘으면 입찰 단계에서 공동수급체 구성을 요구하는 것이 업계에서 통용되는 안전한 관행입니다.
• 하자담보책임 기간: 검수·인도 완료일로부터 1년 이내 무상 하자 보수를 계약서에 명시해야 합니다. 이때 정기 업그레이드인 ‘유지보수’와 오류 복구인 ‘하자보수’를 개념적으로 구분해두지 않으면, 나중에 같은 작업에 두 번 청구되는 상황이 생길 수 있습니다.
• 개발 산출물 권리 귀속: 특수 목적을 제외하면 커스텀 개발한 소프트웨어(터치패널 UI, 제어 로직)의 지식재산권은 발주처와 공급사 공동 귀속이 원칙입니다. 다른 지사·계열사가 같은 로직을 재사용할 수 있는지 여부도 계약 단계에서 정해둬야 합니다.

이 중 하나라도 계약서에 빠져 있으면, 준공 이후 유지보수 단가 분쟁이나 인력 교체 갈등으로 이어지기 쉽습니다. 저는 계약서 검토를 요청받을 때 이 네 항목을 가장 먼저 확인합니다. 견적 금액이 아무리 합리적이어도, 이 조건이 비어 있으면 계약을 다시 열어달라고 말씀드립니다.

장비를 하나로 묶는 순간 청구서가 따라옵니다 — 통합의 숨은 빚

이기종 장비를 하나의 제어 시스템으로 묶는 순간, 견적서에 안 보이던 비용이 따라붙습니다. 저는 이걸 “통합의 숨은 빚”이라고 부릅니다. 눈에 보이는 장비 비용과 별개로, 서로 다른 통신 방식을 하나로 엮는 작업 자체에 비용이 붙기 때문입니다.

통합제어 프로세서는 보통 세 갈래로 신호를 내보냅니다. RS-232 시리얼 통신으로 프로젝터·디스플레이를, TCP/IP로 DSP나 오디오 매트릭스를, 릴레이 접점으로 조명이나 스크린 모터를 제어합니다. 아래 구조를 보면 왜 통합이 단순 배선이 아닌지 감이 잡히실 겁니다.

graph LR
  A[터치패널 UI] --> B[제어 프로세서
Crestron/Q-SYS Core]
  B -->|RS-232| C[프로젝터·디스플레이]
  B -->|TCP/IP| D[DSP·오디오 매트릭스]
  B -->|릴레이| E[조명·스크린 모터]

문제는 이 세 갈래가 장비마다 프로토콜 버전, 명령어 세트, 응답 타이밍이 제각각이라는 점입니다. 첫 번째 시도로 표준 드라이버를 연결하면 대부분 붙습니다. 그런데 구형 프로젝터나 커스텀 조명 컨트롤러처럼 표준 드라이버가 없는 장비를 만나면, 공급사가 직접 명령어 세트를 분석해 전용 드라이버를 만들어야 합니다. 이 작업이 바로 ‘인터페이스 구성 비용’입니다. 배선 재작업, 노이즈 차폐, 이기종 장비 벤치마킹 테스트가 여기 따라붙습니다.

저는 이 작업을 견적서에서 별도 분리해달라고 요청합니다. 한 덩어리 ‘설치비’에 섞여 있으면, 어느 장비가 통합 난이도를 높였는지 담당자가 알 방법이 없습니다. 반대로 ‘인터페이스 구성 비용’이 항목별로 분리돼 있으면, 다음 리모델링에서 어떤 장비를 표준 드라이버 지원 제품으로 교체해야 유지보수가 쉬워지는지 판단할 수 있습니다.

같은 시스템인데 유지보수 견적이 왜 이렇게 다를까요

유지보수 견적도 공급사마다 편차가 큰 항목입니다. 대부분은 시스템의 복잡도를 산정하는 기준이 다르기 때문입니다.

유지보수 난이도는 대체로 세 가지 요소로 결정됩니다. 첫째, 연동되는 외부 인터페이스 수 — 화상회의 플랫폼, 예약 시스템, 사내 IT 네트워크처럼 연결된 시스템이 3개 이상이면 복잡도가 올라갑니다. 둘째, 장애가 발생했을 때 업무에 미치는 영향도 — 임원 회의실처럼 마비되면 곧바로 업무가 중단되는 공간은 대응 등급이 다르게 책정됩니다. 셋째, 복구 요구 시간 — 6시간 이내 긴급 복구를 요구하는 계약과, 다음 영업일 대응으로도 충분한 계약은 유지보수 인력 배치 자체가 다릅니다.

이 세 요소를 담당자가 먼저 정리해서 요청하지 않으면, 공급사는 각자 보수적으로 잡거나 각자 다르게 추정합니다. 그 결과가 유지보수 견적의 편차로 나타납니다. 저는 유지보수 견적을 비교할 때 총액보다 이 세 요소를 어떻게 산정했는지부터 물어봅니다. 산정 근거가 명확한 공급사는 대개 장애 대응 이력 관리도 체계적입니다.

견적서 앞에서 제가 항상 확인하는 5가지

가격 비교 이전에 봐야 할 것이 있습니다. 저는 처음 이 일을 시작했을 때 견적 금액과 스펙표만 비교했습니다. 지금은 공급사의 사업 안정성부터 확인합니다. 시스템이 아무리 잘 설계돼도, 공급사가 몇 년 뒤 지원을 중단하면 그 손해는 고스란히 발주처가 떠안습니다.

제가 견적서를 받으면 항상 확인하는 5가지입니다.

• 지배구조 안정성: 상장 여부, 사모펀드·벤처캐피털 투자 회수 대상인지 확인합니다. 다른 대형 IT 벤더에 인수합병되면 기존 제품군 지원이 갑자기 중단되는 사례가 실제로 있었습니다.
• 국제 품질·보안 인증: ISO 9001, ISO 27001 인증 보유 여부를 확인합니다. 인증이 없다고 무조건 배제하지는 않지만, 대기업 본사 프로젝트라면 요구 수준이 됩니다.
• 동종 규모 레퍼런스: 비슷한 규모의 통합제어 프로젝트를 실제로 수행한 이력이 있는지 확인합니다. 범용 솔루션을 그대로 이식만 하는 곳인지, 회의실 운영 방식에 맞춰 조정한 경험이 있는지가 다릅니다.
• 장애 대응 지표 관리: MTBF(평균 무고장 시간), MTTR(평균 수리 시간)을 추적 관리하는 체계가 있는지 물어봅니다. 이 지표를 답하지 못하는 공급사는 장애 이력 자체를 기록하지 않는다는 뜻입니다.
• 공식 드라이버 사용 여부: Crestron이면 Crestron 공식 인증 프로그램, Q-SYS면 Q-SYS Asset Manager 등록 플러그인, AMX·Extron이면 각 제조사 공식 드라이버 채널을 통한 개발인지 확인합니다. 비공식 드라이버로 구현된 기능은 제조사 펌웨어 업데이트 이후 갑자기 작동을 멈추는 경우가 있습니다.

이 5가지를 확인하고 나서 견적 금액을 비교하면, 왜 어떤 공급사는 항목이 더 세밀하고 왜 어떤 곳은 뭉뚱그려 있는지가 보이기 시작합니다. 대체로 세밀하게 항목을 나누는 공급사가 실제 프로젝트 경험이 더 많습니다. 견적서 받기 전 이 순서(요구사항 정량화 → 계약 조건 확인 → 통합 비용 분리 요청 → 유지보수 산정 기준 확인 → 공급사 검증)를 지키면, 견적서를 열었을 때 놀랄 일이 훨씬 줄어듭니다. 크레스트론·AMX·엑스트론 통합제어 비교에서 플랫폼별 특성을 더 확인하실 수 있습니다.

자주 묻는 질문

통합제어 시스템 구축 비용과 견적서 검토 관련해서 담당자님들이 실제로 자주 물어보시는 질문들입니다.

견적서 항목 편차는 공급사의 문제라기보다 발주 이전 단계의 문제인 경우가 대부분입니다. 요구사항을 숫자로 정리하고, 계약 조건 네 가지를 명시하고, 통합 비용과 유지보수 산정 기준을 분리해서 요청하는 것만으로 견적 비교가 훨씬 쉬워집니다.

[email protected] · https://www.symconsulting.co.kr