1. 개발 배경 — 기존 운영 방식의 한계

저희 회사는 여러 현장에 LED 전광판을 설치 · 운영하고 있습니다. 지금까지의 운영 방식은 단순했습니다. 현장에서 PC와 전광판 컨트롤러를 동일한 네트워크에 연결한 뒤, 제조사에서 제공하는 전용 프로그램으로 직접 제어하는 방식이었습니다.

장비가 한두 대이고 운영 장소가 한 곳일 때는 이 방식으로도 충분했습니다. 문제는 사업이 확장되면서 시작됐습니다. 설치 장소가 늘어나고 장비 수가 많아지자, 운영 방식의 한계가 하나둘 드러나기 시작했습니다.

장비 상태 확인이 어렵다 — 전광판의 전원 상태나 밝기 같은 기본 정보조차 중앙에서 확인할 수 없어, 현장별로 개별 접속하거나 직접 방문해야 확인이 가능했습니다.
모든 작업이 개별 작업이다 — 화면 ON/OFF, 밝기 조절 같은 단순 제어 작업도 일괄 처리가 불가능해 장비별로 개별 수행해야 했고, 장비 수가 늘어날수록 작업량도 그대로 비례해 증가했습니다.
통합 관리가 불가능하다 — 수도권과 지방 등 여러 지역에 분산 설치된 장비를 통합 조회하거나 관리할 수 있는 수단이 없었습니다.
장애 대응이 느리다 — 장애 발생 시 장비 이상인지 네트워크 이상인지 원격으로 진단할 수단이 없어, 원인 파악을 위해 현장 방문이 선행되어야 했습니다.

이 중 가장 치명적인 것은 장애 대응 문제였습니다. 전광판은 화면 표시 자체가 서비스인 장비이므로, 화면이 꺼져 있는 시간은 곧 서비스 중단 시간입니다. 그럼에도 화면이 꺼졌다는 사실조차 실시간으로 감지할 수 없다는 것이 가장 큰 한계였습니다.

이러한 문제를 해결하기 위해, 여러 현장에 분산된 전광판을 중앙 CMS에서 통합 조회하고 원격 제어할 수 있는 시스템 구축을 목표로 설정했습니다.

구조 자체는 단순합니다.

flowchart LR
    A["CMS (중앙 관리 시스템)"] --> B["원격 제어 API"]
    B --> C["각 현장의 컨트롤러 (HD-B6L)"]
    C --> D["LED 전광판"]

CMS 화면에서 버튼 하나로 전국 어디에 설치된 전광판이든 제어할 수 있게 하는 것이 이 프로젝트의 최종 목표입니다.

2. 사전 검토 — HD-B6L의 원격 제어 지원 여부

사용 중인 컨트롤러는 Huidu HD-B6L입니다. LED 전광판 업계에서 널리 쓰이는 중국 Huidu사의 비동기 컨트롤러로, 전광판에 콘텐츠를 내려보내고 화면을 제어하는 역할을 합니다.

CMS에서 장비를 제어하기 위한 전제 조건은 하나입니다. 장비가 문서화된 공식 API를 제공해야 한다는 것입니다. 비공개 프로토콜을 역분석해서 연동하는 방법도 이론상 가능하지만, 제조사 지원을 받을 수 없고 펌웨어 변경에 취약하기 때문에 운영 시스템의 기반으로 삼기는 어렵습니다.

그래서 가장 먼저 진행한 것은 개발이 아니라 지원 여부 확인이었습니다. Huidu 공식 문서를 확인한 결과, B6L은 HTTP API를 지원하는 모델로 명시되어 있었습니다. Huidu는 자사 컨트롤러용 HTTP 기반 SDK를 제공하고 있었고, B6L 역시 지원 대상에 포함되어 있었습니다.

방식은 이렇습니다.

컨트롤러가 자체적으로 HTTP 서버를 띄웁니다 (포트 30080).
외부 프로그램(저희의 경우 CMS)이 이 포트로 HTTP 요청을 보냅니다.
장비 정보 조회, 화면 ON/OFF, 밝기 조절 등의 명령을 API로 수행할 수 있습니다.

문서상으로는 요구사항을 모두 충족하는 구조였습니다. 이제 실제 장비에서 동일하게 동작하는지 검증할 차례였습니다.

3. 첫 번째 문제 — HTTP API 포트(30080) 접속 불가

테스트 환경은 단순하게 구성했습니다. PC와 B6L을 동일 네트워크에 연결한 뒤, 장비 IP로 HTTP API를 호출하는 방식입니다.

당시 장비에서 확인한 BoxPlayer(장비 내 애플리케이션) 버전은 2.11.10.0이었습니다.

그러나 첫 테스트에서 바로 문제가 발생했습니다. 장비에 대한 ping 응답은 정상이었지만, HTTP API가 사용하는 30080 포트로는 접속이 이루어지지 않았습니다.

사설 IP라 외부에서 접근 불가능한 주소지만, 내부 서브넷 구조를 굳이 보여줄 필요는 없어 마스킹처리했습니다.

브라우저에서 http://장비IP:30080/login/으로 접근해도 응답이 없었습니다. 네트워크 문제 여부를 확인하기 위해 포트 스캔을 수행한 결과, 30080 포트 자체가 닫혀 있는 것으로 확인됐습니다. 즉, 장비 자체는 정상 동작 중이지만 HTTP API 서버가 실행되지 않은 상태였습니다.

공식 문서에는 분명 지원 모델로 명시되어 있었지만 실제 장비에서는 API 서버가 동작하지 않는 상황이었기 때문에, 장비 모델명과 BoxPlayer 버전, 증상(30080 포트 미오픈)을 정리하여 Huidu 기술지원팀에 문의했습니다.

확인 결과, B6L의 HTTP API 지원은 맞지만 당시 설치된 펌웨어 버전에서는 해당 기능이 활성화되어 있지 않은 상태였습니다. 기술지원팀에서 제공한 B6L용 업데이트 파일로 펌웨어 업데이트를 진행했습니다.

4. 펌웨어 업데이트 — HTTP API 활성화

제공받은 파일로 펌웨어 업데이트를 진행했습니다. 업데이트는 U-Disk 방식을 사용했으며, 업데이트 파일을 USB 메모리에 담아 장비에 연결하면 자동으로 인식되어 설치가 진행됩니다.

업데이트 후 장비의 Application 버전은 2.11.10.0에서 2.12.8.0으로 변경됐습니다.

이후 포트 상태를 다시 확인한 결과, 기존에 닫혀 있던 30080 포트가 정상적으로 열려 있음을 확인했습니다.

브라우저를 통한 HTTP API 초기화 페이지 접근도 정상적으로 이루어졌습니다.

이 페이지는 HTTP API를 처음 사용할 때 SDK 인증 정보를 등록하는 초기 설정 화면입니다. 이 페이지에 접근할 수 있다는 것은 장비의 API 서버가 정상적으로 실행되고 있다는 의미입니다.

5. SDK 인증 및 조회 API 테스트

Huidu의 HTTP API는 인증 없이 호출할 수 없으며, sdkKey와 sdkSecret을 이용한 인증이 필요합니다. 이 키는 Huidu 기술지원팀을 통해 발급받았고, 앞서 접근한 초기화 페이지에서 장비에 등록했습니다.

인증 설정을 완료한 뒤, 가장 기본이 되는 장비 정보 조회 API를 호출했습니다.

장비 정보 조회 요청

BODY='{"method":"getDeviceProperty","data":[]}'
DATE=$(LC_ALL=C date -u "+%a, %d %b %Y %H:%M:%S GMT")
REQUEST_ID=$(uuidgen)

SIGN=$(printf '%s' "${BODY}${SDK_KEY}${DATE}" \
  | openssl dgst -md5 -hmac "$SDK_SECRET" \
  | sed 's/^.*= //')

curl -sS -X POST \
  'http://192.168.x.x:30080/api/device/<DEVICE_ID>' \
  -H 'Content-Type: application/json' \
  -H "sdkKey: $SDK_KEY" \
  -H "date: $DATE" \
  -H "sign: $SIGN" \
  -H "requestId: $REQUEST_ID" \
  --data "$BODY"

실제 응답

{
  "method": "getDeviceProperty",
  "message": "ok",
  "data": [
    {
      "id": "<DEVICE_ID>",
      "message": "ok",
      "data": {
        "name": "BoxPlayer",
        "sync": "false",
        "screen.width": "512",
        "screen.height": "256",
        "screen.rotation": "0",
        "version.hardware": "HD-B6L-V1.X",
        "version.fpga": "43.22.80",
        "version.kernel": "4.19.219",
        "version.app": "2.12.8.0",
        "time": "2026-09-07 05:59:11",
        "time.timeZone": "Asia/Shanghai",
        "time.sync": "auto",
        "time.ntp": "ntp.huidu.cn",
        "volume": "100",
        "volume.mode": "0",
        "luminance": "100",
        "luminance.mode": "0",
        "eth.dhcp": "true",
        "eth.ip": "192.168.x.x",
        "wifi.enabled": "true",
        "wifi.mode": "ap",
        "wifi.ap.ssid": "<SSID>",
        "wifi.ap.passwd": "********",
        "wifi.ap.channel": "0"
      }
    }
  ]
}

응답으로 장비의 주요 정보들이 정상적으로 내려왔습니다.

장비 정보 (모델명, 장비 ID)
해상도 (전광판 화면 크기)
IP 주소
펌웨어 버전
현재 밝기
볼륨
네트워크 상태

CMS 관점에서 보면 이 조회 API 하나만으로도 의미가 큽니다. 전광판의 동작 여부와 밝기 상태를 현장 방문 없이 파악할 수 있게 되었기 때문입니다. 개발 배경에서 언급했던 원격 진단 수단의 부재 문제를 해결할 수 있다는 것을 확인한 순간이었습니다.

6. 실제 제어 테스트 — 화면 OFF 명령 검증

조회 API가 동작한다고 해서 실제 제어까지 보장되는 것은 아닙니다. 마지막 검증 단계로 실제 제어 명령이 전광판에 정상적으로 반영되는지 확인했습니다.

테스트 명령으로는 화면 OFF 명령인 closeDeviceScreen을 사용했습니다. 실행 결과를 육안으로 즉시 확인할 수 있어 제어 반영 여부를 검증하기에 가장 확실한 명령입니다.

API 호출 결과, 다음과 같은 응답을 받았습니다.

kSuccess

그리고 응답과 동시에 실제 전광판 화면이 꺼지는 것을 확인했습니다.

단순히 응답 코드가 성공으로 반환된 것이 아니라, 실제 장비가 명령에 정상적으로 반응하는 것까지 확인했습니다. 이를 통해 이번 테스트에서 검증하고자 했던 항목을 모두 확인했습니다.

B6L은 HTTP API를 지원한다 (펌웨어 2.12.8.0 이상).
sdkKey/sdkSecret 인증 후 API 호출이 가능하다.
장비 상태 조회가 가능하다.
실제 화면 제어(ON/OFF)가 동작한다.

CMS에서 B6L을 HTTP API로 제어할 수 있다. — 이 프로젝트의 첫 번째 가설이 검증된 것입니다.

7. 다음 문제 — 같은 네트워크 밖에서는 어떻게 제어할까?

그러나 검증은 여기서 끝나지 않습니다. 지금까지의 테스트는 모두 PC와 장비가 동일한 네트워크에 연결된 환경에서 진행됐기 때문입니다.

사무실 테스트 환경

PC ──(같은 네트워크)──> B6L

직접 접근 가능

실제 운영 환경

CMS ──(인터넷)──> 전국 각 현장의 B6L

직접 접근 불가

실제 현장의 B6L은 각 현장 공유기 하위의 사설 IP 대역에 위치합니다. 외부 인터넷망에 있는 CMS 서버가 장비에 접근하려면 별도의 네트워크 구성이 필요합니다.

검토한 방식은 다음과 같습니다.

포트포워딩 — 현장 공유기마다 포트를 개방하는 방식입니다. 하지만 장비의 API 포트가 인터넷에 직접 노출되기 때문에 보안상 채택하기 어려웠습니다.
Site-to-Site VPN — CMS와 각 현장을 하나의 사설망처럼 연결하는 방식입니다. 외부에 API 포트를 노출하지 않고 안전한 통신 경로를 구성할 수 있습니다.

다음 글에서는 이 문제를 해결하기 위해 진행한 포트포워딩 검토 → Site-to-Site VPN 구성 → ipTIME 공유기 테스트 → MikroTik 도입까지의 네트워크 인프라 구축 과정을 다루겠습니다.

Huidu HD-B6L HTTP API 연동 및 제어 검증