메타는 왜 안드로이드 앱을 코틀린으로 다시 짜나

페이스북, 인스타그램 등 1천만 라인 규모 코드베이스 생성

메타는 페이스북, 인스타그램, 메신저, 포탈, 퀘스트VR 등의 안드로이드 앱의 코드를 자바에서 코틀린으로 전환하고 있다. 수천명 개발자를 투입해 진행하는 코틀린 전환 프로젝트에 대해페이스북 내 개발자가 직접 해당 작업의 경험을 공유했다.

최근 미국지디넷은 페이스북 소프트웨어 엔지니어인 오메르 스트룰로비치의 블로그 글을 소개했다.[블로그 바로가기]

오메르 스트룰로비치 엔지니어는 "현재 안드로이드 개발에 사용하는 자바를 코틀린으로 전환하는 것은 사소한 일이 아니다"라고 밝혔다.

그는 "오늘날 페이스북, 메신저, 인스타그램 등의 안드로이드 앱은 각각 100만줄 이상의 코틀린 코드를 갖고 있으며 전환율은 증가하고 있다"며 "전체적으로 안드로이드 코드베이스에 1천만줄 이상의 코틀린 코드가 있다"고 밝혔다.

안드로이드 운영체제용 앱은 자바를 주요 언어로 삼아 개발돼 왔다. 오라클이 안드로이드 OS에 대해 자바 API 저작권 소송을 제기하면서, 구글은 자바를 대체할 주요언어를 다수 물색했다. 코틀린은 여러 후보 중 선택된 공식 1순위 개발언어다.

그는 코틀린의 장점으로 네가지를 들었다. 'Null' 허용 여부를 코틀린에서 기본적으로 제공한다는 점, 실행 속도를 저하시키지 않으면서 함수형 프로그래밍을 사용할 수 있다는 점, 더 짧은 코드를 작성할 수 있다는 점, 도메인 특화 언어(SDL)를 정의할 수 있다는 점 등이다.

그러나 신생언어인 코틀린은 여전히 세계 3위권 개발언어인 자바보다 대중성에서 처진다. 개발언어의 대중성은 단순한 인기 측면보다 활용하기 좋은 보조도구를 확보하기 얼마나 용이한가에 더 영향을 준다. 메타가 안드로이드 앱을 코틀린으로 전환하는 것은 그 코드의 규모를 감안할 때 상당한 도전이다.

스트룰로비치는 대규모 앱의 코틀린 전환에서 나타나는 두가지 단점을 설명했다.

우선, 코틀린은 자바보다 대중적이지 않기 때문에 더 적은 도구가 존재한다는 점이다. 또 코틀린과 자바의 상호운용성을 고려하는 도구는 복잡하다. 메타는 언어의 100% 상호운용성에도 모든 자바를 제거할 수 없다는 사실을 알게 됐다.

스트룰로비치는 "코틀린은 인기있는 언어지만, 자바와 비교할 때 인기 격차는 분명하다"며 "자바는 세계에서 2, 3위 인기 언어고, 이는 코틀린이 더 적은 도구만 쓸 수 있다는 뜻"이라고 설명했다.

그는 "그보다 더 나쁜 건 모든 코틀린 도구가 자바와 상호운용성을 계산해야 하고, 채택을 복잡하게 만든다는 점"이라고 지적했다.

메타가 툴의 부족보다 더 우려하는 건 코틀린의 느린 빌드 속도다.

스트룰로비치는 "코틀린의 빌드 시간은 자바보다 더 길다는 것은 처음부터 알고 있었다"며 "언어와 생태계는 더 복잡하고, 자바는 컴파일러 최적화를 20년 앞서 시작했다"고 적었다.

그는 "메타는 여러 대형 앱을 갖고 있기 때문에 빌드 시간은 개발자의 경험에 부정적 영향을 미칠 수 있다"고 덧붙였다.

그는 HTTP 클라이언트 프로젝트인 'OkHttp'가 2019년 자바에서 코틀린으로 전환된 후 컴파일 시간을 예로 들었다. OkHttp는 2만4천줄의 코틀린으로 작성된 상대적으로 소규모 프로젝트다. 자바의 경우 컴파일 시간이 2.4초였지만, 코틀린 컴파일 시간은 10.2초였다.

스트룰로비치는 "코틀린으로 마이그레이션은 놀라울 정도로 쉽고, 매우 복잡하다"고 밝혔다. 그는 "코틀린 설계는 세심한 상호운용성을 통해 자바에서 간단하게 변환할 수 있어 쉽다"며 "이 디자인을 통해 젯브레인스는 안드로이드스튜디오와 함께 '자바투코틀린' 변환기인 'J2K'를 커뮤니티에 제공할 수 있었다"고 적었다.

이어 "그러나 J2K가 항상 정확한 건 아니며, 자바와 코틀린의 상호운용성은 몇가지 극단적 경우를 노출한다"고 덧붙였다.

메타는 자바 코드를 남기고 새로 작성되는 코드만 코틀린으로 작성하는 방법을 택하지 않았다. 거의 모든 코드를 코틀린으로 전환하는 게 메타의 결정이었다. 비교하자면 리눅스커널과 안드로이드 오픈소스 프로젝트(ASOP)는 러스트를 코드베이스에 도입하기로 결정했다.

스트룰로비치는 신규 코드를 코틀린으로 작성하고 기존 자바 코드를 남겨두는 방식은 해야 할 작업을 줄이지만, 복잡성을 높읻다는 점을 강조했다.

그는 "코틀린과 자바 코드 간의 상호운용성 활성화하면 코틀린에 플랫폼 타입을 사용하게 한다"며 "플랫폼 타입은 코틀린 코드에서 제공하는 정적 안정성 대신 런타임 Null 포인터 역참조를 발생시켜 충돌을 일으킨다"고 설명했다.

그는 "일부 복잡한 경우 코틀린의 null 검사 생략이 null을 허용하고, 나중에 null 포인터 예외를 생성할 수 있다"며 "코틀린 코드가 자바 인터페이스로 구현된 코틀린 인터페이스를 호출하는 경우 이런 상황이 발생한다"고 덧붙였다.

그는 또 다른 문제로 자바를 남겨둘 경우 코틀린의 장점을 개발자가 완전히 누릴 수 없다는 점을 들었다.

코틀린 생태계에 있어 메타의 결정은 상당한 도움이다. 메타는 깃허브에 사내에서 개발한 여러 코틀린 변환도구를 출시했다. 다른 코틀린 사용 개발자는 메타에서 공개한 도구를 직접 사용할 수 있고, 혹은 전환을 자동화하는 좋은 방법을 찾도록 영감을 줄 수 있다.

코틀린 채택은 규모에 비례해 작업의 어려움이 증가한다. 페이스북은 그레이들(Gradle)을 사용하는 인텔리J의 안드로이드 스튜디오 IDE 대신 자체적인 '벅(Buck)' 빌드 시스템을 사용한다.

스트룰로비치는 메타에서 기여한 여러 오픈소스 코틀린 도구를 설명했다. 일례로 자바와 동등한 수준의 경험을 제공하기 위해 사용하는 'Pygments' 라이브러리가 있다. 메타는 또 구글-자바-포맷의 코드와 철학에 기반한 결정론적 코틀린 포맷터 'Kfmt'를 만들었다. 이 도구는 인텔리J 안드로이드스튜디오용 플러그인이다.

몇가지 단점에도 메타가 코틀린 전환으로 거둔 성과는 코드베이스 규모의 감소다.

스트룰로비치는 "지금까지 메타의 코드베이스 크기가 평균 11% 감소했다"고 밝혔다. 과거 구글홈 팀도 새로운 기능을 코틀린으로 이전할 때 앱의 코드베이스 크기를 33% 줄인다고 밝혔었다.

그는 "온라인에서 인용된 훨썬 더 많은 숫자를 봤지만, 이 숫자는 특정 예에서 파생된 것으로 보인다"며 "제거된 라인은 일반적으로 더 짧은 코틀린코드보다 암시적이지 않은 상용구 코드이기 때문에 현 숫자에 만족한다"고 적었다.

그는 이밖에 코틀린의 실행 속도를 자바와 동일하게 유지할 수 있다는 점을 확인했고, 빌드 크기 증가 문제를 해결할 방법을 찾았으며, 길어진 빌드 시간 문제를 개선하는 빌드 시스템을 만들었다는 점을 설명했다.

코틀린은 인텔리J를 만드는 젯브레인스에서 처음 개발했다. 구글은 2017년부터 코틀린을 안드로이드 앱용 언어로 사용했으며, 구글과 젯브레인스는 2018년부터 코틀린재단의 코틀린 언어 개발을 지원하고 있다.

구글의 안드로이드 팀은 2019년부터 '코틀린 퍼스트' 접근법을 채택했다. 구글 지도, 홈, 플레이, 드라이브, 메시지 등 코틀린으로 구축된 구글 안드로이드 앱은 70개를 넘는다. 구글은 코틀린에 대해 자바보다 더 효율적이고 안전하며, 더 작은 코드베이스를 생성하면서도 자바와 100% 상호운용 가능하다고 설명한다. 자바 코드베이스와 코틀린 코드베이스를 공존하게 해 자바에서 코틀린으로 전환을 더 쉽게 할 수 있다고도 한다.

구글의 코틀린 제품매니저인 제임스 워드는 메타의 활동에 환영한다는 입장을 밝혔다.

제임스 워드는 "메타가 코틀린으로 전환하고 성공을 거둔 것을 기쁘게 생각한다"며 "많은 구글의 팀이 안드로이드와 서버 모두를 위해 자바에서 코틀린으로 전환하는 비슷한 여정을 했고, 코틀린 코드는 1천100만 라인 이상으로 절정에 이르렀다"고 밝혔다.

그는 "다른 대규모 프로젝트가 유사한 여정을 거침으로써 구글의 선택을 재확인하게 됐다"고 덧붙였다.