개념
"표준을 지켰다"는 말에는 네 가지 뜻이 있다
제안서에 "국제표준 준수"라고 쓰여 있을 때, 그 문장이 실제로 무엇을 요구하는지는 네 갈래로 갈린다. 이 구분을 못 하면 엉뚱한 시험을 하거나, 해야 할 시험을 빠뜨린다.
① 적합성 시험 (Conformance)
"규격이 시키는 대로 동작하는가"
대상: 우리 제품 하나. 시험기(test system)와 우리 제품을 붙인다
판정: 규격의 각 조항별 Pass/Fail
예: oneM2M 규격의 메시지 포맷·상태코드가 규격대로인가
② 상호운용성 시험 (Interoperability)
"다른 회사 제품과 실제로 통하는가"
대상: 우리 제품 + 타사 제품 조합. 서로 붙여서 돌린다
판정: 시나리오별 성공/실패
예: 우리 IoT 플랫폼에 타사 디바이스가 등록되고 데이터가 오가는가
③ 성능 시험 (Performance)
"규격이 정한 수치 기준을 만족하는가"
대상: 우리 제품. 측정 조건이 규격에 명시된 경우가 많다
판정: 측정값 vs 기준값
예: MTP Latency 20ms 이하, 데이터센터 전력효율 지표
④ 인증 (Certification)
"위 시험 결과를 제3자가 보증하는가"
대상: 시험성적서. 인증기관이 검토하고 인증서·마크를 발급한다
판정: 인증서 발급 여부
예: TTA oneM2M 인증, GS인증①②③은 시험이고 ④는 제도다. 시험은 우리가 직접 할 수도 있지만, 인증은 반드시 지정된 기관을 거친다. 모듈 25 레슨 7에서 다룬 일반시험성적서·KOLAS 공인시험성적서·GS인증의 구분이 여기 ④에 해당한다.
적합성과 상호운용성은 대체 관계가 아니다
현장에서 가장 자주 나오는 오해가 이것이다. "우리 제품이 적합성 시험을 통과했으니 다른 제품과도 잘 붙을 것이다" — 틀렸다. 반대도 틀렸다. "타사 제품과 붙여봤더니 잘 되니까 규격에 맞는 것이다" — 이것도 틀렸다.
적합성 통과 적합성 실패
상호운용 성공 ✅ 정상 ⚠️ 둘 다 같은 방식으로
규격을 어기고 있다
상호운용 실패 ⚠️ 규격에 해석 ❌ 최악
여지가 있다오른쪽 위 칸이 실무에서 제일 위험하다. 두 회사가 똑같이 규격을 잘못 읽어서 서로 잘 통하는 상태. 세 번째 회사 제품이 들어오는 순간 전부 깨진다. 적합성 시험은 정확히 이걸 막는 장치다.
왼쪽 아래 칸도 흔하다. 양쪽 다 규격에는 맞는데 안 붙는 경우인데, 대개 규격에 선택 사항(optional)이 많거나 문장이 모호할 때 생긴다. 이럴 때 나오는 것이 프로파일 — "이 규격 중에서 우리 산업은 이 부분만, 이 옵션으로 쓴다"고 좁혀 놓은 문서다. 상호운용성 문제의 상당수는 규격이 아니라 프로파일 부재 때문이다.
양쪽 다 적합한데 안 붙는 네 가지 원인
왼쪽 아래 칸(양쪽 적합 · 상호운용 실패)은 사고가 아니라 구조적으로 생기는 일 이다. 원인은 대체로 네 갈래다.
| 원인 | 어떻게 생기나 | 적합성 시험이 못 잡는 이유 |
|---|---|---|
| 선택 항목 | 한쪽은 구현, 다른 쪽은 미구현 | 미구현도 적합이다 |
| 해석 차이 | 한 문장을 서로 다르게 읽는다 | 양쪽 해석이 모두 규격 문장에 들어맞는다 |
| 옵션 조합 | 각 옵션은 맞는데 같이 쓰면 깨진다 | 시험 항목이 옵션 단위로 쪼개져 있다 |
| 관용 범위 | 허용 범위의 양 끝을 각자 쓴다 | 양 끝 모두 범위 안이다 |
세 번째가 가장 빨리 커진다. 선택 기능이 10개 면 켜고 끄는 조합은 이론상 1,024가지 다. 적합성 시험은 "각 기능이 규격대로인가" 를 보고 조합은 보지 않는다. 그래서 실제로 쓰는 조합을 고정해 두는 문서가 필요하고, 그게 앞에서 말한 프로파일이다.
네 번째는 눈에 잘 안 띈다. 재전송 대기 시간을 1초 이상 30초 이하로
허용한 규격에서 한쪽이 1초, 다른 쪽이 30초를 쓰면 둘 다 적합한데
재전송이 겹쳐 연동이 불안정해진다. 수치에 범위가 적힌 조항을 만나면
범위의 양 끝으로 시험해 보는 것 이 QA의 일이다 — 모듈 3의 경계값
분석을 규격 조항에 적용하는 셈이다.
사례 — 양쪽 다 적합한데 3주를 태운 연동
IoT 과제에서 자사 플랫폼과 협력사 게이트웨이를 붙이는 일이었다. 양쪽 모두 공인 적합성 시험성적서 를 갖고 있었고, 그래서 연동 일정을 5일 로 잡았다. 실제로는 3주 가 걸렸다.
증상은 단순했다. 게이트웨이가 올리는 등록 요청 100건 중 23건 이 실패했고, 실패한 요청에만 공통점이 있었다 — 리소스 이름이 32자를 넘었다.
원인을 층별로 따라가면 이렇다.
| 층 | 무슨 일이 있었나 |
|---|---|
| 규격 | 리소스 이름 길이를 should 로만 권고했다 |
| 자사 플랫폼 | 권고를 지켜 32자 초과를 거절 했다 |
| 협력사 게이트웨이 | 권고를 따르지 않고 장비 일련번호를 그대로 이름으로 썼다(최대 41자) |
| 양쪽 적합성 시험 | should 는 필수 항목이 아니므로 둘 다 통과 했다 |
적합성 시험이 잘못된 것이 아니다. should 를 필수로 판정하지 않는
것이 규격대로다. 두 성적서 모두 유효했고, 그래도 제품은 안 붙었다.
바꾼 것은 셋이다.
- 연동 착수 전에 양쪽 PICS를 교환 해 선택 항목의 Y/N 을 대조했다
- 두 제품 사이 기준점에 패킷 캡처를 상시로 걸고 시나리오를 돌렸다
should항목 중 상대 구현에 영향을 주는 것 만 따로 목록으로 뽑아 연동 합의 문서의 부록에 넣었다
효과는 다음 연동(다른 협력사)에서 나왔다. PICS 대조에 반나절 이 들었고 불일치 4건 이 나왔다. 그 4건을 먼저 맞춘 뒤 연동은 4일 에 끝났다.
교훈은 셋이다.
- 성적서 두 장은 연동 가능 증명이 아니다. 각각 다른 질문에 답한 문서다
should는 시험 대상이 아니지만 상호운용의 최대 변수다. 필수가 아닌 것이 서로 다르게 구현되는 지점이다- 연동 비용은 PICS 대조로 앞당겨 치를 수 있다. 반나절이 2주를 아낀다
시험은 세 층으로 쌓인다
①②③④를 유형으로 늘어놓으면 선택지처럼 보이지만, 실무에서는 층 이다. 아래 층을 건너뛰고 위로 갈 수 없다.
3층 상호인증 / 인증
"제3자가 보증한다" → 인증서·마크. 시험성적서가 전제다
▲
2층 상호운용성 시험
"실제로 통한다" → 상대 제품이 있어야 한다
▲
1층 적합성 시험
"규격대로다" → 혼자서도 한다. 시험기 + 우리 제품1층을 건너뛰고 2층만 하면, 실패했을 때 누구 잘못인지 가릴 근거가 없다. 반대로 1층만 하고 끝내면 앞 사례처럼 성적서 두 장을 들고도 안 붙는다.
그래서 ETSI 쪽 상호운용성 시험 지침에는 두 층을 겹쳐 쓰는 방식이 따로 이름을 갖고 있다 — 적합성 검사를 붙인 상호운용성 시험 (interoperability testing with conformance checks). 두 제품 사이의 기준점(reference point)에 모니터를 걸어, 시나리오 성공·실패와 주고받은 메시지가 규격대로인지를 동시에 본다.
이 방식이 QA가 사내에서 가장 쉽게 흉내낼 수 있는 모양이다. 시험기를 사지 않아도 두 시스템 사이에 패킷 캡처나 프록시를 하나 걸어 두면, "시나리오는 성공했는데 메시지는 규격을 벗어난" 경우를 잡을 수 있다. 모듈 12의 계약 테스트가 하는 일과 사고방식이 같다.
시험 명세는 어떤 구조로 생겼나 — TSS&TP와 ATS
통신 규격 계열의 적합성 시험 명세는 규격서에서 곧바로 테스트 스크립트로 가지 않는다. 중간에 층이 두 개 더 있다.
규격 (base standard)
│ shall 추출
▼
요구사항 카탈로그
│ "무엇을 확인할 것인가" 를 사람 말로
▼
TSS & TP 시험 모음 구조 + 시험 목적
│ 실행 절차·판정 기준까지 기계가 읽게
▼
ATS 추상 시험 모음 (TTCN 같은 표기법)
│ 우리 제품 고유값을 채운다
▼
실행 가능한 시험 (+ PICS/ICS, PIXIT/IXIT)- TP (Test Purpose) — 시험 하나의 목적을 자립적인 한 단락으로 적은 것. 규격 조항을 근거로 쓴다
- TSS — TP들을 묶는 구조. 기본 연결·오류 처리·기능별로 묶는다
- ATS — TP를 실행 절차와 판정까지 구체화한 추상 케이스 집합. 특정 제품에 묶이지 않는다
- PIXIT/IXIT — 제품 고유값만 따로 뽑아 놓은 자리
이 네 층 구조는 사내 테스트 자산에 그대로 베낄 만하다. 목적(TP)과 구현(스크립트)을 분리해 두면 규격이 개정될 때 목적만 다시 보면 되고, 환경값을 IXIT 자리로 뽑아 두면 같은 케이스를 다른 환경에 그대로 돌릴 수 있다. 이름이 낯설 뿐 구조는 흔한 것이다.
용어는 제도마다 조금씩 다르다. 통신 규격 계열에서는 PICS·PIXIT, 블루투스 적합성 체계에서는 ICS·IXIT 로 부른다. 이름이 달라 다른 것으로 착각하기 쉽지만 역할은 같다 — 무엇을 구현했는지 선언하는 표와, 시험에 필요한 제품 고유 정보다. 선언한 기능이 곧 수행해야 할 시험 항목이 된다 는 점까지 같다.
규격 문서를 테스트 케이스로 바꾸는 5단계
규격서를 처음 열면 압도된다. 300페이지짜리 문서에서 무엇을 뽑을지 막막하다. 절차를 정해두면 기계적으로 처리할 수 있다.
1단계 — 적용 범위(Scope)와 적합성 조항(Conformance clause)을 먼저 읽는다. 대부분의 국제 규격에는 "이 규격에 적합하다고 주장하려면 무엇을 만족해야 하는가"를 명시한 절이 따로 있다. 여기가 시험 범위의 경계다. 이 절을 안 읽고 본문부터 읽으면 우리와 무관한 조항까지 다 검토하게 된다.
2단계 — shall / should / may를 분류한다.
| 조동사 | 뜻 | 시험 대상인가 |
|---|---|---|
| shall (해야 한다) | 필수 요구사항 | ✅ 반드시 시험한다 |
| should (하는 것이 좋다) | 권고 | ⚠️ 안 지켜도 부적합은 아니다. 근거를 남기면 된다 |
| may (할 수 있다) | 허용 | ❌ 시험 대상 아님. 다만 우리가 이 옵션을 쓰는지는 기록한다 |
| shall not / should not | 금지 | ✅ 네거티브 테스트 대상 |
shall 문장의 개수가 곧 필수 시험 항목의 대략적 개수다. 규격서를
받으면 제일 먼저 shall을 전부 세어본다. 30개면 하루 만에 정리되고,
400개면 팀을 붙여야 한다는 판단이 그 자리에서 선다.
3단계 — 각 shall을 관찰 가능한 형태로 다시 쓴다.
규격 원문:
"The platform shall reject a registration request
that does not contain a valid credential."
관찰 가능한 요구사항:
유효하지 않은 자격증명을 포함한 등록 요청에 대해
플랫폼은 4xx 응답 코드를 반환하고 리소스를 생성하지 않는다.
관찰 지점 1: HTTP 응답 코드
관찰 지점 2: 등록 후 리소스 조회 결과 (없어야 함)관찰 지점을 두 개 이상 잡는 습관이 중요하다. 응답 코드만 보면 "에러를 주긴 했는데 리소스는 만들어진" 경우를 놓친다.
4단계 — PICS/PIXIT를 정리한다. 통신 규격 계열에서 쓰는 두 문서다.
- PICS (Protocol Implementation Conformance Statement) — "우리 제품은 규격의 어느 기능을 구현했는가"를 표로 선언한 것
- PIXIT (Protocol Implementation eXtra Information for Testing) — 시험에 필요한 우리 제품 고유 정보(IP, 포트, 인증서, 타임아웃 값 등)
PICS가 곧 시험 항목 선택표 다. 우리가 구현하지 않았다고 선언한 기능은 시험하지 않는다. 그래서 PICS를 부풀려 쓰면 시험 범위가 늘어나고, 줄여 쓰면 "그 기능 지원 안 함"으로 확정된다. PICS 작성은 QA가 개발과 같이 앉아서 해야 하는 일 이지 영업이 혼자 채울 서류가 아니다.
5단계 — 테스트 케이스로 옮기고 추적성을 건다.
| 규격 조항 | 요구사항 ID | 테스트 케이스 | 시험 방법 | 증거 |
|---|---|---|---|---|
| §7.3.2 | REQ-042 | TC-118, TC-119 | 시험기 자동 | 로그 캡처 |
| §7.3.3 | REQ-043 | TC-120 | 수동 관찰 | 화면 녹화 |
| §9.1 | REQ-051 | — (미구현, PICS에서 N 선언) | — | PICS 사본 |
이 표가 레슨 8에서 다룰 표준 추적성 매트릭스 의 원형이다.
실제 인증 제도는 어떻게 돌아가나 — oneM2M 사례
추상적인 설명을 하나의 실제 제도에 붙여보자. oneM2M은 한국·유럽·일본· 미국·중국의 표준화 기관이 2012년에 함께 만든 IoT 공통 서비스 플랫폼 표준이다. 활용·개발 맵의 사물인터넷 영역 항목 상당수가 여기에 걸린다.
TTA가 운영하는 인증 절차의 흐름은 이렇다.
1. 제품 준비 + PICS 작성
↓
2. TTA에 시험 신청
↓
3. 적합성 시험 — 국제공인 시험장비로 규격 기준 시험 수행
상호운용성 시험 — 타사 구현체와 붙여 시나리오 수행
↓
4. 시험 결과 검토 → 시험성적서 발급
↓
5. GCF에 시험성적서 등록 + oneM2M 인증 신청
↓
6. 검토 통과 → 인증서 및 인증마크 발급TTA는 2017년 2월에 상호운용성 시험 기반 oneM2M 인증 프로그램을 시작했고, 2018년 2월에 공인 적합성 시험기를 지정해 적합성 범위를 추가했다. 상호운용성이 먼저, 적합성이 나중이었다 는 순서가 흥미롭다. 신기술 영역에서는 대개 "일단 붙는지"가 먼저 급하고, 규격 조항별 정밀 검증은 시험기가 성숙한 다음에 온다.
이 순서는 사내 검증 계획을 세울 때도 그대로 쓸 만하다. 초기에는 상호운용성 시나리오로 큰 구멍을 찾고, 규격이 안정된 뒤 적합성 항목을 채워 나가는 편이 현실적이다.
인증 시험과 자체 시험은 역할이 다르다
같은 항목을 보더라도 둘은 다른 일을 한다. 대체 관계로 보면 둘 중 하나를 빼게 되고, 그게 사고가 된다.
| 자체 시험 | 인증(공인) 시험 | |
|---|---|---|
| 묻는 질문 | 지금 고칠 것이 무엇인가 | 남에게 보일 근거가 있는가 |
| 시점 | 개발 중 계속 | 규격·제품이 굳은 뒤 |
| 반복 비용 | 거의 없다 | 재시험마다 수수료와 대기 |
| 범위 | 의심되는 곳 위주 | PICS가 정한 항목 전부 |
| 결과물 | 결함 목록 | 시험성적서 |
| 실패했을 때 | 바로 고친다 | 고치고 다시 신청 한다 |
읽는 법은 간단하다. 인증 시험은 디버깅 도구가 아니다. 수수료와 대기 시간이 붙은 자리에서 첫 실패를 발견하면 그 하나가 일정을 몇 주 밀어낸다. 그래서 순서가 정해져 있다 — 공인 시험에 보내기 전에 같은 항목을 자체로 한 번 돌려 본다.
자체 시험에 쓸 재료는 생각보다 공개돼 있다. 시험 목적(TP) 목록이 공개된 규격이면 그 문장만 가져와 우리 손으로 케이스를 짜도 공인 시험 통과 여부를 상당 부분 미리 알 수 있다. 어떤 문서가 공개돼 있는지는 규격마다 다르므로 최신 규격 문서와 시험 제도 공고로 확인한다.
실무에서 왜 필요한가
견적과 일정이 완전히 달라진다
같은 "표준 준수 검증"이라도 네 유형의 비용은 자릿수가 다르다.
| 유형 | 전형적 소요 | 주된 비용 |
|---|---|---|
| 자체 적합성 점검 | 수일~수주 | 인건비 |
| 공인 적합성 시험 | 수주~수개월 | 시험기 사용료, 시험 수수료 |
| 상호운용성 시험(플러그페스트 포함) | 수주 | 타사 협조 조율이 최대 변수 |
| 인증 취득 | 수개월 | 시험 + 인증 심사 + 재시험 |
과제 계획서에 "인증 취득"을 성과로 적었는데 일정에 2개월만 잡아뒀다면, 그 계획은 시작부터 어긋나 있다. QA가 이 구분을 알고 있으면 계획 단계에서 막을 수 있다.
부적합 판정이 났을 때 대응이 달라진다
적합성 시험에서 떨어졌다 → 규격 조항 위반이다. 코드를 고치거나, PICS에서 해당 기능을 "미지원"으로 내리거나 둘 중 하나다.
상호운용성 시험에서 떨어졌다 → 어느 쪽 잘못인지부터 가려야 한다. 양쪽 다 적합성을 통과했는데 안 붙는다면 규격 해석 차이일 가능성이 높고, 이건 규격 관리 기구에 질의(interpretation request)를 올려야 풀린다. 이 판단을 못 하면 우리 코드만 계속 고치다가 시간을 다 쓴다.
규격 해석 질의는 정당한 QA 활동이다
신산업 규격은 문장이 모호한 경우가 많다. 특히 병행·차세대공략 항목의
초안 단계 문서가 그렇다. 모호한 문장을 만났을 때 우리 해석을 임의로
확정하지 말고 기록으로 남기는 것 이 QA의 일이다.
[규격 해석 이슈 기록 템플릿]
규격 / 버전 / 조항: oneM2M TS-0001 v4.x §10.2.3
원문 인용: (한 문장)
해석 A: 우리 팀 해석
해석 B: 대안 해석
차이가 만드는 결과: A를 따르면 X, B를 따르면 Y
현재 채택: A (근거: ...)
후속: TTA PG 문의 / 기구 질의 예정이 기록이 나중에 부적합 판정을 받았을 때 "몰라서 틀린 것"과 "알고 선택한 것"을 가른다. 과제 평가와 감사에서 이 차이는 크다.
채용시장에서의 위치
이 구분은 공고에 이 이름으로 적히는 일이 드물다. 대신 "시험인증 대응", "국책과제 성과 검증", "표준 적합성 검증", "타사 연동 검증" 같은 표현으로 나온다. 하드웨어가 섞인 제품, 통신·IoT·모빌리티, 그리고 공공 R&D를 수행하는 조직에서 반복해서 요구된다.
| 질문 | 약한 답 | 강한 답 |
|---|---|---|
| "적합성 시험과 상호운용성 시험의 차이는요?" | "하나는 규격, 하나는 연동입니다" | "대상이 다릅니다. 적합성은 우리 제품 하나와 시험기, 상호운용은 타사 제품과의 조합입니다. 그래서 실패했을 때 할 일도 다릅니다" |
| "적합성은 통과했는데 연동이 안 됩니다. 뭘 보죠?" | "로그를 봅니다" | "먼저 양쪽 PICS를 대조합니다. 선택 항목 불일치가 아니면 규격 해석 차이로 보고, 기록을 남긴 뒤 규격 관리 기구에 질의합니다" |
| "PICS는 누가 씁니까?" | "개발팀이 씁니다" | "QA가 개발과 같이 앉아 씁니다. 선언한 기능이 그대로 시험 항목이 되니까 부풀리면 비용이, 줄이면 미지원 확정이 따라옵니다" |
| "인증을 꼭 받아야 하나요?" | "받는 게 좋습니다" | "계약·공고가 요구하는지로 갈립니다. 요구하지 않으면 같은 항목을 자체 시험으로 보고 기록을 남기는 편이 빠릅니다" |
| "시험 일정은 어떻게 잡으셨어요?" | "두 달 잡았습니다" | "상호운용성 쪽은 타사 협조가 임계 경로입니다. 플러그페스트 같은 행사 일정을 먼저 확인하고 개발 일정을 거기 맞췄습니다" |
두 번째가 가장 변별력이 크다. 연동 실패를 겪어 본 사람과 책으로 읽은 사람의 차이가 거기서 갈린다. 겪어 보지 않은 사람은 거의 예외 없이 "우리 코드를 봅니다" 로 답하는데, 그 답은 문제의 절반을 처음부터 제외 한다. "양쪽 PICS 대조" 라는 말이 나오면 면접관은 상대가 책임 소재를 가르는 절차 를 갖고 있다고 읽는다.
다섯 번째도 의외로 크다. 일정 질문에 임계 경로가 타사 협조라고 답하는 사람 은 이 시험을 실제로 조율해 본 사람이다. 기술 리스크만 말하면 계획 경험이 없는 쪽으로 읽힌다.
세 번째는 반대로 함정이 있는 질문 이다. "개발이 씁니다" 도 "QA가 씁니다" 도 반쪽이다. 정답은 같이 쓴다 이고, 그 이유를 비용과 범위로 설명할 수 있으면 끝난다.