본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 15. 12:48

처음 며칠은 순조로웠다. 그러다 현실이 닥쳤다. 무엇이 고장 났고, 무엇이 여전히 고장 난 상태이며, 어떻게 해결하고 있는지에 대하여

요약

Gemma 4를 활용한 모바일 에이전트 개발 과정에서 겪은 실질적인 기술적 난관과 디버깅 경험을 다룹니다. ADB 연결, OCR 성능, 비동기 UI 처리 및 예외 상황 대응 등 실제 구현 단계의 문제점들을 상세히 기록했습니다.

핵심 포인트

  • ADB 및 USB 디버깅 권한 설정의 중요성
  • Tesseract OCR 성능 향상을 위한 이미지 전처리 필요성
  • 비동기 UI 업데이트에 따른 검증 지연 시간 확보
  • 모바일 에이전트의 OCR 속도 및 예외 상황(전화, 잠금) 처리 과제

이 빌드 로그(build log)의 첫 4일은 추진력을 얻는 과정이었습니다. 리포지토리(repo)를 생성하고, Gemma 4를 연결하고, ADB가 작동하게 만들고, OCR을 추가하고, 작동하는 태스크(task)를 출시하는 것이었습니다.

5일 차는 다릅니다. 이번에는 제가 마주한 벽과, 여전히 마주하고 있는 벽에 대한 이야기입니다.

만약 여러분이 무언가 실질적인 것을 만들고 있다면—특히 스마트폰을 이용하고 있다면—그 기분을 알 것입니다. 초기 성과들은 점차 사라집니다. 문제들은 더 어려워집니다. 인터넷에는 여러분이 시도하려는 것에 대한 튜토리얼(tutorial)이 없습니다. 이 포스트는 바로 그런 순간들에 관한 것입니다.

초기에 발생했던 문제들 (기록하지 않았던 것들)

저는 처음 며칠을 아주 깔끔해 보이게 만들었습니다. 실제로는 그렇지 않았습니다.

2일 차에, 리포지토리(repo)를 생성하고 agent.py를 푸시(push)한 후, ADB가 제 기기를 감지하지 못한다는 사실을 깨달았습니다. 저는 Termux에서 패키지를 재설치하고, USB 디버깅(USB debugging)을 껐다 켜고, 휴대폰을 재부팅하며 두 시간을 보냈습니다. 해결책은 당혹스러웠습니다. 오래된 권한을 정리하는 과정에서 실수로 USB 디버깅 승인을 취소했던 것입니다. 개발자 옵션(Developer Options)에서 한 번의 탭만으로 모든 것이 정상 작동했습니다.

3일 차에는 Tesseract OCR이 계속해서 의미 없는 글자(gibberish)를 반환했습니다. 텍스트 추출 성능이 너무 좋지 않아서 라이브러리(library)가 고장 난 줄 알았습니다. 알고 보니 스크린샷을 잘못된 형식으로 전달하고 있었습니다. Tesseract는 깨끗하고 대비가 높은 이미지가 필요합니다. 제 스크린샷은 압축되어 있었고 노이즈가 많았습니다. 먼저 PNG로 변환하는 것이 문제의 80%를 해결했습니다.

4일 차에는 검증 레이어(verification layer)가 테스트 시에는 완벽하게 작동했지만, 실제 WhatsApp 화면에서는 매번 실패했습니다. 문제는 무엇이었을까요? WhatsApp의 UI는 비동기적(asynchronously)으로 업데이트됩니다. 에이전트(agent)가 검증용 스크린샷을 찍을 때 연락처 목록이 완전히 로드되지 않았던 것입니다. 검증 전 2초의 지연 시간을 두는 것으로 해결되었습니다. 그 지연 시간을 찾아내기 위해 3시간의 디버깅(debugging) 시간을 허비했습니다.

이런 순간들은 다듬어진 포스트에는 담기지 않습니다. 하지만 이것이 진짜 작업입니다.

현재 겪고 있는 어려움

오늘 제가 막혀 있는 부분은 다음과 같습니다.

1. OCR이 느리고 신뢰할 수 없음

제 기기에서 Tesseract는 화면 스캔 한 번당 8~12초가 소요됩니다. 단일 동작이라면 괜찮습니다. 하지만 5단계 작업의 경우, 텍스트 인식만을 위해 1분 동안 기다려야 합니다. 퍼지 매칭 (Fuzzy matching)이 정확도 향상에는 도움이 되지만, 속도 문제를 해결할 수는 없습니다.

더 가벼운 대안들을 살펴보고 있습니다. 아마도 커스텀 학습된 모델 (Custom-trained model)을 사용하거나, Google ML Kit의 온디바이스 텍스트 인식 (On-device text recognition)으로 전환하는 방법이 있을 것입니다. 하지만 두 옵션 모두 제가 계획하지 않았던 복잡성을 추가하게 됩니다.

2. 에이전트가 중단 상황을 처리하지 못함

작업 도중에 WhatsApp 전화가 걸려오면 에이전트는 망가집니다. 알림이 팝업되어 대상 버튼을 가리면, 에이전트는 버튼 대신 알림을 탭합니다. 화면이 타임아웃되어 잠기면 모든 것이 중단됩니다.

사람은 전화를 거절하고 작업을 계속해야 한다는 것을 알고 있습니다. 에이전트는 그렇지 못합니다. 발생 가능한 모든 중단 상황에 대해 복구 핸들러 (Recovery handler)를 구축하는 것은 마치 무한함을 쫓는 것처럼 느껴집니다.

3. 휴대폰 발열 문제

10~15분간 연속으로 사용하면 휴대폰이 뜨거워집니다. CPU 스로틀링 (Throttling)이 발생하고, 추론 (Inference) 속도가 느려집니다. 한 번은 작업 도중에 휴대폰이 스스로 재부팅되기도 했습니다. AI 에이전트를 실행하도록 설계되지 않은 기기에서 열 관리 (Thermal management)를 위한 해결책을 아직 찾지 못했습니다.

4. 여전히 혼자 개발 중

아직 협업자나 기여자를 찾지 못했습니다. 리포지토리 (Repo)는 공개되어 있고 코드도 준비되어 있습니다. 하지만 혼자 만드는 빌드이며, 이러한 문제 중 일부는 다른 사람의 지혜가 필요합니다.

다음 단계

이러한 도전 과제들이 프로젝트가 실패하고 있다는 것을 의미하지는 않습니다. 이는 프로젝트가 실전이라는 것을 의미합니다. 모든 프로토타입 (Prototype)은 벽에 부딪힙니다. 프로토타입과 제품의 차이는 계속해서 나아가느냐에 달려 있습니다.

다음 단계:

  • 더 가벼운 OCR 대안 조사
  • 가장 흔한 실패 사례에 대한 기본적인 중단 핸들러 (Interruption handler) 작성
  • 하드웨어 문제를 격리하기 위해 두 번째 기기에서 테스트 시작
  • 알려진 각 문제에 대해 GitHub에 이슈 (Issue) 생성 — 어려움을 문서화로 전환

리포지토리 (Repo)

👉 github.com/Dexter2344/phone-agent

만약 여러분도 OCR, 발열, UI 중단과 같은 비슷한 벽에 부딪힌 적이 있다면, 어떻게 해결하셨는지 진심으로 듣고 싶습니다. 댓글을 남기거나 이슈를 열어주세요.

오늘은 5일 차입니다. 신혼 달콤함은 끝났습니다. 진짜 빌드 (Build)는 이제부터 시작입니다.

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0