FireNavi 문제 재정의서
고객이 말한 "대피 안내 앱"을 그대로 만들지 않는다. FDE의 첫 임무는 표면 요구 뒤에 숨은 진짜 문제를 찾아, AI가 실제로 해결해야 할 구조로 다시 정의하는 것이다.
시나리오. 수천 명이 모인 대형 복합시설·공연장에서 화재가 발생했다. FireNavi는 대피자·군중 흐름·출구 수용력·위험구역·관리자 판단을 하나로 연결해, 모두가 안전하게 분산 대피하도록 실시간 의사결정을 지원하는 AI 시스템이다.
1고객의 표면 요구
현장 담당자(시설 안전관리팀)는 처음에 이렇게 요청했다. 대부분의 프로젝트는 이 한 문장에서 시작된다.
"화재나 재난이 발생했을 때 사람들이 가까운 출구로 빠르게 대피할 수 있도록 안내하는 앱이 필요합니다."
표면 요구에 담긴 기능 요청
이 문장을 그대로 분해하면, 고객은 아래 6가지 "기능"을 원한다고 읽힌다. 이것이 표면 요구(Surface Request)다.
🧭 대피 경로 안내
현재 위치에서 목적지까지 이동 경로 제시
🚪 가까운 출구 표시
최단 거리 출구를 우선 노출
🚨 화재 발생 알림
발화·경보 상황을 즉시 통지
🟢 비상구 위치 안내
비상구·계단 위치 지도 표시
📱 대피자용 모바일 앱
개별 사용자가 손에 들고 보는 화면
🖥️ 관리자용 관제 화면
상황실에서 전체를 모니터링
2FDE 관점의 진짜 문제
그러나 실제 대피 현장에서 사람이 다치는 이유는 "출구를 몰라서"만이 아니다. 사람들은 가장 가까운 출구보다 익숙한 길, 많은 사람이 이동하는 방향, 눈에 잘 보이는 통로를 따라 움직인다.
그 결과 특정 출구·계단에 군중이 집중되어 병목이 발생하고, 정작 여유 있는 출구는 비어 있다. 관리자·안전요원은 "어느 구역에 먼저 개입할지"를 즉시 판단하기 어렵다. 즉, 문제의 본질은 경로 안내가 아니라 흐름의 불균형이다.
숨어 있던 구조적 문제 8가지
표면 요구 아래에는 다음과 같은 구조적 문제가 얽혀 있다. 이것이 FireNavi가 실제로 다뤄야 할 대상이다.
3문제 재정의 문장
위 분석을 하나의 문장으로 응축한다. 이 문장이 이후 모든 설계·개발·평가의 기준선이 된다.
재정의된 문제가 연결하는 요소
4핵심 AX 과제 (A → B 전환)
문제 재정의는 곧 "무엇을 어떻게 바꿀 것인가"로 이어진다. FireNavi의 AX(AI Transformation) 과제는 기존 방식(A)을 AI가 개입하는 새로운 방식(B)으로 전환하는 5개의 축으로 정리된다.
| # | AS-IS (기존 방식) | TO-BE (AX 방식) | 전환의 의미 |
|---|---|---|---|
| 1 | 출구 안내 중심 | 군중 분산 중심 | 최단 경로가 아니라 전체 흐름의 균형을 최적화 |
| 2 | 정적 지도 안내 | 실시간 상황 판단 구조 | 연기·혼잡도 변화에 따라 경로를 동적으로 재계산 |
| 3 | 개별 대피자 안내 | 관리자·안전요원 협업 구조 | 대피자·관제·현장 인력을 하나의 판단 루프로 연결 |
| 4 | 대피 완료 여부만 확인 | 대피 과정 KPI 관리 | 결과가 아닌 과정을 지표로 측정하고 개입 |
| 5 | 사후 보고서 작성 | 훈련·운영 데이터 자산화 | 매 상황을 학습 데이터로 축적해 시스템을 개선 |
5성공 기준 후보 (KPI)
재정의된 문제가 "해결됐다"고 말하려면 무엇을 측정해야 하는가? 아래 7개 KPI 후보는 다음 단계에서 목표 수치를 확정하기 위한 출발점이다. (숫자는 방향성 예시)
이 문제 재정의서로 무엇이 달라지는가
- 고객의 "앱을 만들어 달라"는 요청을 "흐름의 불균형을 해결한다"는 문제로 바꿔 놓았다.
- 개발 범위가 화면(UI)에서 AI 실행 구조(감지→분석→판단→실행)로 확장됐다.
- 성공 여부를 감(感)이 아니라 측정 가능한 KPI로 판정할 근거를 마련했다.
- 다음 단계(5단계 암묵지 질문지)에서 현장 담당자에게 무엇을 물어야 하는지가 명확해졌다.