제13부 보안
13.5 보안의 비용 — 성능·운영 트레이드오프
13.5.1 이 장에서 배우는 것 / 선수 지식
보안 논의는 대개 "해야 한다" 로 끝난다. 그런데 실무에서는 그다음 질문이 온다 — "그래서 무엇을 포기해야 하는가?"
정직하게 말하면 보안에도 비용이 든다. 성능이 떨어지고, 개발이 느려지고, 운영이 복잡해지고, 새로운 실패 모드가 생긴다. 이 비용을 인정하지 않고 도입하면 팀이 우회하기 시작한다 — 보안을 끄고 개발하고, 켜는 것을 잊고 배포하고, 결국 있으나 마나 한 상태가 된다.
이 장은 비용을 정직하게 나열하고, 그 위에서 어디까지 할지 판단하는 방법을 다룬다. 제13부의 결론이기도 하다.
배우는 것:
- 성능 비용 — 어디서 얼마나.
- 개발 비용 — 생산성 영향.
- 운영 비용 — 지속적 부담.
- 새로운 실패 모드 — 보안이 만드는 장애.
- 단계적 도입 — 현실적 경로.
- 판단 틀 — 어디까지 할 것인가.
선수 지식: 13.1~13.4(제13부 전체), 11.7(측정), 12.4(지연 예산), 3.6(선택의 절차 — 같은 구조).
정직: 성능 영향의 크기는 하드웨어·메시지 크기·빈도·보호 수준에 따라 자릿수가 다르므로 수치를 제시하지 않는다(3.6.1). 자신의 시스템에서 측정하는 방법을 제공한다. 보안 수준의 최종 결정은 위험 평가와 조직 정책·전문가 판단의 영역이다(13.1.1). 이 환경에서 검증하지 않았다(목차 3). 142차가 이 절의 "측정 방법"을 그대로 따라 이 환경 하나에서 실제로 측정해 봤다 — 아래 13.5.2의 실행 확인 블록을 보라. 이 수치는 이 컨테이너·이 조건에서만 유효하며, 위 정직 고지가 말하는 "자릿수가 다를 수 있다"는 경고를 대체하지 않는다.
13.5.2 성능 비용
| 비용 | 영향받는 것 |
|---|---|
| ① 핸드셰이크 | 시작 시간·재연결 |
| ② 암호화 | CPU — 데이터 크기 비례 |
| ③ 서명·검증 | CPU |
| ④ 크기 증가 | 대역·직렬화(1.3.9) |
| ⑤ 최적화 제약 | 제로 카피·공유 메모리(확인 필요) |
| ⑥ 지연 | ②③④의 합 |
어디서 크게 나타나는가:
| 상황 | 영향 |
|---|---|
| 대용량 고빈도 토픽 | 가장 큼 — 이미지·포인트클라우드 |
| 소형 저빈도 | 작음 |
| 노드 수가 많음 | 핸드셰이크 누적 |
| 잦은 재시작 | 시작 지연 반복 |
| 제한된 CPU | 임베디드에서 두드러짐 |
견해: "대용량 데이터를 암호화할 것인가"가 성능 판단의 핵심이다. 카메라·라이다 원본을
ENCRYPT하면 비용이 크고, 그 데이터의 기밀성이 정말 필요한지는 위협 모델(13.1)에 달렸다. 토픽별 차등 설정(13.3.4)이 이 문제의 해법이다.
견해: 명령·상태 토픽은 작아서 암호화 비용이 작다. 그런데 보호 가치는 가장 크다(13.1.3). 즉 비용 대비 효과가 가장 좋은 곳부터 보호하면 된다 — 명령 경로를 엄격히, 대용량 센서를 상황에 따라.
측정 방법(11.7의 적용):
| 측정 | 비교 |
|---|---|
| 종단 지연 p99 | 보안 off vs on |
| CPU 사용률 | 노드별 |
| 대역 | 토픽별 |
| 시작 시간 | 전체 그래프 준비까지 |
| 최대 처리 가능 빈도 | 한계 |
견해: 12.4의 지연 예산을 보안 활성 상태에서 다시 세우라(13.3.7의 반복). 보안 없이 세운 예산은 실제 운영에서 무효다. 보안이 요구사항이면 처음부터 켜고 측정하는 것이 옳다.
실행 확인(142차,
ros:jazzy-ros-base·ros:humble-ros-base) — "① 핸드셰이크" 비용을 실제로 측정했다. 위 "시작 시간" 측정 항목을 그대로 따라demo_nodes_cpp의talker+listener를 launch하고, 프로세스 시작부터 첫"I heard"로그까지의 시간을 보안 off/on 각각 반복 측정했다(13.2의 키스토어·enclave를 재사용,ROS_SECURITY_STRATEGY=Enforce).
배포판 보안 off 보안 on 표본 Jazzy 평균 687 ms·중앙값 688 ms(sd 50) 평균 1020 ms·중앙값 1132 ms(sd 230) 각 10회 Humble 평균 420 ms·중앙값 451 ms(sd 59) 평균 1149 ms·중앙값 1151 ms(sd 10) 각 6회 보안을 켜면 "첫 메시지까지"가 뚜렷하게 늘어난다 — Humble은 거의 겹치지 않는 두 분포(off 340~466 ms, on 1133~1159 ms, Welch t≈30)로 갈렸고, Jazzy도 방향은 같지만 편차가 커서(on 쪽 sd 230) 신호가 덜 명확했다(Welch t≈4.5, 여전히 유의한 수준). 정직하게 밝힌다 — 이 수치는
demo_nodes_cpp의 1 Hz 발행 주기가 만드는 양자화 잡음을 포함하고(off 조건도 최소 수백 ms의 "다음 발행까지 대기"가 섞여 있다), DDS-Security 핸드셰이크 자체만 분리해 측정한 것이 아니라 "핸드셰이크 + 첫 발행까지의 대기"를 합쳐 측정한 것이다. 그래도 off/on 두 조건에 같은 잡음이 동일하게 섞이므로 차이(추가된 수백 ms)는 실재하는 신호로 본다. 이 컨테이너·이 조건(단일 호스트, 메시지 1개, 노드 2개)에서의 값일 뿐이며, 대용량·고빈도·다수 노드에서는 이 절이 이미 경고한 대로 자릿수가 달라질 수 있다(확인 필요). 하네스는tools/gap_harness/gap142/. 목차 3.
실행 확인(143차) — 이 절이 "가장 크다"고 지목한 조건("대용량 고빈도 토픽")의 "② 암호화" 비용을 직접 측정했다. 자체 발행자·구독자(
gap143_secpub)로 1 MBstd_msgs::String을 10 Hz로 30개씩 발행·수신하며, 각 프로세스의 사용자+시스템 CPU 시간(/usr/bin/time -v)과 종단 지연을 보안 off/on으로 반복 측정했다(Jazzy·Humble 각 3·2회 반복).
배포판 항목 off on 배율 Jazzy 발행자 user CPU 평균 0.057s 평균 0.150s 2.65배 Jazzy 구독자 user CPU 평균 0.130s 평균 0.247s 1.90배 Jazzy 종단 지연(평균) 5859 µs 9678 µs 1.65배 Humble 발행자 user CPU 평균 0.050s 평균 0.160s 3.20배 Humble 구독자 user CPU 평균 0.090s 평균 0.260s 2.89배 Humble 종단 지연(평균) 5139 µs 9905 µs 1.93배 양쪽 배포판, 양쪽 프로세스(발행자·구독자), 반복마다 방향과 크기가 일관됐다 — 보안을 켜면 CPU 시간이 대략 2~3배, 종단 지연이 대략 1.7~1.9배로 늘었다. 이 절의 "① 핸드셰이크 비용"(142차)이 시작 시 한 번의 비용이었다면, 이것은 정상 상태에서 메시지마다 반복되는 비용이다 — 13.5.2의 "대용량 고빈도 토픽이 가장 크다"는 서술과 정확히 들어맞는다. 방법론 메모: 초기 실험에서 마지막 발행 직후 프로세스를 바로 종료하면 대용량(프래그먼트된) 메시지의 RELIABLE 전달이 완료되기 전에 끊겨 메시지가 유실됐다(발행 후 종료 전 유예 시간을 두고, 발행자가
get_subscription_count()로 실제 매칭을 확인한 뒤에만 발행을 시작하도록 고쳐 해결 — 재현 방법 문서에 남김). 하네스는tools/gap_harness/gap143/. 확인하지 못한 것: 서명 전용(암호화 없이 인증만) 조건은 분리해 측정하지 않았다(확인 필요), 반복 횟수가 적어(3·2회) 통계적 유의성 검정은 하지 않았다. 목차 3.
13.5.3 개발 비용
개발 생산성에 미치는 영향이 성능보다 크게 느껴질 수 있다.
| 비용 | 설명 |
|---|---|
| 도구가 연결되지 않음 | RViz2·rqt·ros2 topic echo에 자료 필요 |
| 새 노드 추가 시 정책 갱신 | 개발 흐름에 마찰 |
| 디버깅 어려움 | 실패 원인이 불명확(13.2.9) |
| 초기 학습 | 개념·도구 습득 |
| 키 관리 부담 | 개발자마다 |
| 시험 환경 복잡화 | CI에도 자료 필요 |
견해: "개발 중에는 보안을 끈다"가 현실적이고 옳다(13.1.10). 문제는 운영과의 전환이 확실한가이다. 전환을 사람 손에 맡기면 실수하므로, launch·이미지 빌드 수준에서 자동으로 갈리게 해야 한다(13.4.8).
견해: 정책 갱신을 개발 흐름에 통합하라. 새 토픽을 추가할 때마다 정책을 수동으로 고치면 마찰이 크고 빠뜨린다. 정책 생성을 빌드·시험 파이프라인의 일부로 만들고, 통합 시험에서 정책 누락을 획득하면(14.6) 마찰이 준다.
함정: "보안 켜면 안 돼서" 임시로 끄고 그대로 배포되는 것이 가장 흔한 실패다. 그래서 켠 상태의 시험을 CI에 넣어 상시 동작을 보장하는 것이 중요하다 — 켠 상태가 깨져 있는 것을 배포 직전에 알면 늦다.
13.5.4 운영 비용
지속적으로 드는 부담이다.
| 비용 | 주기 |
|---|---|
| 인증서 갱신 | 만료 주기마다(13.2.8) |
| 키 배포·프로비저닝 | 로봇 추가·교체 시 |
| 정책 유지보수 | 기능 변경 시 |
| CA 운영 | 지속 |
| 침해 대응 준비 | 지속 |
| 패치 적용·재검증 | 지속(13.4.6) |
| 접근 권한 관리 | 인원 변동 |
| 감사·점검 | 주기적 |
견해: 운영 비용이 도입 비용보다 크게 누적된다. SROS 2를 켜는 것은 한 번이지만, 인증서를 갱신하고 정책을 유지하고 키를 배포하는 일은 영원히 계속된다. 이것을 감당할 조직 역량이 있는지가 도입 판단의 실질적 기준이다.
견해: 자동화되지 않은 보안은 시간이 지나면 무너진다. 사람이 매번 수동으로 하는 절차는 바쁠 때 건너뛰어지고, 그 상태가 굳는다. 키 발급·갱신·배포·점검을 파이프라인에 넣는 것(14.8)이 지속 가능성의 조건이다.
함정: 인증서 만료가 대규모 장애를 만든다(13.2.10의 8번). 여러 로봇의 인증서가 비슷한 시기에 만료되면 동시에 통신이 끊긴다. 만료 감시와 갱신 자동화가 없으면 언젠가 이 사고가 난다.
13.5.5 새로운 실패 모드
보안 자체가 장애의 원인이 된다.
| 실패 모드 | 영향 |
|---|---|
| 인증서 만료 | 전체 통신 중단 |
| 시계 오차 | 인증 실패(13.2.9) |
| 정책 누락 | 부분 기능 상실 |
| 키 분실 | 복구 불가 — 재프로비저닝 |
| CA 침해 | 전체 신뢰 재구축 |
| 설정 오류 | 진단 어려움 |
견해: "보안이 가용성을 해칠 수 있다"는 것을 설계에 반영하라. 인증 실패로 로봇이 통신하지 못하면 그것도 운영 중단이다. 만료 경보·시계 감시·복구 절차를 미리 갖추는 것이 도입의 일부여야 한다.
견해: 키 분실 대비를 잊지 말라. 백업이 없으면 재프로비저닝이 필요하고, 현장 로봇이라면 물리적 방문이 필요할 수 있다. 백업 자체가 또 다른 위험이므로, 이 균형은 보안 전문가와 설계할 사항이다.
함정: 보안 관련 장애는 진단이 어렵다(13.2.9·13.3.8). 증상이 "노드가 안 보인다"로만 나타나 QoS·네트워크 문제와 구분이 안 된다. 보안을 끄고 비교하는 절차를 진단 플레이북(11.1)에 넣어 두라.
13.5.6 단계적 도입
한 번에 전부 하려 하면 실패한다.
| 단계 | 비용 | 효과 |
|---|---|---|
| 0 위협 모델 | 낮음 | 방향 결정 |
| 1 네트워크 | 낮음 | 높음 |
| 2 강화·비밀 | 낮음~중간 | 높음 |
| 3 앱 방어 | 낮음 | 중간~높음 |
| 4 SROS 2 부분 | 중간 | 높음 |
| 5 전면 | 높음 | 높음 |
| 6 자동화 | 중간 | 지속 가능성 |
견해: 0~3단계가 비용 대비 효과가 가장 좋다. 위협 모델을 세우고, 네트워크를 분리하고, 시스템을 강화하고, 애플리케이션에서 입력을 검증하는 것 — 이것만으로도 위험이 크게 준다. SROS 2 없이도 상당한 수준에 도달할 수 있다.
견해: 4단계에서 "명령 경로 우선"이 핵심이다(13.2.7). 모든 토픽에 정책을 만들려 하지 말고,
/cmd_vel·모드 변경·안전 관련 서비스부터 통제하면 가장 큰 위험이 먼저 줄어든다.
견해: 6단계(자동화)를 마지막이 아니라 병행으로 두라. 각 단계를 도입할 때마다 그것을 유지하는 자동화를 함께 만들지 않으면, 나중에 전부 수동으로 하는 상태에서 자동화하기가 더 어렵다.
13.5.7 판단 틀
어디까지 할 것인가.
| 요인 | 질문 |
|---|---|
| 위해 가능성 | 사람 근처에서 움직이는가 |
| 운영 환경 | 공용 공간·통제된 구역 |
| 네트워크 노출 | 외부 연결이 있는가 |
| 데이터 민감도 | 카메라·개인정보·기밀 |
| 규제 요구 | 적용되는 규정이 있는가 |
| 로봇 대수 | 규모의 위험 |
| 조직 역량 | 유지할 수 있는가 |
| 원격 접근 | 있는가 |
| 상황 | 권장 접근 |
|---|---|
| 연구실·격리 환경 | 0~2단계 + 수용 위험 문서화 |
| 통제 구역 산업 로봇 | 0~4단계 |
| 공용 공간·사람 근처 | 전면 + 전문가 검토 |
| 원격 접근 있음 | 원격 경로 강한 통제 필수 |
| 규제 대상 | 전문가·규정 우선 |
| 다수 플릿 | 자동화 필수 |
견해: "조직 역량"을 판단 요인에 넣은 것이 중요하다. 유지할 수 없는 보안 체계는 도입 직후부터 무너지기 시작하고, 보안이 있다는 착각만 남는다. 감당 가능한 수준에서 시작해 확대하는 것이 실질적으로 더 안전하다.
견해: 수용한 위험을 문서로 남기라(13.1.6). "현재는 격리 환경이라 SROS 2를 적용하지 않는다"는 결정 자체는 문제가 아니다. 그 결정과 전제가 기록되지 않아, 환경이 바뀌어도 재검토되지 않는 것이 문제다.
정직: 이 판단 틀은 대화의 출발점이며 결론이 아니다. 규제 대상이거나 위해 가능성이 큰 시스템은 보안·안전 전문가의 평가가 필요하며, 이 책은 그것을 대체하지 않는다(13.1.1).
13.5.8 제13부를 마치며
제13부가 반복한 것은 셋이다.
- 기본 상태는 완전 개방이다. 같은 도메인에 도달할 수 있으면 모든 데이터를 읽고 모든 명령을 보낼 수 있다. 이것을 알고 시작하는 것이 출발점이다(13.1.2).
- 로봇 보안의 1순위는 물리적 제어 경로다. 출력이 물리적이라는 점이 로봇을 일반 IT 시스템과 구분한다. 데이터 암호화보다 "누가 명령을 보낼 수 있는가" 가 먼저다(13.1.3·13.2.7).
- 보안은 비용을 수반하며, 감당 못 할 체계는 무너진다. 성능·개발·운영 비용을 정직하게 계산하고, 단계적으로 도입하고, 자동화로 유지하라(13.5.4·13.5.6).
그리고 이 부가 다른 부와 만나는 지점 — 안전(8.7)과 보안이 독립적인 하드웨어 안전 경로에서 만나고, 실시간(12.1)과는 성능 비용에서 만나며, 관측성(11.3)과는 기록의 프라이버시에서 만난다. 보안은 별도 기능이 아니라 시스템 설계 전반에 걸친 관점이다.
13.5.9 함정 카탈로그
| # | 함정 | 증상 | 대처 |
|---|---|---|---|
| 1 | 비용 인정 안 함 | 팀이 우회 | 정직한 계산 |
| 2 | 대용량 토픽 전면 암호화 | 성능 저하 | 토픽별 차등 |
| 3 | 보안 전 성능 예산 사용 | 예산 무효 | 켠 상태 측정 |
| 4 | 개발/운영 전환을 수동으로 | 배포 실수 | 자동 분기 |
| 5 | 정책 갱신이 개발 마찰 | 우회·누락 | 파이프라인 통합 |
| 6 | 켠 상태 시험 없음 | 배포 직전 발견 | CI에 포함 |
| 7 | 운영 비용 과소평가 | 유지 실패 | 역량 판단 |
| 8 | 수동 절차 의존 | 시간이 지나 무너짐 | 자동화 |
| 9 | 인증서 만료 동시 발생 | 대규모 장애 | 감시·분산 갱신 |
| 10 | 키 백업 없음 | 복구 불가 | 백업 설계(전문가) |
| 11 | 보안 장애 진단 절차 없음 | 장시간 혼란 | 플레이북에 포함 |
| 12 | 한 번에 전면 도입 | 실패·롤백 | 단계적 |
| 13 | 명령 경로를 나중에 | 최대 위험 방치 | 우선 적용 |
| 14 | 수용 위험 미문서화 | 재검토 안 됨 | 기록 |
| 15 | 역량 초과 체계 도입 | 보안 착각 | 감당 가능 수준 |
13.5.10 체크포인트
- 보안 비용을 인정하지 않으면 팀에 무슨 일이 일어나는가.
- 성능 비용 다섯 가지와, 가장 크게 나타나는 상황은?
- "비용 대비 효과가 가장 좋은 보호 대상"은 무엇이며 왜인가.
- 보안 활성 상태에서 지연 예산을 다시 세워야 하는 이유는?
- 개발 비용 여섯 가지와, "개발 중 보안 비활성"이 옳은 조건은?
- 정책 갱신 마찰을 줄이는 방법은?
- 운영 비용 여덟 가지와, "도입 비용보다 크게 누적된다"의 의미는?
- 자동화되지 않은 보안이 무너지는 이유는?
- 보안이 만드는 새로운 실패 모드 여섯 가지를 들 수 있는가.
- "보안이 가용성을 해칠 수 있다"를 설계에 어떻게 반영하는가.
- 단계적 도입의 일곱 단계와, 비용 대비 효과가 가장 좋은 구간은?
- 4단계에서 "명령 경로 우선"이 핵심인 이유는?
- 자동화를 마지막이 아니라 병행으로 두라는 조언의 근거는?
- 보안 수준 판단의 여덟 요인과, "조직 역량"을 포함시킨 이유는?
- 수용한 위험을 문서화해야 하는 이유는?
- 제13부가 반복한 세 원칙을 말할 수 있는가.
여기까지가 제13부 보안이다. 위협 모델(13.1), SROS 2(13.2), DDS-Security(13.3), 운영 보안(13.4), 비용 판단(13.5).
지금까지 이 책은 부분들을 다뤘다 — 통신, 실행, 좌표, 하드웨어, 인지, 항법, 조작, 시뮬, 도구, 실시간, 보안. 이제 남은 질문은 그것들을 어떻게 하나의 시스템으로 조립하고, 검증하고, 운영할 것인가이다. 노드를 어디서 나눌 것인가, 어떻게 부팅하고 감시할 것인가, 무엇을 어떻게 시험할 것인가, 어떻게 배포하고 여러 대를 운영할 것인가. 제14부 시스템 설계·품질·운영(14.1~14.10) 의 주제다.