종이부터 시작하는 인시던트 신호 랜턴

내일의 장애를 오늘 찾아내는 수공 Nightly Walkthrough

요즘 신뢰성 스택에는 대시보드, 알림(alert), 트레이스(trace), 자동화 워크플로우가 빼곡합니다. 그런데 가장 성과가 좋은 일부 엔지니어링 팀들은 여기에 아주 로우테크한 무언가를 조용히 더하고 있습니다. 바로 종이입니다.

정확히 말하면, 시스템·위험·신호를 훑어보는 종이부터 시작하는, 손으로 만드는 nightly walkthrough입니다. 이 글에서는 이 의식을 **인시던트 신호 랜턴(Incident Signal Lantern)**이라 부르겠습니다.

등대지기가 밤마다 등대를 한 바퀴 돌며 난간을 걷고, 등불을 확인하고, 기계의 웅웅거리는 소리를 듣고, 뭔가 이상한 기척이 있으면 적어두는 모습을 떠올려 보세요. 이제 그 등대가 바로 여러분의 프로덕션 환경입니다.

이 글에서는 이 의식을 어떻게 설계할지, 왜 일부러 속도를 늦추는 아날로그 도구가 효과적인지, 그리고 이를 선제적 모니터링·리스크 관리·온콜(On-call) 운영과 어떻게 연결해서 내일의 장애를 오늘 발견할 수 있는지 살펴봅니다.

디지털 세상에 왜 ‘종이부터 시작하는’ 의식인가?

처음 들으면, 종이부터 시작하는 인시던트 의식은 향수에 젖은 행동이거나 비효율적으로 보일 수 있습니다. 하지만 이 방식이 통하는 데는 분명한 이유가 있습니다.

1. 일부러 속도를 늦추게 만듭니다. 손으로 쓰는 것은 타이핑보다 느립니다. 이 속도의 마찰은 오히려 장점이 됩니다. 주의를 고정시키고, 중요한 디테일을 휙휙 넘겨보기 어렵게 만듭니다.
2. 멀티태스킹을 줄입니다. 종이에는 알림도, 탭도, 슬랙(Slack) 알림도 없습니다. 노트북을 바라보고 있는 동안에는 대시보드를 끝없이 넘겨보며 딴짓할 수가 없습니다.
3. ‘의식 상태’를 만들어 줍니다. 펜이 종이를 긁는 소리, 페이지를 넘기는 소리, 어쩌면 기계식 타이머가 째깍거리는 소리가 뇌에 신호를 줍니다. “지금은 반응할 때가 아니라, 리뷰할 시간이다.” 시간이 지날수록 이 시간은 긴장되는 순간이 아니라 오히려 차분한 시간으로 자리잡습니다.
4. 생각의 흔적이 그대로 남습니다. 타이핑한 로그는 검색하기는 좋지만, 손글씨 노트에는 어떻게 생각했는지가 남습니다. 무엇을 동그라미치고, 밑줄 긋고, 지우고 다시 썼는지 말이죠. 이는 인시던트 대응 방식을 개선하는 데 매우 귀중한 자료입니다.

인시던트 신호 랜턴은 대시보드나 SRE 프로세스를 대체하려는 것이 아닙니다. 기존 도구 위에 아주 얇게 얹는 아날로그 레이어로, 사람의 주의를 더 예리하게 만드는 데 초점이 있습니다.

인시던트 신호 랜턴: 매일 밤 하는 Walkthrough

핵심 아이디어는 이렇습니다. 하루에 한 번, 보통 늦은 오후나 저녁에, 한 명의 엔지니어가 프로덕션 신호, 위험 지점, 온콜 준비 상태를 손으로 작성하는 walkthrough 형태로 점검합니다.

이것은 하나 더 늘어난 회의나, “로그나 한번 볼까” 하는 즉흥적인 행동이 아닙니다. 의도적이고, 반복 가능한 의식입니다.

1. 아날로그 “랜턴” 키트 준비하기

필요한 것은 많지 않습니다.

• 전용 인시던트 노트북 (팀당 1권 또는 서비스당 1권)
• 매일 똑같이 쓰는 인쇄된 템플릿(또는 손으로 그린 고정된 레이아웃)
• 쓰기 편한 펜 또는 연필
• 선택 사항이지만 도움이 되는 것:
  • 조용한 공간
  • 기계식 타이머
  • 이 리뷰와 연관된 단순한 소리 (째깍거리는 타이머, 저음의 로파이 음악, 화이트 노이즈 등)

도구와 소리가 늘 같다는 점이 중요합니다. 여러분의 신경계는 이렇게 학습합니다. “이 환경 = 침착하고, 비패닉 상태에서 신뢰성을 생각하는 시간.”

2. 단순하고 반복 가능한 페이지 레이아웃

매일 밤 쓰는 페이지는 다음과 같은 섹션을 포함할 수 있습니다.

• 날짜 / 리뷰어 이름
• 점검한 핵심 서비스 목록 (미리 정의된 리스트)
• 오늘의 주요 신호(Top Signals Today)
  • 에러율
  • 지연 시간(latency) / RPS 이상 징후
  • 캐퍼시티/CPU/메모리 추세
  • 큐(backlog) 적체
• (아직 인시던트는 아니지만) 잠재적 리스크
  • 망가진 건 아니지만 서서히 악화되는 것은?
  • 지난주와 비교했을 때 “조금 기분 나쁘게” 느껴지는 것은?
• 리스크 평가 스냅샷
  • 영향도(Impact): 누가, 얼마나 크게 피해를 보는가?
  • 발생 가능성(Likelihood): 감(직관) + 데이터 기반
  • 시간 지평(Time horizon): 몇 시간, 며칠, 몇 주?
• 내일을 위한 계획된 액션
  • 완화 조치(mitigations)
  • 후속 작업
  • 다른 팀에 물어볼 질문
• 온콜 & 런북(runbook) 점검
  • 지금 온콜 담당자는 누구인가? 준비는 되어 있는가?
  • 업데이트가 필요하거나 빠져 있는 런북은 없는가?

구조화된 섹션이 walkthrough의 초점을 잡아 주고, 손글씨라는 형식이 생각을 능동적으로 유지시켜 줍니다.

3. 실제 Walkthrough는 이런 느낌입니다

20–30분 정도의 세션은 대략 다음과 같은 흐름입니다.

1. **고정된 시간(예: 25분)**으로 타이머를 맞춥니다. 슬랙과 이메일은 닫습니다.
2. 새 페이지를 펼치고, 날짜와 이름을 적습니다.
3. 대시보드와 툴을 살펴보되, 인사이트는 종이에 적습니다.
   • “서비스 A: 95퍼센타일 레이턴시가 지난주 대비 소폭 상승.”
   • “Kafka consumer lag가 매일 새벽 2시에 스파이크. 추세상 점점 악화되는 중.”
4. 수상한 것에는 간단한 기호로 표시합니다.
   • ! : 리스크가 큰 항목
   • ? : 아직 잘 모르겠는 것
   • → : 후속 액션이 필요한 것
5. 관찰을 ‘리스크’의 형태로 번역합니다.
   • “현재 메모리 누수 추세가 계속되면, 노드 재시작 시점이 3–5일 안에 피크 트래픽 시간대와 겹칠 수 있음.”
6. 내일을 위한 구체적인 다음 액션 2–3개를 적습니다.
   • “서비스 B 큐 깊이(queue depth) > X에 대한 신규 알림 추가.”
   • “쓰기 실패(write failure) 스파이크 관련해 데이터 팀에 문의.”

타이머가 울리면 그걸로 끝입니다. 토끼굴에 빠져들지 않습니다.

선제적 네트워크/시스템 관리: 머리카락 굵기의 균열 찾기

랜턴 의식의 핵심 목적은 서서히 망가지는 컴포넌트를 전면적인 장애가 되기 전에 잡아내는 것입니다.

이미 모니터링 시스템은 이런 것들을 보고 있습니다.

• 중요 경로에서 천천히 증가하는 레이턴시(latency)
• 자동 재시도로 사용자가 바로 느끼지는 못하지만 점진적으로 오르는 에러율(error rate)
• 조금씩 올라가는 리소스 사용량 (CPU, 메모리, 디스크, 커넥션 풀 등)
• 네트워크 이상 징후 (패킷 손실, 지터(jitter), 라우팅 플랩 등)

하지만 바쁜 하루 속에서는 “조금 나빠진 상태”를 “아직은 괜찮다”로 치부하기 쉽습니다. 매일 하는 랜턴 점검은 이렇게 말합니다. 오늘 밤에는 “조금 나빠진 것”만을 의도적으로 들여다본다.

선제적 네트워크 및 시스템 리뷰를 도와줄 질문들은 다음과 같습니다.

• 지난 며칠, 몇 주에 걸쳐 지속적으로 나쁜 쪽으로 추세를 보이는(metric이 기울어진) 지표는 무엇인가?
• 평균은 괜찮아 보이지만 변동성(variability)이 커지고 있는 곳은 어디인가?
• 항상 특정 캐퍼시티 임계값 근처에서 놀고 있는 컴포넌트는 없는가?
• 반복적으로 발생하지만 페이징 임계치 직전에서 멈추는 **‘소프트 알림(soft alert)’**은 없는가?

이 질문들을 종이 노트에 매일 기록해 나가면, 이런 식의 내러티브가 쌓입니다.

“월요일에는 가벼운 백로그였는데, 목요일에는 캐퍼시티의 90%까지 치솟았다.”

이렇게 며칠에 걸쳐 종이 위에 쌓인 이야기 하나가, 시끄러운 그래프 한 장보다 훨씬 설득력이 있습니다.

리스크 관리 더하기: ‘내일의 고통’을 수치로 느껴 보기

“뭔가 이상한데…”라는 느낌을 실제 액션으로 연결하려면, 랜턴 의식에 간단한 리스크 관리 기법을 통합하는 것이 좋습니다.

복잡한 보험 수리 모델급의 엄밀함은 필요 없습니다. 가벼운 접근으로 충분합니다.

1. 각 리스크를 ‘영향도’와 ‘발생 가능성’으로 평가하기

각 우려 사항마다 페이지에 작은 표를 그립니다.

• 영향도(Impact, 1–5): “작은 잡음 수준”부터 “대형 장애 / 금전적·평판적 타격”까지
• 발생 가능성(Likelihood, 1–5): “매우 낮음”부터 “그냥 두면 거의 확실히 발생”까지

두 값을 곱해서 대략적인 리스크 점수를 만듭니다. 예를 들어,

• 업무 시간 중 메인 API를 다운시킬 수도 있는 메모리 누수:
  • 영향도: 5
  • 발생 가능성: 3
  • 점수: 15 → 빠른 시일 내에 다룰 가치가 충분한 리스크.

2. 시간 지평(Time Horizon)을 같이 적기

각 리스크 옆에 다음 중 하나를 적습니다.

• 시간 지평: 몇 시간, 며칠, 몇 주

위험도는 중간 정도지만 몇 시간 안에 터질 것 같은 이슈는, 점수는 더 높아도 몇 달 뒤에나 영향을 줄 이슈보다 우선순위가 높을 수 있습니다.

3. 소수의 예방 조치만 선택하기

목표는 모든 문제를 다 해결하는 것이 아닙니다. 다음을 하는 것입니다.

• 가장 점수가 높은 리스크를 식별하고
• 내일 작업 큐에 넣을 예방 조치 1–3개만 고르는 것

예시:

• 점진적 성능 저하를 더 일찍 감지하기 위한 신규 알림 임계값 추가
• 임계치 근처에 상시 머무는 컴포넌트에 대한 캐퍼시티 리뷰 일정 잡기
• 취약한 디펜던시를 리팩터링하는 티켓 생성
• 런북에 수동 우회(manual workaround) 절차 기록

몇 주만 꾸준히 이런 소규모 리스크 정리를 해도, 갑작스러운 장애의 빈도는 크게 줄어듭니다.

사람을 태우지 않고(On-call Burnout 방지) 온콜을 지원하기

밤마다 하는 랜턴 리뷰는 구조화된 온콜 전략과 궁합이 좋습니다. 순전히 “영웅적인 소방수식 대응”에만 의존하는 대신, 다음을 할 수 있습니다.

• 충분히 트레이닝된 인원 사이에서 온콜을 공정하게 로테이션하고
• 온콜 응답자가 압박 속에서 즉흥적으로 대응하지 않도록 명확한 런북을 유지하며
• 랜턴 의식을 통해 이 시스템들을 지속적으로 개선할 수 있습니다.

통합 방법 몇 가지:

1. 모든 Walkthrough에 온콜 스냅샷 포함하기

   • 지금 온콜 담당자는 누구인가?
   • 그들이 미리 알아야 할 핫스팟(hot spot)은 무엇인가?
   • 이번 주에 식별한 리스크 중, 관련 런북이 없거나 오래된 것은 없는가?

2. 반복해서 등장하는 랜턴 관찰을 런북으로 승격시키기

   • 노트에 같은 패턴이 반복해서 등장한다면, 이를 공식화합니다.
     • 예: “지표 X가 Y 이상으로 Z일 이상 추세를 보이면, A → B → C 순서로 대응한다.”

3. 레트로(retro)와 온콜 핸드오프에 랜턴 노트 활용하기

   • 온콜 핸드오프 시, 노트북(또는 스캔본)을 같이 전달합니다.
     • “지금 내가 주시하고 있는 ‘서서히 타오르는(slow-burn)’ 리스크는 이거다.”
   • 인시던트 사후 회고(postmortem)에서, 실제 장애 타임라인을 과거 랜턴 노트와 비교합니다.
     • “3일 전부터 전조가 있었는데, 다음에는 더 일찍 대응하려면 무엇을 바꿔야 할까?”

이런 접근은 신뢰성을 습관으로 만들지, 아드레날린으로 버티는 스포츠로 만들지 않습니다. 그 결과, 시스템은 안정되고, 팀의 웰빙은 지켜집니다.

왜 이런 아날로그 의식이 의외로 마음을 편하게 하는가

여기에는 종종 간과되는 심리적인 요소가 있습니다.

• 촉각적 참여(펜, 종이, 페이지 넘김)는 주의를 지금 이 순간에 붙들어 둡니다.
• 예측 가능한 소리(같은 펜, 같은 노트, 같은 타이머 소리)는 “지금은 내가 통제할 수 있는 시간이다”라는 작은 감각적 의식을 만들어 줍니다.
• 눈에 보이는 진행 상황—몇 주에 걸쳐 차곡차곡 채워지는 페이지들—은 항상 불 끄기만 하고, 전혀 나아지지 않는 것 같은 느낌을 상쇄해 줍니다.

3시 새벽에 뛰어나가야 하는 패닉 상태의 인시던트가 아니라, 팀은 점점 이것을 조용하고, 성찰적이며, 거의 명상에 가까운 nightly 체크인으로 인식하게 됩니다.

이 감정적 ‘프레이밍 전환’은 강력합니다. 선제적 신뢰성 작업을 지속 가능하게 만들어 줍니다.

시작하기: 최소한의 구현으로 출발하기

인시던트 프로그램 전체를 다시 설계할 권한이 없어도 괜찮습니다. 이번 주에 아주 작게 시작할 수 있습니다.

1. 시간을 정합니다. (평일 하루 15–30분)
2. 원페이지 템플릿을 만듭니다. 점검한 서비스, 이상 징후, 리스크(영향도/발생 가능성), 내일의 액션 항목 정도만 있으면 됩니다.
3. 한 사람을 정해 일주일 동안 랜턴 담당을 맡기고, 이후에는 로테이션합니다.
4. 주간 신뢰성/온콜 리뷰 미팅 때 노트북을 같이 리뷰합니다.

한 달 뒤에 다음을 자문해 보세요.

• 예전보다 더 일찍 발견한 문제가 있었는가?
• 이 의식은 차분했는가, 아니면 스트레스를 더했는가?
• 템플릿이나 살펴보는 신호를 어떻게 다듬으면 좋을까?

그리고 다시 반복해서 개선합니다—천천히, 종이 위에서.

결론: 내일의 장애는 오늘도 신호를 보내고 있다

대부분의 장애는 갑자기 하늘에서 떨어지지 않습니다. 시스템은 비명을 지르기 전에 속삭입니다.

종이부터 시작하는 인시던트 신호 랜턴은 그 속삭임을 들을 수 있도록 공간을 만드는 일입니다. 매일 밤, 아날로그 방식으로, 손으로 직접 작성하는 walkthrough를 통해:

• 엔지니어의 속도를 일부러 늦추어 더 선명하게 생각하게 만들고
• 단순한 도구와 차분한 의식을 통해 주의를 집중시키며
• 서서히 악화되는 컴포넌트를 장애 전에 표면 위로 끌어 올리고
• 가벼운 리스크 관리 기법으로 예방 작업의 우선순위를 정하고
• 번아웃을 줄이면서 온콜 운영을 강화합니다.

고속 자동화가 당연해진 시대에, 펜을 들고 조용히 이런 질문을 던지는 일은 어쩌면 꽤나 급진적인 행동입니다.

“오늘 밤, 내 시스템은 나에게 무엇을 말해 주려고 할까?”

내일의 장애를 오늘 찾고 싶다면, 우선 종이 위에 작은 랜턴 하나를 매일같이 켜는 것부터 시작하면 됩니다.