2025년 11월 10일·5분
원활한 첫 제출을 위한 Flutter 출시 준비 체크리스트
이 Flutter 출시 준비 체크리스트로 서명, 플래버, 크래시 리포팅, 권한 문구, 스토어 자산을 준비해 첫 제출을 차분하고 완전하게 만드세요.
이 Flutter 출시 준비 체크리스트로 서명, 플래버, 크래시 리포팅, 권한 문구, 스토어 자산을 준비해 첫 제출을 차분하고 완전하게 만드세요.
“릴리스 준비”는 “앱이 내 폰에서 실행된다”는 의미가 아닙니다. 여기서 의미하는 바는 프로덕션 빌드를 생성해서 깨끗한 기기에 설치할 수 있고, 마지막 순간의 놀라움 없이 스토어에 제출할 수 있다는 것입니다.
첫 제출 직전에 문제가 생기는 원인은 대개 지루하지만 고통스러운 것들입니다: 서명 키 누락, 실수로 디버그 빌드를 업로드함, 유용한 로그가 없는 크래시, 의심스러운 권한 프롬프트, 앱과 맞지 않는 스토어 자산(잘못된 아이콘, 오래된 스크린샷, 누락된 개인정보 설명) 등입니다.
첫 Flutter 제출에서는 “릴리스 준비”가 네 가지 결과로 요약됩니다:
이 문서는 첫 제출 필수 항목(서명, 플래버, 크래시 리포팅, 권한 문구와 타이밍, 스토어 자산)에 집중합니다. 전체 QA 계획, 성능 감사, 법적 검토는 포함되지 않습니다.
최소 몇 번의 집중 세션을 계획하세요. 개인 개발자는 보통 1~2일 내에 대부분을 처리할 수 있습니다. 팀에서는 서명/빌드, 크래시 리포팅, 스토어 등록 및 카피에 대해 명확한 소유자를 지정해 마지막 순간에 몰리지 않도록 하세요.
대부분의 “마지막 순간” 릴리스 문제는 초기에 결정하지 않은 항목들 때문에 발생합니다. 몇 가지 기본을 지금 고정하면 하류의 모든 것이 더 간단해집니다.
먼저 정체성부터 시작하세요: 사용자가 보는 정확한 앱명과 스토어가 쓰는 내부 ID(Android의 패키지명, iOS의 번들 식별자). 이를 늦게 변경하면 업데이트나 딥링크, 분석 기록이 깨질 수 있습니다. 또한 릴리스 버전 정책을 결정해 각 빌드에 명확한 번호를 붙이세요.
그다음 플랫폼 범위를 정하세요: 첫날 Android, iOS, 둘 다 중 무엇을 지원할지, 그리고 사용자를 기준으로 한 최소 OS 버전. 최소 버전을 늦게 올리면 디자인 변경을 강요하거나 지원하리라 예상한 기기를 제외할 수 있습니다.
이 결정을 팀이 찾을 수 있는 곳에 문서로 남기세요:
마지막으로 스토어 계정이 존재하고 퍼블리시할 수 있는지 확인하세요. 계정 승인 대기, 누락된 세금 서류, 업로드 권한 부족 같은 것이 출시를 막는 큰 원인입니다. Koder.ai 같은 도구로 앱을 생성하든 직접 코딩하든 이 결정들은 동일하게 적용됩니다.
앱 서명은 앱 업데이트가 진짜 당신에게서 왔음을 증명합니다. 서명이 잘못되면 스토어에서 업로드를 거부하거나 업데이트를 제공할 수 없게 될 수 있습니다.
Android에서는 서명이 보통 keystore 파일(및 비밀번호)을 포함한 업로드 키를 의미합니다. iOS에서는 Apple Developer 계정에 묶인 인증서와 프로비저닝 프로파일을 의미합니다. Koder.ai로 빌드하고 소스 코드를 내보내도 첫 제출 전에 스토어 계정과 서명 자산의 명확한 소유권이 필요합니다.
플랫폼별로 기록 책임자를 정하세요. 개인 계정보다 회사 계정이 이상적입니다. 한 사람이나 한 컴퓨터에 의존하지 않도록 접근 규칙을 설정하세요.
간단한 기록에 다음을 포함하세요:
Android 키를 잃으면 동일 앱 패키지에 대한 향후 업데이트가 차단될 수 있습니다. 암호화된 백업을 별도 장소에 만들고 복원 테스트를 하세요. iOS는 접근을 잃으면 계정 복구가 고통스러우므로 신뢰할 수 있는 관리자 여럿을 두고 누가 그들인지 문서화하세요.
깨끗한 머신(새 체크아웃, 새 CI 러너, 동료의 노트북)에서 서명을 검증하세요. 특정 컴퓨터에서만 동작하면 준비가 된 것이 아닙니다.
플래버는 “내 폰에서 작동함”이 “테스트 서버를 배포함”으로 이어지는 것을 막아줍니다. 간단히 말해 플래버는 파일을 매번 편집하지 않고도 다른 설정을 사용하는 명명된 빌드입니다.
대부분 팀은 dev(테스트용)와 prod(제출용) 두 플래버로 시작해야 합니다. 팀에서 “staging”을 사용한다면 그 이름을 쓰세요. 혼동되는 이름은 잘못된 빌드가 공유되거나 업로드되는 원인이 됩니다.
플래버 간에 무엇이 다른지 고정하세요. 가장 흔한 차이는 앱 정체성(이름과 번들 ID), 아이콘, API 엔드포인트, 기능 플래그, 분석/크래시 설정, 로깅 레벨입니다.
민감한 값은 레포에 두지 마세요. 환경 파일, CI 시크릿, 빌드 시 주입 변수 등을 사용해 키가 커밋되지 않게 하세요.
완료 선언 전에 사용하려는 모든 플래버를 빌드하세요. 누락된 설정은 출시 당일이 아니라 여기서 드러납니다.
깨끗한 빌드를 배포해도 실제 환경의 문제(특정 기기, 불안정한 네트워크, 엣지 케이스 흐름)를 놓칠 수 있습니다. 크래시 리포팅은 그런 놀라움을 해결 가능한 목록으로 바꿔줍니다.
하나의 크래시 리포팅 도구를 선택하고 일찍 연결하세요. 브랜드는 덜 중요합니다. 중요한 것은 모든 릴리스가 유용한 리포트를 전송하도록 하는 것입니다.
많은 “재현 불가” 상황은 심볼 누락에서 옵니다. 릴리스 단계에서 다음을 업로드하도록 하세요:
수동이면 바쁜 주에 건너뛰어집니다.
첫날에 필요한 항목을 결정하세요: 앱 버전/빌드, 기기 모델, OS 버전, 로케일, 마지막 화면 또는 동작. 계정이 있다면 익명 사용자 ID와 로그인/비로그인 플래그를 추가하세요. 로그에 개인 데이터를 포함시키지 마세요.
비치명(fatal) 에러뿐 아니라 비치명(non-fatal) 에러도 캡처하세요. Flutter에서는 충돌로 이어지지 않는 예외(파싱 오류, 타임아웃, 예기치 않은 null 등)가 많습니다. 이런 것들은 짧은 메시지와 몇 가지 키-값 필드로 비치명 이벤트로 전송하세요.
출시 전에 테스트하세요: 스테이징 빌드를 만들어 강제 크래시를 트리거하고(디버그 메뉴나 시크릿 제스처 뒤에) 올바른 버전과 컨텍스트로 읽을 수 있는 스택 트레이스가 도착하는지 확인하세요.
권한은 첫 실행에서 신뢰를 잃게 하는 빠른 방법입니다. 릴리스 전에 앱이 요청할 모든 권한과 그 권한이 필요한 기능, 사용자가 얻는 이득을 나열하세요. 한 문장으로 설명할 수 없다면 요청하지 않는 것이 좋습니다.
문구는 쉬운 말로 구체적으로 쓰세요. “사진 접근이 필요합니다”보다 “영수증에 사진을 첨부하려면 사진 접근을 허용하세요”가 더 좋습니다. “저장소” 같은 기술적 단어는 상황에서 설명이 없으면 피하세요.
사용자가 관련 동작을 실행할 때만 요청하세요. 앱 시작 시 사진 권한을 묻지 마세요. 사용자가 “사진 추가”를 탭할 때, 짧은 사전 안내 화면 뒤에 요청하세요.
사용자가 거부해도 앱이 여전히 사용 가능하게 설계하세요. 사전에 대체 수단을 준비하고 기능을 보이게 유지하며 진행 중인 작업을 저장해서 사용자가 작업을 잃지 않도록 하세요. “다시는 묻지 않기”를 선택하면 설정으로 안내하되 과하게 재촉하지 마세요.
플랫폼별 문구를 다시 확인하세요. iOS는 Info.plist에 명확한 사용 목적 설명이 필요하고, Android는 올바른 매니페스트 항목과 때로는 짧은 인앱 설명이 필요합니다. 누락되거나 모호한 문구는 리뷰 지연이나 사용자 이탈을 초래할 수 있습니다.
릴리스 빌드에서만 발생하는 문제를 잡아내기 위한 가벼운 점검입니다. 한 시간 내에 실행할 수 있도록 간단히 유지하세요.
개발 도구가 없어도 누구나 따라 할 수 있는 간단한 스크립트를 작성하세요. 규칙: 개발자가 검사할 수 있는 것이 아니라 사용자가 하는 행동을 테스트하세요.
적어도 작은 폰 한 대와 큰 폰 한 대(이상적으론 오래된 OS 버전 하나)에서 다음을 실행하세요:
실행 후 강제 종료하고 재시작해 앱이 웜 상태에 의존하지 않고 깨끗하게 시작하는지 확인하세요.
문제가 생기면 정확한 화면, 마지막 동작, 특정 기기 사이즈에서만 발생하는지 여부를 적어 두세요. 빠른 수정에 충분한 정보입니다.
런칭 스트레스의 많은 부분은 코드가 아닌 스토어 페이지에서 옵니다. 등록을 릴리스 작업의 일부로 취급하면 마지막 순간의 디자인 요청, 누락된 개인정보 답변, 스크린샷 혼란을 피할 수 있습니다.
거의 확실히 필요할 항목을 모으세요: 앱 아이콘, 스크린샷, 짧은 부제/한 줄 설명, 긴 설명, 플랫폼별 필수 그래픽. 프로모션 비디오는 선택 사항이며 최신 상태로 유지할 수 있을 때만 가치가 있습니다.
스크린샷은 사용할 기기 크기를 미리 정하고 그 크기에 맞춰 유지하세요. 일관된 순서(온보딩, 핵심 화면, 주요 기능, 설정, 업그레이드)를 유지하면 나중에 업데이트가 급해지지 않습니다.
설명은 사람에게 말하듯 쓰세요: 앱이 무엇을 하는지 한 문장으로 명확히 말하고, 그다음 몇 줄의 핵심 이점, 구독이나 계정이 있다면 간단히 표기하세요. 할 수 없는 것을 약속하지 마세요.
또한 개인정보·데이터 사용 관련 답변을 지금 모으세요. 추적, 수집 데이터 유형, 권한 여부 등을 묻습니다. 위치, 연락처, 사진을 요청하면 왜 필요한지 간단히 설명하세요.
자산을 잘 정리하면 업데이트는 일상 작업이 됩니다. 단순한 구조(아이콘, 기기별 스크린샷, 카피, 개인정보 노트, 릴리스 노트)면 충분합니다.
드라이런은 실제로 출시할 것처럼 스토어 제출 흐름을 진행하되 Publish를 누르기 전까지 멈추는 것입니다. 추정을 실제 답으로 바꿔 줍니다.
제출해도 되는 빌드를 하나 골라(출시하지 않을 수도 있음) 업로드하고 양식을 작성해 초안으로 저장하세요. 부족한 정보를 출시 전 시간 여유가 있을 때 찾게 됩니다.
검증할 항목:
또한 “첫 릴리스가 나쁘면” 어떻게 롤백할지 결정하세요(이전 서명된 아티팩트 보관), 핫픽스 배포 방법, 롤아웃을 중단할 트리거(크래시 급증, 로그인 실패).
출시 후 첫 48시간 동안 초기 피드백을 어떻게 수집할지도 결정하세요. 소규모 그룹 채널, 실제로 모니터하는 지원 인박스, 인앱 “피드백 보내기” 옵션은 분명한 문제를 별점 한 개 리뷰가 되기 전에 잡을 수 있습니다.
대부분의 지연은 테스트한 빌드와 실제로 배포하는 빌드가 다르기 때문입니다. 디버그나 프로파일 빌드는 완벽해 보여도 릴리스 빌드에서는 축소(minification), 다른 구성 값, 누락된 런타임 권한 때문에 실제 기기에서 실패할 수 있습니다.
또다른 시간 낭비는 개발 설정과 프로덕션 설정이 섞이는 것입니다: 스테이징 API URL을 배포하거나 잘못된 분석 키나 테스트 결제 설정을 배포하는 경우입니다. 프로덕션을 별도의 환경으로 취급하고 정확한 릴리스 아티팩트에서 검증하세요.
자주 팀을 태우는 함정들:
금요일 업로드를 상상해 보세요: 리뷰어가 앱을 열고 접근을 요청하는 기능을 탭했는데 문구가 모호합니다. 문구를 고치긴 했지만 서명 키는 오프라인인 동료의 기계에 있습니다. 이건 막을 수 있는 이틀의 지연입니다.
첫 스토어 빌드를 만들기 전날에 사용하세요. 의도적으로 짧습니다. 어떤 항목이 “아마도”이면 진행을 멈추고 배포 전에 고치세요.
Koder.ai(koder.ai) 같은 플랫폼으로 프로젝트를 내보내는 경우, 내보낸 프로젝트가 실제로 업로드할 동일한 서명된 릴리스 빌드를 생성하는지 확인하는 추가 검사를 하세요.
세 명의 소규모 팀(개발자 1명, 디자이너 1명, 파트타임 PM)으로 첫 Flutter 앱을 스토어에 올립니다. 그들은 첫 제출을 리허설처럼 취급합니다.
월요일에 개발자가 릴리스 빌드를 생성하자 서명 키가 곧 포맷될 예정인 랩탑에만 있다는 것을 알게 됩니다. 그들은 그날 해결합니다: 키를 공유 접근 제어 볼트로 옮기고 소유권을 문서화하며 CI 머신이 서명할 수 있음을 확인합니다.
화요일에 PM이 모든 권한 프롬프트를 큰 소리로 읽어봅니다. 사진 권한 문구가 “필수”라고 되어 있었는데 실제로는 프로필 사진 선택에만 필요했습니다. 그들은 문구를 재작성해 이점으로 설명하고 권한 요청을 사용자가 “사진 추가”를 탭했을 때로 옮깁니다.
목요일에 최종 스크린샷, 릴리스 노트, 프로덕션 빌드로 드라이런 제출을 합니다. 스토어에서 설명과 인앱 구독 라벨이 불일치한다고 표시합니다. 드라이런이었기 때문에 출시일 전에 문구를 조정하고 재저장합니다.
다음 번을 위해 간단한 타임라인을 유지합니다:
첫 출시는 “준비됨”이 실제로 무엇인지 가르쳐 줍니다. 경험이 생생할 때 그것을 기록하세요.
명확한 소유자를 지정하세요. 작은 팀에서도 “모두”는 보통 “아무도”를 의미하므로 핵심 작업이 빠집니다:
지금 한 일을 반복 가능한 체크리스트와 릴리스 노트 템플릿으로 만드세요: 실행한 명령, 필요한 승인, 업로드한 파일을 적어두세요. 문제가 되었던 점(예: 어떤 플래버가 프로덕션인지, 어떤 권한 문구가 리뷰어에게 지적받았는지)도 적어두세요.
릴리스 후 일주일 내에 20분짜리 회고를 예약하세요. 책임을 묻기보다 수정에 집중합니다:
Koder.ai로 빌드하면 Planning Mode가 릴리스 작업을 한곳에서 추적하는 데 도움이 되고, 스냅샷으로 마지막 순간 변경 전에 알려진 정상 상태를 확보할 수 있습니다.
릴리스 준비되었다는 것은 서명된 프로덕션(릴리스) 빌드를 생성해 깨끗한 기기에 설치하고 마지막 순간 수정 없이 스토어에 제출할 수 있다는 뜻입니다.
실용적인 기준은:
정식으로 제출할 동일한 빌드를 테스트하려면 릴리스 빌드를 만들고 한 번도 앱이 설치된 적 없는 기기에 설치하세요.
확인할 것:
디버그/프로파일만 테스트했다면, 실제로 배포하는 것을 테스트한 것이 아니라고 가정하세요.
서명 자산을 프로덕션 자격증명으로 취급하세요:
키가 한 랩탑에만 있다면 업데이트를 잃을 위험이 큽니다.
iOS 서명은 Apple Developer 계정과 명확한 관리자 접근으로 묶어 두세요.
일찍 하세요:
두 가지 플래버로 시작하세요: **dev**와 prod.
일반적으로 달라지는 항목:
목표는 출시 전 수동으로 파일을 편집하지 않도록 하는 것입니다.
레포에서 민감한 값을 제거하세요:
이렇게 하면 스테이징 엔드포인트나 테스트 결제 설정이 실수로 배포되는 것을 방지합니다.
하나의 크래시 리포팅 도구를 선택하고 릴리스 프로세스의 일부로 일찍 통합하세요.
최소 구성:
그리고 스테이징/릴리스 빌드에서 강제 크래시를 발생시켜 리포트가 읽을 수 있는지 확인하세요.
권한은 사용자가 기능을 실행할 때 요청하세요.
좋은 패턴:
모호한 프롬프트나 시작 시 권한 요청은 신뢰 상실과 리뷰 지연의 일반 원인입니다.
1시간 이내로 할 수 있는 빠른 ‘릴리스 빌드 스모크 테스트’:
문제가 있으면 마지막 화면, 마지막 동작, 기기 모델과 재현 여부를 기록하세요.
드라이런으로 스토어 제출 흐름을 시작해서 공개 전 초안으로 저장하세요.
준비 여부 확인 항목:
또한 게시 전 어떤 상황에서 롤백하거나 핫픽스를 배포할지 계획하세요.