다른게 많아서 글 적는게 늦어졌다.
그리고 수업에 맞게 주제를 변형하고 하다 보니 프로젝트도 많이 바꼈다.
기존 환승을 도와준다는 이름의 SmoothRide에서 -> 고령자, 외국인 등 디지털 소외 계층을 위한 출발 시간 추천 서비스인 TimeTOGO로 이름을 바꿨다.
기획
대상이 바뀐 대신, Customer obsession을 통해 노약자들 및 외국인들이 어떤 불편함을 가지고 있을지 확인해봤다. 조사 결과 고령자들은 앱 사용에 어려움을 많이 겪었으며, 외국인들은 해외에서는 많이 사용하던 구글 맵이 한국에서는 잘 통용되지 않아 어려움을 겪는다는 것을 알게 되었다.
이를 계기로, 기존 실시간 데이터 스트리밍을 통한 분산형 데이터 처리 등 기술적인 이슈에서 -> 사용자 친화적인 서비스로 변경되었다.
메인 기능
TimeTOGO의 메인 기능은 세가지다.
1. 도착 시간 기반 출발 시간 역산
- Google routes API를 통해 도착 시간, 출발지, 도착지를 입력해 결과를 받아온다. 사실 이 API가 있는지 몰랐는데, 찾아보니 있어서 당황했다. 결과도 깔끔하게 뽑아줘서 역산을 굳이 돌릴 필요가 없어진것 같아 당황스럽긴 하다. 하지만 찾아보니 한국에서는 길찾기 정확도가 좀 떨어지는 편이라고 해서 기존 ODSAY API를 통해 검증을 해야 될까 고민중이다.
- 지금 생각은 google route api 결과 -> odsay api로 대중교통 시간표 조회 및 google routes api 검증 -> 시간 보정해서 결과 도출. 여기에다가 사용자의 나이 등을 고려해서 시간 보정을 할 계획이다.
-
웹앱 방식
-고령자들이 가장 불편해 했던 것중 하나는 앱의 업데이트 등으로 인한 사용 불가이다. 링크로 공유는 대부분의 어플에서 지원하지만, 업데이트가 되는 경우 고령자들의 접근성이 떨어지는 경우가 많다. 이를 통해 우리는 링크 형태로 공유해, 열었을 때 바로 실행이 되는 것을 목표로 했다.
-
환승 알림 공유
-기존 앱들도 물론 노선을 선택할 시 알림을 줬지만, 단순히 이 버스가 곧 온다 등의 알림만 제공했다. 우리는 이를 더 발전시켜 정해진 시간 단위마다 버스의 실시간 위치를 조회해 버스의 도착 시간을 알려주는 것은 물론, 환승이 불가능할 것 같을 때 다음 예상 버스를 미리 알려주는 방식으로 진행하고자 한다.
아키텍처
다음과 같다. 쩝 처음에 고민했던 아키텍처에 비교했을 때 너무 단순해져서 걱정이다. 짜는데 ECS에서 스프링이랑 TimeScaleDB 컨테이너로 돌리는 등 여러 고민 많이 했었는데 결국 다 의미가 없는 것 같아서..
기본적으로 서버리스 구조로 짜보고자 했다. 왜냐면 자동 스케일링이 가능하다는 것도 있고, AWS SA 인턴을 지원해보고 싶은 입장에서 생각해봤다. AWS SA의 업무는 고객들의 요구사항 및 기능에 대한 AWS 상품 설명도 포함되어 있는데, 이 때 내가 많이, 많이는 아니더라도 주 기능들을 제대로 써봐야지 설명이 더 쉽고 자세하지 않을까라는 생각을 했다.
내가 만약 AWS를 사용하는 고객이라면, 기존 EC2를 통해 스왑 스페이스를 늘리고, 서버의 생존성을 걱정하기보다는 AWS가 자동으로 관리해주는 서버리스 아키텍처가 더 의미있을 것이라고 생각해 서버리스 구조로 짜봤다. 물론 이게 맞는지는 모르겠다 ㅎㅎ...
기존에 계획했던 Kinesis/Kafka 등을 이용, 부하 테스트가 다 날라가서 걱정이다. 이게 가장 쉬운 아키텍처긴 한데, 어필을 어케 할까 고민중이다. 더 기능을 추가할 때 넣어봐야 할지 고민중이다.
1️⃣ 사용자 경로 요청 및 출발 시각 역산
사용자는 앱에서 도착 시각과 목적지를 입력하여 요청을 보낸다.
이 요청은 API Gateway를 통해 AWS Lambda로 전달된다.
Lambda 함수는 다음 외부 데이터를 활용하여 출발 시각을 계산한다:
Google Routes API: 예상 소요 시간 계산
기상청 날씨 API: 출발 시간 기준 강수/기온 확인
(선택) ODSAY API: 버스/지하철 시간표를 통한 시간 예측 구체화
계산 결과로 추천 출발 시각, 예상 소요 시간, 날씨 행동 가이드를 생성한다.
생성된 결과는 사용자의 식별 정보(UUID 기반 링크 또는 로그인 정보)와 함께
PostgreSQL (RDS or Supabase)에 저장된다.
2️⃣ 환승 알림 예약 처리
사용자가 경로 요청을 보낸 경우, API Gateway → Lambda로 알림 요청이 전달된다.
Lambda는 다음 정보를 기반으로 알림 트리거 시각을 계산한다:
해당 환승 정류장 ID
환승 버스 도착 예정 시간
설정된 사전 알림 간격 (예: 5분 전)
Lambda는 AWS EventBridge Scheduler를 사용하여,
해당 시각에 실행될 푸시 전송 Lambda 트리거를 예약 등록한다.
동시에 사용자의 환승 알림 요청 내역은
PostgreSQL에 저장되어 추후 실패 시 재시도/로그 확인이 가능하도록 한다.
3️⃣ 푸시 알림 전송 흐름
예약된 시각이 되면 EventBridge Scheduler가 지정한 Lambda 함수를 실행한다.
Lambda는 ODsay API를 통해 해당 정류장에 버스가 접근 중인지 확인한다.
조건이 만족되면, Lambda는 Firebase Cloud Messaging (FCM)을 통해
사용자에게 푸시 알림을 전송한다.
만약 버스가 도착하지 않았거나 알림 조건이 만족되지 않으면,
Lambda는 EventBridge에 3분 후 재예약을 등록하여 최대 3회까지 재시도한다.
모든 알림 시도 및 결과는 PostgreSQL에 기록된다.
이거 말고도 뭐 이것저것 기능들이 있는데, 아키텍처적/백엔드적으로 더 어필할게 뭐가 있을지 고민된다.
그래도 진척이 있으니 다행이라고 해야하나
