아날로그 장애 스토리 ‘매듭 캐비닛’: 실, 핀, 그리고 종이 로그로 숨은 의존성을 풀어내기

요즘 시스템은 끝없이 디지털처럼 느껴집니다. 클라우드, 컨테이너, 마이크로서비스, 스트리밍 파이프라인, 그리고 온갖 대시보드까지. 하지만 실제로 장애가 터지고 압박이 심해지는 순간, 가장 강력하게 쓸 수 있는 도구는 놀랍도록 로우테크일 때가 많습니다. 바로 벽, 핀, 실, 그리고 종이 로그입니다.

이 글은 내가 **“매듭 캐비닛(Cabinet of Knots)”**이라고 부르는 것에 대한 이야기입니다. 멀끔한 아키텍처 다이어그램과 서비스 맵 너머, 시스템이 실제로 돌아가는 모습을 아날로그로 엉성하고 복잡하게 드러내는 도구죠. 동시에, 실과 핀, 종이를 활용해 가장 유용한 장애 대응 도구 중 하나를 직접 만드는 방법에 대한 실용적인 가이드이기도 합니다.

똑똑한 시스템이 어이없이 망가지는 이유

복잡한 시스템은 아키텍처 슬라이드에 그려진 모습 그대로 고장 나는 경우가 거의 없습니다.

숨은 의존성은 어디에나 숨어 있습니다.

“stateless”라고 주장하지만 실제로는 단일 공유 Redis 클러스터에 슬쩍 기대고 있는 API
“best effort” 수준이라던 로깅 파이프라인이 어느 순간 컴플라이언스를 위해 필수 요소가 되어버린 경우
오래된 cron 잡 안의 스크립트 하나만 쓰고 있는데, 이제는 아무도 그 존재 이유를 기억 못하는 서비스

이런 의존성은 보통 장애가 터지기 전까지는 보이지 않습니다. 모니터링은 증상을 보여줄 수 있지만, 진짜 원인은 서비스들 사이의 틈, 그리고 사람들 사이의 틈에 숨어 있는 경우가 대부분입니다.

왜냐하면 실제 프로덕션 환경은 대부분 **사회기술 시스템(sociotechnical system)**이기 때문입니다. 단순히 코드와 인프라만이 아니라, 여기에 이런 것들이 얽혀 있습니다.

사람과 그들의 멘탈 모델
프로세스와 커뮤니케이션 경로
구전 지식과 잊힌 결정들

장애는 종종 **기술 시스템(실제 동작 방식)**과 사회 시스템(사람들이 그렇게 동작한다고 믿는 방식) 사이의 불일치에서 발생합니다.

그리고 바로 이 지점에서 아날로그 도구가 빛을 발합니다.

왜 아날로그인가: 슬라이드보다 실이 더 강력한 이유

디지털 도구는 최신 아키텍처 뷰, 실시간 서비스 맵, 의존성 그래프를 유지하는 데 훌륭합니다. 반드시 써야 합니다. 하지만 그게 전부는 아닙니다.

실제 물리적인 로우테크 도구—실, 핀, 종이, 벽—를 쓰기 시작하면, 사람들이 생각하고 상호작용하는 방식이 달라집니다.

손으로 만질 수 있으면 = 더 잘 기억난다
핀을 꽂고, 실을 당겨 연결하고, 로그를 벽에 붙이는 과정은 대시보드를 클릭하는 것과 완전히 다릅니다. 사람들은 이 지도를 함께 만들었기 때문에 더 잘 기억합니다.
느림 = 성찰의 시간
손으로 그리는 건 API에서 가져와 자동 생성하는 것보다 훨씬 느립니다. 이 느림 덕분에 팀은 자연스럽게 대화를 나누고, 가설을 의심하며, “잠깐만, 이게 진짜 이거에 의존하긴 해?” 같은 질문을 하게 됩니다.
부정확함 = 발견의 여지
디지털 다이어그램은 종종 ‘확실하다’는 인상을 줍니다. 반면 벽에 얽힌 실들은 기꺼이 ‘불확실함’을 드러냅니다. 물음표, 끄적거린 메모, 지워진 선들. 이런 애매함이 오히려 탐색을 부릅니다.
눈에 보임 = 공유된 이해
벽에 붙어 있는 물리적인 지도는 무시하기 어렵습니다. 지나다니는 사람들이 보게 되고, 질문하고, 틀린 부분을 고쳐줍니다. 시간이 지나면, 이건 팀이 공유하는 이해를 담은 살아있는 아티팩트가 됩니다.

아날로그는 향수 때문이 아니라, 디지털 도구만으로는 끌어내기 어려운 생각과 협업을 열어주기 위해 존재합니다.

나만의 매듭 캐비닛 만들기: 실전 연습

거창한 워크숍 공간이 필요하지 않습니다. 방 하나, 벽 한 면, 그리고 다양한 역할의 사람들이 함께 있으면 충분합니다.

1단계: ‘시스템’이 아니라 ‘스토리’를 고르기

“우리 전체 아키텍처를 다 그려보자”로 시작하지 마세요. 너무 방대하고 추상적입니다. 대신, 팀이 실제로 겪었던 특정 장애나 인시던트 하나를 고르세요.

“작년 11월에 있었던 체크아웃 속도 저하 사건”
“블랙 프라이데이 때 몰아쳤던 502 폭풍”
“반나절 동안 대시보드를 망가뜨린 데이터 파이프라인 지연 사고”

이 인시던트가 바로 **이야기의 척추(spine)**입니다. 단순히 서비스를 그리는 게 아니라, 그 장애가 어떻게 전개됐는지를 함께 그리는 겁니다.

2단계: 아날로그 재료 모으기

테이블 위에 이런 것들을 꺼내 두세요.

넓은 벽이나 화이트보드
서비스, 데이터 저장소, 큐, 외부 서비스 등을 표시할 핀이나 포스트잇
호출, 의존성, 데이터 흐름을 나타낼 실
종이 로그(또는 로그, 티켓, Slack 스레드를 출력한 종이)
메모용 마커, 테이프, 추가 포스트잇

이게 바로 여러분의 인시던트 대응 공예 키트입니다.

3단계: 아키텍처보다 ‘시간’부터, 종이 로그로 타임라인 복원하기

먼저 시간 축부터 시작하세요. 아키텍처가 아닙니다.

벽에 가로 방향으로 인시던트 타임라인을 만듭니다.

처음 증상이 나타난 시점은 언제였나요?
알람이 뜬 시점은?
고객 불만이 들어오기 시작한 시점은?
누가 “이거 혹시 X 때문 아닐까?”라고 말한 순간은?
실제 원인을 찾고, 수정이 완료된 시점은 언제였나요?

이 타임라인을 따라 관련된 종이 로그나 Slack 캡처를 붙입니다.

중요한 순간의 로그 라인들
인시던트 채널의 주요 메시지(“Redis가 과부하 같은데요”)
티켓 업데이트나 상태 페이지 공지

이 단계만으로도 시스템의 인간적인 면이 드러납니다. 사람들이 무엇을 봤고, 무엇이라 생각했으며, 무엇을 시도했고, 그게 언제 있었는지.

4단계: 서비스와 의존성 올려놓기

이제 타임라인 위나 아래에, 핀이나 포스트잇으로 이런 것들을 붙입니다.

서비스 (API Gateway, User Service, Billing Service 등)
데이터 저장소 (Postgres 클러스터, Redis, S3 버킷 등)
외부 의존성 (결제 대행사, 이메일 서비스, 서드파티 API)
인프라 컴포넌트 (로드밸런서, 큐, Feature Flag 시스템 등)

그리고 실로 이들을 연결합니다.

실선: 강한 의존성 (서비스 A는 B 없이는 동작 불가)
점선: 약한 / “best effort” 의존성
실 색을 다르게: 내부 vs 외부 의존성 구분

정확함에 집착할 필요는 없습니다. 중요한 건 계속 질문하는 겁니다.

“레코멘데이션 서비스가 저 캐시를 진짜 항상 쓰나, 아니면 일부 요청만?”
“저 결제 프로바이더는 직접 호출해? 아니면 다른 서비스 경유해?”
“저 설정은 누가, 어떤 프로세스로, 얼마나 자주 업데이트하지?”

그냥 그림을 그리는 게 아니라, 아키텍처를 심문하고 있는 겁니다.

5단계: 스토리를 지도 위에 덧입히기

이제 타임라인과 지도를 연결합니다.

인시던트의 각 주요 순간마다, 지도의 어느 부분이 관여했는지 실로 따라가 봅니다.
알람이 울린(혹은 울리지 않은) 지점을 색 스티커로 표시합니다.
누군가의 멘탈 모델이 틀렸던 곳을 표시합니다.
(“우리는 이 서비스가 이중화 되어 있다고 생각했는데, 실제론 아니었다”)
장애 중에 처음 발견된 경로나 흐름을 강조 표시합니다.

이렇게 해서 여러분은 **사회기술 지도(sociotechnical map)**를 만들고 있습니다.

기술 계층: 서비스와 의존성
인간 계층: 인식, 가정, 의사결정

이게 바로 여러분의 매듭 캐비닛입니다. 멀끔한 시스템 다이어그램 아래 숨겨져 있던 실제의 복잡한 얽힘이 드러난 상태죠.

여기서 거의 반드시 발견하게 되는 숨은 의존성들

이 연습을 해 보면 대부분의 팀이 이런 것들을 발견합니다.

아무도 ‘핵심’이라고 생각하지 않았던 싱글 포인트 오브 페일리어(SPoF)
“임시로” 붙여놨다가 어느새 조용히 핵심이 되어버린 컴포넌트
로그를 데이터 소스로 쓰거나, 대시보드가 불안정한 가정들 위에 세워져 있는 숨은 데이터 흐름
공식 아키텍처 다이어그램 어디에도 등장하지 않지만, 실제로는 핵심 동작을 좌우하는
cron 잡, 스크립트, feature flag
“저 서버는 운영팀만 잘 알아요” 같은 구전 지식과 공식 문서 사이의 간극

또, 디지털 도구가 우리를 헷갈리게 했던 지점들도 보입니다.

서비스 맵은 연결 상태를 보여주지만, 실제 런타임 동작은 보여주지 않았던 부분
평상시 운영에는 최적화되어 있지만, 장애 분석에는 별로 도움 안 되는 대시보드
외부 시스템이나 “라인 밖(out-of-band)” 프로세스—이메일, 수동 Runbook, 스프레드시트—를
전혀 반영하지 못했던 의존성 그래프

아날로그 매핑은 기존 도구를 대체하는 게 아닙니다. 기존 도구가 보지 못하는 영역을 드러내는 일입니다.

벽에서 실전으로: 운영에 녹여내기

한 번 매듭으로 엉켜 있는 벽을 만들었다면, 이제 이걸 실제 운영에 도움이 되도록 쓰는 단계가 필요합니다.

1. 디지털 지도에 다시 반영하기

사진을 찍고, 거기서 배운 것들을 이렇게 옮겨 담습니다.

업데이트된 서비스 맵
더 정확한 Runbook
실제 의존성에 맞게 조정된 알림 규칙
그동안 주인이 없던 고아 컴포넌트에 대한 명확한 오너십 부여

이제 디지털 도구들이 더 나은 **현실 반영(ground truth)**을 얻게 됩니다.

2. 다음 인시던트 때 직접 활용하기

실제 장애 상황에서, 물리적인 지도는 이렇게 쓸 수 있습니다.

인시던트 대응 팀의 시선이 모이는 중심점 역할
누가 시스템의 어느 부분을 보고 있는지 조율하는 기준점
각자 브라우저 탭 15개씩 열어놓는 대신, 모두가 같은 참조점을 공유

물리적인 아티팩트는 팀이 정렬 상태를 유지하고, 인지 부하를 줄이는 데 큰 도움이 됩니다.

3. 주기적으로 다시 꺼내 새로 매듭 짓기

아키텍처는 계속 변합니다. 사람은 팀을 옮기고, 서비스는 사라지거나 새로 생깁니다.

그래서 의존성 지도에 다시 손대는 주기를 정하는 편이 좋습니다.

큰 아키텍처 변경 이후
의미 있는 인시던트가 있었던 후
분기별 또는 반기별 학습 세션으로

매 세션마다 새로운 가정이 드러나고, 낡은 지식이 발견되고, 몰래 자라난 의존성이 튀어나옵니다. 이렇게 해야 이 지도는 박물관 전시물이 아니라 계속 살아있는 도구가 됩니다.

왜 이게 중요한가: 예쁜 다이어그램을 넘어서

아날로그 매듭 캐비닛의 진짜 가치는 그 멋진 최종 그림에 있지 않습니다. 그 지도를 만들면서 어쩔 수 없이 하게 되는 대화들에 있습니다.

이 과정을 거치면서 여러분은:

사람들의 실제 시스템 이해가 어떤지 마주하게 되고
“우리 서비스가 당신네 서비스 호출하는 줄 몰랐어요” 같은 사일로를 드러내며
문서에 적힌 내용과 현실 사이의 모순을 밝혀내고
다음 인시던트 때 큰 힘이 되는 공유 멘탈 모델을 쌓게 됩니다.

서비스와 의존성을 실시간으로 매핑하는 작업—벽에 하든, 라이브 서비스 맵 도구로 하든—은 팀이 더 빠르게 트러블슈팅하고, 장애 영향도를 줄이는 데 분명 도움이 됩니다. 여기에 아날로그 접근이 더해주는 가치는 한 걸음 더 나아갑니다. 기술적인 면과 인간적인 면 모두에서, 보이지 않던 것들을 눈에 보이게 만들어 준다는 점입니다.

맺음말: 작게 시작해서, 일단 실 몇 가닥을 묶어보자

숨은 의존성을 이해하기 위해 거창한 예산이나 새로운 SaaS 제품이 필요한 건 아닙니다. 필요한 건 이 정도입니다.

하나의 스토리 (함께 되짚어볼 인시던트)
한 공간 (벽이나 화이트보드)
몇 가지 단순한 도구 (실, 핀, 종이 로그)
그리고 그 자리에 함께 있어야 할 사람들

그다음은, 매듭이 저절로 드러나게 두면 됩니다.

깨끗한 다이어그램은 언제나 중요합니다. 하지만 다음번 장애가 터지고 모두가 “대체 뭐가 뭘 의존하고 있는 거야?”라며 허둥댈 때, 한 번쯤 벽 가득 얽힌 실 앞에 서서 “우리 시스템이 진짜 어떻게 붙어 있는지” 배웠던 경험이 얼마나 소중한지 실감할 겁니다.

가끔은, 미래를 디버깅하는 가장 좋은 방법이 화면에서 잠시 눈을 떼고, 핀 하나를 집어 들어, 실 한 가닥을 따라가 보는 일일지도 모릅니다.