uncrackable 2?

우선 문제 풀이를 위해 에뮬레이터에 앱을 설치한 후 실행시켜보았습니다.

제가 사용중인 에뮬레이터는, Frida 사용을 위해 루팅을 진행한 상태라 앱에 접근하면 곧바로 Root감지 팝업 발생 후 앱이 종료되는 모습을 볼 수 있습니다.

Jadx를 통한 APK 디컴파일

어플리케이션 정적 분석을 위해, JADX를 통해 APK 파일을 디컴파일 해보겠습니다.

디컴파일 후 코드 구조를 확인해보니, 바로 MainActivity가 존재하는 것을 확인했습니다.

그렇다면 MainActivity의 코드 구조를 확인해보겠습니다.

가장 주가 될 함수인 onCreate와 a, verify 그리고 init 이라는 메서드가 존재합니다.

init 메서드는 특이하게 구현체가 없네요 .. 확인해보니 'native' 예약어를 사용한 메서드네요. JNI를 통해 타 언어로 작성된 함수임을 알 수 있습니다. (JNI란?)

JNI 파트는 우선 넘어가고, 다시 코드를 분석해보겠습니다.

가장 먼저 a 메서드 입니다. 아 ... 이녀석이 제 루팅을 감지하고 바로 앱을 종료시킨 버릇없는 녀석이군요. 위에서 만난 루팅 탐지 팝업과 동일한 형태를 정의하고, 호출하는 것을 확인할 수 있습니다.

이번 문제 풀이에서는 사용하지 않으나, Frida를 통해 onClick 메서드를 후킹하면 루팅 탐지 팝업을 무력화시킬 수 있을 것 입니다.

아래에 위치한 verify 메서드를 확인해보니, m 객체의 a메서드를 호출한 결과값으로 성공 팝업을 출력하는 것을 볼 수 있습니다.

JNI로 선언된 코드를 확인해보겠습니다. 우선, JNI는 시스템의 아키텍처에 따라 필요한 native 파일이 달라지기 때문에, 제 아키텍처와 맞는 폴더에 선언된 .so 파일을 Export 해주겠습니다.

그 이후, IDA를 통해 정적 분석을 해보겠습니다. IDA를 통해 .so 파일에 선언된 함수들을 보니, 가장 아래에 JNI 네이밍 규칙에 맞게 CodeCheck 클래스의 bar 메서드가 선언되어 있음을 확인할 수 있습니다.

해당 함수를 디컴파일 해보겠습니다.

문자열을 비교하는 코드들이 있고, 바로 Flag를 확인할 수 있습니다.

성공

Java Native Interface의 약자입니다. Java는 JVM이라는 독립적인 플랫폼을 통해 컴파일 / 동작하기 때문에, 하드웨어에 직접 접근하여 코드를 실행하는 네이티브 코드의 사용이 어렵습니다.

이에 JAVA <-> 네이티브 코드끼리 서로 호출할 수 있도록 도와주는 프레임워크가 JNI 입니다.

왜 쓸까?

JNI를 사용하는 이유는 크게 세가지가 있습니다.

• 성능 최적화
• 기존에 존재하는 라이브러리 사용 (플랫폼 특화 라이브러리 등)
• 플랫폼 종속 기능

사용 방법

public class JniTest {
    public native void nativeMethod();

    static {
        System.loadLibrary("jni_test");
    }

    public static void main(String[] args) {
        new JniTest().nativeMethod();
    }
}

위 코드처럼, 예약어 'native' 를 사용하게 되면 해당 메서드가 네이티브 라이브러리에서 구현됨을 의미합니다.

객체 생성 후 nativeMethod 메서드를 호출하게 되면, 네이티브 코드가 호출됩니다.

네이티브 코드를 호출하는 JAVA 코드를 먼저 작성한 이유는, JNI 연결을 위한 헤더파일을 만들 때, Java의 파일이 지정되어야 하기 때문입니다.

그럼 다음으로 네이티브 코드를 작성하는 방법은 다음과 같습니다.

javac -h . JniTest.java

위 bash 코드를 실행하게 되면, JniTest.h 파일이 생성됩니다.

#include <jni.h>
#include <stdio.h>
#include "JniTest.h"

JNIEXPORT void JNICALL Java_JniTest_sayHello(JNIEnv *env, jobject obj) {
    printf("C에서 호출됨 !\n");
}

위에서 만든 헤더파일을 참조하는 C언어 코드를 다음 형식과 같이 작성합니다.

이후 만든 파일들을 빌드해주면 완료입니다. 플랫폼 별 명령어가 다르니, 참고 부탁드립니다.

MAC or Linux

gcc -shared -fpic -o libjnitest.so -I"$JAVA_HOME/include" -I"$JAVA_HOME/include/darwin" JniTest.c

Windows

gcc -shared -o jnitest.dll -I"%JAVA_HOME%\include" -I"%JAVA_HOME%\include\win32" JniTest.c

이후 자바 코드를 실행해보면, 원하는 출력 결과가 보이는 것을 확인할 수 있습니다.

Project App

처음 사이트에 가입한 후 가장 먼저 풀어본 문제이다.

우선, apk 분석을 위해 jadx로 apk 파일을 열어보았다.

Android App을 구성할 때에, 보통 가장 축이 되는 Activity의 이름을 Main Activity라고 짓는다.

문제의 APK의 MainActivity를 열어보자

플래그가 존재할 것 같은 수상한 함수를 발견했다. 함수의 로직을 직역하면, 다음으로 표현 가능하다.

• decodeSecret 함수를 호출한 결과값과 serialEditText에 입력한 값이 동일한가?
  • Yes : Correct 출력
  • No : Incorrect 출력

editText의 getText 메서드는 그저 입력된 값을 가져오는 코드이니, decodeSecret 메서드의 로직을 확인해보겠다.

decodeSecret의 코드이다. R.raw.secret의 값을 가져와서, Base 64로 디코딩하여 반환하고 있다.

그렇다면 R.raw.secret의 값이 Flag일까 ? -> 그렇지 않다 !!

안드로이드는 키값을 직접 하드코딩 하는 행위를 권장하지 않는다. 그렇기 때문에 보편적으로, 리소스 파일에 텍스트나 이미지를 저장하고 Key값을 통해 리소스를 불러오는 형식을 주로 사용한다.

그렇기 때문에 R.raw.secret의 경우에도 단순한 Key에 불과하며, 저장된 값은 Int형 변수이다.

따라서, 우리는 Apk의 리소스 파일 중, R.raw.secret에 해당하는 파일을 직접 찾아야 한다.

jadx를 통해 APK의 리소스 폴더에 접근해보니, 찾던 secret 파일이 보인다. 바로 열어서 Flag를 확인하면 된다.

그렇지 않았다 .... 내 경우, Mac 환경으로 문제풀이를 진행하고 있는데 그래서인지 jadx로 리소스 파일에 직접 접근하려고 하니, jadx 자체가 멈추며 강제 종료되는 현상이 발생했다. (다른 Windows 사용자들에겐 발생하지 않은 이슈이다.)

이에 다른 툴을 추가로 사용하여 해결했다.

ApkTool APK의 리소스를 디컴파일 하는 툴이다. jadx도 디컴파일 툴임은 동일하나, 리소스를 디컴파일 한다는 것이 더 강조되어 있다.

ApkTool을 통해 리소스를 열어보니, Flag를 확인할 수 있었다.

객체지향이란?

객체지향이란, 객체들간의 상호작용으로 프로그램을 작성하는 것을 목적으로 하는 프로그래밍 방식입니다.

객체지향은 절차지향과 항상 비교군에 있는 대표적인 프로그래밍 방식입니다. 객체지향 프로그래밍을 Object Oriented Programming의 약자인 OOP 라고도 부릅니다.

절차지향이 아니라고 해서 절차가 존재하지 않는다는 뜻은 아닙니다. 절차는 존재하되, 객체들간의 상호작용이 추가된 개념으로 이해하면 됩니다.

그럼 객체들간의 상호작용이 가능한 객체지향 프로그래밍을 왜 사용할까요?

객체 지향을 사용하면, 프로젝트를 구조적이고 효율적이게 만들 수 있도록 합니다.

객체지향이 어떻게 프로젝트를 구조적이고 효율적일 수 있도록 하는지 알기 위해 결제 서비스를 만드는 상상을 해보겠습니다.

절차지향 개발

우리는 결제 서비스를 개발하기 위해, 대한민국에 존재하는 모든 카드사에서 결제가 가능한 프로그램을 개발하고자 합니다.

우선 절차지향의 대표적인 언어중 하나인 C언어로 개발을 시작합니다.

절차지향과 객체지향의 극단적 비교를 위해... 멍청한 코드를 만들어보겠습니다.

각 카드사별 결제에 필요한 API 호출이 다를 것이기에 각 카드사별 결제 함수가 필요할 것입니다.

void hyundai_card_payment_service() {
    // 현대카드 결제
}

void kookmin_card_payment_service() {
    // 국민카드 결제
}

void hana_card_payment_service() {
    // 하나카드 결제
}
.
.
.

위 코드처럼, 모든 카드사의 결제를 정상적으로 처리하기 위해 카드사 개별 함수를 구현해야 합니다.

이렇게 프로그램을 제작한다면 어떤 문제가 있을까요?

여러가지가 있겠지만 대표적인 이슈는 다음과 같습니다.

1. 유지보수가 어렵습니다.
   • 각각의 함수가 존재하기 때문에, 프로그램 수정 시 모든 함수를 각각 수정해야합니다.
   • 수정의 범위가 넓어질수록 테스트 또한 방대해집니다.
   • 코드의 길이가 길어지기에 코드를 보기 어렵습니다.
2. 확장이 어렵습니다.
   • 만약 대한민국에 새로운 카드사가 생긴다면, 그에 맞추어 새로운 함수를 개발해야 합니다.
3. 호출부를 생각하면 어지럽습니다.
   • 각 카드사별 함수 호출을 위해 호출부마다 현재 유저의 카드 정보에 대한 조건문이 필요할 것입니다.

     if (strcmp(card_type, "현대카드") == 0) {
     hyundai_card_payment_service();
     } else if (strcmp(card_type, "국민카드") == 0) {
     kookmin_card_payment_service();
     } else if (strcmp(card_type, "하나카드") == 0) {
     hana_card_payment_service();
     }
     .
     .
     .

     쏟아지는 조건문 ...

물론 절차지향에서도 이러한 문제점을 개선할 방법이 분명 존재하지만, 복잡하고 거대한 프로젝트를 설계할수록, 지속적으로 이러한 문제에 부딛힐 것입니다.

객체지향 개발

위 절차지향에서 발생했던 문제점들을 객체지향 언어인 코틀린을 사용한다면 어떻게 개선할 수 있을까요?

우선 객체지향 프로그래밍의 큰 특징으로 다음이 있습니다.

• 추상화
• 다형성
• 상속
• 캡슐화

추상화

우선 추상화, 우린 다시 카드 결제사의 개발자가 되어 결제 흐름을 구성해보겠습니다. 각 카드 결제사별 공통적으로 필요한 함수가 있을 것 입니다. (결제, 환불, 결제 내역 출력 등 ..)

추상화란, 특정 코드를 작성하기 전에 미리 추상적으로 어떤 코드(동작)가 필요할지 설계할 수 있음을 의미합니다.

interface CardService {
    val name: String

    fun pay()

    fun refund()

    fun print_payment_record()
}

위 코드 예제를 보면, 변수와 함수에 대한 정의는 있지만, 변수 및 함수에 대한 구현은 빠져있음을 확인할 수 있습니다.

이처럼 추상화된 필요한 기능을 정의만 할 수 있는 기능을 인터페이스 라고 부르며 코틀린에서는 'interface' 키워드를 통해 정의합니다.

인터페이스만 정의한다면 아무 동작도 할 수 없으며, 인터페이스를 통해 구현하는 방법은 다형성 파트에서 다루겠습니다.

추상화를 할 수 있는 다른 키워드가 있습니다.

abstract class CardService {
    abstract val name: String

    abstract fun pay()

    abstract fun refund()

    abstract fun print_payment_record()

    fun printLog() {
        print("log")
    }
}

바로 'abstract class' 입니다. 직역하면 추상화 클래스입니다.

interface와의 차이점은, interface는 내부에 어떠한 구현도 할 수 없지만, abstract class는 일부 공통 로직에 대한 구현이 가능합니다.

interface처럼 틀만 작성하고 싶은 함수라면, abstract 키워드를 앞에 붙여 추상화 함수임을 명시하고, 공통 로직을 구현하기 위한 함수라면 일반 함수와 동일하게 선언하면 됩니다.

다형성

형태가 다양하다는 뜻입니다.

우선 예시로, 다형성에 대해 이해하기 위해 위에서 다루었던 인터페이스인 CardService를 통해 class를 만들어보겠습니다.

class HyundaiCardService : CardService {
    override val name: String = "현대카드"

    override fun pay() {
        // 현대카드 결제
    }

    override fun refund() {
        // 환불 요청
    }

    override fun print_payment_record() {
        // 결제 내역 반환
    }
}

이처럼 위에서 정의한 CardService 인터페이스를 통해, 새로운 Class를 정의하고 카드사 각각의 개별 함수를 정의할 수 있습니다.

새롭게 만든 Class가 해당 인터페이스를 따른다는 것을 명시하기 위해, Class 이름 옆에 해당하는 인터페이스의 이름을 ':' 뒤에 작성해줍니다.

인터페이스에서 이미 정의한 함수와 변수를 재정의하는 것이기 때문에, override 키워드를 함께 작성해주어야 합니다.

또다른 추상화 방법이었던 abstract class의 경우, 새로운 Class를 정의하는 방법이 조금 다릅니다.

class HyundaiCardService : CardService() {
    override val name: String = "현대카드"

    override fun pay() {
        // 현대카드 결제
    }

    override fun refund() {
        // 환불 요청
    }

    override fun print_payment_record() {
        // 결제 내역 반환
    }
}

기본적으론 전부 유사하지만 무엇이 바뀌었냐면 ... ':' 뒤에 작성해주던 Abstract class 뒤에 '()' 이 붙은 것을 확인할 수 있습니다.

Kotlin에는 인스턴스라는 개념이 있습니다. 우리가 위에서 정의해온 인터페이스, Class .. 등은 모두 '틀'에 불과하고, 각각 동작하기 위해선 인스턴스를 생성해주어야 합니다.

우리가 다른 언어에서 사용하던 Int와 같은 Type 처럼, 선언만 하면 사용할 수 없지만 초기화를 통해 사용할 수 있던 것을 생각하면 편합니다.

인스턴스를 생성하기 위해 클래스명 뒤에 '()'를 사용합니다.

또한 Class인 틀은 하나여도, 인스턴스는 여러개여도 괜찮습니다.

class HyundaiCardService : CardService() {}

다시 abstract class를 재정의하는 코드를 보겠습니다.

인터페이스와 달리 공통 로직에 대한 구현이 들어있는 class이기 때문에 재정의한 class에 인스턴스를 생성할 때, 해당 absract class에 대한 인스턴스 생성 또한 필요하기에 '()'를 반드시 붙여줘야 합니다.

또한 이를 협업. 즉, 팀 프로젝트에 적용해보겠습니다.

인터페이스 하나만 잘 설계해둔다면, 다른 팀원에게 각각의 구현체를 구현하도록 할 수 있습니다. 서로의 작업 영역이 분리됨으로써 빠른 개발, 오류 방지 등의 효과를 얻을 수 있습니다.

상속

단어 그대로 다른 Class에게 원하는 로직을 '상속' 시킬 수 있습니다.

위에서 살펴본 abstract class에 대한 구현체 또한 하나의 상속 사례로 볼 수 있습니다.

상속을 할 Class를 '부모 클래스' 라고 부르고, 상속을 받는 Class를 '자식 클래스' 라고 부릅니다.

상속에 대한 예제를 만들기 위해 새로운 시나리오를 만들겠습니다.

그간 만들어온 현대카드 서비스에 현대카드 V2가 출시되어 결제할 때, 캐시백을 추가로 지급하도록 예제를 만들어보겠습니다.

open class HyundaiCardService : CardService() {}

위 코드는 이전에 선언했던 HyndaiCardService의 선언부 입니다. 조금 달라진 부분이 있습니다.

바로 open 이라는 키워드가 가장 앞에 추가된 것입니다.

코틀린에서 class를 생성하게 되면, 기본적으로는 상속이 불가능합니다. (자바의 final이 기본적으로 붙어있음) 따라서 상속이 가능한 class로 선언하기 위해 open 이라는 키워드를 추가해줘야 합니다.

class HyundaiCardV2Service : HyundaiCardService() {
    override fun pay() {
        super.pay()
        // 캐시백 지급
    }
}

이제 상속을 받을 차례입니다.

이전 코드들과 동일하게 ':' 옆에 부모 class를 명시해준 후 수정을 원하는 함수를 override 해줍니다.

이렇게 하면 자식 class에서 원하는대로 부모 class의 함수를 수정하는 것이 가능합니다. 또한 예제처럼 부모 class의 함수를 동일하게 사용하고 싶다면, super 키워드를 통해 부모 class의 인스턴스에 접근할 수 있습니다.

이를 통해 상속의 장점을 살리는 프로그래밍을 할 수 있습니다.

캡슐화

우리는 프로그램을 제작하며 많은 사람과 함께 작업을 하고, 과거의 나 자신과 싸우기도 합니다.

결제 서비스를 만들며 한땀한땀 열심히 만든 내 결제 로직을 누군가 접근하여 코드를 수정하면 어떨까요? -> 높은 확률로 오류가 발생하고 시말서 작성이 필요할겁니다 ..

이를 막기 위해 객체지향에선 캡슐화 개념을 적용하였습니다.

단어 그대로 캡슐처럼 코드 영역을 감싸서 외부의 접근을 제어하는 것 입니다.

private, public, protected 등의 키워드를 통해 제어하며

다음처럼 제어가 가능합니다.

private : 같은 클래스 내에만 접근 가능 public : 모든 클래스에서 접근 가능 (아무것도 사용하지 않으면 기본적으로 public) protected : 상속 관계에서만 접근 가능

이를 상속을 위한 부모 class 등의 상위 class에 적용 가능하며 적절히 사용하여 외부 접근을 막거나 허용할 수 있습니다.

open class CardService {
    private val secretKey: String = ""
    protected var name: String = "CardService"
    public var temp: String = "public"
}

class CardServiceImpl: CardService() {
    fun test() {
        // private로 선언한 변수이기 때문에 접근 불가
        // print(secretKey) // 오류 발생
        // protected로 선언한 변수이기 자식 class에서는 접근 가능
        print(name) // CardService
    }
}

class MainTest {
    fun test() {
        val service = CardService()
        // public으로 선언한 변수이기 때문에, 인스턴스만 존재한다면 어디서든 접근 가능
        print(service.temp) // public
    }
}

예시로 코드를 작성하며 반드시 필요한 상수값을 private으로 선언하여 외부에서 변경을 막을 수 있고, 같은 결제 서비스 내 공통적으로 필요한 변수가 있다면, 이는 protected로 선언하여 결제 class끼리만 공유할 수 있습니다.

이번 포스팅에서는 객체지향의 4가지 특징별로 정리를 하며 코틀린의 문법과 함께 포스팅했습니다.

활용도가 높아질수록 명확한 구조로 설계가 가능하기 때문에, 계속 공부해야하는 부분이라고 생각합니다.

APK 란?

APK란, Android Package의 약자로, 안드로이드 앱을 배포, 실행, 설치하기 위해 사용합니다.

APK엔 다음의 파일이 포함됩니다.

• Manifest 파일
  • 앱의 이름, 권한, 실행 정보 등을 포함
• Dex 파일
  • 코드를 컴파일하여 만들어진 실행 파일
• 리소스 파일
  • 이미지, 레이아웃, 문자열 등 앱 UI에 필요한 리소스 파일
• 라이브러리 파일
  • C/C++ 네이티브 코드
• 서명 정보
  • 앱의 무결성 검증과 개발자 인증 서명 파일

AAB ..?

AAB는 Android App Bundle의 약자로, 앱의 모듈과 리소스를 묶은 패키지를 말합니다.

2018년 구글에서 APK를 대체하기 위해 만들어졌고, Playstore에서 2021년 08월부터 APK 대신 AAB만 배포가 가능하도록 변경되었습니다.
AAB는 안드로이드 디바이스에 설치하기 위해, 플레이스토어에서 최적화된 APK를 제작하여 설치합니다.
위에서 살펴본 APK의 내부 파일 중, 리소스 파일은 앱의 크기에 큰 영향을 미칩니다.

여러 국가의 유저를 대상으로 배포하기 위해 방대한 언어셋 파일이 존재할 수 있고, 다양한 해상도의 디바이스를 모두 최적화하기 위해 필요 이상으로 많은 이미지 파일을 APK 파일에 포함해야 합니다.

AAB는 이중 설치할 디바이스에 필요한 리소스만 골라 APK로 만들기 때문에, 앱의 크기를 줄이는데에 매우 큰 효과를 보이고 있습니다.

안드로이드 4대 컴포넌트

안드로이드의 앱을 구성하는 가장 중요한 요소들을 4대 컴포넌트라고 부릅니다.

4대 컴포넌트엔 다음들이 있습니다.

• Activity
• Service
• Broadcast reciever
• Content provider

Activity

Activity란 쉽게 말하자면 '화면' 입니다. 예를 들어 앱에 로그인하기 위해 표시되는 로그인 화면도 Activity이고, 우리가 앱에 상호작용하는 모든 화면은 Activity로 구성되어있습니다.

앱 개발의 편의성을 위해 Fragment를 통해 화면을 구성하기도 하지만, Frament 또한 Activity 위에서 구성되는 요소입니다.

Service

Service는 Activity에서 화면에서 필요한 작업 외에 백그라운드에서 작업이 필요한 경우 사용하는 컴포넌트입니다.

음악 재생, 파일 다운로드 등의 작업에서 유용하게 사용됩니다. 또한 앱이 종료되어도 계속 작업 실행이 가능하다는 특징이 있습니다.

Broadcast receiver

Broadcast receiver는 다른 앱이나 시스템에서 데이터를 수신하고 싶을 때 사용하는 컴포넌트 입니다.

디바이스의 인터넷이 끊겼거나 배터리 부족 등의 상황을 감지하기 위해 사용됩니다.

앱이 여러 상황에서도 에러 없이 정상적으로 작동하기 위해 필수적으로 처리해줘야 하는 컴포넌트입니다.

Content Provider

Content Provider는 서로 다른 앱 간의 데이터 공유를 위해 사용하는 컴포넌트입니다.

예를 들어 디바이스에 저장된 연락처를 조회하기 위해 사용할 수 있습니다.

이외에 다른 데이터를 저장한 SQLite, 파일 등에 접근하기 위해 사용할 수 있는 컴포넌트입니다.

이번 포스팅에서는 APK 파일과 안드로이드의 4대 컴포넌트에 대해 포스팅을 진행했습니다.

안드로이드 개발을 하며 항상 마주했던 개념들이기 때문에 앞으로 잘 기억해야할 것 같습니다.

코틀린은 자바의 문법과 비슷합니다. 기본적인 문법. 즉, 작성 방법이 다를 뿐 내부 클래스, 모듈의 동작은 유사하며 자바 <-> 코틀린 간 높은 호환성을 보여줍니다.

서로 다른 언어가 어떻게 높은 호환성을 보여줄까요? 우선 자바는 프로그램을 실행시키기 위해, JVM 위에서 실행될 수 있도록 .class 타입의 실행 파일을 컴파일합니다.

이것과 동일하게 코틀린 또한 JVM 위에서 실행될 수 있도록 .class 타입의 실행 파일을 동일하게 컴파일합니다.

즉, 서로 다른 언어이지만, 같은 .class 실행 파일로 컴파일 되기 때문에, 높은 호환성을 보일 수 있는 것입니다.

변수 선언

fun main() {    
    var num: Int = 0
    num = 123

    val constNum: Int = 7
    // constNum = 123 <- 변경 불가 !!!
}

코틀린에서 변수를 선언하는 방법은 위와 같습니다. 자바와 달리 var 혹은 val로 변수 선언을 시작하고, 변수의 타입은 변수명 뒤에 지정해주면 됩니다.

var은 변경 가능한 변수를 선언하기 위해 사용하고, val은 변경이 불가능한 변수를 선언할 때 사용하게 됩니다.

Nullable 타입 (널 허용)

fun main() {
    val nullableNum: Int? = null // null 괜찮아요 ~~

    val num: Int = null // Non-null 에러 발생 ! (컴파일 에러)
}

우리는 코틀린 코드를 읽을 때, 타입 뒤에 ?(물음표)가 붙는 경우를 자주 목격하게 됩니다.

이 문법은 타입을 잘 모르겠을 때 모른다고 표현하는 방법일까요?
코틀린은 그렇게 애매한 자세의 프로그래밍 언어가 아닙니다. 이건 코틀린의 특징이자 자바에 비해 가장 강력한 장점으로 꼽히는 Nullable 문법입니다.

?(물음표)가 붙은 타입의 변수는 null이 들어갈 수 있는 변수이고, 붙지 않은 변수 (Ex. var a: Int)는 null이 허용되지 않는 변수로 사용됩니다. ?를 붙이지 않고 선언한 변수에 null을 할당하려고 하면, 컴파일 에러가 발생하게 됩니다.

우리는 개발하며 수많은 NPE (Null Pointer Exception)에 지난 과오를 반성하며 무수히 많은 null-check 구문을 만들어야 합니다.

하지만 코틀린은 이러한 Nullable 타입을 제공함으로써 변수 선언시부터 null에 대한 허용 여부를 강제로 지정하게 함으로써 초반엔 귀찮고 힘들지만 예기치 못한 NPE를 줄일 수 있도록 도와줍니다.

출력

fun main() {
    print("하이 세상")
    println("하이 세상 줄바꿈") //print("하이 세상 줄바꿈\n")
}

print 문법입니다. println을 사용하면 자동으로 줄바꿈이 가능합니다.

조건문

fun main() {
    val test: Int = 3

    if (test == 3) {
        print("삼")
    } else {
        print("낫삼")
    }
}

코틀린의 if 조건문은 다른 언어들과 매우 비슷합니다.

fun main() {
    val test: Int = 3

    when (test) {
        1 -> print("1")
        2 -> print("2")
        3 -> print("3")
        else -> print("Else")
    }
}

이건 코틀린에 존재하는 when 조건문 입니다. 자바의 switch 문과 유사하게, case 별 조건을 설정할 수 있습니다.
제가 가장 좋아하는 신기한 점은 when 문을 사용해 바로 변수에 값을 지정할 수 있다는 점 입니다.

fun main() {
    val test: Int = 3

    val num = when (test) {
        1 -> 1
        2 -> 2
        3 -> 3
        else -> 0
    }
}

위처럼 num에 when 조건문을 사용하여 값을 설정할 수 있습니다.

반복문

fun main() {
    // while 반복문
    var i: Int = 0
    while (i < 3) {
        println(i)
        i++
    }
    // for 반복문
    for (j in 0..3) {
        println(j)
    }
}

반복문 입니다. 다른 언어와 크게 다르지 않습니다. while엔 조건식을 넣어주고, for 문엔 반복 가능한 변수(Range, List)를 넣어주면 됩니다.

함수 선언

fun main() {
    val returnMsg = fun1(1)
    val returnMsg2 = fun2(2)

    println(returnMsg)
    println(returnMsg2)
}

fun fun1(a : Int): String {
    return "return"
}

fun fun2(a : Int): String = "return direct"

코틀린에서 함수를 선언하는 방법은 위와 같습니다. fun1 함수를 예시로, 파라미터의 타입을 변수 선언하듯 타입을 지정해주고, 함수의 리턴 타입 또한 같은 형식으로 지정해줍니다.

하지만 함수가 매우 짧은 경우엔 굳이 중괄호를 사용하지 않아도 됩니다. fun2처럼 '=' 기호를 사용하여 return 구문을 생략하고 함수를 매우 간결하게 선언하는 것 또한 가능합니다.

fun main() {
    val returnMsg = fun1(1)
    val returnMsg2 = fun1(2, 3)

    println(returnMsg)
    println(returnMsg2)
}

fun fun1(a : Int): String {
    return "return"
}

fun fun1(a : Int, b : Int): String {
    return  "overloaded function's return"
}

코틀린은 '메서드 오버로딩' 또한 지원합니다. 같은 함수명을 사용하여도 파라미터가 다르다면 다른 동작을 하도록 구현할 수 있습니다.

코틀린에서 Null을 다루는 방법

엘비스 연산자

fun main() {
    var nullableNum: Int? = null

    print(nullableNum ?: "null이라서 등장")
}

위 문법은 특정 변수가 null인 경우 정해진 값을 반환시키기 위해 사용할 수 있습니다. 따라서 위 코드의 출력 결과는 'null이라서 등장' 입니다.
왜 이 문법을 엘비스 연산자라고 부를까요?

!! 문법

fun main() {
    var nullableNum: Int? = null
    func1(nullableNum)
}

fun func1(a: Int) {
    print(a)
}

위에서 언급했듯이, 코틀린엔 Nullable 타입과 Null을 허용하지 않는 타입이 있습니다. 만약 내가 갖고 있는 변수는 Nullable 한데, 호출하고자 하는 함수의 파라미터가 Null을 허용하지 않는다면 어떻게 될까요?
코틀린에선 이를 컴파일 에러로 인식하여 빌드가 성공하지 않습니다. 이를 위해 다음의 방법을 시도해볼 수 있습니다.

1. Nullable 변수에 값을 할당 or null-check

   fun main() {
    var nullableNum: Int? = null
    nullableNum = 1
    func1(nullableNum)
   
    nullableNum = null
   
    // null-check
    if (nullableNum != null) {
        func1(nullableNum)
    }
   }
   

fun func1(a: Int) { print(a) }

위처럼 코드를 작성하게 되면, nullable 변수였던 'nullableNum'에 값이 할당 혹은 null이 아님을 검증되어 더이상 nullable 하지 않다고 코틀린에서 자동으로 판단하게 됩니다.

따라서 정상적인 함수 호출이 가능합니다. 

하지만 이는 같은 영역에서 선언되고 할당되는 변수의 경우에만 허용되며 영역이 달라지는 경우엔 어디서든 값이 다시 null이 될 수 있기 때문에, 허용되지 않는 방법입니다. 

이 영역의 개념은 추후 포스팅에서 다루도록 하겠습니다. 지금은 서로 구분된 파일 정도로만 알고있으면 충분합니다.

2. !! 문법 사용

```kotlin
fun main() {
    var nullableNum: Int? = null
    func1(nullableNum!!) // <- !! 문법 사용
}

fun func1(a: Int) {
    print(a)
}

본 단락의 제목인 '!! 문법' 입니다. 이 문법은 변수 뒤에 '!!' 을 사용함으로써, 개발자가 이 변수는 null이 아니다! 라고 지정할 때에 사용하게 됩니다.

1번 내용에서 설명했듯, 영역이 달라지는 경우 코틀린은 해당 변수가 null인지 아닌지 확인할 수 없습니다. 따라서 함수를 호출하기 위해 개발자가 강제로 !!를 사용하여 null이 아님을 명시할 수 있습니다.

하지만 이는 null에 대한 처리를 한다기 보단, 강제로 프로그램이 돌아갈 수 있도록 하는 것 이기에 권장되지 않습니다.

실제로 위 코드를 실행해보면, 런타임에서 NPE가 발생하게 됩니다.

이번 포스팅에선 코틀린의 기초 문법 중, class와 연관된 내용은 전부 덜어내고 포스팅을 진행했습니다. 이후 후속 포스팅에선 객체지향의 의미와 코틀린에서의 class 사용에 대하여 포스팅하도록 하겠습니다.