2018년 4/22일에 코엑스에서 개최된 안드로이드 컨퍼런스 드로이드 나이츠에서 발표를 했다.
처음엔 딱히 발표 꺼리도 없고 해서 그냥 컨퍼런스 참여만 생각을 했었는데, 얼마 전 카카오 택시 기사앱에 ConstraintLayout을 적용해보고 너무 좋아서 기왕에 얻은 경험, 발표까지 해 보자! 하고 발표자 신청을 했다. 여기엔 참가비가 4만원이었던 것도 큰 몫을 했다.
리빙 포인트: 컨퍼런스 참가비가 비싸면 발표를 하면 된다.
발표자 신청을 하고 기다렸는데 다행히 선정이 되었다. 실무에 이미 ConstraintLayout 1.0.2 버전을 적용하면서 이런 저런 경험을 했기에 기술적인 부분 보단 발표 자료를 꾸미는게 더 어려운 일이었다. 처음 준비할 시점엔 아직 베타였던 1.1.0의 이런 저런 기능들은 나도 새로 공부를 해 가면서 준비해야 했었다.
준비하면서 제일 어려웠던 부분은 여러 내용들이 확 합쳐져야 레이아웃이 구성되면서 설명을 시작할 수 있기 때문에 이걸 어떻게 쪼개서 설명해야 할지 결정해야 했던 부분이다. 결국엔 Constraint가 뭔지, 크기는 어떻게 결정하는지, 위치는 어떻게 결정하는지 순서로 설명을 하기로 했다.
실무에선 여러 케이스를 마주치게 되지만, 한편으론 실험적으로 이상하게 우겨넣는 케이스가 없기 때문에 이런 이상한 케이스 (일부러 내용이 넘쳐나게 한다던지, 일부러 화면 바깥에 삐져나가게 레이아웃을 잡는다던지...)를 만들어서 실험해 보려고 샘플 프로젝트를 만들었다. 다행히 안드로이드 스튜디오의 레이아웃 프리뷰가 아주 훌륭해서 굳이 일일이 실행해보지 않고 프리뷰만 쳐다봐도 어떻게 구성이 될 지 확인할 수 있었다.
이전 발표와 마찬가지로 발표 자료 자체엔 최소한의 공수를 들이고, 차라리 더 내용을 알차게 꾸미자고 마음을 먹었다. 물론 디자인 능력이 떨어지기 때문에 내가 이쁘게 꾸미겠다고 공수를 들여봤자 아무도 눈치채지 못할 거긴 하지만.
얼추 준비가 수월하게 되어간다 싶었는데 위기 상황이 두 번 왔다.
1차 위기는 당연히 구글 I/O 시즌에 발표하겠지 싶었던 1.1.0 정식버전이 발표 전주인지 전전주에 갑자기 발표되었다. 그 전 까지 자료는 모두 당시 정식버전이 나왔던 1.0.2 를 기준으로 만들고, 마지막에 1.1.0 에는 이런 기능이 추가됩니다 식으로 몰아넣었는데 망했다. 청중이 발표를 듣고 바로 적용할 수 있도록 돕는게 나의 목표인데, 이미 1.1.0 나온 시점에 1.0.2 발표해봤자 뒷북이라 1.1.0을 기준으로 발표자료를 다시 꾸몄다. 물론 바닥부터 새로 만든게 아니라 장표를 재구성하고 머지하는 수준의 작업이긴 했지만 이것도 손이 많이 가긴 했다.
2차 위기는 도구의 문제였다. 맥과 윈도우를 오가면서 작업을 했기 때문에 구글 슬라이드로 작업을 했는데, 이게 프리젠테이션 모드에선 모든 폰트가 바탕 폰트로 보인다. 폰트만 바탕으로 나오면 안이쁘군! 하고 말텐데, 폰트가 바뀌면서 레이아웃이 죄다 미묘하게 틀어져버린다. 아씨! 이건 용납을 못하겠어서 머리를 쥐어뜯다가 혹시나 하고 powerpoint 로 export하니 얼추 꽤 잘 컨버팅이 되었다. 아쉽게도 마스터 슬라이드 적용이나 말머리 기호 통일 같은, 페이지 간 통일성있게 만드는 부분에선 이상한 동작을 해서 일일이 마스터 슬라이드 형태로 폰트와 말머리 기호 등을 변경해 줘야 했지만 그나마 이게 어디야. 정말 다른 분들 얘기처럼 구글 슬라이드를 쓰려면 아예 영어로 발표자료를 만들어야 할 듯 하다.
만든 발표자료는 아래 링크에서 확이할 수 있다.
https://www.slideshare.net/kingori/constraint-layout-94663983
발표 당일은 아내님이 코엑스까지 데려다주어 편하게 컨퍼런스장에 도착했다. 우선 전시부스의 상품들을 챙기고(...) 발표자 대기실에서 시뮬레이션을 좀 했는데, 확실히 예전보단 발표 자체에 대한 준비가 조금 부족한 감이 있었다. 이전까진 나름 "절대 시간을 넘기지 않는다" 를 발표의 목표(-_-;)로 삼았고, 이번에도 그럴수 있겠지 하는 근거없는 자신감이 있었다.
그리고 1시 55분, 내 발표 차례가 돌아왔다. 다행히 막 쿵쾅거리는 떨림은 별로 없었는데, 발표자 스탠드에 서는 순간 위기감을 느꼈다. 여기, 발표장에 시계가 없다... 핸드폰을 꺼내놓던지, 파워포인트의 발표자 도구를 좀 더 적극적으로 컨닝했으면 도움을 받았을텐데, 기존 발표할 땐 항상 발표장의 시계를 보면서 시간을 가늠했어서 다른 도구들을 활용할 생각이 나지 않았다. 그래도 뭐 어떻게 되지 않겠어? 생각했지만 이 세상에 그냥 되는게 어딨겠니. 결국엔 크게 중요하지 않는, 다른 글 찾아보면 다 나오는 부분들에 대부분의 시간을 할애한 나머지, 나름 엣지라고 생각한 후반부의 공식 부분을 후다닥 넘겨버리는 실패를 맛보았다.
다음 발표까지 5분 밖에 남지 않은 상태에서 마쳤기 때문에 다음 발표자 분께도 죄송하고, 화장실 제대로 다녀오지 못했을 청중분들께도 죄송하다는, 그리고 운영진들에게도 죄송하다는 이야기를 이 자리를 빌어서 남겨본다. 며칠전부턴 오로지 발표 연습을 했었어야 하는데 나의 불찰이다. 다음엔 이러지 않아야지 ㅠㅠ
마지막으로 발표 후 몇 분이 찾아오셔서 질문을 해 주셨다. 대부분의 내용은 "과연 실무에 당장 써도 될 수준인가?" 하는 부분인데, 난 다음과 같이 생각한다.
- 당장 써도 된다. 단, 버그는 있다. 하지만 이 세상에 버그 없는게 어디있겠어~ 작업하는 부분에서 벌어질 수 있는 상황을 레이아웃 프리뷰에서 충분히 실험해 본다면 충분히 안심하고 활용할 수 있을거다. 나도 발표자료 준비하면서 버그 2개 찾아서 보고까지 했다.
- RelativeLayout은 완전히 대체할 수 있다. 마음먹으면 LinearLayout도 대체할 수 있다. 하지만 LinearLayout 보다 xml 이 장황해지긴 한다. 그래서 나같으면 ConstraintLayout과 LinearLayout은 어느정도 섞어 쓸 것 같다. 단, ConstraintLayout 안에 LinearLayout을 포함하는 식으론 안 쓸 듯. 하여간 RelativeLayout은 이젠 쓸 일이 없다.
- ConstraintLayout을 쓰면 굉장히 flat한 레이아웃을 구성할 수 있지만, 너무 완전 flat한 레이아웃을 만들기 위해 혼신의 힘을 다 할 필요는 없다고 본다. adapter view의 항목과 같이 굉장히 많이 반복되는 뷰라면 최대한 flat하게 만들기 위해 노력할 가치가 있지만, 그 외의 경우엔 상황을 봐 가면서 판단하는게 좋다고 생각한다. 단적으로, flat 한 구조는 성능상 이점이 있겠지만 xml이 이해하기 어려워질 수 있다. 이럴 땐 어느정도 유지보수성과 성능을 타협을 하는 게 좋다고 본다.
마지막으로 컨퍼런스에서 열심히 들어주신 여러분과 발표 기회를 주신 드로이드나이츠 운영진 분들에게 고맙다는 말씀을 드린다.