본문 바로가기

Home > 열린마당 > 공개SW 소식

공개SW 소식

[구글 I/O 2015] (3) 내일의 안드로이드는 오늘의 안드로이드보다 사랑스럽다

OSS 게시글 작성 시각 2015-08-11 16:46:47 게시글 조회수 2988

2015년 08월 08일 (토)

ⓒ 마이크로소프트웨어, 장혜림 기자


안드로이드 M이 가져올 개발자 삶의 변화



“안드로이드 개발자는 집에 안드로옵니다”라는 우스갯소리가 있다. 안드로이드 개발을 프로요 이상 지원으로 개발해온 개발자들에겐 번뇌의 나날들이었다. 커뮤니티에는 Éclair(API-5) 이상으로 개발하는 분도 있는데 아들 둘을 기르는 엄마에 이어 극락과 천국의 자유이용권을 얻으셨을 것이다. 매일 코딩하며 애정을 가지고 대하면 이유 없이 토라지고, 잘 맞추면 다른 쪽에서 충돌이 나고, 설명도 잘 안해주고, 남들에게 물어물어 알아내면 나만 겪는 문제는 아닌 것 같고.


|필자소개|

김영재 youngjae.kim@gmail.com | 카이스트에서 수학문제풀이에 대한 패턴분석을 연구했다. 지금은 중, 고등학생 학습 Q&A 앱 ‘바로풀기’의 최고기술책임자다. 분당의 한 중학교에서 방과후 수학교사를 3년째 진행하며 교육과 IT를 엮으려고 노력 중이며 스타트업 개발자로서 Microsoft Azure MVP로 클라우드 아키텍처 설계와 안드로이드 개발을 병행하고 있다.


어쩐지 개발자들에겐 낯익은 삶의 리듬 아닌가? 그렇다. 모든 프로그래머는 자신이 다루는 기술과 연애하고 있고 안드로이드 프로그래머도 마찬가지다. 우리는 그저 어제의 그녀를 모델링하 고 내일의 연인을 시뮬레이션하며 오늘의 연인에게 최적화해야 한다.


리눅스 가문의 아빠, 자바 언어의 엄마 사이에서 자란 안드로이드는 이런 성격으로 우리 앞에 다가왔다. 불친절한 문서, OS 버전별 차이점, support library 버그, 제조사별 오류, 아키텍처적으 로 미숙하게 구현된 프레임워크, OS 역사에 유례없는 복잡한 라이프사이클, Out-of-Memory 크래시, 모뎀으로 두근대며 jpg 받았던 추억을 상기시키는 느린 컴파일, 맞추고 또 맞추는 위아래위위아래 호환성, 구글과 AOSP 커스텀의 사랑과 전쟁.


이것이 2년 동안 안드로이드앱 프로그래밍을 하며 생긴 추억이다. 매 버전마다 소개팅하는 느낌이었지만 꽝이었다. 하지만 우리는 언젠가부터 집착이 생겼는지 매일 만났던 모든 연인들과 연락하며 어장관리를 당하고 있다.


이런 우리 앞에 안드로이드 M이 프리뷰로 나왔다. 자,이제 다시 내일의 그/그녀와 소개팅을 준비해보자. 이미 전화번호를 받고 메신저에 얼굴이 뜬 셈이다. 이 글은 어장에서 탈출하려는 한 개발자가 객관적이고 냉정하게 보는 안드로이드 M 프리뷰 관찰기다.


퍼미션(Permission) 변화

가장 먼저 꼽을 변화는 퍼미션의 변화다. 여기서 퍼미션은 OS의 파일시스템의 권한을 의미하는 것이 아닌 기능에 대한 접근 권한을 의미한다. 파일 쓰기 권한, 인터넷 접속 권한, 블루투스 액세스 권한, 많은 분들이 불안해하는 연락처나 SMS 접근 권한 등이다. 많은 안드로이드 개발자는 퍼미션에 대해 필요한 것만 다루지 않고 이용약관 복사붙이기 하듯 필요보다 많은 수의 퍼미션을 복사해서쓴다. 그 이유는 처음 스토어에서 설치할 때만 유저가 승인하면 그 후엔 그 퍼미션에 대해 무제한의 접근이 가능하며, 만일 새 퍼미션을 그 후에 추가하면 자동업데이트가 안되기 때문이다.


안드로이드가 다른 스마트폰 OS와는 달리 이러한 권한 설정 형태를 취한 이유는 그 개발철학이 이토록 민감한 개인정보를 다루거나 이토록 대중적으로 쓰이게 될거라 예상하지 못했기 때문이라고 생각한다. 여하간 안드로이드 M은 이제 다른 OS 플랫폼(iOS, Windows Store)처럼 접근 직전에 권한을 요구하도록 바뀌었다. 새로운 퍼미션 정책이 적용 안된 기존 앱에 대해서는 크래시가 가급적 발생 안하도록 하기 위해 예외(Exception) 대신 비어있는 데이터를 반환한다고 하지만, 그 비어있는 데이터를 처리하지 않는 앱도 많기에 상당수 앱이 불안정하거나 실제실행 결과와 다른 모습을 보일거라 예상한다.


좀더 자세히 보자. 새 퍼미션 모델을 문제없이 사용하기 위해서 는 퍼미션이 이미 있는지 확인하는 checkSelfPermission, 없을 시 요청하는 requestPermission, 요청한 결과를 받는 onRequest PermissionsResult 메소드를 모두 거쳐야만 한다. 역시 내일의 그/그녀도 만만치 않다는 생각이 든다. 윈도우 스토어 앱의 경우를 예로 들면 GetGeopositionAsync()처럼 해당 기능의 메소드를 실 행시 OS 수준에서 퍼미션을 확인하고 결과를 반환하기 때문에 더 편리하며, 이는 iOS도 마찬가지다. 다른 플랫폼이 단 하나의 메소드만으로 처리할 수 있고 안드로이드는 그 이후에 적용했음에도 이런 편리한 방법으로 안되어있는 이유는 안드로이드 개발 철학이 이용자(개발자)에 친화적이라기보다는 기술적 제어에 더 친화적인 개념을 가지기 때문이 아닐까 이해해본다.


하위호환성에 대해서는, 프리뷰 버전이라 조정 중인 것으로 보 인다. 일단은 uses-permission-sdk-m이라는 별도의 퍼미션 명으로 기록하도록 하고 있다. 즉, 롤리팝 이하 버전에서는 해당 퍼미션명은인식되지않는다.이에대한퍼미션은총8개그룹, 25개항목으로적지않다.SMS를직접보낼수있는퍼미션도예 전과 동일하게 있으며, 이런 스팸으로 악용될 소지가 있는 퍼미션 은없애고싶었겠지만한편으론기존에많은앱이가지고있는서 비스 시나리오를 최대한 깨뜨리지 않으려는 노력으로도 보인다.


뜻밖의 Android Studio 1.3

이번 I/O에서 M의 발표 외에 개발 경험을 혁신할 가장 큰 변화는 바로 안드로이드 스튜디오1.3(Android Studio 1.3)이다. 구글이 Eclipse에서 Android Studio로 권장 IDE를 변경하면서 적극적으 로 도입한 것이 gradle 빌드 시스템이다. Gradle이 도입된 후에는 적어도 동료들끼리는 거의 문제가 없이 소스코드를 공유할 수 있다. 물론 gradle을 이용한 오픈소스 프로젝트라 할지라도 정상적으로 동작 안될 때가 많은 것은 여전하지만 말이다.


Gradle 빌드 시스템이 협업 시의 혼란을 어느 정도 줄여줬지만 그만큼의 고통으로 다가온 것은 빌드 속도였다. 현재 100만원 수 준에 판매되는 넉넉한 사양의 데스크톱PC 기준으로 20초 정도가 소요되었던 것이 gradle 빌드를 이용하면 1분 30초 가량 소요된다. 데스크톱보다 성능이 부족한 노트북은 3분 가까이 소요되는데 컵라면 하나를 익힐 수 있는 시간이니 무시할 수 없는 소중한 시간이다. Android Studio 1.3은 프리뷰 기준으로 2배 가량 빨라졌다. 정식 버전에서는 더 빨라지리라 기대한다. 참고로 글을 작성하는 현재 시점에 Dev 채널에 Android Studio 1.3 프리뷰 버전이 올라와있으니 꼭 업데이트를 하자. 통상적으로 프리뷰 버전은 실제 제품개발에 사용하지 않아야 하지만 컵라면은 이제그만먹자. 이미 많이 먹었다.


구글이 NDK 지원을 하기 시작하면서 더는 Eclipse를 사용할 이유가 없어졌다. Android Studio정식 버전이 나오기 전부터 사용하기 시작했지만 개발자들을 만나보면 여전히 Eclipse를 사용하는 분도 많고 중견기업에 속한 개발자들 대상으로는 과반이 넘을 거 라 예상된다. 이제는 갈아타자. Android Studio에는 단축키를 Eclipse로 설정해주는 기능도 있으니 걱정 말고 옮기라고 하고 싶 다. 왜 잘 쓰고 있는 Eclipse에서 갈아타야 하느냐고 설명을 필요로 한다면, 구구절절 기술적으로 설득하는 것보다는 적절한 예시를 들고자 한다. 이제 Eclipse로 안드로이드를 개발하는건 라면을 숫가락으로 먹고 있는 것과 마찬가지다. 옆에 젓가락이 있으니 그 것으로 먹어보자. 김치도 같이 집어 먹을 수 있으니 더 맛있을거다.


하드웨어 지원

플래시 제어용 API로 Flashlight API가 추가됐다. setTorch Mode 라는 기능이 더해졌다. 기존엔 카메라 파라미터에서 FLASH_MODE_TORCH라는 값을 직접 읽거나 쓰는 형태였는데 가상화되어서 보다 안정성이 높아질 것으로 예상한다.


카메라는 하드웨어에 밀접한 만큼 카메라 모듈 제조사 및 핸드 셋 제조사마다 다르게 구현될 수 있기 때문이다. 적어도 지금까지 는그래왔다.그외에MIDI양방향지원은 뜻밖이며 음향재생 또한 96kHz로 향상되었다고 보고하고 있다. 영상 또한 지원되는 하드웨어에 4K해상도로 그리도록 할 수 있다. 동영상 재생뿐만 아닌 UI에 대한 것으로 만일HD만 지원되는 리소스일 경우 업스케일로 그려진다. 재해석해보면, 이제 앱 개발 환경은 고품질 멀티미디어에 대한 지원을 중요하게 생각하고 있으며 근시일내로 충분히 고품질의 멀티미디어 작업도 가능하게 되리라 본다. 10년 전엔 멀티채널 미디레 코딩 시 고가의 장비로도 시간차가 발생하면서 밀리는 경험을 했던 분들이나 전시용 멀티디스플레이를 위해 주문형 그래픽카드를 사용했던 분들은 격세지감을 느낄 것이다.


결론

이 글에서 언급하지 않은 안드로이드 M의 변화는 대부분 UX에 치중한 변화들이며 그것을 지원하는 API에 대한 것이라서 생략하 였다. 현재 안드로이드 M의 공식 이슈트래커에는 넥서스 기기로 테스트하는 개발자들로부터 매우 많은 앱이 정상적으로 동작하지 않는다는 보고가 쌓여있다. 별로 놀라운 일은 아니다. 그저 앞으로 나올 문제점은 열반을 향해 인내하는 마음으로 개발해서 해결해야 할 따름이고, 이번 버전에서 공개된 API 로 새로운 가능성을 발견하고 이를 앱으로 구현하는 것은 온전히 우리 앱 개발자의 몫이다.


안드로이드 M. 내일 만날 소개팅의 그/그녀는 예전에 만났던 그/ 그녀들과 비슷할 것 같다. 다만, 화장실 앞에서 너무 오래 기다리지 않게할 것 같고 내 핸드폰을 함부로 뒤질 것 같지도 않고 캘리그래피와 좋은 음질의 음악도 즐길 줄 아는 것으로 보인다. 조금 기대감을 가져도 좋다. 이제 SDK 매니저를 실행하고 만나러 가자. 




※ 본 내용은 (주)마소인터렉티브(http://www.imaso.co.kr/)의 저작권 동의에 의해 공유되고 있습니다.
    Copyright ⓒ Maso Interactive Corp. 무단전재 및 재배포 금지


[원문출처 : https://www.imaso.co.kr/news/article_view.php?article_idx=20150728094622]

맨 위로
맨 위로