이 글을 쓴 사람: 외주 개발사 대표 (공학박사, 개발 경력 18년)
장비 연동, 센서 데이터, 프로토콜 분석 — 이런 키워드가 들어간 프로젝트를 저희도 여러 번 했습니다. 성공한 것도 있고, 목표를 달성하지 못한 것도 있습니다. 이 글은 그 경험을 바탕으로, 이런 프로젝트를 외주 맡기기 전에 알아야 할 것들을 정리합니다.
※ 이 글에 등장하는 사례는 실제 프로젝트를 바탕으로 하되, 고객사 정보 보호를 위해 업종·규모·기능 등을 각색했습니다.
"산업용 소프트웨어"를 만드는 입장에서 솔직히 말씀드리면
검색창에 "데이터 수집 프로그램 외주"나 "장비 연동 소프트웨어 외주"를 치셨을 겁니다. 마치 "산업용 소프트웨어"라는 별도의 분야가 있고, 그걸 전문으로 하는 업체가 따로 있을 거라고 생각하실 수 있습니다.
솔직히 말씀드리면, 만드는 입장에서는 그런 구분이 크지 않습니다.
있는 건 **"일반적인 SW보다 더 어려운 문제가 포함된 프로젝트"**입니다. 그 "더 어려운 문제"란 대체로 이런 것들입니다:
- 하드웨어와 직접 통신해야 한다 (시리얼, BLE, TCP/IP 등)
- 장비 제조사가 프로토콜을 공개하지 않는다
- 데이터의 물리적 의미를 알아야 제대로 처리할 수 있다
- 일반 웹/앱 개발에서는 만나지 않는 저수준(low-level) 작업이 필요하다
이걸 모르고 시작하면 실패합니다. 그리고 이걸 알고 시작해도 실패할 수 있습니다. 아래에서 실제로 보여드리겠습니다.
데이터 수집 프로그램 — 10Hz로 충분할 거라고 생각했다
이건 저희가 목표를 달성하지 못한 프로젝트 이야기입니다.
프로젝트 개요
차량에 탑재된 가속도 센서(G-sensor) 데이터로 충격 유형을 자동 분류하는 시스템을 만드는 프로젝트였습니다. 범퍼 접촉인지, 포트홀인지, 교통사고인지, 단순 노면 진동인지 — 이걸 센서 데이터만으로 구분하는 것이 목표였습니다.
기존 시스템에 저장되는 G-sensor 데이터는 10Hz(초당 10회 측정)였습니다. 이 데이터를 분석해서 충격을 분류하자는 컨셉이었고, 저는 될 거라고 생각했습니다.
결과: 분류가 안 됐습니다
여러 알고리즘을 시도했지만, 충격 유형을 신뢰할 수 있는 수준으로 분류하지 못했습니다. 다른 방향으로 피봇해서 프로젝트 자체는 마무리했지만, 처음 목표였던 충격 분류는 달성하지 못했습니다.
원인: 나중에야 알았습니다
프로젝트가 끝나고 나서 왜 안 됐는지 궁금해서 관련 자료를 조사했습니다. 답은 나이퀴스트 샘플링 이론에 있었습니다.
간단히 설명하면, 10Hz로 수집된 데이터에서 의미 있게 분석할 수 있는 주파수 정보는 최대 5Hz입니다. 5Hz로는 범퍼 충격(수십~수백Hz 대역)과 포트홀 충격의 파형 차이를 구분할 수 없습니다. 애초에 데이터에 정보가 없었던 것입니다.
나중에 확인해보니, 동종 업계의 제품들은 장비 자체에서 1,000Hz 이상으로 수집한 뒤, 전처리(필터링, 특징 추출)를 거쳐 100Hz 정도로 압축 저장하는 방식을 쓰고 있었습니다. 10Hz와는 차원이 다른 데이터였습니다.
교훈
데이터 수집 프로그램의 성패는 코드가 아니라 **"어떤 데이터를 어떤 주기로 수집하느냐"**에서 갈립니다. 아무리 코드를 잘 짜도, 입력 데이터에 정보가 없으면 결과도 없습니다.
솔직히 말하면, 제가 사전에 이 도메인을 더 조사했어야 합니다. 개발 경력 18년이지만 도메인 지식 없이 뛰어들면 이렇게 됩니다.
외주 맡기기 전 확인할 것
| 확인 항목 | 왜 중요한가 |
|---|---|
| 현재 장비의 샘플링 레이트 | 분석 목적에 필요한 최소 주파수를 충족하는지 |
| 전처리 방식 | 장비에서 할 것인지, 소프트웨어에서 할 것인지 |
| 동종 업계의 데이터 수집 스펙 | 경쟁 제품이 어떤 스펙으로 수집하는지 |
| 분석 알고리즘의 입력 요구사항 | 사용하려는 분석 방법이 요구하는 데이터 품질 |
장비 연동 프로그램 — 문서 없는 프로토콜을 풀어야 할 때
이번에는 성공한 프로젝트입니다.
프로젝트 개요
의료 현장에서 쓰이는 검사 장비 3종을 병원 정보 시스템과 연동하는 프로젝트였습니다. 검사 장비에서 처방을 받고, 검사 결과를 다시 병원 시스템으로 보내는 흐름입니다.
문제는 프로토콜이었습니다.
| 장비 | 프로토콜 문서 |
|---|---|
| A사 장비 | 일부 문서 있음 (처방 프로토콜은 미공개) |
| B사 장비 | 문서 없음 |
| C사 장비 | 문서 없음 |
3종 중 2종은 제조사가 프로토콜을 외부에 공개하지 않는 장비였습니다. 공식적인 연동 방법이 없었습니다.
어떻게 풀었나
다행히 기존에 동작하는 시스템은 있었습니다. 장비와 기존 서버 사이에서 실제로 데이터가 오가고 있었습니다. 저는 그 사이에 끼어들었습니다.
- 패킷 캡처: 네트워크 분석 도구로 장비와 서버 사이의 통신 데이터를 수집
- HTTP 중계 서버: 일부 HTTP 기반 통신은 중계 서버를 만들어서 요청/응답을 기록
- 바이너리 패킷 분석: TCP 기반 독자 프로토콜은 바이너리 데이터를 하나씩 분석해서 구조를 파악
완벽하지는 않지만, 실제 업무에 쓸 수 있는 수준으로 연동을 만들었습니다.
왜 이걸 할 수 있었나
솔직히 말하면, 도메인 전문가여서가 아닙니다. 의료 장비 프로토콜을 미리 알고 있었던 게 아닙니다.
다만 과거에 임베디드 시스템을 다뤄본 경험, 바이너리 데이터를 분석해본 경험이 있었습니다. "패킷을 캡처해서 분석하면 되지 않을까?"라는 발상 자체가 그런 경험에서 나왔습니다.
중요한 건 이겁니다: 이 접근을 "해보겠다"고 생각하는 개발자 자체가 드뭅니다. 리버스 엔지니어링이라는 개념은 많은 개발자가 알고 있지만, 실제로 네트워크 패킷을 캡처하고 바이너리를 분석해서 프로토콜을 재현하는 작업을 해본 사람은 많지 않습니다.
외주 맡기기 전 확인할 것
| 확인 항목 | 왜 중요한가 |
|---|---|
| 장비 프로토콜이 공개인지 비공개인지 | 공개면 연동 난이도가 크게 낮아짐 |
| 기존에 동작하는 시스템이 있는지 | 있으면 리버싱 기반 분석이 가능 |
| 업체의 저수준 통신 경험 | 바이너리/패킷 분석, 시리얼 통신 등의 경험 |
| 프로토콜 종류 | RS-232, Modbus, BLE, TCP/IP, 독자 프로토콜 등 |
GUI·모니터링 소프트웨어 — 데이터를 "보여주는" 것도 도메인 지식이다
데이터를 수집하거나 장비를 연동했으면, 결국 사람이 보고 판단할 화면이 필요합니다. 이 부분을 가볍게 보는 경우가 많은데, 실제로는 여기서 현장 활용도가 갈립니다.
같은 데이터, 다른 화면
예를 들어 차량용 IoT 기기 수십만 대에서 실시간으로 올라오는 센서 데이터가 있다고 합시다. 이 데이터를 어떻게 보여주느냐에 따라 쓸모가 완전히 달라집니다.
- 단순 테이블: 데이터는 다 보이지만, 이상 징후를 발견할 수 없음
- 시계열 차트: 추이는 보이지만, 어떤 기기에서 문제가 생겼는지 파악이 어려움
- 지도 기반 대시보드 + 이벤트 필터링: 어디에서 무슨 일이 일어나고 있는지 즉시 파악 가능
저희가 실제로 만든 대규모 모니터링 시스템은 세 번째 방식입니다. 전 세계에서 동시에 올라오는 데이터를 지도 위에 실시간으로 표시하고, 특정 이벤트(급제동, 충격 등)만 필터링해서 볼 수 있게 했습니다.
"예쁜 UI"가 아니라 "쓸 수 있는 UI"
GUI·모니터링 소프트웨어에서 중요한 건 디자인이 예쁜 것이 아닙니다. 현장에서 의사결정에 쓸 수 있는 화면인지가 핵심입니다.
이걸 만들려면 "사용자가 이 화면을 보고 어떤 판단을 내려야 하는가?"를 먼저 이해해야 합니다. 공장 관리자가 보는 모니터링 화면과 연구자가 보는 분석 화면은 같은 데이터라도 보여주는 방식이 완전히 다릅니다.
업체 선정 — "도메인 전문가"보다 중요한 것
여기까지 읽으셨으면 "그러면 도메인 전문가인 업체를 찾아야 하나?"라고 생각하실 수 있습니다.
이상적으로는 맞습니다. 하지만 현실적으로, 여러분의 도메인을 미리 아는 외주 업체를 찾기는 쉽지 않습니다. 장비 연동, 센서 데이터, 프로토콜 분석이 필요한 프로젝트는 각각 도메인이 다르고, 모든 도메인을 커버하는 업체는 없습니다.
더 중요한 건 이겁니다: "모르는 걸 파고들 수 있는 팀인가."
위의 두 사례를 다시 보세요:
- 실패한 프로젝트: 도메인 사전조사가 부족했습니다. 하지만 실패 원인을 끝까지 추적해서 다음에는 같은 실수를 하지 않을 수 있게 됐습니다.
- 성공한 프로젝트: 의료 장비 프로토콜을 미리 알았던 게 아닙니다. "해보겠다"고 덤벼들어서 패킷을 분석하고 프로토콜을 재현한 것입니다.
업체에 물어봐야 할 5가지
| # | 질문 | 이 질문으로 알 수 있는 것 |
|---|---|---|
| 1 | 유사한 난이도의 프로젝트 경험이 있나요? | 같은 도메인이 아니어도, 저수준 통신이나 하드웨어 연동 경험이 있는지 |
| 2 | 프로토콜 분석이나 리버스 엔지니어링 경험이 있나요? | 문서 없는 장비를 다뤄본 적이 있는지 |
| 3 | 사전 기술 검토(feasibility check)를 해주나요? | 무턱대고 시작하는지, 사전에 가능 여부를 확인하는지 |
| 4 | 과거에 실패한 프로젝트가 있나요? | 실패를 솔직히 이야기하는 업체가 신뢰할 수 있는 업체 |
| 5 | "안 된다"고 한 적이 있나요? | "안 된다" 대신 "조사해보겠다"고 하는 팀이 이런 프로젝트에 적합 |
자주 묻는 질문
C#이나 WPF로만 개발해야 하나요?
아닙니다. C#/WPF는 Windows 데스크톱 프로그램에 주로 사용되지만, 유일한 선택지는 아닙니다. 프로젝트 요구사항에 따라 Python, Java, 웹 기술(React 등) 등 다양한 기술 스택이 가능합니다.
기술 스택은 이런 기준으로 결정합니다:
| 기준 | 설명 |
|---|---|
| 장비 프로토콜 | 장비 SDK가 특정 언어만 지원하는 경우가 있음 |
| 운영 환경 | Windows 전용이면 C#/WPF, 크로스플랫폼이면 웹이나 Python |
| 유지보수 계획 | 내부에서 유지보수할 인력의 기술 스택 |
하드웨어도 같이 만들어주나요?
양산용 완제품 하드웨어 설계·제조는 범위 밖입니다. 다만 프로토타입 수준의 하드웨어는 만들 수 있습니다. ESP32나 아두이노 같은 개발 보드로 센서 연동, 데이터 수집, 통신 테스트 등 MVP 수준의 하드웨어 프로토타입을 제작하고, 여기에 소프트웨어를 연동하는 것까지는 저희 업무 범위입니다. 양산이 필요한 단계에서는 하드웨어 전문 업체와 협업하는 방식을 권장합니다.
기존 장비가 있는데 소프트웨어 연동만 가능한가요?
가능합니다. 오히려 이런 의뢰가 대부분입니다. 장비가 이미 있고, 그 장비에서 나오는 데이터를 수집·분석·표시하는 소프트웨어를 만드는 것입니다. 장비 프로토콜이 공개되어 있으면 비교적 수월하고, 비공개라도 기존에 동작하는 시스템이 있으면 분석을 시도할 수 있습니다.
데이터 수집 프로그램도 외주가 되나요?
됩니다. 다만 위에서 설명했듯이, 센서 데이터 수집은 샘플링 레이트, 전처리 방식, 저장 구조가 분석 결과의 성패를 좌우합니다. "데이터를 저장하는 코드"를 짜는 것보다 "어떤 데이터를 어떻게 저장해야 하는지"를 아는 것이 더 중요합니다.
비용은 일반 앱보다 비싼가요?
일반적으로 더 높습니다. 이유는 일반 웹/앱에는 없는 추가 공수가 발생하기 때문입니다:
- 프로토콜 분석 (공개/비공개에 따라 공수 차이 큼)
- 하드웨어 테스트 환경 구축
- 도메인 학습 (해당 분야의 데이터 특성, 규격 등)
- 실 장비 테스트 (시뮬레이션만으로 검증이 어려운 경우)
구체적인 비용 구조는 소프트웨어 외주 개발 비용 가이드를 참고하세요.
마무리
정리하면 이렇습니다:
- "산업용 소프트웨어"라는 별도의 분야가 있다기보다, 더 어려운 문제가 포함된 프로젝트입니다.
- 데이터 수집은 코드가 아니라 데이터 품질에서 갈립니다. 샘플링 레이트, 전처리 방식을 먼저 확인하세요.
- 장비 연동은 프로토콜이 핵심입니다. 공개인지 비공개인지, 기존 시스템이 있는지를 먼저 파악하세요.
- 업체를 고를 때 "도메인 전문가"를 찾기보다, "파고들 수 있는 팀"을 찾으세요.
어떤 프로그램을 만들어야 할지 아직 정리가 안 됐다면, 유형별 가이드에서 먼저 유형을 파악해 보세요. 비용이 궁금하시면 비용 가이드를, 외주 절차 전체가 궁금하시면 절차 5단계를 참고하세요.
궁금한 점 있으시면 편하게 문의해 주세요. 상담은 무료입니다.
소프트웨어 개발 의뢰가 처음이시라면 소프트웨어 개발 의뢰 가이드에서 전체 흐름을 먼저 확인해 보세요.
About
Things workshop (띵스워크샵)
2020년 설립, 소프트웨어 개발 전문 기업입니다.
| 항목 | 내용 |
|---|---|
| 대표 경력 | 공학박사, 개발 18년 (2007~) |
| 주요 분야 | 의료/헬스케어 IT, IoT/모빌리티, 웹/앱 풀스택 |
| 주요 역량 | 장비 프로토콜 연동, 센서 데이터 처리, 대규모 모니터링 시스템 |
"안 된다는 말 대신 방법을 찾습니다."
📧 contact@thingsw.com 📞 032-889-0410 🌐 thingsw.com
인천광역시 미추홀구 용정공원로 33