소개

큰 장애가 터졌을 때, 여러분을 구해주는 건 도구가 아니라 조율 능력입니다.

대시보드, 티켓 시스템, Slack, 상태 페이지 같은 도구들은 모두 중요합니다. 하지만 압박이 커지고 여러 팀이 한꺼번에 몰리면, 사람들은 똑같은 질문을 반복해서 던지기 시작합니다.

• 지금 무슨 일이 벌어지고 있나요?
• 그 결정은 누가, 언제 내린 거죠?
• 깨지기 직전에 무슨 변경이 있었나요?
• 지금 롤백 중인가요, 아니면 그대로 밀고 가는 건가요?

이 질문들에 누구도 자신 있게 답을 못 하면, 인시던트는 느려지고 리스크는 올라갑니다.

이럴 때 필요한 것이 바로 아날로그 인시던트 시그널 ‘등대’ 로그북입니다. 즉, 단일하고 중앙 집중된 시간 순서 기반 장부로, 종이나 하나의 공유 화면 위에 구현되는 경우가 많고, 장애 상황에서 커뮤니케이션, 의사결정, 기록 관리의 지휘본부 역할을 합니다.

이 글에서는 이 로그북을 시끄럽고, 여러 팀이 동시에 움직이며, 압박이 강한 상황에서도 실제로 잘 작동하도록 설계하는 방법과, 시간이 지나도 정확성과 신뢰성을 유지하는 방법을 다룹니다.

1. 로그를 부가기능이 아닌 ‘지휘본부’로 취급하라

많은 팀이 인시던트 로그를 ‘있으면 좋은 것’ 정도로 취급합니다. 누군가가 문서에 “메모를 좀 남기고” 그 밖의 “실제 작업”은 전부 다른 곳에서 이뤄지는 식이죠. 이건 완전히 반대입니다.

장애가 발생했을 때, 로그가 곧 지휘본부입니다. 다른 모든 정보는 이 로그로 흘러 들어와야 합니다.

핵심 원칙은 이겁니다.

로그에 없으면, 인시던트 관점에서는 일어나지 않은 일이다.

이 원칙은 아주 구체적인 결과를 만듭니다.

• 모든 결정은 로그를 통해 공표합니다.
  • 17:12 — 인시던트 커맨더: 서비스 X에 대한 모든 배포 중단; 릴리스 2024.03.05.1 롤백에 집중.
• 상태는 로그를 읽어서 파악합니다.
  • 늦게 들어온 사람도 최근 10–20개 항목만 훑어보면, 콜을 방해하지 않고도 상황을 따라잡을 수 있어야 합니다.
• 다음 액션도 로그를 통해 조율합니다.
  • 17:15 — 네트워크 온콜: 동부 리전 로드 밸런서 조사 중; 10분 내 상태 업데이트 예정.

로그를 이런 위치로 끌어올리면, 로그는 단순히 사후 분석용 기록이 아니라 **인시던트 상황에서의 단일 소스 오브 트루스(single source of truth)**가 됩니다.

2. 모든 액션과 업데이트를 시간 순으로 빠짐없이 기록하라

혼란스러운 상황에서 기억은 전혀 믿을 수 없습니다. 좋은 로그북은 일어나는 전체 스토리를 실시간으로 잡아냅니다.

• 무엇을 관찰했는지
• 어떤 결정을 내렸는지
• 무엇을 변경했는지
• 누가 했는지
• 언제 일어났는지

이 전체 체인이 있을 때 다음이 가능해집니다.

• 투명성 – 어떤 이유로 그 방향을 선택했는지 누구나 볼 수 있습니다.
• 책임 추적 – 탓을 하기 위함이 아니라, 당시의 의사결정 맥락을 이해하기 위함입니다.
• 신뢰할 수 있는 히스토리 – 사후 리뷰, 감사(audit), 교육 자료로 활용할 수 있습니다.

신호가 높고 최소한의 필드를 갖춘 로그 항목 템플릿은 이렇게 잡을 수 있습니다.

[시간] [역할 또는 이름] [액션 / 관찰] [시스템 / 범위] [레퍼런스]

예시:

• 16:03 — IC (Alex) — SEV-1 선언; SRE, DB, Network 페이지 발송 — 범위: 고객 로그인 실패
• 16:09 — DB (Priya) — 프라이머리 CPU 95% 관찰; 리플리케이션 큐 증가 중 — Ref: DB-Runbook-3.2
• 16:14 — SRE (Jamie) — API를 v2024.03.04.2로 롤백 — 변경 ID CHG-2719
• 16:20 — IC (Alex) — 고객 영향 감소 중; 오류율 15분간 < 1% 유지 시까지 SEV-1 유지

이 구조 덕분에 다음이 쉬워집니다.

• 타임라인 재구성
• 액션과 결과 간의 의존성 파악
• 관찰과 해석을 구분해서 보는 것

핵심 규칙은 단 하나입니다.

“조용한(silent) 액션”을 허용하지 말라. 프로덕션 변경, 의미 있는 테스트, 고객 커뮤니케이션은 모두 로그에 남겨야 합니다.

3. 시끄럽고 멀티 팀이며 고압적인 환경을 기준으로 디자인하라

조용한 사무실이라면 어떤 포맷이든 잘 돌아갑니다. 하지만 고스트레스, 다수 팀, 다수 채널이 동시에 떠들어대는 장애 상황에서는 빠르고 시각적으로 훑기 쉬운 디자인만 살아남습니다.

로그북을 아날로그 계기판이라고 생각해 보세요. 다음을 만족해야 합니다.

• 현재 상황을 보는 뷰는 한 페이지 또는 한 화면에 들어와야 합니다.
• 일관된 컬럼 구조를 쓰고, 자유로운 서술형 텍스트는 최소화합니다.
• 역할, 시간, 액션이 한눈에 들어와야 합니다.

실무에서 쓸 수 있는 레이아웃(종이든 디지털이든)은 다음과 같은 컬럼을 둘 수 있습니다.

1. 시간 (UTC) – HH:MM 혹은 HH:MM:SS처럼 포맷을 엄격히 통일
2. 역할 / 팀 – IC, Comms, SRE, DB, Network, Product 등
3. 액션 / 관찰 – 짧고, 명령형 또는 사실만 기술
4. 시스템 / 범위 – 서비스 이름, 리전, 고객 세그먼트 등
5. 레퍼런스 – 변경 ID, 티켓, 런북 ID, 그래프 링크 등

종이에 적었을 때 한 줄 예시는 다음과 같습니다.

디자인 팁:

• 축약어와 줄임말은 최소한으로 두고, 쓰더라도 작은 목록으로 문서화해 둡니다.
• 잘 읽히는 펜/폰트 크기를 쓰세요. 이 로그는 피곤한 상태에서 다시 읽게 될 겁니다.
• 완료된 액션과 계획된 액션을 분리하세요. (예: 별도 섹션을 두거나 PLANNED: vs DONE: 태그로 구분)

포맷을 다듬을 때마다 스스로에게 해야 할 질문은 하나입니다.

인시던트 시작 30분 뒤에 합류한 사람이, 이 로그만 읽고 90초 안에 상황을 이해할 수 있는가?

아니라면, 더 단순하게 만들 필요가 있습니다.

4. 절차는 ‘하나’, 출처도 ‘하나’만 둬라

빠르게 움직이는 인시던트에서, 여러 개의 ‘진실의 원본’이 존재하면 망설임과 충돌이 발생합니다.

• “위키에는 X라고 되어 있는데, 구글 문서는 Y라고 하네요.”
• “어떤 런북이 최신이죠?”
• “PagerDuty 노트를 따라야 하나요, Confluence 페이지를 봐야 하나요?”

로그북은 각 액션마다 단 하나의 권위 있는 절차만을 참조해야 합니다. 즉, 다음이 필요합니다.

• 모든 절차는 단일한 기준 위치와 단일 ID를 가집니다.
• 로그에는 그 ID만 참조합니다. 예: NET-RB-1.4, DB-RB-5.2.
• 다른 곳에 흩어진 옛 버전은 제거하거나, 명확히 폐기(deprecated) 표시를 합니다.

명확한 레퍼런스를 포함한 로그 예시는 이렇습니다.

• 18:02 — Network (Lee) — NET-RB-1.4 3번 단계에 따라 트래픽 시프트 적용 — 범위: EU → US 페일오버

만약 절차가 변경되었다면, 바뀌어야 하는 것은 그 절차의 ID 또는 버전이지, 의미 자체가 바뀌면 안 됩니다. 그렇지 않으면 과거 로그가, 지금은 다른 내용을 담고 있는 문서를 가리키게 되는 숨은 함정이 생깁니다.

채택해야 할 정책은 다음과 같습니다.

한 줄(또는 한 번의 클릭)로 표준 절차를 가리킬 수 없다면, 그건 표준 절차가 아닌 것이다.

5. 버전 관리와 분기(Quarterly) 리뷰

아무리 잘 만든 런북과 로그 포맷도, 돌보지 않으면 서서히 낡습니다.

인시던트 로그와 그 로그에서 참조하는 절차들을 정확하고 신뢰할 수 있게 유지하려면 다음을 수행해야 합니다.

1. 버전 관리 시스템(Git 등)을 사용해 다음을 관리합니다.

   • 런북과 절차 문서
   • 로그북 포맷 템플릿
   • 역할 설명과 체크리스트

2. 절차를 사용할 때는 항상 버전 식별자를 로그에 포함합니다.

   • 예: DB-RB-3.2 (런북 3, 버전 2)

3. 분기별 리뷰를 수행합니다.

   • 최근 인시던트 일부를 샘플링해 확인: 로그 포맷이 실제로 잘 작동했는가? 특정 필드가 무시되거나 엉뚱하게 사용되지는 않았는가?
   • 절차 노후화 점검: 로그에 반복적으로 등장하는 ‘임시 우회(workaround)’가 있는가? 그렇다면 정식 단계로 편입해야 할지 검토합니다.
   • 로그에서 참조된 모든 런북 ID가 실제로 존재하며, 내용도 여전히 일치하는지 확인합니다.

4. 개선은 반드시 실제 인시던트에 기반해 이뤄져야 합니다. 큰 장애가 끝난 후에는:

   • “포맷 마찰(format friction)”을 수집합니다. (예: “고객 커뮤니케이션 결정을 적을 공간이 애매했다.”)
   • 템플릿을 최소한의 범위에서 조정합니다.
   • 변경 사항과 간단한 이유를 버전 관리에 기록합니다.

런북과 로그 포맷을 모두 버전이 관리되는 아티팩트로 취급하면, 시스템은 감사(auditable) 가능해지고, 보이지 않게 조금씩 내용이 틀어지는 드리프트를 막을 수 있습니다.

6. 오너십을 명확히 하라

“모두의 것”인 것은 결국 아무도 책임지지 않는 것이 됩니다.

각 절차와 로그 포맷의 각 요소마다, 명확한 오너십을 지정해야 합니다.

• 런북 DB-RB-3.x → DB 팀, 주 책임자: @db-oncall-lead
• 네트워크 페일오버 절차 → Network 팀
• 인시던트 로그 템플릿 & 역할 정의 → SRE / 인시던트 매니지먼트 그룹

실제로는 다음과 같이 운영합니다.

• 각 문서 상단에 Owner(담당자), 마지막 리뷰 일자, 다음 리뷰 예정일을 명시합니다.
• 오너십에는 다음이 포함됩니다.
  • 내용의 기술적 정확성 유지
  • 아키텍처나 조직 구조가 바뀐 이후 현실과의 정합성 유지
  • 해당 절차가 사용된 인시던트의 사후 분석(postmortem)에 참여

명확한 오너십은 인시던트 진행 중에도 중요합니다. 로그 상단에는 현재 누가 어떤 역할을 맡고 있는지가 분명하게 나와 있어야 합니다. 예를 들면:

• Incident Commander: Alex R.
• Operations Lead: Jamie K.
• DB Lead: Priya V.
• Network Lead: Lee H.
• Comms Lead: Taylor S.

이렇게 하면, 누가 어떤 결정을 내릴 권한이 있는지에 대한 애매함이 사라집니다.

7. 인시던트 커맨드 시스템(ICS)에서 빌려오기

소방, 구조, 재난 대응 등 긴급 서비스 분야에서는 우리가 겪는 문제와 매우 비슷한 상황을 관리하기 위해 수십 년에 걸쳐 **인시던트 커맨드 시스템(Incident Command System, ICS)**을 다듬어 왔습니다.

• 빠르게 변화하는 상황
• 여러 도메인의 다양한 주체들
• 높은 stakes와 제한된 정보

전체 ICS를 그대로 가져올 필요는 없습니다. 다음과 같은 원칙만 로그북에 차용해도 큰 가치를 얻을 수 있습니다.

1. 단일 Incident Commander (IC)

   • 한 시점에 IC는 항상 한 명입니다.
   • 로그에는 **IC 인수인계(handoff)**를 분명히 기록합니다.
     • 19:00 — IC (Alex) — 근무 시간 제한으로 IC 역할을 Morgan에게 인계

2. 명확한 기능별 역할

   • IC, Operations, Comms, Liaison(고객/경영진 등 외부와의 창구), 그리고 도메인 리드(DB, Network 등)
   • 각 로그 항목에는 그 사람이 어떤 역할로 행동하고 있는지가 포함되어야 합니다.

3. 권한의 범위를 명시

   • 로그북(또는 그 첫 페이지)에는 다음이 정의되어야 합니다.
     • 누가 인시던트와 심각도(severity)를 선언할 수 있는가
     • 누가 고객에게 영향을 줄 수 있는 변경을 승인/실행할 수 있는가
     • 누가 대외 커뮤니케이션(상태 페이지, SNS, 경영진 브리핑 등)을 책임지는가

4. 운영 기간(Operational Period)과 명확한 목표

   • 장기화되는 인시던트라면, 시간을 블록으로 나누고 각 블록에 명시적인 목표를 둡니다.
     • 20:00–20:30 — 목표: 데이터 무결성을 유지하면서 로그인 성공률 90% 회복; 비필수 변경은 전면 동결.
   • 이런 목표는 전환 시점마다 로그에 남겨야, 모두가 지금 시점의 우선순위를 알 수 있습니다.

ICS 구조를 로그북에 가져오면, 로그는 수동적인 노트가 아니라 능동적인 조율 도구로 바뀝니다.

결론: 폭풍이 오기 전에 등대를 지어라

잘 설계된 인시던트 시그널 ‘등대’ 로그북은 얼핏 보면 그저 구조화된 노트 한 페이지처럼 보입니다. 하지만 시끄럽고, 압박이 크며, 여러 팀이 동시에 움직이는 장애 상황에서는, 이 로그북이 모든 사람을 한 방향으로 맞춰주는 단 하나의 아티팩트가 됩니다.

정리하면 다음과 같습니다.

• 로그를 지휘본부로 취급하고, 부수적인 것으로 여기지 마세요.
• 모든 액션과 업데이트를 구조화된 시간 순 항목으로 남기세요.
• 시끄러운 상황에서도 빠르게 훑고 이해할 수 있는 디자인을 목표로 하세요.
• 로그에서 참조하는 절차는 항상 단일한 권위 있는 출처를 가지게 하세요.
• 버전 관리와 분기별 리뷰로 전체 시스템을 최신이고 신뢰할 수 있게 유지하세요.
• 절차와 로그 포맷 모두에 대해 오너십을 명확히 하세요.
• ICS 스타일의 역할과 권한 구조를 차용해, 누가 무엇을 결정하는지 애매하지 않게 만드세요.

작게 시작해도 됩니다. 단 한 페이지짜리 템플릿을 만들고, 오너를 정하고, 다음 ‘작은’ 인시던트에서 직접 사용해 보세요. 실제 상황 몇 번을 거쳐 다듬다 보면, 이 로그북은 제 역할을 하게 됩니다. 바로 폭풍 속에서 모든 팀을 안전한 공동 해답으로 이끄는, 신뢰할 수 있는 등대가 되는 것입니다.