다섯 살도 알 수 있게 · SW공학
소프트웨어 안전/기능안전이 뭐예요?
소프트웨어 안전과 기능안전을, 응급처치 안내서처럼 오탈자 하나가 생명과 직결되는 책에 몇 겹의 엄격한 검증을 거치게 하는 이야기로 풀어봤어요.
약 용량 단위 오탈자 하나를 그냥 지나칠 뻔했어요.보통 책이면 사소한 오탈자지만, 응급처치 안내서에선 생명이 걸려요.
편집장은 다른 책처럼 검토하자 하고, 교정자는 생명이 걸렸다고 반박해요.모든 책을 똑같은 강도로 검토할 순 없어요.
위험이 큰 책일수록 검증을 몇 겹으로 더 엄격하게 거쳐요.위험 등급에 따라 거치는 검증 겹의 수가 달라져요.
위험 등급 나누기책마다 위험 크기가 달라요
둘이 교차 확인하기한 사람의 실수를 서로 잡아줘요
독립된 팀이 재검토원래 팀과 따로 봐요
실제로 시험해 보기안내서를 현장에 쓰기 전에 직접 따라 해봐요
위험 등급에 따라 검증 강도가 달라요.같은 오탈자라도 책에 따라 위험 크기가 달라요. 표의 네 등급은 쉽게 줄인 예시이고, 실제 요구는 표준마다 달라요.
검증해도 위험이 0이 되진 않아요.안전은 위험을 감당할 수 있는 수준까지 낮추는 일이에요.
한 줄로
소프트웨어/기능안전 = 위험이 큰 책일수록 검증을 몇 겹으로 더 엄격하게 거치게 하는 일.
기능안전은 시스템이 고장나더라도 사람을 다치게 하지 않도록, 위험도에 따라 검증 수준(SIL 등)을 차등 적용하는 접근이에요. 위험이 클수록 독립적인 검토, 이중화, 실제 시험 등 더 많은 안전장치를 겹겹이 요구해요. 완벽한 무결함이 목표가 아니라, 받아들일 수 있는 수준까지 위험을 낮추는 게 목표예요.
어른들은 이렇게 불러요
- 기능안전
Functional Safety - 고장나도 사람이 다치지 않게 하는 설계. 위험 등급별로 요구 수준이 달라요.
- 안전무결성수준(SIL)
Safety Integrity Level - 안전 기능이 얼마나 믿을 만해야 하는지 나눈 1~4 눈금. IEC 61508의 등급으로, 4가 가장 높고 높을수록 검증이 엄격해져요.
- 독립 검증
Independent Verification - 원래 팀과 다른 팀이 다시 보는 일. 한쪽의 맹점을 다른 쪽이 잡아줘요.
- 이중화
Redundancy - 하나가 실패해도 다른 하나가 버티게 하는 구조. 교차 확인과 비슷한 원리예요.
- 위험 분석
Risk Analysis - 어떤 책이 더 위험한지 먼저 가늠하는 일. 등급을 나누기 전에 해요.
- 화이트박스/블랙박스 테스트
White-box/Black-box Testing - 속을 볼지 겉만 볼지로 나눈 검토법. 위험이 클수록 이 둘을 더 깊게, 더 많이 해요. → 속을 펼쳐 볼지, 겉만 읽을지
- 정보시스템 감리/PMO
IS Audit/PMO - 출간 과정을 곁에서 살피는 검수관. 안전 검증이 계획대로 됐는지 감리가 볼 수도 있어요. → 출간 과정을 곁에서 살피는 검수관
- 안전 사례(Safety Case)
Safety Case - 이만큼 안전하다는 근거를 모아 둔 서류. 검증 기록을 모아 외부에 설명할 때 써요.
다음 이야기
사라진 원본을 되짚어 다시 짓기 →