종이 인시던트 스토리 온실 트램: 신뢰성 부채가 시스템을 뒤덮기 전에 작은 아날로그 실험을 키우는 법

현대적인 신뢰성 도구는 꽤 위압적으로 보일 수 있습니다. 자동 인시던트 타임라인, 로그 스트림에 대한 머신러닝, 트렌드 대시보드, SLO 소진 알림 등등. 하지만 거의 모든 정교한 신뢰성 관행은 결국 같은 소박한 출발점에서 시작했습니다. 누군가가 뭔가를 적어 두었다는 것에서요.

당신의 인시던트 프로세스를 온실 트램(greenhouse tram) 으로 떠올려보세요. 시스템을 천천히, 의도적으로 따라가며, 작은 모종 같은 “종이 인시던트 스토리”를 수집해 나가는 느린 차량입니다. 인시던트를 어떻게 기록하고, 분류하고, 이야기하느냐 하는 이 작은 아날로그 실험들이 나중에 단단한 자동화 신뢰성 시스템으로 자라나는 씨앗입니다.

이 글에서는 인시던트를 기록하고 분류하는 데 있어 단순하고 마찰이 적은 접근법을 통해 다음을 달성하는 방법을 다룹니다.

미래의 나(와 도구들)가 분석할 수 있는 방식으로 데이터를 남기기
불 끄기(Firefighting)를 학습으로 전환하기
눈에 잘 보이지 않는 신뢰성 부채의 누적을 막기
엔지니어의 동기를 해치지 않으면서도 과도한 프로세스에 빠지지 않기

압정과 티켓에서 검색 가능한 스토리로

많은 팀의 인시던트 관리 출발점은 대략 이렇습니다.

“지금 X 죽었나요?”가 난무하는 공용 채팅 채널
사후에 (어쩌면) 생성되는 티켓
누군가의 개인 노트에 남아 있는 대략적인 타임라인 (있다면 다행)
infra, prod 같은 모호한 태그 몇 개

이건 일종의 “압정과 티켓(pushpins and tickets)” 방식입니다. 사건은 존재하지만 여기저기 흩어져 있고, 일관성도 없고, 나중에 분석하기도 어렵습니다.

당신이 노려야 할 변화는 겉보기보다 훨씬 단순합니다.

모든 인시던트가 사람과 머신이 쉽게 검색·그룹화·학습할 수 있는 작은 구조화된 이야기(story)가 되는 것.

거창한 플랫폼이 없어도 됩니다. 필요한 건 일관된 방식으로 다음 세 가지를 하는 것입니다.

기록(Capture): 모든 인시던트가 빠짐없이 기록되게 만들기
정리(Organize): 예측 가능한 필드에 데이터를 남기기
재방문(Revisit): 일정 주기로 인시던트를 묶어서 패턴을 훑어보기

초기에는 단순 문서, 스프레드시트, 기본적인 도구로 관리하더라도, 이렇게 쌓인 작은 스토리들이 시간이 지나면 자동화의 학습 데이터가 됩니다.

자동 수집과 단순 구조가 중요한 이유

인시던트 수집이 전적으로 수동이고 임기응변식이라면, 보통 이런 일이 벌어집니다.

(특히 새벽 3시에는) 타임라인이 아예 빠져 있거나 엉망임
설명과 태그가 제각각
루트 원인이나 후속 조치와의 연결이 약하거나 아예 없음
몇 달, 여러 팀에 걸친 트렌드를 쉽게 볼 방법이 없음

그 결과, 시스템에는 조용히 신뢰성 부채(reliability debt) 가 쌓여 갑니다. 반복해서 문제를 일으키는 약한 고리, 플래키(flaky)한 컴포넌트, 부서지기 쉬운 의존성이 쌓이는데, 아무도 이를 명확히 보고 우선순위를 줄 수 없습니다.

여기서 부분적인 자동 수집만으로도 판이 달라집니다.

#incident-XYZ 같은 채널이 열리면 인시던트 레코드를 자동 생성하는 봇
시작/종료 시간, 영향 범위, 추정 원인을 묻는 템플릿
관련 대시보드, 런북, 로그를 자동으로 링크하는 기능

처음부터 풀 자동화를 노리는 게 목표가 아닙니다. 목표는 “아무것도 안 한다”에 가까운 기본 경로를 밟더라도 쓸 만한 데이터가 남게 만드는 것입니다.

한번 인시던트가 일관되고 구조화된 형태로 자동 수집되기 시작하면, 다음을 할 수 있습니다.

단순한 트렌드 분석 (예: “어떤 서비스가 가장 자주 장애를 내나?”)
시스템적 약점 파악 (예: “전체 인시던트의 40%에 같은 의존성이 등장한다.”)
발생 빈도와 영향도를 기준으로 한 선제적 개선의 우선순위화

여기서 온실 트램 비유가 중요해집니다. 이 트램은 작고 구조화된 이야기들을 꾸준하고 안정적으로 모으고, 나중에 훨씬 고도화된 도구들의 먹이(데이터)가 됩니다.

전력망에서 배우기: SAIFI, SAIDI, CAIDI

소프트웨어 신뢰성 지표는 꽤 추상적으로 느껴질 수 있지만, 다른 산업은 이미 비슷한 길을 걸어 왔습니다. 예를 들어, 전력 회사들은 처음에는 정전 상황의 종이 로그 에서 출발해 다음과 같은 구조화된 신뢰성 지표를 쓰고 있습니다.

SAIFI (System Average Interruption Frequency Index)
- 대략: 평균적인 고객은 얼마나 자주 정전을 경험하는가?
SAIDI (System Average Interruption Duration Index)
- 평균적인 고객은 1년에 몇 분이나 전기를 사용할 수 없는가?
CAIDI (Customer Average Interruption Duration Index)
- 정전이 발생했을 때, 보통 얼마 동안 지속되는가?

초창기에는 이런 지표도 철저한 수동 관행에서 시작했습니다.

모든 정전을 종이에 기록
시간, 지속 시간, 위치, 원인을 포함
나중에 모아서 단순한 비율을 계산

수십 년에 걸쳐 이 단순한 기록 관행 이 완전한 디지털·자동 시스템으로 진화했고, 결국 업계 전체의 신뢰성과 투자 기준이 되는 표준으로 자리 잡았습니다.

소프트웨어 팀을 위한 교훈은 이렇습니다.

인시던트 스토리를 꾸준히, 구조적으로, 검색 가능하게 기록해 두면, 나중에 당신만의 “서비스용 SAIFI/SAIDI/CAIDI”를 만들어낼 수 있습니다.

하지만 지금 당장 그 수준의 정교한 체계가 필요한 건 아닙니다. 해야 할 일은 단 하나, 미래의 당신이 그런 지표를 계산할 수 있을 정도로 인시던트를 기록해 두는 것입니다.

나중에 크게 돌아오는 작은 아날로그 실험들

거창한 “신뢰성 프로그램”을 출범할 필요는 없습니다. 인시던트를 어떻게 기록하고 분류할지에 대한 미시 실험(micro-experiment) 으로 시작하세요. 먼저 아날로그, 그다음 자동화입니다.

이번 주에 바로 시도해 볼 수 있는 작은 실험들을 소개합니다.

1. 1페이지 인시던트 스토리 템플릿

문서 도구나 티켓 시스템에 아주 단순한 템플릿을 하나 만듭니다.

무슨 일이 있었나? (1–2문장 요약)
언제 시작/종료됐나? (타임스탬프)
누가/무엇이 영향을 받았나? (사용자, 서비스, 리전 등)
주요 기여 요인(Primary contributing factor)은? (짧은 자유 서술 + 짧은 목록에서 선택)
탐지 또는 복구가 느려진 이유는?
후속 조치(Follow-up actions)는? (담당자와 마감일 포함)

사람들이 5–10분 안에 작성할 수 있을 만큼 짧게 유지하는 게 핵심입니다.

2. 최소한의 카테고리 세트

초기부터 복잡한 분류 체계를 들이밀지 마세요. 작고 안정적인 카테고리 세트로 시작합니다. 예를 들면:

Config / Deploy
Dependency / Third-party
Capacity / Performance
Data / Schema
Feature / Logic Bug
Security / Access
Unknown (yet)

첫 번째 목표는 정확도가 아닙니다. 나중에 고칠 수 있을 정도의 일관된, “그럭저럭 괜찮은” 태깅을 만드는 것이 목표입니다.

3. 주간 20분 인시던트 트램 라이드

일주일에 한 번, 짧게 시간을 정해 최근 인시던트를 훑어보세요.

어떤 카테고리가 가장 자주 등장하는가?
동일한 서비스나 컴포넌트 이름이 반복해서 나오지 않는가?
후속 조치가 전혀 없는 인시던트는 없는가?
지난주에 정했던 후속 조치들은 실제로 완료되고 있는가?

이 시간을 인시던트 온실을 따라가는 짧은 트램 여행처럼 여겨 보세요. 어떤 식물이(문제가) 계속 올라오는지 확인할 수 있을 정도만 훑어보면 됩니다.

4. 분기마다 하나씩 추가하는 자동화 훅

아날로그 실험이 어느 정도 안정되면, 작은 자동화 요소를 하나씩 추가해 나가세요.

특정 심각도(severity)가 선언되면 인시던트 레코드를 자동 생성
채널 이름이나 온콜 로테이션 기반으로 서비스명을 자동 태깅
인시던트 레코드에 메트릭 대시보드나 로그를 자동 링크

이처럼 먼저 아날로그, 그다음 자동화로 레이어를 쌓으면, 잘못된 구조나 워크플로를 너무 일찍 굳혀 버리는 일을 피할 수 있습니다.

불만이 아닌 선생님으로서의 인시던트

인시던트를 그저 빨리 꺼야 할 불 정도로만 취급하면, 팀은 자연스럽게 다음과 같이 학습합니다.

문서 작성을 최소화한다. (“지금 폼 채우고 있을 시간이 어딨어?”)
복구 직후 바로 다음 일로 넘어간다. (“픽스 배포했고 끝, 잊자.”)
반복되는 고통을 “원래 이 시스템이 다 그런 거지”라며 받아들인다.

이렇게 해서 신뢰성 부채는 조용히 쌓입니다.

같은 취약한 의존성이 매번 조금씩 다른 방식으로 깨짐
같은 느린 탐지 패턴이 되풀이됨
빠진 런북(runbook) 때문에 시니어 엔지니어 시간이 계속 낭비됨

여기서 작은 관점 전환이 모든 걸 바꿉니다.

인시던트는 단순한 실패가 아니라, 실전 환경에서 시스템이 실제로 어떻게 동작하는지에 대한 관측값입니다.

종이 스토리와 작은 실험들은 이런 관측값을 받쳐 주는 비계(스캐폴딩)에 불과합니다. 이를 통해 다음을 할 수 있게 됩니다.

혼돈이 아닌 패턴을 보기
실제 고통에 기반해 개선의 우선순위를 정하기
리더십과 트레이드오프를 명확히 소통하기 (예: “이 범주의 인시던트에 집중하면 우리의 ‘SAIDI’가 줄어듭니다.”)

엔지니어를 소진시키지 않고 신뢰성 부채와 싸우기

프로세스는 역효과를 낼 수 있습니다. 이미 지친 팀에게 무거운 인시던트 관료주의를 떠안기면, 폼은 처벌처럼 느껴지고 회의는 보여주기식 연극처럼 느껴집니다.

동기와 생산성을 유지하려면 다음을 지키세요.

모든 것을 가볍게 유지하기.
- 인시던트 템플릿 작성에 45분이 걸리면, 일관된 데이터는 절대 나오지 않습니다.
- 코어 레코드는 “최대 5–10분”을 목표로 하세요.
가치가 빨리 보이게 만들기.
- 주간 트램 라이드 시간에, 엔지니어들이 남긴 데이터로 드러난 패턴을 직접 보여주세요.
- 예: “같은 설정 패턴에서 인시던트가 3건 나왔고, 그걸 고쳐서 이번 주에 몇 시간을 아꼈습니다.”
비난이 아니라 개선을 보상하기.
- 시스템적 약점을 발견했을 때, “누가 잘못했나?”가 아니라 “좋다, 일찍 발견했다.”라는 프레임으로 이야기하세요.
팀과 함께 프로세스를 계속 다듬기.
- 로그 구조를 하나의 실험으로 보고, 필요하면 과감히 잘라 내거나 바꾸세요.
- “어떤 필드는 잡무처럼 느껴지나요? 실제로 도움이 되는 건 뭔가요?”를 직접 물어보세요.

이렇게 하면 인시던트 실천이 엔지니어 현실과 맞닿아 있게 됩니다. 온실에서 하는 실험에 가깝고, 서류 작업 관료주의와는 거리가 멀어집니다.

온실 트램에서 풀-grown 신뢰성 시스템으로

작고 일관된 아날로그 실험을 꾸준히 이어 가다 보면, 어느 순간 다음을 할 수 있을 만큼 데이터가 쌓이게 됩니다.

팀/서비스 단위의 신뢰성 지표 정의 (예: “분기별 서비스당 평균 인시던트 수”, “팀별 평균 사용자 영향 시간”)
자동화 후보를 명확히 식별 (예: “우리는 매번 이 로그를 수동으로 모은다. 이 부분을 자동화하자.”)
구체적인 근거를 바탕으로 신뢰성 투자를 설득 (“이 10%의 서비스가 전체 영향의 70%를 차지합니다.”)

이 시점이 되면, 전용 인시던트 툴링, 옵저버빌리티 플랫폼, 신뢰성 대시보드를 도입하는 일이 믿음의 도약이 아닙니다. 이미 종이 스토리에서 보고 있던 패턴을 그대로 코드로 옮기는 자연스러운 다음 단계가 됩니다.

결론: 작게, 그리고 지금 시작하기

신뢰성을 잘하기 위해 거창한 인시던트 AI 플랫폼이 꼭 필요한 건 아닙니다. 필요한 것은 무슨 일이 일어났는지를 꾸준히 적어 두는 규율과, 여러 인시던트를 가로질러 패턴을 보는 습관입니다.

당신의 현재 프로세스를 하나의 종이 인시던트 스토리 온실 트램으로 생각해 보세요.

움직임은 느리지만 꾸준합니다.
단순하고 구조화된 스토리를 수집합니다.
신뢰성 부채가 숲처럼 자라나기 전에 어디서 자라고 있는지 보여 줍니다.

다음에서 시작하세요.

1페이지 인시던트 템플릿
작은 카테고리 세트
주간 20분 리뷰
한 번에 하나씩 추가하는 작은 자동화

이것만으로도 인시던트 시스템은 자연스럽게 진화할 수 있습니다. 아날로그 실험에서 자동화된 인텔리전스로. 그 과정에서 엔지니어를 짓누르지도 않고, 신뢰성 부채가 조용히 스택 전체를 점령하게 내버려 두지도 않으면서 말입니다.