[Walkmate] Day 3 TFLite 모델 붙이고 실행

“초록색 박스와 ‘준비 완료!’ 메시지를 마주했을 때의 성취감은 잊을 수 없다.”

프로젝트 3일 차. 오늘은 프로젝트의 가장 큰 기술적 도전 중 하나인 TFLite 모델의 실제 모바일 앱 연동을 진행했다. 안드로이드 환경에서의 경로 문제와 메모리 누수, 연산 성능 사이에서 균형을 맞추는 과정이 핵심이었다.

🚀 Today’s Mission & Results

TFLite 모델을 안드로이드 WebView 환경에 성공적으로 탑재하고, 실시간 추론이 가능한 수준으로 최적화했다.

💻 GitHub Commit History

안드로이드 플랫폼 초기화와 TFLite 모델 전용 스크린 구현을 위해 총 6건의 커밋이 이루어졌다.

🛠 Tech Stack & Implementation

1. TFLite 라이브러리 연산 환경 구축

Vite 빌드 도구와의 충돌을 방지하기 위해 index.html에 CDN 방식으로 TensorFlow.js 및 TFLite Web API를 직접 주입했다. WASM 부품 로딩 전 모델 로드 함수가 호출되는 것을 막기 위해 전역 객체 체크 로직을 추가하고, WASM 경로를 특정 버전(0.0.1-alpha.10)으로 고정하여 안정성을 확보했다.

2. 안드로이드 WebView 경로 이슈 해결

앱 내부에서 .tflite 모델 파일을 찾지 못하는 문제를 해결하기 위해 androidScheme 설정을 조정하고, 모델 파일의 절대 경로를 동기화했다.

3. 성능 균형과 자원 관리

• 연산 최적화: 모델이 요구하는 1280px 고해상도 추론을 위해 입력 규격을 상향 조정하되, 실제 카메라 캡처는 720px로 처리했다. 추론 직전에만 1280px로 리사이징하여 기기의 발열과 연산 부담을 줄였다.
• 메모리 보호: 고해상도 이미지 텐서가 누적되어 발생하는 A resource failed to call close 경보를 막기 위해 tf.tidy()를 적용했다. 중간 연산 텐서를 즉시 해제하고 추론 주기를 5초로 완화하여 앱의 안정성을 높였다.

⚠️ Issue Situation & Troubleshooting

이슈 1: Input tensor shape mismatch

• 원인: 코드는 640px로 데이터를 전송했으나, 모델은 1280px로 학습되어 있었다.
• 해결: metadata.yaml 분석을 통해 정확한 규격을 파악하고 MODEL_INPUT_SIZE를 1280으로 수정했다.

이슈 2: 메모리 누수 및 시스템 경고

• 원인: 고해상도 텐서가 가비지 컬렉션 전에 계속 쌓여 메모리 부족 현상이 발생했다.
• 해결: tf.tidy()를 통해 사용이 끝난 텐서를 즉시 파괴하는 로직을 구현했다.

💭 Reflections

라이브러리 로딩과 경로 문제로 6시간 이상 진전이 없었다. 그러다 폰 화면에 초록색 박스가 떴을 때의 기분은 꽤 강렬했다.

모델 명세서(metadata.yaml)를 꼼꼼히 읽는 습관이 디버깅 시간을 얼마나 줄이는지 직접 확인했다. 동작 여부를 결정하는 건 결국 설정값들의 일치였다.

Next Plan: 내일은 실제 현장에서 비디오와 사진을 통한 감지 신뢰도 테스트를 진행할 예정이다. 또한, 감지된 정보를 음성으로 알려주는 TTS(Text-to-Speech) 기능을 구현하여 사용자 경험을 완성할 계획이다.

온디바이스 추론으로 방향을 굳히게 된 이유

TFLite 연동을 진행하면서 가장 분명해진 것은, 이 프로젝트에서 모델 추론은 단순한 기술 선택이 아니라 사용자 안전과 직결된다는 점이었다. 서버 호출 기반 구조는 개발 초기에는 구현이 쉽고 디버깅도 편하지만, 실제 이동 상황에서는 통신 상태와 왕복 지연 시간이 결과를 너무 불안정하게 만든다. 반면 온디바이스 추론은 초기 세팅이 어렵고 모델 경량화, 플랫폼 의존성, 빌드 이슈를 함께 다뤄야 하지만, 한 번 안정화되면 핵심 기능의 예측 가능성이 높아진다.

특히 WebView와 모바일 네이티브 환경을 오가며 실험해 본 경험은 의미가 컸다. “브라우저에서 되던 것”이 앱 안에서는 곧바로 재현되지 않는다는 점, 그리고 추론 엔진보다도 입출력 파이프라인과 메모리 관리가 실제 성능을 좌우한다는 점을 몸으로 확인했다. 결국 모델 파일 하나만 넣는다고 끝나는 일이 아니라, 전처리, 결과 후처리, 프레임 간 간격, 사용자 피드백 방식까지 전부 하나의 체인으로 설계해야 했다.

이 날 정리한 실무 체크포인트

• 모델 정확도보다 기기 내 응답 속도를 먼저 확인한다.
• 추론 엔진 선택과 별개로 카메라 프레임 처리 비용을 따로 본다.
• 디버깅 가능한 최소 데모를 먼저 만들고 이후에 최적화한다.
• 브라우저 테스트 결과를 모바일 실성능과 동일시하지 않는다.

이 원칙은 이후 Android 연동과 경로 안내 기능을 붙일 때도 계속 기준으로 작동했다.