이동식 저장소

2025년 회고

해스끼 — Wed, 31 Dec 2025 17:39:17 +0900

오랜만에 키보드로 글을 쓴다. 최근 몇 달간 키보드가 글 쓰는 맛을 느끼지 못해서 그런지, 입력에 조금 저항이 있는 듯하다. 아닌가, 입력하는 사람의 출력이 문제인가. 다행히 출력 속도가 느릴지언정 내용의 질은 크게 변하지 않은 듯하다.

어린 아이들은 살아온 기간이 상대적으로 짧기 때문에, 같은 1년이더라도 영향이 더 크기 마련이다. 그러나 이전 글에서 언급했듯이, 내 선배들은 시간의 경과를 별로 체감하지 못하는 듯하다. 나도 어느덧 아이들보다는 그 쪽에 더 가까운 나이가 되어 버렸지만, 하루하루가 강에 흘려버린 한 컵의 물이 되지 않도록 노력하고 있다.

올해에는 작년과 비교해서 여러가지로 힘썼던 일이 많다. 천천히 하나씩 돌아보자.

1년차!

1년차 사원이 되었다. 우리 회사는 특이하게도 7월 1일이 지날 때 연차를 가산한다. 따라서 올해 6월 30일까지 나는 0년차였고, 이 글을 쓰는 지금 1.5년차가 되었다.

업무를 배정받은 지 9개월 정도 지났는데, 놀랍게도 애착을 갖게 되었다(!). 과거 블린더를 개발할 때 경험했던 접근성 기능에 관한 업무인데, 플랫폼 중에서는 UI에 매우 가까운 기능이라 생각보다 빠르

게 익숙해질 수 있었다. 이로써 또 한 번, 내가 걱정하는 일은 사실 별 거 아니라는 사실을 증명하고야 말았다... 물론 좋은 방향으로.

온실 속 화초 신세에서 벗어나, 많은 조직과 사람들과 함께 일을 하고 있다. 단순 문의부터 협의, 요청, 때로는 질책까지 경험하게 되었다. 1년차가 이런 말 해도 돼요? 너 아니면 할 사람이 없어. 그렇군요 알겠습니다...

다행히도 거의 모든 사람들은 자신의 책임을 기꺼이 수행하려 했고, 덕분에 큰 마찰 없이 일할 수 있었다. 그 사람들도 나를 이렇게 생각할까? 그랬으면 좋겠다.

내년에는 올해보다 더 규모있는 경험을 할 수 있을 듯하다. 우리 플랫폼이 처음으로 출시될 예정이고, 특히 내 기능도 주요 상품성 중 하나로서 포함된다고 한다. 출시될 때 보람을 느낄 수 있도록 조금 더 열심히, 꼼꼼하게 만들어 가야겠다.

Piano

취준생 때 다니던 피아노 학원이 있는데, 올해 2월 다른 지점에서 다시 등록하게 되었다. 대학 동아리 다닐 때처럼 연주회에 자주 참여할 수 있는 점이 제일 좋았다. 무려 2번이나! 심지어 두 번 모두 클래식으로 참여했다. 이 문장을 빌어 열심히 일해준 손가락에게 감사를 표함.

살아오면서 여러 취미를 가지려고 했지만 실패하는 경우가 많았는데, 음악만큼은 길게 이어갈 수 있어 다행이라고 생각한다. 내년에는 유튜브 영상 2개 올리기를 목표로.

다만 한 가지 과제가 생겼다. 악기 연주란 본질적으로 근육의 세밀한 조정과 협동을 필요로 하는데, 생활 근력조차 부족한 나에게는 슬슬 한계가 다가오는 듯하다. 그것조차 없어서 지금도 오른발을 또 다친 신세가 되었다 -_-

이제는 진짜로 운동해야.. 건강하게 살기 위해서라도.

취미생활

최근 개인적인 깨달음을 두 가지 얻었다. 첫 번째는 내 취향이 매우 독특하다는 점이고, 두 번째는 따라서 함께 취미생활을 공유할 수 있는 사람이 매우 드물다는 점. 예전 같았으면 나는 왜 이 모양인지 자책했겠지만, 지금은 그럼 혼자 놀면 되지! 라고 받아들였다. 저 조금 대단하지 않나요?

아직 좋아하는 걸 좋아한다고 말하기는 무섭지만, 적어도 스스로에게는 거짓말하지 않고 즐기기로 했다. 목적없이 나가서 걷기도 하고, 예전부터 팬이었던 분들 공연도 봤다.

청담대교

Vanilla Mood 2025 내한공연

일본 초등학생 수준 인증도 받았다

이 문장을 빌어 취미의 작은 부분이나마 나눌 수 있는 주변인들에게 감사를 전한다. 내년에는 우리 더 많이 즐겨보자.

사이드 프로젝트

쿠링 팀에 3년째 참여하고 있다. 메인 개발자로서 참여하기 어려워진 만큼, 올해부터는 서브 개발자로서 코드리뷰 및 잡일을 도맡아 하고 있다.

솔직히 작년에는 엄청 귀찮았는데, 지금 생각해 보면 앱 개발자로서의 정체성을 잃지 않을 수 있는 귀중한 경험을 하고 있다. 앞으로도 플랫폼 일을 계속 하게 될 지는 모르지만, 만약 앱 개발을 직업으로 삼게 된다면 120% 쿠링과 쿠링의 열정적인 팀원들 덕분이다. 고마워요.

내년부터는 안드로이드 서브 개발자를 병행하면서, 기획자로서도 참여하게 된다. 나는 좋은 리더가 될 수 있을까? 2026년 회고에서 확인해 보자.

마치며

20대 중반까지의 내 삶은 살아남기 위한 투쟁이었다고 볼 수 있다. 투쟁 결과 놀랍게도 가족을 먹여살릴 수 있게 되었지만, 그 과정에서 나는 종종 뒷전으로 밀려났다.

앞으로 몇 년간은 나에게 조금 더 집중해보려 한다. 2026년에도 다양한 경험을 할 수 있기를.

입사 1년차

해스끼 — Sun, 31 Aug 2025 22:09:42 +0900

정확히 1년 하고도 5일 전, 사람을 산 채로 삶아버릴 기세의 여름날 더위에 진절머리를 느끼며, 버스 한 대에 올랐다. 생전 처음 하는 반깁스와, 마찬가지로 생전 처음 받아든 입사 환영 팜플렛과 함께.

지금은 깁스도 팜플렛도 어디론가 사라진 지 오래지만, 그 때의 설렘과 두려움은 잊고 싶어도 잊을 수가 없다. 경마장의 말처럼 앞만 보고 달려야 했던 나에게 처음으로 여유로운 삶이 주어진 순간이었기 때문이다. 다음 달 통장 잔고를 걱정하던 내가, 어느새 자기 앞가림을 할 수 있는 능력과 자유를 얻었다.

연수 후 집으로 돌아가는 버스에서. 이 길을 일주일에 5번, 말 그대로 밥 먹듯이 지나가게 되었다.

인간의 욕구에는 단계가 있어, 최소한의 생리적 및 생존 욕구가 충족된 후에는, 소속감이나 존중, 자아실현 등 정신적인 만족을 추구하게 된다고 한다. 이 이론은 나에게도 그대로 적용되어, 단지 먹고 살 수 있는 사람이 아닌 더 나은 사람이 되기 위해 노력하게 되었다. 조직에 필요한 사람이 되고 싶었고, 타인에게 좋은 사람으로 기억되고 싶었다. 무엇보다 사는 대로 생각하는 사람이 아닌, 생각하는 대로 사는 사람이 되고 싶었다.

죄다 처음 하는 것들뿐이라, 뭔가 잘못된 것 같으면서도 내가 아는 방식으로밖에 할 수 없었다. 다행히 내 주변 사람들은 험담과 비난 대신 도움과 조언을 아끼지 않았다. 고마움을 표현하지 못하는 내 자신이 싫어질 정도로.

1년차에게 가장 중요한 건 기술적인 전문성이 아닌 정확한 소통 능력 내지는 소위 말하는 '일버릇'일 지도 모르겠다. 사수들은 그렇게 생각하지 않는 것 같지만..

아니다. 갤럭시는 컵라면이 제일 중요하다고 한다.

1주년을 핑계로 사수분들께 밥을 얻어먹은 적이 있는데, 이때 들은 말이 아직도 생경하다.

너는 물어볼 때마다 하루하루가 재밌다고 하는데, 사실 우리 정도 연차가 되면(15년차!) 정반대야. 하루하루가 똑같아. 그래서 가끔이라도 자극이 되는 일이 없으면 견딜 수가 없어.

난 진짜로 재밌는데.. 물론 세상에 긍정적인 재미만 있는 건 아니지만, 적어도 아직은 활기차게 하루를 시작할 수 있다. 안 하던 것들도 많이 해보고 있고. 시니어가 된 후에도 지금 마음가짐을 계속 이어갈 수 있었으면 좋겠다.

마지막으로 안 하던 것들 중 하나를 소개해볼까 한다. 굳이 여기에 적는 이유는, 2년차 회고를 쓸 때가지 포기하지 않기 위한 나름의 압박이다.

우선 상대방이 자신을 알 수 있도록 노력합시다.
그리고 상대방을 알기 위해 노력합시다.

상대방이 나를, 내가 상대방을 알게 된다면, 이해의 기회가 생겨나고
마침내 서로를 인정할 수 있게 됩니다.

예전 같으면 나와 다르다는 이유로 무시하고 넘어갔을 사람들도, 조금씩 이해하고 인정해 보려 한다. 할 수 있겠지?

할 수 있을지 없을지는.. 1년 후에 공개

임금님 귀는 당나귀 귀

해스끼 — Wed, 14 May 2025 23:05:03 +0900

취업준비생 시절 링크드인을 위시한 개발자 SNS를 자주 보던 적이 있었다. 프로필 세팅을 끝내고 스크롤을 내리다 문득 이런 생각을 했다. '세상에 왜 이리 대단한 사람이 많지?'

아래를 보고 안도하기보단 위를 보고 부족함을 느끼는 성격이어서가 아니다. 우리 세상에는 각자의 목표를 위해 도전을 이어가는 멋진 사람들이 산더미만큼 있다. 존경할 만하다.

그에 비하면 내가 사는 방식은 거창하지도 않고 공감받기도 쉽지 않으며 대의명분이라곤 눈곱만큼도 없다. 그럼에도 불구하고 이런 평범한 이야기를 정기적으로 적는 이유는 무엇인가?

5년 전, 아직 코로나가 없던 시절 블로그를 처음 만들며 이런 목표를 세웠다.

나중에 내가 참고할 수 있는 블로그를 만들고 싶다.

그 당시에는 통계 부전공자로서 데이터 분석가를 목표로 했었다. 이게 내 첫 번째 블로그 글이다.

Numpy - Numerical Python

Numpy는 수학 연산을 더 쉽고 빠르게 지원해 주는 Python 라이브러리입니다. Numpy는 내부의 많은 부분이 C로 작성되어 있기 때문에, Python 리스트 연산보다 빠른 속도를 자랑합니다. Python으로 회귀분

thinking-face.tistory.com

방금 다시 읽어봤는데 제법 귀엽다. 존댓말도 쓰고.

데이터 분석을 직업으로 삼지는 않았지만(물론 세상 일은 모른다), 업무나 사이드 프로젝트를 위해 과거 글을 참고한 적이 적지 않다. 결과적으로 5년 전의 목표를 달성한 셈이다.

회사에서 일하는 지금도 같은 목표를 세우고 있다. 미래의 내가 오늘을 고마워할 수 있도록, 현재를 통해 미래를 만들자. 블로그뿐만 아니라 내가 관심을 갖는 모든 영역에 대해. 언젠가 오늘을 돌아봤을 때, 그땐 참 열심히 살았지, 라고 추억할 수 있도록.

그렇기에 나의 현재를 가감없이 적는 것이다.

마음속에서 '그럼 일기를 적으면 되지 않느냐'는 외침이 들려왔다. 그치만 일기는 귀찮은걸..

매일 출근을 하고, 의지와 상관없이 수많은 사람들을 만나고, 피드백을 받고, 몇 개는 무시하고, 그래도 몇 개는 듣고, 뭐 그런 일상을 이어가고 있다. 요즘은 내가 너무 순진했나 싶기도 하다.

미래의 나는 회사에서 어떤 인간관계를 맺고 있을까? 궁금하다..

6개월차 신입사원

해스끼 — Sun, 2 Mar 2025 23:25:35 +0900

지난주로 입사 6개월차가 되었다. 6개월이라는 기간에는 큰 의미가 있다. 왜냐하면 내가 그렇게 생각하기 때문이다. 성취감 정도는 내 맘대로 채워도 되지 않을까 싶다.

독보적으로 바쁜 팀에 신입으로 들어와, 십수 명의 1n년차 선배들을 매일같이 마주했다. 쉬운 일을 하고, 어려운 일을 하고, 오래 걸리는 일을 했다. 코딩에는 나름 자신있는 편이었지만, 이상하게 사무실에만 앉으면 내 생각대로 되는 게 하나도 없었다. 그래도 어떻게든 버텼다.

매일 같은 사람들을 만나 대화하고, 웃고, 때로는 싫은 말도 듣는다. 아무런 대가 없는 친구 관계와 돈을 받고 다니는 회사에서의 관계는 다를 수밖에 없다. 특히 나처럼 관계에 서투른 사람이라면 더더욱 적응하기 어렵다. 과거의 실수를 되풀이하지 않기 위해, 어떻게든 6개월을 버텼다.

버티는 건 예전부터 자신있었다. 선배들에게도 그렇게 보인 것 같다. 최근에 '처음 들어왔을 때보다 여유가 생긴 것 같다'는 말을 몇 번 들었는데, 대강 여유있는 척할 수 있는 여유 정도는 생겼다. 다음 목표는 진심으로 여유를 갖고 일하는 것이다.

그런데 요즘 여기저기 불려가는 일이 많아서 고민이다;; 어려운 건 어렵다고 솔직하게 말할 수 있어야 하는데, 우물쭈물하다 뒤늦게 후회하는 경우가 많다. 이게 습관이 되면 정말 큰일날 것 같아, 당분간은 용기내는 연습을 해보려 한다.

지난주 입사 6개월을 기념하여, 앞으로 담당하게 될 업무가 대강 정해졌다. 처음 입사할 때 나에게 주어진 가능성은 두 가지였다.

잘 모르지만 대충 주워들은 게 있는 업무
듣도 보도 못한 완전히 새로운 업무

결과는? 당연히 2번이다... 중요한 순간에 항상 운이 나쁜 나다운 결과였다. 돈을 받고 다니는 사람으로서 선택권은 없었다.

선택할 수 없는 걸 후회하지 말자는 주의로 살아왔지만, 미래의 나도 그렇게 생각할까? 1번을 받아들인 나를 상상하며 후회하지 않을 수 있을까?

잘 할 수 있을까?

지금의 이 감정이, 모르는 것을 특히 두려워하는 나의 엄살이었으면 좋겠다. 지금은 그렇게 믿고 열심히 사는 수밖에 없다.

3월은 휴일도 있고 재미있는 교육도 많다. 조금 더 천천히, 하지만 충실하게 살아보자. 언젠가 이 글을 돌아보며 추억할 수 있도록.

2024년 회고

해스끼 — Sat, 28 Dec 2024 21:59:41 +0900

2개월만의 띵킹이다.

벌써 2달이 지났다고? 마지막 글의 작성일을 볼 때마다 시간의 속도를 느낀다. 사실 이렇게라도 느끼지 않으면 시간에 떠밀려 흘러가버릴 것 같다. 그만큼 개인적으로도, 사회적으로도 정신없는 한 해였다.

달력을 한 장씩 넘길 때마다 '저번달에 아무것도 안 했는데...'라는 생각을 자주 했다. 하지만 나도 사람이니만큼 진짜로 아무것도 안 하지는 않았다. 지난 1년동안 뭘 했는지 간단하게 살펴보자.

새해 첫 글

당황스럽게도 1월 1일부터 코딩 글을 작성했다. 글 주제는 Accompanist navigation 라이브러리 deprecated 해결 방법. 너 생각보다 공부 열심히 했구나?

Accompanist Compose Navigation 라이브러리 deprecated - migration 가이드

아래 글에 나와있는 내용대로 하면 99%는 해결된다. Guide - Accompanist Jetpack Navigation Compose Animation A library which provides Compose Animation support for Jetpack Navigation Compose. Warning This library is deprecated, with officia

thinking-face.tistory.com

인생에서 가장 중요한 코딩을 하고 있었던 때라 나름 열심이었던 것 같다. 결과적으로 이 때의 경험이 취업하는 데 절대적인 영향을 미치기도 했다.

것보다 새해 첫날부터 코딩이라... 얼마전에 크리스마스에 코딩했다고 말했다가 혼난(??) 적이 있는데, 세상에 이런 사람도 있어야 다양성이 보장된다고 생각한다. 아님 말고

배리어프리 최우수상

2023 배리어프리 앱 개발 콘테스트 회고 (1)

2024년 2월 21일 최종 발표회를 끝으로, 2023 배리어프리 앱 개발 콘테스트가 끝났다. 콘테스트 참가부터 최종 발표까지 약 10개월 간 있었던 일을 간략하게 적어 본다. 국내 최초 접근성 보장 학사

thinking-face.tistory.com

2023 배리어프리 앱 개발 콘테스트 회고 (2)

1편에서 이어집니다. 2023 배리어프리 앱 개발 콘테스트 회고 (1) 이동식 저장소 2023 배리어프리 앱 개발 콘테스트 회고 (1) 본문 프로젝트/블린더 2023 배리어프리 앱 개발 콘테스트 회고 (1) 해스끼

thinking-face.tistory.com

블린더 개발 과정은 내 인생에서 가장 중요한 경험이었다. 내가 만든 앱을 통해 실제로 정보 접근성을 높였기 때문이다. 앱 개발자로서 처음으로 존재 의의를 인정받은 것이다.

함께 서비스를 만든 팀원들, 소중한 피드백을 남겨준 맹학교 아이들과 선생님 분들, 아낌없는 조언을 남겨주신 콘테스트 멘토님께 다시 한번 감사를 표한다.

이때 개발한 블린더는 계속 유지보수하고 있다. 여름에는 iOS 앱도 출시했다. 적어도 내가 할 수 있을 때까지는 계속 개발하고 싶지만, 얼마나 더 할 수 있을지는 모르겠다.

졸업

배리어프리 시상식 바로 다음날에 졸업을 했다. 눈이 엄청나게 왔고, 날씨도 추워서 계속 미끄러졌던 기억만 난다. 그래서 내 졸업사진은 어설프게 웃은 사진밖에 없다. 웃으려고 노력했지만 얼굴이 얼어서;;

이거 활짝 웃은 거다. 진짜다

졸업유예를 할까 잠깐 고민했지만, 학교라는 울타리가 있으면 나태해질 것 같아 바로 졸업했다. 울타리가 없다고 해서 성실하게 살까... 는 생각하지 않기로 했다. 자기를 몰아붙인다고 해서 모든 문제가 해결되지는 않는다. 그런 건 고3 때나 하는 것이다.

취준생활

졸업식이 끝나고 돌아온 첫 월요일 아침, 나는 완벽한 백수가 되었다. 권리도 없지만 책임도 없는 완벽한 방임 상태가 찾아왔다. 그래도 먹고는 살아야 하니까 먹고살 길을 찾아 나섰다.

취준생으로서 내 위치를 깨닫는 데에는 오래 걸리지 않았다. 학점은 좀 높지만 변변찮은 인턴 경험 하나 없고, 앱이 최우수상을 받았다곤 하지만 기술적으로 크게 매력적인 점은 없었다. 겉보기에는 그럴듯해 보이지만 기술적인 차별점이 있는 지원자는 아니었다.

이 때부터 단순히 갖다 쓰는 게 아니라 내부 원리를 파고들기 시작했다. 많은 선배들이 '그냥 갖다 쓰는 건 누구나 한다'고 경고했지만, 역시 직접 겪어야 실감하게 되는 법이다.

하나라도 깊게 파본 경험이 있어야 다른 것도 잘 파게 된다. 회사에서도 항상 유념하는 부분이다.

졸업 후부터 취업까지 6개월 정도 걸렸는데, 어쩌면 나를 가장 가까이에서 마주했던 시기였을 지도 모른다. 자기소개서 한 문장도 대충 쓰지 않았다. 나를 아무렇게나 표현하고 싶지 않았다.

내 25년이 얼마나 재밌었는지 알아? 다른 인생은 안 살아봐서 모르겠지만 나도 제법 얘깃거리가 많거든?

그래놓고 두 번이나 일정 놓쳐서 떨어졌지.. 뭐 그렇게 4학년 2학기부터 19연패를 이어갔다. 하지만 이 게임의 가장 큰 장점은, 한 번만 이기면 된다는 것.

졸업한 지 반 년이 되어가던 8월, 나는 단 한 번의 승리를 거뒀다.

취업

전업 백수 탈출기 #1

2024년 8월 9일, 세 명의 젊은이들이 동대문 카페에 모여 각자의 문제와 씨름하고 있었다. 한 명은 생전 처음 보는 플랫폼과 사투를 벌이고 있었고, 다른 한 명은 스터디 준비에 열을 올리고 있었

thinking-face.tistory.com

전업 백수 탈출기 #2

#1에서 이어집니다.두 번의 시험1차면접은 평이했다. 쉬웠다는 말이 아니고, 언제나처럼 긴장 잔뜩 하고 버벅였다는 뜻이다. 그럼에도 불구하고 면접관 분들께서는 나를 한번 더 보고 싶으셨던

thinking-face.tistory.com

저 글은 입사 1개월차에 적었다. 4개월차가 된 지금 생각을 조금 적어 보면... 세상에 쉬운 게 없다. 첫 회사라 그런지 모든 게 새롭고 어색하다. 해도 되는 것과 해야 하는 것을 가리는 데 2달 정도 걸렸다. 팀장님께 '자리에서 과일 먹어도 돼요?'라고 진지하게 여쭤봤던 기억이 난다.

학생들을 위해 답을 적어보자면, 당연히 된다. ㅋㅋ 그 정도로 나는 아무것도 모르는 신입이었다. 물론 지금도 아는 건 별로 없다.

기술 스택은 안드로이드로 동일하지만, 지금까지 했던 앱이 아닌 프레임워크 API 레벨을 개발하게 됐다. 그렇게 공부하고 싶었던 안드로이드 내부를 돈 받으면서 공부하고 있다. 강제로 목표달성 하고 있다...

공부한 내용은 매주 세미나에서 팀 선배님들께 발표했다. 아직은 여기저기 찔러본 수준이지만, 언젠가는 나도 팀 선배님들처럼 질문을 두려워하지 않는 사람이 되고 싶다. 세미나에서 질문 받으면 그렇게 무서울 수가 없다. 그거 모르는데... 저거도...

내년부터는 실무 개발도 조금씩 맡길 예정이라고 한다. 모르는 건 솔직하게 모른다고 하고, 대신 아는 건 확실하게 처리하고 싶다. 아직은 모르는 걸 인정하는 용기가 부족한 것 같다. 용기를 가지자.

2025년은..

내일부터 입사 후 첫 휴가다. 내년은 올해보다 몇 배는 더 힘들 것 같다. 쉴 수 있을 때 잘 쉬자. 그래도 나는 회복탄력성은 나쁘지 않은 것 같아 다행이다.

2024년 수고했고, 2025년도 힘껏 살아 보자.

내 귀찮음이 보상받을 수 있도록, 언젠가 이 글을 돌아보며 웃을 수 있기를 기원한다.

Macrobenchmark로 프레임 성능 측정하기 - 심화

해스끼 — Sun, 20 Oct 2024 22:06:25 +0900

이전 글에서 Android Macrobenchmark를 활용하여 프레임 성능을 개선하는 과정을 설명한 적이 있다.

Macrobenchmark로 프레임 성능 측정하기

문제 상황온보딩 화면에서 기능 소개 탭을 스크롤할 때 프레임 드랍이 발생하는 문제가 있다.이 글에서는 Macrobenchmark를 활용하여 프레임 성능을 측정하고, 성능 문제를 해결하는 연습을 해 보겠

thinking-face.tistory.com

회사 세미나에서 이 경험을 공유했는데, 팀 선배 분들께서 공부 의욕이 뿜뿜하는 질문을 주셨다. 한번 공부해 보자.

frameOverrunMs와 frameDurationCpuMs의 차이가 일정하지 않은 이유?

개선하기 전의 성능 측정 결과를 보자.

두 수치의 P50은 13.4ms 정도 차이나지만, P99의 차이는 무려 1,547.2ms이다. 원 글에서는 ``frameOverrunMs``가 actual duration - expected duration이라고 설명했는데, 위 결과대로라면 expected duration이 음수이며, 심지어 점점 작아진다는(?!) 말도 안 되는 결론이 나온다.

대체 무슨 일이 일어난 걸까?

먼저 ``frameDurationCpuMs``의 의미를 정확히 이해할 필요가 있다. 공식 문서에서는 즉 CPU가 프레임을 만드는 시간이라고 설명하고 있다.

How much time the frame took to be produced on the CPU - on both the UI Thread, and RenderThread. Note that this doesn't account for time before the frame started (before Choreographer#doFrame), as that data isn't available in traces prior to API 31.

그런데 프레임을 그리기 위해서는 CPU 외에도 GPU, 디스플레이 하드웨어가 작업을 수행해야 한다. 즉 CPU 시간은 프레임을 그리는 시간의 일부라는 것.

타임라인을 자세히 그려보면 다음과 같다.

새 프레임 요청: ``Choreographer#doFrame`` 또는 ``AChoreographer_vsyncCallback``이 호출되는 시간이다. 참고로 vsync는 수직 동기화를 의미한다.
CPU 작업: View 또는 Compose UI element를 composition, layout, measure한다. UI 구성, 배치 등을 결정한다고 생각하면 된다.
GPU 렌더링 시작: CPU에서 계산한 작업을 바탕으로 GPU에서 픽셀을 계산한다.
GPU 렌더링 끝: 픽셀 계산이 종료된다.
픽셀 전송 완료: 계산한 픽셀을 ``SurfaceFlinger``에 전송한다. ``SurfaceFlinger``는 여러 앱에서 보낸 픽셀을 합쳐 프레임을 완성하고, 디스플레이 하드웨어에 프레임을 전송한다.

뭔가 모르는 말을 잔뜩 써놨는데, 자세한 내용은 아래 접은글에 서술하였다.

# Choreographer (열기)

프레임을 그리는 타이밍을 동기화한다.

GPU가 프레임을 그리는 빈도(fps)와 디스플레이가 업데이트될 수 있는 주기(주사율; hz)는 다를 수 있다. 예를 들어 GPU의 프레임 생성 속도가 느리다면, 디스플레이의 일부만 새 프레임으로 갱신되는 tearing(찢어짐) 현상이 발생할 수 있다.

이런 문제를 해결하려면 GPU와 디스플레이의 업데이트 빈도를 동일하게 맞춰야 한다. 프레임이 완전히 생성될 때까지 기다리는 수직 동기화 기술을 적용하면 된다.

수직 동기화 신호가 주어지면 ``Choreographer#doFrame()`` 또는 ``AChoreographer_vsyncCallback`` 함수 안에서 UI 콜백이나 애니메이션 작업이 수행된다. 그 후 render 스레드에서 layout measurement/placement 작업을 수행한다.

GPU는 렌더 스레드의 결과를 바탕으로 실제 픽셀 데이터를 계산한다.

일반적으로 ``Choreographer#doFrame()``이 종료된 후 즉시 프레임 렌더링이 시작되지만, 프레임 드랍이 발생하는 경우에는 렌더링이 즉시 시작되지 않을 수 있다.

정상: 왼쪽 위의 Choreographer 함수가 끝난 직후 DrawFrame 작업이 실행되는 모습

비정상: 가운데 작은 부분에서 doFrame()이 실행되고, 약 60ms 후에 DrawFrame 작업이 실행되는 모습

# SurfaceFlinger (열기)

여러 개의 surface를 하나의 프레임으로 합성하여, 디스플레이 하드웨어에 보내는 역할을 한다.

프레임은 여러 개의 surface로 구성될 수 있다. Surface는 픽셀 데이터를 의미한다. 예를 들어 상단 바와 하단 내비게이션 바는 독립된 surface를 가지며, 화면에 보이는 포그라운드 앱은 하나 이상의 surface를 가질 수 있다.

각 surface는 buffer queue를 통해 SurfaceFlinger에 전달된다. SurfaceFlinger는 각 buffer queue의 최신 surface만을 사용하여 프레임을 만든다.

코드 보기: services/surfaceflinger/SurfaceFlinger.cpp - platform/frameworks/native - Git at Google

# UI 스레드와 Render 스레드의 차이 (열기)

UI 스레드는 UI에 접근할 수 있는 유일한 스레드를 말한다. 뷰의 생명주기에 따라 ``onMeasure()``, ``onLayout()`` 등의 콜백을 실행하고, 렌더링에 필요한 정보를 수집하여 render 스레드에 전달한다. 렌더링 작업의 dispatcher 역할을 한다.

Render 스레드는 UI 스레드의 정보를 처리하여 UI를 구성하는 역할을 한다. UI 요소를 measure 및 layout하는 등의 작업이 수행된다. Compose로 따지면 composition과 layout(measure, placement) 단계이 수행된다고 보면 된다.

일반적으로 UI 스레드와 렌더 스레드는 synchronous하게 작동하지만, 애니메이션 등의 일부 작업을 수행할 때에는 비동기적으로 동작한다. 그래서 UI 스레드가 무거운 로직을 수행하고 있을 때에도 애니메이션을 부드럽게 재생할 수 있는 것.

코드 보기: libs/hwui/renderthread/RenderThread.cpp - platform/frameworks/base - Git at Google

프레임 생성 시간은 CPU 시간 외에도 많은 시간을 포함한다. 따라서 ``frameDurationCpuMs``만으로는 프레임 생성 시간을 정확히 알 수 없다.

프레임 성능을 정확히 파악하려면, 공식 문서에서 말하는 대로 ``frameOverrunMs``를 참고하는 것이 좋다.

Generally, prefer tracking and detecting regressions with frameOverrunMs when it is available, as it is the more complete data, and accounts for modern devices (including higher, variable framerate rendering) more naturally.

그렇다면 ``frameOverrunMs``는 왜 이렇게 커진 걸까? 간단하게 요약하면 다음과 같다.

CPU 작업은 크게 ``Choreographer#doFrame()``과 렌더 스레드 작업으로 나눌 수 있다.
Profiler를 자세히 보니, ``Choreographer#doFrame()``은 비교적 빨리 끝난다. (약 2ms 정도)
그런데 ``Chronographer#doFrame()``이 종료된 후 렌더 스레드 작업이 즉시 실행되지 않는다. 렌더 스레드가 다른 작업으로 포화되었기 때문이다.
그 이유는 앞서 생성된 프레임의 렌더 스레드 작업이 지연되었기 때문. 위 사진만 봐도 빽빽하게 차 있다...
즉 이전 프레임에서 지연된 시간이 ``frameOverrunMs``에 점점 누적되는 구조이다.

이 문제를 해결하려면 프레임을 아예 안 만드는 수밖에 없고, 그래서 프레임 드랍이 발생하는 것이다.

참고로 GPU 렌더링 시간은 거의 ㎲ 단위이기 때문에, 게임 같은 특수한 경우가 아니라면 GPU 문제일 가능성은 매우 낮다.

리소스 문제였다니 좀 허무하다. 안드로이드 기능을 사용해서 해결할 수는 없을까?

우선 dpi마다 다른 이미지 파일을 사용하는 방법이 있다. Dpi가 낮은 기기에서는 1024×1024보다 작은 파일을 사용하는 것. Dpi가 낮으면 기기 성능도 낮을 가능성이 높으므로 유효한 방법이다.

또는 이미지를 미리 로드해 두는 방법도 좋다. ``HorizontalPager``의 ``beyondViewportPageCount`` 매개변수를 활용하면 현재 보이는 페이지 전후로 로드해 둘 페이지 수를 정할 수 있다. 현재 탭이 3개이므로, ``beyondViewportPageCount``에 2를 주면 된다.

@Composable
private fun FeatureTabItems(
    tabItems: Array<FeatureTabItem>,
    pagerState: PagerState,
    modifier: Modifier = Modifier,
) {
    HorizontalPager(
        state = pagerState,
        modifier = modifier,
        beyondViewportPageCount = tabItems.size - 1,
    ) {
        FeatureTab(
            item = tabItems[it],
            modifier = Modifier.fillMaxWidth(),
        )
    }
}

beyondViewportPageCount 적용 전

beyondViewportPageCount 적용 후. Overrun P95 0.0ms!

저사양 기기에서도 유효한 해결책인지?

20만원짜리 태블릿에서도 테스트를 돌려 봤다. 무려 갤럭시 A14급의 성능을 자랑하는 태블릿이다.

참고로 A14는 작년 출시된 갤럭시 보급형 기기 중 최하위급 모델이다. A04가 있긴 한데 이건 거의 장난감 수준이라.

Before

After

솔루션 적용 후 overrun P95 2.2ms 수준으로, 충분히 부드러운 화면을 보여줬다. 따라서 웬만한 저사양 기기에서도 유효한 해결책이라고 생각.

References

FrameTimingMetric | Android Developers

androidx.appsearch.builtintypes.properties

developer.android.com

UI jank detection | Android Studio | Android Developers

Learn about jank detection in Android Studio.

developer.android.com

Android Jank detection with FrameTimeline - Perfetto Tracing Docs

Actual Timeline These slices represent the actual time an app took to complete the frame (including GPU work) and send it to SurfaceFlinger for composition. The start time is the time that Choreographer#doFrame or AChoreographer_vsyncCallback started to ru

perfetto.dev

렌더링 되는 View의 내부를 살펴보자 | 찰스의 안드로이드

렌더링 되는 View의 내부를 살펴보자 더 나은 이해를 위해 이전 포스팅인 안드로이드 View가 렌더링 되는 과정을 먼저 참조할 수 있다. 렌더링하는 동안 사용되는 컴포넌트, 디스플레이 파이프 라

charlezz.com

안드로이드 프레임워크 프로그래밍(22) [SurfaceFlinger(시스템 서비스) 등록 및 초기화 과정]

※ 본 포스팅은 Android KitKat 4.4.4 를 기준으로 작성되었습니다. Kitkat 이전의 버전에서는 소스코드의 구조가 다름을 알립니다. 안드로이드 기반 디바이스에 있어 화면을 출력하는 데 가장 중요한

elecs.tistory.com

안드로이드 UI 안무가, Choreographer

CPU 프로파일링을 하다보면 Application Thread 에서 Choreographer#doFrame 함수가 호출되는 것을 볼 수 있다. 구글 문서상에는 아래와 같이 써져있었지만 이해하기 쉽지 않았다.

medium.com

전업 백수 탈출기 #2

해스끼 — Sun, 13 Oct 2024 21:03:27 +0900

#1에서 이어집니다.

두 번의 시험

1차면접은 평이했다. 쉬웠다는 말이 아니고, 언제나처럼 긴장 잔뜩 하고 버벅였다는 뜻이다.

그럼에도 불구하고 면접관 분들께서는 나를 한번 더 보고 싶으셨던 모양이다.

겉모습에 편견을 가지지 않았던 면접관 분들에게 작은 감사를 표하며, 최종 면접을 준비했다.

사실 최종 면접으로 갈 수록 준비할 게 없어진다. CS 벼락치기 정도는 할 수 있겠지만, 지금까지 살아온 인생은 바뀌지 않기 때문. 새로운 무기를 준비하기보단 지금 갖고 있는 것들로 어떻게든 싸우는 수밖에 없다.

특히 최종 면접은 더더욱 그런 것 같다. 경험을 통해 삶의 방향과 의도를 면접관에게 설명하는 것. 당연히 양보다 질이다.

7월 말, 최종 면접을 보러 남양연구소에 갔다. 갈수록 뜨거워지는 공기와 반대로 내 손은 점점 싸늘해지고 있었다. 긴장 1단계 증상이다.

이름답게 최종 면접은 지금까지 봤던 면접 중 제일 어려웠다. 기술적으로 어려운 걸 묻지는 않았지만, 팀 개발에서의 내 모습을 한 치의 모순도 없이 일관되게 전달해야 했다.

전혀 예상치 못한 질문이 이어졌다. 잘 대답한다면 오히려 나를 어필할 수 있는 질문이었지만, 그 때의 내가 제대로 대답했는지는 지금도 모르겠다.

면접 시간은 약 30분이었지만, 체감상 20분도 안 걸렸다. 전신에서 당분이 부족하다는 신호를 보내고 있었다. 야, 빨리 하리보 먹어.

면접장을 빠져나가는 나를 연구원들이 소풍 온 아이들 구경하듯이 바라봤다. 나도 같은 시선을 돌려줬다.

음… 지금 생각해 보면 회사 선배한테 너무 차갑게 대했나 싶기도 하다.

소원 있는 사람

블린더 모각코를 하기 위해 모였던 8월 9일, 하필 이날이 최종 결과 발표일이었다.

놀랍게도 발표 직후 홈페이지가 터졌다! 몇 분도 아니고 무려 3시간 가까이 결과를 확인할 수 없었다. 그 와중에 입사 안내문 문자는 제대로 발송되어 나를 혼란스럽게 했다.

홈페이지에서 확인하라면서요? 그럼 확인을 하게 해 주셔야죠?

전혀 일시적이지 않은데요…

모각코가 끝날 때까지 홈페이지는 복구되지 않았다. 결국 집에 돌아와서야 합격 메시지를 확인할 수 있었다.

전적은 20전 1승 19패. 어떻게 보면 세상에서 제일 관대한 시합이라고 볼 수도 있다. 수백 번 지더라도 한 번만 이기면 되니까.

자기 수준이 높아지더라도 시합 결과에 영향을 미치기 어렵다는 점만 감안하면, 도전할 만한 종목인 것 같다.

나도 10연패를 찍은 후에는 운의 존재를 받아들이고, 결과에 너무 일희일비하지 않으려 했다. 그러기엔 19패(삼성전자)의 충격이 너무 크긴 했지만…

아무 일 없었던 것처럼

지금은 현업 팀에 배치된 지 1달 정도 됐고, 멘토링을 막 시작한 단계이다. 팀 선배 분들께서 반갑게 맞아주신 덕분에 나름 즐겁게 생활하고 있다.

졸업 후 입사까지 정확히 6개월 4일 걸렸는데, 이 때의 기억이 무의식적으로 억눌리는 느낌이 든다. 내가 얼마나 힘들었는지 보여주는 간접적인 증거일까? 이 글도 조금만 더 늦었다면 마치지 못했을 것이다.

아직 취업준비를 하고 있는 친구들, 동기들을 만날 때마다 이야기한다. 너를 믿으라고. 믿을 수 있는 사람이 되라고. 그리고 실패를 당연히 여기라고. 취준생이 아니더라도, 미래를 만들어 가는 개척자로서 지녀야 할 태도라고 생각한다.

아님 말고… 나는 그렇게 살아갈 테니까.

전업 백수 탈출기 #1

해스끼 — Sun, 13 Oct 2024 21:00:25 +0900

2024년 8월 9일, 세 명의 젊은이들이 동대문 카페에 모여 각자의 문제와 씨름하고 있었다. 한 명은 생전 처음 보는 플랫폼과 사투를 벌이고 있었고, 다른 한 명은 스터디 준비에 열을 올리고 있었다.

마지막 한 명은 사소해 보이는 웹 사이트 에러에 진땀을 흘리고 있었다. 모순된 두 가지 메시지가 그를 괴롭히고 있었기 때문이다.

취업하고 싶습니다!

대학에 입학했을 때부터 진로는 취업이라고 거의 정해 놨다. 창업은 내 능력으론 절대 못 한다는 걸 알고 있었고(^^), 대학원 공부는 솔직히 하고 싶지 않았기 때문이다. 이론보다는 응용을 좋아하는 편이라.

첫 취업 활동은 2022년 카카오였다. 생애 첫 코딩테스트를 통과했던 좋은 기억과 함께, 생애 첫 면접을 완벽하게 망쳐버린 슬픈 기억이 아직까지도 선명하다. 면접관 분들이 제발 좀 천천히 말하라고 하셨던…

그 다음 해에 지원했던 네이버 채용도 완벽하게 동일한 과정을 거쳐 1차면접에서 탈락했다. 사실 이 때는 최종 합격보다는 내 상황을 점검해 보겠다는 목적이 강했고, 결과적으로 가장 큰 약점 하나를 찾긴 했다.

자신감 부족으로 인한 의사소통 능력 저하. 쉽게 말하면 쫄아서 말 더듬는 것.

그렇게 내 모습을 조금씩 알아가며, 4학년 2학기 취업 시즌을 맞았다.

서류도 쉽지 않다

안드로이드 개발을 하던 사람은 서비스 기업으로 가는 경우가 많지만, 나는 주로 대기업에 지원했다.

취준 초기에는 자기소개서 작성이 정말 어려웠다. 마지막 자기소개서가 고등학교 입학이었을 정도로 글을 통해 나를 소개해 본 경험도 없었고, 자기 PR을 별로 좋아하지 않기도 했다(지금도 그렇다).

A4용지 몇 쪽짜리 글이 아닌 진짜 내 모습을 봐줬으면 했지만, 이건 연애가 아닌 취업이기 때문에 어쩔 수 없었다.

글감 자체는 적지 않았다. 직무와 잘 어울리는 공모전(배리어프리)도 했고, 자신있게 내세울 수 있는 프로젝트 경험도 있고, 개발자의 사회적 역할 같은 인문학적 생각도 어느 정도 정리해 두었다. 그러나 이것들을 ‘회사’라는 접시에 담아내는 것이 제일 어려웠다.

처음에는 내가 지금까지 이러이러한 일을 했으니 나를 뽑아라! 라는 식으로 작성했다. 당연히 이런 자소서로는 합격할 수 없다. 5연속 서류 탈락한 후에 지금까지 썼던 자소서를 다시 읽어봤는데, 나조차도 나를 뽑고 싶지 않았다.

그래서 단순 정보성 글이 아닌, 회사가 나를 뽑아야 하는 이유를 제시하는 서류를 작성하기 위해 노력했다. 결과적으로 4학년 2학기 내내 글쓰기 연습만 한 셈이 됐다. 면접은 하나도 못 갔으니.

그래도 많이 쓰다 보면 늘긴 는다. 이 때 연습해둔 덕분에 졸업 후에는 서류에서 떨어지는 일은 별로 없었다.

고민

해가 바뀌고, 배리어프리 최종 발표와 졸업식을 마친 나는 완벽한 백수가 되었다. 유예를 할 수도 있었지만, 소속감이 생기면 스스로 안주하게 될 것 같아 일부러 졸업을 선택했다.

비자발적으로 늘어난 자유 시간에 비례하여, 소위 ‘쓸데없는 생각’도 급격하게 늘어났다(당시 나는 합격과 관련없는 모든 생각을 쓸데없는 생각으로 간주했다).

안드로이드 개발에 미래가 있나?

애초에 개발자라는 직업을 하고 싶긴 한가?

너는… 어떻게 살고 싶니?

25년 인생에서 처음 해 보는 고민이었다. 프로그래밍을 좋아하니까 컴공과에 왔고, 앱 개발을 좋아하니까 안드로이드를 공부했다. 그러나 취업 시장에서는 ‘왜 좋아하는지’ 말할 수 있어야 했다.

당연한 것들에 대한 의문이 이어졌다.

왜 프로그래밍을 좋아해?

왜 하필 안드로이드야?

우리가 왜 너를 뽑아야 해?

왜?

이 시기의 나는 대학 입학 이후로 코딩과 가장 멀어져 있었지만, 나 자신과는 가장 가까이 있었다. 전공 공부를 하며, 맹학교 근무를 하며, 프로젝트를 하며 가장 행복했던 순간과 불행했던 순간을 떠올렸다. 나도 몰랐던 마음의 한 구석을 더듬고, 문고리를 잡아당겼다. 문 너머에 내가 있었다.

삶의 이유를 찾자 일하고 싶은 이유는 자연스럽게 따라왔다. 적어도 나 스스로 나를 왜 뽑아야 하는지 납득할 수 있었다.

이제 남들을 설득할 시간이다.

해치웠나?

한창 내 마음 속을 파고 들어갈 때, 현실에서는 상반기 채용 시즌이 시작됐다. 학교도 졸업했겠다, 시간도 많으니 제대로 써 보기로 했는데…

하라는 취업은 안 하고 사고만 잔뜩 쳤다. 인성검사 시간을 까먹어서 떨어지기도 하고, 사전점검에 참여하지 않아서 코딩테스트 응시를 거부당하기도 했다. 100% 실화다. 초딩 때 1개월마다 교통카드 잃어버리던 재능이 어디 안 간다.

뭐… 그런 우여곡절 끝에 삼성전자 면접 응시 기회를 얻었다.

삼성전자는 3종류의 면접을 하루에 모두 본다. 임원면접, 직무면접, 창의면접 각각 30분 정도 보는데, 듣기로는 임원면접과 직무면접의 영향이 크다고 한다.

2024년 첫 최종면접 응시였는데, 생각보다 대답을 잘 했다(고 생각했다). 임원면접에서 면접관 분들이 내가 어필하고 싶은 것 위주로 물어보셨고, 반응도 괜찮았다. 평소와 달리 말을 더듬지 않고 차분하게 말했던 것이 결정적이었다.

면접을 끝내고, 서울행 광역버스를 타며 조심스럽게 불경한 생각을 품었다.

나, 붙을지도…?

불경한 생각은 점차 나를 지배하기 시작했고, 발표 즈음에는 수원 자취방까지 알아봤을 정도로 나는 확신에 차 있었다.

지루한 나날 끝에, 확신이 현실로 바뀔 그날이 왔다.

되겠냐

아침에도 덥다고 느낄 만한 날이 늘어나고 있었다.

6월 중순 어느 여름날, 버스정류장에서 습관처럼 채용 사이트를 열어본 나에게 몇 개의 문장이 다가왔다.

…지원해 주셔서 감사하며… 면밀히 검토하였으나… 아쉽게도…

의례적인 탈락 문구가 이어졌지만 기억나지 않는다. 잠시 세상과의 연결이 끊겼다. 기사 아저씨의 빨리 타라는 목소리에 겨우 몸을 움직였지만, 자리에 앉는 것 이상의 의식적인 헹동을 할 수 없었다.

그저 수많은 물음표가 트리처럼 뻗어나갔다. 어제는 수원 자취방까지 알아봤는데…

10년 만에 눈물이 나온 날이었다. 1년 간 다니던 피아노 학원을 그만두고 오는 길이었는데, 플레이리스트의 어떤 곡 때문에...

음악인에게는 너무나도 슬픈 가사다. 꼭 들어보길.

소원 없는 사람

얘, 세상이 어디 맘대로 되는 줄 아니? 이제 주제를 좀 알려무나.

내 주제가 뭘까… 쌩신입 주제에 대기업만 노리면 주제넘는 건가?

아무도 답해주지 않는 고민을 품고 현대자동차 6월 신입에 지원했다. 여기도 떨어지면 정말 아무 데나 들어가겠다는 마음으로.

서류 합격 정도로는 어떤 기쁨도 느껴지지 않았다. 그 때의 나는 거의 감정 없는 인간이었다. 기껏해야 면접 또 떨어지겠네… 를 중얼거리며 면접 준비를 할 뿐이었다.

#2에서 이어집니다.

[Android Fundamentals] Activity - 9. Parcelables and bundles

해스끼 — Wed, 7 Aug 2024 15:11:44 +0900

``Parcealble``과 ``Bundle``을 사용하면 프로세스 내/외부에 데이터를 전달할 수 있다. 이 글에서는 ``Parceable``과 ``Bundle``을 사용하는 best practices를 알아보자.

Activity 간 데이터 전송

Activity는 ``Intent``를 통해 시작할 수 있다. 이때 ``Intent.putExtra()``를 활용하면 activity에 데이터를 보낼 수 있다.

Intent(context, MainActivity::class.java).apply {
    putExtra("some key", "some data",)
}

넣을 수 있는 데이터는 Java primitive 타입과 String, 이 타입들의 array, 그리고 ``Bundle``이다.

많다

``Intent``에 추가된 extra 데이터는 OS가 ``Bundle`` 형태로 포장하고, 새 activity가 생성되면 포장을 풀어 activity에 전달한다.

보내고 싶은 데이터가 복잡한 경우에는 ``Parceable`` Parcel에 write하는 로직과 Parcel로부터 데이터를 read하는 로직을 직접 구현해야 한다. 자세한 내용은 ``Parcelable`` 문서에서 확인할 수 있다.

다만 intent를 통해 보낼 수 있는 데이터는 몇 KB 정도여야 한다. 데이터가 너무 크면 ``TranscationTooLargeException``이 발생한다.

프로세스 간 데이터 전송

Activity 전송과 비슷하다. 하지만 커스텀 parceable을 보내는 것은 권장되지 않는다. 커스텀 parceable을 다른 앱에 보내는 경우, 데이터를 보내는 앱과 받는 앱이 동일한 형태의 parceable을 알고 있어야 한다. 같은 라이브러리에 의존하면 되긴 한다.

하지만 수신 측이 모르는 parceable을 보내면, 수신 측에서 parceable을 포장 해제할 수 없으므로 에러가 발생한다.

예를 들어 ``AlarmManager``로 알람을 설정할 때, intent에 커스텀 parceable을 넣었다고 해 보자. 알람이 작동할 때 시스템은 알람 반복 횟수를 bundle에 추가하는데, 이때 커스텀 parceable이 없어질 수 있다. 그런데 앱은 intent가 시스템에 의해 수정됐다는 사실을 알지 못하기 때문에 원본 그대로의 커스텀 parceable을 얻으려 한다. 이 과정에서 크래시가 발생할 수 있다.

Binder transaction 버퍼의 크기는 대략 1MB 정도이다. 버퍼는 프로세스 단위로 공유되고, 다른 activity에서 저장한 instance state나 시스템과의 모든 상호작용 정보가 버퍼에 저장된다. 따라서 너무 큰 데이터를 저장하면 TransactionTooLargeException이 발생할 수 있다.

참고로 ``savedInstanceState``에는 데이터를 최소한으로 저장하는 것이 좋다. 사용자가 activity에 돌아올 때까지 state를 보존하고 있어야 하기 때문.

참고자료

Parcelable 및 번들 | Android Developers

Parcelable 및 번들은 IPC/바인더 트랜잭션과 같은 프로세스 경계 전반에서 인텐트가 있는 활동 간에 사용하고 구성 변경 시 일시적인 상태를 저장하기 위한 것입니다.

developer.android.com

[Android Fundamentals] Activity - 8. 프로세스와 앱 생명주기

해스끼 — Wed, 7 Aug 2024 14:22:38 +0900

모든 안드로이드 앱은 개별 리눅스 프로세스에서 실행된다. 앱이 실행되는 프로세스는 시스템에 의해 회수되기 전까지 계속 실행된다.

즉 프로세스의 생명주기를 앱이 아닌 시스템이 제어한다는 것. 프로세스 생명주기는 앱의 실행 여부, 사용자에게의 중요도, 메모리 상황 등 시스템의 많은 부분을 종합적으로 고려하여 결정된다.

따라서 우리 개발자들은 ``Activity``, ``Service``, ``BroadcastReceiver`` 등의 컴포넌트가 프로세스 생명주기에 어떻게 영향을 미치는 지 알아야 한다. 컴포넌트를 정확히 이해하지 못하면 중요한 로직이 실행되지 않을 수도 있고, 로직이 실행되는 도중에 프로세스가 종료될 수도 있다.

예를 들어 ``BroadcastReceiver``에서 ``Intent``를 받은 후 스레드를 생성했다고 해 보자. ``BroadcastReceiver``는 ``onReceive()``가 종료된 후에는 실행이 종료된 것으로 간주되므로 프로세스가 언제든지 종료될 수 있다. 리시버 프로세스가 종료되면 스레드까지 함께 종료되므로 스레드의 작업이 실행되지 않을 수 있다.

이 경우에는 스레드를 만드는 대신 ``JobService``나 ``WorkManager``를 활용해야 한다.

메모리가 부족할 때에는 우선순위가 낮은 프로세스부터 종료된다. 우선순위가 높은 순서대로 살펴보면 다음과 같다.

포그라운드 프로세스

포그라운드 프로세스는 사용자의 현재 작업에 필요한 프로세스를 의미한다. 컴포넌트마다 포그라운드로 간주되는 조건이 모두 다르다.

``Activity``: 사용자와 상호작용하고 있는 activity (resumed 상태의 activity)
``BroadcastReceiver``: ``onReceive()`` 함수가 실행 중인 리시버
``Service``: 콜백을 실행 중인 서비스 (``onCreate()``, ``onStart()``, ``onDestroy()``)

전체 프로세스 중 포그라운드로 간주되는 프로세스는 매우 적고, 포그라운드조차 실행되지 못할 정도로 메모리가 부족한 상황이 아니라면 종료되지 않는다.

솔직히 그 정도로 메모리가 부족하다면 기기나 내 코드 중 하나가 잘못됐을 가능성이 높다.

사용자에게 보이는(visible) 프로세스

사용자가 인식할 수 있는 작업을 수행하는 프로세스이다.

``Activity``: 사용자에게 보이지만, 직접 상호작용하지는 않는 activity이다. 즉 paused 상태에 있는 activity라고 볼 수 있다. 다른 activity에 의해 부분적으로 가려진 activity 등이 해당된다.
``Service``: ``Service.startForeground()``로 실행한 포그라운드 서비스
사용자가 인식할 수 있는 서비스를 실행 중인 프로세스도 해당된다. 라이브 배경화면 등.

Visible 프로세스는 포그라운드 프로세스보단 많지만 전체 프로세스 중에서는 몇개 안 된다. 따라서 포그라운드 프로세스를 위해 메모리를 확보하는 경우가 아니라면 종료되지 않는다.

서비스 프로세스

서비스 프로세스는 ``startService()``로 실행된 ``Service``를 실행하는 프로세스이다. 사용자에게 직접 보이는 건 아니지만, 어쨌든 사용자에게 필요한 작업을 수행하는 프로세스이므로 나름 중요하게 다뤄진다.

단, 너무 오래 실행되는 ``Service``는 ``캐시된 프로세스``로 한 단계 강등될 수 있다. 30분 이상 실행된다던가...

오랫동안 실행되어야 하는 프로세스는 ``CoroutineWorker.setForeground()``로 실행할 수 있다. 프로세스가 정확한 시각에 실행되어야 한다면 ``AlarmManager``를 사용할 수 있다.

캐시된 프로세스

캐시된 프로세스는 당장 필요하지 않고, 따라서 시스템이 자유롭게 종료할 수 있는 프로세스를 말한다. 일반적인 상황에서는 캐시된 프로세스만이 종료된다.

시스템이 정상 상태라면 ``캐시된 프로세스``가 항상 여러 개 존재하고, 작업 상황을 고려하여 몇몇 캐시된 프로세스가 종료된다. 시스템이 극한 상황까지 가지 않는 이상 캐시된 프로세스가 모두 종료되지는 않는다.

이 상태에 있는 프로세스는 모든 작업을 중단하는 것이 좋다. 언제든지 종료될 수 있기 때문. 뭔가 작업을 하고 싶다면 위에서 설명한 방법들을 활용하자.

Stopped 상태의 ``Activity``도 캐시된 프로세스로 간주된다. 생명주기를 잘 지키는 앱이라면, stopped 상태의 activity가 종료되더라도 UX에 부정적인 영향이 없어야 한다. Activity가 종료될 때의 상태는 ``onCreate``에서 ``savedInstanceState``를 통해 복구할 수 있다.

단, 시스템이 activity를 종료할 때에는 ``onDestroy()``가 실행되지 않을 수도 있음에 주의.

캐시된 프로세스는 리스트로 관리되고, 리스트의 순서는 플랫폼에 따라 다르게 구현된다. 제조사마다, 안드 버전마다 다를 수 있다.

일반적으로는 홈 UI나 직전에 본 activity 등 사용자에게 중요한 의미를 갖는 프로세스의 우선순위가 높게 매겨진다. 물론 다른 알고리즘이 적용될 수도 있다. 캐시 상태가 너무 오래 지속되면 아예 종료한다던가.

정리

프로세스의 중요도는 프로세스에서 실행되는 컴포넌트 중 중요도가 가장 높은 컴포넌트의 중요도와 같다. 또, 프로세스 간 의존성에도 영향을 받는다.

예를 들어 프로세스 A가 ``Context.BIND_AUTO_CREATE`` 플래그를 설정한 ``Service``를 실행하거나 프로세스 B의 ``ContentProvider``를 참조하고 있다면, 프로세스 B의 중요도는 A보다 낮지 않다.

결론: 생명주기가 중요하다! Jetpack이나 컴포넌트를 사용할 때 생명주기를 잘 관리하자.

참고자료

프로세스 및 앱 수명 주기 | Android Developers

대부분의 경우 모든 Android 애플리케이션은 자체 Linux 프로세스에서 실행됩니다. 이 프로세스는 일부 코드를 실행해야 할 때 애플리케이션용으로 생성되며 더 이상 필요하지 않고 시스템에서 메

developer.android.com