개념
기능안전이 답하지 못하는 질문
모듈 35 에서 기능안전을 다뤘다. 그 체계의 질문은 "고장이 났을 때 안전한가" 다. 센서가 죽으면, 연산이 틀리면, 신호가 끊기면 — 안전한 상태로 가는가.
자율주행에서는 그 질문으로 덮이지 않는 위험이 있다. 레슨 1 의 마지막에서 본 상황이다 — 세 단계 모두 명세대로 동작했는데 결과가 위험한 경우.
예를 들면 이렇다.
- 카메라가 사양 범위 안에서 정상 동작 했다. 그런데 역광에서 대비가 부족해 정지한 차량을 구분하지 못했다. 고장이 아니다. 성능의 한계 다
- 차선 인식이 설계대로 동작했다. 그런데 공사 구간의 지워진 옛 차선 을 유효한 차선으로 읽었다. 고장이 아니다. 상황이 설계 전제를 벗어났다
- 기능이 의도대로 작동했다. 그런데 운전자가 그것을 완전 자율로 오해 해 주의를 놓았다. 고장이 아니다. 예상 가능한 오사용 이다
이 세 가지가 의도된 기능의 안전(SOTIF) 이 다루는 영역이다. 공개 자료는 ISO 21448 을 기능 부족(functional insufficiency) 에서 비롯되는 안전 위험 — 센서·알고리즘·시스템 논리가 설계대로 정확히 동작하는데도 성능 한계나 불완전한 시나리오 커버리지로 인해 위험한 결과를 내는 상황 — 을 다루는 규격으로 설명한다(2022년 발행).
각 조항의 요구 문장, 용어의 정확한 정의, 요구되는 활동과 산출물은 규격 원문에서 확인한다(원문 확인). 이 레슨은 QA 가 알아야 할 구조와 작업 만 다룬다.
두 체계는 보완한다 — 대체가 아니다
자주 생기는 오해다. 정리하면 이렇다.
| 기능안전 | SOTIF | |
|---|---|---|
| 묻는 것 | 고장이 났을 때 안전한가 | 고장이 없는데도 위험한가 |
| 원인 | 결함·고장 | 성능 부족, 오사용 |
| 대응 | 고장 검출과 안전 상태 | 시나리오 커버리지 확대, 성능 개선, 제약 추가 |
| 증거의 성격 | 결함률·검출률 | 시나리오 범위와 잔여 위험 |
둘 다 필요하다. 고장을 완벽히 처리해도 성능 한계는 남고, 성능을 높여도 고장은 난다. 그래서 두 체계의 활동이 같은 사업 안에서 병행 되고, QA 는 어느 체계의 질문을 하고 있는지 의식해야 한다.
실무에서 이 구분이 중요한 순간이 있다. 결함 보고를 어디로 보낼지 정할 때다. 레슨 1 의 절차가 "세 단계 모두 명세대로" 로 끝나면, 그것은 기능안전 쪽 결함이 아니고 SOTIF 쪽 입력 이다. 기능 결함 추적 도구에 "의도된 동작" 으로 닫으면 그 위험은 사라진다.
네 영역 — 알려짐과 위험함
SOTIF 의 사고 틀 중 QA 에게 가장 직접적으로 쓰이는 것이다. 공개 자료가 설명하는 구도는 시나리오를 알려짐(knowledge) 과 위험함(hazard) 두 축으로 네 영역으로 분류 하는 것이다.
위험하지 않음 위험함
┌──────────────────┬──────────────────┐
알려진 │ 영역 1 │ 영역 2 │
│ 정상 운행 │ 파악된 위험 │
├──────────────────┼──────────────────┤
알려지지 │ 영역 4 │ 영역 3 │
않은 │ 안전하나 미기록 │ 미지의 위험 │
└──────────────────┴──────────────────┘공개 자료의 설명으로 각 영역은 이렇다 — 영역 1 은 알려지고 위험하지 않은 정상 운행, 영역 2 는 알려지고 위험한 시나리오(위험 거동을 유발한다고 식별된 것), 영역 3 은 알려지지 않고 위험한 시나리오(위험 거동을 유발하지만 아직 식별되지 않은 것), 영역 4 는 알려지지 않고 위험하지 않은 시나리오(안전하나 문서화되지 않은 것) 다.
작업의 방향이 이 그림에서 나온다.
- 영역 2 → 영역 1 — 파악된 위험을 개선·제약으로 줄인다. 요구사항 기반 시험으로 확인한다
- 영역 3 → 영역 2 — 미지의 위험을 찾아내 알려진 것으로 만든다. 이것이 QA 가 가장 크게 기여하는 방향이다
- 영역 3·4 를 줄인다 — 미지 영역 전체를 줄이는 것이 검증의 목표다
공개 자료는 알려진 시나리오의 위험은 명시적으로 평가 되어야 하고, 미지 시나리오로부터의 위험이 충분히 낮다는 것은 통계 기반 시험으로 입증 되어야 한다고 설명한다. 그리고 알려진 위험은 요구사항 기반 시험 같은 방법으로, 알려지지 않은 위험은 시뮬레이션과 가상 시험 절차 — 시나리오 기반 시험 — 으로 식별 한다고 안내한다.
여기서 QA 의 자리가 분명해진다. 영역 2 는 요구 기반 시험이고 익숙한 작업이다. 영역 3 을 파내는 일 이 이 분야 특유의 작업이고, 레슨 3·4 가 그 방법을 다룬다.
영역 3 은 "찾아낸 만큼만" 줄어든다
이 성질을 분명히 이해해야 한다. 미지 영역의 크기는 알 수 없다. 알 수 있으면 미지가 아니다. 그래서 "영역 3 이 몇 % 남았습니다" 라고 말할 수 없다.
말할 수 있는 것은 이것이다.
- 얼마나 찾아봤는가 — 어떤 방법으로, 어느 범위에서, 얼마나
- 찾은 것을 어떻게 처리했는가 — 영역 2 로 옮겨 개선·제약했는가
- 찾는 방법이 체계적인가 — 무작위인가, 근거 있는 탐색인가
그래서 증거의 성격이 다르다. 기능안전은 "결함률이 N 이하" 같은 숫자를 낼 수 있지만, SOTIF 의 증거는 "이 범위를 이 방법으로 탐색했고 발견한 것을 이렇게 처리했으며 남은 가정은 이것이다" 라는 논증 이다.
QA 보고서의 문장도 달라진다. "시나리오 1,200건 통과" 는 영역 2 의 증거이고, "이 ODD 범위에서 이 유발 조건 축으로 탐색해 위험 시나리오 N 건을 새로 식별했고, 그중 M 건을 요구사항으로 반영했다" 가 영역 3 작업의 증거다.
운행 설계 영역(ODD) — 범위를 선언하는 것이 안전 수단이다
공개 자료는 ISO 21448 의 중심 개념으로 운행 설계 영역(ODD, Operational Design Domain) 을 들고, 시스템이 안전하게 동작하도록 설계된 특정 조건 을 정의하는 것이라고 설명한다. 환경 조건(비·안개·눈 같은 날씨), 조명(주간·야간·역광), 도로 유형(고속도로·도심·교외), 지리적 제약 등을 포함한다.
ODD 가 왜 안전 수단인가. 범위를 좁히면 그 밖은 기능이 작동하지 않게 할 수 있고, 작동하지 않으면 그 상황의 위험은 발생하지 않는다. 즉 ODD 는 제약이자 안전 설계 다.
QA 가 ODD 에 대해 할 일이 셋이다.
1) ODD 가 문서로 있고 구체적인지 확인한다. "고속도로" 는 ODD 가 아니다. 차선 수, 곡률, 노면 상태, 날씨, 조도, 속도 범위, 교통량, 지리 범위가 판정 가능한 수준으로 적혀 있어야 한다. 애매하면 경계를 시험할 수 없다.
2) ODD 경계를 시험한다. 이것이 QA 의 핵심 작업이다.
| 경계 시험 | 확인할 것 |
|---|---|
| ODD 안쪽 끝 | 명세된 최악 조건에서 성능이 유지되는가 |
| ODD 밖 | 기능이 작동하지 않거나 적절히 축소되는가 |
| 경계를 넘는 순간 | 전환이 안전하게 이뤄지는가 |
| 경계 판정 실패 | ODD 밖인데 안이라고 판정하면? 그 반대면? |
| 모호한 경계 | 비가 "약하게" 오는 상태 |
세 번째가 가장 중요하고 가장 어렵다. 고속도로를 달리다 공사 구간에 들어가는 순간, 안개가 짙어지는 순간. 그 전환에서 운전자에게 전달되고 인수되는 과정이 설계되어 있어야 하고, 전달이 늦거나 불명확하면 그 자체가 위험이다. 레슨 1 의 상태 전환, 레슨 5 의 운전자 인터페이스와 맞물린다.
네 번째도 중요하다. ODD 판정 자체가 틀릴 수 있다. ODD 밖인데 안이라고 판정하면 작동해서는 안 되는 상황에서 작동한다 — 가장 위험한 조합이다. 반대(안인데 밖으로 판정) 는 기능이 불필요하게 꺼지는 것이고, 안전하지만 사용성 문제가 된다. 두 방향의 결과가 다르므로 판정 양식에 둘을 함께 둔다 — 레슨 1 의 미검출·오검출, 모듈 41 레슨 9 의 오탐·미탐과 같은 구조다.
3) ODD 가 좁혀질 때 그 사실이 전달되는지 확인한다. 개발 중 성능 문제로 ODD 를 좁히는 결정이 나올 수 있다. 그 변경이 사용자 문서·경고·기능 제약에 반영되지 않으면, 사용자는 넓은 ODD 를 전제로 쓴다.
유발 조건 — 영역 3 을 파내는 축
미지의 위험을 무작위로 찾을 수는 없다. 어디를 봐야 하는지 알려 주는 개념이 유발 조건(triggering condition) 이다. 특정 조건이 시스템의 기능 부족을 드러내 위험 거동으로 이어지는 상황을 가리킨다. 정확한 정의와 분석 방법은 규격 원문에서 확인한다(원문 확인).
QA 가 쓸 수 있는 탐색 축 으로 정리하면 이렇다.
| 축 | 유발 조건의 예 |
|---|---|
| 광학·조명 | 역광, 터널 출입구, 야간 대비 부족, 반사, 젖은 노면 반사 |
| 기상 | 비·눈·안개의 강도별, 노면 수막, 바람 |
| 대상의 외형 | 비정형 형태, 유사 패턴, 색·무늬가 배경과 섞임, 부분 가림 |
| 기하·배치 | 곡률, 경사, 교차·합류, 좁은 차로, 겹친 객체 |
| 표시·인프라 | 지워진 차선, 임시 차선, 공사 표지, 비표준 표지 |
| 동적 상황 | 급한 끼어들기, 역주행, 갑작스러운 정지, 예측 못 할 보행자 거동 |
| 다중 조합 | 위 둘 이상이 겹침 — 야간 + 비 + 곡선 + 공사 |
| 사람 | 오사용, 주의 분산, 잘못된 기대, 늦은 인수 |
일곱 번째(다중 조합) 가 영역 3 의 주 서식지 다. 단일 조건은 대개 개발 과정에서 다뤄지고, 조합 에서 성능이 급격히 떨어지는 경우가 남는다. 그래서 탐색에서 조합을 의도적으로 만드는 것 이 핵심이고, 레슨 4 에서 커버리지와 함께 다룬다.
여덟 번째(사람) 가 SOTIF 의 특징적 영역 이다. 아래에서 따로 다룬다.
예상 가능한 오사용 — 사용자를 전제로 설계한다
SOTIF 가 다루는 위험의 한 축이 합리적으로 예상 가능한 오사용 이다. "사용자가 설명서를 안 읽었다" 로 닫을 수 없다는 뜻이다. 예상 가능한 오사용은 설계가 다뤄야 하는 입력 이다.
전형적 오사용 유형이다.
- 능력 과대 평가 — 기능을 실제보다 높은 수준의 자율로 이해한다
- 주의 이탈 — 손을 놓거나 다른 일을 한다
- 의도적 우회 — 감시 장치를 속인다
- 늦은 인수 — 경고를 받고도 늦게 반응한다
- 상황 오판 — 기능이 켜져 있다고/꺼져 있다고 잘못 안다
- 범위 오해 — ODD 밖에서도 될 것으로 기대한다
QA 가 확인할 것은 각 오사용에 대해 시스템이 무엇을 하는가 다. 감지하는가, 경고하는가, 기능을 축소하는가, 어떤 순서로 하는가. 그리고 경고가 전달되는지 는 사용적합성 영역이다 — 레슨 5(IVI 와 주행 중 조작) 와 모듈 49 로 이어진다.
"의도적 우회" 를 다루는 방식 에 주의한다. 이 레슨은 우회 기법을 설명하지 않는다. QA 가 확인할 것은 "우회를 어떻게 하는가" 가 아니라 "우회 시도를 감지하고 대응하는 설계가 있는가" 다. 구체적 우회 방법을 문서에 적으면 그 문서가 안내서가 된다.
QA 가 만들 산출물
정리하면 넷이다.
- ODD 명세 검토 결과 — 판정 가능한 수준인지, 애매한 항목은 질의로
- ODD 경계 시험 설계 — 안쪽 끝·밖·전환 순간·판정 실패·모호한 경계
- 유발 조건 탐색 계획 — 여덟 축에서 조합을 만드는 방법(레슨 3·4 로 이어짐)
- 영역 3 작업 보고 양식 — 탐색 범위·방법·발견·처리·남은 가정을 담은 논증
4번이 이 레슨의 핵심 산출물 이고, 기능안전 보고서와 성격이 다르다는 것을 이해하는 것이 중요하다. 숫자 하나로 요약되지 않고, 논증 으로 쓰인다.
실무에서 왜 필요한가
ADAS·자율주행 조직에서 QA 가 가장 자주 마주치는 막다른 길이 "의도된 동작" 으로 닫히는 결함 이다. 위험해 보이는 상황을 보고했는데, 조사 결과 모든 구성 요소가 명세대로 동작했으므로 결함이 아니라는 답이 온다.
SOTIF 를 아는 QA 는 그 지점에서 멈추지 않는다. "기능 결함은 아니지만 성능 부족에 의한 위험입니다" 로 다시 올리고, 그것이 영역 2 에 등록되게 만든다. 등록되면 요구사항 개선이나 ODD 제약으로 처리되고, 등록되지 않으면 그 위험은 출시된다. 이 한 가지 구분이 QA 의 기여 중 가장 큰 것 이다.
두 번째 기여는 ODD 를 판정 가능하게 만드는 것 이다. ODD 가 "고속도로, 맑은 날" 수준으로 적혀 있으면 경계를 시험할 수 없고, 경계 시험이 없으면 전환 순간의 위험 이 그대로 남는다. 구체화를 요구하는 것은 품질 요구가 아니라 안전 요구다.
세 번째는 조합 탐색 이다. 단일 조건은 개발이 다루고, 조합은 아무도 체계적으로 보지 않는 경우가 많다. 야간 + 비 + 곡선 + 공사 같은 조합을 의도적으로 만드는 작업이 영역 3 을 파내는 실제 방법이고, 레슨 3·4 가 그 수단을 준다.
채용시장에서의 위치
SOTIF 는 자율주행 검증 공고에 직접 적히는 단어 다. 완성차·부품사의 안전· 검증 조직, 자율주행 솔루션 기업, 시뮬레이션 도구 기업에서 요구한다.
면접에서 가르는 질문이 분명하다. "기능안전과 SOTIF 의 차이를 설명해 보세요." "둘 다 안전 규격입니다" 로 답하면 약하고, "고장 났을 때 vs 고장이 없는데도" 로 답하고 네 영역을 들면 즉시 구분된다. 그다음 질문은 보통 "영역 3 을 어떻게 줄입니까" 이고, 유발 조건 축과 조합 탐색을 말할 수 있으면 실무자로 읽힌다.
그리고 이 역량은 자율주행 밖에서도 쓰인다. "명세대로 동작하는데 위험하다" 는 구조는 의료 AI(모듈 66), AI 시스템 품질(모듈 36·57) 에서 같은 모양으로 나타난다. SOTIF 의 사고 틀은 AI 가 들어간 모든 안전 관련 시스템 의 공통 문법에 가깝다.