1편에서 markdown-viewer 비공개 저장소를 만들고 내 PC에 clone했지만, 아직 앱 코드는 한 줄도 없습니다. 바로 구현부터 시작할 수도 있지만, 그러면 AI가 어떤 기능을 어디까지 만들어야 하는지 판단할 기준이 없습니다. 이번 편에서는 코드보다 먼저 Markdown Viewer 앱 청사진을 만듭니다.
목표는 실제 Google Play 출시까지 이어갈 Android 앱입니다. 먼저 Kotlin(Jetpack Compose)과 Dart(Flutter)를 비교해 기술 구성을 정하고 현재 PC의 개발환경을 점검합니다. 이어서 DEVELOPMENT_ENVIRONMENT.md, MVP.md, ROADMAP.md를 작성해 구현 범위와 순서, 완료 조건을 고정합니다. Android 앱 제작이 처음이어도 각 프롬프트를 순서대로 실행할 수 있도록 진행 과정을 나눴습니다.
1편의 준비 상태를 확인한다
이 글은 실전 바이브코딩 #1: GitHub와 SSH로 Android 앱 작업공간 준비하기를 마친 상태에서 시작합니다. Linux 또는 Windows에 Codex나 Claude Code가 설치되어 있고, GitHub의 markdown-viewer 비공개 저장소를 SSH 주소로 clone했으며, 터미널 또는 IDE에서 그 폴더를 열 수 있다고 가정합니다.
Markdown 문법, Git과 GitHub의 차이, SSH 키 생성과 공개키 등록, ssh -T git@github.com 인증, git clone이 아직 준비되지 않았다면 1편을 먼저 따라갑니다. 2편부터는 저장소 준비를 반복하지 않고 Android 앱의 목표, 개발환경, MVP와 ROADMAP에 집중합니다.
먼저 읽어두면 좋은 글
프로덕션 수준의 Markdown Viewer가 목표다
이 시리즈는 AI에게 앱을 만들어 달라고 요청하고 화면 하나를 띄우는 데서 끝나지 않습니다. 빈 Git 저장소에서 시작해 빌드와 테스트, Google Play 배포, 출시 후 확인까지 직접 이어가는 것이 목표입니다.
마지막 편에 도달했을 때 앱은 다음 조건을 만족해야 합니다.
- Android 전용 Markdown Viewer 앱을 Kotlin과 Jetpack Compose로 만든다.
- 파일 관리자에서
.md파일을 열었을 때 앱이 실행되게 한다. - 다른 앱에서 Markdown 파일을 공유했을 때 바로 렌더링한다.
- 한글과 UTF-8 문서를 안정적으로 보여준다.
- 큰 Markdown 문서에서도 앱이 멈추지 않도록 테스트한다.
- Debug Build뿐 아니라 Release Build와 AAB까지 검증한다.
- 개인정보처리방침, Data Safety, Store Listing까지 준비해 Google Play 출시 흐름을 경험한다.
- 출시 후 피드백과 Android Vitals를 확인하고 다음 버전 ROADMAP을 만든다.
기능만 보면 단순한 Viewer지만, 입력 파일 처리부터 배포와 운영까지 제품 개발의 앞뒤를 모두 거칩니다. 서버·결제·회원가입까지 필요한 서비스보다는 범위가 작고, 화면만 보여주는 데모보다는 검증할 항목이 많습니다. 첫 Android 앱으로 출시 과정을 익히기에 알맞은 크기입니다.
왜 Markdown Viewer인가
첫 앱의 기능을 무작정 줄이기만 하면 Android에서 무엇을 확인해야 하는지 배우기 어렵습니다. Markdown Viewer는 화면 구성은 단순하면서도 파일 입력과 공유처럼 앱 바깥과 연결되는 기능을 다룰 수 있습니다.
사용자는 파일 관리자에서 문서를 열거나 다른 앱에서 Markdown 파일을 공유할 수 있습니다. 앱은 Android가 전달한 Content URI를 읽고, 문법을 해석해 화면에 렌더링해야 합니다. 한글과 UTF-8 문서, 긴 문서에서의 안정성도 확인해야 합니다.
반면 대규모 서버나 결제, 회원가입, 동기화는 필요하지 않습니다. 제품의 경계도 “Markdown 파일을 안정적으로 열고 읽기 좋은 화면으로 보여준다”라는 한 문장으로 설명할 수 있습니다.
Kotlin(Jetpack Compose)과 Dart(Flutter), 무엇을 선택할까
Android 앱을 만든다고 해서 개발 도구까지 자동으로 정해지는 것은 아닙니다. 이 프로젝트에서 먼저 비교할 선택지는 Kotlin(Jetpack Compose)과 Dart(Flutter)입니다. 둘 다 Android 앱을 만들 수 있지만 출발점이 다릅니다.
Kotlin과 Dart는 앱이 무엇을 해야 하는지 코드로 표현할 때 사용하는 프로그래밍 언어입니다. 흔히 듣는 C++, Python, Java도 프로그래밍 언어에 속합니다. 언어마다 코드를 적는 문법과 실행 방식이 다르므로 Kotlin 코드와 Dart 코드는 같은 모습으로 작성되지 않습니다.
Jetpack Compose와 Flutter는 프로그래밍 언어가 아니라 앱의 화면과 동작을 만드는 UI 도구입니다. Jetpack Compose는 Kotlin을 사용해 Android UI를 만들고, Flutter는 Dart를 사용해 여러 플랫폼의 UI를 만듭니다. 따라서 여기서 비교하는 대상은 언어 하나가 아니라 Kotlin(Jetpack Compose), Dart(Flutter)라는 두 가지 개발 구성입니다.
Android 기능을 직접 다루는 Kotlin(Jetpack Compose)
Kotlin은 Android Studio와 Android SDK에서 공식 지원되며, Jetpack Compose도 Kotlin을 기반으로 합니다. 파일 열기, 공유 Intent, Content URI, Storage Access Framework, Activity Lifecycle처럼 이 앱에 필요한 Android API를 Kotlin 코드에서 바로 사용할 수 있습니다. Android 공식 문서의 설명과 예제도 같은 도구와 용어로 이어집니다.
- 장점: Android API와 Compose를 한 프로젝트 안에서 직접 연결할 수 있고, Android Studio의 빌드·디버깅·테스트 도구를 그대로 사용합니다.
- 이번 프로젝트에서의 단점: Android 중심의 구성이므로 나중에 iOS 앱까지 만들려면 별도의 구현 전략이 필요합니다. 처음에는 Kotlin뿐 아니라 Gradle, Android Lifecycle과 Compose의 상태 관리도 함께 익혀야 합니다.
여러 플랫폼에서 코드를 공유하는 Dart(Flutter)
Flutter는 Dart로 UI와 앱 로직을 작성하고 Android, iOS, 웹과 데스크톱 등 여러 운영체제에서 코드를 공유하도록 설계되었습니다. 개발 중 화면 변경을 빠르게 확인할 수 있는 Hot Reload도 제공합니다. 처음부터 Android와 iOS를 함께 출시하려는 앱이라면 한 코드베이스로 두 플랫폼을 다룰 수 있다는 점이 큽니다.
- 장점: 여러 플랫폼의 UI와 공통 로직을 공유할 수 있고, Flutter의 Widget과 개발 도구로 화면을 일관되게 구성할 수 있습니다.
- 이번 프로젝트에서의 단점: Android 고유 기능은 Flutter 플러그인을 확인하거나 Dart 코드와 Kotlin·Java 코드를 잇는 platform channel을 사용해야 할 수 있습니다. 이 경우 Dart(Flutter)뿐 아니라 Android 쪽 코드와 연결 지점도 함께 살펴봐야 합니다.
이번 앱은 Kotlin(Jetpack Compose)으로 만든다
결정 기준은 지원할 플랫폼과 앱이 다루는 기능입니다. Markdown Viewer는 Android 전용으로 출시하며 iOS나 웹 버전을 동시에 만들 계획이 없습니다. 반면 파일 Intent, Content URI, Storage Access Framework, 화면 크기 변화와 Activity Lifecycle처럼 Android에 맞춰 확인할 항목은 많습니다. Flutter의 코드 공유 장점은 활용하지 못하면서 Android 기능을 연결하는 계층만 늘어날 수 있는 조건입니다.
그래서 이번 앱은 Kotlin(Jetpack Compose)을 선택합니다. 이 구성이 Dart(Flutter)보다 언제나 쉽거나 우수하다는 뜻은 아닙니다. 여러 플랫폼을 한꺼번에 지원한다면 Dart(Flutter)가 더 알맞을 수 있습니다. 지금은 Android 하나에 집중하고 공식 API와 예제를 곧바로 따라갈 수 있는 구성이 초보자가 문제 범위를 좁혀 가며 출시 과정을 배우기에 더 맞다고 판단했습니다.
처음부터 구현하지 않는 이유
AI Coding Agent를 실행하면 바로 “앱 만들어줘”라고 입력하고 싶어집니다. 작은 데모라면 이 방법으로도 화면을 빠르게 확인할 수 있습니다. 실제 출시가 목표라면 구현 전에 사람이 정해야 할 조건이 훨씬 많습니다.
앱 이름과 Application ID, 저장소 이름부터 Android 전용인지, 편집 기능을 제외할지, 어떤 문법까지 지원할지 정해야 합니다. 대용량 문서의 테스트 기준, 개인정보를 수집하지 않는 구조인지, Google Play 등록정보를 어떤 기준으로 작성할지도 구현 방향에 영향을 줍니다.
그래서 2편에서는 구현을 시작하지 않습니다. 대신 개발환경을 점검하고, DEVELOPMENT_ENVIRONMENT.md, MVP.md, ROADMAP.md를 준비합니다. 구현 전 AI 관리문서, Android Skills, 버전 자동관리, Git 커밋 규칙은 3편에서 별도로 고정합니다.
Markdown Viewer 앱 청사진부터 작성한다
지금 만드는 자료는 사람과 AI가 같은 목표와 완료 기준을 보며 작업하기 위한 청사진입니다. 문서를 만드는 일 자체가 목적은 아닙니다. 판단이 바뀌었을 때 어느 내용을 고쳐야 하는지 알 수 있도록 역할에 따라 세 파일로 나눕니다.
DEVELOPMENT_ENVIRONMENT.md: JDK, Android SDK, Gradle, Kotlin과 Compose의 호환 조합 및 실제 검증 결과MVP.md: 첫 출시에서 제공할 기능, 제외할 기능, 품질 기준과 제품의 경계ROADMAP.md: 구현 순서, 작업 간 의존성, 단계별 테스트와 완료 조건
개발환경 보고서는 “이 PC에서 어떤 도구 조합으로 만들 것인가”, MVP는 “무엇을 만들고 어디까지 만들 것인가”, ROADMAP은 “어떤 순서로 만들고 무엇으로 완료를 판단할 것인가”에 답합니다. 목표가 바뀌면 먼저 MVP를 고치고, 구현 순서가 달라지면 ROADMAP을 갱신합니다. 실제 환경이 바뀌었다면 개발환경 보고서의 내용도 다시 검증해야 합니다.
구현이 시작된 뒤에는 README에 프로젝트 목적과 실행 방법을 정리하고, CHANGELOG에 버전별 변경 사항을 남깁니다. AI가 지켜야 할 규칙은 별도의 AI 관리문서에서 다루며, 이 부분은 3편에서 설정합니다. 이름이 비슷해 보여도 각 문서는 개발 과정에서 맡는 역할이 다릅니다.
청사진은 1편의 저장소에서 관리한다
DEVELOPMENT_ENVIRONMENT.md, MVP.md, ROADMAP.md는 1편에서 clone한 markdown-viewer 비공개 저장소에서 함께 관리합니다. 반면 debug·release 키스토어와 서명 정보는 저장소 밖에 따로 보관합니다. 이번 편에서 빈 저장소에 추가하는 것은 앱 코드가 아니라 이 세 문서입니다.
Application ID는 앱의 주민번호와 같다
Android 개발에서는 Application ID를 관습적으로 패키지명이라고 부르기도 합니다. 사람에게 주민번호가 있듯 Application ID는 기기와 Google Play에서 앱 하나를 식별하는 고유한 값입니다. 한 기기에는 같은 Application ID를 가진 앱을 두 개 설치할 수 없고, Google Play에서도 서로 다른 두 앱을 같은 Application ID로 등록할 수 없습니다. 출시 후 Application ID를 바꾸면 기존 앱의 업데이트가 아니라 별개의 새 앱으로 취급되므로 첫 게시 전에 확정해야 합니다.
이 프로젝트의 release Application ID는 com.siamakerlab.markdownviewer입니다. 보통 도메인을 거꾸로 쓴 값에 제품 이름을 붙여 충돌 가능성을 줄입니다. 앱 이름은 사용자가 화면에서 보는 표시 이름이지만 Application ID는 빌드, 설치, 업데이트와 Google Play 등록을 연결하므로 둘의 역할은 다릅니다.
Application ID와 namespace, 코드 package를 구분한다
세 값은 처음에 같게 만들 수 있지만 역할은 다릅니다.
- Application ID: 설치된 앱과 Google Play 등록정보를 구분합니다. 앱 모듈의
build.gradle.kts에서applicationId로 지정합니다. - namespace: Android 빌드 도구가 생성하는
R과BuildConfig클래스의 패키지를 정합니다. - Kotlin/Java package: Activity와 화면, 데이터 처리 코드가 속할 코드 영역입니다. 보통 namespace를 기본 package로 사용합니다.
새 프로젝트에서는 세 값을 같게 시작하는 편이 단순합니다. com.siamakerlab.markdownviewer를 기본 package로 사용하면 소스 코드는 보통 app/src/main/java/com/siamakerlab/markdownviewer/ 또는 app/src/main/kotlin/com/siamakerlab/markdownviewer/ 아래에 놓입니다. 엄밀히 말하면 Application ID 자체가 폴더를 강제하는 것은 아닙니다. namespace와 코드의 package 선언이 폴더 구조에 영향을 주고, 이 프로젝트에서 세 값을 같게 사용하므로 결과적으로 같은 이름이 프로젝트 구조에도 드러납니다.
debug 앱에는 .debug suffix를 붙인다
Google Play에서 설치한 정식 앱과 로컬에서 만든 debug 앱이 같은 Application ID를 사용하면 둘을 한 기기에 나란히 설치할 수 없습니다. 정식 앱과 debug 앱은 일반적으로 서명 인증서도 다르기 때문에 debug APK를 기존 앱의 업데이트로 설치할 수도 없습니다. 이 경우 정식 앱을 제거한 뒤 debug 앱을 설치해야 하며, 제거 과정에서 기기에 저장된 앱 데이터도 사라질 수 있습니다.
그래서 이 프로젝트는 release에 com.siamakerlab.markdownviewer, debug에 com.siamakerlab.markdownviewer.debug를 사용합니다. 실제 Gradle 설정에서는 debug build type에 applicationIdSuffix = ".debug"를 지정합니다.
android {
namespace = "com.siamakerlab.markdownviewer"
defaultConfig {
applicationId = "com.siamakerlab.markdownviewer"
}
buildTypes {
getByName("debug") {
applicationIdSuffix = ".debug"
}
}
}이 설정은 설치되는 debug 앱의 Application ID에만 suffix를 붙입니다. namespace와 소스 코드 package는 com.siamakerlab.markdownviewer를 그대로 사용하므로 .debug용 소스 폴더를 따로 만들 필요가 없습니다. release와 debug를 화면에서도 빠르게 구분하려고 debug 앱 아이콘에 배지를 표시하는 방법도 종종 사용하지만, 이 글에서는 다루지 않습니다.
Codex에 입력할 실제 프롬프트
아래 프롬프트는 한 번에 붙여 넣지 않고 순서대로 실행합니다. 각 단계의 결과를 확인한 뒤 다음 단계로 넘어가야 세 파일의 기준이 서로 어긋나지 않습니다.
개발환경 점검
이 PC에서 Android Kotlin 앱 개발에 필요한 개발환경을 준비해줘.
먼저 현재 시스템에 설치되어 있는 개발도구와 버전을 확인하고,
부족하거나 오래된 구성요소가 있다면 설치 또는 업데이트해.
중요:
- Android, Kotlin, Gradle 등의 공식 문서를 직접 확인한다.
- Preview, Beta, RC, Canary가 아닌 최신 Stable 버전을 사용한다.
- 각 도구를 무조건 개별 최신 버전으로 선택하지 말고
서로 공식적으로 호환되는 최신 안정화 조합을 선택한다.
- 가능하면 시스템 전체에 불필요한 도구를 설치하지 않는다.
- 기존 설치환경을 함부로 삭제하거나 망가뜨리지 않는다.
확인할 항목:
- JDK
- Android SDK
- Android SDK Command-line Tools
- platform-tools / adb
- 필요한 Android SDK Platform
- Android SDK Build Tools
- Gradle
- Android Gradle Plugin
- Kotlin
- Jetpack Compose 개발환경
- Git
환경 구성이 끝나면 실제 명령을 실행해서
Android 프로젝트를 빌드할 준비가 완료되었는지 확인해.
아직 앱 코드는 작성하지 마.
지금은 개발환경 준비와 검증만 수행해.개발환경 보고서 작성
현재 구성한 Android 개발환경을 DEVELOPMENT_ENVIRONMENT.md 문서로 정리해줘.
다음을 포함해.
- OS
- JDK 버전
- Android SDK 위치
- compile/target용 Android SDK
- Build Tools
- Gradle
- Android Gradle Plugin
- Kotlin
- Compose 관련 구성
- Git
- adb
- 주요 환경변수
- 각 버전을 선택한 이유
- 공식 문서 기준 호환 관계
- 설치 및 검증 결과
비밀번호나 개인 경로 등 민감한 정보는 기록하지 마.MVP 작성
Markdown Viewer 안드로이드 앱을 만들고자 함.
앱 이름과 Android 식별자는 다음 값을 사용한다.
- App Name: Markdown Viewer
- Release Application ID: com.siamakerlab.markdownviewer
- Debug Application ID: com.siamakerlab.markdownviewer.debug
- Debug applicationIdSuffix: .debug
- namespace/base package: com.siamakerlab.markdownviewer
release와 debug 앱을 같은 기기에 함께 설치할 수 있도록
두 Application ID를 MVP.md에 구분해서 기록해.
namespace와 소스 코드 package에는 .debug를 붙이지 마.
안드로이드에서 Markdown 문서를 예쁘게 볼 수 있는
간단한 뷰어 앱을 만들 거야.
편집 기능은 없고 Viewer 기능에만 집중한다.
다른 앱에서 파일을 공유해서 보거나,
다운로드 받은 md 문서를 실행했을 때
바로 열어서 볼 수 있으면 좋겠어.
중요한 것은:
- 빠른 동작
- Markdown 문서 호환성
- 정확한 Markdown 렌더링
- 고용량 문서 안정성
- 최신 오픈소스 라이브러리 사용
- 최신 Markdown 기술 및 확장 문법 고려
- Android UX 준수
이 계획에 대한 MVP.md를 작성해줘.ROADMAP 작성
작성한 MVP를 기반으로
실제 구현 가능한 상세 ROADMAP.md를 작성해줘.
작업 순서와 선후 의존성을 고려하고,
각 단계마다 완료 조건을 작성해.
기능 구현뿐 아니라 앱의 특성에 맞는 UI/UX를 분석하고
다음 목표를 ROADMAP에 구체적인 작업과 완료 조건으로 포함해.
- release Application ID는 com.siamakerlab.markdownviewer를 사용한다.
- debug build에는 applicationIdSuffix = ".debug"를 적용해
com.siamakerlab.markdownviewer.debug를 사용한다.
- namespace와 기본 source package는 com.siamakerlab.markdownviewer로 유지한다.
- release와 debug 앱이 같은 기기에 함께 설치되는지 검증한다.
- Navigation 3의 호환되는 최신 Stable 버전을 사용한다.
- 화면 이동과 back stack을 일관되게 관리한다.
- 창 크기와 폴더블 기기의 접힘 상태에 대응하는 adaptive UI를 구현한다.
- 모던하고 단순한 화면으로 문서 읽기에 집중한다.
- 주요 기능에 접근할 때 불필요한 중간 화면과 터치 횟수를 줄인다.
- 화면 회전, 창 크기 변경, 기기 접기·펼치기 이후에도
열어 둔 문서와 읽던 위치가 유지되는지 검증한다.
- 휴대전화, 태블릿, 폴더블과 멀티 윈도우 환경의 테스트 기준을 정한다.
아직 구현하지 말고 ROADMAP 문서만 작성해.ROADMAP 내부 재검토
ROADMAP.md를 내부 기준으로 다시 정밀 검토해.
다음을 기준으로 확인해.
- MVP 범위와 ROADMAP 내용의 정합성
- 작업 순서와 선후 의존성
- Android 공식 문서를 기준으로 한 기술적 구현 가능성
- 불필요한 기능
- 누락된 기능
- 단계별 완료 조건과 테스트 가능성
- 성능 위험
- 보안 위험
분석 결과를 바탕으로 기능을 추가, 갱신, 통합하거나 제거해.
변경 이유와 영향을 ROADMAP에 기록하고 완료 조건도 함께 갱신해.
검토 결과를 반영해 ROADMAP.md를 갱신해.
외부 경쟁 앱, 앱 스토어 리뷰와 커뮤니티 조사는 아직 수행하지 마.UI/UX도 ROADMAP의 완료 조건으로 적는다
기능 목록만 채운 ROADMAP으로는 앱의 사용 흐름을 판단하기 어렵습니다. UI는 화면에 보이는 구성이고, UX는 사용자가 파일을 열고 내용을 읽은 뒤 다음 행동으로 이어지는 전체 경험입니다. “화면을 구현한다”거나 “모던한 UI를 만든다”는 한 줄로 끝내지 않고, 앱의 특성에 맞는 화면 구조와 조작 흐름을 분석해 완료 조건으로 남겨야 합니다.
Markdown Viewer에서는 다음 기준을 ROADMAP에 포함합니다.
- Navigation 3로 화면 이동과 back stack을 일관되게 관리한다.
- 창 크기와 폴더블 기기의 접힘 상태가 바뀌면 사용할 수 있는 공간에 맞춰 화면 구성이 달라지는 adaptive UI를 구현한다.
- 문서 내용에 집중할 수 있도록 모던하고 단순한 화면을 유지하며, 장식보다 읽기와 조작의 우선순위를 높인다.
- 파일 열기나 공유로 전달된 문서를 곧바로 렌더링하고, 주요 기능 앞에 불필요한 중간 화면을 두지 않아 터치 횟수를 줄인다.
- 화면 회전, 창 크기 변경, 폴더블 기기의 접기·펼치기 이후에도 열어 둔 문서와 읽던 위치가 유지되는지 검증한다.
손그림으로 원하는 UI 전달하기
특별히 원하는 화면 구성이 있다면 빈 종이에 펜으로 쓱쓱 그려도 충분합니다. 화면 영역과 버튼 위치, 정보의 우선순위가 드러나도록 그린 뒤 사진을 찍어 프로젝트 폴더에 복사합니다. 예를 들어 docs/ui-reference/markdown-viewer-sketch.jpg처럼 알아보기 쉬운 경로와 파일명을 사용하면 AI에게 정확한 참고 대상을 알려줄 수 있습니다. 디자인 도구를 다루지 않아도 원하는 구성을 빠르게 전달할 수 있어 매우 권장하는 방법입니다.
사진에는 화면 밖의 불필요한 배경이나 개인정보가 들어가지 않도록 잘라내고, 버튼의 역할이나 화면 이동은 짧은 글씨와 화살표로 표시합니다. 손그림은 픽셀 단위로 그대로 복제할 최종 시안이 아니라 화면의 의도와 정보 구조를 전달하는 참고자료입니다. AI가 이를 휴대전화, 태블릿과 폴더블 화면에 맞게 다시 해석하도록 지시해야 합니다.
프로젝트 폴더의 다음 UI 손그림을 확인해.
참고 이미지:
docs/ui-reference/markdown-viewer-sketch.jpg
이미지에서 화면 구성, 정보의 우선순위,
버튼 위치와 화면 이동 의도를 분석해.
중요:
- 손그림을 픽셀 단위로 그대로 복제하지 않는다.
- Markdown 문서 읽기에 집중하는 단순한 UI를 유지한다.
- 주요 기능까지의 불필요한 화면 이동과 터치 횟수를 줄인다.
- Navigation 3 기반 화면 이동과 back stack 구조에 반영한다.
- 휴대전화, 태블릿, 폴더블과 멀티 윈도우에서
사용 가능한 공간에 맞게 바뀌는 adaptive UI로 설계한다.
- 화면 크기가 바뀌어도 열어 둔 문서와 읽던 위치가 유지되어야 한다.
- 손그림에서 의미가 불분명한 부분은 임의로 결정하지 말고 질문한다.
분석한 UI 구성과 기기별 적용 방법,
완료 조건과 테스트 항목을 ROADMAP.md에 반영해.
아직 앱 코드는 구현하지 마.“심플하다”거나 “사용하기 편하다”는 표현만으로는 완료 여부를 확인할 수 없습니다. 기기와 창 크기, 주요 기능까지의 이동 경로, 상태 유지와 테스트 조건까지 적어야 구현 뒤 같은 기준으로 리뷰할 수 있습니다.
ROADMAP은 여러 관점에서 다시 깎아 나간다
처음 작성한 ROADMAP은 바로 구현에 들어가기 위한 확정본이 아니라 검토를 시작하기 위한 초안에 가깝습니다. 앞의 내부 재검토로 문서 안의 모순과 구현 순서를 바로잡았다면, 이제 앱 바깥의 근거를 더할 차례입니다.
앱의 성격에 따라 경쟁 앱도 함께 살펴봅니다. 어떤 기능을 제공하는지에 그치지 않고 첫 실행부터 주요 기능까지 몇 번의 조작이 필요한지, 사용자가 무엇을 핵심 가치로 기대하는지 확인합니다. 앱 스토어 리뷰와 커뮤니티 의견에서는 반복해서 등장하는 장점과 불편을 찾고, UI/UX 분석에서는 화면 구조와 터치 경로가 앱의 목적에 맞는지 다시 봅니다.
경쟁 앱과 사용자 기대를 분석하는 실제 프롬프트
현재 MVP.md와 ROADMAP.md를 기준으로
앱 기획과 사용자 경험을 여러 관점에서 다시 분석해줘.
먼저 앱의 성격, 대상 사용자와 핵심 사용 상황을 파악하고,
이 앱에 필요한 분석 항목만 선택해 진행해.
경쟁 앱 분석이 유효하지 않은 항목은 억지로 비교하지 말고
제외한 이유를 설명해.
조사 원칙:
- 공식 앱 스토어, 제품 공식 페이지, 공개된 최신 리뷰와 커뮤니티 글을 직접 확인한다.
- 현재 제공되는 기능과 최신 상태를 기준으로 분석한다.
- 근거로 사용한 페이지의 URL과 확인 날짜를 기록한다.
- 확인된 사실, 사용자 의견과 분석에 따른 추론을 구분한다.
- 일부 리뷰를 전체 사용자의 의견처럼 확대 해석하지 않는다.
- 확인할 수 없는 기능이나 사용자 반응을 만들어내지 않는다.
분석할 항목:
- 대표적인 직접·간접 경쟁 앱과 각 앱이 해결하는 문제
- 경쟁 앱의 주요 기능과 기능별 진입 경로
- 첫 실행부터 핵심 기능 사용까지 필요한 화면 이동과 터치 횟수
- 사용자가 이 종류의 앱에서 기대하는 핵심 가치
- 앱 스토어 리뷰와 커뮤니티에서 반복해서 언급되는 장점과 불편
- 정보 구조, 화면 계층, 내비게이션과 주요 기능의 발견 가능성
- 불필요한 화면, 중복 기능과 사용 흐름을 끊는 지점
- 휴대전화, 태블릿, 폴더블과 멀티 윈도우에서의 UI/UX
Markdown Viewer에서는 다음 조건도 함께 확인해.
- 문서를 빠르고 정확하게 읽는 Viewer 경험에 집중한다.
- Navigation 3 기반 화면 이동과 back stack 구성이 적절한지 확인한다.
- 창 크기와 폴더블 상태에 따라 바뀌는 adaptive UI 계획을 확인한다.
- 파일 열기와 공유로 들어온 문서가 불필요한 중간 화면 없이 렌더링되는지 검토한다.
- 화면 크기가 바뀌어도 열어 둔 문서와 읽던 위치가 유지되는지 확인한다.
분석 결과는 다음 순서로 정리해.
1. 조사 대상과 출처
2. 사용자가 기대하는 핵심 가치
3. 경쟁 앱과 현재 ROADMAP의 기능·UI/UX 비교
4. 현재 ROADMAP에서 잘 잡힌 부분과 빠진 부분
5. 추가, 갱신, 통합, 제거 또는 보류할 항목
6. 각 변경의 근거, 우선순위, 선행 작업, 영향과 검증 방법
마지막에는 분석 결과를 반영해 ROADMAP.md를 직접 갱신해.
경쟁 앱의 기능을 그대로 복제하거나 MVP 범위를 무조건 넓히지 말고,
Markdown Viewer의 핵심 가치와 출시 가능성을 기준으로 판단해.
아직 앱 코드는 구현하지 마.
이번 작업은 조사, 분석과 ROADMAP 갱신까지만 수행해.분석 결과가 언제나 기능 추가로 이어지는 것은 아닙니다. 우선순위가 낮은 기능은 뒤로 미루고, 겹치는 기능은 합치며, 핵심 경험을 흐리는 항목은 ROADMAP에서 제거할 수도 있습니다. 이렇게 추가·갱신·통합·제거를 반복하면서 각 변경 이유와 완료 조건까지 다시 적어야 구현 단계에서 계획이 흔들리지 않습니다.
검증 체크리스트
- 1편을 완료하고 clone한
markdown-viewer저장소에서 작업 중이다. - Android 개발환경을 실제 명령으로 확인했다.
DEVELOPMENT_ENVIRONMENT.md에 버전과 검증 결과가 정리되었다.MVP.md에 앱 이름, release·debug Application ID, namespace/base package, 앱의 범위와 제외할 기능이 적혀 있다.ROADMAP.md에 debugapplicationIdSuffix = ".debug"설정과 release·debug 동시 설치 검증이 포함되어 있다.ROADMAP.md에 작업 순서와 완료 조건이 있다.- ROADMAP에 Navigation 3, adaptive UI, 주요 기능까지의 터치 경로와 UI/UX 완료 조건이 포함되어 있다.
- 앱의 성격에 맞춰 경쟁 앱, 핵심 가치, 사용자 의견과 UI/UX 관점에서 ROADMAP을 다시 분석했다.
- 재검토 결과에 따라 기능을 추가, 갱신, 통합하거나 제거하고 그 이유를 기록했다.
- 아직 앱 구현은 시작하지 않았다.
이번 편의 완료 상태
이제 release Application ID는 com.siamakerlab.markdownviewer, debug Application ID는 com.siamakerlab.markdownviewer.debug로 확정했습니다. 초기 namespace/base package는 com.siamakerlab.markdownviewer를 유지하고, 사용자에게 보일 앱 이름은 Markdown Viewer로 정했습니다.
DEVELOPMENT_ENVIRONMENT.md, MVP.md, ROADMAP.md를 저장소에 작성하고 경쟁 앱과 사용자 기대, UI/UX까지 체크리스트로 검증했다면 2편에서 할 일은 모두 끝났습니다. 앱 코드는 아직 한 줄도 작성하지 않았지만, 어떤 환경에서 무엇을 만들고 어떤 순서와 화면 흐름으로 구현할지 판단할 기준은 갖췄습니다.
다음 편인 실전 바이브코딩 #3: AGENTS.md와 Android Skills 준비하기에서는 AI 작업 규칙과 Android Skills, 버전·Git 규칙을 정리합니다. 앱 구현은 4편에서 키스토어 준비를 마친 뒤 시작합니다.
참고할 공식 문서
- Android Application ID와 namespace 공식 문서
- Android build variant와 applicationIdSuffix 공식 문서
- Android 앱 설치와 업데이트 조건 공식 문서
- Android Kotlin 공식 문서
- Jetpack Compose 공식 문서
- Flutter 아키텍처 공식 문서
- Flutter platform channel 공식 문서
- Navigation 3 공식 문서
- Jetpack Compose adaptive UI 공식 문서
- Android Intent와 Intent Filter 공식 문서
- Android 문서 및 파일 접근 공식 문서
답글 남기기