2023 성빈랜드 컨퍼런스 발표 자료 및 질문-답변 공유

2023년 4월 8일 성빈랜드 컨퍼런스 세션 자료

연사님들의 답변 의도를 보존하기 위해 수정 없이 원본 그대로 공유합니다.

[지성빈] Welcome, Goodbye

[이기정] 미디어 플레이어 UDA 적용기

발표 자료 공유는 어렵습니다.

야근 많이 하셨나요?

네 많이 했습니다.. 실제로 개발하여 런칭 기간까지 1개월 남짓한 시간안에 해야했기 때문에, 주말에도 개발 시간을 할애하였습니다.

MVI, UDA가 가지는 단점 중 하나가 상태 복원인데요. 플립/폴드 폰과 같이 실행도중에 사용자의 액션으로 View가 재생성된 경우도 자주 있는 케이스 같습니다. 기정님이 생각하시는 상태 복원의 베스트? 추천하는 방법이 있으실까요?

제가 생각하는 상태복원의 Best Practice는 생명주기에 따라 복원돼야하는 것은 StateFlow로 State를 관리하고, 단발성 이벤트는 모두 SharedFlow로 SideEffect를 발행하는 것입니다. 코루틴에서 제공하는 repeatOnLifeCycle함수를 사용하면, onConfigurationChanged에 의해 생명주기가 다시 시작되는 경우에도 재구독을 통해 상태를 복원할 수 있습니다.

짧은시간에 엄청나게 많은 action이 이루어졌을때 문제점은 없을까요?? 가령 사용자가 스몰과 풀스크린을 1초에 수십번을 누르는 말도안되는 액션이 이루어졌을때나 재생,멈춤과 시크바를 동시에 계속 바꾸는 문제들이 발생하는 경우에요

많은 방법이 있겠지만, debounce 함수를 이용해 ActionFlow에서 들어오는 빠른 시간안에 여러번 호출하는 동작에 대해 특정 시간내 마지막에 들어온 이벤트만 처리하게 하는 것입니다. 그러면 수많은 Input이 들어오더라도 하나의 동작 요청을 해결할 수 있습니다.

viewModel의 함수가 유저의 Action 의미한다면, 굳이 Action을 정의하고 그걸 추적해서 호출하지 않아도 될 것 같은데 어떻게 생각하시나요?

Action을 반드시 정의할 필요는 없습니다. AirBnb에서 만든 Maveriks라는 UDA는 Action을 정의하지 않고, 요청에 대한 상태변경을 처리하도록 했습니다. Action을 사용하는 이유는 유저의 Input을 명시적으로 Define하기 위함이며, 입력에 따른 결과를 명확하게 추적하기 위함입니다.

1:1 관계만 고려된 디자인인가요? 2개이상의 UI가 ViewModel을 사용하게 된다면 Action에는 2개 이상의 UI에서 각각 필요한 것들이 Action에 모두 모여있게 되어서 명확한 Action 정의가 어려울것 같은데 어떻게 생각하시나요?

네 그렇습니다. 안드로이드에서는 AAC ViewModel을 사용 시 하나의 View에는 가급적 하나의 ViewModel을 바인하는 것이 좋고, 이것을 따르면서 UDA를 적용하는 것이 목적이었습니다. 그런경우에는 분리돼야하는 것이 맞다고 생각합니다.

앞으로 신규 프로젝트를 진행하는 경우에도 UDA를 계속 사용하실 의향이 있으신가요?

네 있습니다. 해당 프로젝트 런칭 이후 새롭게 개선하고 있는 기능에서도 UDA를 적용하고 있습니다.

혹시 uda 아키텍처 관련해서 참고할만한 레포가 있을까요? 오늘 발표 너무 잘들었습니다~

제가 사이드 프로젝트로 진행했던 Find Things라는 프로젝트를 공유드리겠습니다. 다만, 여기서는 Action을 사용하지 않았습니다. https://github.com/YAPP-Github/21st-Android-Team-2-Android

전역변수를 기존에 어떻게 쓰고 계셨나요?

기존에는 모든 View 상태를 전역변수로 관리하고 있었습니다. 가령 Play Pause 상태나, 재생이 성공적으로 시작됐는지, 해상도, 속도 등등말이죠.

postSideEffect 구현 부분이었던 것 같은데요!혹시 왜 내부에서 runBlocking으로 처리하게 되었는지 궁금합니다.

자료에서 잘못 보신 것 같습니다. withSideEffect로, 현재 replayCache에 있는 최신 값을 꺼내기 위함입니다. 다만, 동기적으로 가져와야 하는 경우 발표자료에 있는 runBlocking보단 replayCache.first()함수를 이용하는 것이 더 나은 방법일 것 같습니다.

ViewModel에서 화면을 실행하고 그 결과를 받아야 하는 경우 SideEffect에 어떤식으로 정의를 하셨나요? ConfirmSave(val completeListner: (Boolean) -> Unit): SideEffect() 와 같은 방식으로 사용하고 있는데 단방향으로 하면

그 경우에는 SideEffect를 통해 구독하고 있는 View애서 Launcher를 launch하고, 이후 결과를 다시 ViewModel로 Action을 통해 넘기면 될 것 같습니다.

기존의 안드로이드 아키텍처 가이드라인과 비교하는 슬라이드에서 (mvvm+uda) usecase를 타는 부분과 바로 레포지토리로 빠지는 부분이 있는데 두개로 분리되는 이유가 혹시 있을까요?

따로 이유는 없습니다. 구글에서도 UseCase나 Repository를 선택적으로 사용하라고 권장합니다.

하나의 화면에서 Action과 State, SideEffect가 많아졌을 때 ViewModel이 비대해지는 단점은 없었나요?

비대해지는 문제가 존재할 수 있습니다. 하지만, handleAction과 같은 함수를 통해 Action에 대한 함수를 명시적으로 when문에서 볼 수 있고, 함수를 추적하기 쉽습니다. 왜냐하면, action을 핸들링 하는 함수를 참조하고 있는 곳은 한곳 밖에 없기 때문입니다. 너무 비대해지는 것이 문제라면 Redux와 같이 Store, Reducer, Middleware를 분리하여 처리하는 것도 방법입니다. 또는, ViewModel을 각 도메인별로 분리하여 UDA에서 여러개의 ViewModel을 구독하도록 처리도 가능합니다.

설계를 진행하실 때, 툴이나 방법이 있으셨나요?

아키텍쳐 설계를 위한 플로우차트를 정의하고, 이것을 기반으로 비즈니스 로직을 구현합니다.

사이드이펙트를 우려하여 기존것을 버리고 아예 새로 작성한건데 기존 기능을 유지해야하는 리스크 또한 있지 않았나요?

맞습니다. 그렇기 때문에 시간도 그만큼 소요되는 문제가 있습니다. 그래서 정말 비즈니스 요구사항을 기간 내 UDA로 잘 설계할 수 있는지에 대한 엔지니어의 역량 및 판단력도 중요합니다.

서비스 도중 Action에 대한 처리 도중 에러가 발생하는 케이스가 있다면, 각 Action마다 Toast/Dialog/Finish 등의 개별 처리가 있다면 어떤 형태로 구현하는 것을 추천하시나요?

화면에서 처리돼야하는 One-Shot Event는 가급적 SideEffect로 정의하여 처리할 수 있을 것 같습니다.

hande 하는 부분에서 post가 어디서 발생되었는지 명확히 알기 어렵다면 디버깅이 용이하다고 보여지지는 않는것 같은데, 동일 action이 여러곳에서 post가 되는 경우는 없었나요?

로깅이 어렵다면, Action을 입력하는 곳에서 갖고있는 Source를 함께 넘겨주는 것도 방법일 것 같습니다. 애초에 UDA에서 Action을 입력받을 때, 여러곳에서 post가 되더라도, View의 소스를 추적하는 것보단, 그 안에 담겨있는 파라미터가 훨씬 중요할 것 같습니다.

새로운 아키텍처를 도입하는데 있어 팀원들을 설득하고 poc를 하는 과정이 있었다면 어떻게 이루어졌는지, 작성해주신 코드 리뷰가 어떻게 진행되었는지 그 과정이 궁금합니다.

이번 프로젝트는 빠르게 런칭이 돼야하는 프로젝트이기에, 팀원들을 설득하기 위해 샘플 PoC를 만들고, 이것을 기반으로 가이드라인 문서를 만들었습니다. 이에 대한 코드리뷰는 샘플 프로젝트를 PoC하고, PR를 리뷰하여 완료했습니다.

[윤희성] 소스코드로 알아보는 안드로이드 Context

솔직하게 저거 어케 다 이해하셨죠 ;; 보면서도 어지럽네요 ㄷㄷ

처음에 코드만 보면 이해하기 어려웠는데 각 클래스는 클래스 다이어그램을 그려보고 메소드 들은 시퀀스 다이어그램을 직접 그려본게 도움어 되었습니다! 개인적으로 소스코드는 최고의 교과서라고 생각합니다:)

면접에서 컨텍스트가 무엇이냐고 물어봤을때 제가 잘 대답을 못했었던 기억이 있는데, 희성님이 생각하셨을때 컨텍스트를 무엇인지 간단하게 표현하라하면 어떤식으로 얘기를 하실 생각이신가요?

안드로이드 시스템과 커뮤니케이션 하기 위한 맥락이라고 답변 할 거 같습니다!

쇼미더머니에는 언제 나가나요?

자료를 너무 많이 준비해서 말이 너무 빨랐던거 같네요. 욕심이 너무 많아서 일어난 일인거 같습니다 🥲

발표 너무 잘들었습니다. 제가 context에 대한 지식이 많지 않아서 그런거 같은데 말도 조금 빠르시고 용어가 너무 어려운거 같아요 ㅠ 전체적인 흐름은 알겠는데 뭐가 중요한지 잘 이해가 안가서 그러는데 혹시 context 사용시 주의할 점이나 중요한점 있을까요 ?

전부를 이해할 필요는 없고 한번 cs.android.com 에서 코드를 따라가보면 도움이 될거 같습니다:) 개인적으로 Context가 시스템과 커뮤니케이션을 위해서 사용되고, 안드로이드 컴포넌트는 ContextWrapper 를 상속하여 베이스컨택스트가 존재하고 교체할 수 있다는 점을 이해하면 도움 이 될거 같습니다. Context 사용시 주의할 점은 Ui관련 작업은 ActivityContext, 액티비티 라이프사이클을 벗어나는 경우는 applicationContext를 사용해야 한다 입니다. ApplicationContext는 앱 생성시 유지되기 때문에 잘못된 참조는 메모리 릭의 원인이 될 수 있습니다!

Context에 대한 깊은 이해가 응용 어플리케이션 개발에 어떤 도움이 된다고 생각하시나요?

Context는 결국 안드로이드 동작에 대한 이해라고 보면 좋을 거 같습니다. 그냥 쓰는 것과 알고 쓰는것에 차이는 분명하다고 생각합니다. androidx.appcompat의 localNightMode를 보면 attachBaseContext를 이용하여 앱별 다크 모드를 구현하고 있습니다. Context에 대한 이해가 있다면 무엇이 가능하고 무엇이 불가능한지에 대한 이해에 도우이 된다고 생각합니다.

발표자료 공유 가능하실까요? 그리고 기본적으로 어느정도 까지 알아야하는지 궁금합니다

발표자료는 성빈랜드 통해서 공유드릴 예정이고, 안드로이드가 왜 Context를 만들 수 밖에 없었는지 정도만 이해해도 안드로이드 프레임워크를 이해하는데 도움이 된다고 생각합니다. 어디까지 알아야 한다는 접근 보다 Context를 공부할 수록 보이는 시야가 넓어진다로 보는게 좋을 거 같습니다. Context는 결국 AOSP에 대한 이해와 관련되어 있습니다.

교수님 진도가 너무 빠른 것 같습니다. 대단하시네요…

cs.android.com 들어가서 android 선택 이후 frameworks/base/core 들어가서 Context 검색하면 소스코드 확인할 수 있습니다. 소스코드를 천천히 따라갈 때 발표 내용이 떠올라서 이해에 도움이 되면 좋을 거 같습니다:)

[이정욱] 이직! 그거 어떻게 하는 건데?

발표 자료 공유는 어렵습니다.

노션으로 이력서를 작성하는 경우가 일반적인데 인사 담당자 분들이나 실제 검토하시는 조직장으로 근무하시는 분들이 비선호하신다는 이야기를 많이 들었습니다. 정욱님도 면접관 시절에 같은 입장이셨다면 어떤 점이 불편하셨는지, 정욱님이 지원자였다면 어떻게 하셨을지 궁금합니다

노션이 불편했던 이유는 프린터로 출력해서 볼때도 웹페이지 형식에 최적화 되어 작성된다는 점인데, PDF로 추출시 단락별로 보기에 불편함이 없게 작성되었거나 아코디언 컴포넌트를 이용해서 접혀있다던가, 링크로 작성되어 있는 것들을 다시 별첨 형태로 수정해서 추출해주시면 이질감 없이 볼 수 있어서 크게 문제 삼지 않았습니다.

저 같은 경우는 프린트용 이력서와 포트폴리오를 준비하고 웹용 노션 등의 이력서와 포트폴리오 페이지를 링크를 추가하는 식으로 제출하곤 했습니다.

대표님이 회사이름을 공개하지 말라고 한 이유가 뭐였을거라고 생각하시나요?

사규에 있는 내용이라 저는 알고 있습니다만 정보보안 차원이라고만 답변드리겠습니다.

자신만의 연봉협상 꿀팁이 있을까요?

연봉협상을 잘 보려면 일단, 면접을 무조건 잘 봐야 합니다. 면접관 모두가 만족스러운 결과를 보여줬을 때 연봉 상승 확률이 비약적으로 올라갑니다. 그리고 재직중인 회사나 다른 합격한 곳이 있다면 카운터 오퍼를 쳐보는 것도 방법이겠죠.

CS, 자료구조, 알고리즘을 병행하면서 안드로이드를 공부하는 것이 벅차서 일단은 안드로이드만 공부를 진행하고있습니다. 주니어 단계에서 CS, 자료구조, 알고리즘을 안드로이드보다 먼저 공부하는게 좋을까요?

저는 항상 후배들에게 안드로이드 기술스택이나 코딩스킬 업에 급급해하기보단, 건축 설계의 주춧돌이 되는 CS 지식을 먼저 탄탄하게 쌓으라고 하고 있습니다.
CS 등의 기초지식을 쌓다보면 막연하게 보던 프레임워크 API들이 디자인 패턴이나 interface가 조금씩 매칭이 되면서 그려지실거에요. CS 기본기도 그렇고 프로그래밍 언어론의 나오는 객체지향 프로그래밍의 SOLID 원칙이라던가, 함수형 프로그래밍의 모나드라던가 하는 것도 보시면 도움 많이 되실거에요. 추천드리는 도서로는 한 권으로 읽는 컴퓨터 구조와 프로그래밍, 오브젝트 라는 도서가 있습니다.

말씀하시는 포트폴리오 정리형태는 어떤걸 선호하시는 건가요?? 회사 내에서 하던 프로젝트들은 github에 다 나와 있지 않은 경우가 많은데, 그런 경우는 ppt같은 자료로 라도 정리하는게 좋은걸까요?

네, ppt나 웹페이지 등의 문서로 당시 맡았던 feature들을 주요 요구사항과 해결방안, 주요 알고리즘, 느낀점들을 나열하고. 어려웠던 점 배운 점, 왜 이 알고리즘이나 기술들을 선택했는지 등을 정리 해주시면 좋습니다.

채용 공고에 몇 년 이상 경력만 기재되어있는 회사는 어떤 회사일거라고 예상하시나요?

정말로 그에 준하는 경험과 실력을 원하는, 당장 투입 될 사람이 있는 경우로 보여집니다. 그리고 1~3년차 뽑는 공고에 7년차 등의 시니어급 지원자가 있다면 서류에서 합격하지 못하는 경우가 많을거에요. 왜냐하면 두가지 이유가 있는데 팀원간의 케미를 위한 저년차가 필요한 경우와, 3년차 수준의 연봉을 생각하고 공고를 올렸는데 대뜸 7년차가 지원하면 생각했던 연봉 수준과 맞지 않기 때문 입니다. 부담스러운거죠.

재직하시면서 기술적 역량을 기르는 꿀팁이 궁금합니다.

제가 저년차일때엔 따로 공부하는 시간을 갖진 않았고, 출퇴근 시간을 최대한 활용해서 Android Weekly 등의 구독 서비스를 이용해서 당시 제가 관심 있거나 흥미로운, 당장 할 일에 연관이 있는 주제만 골라서 보곤 했습니다. 거기서 인사이트를 얻게 되면 실무에 적용해보거나, 자기전에 짬내서 잠깐씩 공부를 했었습니다.

그러다가 발등에 불이 떨어지는 시기가 몇번 있었는데요, 이 땐 정말 하루종일 공부만 했습니다. 공부 할 땐, 테크나 스킬 업을 위한 공부 뿐만 아니라 소프트 스킬을 늘릴 수 있는 도서들도 같이 보았습니다.

그리고, 특정 안드로이드 프레임워크나 라이브러리의 API를 사용 할 때 주로 API 사용법만 익히는게 아니라 내부를 들여다 보면서 모듈의 메커니즘을 이해하려고 많이 노력 했습니다.

[최우성] Compose Canvas로 예쁜 인터렉션 구현하기!

(질문 없음)

[류기민] Compose 정식 출시보다 앞섰던 Compose 적용기

(질문 없음)

감사합니다.