해커톤 시리즈 1/3 — SF Hacks 2026
세 번의 해커톤 경험을 정리하는 시리즈의 첫 번째 글입니다. 이번 편에서는 2026년 10월 2일, 샌프란시스코 주립대학교(SFSU)에서 진행한 SF Hacks x GDG AI Hackathon의 프로젝트와 협업 과정을 기록합니다.
하루 동안 4명이 함께 만든 프로젝트는 GatorAccess입니다. 제출명은 SFSU Gator Accessibility Navigation이며, Build with AI for Social Good 트랙에 제출했습니다. 저는 프로젝트 리드와 Firebase 연동을 맡았습니다.
행사장에 도착해 참가 등록을 하던 아침.
프로젝트 개요
GatorAccess는 SFSU 캠퍼스에서 이동 장벽을 확인하고, 문제를 신고하고, 필요한 지원으로 연결하는 웹 애플리케이션입니다. 서비스의 목적은 길 찾기 → 장벽 신고 → 지원 요청으로 정리할 수 있습니다.
휠체어 사용자나 목발을 짚는 학생에게는 짧은 길보다 실제로 통과할 수 있는 길이 중요합니다. 고장 난 엘리베이터나 막힌 경사로를 목적지에 도착해서야 알게 되는 상황을 줄이고, 발견한 장벽을 다른 사용자와 공유하는 것이 프로젝트의 출발점입니다.
| 항목 | 내용 |
|---|---|
| 행사 | SF Hacks x GDG AI Hackathon · SF Hacks 주최 |
| 진행일 | 2026년 10월 2일, 현지 날짜 기준 |
| 프로젝트 | SFSU Gator Accessibility Navigation · GatorAccess |
| 트랙 | Build with AI for Social Good |
| 팀 규모 | 4명 |
| 내 역할 | 프로젝트 리드, Firebase 연동 |
행사 페이지 · 프로젝트 제출 페이지 · GitHub 저장소 · 팀 시연 영상
팀 구성과 내가 맡은 부분
| 팀원 | 담당 역할 |
|---|---|
| Minjae Kim (나) | 프로젝트 리드, Firebase 연동 |
| Satyam Sharma | 백엔드 개발 |
| Peter Rubin | 프런트엔드 개발, Gemini 연동 |
| Omar Bahlool | 사이트 디자인, UI/UX 디자인 · SFSU 재학생 |
저는 프로젝트 리드로 참여하면서 Firebase 연동을 담당했습니다. 팀 전체가 만든 지도·AI 분석·신고 기능 중에서, 신고 결과가 데이터로 저장되고 다른 화면에서 활용되는 부분을 중심으로 프로젝트를 정리했습니다. 프런트엔드와 Gemini 연동은 Peter, 백엔드는 Satyam, 사이트와 사용 경험 설계는 Omar가 맡았습니다.
 |
 |
점심 무렵의 개발 화면과 제출 직전의 작업 모습. 지도와 AI 기능을 하나의 서비스로 연결하는 것이 팀의 과제였습니다.
1. 문제 정의 — 최단 경로와 이동 가능한 경로의 차이
일반적인 도보 길 안내만으로는 개별 사용자의 이동 조건을 충분히 설명하기 어렵습니다. 계단이 있는 입구, 고장 난 엘리베이터, 통행을 막는 장애물은 같은 경로에서도 사람마다 다른 제약이 됩니다.
장벽을 발견한 뒤 신고하는 과정에도 부담이 있습니다. 사용자가 시설 용어를 정확히 알거나, 긴 설명을 직접 작성해야 한다면 신고까지 이어지기 어렵습니다. GatorAccess는 사진으로 상황을 전달하고, AI가 정리한 초안을 사용자가 확인하는 방식으로 이 과정을 구성했습니다.
2. 구현 내용
캠퍼스 지도와 경로 안내
React 기반 화면에 Google Maps를 결합하고, 캠퍼스 건물과 접근성 관련 정보를 지도 위에 표시합니다. 출발지와 목적지를 선택하면 도보 경로를 요청하고, 경로 좌표를 선으로 그려 이동 방향을 보여줍니다.
경로 요청은 브라우저의 Google Maps 길찾기 기능을 먼저 사용하고, 실패하면 서버 API를 시도하는 구조입니다. 경로의 고도 상승량을 조회하는 코드도 포함되어 있으며, 조회 실패나 시간 초과 시에는 값을 알 수 없는 상태로 처리합니다.
도보 경로 조회와 휠체어 통행 가능 여부의 검증은 별개의 문제입니다. 우회 안내를 제공하더라도 실제 경사와 현장 상태를 확인할 필요가 있다는 점이 서비스 설계의 중요한 제약입니다.
팀 시연 영상 00:23 화면. 건물별 목적지 카드와 지도, Gemini 음성 도우미를 함께 보여줍니다.
카메라와 Gemini를 이용한 위험 요소 분석
위험 요소 신고는 사진 입력 → 위치 확인 → AI 분석 → 검토·수정 → 제출 흐름으로 구성했습니다. 제출된 시연 영상에서는 이미지 업로드와 실시간 카메라 진입 화면을 확인할 수 있습니다. 사진과 위치 정보를 서버에 전달하면 Gemini가 위험 유형·심각도·상황 요약 등의 결과를 반환하는 구조입니다.
서버에서는 이미지 누락, 허용하지 않는 형식, 과도한 크기 등을 검사합니다. 분석 단계에서 발생하는 API 키 누락, 할당량 초과, 시간 초과 등의 오류도 구분해 응답하도록 구성되어 있습니다.
분석 결과를 곧바로 확정 신고로 취급하지 않고, 사용자가 내용을 수정한 뒤 제출할 수 있도록 했습니다. 사진이 불분명하거나 모델 응답이 불완전한 경우를 다루는 코드와 응답 처리 테스트도 저장소에 포함되어 있습니다.
팀 시연 영상 00:46 화면. 사진 입력부터 분석·검토·신고까지의 단계를 화면 상단에 표시했습니다. 실제 분석 결과가 아닌 입력 단계의 캡처입니다.
내 담당 — Firebase 연동과 신고 데이터 연결
신고를 제출하면 서버가 신고 ID와 시설 작업 요청 ID를 생성합니다. 위험 유형과 위치, 사진, 권장 조치 등을 하나의 기록으로 묶고, 앱에서 사용하는 신고 목록에 반영합니다. 건물 ID가 있는 엘리베이터 고장 신고는 해당 건물의 엘리베이터 상태를 갱신하는 흐름으로 연결됩니다.
제출한 서비스의 핵심 흐름은 신고를 Firebase에 저장하고 시설 상태 확인으로 연결하는 것입니다. 공개 저장소의 서버 코드는 Firebase 설정이 있을 때 Firestore 저장을 시도하고, 미설정 또는 저장 실패 시 메모리에서 동작하는 데모 모드를 사용합니다. 앱 내부에서 작업 요청 ID를 생성하는 구현이며, 실제 대학 시설 관리 시스템으로 접수되는 연동은 별도 확인이 필요합니다.
접근성을 고려한 인터페이스
이동 장벽을 안내하는 서비스인 만큼, 화면을 사용하는 방식도 함께 고려했습니다.
- 고대비 화면 전환과 글자 확대 옵션
- 소리 대신 시각적 알림을 사용하는 모드
- 브라우저 음성 합성을 이용한 경로 읽어주기
- 이동 지원과 교내 지원 연락처로 이어지는 화면
캠퍼스 건물과 초기 신고 데이터를 브라우저 Cache API에 저장하는 코드도 포함되어 있습니다. 다만 이 캐시만으로 최신 시설 상태나 모든 지도 기능의 오프라인 사용을 보장할 수는 없습니다.
Gemini 음성 도우미
음성 도우미는 사용자의 요청을 받아 필요한 화면이나 행동으로 연결하는 기능입니다. 제출 시나리오에서는 학생이 Student Services로 이동하기 어렵다고 말하면 길 안내로 연결하고, 통행이 어려울 경우 이동 지원이나 접근성 서비스로 이어지는 흐름을 제시했습니다.
지도에서 목적지를 찾는 것에 더해 현재 무엇이 어려운지 말로 설명하고 도움을 받을 수 있는 진입점을 마련한 것입니다. 이 기능의 프런트엔드와 Gemini 연동은 Peter가 담당했습니다.
3. 시스템 구성과 사용 기술
사용자가 브라우저에서 사진과 위치를 확인하면 Express API가 입력을 검증하고 Gemini 분석을 요청합니다. 사용자가 결과를 검토해 제출한 신고는 저장 계층과 앱 내 목록에 반영되고, 지도·시설 상태 화면에서 활용됩니다.
| 구분 | 사용 기술 및 역할 |
|---|---|
| 프런트엔드 | React 19, TypeScript, Vite |
| 화면 구성 | Tailwind CSS, Motion, Lucide React |
| 지도·위치 | Google Maps, @vis.gl/react-google-maps, 브라우저 위치 API |
| 이미지 분석 | Gemini, @google/genai, 서버 측 모델 호출 |
| 백엔드 | Node.js, Express, tsx |
| 데이터 저장 | Firebase / Firestore 연동 코드, 메모리 기반 데모 모드 |
| 브라우저 기능 | 카메라, 음성 합성, Cache API |
4. 기술적으로 고민한 지점
사진에서 알 수 있는 정보의 범위
사진 한 장으로 장애물의 존재를 추정할 수는 있어도, 정확한 경사도나 출입구의 이용 가능 여부까지 확정하기는 어렵습니다. 따라서 분석 결과와 위치 추정을 사용자가 검토할 수 있게 하고, 정보가 부족할 때는 불확실성을 드러내는 처리가 중요합니다.
저장소의 분석 테스트는 위험 요소가 없는 사진, 불명확한 사진, 불완전한 응답, 네트워크 실패 등을 다룹니다. 이 테스트는 응답 처리 로직을 확인하는 용도이며, 실제 현장 사진에 대한 모델 정확도를 측정한 결과는 아닙니다.
여러 화면이 공유하는 상태
신고 화면에서 제출한 장벽은 지도와 시설 상태에서도 같은 의미로 표시되어야 합니다. 이를 위해 신고 데이터에 위험 유형뿐 아니라 건물 ID, 좌표, 상태와 작업 요청 ID를 함께 담는 구조를 사용합니다. 사용자 입력을 지도상의 시설 정보와 연결하는 데이터 모델이 핵심입니다.
외부 API 실패에 대한 대응
지도와 AI 분석은 외부 서비스의 응답에 의존합니다. 길찾기 요청의 대체 경로, 이미지 입력 검증, AI 오류 분류, 고도 조회 시간 제한은 각 단계가 실패했을 때 상황을 구분하기 위한 구현입니다. 실패를 임의의 분석 결과로 덮기보다 사용자가 다시 시도하거나 내용을 확인할 수 있는 흐름이 필요합니다.
5. 제출과 구현 범위
프로젝트는 2026년 10월 2일 오후 4시 44분에 제출했습니다. 제출 페이지에는 4인 팀과 Build with AI for Social Good 트랙이 기록되어 있습니다.
현장에서 확인한 프로젝트 제출 페이지.
제출 설명에는 Firebase Authentication, Cloud Firestore, Firebase Hosting, Firebase Cloud Messaging을 기술 구성으로 기재했습니다. 이 글에서는 Firebase 연동이라는 개인 담당 범위와 공개 코드에서 확인되는 저장 흐름을 중심으로 설명했습니다. 각 서비스의 운영 배포 상태와 알림 전달까지 모두 검증한 것은 아닙니다.
공개 저장소에는 지도·AI 신고·시설 상태·접근성 옵션을 연결한 프로토타입이 담겨 있습니다. 실제 운영으로 확장하려면 다음 항목을 검증해야 합니다.
- 시설 정보의 신뢰성: 현장 확인과 공식 데이터 연동을 통한 상태·경로 검증
- 신고의 지속성: Firestore 설정과 권한 검토, 저장 실패 처리 및 운영 데이터 관리
- 실제 지원 서비스 연동: 이동 지원 요청 화면의 배차·도착 시간은 시뮬레이션이며 실제 운영 기관과의 연결 필요
- 외부 교통 정보 연동: BART 알림은 모의 피드를 사용하므로 실시간 데이터 소스로 교체 필요
- 접근성 검증: 고대비·확대 등의 옵션 구현에 더해 실제 사용자 평가와 보조 기술 호환성 확인 필요
6. 첫 번째 해커톤 기록을 마치며
GatorAccess에서 다룬 핵심은 AI 분석 자체보다 현장의 문제를 발견하고, 확인하고, 공유하는 전체 과정입니다. 지도, 카메라, 위치 정보, 신고 데이터가 연결되어야 사용자가 다음 행동을 결정할 수 있습니다.
접근성을 위한 서비스에서는 기능의 수만큼 정보의 신뢰성과 실패 시의 동작도 중요합니다. 이 프로젝트는 웹 기술과 멀티모달 AI를 캠퍼스 이동 문제에 적용하면서, 프로토타입의 기능을 실제 운영으로 이어가기 위해 무엇을 검증해야 하는지 살펴본 작업입니다.
행사를 마치고 남긴 기념사진.
이번 편은 세 번의 해커톤을 돌아보는 시리즈의 1/3, SF Hacks 2026 기록입니다. 프로젝트 리드와 Firebase 연동을 맡은 경험을 출발점으로, 다음 편에서는 다른 해커톤에서의 프로젝트와 협업 경험을 이어갈 예정입니다.