개념
이 레슨의 자리 — 제도에서 작업으로
모듈 25 레슨 8 이 제도를 설명했다 — R155 가 CSMS 인증과 차종별 증빙을 형식승인 조건으로 걸고, R156 이 SUMS 와 RXSWIN 을 요구한다는 구조다. 그 레슨을 먼저 읽었다고 전제한다.
이 레슨은 그 구조를 시험 조직이 무엇을 하는 일 로 옮긴다. 질문이 다르다.
| 모듈 25 레슨 8 | 이 레슨 |
|---|---|
| R155·R156 이 무엇을 요구하는가 | 그 요구에 어떤 증거를 내는가 |
| CSMS·SUMS 가 무엇인가 | 심사가 실제로 꺼내 보는 것이 무엇인가 |
| RXSWIN 이 무엇인가 | RXSWIN 을 유지하려면 시험이 무엇을 남겨야 하는가 |
| 업데이트를 안전하게 관리해야 한다 | 업데이트 자체를 어떻게 시험하는가 |
그리고 OTA 업데이트의 차량 상태 전제와 사용자 경험 은 모듈 65 레슨 6 이 맡는다. 이 레슨은 규정이 요구하는 검증과 증거 쪽이다.
규정 원문의 조항 번호와 요구 문장은 UNECE 가 공개한 R155·R156 원문에서 확인한다 (원문 확인). 아래에 적는 구조는 공개 자료로 확인된 범위이고, 심사 운영 방식은 승인 기관과 심사 기관에 따라 다르다.
체계 심사는 프로세스를 본다, 제품을 보지 않는다
QA 가 가장 먼저 교정해야 할 오해다. CSMS·SUMS 심사는 차량이 안전한지를 보지 않는다. 제조사가 그 일을 하는 체계를 갖고 운영하는지 를 본다.
공개 자료는 SUMS 초기 심사가 R156 의 특정 항(7.1.1.1~7.1.1.12 로 언급되는 범위) 에 정의된 열두 개 프로세스 를 확인하는 형태로 운영된다고 설명한다. 조항 번호와 각 프로세스의 정확한 요구 문장은 원문에서 확인한다(원문 확인). 요점은 숫자가 아니라 "프로세스 단위로 확인된다" 는 성격이다.
이 성격이 시험 조직에 뜻하는 것은 분명하다. "우리는 업데이트를 잘 시험합니다" 는 증거가 되지 않는다. 증거가 되는 것은 이런 모양이다.
- 업데이트 영향 판정을 정해진 절차로 수행한 기록이 매 건 남아 있다
- 그 절차가 문서로 정의되어 있고, 문서 판본과 실제 기록의 판본이 맞는다
- 판정 결과에 따라 재시험 범위가 결정된 기록이 있다
- 담당과 승인이 분리되어 기록되어 있다
모듈 32 레슨 8 의 현장평가 논리가 그대로 적용된다 — 문서대로 일한 기록 이 증거다. 그리고 질문은 같은 세 겹으로 좁혀 들어온다(사실 → 근거 → 일관성). 심사원이 "최근 업데이트 3건의 영향 판정 기록을 보여 주십시오" 라고 할 때, 세 건이 서로 다른 방식으로 되어 있으면 체계가 없다는 뜻이 된다.
적합성 증명의 유효기간 — 끝이 아니라 주기다
공개 자료는 CSMS 와 SUMS 의 적합성 증명서가 최대 3년의 유효기간 을 갖고, 기간 중에도 승인 기관이 지속 준수를 확인할 수 있다고 설명한다. 유효기간·갱신 조건·기간 중 확인 방식은 규정 원문과 승인 기관 안내에서 확인한다 (원문 확인).
이 사실이 시험 조직에 주는 함의가 크다. 인증은 한 번 받고 끝나는 사건이 아니라 주기적으로 증명해야 하는 상태 다. 그러면 증거를 만드는 방식이 달라져야 한다.
- 심사 직전에 몰아서 만드는 증거는 다음 주기에 또 몰아 만들어야 한다
- 평시 작업의 산출물이 그대로 증거가 되는 구조 를 만들어야 지속된다
- 그래서 양식 설계가 중요하다 — 업데이트 영향 판정서가 평소 쓰는 문서면 심사 준비가 거의 필요 없다
이것이 이 레슨에서 QA 가 만들 가장 가치 있는 것이다. 평시 양식 = 심사 증거.
RXSWIN 과 시험 기록의 연결
RXSWIN 은 형식승인에 관련된 소프트웨어를 식별하는 번호 다. 제조사가 정의하고, 승인 당국이 요구한다. 차종별로 승인에 관련된 소프트웨어 구성을 이 번호로 식별하고 문서화하며, 업데이트가 있을 때마다 승인된 상태를 바꾸는지 를 평가해 증거로 남긴다. RXSWIN 의 정확한 정의·표기 요구·관리 요건은 원문에서 확인한다(원문 확인).
시험 조직이 여기에 기여하는 지점은 둘이다.
1) 시험 결과를 소프트웨어 식별에 묶는다. 시험 보고서가 "버전 2.4" 가 아니라 형식승인 관련 식별 체계와 연결된 식별자 를 함께 적어야 한다. 그러지 않으면 어느 승인 상태에 대한 시험인지 추적할 수 없다. 모듈 35 레슨 6 에서 시험성적서 한 건을 닫을 때 범위와 대상을 명확히 식별하는 작업을 다뤘다 — 여기서는 그 식별에 승인 관련 식별자 가 추가된다.
2) 승인 관련 구성과 비관련 구성을 가린다. 모든 소프트웨어 변경이 승인에 관련되는 것은 아니다. 관련 범위가 정의되어 있어야 변경마다 판정할 수 있고, 그 정의는 시험 범위 정의와 맞물려야 한다. 관련 범위가 정의되지 않은 상태에서는 어떤 변경도 판정할 수 없다 — 이것은 결함 1건이 아니라 체계 지적이다.
승인 상태를 바꾸는 변경인가 — 판정 절차
실무에서 가장 자주 쓰이는 작업이 이것이다. 소프트웨어가 바뀌었을 때 "이 변경이 승인된 상태를 바꾸는가" 를 판정한다.
판정이 필요한 이유는 분기가 크게 갈리기 때문이다.
| 판정 | 따라오는 일 |
|---|---|
| 승인 관련 범위 밖 | 내부 절차대로 검증, 승인 절차 불필요 |
| 승인 관련이나 승인 상태 유지 | 증거를 보강해 기록, RXSWIN 관리 |
| 승인 상태를 바꿈 | 승인 기관 절차가 필요 |
판정을 즉흥으로 하면 안 되는 이유 는 두 방향이다. 과소 판정하면 승인 절차를 거치지 않은 소프트웨어가 차량에 올라가고, 과다 판정하면 사소한 변경마다 절차가 돌아 업데이트가 멈춘다. 후자는 보안 패치 지연 으로 이어지므로 가볍지 않다.
그래서 판정 기준을 문서로 미리 정해 둔다. 기준에 들어갈 축은 이렇다.
- 변경된 구성 요소가 승인 관련 범위에 속하는가
- 변경이 승인 시 제출한 기능·성능·안전·보안 특성에 영향을 주는가
- 변경이 통신 인터페이스나 외부 노출면을 바꾸는가
- 변경이 안전 메커니즘이나 보안 통제를 건드리는가
- 변경이 진단·기록 기능을 바꾸는가
각 축에 "예" 가 나올 때의 처리를 미리 적어 두면, 판정이 사람에 따라 달라지지 않는다. 판정 기준 문서 자체가 심사 대상 이기도 하다.
판정 결과가 "승인 상태를 바꿈" 으로 나오면 승인 기관 절차를 따른다. 그 절차의 종류와 조건은 규정과 승인 기관 안내에서 확인한다(원문 확인) — QA 가 판정하고, 절차 수행은 형식승인 담당이 맡는다.
OTA 업데이트를 검증 대상으로 설계한다
R156 의 관점에서 업데이트는 그 자체가 검증 대상 이다. 업데이트가 목표 차량을 식별하고, 호환성과 영향을 확인하고, 안전하게 전달되고, 기록되는 전 과정이 체계로 운영되어야 한다. 시험 조직이 설계할 검증 축은 여섯이다.
1) 대상 식별. 이 업데이트가 적용될 차량과 적용되지 않아야 할 차량이 정확히 갈리는가. 잘못된 차종·구성에 적용되는 경우 가 가장 위험한 결함이다. 구성이 조금 다른 변형(variant) 에 적용되는 시험을 반드시 넣는다.
2) 호환성 확인. 선행 버전 조건, 하드웨어 개정, 다른 ECU 의 버전 조합. 업데이트 전 상태가 여러 가지일 수 있고, 모든 선행 상태에서 성공하는지 를 봐야 한다. 조합이 폭발하므로 대표 조합을 선정하는 근거가 필요하다.
3) 무결성·진정성. 업데이트 패키지가 변조되지 않았고 정당한 출처에서 왔음을 확인하는 메커니즘이 동작하는가. 변조된 패키지, 서명이 없는 패키지, 다른 차종용 패키지, 만료된 패키지 를 거부하는지 시험한다. 공격 기법을 다루는 것이 아니라 거부 동작을 확인 하는 것이다. 보안 시험 기법은 모듈 50 이 맡는다.
4) 중단과 복구. 전원이 끊기거나 통신이 끊기거나 저장이 가득 찬 상태에서 업데이트가 중단되면 어떻게 되는가. 판정 기준은 "안전한 상태로 남는가" 다 — 이전 버전으로 돌아가거나, 업데이트 중 상태를 유지한 채 재개 가능하거나, 최소한 차량이 위험해지지 않는 상태 여야 한다. 장애 주입의 기법과 안전 원칙은 모듈 46 레슨 6 이 다루고, 전원·통신 조작은 승인과 안전 조치가 전제다.
5) 롤백. 되돌릴 수 있는가, 되돌린 뒤 상태가 일관된가. 그리고 부분 롤백 이 생기는 경우 — 여러 ECU 중 일부만 되돌아간 상태를 다룬다.
6) 기록. 업데이트 수행 이력이 남는가. 성공·실패·중단이 구분되는가. 식별 번호와 버전이 기록되는가. 기록이 없는 업데이트는 추적할 수 없고, 추적할 수 없으면 승인 상태를 증명할 수 없다.
여기서 차량 상태 전제 조건(주차 중인가, 시동이 걸려 있는가, 사용자 동의를 받았는가) 과 사용자에게 보이는 흐름은 모듈 65 레슨 6 이 다룬다. 두 레슨을 함께 읽으면 업데이트 검증의 전체 그림이 된다.
공급망으로 요구가 내려온다
R155·R156 은 차량 제조사에 걸리는 규정이지만, 요구는 부품·소프트웨어 공급사로 내려온다. 국내 자동차 소프트웨어 업계에서 이 레슨이 실무적으로 쓰이는 자리가 대부분 여기다.
공급사 입장에서 받는 요구의 모양은 이렇다.
- 우리 산출물이 제조사의 CSMS·SUMS 증거로 쓰일 수 있는 형태여야 한다
- 변경 시 영향 판정에 필요한 정보 를 제조사에 제공해야 한다 (무엇이 바뀌었고, 어느 특성에 영향을 주는지)
- 소프트웨어 식별 체계를 제조사의 체계와 맞물리게 관리해야 한다
- 제조사의 심사·감사 때 우리 기록이 열린다
마지막 항목이 과소평가된다. 제조사 심사에서 공급사 산출물이 표본으로 뽑히고, 그때 추적이 끊겨 있으면 제조사가 지적을 받는다. 그래서 공급사의 기록 품질이 계약 유지에 직접 영향을 준다.
ISO/SAE 21434 가 요구하는 개발 활동과 TARA 는 모듈 25 레슨 8 이 다뤘고, 조직 간 책임 배분(공급사와 제조사 사이의 역할 합의) 도 그쪽 범위다. 이 레슨은 그 합의 아래에서 시험 조직이 만들 산출물 에 집중한다.
실무에서 왜 필요한가
국내 자동차 소프트웨어 공급사에서 R155·R156 관련 요구가 내려온 이후, 시험 조직이 겪는 변화는 두 가지다.
첫째, 산출물의 독자가 바뀌었다. 예전에는 시험 보고서를 개발팀과 제조사 담당자가 읽었다. 이제는 그 보고서가 심사 증거로 제출될 수 있다. 독자가 그 자리에 없던 사람이 되면 요구가 달라진다 — 식별, 추적, 작성자·검증자 분리, 재현 가능성. 모듈 35 레슨 6 에서 시험성적서를 닫는 방식을 다룬 이유가 여기 있다.
둘째, 변경마다 판정이 붙었다. 예전에는 "작은 수정이니 영향 분석 생략" 이 가능했다. 이제는 모든 변경에 영향 판정 기록이 필요하고, 그 판정에 일관된 기준 이 있어야 한다. 기준 없이 사람마다 다르게 판정한 기록이 쌓이면 심사에서 일관성 문제로 걸린다.
이 두 변화에 대응하는 방법은 평시 양식을 심사 증거로 설계하는 것 뿐이다. 심사 직전에 증거를 만드는 조직은 3년 주기로 같은 고생을 반복한다. 평시 양식이 증거면 심사 준비가 표본을 꺼내 오는 일로 줄어든다.
그리고 보안 패치를 미루지 않기 위해 판정 기준이 필요하다. "이 패치가 승인 상태를 바꾸는가" 에 즉시 답할 수 없으면, 조직은 안전한 쪽으로 보이는 선택 — 패치를 미루는 선택 — 을 하게 된다. 그것이 실제로는 가장 위험하다. 모듈 33 레슨 7 에서 다룬 같은 구조의 문제다.
채용 관점에서 이 영역은 국내 자동차 소프트웨어 QA 공고에 직접 적히는 항목 이다. "UNECE R155/R156 대응", "CSMS", "SUMS", "OTA 검증", "사이버보안 체계" 같은 말이 나타난다. 면접에서 가르는 질문은 제도 설명이 아니라 "변경이 승인 상태를 바꾸는지 어떻게 판정하십니까" 이고, 판정 기준 축을 들어 답할 수 있는 사람이 적다.