개념
세 영역이 한 레슨에 묶인 이유
블록체인, 메타버스, 지능형 디바이스(로봇·반도체)는 기술적으로 서로 멀어 보인다. 그런데 테스터 입장에서는 같은 종류의 어려움 을 공유한다.
공통점 1 — 기존 테스트 기법이 잘 안 먹힌다
블록체인: 배포하면 못 고친다. "고쳐서 재배포"가 안 된다
메타버스: 사람이 어떻게 느끼는지가 합격 기준이다
로봇: 물리 세계에서 사람이 다칠 수 있다
공통점 2 — 그래서 표준화 항목에 '평가'와 '검증'이 유난히 많다
스마트 컨트랙트의 정형검증 표준
디지털 가상훈련 시스템 평가 표준
이동로봇의 밀집군중하 주행안전 평가 표준
기능성 게임의 성과 측정 및 평가 절차 표준두 번째 관찰이 핵심이다. 맵의 항목명에 평가·측정·검증이 들어간
영역은 곧 "시험 방법 자체가 아직 정립되지 않은 영역" 이다. 그리고 그런
영역이야말로 테스터가 기여할 여지가 가장 큰 곳이다.
블록체인 — 배포 전에 다 끝내야 하는 검증
표준화 항목이 가리키는 것
맵의 블록체인 영역 항목을 보면 두 갈래로 갈린다.
| 갈래 | 항목 예 |
|---|---|
| 거버넌스·신원·기록 | 블록체인 거버넌스 표준, DLT 기반 신원관리를 위한 신뢰 앵커 개요 표준, 공신력있는 기록·기록 시스템·기록 관리 관점에서의 블록체인과 DLT 표준, 데이터 공유 협약 프레임워크 표준 |
| 보안·검증 | 스마트 컨트랙트의 정형검증 표준, 블록체인 스마트 계약 관리를 위한 보안 요구사항 표준, 분산원장기술 보안통제 표준, 분산원장 기반 데이터 접근관리 보안 표준 |
국제 무대에서는 ISO/TC307(블록체인·분산원장기술)이 중심이다. 탈중앙 신원 식별(ISO/AWI 7663), 신뢰 앵커 개요(ISO/DTR 23644), 상호운용성 프레임워크(ISO/AWI TS 23516), 법적 구속력 있는 스마트 컨트랙트 (ISO/DTS 23259), 디지털 자산 수탁자의 보안 관리(ISO/TR 23576) 같은 문서들이 이 위원회에서 나온다.
정형검증이 표준화 항목으로 올라온 이유
스마트 컨트랙트의 정형검증 표준이라는 항목이 있다는 사실 자체가
중요한 신호다. 일반 소프트웨어에서 정형검증(formal verification)은
비용 때문에 항공·원자력 같은 극히 일부 영역에만 쓴다. 그런데 스마트
컨트랙트에서는 이게 주류 검증 수단이 되어가고 있다.
이유는 단순하다.
일반 소프트웨어: 버그 발견 → 패치 배포 → 끝
스마트 컨트랙트: 버그 발견 → 이미 자산이 빠져나갔다 → 되돌릴 수 없다
(컨트랙트 코드 자체를 못 고치는 경우도 많다)"배포 후 수정"이라는 안전망이 없으면 검증의 비용 구조가 완전히 달라진다. 테스트로 "버그를 못 찾았다"가 아니라, 증명으로 "이 성질은 항상 참이다"를 확보해야 한다.
테스터가 실제로 할 수 있는 것
정형검증 도구를 직접 다루는 것은 대개 전문 감사 업체나 연구 인력의 일이다. QA가 맡는 현실적인 역할은 그 앞뒤다.
앞 — 불변식(invariant)을 정의한다. 정형검증이 증명할 대상을 문장으로 만드는 일이다. 이건 요구사항 분석이고, QA의 본업이다.
[불변식 정의 예시 — 토큰 컨트랙트]
INV-01 모든 계정 잔액의 합은 총발행량과 항상 같다
INV-02 전송 후 송신자와 수신자 잔액 합은 전송 전과 같다
INV-03 권한 없는 계정은 발행 함수를 호출할 수 없다
INV-04 일시정지 상태에서는 어떤 전송도 성공하지 않는다
INV-05 같은 서명은 두 번 사용될 수 없다 (재사용 방지)이 목록을 만들 수 있으면, 정형검증을 안 하더라도 속성 기반 테스트 (property-based testing) 로 상당 부분을 확인할 수 있다. 랜덤한 연산 시퀀스를 대량으로 돌리면서 각 단계마다 불변식이 깨지는지 보는 방식이다.
뒤 — 감사 보고서를 검토하고 추적한다. 외부 감사에서 나온 지적이 실제로 수정됐는지, 수정이 다른 곳을 깨뜨리지 않았는지를 확인하는 것은 QA의 일이다. 감사 보고서의 각 지적에 대해 "수정됨 / 위험 수용 / 해당 없음"을 명시하고 근거를 남긴다.
블록체인 시스템의 체크 목록
컨트랙트 코드 바깥에서 QA가 확인할 것들이다.
- 트랜잭션 실패 시 애플리케이션이 어떻게 되는가 (가스 부족, 재구성, 타임아웃)
- 체인 재구성(reorg)이 일어났을 때 이미 "확정"으로 표시한 UI가 되돌아가는가
- 같은 요청이 두 번 제출됐을 때 (사용자가 버튼을 두 번 눌렀을 때) 중복 트랜잭션이 생기는가
- 오프체인 데이터와 온체인 상태가 어긋날 때 어느 쪽을 신뢰하는가, 그 규칙이 명시돼 있는가
- 개인키·시드 구문이 로그·에러 메시지·크래시 리포트에 새어 나가는가
- 권한 관리 — 관리자 키가 몇 개이고 누가 갖고 있는가 (단일 키면 그 자체가 결함)
- 체인 정지·포크 상황에서의 서비스 동작이 정의돼 있는가
세 번째 항목(더블 클릭)은 사소해 보이지만 실제 사고로 이어진 사례가 많다. 일반 웹에서는 중복 요청이 서버에서 걸러지지만, 블록체인에서는 두 트랜잭션이 모두 유효하게 처리될 수 있다.
메타버스 콘텐츠 — 사람이 판정 기준인 검증
휴먼팩터가 합격 기준이 된다
맵의 메타버스 영역에는 다른 데서 보기 힘든 항목들이 있다.
MTP Latency 표준
XR 콘텐츠 사용자 인터랙션 만족도 기준 표준
비디오 휴먼팩터 가이드라인 표준
후각 스크리닝 휴먼팩터 데이터 구조 및 시험 절차 표준
기능성 게임의 성과 측정 및 평가 절차 표준
디지털 가상훈련 시스템 평가 표준전부 사람의 감각과 반응이 측정 대상 이다. "동작한다/안 한다"로 판정되지 않는다.
MTP Latency — 가장 구체적인 측정 항목
MTP(Motion-to-Photon) Latency는 사용자가 머리를 움직인 순간부터 그 움직임이 반영된 화면이 눈에 도달할 때까지의 지연이다. VR(화면 속 공간에 들어간 것처럼 보여 주는 기술) 멀미의 가장 직접적인 원인으로 알려져 있고, 그래서 표준화 항목으로 올라왔다.
측정이 까다로운 이유는 시작점과 끝점이 소프트웨어 바깥에 있기 때문이다. 앱 내부에서 로그를 찍어 재면 렌더링 파이프라인과 디스플레이 지연이 빠진다.
[측정 구간]
실제 머리 움직임 ──── 센서 감지 ──── 앱 처리 ──── 렌더 ──── 디스플레이 출력
▲ ▲
시작점: 물리적 움직임 끝점: 실제 발광
(외부 계측 필요) (외부 계측 필요)
앱 로그로 재면 가운데 구간만 잡힌다 → 실제보다 짧게 나온다표준 측정 방법이 필요한 이유가 이것이다. "우리 측정으로는 15ms"라는 주장은 측정 방법을 밝히지 않으면 의미가 없다. 고속 카메라를 쓰는지, 포토다이오드를 쓰는지, 몇 프레임 평균인지에 따라 값이 크게 달라진다.
QA가 할 일은 측정 장비를 직접 만드는 것이 아니라 측정 조건을 기록으로 고정하는 것 이다.
| 기록할 항목 | 예 |
|---|---|
| 측정 방법 | 고속 카메라 1000fps, 화면과 마커 동시 촬영 |
| 측정 횟수 | 30회 반복, 중앙값 보고 |
| 하드웨어 | 기기 모델, 펌웨어 버전 |
| 콘텐츠 조건 | 씬 복잡도, 동시 오브젝트 수 |
| 설정 | 해상도, 재생률, 재투영(reprojection) 사용 여부 |
재투영 사용 여부는 특히 중요하다. 켜면 수치가 좋아지지만 다른 종류의 아티팩트가 생긴다. 안 밝히고 좋은 수치만 보고하면 나중에 문제가 된다.
XR 만족도·가상훈련 평가 — 주관 지표를 다루는 법
XR 콘텐츠 사용자 인터랙션 만족도 기준 표준, 디지털 가상훈련 시스템 평가 표준 같은 항목은 주관 평가를 다룬다. IEEE 2888.5는 VR 훈련
시스템의 메트릭을 다루고, IEEE 2888.4는 6자유도 VR 재난대응 훈련
시스템 아키텍처를 다룬다.
주관 지표를 다룰 때 지켜야 할 것은 세 가지다.
1. 검증된 설문 도구를 쓴다. 멀미는 SSQ(Simulator Sickness Questionnaire), 현존감은 표준 현존감 설문처럼 학술적으로 검증된 도구가 이미 있다. 직접 만든 5점 척도 설문은 재현성이 없다.
2. 표본과 조건을 기록한다. 참가자 수, 연령 분포, VR 경험 유무, 세션 길이, 휴식 간격. VR 경험이 많은 사람은 멀미를 덜 느끼므로, 개발팀 5명으로 측정하면 항상 좋은 값이 나온다.
3. 사전·사후 측정을 짝으로 한다. 세션 전에도 이미 컨디션이 안 좋은 참가자가 있다. 사후 점수만 보면 콘텐츠 탓인지 알 수 없다.
⚠️ 사람을 대상으로 하는 측정에는 동의 절차와 중단 권리 가 필요하다. 멀미 유발 가능성을 사전에 고지하고, 언제든 중단할 수 있음을 알리고, 중단을 불이익 없이 받아들여야 한다. 사내 실험이라도 마찬가지다.
IEEE 2888 — 현실과 가상을 잇는 인터페이스
맵에서 반복해서 등장하는 IEEE 2888 시리즈는 사이버 세계와 물리 세계의 인터페이스를 규정한다.
| 문서 | 내용 | 검증 포인트 |
|---|---|---|
| IEEE 2888.1 | 센서 인터페이스 규격 | 센서 데이터 포맷, 타임스탬프, 좌표계 일치 |
| IEEE 2888.2 | 액추에이터 인터페이스 규격 | 구동 명령 해석, 안전 한계, 실패 시 동작 |
| IEEE 2888.4 | 6DoF VR 재난대응 훈련 시스템 아키텍처 | 구성요소 간 연동 |
| IEEE 2888.5 | VR 훈련 시스템 메트릭 | 훈련 효과 측정 지표 |
센서·액추에이터 인터페이스에서 가장 자주 터지는 것은 좌표계와 단위 다. 한쪽은 오른손 좌표계, 다른 쪽은 왼손 좌표계. 한쪽은 도(degree), 다른 쪽은 라디안. 한쪽은 밀리미터, 다른 쪽은 미터. 이 불일치는 기능 테스트에서 "동작은 하는데 값이 이상하다"로 나타나고, 원인을 찾기까지 오래 걸린다.
시험 항목에 경계값과 부호를 반드시 포함 한다. 0 근처, 음수, 최대값, 각도 래핑(359° → 1°) 구간에서 확인하면 좌표계 불일치가 바로 드러난다.
접근성도 여기 걸린다
맵에는 스크린 리더용 멀티포인트 제스처 표준 같은 항목이 있고,
ISO/IEC 30113 시리즈(기기·방법 간 제스처 기반 인터페이스)가 관련
규격으로 붙는다. XR 환경의 접근성은 아직 정립되지 않은 영역이라,
맵의 항목명 자체가 검증 항목 힌트가 된다.
지능형 디바이스 — 물리 세계의 안전이 걸린 검증
로봇 — 안전 평가가 표준화의 중심이다
맵의 로봇 영역 항목을 보자.
인간과 로봇의 안전하고 효과적인 협동을 위한 조작 지능 표준
이동로봇의 밀집군중하 주행안전 평가 표준
로봇 이동지능 기반의 시맨틱 맵데이터 표현 표준
로봇 정보 모델 표준
감지 및 인식 지능 모듈을 위한 상호운용성 표준
클라우드 기반 로보틱스 서비스 표준관련 국제 규격으로 ISO 10218(산업용 로봇 안전), ISO 13482(개인 케어 로봇 안전), ISO 3691-4(무인 운반차 안전), ISO 18646(서비스 로봇 성능 평가), ISO 22166(모듈형 로봇 플랫폼)이 붙고, 자율 시스템의 윤리·투명성 쪽으로 IEEE P7001(투명성), IEEE P7009(페일세이프 설계)가 붙는다.
로봇 시험에서 QA가 반드시 이해해야 할 원칙은 "안전 기능은 기능 시험과 분리해서 다룬다" 는 것이다.
[기능 시험] 로봇이 목적지까지 가는가 실패 = 못 감
[안전 시험] 사람이 앞에 서면 멈추는가 실패 = 사람이 다침
비상정지 버튼이 즉시 듣는가
전원이 끊겨도 위험하게 움직이지 않는가
안전 시험은 통과율로 말하지 않는다. 100회 중 99회 멈췄다는 것은
"합격 99%"가 아니라 "1회 실패"다.이동로봇의 밀집군중하 주행안전 평가 표준이라는 항목명은 시험 조건을
그대로 알려준다 — 밀집 군중. 텅 빈 복도에서 사람 하나가 지나가는
시험으로는 부족하다는 뜻이다. 사람이 여럿, 예측 불가능하게, 가까이서
움직이는 조건을 만들어야 한다.
⚠️ 실제 사람을 대상으로 한 로봇 주행 시험은 위험하다. 마네킹·더미, 축소 속도, 안전 요원 배치, 물리적 방호벽 같은 안전 조치 없이 진행하지 않는다. 이건 협상 대상이 아니다.
지능형 반도체 — QA가 만날 접점
인공지능 프로세서 메모리 인터페이스 표준, 인공지능 기기 탑재 뉴로모픽 소자 표준, 스파이킹 신경망 기반의 인터페이스 표준,
지능형 프로세서 기반 시스템 반도체 안전성 고도화 설계 표준 같은
항목들이다.
소프트웨어 테스터가 반도체 설계를 검증할 일은 없다. 그런데 마지막 항목에 ISO 26262가 연결되어 있다는 점 은 알아둘 만하다. 자동차에 들어가는 AI 가속기는 기능안전 요구를 받고, 그 위에서 도는 소프트웨어도 같은 체계 안에 들어간다. 모듈 25 레슨 4에서 다룬 ASIL 등급이 여기서 소프트웨어 검증 강도로 내려온다.
실무적 접점은 하드웨어 가속 경로와 소프트웨어 폴백 경로의 결과가 같은가 를 확인하는 일이다. AI 가속기에서 돌린 추론과 CPU에서 돌린 추론의 결과가 미세하게 다른 경우가 있고(부동소수점 처리 차이), 이것이 임계값 근처에서 다른 판정으로 이어질 수 있다. 두 경로를 같은 입력으로 돌려 비교하는 시험을 넣어둘 가치가 있다.
실무에서 왜 필요한가
이 영역에서는 "검증 방법 설계"가 산출물이다
일반적인 QA 업무에서 테스트 방법은 이미 정해져 있고 케이스를 채우는 것이 일이다. 이 레슨의 영역에서는 어떻게 재야 하는가 자체가 정해져 있지 않다. 그래서 측정 절차서를 만드는 것 자체가 과제 산출물이 된다.
과제 제안서에 "OO 평가 방법론 개발"이 들어 있다면, 그 일은 사실상 QA의 일이다. 개발자는 만들고, QA는 그것을 어떻게 판정할지를 설계한다.
규격이 없을 때의 근거 만들기
앞서 여러 번 나왔듯, 이 영역은 후행·차세대공략 항목이 많다.
시험 기준을 우리가 만들어야 한다. 그럴 때 근거의 층을 쌓는다.
1순위 확정된 국제 규격 (있으면 무조건 이것)
2순위 초안 문서 (WD/CD/DIS) — 버전을 명시하고 인용
3순위 관련 기구의 공개 발표·백서
4순위 학술 논문의 검증된 측정 방법 (SSQ 같은 설문 도구 포함)
5순위 사내 기준 — 위 1~4를 참고했음을 명시하고 근거를 기술5순위만 있는 기준과, 1~4를 거쳐 5순위에 도달한 기준은 같은 숫자라도 설득력이 다르다. 이 층을 문서에 남기는 것이 QA의 부가가치다.
사례 — "멀미가 적다" 를 증명해야 했던 일
XR 콘텐츠 스타트업이 투자 자료에 "경쟁 제품보다 멀미가 적다" 를 넣으려 했다. 개발팀의 근거는 "사내 10명이 써 보고 괜찮다고 했다" 였다.
투자 실사에서 그 문장이 근거 없음으로 지적됐다. 문제가 셋이었다.
| 지적 | 내용 |
|---|---|
| 측정 조건 | 어떤 기기·콘텐츠·체류 시간인지 기록 없음 |
| 비교 대상 | "경쟁 제품" 이 무엇인지 특정되지 않음 |
| 평가 방법 | "괜찮다" 는 판정 기준이 없는 말 |
고친 방법은 표준에서 두 가지를 빌려 온 것이었다.
① 객관 측정 — MTP Latency
측정 조건을 규격이 정한 방식으로 고정
(기기·프레임 기준·반복 횟수·판정값)
→ "우리 기준으로 쟀다" 가 "표준 측정 방법으로 쟀다" 가 된다
② 주관 평가 — 표준 설문 도구
임의 문항이 아니라 공인된 설문을 그대로 사용
체류 시간·휴식 간격·피험자 수를 사전에 고정
→ 점수를 다른 연구·제품과 비교할 수 있게 된다두 가지를 함께 쓴 것이 핵심이다. 객관 측정만으로는 "그래서 사람이 덜 어지러운가" 에 답하지 못하고, 주관 평가만으로는 조건을 재현할 수 없다.
결과는 투자 자료의 문장이 바뀐 것이다 — "멀미가 적다" 가 "표준 측정 방법 기준 MTP Latency 평균 X ms, 표준 설문 점수 Y(피험자 N명, 체류 Z분)" 가 됐고, 그 문장은 되묻히지 않았다.
교훈이 셋이다.
- 주관 지표도 측정될 수 있다 — 임의 문항 대신 공인된 도구를 쓰고 조건을 고정하면 비교 가능한 숫자가 된다
- "사내에서 써 봤다" 는 데이터가 아니다 — 조건·대상·판정 기준이 없다
- 규격 번호 하나가 문장의 신뢰도를 바꾼다(모듈 28 레슨 1의 상황 2와 같은 이야기)
채용시장에서의 위치
세 영역 모두 QA 자리 수는 적고 요구는 특이하다. 공통점은 검증 방법 자체를 설계해야 한다는 것이고, 그래서 "테스트 케이스를 잘 쓴다" 로는 부족하다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "스마트 컨트랙트는 어떻게 검증하세요?" | "기능 테스트를 합니다" | "배포 후 수정이 어려우므로 불변식을 먼저 정의합니다. 테스터가 할 수 있는 건 불변식 목록과 경계 입력입니다" |
| "주관적인 품질은 어떻게 다루세요?" | "사용자 피드백을 받습니다" | "공인된 설문 도구를 그대로 쓰고 조건을 고정합니다. 임의 문항은 비교가 안 됩니다" |
| "XR 성능은 뭘 재세요?" | "프레임 수를 봅니다" | "MTP Latency 를 규격이 정한 조건으로 잽니다. 조건이 없으면 숫자가 비교 불가입니다" |
| "로봇 검증은 뭐가 다른가요?" | "물리적이라 복잡합니다" | "안전 시험과 기능 시험을 분리합니다. 안전은 규격 항목이고 실패 시 출시가 막힙니다" |
| "규격이 없는 영역은요?" | "자체 기준으로 합니다" | "기준을 만들고 근거를 적습니다. 진행 중인 표준화 문서를 인용하면 임의 기준이 아니게 됩니다" |
두 번째가 가장 변별력이 크다. 주관 지표를 "측정 불가" 로 두는 사람 과 도구와 조건으로 측정 가능하게 만드는 사람의 차이가 거기서 드러난다. 이 감각은 사용성·접근성 쪽(모듈 49)에서도 그대로 쓰인다.
네 번째도 중요하다. 안전 시험과 기능 시험을 분리하는 것은 규격 영역의 기본인데, 섞어 두면 기능 결함과 안전 미달이 같은 저울에 올라간다 (모듈 26 레슨 2의 "법규는 협상되지 않는다" 와 같은 구조).
공고 표현으로는 "스마트 컨트랙트 감사", "XR·메타버스 QA", "로봇 안전 검증", "휴먼팩터 평가" 가 이 레슨에 걸린다.