OneStep
완료고립·은둔 청년의 외출을 돕는 산책 챌린지 기반 케어 앱
2026-01-06~ 2026-02-09
androidkotlinspring-bootredispostgresqlmongodbmapboxkafkafastapi
Overview
고립·은둔 청년은 자가진단 결과 방 밖, 심지어 자기 방 밖을 나서는 것조차 어려워하는 경우가 많다. “운동해라”, “나가라”는 강요형 앱은 이들에게 오히려 부담이 된다는 문제의식에서, OneStep은 AI 반려 펫과의 교감을 매개로 초소형 행동(물 마시기 등)부터 산책까지 단계적으로 외출을 유도하는 케어 앱으로 기획됐다. 실패해도 기록도 페널티도 남기지 않는 것(No-Failure Policy)을 핵심 원칙으로 삼았다.
진행 기간: 2026.01.06 ~ 2026.02.09 (6주, 6인 팀) · 성과: 3등 수상
핵심 기능
- 마이크로 루틴 챌린지: AI가 사용자 상태를 분석해 30초~5분 내 완료 가능한 초소형 행동을 추천, 실패 기록 없이 매일 새로운 시작 제공
- AI 감성 펫: 루틴 수행·대화를 먹이 삼아 성장하며, 평가하지 않는 리액션으로 정서적 유대감 형성
- 느슨한 사회적 연결: 가상 창문을 통한 익명 편지 교환 + 단계별 산책(방→현관→공원)으로 점진적 외부 노출
- 산책 챌린지 (담당 파트): GPS 기반 위치 추적과 목표 지점 도착 판정, 앱의 레트로·픽셀 컨셉에 맞춘 Mapbox 커스텀 지도
내 역할
FE(Android) + UI/UX·디자인 — 산책 GPS/지도 기능을 직접 설계·구현했고, 앱 전반의 UI/UX와 레트로·픽셀 컨셉의 비주얼 디자인도 함께 맡았다. 산책 목적지 도착 판정에서 GPS 오차로 인한 오작동을 막기 위해 정확도·거리·판정 기준의 임계값 가드를 설계·적용했다.
Architecture (개요)
Android (Kotlin/Compose)
│ GPS · Mapbox
▼
Spring Boot (REST/WebSocket) ──Kafka──▶ FastAPI (추천/챗봇, ML)
│ │
PostgreSQL MongoDB · ChromaDB
│
Redis (모닥불 고민방 세션/Pub-Sub)
- Android: GPS 위치 추적 + Mapbox 지도 렌더링
- Spring Boot: 인증, 챌린지/산책/펫/편지 API, 고민방 웹소켓, 일일 추천 배치 트리거(Kafka)
- FastAPI(AI 서버): 개인화 추천 알고리즘, RAG 기반 챗봇
- Redis: 고민방 채팅 세션 상태 + Pub/Sub 브로커 (다중 서버 간 메시지 전파)
기술 선택 이유
- Mapbox: 앱의 레트로/픽셀 디자인 톤에 지도를 맞추기 위해 커스텀 스타일링이 가능한 SDK가 필요했음. 구글/카카오맵은 스타일 커스텀 자유도가 낮고, 국내 POI 정확도도 이 앱엔 핵심 요구사항이 아니었음(장소 정보는 백엔드가 미리 계산해 제공)
- 임계값 가드 (GPS 노이즈 대응): 칼만 필터 같은 스무딩 기법 대신 정확도·거리·판정 기준의 단순 가드를 택함. 타겟 사용자 특성상 이동 반경이 좁아 “부드러운 궤적”보다 “명백한 이상치(순간이동) 제거”가 우선이었고, 구현·튜닝 비용도 훨씬 낮았음
- Jetpack Compose: 실시간으로 갱신되는 위치·거리·속도 값을 상태(State) 기반으로 선언형으로 그릴 수 있어, 잦은 UI 갱신이 필요한 산책 화면에 적합했음
- Kafka + 사전 생성 캐싱: 개인화 추천을 접속 즉시 생성하면 응답이 느려지므로, 배치로 미리 만들어두고 접속 시 바로 반환하는 구조를 팀 차원에서 택함 — 실시간 생성보다 응답속도·서버 부하 모두에서 유리
- 게스트 우선 온보딩: 타겟 사용자가 회원가입 자체를 진입장벽으로 느낄 수 있어, 가입 없이 바로 체험하고 이후 원하면 카카오 계정으로 연동하는 흐름을 택함
배운 점
- GPS 원시 데이터의 노이즈 특성을 직접 다루면서, “이상치 제거”와 “궤적 스무딩”이 서로 다른 문제라는 걸 체감했다. 칼만 필터 같은 표준 기법을 무조건 쓰는 게 아니라, 우리 문제가 정말 그 기법을 필요로 하는지부터 판단하는 게 먼저라는 걸 배웠다.
- 타겟 사용자의 실제 행동 반경(좁음)이라는 도메인 제약이 기술 선택(필터링 방식)에 직접 영향을 준다는 걸 배웠다 — “일반적인 지도 앱”의 상식(오차 무시 가능)이 이 앱에선 그대로 적용되지 않았다.
- 팀 프로젝트에서 내가 맡지 않은 백엔드 영역(이벤트 기반 보상 지급, Redis 활용 범위, AI 서버 구조)도 코드 리딩으로 직접 추적하며 전체 아키텍처를 이해하려 했다.
- 프론트엔드뿐 아니라 UI/UX·디자인까지 함께 맡으면서, 지도 같은 핵심 기능도 “기능이 동작하는가”뿐 아니라 “앱의 정체성과 시각적으로 일관되는가”까지 고려해야 한다는 제품 관점을 얻었다.
OneStep 복습
- 📚 OneStep 파헤치기 시리즈 — GPS/지도, 그리고 내가 맡지 않았던 백엔드 영역까지 코드로 다시 짚어보며 정리하는 시리즈