연필로 그린 인시던트 수족관

대규모 장애가 터져 전사 ‘워 룸(war room)’에 들어간 상황을 떠올려 보자.

한쪽 벽에는 거대한 손그림 수족관이 걸려 있다. 유리, 파이프, 수초는 거친 연필선으로 그려져 있고, 그 안에는 수십 마리의 종이 물고기가 실에 매달려 떠 있다. 물고기 한 마리마다 서비스 이름이 휘갈겨 적혀 있다: payments-api, search-indexer, notifications, auth-gateway.

인시던트가 진행되는 동안 어떤 물고기는 위로 떠오르고, 어떤 물고기는 옆으로 밀려나며, 다른 물고기들은 빨간색으로 표시되거나 뒤집힌다. 엔지니어들이 물고기를 뒤집어 뒷면에 새 메모를 적어 넣기 때문이다. 색깔 있는 실로는 데이터 플로우와 의존 관계가 표시되어 있다. 누가 누구를 호출하는지, 무엇이 고장 나면 무엇이 함께 깨지는지가 한눈에 보인다. 전체적으로는 장난감 같은 모습이지만, 실상은 매우 진지하다.

이것이 바로 연필로 그린 인시던트 수족관(Pencil-Drawn Incident Aquarium) 이다. 실제 프로덕션 환경에서 벌어지는 일을 물리적으로 형상화한 메타포다. 종이 물고기들은 각자의 서비스이고, 연필선은 시스템 아키텍처다. 물고기들이 어떻게 움직이는지는 숨겨진 신뢰성의 흐름(hidden reliability currents) 을 보여준다. 장애가 어떻게 전파되는지, 사소한 설정 변경이 시스템 전체에 어떤 파장을 일으키는지, 단 하나의 의존성이 어떻게 조용히 모든 것을 끌어내릴 수 있는지를 시각화해 준다.

대부분의 조직에서는 이런 흐름이 무언가가 부서질 때까지는 보이지 않는다.

이 글에서는 이 수족관 메타포를 정신 모델로 삼아 다음을 어떻게 구현할 수 있는지 살펴본다.

• 인시던트 대응을 더 차분하고 효과적으로 만드는 방법
• 정적인 문서 모음이 아니라, 살아 있는 지식 시스템으로서의 신뢰성 프로그램을 구축하는 방법
• 과도한 사전 확장(premature scale) 과 숨겨진 복잡성의 함정을 피하는 방법
• 일상 업무 속에 신뢰성을 녹여 수족관이 항상 최신 상태를 유지하게 하는 방법

1. 인시던트 대응: 자동화로 물을 가라앉히기

대형 인시던트 중의 사람들은 거친 물살 속 다이버와 같다. 시야는 제한적이고, 숨은 부족하며, 스트레스는 높다. 대시보드를 찾고, 잘못된 사람을 호출하고, 로그를 복사하고 붙여넣는 등 모든 수동적인 마찰은 가장 중요한 일, 즉 상황을 빠르게 이해하고 좋은 결정을 내리는 일에서 집중력을 빼앗아 간다.

수족관 메타포에서 인시던트 대응은 갑자기 물살이 바뀌어 절반의 물고기가 배를 뒤집는 순간에 일어난다. 이때 가장 피해야 할 것은 다음과 같은 상황이다.

• 컨퍼런스 브리지를 매번 수동으로 생성해야 하거나
• 똑같은 차트와 쿼리를 매번 처음부터 다시 만들거나
• 어느 물고기를 누가 소유하는지 추측해야 하거나
• 맥락을 파악하려고 다섯 개의 도구를 전전하며 클릭하는 일

일상적인 자동화와 단순화된 워크플로우는 물을 맑게 유지하는 펌프와 필터 역할을 한다.

• 자동 인시던트 생성 및 라우팅: 설정된 임계값을 넘는 알람이 자동으로 인시던트를 열고, 심각도(severity)를 지정하며, 적절한 팀으로 라우팅한다.
• 표준화된 인시던트 룸: 새 인시던트마다 미리 정의된 템플릿으로 채팅 채널, 문서, 타임라인이 생성되고, 체크리스트와 관련 링크가 자동으로 붙는다.
• 원클릭 컨텍스트: 영향받은 각 “물고기”(서비스)에 대해 대응자는 즉시 다음 정보를 볼 수 있다.
  • 서비스 오너와 온콜 담당자
  • 최근 배포 및 설정 변경 이력
  • 헬스 대시보드와 로그
  • 다운스트림 의존성

목표는 의사결정을 자동화하는 것이 아니라, 의사결정을 둘러싼 마찰을 자동화해 제거하는 것이다. 반복적이고 예측 가능한 단계들을 자동화할수록, 대응자들은 물살 자체를 이해하는 데 더 많은 정신적 여유를 가질 수 있다.

이 작업이 잘 되어 있으면, 인시던트 프로세스는 온갖 것을 더듬어 찾는 탁한 수조가 아니라, 각 물고기와 기포, 흐름이 선명하게 보이는 맑은 수족관처럼 느껴지기 시작한다.

2. 체크리스트가 아닌 지식 기반 시스템으로서의 신뢰성

강력한 신뢰성 프로그램은 단순한 툴 모음이나 컴플라이언스 체크리스트가 아니다. 조직의 구체적인 제품, 사용자, 제약 조건에 기반해 구축되는 복잡한 지식 기반 시스템이다.

수족관 안에서 이 지식은 다음과 같은 모습으로 드러난다.

• 왜 특정 물고기들이 서로 가까이 묶여 있는지
• 어떤 파이프는 왜 이중으로 보강되어 있는지
• 어떤 물살은 거칠어도 괜찮고, 어떤 구역은 반드시 고요해야 하는지

실제 조직에서는 이것이 다음과 같은 형태를 띤다.

• 맥락에 맞는 SLO와 에러 버짓: 모든 것에 5 nines(99.999%)를 요구할 필요는 없다. 마케팅 랜딩 페이지와 핵심 결제 API를 같은 기준으로 평가해서는 안 된다.
• 현실에 기반한 런북(runbook): “서비스를 재시작하라”는 식의 피상적인 단계가 아니라, 풍부한 맥락을 담은 지식이다. 예: “이 메트릭이 튀고, 이 의존성이 불안정하면 보통 DNS 문제이거나 rate limiting 이슈다. 여기서부터 확인하라.”
• 도메인에 맞는 아키텍처 패턴: 어떤 도메인은 결국 일관성(eventual consistency)을 허용하지만, 돈 이체나 의료 기록처럼 절대 허용할 수 없는 도메인도 있다.

이 지식 시스템은 다음을 만족해야 한다.

• 포스트 인시던트 리뷰를 통해 지속적으로 업데이트되고
• 프로덕션을 만지는 누구라도 발견 가능하며
• 툴링, 문서, 코드 주석 등 곳곳에 내재화되어 있고, 특정 개인의 머릿속에만 머물지 않아야 한다.

연필로 그린 인시던트 수족관이라는 메타포는, 이 그림이 결코 완성되지 않는다는 사실을 일깨워 준다. 환경의 복잡성은 살아 움직이며 계속 진화하고, 신뢰성 프로그램 또한 그에 맞춰 함께 성장해야 한다.

3. 리더십: 유리를 계속 다시 그리는 손

신뢰할 수 있는 시스템은 신뢰할 수 있는 조직에서 나온다. 그 시작점은 리더십이다.

리더십의 의지는 다음과 같은 구체적인 모습으로 드러난다.

• 신뢰성이 부가 활동이 아니라 우선순위다: 용량 계획, 카오스 실험, 런북 작성, 아키텍처 리뷰 등 신뢰성 작업에 명시적으로 시간을 배정한다.
• 건강한 트레이드오프를 장려한다: 핵심 신뢰성을 지키기 위해 기능 출시를 늦추는 것이 수용 가능하며, 오히려 기대되는 행동이다.
• 사람에 대한 투자가 의도적이다: 인시던트 커맨더를 체계적으로 훈련하고, 섀도잉을 장려하며, 깊은 기술 역량을 전략적 자산으로 육성한다.

이런 커밋먼트가 없으면 수족관은 방치된 학급 과제처럼 변한다. 연필선은 바래고, 물고기는 몇 마리 사라져 있고, 누가 무엇에 밥을 줘야 하는지 아무도 모르게 된다.

반대로 리더십이 제 역할을 하면, 리더들은 다음과 같은 행동을 반복한다.

• 항상 묻는다: “이 결정은 신뢰성에 어떤 영향을 주는가?”
• 포스트 인시던트 리뷰에 참석해 기술적 원인뿐 아니라 조직적 근본 원인까지 이해한다.
• 당장 ROI가 나오지 않더라도, 미래의 혼란을 줄여 줄 작업에 기꺼이 예산을 배정한다.

리더십은 물살을 직접 조종하지 않는다. 그러나 조직이 어떤 펌프와 필터, 모니터링을 갖추게 될지, 그 방향을 결정한다.

4. 일상 업무 속에서의 신뢰성, 나중에 붙이는 옵션이 아니라

가장 흔한 실패 패턴 중 하나는 신뢰성을 별도의 트랙으로 취급하는 것이다. 분기별 프로젝트, 특별 팀, “나중에 시간이 나면 하는 일”로 미루는 식이다. 수족관 비유로 보자면, 수조를 만들고 물고기를 잔뜩 넣어둔 뒤 정작 필터 시스템은 내년에 생각해 보자는 꼴이다.

효과적인 팀은 신뢰성을 일상 운영에 자연스럽게 녹여 넣는다.

• 디자인 리뷰에서: 새로운 기능은 항상 “이건 어떻게 실패할 수 있는가? 그리고 우리는 그걸 어떻게 감지할 것인가?”를 답해야 한다.
• 코드 리뷰에서: 타임아웃, 재시도 정책, 멱등성(idempotency), 관측 가능성(observability) 등 신뢰성 요소가 체크리스트에 포함된다.
• 스프린트 계획에서: 모니터링/로깅 개선, 회복력(resilience) 강화, 인시던트 후속 조치 같은 작업이 제품 기능과 나란히 우선순위로 올라간다.
• 온보딩 과정에서: 신규 엔지니어는 첫날부터 인시던트 프로세스와 신뢰성에 대한 조직의 기대치를 학습한다.

이처럼 신뢰성이 흐름 속에 통합되면, 수족관은 계속 최신 상태로 유지된다. 새로운 물고기가 추가될 때마다, 이름이 붙고, 의존성이 기록되며, 물살이 바뀌었을 때 어떻게 움직일지에 대한 이해가 함께 업데이트된다.

5. 표준 작업: 모든 인시던트를 위한 수영 레인

위기 상황에서 애매함은 버그만큼 위험하다. 표준 작업(Standard Work) 관행은 비상벨이 울렸을 때 모두가 어떻게 움직여야 하는지에 대한 공통된 스크립트를 제공한다.

일반적으로 포함되는 요소는 다음과 같다.

• 명확한 인시던트 역할: 인시던트 커맨더, 커뮤니케이션 리드, 운영 리드, 도메인 전문가 등. 각자 자신이 어떤 레인에 있는지 분명히 안다.
• 통일된 심각도 정의: 한창 혼란 중에 “이게 SEV-1인가 SEV-2인가”를 두고 논쟁하지 않는다.
• 공통 플레이북: 반복적으로 등장하는 인시던트 유형(의존성 성능 저하, 용량 고갈, 설정 드리프트 등)에 대해서는 사전에 합의된 절차가 있다.
• 포스트 인시던트 의식(ritual): 시간 제한이 있는 리뷰, 익숙한 템플릿, 분명한 후속 조치 트래킹 방식이 정착되어 있다.

표준 작업이란 경직됨을 의미하지 않는다. 예측 가능한 구조를 의미한다. 이는 대응자들에게 심리적 안전감을 주고, 그 위에서 상황에 맞는 임기응변을 할 수 있게 한다. 수족관에 잘 표시된 수영 레인이 있을 때, 물이 거칠어져도 물고기들이 서로 부딪혀 엉망이 되는 일을 줄일 수 있다.

6. 과잉 구축의 위험: 수족관이 미로가 될 때

스케일링은 언제나 흥미롭다. 조직은 종종 너무 이른 시점에 가장 진보된 패턴과 도구를 도입하고 싶어 한다. 서비스 메쉬, 복잡한 이벤트 버스, 깊게 쪼갠 마이크로서비스, 복잡한 멀티 리전 토폴로지 등이다.

하지만 너무 이른 단계에서 스케일을 위해 과잉 구축하면, 치명적인 부작용이 생긴다. 바로 신뢰성에 대한 트레이드오프가 가려지고 디버깅이 느려진다는 점이다.

수족관이 파이프와 숨겨진 칸막이, 난해한 필터 시스템으로 가득 찬 미로처럼 변하면 다음과 같은 일이 생긴다.

• 누구도 엔드 투 엔드 플로우를 완전히 설명하지 못한다.
• “저위험” 물고기의 작은 설정 변경이 연쇄적인 장애를 유발한다.
• 신규 엔지니어가 정확한 정신 모델을 갖추는 데만 몇 달이 걸린다.

단순함은 곧 신뢰성의 기능이다.

수족관을 이해 가능한 수준으로 유지하는 원칙은 다음과 같다.

• 현재 요구를 충족하는 가장 단순한 아키텍처로 시작하고, 필요에 따라 의도적으로 발전시킨다.
• 가능한 곳에서는 통합한다. 모든 기능이 개별 마이크로서비스일 필요는 없다.
• 트레이드오프를 명시적으로 기록한다. 스케일을 위해 복잡성을 추가했다면, 그 운영 비용과 예상 장애 모드를 문서화한다.

지금과 가까운 미래의 물고기들을 건강하게 지탱할 만큼의 유리와 파이프, 칸막이만 있으면 된다. 아무도 길을 찾지 못하는 수중 도시를 만드는 것이 목표가 되어서는 안 된다.

7. 아키텍처 & 의존성 매핑: 진짜 물살을 보는 법

연필로 그린 인시던트 수족관의 핵심은 서비스, 자산, 설정 항목(Configuration Item) 과 이들 간의 연결 관계를 보여주는 시각적 지도다.

명확한 아키텍처와 의존성 매핑은 다음과 같은 질문에 답한다.

• 이 서비스에 직접·간접적으로 의존하는 것은 무엇인가?
• 이 데이터베이스의 속도가 50% 느려지면, 누가 가장 먼저 타격을 받는가?
• 어떤 설정 항목(플래그, 시크릿, 라우팅 규칙)이 크리티컬 경로를 좌우하는가?

수족관 안에서는 다음과 같이 표현된다.

• 각 물고기(서비스)는 오너, SLO, 중요도(criticality)가 라벨로 표시된다.
• 물고기들 사이의 실은 실제, 현재 기준 의존 관계를 나타내며, 3년 전 다이어그램에 있던 옛 관계를 보여주지 않는다.
• 색상이나 위치는 블라스트 레디우스(영향 범위), 데이터 민감도, 장애 도메인 등을 표현한다.

운영 관점에서는 다음이 필요하다.

• CI/CD와 관측 시스템에 통합된 살아 있는 서비스 카탈로그/CMDB
• 단순히 “뭐가 고장 났는지”를 넘어 “다음에 누가 영향을 받을지”까지 보여주는 토폴로지 인식(topology-aware) 알림과 대시보드
• 인시던트 도구가 영향 경로(impact path)를 몇 시간 아니라 몇 초 안에 보여줄 수 있어야 한다.

물살을 명확히 볼 수 있을 때, 전파와 격리를 논리적으로 사고할 수 있다. “이 물고기가 죽으면 저 세 마리는 아플 것이고, 나머지는 괜찮다”라고 자신 있게 말할 수 있다.

결론: 수족관을 계속 다시 그리기

연필로 그린 인시던트 수족관은 의도적으로 저해상도(low-fi)다. 그게 핵심이다.

신뢰성은 가장 화려한 툴이나 정교한 다이어그램의 문제가 아니다. 더 중요한 것은 다음과 같다.

• 스트레스 상황에서의 마찰을 줄이는 세심한 자동화
• 조직 도메인에 밀착된 살아 있는 지식 기반 시스템으로서의 신뢰성
• 리더십이 기술·시간·정렬(alignment)에 투자하도록 만드는 것
• 일상 업무 속에 신뢰성을 내장하고 나중에 덧붙이지 않는 것
• 물살이 거칠어질 때 모두가 어떻게 움직여야 할지 알게 해 주는 표준 작업
• 조급한 복잡성 도입을 경계해 시스템을 이해 가능한 상태로 유지하는 것
• 실제 물살이 어떻게 흐르는지 볼 수 있도록 명료한 아키텍처와 의존성 지도를 유지하는 것

만약 지금 여러분의 프로덕션 환경이 맑은 수족관이라기보다는, 어두운 혼돈의 심해처럼 느껴진다면, 작게 시작하면 된다.

• 종이와 펜으로 직접 의존성 지도를 한 번 그려 보라.
• 가장 중요한 물고기들과 그 물살을 라벨링하라.
• 인시던트 중 가장 고통스러운 작업 하나를 자동화하라.
• 표준 관행 한 가지를 공식화하라.

그리고 계속 다시 그려라.

시간이 지나면, 인시던트는 여전히 스트레스를 주겠지만 더 이상 미스터리는 아닐 것이다. 종이 물고기들이 숨겨진 물살을 보여 줄 것이고, 팀은 그 속을 자신 있게 헤엄쳐 나갈 수 있는 기술, 구조, 시스템을 갖추게 될 것이다.