아날로그 아키텍처 캐비닛: 살아 있는 시스템 다이어그램을 위한 물리적 파일링 시스템 만들기

디지털 도구가 아키텍처 문서화를 장악하고 있지만, 아날로그 방식에는 의외로 강력한 힘이 있습니다. 시스템 다이어그램만을 위한 잘 설계된 아키텍처 캐비닛(physical filing cabinet)은 사고 도구이자 협업 허브, 그리고 시스템이 어떻게 진화해 왔는지를 보여주는 살아 있는 기록이 될 수 있습니다.

이건 종이에 대한 향수가 아닙니다. **물리적 제약과 물리적 특성(affordance)**을 활용해 더 나은 아키텍처 사고를 설계하는 데 관한 이야기입니다. 제대로 만들면, 캐비닛은 구조화되고, 탐색 가능하며, 진화 가능한, 당신의 문서화 전략을 눈에 보이는 형태로 구현한 것이 됩니다.

이 글에서는 시간이 지나며 변화하는 시스템 다이어그램을 위한 물리적 파일링 시스템을 어떻게 설계할지 살펴봅니다. 이 시스템은 다음을 목표로 합니다.

아키텍처를 구조이자 스토리로 다루기
실제 시스템 구성(하드웨어, 소프트웨어, 상호작용)을 반영하기
진화와 버저닝을 혼란 없이 다루기
현대 문서화 도구(태깅, 인덱싱, 내비게이션)의 패턴을 차용하기
아키텍처 문서화 모범 사례와 정렬되기
협업과 공유 이해를 지원하기

1. 구조이자 스토리로서의 아키텍처

대부분의 아키텍처 다이어그램은 구조에 집중합니다. 컴포넌트, 관계, 경계 같은 것들입니다. 하지만 실제 시스템은 동시에 스토리이기도 합니다. 어떻게 만들어졌는지, 어떻게 변해 왔는지, 그리고 외부 세계와 어떻게 상호작용하는지가 스토리를 이룹니다.

캐비닛을 설계할 때 이 둘을 모두 존중하도록 만드십시오.

구조: 정적인 뷰들

우리가 익숙한 다이어그램들입니다.

컴포넌트와 커넥터
데이터 흐름
배포 토폴로지
인터페이스와 프로토콜

캐비닛은 특정 시점에 시스템이 어떻게 맞물려 있는지 쉽게 볼 수 있게 해주어야 합니다.

스토리: 진화와 컨텍스트

디지털 도구에서는 종종 사라져 버리는 부분입니다.

왜 경계가 이렇게 그어졌는지
이전 버전은 어떻게 생겼는지
규제, 고객, 사고(incident) 같은 외부 제약이 설계를 어떻게 바꾸었는지

이 스토리를 파일링 설계에 녹여 넣으십시오.

내러티브 시트: 핵심 다이어그램마다 1페이지짜리 스토리를 붙입니다. 목적, 제약사항, 핵심 결정들을 적어 둡니다.
타임라인 폴더: 주요 서브시스템마다, 어떻게 진화했는지를 보여주는 다이어그램들을 시간 순서대로 보관하는 폴더를 둡니다.
컨텍스트 디바이더: 다이어그램을 서브시스템뿐 아니라 때로는 시대/시기별로 구분합니다. (예: "클라우드 이전", "V2 리팩터 이후")

캐비닛을 통해 시스템의 히스토리를 문자 그대로 손으로 넘겨가며 살펴볼 수 있어야 합니다.

2. 실제 할당 구조를 반영하기: 하드웨어, 소프트웨어, 상호작용

캐비닛의 구조가 실제 시스템의 아키텍처 구조를 닮을수록 훨씬 유용해집니다. 책임이 어떻게 할당되는지 생각해 보십시오.

하드웨어(서버, 디바이스, 네트워크)
소프트웨어(서비스, 모듈, 라이브러리)
상호작용(사용자 플로우, 외부 연동, 비즈니스 프로세스)

이 세 가지를 서랍의 최상위 조직 원칙으로 삼습니다.

예시 레이아웃

서랍 1: 하드웨어 & 인프라

네트워크 & 존(zones)
데이터센터 / 리전(regions)
엣지 디바이스와 게이트웨이

서랍 2: 소프트웨어 & 서비스

코어 서비스
서포팅 서비스
공용 플랫폼/컴포넌트

서랍 3: 상호작용 & 플로우

사용자 여정(User Journey)
외부 시스템 연동
비즈니스 프로세스 다이어그램

각 서랍 안에서는 폴더와 서브폴더를 사용해 아키텍처 뷰와 매핑합니다.

서브시스템 기준 (예: Payments, Identity, Search)
환경 기준 (예: Production, Staging, Local Dev)

"프로덕션 네트워크 레이아웃 다이어그램이 어디 있나요?"라는 질문에 대해, 파일링 논리가 자연스럽게 답을 알려 줄 수 있어야 합니다.

3. 진화를 위한 설계: 버전, 공간, 상호 참조

진화를 보여주지 않는 아키텍처는 곧 잘못된 인상을 줍니다. 아날로그 캐비닛은 처음부터 버전을 의식한 설계여야 합니다.

성장 여유 공간 확보하기

폴더를 과하게 채우지 마십시오. 어떤 영역은 다른 영역보다 더 자주 바뀐다는 가정을 두어야 합니다.

앞으로 생길 게 뻔한 서브시스템에 대해서는, 라벨만 붙여 둔 빈 폴더를 미리 만들어 둡니다.
변화가 빠른 영역은, 주요 이터레이션마다 얇은 폴더를 하나씩 둡니다. (예: Payments v1, Payments v2, Payments v3 ...)

필요로 하는 물리적 공간은 복잡성이 어디에서 커지고 있는지를 보여주는 초기 신호가 됩니다.

버저닝 실무

각 다이어그램을 코드 아티팩트처럼 다루십시오.

버전 스탬프를 찍습니다: Service X – Logical View – v3 – 2025-05-12 – Author: A.B.
폐기된(이전) 다이어그램은 같은 폴더에서 최신 버전 뒤에 보관하고, 절대 버리지 않습니다. 단지 "vX로 교체됨(replaced by vX)"이라고 명시만 합니다.
대규모 리디자인이 있는 경우에는 새 폴더를 만듭니다. (예: Legacy Payments (pre-2025) vs Payments Platform (post-2025))

상호 참조 카드

인덱스 카드나 반절 크기 종이를 사용해 크로스 레퍼런스 카드를 만듭니다.

"이 다이어그램의 최신 버전은: 서랍 2 / Software / Payments / v4에 있음"
"배포 상세는 여기 참고: 서랍 1 / Infra / Region EU / Node Layout"

이 카드는 변화하는 다이어그램들 사이의 탐색 가능성을 유지하면서도, 오래된 것들을 잃지 않게 해 줍니다.

4. 현대 문서화 도구에서 차용하기

캐비닛을 좋은 문서화 시스템의 물리 버전이라고 생각해 보십시오. 디지털에서 쓰이는 많은 패턴은 종이로도 놀랍도록 잘 옮겨집니다.

태깅(물리 메타데이터)

다이어그램 용지와 폴더 탭에 컬러 스티커나 작은 라벨 코드를 사용합니다.

파란 점 = 보안(Security) 관련
초록 줄무늬 = 고객이 직접 마주하는 컴포넌트
빨간 별 = 고위험 또는 크리티컬 경로

또는 용지 오른쪽 상단에 짧은 태그 코드를 적을 수도 있습니다: SEC, PERF, PRIV, OPS.

인덱싱과 목차

각 서랍 맨 앞에는 서랍 인덱스 시트를 둡니다.

폴더 전체 목록과 순서를 적고
각 폴더가 무엇을 담고 있는지 짧게 설명하며
중요한 폴더의 경우 마지막 업데이트 날짜나 버전 정보를 표기합니다.

캐비닛 맨 앞에는 마스터 목차를 둡니다.

서랍 목록
섹션 구조
핵심 다이어그램과 그 위치

이것이 아날로그 버전의 랜딩 페이지입니다.

내비게이션 경로

자주 하는 질문에 대한 가이드 내비게이션 시트를 만듭니다.

"모바일 앱에서 데이터베이스까지 요청이 어떻게 흐르는지 이해하려면, 서랍 3 > User Journeys > Mobile Checkout에서 시작해, 서랍 2 > Services > Checkout Service로 이동한 뒤, 서랍 1 > Production Infra > DB Cluster로 가십시오."

이렇게 인쇄된 플로우차트나 간단한 체크리스트를 만들어두면, 일종의 탐색 경로 문서화가 됩니다.

5. 아키텍처 문서화 모범 사례와 정렬하기

캐비닛은 잘 알려진 아키텍처 뷰를 반영해야 하며, 서로 다른 관심사를 한데 뒤섞어 엉망이 되지 않도록 해야 합니다.

명확히 라벨링된 섹션(구분자나 색깔 폴더)을 다음과 같이 만드십시오.

개념적 다이어그램(Conceptual)
- 고수준 비즈니스 역량
- 도메인 지도와 Bounded Context
- 대상: 이해관계자, 프로덕트, 리더십
논리적 다이어그램(Logical)
- 서비스와 모듈
- 주요 인터페이스, 데이터 계약
- 대상: 아키텍트, 시니어 엔지니어
물리적 다이어그램(Physical)
- 배포 다이어그램(노드, 클러스터, 리전)
- 네트워크 레이아웃, 방화벽, 로드밸런서
- 대상: 인프라/운영, 보안, SRE
운영 다이어그램(Operational)
- 런북과 인시던트 플로우
- 모니터링, 알림, 페일오버 경로
- 대상: 온콜 엔지니어, SRE, 지원팀

각 서브시스템 폴더 내에서는 이 구조를 일관되게 유지합니다.

[Subsystem: Payments]
  01 – Conceptual
  02 – Logical
  03 – Physical
  04 – Operational

이 표준화 덕분에 내비게이션이 예측 가능해지고, 인지 부하가 줄어듭니다.

6. 캐비닛을 협업의 표면으로 만들기

물리적 캐비닛은 본질적으로 공유 자원입니다. 개인 수납함이 아닌, 협업 공간으로 설계하십시오.

기여 규칙

캐비닛 문 안쪽에 1페이지짜리 "캐비닛 기여 가이드"를 붙입니다.

새 다이어그램 라벨링 방법
특정 유형의 다이어그램을 어디에 파일링할지
드래프트 vs 승인된 버전을 어떻게 표시할지
누가 다이어그램을 아카이빙하거나 은퇴시킬 수 있는지

주석과 피드백

팀이 다이어그램에 직접 주석을 달도록 장려합니다.

질문과 제안은 포스트잇으로 남깁니다.
리뷰 코멘트에는 다른 색 펜을 사용합니다.
의미 있는 주석에는 날짜와 이니셜을 적습니다.

중요한 결정이 있을 경우 폴더에 **결정 메모(Decision Slip)**를 추가합니다.

결정 요약
고려했던 대안들
날짜, 참여자
이 결정의 영향을 받는 다이어그램

캐비닛 주변 워크숍

캐비닛을 워크숍의 물리적 앵커로 사용하십시오.

특정 서브시스템의 다이어그램을 모두 꺼내 테이블 위에 펼쳐 둡니다.
"이게 아직 현실을 반영하나?"와 "어디에 갭이 있나?"를 함께 묻습니다.
현장에서 다이어그램을 업데이트하거나 새로 그리고, 합의한 구조에 따라 즉시 다시 파일링합니다.

목표는 캐비닛을 아키텍처에 대한 공유 이해가 물리적으로 존재하는 단 하나의 장소가 되게 하는 것입니다.

7. 물리적 제약을 설계 도구로 활용하기

종이의 단점처럼 보이는 것—제한된 공간과 변경의 마찰—은 동시에 가장 큰 강점이기도 합니다.

강제되는 명료함

줌을 무한히 할 수도 없고, 레이어를 토글하는 것도 어렵습니다. 그래서 규율이 생깁니다.

각 다이어그램의 스코프를 신중히 선택해야 합니다.
경계 안에 무엇을 넣고, 경계 밖에는 무엇을 둘지 명확히 정의해야 합니다.
한 장에 너무 많은 관심사를 동시에 담으려 할 때 바로 눈에 띕니다.

다이어그램이 읽기 어려워지면, 그건 더 명확한 뷰 여러 개로 쪼개라는 신호입니다.

경계가 있는 복잡성

서랍과 폴더에는 물리적인 용량 한계가 있습니다.

한 서브시스템 폴더가 넘쳐난다면, 이는 과도한 복잡성이나 잦은 변동의 신호입니다.
몇 개 폴더만 지나도 플로우를 따라가기 어려워진다면, 시스템이 과도하게 얽혀 있을 가능성이 있습니다.

캐비닛은 디지털 리포지토리의 어지러움보다 무시하기 훨씬 어려운, 복잡성의 물리적 거울이 됩니다.

결론: 살아 있고, 손에 잡히는 아키텍처 실천

아날로그 아키텍처 캐비닛은 단순한 옛날식 파일링 시스템이 아닙니다. 이것은 다음을 가능하게 하는 방법입니다.

아키텍처를 구조이자 스토리로 다루기
시스템이 실제로 어떻게 만들어지고 사용되는지 반영하기
진화와 히스토리를 1급 시민으로 다루기
디지털 문서화 설계의 장점을 물리 세계로 옮기기
시스템을 함께 생각하기 위한 공유 협업 공간을 제공하기
물리적 한계를 통해 명료함과 더 좋은 설계를 이끌어내기

디지털 도구를 버릴 필요는 없습니다. 캐비닛은 그것을 보완합니다. 작게 시작하십시오. 서랍 하나, 서브시스템 하나, 의도를 담아 잘 정리된 다이어그램 세트 하나로 시작하는 겁니다. 시간이 흐르면서, 아날로그 아키텍처 캐비닛은 시스템이—그리고 그 시스템에 대한 당신의 이해가—어떻게 성장하고 변해 왔는지를 보여 주는 강력한 살아 있는 아티팩트가 될 수 있습니다.