아날로그 아키텍처 샌드박스: 쿠버네티스를 손대기 전에 종이 토큰으로 분산 시스템 모델링하기

팀이 모놀리식에서 마이크로서비스로 전환하거나, 처음으로 쿠버네티스 배포를 계획할 때, 대부분 곧장 YAML, Helm 차트, 클라우드 콘솔로 뛰어듭니다. 하지만 그 전에 분산 아키텍처를 탐색할 수 있는 더 단순하고, 저렴하며, 훨씬 인간적인 방법이 있습니다.

테이블 위에 종이 토큰으로 시스템을 만들어 보는 것입니다.

이 "아날로그 아키텍처 샌드박스"는 당신의 시스템을 하나의 물리적인 게임판으로 바꿔 줍니다. 서비스, 큐, 토픽, 사용자 등을 토큰으로 표현하고, 트래픽 급증, 장애, 부분 장애, 인시던트 대응 같은 현실적인 시나리오를 직접 손으로 플레이합니다.

그 결과, 인프라에 투자하기 이전에 시스템이 어떻게 동작하는지에 대한 시각적이고 공유된 이해를 얻을 수 있습니다.

왜 종이로 분산 시스템을 모델링할까?

분산 시스템이 어려운 이유는 다음과 같습니다.

• 동작이 직관적이지 않고, ** emergent**(복합적인 상호작용의 결과)하게 나타납니다.
• 장애가 이분법적(된다/안 된다)이 아니라, 부분적이고 지저분하게 발생합니다.
• 서비스 간, 그리고 사람 간 커뮤니케이션 경로가 복잡합니다.

다이어그램 툴과 아키텍처 문서는 도움이 되지만, 결국 정적입니다. 테이블탑(테이블 위에서 하는) 연습은 동적이고 협업적입니다.

• 저비용, 고학습 효과 – 과감한 아이디어를 시도해 보고, 몇 분 만에 버릴 수 있습니다.
• 공유된 멘탈 모델 – 엔지니어, SRE, PM, 심지어 비기술 직군까지 모두 시스템 동작을 한눈에 볼 수 있습니다.
• 안전한 실패 실험실 – 포스트잇만 충분하다면, 시스템을 마음껏 "부숴"도 아무 위험이 없습니다.
• 쿠버네티스 도입 전 sanity check – 진짜로 복잡한 인프라가 필요한지, 필요하다면 어떤 종류의 것이 필요한지 검증할 수 있습니다.

코드 대신 종이를 사용하는 아키텍처 단위 테스트라고 생각하면 됩니다.

핵심 아이디어: 논리 패턴을 물리 토큰으로 표현하기

먼저 흔한 분산 시스템 패턴을 물리적인 오브젝트에 매핑합니다.

• 클라이언트 / 사용자 → 막대 그림(스틱 피겨) 혹은 색깔 토큰
• 서비스 / 컴포넌트 → 포스트잇 또는 인덱스 카드(카드 하나당 컴포넌트 하나)
• 데이터베이스 / 데이터 스토어 → 더 큰 카드 또는 색이 다른 포스트잇
• 큐(Queue) (예: SQS, RabbitMQ) → 화살표와 작은 "inbox" 영역이 있는 직사각형 카드
• 토픽 / Pub-Sub (예: Kafka) → 여러 Consumer로 향하는 화살표가 있는 원형 또는 중앙 카드
• 요청 / 메시지 → 실제로 움직이는 작은 종이 쪽지나 동전
• 외부 의존성 (결제 게이트웨이, 서드파티 API 등) → 테이블 가장자리에 위치한 카드

픽셀 단위로 정확하게 그리는 것이 목표가 아닙니다. 목표는 패턴을 눈에 보이게 만드는 것입니다.

• 이 호출은 동기(synchronous)인가, 비동기(asynchronous)인가?
• 누가 누구와 통신하는가?
• 완전히 다운된 경우뿐 아니라, 느려졌을 때는 어떻게 되는가?

1단계: 테이블 위에 모놀리스를 먼저 올려라

목표가 마이크로서비스와 쿠버네티스라고 하더라도, 먼저 현재 혹은 가능한 한 가장 단순한 아키텍처부터 시작해야 합니다. 많은 팀에게 그것은 모놀리식 애플리케이션이나 기본적인 클라이언트–서버 구조일 것입니다.

1. 모놀리스를 그린다

   • 가운데에 App이라고 적힌 큰 포스트잇을 하나 둡니다.
   • 그 근처에 DB 카드 하나를 둡니다.
   • 테이블 가장자리에 여러 개의 User 토큰을 놓습니다.

2. 기본 요청 플로우를 시뮬레이션한다

   • 한 User로부터 Request 토큰을 집어 App으로 옮깁니다.
   • App에서 DB로, 다시 App으로, 그리고 다시 User로 토큰을 옮깁니다.
   • 진행하면서 말로 설명합니다: "사용자가 로그인 요청을 보내고, 앱이 DB를 조회한 뒤 결과를 돌려준다."

3. 성능과 한계를 적어 둔다

   • 작은 메모를 붙입니다: App: ~500 RPS, DB: ~200 writes/sec 등.
   • 캐시가 있다면 어디에 있는지 표시합니다.

이제 방 안에 있는 모두가 현재 시스템의 베이스라인을 이해할 수 있어야 합니다.

2단계: 컴포넌트를 점진적으로 "쪼개" 마이크로서비스로 만들기

모놀리스 구조가 명확해졌다면, 이제 마이크로서비스 후보들을 탐색해 봅니다.

1. 자연스러운 경계 찾기

   • 팀, 비즈니스 도메인, 스케일링 특성이 뚜렷이 다른 영역을 찾습니다.
     • 예: Auth, Payments, Catalog, Notifications 등

2. 모놀리스를 물리적으로 분리하기

   • App 카드의 일부를 떼어내어 Auth Service, Orders Service, Inventory Service 같은 개별 서비스 카드로 교체합니다.
   • 플로우를 다시 그립니다. User → Gateway → 특정 서비스로 Request 토큰이 이동하도록 만듭니다.

3. 서비스 간 상호작용 스타일을 선택하기

   • 동기 호출의 경우: 서비스 카드 사이에 직접 화살표를 그립니다.
   • 비동기 패턴의 경우: Queue나 Topic 카드를 추가하고, Message 토큰이 그 사이를 지나가게 합니다.

4. 실시간으로 설계 질문을 던진다

   • 이건 동기 HTTP 호출이어야 할까, 아니면 토픽에 발행하는 이벤트여야 할까?
   • Inventory Service가 다운되면, Orders Service는 빨리 실패(fail fast)해야 할까, 재시도할까, 아니면 요청을 큐에 쌓아둘까?
   • 어떤 데이터는 복제해서 쓰고, 어떤 데이터는 각 서비스가 직접 소유해야 할까?

카드들을 물리적으로 재배치하고 쪼개는 과정은, 코드나 쿠버네티스 매니페스트를 손대지 않고 아키텍처 리팩토링을 하는 것과 같습니다.

3단계: 팀이 함께 현실적인 시나리오를 플레이하기

이제부터가 아날로그 샌드박스의 진짜 힘이 드러나는 구간입니다. 이 셋업을 하나의 테이블탑 인시던트 대응(tabletop incident-response) 연습처럼 다루세요.

시나리오 A: 트래픽 급증

1. User 토큰을 두 배, 세 배로 늘립니다.
2. Request 토큰을 시스템 전체에 빠르게 흘려보냅니다.
3. 어디에 토큰이 쌓이는지 지켜봅니다.
   • Gateway에 몰리나요? DB에 몰리나요? 특정 Queue에 쌓이나요?
4. 각 지점에 다음과 같은 조치를 어디에 적용할지 메모합니다.
   • 오토스케일링 (Pods, HPA)
   • 캐싱 (CDN, 인메모리 캐시)
   • Rate limiting 또는 백프레셔(Backpressure)

시나리오 B: 부분 장애

1. 서비스 카드 하나(예: Payments Service)를 골라 뒤집고 "DOWN"이라고 표시합니다.
2. 실제 사용자들이 여전히 시스템을 사용하고 있다고 가정하고 Request 토큰을 계속 움직입니다.
3. 팀으로서 함께 다음에 답해 봅니다.
   • 무엇이 degrade(성능 또는 기능 저하)되고, 무엇은 그대로 동작하나요?
   • UI는 제한된 기능만 제공할까요, 아니면 아예 강한 에러를 보여 줄까요?
   • 실패한 요청은 어떻게 되나요? 유실되나요, 나중에 재시도되나요, 큐에 쌓이나요?

시나리오 C: 느려진 의존성

1. External API 카드에 "+2 seconds latency"라고 적습니다.
2. 해당 API를 호출하는 요청마다, 토큰을 다음 단계로 옮기기 전에 실제로 몇 초간 멈춰 있습니다.
3. 관찰 포인트:
   • 호출하는 서비스에 요청이 백업(밀림)되나요?
   • 이 느려짐이 모든 플로우를 늦추나요, 아니면 일부 플로우에만 영향을 주나요?
   • Circuit breaker나 timeout은 어디에 두는 게 좋을까요?

이런 시나리오를 통해 평소에는 눈에 보이지 않던 동작이 구체적으로 드러납니다. 큐가 쌓이고, 병목이 생기고, 장애가 연쇄적으로 번지는 모습을 모두가 함께 확인할 수 있습니다.

4단계: 역할, 책임, 커뮤니케이션에 집중하기

세션이 순수하게 기술 논의로만 흐르지 않도록 하세요. 실제 인시던트 대응 tabletop이라고 생각하고 진행합니다.

1. 보드 위에 사람(조직)을 추가한다

   • Backend Team, SRE, On‑Call, Product Owner 같은 팀이나 역할을 토큰으로 표현합니다.
   • 각 팀 토큰에서 이들이 책임지는 서비스 카드로 선이나 화살표를 그립니다.

2. 조직적인 질문을 던진다

   • Payments Service가 다운되면, 누구에게 페이저가 울리나요?
   • 기능을 degrade할지, 전체 플로우를 막을지 누가 결정하나요?
   • 긴급 상황에서 설정을 바꿀 권한은 누구에게 있나요?

3. 인시던트 커뮤니케이션을 시뮬레이션한다

   • 장애 상황을 플레이하다가 중간중간 멈추고 질문합니다.
     • 고객에게는 누가 대응하나요?
     • 팀 간 조율은 누가 맡나요?
     • 런북(runbook)은 어디에 있고, 누가 어떻게 찾나요?

이 과정은 기술적인 단일 장애 지점뿐 아니라, 소유권과 커뮤니케이션의 공백까지 드러내는 데 큰 도움이 됩니다.

5단계: 병목과 단일 장애 지점을 표면 위로 끌어올리기

시스템 패턴이 드러나기 시작하면, 보드 위에 위험 요소를 주석처럼 표시합니다.

• 병목(Bottlenecks)

  • 부하가 걸렸을 때 토큰이 유난히 많이 쌓이는 컴포넌트
  • 모든 요청이 경유하는 서비스(예: Gateway, DB)

• 단일 장애 지점(Single Point of Failure)

  • 이중화나 우회 경로가 전혀 없는 카드
  • 그레이스풀 디그레이데이션(graceful degradation) 전략이 없는 중요 외부 의존성

• 모호한 소유권

  • 어떤 팀 토큰과도 연결되지 않은 서비스
  • 계약(스키마, API 계약 등)이 명확하지 않은 채 여러 서비스가 공유해서 쓰는 데이터베이스

이 발견 사항을 리스트로 정리합니다.

• "Orders Service가 Inventory와 Pricing에 동기적으로 의존 — 연쇄 장애(cascading failure) 위험."
• "모든 서비스가 단일 write-heavy DB를 사용 — 스케일링 및 락/경합(contension) 위험."
• "Notification Service의 명확한 오너가 없음 — 인시던트 시 대응 경로 불명확."

이 위험 리스트는 이후 실제 쿠버네티스 및 인프라 설계를 위한 핵심 인풋이 됩니다.

6단계: 나중에 더 좋은 다이어그램을 위해 C4 모델과 정렬시키기

인사이트가 포스트잇 위에서만 끝나지 않도록, 지금 만든 구성을 C4 모델 같은 더 형식적인 다이어그램 방식에 매핑합니다.

• 레벨 1 (System Context)

  • 테이블 전체를 하나의 시스템으로 보고, 외부 사용자와 외부 의존성을 함께 표현합니다.

• 레벨 2 (Containers)

  • 각 카드(서비스, DB, 큐 등)를 C4에서 말하는 컨테이너(배포 단위 컴포넌트)로 봅니다.

• 레벨 3 (Components)

  • 하나의 서비스 카드를 API, Worker 등 서브 카드로 쪼개 두었다면, 이것들을 C4의 컴포넌트로 매핑합니다.

세션이 끝나면:

1. 테이블을 여러 각도에서 사진으로 찍어 둡니다.
2. 선호하는 툴을 사용해 이 레이아웃을 C4 다이어그램으로 옮깁니다.
3. 신뢰 경계(trust boundary), 프로토콜(HTTP, gRPC, 이벤트), 배포 환경 등을 주석으로 추가합니다.

이제 아날로그 샌드박스에서 얻은 결과물이, 개발자와 플랫폼 엔지니어가 실제로 구현 가능한 아키텍처 다이어그램과 실행 계획으로 직접 연결됩니다.

언제 아날로그 아키텍처 샌드박스를 실행할까?

다음과 같은 상황에서 이 기법을 활용해 볼 수 있습니다.

• 모놀리식 → 마이크로서비스 마이그레이션을 검토할 때
• 첫 번째 쿠버네티스 또는 서비스 메시 롤아웃을 계획할 때
• 분산 컴포넌트가 포함된 신규 제품을 설계할 때
• 아픈 인시던트를 겪었고, 시스템 전반의 동작을 다시 이해하고 싶을 때

세션은 짧고 집중적으로 진행해도 충분합니다.

• 하나의 시나리오와 아키텍처 슬라이스에는 60–90분 정도
• 복잡한 환경이라면 반나절 워크숍

참여자는 가능하면 크로스 펑셔널하게 구성합니다. 엔지니어, SRE, 아키텍트, PM, 필요하다면 고객 지원이나 운영 담당도 포함하세요.

결론: YAML로 설계하기 전에 종이로 먼저 설계하라

쿠버네티스, 서비스 메시, 클라우드 네이티브 툴링은 강력하지만, 동시에 복잡성을 고착시키고 초기 설계 실수를 증폭시킬 수 있습니다.

간단한 종이 토큰 테이블탑 연습을 통해 다음을 할 수 있습니다.

• 분산 시스템 패턴을 눈앞에 시각화하고, 날카롭게 질문을 던질 수 있습니다.
• 마이크로서비스 경계를 안전하게 탐색해 볼 수 있습니다.
• 인시던트 대응 및 커뮤니케이션 플로우를 연습할 수 있습니다.
• 병목, 소유권 공백, 단일 장애 지점을 드러낼 수 있습니다.
• C4 같은 구조화된 다이어그램, 그리고 궁극적으로는 깔끔한 쿠버네티스 매니페스트로 자연스럽게 이어질 수 있습니다.

클러스터를 먼저 올리거나 첫 번째 Helm 차트를 쓰기 전에, 우선 테이블을 하나 확보하고, 포스트잇과 펜을 꺼낸 뒤, 모두가 볼 수 있는 곳에 당신의 아키텍처를 지어 보세요. 시스템을 부수고, 고치고, 다시 설계해 볼 수 있는 가장 싸고 빠른 장소는 여전히 종이 위입니다.