[Android/세미나실] 2024 Google I/O 참가 후기 및 정리

연구실 생활을 할 때 교수님을 따라 컨퍼런스 발표나 참관 등을 해본 경험은 있지만 스스로 적극적으로 나서서 참가해본 적은 없었다. 

Google I/O는 안드로이드 개발자로서 더 폭넓은 지식을 알아가고 싶고 성장하고 싶다는 생각에 처음으로 내돈내산 내발로 참여해보는 안드로이드 관련 대외 컨퍼런스, 세미나 행사였고 그래서 더 의미가 있었다. 

컨퍼런스는 인천 송도에서 열렸는데 뭔가 "멋있다~" 라는 생각이 들었지만 막상 가보니 '드릅게 먼 곳에서 하는구나' 라는 생각이.... 

 

혹시 너무 어렵고 막 지목해서 질문하고(학교냐고ㅋㅋㅋ) 그럴까봐 걱정했는데 후기를 찾아보니 진짜 그냥 듣고 오는거고, 강의도 30분 내외로 짧게 이루어지기 때문에 어떻게 보면 오히려 가볍게 느껴질 수도 있다는 이야기가 있었다. 

 

미리 안드로이드 섹션 강의 리스트를 확인해보니 역시나 요즘 대세인 Compose와 관련된 내용들로 가득했다. 

아직 Compose를 제대로 알지 못하는 나였기에 기본적인 개념은 떼고 가야 인천 송도까지 간 보람이 있겠다고 생각해서 유튜브 강의로 기본 컴포넌트에 대한 실습을 따라해보며 공부해갔다. 그래서인지 다행히 어느정도는 알아들을 수 있었다. 

바로 앞에 오크우드 타워(포스코)와 쉐라톤 호텔이..! 이전에 가족들과 종종 호캉스하던 곳(TMI)

 

다른 페스타(?)도 진행중이라 Google 페스타가 진행되는 구역으로 찾아가야 하는데 구역  찾기가 어렵다....

안내 종이나 팻말 좀 넉넉히 배치해줬으면....

 

기념품으로는 구글 티셔츠를 주는데 난 좀 늦게 갔더니 증정 티셔츠가 2XL 밖에 안 남았다. (이럴거면 미리 설문조사 왜 한겨..)

스탭들은 등에도 프린팅이 있어서 탐났다ㅋㅋ 

---

 

내가 듣고 싶은 섹션, 강의에 맞게 강의실을 이동하면서 듣는 자유로운 분위기이다. 

한 5시간동안 5개의 강연을 듣고 왔는데 기억에 남고 나도 이해할 수 있었던 강의 위주로 간단하게 정리해보려고 한다.

 

Compose 성능 끌어올리기

가장 마음에 드는 강의였다. 연사님의 강의력이 군더더기나 쓸데없는 농담 없이 딱 핵심 내용만 30분 안에 깔끔하게 말씀해주셔서 전달력이 가장 좋았다. 

 

1. 컴포즈 버전 올리기

• 컴포즈 버전을 올리면 더 나은 성능의 랜더링 엔진을 업그레이드 될 수 있기 때문이다. 가장 간단하면서도 중요한 시도라는 점이 웃겼다. 

2. 불필요한 Recomposition 줄이기

    컴포즈는 Composition -> layout -> drawing 이렇게 총 3단계에서 걸쳐 화면 UI를 그린다.

    코드를 작성하면 컴포넌트를 트리 구조로 구성하고 연산하는 작업이 Composition / 이를 layout 형태로 배치하는 것이 layout / 

    layout을 실제 UI 화면에 그리는 것을 drawing 이라고 알고 있다. 

 

    XML 과 비교했을 때 Compose의 장점 중 하나가 Composition 과정에서 컴포넌트 요소들을 한 번씩만 방문해 연산량과 속도가 더 

    개선된다는 점이라고 알고 있다. 그래서 이 Composition 과정이 성능을 좌우하는 요소라고 단번에 와닿았다. 

   

그렇다면 UI에 변화가 생길때 저 3단계가 다시 실행될 것이다. 하지만 이때 Compose 컴포넌트를 적절히 잘 작성하거나 함수로 분리하면 딱 변화가 생긴 부분만 Recomposition이 일어나고 그렇지 않은 부분은 재연산을 하지 않음으로서 성능을 개선할 수 있는 것이다. 

 

그렇다면 이 Recomposition이 언제 일어나는지를 이해해야 하고 skippable 과 restartable 상태에 대해 알아야 하는데 

skippable은 파라미터 값이 변경되지 않았다면 Recomposition이 가능한 상태이고 restartable는 Recomposition을 다시 요청할 수 있는 상태이다. 컴파일러에 의해 입력걊이나 상태가 변하면 그 지점이 restartable 지점이 되면서 하위 컴포넌트들이 전부 Recomposition 된다. 

 

위 코드에서 상태 변화는 favorite 에 대해서만 일어났는데 가장 가까운 restartable 지점이 TestListScreen 컴포져블 함수이기 때문에 Recomposition 범위가 저렇게 잡힌다. 

 

반면에 이 코드는 가장 가까운  restartable 지점이 Button 이기 때문에 Recomposition가 대폭 줄어든다. 

 

restartable 지점이 기본적으로 Compose 함수가 호출되는 지점이기 때문에 저렇게 Button 이라는 Compose 함수를 하위 컴포넌트로 적절히 잘 사용해줌으로서 가장 가까운 Recomposition 지점을 조정할 수 있다. 

 

그렇다면 skippable 과 restartable 지점이 어딘지 확인할 수 있다면 그걸 활용해서 컴포즈 함수를 잘 활용해 Recomposition 줄이고 성능을 높일 수 있다는 결론이다. 

 

 

어떤게 Stable 이고 어떤게 Unstable 인지 정리해주셨다

 

그렇다면 skippable 과 restartable 지점이 어딘지 어떻게 확인할 수 있고, 또 그렇게 규정되는 기준은 무엇일까?

우선 이는 Compiler에 의해 결정되는 것이기 때문에 Compose Compiler Reports 를 확인해보면 알 수 있다. 

그리고 위 자료처럼 stable 한 부분은 skip이 가능하고 unstable한 부분은 restart 될 수 있다고 이해했다. 

 

Report 분석을 통해 적절하게 컴포즈 함수를 작성할 수도 있겠지만 개발자가 명시적으로  @stable 과 @Immutable 어노테이션을 지정해 컴포넌트를 Stable 가능하고 이는 즉 Skippable 가능한 형태로 만들 수도 있다. 

 

@Immutable은  항상 불변임을 보장하도록 컴파일러와 약속하는 것이다. 즉,  변경 되어도 불변을 약속 했기에 UI 가 안 바뀌는 등 문제 발생 가능성 있고 @Immutabl이 명시된 곳의 모든 프로퍼티가 변경 불가능한 val 로 정의되어야 한다. 

그래서 차라리 @Immutable보다는 좀 느슨한 약속인 @stable 을 사용하는게 낫다고 한다. Recomposition 일어날 수 있는 지점이더라도 입력값, 파라미터 등이 동일하면 skip 해준다. 

 

하지만 이는 컴파일러가 자동으로 처리해줘야 할 일을 개발자가 인위적으로 조정하는 것이다. 물론 컴파일러가 신은 아니지만 아무튼 자주 해서는 안 될 일이기 때문에 성능 상의 문제가 발생했을 때만 적절히 사용하는게 좋다. 

클린코드에 과도하게 빠져 반복을 절대 용납하지 못하고 재사용성에 미쳐버려서는 안 된다는 말이 생각난다ㅋㅋ

 

 

 

3. 벤치마킹 툴을 사용해 이미 개발된 코드에서 어떤 성능 문제가 있는지 확인하기 

개발자가 이렇게 코드 작성, 함수 분리를 통해 성능을 개선할 수도 있지만 섣부르고 과도한 변경은 독이 될 수 있다. 

그렇기 때문에 꼭 필요한 성능 이슈를 탐색하고 찾아내는 것이 중요한데 MacroBenchMark 라는 툴을 사용해 어떤 부분에서 성능 이슈가 발생하는지 체크할 수 있는 방법을 알려주셨다. 

 

예를 들어 화면 로딩 시간에 대한 성능을 확인하기 위해 테스트 반복 횟수 등을 지정해주면 평균 로딩 시간 등을 알려주고 특정 수치보다 시간이 길면 이부분에서 성능 이슈가 발생할 수 있다는 것을 파악할 수 있다. 

 

CodeLab에서 따라해볼 수 있으니 그거 참고해서 해보면 좋을듯

 

(아마 네모 박스 부분이 좀 중요한 수치이고, 양수가 크면 로딩 속도가 오래걸리는거고 P99 로 갈수록 고성능에 대한 측정 결과이기 때문에 P99까지 최적화가 되면 완전 성능 굿~ 이라고 해석하면 됐던 것 같다...ㅎ)

 

---

Gemini in Android Studio

요즘 핫한 생성형 AI, 그중에서도 Google에서 밀고 있는 Gemini(잼민이) 에 관심이 가서 들어봤다. 

연사님이 조~금만 더 스피치 연습을 해서 오셨더라면 좀 더 몰입되었을 것 같은데 아무튼 내용 자체로 흥미로웠다.

 

내가 취한 내용은 별건 아니고...

• Gemini가 안드로이드 디바이스에서 사용하기에 최적화 되어있는 모델인데 모바일 개발은 최적화, 경량화가 중요하기 때문에 이부분이 아주 맘에 들었다
• 현재 LoRA 모델 사용하고 있는데  fine tuning 을 통해 충분히 모델 성능도 개선할 수 있다 
• 인터넷 연결 없이 사용 가능 / 개인 정보 민감한 콘텐츠 다루는 경우 좋은 선택 /  백엔드 인프라도 필요 없음

 

그리고 안드로이드 스튜디오에서 Gemini를 설치해 다음과 같은 것들을 해볼 수 있다는 것이었다. 

• 다양한 톤으로 메세지 응답 / 음성 녹음 요약 / 키보드 문자 메세지에 대한 스마트 답변 생성 (현재 사용되고 있는 서비스) 
• 추천 키워드 생성 (음식점 검색시 ~)
• 테스트 시나리오 작성 
• Code Description 작성

 

테스트 시나리오(코드) 작성 부분은 찐으로 꼭 사용해보고 싶었다. 아직 테스트 코드 작성 무경험자인 내가 쉽게 입문할 수 있도록 도움을 받을 수 있을 것 같고, 현재 출시된 '어비로' 앱이 어느정도 규모와 복잡도 있는 서비스이기 때문에 나 혼자 모든 테스트 코드를 다 작성하기 보다는 이런 AI의 힘을 빌리면 더 효율적일 것 같았다. 

Code Description 도 실무에서는 이런 작업이 중요하다고 알고 있는데 아직 나에게는 익숙하지 않은 작업이기에 도움을 받을 수 있을 것 같다고 생각했다. 

 

추천 키워드 같은 기능은 코드 작성에 도움이 되는게 아닌 서비스 기능에 활용할 수 있는 부분인데 '비건 음식점 추천 기능' 등에 활용할 수 있지 않을까 싶었다. 

 

이 강의는 엄청 큰 홀에서 진행됐다!! 홀 앞 뷰는 오크우드(포스코) 빌딩과 쉐라톤 호텔~ 전에 가족들과 종종 묶었던 호텔들ㅎㅎ (TMI)

 

---

Compose 에서 함수 분리

 

---

DataDog 를 모든 application에서 사용 

DataDog 을 너무 좋아하시는 연사님의 무한 DataDog PR 을 듣고 올 수 있었다. 

DataDog은 백엔드 개발자인 동기가 종종 사용하는 백엔드용 모니터링, 로그 분석 툴 정도로 알고 있었는데

이걸 모든 Application에 적용할 수 있다길래 안드로이드 환경에서도 적용할 수 있을까 하는 관심이 가서 들어봤다. 

 

1. 다양한 데이터를 수집해 하나의 플랫폼에서 활용 가능

• 하나의 플랫폼에서 이벤트, 트래픽, 에러, 로그 등 여러 데이터를 분석할 수 있기 때문에 백엔드 개발팀이 쓰는 분석툴, 프론트엔드 개발팀이 쓰는 분석툴, 기획팀이 쓰는 분석툴 이런식으로 여러개 사용할 필요없이 올인원으로 사용 가능하다는 장점이라고 이해했다 

2. 로그 저장을 할 때, 불필요한 로그 리소스는 제거를 해줌

• 로그가 계속 쌓이면 그게 비용과 연결되니까 학실히 장점인 것 같다.

3. 프론트엔드 단 모니터인 RUM 기능도 잘 제공함

• 사용자의 접속 환경에 상관없이 사용이 가능하다
• 클라이언트 에러, 페이지 종속성, 로딩 속도, 헤비 유저 등을 확인할 수 있다
• 아무래도 난 안드로이드(프론트엔드)개발자이기 때문에 이부분에 관심이 갔다
•  

강의를 쭉 듣고 나니 솔깃하는 부분이 있었고, 현재진행중인 '어비로' 프로젝트에 적용해볼 수 있지 않을까 싶었다. 

현재는 기획자분께서 이벤트 로그를 수집해 분석하기 위해 Amplitude(앰플리튜드)를 사용중인데 더 좋은 툴이 있다면 내가 먼저 제안해보는 것도 좋겠다 싶었다. 

 

그러다가 이 블로그 글을 읽고 재고해보게 되었다ㅋㅋㅋㅋ

https://steady-study.super.site/datadog-rum

운영환경 Datadog RUM 2개월 사용 후기

 

블로그의 내용은 결론적으로 DataDog 만으로 올인원 하기는 좀 힘들었고 이벤트 분석은 Amplitude, 프론트엔드 에러 모니터링은 Sentry 가 훨씬 낫다는 이야기다. 

난 프론트엔드 개발자이기 때문에 유저 에러 모니터링이 중요한데 RUM은 안 잡히는 에러도 많다고 한다.

DataDog은 역시 백엔드 개발자가 디버깅용으로 사용하기에는 좋은 것 같다. 

 

또 비용 문제도 있는데 수익이 완전 0₩ 인 사이드 프로젝트 팀에는 적용하기 쉽지 않은 것 같다. 

 

---

 

P.S. 원래 컨퍼런스라는게 약간 만남의 장, 친목 이런 목적도 있기 때문에 혹시나~ 다른 개발자들과 친해져볼 수 있을까? 하는 기대도 내심 있었지만 사실 그런 분위기도 그럴 힘도 없었기에 얌전히 발표만 듣고 왔다ㅋㅋ

또 당연히 나는 지식을 나누는 기쁨을 아는 사람이기에 언젠가는 나도 저기 서서 발표 해보고 싶다는 생각도 들었다.