452. 가용성 (Availability)

핵심 인사이트 (3줄 요약)

본질: 가용성 (Availability)은 시스템이 "고장 나지 않는가"만이 아니라, 장애가 생겨도 사용자가 필요한 순간에 서비스를 계속 받을 수 있는지를 수치로 표현한 운영 지표다.

가치: 같은 하드웨어라도 평균 고장 간격인 MTBF (Mean Time Between Failures)보다 평균 복구 시간인 MTTR (Mean Time To Repair)을 얼마나 짧게 줄이느냐에 따라 체감 품질이 크게 달라진다.

판단 포인트: 가용성은 무조건 100%를 외치는 문제가 아니라, 비즈니스 손실과 설계 비용을 비교해 적절한 이중화 수준과 장애 복구 전략을 선택하는 문제다.

Ⅰ. 개요 및 필요성

가용성 (Availability)은 시스템이 요구된 시간 동안 실제로 서비스를 제공할 수 있는 능력이다. 신뢰성 (Reliability)이 "얼마나 오래 안 고장 나는가"에 초점을 둔다면, 가용성은 "고장이 나더라도 사용자는 서비스를 계속 쓸 수 있는가"에 초점을 둔다. 그래서 가용성은 부품 품질만으로 결정되지 않고, 이중화 구조, 복구 자동화, 운영 절차까지 포함한 시스템 전체 설계의 결과가 된다.

이 개념이 중요해진 이유는 현대 정보시스템이 단순 계산기가 아니라 항상 연결되어 있어야 하는 사회 인프라가 되었기 때문이다. 은행 이체, 항공 예약, 공장 제어, 클라우드 서비스는 몇 분의 중단만으로도 매출 손실, 신뢰 추락, 안전 문제를 일으킨다. 결국 성능이 조금 느린 시스템보다, 필요할 때 살아 있는 시스템이 더 높은 가치를 가진다.

가용성은 보통 연간 가동률과 허용 다운타임으로 설명한다. 숫자의 차이는 작아 보여도 운영 난이도는 기하급수적으로 올라간다.

┌──────────────────────────────────────────────────────────────┐
│       가용성 수준과 연간 허용 다운타임의 감각적 차이        │
├───────────────┬──────────────────────────────┬───────────────┤
│ 가용성 수준   │ 연간 허용 다운타임           │ 체감 의미     │
├───────────────┼──────────────────────────────┼───────────────┤
│ 99%           │ 약 3.65일                    │ 가끔 멈춤     │
│ 99.9%         │ 약 8.76시간                  │ 월간 점검 허용│
│ 99.99%        │ 약 52.6분                    │ 무중단 운영 근접│
│ 99.999%       │ 약 5.26분                    │ 미션 크리티컬 │
└───────────────┴──────────────────────────────┴───────────────┘

즉 가용성은 "안 멈추는 시스템"이라는 추상 구호가 아니라, 허용 가능한 중단 시간을 얼마나 엄격하게 관리할 것인지에 대한 계약이자 설계 목표다. 여기서 서비스 수준 협약인 SLA (Service Level Agreement)가 등장하며, 운영팀은 이 수치를 지키기 위해 구조적 대비를 해야 한다.

📢 섹션 요약 비유: 가용성은 병원의 응급실과 같다. 의사가 한 번도 쉬지 않는 것이 핵심이 아니라, 환자가 언제 와도 바로 치료받을 수 있게 교대 인력과 예비 장비가 준비되어 있어야 한다.

Ⅱ. 아키텍처 및 핵심 원리

가용성의 기본 식은 아래와 같다. 시스템을 아무리 튼튼하게 만들어도 복구가 오래 걸리면 가용성은 내려가고, 반대로 고장이 다소 자주 나더라도 빠르게 우회·복구하면 높은 가용성을 달성할 수 있다.

[ Availability = \frac{MTBF}{MTBF + MTTR} ]

여기서 핵심은 MTBF를 늘리는 노력과 MTTR을 줄이는 노력이 서로 다른 설계 수단을 가진다는 점이다. 전자는 고품질 부품, 오류 검출, 예방 정비에 가깝고, 후자는 이중화, 자동 장애 감지, 페일오버 (Failover), 핫스왑 (Hot Swap)에 가깝다.

요소	의미	높이거나 줄이는 방법	설계 시사점
MTBF (Mean Time Between Failures)	평균 고장 간격	ECC (Error Correcting Code) 메모리, 품질 부품, 열 설계 개선	장애 빈도를 낮춤
MTTR (Mean Time To Repair)	평균 복구 시간	자동 재시작, 예비 장비, 운영 자동화	장애 지속 시간을 단축
SPOF (Single Point of Failure)	단일 장애점	이중 전원, 다중 경로, 이중 컨트롤러	전체 중단 위험 제거
HA (High Availability)	고가용성 구조	Active-Active, Active-Standby	사용자 체감 중단 최소화

아래 그림은 가용성이 단순히 "서버 2대"의 문제가 아니라, 감지-판단-전환-복구의 연쇄 메커니즘임을 보여준다.

┌────────────────────────────────────────────────────────────────────┐
│                고가용성 동작 흐름: 장애를 서비스 밖으로 숨기기    │
├────────────────────────────────────────────────────────────────────┤
│ 사용자 요청                                                        │
│    │                                                               │
│    ▼                                                               │
│ 로드밸런서 (Load Balancer) ── Health Check ──┐                     │
│    │                                         │                     │
│    ├────────────▶ 주 서버 (Active) ── 장애 발생 ──┐               │
│    │                                              │               │
│    └────────────▶ 예비 서버 (Standby) ◀───────────┘               │
│                               │                                    │
│                               ▼                                    │
│                     세션 승계 · 재시도 · 서비스 지속                │
└────────────────────────────────────────────────────────────────────┘

이 구조의 포인트는 장애를 없애는 것이 아니라, 사용자가 장애를 느끼기 전에 경로를 바꾸는 것이다. 따라서 가용성 설계에서는 장애 감지 주기, 상태 동기화 범위, 전환 시간, 데이터 일관성 비용이 함께 고려되어야 한다. 빠른 전환만 보고 설계하면 데이터가 어긋날 수 있고, 일관성만 강조하면 전환 시간이 길어질 수 있다.

📢 섹션 요약 비유: 가용성 구조는 비행기의 이중 엔진과 같다. 한쪽 엔진이 멈췄을 때 중요한 것은 "왜 멈췄나"를 즉시 분석하는 것보다, 남은 엔진으로 바로 비행을 계속해 추락을 막는 것이다.

Ⅲ. 비교 및 연결

가용성을 정확히 이해하려면 비슷해 보이는 개념들과 경계를 구분해야 한다. 특히 신뢰성, 서비스성, 장애 허용성과의 차이를 구분해야 설계 목표가 흐려지지 않는다.

구분	초점	대표 질문	대표 수단
신뢰성 (Reliability)	얼마나 오래 고장 없이 버티는가	"언제 고장 나는가?"	품질 향상, 오류 예방
가용성 (Availability)	지금 서비스를 쓸 수 있는가	"지금 살아 있는가?"	이중화, 빠른 복구
서비스성 (Serviceability)	얼마나 쉽게 수리할 수 있는가	"얼마나 빨리 고칠 수 있는가?"	모듈 교체, 진단 기능
장애 허용성 (Fault Tolerance)	장애 중에도 계속 동작하는가	"고장 중에도 멈추지 않는가?"	중복 실행, 실시간 대체

가용성은 RAS (Reliability, Availability, Serviceability) 관점에서 가운데 연결축 역할을 한다. 신뢰성이 높으면 장애 빈도가 줄고, 서비스성이 높으면 복구 시간이 짧아져 결국 가용성이 올라간다. 그래서 컴퓨터구조에서는 ECC 메모리, RAID (Redundant Array of Independent Disks), 이중 전원 같은 하드웨어 기법을 다루고, 시스템 관점에서는 클러스터링, 체크포인팅, 로드밸런싱 같은 소프트웨어 기법이 결합된다.

또한 가용성은 분산시스템의 일관성 문제와도 연결된다. 예를 들어 Active-Active 구조는 서비스는 잘 살아 있지만, 데이터 동기화가 늦으면 읽기 결과가 달라질 수 있다. 반대로 완전한 동기 복제를 고집하면 가용성보다 일관성을 우선하는 선택이 된다. 결국 가용성은 독립된 숫자가 아니라, 성능·비용·일관성과 맞물린 절충의 결과다.

📢 섹션 요약 비유: 신뢰성은 자동차가 잘 안 고장 나는 성질이고, 가용성은 고장 나도 바로 대체 차량을 보내 손님 약속을 지키는 능력이다. 둘은 비슷해 보여도 돈을 쓰는 방향이 다르다.

Ⅳ. 실무 적용 및 기술사 판단

실무에서 가용성 설계는 "몇 개의 9를 목표로 할 것인가"에서 시작한다. 모든 서비스에 Five Nines를 적용하면 비용이 과도하게 커지고 구조도 복잡해진다. 따라서 아키텍트는 장애 1분당 손실, 법적 규제, 사용자 기대치, 운영 인력 수준을 함께 보고 목표치를 정해야 한다.

예를 들어 사내 포털은 짧은 야간 점검이 허용될 수 있지만, 결제 시스템이나 제조 제어 시스템은 계획 정지조차 민감하다. 이 경우 단순 백업만으로는 부족하고, 최소한 N+1 예비 자원, 다중 전원, 네트워크 경로 이중화, 데이터 복제, 자동 페일오버를 함께 설계해야 한다. 특히 겉으로는 서버를 여러 대 두었더라도 DNS, 스토리지, 인증 서버, 네트워크 스위치 중 하나가 단일 장애점으로 남아 있으면 전체 가용성은 무너진다.

실무 판단 체크리스트

목표 SLA에 맞는 허용 다운타임이 수치로 정의되어 있는가?
서버·스토리지·전원·네트워크 중 SPOF가 제거되었는가?
장애 감지부터 전환까지가 수동 절차가 아니라 자동화되어 있는가?
복구 후 데이터 정합성 검증 절차까지 포함되어 있는가?
정기 점검과 배포도 서비스 중단 없이 수행할 수 있는가?

자주 보이는 안티패턴

서버는 이중화했지만 데이터베이스는 단일 인스턴스로 둔 경우
백업은 있으나 복구 리허설이 없어 실제 MTTR을 모르는 경우
장애 전환은 가능하지만 세션/캐시 동기화가 없어 사용자 오류가 발생하는 경우
지나치게 복잡한 Active-Active 구조를 도입해 운영팀이 감당하지 못하는 경우

기술사 답안 관점에서는 "가용성을 높인다"라는 문장만으로는 부족하다. 어떤 계층의 어떤 단일 장애점을 제거하고, MTTR을 어떤 방법으로 줄이며, 그 대가로 비용과 복잡성이 어떻게 증가하는지를 함께 써야 설계 판단이 된다.

📢 섹션 요약 비유: 가용성 설계는 건물에 비상구를 하나 더 만드는 일과 비슷하다. 중요한 것은 문을 많이 그려 넣는 것이 아니라, 정전이 나도 자동으로 열리고 사람들이 실제로 그 문으로 빠져나갈 수 있게 만드는 것이다.

Ⅴ. 기대효과 및 결론

가용성이 잘 설계된 시스템은 단순히 장애가 적은 시스템이 아니라, 장애가 사업 중단으로 번지지 않는 시스템이 된다. 사용자 입장에서는 서비스 신뢰도가 올라가고, 운영팀 입장에서는 장애 대응이 예측 가능해지며, 기업 입장에서는 SLA 위반 비용과 평판 손실을 줄일 수 있다. 즉 가용성은 기술적 미덕이면서 동시에 경영 지표다.

다만 가용성 향상에는 분명한 전제조건이 있다. 첫째, 이중화는 상태 동기화와 함께 설계되어야 하며, 둘째, 자동화는 충분한 테스트와 모니터링이 뒷받침되어야 하고, 셋째, 높은 가용성 목표는 그에 맞는 운영 성숙도를 요구한다. 장비만 많이 사는 것으로는 고가용성이 완성되지 않는다.

앞으로의 방향은 단순 예비 장비 확보를 넘어, 예측 장애 분석, 자율 복구, 무중단 배포, 지역 간 트래픽 분산으로 확장된다. 따라서 가용성은 "절대 안 고장 나는 컴퓨터"로 기억하기보다, "고장을 전제로 하되 서비스를 멈추지 않게 만드는 설계 철학"으로 기억하는 것이 정확하다.

📢 섹션 요약 비유: 가용성의 핵심은 완벽한 선수 한 명이 아니라, 누가 빠져도 경기를 계속 이어 가는 팀 전술이다. 강한 팀은 실수가 없어서가 아니라, 실수 뒤에도 무너지지 않아서 강하다.

📌 관련 개념 맵

개념	연결 포인트
MTBF (Mean Time Between Failures)	장애 빈도를 줄여 가용성의 분자를 키우는 핵심 지표
MTTR (Mean Time To Repair)	복구 시간을 줄여 가용성 하락 폭을 최소화하는 핵심 지표
SPOF (Single Point of Failure)	하나만 고장 나도 전체 서비스가 멈추는 구조적 약점
HA (High Availability)	이중화와 자동 전환으로 높은 가용성을 구현하는 운영 구조
장애 허용성 (Fault Tolerance)	장애가 발생한 순간에도 서비스 중단 없이 계속 동작하게 하는 상위 개념
SLA (Service Level Agreement)	가용성을 계약과 운영 목표로 수치화한 기준

📈 관련 키워드 및 발전 흐름도

고장 예방 중심 설계
    │
    ▼
신뢰성 (Reliability) · MTBF
    │
    ▼
서비스성 (Serviceability) · MTTR
    │
    ▼
가용성 (Availability) · SPOF 제거
    │
    ▼
HA (High Availability) · Failover · Clustering
    │
    ▼
무중단 운영 · 자율 복구 · 지역 간 분산

이 흐름은 "안 고장 나는 부품"에서 출발해 "고장 나도 계속 서비스하는 시스템"으로 발전하는 관점을 보여준다.

👶 어린이를 위한 3줄 비유 설명

가용성은 가게가 비가 오든 밤이든 손님이 왔을 때 문을 열어 줄 수 있는 힘이에요.
가게 주인이 잠깐 아파도 다른 사람이 바로 대신 계산하면 손님은 가게가 멈춘 줄 몰라요.
그래서 좋은 시스템은 아예 안 망가지는 것보다, 망가져도 바로 이어서 일하게 준비해 두는 거예요.