소개

상황을 떠올려 보자. 인시던트 채널은 불이 나고, 대시보드는 온통 빨간색이며, 서비스는 살아났다 죽었다를 반복한다. 그런데 각 서브시스템을 따로 들여다보면 하나같이 이렇게 말한다.

“나 문제 없는데요?”

알람은 서로 모순되고, 로그는 말이 안 맞고, 머릿속에 있던 시스템 모델은 압박 속에서 와르르 무너진다.

이게 바로 분할 브레인(split‑brain) 장애가 체감되는 순간이다.

이 글에서는 픽션이지만 꽤 현실적인 시나리오를 사용해 이 상황을 풀어본다. 바로 아날로그 인시던트 노면전차 스위치보드(Analog Incident Streetcar Switchboard, AISS) 다. 시스템 곳곳을 돌아다니는 “노면전차(incident)”를 라우팅하는 옛날식 물리 제어판이라고 생각하면 된다. 약간은 패러디고, 약간은 교육 도구지만, 복잡한 연쇄 장애를 이해하는 데 놀라울 만큼 효과적이다.

이 글에서 다룰 내용은 다음과 같다.

• “아날로그 인시던트 노면전차 스위치보드” 사례가 어떻게 생겼는지
• 분산 장애가 어떻게 전파되며 작은 문제가 어떻게 대형 장애로 커지는지
• 왜 “2+1” 분할 브레인 시나리오가 그렇게 위험한지
• 쿼럼(quorum) 설계와 테이블탑(tabletop) 연습이 실제 시스템을 어떻게 더 탄탄하게 만드는지
• 왜 인시던트 후 회고를 널리 공유하는 것이 선택이 아니라 필수인지

아날로그 인시던트 노면전차 스위치보드(AISS)

커다란 물리 스위치보드가 벽에 붙어 있다고 상상해보자.

• 각 노면전차 노선 = 핵심 서비스 (인증, 과금, 검색, 메시징 등)
• 각 스위치 = 라우팅 결정 (어느 리전, 어느 데이터베이스, 어느 캐시로 보낼지)
• 각 램프 = 헬스 신호 또는 알람
• 옆에 꽂혀 있는 작은 인쇄 지도 = 시스템 다이어그램

이게 바로 당신의 아날로그 인시던트 노면전차 스위치보드(AISS) 다. 평소에는 노면전차가 제시간에 잘 다닌다. 불빛은 익숙한 패턴으로 깜빡이고, 운용자(온콜 엔지니어)는 그 리듬을 몸으로 안다.

이제 여기에 심각한 인시던트를 주입해 보자.

AISS에서 벌어진 “분할 브레인” 장애

중심 리전 하나에 큰 네트워크 장애가 발생한다.

• 리전 A와 리전 B 사이 링크에서 패킷 드롭이 발생하기 시작한다.
• 리전 C에서 보는 모니터링은 불규칙한 하트비트를 감지한다.
• 어떤 운용자의 콘솔에는 A가 프라이머리로, 어떤 콘솔에는 B가 프라이머리로 보인다.

스위치보드에서는 이런 일이 벌어진다.

• 리전 A 램프는 로컬에선 초록불인데, 집계 대시보드에선 빨간불이다.
• 리전 B 램프는 노란색과 초록색 사이에서 깜빡인다.
• “인증(auth)” 노면전차는, 어떤 패널을 보느냐에 따라 A와 B로 동시에 라우팅된다.

당신은 분할 브레인(split‑brain) 세계로 들어왔다. 시스템의 서로 다른 부분이, 누가 살아 있는지, 누가 프라이머리인지, 쓰기 트래픽을 어디로 보내야 하는지에 대해 서로 다른 현실을 보고 있다.

이 지점부터 실제 장애는 더 이상 “X 컴포넌트의 버그”가 아니라, 다음이 뒤엉긴 복잡계 사고(complex system accident) 가 된다.

• 부분적인 네트워크 파티션
• 서로 충돌하는 타임아웃과 재시도 전략
• 일관되지 않은 쿼럼 결정
• 서로 다른 멘탈 모델을 가진 사람들의 운영 행동

분산 장애는 왜 노면전차처럼 연쇄적으로 무너지는가

분산 시스템은 깔끔하게 망가지지 않는다. 러시아워에 꼬여버린 철도망처럼 망가진다.

핵심적인 장애 특성은 다음과 같다.

1. 로컬 문제가 금방 글로벌 문제가 된다
   조용한 국지적 문제(노드 하나의 이상 동작, 플래핑(flapping) 링크)는 다음을 유발할 수 있다.

   • 재시도 폭증과 쓰나미(소위 thundering herd)
   • 커넥션 풀 고갈
   • 이웃 노드 과부하
   • 중앙 인증 서비스 같은 공유 의존성 전체를 넘어뜨림

2. 상태 불일치가 전염된다
   서로 다른 노드는 서로 다른 현실을 본다.

   • 노드 A: “노드 B가 안 보이네. 내가 리더가 되어야겠다.”
   • 노드 B: “노드 A가 안 보이네. 내가 리더가 되어야겠다.”
   • 클라이언트: “가끔은 A가 리더고, 가끔은 B가 리더네. 둘 다 계속 두드려 본다.”

3. 관측 가능성(observability)은 ‘빠진 것’으로 거짓말한다
   링크가 끊어지면, 고립된 쪽의 메트릭과 로그는 중앙 스토리지까지 도달하지 못한다. 그러면 이런 일이 벌어진다.

   • 대시보드에 구멍이 뚫린다.
   • 꼭 필요한 시점의 로그가 사라진다.
   • 멀쩡해 보이는 패널 뒤에, 보이지 않는 장애가 숨어 있다.

AISS 관점에서 보면, 이는 곧 보기에는 멀쩡한 선로로 노면전차를 계속 라우팅하고 있지만, 실제로는 막다른 길에 밀어 넣고 있다는 것이고, 다른 노선들은 아무도 볼 수 없는 터널 안에서 조용히 쌓여 간다는 뜻이다.

“2+1” 분할: 쿼럼 규칙이 가용성을 해치는 순간

대부분의 현대 분산 시스템은 Raft, Paxos 같은 합의 알고리즘을 변형해 쿼럼 기반(quorum‑based) 결정을 내린다.

• 노드가 3개면, 쿼럼은 2다.
• 노드가 5개면, 쿼럼은 3이다.

일관성(consistency) 측면에서는 훌륭하지만, 네트워크 파티션 상황에서는 여전히 곤혹스러운 패턴이 나온다.

2+1 시나리오

3노드 클러스터(N1, N2, N3)가 있다고 하자.

• 부분적인 파티션으로 N3가 고립된다.
• N1과 N2는 서로 통신이 가능하다.

결과는 다음과 같다.

• N1 + N2는 여전히 쿼럼을 유지하며 권위 있는(leader를 포함한) 쪽으로 남는다.
• N3는 쿼럼을 잃고 리더에서 내려온다. 이상적으로는, 읽기 전용이 되거나 완전히 사용 불가 상태가 되어야 한다.

일관성 관점에선 우리가 바라던 동작이다. 하지만 운영(AISS) 관점에서 보면 이렇게 보인다.

• N3가 있는 랙 근처 패널에서는, 로컬 노드가 “살아 있지만 외톨이”인 상태로 보인다.
• N3만 조회하는 지역 상태 페이지는 초록불(정상) 을 띄운다.
• 전역 컨트롤 플레인은 N1 + N2 덕분에, 클러스터를 ‘성능 저하(degraded)지만 서비스 중’ 으로 표시한다.

그러면 서로 다른 신호가 튀어나온다.

• “내 노드는 살아 있는데?” (N3)
• “클러스터는 살아 있는데?” (N1 + N2)
• “일부 클라이언트는 타임아웃 난다” (트래픽이 N3가 있는 존에 ‘붙들려’ 있기 때문)

시스템은 데이터 손상(data corruption)으로부터 우리를 지켜 주었지만, 사용자 경험은 여전히 망가지고, 운용자들은 대시보드 해석을 두고 소중한 시간을 소모하게 된다.

왜 노드 하나 장애가 쿼럼 상실로 이어지면 안 되는가

그래서 잘 설계된 클러스터는 노드 하나 정도의 손실로는 쿼럼이 깨지지 않도록 한다.

• 3노드 클러스터는 노드 1개 장애를 견딜 수 있다.
• 5노드 클러스터는 노드 2개 장애를 견딜 수 있다.

실제로는 다음과 같은 의미다.

• 복제 계수(replication factor) 와 장애 도메인(가용영역, 랙, 리전 등) 을 신중하게 선택한다.
• 특정 “특별한” 노드 하나에 너무 많은 역할을 몰아줘, 그 노드가 죽으면 전체 시스템이 멈추는 설계를 피한다.

이렇게 하면 대부분 워크로드에서 더 나은 복원력(resilience) 과 비용 효율성 을 얻을 수 있다. 노드를 몇 개 더 쓰는 대신, 머신 하나나 링크 하나 이상 동작만으로 전체 클러스터가 날아가는 상황을 피하는 것이다.

하지만 쿼럼 수학을 아무리 잘 짜도, 헷갈리는 2+1 반쪽 장애(half‑degraded) 시나리오 자체를 없앨 수는 없다. 프로토콜만큼이나 프로세스와 운영 문화 가 중요하다.

테이블탑 연습: 종이 위에서 노면전차 노선을 따라가 보기

첫 번째 복잡한 인시던트를 실제 프로덕션에서 겪고 싶진 않을 것이다.

강력한 도구 중 하나가 바로 테이블탑(tabletop) 연습이다. 구조화된, 저스트레스 리허설로, 구체적이고 현실적인 시나리오를 가지고 진행한다.

AISS 분할 브레인 장애 같은 상황을 테이블탑으로 연습한다면 대략 다음과 같을 것이다.

1. 시나리오 준비하기

   • 리전 A와 리전 B 사이 네트워크 파티션
   • 말끔히 끊기는 게 아니라, 간헐적 패킷 손실이 나는 상황
   • 일부 헬스 체크는 성공하고, 일부는 실패하는 상태
   • 큐, 캐시 같은 몇몇 종속 서비스가 리전마다 다르게 행동하도록 설정

2. 종이 자료 인쇄하기

   • 시스템 다이어그램
   • T+5, T+15, T+30 시점의 단순화된 로그와 메트릭 스냅샷
   • 사용자 제보(지원 티켓, synthetic 체크 결과, 상태 페이지에 올라온 불만)

3. 역할 배정하기

   • 인시던트 커맨더(Incident Commander)
   • 커뮤니케이션 담당(상태 페이지, 내부 공지)
   • 각 서브시스템(DB, 네트워크, 애플리케이션, 관측/모니터링) 담당 운용자

4. “노면전차 노선”을 따라가 보기

   • 하나의 사용자 요청이 다음을 따라 흐를 때를 추적한다.
     • DNS → 엣지(Edge) → 앱 → 캐시 → DB
   • 동일한 요청이 리전 A에 도착했을 때와 리전 B에 도착했을 때 각각 어떻게 다르게 동작하는지 보여준다.
   • 시스템의 서로 다른 뷰에서 상충되는 신호가 어떻게 보이는지 드러낸다.

5. 어려운 의사결정을 강제로 하게 만들기

   • 언제 한 리전으로 트래픽을 완전히 페일오버할 것인가?
   • 언제 특정 리전의 리더를 강등(demote)할 것인가?
   • 서로 다른 뷰가 충돌할 때, 어떤 신호를 “권위 있는(authoritative)” 신호로 볼 것인가?

이런 테이블탑 연습을 통해 근육 기억(muscle memory) 을 만들 수 있고, 비용이 낮을 때 설계상 허점을 드러낼 수 있다.

인시던트 이후 학습 공유: 하나의 스위치보드에서 전체 조직으로

AISS 장애는 그날 온콜을 섰던 사람들만 기억하는 무용담으로 끝나서는 안 된다. 이 사례는 다음을 바꾸는 케이스 스터디 가 되어야 한다.

• 새로운 서비스를 설계하는 방식
• 쿼럼과 페일오버를 구성하는 방식
• 관측 가능성과 상태 페이지를 설계하는 방식

그러려면 반드시 학습 내용을 널리 공유 해야 한다.

효과적인 패턴은 다음과 같다.

• 블레이멀리스(blameless) 인시던트 리뷰 를 내부에 공개
• 각 팀이 자기 관점에서 본 인시던트 타임라인을 가져와 발표하는 크로스팀 데브리핑
• 해당 장애 사례를 예시로 반영해 업데이트한 아키텍처 가이드라인
• 같은 시나리오를 재사용하는 교육 자료 (런북, 테이블탑 덱, 온보딩 콘텐츠 등)

목표는 “그 서비스 하나를 고쳤다”에서 멈추지 않고, “조직 전체의 시스템 설계 방식이 바뀌었다” 로 가는 것이다.

다음에 누군가 새로운 컨트롤 플레인을 설계할 때, 이미 이런 질문을 하고 있어야 한다.

• 이 시스템은 2+1 분할 상황에서 어떻게 동작할까?
• 관측 파이프라인 자체가 파티션되면 어떻게 될까?
• 서로 다른 뷰가 충돌할 때, 어떤 신호를 권위 있는 소스로 볼 것인가?

이게 바로 “아날로그 인시던트 노면전차 스위치보드” 같은 생생한 사례가 주는 진짜 보상이다.

결론

아날로그 인시던트 노면전차 스위치보드는 가상이지만, 이 사례가 보여주는 패턴은 매우 현실적이다.

• 분산 장애는 빠르고, 예측하기 어려운 방식으로 전파된다.
• 분할 브레인과 2+1 시나리오는 단순한 다운타임을 넘어서 서로 다른 현실 을 만들어낸다.
• 쿼럼 설계는 노드 하나 장애로 시스템 전체가 내려가지 않도록 해야 한다.
• 아무리 설계를 잘해도, 결국 얼마나 사람과 프로세스 가 잘 준비됐는지가 장애의 크기를 좌우한다.

이를 위해서는:

• 현실적이고 지저분한 시나리오를 활용한 테이블탑 연습 을 하고
• 단일 노드 손실로는 쿼럼이 깨지지 않는 클러스터와 장애 도메인을 설계하고
• 인시던트 이후의 학습을 조직 전체에 광범위하게 공유 함으로써

혼란스럽고 스트레스가 심한 장애를, 강력하고 재사용 가능한 학습 자산으로 바꿀 수 있다.

다시 말해, 노면전차가 터널 안에 산더미처럼 쌓일 때까지 기다리지 말자. 종이 위에서 노선을 따라가 보고, 어려운 결정을 미리 연습해 두며, 한 번의 아날로그 인시던트 노면전차 스위치보드 장애가 당신 조직의 ‘시스템 도시’ 전체를 개선하도록 만들자.