안드로이드 앱을 처음 만들어보려는 사람이든, 이미 몇 개의 프로젝트를 완주해본 개발자든 한 번쯤은 반드시 마주치는 질문이 있다. 코틀린으로 시작할 것인가, 자바로 시작할 것인가. 겉으로 보면 단순한 문법 선택처럼 보이지만, 실제로 이 결정은 개발 속도, 유지보수 비용, 팀 협업 방식, 심지어 채용 시장에서의 경쟁력까지 영향을 미친다.
필자도 처음 안드로이드 개발을 시작했을 때는 자바로 입문했다. 당시만 해도 안드로이드 공식 문서와 대부분의 튜토리얼이 자바를 기준으로 작성되어 있었기 때문에 별다른 고민 없이 자연스럽게 자바를 선택했던 기억이 있다. 하지만 프로젝트 규모가 커지고 널 포인터 예외(NullPointerException)로 인한 크래시 리포트가 쌓이기 시작하면서, 코틀린으로의 전환을 진지하게 고민하게 되었다. 이 글에서는 실무에서 두 언어를 모두 다뤄본 경험을 바탕으로, 각 언어의 특징과 장단점을 구체적으로 비교하고 어떤 상황에서 어떤 언어를 선택하는 것이 합리적인지 정리해보려 한다.
코틀린이 안드로이드 공식 언어가 된 배경
2017년 구글 I/O에서 코틀린이 안드로이드 공식 지원 언어로 발표되었을 때, 업계는 꽤 큰 충격을 받았다. 자바는 안드로이드 출시 초기부터 사실상 유일한 개발 언어였고, 수많은 라이브러리와 문서, 커뮤니티 자산이 자바를 중심으로 형성되어 있었기 때문이다. 그럼에도 구글이 코틀린을 공식화한 이유는 명확했다. 자바가 가진 근본적인 한계, 특히 널 안정성 부재와 장황한 보일러플레이트 코드 문제를 해결할 대안이 필요했던 것이다.
이후 2019년 구글은 한 걸음 더 나아가 안드로이드 개발의 “코틀린 퍼스트(Kotlin-first)” 정책을 선언했다. 새로운 안드로이드 API와 젯팩(Jetpack) 라이브러리들이 코틀린을 기준으로 먼저 설계되고 문서화되기 시작했으며, 젯팩 컴포즈(Jetpack Compose) 같은 최신 UI 프레임워크는 아예 코틀린 없이는 제대로 활용하기 어려운 구조로 만들어졌다. 이런 흐름을 실무에서 체감한 적이 있는데, 최근 몇 년간 새로 올라오는 안드로이드 공식 샘플 코드나 코드랩(Codelab) 자료들을 살펴보면 자바 버전이 아예 제공되지 않거나 뒤늦게 업데이트되는 경우가 많아졌다.
문법적 차이가 실제 생산성에 미치는 영향
코틀린과 자바의 가장 직관적인 차이는 코드의 간결성이다. 자바에서는 데이터 클래스 하나를 만들기 위해 생성자, getter, setter, equals, hashCode, toString을 일일이 작성해야 하지만, 코틀린은 data class 키워드 하나로 이 모든 기능을 자동으로 생성해준다. 실제로 필자가 진행했던 프로젝트에서 자바로 작성된 모델 클래스 파일을 코틀린으로 변환했을 때, 코드 라인 수가 평균 40% 이상 줄어드는 경험을 했다. 이는 단순히 타이핑 양이 줄어드는 것을 넘어, 리뷰해야 할 코드가 줄어들고 버그가 숨을 공간이 줄어든다는 실질적인 이점으로 이어진다.
또 하나 무시할 수 없는 차이는 널 안정성(Null Safety)이다. 자바 개발을 하다 보면 런타임에 갑자기 발생하는 NullPointerException 때문에 골머리를 앓는 경우가 흔하다. 코틀린은 타입 시스템 자체에 널 가능성을 포함시켜, 컴파일 시점에 널 관련 오류를 상당 부분 걸러낼 수 있게 설계되었다. 필자가 담당했던 프로덕션 앱에서도 자바 코드베이스에서 발생한 크래시의 상당수가 널 참조와 관련된 문제였는데, 해당 모듈을 코틀린으로 마이그레이션한 이후 관련 크래시 리포트가 눈에 띄게 줄어든 사례가 있었다.
코루틴과 비동기 처리, 코틀린의 실질적 강점
안드로이드 개발에서 비동기 처리는 피할 수 없는 과제다. 네트워크 통신, 데이터베이스 접근, 파일 입출력 등 대부분의 작업이 메인 스레드를 차단하지 않도록 별도 처리가 필요하기 때문이다. 자바 환경에서는 전통적으로 AsyncTask, Handler, RxJava 등을 활용해 비동기 처리를 구현해왔는데, 콜백 지옥(callback hell)이라 불리는 중첩 구조 문제가 항상 골칫거리였다.
코틀린은 코루틴(Coroutine)이라는 강력한 도구를 제공한다. 코루틴을 사용하면 비동기 코드를 마치 동기 코드처럼 순차적으로 작성할 수 있어 가독성이 크게 향상된다. 실제로 여러 개의 네트워크 호출을 순차적으로 처리하면서 각 단계마다 에러 핸들링을 해야 하는 로직을 자바의 콜백 방식과 코틀린의 코루틴 방식으로 각각 구현해본 적이 있는데, 코드 가독성과 유지보수성에서 체감되는 차이가 상당히 컸다. 특히 여러 명이 협업하는 프로젝트에서는 코드를 읽는 시간 자체가 줄어들기 때문에 팀 전체의 생산성에도 긍정적인 영향을 준다.
그럼에도 자바를 선택해야 하는 경우
그렇다고 해서 자바가 완전히 도태된 언어는 아니다. 우선 자바는 20년 이상 축적된 방대한 오픈소스 생태계와 스택오버플로우 답변, 서적, 강의 자료를 보유하고 있다. 특정 레거시 라이브러리나 SDK가 자바 기반으로만 제공되는 경우, 코틀린 프로젝트에서도 자바 코드를 함께 사용해야 하는 상황이 종종 발생한다. 다행히 코틀린은 자바와의 상호운용성(interoperability)을 최우선 설계 원칙으로 삼았기 때문에, 하나의 프로젝트 안에서 두 언어를 혼용하는 것이 기술적으로는 큰 무리 없이 가능하다.
또한 이미 대규모 자바 코드베이스를 보유한 기존 앱을 운영 중인 회사라면, 전면적인 코틀린 전환보다는 신규 기능부터 점진적으로 코틀린을 도입하는 전략이 현실적이다. 필자가 참여했던 한 프로젝트도 기존 자바 코드베이스를 유지한 채, 새로 추가되는 모듈에만 코틀린을 적용하는 방식으로 전환을 진행했는데, 이 방식이 리스크를 최소화하면서도 팀이 코틀린에 자연스럽게 적응할 수 있는 좋은 완충 지대가 되어주었다.
마지막으로 학습 곡선 측면에서도 고려할 점이 있다. 프로그래밍을 처음 배우는 입문자라면 자바가 가진 명시적이고 장황한 문법이 오히려 기초 개념, 예를 들어 객체지향, 타입 시스템, 예외 처리 등을 이해하는 데 도움이 될 수 있다는 의견도 존재한다. 코틀린의 간결한 문법은 익숙해지면 강력한 무기가 되지만, 그 이면에 숨겨진 동작 원리를 제대로 이해하지 못한 채 사용하면 오히려 디버깅이 어려워지는 경우도 있다.
실무 관점에서의 최종 선택 기준
결국 코틀린과 자바 중 무엇을 선택할지는 몇 가지 기준으로 정리할 수 있다. 첫째, 신규 프로젝트를 시작하는 경우라면 구글의 공식 방향성과 최신 라이브러리 지원, 개발 생산성을 고려했을 때 코틀린을 선택하는 것이 합리적이다. 특히 젯팩 컴포즈로 UI를 구성할 계획이라면 코틀린은 사실상 필수에 가깝다. 둘째, 기존 대규모 자바 프로젝트를 유지보수하는 입장이라면 전면 전환보다는 신규 모듈부터 코틀린을 점진적으로 도입하는 하이브리드 전략이 리스크 관리 측면에서 유리하다. 셋째, 채용 시장과 팀 구성을 고려해야 한다. 최근 채용 공고를 살펴보면 안드로이드 개발자 요건에 코틀린 숙련도를 기본으로 요구하는 경우가 눈에 띄게 늘었는데, 이는 장기적으로 코틀린 역량이 개발자 경쟁력에 직결된다는 것을 시사한다.
두 언어 모두 각자의 자리가 있다. 다만 안드로이드 생태계 전체가 코틀린 중심으로 재편되고 있다는 흐름을 감안하면, 새롭게 안드로이드 개발을 시작하는 입장에서는 코틀린을 우선적으로 학습하고, 필요에 따라 자바 코드를 읽고 이해할 수 있는 능력을 함께 갖추는 것이 가장 현실적인 전략이라고 할 수 있다. 언어 선택은 결국 도구 선택의 문제이며, 프로젝트의 성격과 팀의 상황에 맞춰 유연하게 판단하는 것이 가장 중요하다.