“Fail Open”과 “Fail Closed”, 보안 설계에서 꼭 알아야 할 사항

들어가며

프로그램이나 시스템을 개발하다 보면 예상하지 못한 오류가 발생할 수 있습니다.

외부 인증 서버가 응답하지 않을 수도 있고, 네트워크 연결이 끊길 수도 있습니다. 데이터베이스에 문제가 생기거나 특정 보안 장비가 정상적으로 동작하지 않는 경우도 있습니다.

이런 상황에서 중요한 질문이 하나 있습니다.

“오류가 발생했을 때 시스템은 무엇을 해야 할까?”

그냥 서비스를 중단시키는 것이 항상 정답은 아닙니다. 반대로 오류가 발생했는데도 기존 사용자의 접근을 그대로 허용하는 것도 문제가 될 수 있습니다.

이때 자주 등장하는 개념이 바로 Fail Open과 Fail Closed입니다.

이 두 용어는 시스템에 장애나 오류가 발생했을 때 기본적으로 어떤 방향으로 동작할 것인지를 설명합니다.

간단하게 기억하면 다음과 같습니다.

Fail Open
→ 문제가 생겨도 접근을 허용하는 방향

Fail Closed
→ 문제가 생기면 접근을 차단하는 방향

하지만 실제 개발에서는 이렇게 단순하게만 생각하면 안 됩니다.

어떤 시스템에 적용하느냐에 따라 허용과 차단의 의미가 달라지기 때문입니다.

Fail Open이란?

먼저 Fail Open부터 살펴보겠습니다.

Fail Open은 시스템에 오류가 발생했을 때 가능한 한 기존 기능이나 접근을 허용하는 방향으로 동작하는 방식을 의미합니다.

쉽게 표현하면 다음과 같습니다.

정상 상태
→ 접근 허용

오류 발생
→ 그래도 접근 허용

예를 들어 특정 시스템에서 부가적인 인증 확인 서버를 사용하고 있다고 가정해보겠습니다.

그런데 인증 확인 서버가 일시적으로 응답하지 않습니다.

Fail Open 방식으로 설계되어 있다면 인증 확인 서버의 장애 때문에 전체 서비스의 접근을 무조건 차단하지 않고, 정해진 조건에 따라 기존 서비스를 계속 사용할 수 있도록 처리할 수 있습니다.

이런 방식은 서비스 가용성이 중요한 환경에서 고려될 수 있습니다.

인증 시스템 하나의 장애 때문에 정상적인 사용자까지 전부 서비스를 이용하지 못하는 상황을 피할 수 있기 때문입니다.

다만 여기에는 중요한 문제가 있습니다.

보안 기능에 Fail Open을 적용하면 보안 검증에 실패했는데도 접근이 허용될 가능성이 생깁니다.

따라서 보안과 관련된 중요한 기능에서는 Fail Open을 적용할 때 신중하게 판단해야 합니다.

Fail Closed란?

반대로 Fail Closed는 오류가 발생했을 때 접근이나 기능을 차단하는 방향으로 동작하는 방식입니다.

간단하게 표현하면 다음과 같습니다.

정상 상태
→ 접근 허용

오류 발생
→ 접근 차단

예를 들어 출입문에 카드 인증 시스템이 설치되어 있다고 생각해보겠습니다.

카드 인증 서버와 통신할 수 없는 상황이 발생했을 때 문을 열어버리는 방식이라면 보안 측면에서 문제가 될 수 있습니다.

Fail Closed 방식에서는 인증을 정상적으로 확인할 수 없다면 문을 열지 않는 방향으로 처리할 수 있습니다.

즉,

“정상적으로 확인할 수 없다면 일단 허용하지 않는다.”

라는 접근입니다.

보안이 중요한 시스템에서는 이런 방식이 고려되는 경우가 많습니다.

Fail Open과 Fail Closed를 쉽게 비교하면

두 개념을 가장 간단하게 비교하면 다음과 같습니다.

구분	Fail Open	Fail Closed
오류 발생 시	허용 방향	차단 방향
중요하게 보는 부분	서비스 연속성	접근 통제
장점	서비스 중단을 줄일 수 있음	검증 실패 시 접근을 막을 수 있음
주의점	보안 취약점이 발생할 가능성	정상 사용자도 접근하지 못할 가능성
대표적으로 고려할 부분	가용성이 중요한 기능	보안이 중요한 기능

여기서 중요한 것은 어느 한쪽이 모든 상황에서 적용하기 좋다고 생각하면 안 된다는 것입니다.

시스템의 목적과 장애가 발생했을 때 발생할 수 있는 영향을 함께 고려해야 합니다.

보안 시스템에서는 왜 Fail Closed가 중요할까?

보안과 관련된 기능을 생각해보면 Fail Closed의 개념을 이해하기 쉽습니다.

예를 들어 사용자의 권한을 확인하는 시스템이 있다고 해보겠습니다.

정상적인 상황에서는 다음과 같이 동작합니다.

사용자 요청
   ↓
권한 확인
   ↓
권한 있음
   ↓
접근 허용

그런데 권한 확인 시스템 자체가 장애를 일으켰다고 가정해보겠습니다.

이때 권한을 확인할 수 없다는 이유로 무조건 접근을 허용한다면 어떻게 될까요?

실제로 권한이 없는 사용자도 시스템에 접근할 가능성이 생깁니다.

이런 상황을 피하기 위해 권한이나 접근 통제가 중요한 영역에서는 Fail Closed 방식이 고려될 수 있습니다.

즉, 확인할 수 없으면 허용하지 않는 것입니다.

물론 이것 역시 시스템의 특성과 업무 요구사항을 기준으로 결정해야 합니다.

그렇다고 Fail Open이 나쁜 것은 아니다

여기서 흔히 생기는 오해가 있습니다.

Fail Open은 보안에 좋지 않고 Fail Closed는 항상 안전하다고 생각하는 것입니다.

실제로는 그렇게 단순하지 않습니다.

Fail Open과 Fail Closed는 각각 서로 다른 목적과 위험을 가지고 있습니다.

예를 들어 어떤 서비스에서 특정 외부 시스템이 일시적으로 장애가 발생했다고 해보겠습니다.

그 외부 시스템이 핵심 보안 기능이 아니라 단순한 부가 기능을 담당하고 있다면 장애 때문에 전체 서비스를 차단하는 것이 오히려 사용자에게 큰 불편을 줄 수 있습니다.

이런 경우에는 제한적인 조건에서 서비스를 계속 제공하는 방식을 검토할 수 있습니다.

반대로 인증이나 권한 확인처럼 보안과 직접적으로 연결된 기능이라면 검증에 실패했을 때 접근을 차단하는 방식이 더 적절할 수 있습니다.

결국 핵심은 무엇이 실패했는지입니다.

실제 개발에서는 어떻게 판단해야 할까?

Fail Open과 Fail Closed를 설계할 때는 단순히 개발자의 취향으로 결정하기보다는 장애가 발생했을 때의 영향부터 살펴봐야 합니다.

다음과 같은 질문을 해보면 도움이 됩니다.

1. 어떤 기능이 실패하는가?

2. 해당 기능이 보안과 직접적으로 관련되어 있는가?

3. 오류가 발생했을 때 접근을 허용하면 어떤 문제가 생기는가?

4. 접근을 차단하면 서비스에 어떤 문제가 발생하는가?

5. 장애가 얼마나 오래 지속될 수 있는가?

6. 긴급 상황에서 별도의 우회 방법이 필요한가?

이런 질문을 먼저 정리한 다음 시스템의 기본 동작을 결정하는 것이 좋습니다.

인증 시스템을 예로 들어보자

예를 들어 웹사이트에 로그인한 사용자의 추가 권한을 확인하는 기능이 있다고 해보겠습니다.

정상적인 상황에서는 다음과 같습니다.

사용자
 ↓
로그인
 ↓
인증 확인
 ↓
권한 확인
 ↓
서비스 이용

그런데 권한 확인 서버가 다운됐습니다.

Fail Open 방식이라면 상황에 따라 다음과 같은 처리가 가능합니다.

권한 서버 장애
 ↓
권한 확인 불가
 ↓
제한적인 접근 허용

반면 Fail Closed라면 다음과 같이 처리할 수 있습니다.

권한 서버 장애
 ↓
권한 확인 불가
 ↓
접근 차단

두 방식 모두 기술적으로 구현할 수 있지만 사용자 경험과 보안에 미치는 영향은 상당히 다릅니다.

따라서 어떤 방식을 사용할지는 해당 서비스의 요구사항을 기준으로 결정해야 합니다.

방화벽이나 접근 제어에서도 중요한 개념

Fail Open과 Fail Closed는 인증 시스템에서만 등장하는 개념이 아닙니다.

방화벽, 네트워크 장비, 접근 제어 시스템, API Gateway, 인증 시스템 등 다양한 환경에서 장애 발생 시의 기본 동작을 설계할 때 비슷한 개념을 생각할 수 있습니다.

예를 들어 네트워크 접근을 제어하는 시스템이 있는데 해당 시스템에 문제가 발생했다고 해보겠습니다.

접근을 모두 허용하는 방식이라면 서비스 자체는 계속 동작할 가능성이 있지만 보안 측면의 위험이 발생할 수 있습니다.

반대로 접근을 모두 차단한다면 보안 통제는 유지할 수 있지만 정상적인 서비스까지 중단될 수 있습니다.

결국 여기에서도 보안성과 가용성 사이의 영향을 함께 살펴봐야 합니다.

Fail Safe라는 개념도 함께 알아두자

Fail Open과 Fail Closed를 찾아보다 보면 Fail Safe라는 용어도 접하게 됩니다.

Fail Safe는 단순히 “무조건 열어준다” 또는 “무조건 닫는다”라는 의미와는 조금 다르게 사용될 수 있습니다.

핵심은 장애가 발생했을 때 위험을 최소화하는 안전한 상태로 전환하도록 설계하는 것입니다.

여기서 어떤 상태가 안전한지는 시스템마다 달라집니다.

예를 들어 어떤 시스템에서는 접근 차단이 안전한 상태일 수 있습니다.

반면 긴급 상황에서 서비스가 중단되면 더 큰 문제가 발생하는 시스템이라면 단순한 차단이 안전한 상태라고 보기 어려울 수도 있습니다.

그래서 실제 설계에서는 Fail Open, Fail Closed라는 용어만 보고 결정하기보다 장애 상황에서 어떤 상태가 안전한지 먼저 정의하는 것이 중요합니다.

개발할 때 가장 중요한 것은 ‘실패했을 때’를 미리 생각하는 것

프로그램을 개발할 때는 정상적인 상황을 먼저 구현하게 됩니다.

예를 들면 다음과 같습니다.

정상적인 인증
정상적인 데이터 조회
정상적인 API 응답
정상적인 네트워크 연결

하지만 실제 서비스에서는 항상 정상적으로 동작하지 않습니다.

네트워크가 끊길 수도 있고 API 서버가 다운될 수도 있습니다.

데이터베이스가 응답하지 않을 수도 있으며 인증 서버에 장애가 발생할 수도 있습니다.

따라서 시스템을 설계할 때는 “정상적으로 동작할 때 어떻게 할 것인가?”뿐만 아니라 “실패했을 때 어떻게 할 것인가?”도 함께 정해야 합니다.

이것이 Fail Open과 Fail Closed를 이해하는 핵심이라고 볼 수 있습니다.

마무리

Fail Open과 Fail Closed는 결국 장애나 오류가 발생했을 때 시스템이 어떤 기본 동작을 취할 것인지 결정하는 개념입니다.

간단하게 정리하면 다음과 같습니다.

Fail Open
→ 오류 발생 시 허용하는 방향

Fail Closed
→ 오류 발생 시 차단하는 방향

하지만 실제 시스템에서는 단순히 어느 한쪽을 선택하는 것으로 끝나지 않습니다.

서비스의 성격, 보안 요구사항, 가용성, 장애 발생 시 영향, 사용자의 접근 필요성 등을 함께 고려해야 합니다.

특히 인증이나 권한처럼 보안과 직접적으로 연결되는 기능이라면 검증에 실패했을 때 접근을 허용해도 되는지를 먼저 생각해봐야 합니다.

반대로 서비스 이용 자체가 중요한 기능이라면 외부 시스템 하나의 장애 때문에 전체 서비스가 중단되지 않도록 예외 처리나 제한적인 운영 방식을 함께 고려할 수도 있습니다.

결국 좋은 시스템 설계는 오류가 발생하지 않는 것만 생각하는 것이 아니라 오류가 발생했을 때 어떤 상태로 넘어갈 것인지까지 미리 정해놓는 것에서 시작합니다.

개발하면서 인증, 방화벽, API, 접근 제어 같은 기능을 구현하고 있다면 정상적인 상황의 코드만 작성하지 말고 한 번쯤 이런 질문을 던져보는 것도 좋습니다.

“이 기능이 지금 죽는다면 우리 시스템은 문을 열어야 할까, 닫아야 할까?”

바로 이 질문에서 Fail Open과 Fail Closed에 대한 고민이 시작됩니다.