개념
이 레슨의 범위를 먼저 못 박는다
기능안전은 전담 직무가 따로 있는 분야 다. 안전 요구사항 명세, 위험원 분석, 안전 등급 결정, 안전 관련 시스템의 설계와 검증은 설비 안전 담당자와 인증 기관이 맡는다. 소프트웨어 QA 가 그 역할을 대신하는 일은 없다.
그렇다면 QA 는 왜 이걸 알아야 하는가. 세 가지 이유다.
- 시험 대상에 안전 관련 기능이 섞여 있다. MES 화면의 "설비 정지" 버튼, SCADA 의 비상 정지 상태 표시, 레시피 파라미터의 상한 검증 — 이것들이 안전 기능인지 아닌지에 따라 시험 강도가 달라진다
- 안전 기능으로 분류되면 요구되는 활동이 늘어난다. 커버리지 목표, 추적성 문서, 검토 기록, 변경 영향 분석. 일정 산정 때 이걸 모르면 후반에 일정이 터진다
- QA 가 해서는 안 되는 시험이 있다. 안전 기능을 임의로 무력화하고 시험하는 행위는 사고로 직결된다
이 레슨의 목표는 경계를 아는 것 이다. "여기까지는 내 일이고, 여기부터는 안전 담당에게 넘긴다" 는 선을 그을 수 있으면 된다.
안전 기능과 일반 제어 기능을 가르는 질문
구분 기준은 기술이 아니라 실패했을 때 사람이 다치는가 다. 세 질문으로 가른다.
| 질문 | 예 = 안전 관련 | 아니오 = 일반 제어 |
|---|---|---|
| 이 기능이 실패하면 사람이 상해를 입을 수 있는가? | 비상 정지, 도어 인터락, 광전 센서 정지, 로봇 속도 제한 | 생산 카운터, 실적 전송 |
| 이 기능이 위험을 줄이기 위해 의도적으로 설계된 것인가? | 양손 조작 스위치, 이중 안전 릴레이 | 작업 편의용 자동 복귀 |
| 이 기능이 없거나 꺼져 있으면 설비를 운전해서는 안 되는가? | 안전 문 잠금 | 화면 테마 설정 |
실무에서 혼동이 생기는 지점은 "안전에 관련된 정보를 보여 주는 기능" 이다. SCADA 화면에 비상 정지 상태가 표시된다고 해서 그 화면이 안전 기능을 수행하는 것은 아니다. 실제 정지는 안전 회로가 한다. 다만 화면이 거짓 정보를 보여 주면 사람이 잘못 판단한다. 그래서 이런 기능은 "안전 기능은 아니지만 안전에 영향을 주는 정보 표시" 로 따로 분류하고, 일반 기능보다 높은 강도로 시험한다.
이 분류는 QA 가 혼자 결정하지 않는다. 분류 초안을 만들어 안전 담당자와 설비 담당자의 확인을 받는 것이 올바른 절차다. 확인받은 분류표가 시험 강도 배분의 근거 문서가 된다.
규격 체계의 위치 — 이름과 역할만 정확히
기능안전 규격은 계층 구조를 갖는다. 정확한 조항·요구사항 문장은 반드시 원문에서 확인해야 하고, 이 레슨에서는 어느 규격이 무엇을 다루는가 만 다룬다.
- IEC 61508 — 전기·전자·프로그래머블 전자 안전 관련 시스템의 기능안전을 다루는 기본 안전 규격(basic safety publication) 이다. 여러 산업 분야 규격의 모체 역할을 한다. 소프트웨어를 다루는 파트가 따로 있다
- 분야별 파생 규격 — 공정 산업, 기계류, 철도, 자동차 등 분야마다 61508 을 바탕으로 한 규격이 따로 있다. 자동차 쪽은 모듈 46 의 범위에서 다룬다
- 기계류 안전 규격 — 기계 설비의 안전 관련 제어 부분을 다루는 규격 체계가 따로 있고, 여기서는 PL(Performance Level) 이라는 등급 체계를 쓴다
여기서 가장 중요한 주의. SIL(Safety Integrity Level) 과 PL(Performance
Level) 은 서로 다른 규격 체계의 등급이며 섞어 쓰면 안 된다. 두 체계 사이의
대응 관계를 언급하는 자료가 있지만, 그 대응의 정확한 조건과 한계는 해당 규격
원문에서만 확인할 수 있다. QA 문서에서는 설비 문서에 적힌 등급 표기를 그대로
인용 하고, 다른 체계로 환산하지 않는다. 환산이 필요하면 안전 담당자에게 요청한다.
등급 번호·결정 절차·요구 활동의 구체적 내용은 이 레슨에서 다루지 않는다. 각 규격 원문과 사내 안전 표준에서 확인한다(규격 번호, 등급 정의, 요구 활동 목록 — 원문 확인). 외운 숫자를 QA 문서에 적는 것이 이 분야에서 가장 위험한 행동이다.
안전 관련 소프트웨어에 추가로 요구되는 것
일반 기능과 비교해 무엇이 늘어나는지를 활동의 성격 으로 보면 이렇다. 구체적 요구 수준은 등급과 규격에 따라 다르므로 원문을 본다.
추적성이 양방향으로 요구된다. 안전 요구사항 하나하나가 설계·구현·시험 케이스·시험 결과까지 연결되고, 거꾸로 시험 케이스에서 요구사항으로 되짚을 수 있어야 한다. 일반 기능에서는 권장이지만 여기서는 산출물 이다.
커버리지가 목표가 아니라 요건이 된다. 어떤 커버리지 기준을 어느 수준까지 달성해야 하는지가 규격과 등급에 따라 정해진다. 미달이면 미달 사유와 보완 조치를 문서로 남긴다. 모듈 53 에서 다룬 구조 커버리지 개념이 여기서 쓰인다.
검토와 분석이 정해진 형태로 요구된다. 코드 검토, 설계 검토, 영향 분석을 했다는 기록 자체가 증거가 된다. 모듈 58 레슨 2 의 문서 검토 기법이 그대로 쓰인다.
변경마다 영향 분석이 붙는다. 한 줄을 고쳐도 영향 범위를 분석하고 재시험 범위를 정한 기록을 남긴다. "작은 수정이니 회귀 생략" 이라는 선택지가 없다.
도구에도 조건이 붙는다. 컴파일러·정적 분석기·시험 도구를 쓰는 데 대한 요구가 규격에 있다. 도구를 바꾸는 것이 자유롭지 않다.
QA 가 일정 산정 때 반드시 반영할 것은 문서화 비용 이다. 안전 관련 기능의 시험은 실행 시간보다 증거를 남기는 시간이 더 든다. 경험적으로 일반 기능 대비 몇 배를 잡아야 하고, 그 배수를 프로젝트 초기에 안전 담당자와 합의해 둔다.
증거는 "다시 만들 수 있게" 남긴다
안전 관련 시험의 증거는 보존 기간이 길고, 읽는 사람이 그 자리에 없던 사람 이다. 인증 심사원, 몇 년 뒤의 사고 조사자, 설비를 인수한 다른 공장.
그래서 증거의 요건은 "결과가 적혀 있다" 가 아니라 "이것만 보고 같은 시험을 다시 할 수 있다" 다. 한 건의 증거에 들어가야 하는 것은 이렇다.
| 항목 | 왜 필요한가 |
|---|---|
| 대상 식별 | 설비·소프트웨어 버전·펌웨어 버전·파라미터 세트 |
| 시험 환경 | 어느 환경에서, 어떤 구성으로 |
| 절차 | 수행한 조작을 순서대로. 재현 가능한 수준으로 |
| 기대값과 실측값 | 판정의 근거. 측정값은 단위와 함께 |
| 판정과 판정자 | 누가 언제 합격이라고 판단했는가 |
| 원시 기록 | 로그·트렌드·영상 등 가공 전 자료 |
| 추적 연결 | 어느 안전 요구사항에 대응하는 시험인가 |
스크린샷 한 장과 "정상 동작" 이라는 문장 은 안전 증거가 되지 못한다. 그리고 증거의 변경 이력 이 관리돼야 한다. 결과 파일을 덮어쓰면서 관리하면 심사에서 문제가 된다.
QA 가 하는 시험과 하지 않는 시험
QA 가 담당할 수 있는 범위
- 안전 정보 표시 기능의 정확성 — SCADA·HMI·MES 화면의 상태 표시가 실제 상태와 일치하는가. 지연·반전·정지 화면(freeze) 같은 실패 모드 포함
- 안전 관련 데이터의 기록과 보존 — 안전 사건(비상 정지·인터락 작동) 이 빠짐없이 기록되고 시각이 맞고 지워지지 않는가
- 파라미터 상·하한 검증 — 레시피나 설정값에 설비 허용 범위를 넘는 값을 넣을 때 소프트웨어가 거부하는가. 입력 검증은 QA 의 본래 영역이다
- 권한 통제 — 안전 관련 설정을 아무나 바꿀 수 없는가. 변경 이력이 남는가
- 인터락 상태에서의 상위 소프트웨어 동작 — 인터락이 걸린 동안 작업 지시를 내려보내거나 자동 운전을 요청하면 어떻게 되는가
- 문서 검토 — 안전 요구사항 명세의 모호성·검증 불가능한 표현·누락을 검토 관점에서 지적하는 일. QA 의 검토 기법이 그대로 쓰인다
QA 가 하지 않는 시험
- 안전 기능 자체의 작동 시험 — 비상 정지를 실제로 눌러 설비가 규정 시간 안에 멈추는지 확인하는 시험은 설비 안전 담당의 영역이다. QA 는 참관하고 기록을 받는 쪽이다
- 안전 장치 무력화 후 시험 — 센서를 가리거나 인터락을 우회하고 시험하는 행위는 어떤 이유로도 하지 않는다. 필요하다면 안전 담당자가 정해진 절차로 수행한다
- 안전 등급 판정과 환산 — SIL·PL 등급을 QA 가 정하거나 환산하지 않는다
- 안전 회로·배선 조작 — 전기 작업 영역이다
이 경계를 프로젝트 착수 시점에 문서로 합의 해 두면 나중에 "그건 QA 가 확인한 줄 알았다" 는 공백이 생기지 않는다. 안전 관련 기능 목록에 담당 주체 열 을 넣는 것이 가장 단순한 방법이다.
실무에서 왜 필요한가
제조 프로젝트에서 QA 가 안전 영역에서 실수하는 방향은 두 가지인데, 둘 다 비싸다.
과소 — 안전 관련 기능을 일반 기능으로 시험한다. 인터락 상태 표시를 "표시 기능" 으로 보고 가볍게 넘긴다. 나중에 심사나 인수 단계에서 증거가 없다 는 지적을 받고, 그때 다시 시험한다. 설비가 이미 가동 중이면 재시험 기회를 잡기 어렵다. 최악은 표시가 틀린 채로 운영에 들어가 작업자가 잘못 판단하는 경우다.
과잉 — 안전 담당 영역을 QA 가 건드린다. 좋은 의도로 비상 정지를 눌러 보거나 센서를 가려 본다. 설비 손상, 생산 중단, 그리고 사람이 다치는 사고로 이어질 수 있다. 안전 영역에서 승인 없는 선의의 행동 은 그 자체로 중대한 절차 위반이다.
그래서 이 레슨의 실질적 산출물은 분류표와 담당표 다. 안전 관련 기능이 무엇이고, 각각을 누가 어떤 강도로 시험하며, 증거는 어떤 형태로 남기는가. 이 문서를 착수 시점에 만들어 안전 담당자의 확인을 받아 두면 일정과 책임이 동시에 정리된다.
채용 관점에서도 의미가 있다. 제조·설비 분야 QA 공고에서 기능안전 전문가 를 QA 에게 기대하지는 않는다. 기대하는 것은 "안전 영역을 알아보고, 경계를 지키고, 증거 요건을 이해하는 사람" 이다. 면접에서 "안전 기능은 제가 임의로 시험하지 않고 분류표와 담당 합의를 먼저 만듭니다" 라고 말할 수 있으면 그것으로 충분하다.