⚡메타, 자바에서 코틀린으로?

코드를 다시 짜는 이유는 😲 ?

2022. 11. 30.

⚡메타, 자바에서 코틀린으로?

💬 Editor's Comment

안녕하세요, 구독자님!
2023년까지 한 달 밖에 남지 않았어요! 새해에 다짐했던 목표를 달성하셨을지 궁금한데요.
만약 달성하지 못했어도 괜찮아요! 우리에게는 한 달이라는 긴 시간이 있으니까요. 그래서 오는 12월은 아직 실천하지 못한 일, 아쉬웠던 일들을 새롭게 도전하는 달이 되었으면 해요. 마지막까지 힘내서 기억에 남을 2022년을 만들어요 우리 💪🏻

그럼 11월의 에러데이나잇, 지금 시작합니다 🤗

오늘의 에러데이나잇 미리보기

[TECH ISSUE] 메타, 자바에서 코틀린으로?
[IT GLOSSARY] 오늘 알아볼 용어 ‘정적 타입 언어, 동적 타입 언어'
[TECH STORY] IMQA 성능 개선기 1편_ 대시보드가 너무 느려요!
[IMQA NEWS] 2022년 마지막 참가 전시회 ‘소프트웨이브’
[BUSINESS STORY] 문제를 겪고 있는 고객의 사용 현황만 확인할 순 없을까?

#안드로이드앱 코틀린 전환 #예정된 프로젝트? #배경과 이유 #현재 상황은?

메타는 페이스북, 인스타그램, 메신저 등 안드로이드 앱의 코드를 자바에서 코틀린으로 전환하고 있는데요. 이 코틀린 전환 프로젝트에 수천 명의 개발자가 투입되었어요. 그렇다면 메타는 왜 안드로이드 앱을 코틀린으로 다시 짤까요? 이번 시간에는 코틀린으로 전환하기까지의 배경과 이 프로젝트에 참여했던 페이스북 개발자가 경험한 내용을 정리해 보았어요.

예정된 프로젝트?

안드로이드 앱은 주요 언어로 자바를 사용하여 개발했어요. 하지만 2010년, 오라클은 구글이 안드로이드 앱에서 오라클의 자바 API를 사용하는 것은 저작권 침해라며 구글을 고소했는데요. 10년 동안 진행된 이 소송의 결과, 작년 ‘API에는 저작권이 있다. 그러나 공정사용 대상이다’라는 판결이 났어요. 이 말은 구글이 소송에는 패소하였지만 실질적으로는 승리했다고 여겨지는데요. 왜냐하면 저작권을 침해하더라도 배상 의무를 지지 않기 때문이에요.

그리고 이런 과정에서 구글은 꾸준하게 탈 자바를 준비해 왔어요. 안드로이드 스튜디오를 IntelliJ 기반으로 만들면서 JetBrain과 협업을 늘려 갔고, JetBrain에서 만든 코틀린은 안드로이드 개발 언어로 안정화가 되었죠. 그리고 2017년 구글 I/O에서 코틀린을 공식 언어로 지정했어요. 또 구글이 만든 Go-Lang을 꾸준히 발전시켜 나가고 있고요. (궁극적인 목표는 구글이 만든 Go-Lang을 사용하는 것이라고 해요!)

메타가 선택한 코틀린

코틀린은 정적 타입 언어로 자바를 대체할 수 있는 멀티 플랫폼이에요.

이 프로젝트에 참여했던 스트룰로비치는 코틀린의 장점을 아래와 같이 말했어요.

‘Null’ 허용 여부를 기본적으로 제공
실행 속도를 저하시키지 않으면서 함수형 프로그래밍을 사용
더 짧은 코드로 작성 가능
도메인 특화 언어(SDL) 정의

‘Null’값 허용 여부를 컴파일 단계에서 검사하기 때문에 널포인터(NPE)로 인한 프로그램 중단을 예방할 수 있다는 것을 의미해요. 이외에도 코틀린은 오픈소스이기 때문에 경제적이며, 간결한 문법을 가지고 있어 버그 발생 횟수를 줄일 수 있다는 점, 이해하기 쉬워 초보자들도 빠르게 학습할 수 있다는 장점이 있어요.

대중적이지 않아, 100% 상호운용성 불가

하지만 이런 장점 외에도 코틀린으로 전환하는데 몇 가지 단점이 발생해요.

신생 언어로 대중적이지 않아 활용할 수 있는 도구가 적음
자바보다 빌드/컴파일 시간이 느림
기존 자바와 100% 상호운용성이 불가하여 코틀린만 사용할 수 없음

위 단점들을 비추어 보았을 때, 메타가 대규모 안드로이드 앱을 코틀린으로 전환한다는 것은 상당한 도전으로 보이죠.

기존 코드까지 모두 코틀린으로, 왜?

메타는 새로 작성되는 코드만 코틀린으로 작성하는 것이 아닌 기존 코드까지 모두 코틀린으로 전환한다고 하는데요. 그 이유는 무엇일까요? 신규 코드만 코틀린으로 작업할 경우 해야 할 일은 줄어들지만 복잡해지면서 오류가 발생할 수 있어요. 코틀린과 자바 간 상호운용성을 활성화하면 코틀린에 플랫폼 타입을 사용하게 되는데 코틀린 코드에서 제공하는 정적 안정성 대신 런타임 Null 포인터 역참조를 발생시켜 충돌을 일으키게 되는 것이죠. 또 다른 문제로는 앞서 언급한 코틀린의 장점을 완전히 누릴 수 없기 때문이에요.

이런 이유로 메타는 기존 코드까지 모두 코틀린으로 전환하고 있어요.

현재는

구글은 코틀린의 실행 속도도 자바와 동일하게 유지할 수 있다는 점을 확인했고, 빌드 크기 증가 문제를 해결할 방법을 찾았으며, 길어진 빌드 시간문제를 개선하는 빌드 시스템도 만들었다고 해요. 실제로 메타는 코틀린으로 전환한 후 코드 베이스 크기를 평균 11% 감소했다고 하네요. 구글은 2019년부터는 '코틀린 퍼스트' 접근법을 채택하여 현재까지 구글 지도, 홈, 플레이, 드라이브, 메시지 등 약 70개의 앱을 코틀린으로 구축하였으며, 앞으로 거의 모든 안드로이드 앱을 코틀린으로 전환할 생각이에요.

알아두면 유용할 IT 용어 사전

정적 타입(Static Typed) 언어, 동적 타입(Dynamic Typed) 언어

앞서 코틀린에 대해 이야기하면서 코틀린은 정적 타입 언어라고 했는데요. 정적 타입, 동적 타입 언어의 차이는 무엇이며 어떤 것들이 있을까요? 쉬운 내용이니 가볍게 한번 훑어보아요!

정적 타입 언어

정적 타입 언어와 동적 타입 언어를 구분하는 기준은 코드의 상수, 변수, 함수 등에 대한 타입을 언제 확인하는지에 따라 나뉘어요. 컴파일 시 변수의 타입이 결정되는 언어를 정적 타입 언어라고 해요.

장점

- 타입 에러로 인한 문제점을 초기에 발견할 수 있어 안정성이 높아요.

- 컴파일 시 타입을 결정하기 때문에 실행 속도가 빨라요.

- 타입이 지정되어 있기 때문에 코드의 가독성이 좋고 협업 및 대규모 프로젝트에 수월해요.

단점

- 알아야 할 BoilerPlate 코드와 지켜야 할 규칙이 많아 동적 타입 언어에 비해 상대적으로 길어요.

- 매번 코드 작성 시 변수형을 결정해 줘야 하는 번거로움이 있어요.

- 컴파일 시 타입에 맞지 않은 값이 들어있으면 컴파일 에러가 발생해요.

대표 언어

- Java, C, C++, C#, Scala, Fortran, Haskell, ML, Pascal 등

동적 타입 언어

타입을 런타임에서 확인하는 언어를 동적 타입 언어라고 해요. 즉, 소스가 빌드 될 때 타입을 결정하는 것이 아니라 실행 시에 결정되죠.

장점

- 컴파일 시 타입을 명시해 주지 않아도 되기 때문에 코드를 빠르게 작성할 수 있어요

- 매번 타입을 써줄 필요가 없고 런타임까지 결정을 끌고 갈 수 있어 유연성이 높아요.

- 사용하기 위해 지켜야 할 규칙이 적기 때문에 상대적으로 코드가 짧고 Learning-Curve가 낮아요.

단점

- 실행 시점이 되어서야 변수에 예상치 못한 타입이 들어와 타입 에러가 발생할 수 있어요.

- 런타임 시 에러를 확인할 수 있기 때문에 코드가 길고 복잡해질 경우 타입 에러를 찾기 어려워요.

- 사전에 타입 체크가 안되기 때문에 오류에 취약하고 최적화가 어려워요. 발생했을 때 손해도 커요.

대표 언어

- Groovy, Python, JavaScript, Ruby, Smalltalk, Lisp, Objective-C, PHP, Prolog 등

정리하면, 정적 타입 언어는 소스 코드를 보고 변수의 타입을 판단하고, 동적 타입 언어는 코드를 실행할 때 변수의 타입을 판단하는 것이에요.

#컴파일 VS 인터프리터 언어

컴파일 언어는 소스코드를 다른 목적 코드로 번역한 후, 한 번에 실행하는 언어에요. 쉽게 말해 컴퓨터 하드웨어가 알아들을 수 있는 로우 레벨 언어로 번역한 후, 컴파일해요. 그럼 실행 가능한 파일이 생성되죠. 즉 번역과 실행이 따로 이루어져요. 규모가 큰 소스의 경우 인터프리터를 이용해 실행시키는 것보다 빠르게 동작하나, 컴파일 과정에서 상당한 시간이 소요되고 메모리도 많이 차지해요.

인터프리터 언어는 소스코드를 한 줄 한 줄 읽어가며 명령을 바로 처리하는 언어예요. 번역과 실행이 동시에 이루어지죠. 코드를 한 번에 한 줄씩 읽어 들이면서 바로 실행이 가능하여 프로그램 수정이 간단하지만, 명령 자체의 속도는 컴파일러 언어에 비해 느려요.

#자바는 컴파일 언어일까, 인터프리터 언어일까?

자바의 경우 자바 컴파일러와 자바 인터프리터가 있어요. 자바 컴파일러는 .java라고 쓰인 소스 파일을 .class 파일로 변환하고, 자바 인터프리터는 바이트코드로 작성된 클래스 파일을 특정 환경의 기계에서 실행될 수 있도록 기계어로 변환해요. 그래서 자바는 컴파일 언어라고만 볼 수 없죠.

이렇듯 컴파일링과 인터프리팅은 주어진 언어를 실행하는 서로 다른 방식일 뿐 절대적인 것은 아니에요.

#자바스크립트를 보완한 타입스크립트(TypeScript)

타입스크립트는 구문과 런타임 특성을 공유하고, 타입을 부여하여 자바스크립트의 느슨하게 짜여진 코드로 발생하기 쉬운 오류를 사전에 예방할 수 있어요. 정적 타입을 쓰는 타입스크립트로 안전하게 코드를 짠 다음, 브라우저나 Node.js에서 실행되는 자바스크립트로 컴파일해서 타입에 의한 오류들을 방지하는 것이죠.

정적 언어의 특성을 살려 타입을 지정할 수 있어 메모리 저장 값의 크기를 미리 파악하여 메모리를 절약할 수 있고, 타입으로 인해 발생할 수 있는 에러 핸들링이 쉬워요.

또한, 타입스크립트를 자바스크립트로 변환하는 트랜스파일링 과정에서 미리 에러를 잡을 수 있기 때문에 에러 예측이 쉽다는 장점이 있어요.

IMQA 대시보드에서는 모바일 앱 성능을 실시간으로 모니터링하고 알림을 통해 고객의 장애를 가장 빠르게 확인할 수 있습니다. 하지만 이렇게 성능을 모니터링하는 솔루션에서 성능이 나오지 않는 아이러니한 상황이 발생하게 되는데요. 과연 IMQA 성능에 어떤 문제가 있었을까요? 또 어떻게 개선하였을까요?

모니터링 서비스, 대용량 트래픽을 감당해야 하는 서비스를 운영 중이라면 꼭 한번 읽어보세요!

(이미지를 클릭하시면 상세 내용을 확인하실 수 있어요!)

2022년 IMQA가 참가하는 마지막 전시회를 소개해 드립니다.

바로 12월 7일부터 9일까지, 3일간 코엑스에서 열리는 제7회 대한민국 소프트웨어대전, ‘소프트웨이브 2022’입니다.

소프트웨이브는 SW 전문 B2B 전시회로, 대한민국을 대표하는 소프트웨어-ICT 비즈니스 박람회인데요. 국내 최고의 SW기업들과 기술들을 선보이며 서밋(Summit)이나 다양한 부대행사들을 통해 최신 시장 트렌드를 알 수 있는 행사입니다. 특히 이번 전시회에서 IMQA는 신규 기능인 '행동 분석'을 시연할 예정인데요. 방문하셔서 꼭 사용해 보시길 바랍니다 😊

IMQA 부스 위치 및 자세한 일정은 블로그를 통해 확인해 보세요!

👉🏻 블로그 바로가기

문제는?

CS를 통해 로딩 시간이 너무 길어 앱을 사용하지 못하고 있다는 컴플레인이 들어왔어요. 고객은 어떤 화면인지 기억하지 못했고, 해당 화면에 대한 스크린샷, URL 등을 받을 수 없어 문제가 발생한 화면을 알기 어려운 상황이었어요. 고객의 컴플레인은 커져 갔고 정확한 원인 분석과 빠른 대처가 필요했어요.

해결방법은?

행동분석을 통해 사용자 정보와 문제를 겪었던 시간대를 조회하였어요. 행동 흐름을 통해 전후 상황을 분석하고 성능 상세 분석을 확인하여 문제의 원인을 정확히 파악할 수 있었어요.

현재는?

어떤 상황에서 문제가 발생했는지 사용 경로를 확인하고, 정확한 원인 분석을 위해 전체 사용 현황을 파악하는 용도로 활용하고 있어요.

+ 우리도 고객의 장애 신속히 해결하고 싶어요!