"1분반-우리어때"의 두 판 사이의 차이

cdc wiki
이동: 둘러보기, 검색
(→‎지도교수)
(→‎결과 및 평가)
 
(같은 사용자의 중간 판 4개는 보이지 않습니다)
25번째 줄: 25번째 줄:
  
 
==서론==
 
==서론==
−
 
 
===개발 과제의 개요===
 
===개발 과제의 개요===
 +
====개발 과제 요약====
 +
'''우때(Uttae)'''는 여러 사용자가 하나의 여행 방에서 지도, 채팅, 보관함, 일정표를 함께 사용하며 여행 계획을 세우는 협업형 여행 계획 플랫폼이다.
  
−
====개발 과제 요약====
+
사용자는 Google 계정으로 로그인한 뒤 여행 방을 생성하고, 초대 코드로 팀원을 초대하며, 방 안에서 장소 검색, 장소 공유, 후보지 보관, 일자별 일정 편집을 실시간으로 수행할 수 있다. 또한 AI 서버는 채팅 요약, 여행 관련 질문 응답, Google Places 기반 장소 추천, 비여행 질문 거절을 담당한다.
−
* 본 개발 과제는 여러 사용자가 하나의 여행 방에서 지도, 채팅, 보관함, 일정표를 함께 사용하며 여행 계획을 세울 수 있는 협업형 여행 계획 플랫폼 '''우때(Uttae)'''를 개발하는 것이다.
 
−
* 사용자는 Google OAuth 기반 로그인 후 여행 방을 생성하고, 초대 코드를 통해 팀원을 초대할 수 있다.
 
−
* 방 안에서는 장소 검색, 장소 공유, 후보지 보관, 일자별 일정 편집, 실시간 채팅을 수행할 수 있다.
 
−
* 본 서비스는 지도 기반 장소 탐색, 실시간 채팅, Drag and Drop 기반 일정 편집, WebSocket/STOMP 기반 실시간 동기화, AI 기반 채팅 요약 및 장소 추천 기능을 결합한다.
 
−
* 이를 통해 카카오톡, 지도 앱, 엑셀, 메모장 등 여러 도구에 분산되던 여행 계획 과정을 하나의 협업 환경으로 통합하는 것을 목표로 한다.
 
  
 
====개발 과제의 배경====
 
====개발 과제의 배경====
−
* 기존 여행 계획 방식은 장소 검색, 후보지 저장, 팀원 의견 조율, 일정 배치, 이동 시간 확인이 각각 다른 앱과 채팅방에 흩어지는 경우가 많다.
+
여행 계획은 장소 검색, 후보 저장, 팀원 의견 조율, 일정 배치, 이동 시간 확인이 여러 앱과 채팅방에 흩어지기 쉬워 협업 비용이 크다. 일반 메신저는 의견 조율에는 편리하지만 장소 카드, 지도 위치, 일정표, 후보지 분류를 구조화하기 어렵고, 지도 앱은 장소 탐색에는 강하지만 팀 단위 의사결정 흐름을 담기 어렵다.
−
* 일반 메신저는 팀원 간 의견 교환에는 적합하지만, 장소 정보와 일정표를 구조화하여 관리하기 어렵다.
+
 
−
* 일반 지도 서비스는 장소 검색과 경로 확인에는 강점이 있으나, 팀 단위 채팅, 후보지 분류, 일정 편집, 실시간 협업 기능은 제한적이다.
+
본 서비스는 지도, 채팅, 일정, 보관함, AI를 하나의 방 단위 협업 모델로 통합하여 여행 계획의 탐색, 논의, 결정, 일정화를 한 흐름 안에서 수행하도록 돕는다.
−
* 여행 일정 앱은 일정표 작성에는 강점이 있으나, 실시간 채팅과 AI 요약, 대화 맥락 기반 추천 기능이 부족할 경우 공동 의사결정 흐름을 충분히 담기 어렵다.
 
−
* 이에 따라 본 과제는 지도, 채팅, 일정, 보관함, AI 기능을 하나의 서비스 안에 통합하여 여행 계획의 탐색, 논의, 결정, 일정화를 자연스럽게 연결하는 플랫폼을 개발하고자 한다.
 
  
 
====개발 과제의 목표 및 내용====
 
====개발 과제의 목표 및 내용====
−
* 본 과제의 목표는 소규모 그룹 사용자가 여행 계획을 실시간으로 함께 수립할 수 있는 웹 기반 협업 플랫폼을 구현하는 것이다.
+
{| class="wikitable"
−
* Google OAuth, JWT, Refresh Token Rotation, Redis 기반 세션 관리를 통해 사용자 인증과 방 단위 접근 권한을 통제한다.
+
! 구분 !! 주요 내용
−
* 사용자는 방 생성, 초대 코드 기반 입장, 입장 요청 승인 및 거절, 멤버 관리, 방장 위임 등의 협업 방 관리 기능을 사용할 수 있다.
+
|-
−
* Google Places API와 Routes API를 활용하여 장소 검색, 장소 상세 정보 조회, 사진 확인, 이동 정보 조회 기능을 제공한다.
+
| 인증 및 방 관리 || Google OAuth, JWT, Refresh Token Rotation, Redis 기반 세션 관리, 초대 코드, 입장 승인/거절, 방장 위임, 멤버 관리
−
* 검색한 장소는 보관함에 저장하거나 채팅으로 공유할 수 있으며, 일정표에 추가할 수 있다.
+
|-
−
* 일자별 여행 일정은 Drag and Drop 방식으로 순서를 변경하거나 다른 날짜로 이동할 수 있다.
+
| 지도·장소 기능 || Google Places/Routes API 기반 장소 검색, 장소 상세, 사진 URL, 이동 정보 조회, Redis 캐시 적용
−
* WebSocket/STOMP 기반 실시간 통신을 통해 채팅, 일정 변경, 장소 공유, 멤버 상태 변경 등의 이벤트를 모든 참여자에게 동기화한다.
+
|-
−
* FastAPI 기반 AI 서버를 Spring Boot 백엔드와 분리하여 운영하며, AI 서버는 채팅 요약, 여행 관련 질문 응답, 장소 추천, 비여행 질문 거절 기능을 담당한다.
+
| 협업 기능 || WebSocket/STOMP 기반 실시간 채팅, 일정 변경, 보관함 변경, 멤버 상태 동기화
 +
|-
 +
| 일정 기능 || 일자별 일정 생성·삭제·이동, Drag and Drop 기반 순서 변경, 시간·메모 편집
 +
|-
 +
| AI 기능 || 채팅 요약, 여행 질문 응답, 장소 추천, 일정·북마크 기반 맥락 반영, 비지원 질문 거절
 +
|}
  
 
===관련 기술의 현황===
 
===관련 기술의 현황===
−
 
 
====관련 기술의 현황 및 분석(State of art)====
 
====관련 기술의 현황 및 분석(State of art)====
 +
*전 세계적인 기술현황
 +
최근 생성형 AI 서비스는 단순 질의응답을 넘어 사용자의 의도를 분석하고 외부 API나 도구를 선택해 실행하는 Agentic Workflow 형태로 발전하고 있다. OpenAI Function Calling, LangChain, LangGraph 등은 복잡한 다단계 추론과 도구 호출을 지원한다.
  
−
*전 세계적인 기술현황
+
여행·모빌리티 서비스에서는 Google Places API, Routes API 등을 활용한 장소 검색, 상세 정보 조회, 이동 시간 계산, 위치 기반 추천 기술이 핵심 요소로 자리 잡고 있다. 또한 다수 사용자가 동시에 참여하는 협업 서비스에서는 WebSocket과 STOMP 기반 Pub/Sub 구조가 실시간 동기화 기술로 널리 사용된다.
−
** 최근 생성형 AI 서비스는 단순 질의응답을 넘어 사용자의 의도를 분석하고 외부 API나 도구를 선택적으로 호출하는 Agentic Workflow 형태로 발전하고 있다.
 
−
** OpenAI Function Calling, LangChain, LangGraph 등은 복잡한 다단계 추론과 도구 호출을 통해 실제 업무 수행에 가까운 AI 에이전트 구현을 가능하게 한다.
 
−
** 여행 및 모빌리티 서비스 분야에서는 지도 시각화, 장소 검색, 장소 상세 정보 조회, 이동 시간 계산을 통합하는 Location Intelligence 기술이 핵심 요소로 자리 잡고 있다.
 
−
** Google Places API와 Routes API를 활용하면 장소 탐색, 위치 기반 추천, 경로 계산, 일정 최적화 기능을 구현할 수 있다.
 
−
** 다수 사용자가 동시에 참여하는 협업 서비스에서는 WebSocket과 STOMP 기반 실시간 양방향 통신이 널리 사용되고 있다.
 
−
** 데이터 저장 측면에서는 데이터 특성에 따라 PostgreSQL/PostGIS, MongoDB, Redis 등을 조합하는 Polyglot Persistence 구조가 확산되고 있다.
 
  
 
*특허조사 및 특허 전략 분석
 
*특허조사 및 특허 전략 분석
−
** 관련 선행 특허로는 AI 기반 맞춤형 여행 일정 추천 시스템, 개인화 여행 일정 추천 기술, 협업형 여행 계획 시스템, 대화형 여행 인터페이스 시스템 등이 조사되었다.
+
{| class="wikitable"
−
** 기존 특허들은 주로 사용자 정보, 선호도, 여행 장소 정보, 행사 및 콘텐츠 정보를 활용해 여행 일정을 자동 생성하거나, 그룹 여행 계획에서 목적지 목록을 생성하고 여행 검색 결과를 공유하는 구조에 초점을 둔다.
+
! 특허 !! 내용 !! 시사점
−
** 따라서 본 과제의 특허 전략은 단순한 여행 일정 추천이나 지도 기반 장소 탐색을 권리화하기보다는, 협업형 대화 맥락 처리, 실시간 UI 반영, AI 요약 및 추천 결과가 여행 방의 상태와 연결되는 구조에 초점을 두는 것이 적절하다.
+
|-
−
** 특히 AI가 채팅 맥락, 일정, 보관함, 장소 메타데이터를 입력으로 받아 의도를 분류하고, 필요한 도구를 호출한 뒤 결과를 채팅 및 일정 관리 흐름에 반영하는 방식이 차별화 요소가 될 수 있다.
+
| KR20230072017A || AI 기반 맞춤형 여행 일정 추천 || 일반 여행 추천은 선행기술이 많음
 +
|-
 +
| US10445666B1 || 개인 선호 기반 여행 일정 추천 || 개인화 일정 추천 영역과 차별화 필요
 +
|-
 +
| US20120191341A1 / US8719251B1 || 협업형 여행 계획 및 검색 결과 공유 || 채팅 기반 협업 구조와의 차별화 필요
 +
|-
 +
| WO2023073505A1 || 대화형 여행 계획 인터페이스 || 자연어 기반 여행 UI와의 차별화 필요
 +
|}
 +
 
 +
본 과제의 특허 전략은 범용 여행 추천보다 '''협업형 대화 맥락 처리''', '''실시간 일정·보관함 반영''', '''채팅 요약 기반 AI 장소 추천'''에 초점을 맞추는 방향이 적절하다.
  
 
*기술 로드맵
 
*기술 로드맵
−
** 1단계: Google OAuth 로그인, 방 생성, 초대 코드 기반 입장, 멤버 관리, 기본 장소 검색 및 일정 편집 기능 구현
+
{| class="wikitable"
−
** 2단계: MongoDB 기반 채팅 메시지 저장, WebSocket/STOMP 기반 실시간 브로드캐스트, 읽음 위치 관리, 안 읽은 메시지 수 표시, 재접속 시 누락 메시지 복구 기능 구현
+
! 단계 !! 개발 내용
−
** 3단계: 보관함 카테고리, 장소 공유, Drag and Drop 일정 편집, 일정 항목의 다른 일자 이동, 이동 정보 조회 및 Redis 캐시 기능 구현
+
|-
−
** 4단계: AI 요청 큐와 방별 처리 lock 적용, 채팅 자동 요약, 장소 추천, 요약 조회, 여행 관련 일반 대화, 비지원 질문 거절 기능 구현
+
| 1단계 || Google OAuth 로그인, 방 생성, 초대 코드 입장, 멤버 관리, 기본 장소 검색과 일정 편집
−
** 5단계: Docker Compose 기반 운영 배포, Caddy edge proxy, Prometheus/Grafana/Loki/Alloy 기반 관측성, rate limit, 장애 대응 정책 고도화
+
|-
 +
| 2단계 || MongoDB 채팅 저장, WebSocket/STOMP 브로드캐스트, 읽음 위치, 재접속 복구
 +
|-
 +
| 3단계 || 보관함 카테고리, 장소 공유 메시지, Drag and Drop 일정 편집, 이동 정보 Redis 캐시
 +
|-
 +
| 4단계 || AI 요청 큐, 방별 lock, 채팅 30개 단위 자동 요약, 장소 추천과 비지원 질문 거절
 +
|-
 +
| 5단계 || Docker Compose 배포, Caddy edge proxy, Prometheus/Grafana/Loki/Alloy 관측성 고도화
 +
|}
  
 
====시장상황에 대한 분석====
 
====시장상황에 대한 분석====
−
 
 
*경쟁제품 조사 비교
 
*경쟁제품 조사 비교
−
** 경쟁 제품은 Google Maps와 같은 일반 지도 서비스, 카카오톡과 같은 일반 메신저, Wanderlog와 같은 여행 일정 앱, TripIt과 같은 예약·여정 관리 서비스로 구분할 수 있다.
+
{| class="wikitable"
−
** Google Maps는 글로벌 장소 데이터, 리뷰, 경로 탐색, 자연어 내비게이션에 강점이 있으나, 여행 그룹의 의사결정 과정이나 채팅 기반 협업 워크플로우는 상대적으로 약하다.
+
! 제품 !! 강점 !! 한계
−
** 일반 메신저는 팀원 간 의견 조율에는 강점이 있으나, 장소 데이터와 일정표가 구조화되지 않아 나중에 결정 사항을 다시 찾기 어렵다.
+
|-
−
** Wanderlog는 일정, 지도, 협업, AI, 예산 기능이 한 앱에 통합되어 있다는 장점이 있으나, 채팅방 멘션 기반 실시간 공동 의사결정 흐름은 상대적으로 약하다.
+
| Google Maps || 글로벌 POI/경로 데이터, 자연어 내비게이션 고도화 || 여행 그룹 합의 중심 워크플로우는 약함
−
** TripIt은 예약 정보와 여정을 자동으로 수집하고 정리하는 데 강점이 있으나, 실시간 그룹 협업, 지도 연동 장소 추천, 채팅 기반 일정 조율 기능은 제한적이다.
+
|-
−
** 우리어때는 지도, 채팅, 보관함, 일정표, AI 요약 및 추천을 하나의 화면에서 제공하여 팀 단위 여행 계획의 탐색·논의·결정·일정화 과정을 통합적으로 지원한다는 점에서 차별성을 가진다.
+
| Wanderlog || 일정·지도·협업·예산 기능 통합 || 채팅방 멘션 기반 실시간 공동 의사결정은 상대적으로 약함
 +
|-
 +
| TripIt || 예약/여정 자동 수집 및 정리 강점 || 실시간 그룹 협업과 지도 연동 추천은 제한적
 +
|}
  
 
*마케팅 전략 제시
 
*마케팅 전략 제시
−
** 주요 타깃은 친구, 가족, 동아리, 학생회, 팀 단위로 여행을 준비하는 20~30대 소규모 그룹 사용자이다.
+
주요 대상은 친구, 가족, 동아리, 팀 단위로 여행을 준비하는 소규모 그룹 사용자이다. 초기 확산은 대학생 지인, 동아리, 학생회, 여행 커뮤니티처럼 공동 의사결정이 많은 사용 사례를 중심으로 진행한다.
−
** 특히 여러 명이 함께 여행 계획을 세우면서 카카오톡, 지도 앱, 엑셀, 메모장을 오가는 불편함을 경험한 사용자를 핵심 타깃으로 설정한다.
+
 
−
** 마케팅 메시지는 “하나의 사이트에서 여행계획 끝”, “지도와 채팅을 오가며 정리하는 번거로움 해결”, “팀원들과 실시간으로 여행을 기획”과 같이 기존 여행 계획 방식의 불편함을 직접적으로 해결한다는 점을 강조한다.
+
서비스 메시지는 “지도와 채팅을 오가며 여행 계획을 정리하는 불편함을 줄이고, 한 화면에서 후보 저장·일정 배치·AI 요약을 제공한다”는 점에 집중한다.
−
** 초기 확산 전략으로는 대학생, 동아리, 학생회, 여행 커뮤니티와 같은 공동 의사결정이 많은 사용자 집단을 중심으로 베타 테스트를 진행한다.
 
−
** 이후 SNS 광고, 지도·여행 인플루언서 체험형 콘텐츠, 여행 동행 커뮤니티 제휴 등을 통해 사용자를 확대한다.
 
−
** 수익화 전략은 기본 팀 기능은 무료로 제공하되, 고급 비교 기능, 리포트, 히스토리 관리, AI 추천 고도화 기능 등을 구독 모델로 확장하는 방식이 가능하다.
 
−
** 장기적으로는 여행사, 숙박업체, 지역 관광 업체와의 B2B 제휴 및 광고 모델로 확장할 수 있다.
 
  
 
===개발과제의 기대효과===
 
===개발과제의 기대효과===
 +
====기술적 기대효과====
 +
Frontend, Spring Backend, AI Server를 분리하여 사용자 상태 저장과 AI 판단을 독립적으로 확장할 수 있다. PostgreSQL/PostGIS, MongoDB, Redis를 목적별로 분리해 관계형 도메인 데이터, 채팅 타임라인, 캐시·큐·세션 데이터를 각각 적합한 저장소에 배치한다.
  
−
====기술적 기대효과====
+
또한 WebSocket/STOMP 기반 실시간 동기화와 OpenAI structured output 기반 응답 계약을 결합하여, 지도·채팅·일정·AI 추천이 안정적으로 연결되는 협업형 여행 계획 구조를 구현한다.
−
* 본 과제는 Frontend, Spring Backend, AI Server를 분리한 구조로 설계하여 각 영역의 책임을 명확히 하고 확장성을 확보하였다.
 
−
* 프론트엔드는 사용자 화면과 클라이언트 상태 관리를 담당하고, Spring Boot 백엔드는 인증·권한·도메인 데이터·실시간 이벤트 전파의 source of truth 역할을 수행한다.
 
−
* FastAPI 기반 AI 서버는 의도 분류, 요약, 장소 추천, 외부 도구 호출을 담당한다.
 
−
* PostgreSQL/PostGIS, MongoDB, Redis를 목적별로 분리하여 저장소의 역할을 명확히 하였다.
 
−
* 관계형 도메인 데이터는 PostgreSQL/PostGIS에 저장하고, 채팅 메시지와 AI 맥락 데이터는 MongoDB에 저장하며, 토큰·세션·접속 상태·캐시·AI 요청 queue/lock은 Redis를 활용한다.
 
−
* WebSocket/STOMP 기반 실시간 브로드캐스트를 통해 채팅, 일정, 보관함, 멤버 상태 변경을 즉시 동기화할 수 있다.
 
−
* AI 측면에서는 단순 LLM 호출 서버가 아니라 intent routing, context selection, summary 관리, tool calling, 후보 검증, 응답 계약을 포함한 여행 계획용 오케스트레이션 서버를 설계하였다.
 
  
 
====경제적, 사회적 기대 및 파급효과====
 
====경제적, 사회적 기대 및 파급효과====
−
* 본 서비스는 여행 계획에 필요한 장소 탐색, 정보 공유, 일정 조율 시간을 줄여 소규모 그룹 여행 준비의 생산성을 높일 수 있다.
+
여행 계획에 필요한 장소 탐색, 정보 공유, 일정 조율 시간을 줄여 소규모 그룹 여행 준비의 생산성을 높일 수 있다. 대화와 일정이 분리되지 않아 의사결정 이력을 보존하고, 늦게 합류한 팀원도 AI 요약과 후보지를 통해 빠르게 맥락을 따라갈 수 있다.
−
* 기존에는 여러 앱을 오가며 장소를 검색하고, 채팅방에서 의견을 나누고, 별도의 문서나 엑셀에 일정을 정리해야 했지만, 우리어때는 이 과정을 하나의 화면에서 처리할 수 있도록 한다.
+
 
−
* 대화와 일정이 분리되지 않기 때문에 의사결정 이력이 보존되고, 늦게 합류한 팀원도 AI 요약과 후보지 정보를 통해 빠르게 여행 맥락을 파악할 수 있다.
+
나아가 지도·채팅·AI를 결합한 협업 경험은 여행뿐 아니라 모임 장소 선정, 현장 답사, 팀 프로젝트 일정 조율 등으로 확장될 수 있다.
−
* 이는 팀원 간 정보 비대칭을 줄이고 공동 의사결정 과정을 효율화하는 효과를 가진다.
 
−
* 사회적으로는 지도, 채팅, AI를 결합한 협업 경험을 여행뿐 아니라 모임 장소 선정, 현장 답사, 팀 프로젝트 일정 조율, 행사 준비 등 다양한 협업 상황으로 확장할 수 있다.
 
−
* 경제적으로는 초기에는 무료 협업 여행 계획 서비스로 사용자 기반을 확보하고, 이후 고급 AI 추천, 여행 리포트, 일정 히스토리, B2B 제휴, 광고 모델 등으로 수익화가 가능하다.
 
  
 
===기술개발 일정 및 추진체계===
 
===기술개발 일정 및 추진체계===
−
 
 
====개발 일정====
 
====개발 일정====
−
* 개발 기간은 2026년 3월부터 2026년 6월까지 총 4개월로 진행되었다.
+
{| class="wikitable"
−
* 3월에는 과제 기획, 요구사항 정의, 서비스 구조 설계, 기술 스택 선정, 화면 설계, 기본 아키텍처 설계를 진행하였다.
+
! 기간 !! 주요 개발 내용
−
** 이 단계에서 Google OAuth 기반 인증, 방 생성 및 초대 코드 구조, 지도·채팅·일정·보관함 중심의 핵심 기능 흐름을 정의하였다.
+
|-
−
* 4월에는 프론트엔드, 백엔드, 데이터베이스, 실시간 통신의 핵심 기능을 구현하였다.
+
| 2026년 3월 || 기획, 요구사항 정의, 화면 설계, 기술 스택 선정
−
** Google Places API 기반 장소 검색, 방 관리, 보관함, 일정 편집, WebSocket/STOMP 기반 실시간 채팅 및 이벤트 동기화 기능을 개발하였다.
+
|-
−
* 5월에는 AI 서버 기능과 외부 API 연동을 고도화하였다.
+
| 2026년 4월 || 인증, 방 생성, 초대 코드, 장소 검색, 기본 채팅 기능 구현
−
** FastAPI 기반 AI 서버를 분리하고, 채팅 요약, intent 분류, 여행 관련 질문 응답, 장소 추천, 비여행 질문 거절 기능을 구현하였다.
+
|-
−
* Redis 캐시, 요청 제한, 이동 정보 조회 기능 등을 개선하였다.
+
| 2026년 5월 || 보관함, 일정 편집, Drag and Drop, WebSocket 실시간 동기화 구현
−
** 6월에는 배포 환경 구성, 서비스 안정화, 테스트, 사용자 설문, 포스터 제작, 최종 보고서 작성 및 발표 준비를 수행하였다.
+
|-
−
** 실제 서비스는 uttae.app 도메인을 통해 배포되었으며, 사용자 통계와 만족도 조사를 기반으로 결과를 평가하였다.
+
| 2026년 6월 || AI 요약·추천, 운영 배포, 모니터링, 사용자 테스트 및 최종 보고서 정리
 +
|}
  
 
====구성원 및 추진체계====
 
====구성원 및 추진체계====
−
* 본 과제는 Frontend, Backend, AI Server 영역을 분리하여 병렬 개발하는 방식으로 추진하였다.
+
{| class="wikitable"
−
** Frontend 담당은 Next.js 기반 화면 구현, 지도·채팅·일정·보관함 UI, 클라이언트 상태 관리, API 연동, 반응형 화면 개선을 수행하였다.
+
! 구성원 !! 역할 !! 담당 업무
−
** Backend 담당은 Spring Boot 기반 REST API, 인증/인가, 방/멤버/장소/북마크/일정/채팅 도메인, WebSocket/STOMP 기반 실시간 이벤트 처리를 구현하였다.
+
|-
−
** AI Server 담당은 FastAPI 기반 AI API, 채팅 요약, intent 분류, 장소 추천, OpenAI API 및 Google Places API 연동 기능을 구현하였다.
+
| 김민형, 박주영 || Backend || Spring Boot 기반 REST API, 인증/인가, WebSocket/STOMP 실시간 이벤트 개발 등
−
* 전체 추진체계는 Git 기반 버전 관리, API 명세 공유, Docker Compose 기반 로컬 개발 환경, 기능별 테스트 및 시연을 중심으로 운영되었다.
+
|-
−
* 개발 결과는 Frontend, Backend, AI Server, Database, Redis, MongoDB, PostgreSQL/PostGIS, 관측성
+
| 송희영 || Frontend || Next.js 기반 화면 구현, 지도·채팅·일정·보관함 UI, 상태 관리, API 연동 등
 +
|-
 +
| 문재영 || AI Server || FastAPI 기반 AI API, 채팅 요약, intent 분기, 장소 추천, OpenAI 및 Google Places 연동 등
 +
|}
 +
 
 +
전체 추진체계는 Git 기반 버전 관리, API 명세 공유, Docker Compose 로컬 환경, 기능별 테스트 및 시연을 통해 개발 결과를 통합하는 방식으로 운영하였다.
  
 
==설계==
 
==설계==
 
===설계사양===
 
===설계사양===
 
====제품의 요구사항====
 
====제품의 요구사항====
−
내용
+
{| class="wikitable"
 +
! 번호 !! 요구사항
 +
|-
 +
| R1 || 사용자는 Google 계정으로 약관 동의 후 회원가입 및 회원 탈퇴를 할 수 있으며, 로그인하여 자신이 참여한 여행 방 목록과 방 상세 정보를 조회할 수 있어야 한다.
 +
|-
 +
| R2 || 사용자는 방을 생성하고 초대 코드로 다른 사용자를 초대할 수 있어야 하며, HOST는 입장 요청 승인/거절, 멤버 추방, 방장 위임, 방 정보 수정, 방 삭제, 초대 코드 재발급을 할 수 있어야 한다.
 +
|-
 +
| R3 || 사용자는 지도에서 장소를 검색하고, 장소를 보관함에 저장하거나 채팅에 공유하고, 일정에 추가할 수 있어야 한다.
 +
|-
 +
| R4 || 사용자는 방 안에서 실시간 채팅을 주고받고, 읽음 위치와 안읽은 메시지 수를 확인할 수 있어야 한다.
 +
|-
 +
| R5 || 사용자는 일자별 여행 일정을 생성·삭제·이동하고, 일정 항목을 추가·삭제·순서 변경·다른 일자로 이동하며, 시간과 메모를 편집할 수 있어야 한다.
 +
|-
 +
| R6 || 사용자는 AI에게 여행 관련 질문을 보낼 수 있어야 하며, AI는 대화 요약, 장소 추천, 일정·북마크 기반 일반 여행 조언을 제공해야 한다.
 +
|-
 +
| R7 || AI는 비여행 질문이나 예약·결제·일정 직접 수정 같은 실행 권한 밖 요청을 수행했다고 답하지 않고, 가능한 안내만 제공해야 한다.
 +
|}
 +
 
 
====설계 사양====
 
====설계 사양====
−
내용
+
{| class="wikitable"
 +
! 구분 !! 설계 사양
 +
|-
 +
| 인증 및 방 관리 || Google OAuth, JWT, Refresh Token Rotation, Redis 기반 세션 관리를 적용한다. 방 생성 시 여행 기간 기준으로 일자별 초기 schedule을 자동 생성한다.
 +
|-
 +
| 지도·장소·보관함 || Google Places 검색은 pageSize 1~20 범위를 지원한다. 장소 미리보기 캐시는 Redis 24시간, 장소 상세 캐시는 Redis 6시간, 사진 URL은 Redis 10분 TTL을 적용한다.
 +
|-
 +
| 일정 편집 || 방의 schedule은 최소 1개를 유지하며 최대 30일을 초과하지 않도록 제한한다. 일정 항목은 order_index로 순서를 관리하고 Drag and Drop 후 연속되게 보정한다.
 +
|-
 +
| 이동 정보 || Google Routes 이동 정보는 DB에 저장하지 않고 Redis 10분 캐시와 5초 single-flight lock으로 중복 호출을 줄인다.
 +
|-
 +
| 실시간 협업 || STOMP topic으로 메시지, 멤버, presence, bookmark, schedule 변경 이벤트를 브로드캐스트한다. 채팅/장소 공유 전송은 사용자별 5/sec + 60/min rate limit을 적용한다.
 +
|-
 +
| AI 기능 || 일반 메시지 30개 누적 시 AI 서버가 구조화 summary를 갱신한다. AI 요청은 방별 QUEUED 최대 3개, 사용자별 같은 방 내 QUEUED/PROCESSING 최대 1개로 제한한다.
 +
|-
 +
| AI 응답 형식 || AI 장소 추천은 최대 3개의 장소 카드를 반환하며, intent는 place_recommendation, conversation_summary, travel_general_chat, unsupported로 고정한다.
 +
|}
 +
 
 +
{| class="wikitable"
 +
! 구분 !! 선택 기술 !! 적용 목적
 +
|-
 +
| Frontend || Next.js 16, React 19, Tailwind CSS, Zustand, TanStack Query, Framer Motion || 사용자 화면 구성, 클라이언트 상태 관리, 서버 상태 동기화, UI 애니메이션 구현
 +
|-
 +
| Backend || Java 21, Spring Boot 4, Spring Security, Spring Data JPA, Spring Data MongoDB, Spring Data Redis, Bucket4j, WebSocket/STOMP || REST API, 인증/인가, 도메인 데이터 처리, 실시간 협업 이벤트, rate limit 구현
 +
|-
 +
| AI Server || Python FastAPI, OpenAI API, Google Places API || 채팅 요약, intent 분기, 여행 맥락 기반 답변, 장소 추천 및 장소 정보 보완
 +
|-
 +
| Database || PostgreSQL 17, PostGIS, MongoDB 8, Redis 8 || 관계형 도메인 데이터, 채팅 메시지, 캐시, 세션, AI 요청 queue/lock 관리
 +
|-
 +
| 운영 환경 || Docker Compose, Dockerfile, Caddy, Prometheus, Grafana, Loki, Alloy || 서비스 컨테이너화, edge proxy, 로그 및 메트릭 관측성 확보
 +
|}
  
 
===개념설계안===
 
===개념설계안===
−
내용
+
[[파일:Uttae arch.jpeg|섬네일|가운데|800px|우때 전체 시스템 아키텍처]]
 +
 
 +
본 서비스는 Frontend, Spring Backend, AI Server를 분리한 구조로 설계한다. Frontend는 사용자 화면과 지도·채팅·일정·보관함 UI를 담당하고, Spring Backend는 인증, 권한, 원본 데이터 저장, 실시간 이벤트 전파의 중심 역할을 한다. AI Server는 FastAPI 기반의 독립 서버로 두어 요약 생성, intent 분기, context selection, Google Places 검색 및 최종 응답 생성을 담당한다.
 +
 
 +
{| class="wikitable"
 +
! 계층 !! 역할
 +
|-
 +
| Frontend || 지도 기반 장소 탐색, 채팅, 일정표, 보관함, 방 설정 등 사용자 인터페이스 제공
 +
|-
 +
| Spring Backend || 인증/인가, 방·멤버·장소·북마크·일정·채팅 도메인 처리, WebSocket/STOMP 이벤트 전파
 +
|-
 +
| AI Server || 채팅 요약, 여행 질문 응답, 장소 추천, 비지원 질문 거절
 +
|-
 +
| PostgreSQL/PostGIS || 사용자, 방, 멤버, 일정, 보관함 등 정형 데이터 저장
 +
|-
 +
| MongoDB || 채팅 메시지와 AI context summary 등 문서형 데이터 저장
 +
|-
 +
| Redis || refresh token, 접속 상태, 장소/경로 캐시, rate limit bucket, AI 요청 queue/lock 관리
 +
|}
  
 
===이론적 계산 및 시뮬레이션===
 
===이론적 계산 및 시뮬레이션===
−
내용
+
AI 응답 생성 시 전체 채팅 로그를 매번 전달하면 대화가 길어질수록 LLM 입력 토큰과 비용이 지속적으로 증가한다. 이를 줄이기 위해 본 서비스는 구조화 summary 1개, 마지막 요약 이후 delta, 최근 원문 메시지, 요청 메시지를 조합하여 최신 맥락을 유지한다.
 +
 
 +
{| class="wikitable"
 +
! 항목 !! 설계 기준 !! 기대 효과
 +
|-
 +
| 채팅 요약 주기 || 일반 메시지 30개 단위로 summary 갱신 || 요약 호출 빈도와 맥락 최신성의 균형 확보
 +
|-
 +
| AI 장소 추천 수 || 최대 3개 카드 반환 || UI 가독성 유지 및 응답 길이 제한
 +
|-
 +
| 장소 미리보기 캐시 || Redis 24시간 TTL || 반복 검색 비용 감소
 +
|-
 +
| 장소 상세 캐시 || Redis 6시간 TTL || 상세 조회 API 호출 절감
 +
|-
 +
| 사진 URL 캐시 || Redis 10분 TTL || Google Photo Media URL 신선도 유지
 +
|-
 +
| 경로 정보 캐시 || Redis 10분 TTL, 5초 single-flight lock || 중복 Routes API 호출 방지
 +
|-
 +
| 일정 길이 제한 || 최대 30일 || 과도한 일정 생성과 UI 복잡도 방지
 +
|}
 +
 
 +
이 구조를 통해 AI 입력 토큰 증가를 제한하고, 외부 API 호출 비용과 응답 지연을 줄이며, 실시간 협업 상황에서도 일정·채팅·AI 응답이 안정적으로 동기화되도록 설계하였다.
  
 
===상세설계 내용===
 
===상세설계 내용===
−
내용
+
[[파일:Uttae FE BE Flow.jpg|섬네일|가운데|800px|Frontend와 Backend 주요 기능 흐름]]
 +
 
 +
Frontend와 Backend는 REST API와 WebSocket/STOMP를 함께 사용한다. 사용자는 Google OAuth로 로그인하고, 방 생성·입장·장소 검색·보관함 저장·일정 편집·실시간 채팅 기능을 사용한다. Backend는 PostgreSQL/PostGIS, MongoDB, Redis에 각 데이터 성격에 맞게 정보를 저장하고, 변경 이벤트를 방 단위 topic으로 브로드캐스트한다.
 +
 
 +
{| class="wikitable"
 +
! 영역 !! 상세 설계
 +
|-
 +
| 인증 || 사용자는 Google OAuth로 로그인한다. Backend는 Access Token과 Refresh Token을 발급하며, Refresh Token은 Redis에 저장하여 rotation 방식으로 관리한다.
 +
|-
 +
| 방 관리 || 사용자는 여행 방을 생성하고 초대 코드로 팀원을 초대한다. HOST는 입장 요청 승인/거절, 멤버 추방, 방장 위임, 방 정보 수정, 방 삭제를 수행할 수 있다.
 +
|-
 +
| 장소 검색 || Backend가 Google Places API를 프록시하여 장소 검색, 장소 상세, 사진 URL을 제공한다. API 응답은 정책과 신선도를 고려해 Redis에 TTL 기반으로 캐시한다.
 +
|-
 +
| 보관함 || 사용자는 장소를 방 단위 보관함 카테고리에 저장한다. 보관함 변경 이벤트는 WebSocket/STOMP로 방 멤버에게 전파된다.
 +
|-
 +
| 일정 || 일정은 방의 여행 기간에 맞춰 일자별 schedule로 관리된다. 일정 항목은 order_index로 순서를 유지하며, Drag and Drop으로 같은 일자 또는 다른 일자로 이동할 수 있다.
 +
|-
 +
| 채팅 || 일반 채팅, 장소 공유, AI 요청, AI 응답, 시스템 메시지를 MongoDB messages 컬렉션에 저장한다. 각 메시지는 방별 sequence를 가지며 재접속 시 누락 메시지 복구에 사용된다.
 +
|-
 +
| 실시간 동기화 || 메시지, 멤버, presence, bookmark, schedule 변경 이벤트를 STOMP topic으로 브로드캐스트한다. 클라이언트는 이벤트 종류에 따라 필요한 범위만 재조회한다.
 +
|}
 +
 
 +
[[파일:Uttae AI Flow.jpg|섬네일|가운데|800px|AI 요청 처리 및 장소 추천 흐름]]
 +
 
 +
AI Server는 단순 LLM 호출 서버가 아니라 여행 계획용 오케스트레이션 서버로 설계하였다. 사용자의 자연어 요청을 intent로 분류하고, 현재 방의 채팅 요약, 최근 메시지, 일정, 북마크, 장소 메타데이터를 조합해 필요한 경우 Google Places 검색 도구를 호출한다. 이후 하드 필터와 소프트 랭킹을 거쳐 최종 응답과 최대 3개의 장소 추천 카드를 생성한다.
 +
 
 +
또한 예약·결제·일정 직접 수정처럼 시스템 권한 밖 요청은 수행하지 않고 안내만 제공하도록 응답 계약을 고정하였다.
  
 
==결과 및 평가==
 
==결과 및 평가==
 
===완료 작품의 소개===
 
===완료 작품의 소개===
 
====프로토타입 사진 혹은 작동 장면====
 
====프로토타입 사진 혹은 작동 장면====
−
내용
+
본 과제의 완료 작품은 배포된 웹 서비스 형태로 구현되었으며, 사용자는 [https://www.uttae.app 우때 바로가기] 에 접속하여 서비스를 사용할 수 있다. 서비스는 Google 로그인 후 여행 방을 생성하고, 지도 기반 장소 탐색, 장소 공유, 보관함 저장, 일정 편집, 실시간 채팅, AI 장소 추천 기능을 하나의 협업 공간에서 제공한다.
 +
 
 +
[[파일:uttae_01_landing.jpg|섬네일|가운데|800px|우때 서비스 랜딩 화면]]
 +
 
 +
[[파일:uttae_02_search.jpg|섬네일|가운데|800px|지도 기반 장소 탐색 화면]]
 +
 
 +
[[파일:uttae_03_schedule.jpg|섬네일|가운데|800px|일자별 일정 계획 화면]]
 +
 
 +
<gallery mode="packed" heights="800px">
 +
파일:uttae_04_chat.jpg|실시간 채팅 화면
 +
파일:uttae_05_ai.jpg|AI 장소 추천 화면
 +
</gallery>
 +
 
 +
{| class="wikitable"
 +
! 구분 !! 구현 내용
 +
|-
 +
| 지도 기반 장소 탐색 || Google Places API를 활용하여 장소를 검색하고 상세 정보를 확인할 수 있다.
 +
|-
 +
| 보관함 || 여행 후보지를 카테고리별로 저장하고 팀원과 함께 관리할 수 있다.
 +
|-
 +
| 일정 계획 || 일자별 일정에 장소를 추가하고 Drag and Drop으로 순서를 조정할 수 있다.
 +
|-
 +
| 실시간 채팅 || WebSocket/STOMP 기반으로 방 멤버 간 실시간 채팅과 장소 공유가 가능하다.
 +
|-
 +
| AI 추천 || 채팅 요약, 일정, 북마크 맥락을 바탕으로 여행 관련 답변과 장소 추천을 제공한다.
 +
|}
 +
 
 
====포스터====
 
====포스터====
−
내용
+
홍보 포스터는 서비스의 핵심 가치인 “지도, 채팅, 일정, AI 추천을 한 공간에서 제공하는 협업형 여행 계획 플랫폼”을 중심으로 구성하였다. 포스터에는 서비스 소개, 주요 기능, 사용 흐름, 기대효과를 포함하여 사용자가 서비스의 목적과 차별점을 빠르게 이해할 수 있도록 하였다.
 +
 
 +
[[파일:Uttae poster.jpg|섬네일|가운데|800px|우때 홍보 포스터]]
  
 
===관련사업비 내역서===
 
===관련사업비 내역서===
−
내용
+
본 과제의 개발 사업비는 디자인 도구, AI API, 서버 및 배포 환경, 도메인 구매 등에 사용되었다.
 +
 
 +
{| class="wikitable"
 +
! 구분 !! 항목 !! 수량 !! 단가(천원) !! 금액(천원) !! 비고
 +
|-
 +
| 직접 개발비 || Figma Professional 구독 || 1 || 33.9 || 33.9 || 화면 설계 및 프로토타입 제작
 +
|-
 +
| 직접 개발비 || ChatGPT 구독 || 1 || 29.0 || 29.0 || 개발 보조 및 문서화
 +
|-
 +
| 직접 개발비 || Claude 구독 || 3 || 69.4 || 209.1 || 3건
 +
|-
 +
| 직접 개발비 || OpenAI API 사용료 || 3 || 11.0 || 34.1 || AI 요약 및 추천 기능 개발
 +
|-
 +
| 직접 개발비 || Claude API 사용료 || 1 || 8.3 || 8.3 || AI 응답 비교 및 개발 보조
 +
|-
 +
| 직접 개발비 || 서버비 및 GCP 사용료 || 3 || 82.7 || 248.0 || 서버 운영 및 지도 API 사용
 +
|-
 +
| 직접 개발비 || 도메인 구매 || 2 || 22.0 || 44.0 || 서비스 도메인 구매
 +
|-
 +
! colspan="4" | 합계
 +
! 606.4
 +
!
 +
|}
  
 
===완료작품의 평가===
 
===완료작품의 평가===
−
내용
+
{| class="wikitable"
 +
! 번호 !! 평가항목 !! 평가방법 !! 적용기준 !! 개발목표치 !! 비중(%) !! 평가결과
 +
|-
 +
| 1 || 사용자 인증 및 방 관리 || Google OAuth 로그인, JWT 발급, refresh token rotation, 방 생성/조회/입장 요청/승인 API 동작 확인 || 인증된 사용자만 방 기능 접근 가능, HOST 권한 기능 분리 || 로그인, 토큰 갱신, 방 생성, 초대 코드 입장, 승인/거절 기능 구현 || 15 || 달성
 +
|-
 +
| 2 || 장소 검색 및 보관함 기능 || Google Places 검색, 장소 상세 조회, 장소 저장/삭제, 카테고리 변경 기능 확인 || 장소 검색 pageSize 1~20, 장소 미리보기 Redis 24시간, 상세 6시간 캐시 적용 || 지도 기반 장소 탐색, 장소 상세, 보관함 카테고리 관리 구현 || 20 || 달성
 +
|-
 +
| 3 || 일정 편집 및 이동 정보 기능 || 일정 생성/삭제/이동, 일정 항목 추가/삭제/순서 변경, Routes 조회 확인 || 방 일정 최대 30일, 최소 1개 일정 유지, 경로 정보 Redis 10분 캐시 || 일자별 일정표와 Drag and Drop 기반 일정 항목 편집 구현 || 20 || 달성
 +
|-
 +
| 4 || 실시간 채팅 및 협업 동기화 || WebSocket/STOMP 메시지 송수신, 읽음 상태, 재접속 동기화, 시스템 메시지 확인 || 채팅/장소 공유 5/sec + 60/min rate limit, MongoDB sequence 기반 메시지 저장 || 일반 채팅, 장소 공유, AI 메시지, 읽음 위치, 실시간 이벤트 구현 || 20 || 달성
 +
|-
 +
| 5 || AI 요약 및 여행 추천 기능 || AI summary API, AI chat plan API, 비여행 질문 거절, 장소 카드 응답 확인 || 일반 메시지 30개 단위 요약, AI 추천 장소 최대 3개, 고정 intent 4종 적용 || 대화 요약, 여행 일반 답변, 장소 추천, unsupported 응답 구현 || 25 || 달성
 +
|}
 +
 
 +
추가로 Google Analytics를 통해 서비스 사용 현황을 확인하였다. 2026년 6월 16일 기준 활성 사용자는 87명이며, 이벤트 발생 수는 약 2.7천 건이다. 또한 2026년 6월 13일 기준 Google Form 서비스 만족도 조사에 총 28명이 참여하였다.
  
 
===향후계획===
 
===향후계획===
−
내용
+
향후에는 실제 사용자 피드백을 기반으로 AI 장소 추천 품질을 개선하고, 모바일 환경에서 지도·채팅·일정·보관함을 더 자연스럽게 전환할 수 있도록 반응형 UX를 고도화할 계획이다.
 +
 
 +
{| class="wikitable"
 +
! 구분 !! 향후 계획
 +
|-
 +
| AI 추천 고도화 || 사용자 피드백을 기반으로 prompt와 ranking 기준을 개선한다.
 +
|-
 +
| 모바일 UX 개선 || 지도, 채팅, 일정, 보관함 화면을 모바일에서 더 자연스럽게 전환할 수 있도록 개선한다.
 +
|-
 +
| 동선 최적화 || 일정 항목 간 이동 시간뿐 아니라 전체 여행 동선 최적화와 추천 순서 조정 기능을 추가한다.
 +
|-
 +
| 공동 의사결정 || 팀원 투표, 선호도 표시, 후보지 우선순위 기능을 추가한다.
 +
|-
 +
| 여행 부가 기능 || 숙소 예약, 비행기 예매 등 여행 준비에 필요한 부가 기능을 검토한다.
 +
|-
 +
| 운영 안정성 || 로그, 메트릭, 장애 알림, 대시보드를 고도화하여 운영 환경의 안정성을 높인다.
 +
|}
  
 
===특허 출원 내용===
 
===특허 출원 내용===
−
내용
+
본 과제는 현재 별도의 특허 출원을 진행하지 않았다. 다만 개발 과정에서 조사한 선행특허와 비교했을 때, 향후 권리화 가능성이 있는 요소는 다음과 같다.
 +
 
 +
{| class="wikitable"
 +
! 구분 !! 내용
 +
|-
 +
| 출원 여부 || 현재 미출원
 +
|-
 +
| 관련 선행특허 || KR20230072017A, US10445666B1, US20120191341A1, US8719251B1, WO2023073505A1
 +
|-
 +
| 권리화 검토 대상 1 || 채팅 요약 기반 여행방 컨텍스트 선택 구조
 +
|-
 +
| 권리화 검토 대상 2 || 일정·북마크 정보를 활용한 AI 장소 추천 방식
 +
|-
 +
| 권리화 검토 대상 3 || 실시간 협업 일정 변경 이벤트와 AI 응답을 연동하는 구조
 +
|}

2026년 6월 18일 (목) 22:36 기준 최신판

프로젝트 개요

기술개발 과제

국문 : 우때

영문 : Uttae

과제 팀명

우리어때

지도교수

김민호 교수님

개발기간

2026년 3월 ~ 2026년 6월 (총 4개월)

구성원 소개

서울시립대학교 컴퓨터과학부 2020920007 김민형(팀장)

서울시립대학교 컴퓨터과학부 2020920020 문재영

서울시립대학교 컴퓨터과학부 2021920029 박주영

서울시립대학교 컴퓨터과학부 2021430021 송희영

서론

개발 과제의 개요

개발 과제 요약

우때(Uttae)는 여러 사용자가 하나의 여행 방에서 지도, 채팅, 보관함, 일정표를 함께 사용하며 여행 계획을 세우는 협업형 여행 계획 플랫폼이다.

사용자는 Google 계정으로 로그인한 뒤 여행 방을 생성하고, 초대 코드로 팀원을 초대하며, 방 안에서 장소 검색, 장소 공유, 후보지 보관, 일자별 일정 편집을 실시간으로 수행할 수 있다. 또한 AI 서버는 채팅 요약, 여행 관련 질문 응답, Google Places 기반 장소 추천, 비여행 질문 거절을 담당한다.

개발 과제의 배경

여행 계획은 장소 검색, 후보 저장, 팀원 의견 조율, 일정 배치, 이동 시간 확인이 여러 앱과 채팅방에 흩어지기 쉬워 협업 비용이 크다. 일반 메신저는 의견 조율에는 편리하지만 장소 카드, 지도 위치, 일정표, 후보지 분류를 구조화하기 어렵고, 지도 앱은 장소 탐색에는 강하지만 팀 단위 의사결정 흐름을 담기 어렵다.

본 서비스는 지도, 채팅, 일정, 보관함, AI를 하나의 방 단위 협업 모델로 통합하여 여행 계획의 탐색, 논의, 결정, 일정화를 한 흐름 안에서 수행하도록 돕는다.

개발 과제의 목표 및 내용

구분 주요 내용
인증 및 방 관리 Google OAuth, JWT, Refresh Token Rotation, Redis 기반 세션 관리, 초대 코드, 입장 승인/거절, 방장 위임, 멤버 관리
지도·장소 기능 Google Places/Routes API 기반 장소 검색, 장소 상세, 사진 URL, 이동 정보 조회, Redis 캐시 적용
협업 기능 WebSocket/STOMP 기반 실시간 채팅, 일정 변경, 보관함 변경, 멤버 상태 동기화
일정 기능 일자별 일정 생성·삭제·이동, Drag and Drop 기반 순서 변경, 시간·메모 편집
AI 기능 채팅 요약, 여행 질문 응답, 장소 추천, 일정·북마크 기반 맥락 반영, 비지원 질문 거절

관련 기술의 현황

관련 기술의 현황 및 분석(State of art)

  • 전 세계적인 기술현황

최근 생성형 AI 서비스는 단순 질의응답을 넘어 사용자의 의도를 분석하고 외부 API나 도구를 선택해 실행하는 Agentic Workflow 형태로 발전하고 있다. OpenAI Function Calling, LangChain, LangGraph 등은 복잡한 다단계 추론과 도구 호출을 지원한다.

여행·모빌리티 서비스에서는 Google Places API, Routes API 등을 활용한 장소 검색, 상세 정보 조회, 이동 시간 계산, 위치 기반 추천 기술이 핵심 요소로 자리 잡고 있다. 또한 다수 사용자가 동시에 참여하는 협업 서비스에서는 WebSocket과 STOMP 기반 Pub/Sub 구조가 실시간 동기화 기술로 널리 사용된다.

  • 특허조사 및 특허 전략 분석
특허 내용 시사점
KR20230072017A AI 기반 맞춤형 여행 일정 추천 일반 여행 추천은 선행기술이 많음
US10445666B1 개인 선호 기반 여행 일정 추천 개인화 일정 추천 영역과 차별화 필요
US20120191341A1 / US8719251B1 협업형 여행 계획 및 검색 결과 공유 채팅 기반 협업 구조와의 차별화 필요
WO2023073505A1 대화형 여행 계획 인터페이스 자연어 기반 여행 UI와의 차별화 필요

본 과제의 특허 전략은 범용 여행 추천보다 협업형 대화 맥락 처리, 실시간 일정·보관함 반영, 채팅 요약 기반 AI 장소 추천에 초점을 맞추는 방향이 적절하다.

  • 기술 로드맵
단계 개발 내용
1단계 Google OAuth 로그인, 방 생성, 초대 코드 입장, 멤버 관리, 기본 장소 검색과 일정 편집
2단계 MongoDB 채팅 저장, WebSocket/STOMP 브로드캐스트, 읽음 위치, 재접속 복구
3단계 보관함 카테고리, 장소 공유 메시지, Drag and Drop 일정 편집, 이동 정보 Redis 캐시
4단계 AI 요청 큐, 방별 lock, 채팅 30개 단위 자동 요약, 장소 추천과 비지원 질문 거절
5단계 Docker Compose 배포, Caddy edge proxy, Prometheus/Grafana/Loki/Alloy 관측성 고도화

시장상황에 대한 분석

  • 경쟁제품 조사 비교
제품 강점 한계
Google Maps 글로벌 POI/경로 데이터, 자연어 내비게이션 고도화 여행 그룹 합의 중심 워크플로우는 약함
Wanderlog 일정·지도·협업·예산 기능 통합 채팅방 멘션 기반 실시간 공동 의사결정은 상대적으로 약함
TripIt 예약/여정 자동 수집 및 정리 강점 실시간 그룹 협업과 지도 연동 추천은 제한적
  • 마케팅 전략 제시

주요 대상은 친구, 가족, 동아리, 팀 단위로 여행을 준비하는 소규모 그룹 사용자이다. 초기 확산은 대학생 지인, 동아리, 학생회, 여행 커뮤니티처럼 공동 의사결정이 많은 사용 사례를 중심으로 진행한다.

서비스 메시지는 “지도와 채팅을 오가며 여행 계획을 정리하는 불편함을 줄이고, 한 화면에서 후보 저장·일정 배치·AI 요약을 제공한다”는 점에 집중한다.

개발과제의 기대효과

기술적 기대효과

Frontend, Spring Backend, AI Server를 분리하여 사용자 상태 저장과 AI 판단을 독립적으로 확장할 수 있다. PostgreSQL/PostGIS, MongoDB, Redis를 목적별로 분리해 관계형 도메인 데이터, 채팅 타임라인, 캐시·큐·세션 데이터를 각각 적합한 저장소에 배치한다.

또한 WebSocket/STOMP 기반 실시간 동기화와 OpenAI structured output 기반 응답 계약을 결합하여, 지도·채팅·일정·AI 추천이 안정적으로 연결되는 협업형 여행 계획 구조를 구현한다.

경제적, 사회적 기대 및 파급효과

여행 계획에 필요한 장소 탐색, 정보 공유, 일정 조율 시간을 줄여 소규모 그룹 여행 준비의 생산성을 높일 수 있다. 대화와 일정이 분리되지 않아 의사결정 이력을 보존하고, 늦게 합류한 팀원도 AI 요약과 후보지를 통해 빠르게 맥락을 따라갈 수 있다.

나아가 지도·채팅·AI를 결합한 협업 경험은 여행뿐 아니라 모임 장소 선정, 현장 답사, 팀 프로젝트 일정 조율 등으로 확장될 수 있다.

기술개발 일정 및 추진체계

개발 일정

기간 주요 개발 내용
2026년 3월 기획, 요구사항 정의, 화면 설계, 기술 스택 선정
2026년 4월 인증, 방 생성, 초대 코드, 장소 검색, 기본 채팅 기능 구현
2026년 5월 보관함, 일정 편집, Drag and Drop, WebSocket 실시간 동기화 구현
2026년 6월 AI 요약·추천, 운영 배포, 모니터링, 사용자 테스트 및 최종 보고서 정리

구성원 및 추진체계

구성원 역할 담당 업무
김민형, 박주영 Backend Spring Boot 기반 REST API, 인증/인가, WebSocket/STOMP 실시간 이벤트 개발 등
송희영 Frontend Next.js 기반 화면 구현, 지도·채팅·일정·보관함 UI, 상태 관리, API 연동 등
문재영 AI Server FastAPI 기반 AI API, 채팅 요약, intent 분기, 장소 추천, OpenAI 및 Google Places 연동 등

전체 추진체계는 Git 기반 버전 관리, API 명세 공유, Docker Compose 로컬 환경, 기능별 테스트 및 시연을 통해 개발 결과를 통합하는 방식으로 운영하였다.

설계

설계사양

제품의 요구사항

번호 요구사항
R1 사용자는 Google 계정으로 약관 동의 후 회원가입 및 회원 탈퇴를 할 수 있으며, 로그인하여 자신이 참여한 여행 방 목록과 방 상세 정보를 조회할 수 있어야 한다.
R2 사용자는 방을 생성하고 초대 코드로 다른 사용자를 초대할 수 있어야 하며, HOST는 입장 요청 승인/거절, 멤버 추방, 방장 위임, 방 정보 수정, 방 삭제, 초대 코드 재발급을 할 수 있어야 한다.
R3 사용자는 지도에서 장소를 검색하고, 장소를 보관함에 저장하거나 채팅에 공유하고, 일정에 추가할 수 있어야 한다.
R4 사용자는 방 안에서 실시간 채팅을 주고받고, 읽음 위치와 안읽은 메시지 수를 확인할 수 있어야 한다.
R5 사용자는 일자별 여행 일정을 생성·삭제·이동하고, 일정 항목을 추가·삭제·순서 변경·다른 일자로 이동하며, 시간과 메모를 편집할 수 있어야 한다.
R6 사용자는 AI에게 여행 관련 질문을 보낼 수 있어야 하며, AI는 대화 요약, 장소 추천, 일정·북마크 기반 일반 여행 조언을 제공해야 한다.
R7 AI는 비여행 질문이나 예약·결제·일정 직접 수정 같은 실행 권한 밖 요청을 수행했다고 답하지 않고, 가능한 안내만 제공해야 한다.

설계 사양

구분 설계 사양
인증 및 방 관리 Google OAuth, JWT, Refresh Token Rotation, Redis 기반 세션 관리를 적용한다. 방 생성 시 여행 기간 기준으로 일자별 초기 schedule을 자동 생성한다.
지도·장소·보관함 Google Places 검색은 pageSize 1~20 범위를 지원한다. 장소 미리보기 캐시는 Redis 24시간, 장소 상세 캐시는 Redis 6시간, 사진 URL은 Redis 10분 TTL을 적용한다.
일정 편집 방의 schedule은 최소 1개를 유지하며 최대 30일을 초과하지 않도록 제한한다. 일정 항목은 order_index로 순서를 관리하고 Drag and Drop 후 연속되게 보정한다.
이동 정보 Google Routes 이동 정보는 DB에 저장하지 않고 Redis 10분 캐시와 5초 single-flight lock으로 중복 호출을 줄인다.
실시간 협업 STOMP topic으로 메시지, 멤버, presence, bookmark, schedule 변경 이벤트를 브로드캐스트한다. 채팅/장소 공유 전송은 사용자별 5/sec + 60/min rate limit을 적용한다.
AI 기능 일반 메시지 30개 누적 시 AI 서버가 구조화 summary를 갱신한다. AI 요청은 방별 QUEUED 최대 3개, 사용자별 같은 방 내 QUEUED/PROCESSING 최대 1개로 제한한다.
AI 응답 형식 AI 장소 추천은 최대 3개의 장소 카드를 반환하며, intent는 place_recommendation, conversation_summary, travel_general_chat, unsupported로 고정한다.
구분 선택 기술 적용 목적
Frontend Next.js 16, React 19, Tailwind CSS, Zustand, TanStack Query, Framer Motion 사용자 화면 구성, 클라이언트 상태 관리, 서버 상태 동기화, UI 애니메이션 구현
Backend Java 21, Spring Boot 4, Spring Security, Spring Data JPA, Spring Data MongoDB, Spring Data Redis, Bucket4j, WebSocket/STOMP REST API, 인증/인가, 도메인 데이터 처리, 실시간 협업 이벤트, rate limit 구현
AI Server Python FastAPI, OpenAI API, Google Places API 채팅 요약, intent 분기, 여행 맥락 기반 답변, 장소 추천 및 장소 정보 보완
Database PostgreSQL 17, PostGIS, MongoDB 8, Redis 8 관계형 도메인 데이터, 채팅 메시지, 캐시, 세션, AI 요청 queue/lock 관리
운영 환경 Docker Compose, Dockerfile, Caddy, Prometheus, Grafana, Loki, Alloy 서비스 컨테이너화, edge proxy, 로그 및 메트릭 관측성 확보

개념설계안

우때 전체 시스템 아키텍처

본 서비스는 Frontend, Spring Backend, AI Server를 분리한 구조로 설계한다. Frontend는 사용자 화면과 지도·채팅·일정·보관함 UI를 담당하고, Spring Backend는 인증, 권한, 원본 데이터 저장, 실시간 이벤트 전파의 중심 역할을 한다. AI Server는 FastAPI 기반의 독립 서버로 두어 요약 생성, intent 분기, context selection, Google Places 검색 및 최종 응답 생성을 담당한다.

계층 역할
Frontend 지도 기반 장소 탐색, 채팅, 일정표, 보관함, 방 설정 등 사용자 인터페이스 제공
Spring Backend 인증/인가, 방·멤버·장소·북마크·일정·채팅 도메인 처리, WebSocket/STOMP 이벤트 전파
AI Server 채팅 요약, 여행 질문 응답, 장소 추천, 비지원 질문 거절
PostgreSQL/PostGIS 사용자, 방, 멤버, 일정, 보관함 등 정형 데이터 저장
MongoDB 채팅 메시지와 AI context summary 등 문서형 데이터 저장
Redis refresh token, 접속 상태, 장소/경로 캐시, rate limit bucket, AI 요청 queue/lock 관리

이론적 계산 및 시뮬레이션

AI 응답 생성 시 전체 채팅 로그를 매번 전달하면 대화가 길어질수록 LLM 입력 토큰과 비용이 지속적으로 증가한다. 이를 줄이기 위해 본 서비스는 구조화 summary 1개, 마지막 요약 이후 delta, 최근 원문 메시지, 요청 메시지를 조합하여 최신 맥락을 유지한다.

항목 설계 기준 기대 효과
채팅 요약 주기 일반 메시지 30개 단위로 summary 갱신 요약 호출 빈도와 맥락 최신성의 균형 확보
AI 장소 추천 수 최대 3개 카드 반환 UI 가독성 유지 및 응답 길이 제한
장소 미리보기 캐시 Redis 24시간 TTL 반복 검색 비용 감소
장소 상세 캐시 Redis 6시간 TTL 상세 조회 API 호출 절감
사진 URL 캐시 Redis 10분 TTL Google Photo Media URL 신선도 유지
경로 정보 캐시 Redis 10분 TTL, 5초 single-flight lock 중복 Routes API 호출 방지
일정 길이 제한 최대 30일 과도한 일정 생성과 UI 복잡도 방지

이 구조를 통해 AI 입력 토큰 증가를 제한하고, 외부 API 호출 비용과 응답 지연을 줄이며, 실시간 협업 상황에서도 일정·채팅·AI 응답이 안정적으로 동기화되도록 설계하였다.

상세설계 내용

Frontend와 Backend 주요 기능 흐름

Frontend와 Backend는 REST API와 WebSocket/STOMP를 함께 사용한다. 사용자는 Google OAuth로 로그인하고, 방 생성·입장·장소 검색·보관함 저장·일정 편집·실시간 채팅 기능을 사용한다. Backend는 PostgreSQL/PostGIS, MongoDB, Redis에 각 데이터 성격에 맞게 정보를 저장하고, 변경 이벤트를 방 단위 topic으로 브로드캐스트한다.

영역 상세 설계
인증 사용자는 Google OAuth로 로그인한다. Backend는 Access Token과 Refresh Token을 발급하며, Refresh Token은 Redis에 저장하여 rotation 방식으로 관리한다.
방 관리 사용자는 여행 방을 생성하고 초대 코드로 팀원을 초대한다. HOST는 입장 요청 승인/거절, 멤버 추방, 방장 위임, 방 정보 수정, 방 삭제를 수행할 수 있다.
장소 검색 Backend가 Google Places API를 프록시하여 장소 검색, 장소 상세, 사진 URL을 제공한다. API 응답은 정책과 신선도를 고려해 Redis에 TTL 기반으로 캐시한다.
보관함 사용자는 장소를 방 단위 보관함 카테고리에 저장한다. 보관함 변경 이벤트는 WebSocket/STOMP로 방 멤버에게 전파된다.
일정 일정은 방의 여행 기간에 맞춰 일자별 schedule로 관리된다. 일정 항목은 order_index로 순서를 유지하며, Drag and Drop으로 같은 일자 또는 다른 일자로 이동할 수 있다.
채팅 일반 채팅, 장소 공유, AI 요청, AI 응답, 시스템 메시지를 MongoDB messages 컬렉션에 저장한다. 각 메시지는 방별 sequence를 가지며 재접속 시 누락 메시지 복구에 사용된다.
실시간 동기화 메시지, 멤버, presence, bookmark, schedule 변경 이벤트를 STOMP topic으로 브로드캐스트한다. 클라이언트는 이벤트 종류에 따라 필요한 범위만 재조회한다.
AI 요청 처리 및 장소 추천 흐름

AI Server는 단순 LLM 호출 서버가 아니라 여행 계획용 오케스트레이션 서버로 설계하였다. 사용자의 자연어 요청을 intent로 분류하고, 현재 방의 채팅 요약, 최근 메시지, 일정, 북마크, 장소 메타데이터를 조합해 필요한 경우 Google Places 검색 도구를 호출한다. 이후 하드 필터와 소프트 랭킹을 거쳐 최종 응답과 최대 3개의 장소 추천 카드를 생성한다.

또한 예약·결제·일정 직접 수정처럼 시스템 권한 밖 요청은 수행하지 않고 안내만 제공하도록 응답 계약을 고정하였다.

결과 및 평가

완료 작품의 소개

프로토타입 사진 혹은 작동 장면

본 과제의 완료 작품은 배포된 웹 서비스 형태로 구현되었으며, 사용자는 우때 바로가기 에 접속하여 서비스를 사용할 수 있다. 서비스는 Google 로그인 후 여행 방을 생성하고, 지도 기반 장소 탐색, 장소 공유, 보관함 저장, 일정 편집, 실시간 채팅, AI 장소 추천 기능을 하나의 협업 공간에서 제공한다.

우때 서비스 랜딩 화면
지도 기반 장소 탐색 화면
일자별 일정 계획 화면

  • 실시간 채팅 화면

  • AI 장소 추천 화면

구분 구현 내용
지도 기반 장소 탐색 Google Places API를 활용하여 장소를 검색하고 상세 정보를 확인할 수 있다.
보관함 여행 후보지를 카테고리별로 저장하고 팀원과 함께 관리할 수 있다.
일정 계획 일자별 일정에 장소를 추가하고 Drag and Drop으로 순서를 조정할 수 있다.
실시간 채팅 WebSocket/STOMP 기반으로 방 멤버 간 실시간 채팅과 장소 공유가 가능하다.
AI 추천 채팅 요약, 일정, 북마크 맥락을 바탕으로 여행 관련 답변과 장소 추천을 제공한다.

포스터

홍보 포스터는 서비스의 핵심 가치인 “지도, 채팅, 일정, AI 추천을 한 공간에서 제공하는 협업형 여행 계획 플랫폼”을 중심으로 구성하였다. 포스터에는 서비스 소개, 주요 기능, 사용 흐름, 기대효과를 포함하여 사용자가 서비스의 목적과 차별점을 빠르게 이해할 수 있도록 하였다.

우때 홍보 포스터

관련사업비 내역서

본 과제의 개발 사업비는 디자인 도구, AI API, 서버 및 배포 환경, 도메인 구매 등에 사용되었다.

구분 항목 수량 단가(천원) 금액(천원) 비고
직접 개발비 Figma Professional 구독 1 33.9 33.9 화면 설계 및 프로토타입 제작
직접 개발비 ChatGPT 구독 1 29.0 29.0 개발 보조 및 문서화
직접 개발비 Claude 구독 3 69.4 209.1 3건
직접 개발비 OpenAI API 사용료 3 11.0 34.1 AI 요약 및 추천 기능 개발
직접 개발비 Claude API 사용료 1 8.3 8.3 AI 응답 비교 및 개발 보조
직접 개발비 서버비 및 GCP 사용료 3 82.7 248.0 서버 운영 및 지도 API 사용
직접 개발비 도메인 구매 2 22.0 44.0 서비스 도메인 구매
합계 606.4

완료작품의 평가

번호 평가항목 평가방법 적용기준 개발목표치 비중(%) 평가결과
1 사용자 인증 및 방 관리 Google OAuth 로그인, JWT 발급, refresh token rotation, 방 생성/조회/입장 요청/승인 API 동작 확인 인증된 사용자만 방 기능 접근 가능, HOST 권한 기능 분리 로그인, 토큰 갱신, 방 생성, 초대 코드 입장, 승인/거절 기능 구현 15 달성
2 장소 검색 및 보관함 기능 Google Places 검색, 장소 상세 조회, 장소 저장/삭제, 카테고리 변경 기능 확인 장소 검색 pageSize 1~20, 장소 미리보기 Redis 24시간, 상세 6시간 캐시 적용 지도 기반 장소 탐색, 장소 상세, 보관함 카테고리 관리 구현 20 달성
3 일정 편집 및 이동 정보 기능 일정 생성/삭제/이동, 일정 항목 추가/삭제/순서 변경, Routes 조회 확인 방 일정 최대 30일, 최소 1개 일정 유지, 경로 정보 Redis 10분 캐시 일자별 일정표와 Drag and Drop 기반 일정 항목 편집 구현 20 달성
4 실시간 채팅 및 협업 동기화 WebSocket/STOMP 메시지 송수신, 읽음 상태, 재접속 동기화, 시스템 메시지 확인 채팅/장소 공유 5/sec + 60/min rate limit, MongoDB sequence 기반 메시지 저장 일반 채팅, 장소 공유, AI 메시지, 읽음 위치, 실시간 이벤트 구현 20 달성
5 AI 요약 및 여행 추천 기능 AI summary API, AI chat plan API, 비여행 질문 거절, 장소 카드 응답 확인 일반 메시지 30개 단위 요약, AI 추천 장소 최대 3개, 고정 intent 4종 적용 대화 요약, 여행 일반 답변, 장소 추천, unsupported 응답 구현 25 달성

추가로 Google Analytics를 통해 서비스 사용 현황을 확인하였다. 2026년 6월 16일 기준 활성 사용자는 87명이며, 이벤트 발생 수는 약 2.7천 건이다. 또한 2026년 6월 13일 기준 Google Form 서비스 만족도 조사에 총 28명이 참여하였다.

향후계획

향후에는 실제 사용자 피드백을 기반으로 AI 장소 추천 품질을 개선하고, 모바일 환경에서 지도·채팅·일정·보관함을 더 자연스럽게 전환할 수 있도록 반응형 UX를 고도화할 계획이다.

구분 향후 계획
AI 추천 고도화 사용자 피드백을 기반으로 prompt와 ranking 기준을 개선한다.
모바일 UX 개선 지도, 채팅, 일정, 보관함 화면을 모바일에서 더 자연스럽게 전환할 수 있도록 개선한다.
동선 최적화 일정 항목 간 이동 시간뿐 아니라 전체 여행 동선 최적화와 추천 순서 조정 기능을 추가한다.
공동 의사결정 팀원 투표, 선호도 표시, 후보지 우선순위 기능을 추가한다.
여행 부가 기능 숙소 예약, 비행기 예매 등 여행 준비에 필요한 부가 기능을 검토한다.
운영 안정성 로그, 메트릭, 장애 알림, 대시보드를 고도화하여 운영 환경의 안정성을 높인다.

특허 출원 내용

본 과제는 현재 별도의 특허 출원을 진행하지 않았다. 다만 개발 과정에서 조사한 선행특허와 비교했을 때, 향후 권리화 가능성이 있는 요소는 다음과 같다.

구분 내용
출원 여부 현재 미출원
관련 선행특허 KR20230072017A, US10445666B1, US20120191341A1, US8719251B1, WO2023073505A1
권리화 검토 대상 1 채팅 요약 기반 여행방 컨텍스트 선택 구조
권리화 검토 대상 2 일정·북마크 정보를 활용한 AI 장소 추천 방식
권리화 검토 대상 3 실시간 협업 일정 변경 이벤트와 AI 응답을 연동하는 구조
원본 주소 "https://capstone.uos.ac.kr/cdc/index.php?title=1분반-우리어때&oldid=13023"