태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.


이번 글에서는 열심히 만든 안드로이드 앱을 구글 플레이 스토어에 등록하기 위해 필요한 절차를 설명합니다.


참고로, 릴리즈를 준비하는 방법에 대한 문서는,

         http://developer.android.com/intl/ko/tools/publishing/preparing.html 

에서 자세히 살펴볼 수 있습니다. (언제나 그렇듯이 제작업체에서 제공하는 공식 문서는 항상 가까이 해야 합니다.)


이 글도 위 문서에 기초해서 꼭 필요하다고 생각 되는 것을 정리해 보겠습니다. (참고로 이 글은 위 문서의 번역본이 아닙니다. 따라서 위 문서에서 빠지는 내용도 많고, 위 문서에는 없는 내용도 있습니다.)


참고로, 이 글은 안드로이드 스튜디오 1.1.0 기준으로 쓰여졌습니다.


제작한 앱을 구글 플레이 스토어와 같은 스토어에 올려서 배포하기 위해서는 릴리즈 빌드된 APK 파일을 만들어야 합니다. 우리가 일반적으로 개발할 때 사용하는 빌드 설정은 디버그 빌드입니다. 


디버그 빌드와 릴리즈 빌드의 차이점은 릴리즈 빌드는 개발자의 고유 인증서로 서명한다는 것과 (디버그 빌드는 디버그 인증서로 서명합니다. 대체로 디버그 인증 서명은 개발툴에서 알아서 해주기 때문에(수동으로도 가능) 초보 개발자는 모르고 있을 수도 있지만 존재한다는 것은 기억해야 합니다.) Zipalign 툴로 최적화 되어 있다는 점이 다릅니다. 필요에 따라 ProGuard와 같은 난독화 툴을 사용하여 난독화 하기도 합니다. (자바는 구조상 소스코드 노출에 취약하기 때문에 코드 보안을 위해 난독화를 해야 하는 경우가 많습니다.)


중요한 점 하나는 릴리즈 빌드에 사용하는 개발자의 고유 인증서는 생성하고 사용한 후 절대로 잃어 버리면 안된다는 점입니다. 특히 iOS 개발하는 분들은 이점이 iOS와 크게 다르다는 것을 기억할 필요가 있습니다. iOS와는 달리 고유 인증서를 잃어 버리면, 다시는 해당 앱의 업데이트 버전을 만들 수 없게 됩니다. (새로 인증서를 만들면 완전히 다른 앱으로 취급됩니다.)


자 그럼 이제 앱을 릴리즈할 준비를 해 볼까요?



앱을 릴리즈 하기 위해 준비해야 할 것들



(1) 구글 플레이 스토어 정책 확인


무엇보다 자신이 만든 앱이 구글 플레이 스토어 정책에 위반 되는 사항이 없는지 꼼꼼히 체크해야 합니다.


작년 중순쯤부터인가 구글은 구글 플레이 스토어에 올라가 있는 앱이 정책을 위반하는지 상당히 강하게 확인을 하고 있는 것으로 알려져 있습니다.


애플 앱스토어의 경우에는 사전 검수에서 정책에 위반 되면 등록을 거부하지만, 구글 플레이 스토어의 경우에는 사전 검수가 없는 대신 올리고 나서 정책 위반이 발견되면 강하게 제재를 가하기 때문에 반드시 정책을 확인해야 합니다.


구글 플레이 스토어의 정책과 관련한 문서는,

https://support.google.com/googleplay/android-developer/answer/4430948?hl=ko

에서 확인 할 수 있습니다. 


이 문서는 한국어를 지원하기 때문에 쉽게 확인해 볼 수 있을 것입니다. (사실 문서 내용이 그리 많지는 않습니다.)


iOS 개발자이든 안드로이드 개발자인든 각각의 앱스토어에 본인의 앱을 올리려면 항상 정책문서(애플은 리뷰 가이드라인)를 자주 확인하고 적용해야 합니다. (이렇게 말하고도 저도 자주는 확인 못하고 앱을 등록할때나 되서야 확인을 하네요)



(2) 암호화 키


안드로이드 앱은 iOS 앱과 마찬가지로 개발자의 개인키로 인증된 인증서가 필요합니다. 이것으로 안드로이드는 앱의 제작자가 누구인지 식별합니다. 참고로 서두에서도 언급했듯이 안드로이드는 절대로 서명한 인증서 파일(키스토어 파일이라고 함)을 잃어 버리지 않아야 합니다. iOS와는 달리 새로 생성해서 사용할 수 있는 방법이 없습니다. (아예 다른 제작자로 인식됨)


인증서 파일을 생성하는 방법은 다음 포스팅에서 다룹니다. (사실 인터넷상에도 많이 나와 있고, 구글 공식 문서에도 있습니다.)


참고로, 문서에서는 인증서 유효기간을 2033년 10월 22일 이후로 하라고 써놓았네요. 넉넉히 앞으로 업데이트 할 기간을 생각해서 충분히 긴 기간을 유효기간으로 해야 문제가 없겠죠?



(3) 앱 아이콘


디바이스의 홈 스크린이나 런처 윈도우에 나타날 앱의 아이콘을 준비해야 합니다. (구글 플레이 스토어에도 나타남) 문서에서는 아이콘 가이드라인을 참조할것을 권고한다고 되어 있는데요. 거기에 나와 있는 내용중에 일단 런처 앱 아이콘 사이즈를 얘기해 보자면, 디바이스를 위해서 48x48dp 아이콘과 구글 플레이 스토어를 위해서 512x512px 아이콘을 준비하라고 되어 있네요.

디바이스 아이콘 단위가 dp라서 헷갈리는데 (어차피 런처 아이콘은 픽셀 단위로 작업해야 하는데... ㅡㅡ), 참고로 48x48dp는, MDPI에서 48x48px, HDPI에서 72x72px, XHDPI에서 96x96px 입니다.



(4) 구글 플레이 스토어에 올라갈 멋진 앱 제목


구글 플레이 스토어에 올라갈 멋진 앱 이름이 필요하겠지요. 일반적으로 사용자가 이해하기 쉬운 제목이 좋다고 하더군요. 주의 할 점은 앱 제목도 구글 가이드 라인 제재 대상입니다. 따라서 구글 가이드 라인을 꼭 먼저 읽어 보고 준수해야 합니다. (요즘 가이드 라인 제재가 상당히 타이트 해졌다고 하니 꼭 주의 해야 하겠습니다.)



(5) 구글 플레이 스토어에 올라갈 적절한 앱 설명


막상 올릴때 앱 설명을 쓰려고 하면 머릿속이 하얗게 됩니다. 사전에 미리미리 본인의 앱을 잘 표현할 앱 설명을 준비 합니다. 이것 역시 앱 제목과 마찬가지로 구글 가이드 라인 제재 대상이므로 반드시 구글 가이드 라인을 읽어보고 준수해야 합니다.



(6) 스크린샷 및 Featured Image


사용자들은 앱을 받기 전에 스크린샷을 많이 보기 때문에 (앱 설명은 읽지도 않는 경우도 많다고 합니다) 좋은 스크린샷을 준비하는 것도 꼭 필요하겠죠?


준비해야 할 그래픽 리소스와 관련된 사항은,

https://support.google.com/googleplay/android-developer/answer/1078870

을 참조하면 되겠네요.



(7) EULA (선택사항)


EULA가 뭔지는 아시죠? 개발하시는 분들이 EULA 모르시면 안됩니다. End User License Agreement 의 약자인데요, 한국어로 하자면 '최종 사용자 계약서' 정도 되겠습니다. 즉, 소프트웨어는 사용자 입장에서 소유하는 개념이 아니라 사용 허가를 받는 개념인데요, 이 권리에 대해서 또한 책임의 한계등에 대해서 서술해 놓은 계약 문서입니다. 이 라이선스 문서가 잘 정의 되어 있어야 법적으로 뒷 탈이 없으니 만들어 두어라 라는 의미로 보면 되겠습니다.



앱 설정 확인 사항


이제 실제로 프로젝트에서 확인해야 될 사항들을 살펴보죠.


(1) 적절한 패키지명


릴리즈 하기 전에 패키지 이름을 확정 해야 합니다. 패키지 이름은 한번 구글 플레이 스토어에 배포 하고 나면 변경할 수 없기 때문에 신중하게 정하는 것이 좋겠죠. 안드로이드스튜디오에서는 AndroidManifest.xml (package속성)과 Build.gradle (applicationId 항목) 두 파일에 패키지 이름이 들어갑니다. 우선순위는 Build.gradle 이 높다고 하지만 혼동을 방지하기 위해서 둘다 같은값으로 되어 있는지 확인하는게 좋을 것 같습니다. (빌드 타입을 여러가지로 하고 빌드 타입별로 패키지 이름을 다르게 할 때는 예외)



(2) 권한 및 버전, 타겟 SDK 버전 확인


먼저 앱에서 필요로 하는 권한을 AndroidManifest.xml 에 정의 해야 합니다. <uses-permission...... > 태그로 된 것들을 말하는 것이죠. 적절한 권한을 명시하지 않으면 앱이 해당 권한이 필요한 기능을 사용할때 죽게 됩니다. 따라서 적절한 권한을 꼭 확인해 봐야 합니다.


버전은, 사용자가 식별할 앱에 표시할 버전과, 내부적으로 개발자가 관리할 버전을 정의해야 합니다.

아래는 제가 사용한 build.gradle (앱모듈)의 일부입니다. 


android {

    compileSdkVersion 21

    buildToolsVersion "21.1.1"


    defaultConfig {

        applicationId "ooo.ooo.ooo.oooooooo"

        minSdkVersion 14

        targetSdkVersion 21

        versionCode 1

        versionName "1.0.0"

    }

.

.

.

}



위 파일 내용중, versionName이 사용자에게 보여줄 버전입니다. 스트링이니 자유롭게 정할 수 있습니다.

versionCode가 내부적으로 개발자가 관리하는 버전이라고 보면 됩니다. 

applicationId가 패키지 이름입니다.

minSdkVersion은 이 앱이 실행될 최소 안드로이드 버전이라고 생각하면 됩니다. (이 밑으로의 안드로이드 버전에서는 실행되지 않습니다.)

targetSdkVersion은  실제 개발 작업에 사용하는 안드로이드 SDK 버전이라고 생각하면 되겠죠. 기준이 되는 SDK 버전이라고 할 수 있습니다.


참고로, 안드로이드 스튜디오에서는 위와 같은 build.gradle이 AndroidManifest.xml보다 우선 순위가 높다는 점 기억하고 있어야 합니다.


버전과 관련된 자세한 내용은,

http://developer.android.com/intl/ko/tools/publishing/versioning.html

에서 확인 할 수 있습니다.



(3) 디버깅 불가능 하도록 차단


사실상 일반적으로 안드로이드 스튜디오가 알아서 해주기 떄문에 신경쓸 필요는 없습니다만 확인은 해보는게 좋겠습니다.


본인이 만든 앱이 다른 누군가에 의해 해킹 당할 가능성을 줄이기 위해 릴리즈 하는 APK는 디버깅을 할 수 없어야 하겠죠. 혹시 안드로이드스튜디오와 같은 IDE를 사용하지 않는 경우는 수동으로 설정해야 할 수 있다고 하는데, (막는 방법은 AndroidManifest.xml 에서, <application>태그 속성의 android:debuggable=false를 해주면 된다고 합니다.) 일반적으로 IDE를 사용하기 때문에 릴리즈 모드로 빌드 하면 자동으로 false가 된다고 합니다. (이 속성이 true이면 구글 플레이 스토어에 올릴 수가 없다고 하네요)



(4) 불필요한 로그 정리


개발시에는 적절한 디버깅 정보를 보기 위해 Log.d 와 같은 로그 정보 출력 API를 많이 사용하게 됩니다. 하지만, 개발할 때 디버깅 및 테스트 용도로 사용을 하는 것이지, 일반 사용자에게 배포가 되고 난 후에는 불필요한 부하가 걸릴 뿐 아니라, 보안상으로도(혹시 노출되면 안되는 값을 찍는다던지 하는등...) 문제가 될 수 있습니다. 그러므로 불필요한 로그는 주석처리 하거나 다른 방법으로 해당 코드가 호출되지 않도록 합니다.


제 개인적으로는 Log.d 대신에 개인적으로 만들어 사용하는 유틸 클래스에서,


    public static final void logD (String TAG, String message) {

        if (BuildConfig.DEBUG) {

            Log.d(TAG, message);

        }

    }


와 같이 만들어 대신 사용합니다. 이렇게 하면 디버그 빌드에서만 해당 코드가 실행됩니다.


아쉽게도 C++이나 Objective C 같은 언어와는 달리 전처리기를 지원하지 않기 때문에 완전히 삭제 할 수 있는 방법은 없지만, 자바에서는 빌드시 항상 false 인 조건은 바이너리 코드에서 빼버린다고 하니 그럭저럭 사용할 만 할 것입니다. (그렇게들 주장 하더군요... 전처리기는 불필요한 것이라니....정말 불편한데요...)


참고로, BuildConfig.DEBUG는 ADT 17 이상에서만 지원된다고 합니다. 안드로이드스튜디오 정식버전 사용하는 분들은 해당 사항 없겠네요. 기본이 24인가 그렇죠? (확실하진 않습니다.) 또한 BuildConfig.DEBUG는 바로 android:debuggable 의 값을 사용하기 때문에 android:debuggable 상태를 확인하는 데도 간편하게 사용할 수 있다고 합니다.


그리고, 문서상에서는 startMethodTracing() 와 stopMethodTracing() 같은 디버깅 트레이트 메소드들도 제거 하라고 되어 있습니다. (저는 아직까지는 사용해 보지 않은 API이긴 합니다.) 또한, 웹뷰를 사용하고 있다면 반드시 setWebContentsDebuggingEnabled (false)로 웹 디버깅을 차단하라고 하는군요.



(5) 프로젝트 내의 불필요한 파일 정리


개발하다 보면 이래저래 파일들이 쌓이게 됩니다. 그러다가 개발이 끝나고 나서 보면 불필요한 파일들이 남아 있게 되는데, 이러한 파일들은 정리 하는 것이 좋습니다.


구글 문서를 보면, 디렉터리마다 있어야 할 파일들(즉, 없어도 되는 파일은 없애라는 것이겠죠)을 알려 주고 있습니다.


확인해 보아야 할 디렉터리들을 정리하면 아래와 같습니다.


jni/ - NDK관련 소스파일만 있어야 함 (예: c, cpp, h, mk 파일등)

lib/ - 라이브러리 파일만 있어야 함 (예: .so, jar 파일등). 테스트 용도로 쓰고 릴리즈에는 필요없는 라이브러리 파일도 삭제

src/ - 소스코드 파일만 있어야 함 (예: .java, .aidl 등). 어떤 jar 파일도 있으면 안됨

res/, assets/, res/raw/ - 불필요한 파일은 삭제 



(6) 코드 난독화


이 부분은 상황에 따라 코드 난독화를 할지 말지를 결정 해야 합니다.


안드로이드에 사용되는 자바는 언어 특성상 빌드 후에 C/C++언어나 Objective C와 같은 네이티브 언어들과는 달리 네이티브 바이너를 생성하는 것이 아니라 자바 바이트 코드라는 중간 바이너리 코드를 생성하게 됩니다. (이것은 마이크로소프트의 닷넷 언어도 마찬가지 입니다.) 


이런 종류의 언어는 멀티플랫폼을 지원하기 편리하다는 장점이 있지만, 빌드된 바이너리가 너무 쉽게 디컴파일 된다는 단점이 있습니다. 사실상 리버스 엔지니어링으로 소스코드가 거의 노출 된다고 볼 수 있습니다.


따라서 코드의 보안이 중요한 프로젝트의 경우는 코드의 난독화라는 과정을 거쳐야 합니다. 코드 난독화란 소스코드를 사람이 알아보기 어렵게 바꾸는 것을 의미합니다. 물론 이렇게 해도 100% 보안을 유지하지는 못합니다만, 안하는 것보다는 훨씬 낫다고 볼수 있겠죠.


이 작업을 할 수 있는 것이 ProGuard 를 사용하는 것입니다. ProGuard는 안드로이드 스튜디오에서 활성화 하면 사용할 수 있게 되어 있습니다. 여기서는 난독화를 하기로 결정한 경우 ProGuard 같은 툴을 사용해야 한다는 정도만 적어 놓습니다. 사용법은 검색해 보세요.


참고로 ProGuard는 난독화도 하지만 최적화 기능도 있다고 하네요.



(7) APK 사이즈 확인


구글 플레이 스토어에 올릴 수 있는 APK 파일은 크기가 50MB로 제한되어 있습니다. APK가 50MB가 넘으면 올리지 못합니다. 그래서 본인의 앱이 50MB가 넘어 간다면, 확장 파일을 만들어 사용해야 합니다. (확장 파일에는 이미지나 사운드 또는 기타 리소스 등이 들어가게 됩니다.)


확장 파일에 대해서는,

http://developer.android.com/intl/ko/google/play/expansion-files.html

문서를 확인해 보시기 바랍니다.



(8) 각종 써드파티 라이브러리 및 서비스들의 아이디와 설정 확인


개발하다 보면 여러가지 써드파티 라이브러리나 서비스를 연동하는 경우가 있습니다. 애드몹이나 다음애드핏같은 광고 솔루션을 연동할 수도 있고, 페이스북이나 트위터같은 SNS를 연동할 수도 있습니다.


여하튼 이러한 써드파티 라이브러리나 서비스를 연동하고 릴리즈 할때 설정을 릴리즈 설정으로 바꾸어 놓았는지 확인합니다. 예를 들어 어떤 광고 솔루션은 테스트를 할때는 테스트 아이디를 사용하도록 하고 있습니다. 그런데, 릴리즈 할때 테스트 아이디 그대로 해놓고 배포를 해버린다면, 광고는 나오지 않게 되겠죠?


그러므로 반드시 각종 라이브러리나 서비스를 릴리즈 모드에 맞게 설정해 두었는지 반드시 확인하도록 해야 합니다.




이렇게 앱을 배포하기 전에 준비하거나 확인해야 할 점들을 살펴봤습니다.



이 외에 구글 플레이 스토어에 올리기 위해 체크 리스트가,

http://developer.android.com/intl/ko/distribute/tools/launch-checklist.html

에 있으므로 참고하면 도움이 될 것입니다.




다음 포스팅에서는 실제로 인증서로 서명하고 릴리즈 모드로 빌드하는 방법을 알아봅니다.




(C) 2015 WingsNote.com, 무단 복제 게시 금지. 링크 허용.



Posted by 날개

댓글을 달아 주세요

  1. 이전 댓글 더보기
  2. 이승희 2016.07.16 03:45 신고 Address Modify/Delete Reply

    안녕하세요 반가워요

  3. 만델라 2016.09.04 10:37 신고 Address Modify/Delete Reply

    고마워요~!
    지금 출시전입니다만
    정말 하나하나 다 읽어보고 있어요
    그에 맞는 글을 써주셔서 정말 감사합니다

    활동중이시라면 답변 한방만 부탁드려요 궁금한게 잇어서요
    (앱을 아직 한번도 출시 안한상태인데, 구글개발자 이름을 변경할 수 있는지 궁금합니다)

    1,2편 정말 감사합니다~!

    • 날개 2016.09.20 11:50 신고 Address Modify/Delete

      실제로 되는지는 확인 못해봐서 될지는 모르겠는데요, 일단 구글플레이 콘솔에 들어가시면, 화면 맨 왼쪽에 아이콘들 중 톱니바퀴 모양의 '설정'이 있습니다.
      '설정'에 들어가면 '계정 세부정보'가 있고, 그 안에 '개발자 이름' 을 변경할 수 있게 되어 있습니다.
      저장 후 실제 반영되는데는 시간이 걸릴 수 있다고 하는것 같습니다.

  4. 김병희 2016.09.30 05:18 신고 Address Modify/Delete Reply

    감사,
    감사합니다.

  5. 2017.01.21 20:22 Address Modify/Delete Reply

    비밀댓글입니다

  6. LG,넥센,한화,삼성,KT,소프트뱅크,요코하마,주니치,라쿠텐,NP.. 2018.02.07 20:00 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  7. 1 2018.02.07 21:13 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  8. 1 2018.02.08 20:30 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  9. LG,넥센,한화,삼성,KT,소프트뱅크,요코하마,주니치,라쿠텐,NP.. 2018.02.09 06:22 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  10. LG,넥센,한화,삼성,KT,소프트뱅크,요코하마,주니치,라쿠텐,NP.. 2018.02.09 18:01 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  11. 1 2018.02.10 18:50 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  12. 1 2018.02.11 19:50 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  13. LG,넥센,한화,삼성,KT,소프트뱅크,요코하마,주니치,라쿠텐,NP.. 2018.02.12 08:29 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  14. LG,넥센,한화,삼성,KT,소프트뱅크,요코하마,주니치,라쿠텐,NP.. 2018.02.13 20:11 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  15. 1 2018.02.13 21:06 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  16. LG,넥센,한화,삼성,KT,소프트뱅크,요코하마,주니치,라쿠텐,NP.. 2018.02.14 17:55 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  17. 1 2018.02.14 18:43 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  18. LG,넥센,한화,삼성,KT,소프트뱅크,요코하마,주니치,라쿠텐,NP.. 2018.02.15 11:15 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  19. 1 2018.02.15 20:11 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  20. LG,넥센,한화,삼성,KT,소프트뱅크,요코하마,주니치,라쿠텐,NP.. 2018.02.16 10:46 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

  21. 솔루션 2018.02.17 08:58 Address Modify/Delete Reply

    관리자의 승인을 기다리고 있는 댓글입니다

티스토리 툴바