개념
이 영역의 표준은 대부분 "데이터 모델"이다
SOC 디지털화 맵의 스마트시티·스마트공장·스마트팜·디지털트윈 항목을 늘어놓으면 또 하나의 패턴이 보인다.
스마트시티 데이터 모델 표준
3차원 도시공간객체 모델 및 공유 인터페이스 표준
스마트시티 데이터 플랫폼 시험 표준
도시 인프라 모니터링을 위한 센서 관리 시스템 표준
선박 내 장비 데이터 모델링 표준
농축수산 유통물류 데이터 공유 표준
빅데이터 기반의 시설원예 데이터 수집·제공 서비스 표준
주택 전력 에너지 사용량(AMI) 빅데이터 및 정보 모델 표준
스마트가전 에너지 관리 시스템 상호운용성 참조모델 표준
물리객체 및 가상객체 간 상태 동기화 기술 표준
디지털 트윈 연합 식별체계 및 관리 표준데이터 모델, 정보 모델, 참조 모델, 식별체계, 데이터 공유. 레슨 3의 IoT가 "연결"이 문제였다면, 이 영역은 "연결된 다음에 그 데이터를 같은 뜻으로 읽는가" 가 문제다.
그리고 이건 QA가 가장 잘하는 일이다. 데이터 모델 검증은 결국 경계값, 널 처리, 단위, 시간대, 식별자 충돌 의 문제이고, 전부 모듈 3에서 배운 기법이 그대로 적용된다.
스마트시티 데이터 플랫폼 시험 표준이라는 항목
맵에 이런 이름의 항목이 있다는 것에 주목한다. 표준화 항목 자체가 "시험 방법을 표준화하자"는 것 이다. 레슨 4에서 말했듯 이런 항목은 테스터에게 가장 값진 신호다.
스마트시티 데이터 플랫폼의 시험 항목을 설계한다면 무엇이 들어가야 할까. 항목명에서 출발해 다음처럼 전개할 수 있다.
[스마트시티 데이터 플랫폼 시험 영역]
① 수집 다양한 소스(센서·행정 데이터·민간 API)가 붙는가
소스 장애 시 나머지가 계속 도는가
② 정규화 서로 다른 단위·좌표계·시간대가 하나로 맞춰지는가
③ 저장 대용량·고빈도 데이터의 적재 성능, 보존 정책
④ 제공 API 응답 형식·성능, 대량 조회 시 동작
⑤ 품질 결측·이상값·중복을 탐지하고 표시하는가
⑥ 보안 접근 제어, 개인정보 비식별, 감사 로그
⑦ 개방 표준 형식(공간정보 표준 등)으로 내보낼 수 있는가⑤가 이 영역 고유의 시험 영역이다. 일반 웹 서비스에서 데이터 품질은 보통 별도 관심사지만, 도시 데이터 플랫폼에서는 데이터 품질이 곧 제품 품질 이다.
공간 데이터의 함정 — 여기서 가장 많이 깨진다
3차원 도시공간객체, 정밀도로지도, 선박 3D 모델, 디지털 트윈 — 이 영역의 상당수가 공간 데이터를 다루고, 관련 국제 규격으로 ISO 19107 (공간 스키마), ISO 19136(GML), ISO 19142(웹 피처 서비스), ISO 37156 (도시 인프라 데이터 교환) 같은 문서가 붙는다.
공간 데이터에서 QA가 반드시 확인할 항목이 있다.
- 좌표계(CRS) — EPSG 코드가 데이터에 명시돼 있는가. 시스템 간 변환이 일어나는 지점이 어디인가
- 측지계 불일치 — 국내 데이터는 특히 여러 측지계가 섞인다. 수 미터 오차가 조용히 생긴다
- 축 순서 — 위도·경도인가 경도·위도인가. 규격마다 다르고, 뒤바뀌면 엉뚱한 대륙으로 간다
- 고도 기준 — 타원체고인가 해발고인가
- 경계 넘김 — 경도 180도, 극지방, 시·도 경계 걸침
- 정밀도 손실 — 좌표를 문자열이나 float32로 다루는 구간이 있는가
- 폴리곤 유효성 — 자기 교차, 열린 링, 구멍(hole) 방향
축 순서 문제는 실무에서 놀랄 만큼 자주 터진다. 두 시스템을 붙였는데 지도에 아무것도 안 보이면 제일 먼저 의심할 것이 이것이다.
디지털 트윈 — ISO 23247과 "동기화"의 검증
제조 분야 디지털 트윈의 국제 규격은 ISO 23247 시리즈다.
| 파트 | 내용 |
|---|---|
| ISO 23247-1 | 개요와 일반 원칙 |
| ISO 23247-2 | 참조 아키텍처 |
| ISO 23247-3 | 제조 요소의 디지털 표현 |
| ISO 23247-4 | 정보 교환 |
맵에는 여기에 더해 디지털 트윈 성숙도 모델 표준, 디지털 트윈 연합 기술 요구사항 표준, 디지털 트윈 연합 식별체계 및 관리 표준,
디지털 트윈 동기화 기능 요구사항 및 유스케이스 시나리오 표준,
물리객체 및 가상객체 간 상태 동기화 기술 표준, 디지털 쓰레드 프레임워크 표준이 올라와 있다. 국제적으로는 ISO/IEC TR 30172(디지털 트윈 유스케이스)
같은 문서도 나와 있다.
항목 여섯 개 중 두 개가 동기화다. 이게 디지털 트윈 검증의 핵심이
어디인지 알려준다.
동기화를 어떻게 시험하는가
"디지털 트윈이 실물과 동기화된다"는 문장은 그대로는 시험할 수 없다. 세 가지 축으로 분해해야 한다.
축 1 — 지연(latency)
실물이 바뀐 뒤 트윈에 반영되기까지 몇 초인가
시험: 실물 상태를 알려진 시각에 바꾸고, 트윈 반영 시각을 기록
판정: 요구 지연 이내인가 (용도별로 다르다. 모니터링 10초 vs 제어 100ms)
축 2 — 정확도(fidelity)
반영된 값이 실물과 얼마나 같은가
시험: 동시 측정 후 차이 분포를 본다
판정: 허용 오차 이내인가. 편향(bias)이 있는가
축 3 — 일관성(consistency)
여러 트윈·여러 뷰가 서로 모순되지 않는가
시험: 동일 시점에 여러 경로로 같은 값을 조회해 비교
판정: 불일치가 있는가. 있다면 수렴하는가그리고 가장 중요한 네 번째 질문 이 있다.
축 4 — 단절과 복구
연결이 끊긴 동안 트윈은 무엇을 보여주는가?
(가) 마지막 값을 계속 보여준다 ← 위험. 사용자가 현재값으로 오인
(나) "데이터 없음"으로 표시한다 ← 안전
(다) 마지막 값 + 갱신 시각을 표시한다 ← 최선
레슨 5의 '없음과 모름' 문제가 여기서도 그대로 나온다.디지털 트윈 데모에서 (가)로 구현된 경우가 매우 많다. 화면이 깔끔해 보이기 때문이다. QA가 반드시 지적해야 할 결함 이다.
스마트공장 — 시험 환경이 최대 제약이다
맵의 스마트공장 항목들은 5G를 적용한 스마트공장 표준,
사설 5G 기반 스마트공장 보안기술 표준, 스마트공장을 위한 IoT 아키텍처 표준, 스마트공장을 위한 On-Site 엣지 표준, 스마트공장 KPI 분석 표준,
CPPS 기반 디지털 제조 플랫폼 표준, AI 기반 스마트공장 요구사항 표준
등이다. 국제 규격으로는 IEC 62264 시리즈(기업-제어 시스템 통합),
IEEE 802.1 TSN(시간 민감 네트워킹)이 연결된다.
스마트공장 QA의 최대 제약은 기술이 아니라 라인을 세울 수 없다는 사실이다. 생산 라인은 멈추면 돈이 나간다. 그래서 검증 전략 자체가 달라진다.
| 제약 | 대응 |
|---|---|
| 운영 중인 라인에서 시험 불가 | 미러 환경·시뮬레이터·야간 정지 시간 활용 |
| 장비 제조사가 제각각 | 인터페이스 어댑터 계층에서 경계 시험 |
| 실패가 물리적 손상으로 이어짐 | 안전 인터록이 소프트웨어보다 우선하는 구조 확인 |
| 레거시 설비 혼재 | 프로토콜 변환 구간의 손실·지연 측정 |
그래서 스마트공장에서는 "운영 환경에서 안전하게 관찰하는 능력" 이 시험 능력만큼 중요하다. 섀도 모드(실제 제어는 하지 않고 판단만 기록), 카나리아 라인(한 개 라인에만 먼저 적용), 롤백 시간 측정 같은 기법이 쓰인다.
스마트공장 KPI 분석 표준 항목은 흥미로운 검증 대상이다. KPI 계산 자체가
검증 대상이 된다 — 같은 원데이터로 계산한 OEE가 시스템마다 다르게
나오는 일 이 실제로 벌어진다. 계산 정의(가동 시간에 계획 정지를 포함하는가
등)를 문서로 고정하고, 경계 사례로 검산하는 것이 QA의 일이다.
스마트팜·농축수산 — 데이터 품질과 이력 추적
맵의 농축수산 항목은 두 갈래다.
환경 관리 계열 — IoT 기반의 시설원예 환경 관리 표준,
IoT 기반의 스마트축사 환경 관리 표준, IoT 기반의 양식 환경 관리 표준,
스마트팜 실외(과수, 밭작물 등) 로봇 운용 표준
데이터 계열 — 빅데이터 기반의 시설원예·노지과수·스마트축사·수산양식 데이터 수집·제공 서비스 표준, 농축수산 유통물류 데이터 공유 표준,
농축수산 이력 데이터, 추적, 위조방지(블록체인) 표준
환경 관리 계열에서 QA가 놓치기 쉬운 것은 센서 신뢰성 자체가 시험 대상 이라는 점이다. 온실 온도 센서가 고장 나서 항상 25도를 보고하면, 소프트웨어는 완벽하게 동작하면서도 작물을 죽인다.
[센서 신뢰성 검증 항목]
- 고착(stuck) 탐지 — 값이 N분간 전혀 변하지 않으면 의심하는가
- 범위 이탈 — 물리적으로 불가능한 값(영하 50도)을 걸러내는가
- 급변 — 1초 만에 20도가 오르면 이상으로 표시하는가
- 상호 검증 — 인접 센서 간 값이 크게 다르면 경고하는가
- 교정 이력 — 마지막 교정 시점이 관리되는가이력 추적 계열은 블록체인(레슨 4)과 만난다. 여기서의 핵심 질문은 "체인에 기록된 것이 진실인가" 다. 블록체인은 기록의 변조를 막지만, 애초에 거짓된 정보가 입력되는 것은 막지 못한다. 이 구분을 명확히 하지 않은 이력 추적 시스템의 보안 주장은 과장이다. QA는 입력 지점의 검증(누가, 어떤 권한으로, 어떤 근거로 기록하는가)을 함께 봐야 한다.
에너지 — 참조 모델 상호운용성
스마트가전 에너지 관리 시스템 상호운용성 참조모델 표준,
주택 전력 에너지 사용량(AMI) 빅데이터 및 정보 모델 표준,
에너지 저장 장치(ESS) 안전 기술 표준이 맵의 에너지 항목이고,
국제 규격으로 IEC 61970-301(CIM 공통 정보 모델), IEC 61968-1(배전 관리
시스템 인터페이스)이 연결된다.
에너지 영역 검증에서 특징적인 것은 시간 정렬 이다. 전력 데이터는 15분 단위, 1시간 단위처럼 구간으로 집계되는데, 구간 경계 처리(시작 포함인가 끝 포함인가)와 서머타임·윤초 처리에서 값이 어긋난다. 연간 정산에서 이 오차가 드러나면 이미 늦다.
구간 경계, 시간대 전환, 결측 구간 보간 규칙 — 이 셋은 에너지 데이터 시험의 필수 항목이다.
사례 — 트윈은 녹색이었고 설비는 멈춰 있었다
중견 부품 공장의 디지털 트윈 도입 사례다. 설비 42대 를 1초 주기로 수집해 대시보드를 5초마다 갱신하는 구성이었다.
야간에 게이트웨이 한 대의 회선이 끊겼다. 그 게이트웨이에 붙은 설비
11대 의 값이 마지막 수신값에 고정됐고, 대시보드는 계속 녹색
가동 중 을 보여 줬다. 실제로는 그중 3대가 정지 해 있었다.
단절은 약 3시간 이어졌고, 그 사이 생산 계획이 트윈 수치로 재산출됐다.
다음 날 아침 실적과 계획이 어긋난 뒤에야 문제가 드러났다.
원인은 소프트웨어 버그가 아니었다.
| 원인 | 내용 |
|---|---|
| 수집 실패와 무변화를 같은 칸에 저장 | "값이 안 왔다" 와 "값이 안 바뀌었다" 가 구분되지 않았다 |
| 화면에 수신 시각이 없었다 | 운영자는 보이는 값을 현재값으로 읽었다 |
| 알림이 이상값만 봤다 | "데이터가 오지 않는다" 를 잡는 규칙이 없었다 |
바꾼 것은 세 가지다.
- 모든 측정값에 수신 시각과 출처 게이트웨이 를 함께 저장
- 마지막 수신이 수집 주기의 3배 를 넘기면 녹색 대신 회색
데이터 없음 - 무음 감시(watchdog) 경보 추가 — 정해진 시간 동안 데이터가 안 오면 알림
그 뒤 같은 유형의 단절이 두 번 더 났지만 둘 다 10분 안에 감지됐고, 실적·계획 불일치는 재발하지 않았다.
- 트윈의 전형적 결함은 "틀린 값" 이 아니라 "낡은 값을 현재값처럼 보여 주는 것" 이다
- 수집 실패와 상태 무변화를 같은 칸에 넣으면, 그 뒤 어떤 검증도 둘을 구분할 수 없다
- 이상값 탐지만 있는 모니터링에는 "오지 않는 데이터" 를 잡는 규칙이 비어 있다
운영을 멈출 수 없는 곳의 검증 — 권한을 계단으로 나눈다
제조 라인과 도시 인프라에는 "테스트 환경" 이 없는 경우가 많다. 똑같은 설비를 한 벌 더 사 둘 수 없고, 가동을 멈추면 돈이 나간다. 이때 쓰는 방법은 환경을 복제하는 것이 아니라 시스템에 주는 권한을 단계로 나누는 것 이다.
| 단계 | 주는 권한 | 여기서 검증되는 것 | 다음 단계로 가는 조건 |
|---|---|---|---|
| ① 읽기 전용 관찰 | 조회만 | 데이터 정합성·지연·표시 규칙 | 일정 기간 오경보 없이 통과 |
| ② 섀도우 판단 | 제어값을 계산하되 보내지 않고 기록 | 판단 로직이 기존 운영과 일치하는가 | 불일치 건을 전수 설명 가능 |
| ③ 제한 구역 적용 | 라인 1개·설비 1대에만 실제 제어 | 실제 영향과 롤백 소요 시간 | 롤백 시간을 측정해 문서화 |
| ④ 전면 적용 | 전체 | — | ①~③ 기록 제출 |
②가 이 계단의 핵심이다. 판단만 기록하면 틀려도 아무 일이 일어나지 않으면서 틀렸다는 사실은 남는다. 자동화 도입 검증에서 가장 비용 대비 효과가 큰 구간이다.
③에서 롤백 시간을 재지 않고 ④로 올라가는 것이 이 영역의 대표적 사고 경로다. 되돌릴 수 있는 상태를 유지하지 못하는 단계는 통과가 아니다.
레거시 설비 — 규격을 "부분만" 지키는 장비
한 공장 안에 OPC UA(IEC 62541 시리즈)처럼 최근 규격을 따르는 설비와, 훨씬 오래된 직렬 기반 프로토콜을 쓰는 설비가 함께 돌아간다. 실무에서 발목을 잡는 것은 규격 버전 차이가 아니라 부분 구현 이다.
[부분 구현이 드러나는 지점]
① 선택(optional) 기능 미구현 — 규격상 위반은 아니지만 연동은 실패한다
② 데이터 폭 불일치 — 32비트 값을 16비트 레지스터 둘로 쪼개 보내고,
그 바이트 순서가 제조사마다 다르다
③ 오류 코드 미사용 — 실패해도 정상 응답을 돌려준다
④ 시각 정보 없음 — 값만 오고 "언제의 값인가" 가 빠져 있다그래서 QA가 만들 산출물이 하나 늘어난다. 설비별 규격 준수 현황표 — 어떤 기능을 구현했고 어떤 기능이 비었는지, 그 구멍을 어댑터 계층이 어떻게 메우는지 적은 표다.
②와 ④가 특히 위험하다. 바이트 순서가 뒤바뀌거나 시각 보정이 어긋나도 값은 그럴듯하게 나온다. 눈에 띄는 오류 없이 수치만 틀리므로 가장 늦게 의심받는다. 어댑터 계층은 반드시 독립된 검증 대상으로 둬야 한다.
표준 준수 검증과 제품 동작 검증은 다른 일이다
이 영역에서 가장 자주 섞이는 두 가지다.
| 구분 | 묻는 것 | 근거 문서 | 실패하면 |
|---|---|---|---|
| 표준 준수 시험 | 규격의 요구를 만족하는가 | 규격 조항·규정된 시험 절차 | 인증·검수를 못 받는다 |
| 제품 동작 시험 | 현장에서 쓸 수 있는가 | 요구사항·운영 시나리오 | 사고와 불만이 난다 |
둘은 서로를 대체하지 못한다. 프로토콜 준수 시험을 통과한 설비가 현장의 1초 주기 폴링에서는 응답이 늦어 값을 떨구는 일이 있고, 반대로 현장에서 몇 년 잘 돌던 시스템이 규격의 필수 기능 미구현으로 검수에서 막히는 일도 있다.
"준수했으니 동작한다" 와 "동작하니 준수한다" 는 둘 다 틀렸다. 검증 계획서에서 두 줄을 나눠 쓰고, 각각의 근거 문서를 따로 적는 것이 이 영역 QA의 기본 자세다.
실무에서 왜 필요한가
실증 사업 검수의 대부분이 데이터 검증이다
스마트시티·스마트팜 실증 사업의 검수에서 실제로 문제가 되는 것은 화면이 예쁜가가 아니라 데이터가 맞는가 다. 좌표가 틀려서 센서가 엉뚱한 곳에 찍히거나, 단위가 안 맞아 값이 1000배 차이 나거나, 결측 구간을 0으로 채워 평균이 무너지는 일이 흔하다.
이 레슨의 체크리스트를 검수 전에 한 번 돌리는 것만으로 상당수가 걸린다.
디지털 트윈 과제에서 "동기화됨"을 증명해야 할 때
과제 성과지표에 "실시간 동기화"가 적혀 있다면, 평가에서 반드시 "얼마나 실시간인가"를 묻는다. 축 1~3(지연·정확도·일관성)의 측정값을 준비해두면 그 자리에서 답할 수 있다. 준비 안 되어 있으면 "실시간입니다"라는 말만 반복하게 된다.
제조·에너지 QA 채용의 실질 요건
이 영역 채용에서 요구하는 것은 프로그래밍보다 도메인 데이터를 의심할 줄 아는 능력 이다. OEE 계산식의 경계 사례를 짚고, 센서 고착을 탐지 항목으로 제안하고, 시간 구간 경계를 시험 케이스로 만드는 사람이 현장에서 즉시 쓰인다.
채용시장에서의 위치
이 영역의 채용은 도메인 데이터를 의심할 줄 아는 사람 을 찾는다. 도구 숙련도보다 "이 숫자를 왜 믿는가" 를 되묻는 습관이 변별력을 만든다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "디지털 트윈을 테스트해 보셨어요?" | "대시보드를 확인했습니다" | "동기화를 지연·정확도·일관성·단절 네 축으로 나눠 측정했습니다. 실제로 가장 많이 깨진 건 단절 시 표시 규칙이었습니다" |
| "멈출 수 없는 설비는 어떻게 검증하나요?" | "야간에 테스트합니다" | "읽기 전용 관찰 → 섀도우 판단 → 제한 구역 → 전면 순서로 올리고, 각 단계에서 롤백 시간을 먼저 측정합니다" |
| "센서 데이터를 믿을 수 있나요?" | "센서는 하드웨어 담당입니다" | "고착·범위 이탈·급변·인접 상호 검증·교정 이력을 탐지 항목으로 둡니다. 소프트웨어가 완벽해도 고착 센서는 작물을 죽입니다" |
| "같은 지표가 시스템마다 다르게 나옵니다" | "데이터를 다시 받아 보겠습니다" | "계산 정의부터 맞춥니다. 계획 정지 포함 여부·구간 경계 규칙·결측 처리, 이 셋이 거의 항상 원인입니다" |
| "규격 준수 시험만 통과하면 되나요?" | "통과하면 됩니다" | "준수와 동작은 다른 검증입니다. 준수 시험을 통과한 설비가 현장 폴링 주기에서 값을 떨구는 경우가 있습니다" |
두 번째가 가장 변별력이 크다. "야간에 테스트합니다" 가 틀린 답은 아니다. 다만 야간 정지 시간이 몇 시간인지, 그 안에 되돌릴 수 있는지를 재 본 적이 없다는 뜻으로 읽힌다. 승격 계단과 롤백 시간을 말하는 사람은 라인을 세운 비용을 아는 사람 으로 읽힌다. 이 차이는 경력 연수로 가려지지 않는다.
네 번째도 좋은 질문이다. 숫자가 다를 때 데이터를 의심하는 사람과 정의를 의심하는 사람 이 갈린다. 제조·에너지 영역에서 값 불일치의 원인은 수집 쪽보다 정의 쪽이 훨씬 많다. "어느 쪽이 맞느냐" 를 따지기 전에 "정의가 합의돼 있느냐" 를 묻는 것이 순서다.
공고에서는 "스마트팩토리", "MES/SCADA 연동", "디지털 트윈", "OPC UA", "산업용 프로토콜", "데이터 품질 검증", "공간정보·GIS", "AMI" 같은 표현으로 이 레슨의 내용이 걸린다.