컨퍼런스는 일 년에 서너 번 정도 가는 것 같은데 막상 후기를 쓰는 건 처음이다. 글을 쓰는 번거로움보다도, 컨퍼런스 내용을 이해하지 못했다거나 혹은 나와 크게 관련 없는 주제여서 정리를 하고 싶어도 할 수 없던 경우가 참 많았다.

GDG Korea 에서 준비해준 이번 안드로이드 데브페스트는 아주 규모가 큰 행사는 아니었지만, 안드로이드 전용 컨퍼런스인만큼 거의 모든 세션에 흥미가 갔다. 이미 다른 곳에서도 여러 번 다뤄진 메이저한 주제들이기도 했고, 세션 발표자들이 실무에서 사용하기 편하도록 간결히 정리해서 발표해 주어서 내용을 편하게 들을 수 있었다. 여기에, 업무를 하며 얻은 경험과 회사 동료들로부터 들은 지식이 조금이나마 쌓여서 이제는 간단히나마 정리를 할 수 있을 것 같다.




DevFest Android 2019

GDG Korea 주최라고 하니 왠지 세종대학교 아닌가? 싶었는데, 이번에는 삼성역에 있는 구글 스타트업 캠퍼스에서 진행되었다. 구글 스타트업 캠퍼스에서 무려 장소 협찬을 해주셨다고 한다. 이처럼 좋은 취지의 두 단체가 만나서 그랬던건진 모르겠지만, 이번 행사는 유난히 푸짐했던 것 같다. 다만 나중에 준비된 간식에 힘(?)이 집중되다보니 입장할 때에는 물이나 커피 같은 게 준비되지 않아서 목마른 좀비들이 여럿 돌아다니기도 했다. 현대 오토웨이 건물 내에 있던 편의점도 닫았었는데 쉬는 시간이 10분밖에 없다는 걸 깨닫고 정말절망.

스푼라디오, 아이디어스, 헬로우봇 부스가 준비되어 있었다. 와글와글한 분위기가 아니었던 만큼 부스에 가서 서비스에 대해 물어보거나 여유있게 경품을 받아올 수 있었다.

스푼은 인스타그램 광고에서 많이 봐서 개인 라디오 스트리밍인 서비스인걸 알고 있었다. 아이디어스는 핸드메이드 위주의 마켓으로, 나는 이미 두 번의 구매 경험이 있는 곳이었다. 헬로우봇은 처음 봤는데, 인공지능을 이용한 카테고리 특화 챗봇 서비스라고 하셨다. ‘타로카드-연애상담’ 카테고리를 담당하는 캐릭터와 채팅을 시작했는데 갑자기 챗봇이 ‘당신이 솔로인 이유를 알려드릴게요-‘해서 조금 슬프기도 했고, 그 와중에 어떻게 알았지 하며 신기해하기도 했다.






타임테이블을 보니 20-30분 정도 세션을 진행하고 10분 휴식시간이 있는 구조로 되어 있었다. 반 정도 진행한 후 간식 시간이 있었고, 뒷 세션은 비교적 가벼운 내용들로 준비되어 있다고 하셨다. 코틀린 익스텐션, 데이터 바인딩, 다크 테마, 테스트 코드, 플러터 등에 대한 내용이었다.

festa 에서 티켓을 구매하면서 사전 설문조사를 했는데, 피자 치킨 샌드위치 등 어느 음식을 선호하냐는 질문과 맥주나 커피 중 어느 것이 좋은 지에 대해 묻는 항목이 있었다. 그 비율에 맞춰 간식을 준비한 듯했다. 12,000원 하는 행사에 먹거리를 이렇게나 많이 준비하시다니 정말로 네트워킹이나 연말 분위기에 신경을 많이 쓰신 것 같았다. (그래도 단체 행사에서는 뼈치킨보다는 순살로 해주세요)

치맥에 정신 팔렸던데다가 행사장에 책상이 없어 허벅지에 올려놓고 타이핑 해야했던 환경이라 모든 세션의 모든 내용을 다 담지는 못했지만, 최대한 기억을 되살려보았다.


Android KTX, DataBinding 으로 코드 생산성 개선하기

안성용 / 네이버웹툰

첫 세션의 이름은 ‘코드 생산성 개선하기’였다. 하지만 코드 개선의 목적에 초점을 두어 제목을 ‘KTX / DataBinding 으로 View Layer 코드 줄이기’로 다시 정하신 것 같았다. KTX는 Jetpack 중의 하나로, 코틀린의 확장 기능이다. ‘이런 코드가 있어요’ 하고 넘어가기보다는 실제 쓰고 있는 코드 중에 간결하게 바꿀 수 있는 부분을 자세히 설명해주셔서 좋았던 세션이었다.

가령, 어떤 boolean값에 따라 View를 VISIBLE 혹은 GONE 처리를 해야 할 때 기존에는 if 혹은 삼항 연산자를 거쳐야했다. KTX를 사용하면 isVisible 처럼 간결한 확장 속성을 제공하기 때문에 loadingView.isVisible = isLoading 같은 짧은 코드가 가능해졌다. 사실 내부 코드를 열어보면 별 거 아닌데, 귀찮은 부분들을 숨겨두고 간단하게 꺼내 쓸 수 있게 정리를 미리 해두었다는 점에서 KTX에 매력을 느꼈다.

이외에도 Html Text 처리, StringBuilder와 비슷한 spannableStringBuilder, Bundle의 자료형 처리를 간단하게 해주는 bundleOf 등 KTX를 이용해 코드를 훨씬 간결하게 쓰는 꿀팁들을 알려주셨다. KTX 리스트 에서 확인할 수 있다.

여기에 DataBinding으로 데이터와 UI 요소를 묶을 수 있다. KTX에서 확장 속성을 쓸 수 있었다면, 데이터 바인딩에서는 BindingAdapter를 통해 xml에 어트리뷰트를 추가한 것처럼 쓸 수 있다. Visible 처리, 클릭 처리 등에서 흔히 쓰인다. 2-Way Binding 에서는 조금 호불호가 갈리지만, 체크박스 처럼 view에서 toggle한 후 로직을 처리하고 view로 재전달하는 식으로도 사용된다고 하셨다.

발표하신 분의 Medium 블로그 에서 자세한 내용을 확인할 수 있었다.

실제 운영중인 서비스에 다크모드 적용 과정

김종식 / 원티드

실제 원티드 서비스에 다크모드를 적용하는 스토리를 들려주셨다. UI 편의성을 위한 부분이라 리소스를 천천히 들여, 다른 프로젝트와 병행하면서 조금씩 안정적으로 진행하신 것 같았다.

발표를 들으며 사람들이 다크 모드에 관해서 은근히 모르고 있었다는 걸 알게 됐다. 개인적으로는 다크 러버라서 안드로이드 신 버전에서 다크 모드를 밀어주려는 움직임이 보여서 행복하다.

앱 테마는 DayNightTheme를 사용했다고 하셨다. 필수는 아닌데, 필수로 하는게 좋다고. 이미지 리소스에는 tint를 적용했다. 키 값이 같은 color 리소스를 Light/Dark 모드에서 각각 다른 색을 지정해주었다. 특히 convertingcolors.com 사이트를 이용하면 컬러에 관련된 이슈 거의 없었을 정도로 색을 잘 뽑아주었다고 한다. Light 테마 색상 기준으로 밝기와 채도를 20-40% 다운시키면 Dark 테마 색으로 적절하다고 했다. 텍스트는 #RRGGBB의 16진수 값을 반전해서 사용했지만,(#111111 -> #eeeeee) 배경이 있는 경우 조금 더 신중하게 했다고 하셨다.

색상 외에도 레거시 코드를 정리하고 미사용 리소스 제거(레이아웃, 이미지, 스타일, 컬러 등)하며 필요한 리소스는 디자인 팀과 협업해서 받았다고 하셨다.

만약 다크 테마 적용한다면 추가로 고려해야 할 것들은 다음과 같았다.

  • 컨텐츠 원본 이미지 (쇼핑 등 이미지가 큰 비중을 차지하면 서비스면 고민 필요)
  • 아이콘, 위젯, swipeRefreshLayout
  • 구글지도 다크테마 (한국 미지원)
  • 인앱 웹뷰

머신러닝을 이용한 Android 앱 자동화 테스트 방법

안창남 / HP

사실 이 세션은 내가 이해할 수 있는 지식의 범위를 넘어선 것 같다.

기존에는 수동으로(매뉴얼) 테스트를 진행했다. 즉 QA팀과 같은 사람이 시나리오대로 테스트하는 게 전부였다. 이제는 Selenium , Selendroid, Appium 등을 이용해 test script를 작성하고 자동화 테스트를 하는 단계인 것 같았다.

물론 인력을 사용하지 않고 자동화 시키는 게 베스트이긴 하겠지만, 초기 테스트 케이스 만드는게 힘들다는 문제점이 있다고 하셨다. 테스트에서 오류가 발생하면 테스트 코드를 재수정하는 데에 리소스가 많이 투입된다. 오류가 발생하지 않는다 하더라도 디바이스, OS버전, 앱 업데이트, 외부 의존성 등으로 인하여 유지관리가 쉽지는 않다고 하셨다.

그래서 도입을 고려중인 머신러닝 테스트 하면 좋은점

  • Training set 이 자동으로 만들어짐
  • 강화학습을 통해서 테스트 정확성 증가
  • Report(보고서) 시스템

우선 오픈소스를 찾아서 상용 앱에 Random Test를 진행한다. Visualization(테스터가 결과를 보고 확인할 수 있는 agent 개발)도 이 단계에서 진행했다고 하셨다. 그 데모를 보고 전체적인 full path를 찾으면 각 액티비티에 대한 라벨링을 하고 앱 스크린을 분류한다.

그리고 그 UI를 캡쳐해서 어느 상황을 테스트 할 건지 input을 작성한다. 사용자가 CSV파일에 어떤게 Pass/Fail 인지 작성하여 강화 학습(Reinforcement Learning)에 던져주면, 결과도 CSV 파일로 제공해준다고 했다. 그리고 시나리오대로 수행하면서

  • 다음 상태로 이동 : +1
  • 이전 상태로 이동 : -1
  • 제자리(Checkbox, Scroll 등) : 0

의 기준으로 스코어를 매긴다. 하지만 각 액티비티마다 실행할 수 있는 액션과 개수가 달라서 일반화가 필요하다고 하셨다. 여기서부터는 내 뇌에 Out of Memery Exception …

Android 앱개발과 Flutter 개발의 큰 차이점 5가지

남반석 / Lawfully

컨퍼런스 도중에는 사진 안 찍는 편인데, 그래도 한 장 찍어야하지 않겠냐며 찍은 한 컷


Native 앱 개발과의 큰 차이점 5가지를 설명해주셨는데, Flutter에 좋은 쪽으로 뽑아와주신 것 같았다.

  • 크래시가 나지 않는다.
    강제로 앱이 죽지 않는다. 단 native 과 연동하면 앱이 강제종료 될 수도 있다고 하셨다. 코드가 문제에 생기면? 위젯 안에 빨간 바탕의 노란 글씨 에러 코드들이 도배되었다. 발표자의 입장에서는 약간 Ugly 하더라도 죽는 것보다는 낫다고 하셨는데… 내 기준에는 그 빨간 화면이 많이 어글리했다.

오류 코드는 잡을수 없냐는 이야기가 나왔었는데, Firebase Crashes 필터 -> non-fatal 로 바꾸면 라인을 볼 수 있다고 하셨다.

  • 획기적인 화면 사이의 통신
    Android에서는 onActivityForResult, ViewModel, Listener, Dialog Listener, EventBus 등등을 통해 액티비티 간 데이터를 전달한다. 하지만 액티비티 시작, 받는 위치가 다르고 생명주기에 따라 데이터 전달이 안 될 수 있다. ViewModel 패턴을 사용하는 경우, 뷰모델 코드가 커질 우려가 있다. Listener를 사용할 때에는 참조가 끊겼을 때 전달되지 않는 어려움이 있고, Dialog Listener 에서는 일일이 수동으로 dismiss를 해주어야 한다. 무엇보다 안드로이드에서는 Intent Bundle에 넣기 위해 Serializable, Parceleable 을 구현하는 데에 불편함이 있다. “Flutter에서는 객체 그대로 싣고 보낸다.”

  • 쓰레드 스트레스에서 해방
    안드로이드에서는 AsyncTask(Deprecated), Rx, Coroutine을 사용해 비동기 처리를 한다. Flutter 에서는 JavaScript와 비슷하게 Single Thread로 이루어져 있고, 대신 Event Loop가 흐름을 제어한다. 단일 스레드 방식으로 동작하지만, 통신이나 이미지뷰 처리가 UI를 느리게 하지 않는다. Dart 언어에서 제공하는 isolate 기능을 사용한다고 설명해주셨다.

  • 만들고 스기 쉬운 커스텀뷰 (widget) 안드로이드에서는 커스텀뷰를 만들 때에 attrs.xml 쓴 다음에 자바 코틀린에서 속성을 하나씩 가져와 정의해주어야 한다. 레이아웃을 xml에 그리기 때문에 생기는 번거로움이다. View는 자바 객체이기 때문에 이 과정도 사실 불필요한 과정이라고 말씀하셨다. Flutter 에서는 필드에 필요한 생성자를 정의하고 각 필드에 원하는 변수를 배치한다. MVVM 처럼 데이터 바인딩되고, setState 쓰면 알아서 갱신된다고 한다. + Hot Reload 는 덤 (편-안-)

  • 쉽고 직관적인 Animation 처리 안드로이드에서는 우선 id로 View를 찾고, transitionX, alpha, scale 등 타겟값 세팅하고, duration 세팅, start 까지 수동으로 지정해줘야 한다. Flutter에선 암시적으로(implicit) 처리한다고 했다. implicit animated widgets에 다양한 기본 위젯이 있어 비교적 쉽게 애니메이션 구현이 가능한 것 같았다.

발표자 총평: UI 개발 프레임워크 끝판왕

나의 첫 실무에 Test 반영기

김정원 / KineMaster

이 때 하필이면 뼈치킨 먹느라 집중을 못했는데… 테스트코드에 관련된 얘기를 했다. 기억에 남는 건, 다른 회사에서 테스트 코드를 어떻게 적용하고 있는지 이야기를 공유하는 식으로 세션이 진행되었다. 네 명 정도가 이야기를 공유해주었는데, 다들 실행하고는 싶지만 실질적으로 코드가 테스트 하기 좋게 정리되어있는 것도 아니고, 테스트를 진행하기 위해 일이 더 많아지는 경우가 빈번하다고 말씀해주셨다. 현실적으로 아직은 Unit Test 정도가 가장 최선이 아닐까 싶었다.

컨퍼런스 진행자가 ‘혹시 좋은 케이스는 없나요?’ 라고 되물어봤는데, 100명 가량의 사람들 중에 아무도 대답을 못 했다고 한다.

본인 방금 매니저되는 상상함ㅋㅋ

이승민 / 뱅크샐러드

매니저(라고 쓰고 리드라고 읽었다)가 된 지 한 달 정도 된 발표자분께서 리드 후기를 말씀해주셨다.
사실 세션 제목부터 쓰고 드립부터 치고 싶으셨다고…

발표자가 생각한 리드의 역할은 크게 두 가지, Visioning 과 Managing 이 있다. Visioning은 말 그대로 ‘우리팀은 이렇게 가야한다’하는 팀의 방향을 설정하는 일이며, 가장 중요한 업무라고 하셨다. 예를 들어 안정적인 앱을 만드는 것이 목적인 경우 충분한 작업/리뷰시간 확보하거나, 개인의 성장이 목표인 경우 비동기/기록 커뮤니케이션 문화 확립하는 데에 힘썼다고 하셨다. Managing은 추상적인 키 액션을 실행하기 위한 구체 업무를 말한다. 좋은 코드리뷰를 위한 PR정책 개선, 코드리뷰 오너 도입, 배포주기 2주로 연장, 스케줄 주도권 확보, 빌드/배포 자동화 등 아주 세부적이고 오픈된 예시를 들어 설명해주셨다.

발표자 분의 리드에 대한 생각은 ‘팀원들이 달릴 수 있는 좋은 환경을 제공하고 싶어한다’고 했다. 실제로 의사 결정권을 더 가져오고 싶어 하시는 모습을 보고, 좋은 의미로 업무에 대한 욕심이 있는 사람이구나, 하는 생각이 들었다. 더불어 나쁜 리드와 좋은 리드에 대한 생각을 말해주셨는데,

나쁜 리드는

  • 비전이 없는 기준이 없는/바뀌는 일관성 없는 리드
  • 구름 위를 걷는 리드 - 무슨 일을 하는지 잘 모르겠지만 바쁨, 일 시키고 관리만 하는 사람 (ex 이슈가 터졌습니다. 담당자 누구죠? 하고 끝나는 케이스)

좋은 리드가 되려면?

  • 실무를 팀원만큼 잘해야 한다 -> 이슈의 해결책을 내놓을 수 있어야 하니까.
  • 문화는 정책으로 개선되지 않는다. -> 내가 먼저 실행하고 그 결과로 유용함을 설득/증명해야 한다.

하는 것이 결론이었다. 실제로 안드로이드에서 시작하셨지만 웹 프론트와 iOS 개발을 열심히 공부하고 있다고 하셨다.

마무리

SWAG

자본 최고

선물 최고




[성실도]

성공한 것

  • 컨퍼런스를 다녀와서 그냥 일상으로 돌아가버리면 분명 잊어버린다. 처음으로 블로그에 기록을 해봤는데, 다시 되새겨보니 기억 안 나는 부분은 검색도 해보며 복습할 수 있었다.
  • 네트워킹 시간을 가지면서 다른 개발자들과 간단히 몇 마디 한 게 꽤 재미있었다. (근데 에어팟 당첨자 발표 직후에 바로 전원 해산해버렸다)

실패한 것

  • 에어팟 프로 당첨 안됨.
  • 블로거라는 사명감을 가지고 사진을 좀 더 많이 찍어야겠다.
  • 이런 날에는 명함을 가지고 와야겠구나.

도달한 결론

  • 벌써 새로운 기술들을 익히고, 회사 프로젝트에 적용하고, 발표까지 하는 사람들이 부럽기도 했다. 내 공부를 열심히 하고, 적용할 수 있는 부분은 회사에 도입할 시점이 되면 나도 발표자 자리에 서있을 수 있지 않을까. 일단 회사 사람들에게부터 연습해보며 개발 공부/정리/발표하는 방법까지 두루 통달하고 싶다.