목차
버스 지각을 반복하던 직장인이 퇴근 후 30분씩 투자해 우리 동네 AI 교통 불편 앱을 만든 과정을 아이디어, 기획, 개발, 운영 단계로 나누어 정리합니다. 실제 출퇴근 불편에서 출발해 AI 교통 앱으로 해결책을 모색한 현실적인 사이드프로젝트 사례를 소개합니다.
출근길마다 버스를 놓쳐 지각을 반복하다 보면, 단순한 운이 아니라 구조적인 문제가 있다는 생각이 들기 마련입니다. 특정 정류장은 배차 간격이 너무 길고, 또 다른 구간에서는 교차로 정체 때문에 버스가 예상보다 훨씬 늦게 도착합니다. 내비게이션에는 잘 드러나지 않지만 실제로는 주민들이 불편을 크게 느끼는 숨은 병목 구간들이 곳곳에 존재합니다. 저 역시 이런 구간을 매일 지나면서 불만을 가졌고, 온라인 커뮤니티에 글을 남겨 보기도 했지만 상황은 쉽게 바뀌지 않았습니다. 그러던 중 “어디가 얼마나 불편한지 데이터로 보여 줄 수 있다면 설득력이 달라지지 않을까”라는 생각이 들었습니다. 그렇게 버스를 놓치고 지각하던 경험이, 우리 동네 AI 교통 불편 앱을 직접 만들어 보자는 결심으로 이어졌습니다. 이 글에서는 한 명의 직장인이 제한된 시간 속에서 어떤 방식으로 문제를 정의하고, 로컬 데이터를 모으고, AI를 활용해 교통 불편을 구조화했는지 구체적인 과정을 소개하고자 합니다.
1. 버스 지각에서 시작된 문제 의식과 로컬 교통 불편 정의
저에게 가장 크게 다가온 문제는 “왜 항상 같은 정류장에서, 같은 시간대에 지각이 반복되는가”였습니다. 회사까지의 거리는 멀지 않았지만, 배차 간격과 정체 구간이 겹치면서 출근 시간이 일정하지 않았고, 그 결과 중요한 회의에 늦는 일이 몇 번이나 반복되었습니다. 처음에는 단순히 운이 없다고 생각했지만, 지각이 계속되면서 이 문제는 개인의 운이 아니라 동네 교통 구조와 연결되어 있다는 판단을 하게 되었습니다. 주민 커뮤니티를 살펴보니 같은 정류장, 같은 교차로에 대한 불만 글이 꾸준히 올라오고 있었고, 특정 시간대에 민원이 집중된다는 사실도 눈에 띄었습니다. 그러나 이 정보는 게시글과 댓글에 흩어져 있어 누가 보더라도 문제의 크기와 위치를 한눈에 이해하기는 어려웠습니다. 기존 민원 시스템에 글을 남겨 보기도 했지만, 처리 과정과 결과를 체감하기 어렵고, 어디까지가 반복되는 문제인지 파악하기도 쉽지 않았습니다. 저는 이 지점에서 “동네 사람들만 아는 불편을 지도와 시간대, 유형별로 정리해 보여 줄 수 있는 도구가 필요하다”는 결론에 도달했습니다. 문제를 너무 크게 잡으면 아무것도 시작하지 못할 것 같아, 범위를 ‘내가 실제로 이용하는 버스 노선과 정류장들’로 우선 좁혔습니다. 이렇게 좁은 범위로 출발하면, 어떤 데이터를 모아야 할지, 어떤 기능만 있어도 의미가 있을지 명확해져 실행 가능성이 훨씬 높아졌습니다.
2. 우리 동네 교통 불편을 모으는 구조와 AI를 활용한 분류 설계
앱을 설계할 때 가장 먼저 고민한 것은 주민이 교통 불편을 제보할 때 어떤 흐름이 가장 자연스러운지였습니다. 저는 사용자가 웹 앱에 접속하면, 복잡한 회원가입이나 긴 설명 없이 바로 지도를 보고 정류장 또는 구간을 선택할 수 있도록 하는 구조를 선택했습니다. 위치를 클릭하면 날짜와 시간대를 선택하고, “버스 지연”, “배차 간격 과다”, “위험한 보행 동선”, “신호 체계 문제” 같은 불편 유형을 체크한 뒤, 짧은 설명을 입력하도록 구성했습니다. 사진을 꼭 올리지 않아도 되지만, 필요할 경우만 첨부할 수 있게 해 제보 진입 장벽을 최대한 낮추었습니다. 이렇게 모인 텍스트 설명과 위치, 시간대 정보는 단순히 저장하는 데서 끝나지 않고, AI가 자동으로 분류하고 우선순위를 제안하는 데 사용됩니다. 예를 들어 설명 문장에서 “항상”, “매일”, “출근 시간” 같은 표현이 반복되면 반복 문제 가능성이 높다고 판단해 점수를 더하고, 같은 정류장에서 비슷한 유형의 제보가 많이 쌓이면 그 구간의 체감 민원 점수가 높아지도록 설계했습니다. 초기에는 규칙 기반 키워드 분류로 시작하여, 이후 제보가 어느 정도 쌓이면 간단한 텍스트 분류 모델을 학습시켜 더 정교한 분류가 가능하도록 단계적인 계획도 세웠습니다. 관리 화면에서는 지도 기반으로 열지도(heatmap)를 표시해, 어느 구간에 불편이 집중되는지 시각적으로 보여 주도록 설계했습니다. 시간대별, 요일별 필터를 통해 출근 시간과 퇴근 시간의 패턴 차이를 비교할 수 있도록 한 것도 중요한 요소였습니다. 이러한 구조를 통해 단편적인 불만을 모아, “어디가, 언제, 어떤 이유로 불편한지”를 데이터로 설명할 수 있는 기반을 마련하고자 했습니다.
3. 퇴근 후 30분 사이드프로젝트 루틴과 사용 도구 선택 기준
평일 저녁에 사용할 수 있는 시간은 길지 않았기 때문에, 저는 하루 30분이라는 제한을 명확히 정하고 그 안에서 할 수 있는 일만 계획했습니다. 처음 일주일은 문제 정의와 화면 구성을 종이에 스케치하는 데 집중하며, 어떤 데이터를 최소 단위로 모을지, 제보 흐름을 어떻게 간단하게 만들지를 정리했습니다. 이후에는 웹 프레임워크와 호스팅 서비스를 선택할 때도 “빠르게 배포할 수 있는가”, “설정에 시간을 많이 쓰지 않아도 되는가”를 기준으로 삼았습니다. 복잡한 인프라를 직접 구성하기보다는 관리형 서비스와 노코드·로우코드 도구를 적극적으로 활용해 개발 부담을 줄였습니다. 예를 들어 지도 표시와 위치 선택은 이미 검증된 지도 API를 사용하고, AI 텍스트 분류는 별도의 모델을 처음부터 학습하기보다 상용 API를 연동해 초기에 필요한 기능만 확보했습니다. 하루 30분 중 절반은 코드를 수정하는 시간, 나머지 절반은 실제 데이터를 입력해 보며 화면과 흐름을 검증하는 시간으로 나누었습니다. 버스를 놓쳤던 날의 경험을 그대로 입력해 보며, 제보 과정이 번거롭지 않은지, 같은 내용을 두 번 입력하게 만들고 있지는 않은지를 계속 확인했습니다. 일정이 길어지면서 동기부여가 떨어지지 않도록, 매일 작은 목표를 하나만 정해 두고 그 목표를 달성하면 개발을 멈추는 방식으로 루틴을 유지했습니다. 이렇게 짧은 시간이지만 꾸준히 투자하니, 어느 순간부터는 기본 기능을 갖춘 우리 동네 전용 교통 불편 앱의 형태가 눈에 보이기 시작했습니다.
4. 직장인 사이드프로젝트로서 얻은 인사이트와 앞으로의 활용 방향
이 프로젝트를 진행하면서 가장 크게 느낀 점은, 직장인의 사이드프로젝트는 완성도보다 “문제 정의의 정확성”이 더 중요하다는 사실입니다. Gocheon Connect와 같은 로컬 교통 불편 앱의 경우, 전국 모든 노선을 다루려 했다면 시작조차 하지 못했을 것입니다. 대신 제가 실제로 타는 버스 노선과 정류장, 그리고 그 주변 교차로에만 초점을 맞추자 어떤 데이터가 필요한지 명확해졌고, 짧은 시간 안에도 체감 가치를 만들 수 있었습니다. 또한 AI를 직접 개발하기보다, 이미 제공되는 AI 서비스를 활용해 분류와 요약, 우선순위 판단에만 집중한 전략이 사이드프로젝트 환경에 잘 맞았습니다. 기술적인 시도뿐 아니라, 주민 입장에서 어떤 화면이 이해하기 쉬운지, 어느 정도의 디테일까지 보여 줘야 설득력이 생기는지에 대한 감각도 함께 얻을 수 있었습니다. 아직 이 앱은 소규모 사용자만 쓰는 실험 단계이지만, 쌓이는 데이터를 기반으로 행정기관에 전달할 수 있는 리포트를 정기적으로 만들어 보는 것도 다음 단계의 목표입니다. 예를 들어 “어느 교차로에서, 어느 시간대에, 어떤 유형의 불편이 반복되는지”를 정리한 리포트를 분기마다 만들어 주민자치회나 담당 부서와 공유하면, 단순 민원을 넘어 데이터 기반 대화를 시작할 수 있을 것입니다. 장기적으로는 교통 외에 보행 안전, 야간 조도, 불법 주정차 등 다른 생활 불편 영역에도 동일한 구조를 확장해 보는 것도 고려하고 있습니다.
결론: 요약 및 정리
버스를 놓치고 지각하던 반복적인 경험은 불편한 일상이었지만, 동시에 로컬 문제를 스스로 해결해 보자는 동기가 되었습니다. 우리 동네의 구체적인 교통 불편을 정의하고, 제보 구조와 AI 분류 로직을 설계해 앱으로 구현하는 과정에서, 민원을 단순한 불만이 아닌 데이터로 전환하는 힘을 확인할 수 있었습니다. 퇴근 후 30분이라는 제한된 시간을 전제로 작은 목표를 나누어 실행하면서, 직장인도 충분히 의미 있는 사이드프로젝트를 완성할 수 있다는 가능성도 체감했습니다. 아직은 실험적인 프로젝트이지만, 이 앱을 통해 출퇴근길의 불편을 더 명확하게 설명하고, 향후 행정기관이나 지역 커뮤니티와의 대화를 준비할 수 있는 기반을 마련했다는 점에서 큰 의미가 있습니다. 이 글이 비슷한 불편을 겪고 있는 분들, 그리고 로컬 문제를 자신만의 방식으로 해결해 보고 싶은 분들께 하나의 참고 사례가 되기를 바랍니다. 작은 시간과 도구를 활용해도, 문제를 정확히 정의하고 데이터를 꾸준히 쌓아 나가면 생각보다 큰 변화를 만들어 낼 수 있다는 메시지를 전하고 싶습니다.