제14부 시스템 설계·품질·운영
14.10 안전 표준과 ROS 2의 위치
14.10.1 이 장에서 배우는 것 / 선수 지식
이 책은 여러 장에서 같은 문장을 반복했다 — "이 책은 안전 인증에 관한 조언을 제공하지 않으며, 해당 판단은 표준과 전문가의 영역이다." 8.7(항법 안전), 9.6(매니퓰레이터), 12.1(실시간), 13.1(보안), 14.6(승인 시험), 14.9(다중 로봇)에서 그랬다.
이 장은 그 반복을 정면으로 정리한다. 다만 여기서도 결론은 같다 — 이 장은 안전 표준을 가르치지 않는다.
배우는 것:
- 왜 이 책이 그 선을 긋는가 — 정직한 이유.
- 현황 — 어떤 표준이 있고 무엇을 다루는지의 개관.
- ROS 2가 어디에 서는가 — 기능 안전 관점에서의 위치.
- 실무 구조 — 안전과 기능을 어떻게 나누는가.
- 개발자가 할 수 있는 것 — 전문가와 일하기 위한 준비.
이것은 안내가 아니라 지도다. 목적지로 데려다주지 않고, 어디에 무엇이 있는지만 보여준다.
선수 지식: 8.7(항법 안전), 9.6(조작 안전), 12.1(실시간), 13.1(보안), 14.2(오케스트레이션), 14.6(승인 시험).
정직: 이 장은 특정 표준의 요구사항·적용 판단·인증 절차를 서술하지 않는다. 표준의 정확한 내용은 원문을 구입해 읽어야 하고, 적용 여부와 방법은 자격 있는 안전 전문가·인증 기관이 판단한다. 이 장의 어떤 서술도 안전 근거로 인용되어서는 안 된다. 표준 번호·명칭은 개관 목적이며 정확성은 원문으로 확인해야 한다
(확인 필요). 이 환경에서 검증하지 않았다(목차 3).
14.10.2 왜 이 선을 긋는가
이 책이 안전 인증을 다루지 않는 이유는 겸양이 아니라 정확성이다.
| 이유 | 설명 |
|---|---|
| 적용이 맥락 의존적 | 같은 기술도 용도·환경에 따라 요구가 다름 |
| 판단에 자격이 필요 | 위험 평가는 훈련된 사람의 일 |
| 잘못된 안내의 결과가 큼 | 사람이 다칠 수 있음 |
| 표준은 해석을 동반 | 문언만으로 결정되지 않음 |
| 책은 책임을 질 수 없다 | 문서가 검증을 대체하지 못함 |
| 지역·시기별 차이 | 규제가 다르고 개정됨 |
견해: "이 책을 읽고 안전 설계를 했다"는 상황이 이 책이 만들 수 있는 최악의 결과다. 기술적 내용은 검증할 수 있지만, 안전은 조직·절차·검증·책임이 함께 있어야 성립한다. 이 책은 그중 어느 것도 제공하지 않는다.
견해: 동시에 "안전은 내 일이 아니다"라고 미루는 것도 틀렸다. 개발자는 시스템을 만드는 사람이므로, 안전 요구가 무엇을 뜻하고 어떻게 설계에 반영되는지 이해해야 전문가와 대화할 수 있다. 이 장의 목적이 그 대화의 준비다.
14.10.3 현황 개관
어떤 종류의 표준이 있는지에 대한 개관이다(확인 필요: 정확한 범위·번호는 원문 확인).
| 영역 | 대표적으로 언급되는 것 |
|---|---|
| 기능 안전 일반 | IEC 61508 계열 |
| 기계류 제어 | ISO 13849·IEC 62061 계열 |
| 산업용 로봇 | ISO 10218 계열 |
| 협동 로봇 운용 | ISO/TS 15066 |
| 이동 로봇·AGV | 관련 표준군 |
| 서비스 로봇 | 관련 표준군 |
| 차량 | ISO 26262 등 |
| 사이버보안 | IEC 62443·관련 규격 |
정직: 위 표는 "이런 것들이 존재한다"는 개관일 뿐이며, 어떤 표준이 당신의 시스템에 적용되는지는 이 표로 판단할 수 없다. 용도·설치 국가·판매 방식·사용자에 따라 달라지고, 여러 표준이 동시에 적용되기도 한다.
공통적으로 나타나는 개념들:
| 개념 | 대략적 의미 |
|---|---|
| 위험 평가 | 위해 요인을 식별하고 위험을 평가 |
| 위험 감소 | 설계·보호 장치·정보 순의 우선순위 |
| 안전 기능 | 위험을 줄이기 위한 특정 기능 |
| 무결성 수준 | 안전 기능에 요구되는 신뢰도 등급 |
| 검증·타당성 확인 | 요구대로 만들었나·의도대로 동작하나 |
| 문서화 | 근거의 기록 |
견해: "위험 감소의 우선순위"가 개발자가 가장 먼저 이해할 개념이다. 대체로 ① 본질적 설계로 위험 제거 → ② 보호 장치·안전 기능 → ③ 사용자 정보·훈련 순으로 다뤄지며, 소프트웨어는 대개 ②에 속한다. 즉 소프트웨어로 해결하기 전에 기계적·구조적으로 위험을 줄일 수 있는지 묻는 것이 순서다.
견해: "무결성 수준"이라는 개념이 ROS 2 논의의 핵심이다. 안전 기능에는 요구되는 신뢰도 등급이 있고, 그 등급을 만족하려면 개발 프로세스·검증·아키텍처에 대한 요구가 따라온다. 범용 OS와 대규모 오픈소스 스택이 그 요구를 만족하기 어렵다는 것이 14.10.4의 논점이다.
14.10.4 ROS 2는 어디에 서는가
정직한 평가다.
| 질문 | 답 |
|---|---|
| ROS 2가 안전 인증을 받았는가 | 일반적으로 아니다(확인 필요: 특수 구성) |
| 리눅스가 안전 인증 대상인가 | 일반 배포판은 그렇지 않다 |
| ROS 2로 안전 기능을 구현할 수 있는가 | 일반적으로 그렇게 하지 않는다 |
| ROS 2를 안전 관련 시스템에 쓸 수 있는가 | 구조에 따라 가능 |
왜 어려운가:
| 요인 | 설명 |
|---|---|
| 규모·복잡도 | 검증해야 할 코드가 방대 |
| 비결정성 | 실행 순서·타이밍(12.5) |
| 범용 OS | 리눅스의 복잡도(12.2) |
| 의존성 사슬 | 수많은 서드파티(14.7) |
| 개발 프로세스 | 표준이 요구하는 추적성 |
| 동적 구성 | 런타임 그래프 변경(1.1·1.13) |
견해: "ROS 2는 안전하지 않다"가 아니라 "ROS 2는 안전 무결성 논증의 대상으로 설계되지 않았다"가 정확한 표현이다. 잘 만든 ROS 2 시스템은 신뢰성 있게 동작하지만, 그것을 표준이 요구하는 방식으로 논증하는 것은 다른 문제다.
정직: 안전 인증을 목표로 하는 ROS 관련 활동·프로젝트가 존재해 왔다
(확인 필요: 현재 상태·범위). 이 영역은 변화가 있으므로, 해당 요구가 있다면 현재 상태를 조사하고 전문가와 검토할 가치가 있다. 다만 "어떤 프로젝트가 있으니 우리 시스템도 인증 가능하다"는 추론은 성립하지 않는다.
14.10.5 실무 구조 — 분리
업계에서 널리 쓰이는 구조다.
| 계층 | 역할 |
|---|---|
| 기능 계층 | 무엇을 할지 결정 — 복잡·유연·비인증 |
| 안전 계층 | 위험한 일이 일어나지 않게 — 단순·독립·인증 부품 |
이 구조의 핵심 성질:
| 성질 | 설명 |
|---|---|
| 기능 계층이 침해·오작동해도 | 안전 계층이 여전히 작동 |
| 안전 계층은 단순 | 검증 가능한 크기 |
| 독립성 | 공통 원인 고장 회피 |
| 일방향 의존 | 안전이 기능에 의존하지 않음 |
견해: 이 책이 여러 장에서 "독립 하드웨어 안전 경로"를 반복한 이유가 이것이다(8.7.7·12.1.6·13.1.4·14.2.5·14.9.5). 소프트웨어 스택이 아무리 잘 만들어져도, 안전을 그것에 의존시키면 전체를 안전 무결성 수준으로 논증해야 하는데 그것이 현실적으로 어렵다. 분리하면 논증 대상이 작아진다.
견해: 개발자 입장에서 이 구조의 의미는 "안전 계층을 우회하는 설계를 하지 말라"는 것이다. 안전 감시가 답답하다고 소프트웨어로 무력화하거나, 안전 기능을 ROS 토픽에 의존시키면 구조가 무너진다. 안전 계층의 제약을 전제로 기능을 설계해야 한다.
정직: 어떤 부품이 어떤 등급으로 인증되었고 어떻게 구성해야 하는지는 전문가의 설계 영역이다. 위 그림은 개념적 구조일 뿐이며, 구체적 설계는 위험 평가 결과에 따라 결정된다.
14.10.6 소프트웨어가 기여하는 부분
안전 계층 밖에서도 소프트웨어가 위험을 줄일 수 있다.
| 조치 | 성격 |
|---|---|
| 속도·가속 제한 | 제어 계층에서 강제(8.7.5·13.1.9) |
| 작업 공간 제한 | 기하학적 경계(9.4) |
| 입력 검증 | 비정상 명령 거부(13.1.9) |
| 신선도 검사 | 오래된 데이터로 동작 안 함(7.7.7) |
| 상태 기계 강제 | 허용된 전이만(1.12·14.2.7) |
| 강등·안전 정지 | 이상 시 보수적 동작(14.2.6) |
| 감시·진단 | 조기 발견(6.9) |
| 기록 | 사후 분석(11.3) |
견해: 이런 조치는 "안전 기능"으로 논증되지 않더라도 실질적으로 위험을 줄인다. 표준상 안전 기능으로 인정받는 것과, 실제로 사고 가능성을 낮추는 것은 다른 층위다. 둘 다 필요하다 — 인증된 안전 계층이 있어도, 소프트웨어가 함부로 움직이면 가동 중단과 손상이 잦아진다.
함정: 이런 조치를 "안전 기능"이라고 부르지 말라. 내부 문서나 대화에서 용어를 혼용하면, 나중에 "우리는 안전 기능이 있다"는 잘못된 인식이 생긴다. "위험 완화 조치"와 "인증된 안전 기능"을 언어에서부터 구분하는 것이 중요하다.
14.10.7 개발자가 준비할 것
전문가와 일하기 위한 준비다.
| 준비 | 내용 |
|---|---|
| 시스템 구조 문서 | 무엇이 무엇을 제어하는가 |
| 동작 명세 | 정상·이상 시 거동 |
| 인터페이스 목록 | 명령 경로·센서 경로(14.1.5) |
| 고장 모드 목록 | 무엇이 어떻게 실패하는가 |
| 실패 시 거동 | 각 고장에서 무엇이 일어나는가 |
| 제한 값 | 속도·힘·범위와 그 강제 지점 |
| 시험 결과 | 무엇을 어떻게 검증했나(14.6) |
| 변경 이력 | 추적성 |
견해: "고장 모드 목록"을 만드는 작업 자체가 개발자에게 가치가 크다. "센서가 고장 나면?", "통신이 끊기면?", "노드가 종료되면?", "값이 NaN이면?" — 이 질문들에 답을 적다 보면 설계의 공백이 드러난다. 안전 논의가 아니더라도 할 만한 일이다(14.2.6·14.5.7과 연결).
견해: "제한 값이 어디서 강제되는가"를 명확히 하라. 최대 속도가 파라미터에만 있고 코드에서 클램프하지 않으면, 파라미터를 바꾸면 제한이 사라진다(13.1.5). 강제 지점을 하드웨어에 가깝게 두는 것(13.1.9)이 논증과 실질 둘 다에 유리하다.
견해: 문서를 "인증을 위해" 만들지 말고 "이해를 위해" 만들라. 실제 구조와 다른 문서는 검토 과정에서 드러나고 신뢰를 잃는다. 개발 중에 유지되는 지속 갱신 문서가 결국 쓸모 있다.
14.10.8 흔한 오해
| 오해 | 정정 |
|---|---|
| "소프트웨어를 잘 만들면 안전하다" | 무결성 논증은 품질과 다른 축 |
| "RT 커널을 쓰면 안전 인증에 가까워진다" | 실시간과 안전은 다른 문제(12.1) |
| "비상정지를 구현했으니 안전하다" | 구현 방식·독립성·등급이 관건 |
| "오픈소스라 인증이 불가능하다" | 라이선스가 아니라 논증 가능성의 문제 |
| "시뮬에서 충돌이 없으니 안전하다" | 시뮬의 경계(10.1.3·10.6.7) |
| "우리 로봇은 작아서 위험하지 않다" | 위험 평가로 판단할 일 |
| "보안과 안전은 별개다" | 보안 침해가 안전을 해칠 수 있다(13.1.3) |
| "표준을 읽으면 할 수 있다" | 해석·경험·자격이 필요 |
견해: "비상정지를 구현했다"는 말이 특히 위험하다. ROS 토픽으로 정지 명령을 보내는 것과, 인증된 안전 부품으로 구동 전원을 차단하는 것은 완전히 다른 것인데 같은 이름으로 불린다(8.7.7). 용어를 구분해 쓰는 것이 오해를 막는다.
견해: "보안과 안전이 만나는 지점"을 인식하라(13.5.8). 침해로 로봇이 위험하게 움직일 수 있다면, 보안은 안전 문제의 일부가 된다. 최근 규제 논의에서 이 연결이 강조되는 추세이며
(확인 필요: 구체적 규제), 양쪽을 함께 다루는 것이 필요하다.
14.10.9 제14부를 마치며
제14부가 반복한 것은 셋이다.
- 경계가 설계의 본질이다. 노드 경계(14.1), 인터페이스(14.1.5), launch 계층(14.4), 시험 층위(14.5), 안전과 기능의 분리(14.10). 어디에 선을 긋는가가 시스템의 성질을 결정한다.
- 자동화되지 않은 것은 규모에서 무너진다. 수동 점검·수동 배포·수동 프로비저닝은 한 대에서는 되지만 스무 대에서는 병목이 된다(14.8·14.9). 수작업으로 하던 것을 코드로 옮기는 것이 규모 준비의 실체다.
- 한계를 명시하라. 시험하지 않는 영역(14.6.8), 수용한 위험(13.5.7), 안전 논증의 범위(14.10). 모르는 것과 안 하는 것을 아는 것이 시스템을 실제로 안전하게 만든다.
14.10.10 함정 카탈로그
| # | 함정 | 결과 | 대처 |
|---|---|---|---|
| 1 | 책·블로그로 안전 설계 | 위험 | 전문가·표준 원문 |
| 2 | "안전은 내 일 아님" | 설계 공백 | 이해하고 대화 |
| 3 | 안전을 SW 스택에 의존 | 논증 불가·우회 가능 | 독립 계층 |
| 4 | 안전 계층 우회 설계 | 구조 무너짐 | 제약 전제 설계 |
| 5 | "안전 기능" 용어 혼용 | 잘못된 인식 | 언어 구분 |
| 6 | 비상정지를 토픽으로만 | 위험 | 독립 회로 |
| 7 | 제한을 파라미터에만 | 무력화 가능 | 코드 클램프 |
| 8 | 시뮬 결과를 안전 근거로 | 과신 | 경계 인식 |
| 9 | 고장 모드 미정리 | 이상 시 미정의 동작 | 목록화 |
| 10 | 문서를 형식으로만 | 신뢰 상실 | 지속 갱신되는 문서 |
| 11 | 보안과 안전 분리 취급 | 침해가 안전 위협 | 함께 다룸 |
| 12 | 이 책을 근거로 인용 | 부적절 | 원문·전문가 |
14.10.11 체크포인트
- 이 책이 안전 인증을 다루지 않는 여섯 이유를 말할 수 있는가.
- "안전은 내 일이 아니다"가 왜 틀린가.
- 안전 표준 현황의 다섯 영역을 개관할 수 있는가.
- 공통적으로 나타나는 개념 여섯 가지는?
- "위험 감소의 우선순위"에서 소프트웨어가 위치하는 곳과 그 함의는?
- ROS 2의 안전 관련 네 질문에 답할 수 있는가.
- ROS 2가 안전 무결성 논증에 어려운 요인 여섯 가지는?
- "ROS 2는 안전하지 않다"와 "논증 대상으로 설계되지 않았다"의 차이는?
- 기능 계층과 안전 계층 분리 구조의 네 성질은?
- 이 구조가 개발자에게 주는 실무적 의미는?
- 소프트웨어가 위험을 줄이는 여덟 조치와, 용어 구분의 중요성은?
- 전문가와 일하기 위한 준비 여덟 항목을 들 수 있는가.
- "고장 모드 목록"이 개발자에게 주는 가치는?
- 제한 값 강제 지점을 하드웨어에 가깝게 두는 이유는?
- 흔한 오해 여덟 가지를 정정할 수 있는가.
- "비상정지를 구현했다"가 특히 위험한 이유는?
- 제14부가 반복한 세 원칙을 말할 수 있는가.
여기까지가 제14부 시스템 설계·품질·운영이다. 경계(14.1), 조율(14.2), launch(14.3·14.4), 시험(14.5·14.6), 품질(14.7), 배포(14.8), 플릿(14.9), 그리고 안전의 지도(14.10).
이 책의 본문은 거의 끝났다. 남은 것은 시간 축의 문제다 — 배포판은 EOL이 오고, 코드는 이행해야 하고, 생태계는 계속 바뀐다. 이미 만든 시스템을 어떻게 지속 운영할 것인가. 제15부 이행·확장(15.1~15.5) 의 주제다.