“누군가에게는 당연한 보행이, 누군가에게는 도전이 되지 않도록.”

2026년 2월 9일, 시각장애인을 위한 AI 보행 보조 및 자동 민원 신고 서비스 Walkmate 프로젝트를 본격적으로 시작했다. 단순한 기술 구현을 넘어 사회적 가치를 담은 서비스를 지향한다.


🚀 Today’s Mission & Results

오늘은 아이디어를 구체화하고, AI 모델이 실제로 돌아가는 환경을 잡는 게 목표였다.

프로젝트 핵심 아이디어 구체화 및 차별화 포인트 설정
유료 서비스(PathPal) 벤치마킹 및 차별성 확보
기술 스택 확정 (YOLOv11n, TFLite, Flutter)
모바일 최적화를 위해 경량 모델 채택
프로젝트 제안서 초안 작성 (1.1~1.4)
2025 통계 기반 문제 분석 반영
협업 그라운드 룰 및 브랜치 전략 수립
Git Flow 기반 협업 규칙 정립

💻 GitHub Commit History

오늘 커밋은 AI 모델을 붙이기 위한 기초 환경 세팅에 집중했다.

[!NOTE] Commit Hash: b87cb99 Message: feat: Add new2.py script, road.jpg image, and dataset/train directory.

  • new2.py: YOLOv11n 모델 추론 및 테스트를 위한 기초 스크립트 작성.
  • road.jpg: 객체 탐지 성능 검증을 위한 샘플 도로 이미지 추가.
  • dataset/train: AI Hub 및 공개 데이터셋 활용을 위한 학습 데이터 디렉토리 구조 설계.

🛠 Tech Stack Optimization

프로젝트 기획 단계에서 발생한 가장 큰 이슈는 실시간성모델 용량이었다.

⚠️ Issue Situation

기존의 서버 통신 방식(API)은 지연 시간(Latency) 문제로 인해 실시간 보행 보조에 한계가 있었다. 보행 중 1~2초의 지연은 치명적인 사고로 이어질 수 있기 때문이다.

💡 Solution: On-device AI

  1. Model Selection: 최신 YOLOv11 Nano 모델을 선택하여 연산량(FLOPs)을 최소화했다.
  2. Quantization: 고도의 양자화 기술을 적용할 경우 모델 용량을 6MB 이하로 줄일 수 있음을 확인했다.
  3. Framework: Flutter와 Vision 라이브러리를 결합하여 안정적인 크로스 플랫폼 환경을 구축하기로 했다.

📝 Daily Report Summary

  • 실제 소요 시간: 8시간 (계획 대비 2시간 초과 - 기술 스택 선정을 위한 심층 분석 진행)
  • 핵심 결과물: [Stitch UI 시안], [기술 검토 보고서], [GitHub 기초 리포지토리]
  • 팀 작업: 팀원 최현석, 이지호 님과 함께 ‘자동 민원 신고’라는 차별 포인트를 찾아냈다.

💭 Reflections

처음에는 기존 기술들이 너무 완벽해 보여서 “우리가 과연 새로운 걸 만들 수 있을까?” 싶었다. 그런데 ‘자동 신고’라는 각도를 찾고 나니 방향이 생겼다.

모바일 환경에서는 최신 버전보다 파라미터 수연산량을 먼저 보는 게 맞다는 걸 다시 확인했다.


Project Resources

프로젝트의 상세한 기획 내용이 담긴 제안서 파일을 아래 링크에서 확인할 수 있다.


Next Plan: 내일은 실제 맞춤형 데이터셋(점자블록, 킥보드 등)을 구축하고 YOLOv11n 모델의 첫 전이 학습(Transfer Learning)을 실시할 예정이다.

왜 이 문제가 실제로 중요했는가

Walkmate의 출발점은 단순한 객체 인식 앱이 아니었다. 시각장애인 보행 보조라는 맥락에서는 “인식률이 높다”는 말만으로 충분하지 않았다. 실제 사용자는 실험실이 아니라 복잡한 도로와 골목, 공사 구간, 불법 주정차 구역, 갑작스럽게 놓인 전동 킥보드가 있는 환경에서 앱을 사용한다. 그래서 초기에 기술 검토를 하면서도 정확도 수치 하나만 보지 않고, 지연 시간, 기기 발열, 배터리 사용량, 네트워크 연결 여부까지 함께 고려해야 했다. 이 기준을 먼저 세우고 나니 프로젝트가 단순한 AI 데모가 아니라 생활 보조 도구라는 점이 더 분명해졌다.

또 하나 중요했던 것은 “무엇을 인식할 것인가”보다 “무엇을 먼저 인식해야 하는가”였다. 점자블록, 횡단보도, 보행 방해물, 길 가장자리처럼 우선순위가 분명한 대상을 먼저 정리하지 않으면 데이터셋 구성도, UI도, 음성 안내도 모두 흐려진다. 초기 기획 문서에서 이 우선순위를 먼저 합의했던 덕분에 이후의 학습 데이터 수집과 기능 분할이 비교적 빠르게 진행될 수 있었다.

초반 기획에서 미리 정리해 둔 기준

  • 인터넷 연결이 불안정해도 핵심 안내는 동작해야 한다.
  • 사용자가 화면을 오래 보지 않아도 음성만으로 이해할 수 있어야 한다.
  • 인식 결과는 많이 보여주는 것보다 필요한 것만 분명하게 전달해야 한다.
  • 관리자 화면과 신고 기능은 사회적 가치와 운영 가능성을 함께 고려해 설계해야 한다.

이 기준들은 이후 구현 단계에서 계속 판단의 기준점이 됐다. 어떤 기능을 넣고 뺄지 고민할 때도 결국 “보행 중 실제로 도움이 되는가”라는 질문으로 돌아오게 됐다.

Community

Comments

0 comments

Comments appear immediately. Use report if something needs review.

No comments yet.