HAZOP에서 Safeguard와 Recommendation을 구분하는 기준

HAZOP을 수행하다 보면 가장 자주 혼동되는 항목 중 하나가 Safeguard와 Recommendation의 구분입니다.

둘 다 위험을 줄이기 위한 수단이라는 점에서는 비슷해 보이지만, 실제 HAZOP에서는 역할이 명확히 다릅니다.

간단히 정리하면 Safeguard는 현재 이미 존재하면서 해당 사고 시나리오의 발생을 예방하거나 결과를 완화하는 보호수단이고, Recommendation은 현재 보호수단만으로 위험이 충분히 낮아지지 않을 때 추가로 요구되는 개선조치입니다.

HAZOP 결과의 품질은 이 두 항목을 얼마나 정확하게 구분하느냐에 크게 좌우됩니다.

1. Safeguard란 무엇인가?

HAZOP에서 Safeguard는 특정 Cause가 발생했을 때 사고가 Consequence까지 진행되는 것을 차단하거나 사고 결과를 줄이는 기존의 보호수단을 의미합니다.

대표적인 Safeguard에는 다음과 같은 것들이 있습니다.

• PSV 및 Rupture Disk
• High/Low Pressure Alarm
• High-High Level Trip
• Interlock
• Emergency Shutdown System
• Gas Detector
• Fire & Gas System
• Check Valve
• Dike 또는 방유제
• 운전원 대응절차
• 안전운전절차서
• 물리적인 설비 설계조건

예를 들어 반응기의 Outlet Valve가 닫히면서 내부 압력이 상승하는 상황을 생각해 볼 수 있습니다.

HAZOP 기록은 다음과 같이 작성할 수 있습니다.

Deviation: High Pressure
Cause: Reactor Outlet Valve Closed
Consequence: Reactor Overpressure → Vessel Failure → Hazardous Material Release
Safeguard: PSV-101

이 경우 PSV-101이 현재 설비에 설치되어 있고, 해당 과압 시나리오에서 필요한 방출량을 처리할 수 있도록 설계되어 있다면 Safeguard로 기록할 수 있습니다.

2. 설치되어 있다고 모두 Safeguard는 아니다

여기서 가장 중요한 점이 있습니다.

설비나 장치가 존재한다는 이유만으로 Safeguard로 인정해서는 안 됩니다.

HAZOP Team은 해당 보호수단이 실제 분석 중인 Cause-Consequence Scenario에서 기능할 수 있는지를 검토해야 합니다.

예를 들어 High Pressure Alarm이 설치되어 있다고 하더라도 운전원이 Alarm을 확인한 뒤 사고가 발생하기 전에 충분한 시간 내에 조치를 취할 수 없다면 효과적인 Safeguard라고 보기 어렵습니다.

실무적으로 Safeguard를 판단할 때는 최소한 다음 사항을 확인해야 합니다.

① 해당 사고 시나리오와 직접적인 관련이 있는가?

Tank Overfill 사고를 분석하고 있는데 Pump Discharge Pressure Alarm이 설치되어 있다는 이유만으로 이를 Safeguard에 포함해서는 안 됩니다.

해당 Alarm이 실제로 Tank Overfill을 감지하거나 예방하는 기능이 없다면 해당 시나리오의 Safeguard라고 보기 어렵습니다.

② 사고가 발생하기 전에 기능할 수 있는가?

Alarm과 Operator Action을 Safeguard로 인정하려면 사고가 최종 Consequence까지 진행되는 시간보다 감지와 대응시간이 충분히 빨라야 합니다.

예를 들어 이상상태 발생 후 30초 만에 사고가 발생하는 공정인데, 운전원의 인지와 현장조치에 수분이 필요하다면 운전원 대응만을 주요 Safeguard로 보는 것은 적절하지 않을 수 있습니다.

③ 실제로 작동 가능한 상태인가?

설치만 되어 있고 시험, 검사, 교정 또는 유지보수가 제대로 이루어지지 않은 보호장치는 신뢰할 수 있는 Safeguard라고 보기 어렵습니다.

따라서 PSV 검사이력, 계측기 Calibration, Interlock Function Test 등의 상태도 함께 확인할 필요가 있습니다.

④ Cause와 독립적으로 기능할 수 있는가?

Safeguard가 사고 원인과 동일한 원인에 의해 동시에 기능을 상실한다면 실제 보호효과가 크게 떨어질 수 있습니다.

예를 들어 정상 Cooling Water와 Emergency Cooling Water가 동일한 Pump와 전원계통을 사용한다면 정전이 발생했을 때 두 계통이 동시에 기능을 잃을 가능성이 있습니다.

따라서 HAZOP에서는 단순히 보호장치의 개수보다 각 보호수단이 실제 사고 시나리오에서 얼마나 효과적으로 기능하는지를 보는 것이 중요합니다.

3. HAZOP Safeguard와 IPL은 같은 개념인가?

HAZOP 실무에서 자주 발생하는 또 하나의 오해가 있습니다.

Safeguard와 IPL(Independent Protection Layer)은 완전히 동일한 개념이 아닙니다.

HAZOP에서는 사고의 발생을 예방하거나 결과를 완화하는 다양한 보호수단을 Safeguard로 기록할 수 있습니다.

하지만 LOPA에서 IPL로 인정하려면 일반적으로 다음과 같은 조건을 보다 엄격하게 검토합니다.

• Independence
• Effectiveness
• Reliability
• Auditability

따라서 HAZOP에서 Safeguard로 기록된 모든 항목이 LOPA에서 IPL로 인정되는 것은 아닙니다.

예를 들어 일반적인 운전원 순찰은 HAZOP에서는 보조적인 Safeguard로 언급될 수 있지만, LOPA에서 독립적인 보호계층으로 인정하기에는 부족할 수 있습니다.

4. Recommendation은 언제 작성하는가?

Recommendation은 HAZOP Team이 현재 존재하는 Safeguard를 검토한 후에도 Residual Risk가 허용 가능한 수준까지 감소하지 않는다고 판단할 때 제시하는 추가 조치입니다.

전체 흐름을 정리하면 다음과 같습니다.

Cause → Consequence → Existing Safeguard → Risk Evaluation → Recommendation

예를 들어 Tank의 High Level 상황을 분석한다고 가정해보겠습니다.

Deviation: High Level
Cause: Inlet Control Valve Fail Open
Consequence: Tank Overfill → Flammable Liquid Release
Existing Safeguard: High Level Alarm
Risk: High

HAZOP Team이 검토한 결과 High Level Alarm과 운전원의 대응만으로는 위험을 충분히 낮추기 어렵다고 판단했다면 다음과 같은 Recommendation을 제안할 수 있습니다.

Recommendation: 독립적인 High-High Level Detection 및 Inlet Isolation 기능의 적용 필요성을 검토한다.

이때 중요한 것은 Recommendation은 현재 존재하는 보호수단을 기록하는 항목이 아니라 앞으로 수행해야 할 Action을 기록하는 항목이라는 것입니다.

5. Safeguard와 Recommendation을 쉽게 구분하는 방법

실무에서는 다음 질문을 해보면 상당 부분 구분할 수 있습니다.

“현재 이 보호수단이 이미 설치되어 있고 정상적으로 기능하고 있는가?”

YES라면 Safeguard 후보입니다.

반대로 아직 존재하지 않고 앞으로 설치하거나 개선해야 하는 사항이라면 Recommendation 후보입니다.

예를 들어 다음과 같이 구분할 수 있습니다.

검토 내용	구분
현재 설치된 PSV	Safeguard
신규 PSV 설치 검토	Recommendation
현재 운전 중인 High Pressure Alarm	Safeguard
High-High Pressure Trip 추가 설치	Recommendation
현재 승인되어 적용 중인 안전운전절차	Safeguard
운전절차 신규 작성 또는 개정	Recommendation
현재 설치된 ESD	Safeguard
독립적인 ESD 기능 추가	Recommendation

다만 앞서 설명했듯이 현재 존재한다는 사실 하나만으로 Safeguard가 되는 것은 아닙니다.

해당 사고 시나리오에서 실제로 기능할 수 있어야 합니다.

6. 잘못된 Safeguard 선정 사례

HAZOP에서 자주 발생하는 오류 중 하나는 너무 많은 항목을 Safeguard로 기록하는 것입니다.

대표적인 사례가 다음과 같습니다.

“운전원이 항상 현장에 있음”

이 문장만으로는 유효한 Safeguard라고 판단하기 어렵습니다.

운전원이 무엇을 감지하고, 어떤 방법으로 이상상태를 인지하며, 얼마 이내에 어떤 조치를 취하는지가 명확해야 합니다.

또 다른 예가 있습니다.

“정기점검 실시”

정기점검은 설비의 장기적인 고장 가능성을 줄이는 데는 도움이 될 수 있습니다. 그러나 특정 HAZOP Scenario가 발생했을 때 사고의 진행을 직접 차단하는 보호수단인지 여부는 별도로 판단해야 합니다.

따라서 HAZOP Worksheet에 단순히

운전원 확인

이라고 작성하기보다는

High Pressure Alarm 발생 시 운전원이 Feed Pump를 정지하도록 안전운전절차서에 규정

처럼 구체적인 보호기능을 작성하는 것이 좋습니다.

7. Recommendation 작성 시 흔히 발생하는 오류

Recommendation 역시 지나치게 추상적으로 작성하면 이후 Action Closure가 어려워집니다.

다음과 같은 표현은 가급적 피하는 것이 좋습니다.

• 안전성을 강화한다.
• 추가 검토한다.
• 위험성을 줄인다.
• 주의해서 운전한다.
• 교육을 강화한다.

이러한 표현만으로는 누가 무엇을 언제까지 수행해야 하는지 판단하기 어렵습니다.

예를 들어 다음 Recommendation을 비교해볼 수 있습니다.

나쁜 예

Tank Overfill 대책을 강화한다.

개선된 예

Tank T-101의 Overfill Scenario에 대해 기존 High Level Alarm과 독립된 High-High Level 감지 및 Inlet Isolation 기능의 적용 필요성을 검토하고 결과를 문서화한다.

좋은 Recommendation에는 최소한 다음 내용이 드러나는 것이 좋습니다.

어떤 위험을 대상으로 하는가

어떤 설비 또는 시스템에 대한 것인가

어떤 방향으로 개선하거나 검토할 것인가

Recommendation은 반드시 HAZOP 단계에서 상세 설계방안까지 확정해야 한다는 의미는 아닙니다.

HAZOP에서는 해결해야 할 위험과 요구사항을 정의하고, 구체적인 기술적 해결방안은 이후 Engineering Review 과정에서 결정할 수도 있습니다.

8. Safeguard가 충분하면 Recommendation이 없어도 된다

HAZOP을 수행하면 반드시 Recommendation이 많이 나와야 좋은 평가라고 생각하는 경우가 있습니다.

하지만 이는 적절한 접근이 아닙니다.

HAZOP의 목적은 Recommendation 개수를 늘리는 것이 아니라 현재 공정의 위험이 적절한 수준으로 관리되고 있는지 확인하는 것입니다.

기존 Safeguard가 충분하고 Risk Matrix 평가 결과 Residual Risk가 사업장의 허용기준을 만족한다면 Recommendation이 없어도 됩니다.

반대로 Safeguard가 여러 개 존재한다고 해서 위험이 반드시 충분히 낮아지는 것도 아닙니다.

예를 들어 3개의 Safeguard가 모두 동일한 전원이나 동일한 계측 신호에 의존한다면 하나의 Common Cause에 의해 동시에 기능을 상실할 수 있습니다.

결국 중요한 것은 Safeguard의 개수가 아니라 보호수단의 실제 효과성입니다.

9. 실무 사례로 이해하기

다음과 같은 Reactor를 가정해보겠습니다.

Deviation: High Pressure

Cause: Cooling Water Failure

Consequence: Reactor Temperature 상승 → 반응속도 증가 → Reactor Pressure 상승 → Vessel Rupture → 유해물질 누출

현재 설치된 보호수단은 다음과 같습니다.

• Reactor High Temperature Alarm
• High Pressure Alarm
• PSV
• Emergency Cooling Water Supply

이 네 가지 장치와 시스템이 현재 설치되어 있고 실제 해당 사고 시나리오에서 기능할 수 있다면 Safeguard 후보가 됩니다.

이후 HAZOP Team은 이들 Safeguard를 고려하여 Risk를 평가합니다.

만약 허용 가능한 수준까지 Risk가 낮아진다면 추가 Recommendation은 필요하지 않을 수 있습니다.

하지만 검토 과정에서 Emergency Cooling Water가 정상 Cooling Water와 동일한 Pump 및 전원계통을 공유하고 있다는 사실을 발견했다고 가정해보겠습니다.

정전이 Cooling Water Loss의 Cause라면 Emergency Cooling Water 역시 함께 상실될 수 있습니다.

이 경우 Team은 다음과 같은 Recommendation을 작성할 수 있습니다.

Emergency Cooling Water System의 독립적인 공급원 및 전원 구성 필요성을 검토한다.

즉,

현재 존재하는 Emergency Cooling Water System = Safeguard

독립성을 확보하기 위한 추가적인 개선조치 = Recommendation

으로 구분할 수 있습니다.

10. Recommendation 완료 후에는 어떻게 되는가?

Recommendation이 제시되었다고 HAZOP 업무가 끝나는 것은 아닙니다.

실제 PSM 관리에서는 다음과 같은 흐름으로 연결되는 것이 중요합니다.

Recommendation 발생 → 담당부서 지정 → 완료기한 설정 → 기술검토 → MOC 여부 판단 → 설계 및 설치 → 관련 문서 개정 → 필요 시 PSSR → Action Closure

그리고 이후 HAZOP Revalidation을 실시할 때는 과거 Recommendation의 완료사항이 새로운 Safeguard로 반영될 수 있습니다.

예를 들어 과거 HAZOP에서

Recommendation: High-High Level Trip 설치 검토

가 제시되었고 실제 설계·설치·시험까지 완료되었다면, 차기 HAZOP에서는 해당 High-High Level Trip이 Existing Safeguard로 기록될 수 있습니다.

즉,

Recommendation → 실행 및 검증 → Existing Safeguard

라는 흐름이 만들어집니다.

11. PSM 자체감사에서도 Safeguard를 확인해야 한다

HAZOP Worksheet에 Safeguard가 적혀 있다는 사실만 확인해서는 안 됩니다.

예를 들어 HAZOP에는 다음과 같이 작성되어 있을 수 있습니다.

Safeguard: PSV-101

하지만 실제 현장을 확인해보니 PSV Set Pressure가 변경되어 있거나 검사주기가 초과되어 있다면 HAZOP 당시 가정했던 보호수준이 현재도 유지되고 있다고 보기 어렵습니다.

Interlock도 마찬가지입니다.

HAZOP에는 High-High Pressure Trip이 Safeguard로 기록되어 있지만 실제 DCS Logic에서 Bypass되어 있다면 사실상 보호기능이 없는 상태일 수 있습니다.

따라서 HAZOP Revalidation이나 PSM 자체감사에서는 다음을 함께 확인해야 합니다.

HAZOP Worksheet의 Safeguard

→ 실제 현장설비

→ P&ID 및 Cause & Effect

→ Alarm/Interlock Set Point

→ 검사·시험·교정 기록

→ Bypass 또는 Override 상태

이러한 연결성을 검증해야 HAZOP이 단순한 문서가 아니라 실제 공정의 위험관리 자료로 기능할 수 있습니다.

마무리

HAZOP에서 Safeguard와 Recommendation을 구분하는 가장 기본적인 기준은 명확합니다.

현재 존재하면서 특정 사고 시나리오의 발생을 예방하거나 결과를 완화하는 보호수단은 Safeguard입니다.

반대로 현재의 Safeguard를 고려하고도 위험이 충분히 낮아지지 않아 앞으로 추가하거나 개선해야 하는 조치는 Recommendation입니다.

다만 실무에서는 한 단계 더 깊게 판단해야 합니다.

설비가 존재한다고 무조건 Safeguard가 되는 것이 아니라, 해당 Cause-Consequence Scenario에 실제로 효과가 있는지 확인해야 합니다.

이를 간단히 정리하면 다음과 같습니다.

Existing & Effective Protection → Safeguard

Existing Safeguard 적용 후에도 Residual Risk가 높음 → Recommendation

Recommendation 실행 및 검증 완료 → 이후 Existing Safeguard로 관리

결국 HAZOP은 단순히 위험요인을 나열하는 작업이 아닙니다.

Cause → Consequence → Safeguard → Risk Evaluation → Recommendation → Action Closure

이 흐름을 정확하게 연결하는 것이 HAZOP의 핵심이며, Safeguard와 Recommendation을 명확하게 구분하는 것이 신뢰성 높은 공정위험성평가를 만드는 첫 번째 단계입니다.

---