인공지능은 보안 및 운영 팀이 사고를 처리하는 방식을 바꾸었다. 이제 인공지능은 경보 분류, 운영 런북 검색, 조치 제안은 물론 사고 후 분석 작성에도 사용된다. 그러나 Tabletop Exercises라고 알려진 시뮬레이션 훈련은 여전히 주로 절차에 대한 사람들의 지식과 압박 속에서 의사 결정을 내리는 능력을 테스트하며, 사람과 정보 사이의 중개자가 된 지능형 시스템 자체는 테스트하지 않는 경우가 많다.
Webflow가 후원 콘텐츠로 게시한 이 글은 이것이 실무상의 공백을 만든다고 본다. 인공지능이 실제 대응 프로세스의 일부라면 테스트의 일부가 되어야 한다는 것이다. 이는 보안 팀뿐 아니라 장애 분류에 인공지능을 사용하는 사이트 신뢰성 팀, 에스컬레이션 안내를 인공지능에 의존하는 지원 팀, 액세스 요청 자동화에 인공지능을 사용하는 IT 운영에도 해당한다.
사람 테스트에서 전체 시스템 테스트로
기존의 시뮬레이션 훈련은 도구가 고정되어 있고 핵심 변수가 사람이라고 가정했다. 누가 경보를 받는가? 누가 의사 결정 권한을 갖는가? 팀은 충분히 신속하게 운영 런북을 따르는가? 그러나 인공지능 도구의 실패가 반드시 명확한 장애 형태로 나타나는 것은 아니다. 시스템은 자신 있게 잘못된 요약을 제공하거나, 키워드가 일치한다는 이유로 오래된 런북을 검색하거나, 논리적으로 보이지만 안전하지 않은 조치를 제안할 수 있다.
이러한 조용한 실패는 팀에 경고하는 오류 메시지를 표시하지 않은 채 대응을 늦추거나 팀을 잘못된 결정으로 이끌 수 있다. 따라서 이러한 상황을 포함하지 않는 훈련은 실제 사고 중 작동할 시스템의 일부만 테스트하는 셈이다.
훈련에 포함해야 할 상황
- 자신 있게 제시되는 오답: 근본 원인 식별이나 가깝지만 오래된 문서 검색에서 환각이 발생하는 상황을 시뮬레이션할 수 있다. 목표는 시스템이 실수하지 않을 것이라고 가정하는 것이 아니라, 대응 인력이 검증하고 답변을 사실로 취급하지 않는 능력을 테스트하는 것이다.
- 인공지능 시스템 장애: 조사에 사용되는 시스템을 이용할 수 없게 되거나 시스템 자체가 사고의 영향을 받는 경우에 어떤 일이 발생하는지, 그리고 팀이 여전히 분류를 수동으로 수행할 수 있는지를 테스트해야 한다.
- 압박 속에서 보호 장치 우회: 차분한 검토에서는 통제가 적절해 보일 수 있지만, 사고가 여러 시간 동안 지속되고 누군가 시스템에 인간의 승인을 위한 제안이 아니라 조치 자체를 실행하도록 요구할 때 무시될 수 있다.
- 수동 역량의 약화: 자동 검색에 장기간 의존하면 팀이 도움 없이 문서를 검색하고 단계를 수행하는 능력이 약해질 수 있다.
- 인계 지점의 모호성: 특히 자동화된 권고가 설득력 있지만 부분적으로 틀린 경우, 구성원들이 시스템의 역할이 끝나는 지점과 인간의 결정이 시작되는 지점을 명확히 알고 있는지 테스트해야 한다.
팀은 훈련을 어떻게 업데이트해야 하는가?
조직은 기존 프로그램을 폐기할 필요가 없으며, 인공지능 도구 자체를 대상으로 하는 계층을 추가하면 된다. 이러한 도구를 구축하고 운영하는 사람들도 참여시켜야 한다. 이들이 도구의 실패 패턴을 가장 잘 파악할 수 있기 때문이다. 또한 검토 세션은 “팀이 운영 런북을 따랐는가?”라는 질문에서 벗어나 다음 질문까지 다뤄야 한다. “팀은 시스템에 정확한 수준의 신뢰를 부여했는가?” 신뢰가 낮으면 도구의 이점을 낭비하지만, 신뢰가 지나치면 잘못된 답변이 사고 악화의 직접적인 원인이 될 수 있다.
이 글은 모델, 검색 소스, 보호 장치가 시간이 지나면서 변하기 때문에 한 번의 테스트만으로는 충분하지 않다고 강조한다. 따라서 대응에 영향을 미치는 시스템 구성 요소가 변경될 때마다 훈련을 반복해야 한다.
certi.news의 편집적 해석
여기서 실제 변화는 도구 목록에 인공지능을 추가하는 것이 아니라, 인공지능이 의사 결정 과정에서 영향력 있는 위치로 이동했다는 점이다. 이에 따라 사고 대응의 범위가 넓어진다. 팀은 구성원들의 준비 상태뿐 아니라 정보를 요약하고 다음 단계를 제안하는 중개자의 신뢰성도 테스트해야 한다. 다만 이 주장의 한계는 분명하다. 이 글은 이러한 훈련을 평가하기 위한 독립적인 측정 결과나 통일된 기준을 제시하지 않으며, Webflow의 경험에 근거하고 있다. 따라서 권고 사항은 일반적인 증명 자료가 아니라 조정 가능한 실무 프레임워크로 받아들여야 한다.
뉴스 출처
The New Stack - Software Development
원문 보기 ↗