골판지 실패 도시: 시스템 속 숨겨진 위험 동네를 탁상 위에 펼쳐보기

현대 시스템은 인간의 머리로는 한눈에 담기엔 너무 거대합니다.

클라우드 네이티브 아키텍처는 수십, 수백 개의 마이크로서비스, 서드파티 API, 큐, 데이터 스토어, 백그라운드 잡으로 끝없이 뻗어 나갑니다. 실제 의존성 그래프는 깔끔한 다이어그램과는 거리가 멀고, 마치 누군가 바닥에 쏟아 버린 스파게티 한 그릇처럼 보입니다.

서비스 맵, 트레이싱 도구, 의존성 그래프를 갖추고 있어도, 새벽 3시에 장애가 터지면 여전히 “아무도 제대로 모르는 동네”들이 튀어나옵니다. 그곳이 바로 당신 시스템의 **숨겨진 위험 동네(neighborhoods of risk)**입니다.

그 동네들을 실제로 걸어서 지나가 볼 수 있다면 어떨까요?

여기서 등장하는 것이 바로 **골판지 실패 도시(Cardboard Failure City)**입니다. 추상적인 의존성을, 눈으로 보고 손으로 가리키고 직접 움직일 수 있는 물리적인 탁상용 도시 모형으로 바꿔 주는 방법입니다.

왜 ‘도시’인가? 왜 ‘골판지’인가?

의존성 다이어그램과 아키텍처 차트에는 결정적인 문제가 하나 있습니다. 인간의 인지 한계에 맞게 스케일되지 않는다는 점입니다.

• 서비스가 몇 개 안 될 땐? 그래프만으로도 충분합니다.
• 수십 개로 늘어나면? 이미 복잡하게 느껴지기 시작합니다.
• 수백 개가 되면? 시각화 자체가 사실상 읽을 수 없는 수준이 됩니다.

인터랙티브 도구를 써도, 확대·축소·이동을 반복하다 보면 소수의 전문가만이 그 그림을 해석할 수 있게 됩니다.

도시 메타포는 여기에 구조와 공간적 의미를 부여함으로써 문제를 해결합니다.

• 서비스는 건물이 됩니다. (높은 건물, 넓은 건물, 구역별로 묶인 건물들)
• 의존성은 도로가 됩니다. (일방통행, 고속도로, 좁은 골목길)
• 공유 인프라는 공공 설비가 됩니다. (발전소, 정수장, 지하철 노선 등)

그리고 골판지가 중요한 이유는:

• 물리적이기 때문입니다 – 모두가 한 자리에 모여 둘러볼 수 있습니다.
• 싸기 때문입니다 – 마음껏 뜯어 고치고 옮겨도 아무도 부담을 느끼지 않습니다.
• 창의적이기 때문입니다 – “손대기 무서운 정식 다이어그램”이 아니라, 실험을 부르는 프로토타입 놀이터가 됩니다.

종이비행기를 접어 공기역학을 시험해 보듯, 골판지 도시를 만드는 일은 시스템 아키텍처와 실패 양식을 저위험·저비용으로 실험해 보는 방법입니다.

1단계: 시스템을 도시로 매핑하기

처음부터 완벽하게 만들 필요는 없습니다. 모든 구현 세부사항을 복제하려는 게 아니라, 위험과 결합(coupling)을 눈에 보이게 만드는 게 목적입니다.

1. 건물 단위 정하기

손에 있는 어떤 것도 좋습니다.

• 작은 골판지 상자
• 접은 인덱스 카드나 포스트잇
• 3D 프린팅한 블록

각 건물은 하나의 서비스나 핵심 컴포넌트를 나타냅니다.

• 마이크로서비스
• 데이터베이스
• 메시지 큐
• 서드파티 API (도시 가장자리의 “외곽 건물”처럼 배치)

각 건물에는 서비스 이름을 명확하게 라벨링합니다.

2. 구역(디스트릭트) 배치하기

연관된 서비스들을 **구역(district)**으로 묶습니다.

• “결제 구역” – 빌링, 인보이싱, 트랜잭션 프로세서
• “사용자 구역” – 인증, 프로필, 권한
• “콘텐츠 구역” – 카탈로그, 검색, 추천 엔진

이 구역들이 나중에 **위험 동네(neighborhoods of risk)**로 드러나게 됩니다.

3. 도로(의존성) 추가하기

실이나 테이프, 마커, 털실 등을 이용해 의존성을 표현합니다.

• 테이블 위에 선이나 화살표를 그려 누가 누구를 호출하는지 표시합니다.
• 굵은 선은 트래픽이 많거나, 중요도가 높은 크리티컬 패스를 의미하게 합니다.
• 큐 기반 통신처럼 비동기 의존성은 다른 색으로 구분합니다.

이제 기본적인 물리 의존성 맵이 만들어졌습니다. 하지만 진짜 가치는 이걸 실제 도시처럼 걸어 다니며 바라볼 때 드러납니다.

2단계: 숨겨진 위험 동네 드러내기

모든 구역이 똑같이 위험한 것은 아닙니다. 어떤 곳은 조용한 교외 같고, 어떤 곳은 장애가 한번 나면 순식간에 번지는 불안정한 동네입니다.

변경 결합(Change Coupling)으로 위험한 구역 찾기

**변경 결합(change coupling)**은 어떤 서비스들이 함께 자주 변경되는지를 보는 관점입니다. 대개 이런 서비스들이 여기에 해당합니다.

• 같은 팀이 주로 다루는 서비스
• 데이터 모델·스키마를 공유하는 서비스
• 동작이 촘촘히 엮여 있는 서비스

이를 도시 모형에 반영해 봅니다.

1. 최근 몇 달간의 배포 이력을 살펴봅니다.
2. 같은 PR, 스토리, 릴리스 노트에 자주 함께 등장하는 서비스들을 찾습니다.
3. 이 건물들을 골판지 도시에서 서로 더 가깝게 모아서 배치합니다.

그러면 시각적으로 이런 동네들이 보이기 시작합니다.

• 하나의 공유 데이터베이스 주변에 모여 항상 같이 배포되는 작은 서비스들의 클러스터
• 공사 중인 빌딩처럼, 항상 뭔가 공사가 진행되는 “백엔드 블록”

이런 곳이 바로 **불안정한 동네(unstable neighborhoods)**입니다. 이런 곳에는 다음과 같은 대책이 더 필요합니다.

• 서킷 브레이커, 재시도, 그레이스풀 디그레이션 같은 추가적인 회복 탄력성 패턴
• 더 정교한 테스트 전략
• 카나리 배포, 피처 플래그 같은 더 엄격한 롤아웃 전략

핫스팟 표시하기

색깔이나 심볼로 위험을 표시합니다.

• 빨간 스티커 – 인시던트가 잦은 서비스
• 노란색 – 트래픽이 많거나 비즈니스 크리티컬한 서비스
• 파란색 – 통제권 밖의 외부 의존성

이렇게 하면 눈으로 바로 다음과 같은 것들이 보이기 시작합니다.

• 위험 회랑(risk corridor) – 중요한 크리티컬 패스를 따라 빨간·노란 건물들이 줄줄이 이어진 구간
• 단일 장애 지점(SPOF) – 거의 모든 주요 도로가 지나가는 외로운 한 건물

이제 누구나 한눈에 이해할 수 있는 **위험 지도(risk map)**를 갖게 된 셈입니다.

3단계: 인시던트 대응 테이블탑 연습으로 확장하기

이제 이 도시를 재난 시뮬레이션 보드로 바꿔 봅니다.

도시 이벤트로 장애 시나리오 만들기

“payments-service가 다운됐다”라고 말하는 대신, 이렇게 말해 봅니다.

• “결제 구역 전체에 정전이 났습니다.”
• “Auth와 Checkout을 잇는 메인 도로가 공사로 막혔습니다.”
• “외부 지도 공급자가 도시에서 철수해, 그쪽으로 나 있던 도로가 전부 사라졌습니다.”

각 시나리오마다 다음을 수행합니다.

1. 실제로 장애를 표시합니다 – 건물 위에 “Down” 카드(또는 ‘장애’ 카드)를 올려두거나, 도로를 끊는다며 끈을 잘라내고, 아예 구역 전체를 “재난” 카드로 덮습니다.
2. 팀에 묻습니다. “이제 무엇이 함께 망가질까?” 어떤 길이 더 이상 통행 불가능해졌는지, 어떤 건물이 접근 불가인지, 어떤 고객 여정이 막히는지를 함께 따져봅니다.
3. 도로를 따라가며 장애가 어떻게 전파되는지 추적합니다.

“이 서비스가 뭘 하는지”만 묻는 게 아니라, **“이 블록에 불이 나면 이 동네 전체에 무슨 일이 벌어지지?”**를 묻는 셈입니다.

팀 단위로 대응 연습하기

실제 인시던트처럼 연습을 진행합니다.

• 역할을 나눕니다. 인시던트 커맨더, 커뮤니케이션 담당, 각 도메인 SME 등.
• 시나리오를 설정합니다. 예: “10시 07분, 결제 구역 전체가 암흑에 빠졌습니다.”
• 팀에게 다음을 요구합니다.
  • 어떤 플로우와 고객이 영향받는지 식별하기
  • 우회·피처 플래그·폴백 같은 완화 전략 결정하기
  • 누가, 얼마나 빨리, 어떤 내용으로 커뮤니케이션을 받아야 하는지 논의하기

모델이 물리적이고 모두가 공유하는 대상이기 때문에, 지원(고객센터), 프로덕트, 리더십 등 비전문가도 이야기 흐름을 따라가며, 왜 어떤 대응은 시간이 걸리는지 쉽게 이해할 수 있습니다.

4단계: 안전한 프로토타이핑 공간으로 활용하기

골판지 도시는 일부러 **저해상도(low fidelity)**로 만드는 것입니다. 그게 장점입니다.

종이 비행기를 풍동에 넣듯, 이 모형은 취약한 구조를 안전하게 탐색하는 샌드박스입니다.

이 모형을 두고 이런 질문들을 던져 봅니다.

• “이 건물을 아예 없애면 어떨까?”
  그래도 동작하는 플로우가 있을까? 무엇을 바꿔야 할까?
• “이 거대한 모놀리식 건물을 세 개로 쪼개면 어떨까?”
  새 도로가 얼마나 많이 생기나? 동네는 더 단단해질까, 더 깨지기 쉬워질까?
• “이 외부 공급자가 매달 한 번씩은 장애를 낸다면?”
  우회가 가능한가? 다른 공급자로 향하는 ‘백업 도로’를 뚫어야 할까?

구성원들에게 이렇게 제안해 보세요.

• 원하는 미래 아키텍처를 반영해 구역을 다시 배치해 보기
• 새로운 도로(의존성)를 제안하고, 그것이 만드는 위험을 함께 논의하기
• 캐시, 로컬 폴백, 대체 경로 같은 회복 탄력성 패턴을 새로운 도로·골목길로 표현하며 실험해 보기

골판지일 뿐이기 때문에 틀려도 전혀 두렵지 않습니다. 목표는 정밀함이 아니라 학습입니다.

5단계: 팀 스포츠로 만들기

골판지 실패 도시의 가장 큰 가치는 모형 자체가 아니라, 그 모형을 둘러싸고 생기는 대화입니다.

‘맡기지 말고, 함께 만들기’

아키텍처 팀이나 SRE 팀에게만 맡겨 혼자 만들게 두지 마세요. 대신:

• 여러 팀의 엔지니어를 함께 참여시키고,
• 가능하다면 프로덕트 매니저, 디자이너, 고객지원도 포함시키며,
• 각 팀에게 “자기” 건물을 직접 배치하고, 연결 관계를 설명하게 합니다.

이 과정에서 다음과 같은 일들이 자연스럽게 드러납니다.

• 숨은 가정이 폭로됩니다.
  (“잠깐, 우리 읽기 전용 레플리카에만 의존하는 줄 알았는데?”)
• 지식 사일로가 보입니다.
  (“저 건물이 정확히 뭘 하는지는 저 사람만 알아요.”)
• 조직 전체의 공유 멘탈 모델이 좋아집니다.

살아있는 도시로 유지하기

이 도시는 일회성 워크숍 소품이 아니라, 살아있는 모델이어야 합니다.

• 분기별 아키텍처 리뷰처럼 정기적으로 업데이트합니다.
• 새 서비스가 생기면 새 건물을 추가합니다.
• 큰 변경이 있을 때마다 새로운 장애 시나리오를 만들어 돌려 봅니다.

시간이 지날수록 팀 안에는 자연스럽게 지리 기반 공용 언어가 생깁니다.

• “Checkout 구역에 새 서비스를 하나 배포할 예정이에요.”
• “이번 변경으로 Auth 메인 도로를 우회하는 골목 하나가 생깁니다.”
• “저기는 이미 취약한 동네라, 발걸음을 조심해야 해요.”

이런 언어를 쓰면, 수십 개 대시보드와 탭을 열지 않고도 위험에 대해 이야기하기가 훨씬 쉬워집니다.

결론: 시스템을 다이어그램이 아닌 ‘도시’로 보기

대규모 시스템의 실패는 단순히 기술적인 문제가 아니라, 공간적이고 관계적인 현상으로 나타납니다. 장애는 구역과 대로를 따라 불길이 번지듯 퍼지지, 깔끔한 의존성 차트 선을 따라 움직이지 않습니다.

골판지 실패 도시를 만들면 다음과 같은 효과를 얻습니다.

• 눈에 보이지 않던 결합을 도로와 블록으로 시각화할 수 있습니다.
• **변경 결합(change coupling)**으로 불안정한 동네를 찾아낼 수 있습니다.
• 인시던트 대응 테이블탑 연습을 실제 지도를 기반으로 진행할 수 있습니다.
• 실패와 회복 탄력성을 탐색하는 저비용 프로토타이핑 랩을 갖게 됩니다.
• 팀 간 공유 이해와 커뮤니케이션을 강화할 수 있습니다.

완벽한 정밀도가 필요하지는 않습니다. 사람들끼리 둘러서서 손가락으로 가리키며 **“여기서 불이 나면, 어디까지 번질까?”**를 함께 상상할 수 있을 만큼만 정확하면 됩니다.

한번 팀이 함께 이 도시의 큰길과 골목을 걸어보고 나면, 아키텍처를 바라보는 시선은 완전히 달라질 것입니다. 그리고 다음 인시던트가 닥쳤을 때, 아무 지도 없이 낯선 어둠 속 도시를 헤매는 기분은 분명 훨씬 줄어들 것입니다.