2. 안드로이드 기본 구조의 이해 (5) - gradle(그레이들) [2/2]

 

 

 

앞선 아티클에서 우리는 프로젝트 레벨의 그레이들(gradle)을 살펴보았습니다. 그러나 우리가 실제로 직접 수정하거나 확인하게 되는 부분은 모듈 단위의 그레이들이 될 것입니다. 이제 실제 모듈 레벨의 그레이들을 실제로 살펴보면서, 내용들을 살펴보겠습니다. 

 

plugins {
    id 'com.android.application'
}

android {
    compileSdk 31

    defaultConfig {
        applicationId "com.example.androidlab"
        minSdk 21
        targetSdk 31
        versionCode 1
        versionName "1.0"

        testInstrumentationRunner "androidx.test.runner.AndroidJUnitRunner"
    }

    buildTypes {
        release {
            minifyEnabled false
            proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro'
        }
    }
    compileOptions {
        sourceCompatibility JavaVersion.VERSION_1_8
        targetCompatibility JavaVersion.VERSION_1_8
    }
}

dependencies {

    implementation 'androidx.appcompat:appcompat:1.3.1'
    implementation 'com.google.android.material:material:1.4.0'
    implementation 'androidx.constraintlayout:constraintlayout:2.1.0'
    testImplementation 'junit:junit:4.+'
    androidTestImplementation 'androidx.test.ext:junit:1.1.3'
    androidTestImplementation 'androidx.test.espresso:espresso-core:3.4.0'
}

 

 

 

 

---

 

 

 

 

우선, 여기서 가장 헷갈릴 수밖에 없는 SDK 관련 설정들에 대해서 먼저 짚어보겠습니다. 의외로 어렵지 않은 개념이니 하나씩 살펴보도록 하겠습니다.

 

· compileSdk : 이것은 기본적으로 해당 모듈(앱)을 빌드할 때 이용되는 SDK 버전 정보를 설정하는 것입니다. 여기서는 SDK버전 31로 지정되어 있네요? 그렇다면 이 모듈은 안드로이드12 SDK로 개발된다는 것을 의미합니다. 쉽게 말해서, 이론적으로 해당 모듈은 SDK버전 31까지 제공하는 API와 기능을 사용할 수 있다는 것을 의미하게 됩니다. 지원하는 '가장 높은' 버전이 되겠죠. 특별한 이슈가 없다면, 이 부분은 가장 최신 버전으로 유지해 주는 것이 좋습니다.

 

단, 이것은 앱에서 해당 SDK가 지원하는 모든 기능을 사용할 수 있다는 것을 의미하지는 않습니다. 이와 관련해서 targetSdk 개념이 연계 되지요. 이는 다시 아래에서 살펴보겠습니다. 

 

그리고 덧붙여서 외부에서 작성된 코드나 라이브러리를 import하여 사용할 때, compileSdk에 지정된 버전으로 찾게 됩니다. 오류가 발생하는 경우, 안드로이드 스튜디오에 설치된 툴 버전으로 명시하거나, 맞는 버전의 툴을 설치하는 등의 수정이 필요합니다.

 

· minSdk : 이는 해당 모듈이 어느 버전의 스마트폰까지를 지원하는지를 결정하게 됩니다. 여기서는 '21'로 지정되어 있습니다. 이는 곧 안드로이드5 버전의 스마트폰까지 지원한다는 의미가 됩니다. 즉, 해당 버전보다 낮은 OS인 스마트폰에서는 설치 자체가 되지 않는 것입니다. 

 

· targetSdk : 개발 시, 실제로 설계하고 사용하는 SDK 버전을 선언하는 것입니다. 이게 무슨 의미일까요? 위에서 compileSdk에서 선언한 것과 별개인 듯 합니다. 예를 들어서, 우리가 compileSdk 31을 설치해서 개발을 진행하는 상태인데, targetSdk는 30을 쓴다고 가정하겠습니다. 이럴 경우, 실제로 SDK 버전 31에서부터 제공하는 최신 기능을 구현할 수 없습니다. 

 

우리가 어떤 버전 이상에서 제공하는 API와 피처를 사용하려고 하면, 최소한 targetSdk에서 해당 버전 이상이 선언되어 있어야 하는 것입니다. 그리고, 당연하게도 compileSdk는 targetSdk 이상(>=)이 되어야 하겠죠?

 

minSdk <= targetSdk <= comileSdk 

 

결과적으로 targetSdk로 선언한 버전이 있다면, 해당 버전의 기기까지는 정상적인 작동이 테스트 되었다고 생각하면 됩니다(QA와는 다른 개념입니다). compileSdk가 31인데 targetSdk가 30이라면 30인 기기에서의 동작은 보장하겠지만, 31에서는 어떻게 동작할지 모르는 것입니다. 

 

그렇기 때문에 가능하다면 안정적으로 동작하기 위해서는 compileSdk와 targetSdk가 같은 상황이 가장 이상적입니다. 

 

minSdk <= targetSdk == comileSdk 

 

 

 

 

---

 

 

 

· versionCode / versionName : versionCode는 말 그대로 앱의 버전을 의미하는데, 1부터 정수(int)로 올라가게 됩니다. 이를 통해서 업데이트 시 새로운 버전을 검토하게 되는 것이죠. 단, 이는 유저를 대상으로 하는 버전 표기가 아니라 개발자와 스토어를 위한 버전을 의미합니다. 

 

우리가 흔히 보는 1.x.x와 같은 표현이 versionName에 해당합니다. 이는 유저와 외부 공개를 위해 사용하는 명칭이죠. 실제 앱을 업데이트하거나 갱신하는데 영향을 주지는 않습니다. 통상적으로 [major.minor.point] 형식으로 버전 이름을 명명하게 됩니다. 

 

major는 말 그대로 콘셉트, 방향성이 크게 바뀌는 경우를 의미합니다. minor의 경우에는 기능 추가 / 삭제 혹은 사양의 변경을 의미합니다. 마지막 point는 일부 디자인 변경, 버그 수정 수준을 의미합니다. 

 

 

 

· applicationId : 이는 앱의 고유 식별자를 의미합니다. 흔히 말하는 패키지명이죠. 안드로이드 앱은 기본적으로 별도의 키가 아닌 해당 패키지명으로 식별하게 됩니다. 세상에서 유일무이해야 하는 식별자이며, 동일한 패키지명이 있다면 스토어에 등록도 불가능하고 - 해당 패키지명으로 된 앱이 설치가 되어있다면 새로 설치도 되지 않습니다. 

 

 

· dependencies : 개발 시, 안드로이드 표준 라이브러리 외의 다양한 외부 라이브러리를 사용하게 될 것입니다. 이 때, 라이브러리 적용을 위해서 이곳에 등록을 하게 됩니다. 그래야 빌드 시에 해당 라이브러리를 정상적으로 참조가 가능하기 때문이죠.