실제 생활에서의 System Design: 고대 박물관이 실제로 Microservices인 이유?

Source: Dev.to

Introduction

저는 백엔드 개발자(Java/Spring)이며 동시에 박물관학을 전공하는 대학생입니다. 현대 박물관의 물리적 보안 레이어를 살펴보던 중, 현대 클라우드 소프트웨어의 아키텍처와 놀라울 정도로 유사한 점을 발견했습니다. 이 관찰을 바탕으로 시스템 설계 개념을 설명하기 위해 박물관 레이아웃을 역공학해 보았습니다.

The Architecture Breakdown

The Old Way (Monolith)

• 고대 사원은 하나의 거대한 구조물이었다.
• 한 방에 화재가 발생하면 전체 건물(시스템)이 무너질 수 있었다.

The New Way (Microservices)

• 현대 박물관은 별개의 전시관(예: 이집트 전시관, 르네상스 전시관)으로 구성된다.
• 한 전시관에서 보안이 뚫리더라도 다른 전시관은 스스로 차단하여 전체 시스템이 계속 운영될 수 있다.

Entry Point – API Gateway Analogy

1. 회전식 턱/티켓 부스 – 신원을 확인한다.
2. 티켓(토큰) 검사 – 접근 권한을 검증한다.
3. 입구로 라우팅 – 방문자를 적절한 구역으로 안내한다.

이는 트래픽을 관리하고 하위 서비스에 도달하기 전에 처리하는 API Gateway와 동일한 원리이다.

Data Protection – Vault Analogy

• 가장 귀중한 아이템은 전시되지 않은 지하 금고에 보관된다.
• **방문객(사용자)**은 금고에 직접 접근할 수 없다.
• **큐레이터(백엔드 서비스)**만이 금고에 접근할 수 있는 권한을 가진다.

이는 데이터베이스가 사용자로부터 직접 접근이 차단되는 방식을 반영한다.

Takeaway

물리적 시스템을 바라보면 추상적인 코드 개념을 명확히 이해할 수 있다. 2천 년 된 사원이든 Spring Boot 애플리케이션이든, 근본적인 보안 논리—깊이 있는 방어—는 변하지 않는다.

이 비유에 대한 의견을 공유하거나 코딩 패턴과 닮은 다른 실생활 시스템을 제안해 주세요.