제3장: WIA-ROB-011 표준 개요

弘益人間 (홍익인간) - 널리 인간을 이롭게 하라

3.1 표준의 사명과 비전

WIA-ROB-011 청소 로봇 표준은 상호운용성을 위한 공통 프레임워크를 수립하여, 어느 제조사의 청소 로봇이든 스마트 홈, 건물, 기업 관리 시스템과 무리 없이 통합될 수 있게 하는 것을 목표로 한다. 청소 자동화 도입의 장벽을 낮추고 개방형 협업으로 혁신을 앞당긴다는 이 사명은 WIA의 핵심 철학인 弘益人間(널리 인간을 이롭게 하라)과 맞닿아 있다.

비전 선언

이 표준이 그리는 세상에서 청소 로봇은 제조사, 배치 규모, 환경의 복잡도와 관계없이 Wi-Fi처럼 상호운용 가능하고 신뢰할 수 있는 인프라로 작동한다. 고객은 생태계 종속이 아니라 성능과 기능을 기준으로 로봇을 선택한다. 개발자는 부가가치 서비스를 한 번 만들어 모든 호환 기기에 배포한다. 건물 관리자는 서로 다른 기종이 섞인 로봇군(fleet)을 하나의 인터페이스로 조율한다.

핵심 목표

보편적 상호운용성: WIA-ROB-011을 준수하는 로봇은 제조사와 관계없이 준수하는 모든 제어 시스템과 함께 작동한다.

데이터 이동성: 로봇 상태, 지도, 청소 기록, 센서 데이터가 표준화된 형식을 통해 시스템 간에 이전된다.

API 일관성: 개발자는 하나의 API만 익히면 모든 준수 로봇을 제어할 수 있어, 제조사마다 별도로 통합해야 하는 부담이 줄어든다.

설계 단계부터의 보안: 인증, 전송 구간 암호화, 저장 데이터 암호화가 명세 수준에서 요구되어 사용자와 시설을 보호한다.

미래 대응 아키텍처: 확장 필드와 버전 관리 규칙을 통해 호환성을 깨뜨리지 않고 새로운 기술을 수용한다.

3.2 표준의 범위와 적용 대상

WIA-ROB-011은 자율 및 반자율 청소 기기를 위한 표준 인터페이스를 정의한다. 이 표준은 특정 기계 설계나 내비게이션 알고리즘을 규정하지 않고, 의도적으로 데이터 교환, 제어 인터페이스, 통신 프로토콜, 외부 시스템 통합에 초점을 맞춘다.

포함되는 로봇 유형

명세의 데이터 모델(점유 격자 지도, 바닥 재질 구분, 흡입력 제어 등)은 바닥 청소 로봇을 중심으로 작성되어 있다. 다른 유형의 청소 로봇은 로봇 식별 정보, 상태, 이벤트, 명령, API, 통신 프로토콜 같은 공통 계층을 그대로 사용하고, 유형 고유의 정보는 x_ 접두사를 붙인 확장 필드로 표현한다.

로봇 범주 세부 유형 적용 방식
바닥 청소 진공, 물걸레, 진공·물걸레 복합형, 바닥 스크러버 명세의 데이터 모델을 직접 적용
창문 청소 가정용 창문, 고층 외벽(파사드), 천창 공통 계층 + 확장 필드
살균·소독 UV-C 소독, 화학 분무(포깅), 스팀 청소 공통 계층 + 확장 필드
수영장 관리 수영장 진공, 스크러버, 스키머 로봇 공통 계층 + 확장 필드
특수 시스템 에스컬레이터 청소, 태양광 패널 청소, 덕트 청소 공통 계층 + 확장 필드

제외 범위

이 표준은 수동 청소 장비(전자식이라 하더라도), 고정식 청소 인프라(세차 시스템 등), 사람이 계속 조작해야 하는 비자율 청소 기기를 다루지 않는다. 이러한 시스템은 다른 표준이나 기존 업계 규격의 적용을 받는다.

3.3 4단계 구현 아키텍처

WIA-ROB-011은 WIA 표준에 공통된 4단계 구조를 따른다. 각 단계는 별도의 명세 문서(PHASE-1~PHASE-4, 모두 v1.0.0)로 정의되며, 앞 단계를 기반으로 다음 단계가 쌓이는 방식이므로 점진적으로 도입할 수 있다. 각 단계의 상세 내용은 제4장부터 제7장에서 차례로 다룬다.

1단계: 데이터 형식 (제4장)

선행 조건: 없음
복잡도: 낮음
가치: 데이터 이동성, 벤더 독립성

1단계는 청소 로봇 데이터를 JSON-LD 형식으로 표현하는 규칙을 정한다. 로봇 식별 정보(CleaningRobot), 로봇 상태(RobotState), 지도(OccupancyGrid), 청소 세션 기록(CleaningSession), LiDAR·카메라 센서 데이터, 이벤트, 명령이 그 대상이다. 모든 시각은 시간대를 포함한 ISO 8601 형식, 모든 측정값은 SI 단위를 사용해야 한다. 어떤 시스템이든 이 형식을 내보내고 가져올 수 있으므로 다음이 가능해진다.

2단계: API 인터페이스 (제5장)

선행 조건: 1단계
복잡도: 중간
가치: 프로그래밍 방식 제어, 통합 유연성

2단계는 로봇 제어와 모니터링을 위한 RESTful HTTP API(기본 경로 /api/v1)와 WebSocket 인터페이스를 정의한다. 모든 엔드포인트는 인증과 요청 속도 제한(rate limiting)을 구현해야 한다. 표준화된 엔드포인트, 요청/응답 형식, 오류 처리를 통해 다음이 가능해진다.

3단계: 통신 프로토콜 (제6장)

선행 조건: 2단계
복잡도: 높음
가치: 보안 통신, 자동 탐색, 안전한 펌웨어 관리

3단계는 네트워크 프로토콜, 보안 요구 사항, 기기 탐색, 펌웨어 업데이트 방식을 정의한다. 주요 내용은 다음과 같다.

4단계: 시스템 통합 (제7장)

선행 조건: 3단계
복잡도: 매우 높음
가치: 생태계 상호운용성, 로봇군 운영

4단계는 청소 로봇을 더 넓은 생태계에 연결한다. 명세가 다루는 통합 대상은 스마트 홈 플랫폼(Amazon Alexa, Google Assistant, Apple HomeKit, Samsung SmartThings), 로봇군 관리(다중 로봇 협조, 구역 할당, 부하 분산), 클라우드 IoT 서비스(AWS IoT Core, Azure IoT Hub 등), 서드파티 자동화 도구(IFTTT, Zapier, Home Assistant)다. 이를 통해 다음과 같은 시나리오가 가능해진다.

3.4 기술 아키텍처 개요

┌──────────────────────────────────────────────────────────┐
│                 WIA-ROB-011 Architecture                 │
├──────────────────────────────────────────────────────────┤
│                                                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐    │
│  │  Smart Home  │  │   Building   │  │  Enterprise  │    │
│  │   Platform   │  │  Management  │  │   Systems    │    │
│  └──────┬───────┘  └──────┬───────┘  └──────┬───────┘    │
│         └─────────────────┼─────────────────┘            │
│                           │                              │
│  ┌────────────────────────┴───────────────────────────┐  │
│  │              WIA-ROB-011 API Layer                 │  │
│  │          (RESTful HTTP, WebSocket, MQTT)           │  │
│  └────────────────────────┬───────────────────────────┘  │
│                           │                              │
│  ┌────────────────────────┴───────────────────────────┐  │
│  │        Standardized Data Formats (JSON-LD)         │  │
│  │    State | Maps | Session Logs | Sensors | Events  │  │
│  └────────────────────────┬───────────────────────────┘  │
│                           │                              │
│  ┌────────────────────────┴───────────────────────────┐  │
│  │              Robot Abstraction Layer               │  │
│  │        (Manufacturer-Specific Translation)         │  │
│  └────────────────────────┬───────────────────────────┘  │
│                           │                              │
│  ┌───────┬───────┬────────┴┬─────────┬───────┬───────┐   │
│  │Vacuum │  Mop  │ Floor   │ Window  │  UV   │ Pool  │   │
│  │Robot  │ Robot │Scrubber │ Cleaner │ Robot │Cleaner│   │
│  └───────┴───────┴─────────┴─────────┴───────┴───────┘   │
│                                                          │
└──────────────────────────────────────────────────────────┘

위 그림의 계층을 위에서 아래로 살펴보면 다음과 같다. 최상위의 스마트 홈 플랫폼, 빌딩 관리 시스템, 기업 시스템은 모두 WIA-ROB-011 API 계층(RESTful HTTP, WebSocket, MQTT)을 통해 로봇에 접근한다. 그 아래에 표준화된 데이터 형식(JSON-LD: 상태·지도·청소 세션 기록·센서·이벤트)이 놓이고, 로봇 추상화 계층(제조사별 변환)이 이를 각 기기에 맞게 옮긴다. 최하단에는 진공 로봇, 물걸레 로봇, 바닥 스크러버, 창문 청소기, UV 로봇, 수영장 청소기 등 실제 기기가 위치한다.

3.5 설계 원칙

원칙 1: 완벽함보다 단순함

이 표준은 예외 상황을 빠짐없이 다루는 것보다 구현의 용이성을 우선한다. 널리 채택되는 실용적인 해법이 거의 채택되지 않는 완벽한 해법보다 더 큰 가치를 만든다는 판단이다. 1단계 데이터 형식처럼 기반이 되는 부분은 기존 제품에도 비교적 적은 부담으로 적용할 수 있도록 설계되었다.

원칙 2: 하위 호환성

모든 데이터에는 @version과 schemaVersion 같은 버전 정보가 포함된다. 부 버전(minor) 사이에서는 하위 호환성을 유지해야 하고, 주 버전(major)이 바뀔 때에는 마이그레이션 도구 제공과 호환성을 깨는 변경 사항의 문서화가 요구된다. 명세의 규범 조항에 호환성을 깨는 변경이 생기면 주 버전을 올려야 하며, WIA가 공개한 참조 구현에서는 이전 주 버전과 최소 90일간 병행 지원해야 한다.

원칙 3: 확장 필드를 통한 확장성

구현체는 x_ 접두사를 붙인 사용자 정의 필드(예: x_customField)를 추가할 수 있다. 접두사 규칙 덕분에 제조사 고유 정보가 향후 표준에 추가될 필드와 충돌하지 않는다. 서드파티 도구는 알 수 없는 확장 필드를 무시하고, 제조사 전용 도구는 이를 활용해 고급 기능을 제공한다.

원칙 4: 기본값으로서의 보안과 개인정보 보호

모든 API 엔드포인트는 인증을 구현해야 하며, 네트워크 통신에는 TLS 1.3 이상과 인증서 검증이 요구된다. 저장 데이터 역시 암호화 대상이다. 지도와 카메라 이미지처럼 개인정보에 민감한 데이터는 접근 제어가 필요하며, 보안 관련 세부 사항은 제6장과 제8장에서 다룬다.

원칙 5: 오픈소스 참조 구현

WIA는 WIA-Official GitHub 조직 아래에 참조 구현을 공개한다. TypeScript SDK 골격, 요청/응답 계약을 보여 주는 POSIX 셸 클라이언트, 브라우저 기반 시뮬레이터가 여기에 포함된다. 명세 문서는 MIT 라이선스로 공개되어 있으며, 특정 라이브러리 사용을 강제하지 않는다.

3.6 외부 표준 및 생태계와의 관계

WIA-ROB-011은 이미 공개된 국제 표준을 재사용하거나 규범적으로 참조한다. 명세 부속서(Annex B)가 열거하는 표준은 다음과 같다. 이 대응표는 참고용이며, WIA 요구 사항과 충돌할 경우 구속력 있는 국가 규제가 달리 정하지 않는 한 더 구체적인 WIA 요구 사항이 우선한다.

참조 표준 내용 WIA-ROB-011에서의 역할
ISO/IEC 17065:2012 제품·프로세스·서비스 인증기관 요구 사항 최고 적합성 등급(Tier 3)의 적합성 평가
ISO/IEC 27001:2022 정보보호 관리체계 보안 관리 기준
IETF RFC 9457 HTTP API 문제 세부 정보(Problem Details) API 오류 응답 형식
IETF RFC 7519 JSON Web Token(JWT) 권장 인증 토큰
IETF RFC 6749 OAuth 2.0 인가 프레임워크 서드파티 접근 인가
W3C PROV-DM 출처(provenance) 데이터 모델 데이터 출처 기록

생태계 측면에서는 3단계와 4단계 명세가 Matter/Thread, Apple HomeKit, Amazon Alexa, Google Home 등 주요 스마트 홈 플랫폼과 AWS IoT Core, Azure IoT Hub 같은 클라우드 IoT 서비스와의 연동 방식을 규정한다. 구체적인 연동 방법은 제7장에서 다룬다.

3.7 준수 수준과 적합성 등급

이 책은 제조사가 어느 단계까지 구현했는지를 기준으로 세 가지 준수 수준(기본·표준·고급)을 구분한다(제1장 참조). 이와 별도로 명세는 적합성을 누가 어떻게 검증했는지에 따라 세 가지 적합성 등급(Tier)을 정의한다. 두 축은 서로 독립적이므로, 예컨대 고급 수준의 구현이라도 자체 선언(Tier 1)에 머무를 수 있다.

기본 수준: 데이터 형식 준수

요구 사항:

대상: 보급형 제품, 기존 제품의 단계적 지원
이점: 데이터 이동성, 백업/복원, 분석 통합

표준 수준: API 인터페이스 준수

요구 사항:

대상: 중급형 제품, 스마트 홈 통합
이점: 서드파티 앱 제어, 스마트 홈 호환성

고급 수준: 전체 프로토콜 및 통합 준수

요구 사항:

대상: 프리미엄·상업용 제품, 로봇군 운영자
이점: 생태계 통합, 다중 로봇 운영, 기업 관리

명세의 적합성 등급(Tier)

등급 적용 범위 필수 산출물 감사 주기
Tier 1 — 자체 선언 내부 사용, 시범 배치 OpenAPI 3.0 계약, JSON Schema 검증 보고서, 보안 위협 모델 연 1회 자체 검토
Tier 2 — 제3자 평가 외부 파트너, B2B 통합 Tier 1 산출물 + 서명된 제3자 평가 보고서 24개월마다
Tier 3 — 공인 대외 공개 또는 규제 대상 배치 Tier 2 산출물 + WIA 공인, ISO/IEC 17065:2012 적합성 평가, 증거 7년 이상 보존 12개월마다

구현체는 자신의 적합성 등급을 OpenAPI의 info.x-wia-tier 확장 필드와 공개 인증 페이지에 밝혀야 하며, 등급이 하향되면 30일 이내에 WIA 레지스트리에 보고해야 한다. Tier 2 이상을 주장하는 구현체는 공개된 테스트 벡터를 요청 직렬화와 응답 역직렬화 양방향 모두 통과해야 한다.

3.8 인증 절차

4단계 명세는 인증 절차를 다음 다섯 단계로 정의한다. 실무 준비 사항과 체크리스트는 제8장에서 자세히 다룬다.

1단계: 신청서 제출

제조사는 대상 제품과 구현 범위를 밝혀 인증을 신청한다.

2단계: 자동화 테스트 (2~3일)

API 엔드포인트 적합성, 데이터 형식 유효성, 성능 벤치마크 등을 자동화된 테스트로 검증한다.

3단계: 수동 검토 (1주)

보안 감사를 포함해 자동화 테스트로 확인하기 어려운 항목을 검토한다.

4단계: 통합 테스트 (1주)

다른 시스템과의 상호운용성을 시험한다.

5단계: 인증 부여

모든 과정을 통과하면 인증이 부여된다. 인증 제품은 이후에도 연 1회 보안 감사를 받아야 한다.

3.9 오픈소스 생태계

WIA-ROB-011의 명세 문서와 참조 구현, 시뮬레이터는 WIA-Official GitHub 조직의 공개 저장소에서 제공된다. 4단계 명세는 공식 SDK 언어로 TypeScript, Python, Java, C#, Go, Rust를 제시하고 패키지 이름을 wia-rob-011로 정한다. 그러나 이 책을 쓰는 시점에 이 이름의 패키지는 npm이나 PyPI 같은 공개 패키지 저장소에 배포되어 있지 않다. 현재 이용할 수 있는 것은 공개 저장소의 cleaning-robot/api/typescript 디렉터리에 있는 TypeScript SDK 골격(모듈 이름 wia-rob-011, 주 클래스 WiaCleaningRobot)이며, 이는 운영 수준의 구현이 아니라 출발점으로 삼기 위한 참조 자료다.

SDK 받기

# 공개 저장소에서 참조 SDK 골격 받기
git clone https://github.com/WIA-Official/wia-standards-public.git
cd wia-standards-public/cleaning-robot/api/typescript

# 명세(PHASE-4 7.2절)가 제시하는 패키지 이름
# 이 책을 쓰는 시점에는 아직 배포되지 않았다
#   npm install wia-rob-011
#   pip install wia-rob-011

커뮤니티 참여

명세에 대한 의견과 제안은 WIA-Official 조직의 GitHub 이슈 트래커로 받는다. 명세의 각 부분은 안정성에 따라 세 부류로 관리된다. MUST/MUST NOT으로 표기된 규범 조항은 안정(Stable) 부류로 유의적 버전 규칙을 따르고, 부속서의 미해결 과제는 잠정(Provisional) 부류로 공개 논의를 거쳐 규범으로 승격될 수 있다. 테스트 벡터, 시뮬레이터, 참조 SDK는 참조(Reference) 부류로, 명세 문서와 독립적으로 버전이 관리된다.

3.10 개방형 표준으로서의 이용 조건

WIA-ROB-011 명세는 MIT 라이선스로 공개되어 있어, 어떤 제조사든 라이선스 비용이나 로열티 없이 명세를 읽고 구현할 수 있다. 명세의 구현과 공식 인증 취득은 별개의 문제로, 인증을 받으려면 3.8절의 절차를 거쳐야 한다. 이러한 개방성은 도입 장벽을 낮추고, 여러 제조사와 개발자가 같은 기반 위에서 경쟁하고 협업하도록 돕는다.

핵심 요약

복습 문제

  1. WIA-ROB-011 표준의 주된 사명은 무엇인가?
  2. 네 가지 구현 단계의 차이를 설명하라.
  3. WIA-ROB-011은 바닥 청소 로봇 이외의 로봇 유형을 어떻게 수용하며, 제외되는 기기는 무엇인가?
  4. 세 가지 준수 수준과 세 가지 적합성 등급(Tier)은 각각 무엇을 기준으로 구분되는가?
  5. 이 표준은 왜 예외 상황을 빠짐없이 다루는 것보다 단순함을 우선하는가?
  6. x_ 확장 필드는 표준화와 제조사 혁신 사이의 균형을 어떻게 맞추는가?
  7. 주 버전과 부 버전 변경 시 하위 호환성 요구 사항은 어떻게 다른가?
  8. 5단계 인증 절차를 설명하라.
  9. WIA-ROB-011이 참조하는 국제 표준을 세 가지 이상 들고 각각의 역할을 설명하라.
  10. 명세를 MIT 라이선스로 공개하는 것은 도입에 어떤 영향을 주는가?

📐 시뮬레이터 패널 2