아날로그 인시던트 스토리 카고 포트: 종이 도크야드로 온콜 업무를 진짜로 ‘하역’하기

현대 팀들은 수많은 대시보드 속에서 허우적대면서도, 정작 이런 기본적인 질문에는 답을 잘 못 합니다.

• 지금 누가, 무엇에 대해, 온콜을 맡고 있는가?
• 무엇이 진행 중인가? 무엇이 막혔는가?
• 다음으로 중요한 작업을 어디에 안전하게 ‘하역’할 수 있는가?

이 지점에서, 거의 잊혀진 아날로그 도구 하나가 조용히 판을 바꿀 수 있습니다. 바로 **T-카드(T-Card)**입니다.

인시던트 커맨드 시스템(ICS)에서 T-카드(ICS 219)는 리소스의 실시간 상태를 추적하는 데 쓰입니다. 누가 어디서, 무엇을, 어떤 상태로 하고 있는지를 보여주는 것이죠. 비상 상황용 물리적 칸반 카드라고 생각하면 됩니다. 이제 그 동일한 원리를 온콜·트리아지 업무에 가져와서, 들어오는 일이 실제로 ‘하역’되는 **종이 기반의 카고 포트(“cargo port”)**를 설계해 보세요. 일이 눈에 보이고, 예측 가능하며, 실제 용량에 맞게 처리되는 곳입니다.

이 글에서는 그 아날로그 도크야드를 어떻게 설계하는지, 디지털 도구와는 어떻게 보완 관계를 맺는지, 그리고 스프린트 플래닝 같은 현실적인 캐퍼시티 플래닝에 어떻게 연결하는지까지 살펴봅니다. 팀이 단순히 일을 “처리”하는 수준을 넘어, 일을 안전하게 처리할 수 있도록 돕기 위해서입니다.

디지털 세상에 웬 아날로그 도크야드인가?

처음 들으면 종이 시스템은 다소 구식이거나 후퇴처럼 느껴질 수 있습니다. 하지만 T-카드 같은 아날로그 도구는, 특히 압박이 큰 상황에서 분명한 장점이 있습니다.

1. 즉시 보이는 가시성
   중앙에 놓인 물리적 T-카드 랙은 곧 즉각적으로 한눈에 보이는 라이브 대시보드가 됩니다. 누가 바쁜지, 무엇이 막혔는지, 남은 여유 용량이 어디에 있는지 바로 보입니다.

2. 낮은 인지 부하
   로그인도, 메뉴도, 모달 창도 없습니다. 고압적인 인시던트나 트리아지 폭풍 한가운데서도, 카드를 2초 안에 옮길 수 있고, 그 변화는 모두에게 곧장 공유됩니다.

3. 디지털이 실패해도 버티는 복원력
   장애, 네트워크 문제, 툴 과부하가 와도 물리 보드는 그대로 작동합니다. 말 그대로 여러분의 ‘레이어 0’ 운영 뷰입니다.

4. 공유된 상황 인식(Situational Awareness)
   모두가 실제로 같은 보드 앞에 서 있으면, 일에 대한 공통의 정신 모델이 생깁니다. 이로 인해 핸드오프 마찰, 빠진 컨텍스트, 중복 작업이 줄어듭니다.

아날로그는 디지털을 대체하지 않습니다. 오히려 디지털을 앵커(anchor) 해 줍니다. T-카드 보드는 온콜·트리아지 모델의 물리적 프론트엔드에 가깝습니다.

T-카드 소개: 일을 담는 아날로그 컨테이너

ICS에서는 T-카드로 리소스(사람, 차량, 팀)와 그 상태를 추적합니다. 지식 노동 환경에서 우리의 “리소스”는 보통 사람이고, “카고(화물)”는 작업 단위입니다.

각 T-카드는 작은, 구조화된 스토리가 됩니다.

• 이 카드는 누구에 대한 것인가?

  • 개인: "온콜 엔지니어 – 백엔드"
  • 역할: "트리아지 리드", "인시던트 커맨더"
  • 워크스트림: "데이터베이스 트리아지 큐"

• 지금 무엇을 하고 있는가?

  • Free / Available (비어 있음 / 가용)
  • Busy / Handling incident (바쁨 / 인시던트 처리 중)
  • In handoff / Awaiting review (핸드오프 중 / 검토 대기)

• 어디에 있는가?

  • 온콜 보드
  • 에스컬레이션 랙
  • 복구 / 포스트 인시던트 영역

또한 개별 작업 단위(예: 인시던트, 지원 티켓, 트리아지 태스크)마다 별도의 T-카드를 만들어, 랙을 통해 시스템 안에서 어떻게 이동하는지 보여줄 수도 있습니다.

여기서 핵심 설계 선택지는, 카드가 주로 사람/리소스를 나타내게 할지, 아니면 작업/카고를 나타내게 할지입니다. “카고 포트” 메타포를 쓸 때는 보통 아래 구성이 가장 잘 맞습니다.

• 한 색상의 T-카드는 사람/역할용 (배/선박 역할)
• 다른 색상의 T-카드는 작업 아이템용 (컨테이너 역할)

이렇게 하면 벽 전체가 살아 있는 배가 입항·접안하고, 화물을 싣고 내리고, 출항하는 모델이 됩니다.

종이 도크야드 설계하기: 핵심 레이아웃

벽이나 화이트보드를 하나의 카고 포트 다이어그램으로 생각해 보세요. 즉시 답하고 싶은 두 가지 질문이 있습니다.

1. 지금 어디에 더 많은 작업을 안전하게 하역할 수 있는가?
2. 어떤 것들이 배(사람)가 항구를 떠나는 것을 막고 있는가?

여기 바로 시작할 수 있는 간단한 레이아웃이 있습니다.

1. 입항 구역(Arrival Bay): 들어오는 작업

새로운, 아직 트리아지되지 않은 모든 항목을 위한 컬럼입니다.

• 컬럼 예:

  • New / Untriaged (새로 도착 / 미트리아지)
  • Sifted / Needs owner (1차 분류 완료 / 담당자 필요)

• 카드: 작업 T-카드 전용

  • 주요 필드: ID, 유형(버그/인시던트/요청), 심각도, 접수 시각

여기는 원(raw) 인입 큐입니다. 한눈에 다음을 볼 수 있어야 합니다.

• 얼마나 많은 작업이 대기 중인지
• 각 항목이 얼마나 오랫동안 대기했는지

2. 도크사이드(Dockside): 온콜·트리아지 용량

여기는 온콜, 트리아지 담당자들이 T-카드 형태로 위치하는 곳입니다.

• 행(스윔레인): 각 역할별

  • 1차 온콜(Primary)
  • 2차 온콜(Secondary)
  • 트리아지 리드
  • 인시던트 커맨더(활성 시)

• 컬럼: 용량 상태

  • Available (가용 – 새 작업 가능)
  • At capacity (용량 꽉 참 – 더 이상 불가)
  • Overloaded (과부하 – 너무 많은 인시던트 처리 중)

각 사람의 T-카드를 현재 상태에 맞는 컬럼에 둡니다. Available에 있는 자리가 곧 카고를 하역할 수 있는 빈 도크입니다.

3. 작업 접안 구역(Work Berths): 활성 인시던트·태스크

이제 카고(작업) 자체를 위한 접안 구역을 만듭니다.

• 컬럼 예:
  • In triage (트리아지 중)
  • Under investigation (원인 분석 중)
  • Fix in progress (수정 작업 중)
  • Waiting on external team (외부 팀 대기)
  • Resolved / Monitoring (해결 / 모니터링 중)

각 작업 T-카드는 상황 변화에 따라 왼쪽에서 오른쪽으로 이동합니다. 필요하다면 각 작업 카드에 **‘배’ 카드(리소스 카드)**를 연결하세요.

• 현재 담당자의 리소스 T-카드를 해당 작업 카드 옆이나 아래에 붙입니다.
• 소유권이 바뀔 때마다, 리소스 카드를 새로운 작업 접안 구역으로 직접 옮기세요. 핸드오프가 물리적으로 드러납니다.

4. 출항 레인(Departure Lane): 완료 및 학습

작업이 진짜로 끝났다면, 활성 포트에서 나가야 합니다.

• 컬럼 예:
  • Completed this cycle (이번 사이클 내 완료)
  • Needs post-incident review (포스트 인시던트 리뷰 필요)
  • Documented / Lessons captured (문서화 / 교훈 정리 완료)

이렇게 하면 포트는 라이브 트래픽만을 위한 공간으로 유지되고, 여전히 학습·후속 조치가 필요한 작업도 표면 위로 올릴 수 있습니다.

온콜을 ‘제대로’ 작동시키기: 카고를 배와 매칭하기

온콜·트리아지 모델이 실패하는 경우는, 개념이 나빠서라기보다 로컬 현실 때문에인 경우가 많습니다.

• 같은 사람에게 너무 많은 상충하는 요구가 몰리는 경우
• 팀 간 핸드오프가 불분명한 경우
• 실제로 누가 사용 가능한지에 대한 공유된 뷰가 없는 경우

모델을 바꾸기 전에, 먼저 현장의 **장애물(Barriers)과 촉진 요인(Facilitators)**을 이해하는 데 시간을 쓰세요.

• Barriers(장애물):

  • 온콜 작업이 항상 프로젝트 작업에 의해 끊기는가?
  • 일부 팀이 트리아지 프로세스를 무시하고 ‘자기들이 좋아하는 엔지니어’에게 바로 가는가?
  • 리더십이 용량 한계를 인정하지 않은 채, 인시던트 때마다 ‘히어로 모드’를 기대하는가?

• Facilitators(촉진 요인):

  • 이미 자연스러운 “트리아지 허브”(예: 슬랙 도움 채널)가 있고, 이를 공식화할 수 있는가?
  • 보드를 함께 보는 데 쓸 수 있는 데일리 스탠드업, 운영 리뷰 문화가 있는가?

T-카드 보드를 사용해 이런 현실을 숨기지 말고 드러내세요. 예를 들어 보드에 다음이 반복해서 나타난다면:

• 특정 역할에 반복적으로 과부하가 걸리는 패턴
• 트리아지를 건너뛰고 직접 들어오는 작업
• 담당자 없이 쌓여가는 인시던트

…이제 프로세스를 개선하기 위한, 구체적이고 눈에 보이는 증거가 생긴 것입니다.

도크야드와 캐퍼시티 플래닝 연결하기

눈에 보이는 도크야드는 강력하지만, 이를 스프린트, 주 단위 계획, 온콜 로테이션 같은 정기적인 캐퍼시티 플래닝과 연결할 때 비로소 진가를 발휘합니다.

1. 단순한 캐퍼시티 모델부터 시작하기

각 온콜 기간 또는 스프린트마다 다음을 추정해 보세요.

• 팀의 총 가용 시간
  (예: 5명 × 집중 근무 30시간 = 150시간)

• 온콜·트리아지에 예약해 둘 용량
  (히스토리컬 데이터 기반: 예를 들어 주당 평균 인터럽트 30시간)

그러면 남는 시간은 프로젝트(계획된) 작업에 쓸 수 있는 시간입니다.

예시:

• 총 150시간
• 온콜·인터럽트 용 30시간 예약
• 스프린트 계획 작업에 120시간 사용 가능

이제 도크야드를 이용해, 이 가정이 실제와 맞는지 실시간으로 검증합니다.

2. 보드를 살아 있는 용량 계기판으로 쓰기

스프린트나 온콜 로테이션 기간 동안 다음을 추적합니다.

• 온콜 담당자가 Overloaded 컬럼에 있는 빈도는 어느 정도인가?
• Waiting on external team에 멈춰 있는 작업 카드는 얼마나 되는가?
• 사람들이 프로젝트 작업에서 끌려 나와, 예기치 못한 카고를 처리하는 시간이 얼마나 되는가?

몇 사이클을 거치면, 실제 상황과 초기 계획을 비교할 수 있습니다.

• 온콜 레인이 대부분의 날에 과부하였다면, 인터럽트 용량을 과소 추정한 것입니다.
• 반대로 온콜 쪽에 한가한 시간이 많이 보인다면, 용량을 너무 많이 과잉 예약했을 수 있습니다.

이런 촘촘한 피드백 루프 덕분에, **감(guess)**이 아니라 **증거(evidence)**를 바탕으로 캐퍼시티 숫자를 조정할 수 있습니다.

3. 시각적 증거를 계획 입력값으로 바꾸기

플래닝 세션에 물리적 보드를 그대로 가져오세요.

• 지난 주나 지난 스프린트 동안 보드 사진을 찍어 패턴을 보여줍니다.
• 각 레인을 통해 흘러간 작업 아이템 수를 셉니다.
• 배(사람)가 용량 한계나 과부하 상태였던 빈도를 기록합니다.

이 데이터를 사용해 다음과 같은 질문에 답합니다.

• 주당 실제로 필요한 온콜 시프트 수는 얼마인가?
• 피크 시간대에 전담 트리아지 역할이 필요한가?
• 다음 스프린트에서 인터럽트용 버퍼를 얼마나 잡아야 하는가?

많은 팀이 10–30% 정도의 명시적인 인터럽트 버퍼를 추가로 두기만 해도, 온콜이 훨씬 덜 혼란스럽게 느껴지면서도 프로젝트 속도는 충분히 유지된다는 것을 발견합니다.

실천 팁: 완벽함보다 ‘최소 기능 도크야드’부터

완벽한 설계로 시작할 필요는 없습니다. 목표는 **최소 기능 도크야드(MVD: Minimum Viable Dockyard)**입니다.

1. 기본 T-카드 랙을 사거나 만들어라
   없으면 인덱스 카드 + 마스킹 테이프, 화이트보드만으로도 충분합니다.

2. 사람·작업 각각 3–5개 정도의 단순한 상태 컬럼 정의
   나중에 언제든 개선할 수 있으니, 처음에는 단순하게 시작하세요.

3. 2–4주 동안 디지털 툴과 병행 운영
   티켓 시스템은 계속해서 ‘싱글 소스 오브 트루스(단일 진실 원천)’로 두고, 보드는 운영상의 프론트엔드로 사용합니다.

4. 매일 보드를 리뷰하라
   스탠드업이나 운영 리뷰에서 보드를 실제로 업데이트하고, 과부하, 흐름 상의 문제를 함께 봅니다.

5. 마찰을 기준으로 설계를 조정하라
   아무도 카드를 안 움직인다면, 설계가 너무 복잡한 겁니다. 최소한의 노력으로 현실을 반영할 수 있을 때까지 간소화하세요.

결론: ‘포트’가 아니라 ‘쌓임’이 되어선 안 된다

온콜과 트리아지의 목적은 가용성을 높이고, 희소한 전문성을 더 잘 활용하기 위한 것입니다. 그러나 현실에서는 종종 보이지 않고, 경계도 없는 스트레스의 흐름이 되어 버립니다.

단순한 아날로그 T-카드 도크야드는 팀에 다음을 제공합니다.

• 누가 무엇을 하고 있는지에 대한 공유된 실시간 그림
• 일이 입항하고, 접안하고, 처리되고, 출항하는 물리적 장소
• 캐퍼시티 플래닝과 온콜 설계를 개선하기 위한 구체적 데이터

다시 말해, 인시던트와 인터럽트가 해안에 난파선처럼 밀려들어 오는 것이 아니라, 실제로 하역되고, 흐르고, 떠나가는 스토리 카고 포트를 만드는 것입니다.

더 많은 대시보드를 추가할 필요는 없습니다. 필요한 것은 더 명확한 포트입니다. 종이부터 시작하세요. 일이 눈에 보이게 하세요. 그리고 거기서 배운 것을 바탕으로, 팀이 ‘버티는’ 수준이 아니라 지속 가능하게 운영할 수 있는 온콜 모델을 설계하세요.