IoT/MSA · 팀 프로젝트

Smooth

IoT 및 실시간 스트리밍 기반 스마트 사고 예방 서비스

문자 발송이 실패했다고, 긴급 신고까지 사라져도 될까?

프로젝트
Smooth
기간
2025.07 ~ 2025.09
담당 역할
프로젝트 전체 기획 · Frontend · Backend · Data · Infra Pipeline

장애 상황에서의 처리

문자는 실패해도, 신고는 제대로 남아야 했습니다.

신고 저장과 SMS 발송을 분리해, 외부 문자 API가 실패해도 핵심 신고 기록이 사라지지 않도록 했습니다.

01 · 먼저 보존신고 데이터 저장

핵심 사고 기록을 먼저 저장합니다.

02 · 외부 호출SMS 발송

저장 성공 후 문자 알림을 보냅니다.

장애가 나면재시도 대기

신고 데이터는 롤백하지 않습니다.

문제 상황

SMS 장애가 신고 저장까지 실패시킬 수 있었습니다.

내가 바꾼 것

핵심 저장과 외부 알림의 완료 시점을 분리했습니다.

내가 맡은 기능

위험 감지부터 실시간 알림·신고 처리까지 맡았습니다.

  • WebSocket 프론트엔드
  • 119 신고 서비스 프론트엔드·백엔드
  • DynamoDB 백엔드
  • 사고 이력 조회 API 설계
  • 프로젝트 전체 기획
  • 인프라 파이프라인 구축

01 / 문제 정의

주행 중 갑작스러운 돌발 위험 및 몇 초 대응 지연에 따른 2차 사고

  • 01

    운전 중 급정거, 도로 장애물, 사고차량 등은 찰나의 순간에 발생하며 시야 확보 실패 시 대형 사고로 이어집니다.

  • 02

    위험 이벤트를 수집하고 분석해 주변 운전자에게 실시간으로 전달하는 전체 알림 구조가 필요했습니다.

  • 03

    사고 발생 시 119 긴급 신고 저장과 SMS 알림 발송 중 하나라도 실패할 경우 발생할 수 있는 데이터 손실 위험을 방지해야 했습니다.

속도보다 먼저, 무엇을 반드시 남길지 정했습니다.

02 / 내 결정

신고는 먼저 저장하고, SMS는 따로 다시 시도하기

판단 기준

신고 데이터 저장을 먼저 완료한 뒤 SMS를 호출했습니다. 발송 실패는 재시도 대상으로 남겨 문자 장애가 핵심 신고 기록을 롤백시키지 않게 했습니다.

간단 아키텍처

위험 감지와 주변 운전자 알림

  1. 01Carla주행 시뮬레이션 데이터
  2. 02IoT / Kinesis수집과 스트림 전달
  3. 03Flink위험 이벤트 분석
  4. 04Redis / STOMP여러 Pod의 알림 전달

긴급 신고 · 핵심 기록과 외부 알림을 분리

  1. 01신고 요청핵심 사고 정보
  2. 02신고 저장 완료DB 기록을 먼저 확정
  3. 03SMS 발송저장 성공 후 외부 API 호출
  4. 04재시도 대기실패 상태 기록 · 재발송

03 / 해결 과정

IoT 실시간 스트림 아키텍처 및 고가용성 긴급 사고 처리

  1. Carla 시뮬레이터 데이터를 AWS IoT Core로 수집 후 Kinesis Data Streams 및 Flink 분석 파이프라인으로 연결

  2. WebSocket (STOMP)과 Redis Pub/Sub을 결합하여 Auto Scaling 환경의 멀티 Pod에서도 안정적인 실시간 브로드캐스팅 구현

  3. 119 신고 저장과 SMS 문자 발송 트랜잭션을 상호 분리하고 Fallback 패턴을 적용하여 SMS 실패에 따른 신고 저장 롤백 방지

  4. 5개 독립 Microservice (MSA), API Gateway, EKS 클러스터 기반으로 확장 가능한 인프라 구축

구현 중 마주한 문제

119 신고 즉시성 및 실패 차단
발생한 상황

단일 트랜잭션 내에서 신고 저장과 문자가 묶여 있어 외부 SMS API 장애 발생 시 DB 신고 건까지 전량 롤백되는 위협 발견

바꾼 부분

트랜잭션을 독립 레이어로 분리하고, SMS 발송 실패 시 비동기 큐 대기 및 재시도 Fallback을 도입하여 SMS 실패가 핵심 신고 DB 저장을 롤백시키지 않도록 처리함

WebSocket 연결 끊김 복구
발생한 상황

토큰 만료 및 네트워크 무선 흔들림 시 소켓이 끊어진 후 연결이 복구되지 않는 문제 발생

바꾼 부분

재연결 횟수 지수 백오프(Exponential Backoff)와 토큰 갱신 시점을 분리한 복구 핸들러를 구성했습니다.

현재 결과

주행 데이터 스트림과 실시간 알림을 연결하고, SMS 장애가 발생해도 신고 기록은 남고 발송만 재시도되도록 처리 경계를 분리했습니다.

04 / 회고

이 선택을 돌아보며.

실시간 서비스는 정상 상황의 속도뿐 아니라, 외부 의존성이 실패했을 때 무엇을 남길 수 있는지까지 설계해야 합니다.

다음으로 검증할 질문

현재 설계를 바탕으로 더 확인해야 할 항목입니다.

  • SMS 장애 주입 시 신고 저장과 재시도 확인
  • 재연결·토큰 만료·중복 이벤트 시나리오
  • 멀티 Pod 환경의 알림 전달 지연 측정