IoT 개발업체는 무엇을 보고 선택해야 하나요?
IoT 개발업체를 고를 때는 유사 기기 연동 경험, 실물 테스트 방식, 하드웨어·펌웨어·앱·서버의 담당 범위, 운영 인수 절차를 함께 확인하세요. 유명한 기술 이름이나 포트폴리오 수만으로는 자신의 장비를 안정적으로 연결할 수 있는지 판단하기 어렵습니다. 같은 질문과 같은 샘플 자료를 업체마다 제공해야 제안을 비교할 수 있습니다.
포트폴리오를 읽는 네 가지 기준
| 확인 대상 | 면담에서 물어볼 질문 | 확인할 근거 |
|---|---|---|
| 연동 대상 | 어떤 장비·통신 방식과 연결했나요? | 기기 모델·연결 구성도·공개 기술 설명 |
| 수행 범위 | 자체 개발과 외부 제조사 담당은 어디까지였나요? | 개발 범위표·공개 사례의 역할 설명 |
| 장애 처리 | 오프라인·중복 수신·업데이트 실패를 어떻게 검증했나요? | 민감정보를 제거한 테스트 시나리오·데모 |
| 운영 인수 | 다른 담당자가 배포와 장애 확인을 할 수 있나요? | 인수 문서 목차·접근 권한 이전 절차 |
토핑의 공개 사례 중 진성ETS 프로젝트는 LoRa·RS485와 라즈베리 파이 게이트웨이를 이용한 화재 감지 관제를 설명합니다. 이 사례를 볼 때는 통신 연동, 온도 수집, 임계치 알림처럼 공개된 구현 범위를 기준으로 비교하세요. 자신의 장비에서도 같은 결과를 얻을 수 있는지는 별도 PoC와 현장 조건 확인이 필요합니다.
미팅에서는 정상 연결 다음 장면을 요청하세요
- 기기 전원을 껐다 켠 뒤 앱과 관제가 상태 변화를 구분하는가
- 네트워크를 끊었다 복구했을 때 저장된 데이터가 어떻게 처리되는가
- 명령 전송 성공과 실제 장치 동작 성공을 구분하는가
- 권한이 없는 사용자가 다른 고객의 기기를 조회하거나 제어할 수 없는가
- 기기 교체·소유권 이전 후 이전 사용자의 접근이 차단되는가
- 서버·앱·펌웨어 버전이 다를 때 오류를 진단할 기록이 있는가
외주를 나눠 맡긴다면 인터페이스 책임자를 정하세요
하드웨어 업체와 앱 개발사가 다르더라도 공동 프로토콜 문서와 통합 테스트 담당자가 있으면 협업할 수 있습니다. 반대로 한 업체가 모두 맡더라도 사양 변경 승인과 장애 분석 절차가 없으면 경계 구간에서 문제가 남습니다. 명령 ID, 데이터 단위, 응답 시간, 오류 코드, 버전 변경 규칙을 누가 확정하는지 적어두세요.
| 산출물 | 합의할 내용 |
|---|---|
| 프로토콜 문서 | 요청·응답 예시, 단위, 바이트 순서, 오류 코드, 버전 |
| 이슈 기록 | 재현 기기·펌웨어·앱 버전, 발생 시각, 로그, 담당자 |
| 완료 기준 | 실물 테스트 조합, 실패 시 재검수, 현장 확인자 |
| 변경 기록 | 변경 이유와 영향받는 앱·서버·펌웨어, 반영 일정 |
납품 이후에도 운영 가능한지 확인하세요
소스 저장소만 넘겨받아서는 운영을 이어가기 어렵습니다. 클라우드·앱 배포 계정의 소유 주체, 기기 인증서 발급·회수 절차, 펌웨어 빌드 방법, DB 백업·복구, 알림 수신자 변경, 장애 대응 연락 체계를 확인해야 합니다. 비밀 키는 공개 문서에 넣지 않고 별도 보안 경로로 전달합니다.
작성팀 소개
TOPPING 프로젝트팀 · PM · 기획 · 프로젝트 운영
2005년 이후 다양한 산업의 웹·앱·IoT·ERP 프로젝트를 기획하고 운영해 온 TOPPING의 프로젝트·기획 담당 팀입니다. 고객 상담, 범위 정의, 일정·변경 관리와 검수 기준 수립을 담당합니다.
