30일 만에 Wear OS 앱 출시 (ft AI) #2

2장. 개발 환경 세팅과 기본 구조

이 장의 목표는 “30일 플랜을 실행 가능한 프로젝트”로 바꾸는 일입니다. 설치만 끝내는 세팅이 아니라, 바로 화면을 띄우고 기능을 쌓아올릴 수 있는 구조를 만듭니다. 핵심은 안정성(빌드가 흔들리지 않기), 단순성(모듈/의존성 최소), 확장성(기능을 추가해도 복잡해지지 않기)입니다.

왜 구조부터 잡아야 할까요?

• 워치는 화면이 작고 상호작용이 짧습니다. 그래서 “기능 1~2개를 빠르게 완성”하는 흐름이 중요합니다. 이를 돕는 구조는 곧 개발 속도입니다.
• 초기에 정리된 모듈/의존성/상태 관리 패턴은 디버깅 시간을 절반으로 줄입니다.
• 출시 시점의 서명/정책/자산 준비까지 거슬러 올라가면, 세팅이 깔끔할수록 마지막 주가 편해집니다.

1. 필수 환경 점검

• IDE: 최신 안정 버전의 Android Studio
• SDK/에뮬: Wear OS 3 이상 에뮬레이터 1개, 실제 워치가 있다면 페어링
• 프로젝트 템플릿: Wear OS Compose 템플릿을 권장(기본 네비게이션/테마 포함)
• 패키지 네이밍: 초기에 고정(스토어/서명과 직결). 바꾸면 후반 작업이 증가합니다.

1. 프로젝트 뼈대 만들기(초기 2시간)

• 앱 이름/아이콘/패키지명 확정
• 최소 구성만 유지: app(워치 앱) + core 모듈 1~2개 정도
  • core:design — 테마, 색상, 타이포, 공통 컴포저블(예: PrimaryButton, AppScaffold)
  • core:model(선택) — 데이터 모델/간단한 유틸(시간 포맷 등)
• 이유: 피처 단위 모듈화는 후반으로 미루고, 먼저 “작동하는 MVP”까지 직선으로 갑니다.

1. 의존성 최소 셋업

• Wear Compose: foundation, material(혹은 Wear Material), navigation-wear
• ViewModel/코루틴: lifecycle, runtime, kotlin coroutines
• Horologist(선택적): composables(공통 UI), tiles(타일), complications 데이터 헬퍼
• 테스트: junit/robolectric(옵션), UI 테스트는 MVP 이후 추가
• 팁: 버전은 카탈로그/버전 관리 파일로 한 곳에서 관리. 흔한 충돌을 예방합니다.

1. 테마와 컴포넌트 합의(초기 30분 투자)

• MaterialTheme 시스템을 초기에 고정하세요.
  • 다크 전용 대비, 큰 폰트(손목 가독성 최우선), 포커스 링/터치 타깃 48dp 이상
• 버튼/칩/타이틀의 스타일 가이드를 한 번에 정리
  • 예: PrimaryChip, SecondaryChip, GhostChip 3종만 사용
• 자주 생기는 문제
  • 색 조합 과다 → 배터리/가독성에 불리
  • 컴포넌트 API 변경으로 인한 오류 → 최신 가이드를 기준으로 Defaults 기반 색상 API 사용

1. 화면 구조와 네비게이션

• 기본 흐름: 홈 → 행동(예: 타이머 시작) → 설정
• 버튼은 “한 손가락, 한 목적” 원칙을 따릅니다.
• 네비게이션 전략
  • 단순 스택(뒤로가기로 충분) 우선
  • 반복 진입이 잦은 기능은 타일/컴플리케이션으로 바로가기 제공
• 상태 복원: 워치는 인터럽트가 잦습니다. ViewModel + savedState를 기본으로 두세요.

1. 상태 관리 패턴(간단·명확·복원 가능)

• 단일 소스의 진실: ViewModel에 UIState를 두고, 화면은 상태만 관찰
• 이벤트 드리븐: 이벤트(시작/정지/리셋) → 리듀서(상태 변경) → UI 반영
• 예시 흐름
  • UI: 시작 버튼 탭 → ViewModel.onStart()
  • VM: 타이머 시작, 상태를 Running으로 → UI가 Running 레이아웃로 자동 전환
• 장점: 타이밍 이슈/회전/백그라운드 전환에도 예측 가능

1. 타일/컴플리케이션 최소 예비 설계

• 타일: 가장 자주 쓰는 액션 1개만 노출(예: 시작/정지 토글)
• 컴플리케이션: “읽자마자 끝나는 정보”만(예: 남은 시간, 오늘 횟수)
• 주의: 타일/컴플리케이션은 배터리와 밀접. 갱신 주기/데이터 소스는 “필요할 때만” 업데이트

1. 백그라운드와 배터리

• 기본 원칙
  • 폴링 대신 이벤트/알림 기반
  • 무거운 연산은 지연·배치(사용자 상호작용 직후엔 최대한 가볍게)
  • 네트워크는 압축/캐시/간격 확대
• 모니터링
  • 첫 주엔 배터리 드레인 체감 테스트(하루 사용 후 % 기록)
  • 프레임 드랍, 할당 스파이크는 즉시 기록하고 원인 메모(후반 최적화에 재활용)

1. 빌드/서명/플레이 준비(초기 발판만)

• appId/버전 코드 정책을 초기에 문서화
  • 예: 마이너(주 단위), 패치(버그), 코드 자동 증가
• 서명 키는 안전한 저장소에 백업(유실 시 업데이트 불가)
• 릴리즈 빌드 프로필을 미리 만들어 “릴리즈 빌드가 항상 돈다”는 신뢰 확보

1. 자주 막히는 포인트와 해결 루틴

• 의존성 충돌: 한 번에 여러 라이브러리를 올리지 말고, 1개씩 추가 후 빌드
• 구식 API/빌더 혼용: 최신 컴포저블/Defaults API로 마이그레이션(경고는 즉시 해소)
• 타입 불일치/오버로드 혼동: 함수 시그니처를 주석으로 고정, 공용 팩토리 함수로 단일화
• 디버그 메시지: 재현 경로/기기 상태를 함께 메모(다음 버그 때 검색 효율↑)

퀵 체크리스트(오늘 완료 목표)

• Wear Compose 템플릿으로 새 프로젝트 생성
• core:design 모듈 분리, Primary/Secondary 컴포넌트 3종 정의
• ViewModel + UIState 틀 완성(시작/정지/리셋 이벤트만 우선)
• 홈–행동–설정 3화면 뼈대 연결
• 타일 1개, 컴플리케이션 1개 ‘자리’만 먼저 잡기(나중에 로직 연결)
• 릴리즈 빌드 구성과 버전 정책 초안 문서화

작게 테스트하는 방법

• 에뮬에서 폰 연결 없이 5분 테스트: 시작–정지–재개만 확인
• 대비/터치: 어두운 공간에서 팔을 살짝 움직이며 가독성 체크
• 배터리: “기능 없이” 앱을 켜두고 30분 소모율 기록(기준선 만들기)

실전 팁

• 시작–정지–재개 같은 핵심 액션은 “타일 → 알림 → 앱 본문” 3가지 진입로를 모두 지원하면 재방문율이 오릅니다.
• 공통 여백/폰트 크기는 초기에 강제(디자인 시스템). 화면별 임의 조정은 나중에 빚이 됩니다.
• 컴포넌트 개수는 적을수록 유지보수가 쉽습니다. 대표 버튼/칩만 만들어 돌려 쓰세요.

요약 포인트

• 단순한 모듈 구조 + 일관된 테마 + 예측 가능한 상태 관리가 개발 속도를 만듭니다.
• 타일/컴플리케이션은 “한 가지 가치”에 집중하고, 배터리는 기본값으로 지킵니다.
• 릴리즈 빌드는 지금부터 항상 성공해야 합니다. 출시 주에 환경과 싸우지 마세요.

 

앱 이미지