[2026 SUMMER DEV] AI 기반 플로깅 경로 추천 서비스 ‘플로버’, 플로버팀

프로젝트 소개

플로버팀은 공공데이터를 활용한 상권 밀집도 분석을 통해 AI 기반 플로깅 경로를 추천해주는 서비스인 “플로버” 앱을 개발하였습니다.

팀원 소개

플로버팀은 AI 상현님, AI 지환님, BE 재륜님, FE 영현님, FE 태은님, DE 아현님으로 구성되어 있습니다.

인터뷰

Q. 프로젝트를 소개해주세요!

상현 : 저희 팀은 5 소프트웨어공학과, 1 국악학과로 이뤄진 팀입니다. 저희는 이번에 단순 서비스를 만들기 보단, 공모전과 실사용자 유치를 위한 개발을 해보기로 이야기를 했었고, 여러 도메인에서 겪는 문제들을 찾으려고 했었습니다.

그 과정 속에서, 플로깅하는 여러 단체에서 빈번히 말하는 쓰레기 위치를 못 찾는 문제, 초행길에 동선 짜는 문제들을 해결하고자 “플로버”라는 앱을 기획하고 개발하게 되었습니다.

Q. 프로젝트 하면서 어떤 문제를 겪었나요?

상현 : 기획을 하는데 있어서 가장 큰 어려움을 겪었던 것 같습니다. 어떤 도메인으로 할지, 어떤 가치를 사용자에게 제공할지 고민하는 과정이 3주 가량 이어졌었고, 간신히 환경 도메인과 관련된 플로깅 서비스를 기획하게 됐었습니다.

플로깅 서비스를 기획하면서도 사용자들에게 어떤 가치를 제공해줄지 많은 논의가 이뤄졌습니다. 저는 사용자들로부터 데이터를 수집해서 추후 경로 추천 기능을 발전시킬 방법을 추가하고 싶었으나, 플로깅 하는 과정에서 사용자가 어떤 쓰레기를 주웠는지 그때 그때 기록하는게 사용자 친화적이지 않다는 팀간의 논의에 따라 해당 기능이 기각 됐었습니다.

하지만 이걸 다른 방향성으로 전환했었는데요, 플로깅을 하고 있지 않는 사용자가 길거리에 떨어진 쓰레기를 제보하는 기능을 도입하여, 사용자가 제보한 위치, 쓰레기의 종류와 갯수를 분류하여 DB에 저장하는 방식을 사용했었습니다.

덕분에 팀 내부 큰 불화 없이 서로가 추구하는 문제 해결 방법을 채택할 수 있었습니다.

Q. 프로젝트를 하기 전 후 달라진 점이 있다면?

상현 : 서비스를 바라보는 관점을 다르게 가지게 된 것 같습니다.

그 전까지 진행했던 프로젝트는 근거 없이 무작정 기획, 개발을 하는 프로세스로 이뤄졌었습니다. 그러나 이번에는 6명이라는 인원이 모인 만큼 문제 파악, 원인 분석, 관계자 인터뷰, 경쟁사 조사 등을 앞서 진행해서 체계적으로 프로젝트를 이끌어나갈 수 있었습니다.

특히 이번 프로젝트에서 팀장을 맡으면서 개발뿐만 아니라 PM 역할도 비슷하게 했던 것 같습니다. 아현님이 많은 도움을 주셨지만 팀원들 일정 조율이나 프로젝트 진행 관리하는게 많이 힘들었던 것 같아요. 그치만 단순 기능 개발에서 멈추지 않고, 여러 경험을 해보면서 저만의 가치를 쌓아가는 경험을 했던 것 같아서 많은걸 얻어갈 수 있는 한 학기였습니다.

Q. 프로젝트를 시작하는 팀에게 전해줄 꿀팁을 말해주세요!

상현 : 저는 후배들에게 항상 이 말을 전해주고 싶었어요. 자신이 흥미를 잃지 않고 끝까지 즐길 수 있는 프로젝트를 했으면 좋겠습니다.

내가 재밌어하는 주제가 아니라면 프로젝트 중반을 넘어갈 때, 흥미를 잃기 시작하게 되더라구요. 그러다가 번아웃이 오고 프로젝트에 적극적으로 임하지 않게도 되고…

그래서 기획을 하는 단계에서 팀원들과 자신이 이루고자 하는 방향과 가치를 명확하게 말하고, 팀원들 간 조율이 진행된 상황에서 프로젝트를 진행했으면 좋겠습니다.

누군가는 제품 출시를 통해 사용자 유치 경험을 해보고 싶을 수도 있고, 누구는 서비스 출시보다는 깊게 기술적인 고민과 공부를 하면서 진행하고 싶을 수도 있고, 누구는 돈을 벌 수 있는 프로젝트를 여러개 하고 싶을 수도 있을거에요.

이런 점들을 우선 스스로 생각을 해서 메타인지가 된 상태로, 팀원들과 이야기를 하면 좀 더 좋은 프로젝트를 할 수 있지 않을까 !!!!!!! 싶습니다.

다들 포기하지말고 항상 웃으면서 즐기면서 개발했으면 좋겠어요 !!

Q. Summer Dev 프로젝트에서 개발자로 참여한 경험을 설명해 주세요. 어떤 역할을 맡았고, 주요 기술 스택은 어 떻게 구성되었나요?

영현 : 플로버 프로젝트에서 프론트엔드 개발자로 참여해 기획과 디자인을 실제 앱 화면으로 구현하고, 사용자 흐름과 UI 완성도를 높이는 역할을 맡았습니다.

React Native, Expo, TypeScript를 활용해 주요 기능과 재사용 가능한 컴포넌트를 개발했으며, iOS 환경에서 발생하는 화면 및 동작 문제를 점검하고 개선했습니다.

또한 iOS 빌드와 TestFlight 테스트부터 App Store 심사 대응 및 최종 배포까지 담당하며 앱 개발의 전 과정과 실제 출시 경험을 쌓았습니다.

Q. 프로젝트 개발 중 어려움을 겪은 경험이 있나요? 어떻게 해결했으며, 그 과정에서 얻은 교훈은 무엇인가요?

태은 : 프로젝트에서 가장 어려웠던 점은 React Native와 Expo를 처음 사용하는 상황에서, 앱이 백그라운드로 전환되어도 플로깅 경로와 걸음 수를 정확하게 기록하는 것이었습니다.

처음에는 expo-location의 watchPositionAsync와 Pedometer를 사용했습니다. 하지만 화면을 끄거나 다른 앱을 실행하면 위치 추적과 타이머 갱신이 중단되어 이동 경로가 누락됐습니다. 앱으로 돌아왔을 때 시간이 달라지거나, 만보기의 누적값이 중복 반영되는 문제도 발생했습니다. GPS 오차 때문에 실제로 움직이지 않았는데도 이동 거리가 증가하기도 했습니다.

이를 해결하기 위해 Expo 공식 문서와 예제를 참고하며 앱 생명주기와 백그라운드 Task의 동작 방식을 학습했습니다. 이후 expo-task-manager와 expo-location으로 백그라운드 위치 추적을 구현했습니다. 수집한 좌표는 React 상태에만 두지 않고 expo-file-system을 이용해 세션 스냅샷으로 저장했습니다. 앱이 다시 활성화되면 아직 반영되지 않은 좌표만 불러오도록 하여 데이터 누락과 중복을 방지했습니다.

데이터 정확도를 높이기 위한 보정도 적용했습니다. 정확도가 30m보다 낮은 GPS 좌표와 이전 위치에서 2m 미만으로 이동한 좌표는 제외하고, 유효한 좌표 사이의 거리는 Haversine 공식으로 계산했습니다. 타이머는 setInterval의 실행 횟수가 아니라 시작 시각과 누적 휴식 시간을 기준으로 계산해 백그라운드 전환 후에도 실제 시간과 일치하도록 했습니다. 걸음 수 역시 Pedometer의 누적값을 그대로 더하지 않고 이전 값과의 차이만 반영했으며, iOS에서는 백그라운드에 있었던 구간의 걸음 수를 별도로 조회해 보정했습니다.

백엔드 연동에서는 촬영한 인증 사진과 경로 지도 이미지를 presigned URL로 S3에 먼저 업로드했습니다. 이후 로컬 URI가 아닌 업로드에 성공한 이미지 URL과 이동 경로, 거리, 걸음 수, 운동 시간 등을 플로깅 완료 API에 전달했습니다. 또한 권한이 거부되거나 백그라운드 Task를 지원하지 않는 환경에서는 foreground 추적으로 전환해 앱이 중단되지 않도록 처리했습니다.

이 경험을 통해 모바일 프론트엔드는 화면 구현뿐 아니라 앱 생명주기, 운영체제별 권한, 센서 데이터의 오차와 네트워크 실패까지 고려해야 한다는 것을 배웠습니다. 또한 새로운 기술을 사용할 때 기능을 작은 단위로 나누고 실제 기기에서 검증하며 점진적으로 개선하는 것이 중요하다는 점을 배웠습니다.

Q. 프로젝트 팀 내에서 코드 리뷰 및 테스트 프로세스는 어떻게 이루어졌나요? 코드 품질과 안정성을 유지하기 위 해 어떤 노력을 기울였나요?

재륜 : 저희 팀은 GitHub PR과 단위 및 통합 테스트를 통해 코드를 검증했고, 코드 가독성과 일관성을 유지하기 위해 AGENTS.md와 Skills를 활용해 프로젝트의 개발 규칙을 관리했습니다. 특히 개발 과정에서 발생했던 오류나 잘못된 구현 방식은 그때그때 문서에 추가해, 이후 같은 실수가 반복되지 않도록 했습니다.

또한 단순히 현재 개발을 위한 문서화에 그치지 않고, API 동작 방식, 주요 설계 결정, 트러블슈팅 과정 등 프로젝트 전반에 대한 문서화를 지속적으로 진행했습니다. 이후 다른 개발자가 프로젝트를 유지보수하거나 인수인계를 받을 때 기존 코드와 설계 의도를 빠르게 파악할 수 있도록 하는 것까지 고려했습니다.

최근에 다른 사람이 개발해둔 프로젝트를 직접 유지보수할 일이 있었는데, 그 과정에서 문서화의 중요성을 크게 느꼈습니다. 문서가 부족하면 작은 기능 하나를 수정하기 위해서도 기존 코드의 구조와 개발자의 의도를 파악하는 데 많은 시간이 들지만, 설계 이유나 문제 해결 과정이 잘 남아 있으면 그 시간을 크게 줄일 수 있었습니다.

그래서 이번 프로젝트에서는 문서화를 단순한 기록이 아니라 코드 품질의 일부라고 생각했습니다. 문서 작성에 당장은 시간이 들더라도, 장기적으로는 유지보수와 인수인계 시간을 줄이고 같은 문제를 다시 분석하는 비용을 줄일 수 있기 때문에 결과적으로 개발 비용 절감에도 도움이 된다고 생각합니다.

Q. 문제에 대한 개선 방향은 어떤 것이 있을까요?

지환 : 프로젝트를 시작하기 전까지는 Java와 Spring을 이용한 백엔드 개발을 주로 공부했습니다. 머신러닝이나 GIS는 거의 처음 접하는 분야였기 때문에, 초반에는 모델을 만드는 것보다 데이터가 어떤 특성을 갖는지 이해하는 것부터 쉽지 않았습니다. 예를 들어 쓰레기 제보 데이터는 제보된 위치는 확실한 쓰레기 발생 지점이라고 볼 수 있지만, 제보가 없는 지역을 모두 깨끗한 지역이라고 단정할 수 없었습니다.

이 문제를 해결하기 위해 PU-Learning을 공부했고, 처음 사용했던 Random Forest에서 XGBoost로 모델을 변경한 뒤 편의점, 상권, 도로 특성처럼 실제 환경과 관련 있는 피처를 하나씩 추가하며 결과를 비교했습니다. 그 과정에서 Recall을 71.4%에서 88.86%까지 높일 수 있었습니다.

모델을 만드는 것보다 더 어려웠던 건 이 결과를 실제 서비스 규모로 가져가는 일이었습니다. 광주 일부 지역에서 잘 돌아가던 코드를 전국 단위로 확장하니 10m 격자만 1억 개가 넘었고, 공간 조인 과정에서 메모리가 부족해 프로세스가 계속 종료됐습니다. 처음에는 서버 사양의 문제라고 생각했지만, 데이터를 한꺼번에 메모리에 올리는 구조 자체가 문제였습니다. 이후 지역을 일정 크기로 나눠 처리하고, 피처 추출과 DB 적재도 청크 단위로 수행하도록 바꾸면서 전국 데이터를 처리할 수 있도록 만들었습니다. 이 과정에서 메모리 사용량이나 I/O 같은 부분도 실제 서비스에서는 중요한 설계 요소라는 걸 많이 배웠습니다.

또 하나 많이 배운 부분은 각 기능을 따로 구현하는 것과 실제 서비스로 연결하는 것은 완전히 다른 문제라는 점이었습니다. 모델이 만든 예측값을 PostGIS에 저장하고, 이를 OSM 도로 데이터와 공간 조인한 뒤 GraphHopper의 경로 가중치로 사용했습니다. 지도에서는 같은 데이터를 그대로 보내는 대신 H3와 PMTiles 형태로 가공해 서비스하도록 구성했습니다. 개발 도중에는 모델 추론과 DB 적재가 하나로 묶여 있어서 DB 오류가 발생할 때마다 긴 추론을 처음부터 다시 해야 하는 문제도 있었는데, 두 과정을 분리해 필요한 단계만 다시 실행할 수 있도록 구조를 바꾸기도 했습니다.

이 프로젝트를 하면서 가장 많이 달라진 점은 제가 익숙한 기술 안에서만 해결책을 찾지 않게 된 것입니다. 처음에는 백엔드 개발만 해왔지만, 실제 문제를 해결하려다 보니 머신러닝, 공간 데이터 처리, 데이터베이스, 라우팅, 대용량 데이터 처리까지 자연스럽게 영역이 넓어졌습니다. 새로운 기술을 많이 사용했다는 것 자체보다, 문제가 생겼을 때 원인을 찾아보고 필요한 기술을 공부한 뒤 직접 적용하고 다시 결과를 확인하는 과정을 반복해본 경험이 가장 큰 성장이라고 생각합니다.

Q. 사용자 경험을 개선하기 위해 어떤 전략을 사용했나요?

아현 : 우선 저희 앱을 사용하시는 분들은 당장 플로깅을 하기 위해서 사용하실 것이라는 가정을 두었습니다. 그래서 처음에 강하게 의견을 냈던 부분은 ‘앱을 실행하자마자 플로깅 시작 버튼을 누를 수 있어야 한다.’ 였고요.

플로깅을 하면서 앱 사용이 불편하지 않도록 하는 것도 중요한 지점이라, 초기에 기획했던 ‘줍’버튼. 쓰레기를 주울 때 마다 카운트를 세는 버튼은 과감하게 삭제 하였습니다. 사유는 쓰레기를 주우려면 장갑을 끼거나 집개를 잡아야 하는데, 양 손을 쓰는 과정에서 줍버튼을 누르는 것은 너무 번거롭다는 것이었습니다.

그리고 사용자 경험을 고려하기 위해 사전에 심층 인터뷰를 3건, 설문조사를 63건 가량 받은 것도 전략중에 하나였던 것 같습니다. 저희 팀은 당시 플로깅에 대한 지식이 전무한 상황이었어서 인터뷰 과정이 크게 도움이 되었던 것 같습니다.

지금까지 환경을 생각하는 서비스 “플로버”를 개발한 플로버팀이었습니다!