개념
이 영역 표준화 항목의 공통 관심사는 "연동"이다
활용·개발 맵 03 초연결 신산업 육성의 사물인터넷·클라우드 영역
표준화 항목을 늘어놓으면 패턴이 보인다.
IoT 통신 표준
IoT 플랫폼과 이동통신망 연동 표준
IoT 플랫폼 코어 네트워크 연동 검증 표준
IoT 플랫폼 연동을 위한 브릿징 표준
IoT 서비스 융합 데이터 모델 표준
IoT 에지 컴퓨팅 모델 및 기능 정의 표준
IoT 저전력 네트워킹 표준
정보중심네트워킹(ICN) 기반의 IoT 통신 표준
기계학습 기반 IoT 네트워크 관리 표준
경량형 IoT 데이터 분석 기술 표준
군집지능 지원 지능형 IoT 디바이스 표준
IoT 데이터 유통 거래 플랫폼 표준
IoT 통합보안 프레임워크 표준
IoT 디바이스 보안설정 표준
IoT 서비스 접근성 가이드라인 표준
IoT 접근성 보조기기 인터페이스 표준절반 이상이 연동·브릿징·인터페이스·데이터 모델 이다. 이유는 분명하다. IoT의 핵심 문제가 기능이 아니라 서로 다른 제조사·플랫폼·망이 붙는가 에 있기 때문이다.
이 관찰이 테스터에게 주는 결론은 단순하다. IoT 영역에서는 적합성 시험보다 상호운용성 시험의 비중이 훨씬 크다. 레슨 2의 네 유형 중 ②에 무게를 싣고 계획을 짜야 한다.
검증 관점에서 본 IoT 계층
IoT 시스템을 시험할 때는 계층을 나눠 각 경계마다 무엇이 깨질 수 있는지 따로 잡아야 한다. 한 덩어리로 보면 "안 되는데 어디가 문제인지 모르겠다"에 빠진다.
[애플리케이션] 대시보드, 알림, 분석
│ ← 경계 A: 데이터 모델 불일치 (단위·타임존·널 처리)
[플랫폼 / 서비스 계층] oneM2M CSE 등. 등록·구독·리소스 관리
│ ← 경계 B: 플랫폼 간 브릿징 (리소스 ID 매핑, 구독 전파)
[게이트웨이 / 에지] 프로토콜 변환, 로컬 처리, 버퍼링
│ ← 경계 C: 단절 시 동작 (버퍼 한계, 재전송, 중복)
[디바이스 / 센서] 측정, 저전력 송신
│ ← 경계 D: 시각 동기, 펌웨어 버전 혼재
[네트워크] LPWAN, 셀룰러, 코어망
← 경계 E: 망 전환, 로밍, QoS경계 C가 실무에서 가장 많이 터진다. 네트워크가 끊겼다가 돌아올 때 에지가 버퍼에 쌓아둔 데이터를 어떻게 올리는가 — 순서대로? 한꺼번에? 중복 제거는? 이 시나리오를 테스트 계획에 넣지 않은 IoT 프로젝트는 거의 예외 없이 운영에서 사고가 난다.
IoT 플랫폼 코어 네트워크 연동 검증 표준 — 항목명이 곧 시험 설계다
이 항목은 이름 자체에 검증이 들어간다. 맵의 항목 중 이런 이름을 가진
것들은 테스터에게 특히 값지다. 표준 자체가 시험 절차를 규정하려는
시도 이기 때문이다.
이런 항목을 만나면 다음 순서로 접근한다.
- 그 항목의 관련 기구(oneM2M, 3GPP, ITU-T SG20 등)에서 시험 규격 (Test Specification) 문서가 있는지 찾는다. 통신 규격은 대개 기능 규격과 시험 규격이 짝으로 나온다
- 시험 규격이 있으면 그 안의 테스트 케이스 목록을 그대로 가져온다. 직접 설계할 필요가 없다
- 없으면 기능 규격의
shall에서 직접 만든다(레슨 2의 5단계)
oneM2M의 경우 TS-0001(기능 아키텍처), TS-0004(서비스 계층 프로토콜) 같은 기능 규격과 별도로 적합성·상호운용성 시험 규격이 존재한다. TTA의 oneM2M 인증이 바로 이 시험 규격을 기반으로 돌아간다.
에지 컴퓨팅 — 무엇을 재야 하는가
맵에는 IoT 에지 컴퓨팅 모델 및 기능 정의 표준, 에지 컴퓨팅 개념 및 요구사항 표준, 에지 클라우드 개념 및 기능 요구사항 표준,
에지 클라우드 관리 요구사항 표준이 따로따로 올라와 있다. 개념 정의부터
관리 요구사항까지 단계별로 표준화하려는 구조다.
에지를 검증할 때 중앙 클라우드와 다른 점이 세 가지다.
첫째, 지연시간이 기능 요구사항이다. 에지를 쓰는 이유 자체가 지연 단축이므로, "동작한다"가 아니라 "몇 ms 안에 동작한다"가 판정 기준이 된다. 성능 시험(레슨 2의 ③)이 필수로 들어간다.
둘째, 오프라인 자율성을 시험해야 한다. 중앙과 끊겨도 에지가 로컬에서 판단을 계속하는가. 끊긴 동안의 결정이 재연결 후 중앙의 상태와 충돌하면 어떻게 화해(reconciliation)하는가.
[오프라인 자율성 시험 시나리오 골격]
1. 정상 동작 확인
2. 중앙 연결 차단 (네트워크 레벨에서, 앱 종료가 아니라)
3. 차단 상태에서 로컬 판단이 계속되는지 확인
4. 차단 중 중앙에서 설정을 변경 (충돌 조건 생성)
5. 연결 복구
6. 최종 상태 확인 — 어느 쪽이 이겼는가? 그게 규칙대로인가?
7. 손실 데이터 확인 — 차단 중 발생한 이벤트가 모두 반영됐는가?셋째, 배포 형상이 제각각이다. 에지 노드는 수백 대가 서로 다른 하드웨어, 다른 펌웨어 버전으로 돌아간다. 버전 혼재 상태에서의 동작 이 시험 항목에 들어가야 한다. 전부 최신 버전인 실험실 환경에서만 검증하면 현장에서 반드시 깨진다.
멀티 클라우드 — 검증의 핵심은 이식성과 탈출 가능성
맵의 멀티 클라우드 개념 및 다중 클라우드 배치 모델 표준,
멀티 클라우드 기능 요구사항 표준, 분산 클라우드 기반 글로벌 관리 표준,
클라우드 서비스 브로커리지 참조구조 표준이 이 영역이다.
멀티 클라우드를 쓴다고 선언한 시스템에서 QA가 실제로 확인해야 할 것은 "두 클라우드에 다 배포됐는가"가 아니다.
| 확인할 것 | 시험 방법 |
|---|---|
| 워크로드 이식성 | 한쪽 CSP에서 다른 쪽으로 실제로 옮겨 띄워본다. 문서상 가능이 아니라 실행 |
| 데이터 이동 | 데이터를 내보내고 반대편에서 복원해 무결성을 검증한다 |
| 장애 격리 | 한쪽 리전을 죽였을 때 다른 쪽이 받는가. 받는 데 얼마나 걸리는가 |
| 관리 일관성 | 계정·권한·로깅·모니터링이 양쪽에서 같은 정책으로 적용되는가 |
| 종속성 목록 | 각 CSP 고유 서비스(관리형 DB, 메시징 등)에 얼마나 묶여 있는가 |
마지막 항목이 특히 중요하다. "멀티 클라우드"라고 부르지만 실제로는 한쪽 CSP의 관리형 서비스에 깊이 묶여 있어 옮길 수 없는 시스템 이 매우 흔하다. 종속성 목록을 만들어 제시하는 것만으로도 QA의 기여가 크다.
클라우드 보안·감사 — 통제 항목을 시험 항목으로
클라우드 서비스 보안 표준, 클라우드 인프라 보안 표준,
클라우드 서비스 감사 표준이 이 영역이다. ISO/IEC 27002 계열의 통제
항목이 바탕에 깔린다.
보안 표준의 검증은 일반 기능 시험과 성격이 다르다. 대부분이 "통제가 존재하는가"를 확인하는 문서·설정 검토 이고, 일부만 실제 공격 시도로 확인한다.
통제 항목 하나를 시험으로 옮기는 3단 확인
① 정책이 있는가 → 문서 검토
② 설정이 정책대로인가 → 설정 덤프 확인 (IaC 코드, 콘솔 스냅샷)
③ 실제로 막히는가 → 동작 시험 (권한 없는 계정으로 접근 시도)
③까지 해야 "검증했다"고 말할 수 있다.
①②만 하고 넘어가는 것이 감사 지적의 단골이다.IoT 보안 — 디바이스 기본 설정이 가장 큰 구멍
IoT 디바이스 보안설정 표준, IoT 통합보안 프레임워크 표준이 다루는
영역이다. IoT 보안 사고의 압도적 다수가 고급 취약점이 아니라
출고 기본값 에서 나온다.
QA가 반드시 확인할 목록:
- 출고 시 기본 계정·기본 비밀번호가 있는가. 있다면 최초 사용 시 강제 변경되는가
- 디버그 포트(UART, JTAG, telnet, 개발용 HTTP 엔드포인트)가 양산 펌웨어에 남아 있는가
- 펌웨어 업데이트가 서명 검증을 하는가. 서명이 틀린 펌웨어를 밀어 넣어봤는가
- 롤백 공격 — 구버전(취약점 있는) 펌웨어로 되돌릴 수 있는가
- 디바이스 간 인증서·키가 전 제품 공용인가, 개체별로 다른가
- 평문 전송 구간이 남아 있는가 (패킷 캡처로 직접 확인)
- 초기화(factory reset) 후 이전 사용자 데이터·자격증명이 남는가
마지막 항목은 중고 거래되는 IoT 기기에서 실제로 반복되는 사고다.
접근성 — 맵이 별도 항목으로 세운 이유
IoT 서비스 접근성 가이드라인 표준과 IoT 접근성 보조기기 인터페이스 표준이 맵에 따로 올라와 있고, 관련 국제 규격으로 ISO/IEC 13066 계열
(보조기술과 IT의 상호운용성)이 붙는다.
IoT 접근성은 웹 접근성과 다른 문제 라는 점을 알아야 한다. 웹은 화면과 스크린리더의 문제지만, IoT는 물리 기기다.
| 웹 접근성 | IoT 접근성 |
|---|---|
| 대체 텍스트, 키보드 탐색 | 물리 버튼의 촉각 구분, 음성 안내 |
| 색 대비 | 표시등 색상 + 형태·소리 동시 제공 |
| 스크린리더 호환 | 보조기기(스위치·점자 디스플레이)와의 인터페이스 |
| 타임아웃 연장 | 조작 시간 여유, 오조작 취소 |
시험 방법도 다르다. 화면 검사 도구로는 잡히지 않고, 실제 보조기기를 연결하거나 상황을 재현해 조작해보는 수밖에 없다. 눈을 감고 기기를 설정해보는 단순한 실험이 의외로 많은 것을 드러낸다.
기기 식별과 온보딩 — 첫 1분이 가장 취약하다
기기가 처음 네트워크에 붙는 순간이 보안과 검증 모두에서 가장 약한 구간 이다. 확인할 축이 셋이다.
| 축 | 질문 |
|---|---|
| 식별 | 기기를 무엇으로 구분하나. 시리얼·인증서·사용자 등록 |
| 중복 등록 | 같은 기기를 두 번 등록하면 어떻게 되나 |
| 소유권 이전 | 기기를 다른 사용자에게 넘기면 이전 데이터는 어떻게 되나 |
세 번째가 거의 항상 빠져 있다. 중고 거래·사무실 이전·담당자 변경이 실제로 일어나고, 초기화 절차가 없으면 이전 소유자의 데이터가 남거나 새 소유자가 접근하지 못한다. 개인정보가 걸리면 그 자체가 사고다 (모듈 26 레슨 4).
끊겼다 붙을 때 — 유실과 중복 중 무엇을 택했는가
에지·IoT에서 연결이 끊긴 상태는 고장이 아니라 정상 동작의 일부다. 그래서 검증의 중심 질문이 "끊기나" 가 아니라 "붙을 때 무엇이 일어나나" 가 된다.
| 재연결 시 설계 | 결과 | 적합한 데이터 |
|---|---|---|
| 끊긴 동안 버리고 최신만 | 유실 발생 | 현재 상태값(온도·위치) |
| 쌓아 두고 전부 전송 | 중복·순서 역전 가능 | 누적 계측·거래 기록 |
| 쌓아 두고 중복 제거 후 전송 | 가장 안전, 구현 비용 큼 | 과금·안전 관련 |
어느 쪽이 맞는지는 데이터 성격이 정한다. 그런데 실무에서 가장 흔한 문제는 틀린 선택이 아니라 선택이 문서에 없는 것이다. 개발은 버리고 있고 기획은 쌓인다고 믿는 상태가 몇 달간 발견되지 않는다.
QA가 할 일은 그 선택을 드러내는 것이다. 시험 시나리오는 단순하다.
① 알려진 값 N개를 보낼 상태로 만든다
② 통신을 끊는다 (기기 전원이 아니라 네트워크만)
③ 끊긴 동안 M개가 발생하도록 둔다
④ 다시 연결한다
⑤ 서버에 도달한 개수와 순서를 센다
판정: 도달 = M (전부) / 0 (전부 유실) / M보다 큼 (중복) / 순서 역전⑤에서 "M보다 큼" 이 나오는 경우가 의외로 많다. 재전송과 정상 전송이 겹치면 중복이 생기고, 서버가 중복 제거를 하지 않으면 누적 집계가 부풀려진다(모듈 26 레슨 5의 트래킹 문제와 같은 성질).
시각이 어긋나면 순서가 뒤바뀐다
IoT에서 조용히 사고를 만드는 축이 시각이다. 기기마다 시계가 다르면 서버에서 발생 순서가 뒤바뀐다.
| 어긋나는 원인 | 결과 |
|---|---|
| 기기 시계가 동기되지 않음 | 과거 시각으로 기록 |
| 시간대(타임존) 설정 차이 | 9시간 차이가 미래 데이터로 보인다 |
| 기기 시각 vs 서버 수신 시각 | 어느 쪽으로 정렬하나가 정의되지 않음 |
| 끊김 중 발생분의 시각 | 발생 시각인가 전송 시각인가 |
세 번째와 네 번째가 설계 결정 사항이고, 역시 문서에 없는 경우가 많다. 확인 질문 두 개로 충분하다 — "정렬은 어느 시각 기준인가", "기기 시각을 신뢰하나 서버가 덮어쓰나".
이것이 중요한 이유는 순서가 판정에 쓰이기 때문이다. "경고 뒤에 정상 복구" 와 "정상 복구 뒤에 경고" 는 완전히 다른 상황이고, 시각이 어긋나면 대시보드가 거짓을 보여 준다.
펌웨어 업데이트는 되돌릴 수 있어야 한다
IoT에서 가장 비싼 사고가 업데이트 실패다. 기기가 현장에 흩어져 있어 직접 가야 복구되는 경우가 생긴다. 확인할 축이 넷이다.
| 축 | 질문 |
|---|---|
| 중단 | 전송 중 전원·통신이 끊기면 이전 버전으로 돌아오나 |
| 롤백 | 새 버전이 불량이면 되돌릴 경로가 있나 |
| 부분 적용 | 일부 기기만 올라간 상태에서 서버와 호환되나 |
| 검증 | 서명·무결성 확인 없이 설치되지 않나 |
세 번째가 가장 많이 빠진다. 현장 기기가 한꺼번에 업데이트되지 않으므로 구버전과 신버전이 동시에 돌아가는 기간이 반드시 있고, 그 기간의 호환성이 시험되지 않으면 운영에서 드러난다. 모듈 4 레슨 6의 전환 검증과 같은 구조다.
사례 — 온도 데이터가 하루 비어 있었던 이유
현장 센서 200대에서 온도를 수집하는 시스템이었다. 월말 보고서를 뽑다가 특정 날짜의 데이터가 통째로 비어 있는 것을 발견했다. 기기는 정상이었고 통신 장애 기록도 없었다.
추적 결과 원인이 셋 겹쳐 있었다.
| 원인 | 내용 |
|---|---|
| 재연결 설계 | 끊긴 동안 데이터를 버리는 방식이었다(문서에 없었다) |
| 끊김 이유 | 그날 게이트웨이 펌웨어 업데이트가 돌았다(23분) |
| 보고서 집계 | 결측을 0으로 채우지 않고 건너뛰어 평균이 정상처럼 보였다 |
세 번째가 가장 위험했다. 데이터가 없는데 보고서는 정상으로 보였고, 그래서 한 달간 아무도 몰랐다. 결측이 눈에 보이지 않는 결함이었던 것이다 (모듈 26 레슨 5와 같은 성질).
바꾼 것은 셋이었다.
- 재연결 시 쌓아 두고 전송 + 서버 중복 제거로 설계 변경(데이터 성격이 누적 계측이므로)
- 보고서에 결측 개수와 비율을 함께 표시 — 비어 있으면 비어 있다고 보이게
- 시험 시나리오에 "펌웨어 업데이트 중 데이터 발생" 을 추가
2번이 비용이 가장 낮고 효과가 가장 컸다. 결측을 드러내기만 해도 같은 문제가 다음에는 하루 안에 발견된다.
교훈이 셋이다.
- "연결이 끊긴다" 는 정상 동작이므로 시험 시나리오에 들어가야 한다
- 재연결 시 유실·중복 중 무엇을 택했는지가 문서에 없으면 그것부터 쓴다
- 결측이 보이지 않는 집계가 가장 오래 숨는다 — 비어 있으면 비어 있다고 보이게 만든다
실무에서 왜 필요한가
실증 사업의 검수 기준이 여기서 나온다
스마트시티·스마트팩토리 실증 사업의 과업지시서에는 "oneM2M 기반 플랫폼 연동", "에지-클라우드 연계 구조 적용" 같은 문구가 흔하다. 검수 시점에 발주처가 묻는 것은 결국 두 가지다 — 다른 시스템과 붙는가, 그리고 그것을 무엇으로 증명하는가.
레슨 2에서 만든 추적성 매트릭스에 이 레슨의 계층별 경계(A~E)와 시험 항목을 채워 넣으면 그대로 검수 근거 문서가 된다.
장애 조사 시간이 줄어든다
계층과 경계를 나눠 시험해두면, 운영 중 장애가 났을 때 "어느 경계에서 깨졌는가"를 훨씬 빨리 좁힐 수 있다. 경계별로 정상 동작을 확인하는 스모크 시나리오를 미리 만들어두면 장애 대응 시간이 눈에 띄게 줄어든다.
탄소중립 지표가 새 검증 대상으로 들어온다
04 SOC 디지털화 맵에는 탄소중립 클라우드 데이터센터 설비 자원 효율 측정 및 평가 표준이 올라와 있다. 앞으로 클라우드·데이터센터 관련
과제에서 전력·자원 효율이 측정 대상 품질 특성 으로 들어온다는 뜻이다.
이건 QA에게 새로운 영역이다. 기능도 성능도 아닌, 같은 작업을 얼마나 적은 자원으로 했는가를 재는 시험이다. 측정 조건(부하 수준, 측정 구간, 기준 작업)을 정의하는 일이 핵심이고, 그건 전형적인 테스트 설계 작업이다.
채용시장에서의 위치
IoT·엣지 쪽 QA 공고는 수가 많지 않지만 경쟁자도 적다. 그리고 요구되는 감각이 웹 QA와 분명히 다르다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "IoT 테스트는 웹과 뭐가 다른가요?" | "기기가 있어서 복잡합니다" | "연결이 끊긴 상태가 정상 동작의 일부입니다. 붙을 때 유실·중복 중 무엇이 일어나는지를 봅니다" |
| "데이터가 비어 있으면 어떻게 찾으세요?" | "로그를 봅니다" | "결측 개수와 비율을 보고서에 드러냅니다. 안 보이는 결측이 가장 오래 숨습니다" |
| "시각 관련 문제를 겪어 보셨어요?" | "타임존 이슈가 있었습니다" | "정렬 기준이 기기 시각인지 서버 수신 시각인지를 먼저 확인합니다. 순서가 판정에 쓰이니까요" |
| "펌웨어 업데이트는 어떻게 검증하세요?" | "업데이트 후 동작을 봅니다" | "중단·롤백·부분 적용·서명 넷을 봅니다. 구버전과 신버전이 동시에 도는 기간이 반드시 있습니다" |
| "멀티 클라우드 검증은요?" | "양쪽에서 돌려 봅니다" | "이식성과 탈출 가능성을 봅니다. 특정 서비스에 묶인 지점을 목록으로 만듭니다" |
첫 번째와 네 번째가 가장 변별력이 크다. 둘 다 기기가 현장에 흩어져 있는 상황을 겪어 본 사람의 답이다. 특히 네 번째의 "구버전과 신버전이 동시에 도는 기간" 은 웹 QA에서는 잘 안 나오는 감각이다.
두 번째도 좋다. 없는 데이터를 찾는 일은 IoT·데이터 QA에서 반복되는 과제이고, 드러내는 장치를 만드는 쪽으로 답하면 문제를 구조로 보는 사람으로 읽힌다.
공고 표현으로는 "IoT 디바이스 테스트", "엣지·게이트웨이 검증", "펌웨어 QA", "클라우드 인프라 QA", "데이터 파이프라인 QA" 가 이 레슨에 걸린다.