OTA 업데이트, 법은 생겼는데 무엇을 증명해야 할까? — UN R156, ISO 24089, 자동차관리법 34조의5의 빈틈

보안 규제와 프로세스

현장에서 자주 듣는 말

"SUMS 인증받았으면 국내 자동차관리법도 자동으로 통과되는 거 아닌가요?"

"'정상적으로 작동'을 증명하라는데, 어디까지 테스트하면 되는 거죠?"

"CSMS처럼 사전인증인 줄 알았는데, SUMS는 자가인증이라고요?"

"법 조문은 짧은데 왜 준비할 서류는 이렇게 많아지죠?"

자동차관리법 34조의5(SW 업데이트 조항)는 2025년 8월에 시행됐습니다. 그런데 조문을 실제로 읽어보면 이상한 점이 있습니다.

"모든 장치가 정상적으로 작동되도록 할 것", "안전기준에 적합하도록 할 것" — 법은 요구하는데, '정상'과 '적합'을 판단하는 구체적 기준은 법 안에 없습니다. UN R156(SUMS)도, ISO 24089도 각자 다른 층위에서 이 질문에 답하고 있지만 서로 완전히 포개지지는 않습니다. 이 세 문서 사이의 틈을 실무자가 스스로 메워야 하는 게 지금의 현실입니다.

---

자동차관리법 34조의5 — 무엇을 요구하는가

2025년 8월 14일 시행된 자동차관리법 34조의5(자동차제작자등의 소프트웨어 업데이트)는 국내에서 처음으로 차량 SW 업데이트를 법제화한 조항입니다. 요구사항은 크게 다섯 가지입니다.

항목	요구사항 (요지)	성격
①	업데이트 후 모든 장치·기능이 정상적으로 작동할 것	품질(Quality)
②	업데이트 관련 구조·장치가 자동차안전기준에 계속 적합할 것	기능안전(Functional Safety)
③	사이버공격·위협으로부터 보호된 상태에서 안전하게 실시할 것	사이버보안(Cybersecurity)
④	업데이트 전·후 관련 정보를 사용자에게 제공할 것	사용자 정보제공
⑤	업데이트 내용·이력을 기록·보관하고 훼손·위변조를 방지할 것	문서 관리

문제는 위반 시 과징금·시정명령·벌칙·과태료까지 규정돼 있는데, 정작 조문 안에는 "모든", "정상", "기준", "안전", "적합", "적정" 같은 판단 기준이 되는 단어들의 정의가 없다는 점입니다. 법은 결과(무엇을 지켜야 하는가)를 말하지만, 과정(무엇을 증빙해야 통과인가)은 침묵합니다.

---

고시가 한 겹 더 채워준다 — 그런데 여전히 절차 중심

다행히 법 조문만 덩그러니 있는 건 아닙니다. 국토교통부는 "SW 업데이트 증명자료에 대한 고시"를 통해 34조의5의 각 항목별로 어떤 자료를 준비해야 하는지 조금 더 구체화했습니다. 항목별로 요구하는 증빙자료를 정리하면 다음과 같습니다.

법 조항	고시가 요구하는 증빙자료 (요지)
①번 (정상 작동)	시스템 간 상호의존성 확인 절차서, 기능 추가·변경 평가·기록 절차서, 영향받는 시스템·기능 기록 문서, 검증 절차서 및 검증 통과 기록
②번 (안전기준 적합)	업데이트 전후 SW 버전·HW 구성 식별 절차서, 안전기준 관련 시스템 영향 평가·기록 절차서, 안전기준 관련 기능 추가·변경·삭제 평가 절차서
③번 (사이버보안)	사이버 위협으로부터 업데이트를 보호하는 절차에 대한 설명자료
④번 (사용자 정보제공)	사용자 고지 절차서, 업데이트 실행 가능 방법·조건에 대한 설명자료
⑤번 (기록·보관)	문서 보관·제출 절차서(국토부·성능시험대행자 요청 대응 포함), 대상차량 식별 절차서, 개별 차량 업데이트 전후 정보 기록·적용가능 여부 식별 절차서

읽어보면 알 수 있듯, 고시 역시 "무엇을 증명하라"고 말할 뿐 "그 절차서가 어느 수준이면 충분한지"는 여전히 열어두고 있습니다. 즉 고시는 법의 침묵을 "절차서를 갖추라"는 수준까지만 좁혀줄 뿐, 절차서의 구체적 내용은 결국 제작사가 스스로 채워야 하는 몫으로 남습니다.

---

그럼 UN R156(SUMS)은 답을 주는가

❌ "국제표준·국제법규니까 R156이 국내법보다 더 구체적일 것이다"

✅ R156(SUMS)도 성능 수치가 아니라 프로세스 요건 중심이라 여전히 해석의 여지가 크다

SUMS(Software Update Management System)는 "이런 값을 만족하는가"를 검사하는 규정이 아니라 "이런 프로세스와 관리 체계를 갖췄는가"를 확인하는 규정에 가깝습니다. 자동차관리법보다는 구체적이지만, 여전히 "일반적인 가이드 수준"이라는 게 국내 실무자들 사이의 공통된 평가입니다. 즉 SUMS를 통과했다고 해서 자동차관리법 34조의5의 다섯 항목을 자동으로 충족한다고 보기는 어렵습니다.

ℹ️ 여기서 실무적으로 중요한 차이가 하나 있습니다. 사이버보안(CSMS)은 사전인증 방식이라 승인기관의 심사를 거쳐야 하지만, SW 업데이트(SUMS)는 OEM 자가인증 방식입니다. 즉 "무엇을 준비해야 통과인지"를 제3자가 미리 확인해주지 않고, 제작사 스스로 판단하고 책임져야 하는 구조입니다. 기준이 모호한 상태에서 자가인증까지 겹치면, 실무 부담은 고스란히 개발·품질 조직으로 넘어옵니다.

---

빈틈을 메우는 실질적 역할 — ISO 24089

이 틈을 메우는 실무적 다리 역할을 하는 것이 ISO 24089(도로 차량 — 소프트웨어 업데이트 엔지니어링)입니다. ISO 24089는 조직 수준부터 인프라, 차량, 소프트웨어 업데이트 패키지, 캠페인 단계까지 SW 업데이트의 전 과정을 세부 조항으로 구조화한 표준입니다.

UN R156의 인터프리테이션 문서(해석 지침) 개정안에서는 SUMS의 각 조항을 ISO 24089의 세부 조항과 연결하면서 [R](규정) · [Q](품질) · [C](사이버보안) · [F](기능안전) 키워드를 붙여 정리하고 있습니다. 예를 들면 이런 식입니다.

SUMS 조항 (예시)	ISO 24089 대응 조항 (예시)	핵심 키워드
7.1.1.2	4.3.4.4, 6.3.2.1	[C][R] 무결성, 고유 식별
7.1.1.5	6.3.2.4, 8.3.1.4, 9.3.1.9	[Q][R] 상호의존성 식별
7.1.3.1	5.3.4.1, 6.3.4.6, 8.3.1.7	[C] 보호, 방지
7.1.4.1	4.3.1.3	[Q][F] 평가, 안전성

이런 매핑이 갖는 의미는 단순합니다. 법 조문의 추상적인 단어("정상", "적합") 하나하나를 ISO 24089의 구체적인 산출물(work product) — 예를 들어 "차량 구성정보 관리 기능에 대한 문서가 있는가", "업데이트 캠페인 실행 문서가 있는가" — 로 치환할 수 있게 해준다는 것입니다. 즉 법이 침묵하는 "무엇을 증빙해야 하는가"의 answer를, 국제표준의 산출물 체크리스트가 대신 채워주는 구조입니다.

실제 감사에서는 이런 식으로 묻는다

매핑표만 보면 여전히 추상적입니다. 실제 인증·감사 가이드라인은 이 매핑을 근거로 "예/아니오"로 답할 수 있는 구체적 질문(work product 확인) 형태까지 내려갑니다. 아래는 그 형태를 이해하기 위한 예시입니다. (구체적 구현 방식은 회사·차종마다 다르므로 어디까지나 예시로 봐주세요.)

영역	감사 질문 예시	답변에 흔히 등장하는 개념 (예시)
조건(Condition)	SW 업데이트 작업 수행에 필요한 조건이 충족되는지 결정하는 기능이 있는가?	배터리 잔량, 파킹 상태, 기어 위치, 후드 개폐, 램프 상태 등 업데이트 실행 전제조건 점검
무결성·진위성(Integrity/Authenticity)	활성화 이전 시점에 수신 패키지의 무결성·진위성을 검증하는 기능이 있는가?	패키지 복호화 후 검증(verify), 전자서명 검증, 타겟(ECU) 업데이트 검증
안전한 차량 상태(Safe Vehicle State)	업데이트 작업의 각 단계에서 안전한 차량 상태를 보장하는 기능이 있는가?	이중화 메모리 뱅크(2-bank) 구조, 실패 시 롤백(Rollback), 재시도(Retry), 리부트 후 버전 비교
사이버보안 위험(Cybersecurity Risk)	차량 내 SW 업데이트 작업의 사이버보안 위험이 관리되는가?	TARA(위협분석·위험평가) 수행 근거, 다운그레이드 방지, 패키지 암복호화, HSM 등 보안 사양 연계
기능안전 위험(Functional Safety Risk)	업데이트 작업의 기능안전 위험이 관리되는가?	HARA(위험원분석·위험평가) 수행 근거, 위험의 식별·분석·평가·처리 문서

💡 "답변에 흔히 등장하는 개념" 칸에 적은 배터리·파킹·기어 조건이나 2-bank 구조 등은 표준이 강제하는 수치나 방식이 아니라, 표준이 요구하는 기능을 각 제작사가 구현하는 방식의 예시입니다. 표준은 "조건을 판단하는 기능이 있는가"까지만 요구하고, 그 조건이 무엇이어야 하는지는 여전히 제작사 재량입니다.

이 지점에서 자동차관리법 34조의5로 다시 돌아가 보면, 결국 감사관이 실제로 확인하는 것은 "TARA를 했는가", "HARA를 했는가", "롤백 기능이 있는가", "SRS/SADS/SUDS 같은 설계 문서에 이 내용이 반영돼 있는가"입니다. 법 조문의 "정상적으로 작동", "안전기준 적합"이라는 말이 실무에서는 이런 구체적 산출물의 존재 여부로 치환되는 셈입니다.

---

3중 참조 구조

자동차관리법
34조의5
(국내법·추상적)

↔

UN R156
SUMS
(국제법규·가이드 수준)

↔

ISO 24089
(국제표준·산출물 명시)

세 문서가 서로를 완전히 포함하지 않기 때문에, 실무에서는 세 축을 모두 대조해 증빙 범위를 스스로 확정해야 합니다.

---

실무에서 이 구조가 만드는 문제

이론적으로는 "법 → SUMS → ISO 24089"로 내려가면서 점점 구체화되는 깔끔한 그림입니다. 그런데 현실에서는 세 문서가 서로 완전히 겹치지 않기 때문에, 다음과 같은 실무적 판단을 조직이 스스로 내려야 합니다.

현업에서 실제로 부딪히는 지점 5가지

"정상 작동"의 증빙 범위를 어디까지 잡을 것인가 — 법은 "모든 장치 및 기능"이라고 썼지만, ISO 24089는 "영향받는 시스템·기능에 대한 평가·확인·기록 절차 문서"를 요구합니다. 결국 영향 범위(scope) 판단 자체를 제작사가 정의하고, 그 정의가 타당했는지를 사후에 증명해야 하는 구조입니다.

롤백·실패 처리 절차의 문서화 수준 — 업데이트 실패 시 이전 버전으로 되돌리는 로직(Resume, Cancel, Retry, Rollback)은 ISO 24089 OTA 플로우에 명시돼 있지만, 이 절차가 자동차관리법상 "안전기준 적합성"을 어느 수준까지 만족해야 하는지는 법 조문만으로는 판단하기 어렵습니다. 2-bank 구조로 롤백을 구현했다는 사실 자체보다, "실패 시나리오별로 안전한 차량 상태가 무엇인지"를 사전에 정의해뒀는지가 감사에서 더 자주 걸리는 지점입니다.

TARA·HARA가 이제 SW 업데이트 감사의 필수 산출물이 됐다 — 사이버보안 위험 관리는 TARA로, 기능안전 위험 관리는 HARA로 근거를 남기라는 요구가 감사 가이드라인에 명시돼 있습니다. 기존에 CSMS·기능안전 인증을 위해 만들어둔 TARA·HARA 문서를 OTA 감사 시점에도 그대로 재사용할 수 있는지, 아니면 SW 업데이트 작업 관점에서 별도로 갱신해야 하는지를 조직 차원에서 미리 정리해둘 필요가 있습니다.

SRS/SADS/SUDS 설계 문서와의 정합성 — 감사 질문 대부분의 최종 근거는 결국 "SRS/SADS/SUDS 같은 설계 문서에 이 내용이 있는가"로 귀결됩니다. 즉 OTA 인증 대응은 별도 문서 작업이 아니라, 기존 설계 문서 체계 안에 사이버보안·기능안전·품질 요구사항이 처음부터 추적 가능하게 반영돼 있어야 감사 시점의 부담이 줄어듭니다.

자가인증이라는 무게 — CSMS처럼 사전에 승인기관이 봐주는 구조가 아니기 때문에, "이 정도면 충분하다"는 내부 판단 기준을 문서화하고 근거를 남겨두는 작업 자체가 감사·분쟁 상황에서 조직을 지키는 핵심 방어선이 됩니다.

법이 요구하는 건 결과입니다. 표준이 채워주는 건 과정입니다.

법과 표준 사이의 틈을 미리 메워두지 않으면, 그 틈을 메우는 역할은 결국 감사 시점의 실무자에게 넘어옵니다.

핵심 요약

1

자동차관리법 34조의5는 결과를 요구하지만 판단 기준어를 정의하지 않는다 — "모든", "정상", "적합" 등의 구체적 기준이 법 조문 안에는 없다.

2

UN R156(SUMS)도 완전한 답은 아니다 — 성능 수치가 아니라 프로세스 요건 중심이라 여전히 해석의 여지가 남는다.

3

ISO 24089가 실질적인 증빙 언어를 제공한다 — SUMS 조항을 구체적 산출물(work product)로 치환해주는 매핑 구조가 존재한다.

4

고시는 법의 침묵을 절반만 메운다 — "어떤 절차서를 준비하라"까지는 알려주지만, 그 절차서의 구체적 수준은 여전히 열려 있다.

5

실제 감사는 결국 TARA·HARA·SRS/SADS/SUDS 같은 구체적 산출물로 귀결된다 — 법 조문의 추상어가 실무에서는 기존 개발 산출물의 존재 여부로 치환된다.

6

SUMS는 CSMS와 달리 자가인증이다 — 사전에 승인기관이 기준을 확인해주지 않으므로, 내부 판단 근거의 문서화가 곧 방어선이 된다.

7

법·고시·SUMS·ISO 24089 네 문서를 전부 대조해야 증빙 범위가 확정된다 — 어느 한 문서만 보고 준비를 끝냈다고 판단하면 감사 시점에 공백이 드러날 수 있다.

※ 이 글은 2025~2026년 한국자동차공학회 학술대회 발표 자료 및 ISO 24089:2023, UN Regulation No. 156, 자동차관리법(법률 제21065호) 등 공개된 법령·표준 자료를 바탕으로 작성했습니다.

자동차관리법 34조의5 UN R156 SUMS ISO 24089 OTA 소프트웨어 업데이트 인증 자가인증 CSMS 규제 대응