FBI Sentinel 9·11 25년 조직 혁신 교훈

9·11 이후 FBI가 얻은 핵심 교훈은 도구보다 업무 구조를 먼저 바꿔야 한다는 점이다. 흩어진 정보와 늦은 검증은 VCF 실패로 이어졌고, Sentinel은 짧은 개발 주기와 현장 피드백을 도입한 뒤 2012년 전면 배포됐다.

이 글의 수치와 연표는 2004년 위원회 보고서와 2012~2014년 Sentinel 감독 기록을 기준으로 한다.

9·11 이전 FBI가 놓친 신호

FBI에는 공격 전에 검토할 만한 단서가 존재했다. 문제는 단서가 서로 다른 조직과 시스템에 흩어졌다는 점이다. 현장 정보가 본부 판단으로 이어지는 경로도 약했다. 약 3,000명이 숨진 2001년 공격은 이 단절을 드러냈다.

대표 사례는 피닉스 메모와 미니애폴리스 수사였다. 피닉스 요원은 2001년 7월 비행학교 동향을 보고했다. 미니애폴리스 요원들은 자카리아스 무사위의 소지품 수색을 추진했다. 두 정보는 공격 계획을 보여주는 통합 경보로 발전하지 못했다.

9·11 조사위원회는 정보 공유만 탓하지 않았다. 분석 역량과 관리 체계의 결함도 함께 지적했다. 아래 문장은 보고서 관련 대목을 옮긴 한국어 표현이다.

“FBI는 자신들이 이미 갖고 있는 정보도 제대로 알지 못했다.” — 『9/11 조사위원회 보고서』

이 사례를 단순한 데이터 부족으로 읽으면 핵심을 놓친다. 정보가 있어도 검색되지 않으면 활용할 수 없다. 책임자가 없으면 여러 단서를 연결하기도 어렵다. 반대 의견을 올릴 통로가 약하면 경고는 더 쉽게 사라진다.

×

분석가들이 디지털 업무 흐름의 병목과 개선 방안을 함께 검토하고 있다.

VCF와 Sentinel의 진행 연표

FBI의 전자 사건관리 전환은 두 사업을 거쳐 진행됐다. VCF는 실제 업무에 배포되지 못한 채 2005년 중단됐다. Sentinel도 초기 일정과 비용 관리에서 어려움을 겪었다. 그러나 2010년 재정비 뒤 2012년 전면 배포에 도달했다.

VCF에는 약 1억7,000만 달러가 투입됐다고 알려졌다. 다만 감사 문서마다 계약비와 관련 사업비의 범위가 다르다. 따라서 이 금액을 FBI 전체 현대화 비용으로 읽어서는 안 된다. VCF 자체가 사건관리 시스템으로 가동되지 못했다는 점은 분명하다.

Sentinel의 초기 사업 규모는 4억2,500만 달러였다. 사업은 여러 단계로 나뉘었지만 일정 지연이 누적됐다. 2010년에는 기존 계획으로 완수하기 어렵다는 판단이 나왔다. FBI는 범위를 다시 나누고 개발 통제를 내부로 가져왔다.

VCF와 재정비된 Sentinel 비교

두 사업의 차이는 소프트웨어 이름보다 검증 방식에 있었다. VCF에서는 완성된 결과를 늦게 확인하는 문제가 컸다. 재정비된 Sentinel은 작동 가능한 단위를 자주 공개했다. 현장 사용자의 피드백도 다음 개발 주기에 반영했다.

이를 애자일이라는 방법론 하나의 승리로만 보면 부족하다. FBI는 사업 범위와 지휘 체계도 함께 손봤다. 내부 기술 인력의 역할도 확대했다. 짧은 개발 주기는 이런 변화가 작동하는 수단이었다.

AI 도입 상황별 정리

AI를 적용할 위치에 따라 먼저 고칠 업무가 달라진다. 문서 검색에는 메타데이터와 접근권한이 필요하다. 의사결정 지원에는 근거와 승인 절차가 필요하다. 자동화에는 예외 상황을 처리할 담당자가 필요하다.

먼저 한 업무를 시작점부터 끝까지 그려야 한다. 그다음 대기 시간과 중복 입력을 표시한다. AI는 병목이 확인된 지점에 제한적으로 적용한다. 결과는 정확도뿐 아니라 수정 비용까지 측정해야 한다.

AI 시대에 추가된 지식 구조 문제

생성형 AI는 흩어진 정보를 그럴듯하게 연결할 수 있다. 그러나 접근할 수 없는 문서는 연결하지 못한다. 낡은 문서가 많으면 오래된 답을 만들 수 있다. 서로 충돌하는 규정에는 자체적으로 책임을 질 수도 없다.

이 때문에 AI 시대의 지식 관리는 저장량으로 평가하기 어렵다. 문서마다 작성자와 적용 기간을 표시해야 한다. 폐기 여부와 승인 상태도 구분해야 한다. 답변에서 원문 근거를 다시 찾을 수 있어야 한다.

다음 항목은 모델 선정 전에 점검할 수 있다.

• 같은 주제의 규정이 여러 저장소에 중복돼 있는가
• 최신 문서와 폐기 문서를 구분할 수 있는가
• 민감정보에 역할별 접근권한이 적용되는가
• AI 답변의 근거 문서와 버전을 확인할 수 있는가
• 잘못된 답을 신고하고 수정할 담당자가 있는가
• 사람이 반드시 승인해야 하는 업무가 정의돼 있는가

이 관점은 과거 FBI 사례에 없던 새로운 위험도 보여준다. 과거에는 정보가 검색되지 않는 문제가 컸다. 이제는 잘못 연결된 정보가 빠르게 확산될 수 있다. 검색 가능성과 검증 가능성을 함께 설계해야 한다.

흔한 실수와 오해

첫째, 9·11을 단순한 정보 부족 사건으로 설명하면 안 된다. 여러 단서는 존재했지만 함께 분석되지 못했다. 조직 구조와 판단 절차도 결과에 영향을 줬다. 데이터 수집량만 늘려서는 같은 문제를 막기 어렵다.

둘째, VCF 실패를 워터폴 방식 하나로 환원하면 안 된다. 요구사항 관리와 계약 감독도 문제였다. 사용자 참여와 기술 통제 역시 충분하지 않았다. 개발 방식은 여러 원인 가운데 하나였다.

셋째, Sentinel이 애자일을 채택하자 자동으로 성공했다고 보면 안 된다. 사업 범위 재조정과 리더십 변화가 병행됐다. 내부 인력도 더 큰 책임을 맡았다. 방법론은 책임 구조를 대신하지 않는다.

넷째, 세계무역센터 붕괴를 확정적인 ‘14초’ 하나로 설명하면 부정확할 수 있다. 두 타워는 충돌과 붕괴 시점이 서로 달랐다. 붕괴 시간도 측정 기준에 따라 표현이 달라진다. 핵심 교훈과 무관한 단일 수치는 신중히 다뤄야 한다.

×

단절된 정보 구조에서 Sentinel의 소규모·신속 검증 체계로 전환한 과정을 설명한다.

조직에 적용하는 실행 순서

AI 도입은 작은 업무 단위에서 검증하는 편이 안전하다. 목표는 도구 사용률이 아니라 업무 성과로 정해야 한다. 실패를 조기에 발견할 중단 기준도 필요하다. 다음 순서는 한 개 업무를 시험할 때 쓸 수 있다.

1. 반복되거나 지연이 잦은 업무 하나를 고릅니다.
2. 입력 정보와 최종 승인자를 기록합니다.
3. 현재 처리 시간과 오류 유형을 측정합니다.
4. AI가 맡을 범위와 사람이 맡을 범위를 나눕니다.
5. 작은 사용자 집단에 먼저 배포합니다.
6. 오류와 수정 시간을 다음 주기에 반영합니다.
7. 기준을 충족한 경우에만 적용 범위를 넓힙니다.

성과 지표는 사용 횟수만으로 정하지 마세요. 처리 시간과 재작업량을 함께 보세요. 중대한 오류가 얼마나 빨리 발견됐는지도 확인하세요. 현장 피드백이 실제 변경으로 이어졌는지도 기록해야 합니다.

FBI 사례가 남긴 조직 질문

이 사례는 AI가 조직의 기존 습관을 증폭할 수 있음을 보여준다. 정보가 고립된 조직에서는 AI도 불완전한 맥락을 받는다. 승인 단계가 불분명하면 빠른 생성이 재작업을 늘린다. 검증을 미루면 오류 역시 대규모로 쌓인다.

조직은 세 가지 질문부터 답할 수 있다.

• 필요한 정보를 누가 보유하고 있는가
• 서로 다른 신호를 연결할 책임자는 누구인가
• 작은 실패를 언제 발견하고 멈출 수 있는가

FBI Sentinel 사례의 핵심은 특정 개발 방법을 복제하는 데 있지 않다. 불확실성을 작게 나누고 자주 확인하는 운영 원칙에 있다. AI 도구도 같은 통제 아래 놓여야 한다. 조직의 학습 속도가 도입 속도보다 앞서야 한다.