연필 모드 장애 등대: 도구가 멈춘 밤을 헤쳐 나가는 손그림 비콘

Incident Bot이 죽고, 대시보드는 깜깜하고, CI는 멈춰 서 있고, 워룸 링크까지 끊겼다면, 그건 더 이상 현대적인 엔지니어링이라기보다는 폭풍 속에서 눈 감고 항해하는 기분에 가깝다. 레이더도, GPS도 없다. 그저 어딘가에 아직 보이지 않는 등대가 있기를 막연히 바랄 뿐이다.

툴 장애는 엔지니어링 세계의 달도 별도 없는 한밤 항해다. 속도를 늦추는 수준이 아니라, 평소에 얼마나 많은 걸 우리가 당연하게 여기고 있었는지—그리고 그게 멈추는 순간 어떤 일이 벌어지는지—여실히 드러나게 만든다.

이 글은 그 등대를 미리 그려 두는 방법에 관한 이야기다. 즉, “연필 모드(pencil-only)” 백업 관행과 손으로 그린 비콘을 통해, 익숙한 도구들이 모두 꺼졌을 때도 팀이 길을 잃지 않고 항해를 이어 가는 법이다.

대시보드가 깜깜해지는 순간

오늘날 엔지니어링 팀은 수많은 도구의 코쿤 속에서 일한다.

CI/CD 및 배포 플랫폼
Observability 스택(메트릭, 로그, 트레이스)
Incident Bot과 Slack 통합
티켓·워크플로 시스템(Jira, ServiceNow 등)
AI/에이전트 Copilot, 원격 터미널

이 중 하나가 멈추면 짜증 나는 정도다. 그런데 이 중 몇 개가 동시에 멈추면, 그때부터는 진짜로 눈 가리고 비행하게 된다.

장애를 고객이 먼저 발견하거나 한참 뒤에야 눈치챈다.
소유권과 에스컬레이션 경로가 모호해진다.
의사결정이 기록되지 않아, 같은 논쟁이 여러 번 반복된다.
리더십·고객 대상 상태 공유가 불일치하거나 아예 사라진다.

툴 장애는 불편함 이상의 것을 드러낸다. 우리의 프로세스가 “툴에 붙어 있는 클릭 절차”지, “단순하고 튼튼한 워크플로”가 아니라는 사실이다.

우리가 ‘프로세스’라고 믿고 있던 게 사실은 “그 SaaS에서 이 버튼 누르기”였다는 걸 그제야 깨닫게 된다.

취약함을 ‘사고’가 아니라 ‘특성’으로 보기

핵심 툴이 죽는 일은 어쩌다 한 번 있는 대형 사고처럼 느껴지지만, 실제로는 아니다. 충분히 복잡하고 서로 엮인 시스템에서는 통계적으로 피할 수 없는 이벤트다.

이런 장애가 진짜로 드러내는 건 다음과 같다.

의존성 블라인드 스폿
“핫픽스 배포 한 번”에 최소 다섯 개 이상의 서비스가 정상 동작해야 한다는 사실을 보통은 잘 모른다.
당연시된 자동화
로그는 검색 가능하고, 알람은 알아서 뜨고, 봇이 요약해 주고, 티켓은 자동 생성되고, 포스트모템 뼈대도 생성될 거라고 ‘당연히’ 여긴다. 그 모든 게 한꺼번에 안 될 때까지는.
프로세스의 속 빈 강정화(Process Hollowing)
시간이 지나면서 수동 워크플로는 근육처럼 퇴화한다. 런북은 문서상으로는 존재하지만, 실제로 그걸 마지막으로 따라 해 본 사람이 2년 전이다.

목표는 취약함을 없애는 것이 아니다. 완전한 무결함은 불가능하다. 목표는 취약함을 인정하고, 수동Fallback 레이어, 즉 고도화된 툴 스택이 무너졌을 때 꺼내 쓸 수 있는 얇지만 단단한 로우테크 안전망을 깔아 두는 것이다.

왜 “연필 모드(pencil-only)” 백업인가

“연필 모드”가 정말로 흑연과 종이만을 의미하는 건 아니다(물론 그럴 때도 있다). 여기서의 의미는 이렇다.

핵심 장애 대응·엔지니어링 워크플로를, 키보드·평문 텍스트·규율만으로도 실행할 수 있다.

연필 모드 백업을 이렇게 떠올려 보자.

대시보드 대신 텍스트 파일
봇 대신 체크리스트
자동 타임라인 대신 수동 로그
자동 갱신 상태 페이지 대신 사람이 말로 정리하는 상태 공유

이게 왜 중요한가?

회복력(Resilience): 장애 상황에서도 여전히 패치를 배포하고, 대응을 조율하고, 타임라인을 기록할 수 있다.
명료성(Clarity): “무엇을 해야 하는가”에 기반해 있고, “어떤 버튼을 눌러야 하는가”에 종속되지 않는다.
복원 가능성(Recoverability): 수동 기록이 잘 남아 있으면, 툴이 돌아온 뒤 사건 재구성이 훨씬 빨라진다.

연필 모드 워크플로는 자동 항법 시스템이 고장 났을 때 펼쳐 보는 손그림 항해도 같은 것이다.

전략 플레이북: 에이전트/터미널 장애 속에서 이끄는 법

AI 에이전트, 원격 터미널, 핵심 도구들이 죽었을 때 팀이 필요한 건 슈퍼 히어로가 아니다. 명확한 전략 플레이북이다. 리더는 몇 분 안에 이렇게 선언할 수 있어야 한다.

“지금부터 연필 모드로 전환합니다. 우리가 할 일은 다음과 같습니다.”

실용적인 장애 플레이북은 네 가지 질문에 답해야 한다.

1. 누가 책임자이고, 어떻게 소통할 것인가?

즉시 **인간 Incident Commander(IC, 장애 총괄)**를 지정한다.
백업 커뮤니케이션 채널에 우선순위를 매겨 둔다.
예: Slack → Zoom → 전화 브리지 → SMS/전화 트리
IC가 책임지는 단일 소스 오브 트루스(Single Source of Truth) 노트를 유지한다.
(공유 문서, 단순 텍스트 파일, 심지어는 한 명의 노트라도 좋다.)

2. 지금 무슨 일이 일어나는지 어떻게 추적할까?

Incident 관리 툴이나 봇이 없을 때는 이렇게 한다.

문서나 메모 앱에 실시간 타임라인을 적는다.
아주 단순한 테이블을 만든다.
- 시각(Time)
- 이벤트/관찰(Event/Observation)
- 담당자(Person)
- 결정/액션(Decision/Action)

이 수동 로그는 결국 다음의 기반이 된다.

상태 업데이트
교대/인수인계
사후 Incident 리뷰(Post-Incident Review)

3. 최소한 무엇은 반드시 지켜야 하는가?

“저하 모드(degraded mode)” 프로세스를 미리 명시해 둔다.

장애 중에도 반드시 지켜야 하는 것을 분명히 한다.
- 주요 의사결정은 반드시 기록
- 핵심 이해관계자(내부·외부) 통지
- 위험한 변경에 대한 가드레일(예: 스키마 변경은 반드시 Peer Review 필요)
그 외 **비핵심 단계는 IC가 명시적으로 ‘면제’**할 수 있도록 정한다.

4. 언제 평상시 모드로 복귀한다고 판단할까?

표준 도구 사용으로 복귀하기 위한 **Exit Criteria(복귀 기준)**를 사전에 정의해 둔다.
여기에 반드시 회고(레트로) 의무를 포함한다.
즉, 모든 툴 장애 Incident는 “연필 모드 실천에서 어떤 구멍이 있었는지”를 짧게라도 리뷰하도록 한다.

이게 바로 등대를 지키는 리더십이다. 바다를 통제하는 게 아니라, 빛을 유지하는 것이 리더의 일이다.

손으로 그린 비콘: 템플릿과 체크리스트

어둠 속에서 사람의 뇌가 가장 먼저 찾는 건 **구조(structure)**다. 그래서 준비된 템플릿과 사전 정의된 프로세스가 손으로 그린 비콘이 된다.

연필 모드에서 쓸 템플릿을 미리 만들어 두자.

1. Incident 로그 템플릿

Plain text 또는 간단한 문서 형태:

# Incident Log – [System] – [Date]

Commander: [Name]
Comms Channel: [e.g., Zoom link / Slack channel]

## Timeline
[HH:MM] [Person] [Event/Decision]
[HH:MM] [Person] [Action Taken]

## Observations & Hypotheses
- [ ] Hypothesis 1
- [ ] Hypothesis 2

## Actions
- [ ] Action 1 (Owner, ETA)
- [ ] Action 2 (Owner, ETA)

## Open Questions
- [ ] Question 1
- [ ] Question 2

2. 상태 업데이트 템플릿

Salesforce, ServiceNow, 이메일, Slack 업데이트, Zoom 노트 등 어디서든 쓸 수 있는 형태:

Subject: [Service] Incident – [Status: Investigating / Mitigating / Resolved]

Summary:
- Start time:
- Impact:
- Affected users/systems:

Current Status:
- What we know:
- What we’re doing:

Next Update:
- Time:
- Owner:

이게 준비되어 있으면, 어떤 툴이든 남아 있는 채널에서 누구나 명확한 업데이트를 바로 보낼 수 있다.

3. 수동 트리아지 체크리스트

한 페이지 안에 들어갈 정도로 단순한 체크리스트:

Incident 범위 확인(누가/무엇이 영향을 받는가?)
커뮤니케이션 채널과 IC 지정
타임라인 로그 시작
현재 상태 캡처(스크린샷, 에러 메시지, 시스템 시각)
롤백/안전 상태 옵션 파악
상태 템플릿으로 이해관계자 알림
고위험 변경은 반드시 기록
주요 의사결정의 이유를 간단히 기록

이 손으로 그린 비콘들은 도구를 대체하지 않는다. 대신 도구가 돌아올 때까지 길을 잃지 않게 안내한다.

커뮤니케이션은 항해 등화다

주요 시스템이 실패하더라도, 명확한 커뮤니케이션이 계속되는 한 배는 움직일 수 있다.

뭐든 남아 있는 툴—Salesforce, ServiceNow, Jira, Zoom 노트, 공유 문서—을 **항해 등화(navigation lights)**처럼 활용하자.

빨간 불(Red): 리스크와 영향 범위를 명확히 표기
녹색 불(Green): 현재 안전한 것/정상 동작 중인 것
흰색 불(White): 지금 하고 있는 일과 다음 업데이트 시점

실용적인 팁:

어떤 채널이든 고정된 상태 업데이트 리듬을 유지한다(예: 30분마다 한 번씩, 어떤 도구를 쓰든).
사용 가능한 여러 도구에 핵심 업데이트를 미러링한다.
예: Zoom 노트 + 내부 전체 메일 + Salesforce/ServiceNow 티켓의 간단한 메모.
다음 업데이트 책임자와 예정 시각을 매번 명시한다.

정보의 완벽함보다 중요한 건 리듬의 일관성이다. 사람들은 불확실성보다 침묵을 더 힘들어한다.

손전등 켜고 코드를 보는 법: 디버그·로깅 내재화

자동화된 도구가 모두 멈췄을 때—그럴듯한 대시보드도, AI 요약도, 고급 로그 쿼리도 안 될 때—남는 빛은 미리 코드에 심어 둔 것들뿐이다.

시스템을 설계할 때 이렇게 생각해야 한다.

로그는 그 자체로 의미가 있어야 한다
- 사람이 읽기 쉬운 메시지
- 명확한 Correlation ID
- “무엇을 하려다 실패했는지”까지 포함한 에러 컨텍스트
디버그 힌트를 코드 근처에 둔다
- 주석에 “이 부분이 프로덕션에서 실패하면 X, Y, Z를 확인할 것” 같은 안내를 적어 둔다.
- 관련 런북 링크를 코드나 커밋 메시지에 남겨 둔다.
Feature Flag와 Kill Switch는 찾기 쉽고 문서화되어야 한다
- 플래그·세이프티 스위치 목록을 평문 인덱스(문서/레포)로 유지한다.
- 각 플래그의 동작과 기본값을 기록해 둔다.
로컬 재현이 가능해야 한다
- 풀 툴체인 없이도, 노트북에서 최소한의 시나리오는 재현할 수 있게 해 둔다.

이건 코드베이스 안에 자체 손전등을 내장하는 일이다. 터미널 하나와 로그 파일 하나만 남았을 때도, **그걸로 상황을 볼 수 있는가?**를 기준으로 설계해야 한다.

진짜 밤이 오기 전에 연필 모드를 연습하라

폭풍 속에서 별을 보며 항해하는 법을 처음 배우는 건 무리다. 가장 좋은 팀들은 저하 모드 운영을 미리 연습한다.

가벼운 드릴 아이디어:

분기마다 한 번, **“봇·대시보드 없음”**을 가정한 Incident 시뮬레이션을 돌린다.
한 번쯤은 AI 에이전트와 원격 터미널이 모두 죽었다고 가정하고 연습해 본다.
온콜(On-call) 트레이닝 때, 연필 모드 체크리스트와 템플릿을 실제로 따라 해 본다.

각 드릴이 끝날 때마다 정리한다.

있었으면 좋았지만 없었던 정보는 무엇인가?
어떤 템플릿/체크리스트를 수정·보완해야 하는가?
우리가 과하게 의존하고 있는 툴은 무엇인가?

시간이 지나면 장애는 여전히 스트레스겠지만, 방향 감각을 잃게 만들지는 못할 것이다.

결론: 밤이 오기 전에 등대를 그려 두자

툴 장애는 앞으로도 계속 일어날 것이다. 시스템은 실패하고, 에이전트는 크래시 나고, 늘 믿고 의지하던 그 대시보드는 가장 안 좋을 타이밍에 빈 화면을 보여줄 것이다.

우리는 폭풍을 통제할 수 없다. 하지만 등대는 미리 그려 둘 수 있다.

연필 모드 백업: 텍스트만으로도 돌아가는 수동 로그, 체크리스트, 워크플로
명확한 리더십 플레이북: 누가 이끄는지, 어떻게 소통하는지, 저하 모드에서 반드시 지켜야 하는 최소 프로세스는 무엇인지
준비된 템플릿: 어디에든 복붙해서 쓸 수 있는 Incident 로그, 상태 업데이트, 트리아지 체크리스트
내재된 디버깅 관행: 고급 툴 없이도 프로덕션 문제를 비춰 줄 수 있는 로깅과 코드 힌트
교차 시스템 커뮤니케이션의 일관성: 남아 있는 어떤 플랫폼이든 활용해 모두가 같은 그림을 보게 만들기

다음 번 툴 장애의 밤이 찾아와도, 팀은 어둠 속에서 얼어붙어 있을 필요가 없다. 손으로 그린 비콘과 연필 모드 관행만 있다면, 여전히 항해하고, 결정하고, 전달할 수 있다.

모든 차트와 계기판을 잃을 수도 있다. 그래도 하나의 등대만큼은 남아 있을 것이다. 바로, 밤이 완전히 깔리기 전에 당신이 의도적으로 지어 올려 둔 그 등대다.