대규모 행사 인파·안전 실시간 관제

Life-Line

"보이지 않는 위험을 데이터로 보고,
통신이 끊겨도 안전은 지킨다."

3VPC 분리 아키텍처
10초IoT 데이터 수집 주기
0%안전망 패킷 손실 목표
프로젝트 보기 ↓
NORMAL
정상 운영 중
"
이 프로젝트를 하게 된 이유

요즘은 자동화의 시대입니다. 재난 상황에서도 감정이 아닌 데이터로 판단하고 즉각 대응하는 인프라를 만들고 싶었습니다. AWS 서비스들을 조합해 사람의 개입 없이 자동으로 흐르는 구조를 설계하면서, 인프라 자체가 하나의 자동 대응 시스템이 될 수 있다는 것을 직접 증명하고 싶었습니다.

데이터 수집
→
위험 판단
→
정책 전환
→
알림 발송
담당 역할
🌐
네트워크 / 인프라
  • VPC 망 분리 설계
  • 접근 경로 · 보안 정책 구성
  • 서비스 간 연결 점검
🗄️
데이터 구조 설계
  • DynamoDB · RDS 스키마 설계
  • 수집 데이터 구조 정의
  • Redis 상태 관리 로직
⚡
QoS / Lambda 구현
  • QoS 정책 제어 로직 개발
  • WAF · ALB 자동 전환 Lambda
  • EventBridge 트리거 연동
✅
테스트 & 검증
  • 시나리오별 테스트 케이스 작성
  • 기능 검증 절차 정리
  • 재현 가능한 운영 흐름 정돈
프로젝트 배경 및 목적

이태원 참사가 남긴 질문,
기술로 답하다

⚡
문제 상황
  • 도심·축제·행사 등 인파 집중
  • 사고 발생 시 대형 인명 피해로 확산
→
🚫
기존 시스템 한계
  • CCTV 사각지대 존재
  • 실시간 데이터 부족
  • 네트워크 장애 시 대응 불가
  • 사고 "이후" 대응 중심
→
🎯
프로젝트 필요성
  • 위험 신호의 실시간 인지
  • 조기 경고 및 대응 구조 필요
Vision

"기술이 골든타임을 지키는
데이터 기반의 초안전 사회 실현"

Mission

"네트워크 생존 기술과 IoT 데이터를 결합하여,
어떠한 재난 상황에서도 중단되지 않는
지능형 관제 인프라 구축"

Value

"보이지 않는 위험을 데이터로 보고,
통신이 끊겨도 안전은 지킨다."

AWS 아키텍처

3-VPC 분리로 구현한
통신 생존성 아키텍처

재난·혼잡 상황에서도 관제 통신이 절대 끊기지 않도록, Field·Normal·Safety VPC를 완전 분리하고 자동 전환 파이프라인으로 연결했습니다.

Channel
mobile시민
모바일
IoTIoT 센서
CCTVCCTV
user현장요원
Internet
Field VPC 현장 데이터 수집
Public Subnet
NATNAT Gateway
Private Subnet
IoTIoT Device
Zone 1~4
CCTVCCTV
Zone 1~4
mobileField Staff
Mobile App
TGWTransit Gateway
HTTPS
Normal VPC 트래픽 흡수 · 수집
Public Subnet
WAFAWS WAF
ALBApp Load
Balancer
PythonPython
Collector
EC2Web Server
× 2
AutoScalingAuto Scaling
SQSAmazon SQS
Private
Safety VPC 분석 · 판단 · 알림
Private Subnet (분석)
LambdaLambda
SQS Consumer
IngestData Ingest
PandasAnalysis
Pandas
DashboardDashboard
Private Subnet (데이터)
DynamoDBDynamoDB
RDSRDS MySQL
ElastiCacheElastiCache
Valkey
🔒 VPN으로만 접근 (비상 경로)
자동화 · 모니터링 레이어 (VPC 공통)
CloudWatch
CloudWatch
ALB RequestCount
WAF Blocked 모니터링
→Alarm
EventBridge
EventBridge
룰 매칭
Lambda 트리거
→
Lambda
Lambda
check metrics
모드 확인
주기적 상태 판단
→
Lambda
Lambda
QoS 전환
WAF Rule 변경
ALB Listener 변경
→
Lambda
Lambda
Alert
Slack 알림
재난모드 전환 안내
→
Slack
Slack
현장요원·관제실
즉시 알림
운영 흐름도

상황별 자동 대응 파이프라인

NORMAL MODE

IoT/CCTV 가상 디바이스가 10초 주기로 메타데이터를 생성하고, Transit Gateway → Python Collector → SQS → Data Ingest 파이프라인을 통해 실시간 수집·분석합니다.

📡
IoT / CCTV
메타데이터 생성
(10초 주기)
Python
→
🔀
TGW → ALB
HTTPS 전송
WAF 검사
Transit Gateway
→
🐍
Python Collector
메타데이터 검증
공통 필드 보강
collector_ts, source
→
📨
SQS → Lambda
버퍼링
Consumer 처리
Amazon SQS
→
🔍
Data Ingest
스키마 검증
중복 제거
DynamoDB 저장
→
📊
Analysis
데이터 정규화
Risk Level 판단
Pandas → RDS
CONGESTION — 웹트래픽 폭주

CloudWatch ALB RequestCount 1분간 3,000건 이상, 5분 연속 → Alarm → EventBridge → Lambda(QoS 전환) → WAF·ALB 룰 변경 → Safety 모드

📱
트래픽 폭주
시민앱 동시 접속
SNS 업로드 폭증
→
📊
CloudWatch Alarm
RequestCount ≥ 3,000
5분 연속 충족
ALARM 상태
→
🔀
EventBridge
룰 매칭
Lambda 호출
→
⚡
Lambda QoS 전환
모드 확인
NORMAL → SAFETY
current_mode 체크
→
🛡
WAF · ALB 변경
/ops/ → VPN CIDR만
그외 403 응답
Rule 자동 적용
→
🔔
Slack 알림
"관제는 VPN으로
접속 바랍니다"
현장요원 VPN 접속
DISASTER — Risklevel 3 (DANGER)

Analysis(Pandas)에서 RDS의 risklevel = 3이 1분간 지속되면 check_metrics_lambda 트리거 → 동일한 QoS 전환 파이프라인 실행

📊
Analysis 감지
risklevel = 3
1분간 지속
RDS 트리거
→
λ
check_metrics
모드 확인
NORMAL이면 실행
중복 방지 체크
→
🔀
EventBridge
룰 매칭
QoS Lambda 호출
→
🛡
WAF · ALB 변경
/ops/ VPN 전용
ALB 403 응답
→
💾
DynamoDB 업데이트
mode: SAFETY
상태 저장
→
🔔
Slack 알림
"재난모드 전환
VPN으로 접속"
Client VPN 연결
RECOVERY — 재난모드 해제

risklevel 0~1이 5분간 지속되면 복원 시작. Redis로 지속시간 추적 + DynamoDB 중복 방지 플래그 → SAFETY → RECOVERY → NORMAL 순차 전환

SAFETY
재난 모드
VPN 전용 접근
→
risklevel 0~1
5분 지속
Redis 타이머 확인
RECOVERY
복원 중
WAF·ALB 규칙 해제
→
Lambda 성공
DynamoDB 업데이트
중복 처리 방지
NORMAL
정상 모드
일반 접근 허용
⚠ 설계 원칙

위험 상승은 즉시 반영, 위험 하락은 HOLD_SECONDS 유지 후에만 반영 — 오탐에 의한 반복 전환 방지

Redis 역할
  • level 지속시간 추적 (level_since_epoch)
  • Recovery 실행 이력 플래그
  • 중복 처리 방지
DynamoDB 역할
  • 현재 mode 상태 저장 (NORMAL/SAFETY/RECOVERY)
  • zone별 밀집도·위험 상태
  • 전환 전 항상 모드 확인
Analysis 처리 로직

10초 수집 → 60초 판단 →
자동 대응 트리거

Level 0
NORMAL
Action: 없음
Level 1
CAUTION
Action: Slack 알림
Level 2
WARNING
Action: Slack + QoS 준비
Level 3
DANGER
Action: QoS 전환 + Slack
데이터 수집 주기
10초 IoT/CCTV 원본 데이터 수집
60초 1분 단위 판단 주기 (10초 × 6)
3분 초기 상태 결과 확인 (3 판단 주기)
1분 이후 주기적 상태 확인
레벨별 지속 판단 기준
DANGER 1분 지속 → SAFETY 전환
WARNING 5분 지속 → 에스컬레이션
CAUTION 10분 지속 → 에스컬레이션
임계치 계산 파이프라인
raw IoT + CCTV 원본 데이터
minute 1분 집계값
3min 3분 이동 평균
final final_level 결정 → 대응 트리거
⚡ 핵심 설계 원칙: 위험 상승은 즉시 반영, 위험 하락은 HOLD_SECONDS 유지 후에만 반영 — 오탐에 의한 불필요한 전환 방지
성과 및 어려웠던 점

무엇을 구현하고 배웠나

01

선제적 위험 감지 체계 구현

군중 밀집도와 이동 흐름을 기반으로 사고 발생 이전 단계에서 위험 상황을 감지할 수 있는 구조를 구현함

02

자동화된 재난·혼잡 대응 흐름 구축

위험 상황 발생 시 분석 → 판단 → QoS 전환 → 알림까지 자동으로 수행되는 흐름을 구현함

03

운영 안정성을 고려한 아키텍처 설계

평시·위기·복원 상황을 고려한 단계적 상태 전환 로직 설계. SAFETY → RECOVERY → NORMAL 구조 구현

04

확장·재사용 가능한 구조 설계

군중 위험도 판단과 웹트래픽 폭주 감지 로직을 분리 설계. 서로 다른 트리거에 동일한 QoS 전환 로직 재사용 가능

어려웠던 점 & 해결
Point 1

실시간성과 안정성의 균형

어려웠던 점

실시간 판단 시 오탐 잦음 / 평균 기반 판단은 대응 지연

해결

10초 수집 + 60초/3분 윈도우 기반 연속 판정 구조 설계. 위험 상승 즉시 반영, 하락은 HOLD_SECONDS 후 반영

배운 점

실시간 시스템에서는 "빠름"도 중요하지만 "안정적인 판단"도 중요함

Point 2

운영 트래픽 보호

어려웠던 점

트래픽 폭주 시 관제 접근 자체가 불가능해질 위험

해결

WAF와 ALB Listener Rule로 /ops 경로 분리. VPN CIDR 기반 접근 제어로 관제 트래픽 우선 처리

배운 점

장애 상황에서는 기능보다 "운영 접근성"을 먼저 보장해야 함

Point 3

중복 처리 방지

어려웠던 점

EventBridge + Lambda 자동화에서 동일 이벤트 중복 실행 가능성

해결

DynamoDB에 mode 상태 저장. Redis last_trigger_epoch + 플래그로 중복 방지. 전환 전 항상 현재 모드 확인

배운 점

자동화일수록 idempotency 설계가 필수적임

Point 4

복원 시점 판단

어려웠던 점

위험이 잠시 내려갔다 다시 상승하는 경우 시스템 모드가 반복 변경

해결

SAFETY → RECOVERY → NORMAL 3단계 복원 설계. 위험 하락 후 일정 시간 유지 시에만 복원 트리거

배운 점

복원 로직은 전환 로직보다 더 보수적으로 설계해야 함

개선할 점
01
임계치 초과 후 알림 → 이미 혼잡 발생
↓
AI 시계열 예측 모델 도입 — 사후 대응에서 사전 예측으로
02
Raw Data 중앙 집중으로 병목 발생
↓
Vision AI를 카메라 자체에서 수행 — 엣지 컴퓨팅으로 네트워크 부하 감소
03
센서 사각·오류 시 현장 상황 반영 불가
↓
시민·요원 제보 기능 추가 — 양방향 소통 채널 구축
기대효과

Life-Line이 바꾸는 3가지

⏱

골든 타임의 획기적 확보

  • 위험 징후 즉시 포착
  • 사고 발생 이전 단계 감지로 골든 타임 확보
📊

데이터 기반 객관적 의사결정

  • 밀집도·이동속도 정량적 데이터 제공
  • 대응 지연 및 인적 오류 감소
🔒

운영 안정성 확보

  • 위기 상황에서도 관제 접근 보장 (VPN)
  • 단계적 복원으로 시스템 안정성 유지
기술 구성

플랫폼을 구성하는 기술 스택

네트워크
VPC
VPC
TGW
Transit Gateway
VPN
Client VPN
NAT
NAT Gateway
서비스 처리
WAF
AWS WAF
ALB
App Load Balancer
EC2
EC2
AutoScaling
Auto Scaling
Python
Python Collector
데이터 분석
SQS
Amazon SQS
Lambda
AWS Lambda
Python
Python
Pandas
Pandas
데이터 저장소
DynamoDB
DynamoDB
RDS
Amazon RDS (MySQL)
ElastiCache
ElastiCache (Valkey)
시각화 · 모니터링 · 자동화
FastAPI
FastAPI · Uvicorn
CloudWatch
CloudWatch
EventBridge
EventBridge
Lambda
Lambda (×3)
Slack
Slack
프로젝트 정보

1조 슈퍼소닉

5
인 팀 프로젝트
6주
개발 기간
AWS
클라우드 인프라
Python
주요 개발 언어