연필로 그린 사건 정원: 손으로 스케치한 실패 씨앗에서 신뢰성 의식을 키우기

우리가 장애(incident)를 마주하는 순간은 보통 최악의 형태다. 반짝이는 페이저 알림, 팽팽한 회의 콜, 온통 빨간색으로 물든 대시보드. 그 뒤에는 서둘러 패치하고, 최소한만 문서화한 다음, 같은 일이 다시는 안 일어나길 바라며 그냥 넘어간다.

그런데 만약 모든 장애를 작고 불완전한 씨앗처럼 다루면 어떨까? 숨기고 싶은 실패의 증거가 아니라, 스케치하고 들여다보고, 우리 신뢰성 실천의 정원에 의도적으로 심어야 할 씨앗으로 대한다면?

이것이 **연필로 그린 실패 씨앗(pencil-drawn failure seeds)**과 **사건 정원(incident garden)**이라는 아이디어다. 이야기, 스케치, 의식을 이용해 팀이 신뢰성을 바라보는 방식을 바꾸는 것이다.

왜 연필로 그린 “실패 씨앗”인가?

방금 프로덕션 장애가 났다고 상상해 보자. 포스트모템 템플릿을 열거나 형식적인 보고서를 쓰기 전에, 연필과 빈 종이 한 장을 집어 든다.

당신은 이렇게 그린다:

작은 씨앗 하나에 *"API 지연 시간 급증"*이라고 적는다.
복잡하게 얽힌 뿌리에는 *"연쇄 타임아웃"*이라고 이름 붙인다.
그 위에 떠 있는 먹구름에는 *"자원 포화에 대한 알림 누락"*이라고 쓴다.
도구를 들고 있는 정원사(당신의 팀)를 그리고, 도구에는 "런북(runbook)", "피처 플래그(feature flags)", *"SLOs"*라고 표기한다.

5분 만에, 방금 일어난 일과 그로부터 무엇이 자라날 수 있는지를 보여주는 시각적 은유를 만들어낸 것이다.

이 단순한 행동이 생각보다 많은 걸 바꾼다.

사건을 재구성한다 – 더 이상 “DB가 죽던 그 날”이 아니라, 우리가 심고 돌볼 수 있는 인사이트의 씨앗이 된다.
비난을 완화한다 – 씨앗은 악이 아니라 가능성이다. 개인의 잘못이 아니라, 조건과 돌봄에 집중하게 된다.
대화를 초대한다 – 텍스트 벽보다 스케치가 훨씬 이야기하기 쉽다. 사람들은 그림의 요소를 가리키며 묻고, 의견을 보태고, 아이디어를 추가한다.

연필이라는 도구 자체도 의미가 있다. 일부러 거칠고 지울 수 있는 도구를 쓰는 것은, 지금은 ‘결론’이 아니라 ‘탐색’의 단계라는 신호이기도 하다.

스토리텔링을 활용한 신뢰성 테라피

요즘 신뢰성(reliability) 분야의 언어는 종종 위압적이다. 분산 합의(distributed consensus), 백프레셔(backpressure), 인과 추적(causal tracing), 최종적 일관성(eventual consistency)… 모두 중요하지만, 스트레스 가득한 장애 직후 사람 사이의 대화를 시작하기에는 적절한 언어가 아닐 때가 많다.

대신, 우리는 상담(therapy)과 스토리텔링 전통에서 아이디어를 빌려올 수 있다.

은유 – “우리 캐시는 출처 없는 소문만 돌리는 가십 네트워크처럼 행동했다”는 말은, “캐시 무효화(cache invalidation) 오류였다”보다 훨씬 기억에 남는다.
캐릭터 – 잡 스케줄러는 “과로한 교통경찰”, 배포 파이프라인은 “잠들 줄 모르는 컨베이어 벨트”가 된다.
여정 – 장애는 시작(트리거), 중간(확산), 끝(복구와 학습)을 가진 하나의 이야기다.

이러한 ‘테라피 스타일’ 은유는 기술적 디테일을 대체하지 않는다. 대신, 그 디테일을 사람들이 몸에 익히고 압박 상황에서도 떠올리기 쉬운 이야기의 껍질로 감싸준다.

모든 문화는 중요한 규범을 전하기 위해 우화, 비유, 동화를 사용한다. “양치기 소년”, “토끼와 거북”, “모래 위에 원을 그린 아이” 같은 이야기들 말이다. 신뢰성 문화도 마찬가지다. 시간이 지나면 장애는 조직 내부의 우화가 된다.

“이건 딱 블랙프라이데이 캐시 붕괴 때랑 같네. 그때 우리가 SLO를 tightened 하고 백프레셔를 추가해서 살아남았던 거 기억나?”
“지금 ‘침묵의 알림(silent alert)’ 구역으로 들어가고 있어. 지난번엔 그 메트릭을 책임지는 사람이 아무도 없었잖아.”

은유는 추상적인 신뢰성 원칙을 감정이 실린, 잘 달라붙는(sticky) 이야기로 바꿔서 실제 행동을 움직이게 한다.

기술적 토양: 정원의 화단이 되는 DevOps

사건이 씨앗이라면, 유용한 것으로 자라기 위해서는 토양이 필요하다. 현대 시스템에서 그 토양은 바로 DevOps 실천이다.

핵심 DevOps 역량은 신뢰성 의식(ritual)이 뿌리내릴 수 있는 환경을 만든다.

지속적 통합(CI) – 학습을 테스트로 옮기기 쉽게 만든다. 실패 씨앗이 경계 조건을 알려주면, 그에 맞는 테스트를 CI에 추가한다. 정원에 건강한 식물이 하나 더 생기는 셈이다.
지속적 전달/배포(CD) – 안전하고 빈번한 변경을 가능케 한다. 인사이트를 빠르게 반영할 수 있어, 씨앗이 백로그에서 썩도록 두지 않아도 된다.
Infrastructure as Code(IaC) – 학습 내용을 버전 관리되고 리뷰 가능한 설정 변경으로 남길 수 있게 한다. 특정 몇 사람만 아는 구전 지식이 되지 않게 해준다.

나쁜 토양, 즉 수동 배포, 깨지기 쉬운 환경, 느린 변경 문화에서는 당신의 사건 의식은 쉽게 시든다. 사람들에게 새 실천을 심고 가꿀 여유나 자신감이 없기 때문이다.

그러니 “왜 우리는 사후 장애 의식(post-incident ritual)이 잘 안 먹힐까?”라고 묻기 전에, 먼저 “우리 DevOps 토양이 무엇이든 잘 자랄 만큼 건강한가?”를 물어볼 필요가 있다.

Observability: 정원을 또렷이 보는 눈

실패 씨앗을 그린다는 것은, 곧 그 식물을 이해하고 있다는 전제 위에 선다. 모니터링과 Observability(가시성) 없이는, 우리는 그저 대략적인 형태를 짐작할 뿐이다.

신뢰성 정원은 우리가 이런 능력을 갖출수록 더 잘 자란다.

풍부한 텔레메트리 – 로그, 메트릭, 트레이스, 프로파일 등 실제로 어떤 일이 일어났는지를 보여주는 데이터. 우리의 추측이 아니라 사실을 제공한다.
상관관계 있는 뷰 – 하나의 사용자 요청이 여러 서비스를 거쳐가는 경로나, CPU 스파이크를 특정 배포와 연결해서 볼 수 있는 능력.
역사적 맥락 – 오늘 장애가 지난주, 작년의 장애와 어떻게 다른지, 혹은 비슷한지 보는 관점.

Observability 도구는 정확한 사건 정원을 그리는 데 필요한 데이터를 제공한다.

시스템에서 어디서 결함이 시작되었는지 그릴 수 있다.
의존성들을 타고 어떻게 전파되었는지 보여줄 수 있다.
누가 영향을 받았는지(SLO, 사용자 세그먼트, 리전 등) 시각화할 수 있다.

Observability가 좋아질수록, 당신의 사건 스케치는 더 현실에 가깝고, 학습은 더 비옥해진다.

사건을 재사용 가능한 씨앗으로 만들기

모든 사건이 큰 의식을 치를 만한 가치는 있는 것은 아니다. 하지만 중요하거나 반복되는 장애는 구조화된 교훈 도출 프로세스를 반드시 거쳐야 한다.

간단한 패턴은 다음과 같다.

씨앗을 포착한다
- 사건 정원을 스케치한다: 핵심 컴포넌트, 트리거, 결과를 그림으로 남긴다.
- 짧은 내러티브를 쓴다: "어느 배포 날, 우리의 체크아웃 지연 시간이 자라나기 시작했다…" 같은 형태로.
조건을 명확히 한다
- 어떤 토양 문제가 있었는가? (기술 부채, 부족한 테스트, 불분명한 오너십 등)
- 어떤 날씨가 영향을 미쳤는가? (트래픽 급증, 서드파티 장애, 조직 변화 등)
패턴에 이름을 붙인다
- 기억에 남을 만한 이름을 준다: "숨겨진 타임아웃 씨앗(The Hidden Timeout Seed)", "버려진 알림 씨앗(The Orphaned Alert Seed)", "과신한 롤아웃 씨앗(The Overconfident Rollout Seed)" 등.
- 이렇게 하면 나중에 다시 참조할 수 있는 재사용 가능한 이야기 단위가 된다.
개선점을 심는다
- 새로운 가드레일(테스트, 알림, SLO, 서킷 브레이커).
- 프로세스 변화(오너십 명확화, 더 나은 인수인계).
- 문서 업데이트(런북, 설계 문서).
씨앗 봉투를 보관한다
- 스케치, 스토리, 그에 따른 변경 사항을 한곳에 모아 둔다. 사건 라이브러리, 내부 위키, 신뢰성 플레이북 같은 곳이 될 수 있다.

시간이 지나면, 조직은 씨앗과 이야기의 카탈로그를 갖추게 된다. 신규 엔지니어는 사건 정원을 거닐며 무엇이 잘못됐는지만이 아니라, 그 경험에서 팀이 어떻게 성장하기로 선택했는지를 함께 배우게 된다.

의식화된 사후 검토: 정원을 돌보는 일

씨앗의 가치는, 그것을 키우는 의식의 힘만큼만 발휘된다. 그래서 **정기적이고 구조화된 사후 장애 검토(post-incident review)**가 중요하다.

건강한 신뢰성 의식의 요소는 다음과 같다.

심리적 안전을 우선시한다
- 항상 이렇게 시작한다: “우리는 개인의 잘못을 따지기 위해 모인 것이 아니라, 시스템의 행동과 우리의 맥락을 이해하기 위해 모였습니다.”
- 비난 없는 언어를 사용한다: “이 코드 경로는 ~하기 쉽게 만들었다”라고 말하고, “당신이 ~를 깜빡했다”라는 표현은 피한다.
하나의 그림, 하나의 이야기
- 매 검토를 스케치로 시작한다. 연필로 그린 사건 그림을 보여준다.
- 누군가가 일상의 언어로 짧게 이야기를 들려준다. 그래프와 타임라인으로 들어가기 전에 서사 구조를 먼저 공유하는 것이다.
일관된 구조
전형적인 섹션은 이렇다:
- 우리가 기대한 일은 무엇이었나?
- 실제로는 무엇이 일어났나?
- 탐지, 진단, 복구에 도움이 된 것은 무엇이었나?
- 더 어렵게 만든 것은 무엇이었나?
- 무엇을 “심을 것”인가(액션), 그리고 그것이 자랐는지 어떻게 확인할 것인가(후속 점검)?
의식적인 후속 조치
- 액션 아이템은 실제로 수행할 수 있는 범위로 제한한다.
- 명확한 오너와 마감일을 지정한다.
- 이후 검토에서 주요 씨앗들을 다시 꺼내 본다: “이 식물은 결국 싹이 났는가?”

이런 의식이 루틴이 되면,

실패를 공개적이고 건설적으로 이야기하는 문화가 자연스러워지고,
두려움은 호기심으로 바뀌며,
학습은 위기 상황에만 폭발적으로 일어나는 것이 아니라, 지속적인 흐름이 된다.

다시 말해, 조직 안에 지속적인 학습, 회복탄력성(resilience), 심리적 안전의 문화를 기르는 셈이다.

당신의 팀에 사건 정원을 들여오는 방법

자신만의 사건 정원을 키우기 시작하는 데 거창한 새 도구는 필요 없다. 몇 가지 의도적인 변화면 충분하다.

스케치 단계를 체크리스트에 추가한다.
- 사후 장애 프로세스에, 검토 전에 누군가가 단순한 연필 스타일의 사건 다이어그램을 그리는 단계를 넣는다.
씨앗에 이름을 붙인다.
- 주요 장애마다 그 교훈을 담은 은유적인 이름을 붙인다.
보이는 정원을 만든다.
- 사무실에 실제 벽을 하나 마련하거나, 가상 보드에 사건 스케치와 짧은 이야기를 모아둔다.
씨앗을 토양과 연결한다.
- 각 사건에 대해, 그 교훈이 CI/CD, IaC, Observability 개선과 어떻게 연결되는지 명시적으로 작성한다.
이야기를 나눈다.
- 온보딩, 설계 리뷰, 계획 미팅에서 이 우화들을 활용한다.
- 익숙한 패턴이 다시 보일 때, 과거의 씨앗을 참조해 이야기한다.

결론: 실패에 대한 두려움에서 성장에 대한 호기심으로

사건이 즐거울 날은 아마 오지 않을 것이다. 하지만 사건을 단절된 비상사태 이상의 것으로 바라볼 수 있다면, 그것들은 매우 깊은 가치를 줄 수 있다.

다음과 같은 실천을 통해,

연필로 실패 씨앗을 스케치하고,
복잡한 신뢰성 개념을 이야기와 은유로 감싸고,
DevOps 실천을 건강한 토양으로 가꾸고,
Observability를 활용해 정확한 정원 그림을 그리며,
구조화된, 의식적인 사후 검토를 이어 간다면,

조직의 질문은 “누가 망쳤나?”에서 “여기서 무엇을 키울 수 있을까?”로 바뀐다.

이 관점 전환에 바로 사건 정원의 진짜 힘이 있다. 공유된 이야기와 구체적인 실천이 끊임없이 더해지며, 시스템과 팀이 조금씩 더 회복탄력 있고 단단해지는 살아 있는 풍경을 만들어 가는 것이다.

이 모든 것을 시작하는 데 필요한 것은, 한 자루의 연필, 하나의 이야기, 그리고 실패를 흉터가 아닌 씨앗으로 보려는 작은 의지뿐이다.