스마트 오피스 빌딩 앱 개발 업체, 어떻게 고르는가 — 견적서를 받은 뒤 물어야 할 6가지

준공을 앞두고 입주 일정 공지까지 나간 시점에 스마트 오피스 빌딩 앱 개발 업체 선정만 남아 있는 경우는 드물지 않습니다. 같은 요구사항 문서를 보냈는데도 돌아온 견적서는 금액이 두 배 가까이 벌어지고, 개발 기간은 네 달과 아홉 달로 갈립니다. 기능 목록만 놓고 보면 어느 쪽이든 비슷해 보입니다. 방문자 출입, 회의실 예약, 민원 접수, 공지 발송까지 적혀 있는 항목 자체는 크게 다르지 않습니다. 그런데 금액과 일정이 이 정도로 다르다면, 비교해야 할 것은 적혀 있는 항목이 아니라 적혀 있지 않은 항목입니다.

견적서에서 가장 먼저 빠지는 항목은 대체로 정해져 있습니다. 스피드게이트와 엘리베이터 제조사로부터 연동 규격을 누가 받아내는지, 실제 장비 앞에서 진행하는 현장 테스트를 몇 회로 잡아 두었는지, 입주사가 늘어날 때 권한과 데이터를 어떻게 분리할 것인지입니다. 이 세 가지는 화면 수나 개발 공수로 환산하기 어렵기 때문에 견적서에 줄로 잡히지 않습니다. 그리고 프로젝트가 밀리는 지점은 정확히 그 세 곳입니다.

이 글은 업체별 기능 목록을 비교하는 글이 아닙니다. 스마트 빌딩 앱 프로젝트가 실제로 어디에서 무너지는지, 견적서를 받은 뒤 업체에 무엇을 직접 물어야 하는지를 정리했습니다. 앱에 어떤 기능이 들어가야 하는지는 스마트 빌딩 앱 핵심 기능과 설계 전략에서 따로 정리했습니다.

디비컨설팅은 100건 이상의 프로젝트를 수행했으며, 그 가운데 프라임 오피스 입주사 앱 구축이 포함되어 있습니다. 서울 종로의 센트로폴리스 프로젝트는 K.awards 2023 웹 3.0 서비스 부문 대상을, 강남 테헤란로의 센터필드 프로젝트는 K.awards 2023 디지털 크리에이티브 우수상을 받았습니다. 그랑서울에서는 스마트 빌딩 입주사 서비스 앱을 구축했습니다. 아래 내용은 제안서 단계에서 정리한 이론이 아니라, 운영 중인 건물의 게이트와 엘리베이터 앞에서 확인한 내용입니다.

스마트 빌딩 앱 프로젝트는 어디에서 무너지는가

스마트 빌딩 앱 프로젝트가 일정과 비용에서 무너지는 이유는 개발 난이도가 아닙니다. 예약 화면을 만들고 알림을 보내는 작업 자체는 표준적인 개발입니다. 무너지는 이유는 건물이라는 현장에 자산운용사, PM사, 관리단, 하드웨어 제조사, 시공사, 입주사가 동시에 관여하는데, 그 사이에 생기는 공백을 누가 메울 것인지 정하지 않은 채 발주되기 때문입니다. 공백이 드러나는 순간 개발사는 계약 범위가 아니라고 말하고, 하드웨어 업체는 요청받은 적이 없다고 말합니다. 그동안 일정만 소모됩니다.

하드웨어 연동의 책임자가 정해져 있지 않습니다

스피드게이트, 엘리베이터, 출입통제, 주차 설비는 제조사마다 연동 방식이 다릅니다. 표준적인 규격을 제공하는 곳도 있고, 전용 연동 모듈이나 현장 서버를 반드시 거쳐야 하는 곳도 있습니다. 기술 문서가 영업 자료 수준이거나 아예 제공되지 않는 경우도 있습니다. 같은 제조사의 장비라도 건물에 실제로 설치된 모델과 펌웨어 버전에 따라 동작이 달라지기 때문에, 카탈로그만 보고 연동 가능 여부를 단정할 수 없습니다.

문제는 이 작업의 난이도가 아니라 주체입니다. 연동 명세를 받아내고, 테스트 계정과 검증 환경을 확보하고, 제조사 엔지니어의 일정을 잡는 일을 누가 할 것인지가 계약서에 없으면 그 공백은 전부 일정 지연으로 돌아옵니다. 개발사는 자료를 기다리는 중이라고 하고, 건물 측은 개발사가 이미 요청한 줄 알았다고 합니다. 이런 상태로 몇 주가 지나가는 일은 드물지 않습니다. 연동 책임자를 계약서에 명시하는 것만으로도 이 지연의 상당 부분은 사라집니다.

입주사별 권한과 데이터 분리를 나중에 붙이려 합니다

입주사 A의 직원은 A가 예약한 회의실, A가 등록한 방문자, A가 접수한 민원만 볼 수 있어야 합니다. 관리단은 건물 전체를 보아야 하고, 임대 조건에 따라 특정 입주사만 쓰는 공간과 공용 공간의 권한도 달라집니다. 이것은 화면에 버튼을 숨기는 문제가 아니라 데이터 구조와 인증 설계의 문제입니다.

이 구조를 초기에 잘못 잡으면 다른 회사의 정보가 보인다는 보안 사고로 이어집니다. 입주사의 보안 담당 부서가 사용 중단을 요구하면 앱은 그대로 멈춥니다. 뒤늦게 바로잡으려면 데이터 모델, 권한 검증 로직, 화면, 통계까지 모두 손을 대야 하므로 사실상 재개발에 가까워집니다. 따라서 견적 단계에서 입주사별 분리를 전제로 설계했는지, 아니면 단일 조직용 앱을 만든 뒤 나중에 분리를 얹을 생각인지를 반드시 확인해야 합니다. 입주자 앱이 실패하는 구조도 대부분 여기에서 시작됩니다.

현장 테스트 시간이 견적에 들어 있지 않습니다

사무실 환경에서 정상 동작하던 기능이 실제 게이트 앞에서는 다르게 동작하는 경우가 있습니다. 인증 화면의 인식 각도, 통신 지연, 사람이 걸어 들어오는 속도와 게이트 개폐 타이밍, 엘리베이터 자동 호출이 걸리는 순간, 지하 주차장의 통신 음영 같은 조건은 실제 장비 앞에 서 보아야 드러납니다. 이런 문제는 코드 품질과 무관하게 발생하며, 발견 시점이 늦을수록 수정 비용이 커집니다.

더 큰 제약은 건물이 이미 운영 중이라는 점입니다. 출근 시간대에 게이트를 점유할 수 없고, 야간이나 주말에만 테스트가 가능하며, 관리단과 제조사 엔지니어의 입회가 필요한 경우도 있습니다. 테스트 한 번을 잡기 위한 조율에만 며칠이 걸립니다. 이 시간을 일정에 반영하지 않은 견적서가 가장 싸고 가장 짧아 보입니다. 그리고 그 견적서가 실제로는 가장 늦게 끝납니다. 앱 개발 기간이 계획보다 길어지는 이유와 같은 구조입니다.

발주 구조 비교 — 누가 프로젝트를 책임지는가

그래서 실제 선택지는 어느 개발사가 더 싼가가 아닙니다. 하드웨어 제조사와의 협의, 이해관계자 조율, 현장 테스트, 출시 이후 장애 대응까지 포함한 프로젝트 전체를 누가 책임지고 끌고 가느냐의 구조 선택입니다. 발주사 내부에 그 역할을 맡을 인력이 있는지, 없다면 외부의 누가 그 자리를 채우는지에 따라 같은 기능 목록도 전혀 다른 일정과 비용으로 끝납니다. 아래 표는 선택 가능한 발주 구조를 책임 소재 기준으로 비교한 것입니다.

해외 개발팀에 직접 발주하면 단가는 내려가지만, 요구사항 정의와 제조사 협의, 현장 테스트 조율이 모두 발주사 담당자에게 넘어옵니다. 건물 운영 조직에 개발 인력이 없다면 이 구조는 현실적으로 유지되지 않습니다. IT 아웃소싱 구조를 검토하실 때 단가표보다 먼저 보셔야 할 것이 이 책임 배분입니다.

견적서를 받은 뒤 반드시 물어야 할 6가지

견적서를 받으셨다면 금액을 비교하기 전에 다음 여섯 가지를 업체에 직접 질문하시기 바랍니다. 답변이 구체적이지 않은 항목은 협상으로 해결되지 않고 그대로 프로젝트의 위험으로 남습니다.

1. 하드웨어 연동을 실제로 해본 적이 있습니까

가능하다는 답변이 아니라 어느 제조사의 어떤 장비를, 어떤 방식으로 연동했는지를 물어야 합니다. 출입 게이트와 엘리베이터는 연동 구조가 서로 다르므로 각각 따로 확인하시기 바랍니다. 연동이 막혔을 때의 대안을 가지고 있는지도 함께 물어야 합니다. 현장 서버 경유, 중계 모듈 추가, 일부 기능의 수동 운영 전환 같은 차선책을 미리 말할 수 있는 업체는 이미 겪어본 업체입니다.

2. 입주사별 권한 구조를 설계해본 적이 있습니까

하나의 앱 안에서 여러 입주사의 데이터를 분리해 운영한 경험이 있는지 확인해야 합니다. 입주사가 추가되거나 퇴거할 때 데이터와 계정을 어떻게 처리하는지, 관리단과 입주사 관리자의 권한을 어떤 단위로 나누는지까지 설명할 수 있어야 합니다. 설계 산출물로 권한 정의서를 제출할 수 있는지 물어보시면 경험 여부가 분명해집니다.

3. 현장 테스트 일정이 견적에 포함되어 있습니까

몇 회를 계획했는지, 1회당 몇 시간을 잡았는지, 누구의 입회가 필요한지를 숫자로 확인해야 합니다. 테스트 시간대가 야간이나 주말로 제한될 가능성과 그에 따른 비용 처리 방식도 미리 합의해 두는 편이 좋습니다. 이 항목이 비어 있는 견적서는 금액이 확정된 견적서가 아니라 추후 변경을 전제한 견적서입니다.

4. 건물 이해관계자 조율은 누가 합니까

자산운용사, PM사, 관리단, 입주사, 하드웨어 제조사의 요구는 서로 충돌합니다. 출입 정책 하나만 해도 보안을 우선하는 쪽과 편의를 우선하는 쪽의 결론이 다릅니다. 이때 요구를 정리해 하나의 기준으로 확정하는 주체가 발주사 담당자인지 업체의 담당자인지 계약 전에 정해야 합니다. 이 역할이 비어 있으면 결정이 미뤄지고, 미뤄진 결정은 전부 개발 일정에서 차감됩니다.

5. 출시 이후 장애 대응 체계가 있습니까

건물은 24시간 운영됩니다. 출근 시간에 출입 인증이 되지 않으면 로비가 즉시 막히므로, 다음 영업일 대응으로는 부족합니다. 장애 접수 경로, 연락 가능한 시간대, 1차 대응까지의 목표 시간, 담당자가 한국어로 소통되는지를 계약서 수준에서 확인하시기 바랍니다.

6. 소스코드와 산출물의 소유권이 명시되어 있습니까

완성된 앱의 소스코드가 발주사에 귀속되는지 계약서에 적혀 있어야 합니다. 코드만으로는 부족하며, 연동 명세와 데이터 구조, 배포 절차 문서까지 함께 받아야 다음 단계에서 다른 업체도 이어받을 수 있습니다. 이 조건이 없으면 유지보수 업체를 바꾸는 순간 처음부터 다시 만들어야 합니다.

디비컨설팅은 이 리스크를 어떻게 통제하는가

디비컨설팅은 한국인 PM이 요구사항 정의와 일정, 검수를 책임지고 개발은 검증된 글로벌 개발팀이 수행하는 구조로 프로젝트를 운영합니다. 50개 이상의 글로벌 파트너사를 통해 전담 개발팀을 2~4주 내에 구성하며, 국내 개발사에 직접 발주하는 경우와 비교해 평균 40~60%의 비용 절감이 가능합니다. 발주사는 처음부터 끝까지 한국어로만 소통하며, 제조사 협의나 관리단 일정 조율 같은 현장 업무도 PM이 맡습니다. 앞에서 설명한 세 가지 공백은 모두 이 PM의 책임 범위 안에 있습니다.

특히 1단계에서 요구사항을 한국어 문서로 확정하는 작업이 이후의 재작업을 줄입니다. 출입 정책, 입주사별 권한 범위, 연동 대상 장비와 제조사, 현장 테스트 횟수와 시간대를 문서에 적어 두면 개발 중간에 해석이 갈릴 여지가 사라집니다. 구두로 합의한 내용이 개발팀에 전달되는 과정에서 달라지는 일이 없도록, 발주사가 읽고 승인한 한국어 문서를 기준 문서로 삼습니다.

1. 상담 및 요구 분석 — 건물의 운영 방식과 입주사 구성, 설치된 장비를 확인하고 요구사항을 한국어 문서로 정리합니다. 이 단계에서 연동 가능 여부와 확인이 필요한 항목을 구분합니다.
2. 개발팀 구성 — 프로젝트 성격에 맞는 전담 개발팀을 2~4주 내에 구성합니다. 하드웨어 연동이 포함된 프로젝트는 해당 경험을 보유한 인력을 우선 배치합니다.
3. 프로젝트 개발 — 애자일 방식으로 기능을 단계적으로 완성하고 진행 상황을 투명하게 공유합니다. 발주사는 주요 기능이 나올 때마다 확인할 수 있으므로 완성 후에 문제를 발견하는 상황을 피할 수 있습니다.
4. 테스트 및 배포 — 기능 테스트와 함께 실제 장비를 이용한 현장 검증을 진행합니다. 테스트 시간대는 건물 운영에 지장이 없도록 관리단과 사전에 조율합니다.
5. 운영 및 유지보수 — 출시 이후 장애 대응과 개선을 지원하며, 소스코드와 함께 연동 명세, 데이터 구조, 배포 절차 문서를 인계합니다. 산출물의 소유권은 발주사에 귀속됩니다.

건물 관리 시스템 자체를 함께 구축하거나 기존 시스템과 통합해야 하는 경우는 BMS 구축에서, 앱 개발 전반의 진행 방식은 앱 개발 외주에서 확인하실 수 있습니다.

실제 구축 사례

아래는 실제로 구축한 프라임 오피스 입주사 앱 사례입니다. 건물마다 설치된 장비와 운영 주체가 달랐기 때문에 요구사항과 연동 범위도 각각 다르게 설계했습니다.

• 센트로폴리스 (서울 종로) — 다수 입주사를 전제로 한 권한·데이터 분리 설계, 방문자 QR 출입, 실시간 혼잡도 기반 시설 예약, 민원 접수 처리 상태 조회, 입주사 커뮤니티. K.awards 2023 웹 3.0 서비스 부문 대상.
• 센터필드 (강남 테헤란로) — QR 스피드게이트 통과와 연동된 엘리베이터 자동 호출, 회의실·비즈니스 라운지 예약, 로비 미디어홀 연동. K.awards 2023 디지털 크리에이티브 우수상.
• 그랑서울 — 시설 예약, 방문객 관리, 공지 및 편의 서비스를 통합한 입주사 서비스 앱.

입주사 편의 시스템의 기능 범위를 더 자세히 보시려면 프라임 오피스 빌딩 입주사 편의 시스템 구축을, 다른 구축 사례는 포트폴리오에서 확인하실 수 있습니다.

이런 기업에 적합합니다

• 준공 또는 리뉴얼을 앞두고 입주사 서비스 앱을 처음 구축하는 자산운용사와 PM사
• 사내에 개발 인력이 없어 하드웨어 연동과 일정 관리를 책임질 주체가 필요한 경우
• 복수의 입주사가 입주하는 건물이라 권한과 데이터 분리가 반드시 필요한 경우
• 여러 건물을 운영하고 있어 하나의 구조를 다른 건물로 확장하려는 경우

반대로 권하지 않습니다

• 사내에 빌딩 IT 전담 조직과 개발 인력이 이미 있어 직접 설계하고 관리할 수 있는 경우
• 장비 연동 없이 공지와 안내만 제공하는 단순 앱이면 되는 경우로, 이때는 과한 투자가 됩니다
• 건물 운영 주체가 아직 확정되지 않아 출입 정책과 입주사 범위를 결정할 수 없는 경우

자주 묻는 질문

해외 개발팀이라면 의사소통과 현장 대응은 어떻게 이루어집니까?

발주사의 소통 창구는 한국인 PM 한 명으로 고정되며, 모든 협의와 문서는 한국어로 진행됩니다. 요구사항을 개발팀에 전달하고 결과를 검수하는 책임도 이 PM에게 있습니다. 관리단 입회가 필요한 현장 테스트나 하드웨어 제조사와의 협의처럼 한국 현장에서 처리해야 하는 업무도 PM이 맡습니다. 발주사가 해외 개발팀과 직접 영어로 소통할 일은 없습니다.

비용은 어떻게 산정됩니까?

화면 수만으로 산정하지 않고, 연동 대상 장비의 수와 제조사, 입주사별 권한 분리 범위, 현장 테스트 횟수를 포함해 산정합니다. 1단계 상담에서 이 항목들을 확인한 뒤 범위를 확정하므로, 연동 대상이 늘어나거나 테스트 조건이 달라지면 금액도 달라집니다. 국내 개발사에 직접 발주하는 경우와 비교하면 평균 40~60%의 비용 절감이 가능합니다.

기획서가 없는데 견적을 받을 수 있습니까?

가능합니다. 건물 개요, 입주사 구성, 설치된 출입 및 엘리베이터 설비, 앱으로 제공하고 싶은 서비스 범위 정도만 공유해 주시면 1단계에서 요구사항을 함께 정리합니다. 이 과정에서 한국어 요구사항 문서를 작성해 드리므로, 다른 업체와 비교하실 때도 동일한 기준으로 견적을 받아 보실 수 있습니다.

기존 BMS나 출입통제 시스템과 연동이 됩니까?

연동 가능 여부는 제조사와 설치된 모델, 제공되는 연동 방식에 따라 달라지므로 사전 확인이 필요합니다. 그래서 1단계에서 설비 목록과 제조사를 먼저 파악하고, 연동 명세와 검증 환경 확보까지 PM이 진행합니다. 연동이 불가능한 항목이 확인되면 현장 서버 경유나 일부 기능의 운영 절차 대체 같은 대안을 함께 제시합니다. 확인 전에 가능하다고 단정해 드리지는 않습니다.

소스코드 소유권은 누구에게 있습니까?

완성된 소스코드의 소유권은 발주사에 귀속됩니다. 코드와 함께 API 명세, 데이터베이스 구조, 배포 절차 문서까지 인계하므로 이후 다른 업체가 유지보수를 이어받는 것도 가능합니다. 인계 범위는 계약서에 명시합니다.

정리

스마트 오피스 빌딩 앱 개발에서 결과를 가르는 것은 개발 단가가 아닙니다. 하드웨어 연동 규격을 누가 받아내는지, 입주사별 권한 구조를 누가 설계하는지, 현장 테스트 일정을 누가 조율하는지, 출시 이후 장애를 누가 받는지가 정해져 있는지 여부입니다. 건물 운영 주체에 개발 인력이 없다면 이 책임은 발주사 안에서 채워지지 않으며, 결국 누군가 외부에서 그 자리를 맡아야 합니다. 견적서를 비교하실 때 금액 아래에 적힌 범위부터 확인하시고, 책임 주체가 비어 있는 항목이 있다면 계약 전에 채우시기 바랍니다.