Android 개발을 위한 AI: 비개발자의 경험

# 비개발자가 AI로 안드로이드 앱 제작 및 유지보수: 프로젝트 중간 분석

코딩 경험이 전혀 없는 비즈니스 애널리스트가 AI 채팅(Claude)과 안드로이드 스튜디오만 사용해 두 개의 안드로이드 앱을 출시했습니다. 인간의 역할은 작업 정의, 테스트, 변경 통합, 배포입니다. AI는 코드 생성, 오류 진단, 아키텍처 제안을 담당합니다. 목표는 이 접근 방식이 실제 사용자와 함께 진짜 제품을 유지할 수 있는지 테스트하는 것, 버그 수정과 신규 기능 포함입니다.

방법이 진화했습니다: 처음엔 기능을 처음부터 생성하다가 최소 diff와 수정으로 발전. AI 작업에는 증상, 재현 단계, 제약 조건(신규 라이브러리 금지, 데이터 지속성), 오류 로그 같은 맥락을 포함합니다.

도구와 워크플로

주요 구성 요소:

• Claude: 코드 생성, 빌드 오류 분석, 지속 저장소와 액티비티 라이프사이클 제안.
• 안드로이드 스튜디오: 빌드, 에뮬레이션, 수동 변경 통합.
• RuStore: 출시, 피드백 수집, 업데이트 배포.

AI를 위한 버그 보고 형식:

• 증상 설명과 예상 동작.
• 재현 단계.
• 앱 버전과 제약 조건.
• 이전 수정 시도와 로그.

AI 응답: 가능한 원인, 확인할 파일, 2~3개 솔루션 옵션(위험 포함), 패치 제공.

출시 후 결과

출시된 앱:

• "168 Hours" — 주 168시간 예산 기반 플래너.
• "F1 Tycoon" — 시뮬레이터.

첫 기사 후 다운로드 급증: "168 Hours" 1→71, "F1 Tycoon" 13→45. 실제 사용자가 테스트되지 않은 시나리오에서 버그를 발견했습니다.

케이스 1: 재시작 시 타이머 리셋

증상: 타이머 시작 → 앱 종료 → 복귀 → 0으로 리셋. AI 솔루션: 경과 시간 저장 대신 시작 타임스탬프 + 재계산으로 변경. 수정에 2시간 소요(진단+빌드+배포). 액티비티 라이프사이클과 지속 저장소 부족이 원인.

케이스 2: 수동 활동 생성

신규 기능 추가: 사용자 맞춤 엔티티 입력. AI가 데이터 모델, 화면, 저장소 통합 제안, 엣지 케이스 검증(빈 필드, 리스트 업데이트).

프로젝트 구조 이해

깊은 문법 지식 없이 운영 모델이 형성:

• 클래스: 화면, 모델, 저장소 분리.
• 데이터 모델: UI, 지속성에 파급 효과.
• 상태: 주요 버그 원인 — 라이프사이클, 재시작, 스레드.
• 로직 vs. 데이터: 화면은 UI 처리, 저장소는 데이터 관리.

이로써 시스템 노드를 정확히 타겟팅한 AI 프롬프트 가능.

접근 방식 한계

프로젝트 무결성: AI는 로컬 변경 생성하나 의존성 놓침. 인간이 아키텍처 소유.

디버깅: 재현 가능한 버그(타이머, 상태)에 효과적. 불안정 문제(동시성, 기기 특화)는 로그와 반복 필요.

UI/UX: 기능 구현됐으나 사용자 지표 없어 인체공학성 부족.

유지보수: 피드백을 요구사항으로, 업데이트를 별도 프로세스로(하위 호환성).

경계: 릴리스와 수정에 가능하나 기본 스킬(라이프사이클, 상태 관리) 필요.

주요 교훈

• 실제 사용자(71+45 설치)로 프로토타입에서 제품으로 진화, 버그 노출.
• 수정(타이머, 기능) AI 도움으로 2시간 내 완료.
• 인간 통합자: 테스트, 배포, 구조 파악.
• 한계: 아키텍처와 복잡 디버깅은 인간 몫.
• 궤도: 앱 운영 중, 업데이트 지속.

개발 계획

• "168 Hours" 안정화: 체크리스트 테스트, 타이머 상태 예측.
• 반복 기능: 현재 아키텍처 내.
• 기본 스킬: 라이프사이클, 진단, 구조.
• 다음 보고: 지표(버그, 업데이트, 트렌드).

— Editorial Team