종이 사건 스토리 분기장 칠판: 망가지기 전에 손으로 그려보는 라이브 시스템

많은 훌륭한 사고(Postmortem) 보고서가 결국엔 화이트보드에 상자와 화살표를 그리는 장면으로 끝나는 데는 이유가 있습니다.

빠르게 전개되는 보안 사고 한가운데에서는 디지털 도구들이 너무 느리거나, 너무 경직되었거나, 너무 시끄러운 경우가 많습니다. 그래서 사람들이 손이 먼저 가는 것은 의외로 단순합니다. 마커, A4용지, 칠판 같은 것들입니다. 그 순간 팀은 기억만을 가지고 시스템을 다시 구성하면서, 실제로 무엇이 존재하는지, 어떻게 고장 나고 있는지를 이해하려고 합니다.

이것이 바로 **종이 사건 스토리 분기장 칠판(paper incident story trainyard chalkboard)**입니다. 스트레스를 받고 있는 라이브 시스템을 손으로 거칠게 그려낸 비공식 모델이죠.

진지하게 보안을 다루는 프로그램이 반드시 스스로에게 던져야 할 질문은 이겁니다. “왜 모든 게 불타고 있는 중에야 이걸 처음으로 그리고 있는가?”

이 글에서는 그 칠판을 “사고 이후”가 아니라 “사고 이전”으로 앞당기는 방법을 다룹니다. 손그림 시각화, 사회기술적(socio-technical) 모델링, 그리고 NIST CSF 2.0 같은 구조화된 프레임워크를 활용해, 사고가 터지기 전에 준비하는 접근입니다.

NIST CSF 2.0에서 워룸까지: 점들을 어떻게 이어 붙일 것인가

많은 조직이 사고 대응(Incident Response)을 전체 위험 관리와 분리된 별도의 플레이북으로 취급합니다. 하지만 NIST 사이버보안 프레임워크(CSF) 2.0은 애초에 사고 계획과 대응을 지속적인 위험 관리 사이클 안에 통합할 것을 명시적으로 권장합니다.

다시 말해, 사고 대응은 무언가가 망가지고 난 뒤에만 하는 일이 아닙니다. 전략적인 설계 활동이며, 따라서 아래를 이끌어야 합니다.

아키텍처 결정에 영향을 주고
통제(Control) 선택과 투자 방향을 정하며
모니터링·탐지 우선순위를 정의하고
교육 및 이해관계자 참여 방식을 설계해야 합니다.

사고 대응이 전체 사이버보안 위험 관리에 내재화되면 결과적으로:

사고 발생 건수를 줄입니다. 약점과 악용 경로를 미리 찾아내기 때문입니다.
사고의 영향도를 줄입니다. 현실적인 통제·커뮤니케이션·복구 시나리오를 리허설해 두었기 때문입니다.
사고 처리 효율이 올라갑니다. 위기 상황에서 처음 보는 시스템을 탐색하느라 시간을 낭비하지 않게 되기 때문입니다.

칠판 위 스케치는 단지 위기 속에서 남긴 기록물이 아니라, 위험 관리 프로그램 안에 상시 존재해야 하는 설계 아티팩트입니다.

사고가 엉망이 되는 이유: 빠져 있는 ‘그림’ 한 장

사고가 망가지는 이유는, 사람들이 관심이 없어서도, 도구가 없어서도 아닌 경우가 대부분입니다. 공통적인 실패 패턴은 대체로 이렇습니다.

시스템이 실제로 어떻게 동작하는지 최신의 정신적 모델을 가진 사람이 없다.
기본 사실을 두고 팀이 다툰다. “트래픽이 실제로 저 프록시를 지나가나요?”
수동 우회, 그림자 IT, 외주 운영 같은 핵심 인간 요소가 그림에서 완전히 빠져 있다.
플레이북은 더 이상 프로덕션에는 존재하지 않는 이상화된 아키텍처를 전제로 만들어져 있다.

여기에서 초기 단계 손그림 시각화가 빛을 발합니다.

정식 다이어그램 전에 먼저 ‘그려보는’ 힘

고급 모델링 도구를 켜기 전에, 시스템을 만들고 운영하고 여기에 의존하는 사람들을 모아 직접 시스템을 손으로 그려보게 하십시오.

데이터는 어디로 들어와서 어디로 나가는가?
그 과정에서 누가 데이터를 만지는가? (사람, 서비스, 벤더 등)
이 컴포넌트가 사라지면 무엇이 멈추는가?
누가 가장 먼저 이상을 알아챌 것이며, 어떻게 알아차리는가?

이 스케치는 일부러 엉성하고 지저분해야 합니다. 그 안에서 드러나는 것은:

정신적 모델의 불일치 (Dev vs. Ops vs. Security vs. Business)
“아직도 저 구 서버에서 돌고 있는 배치 잡이 있었네” 같은 숨겨진 의존성
우회, 수동 단계, 막판 통합 등 사회기술적 현실입니다.

손으로 그린 다이어그램은 복잡성을 다루는 마찰이 적은 도구가 됩니다. 모델링 툴을 다시 구성하는 것보다 지우고 다시 그리는 게 훨씬 빠릅니다. 그리고 스트레스가 높은 상황에서는 복잡한 것보다 단순한 게 곧 장점입니다.

사회기술적 보안 모델링: 상자와 방화벽만으로는 부족하다

보안 실패는 거의 결코 기술적 문제만으로 끝나지 않습니다. 항상 사회기술적(socio-technical) 요소가 섞여 있습니다.

기술(시스템, 프로토콜, API)
사람(관리자, 운영자, 사용자, 공격자)
조직(정책, 인센티브, 예산, 사일로)

현실적인 사고 대비 모델은 이 모든 것을 함께 포착해야 합니다.

실전에서의 사회기술적 모델링은 이렇게 보인다

사고 대응 계획을 위해 시스템을 칠판에 그릴 때, 다음 항목을 빠짐없이 포함해 보십시오.

기술 컴포넌트: 서버, 데이터베이스, 클라우드 서비스, ICS/SCADA 구성요소, 엔드포인트 등
데이터 플로우: 무엇이 어디로, 어떤 가정을 전제로 이동하는지
통제 포인트(Control points): 탐지·차단·격리·관찰이 가능한 지점
사람(휴먼 인 더 루프): 관리자, 운영자, 벤더, 사용자, 외부 대응 인력
조직적 제약: 결재 라인, 컴플라이언스 의무, SLA 등

칠판 위에서는 예를 들어 이런 식으로 나타납니다.

“관제센터 운영자”, “현장 기술자”, “SOC 분석가” 같은 이름이 적힌 막대기(스틱) 사람 그림
문제가 생겼을 때 누가 누구에게 전화를 하는지를 나타내는 점선
“여기서 수동 우회 가능”, “레거시 시스템 – 로그 없음”, “벤더 관리 – SLA 24시간” 같은 메모

이런 디테일이 중요한 이유는, 실제 사고 상황에서 우리가 던지는 질문이 단순히

“이 컴포넌트를 기술적으로 격리할 수 있는가?” 로 끝나지 않기 때문입니다.

동시에 이런 질문을 던지게 됩니다.

“그걸 할 권한이 있는 사람은 누구인가?”
“운영상 영향은 무엇인가?”
“누구에게, 어떤 순서로 통보해야 하는가?”

사회기술적 모델링은 이런 답들을 미리 방 안으로 가져다 놓습니다.

워크숍을 보안 도구로 쓰기: ‘올바른 사람들’과 함께 그리기

복잡한 시스템은 누구 한 사람의 시야만으로는 제대로 모델링할 수 없습니다. 다음과 같은 이해관계자들이 필요합니다.

핵심 인프라를 운영하는 사람들
레거시 시스템을 유지보수하는 팀
비즈니스 프로세스와 고객 커밋먼트를 책임지는 오너
서드파티·벤더 관계를 관리하는 담당자
탐지(Detection)와 대응(Response) 기능을 운영하는 팀

칠판이나 가상 화이트보드를 중심으로 하는 협업 워크숍은 다음을 이루는 데에 매우 효과적입니다.

실제로 어떻게 돌아가는지에 대한 공통 이해를 구축하고
숨겨진 리스크와 취약한 의존성을 드러내며
이 시스템에서 “사고”가 의미하는 바가 무엇인지 공통 정의를 만드는 것

단순하지만 강력한 워크숍 패턴

시나리오 프레이밍
합리적으로 있을 법한 사고를 하나 고릅니다. 랜섬웨어 확산, 내부자 오남용, 클라우드 자격 증명 탈취, OT 네트워크 침입 등.
시스템 스케치
참가자들에게 문서에 적힌 구조가 아니라, “현장에서 체감하는 그대로” 현재 시스템을 그리게 합니다. 여기에 다음을 추가합니다.
- 컴포넌트
- 데이터 흐름
- 사람이 개입되는 접점
- 외부 의존성
실패 탐색
질문을 던집니다. 이 시나리오는 어디에서 시작될 수 있을까? 어떻게 확산될까? 우리가 처음으로 보게 될 신호는 무엇일까?
대응 맵핑
구체적인 행동을 그림 위에 얹어 봅니다.
- 어디에서 조기 탐지가 가능한가?
- 어디에서 격리·차단할 수 있는가?
- 누가, 어떤 도구와 권한을 가지고 행동해야 하는가?
갭 분석과 개선안 도출
인사이트를 다음과 같은 것으로 정리합니다.
- 업데이트된 사고 대응 플레이북
- 모니터링·로그 수집 우선순위
- 아키텍처 또는 프로세스 변경 사항
- 교육 및 커뮤니케이션 필요 요소

이 다수 이해관계자 기반 모델링은 단순한 브레인스토밍이 아니라, NIST CSF 2.0의 Identify, Protect, Detect, Respond, Recover와 같은 카테고리에 직접 연결되는 위험 관리 인풋입니다.

다방법(멀티 메서드) 인사이트: 문헌, 모델링, 이해관계자

가장 탄탄한 조직은 한 가지 관점에만 의존하지 않습니다.

아래 세 가지를 섞어서 씁니다.

문헌과 표준
- 구조와 공용 언어를 위한 NIST CSF 2.0
- 중요 인프라, ICS, 헬스케어 등 업종별 가이드라인
시스템 모델링
- 손그림 스케치에서 더 정형화된 모델까지 확장
- 위협 모델링, 공격 경로 분석, 블라스트 레디우스(blast radius) 분석
이해관계자 인풋
- 워크숍, 인터뷰, 모의훈련(Tabletop Exercise)
- 과거 사고와 Near-miss(아슬아슬하게 빗나간 사고)에서의 교훈

이러한 다방법 접근법은 어떤 단일 기법보다 더 견고한 인사이트를 제공합니다. 그리고 다음과 같은 중요한 질문에 답할 수 있게 해 줍니다.

문서가 아닌 현실 세계에서 이 시스템은 어떻게 실패할 수 있는가?
우리는 어디에서 먼저 이상을 감지하고, 어디에는 완전히 눈이 멀어 있는가?
지금 무엇을 바꾸면, 나중에 실패가 일어나더라도 치명적이지 않게 만들 수 있을까?

이 프로세스가 지속적으로 돌아가면, 사고 대응 권고사항이 다시 아키텍처, 거버넌스, 운영에 피드백됩니다. 시간이 지날수록:

사고는 더 적게 일어나고,
일어나더라도 규모와 지속 시간이 줄어들며,
대응은 덜 혼란스럽고, 더 조율된 활동이 됩니다.

현실로 옮기기: 칠판 하나로 시작하라

시작부터 거대한 프로그램이 필요하지는 않습니다. 시스템 하나, 세션 하나면 충분합니다.

실행 가능한 출발용 플레이북은 이렇습니다.

핵심 시스템 하나를 고른다
멈추면 정말로 타격이 큰 것. 결제 파이프라인, 생산 OT 네트워크, 고객 포털 같은 것들.
핵심 이해관계자 6~10명을 모은다
운영, 보안, 비즈니스 오너, 벤더 담당자, 필요하다면 컴플라이언스나 법무까지.
90분짜리 칠판 세션을 진행한다
- 현재 시스템을 그린다.
- 현실적인 사고 시나리오 하나를 함께 walkthrough 한다.
- 페인포인트와 갭을 기록한다.
결과를 문서화한다
- 스케치를 정리한다(사진 + 디지털 리드로잉)
- 사고 대응 상의 갭을 요약한다.
- 구체적인 액션 3~5개를 만든다(새 로그 소스 추가, 런북 업데이트, 접근 권한 조정 등).
NIST CSF 정렬 위험 관리 프로세스에 반영한다
액션을 CSF 기능·카테고리에 매핑하고, 담당자를 지정해 진행 상황을 추적합니다.

이 과정을 다른 주요 시스템으로 반복하십시오. 시간이 지날수록, 여러분의 “종이 사건 스토리”는 사회기술적 모델의 살아 있는 포트폴리오가 되어, 설계·모니터링·대응 방식을 함께 형성하게 됩니다.

결론: 실제 화재 훈련까지 기다리지 마라

실제 사고가 터지면, 결국 당신도 화이트보드에 뭔가를 그리게 됩니다. 그때의 질문은 하나입니다. 그 그림이 처음 보는 시스템의 초상화인지, 아니면 의도적으로 만들어 두었던 모델을 다시 꺼내 보는 것인지입니다.

다음과 같은 방식으로:

사고 대응을 NIST CSF 2.0 기반 위험 관리에 통합하고
손그림 시각화로 초기부터 복잡성을 다루며
사람·프로세스·기술을 모두 담는 사회기술적 모델링을 도입하고
다양한 이해관계자가 함께하는 협업 워크숍을 운영하며
표준·모델링·현장 경험을 섞는 다방법 접근을 취한다면,

사고 대응은 패닉 상태에서의 방어적 반응이 아니라, 계획되고 리허설된 역량으로 바뀝니다.

종이 사건 스토리 분기장 칠판은 단지 워룸 한편에 남는 흔적이 아닙니다. 강력한 설계 도구입니다. 시스템이 망가지기 전에 이 도구를 활용하십시오. 언젠가 실패가 찾아오더라도, 여러분의 시스템과 사람들은 훨씬 더 탄탄하게 버틸 수 있을 것입니다.