hrniin의 개발 노트

2025년 회고 - 인생사 새옹지마

hrniin — Sat, 10 Jan 2026 16:36:00 +0900

https://youtu.be/KsRhciAW5ao?si=xOepuHAd5vftljHy

올해는 크고 작은 변화들이 쉴틈없이 이어졌던 한 해였다. 매년 새로운 목표를 세웠었지만 2025년에는 잘 지키지 못할 거창하고 상세한 목표보다 하루하루를 잘 살아내는 것을 목표로 했다. 다만 취업이라는 유일한 목표를 세웠는데, 운이 좋게도 목표를 잘 이뤄냈고 아직 새로운 환경에서 정신없이 적응중이다.

구체적인 목표를 세우지 않았더라도, 어김없이 내가 사랑하는 회고를 해보자!

요즘 글쓰기 능력이 떨어진 것 같아 이번 회고만큼은 지피티의 도움 없이 회고를 써보려 한다. 정제되지 않은 TMI들이 난무하니 주의바란다. ^^

1월~9월: 취업 준비 기간

올해는 취업 준비로 정신없이 달려왔다. 첫 직장은 대기업에 가고 싶다는 욕심이 있었기 때문에 초반에는 대기업만 지원했다. 그러나 10%의 서류 합격률을 맛보며 이대로 가다간 올해 안에 취업은커녕 면접조차 제대로 못 볼 것 같다는 압박감이 다가왔다. 또한 나중에 정말 원하는 기업의 면접을 보게 될 때, 면접에 익숙해진 상태가 되고 싶었다. 그 이후로 대충 직무와 지역만 맞으면 무작정 다 지원했다. 한달에 면접을 10번 가까이 볼 정도로 바쁘게 살았다.

지치지 않게 도와준 우리집 오디

오디는 우아한테크코스에서 했던 팀 프로젝트다. 수료 후에도 몇몇 크루들과 프로젝트를 계속 유지했다. 프로젝트를 유지하는 각자의 이유가 있었지만, 나는 오로지 ”이력서 소재“를 위함이었다. View 기반 코드를 Compose로 마이그레이션 하고, 복잡한 코드를 단순화하고, 분산되어 있던 비즈니스 로직을 Usecase로 통일했다. 모든게 취업을 위한 것이었지만, CS/자소서/면접 준비에 지칠 때마다 도망칠 수 있는 안식처이기도 했다. 계속되는 취준에 지쳐 내가 왜 개발자가 되고싶은지 의문이 들 때면, 코드를 개선하는 과정에서 개발에 다시금 흥미를 느끼곤 했다. 결과적으로도 포트폴리오에 개선 경험을 잘 녹여내어 면접에서도 강점으로 활용할 수 있었다.

내 인생 최악의 시기

다른 기업에 잘 다니고 있는 지금 얘기하기엔 좀 웃기지만 2025년 나에게 꽤나 큰 이슈는 네이버 공채였다. 3개월이라는 긴 시간동안 채용이 진행되기도 했고, 정말 가고 싶은 기업이었기 때문에 최선을 다해 준비했다. 결과적으로는 최종 면접에서 탈락했고, 최선을 다한만큼 탈락했을 때 타격이 컸었다. 온전히 회복하는데까지 1~2일의 시간이 걸린 것 같다.
당시에는 스트레스를 많이 받았기에 '차라리 서류부터 떨어졌으면 기대도 안했을텐데'라는 생각을 했다. 하지만 나중에 돌이켜보니, 간절함을 가지고 최선을 다하는 과정에서 얻은 것들이 정말 많았다. 이때의 경험이 기반이 되어 다른 면접을 더 수월하게 임할 수 있었고, 국내 최대 IT기업의 문턱까지 가보며 개발자로서 자신감이 붙기도 했다.

이때쯤 <한 기업에 최선을 다하고 집중하는 것>와 <정신건강을 위해 한 기업에만 올인하지 않는 것> 두 선택지 사이를 고민했었다. 한 기업에 너무 집중한 결과, 스스로를 혹사시키고 있다는 생각이 들었기 때문이다. 그치만 내 성향상.. 몸과 마음이 잠시동안 망가지더라도 과정에 후회가 없도록 최선을 다해보자는 결론을 내렸고, 현재 재직 중인 회사에 합격한 것도 이 결정 덕분이라고 생각한다.

약 10개월 정도 취준을 했다. 취준 기간이 길어지면서 "남들 다 하는 건데 왜 나만 이렇게 어렵지?"(아님)라는 생각이 들며 자존감도 낮아졌다. 좋아하는 우테코 동기들도 만나지 않고, 동기들이 컨퍼런스를 가자고 해도 가지 않았다. 가끔 친구들을 만나도 자신감이 떨어져서 온전히 즐기지 못했다. 미래가 불확실하다는 압박감이 너무나도 크게 다가와서 불면증, 위궤양까지 겪었다.

파도 위에서 균형을 찾는 사람

이대로 가다가는 장기적으로 건강한 취준을 할 수 없겠다는 생각이 들어, 의식적으로 나를 위한 하루를 보내기 시작했다. 하루동안은 노트북을 펼치지 않고, 일찍 일어나 장을 보러 나갔다. 스스로를 위해 좋아하는 음식을 정성스레 만들었고, 방을 깨끗히 청소하며 복잡한 마음도 다잡으려 노력했다. 천천히 다이어리를 쓰면서 내 감정을 들여다봤다.

취준에 몰입하다 보면 시간적/금전적/심리적 여유가 줄어들어서, 좋아하는 취미나 여가를 온전히 즐기지 못할 때가 많다. 그러다 보면 '취업만 하면 하고 싶은 걸 마음껏 할 수 있겠지'라는 생각을 하게 되고, 자연스레 행복을 미래로 계속 유예하게 된다. 하지만 미래에도 또 다른 어려움이 있을 것이고, 그렇게 미래만 바라보다 보면 지금의 나를 잃어버릴 것 같았다. 의식적으로 나를 돌보는 하루를 보내며, 현재를 온전히 받아들이고 즐기는 사람이 되려 했다.

수많은 실패와 단 한 번의 합격

긴 노력 끝에, 운이 좋게도 내가 원하는 조건의 기업에 합격할 수 있었다. 취준 기간이 길어지다보니 처음엔 믿기지 않았다.. (사실 아직도 가끔 신기하다) 합격하고보니, 밀도 있는 면접을 위해서는 내가 어떤 사람인지 잘 아는게 첫번째라고 느꼈다. 내가 뭘 알고 뭘 모르는지, 왜 이런 생각을 가지고 있는지를 깊이 회고한 후에야 내가 원하는 면접의 흐름을 가져갈 수 있었다.

가끔 '이걸 좀 더 일찍 일었더라면 더 빨리 취업할 수 있었을까?' 라는 생각이 들지만, 오히려 조금 늦게 알았기 때문에 현재의 회사에 합격할 수 있었던 것 같다. 지금 회사가 나한테 너무 잘 맞아서, 늦게 깨닫게 된게 참 다행이다.

인생사 새옹지마

최종 합격 이후 일상 블로그에 회고를 남긴 적이 있다. (회고에 대한 광기 ㄷㄷ) 회고를 쓰기 위해 노트북을 켜자마자 가장 먼저 떠오른 단어가 바로 '새옹지마'였다. 인생의 행복과 불행은 예측하기 어렵다는 뜻이다. 그렇기에 잠시 뒤처지는 사람이 기죽을 필요도 없고, 앞서가는 사람이 자만할 이유도 없다. 취준 기간 내내 이 말이 머릿속에 오래 남았다.

스스로 채워가는 일상들

취업 이후 완전히 새로운 일상을 살아가고 있다. 일단 네 번째 자취를 시작했다. 이전에는 학교, 인턴, 부트캠프 때문에 짧게만 자취를 했었는데, 이제는 본가에서 완전히 독립한 느낌이 들어서 왠지 기분이 이상하다.

취준 기간 동안 잃어버렸던 취미들도 다시 되찾고 있다. 동기들과 밴드 합주를 하거나 공연을 보러 다니고, 난생 처음 필라테스에 등록해서 일주일에 한번씩 공사장 소리도 내보고 있다. (ㅋㅋ;;)

일하는게 즐겁다. 업무량이 많은 회사라 야근을 밥먹듯이 하고 있다. 그런데도 힘들다기보다 몰입의 즐거움을 느끼고 있다. 일단은 내가 원하는 환경에서 자유롭게 근무할 수 있다는 점이 크고, 그냥 나는 개발 자체가 즐겁다.

인턴 때 제대로 적응하지 못한 적이 있었어서, 이번에도 걱정을 했었다. 다행히도 편안해보여서 경력직인 줄 알았다는 얘기도 많이 들을 정도로 잘 적응하고 있다. 운이 좋게도 너무 좋은 동료들을 만난 덕분이다. 사실 팀에는 잘 적응했지만 업무에 충분히 적응했는지는 잘 모르겠다. 이 부분은 앞으로의 숙제가 될 것 같다.

좋은 개발자로서의 마인드셋

좋은 개발자는 어떤 사람일까? 좋은 개발자가 되기 위해서는 어떤 노력을 해야할까? 입사 후 혼자 많이 고민해본 주제다.

자신이 알고있는 기술에만 얽매이지 않고, 상황에 따라 유연하게 대처하는 사람
겪은 어려움이나 실수를 숨기지 않고 빠르게 공유하는 사람
제품 전반에 대한 이해를 가지고 놓친 부분을 빠르게 짚어내는 사람

내가 생각했을 때는 위와 같은 것들이 있겠다. 아직 전반적으로 부족한 점이 많지만 제품에 대한 것들이 가장 어렵다. 특히 현재 회사는 개발자가 제품에 대한 의견을 적극적으로 낼 수 있는 환경인데, 그 환경을 제대로 활용하고 있지 못한 것 같아 마음 한구석이 늘 불편했다. 챕터 리드분께서 팀 적응 이후 자연스럽게 따라올 것이라 말씀해주셔서 마음의 짐을 조금은 덜 수 있었지만, 여전히 항상 작은 고민으로 남아있다.

2026년에 이루고 싶은 것들

업무에 적응하기

입사한 지 두 달밖에 되지 않은 신입 개발자로서, 아직은 모든 것이 낯설다. 입사하자마자 피쳐 개발을 정신없이 하고있지만, 개발자에게는 개발만이 다가 아니라는 걸 매일 실감하고 있다. 아직은 제품에 대한 이해가 높지 않고, 다른 팀과의 의존성도 명확히 파악하지 못했다. 이러한 이유들로 아무 의견을 내지 못하고 회의가 끝날 때, 그렇게 기죽을 수가 없다. 일단은 사일로에, 챕터에, 커뮤니티에 더더욱 적응하는 게 가장 첫번째 목표겠다.

개발 컨퍼런스 발표

나는 개발자로서 욕심이 크다. 내가 멋지다고 생각하는 개발자들이 하는 일들은 다 해보고 싶다. 그 중 하나가 컨퍼런스에서 발표하기다. 발표를 통해 내가 멋지고 대단한 사람이라는 걸 알리고 싶다. 내가 정말 멋진 사람이 아니더라도, 발표를 하다보면 멋진 사람이 되어있을 것이라 믿는다.

나에게 관대해지기

나는 욕심이 큰 만큼, 나에 대한 기준이 높다. 스스로에게 당근보다는 채찍을 더 많이 주는 편이다. 입사 한 달 차에 팀원들과 커피챗을 하며 모두가 칭찬을 해주었는데, 감사함과 동시에 "내가 정말 그런가? 아직 부족한데.."라는 생각이 들었다. 부족하더라도 나에게 당근을 주는 습관을 들여보자. 토스는 빠르게 흘러가는 만큼 완벽보다는 속도를 중요시 여기고, 실수하더라도 빠르게 공유하고 해결하면 된다.

나만의 강점 찾기

모두가 각자만의 강점이 있다. 개발 역량뿐만 아니라 커뮤니케이션, 꼼꼼함, 사용자 경험 등등.. 그런데 아직은 내 강점이 어떤 건지 잘 모르겠다. 내가 일하는 방식을 조금 더 잘 이해하고, 그 안에서 내 강점을 살려서 더 잘 일할 수 있는 방식을 찾아가보고 싶다.

AI 잘 활용하기

내 주변에 AI를 잘 활용하는 동료들이 많다. 반면에 나는 개발 시에 로직이 헷갈릴 때 가볍게 참고하는 정도다. (아직은 코드를 완전히 이해하며 업무하고 싶다는 욕심도 있다) 팀원들과 AI를 주제로 얘기를 나눌때가 종종 있는데, 그럴 때마다 나는 잘 활용하지 않는다는 대답을 했고 왠지 모르게 시대에 뒤처져있다는 생각이 들어 부끄러웠다. 이제는 AI에 대한 거리감을 줄이고 업무 효율을 높이기 위해 더 적극적으로 활용해보려고 한다.

체력 증진

야근이 잦은 만큼 체력 관리가 필수라는 것을 느끼고 있다. 아직은 주 1회 정도로 가볍게 운동하고 있지만, 앞으로는 나와 잘 맞는 운동 패턴을 찾아 습관화해야겠다. 표준까진 아니더라도 표준에 근접할 때까지 근육량을 늘리는게 목표다.

기술 블로그 업로드

아직은 기술 부채를 해결한다거나 복잡한 아키텍처를 개선하는 등의 거창한 일을 해보지는 않았다. 남들이 다 할 수 있는 피쳐 개발이 아닌, 조금 더 복잡한 문제를 해결해 보고 그 과정을 기술 블로그로 담아보고 싶다.

기록하기

어떤 업무를 했는지, 업무하며 배운 제품 정책, 사소한 인사이트까지 꾸준히 기록하고 싶다. 바쁘게 살다보면 어떻게 하루가 흘러갔는지 모를때가 있다. 아무런 긴장감 없이 기계처럼 이슈를 쳐내기 보다는 바쁘더라도 학습을 놓지않는 사람이 되고 싶다.

쉽게만 살아가면 재미없어 빙고!

나이먹기 싫다고 투정하긴 했지만 사실 27살이 되는 2026년이 기대된다. 처음으로 개발자로서 온전히 채워가는 한 해가 될테고 그 과정 속에서 나만의 색깔을 찾아갈 것이다. 내가 바랐던 안정적인 삶 속에서 원하는 방향대로 나아가는 삶이 너무 즐겁다.

물론 내 기대만큼 멋진 삶이 아닐 수 있다. 하지만 어려움이 와도 결국 이겨낼 것이고 그 속에서 깨닫는게 분명 있을 것이다. 예측대로 흘러가지 않기에 재밌는 인생이라는 걸 느끼는 요즘이다. 평탄하진 않더라도 어려움 속에서 많이 성장하는 해가 되길 바란다.

토스 NEXT 2025 Android Developer 합격 후기

hrniin — Mon, 29 Sep 2025 00:13:29 +0900

들어가며

약 1년 째 이어지던 취업 준비 끝에, 드디어 토스에 합격하게 되었다.

8월 초에 NEXT 개발자 챌린지에 지원했고, 9월 말에 오퍼 레터를 받았다.

안드로이드 NEXT 후기가 거의 없어서 ㅎ 채용 과정에서의 준비 과정과 후기를 정리해 보려 한다.

일정

과제 테스트 > 온라인 과제 테스트 > 직무 인터뷰 > 문화적합성 인터뷰 > 레퍼런스 체크 및 처우 협의 > 입사일 조율 및 입사

서류

주변 지인들과 얘기를 나누며 토스의 문화에 대해서는 어느 정도 알고 있었다.

가서 잘 할 수 있을지 고민도 되었지만, 주도적으로 문제를 해결해 나간다는 점에서 빠르게 성장할 수 있을 거라 확신했다.

나는 초기 커리어를 단단히 쌓고, 다양한 경험을 통해 시야를 넓히고 싶다는 목표를 가지고 있었기에 토스에 지원하게 되었다.

토스는 자기소개를 따로 작성하지 않고, 이력서만 제출하면 된다.

포트폴리오는 선택사항이지만, 나는 포트폴리오도 함께 제출했다.

이력서는 pdf 4장 분량이었고, 아래와 같은 사항들을 간략히 정리했다.

간단한 자기소개 - 관심 분야, 강점 등
경력, 학력, 외부 경험, 자격증
사용 가능한 기술 스택
프로젝트 - 소개, 기술 스택, 기여한 부분

포트폴리오는 pdf 23장 분량이었다.

이력서에 많은 정보를 담게 되면 읽는 입장에서 흥미가 떨어질 것이라 판단했고,

대신 포트폴리오에서 내 강점들을 자세히 어필하려 노력했다.

이력서는 기본사항을 위주로 작성했다면, 포트폴리오에는 "어떻게 문제를 해결해나가는 사람인지"에 집중했다.

예를 들어 기술은 어느정도까지 알고 있는지, 프로젝트에서 어떤 문제를 어떻게 해결했는지, 우아한테크코스를 통해 어떤 걸 배웠는지, 내 협업 방식은 어떤지 등등..

당연한 얘기를 길게 늘어놓기보다는, 나만의 얘기를 만들어나가려 노력했다.

정량적인 스펙을 말하자면 지방대 컴공 수석졸업, 우아한테크코스 수료, 대기업 인턴, 현장실습, 정보처리기사 정도다. (어학, 수상X)

그렇지만 대부분의 IT기업이 그렇듯, 개발자는 스펙보다 실력이 훨씬 중요하다고 생각한다.

(스펙을 중요시했다면 지방대 나온 내가 토스에 붙지 않았을 것이다..)

온라인 과제 테스트

8월 7일까지 서류 접수를 받고, 8월 9일에 바로 과제 테스트가 진행되었다.

프로그래머스에서 2시간 동안 객관식 34문제, 서술형 7문제를 풀어야 했다.

준비 방법

서류 마감 이후 바로 테스트가 진행되었기 때문에, 크게 준비를 하진 않았다.

면접 대비용으로 안드로이드 개념들을 정리해둔 노션 페이지가 있는데, 테스트 전날 가볍게 훑어보았다.

후기

전반적으로 적당한 난이도라고 느껴졌다.

객관식은 안드로이드 심화적인 개념 위주의 문제였다.

완전히 처음 보는 개념의 문제가 3~4개 정도 있었는데, 문제를 꼼꼼히 읽으면서 답을 유추해나갔고 대부분 맞혔다고 생각한다.

서술형은 앱을 구현하며 실제로 겪을 만한 문제들이 나와있어서 재밌었다.

대부분 무난하게 작성할 수 있었지만, 1~2문제는 고민을 좀 하게 되었다.

어렵더라도 합리적인 근거를 기반으로 납득할 수 있게끔 작성하려 노력했다.

평소 자신의 코드에 의문을 가지고, 코드를 한 줄 한 줄 이해하면서 앱을 구현해봤다면 충분히 답을 작성할 수 있을 것이다.

최선을 다해 테스트를 응시한 결과, 테스트 3일 뒤인 8월 12일에 합격 메일을 받을 수 있었다!

서술형에서 더 좋은 답을 작성하지 못한 게 마음에 걸렸는데, 구체적인 근거와 함께 내 생각을 작성한 점을 좋게 봐주신 것 같다.

직무 인터뷰

직무 인터뷰는 9월 초에 온라인으로 진행되었다. (지원자마다 일정은 상이)

안드로이드 직군은 인터뷰 전에 사전 과제를 진행한다.

사전 과제를 60분 동안 구현한 뒤, 짧은 휴식 시간을 가지고 약 60분 동안 인터뷰가 진행되었다.

준비 방법

가장 먼저 토스 면접 후기를 찾아보며 전반적인 면접 진행 방식을 파악했다.

또한 토스 채용 홈페이지에 게시된 인터뷰 관련 아티클이 많은 도움이 되었다.

(아티클 링크: https://toss.im/career/article/server_developer_interview, https://toss.im/career/article/next-25-frontend)

이렇게 면접 방식을 살펴본 결과, 공통적으로 강조되는 점이 하나 있다. 바로 "왜?"에 집중한다는 것이다.

예를 들어 프로젝트에 어떤 기술을 사용했다고 했을 때, 합리적인 근거와 맥락에 기반하여 선택했는지를 묻는다.

그래서 면접 준비를 하는 과정에서도 "왜?"에 집중하며 예상 질문을 뽑았다.

제출한 이력서와 포트폴리오를 보면서, 사용한 기술이나 문제 해결 방식에 대해 "왜 이런 판단을 내렸는지"를 꼼꼼히 되짚고 정리하는 시간을 가졌다.

이후에는 정리했던 내용들을 계속 들여다보며 면접에서 자연스럽게 얘기할 수 있도록 연습했다.

사전 과제 후기

처음 요구사항을 받았을 때는 엄청 당황했지만, 침착하게 다시 읽어보니 감이 잡혔다.

안드로이드를 어느정도 다뤄봤다면 충분히 구현할 수 있는 정도라고 생각한다.

하지만 1시간 안에 프로젝트 셋팅부터 구현까지 완료하기엔 시간이 매우 부족했다.

코드가 정리되지 않은 상태로 약 60% 정도 구현을 마치고 과제를 제출하게 되었다.

그럼에도 내가 익숙한 방식으로 구현하는 습관이 있기 때문에, 아키텍처나 기술 스택들은 신경써가며 구현했다.

면접 후기

안드로이드 개발자 세 분과 함께 진행되었다.

면접 초반에는 과제를 기반으로 진행되고, 후반에는 이력서/포트폴리오를 기반으로 진행되었다.

과제 기반 면접에서는 과제 코드를 함께 보면서 "어떤 의도로 이 코드를 작성했는지"를 위주로 말씀드렸다.

또한 면접관님과 함께 의견을 주고받으며 과제 코드를 실시간으로 개선해나갔는데, 이 과정이 굉장히 재미있었다.

평소에 자신이 작성하는 코드에 대해 깊이 이해하는 것이 중요하다고 느꼈다.

이력서 기반 면접은 그동안 봤던 직무 면접과 비슷한 방식으로 진행되었다.

개발할 때 선호하는 방식, 어려웠던 문제 해결 경험 등을 얘기했고, 답변에 대한 꼬리질문을 이어갔다.

이력서 기반으로 면접을 준비해왔기 때문에 대부분의 질문에 잘 대답할 수 있었다.

물론 잘 모르는 부분들도 많았다.

그치만 바로 포기하지 않고, 힌트를 요청하거나 현재 고민하고 있는 지점들을 말씀드렸다.

이 과정에서 정답을 도출하기도 했고, 감이 안 잡혀 대답을 전혀 못하기도 했다.

면접관 세 분 모두 정말 친절하셨고 편안하게 대답할 수 있도록 노력해주셔서 감사했다.

기술 질문에 대한 대답을 하면 "너무 잘 대답해 주셨네요~"라고 ㅋㅋㅋ 해주셔서
'아! 나 잘 대답했구나!'라고 안심할 수 있었고 덕분에 편하게 얘기할 수 있었다.

면접 분위기도 좋았고 왠지 느낌이 좋았지만, 기대하지 않으려 했다.

분위기가 좋았던 건 내가 잘해서가 아니라 면접관님들이 친절해서일 수 있기 때문에... ㅋㅋ

면접을 보고 딱 일주일 후 합격 메일을 받을 수 있었다!

문화적합성 인터뷰

9월 중순 온라인으로 약 1시간 동안 진행되었다.

준비 과정

가장 먼저 토스 홈페이지의 문화 관련 글과 토스 유튜브의 문화 관련 영상을 하나도 빠짐없이 시청했다.

이 과정에서 면접에 도움될 만한 것들을 따로 정리해두었다.

토스에 대해 공부하면서, 토스에 가고 싶은 마음이 더 커졌던 것 같다.

모든 팀원들이 스스로 의사결정을 하며 즐겁게 일하는 회사가 정말 존재한다니! 그리고 나도 그 과정에서 함께할 상상을 하니 설레었다.

이후 면접 예상 질문을 먼저 뽑고 그에 대한 답변을 작성했다. 키워드 중심으로 외우고 소리내어 얘기해봤다.

이 과정에서 그동안 살면서 겪었던 경험들을 깊이 회고해볼 수 있었다. (그 경험에서 어떤 걸 얻었고 가치관이 어떻게 바뀌었는지 등)

또한 내 경험들을 토스 문화/코어밸류와 연관지으려 노력했다. 토스와 잘 맞는 경험들 위주로 얘기하고 싶었다.

나는 예상치 못한 질문을 받았을 때, 잘 정리된 답변을 하기까지 비교적 오랜 시간이 걸리는 편이다.

그래서 면접 전에 최대한 다양한 소재와 경험을 정리하려 했다.

여러 소재가 있다면 예상치 못한 질문에서도 그 소재들을 기반으로 유연하게 답변을 구성할 수 있을 것이라 생각했고, 실제로도 그랬다.

개인적으로 대기업부터 스타트업까지 여러 면접에서 떨어지면서, 내 면접 역량에 대해 깊은 회의감을 느끼던 시기였다.

내 의견을 효과적으로 전달하고자 지인에게 추천받은 면접 과외를 함께 진행했다.

마지막 기회라는 생각으로 정말 최선을 다해 준비했고, 스트레스를 받느라 살도 엄청 빠졌었다..

후기

HRBP님과 1:1로 면접이 진행되었다.

이력서를 기반으로 가장 오래전 경험부터 차근차근 짚어가며 질문하셨다.

사소한 부분까지 꼼꼼히 질문해주셔서, 형식적인 면접이 아니라 '나라는 사람을 정말 궁금해하시는구나'라는 느낌을 받았다.

면접 보다는 커피챗하는 것 같았다는 후기가 많았는데, 단번에 이해가 되었다.

이런저런 얘기를 나누며 회고라는 키워드가 나왔고, "오늘 면접에 대해 회고해보자면?"이라는 질문을 하셨다.

나는 "긴장하지 않으려 노력했는데 긴장한게 면접에서 티가 난 것 같아 아쉽다"라는 답변을 드렸다.

면접관님께서 "그동안 토스에 여러번 도전해온 만큼 간절한 기회인데 긴장하는 것이 당연하다, 혜민님 내면에 있는 얘기를 듣고 싶어서 긴장하지 말라는 얘기를 여러번 했다, 너무 신경쓰지 말라"라고 말씀해주셨다.

덕분에 그동안 봤던 면접들 중 가장 편안하게 나를 드러낼 수 있었다. 이날 면접에서 가장 기억에 남는 순간이다.

그동안의 몰입 경험, 토스에 왜 가고 싶은지, 성향 등을 말씀드리며 토스에 잘 맞는 사람이라는 것을 어필하려 노력했다.
좋게 봐주신 부분들도 있었지만, 내 단점들도 솔직하게 얘기했기 때문에 면접 결과는 정말 예상이 가지 않았다.

합격이어도 납득이 갔고 불합격이어도 납득이 갔다.

드디어 다른 후기에서만 보던 READY FOR TOSS를 만나게 되었다!

수요일에 면접을 보고, 다음 주 월요일에 결과를 받았는데 그 5일 동안은 정말 마음 졸이며 시간을 보낸 것 같다....

오랫동안 취준을 하며 고생한 만큼 엄청 기쁠 거라 생각했는데, 아직 실감이 잘 안 난다.

마무리

길어지는 취준에 무력감을 느낄 때쯤, 좋은 결과를 받게 되어 다행이다.

클라이언트 개발자 첫 커리어를 토스에서 시작하게 되다니! 너무 영광이다 ㅎㅎ

잘 적응할 수 있을지 걱정도 되고, 내 개발 시야가 넓어진다는 생각에 기대도 된다.

어려운 점이 있으면 주변 사람들에게 적극적으로 도움을 요청하며 최선을 다해볼 생각이다.

그동안 내가 추구해왔던 마인드셋을 잃지않고 꾸준히 노력한다면, 충분히 잘 할 수 있을거라 믿는다.

일단은... 현재를 즐기자!

코루틴 취소와 OkHttp 네트워크 요청 연동하기

hrniin — Wed, 13 Aug 2025 00:01:22 +0900

들어가며

요즘은 Retrofit, Room 같은 라이브러리에서 내부적으로 코루틴을 지원하고 있다.

함수 앞에 suspend 키워드만 붙이면, 라이브러리가 알아서 처리해주기 때문에 개발자가 따로 신경쓸 필요가 없다.

예를 들어, 메인 디스패처에서 네트워크 요청을 보내는 함수를 호출하더라도, 메인 스레드가 블로킹되지 않는다.

이는 라이브러리 내부에서 적절한 디스패처로 전환해 백그라운드 스레드에서 동작하기 때문이다.

그래서 직접 저수준의 코드를 구현하는 게 아니라면, 평소에 자주 접하게 되는 코루틴 API는 suspend, viewModelScope, Dispatchers 정도에 그친다고 생각한다.

그런데 최근 이미지 라이브러리를 만들다가 예상치 못한 오류를 만났고, 이를 해결하는 과정에서 suspendCancellableCoroutine을 사용하게 되었다.

코루틴을 처음 학습할 때 다뤘던 API지만, 잘 사용하지 않다보니 어떤 상황에 활용해야 하는지 잊고 있었다.

이번 기회에 확실히 되짚기 위해 이 글을 작성한다.

문제 상황

먼저 당시 상황을 살펴보자.

    override suspend fun intercept(chain: Interceptor.Chain): Bitmap {
        val request = Request.Builder()
            .url(chain.url)
            .build()
        val call = okHttpClient.newCall(request)
        val response = call.execute()

        if (!response.isSuccessful) {
            val errorBody = response.body?.string() ?: "No error body"
            error("이미지를 불러올 수 없습니다. code=${response.code}, message=${response.message}, body=$errorBody")
        }

        val byteArray = response.body?.bytes() ?: error("응답이 비어있습니다.")
        val bitmap = byteArray.decodeSampledBitmap(chain.imageRequest.size)
        if (logging) Log.d("ImageLoader", "Network Image Load: ${chain.url}")
        return bitmap
    }

OkHttp를 통해 네트워크 요청을 보내고, 응답을 받아 반환하는 간단한 함수다.

이 intercept 함수는 suspend 함수로 선언되어 있다.

이 함수의 문제점이 뭘까?

바로 intercept 함수를 호출한 코루틴이 취소되어도, 네트워크 응답은 계속 진행된다는 점이다.

이유는 OkHttp의 execute() 함수가 코루틴과 무관한 일반 함수이기 때문이다.

따라서 코루틴의 취소 신호를 전혀 감지하지 못한다.

이 문제를 해결하기 위해서는 코루틴이 취소되었을 때 네트워크 요청까지 취소되어야 한다.

즉, intercept 함수 내부에서 코루틴이 취소되었다는 것을 감지하고 네트워크 요청을 취소해야 한다.

여기서 필요한 것이 바로 suspendCancellableCoroutine이다.

suspendCancellableCoroutine의 역할

suspendCancellableCoroutine을 호출하면 코루틴이 즉시 중단된다.

이후 적절한 시점에 resume() 또는 resumeWithException()을 호출하여 코루틴을 다시 재개한다.

resume(): 인자로 전달한 값으로 코루틴을 재개
resumeWithException(): 예외를 던지면서 코루틴을 재개

또한 block 람다의 인자로 CancellableContinuation을 받고 있다.

이를 활용해 코루틴 취소와 관련된 필요한 작업을 수행할 수 있다.

예를 들어 다음과 같은 API들을 제공한다.

invokeOnCacellation(): 코루틴이 취소될 때 수행할 작업을 지정한다.
cancel(): 코루틴을 취소한다.
isCancelled: 코루틴이 취소되었는지 확인한다.

suspendCancellableCoroutine 사용 시 주의할 점

suspend fun main() {
    val result = fetchData()
}

suspend fun fetchData() = suspendCancellableCoroutine<String> { continuation ->
    println("데이터 요청 시작")
    // ...

    if (shouldCancel) {
        println("작업 중단")
        return@suspendCancellableCoroutine
    }

    continuation.resume("서버에서 받은 데이터")
}

resume()이나 resumeWithException()을 호출하지 않으면, 이 함수를 호출한 코루틴은 영원히 대기 상태로 남는다.

suspendCancellableCoroutine은 호출 즉시 코루틴을 중단시키기 때문이다.

위 코드에서 return을 호출했기 때문에 fetchData() 함수는 종료되지만, 코루틴이 재개되지 않아 main() 함수의 코루틴은 계속 대기하게 된다.

이러한 문제를 방지하기 위해 suspendCancellableCoroutine 내부에서는 early return을 최대한 지양해야 한다.

취소 가능하도록 개선하기

다시 intercept 함수로 돌아와서, 네트워크 요청을 취소 가능한 형태로 수정해 보자.

    override suspend fun intercept(chain: Interceptor.Chain): Bitmap =
        suspendCancellableCoroutine { continuation ->
            val request = Request.Builder()
                .url(chain.url)
                .build()
            val call = okHttpClient.newCall(request)
            val response = call.execute()

            continuation.invokeOnCancellation {
                call.cancel()
            }

            if (!response.isSuccessful) {
                val errorBody = response.body?.string() ?: "No error body"
                val exception = IllegalStateException("이미지를 불러올 수 없습니다. code=${response.code}, message=${response.message}, body=$errorBody")
                continuation.resumeWithException(exception)
            }

            val byteArray = response.body?.bytes()
            if (byteArray == null) {
                continuation.resumeWithException(IllegalStateException("응답이 비어있습니다."))
            } else {
                val bitmap = byteArray.decodeSampledBitmap(chain.imageRequest.size)
                if (logging) Log.d("ImageLoader", "Network Image Load: ${chain.url}")
                continuation.resume(bitmap)
            }
        }

CancellableContinuation의 invokeOnCacellation()을 사용해서, 코루틴이 취소되면 네트워크 요청도 함께 취소되도록 구현했다.

불필요한 네트워크 리소스 낭비를 방지할 수 있어 더 효율적이다.

콜백 기반 API와 함께 사용하기

현재 intercept 함수는 항상 IO 디스패처에서 호출하도록 설계되어 있어 execute를 사용했다.

하지만 메인 디스패처에서도 안전하게 호출하려면 enqueue를 사용할 수 있다.

이 경우에도 suspendCancellableCoroutine을 활용하면, 콜백 기반 API를 깔끔하게 코루틴 스타일로 감쌀 수 있다.

아래는 intercept 함수의 execute를 enqueue로 변환한 코드다.

    override suspend fun intercept(chain: Interceptor.Chain): Bitmap =
        suspendCancellableCoroutine { continuation ->
            val request = Request.Builder()
                .url(chain.url)
                .build()
            val call = okHttpClient.newCall(request)

            continuation.invokeOnCancellation {
                call.cancel()
            }

            val callback = object : Callback {
                override fun onFailure(
                    call: Call,
                    e: IOException,
                ) {
                    continuation.resumeWithException(e)
                }

                override fun onResponse(
                    call: Call,
                    response: Response,
                ) {
                    if (!response.isSuccessful) {
                        val exception = IllegalStateException("이미지를 불러올 수 없습니다. code=${response.code}, message=${response.message}")
                        continuation.resumeWithException(exception)
                        return
                    }

                    val byteArray = response.body?.bytes()
                        ?: return continuation.resumeWithException(IllegalStateException("응답이 비어있습니다."))

                    val bitmap = byteArray.decodeSampledBitmap(chain.imageRequest.size)
                    if (logging) Log.d("ImageLoader", "Network Image Load: ${chain.url}")
                    continuation.resume(bitmap)
                }
            }
            call.enqueue(callback)
        }

suspendCancellableCoroutine은 특히 콜백 기반 API를 코루틴 형태로 변환하고 싶을 때 유용한다.

콜백이 단일 값을 반환하면 suspendCancellableCoroutine을, 스트림처럼 여러 값을 반환하면 callbackFlow를 사용한다.

suspendCoroutine vs suspendCancellableCoroutine

suspendCancellableCoroutine을 학습하다보면 suspendCoroutine이 항상 함께 언급된다.

함수명에서 알 수 있듯 suspendCoroutine은 취소를 감지할 수 없는 suspendCancellableCoroutine과 유사하다.

	suspendCoroutine	suspendCancellableCoroutine
Continuation 타입	Continuation	CancellableContinuation
취소 감지	불가능	가능
사용 목적	취소 처리 없는 단순 래핑	취소 시 리소스 해제가 필요한 경우

두 함수 모두 코루틴을 일시 중단하고, 이후 수동으로 재개한다는 점은 같다.

suspendCoroutine은 취소 신호를 무시하기 때문에, 리소스 정리 없이 영원히 중단 상태로 남을 수 있다.
반면 suspendCancellableCoroutine은 취소 처리가 가능해 훨씬 안전하다.

마무리

suspendCancellableCoroutine은 콜백 기반 API를 코루틴으로 감싸고, 코루틴 취소 시 별도의 처리가 필요할 때 사용한다.

어떻게 보면 당연하고 기본적인 얘기일 수도 있겠다.

실제 코루틴을 학습하며 처음 작성했던 블로그 내용이기도 하다.

그럼에도 실전에서 겪은 경험을 바탕으로 다시 되짚어보며 개념을 정리해두는 데 의미가 있었다.

기본적인 개념을 확실히 이해하고 있어야겠다.
기초가 탄탄해야 복잡한 문제도 능숙하게 해결할 수 있다는 걸 다시금 깨달았다..!

Fragment에서 ViewCompositionStrategy를 사용하는 이유

hrniin — Tue, 3 Jun 2025 22:45:51 +0900

개요

오디라는 프로젝트에서 점진적으로 Compose 마이그레이션을 진행중이다.

처음부터 Compose를 사용한게 아니기 때문에, 화면 전환에는 Compose Navigation이 아닌 Intent나 FragmentManager 방식을 사용하고 있다.

화면 전환은 기존에 사용하던 방식을 사용하고, 각각의 Activity/Fragment에서 컴포저블 함수를 호출하는 방식이다.

예를 들어 LoginActivity라면 LoginScreen을 호출하고, MeetingsActivity라면 MeetingsScreen을 호출한다.

이 때, Fragment에서는 ViewCompositionStrategy와 함께 컴포저블 함수를 호출한다.

"State 유지와 메모리 누수를 방지하기 위해" ViewCompositionStrategy를 사용하는 것은 알고 있었지만,

막상 어떤 문제가 발생하는지, 그리고 ViewCompositionStrategy은 어떤 역할을 하는지 제대로 알지 못하고 사용했다.

구글링을 해봐도 명확한 답이 나오지 않아서 이를 계기로 블로그를 작성하게 되었다.

Activity에서 Compose 사용하기

class XXXActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        setContent {
            enableEdgeToEdge()
            OdyTheme {
                XXXScreen()
            }
        }
    }
}

가장 먼저 Activity에서는 위처럼 간단히 setContent 블록 내에서 컴포저블 함수를 호출할 수 있다.

Fragment에서 Compose 사용하기 - 좋지 못한 예시

class XXXFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?,
    ): View {
        return ComposeView(requireContext()).apply {
            setContent {
                OdyTheme {
                    XXXScreen()
                }
            }
        }
    }
}

그런데 Fragment에서 Activity와 유사하게 컴포저블 함수를 호출하면 메모리 누수가 발생한다.

그 이유가 뭘까? 그리고 안전하게 컴포저블 함수를 호출하려면 어떻게 해야할까?

Fragment에서 Compose 사용하기 - 좋은 예시

class XXXFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?,
    ): View {
        return ComposeView(requireContext()).apply {
            setViewCompositionStrategy(
                ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed,
            )
            setContent {
                OdyTheme {
                    XXXScreen()
                }
            }
        }
    }
}

결론부터 말하면 위처럼 사용하면 안전하게 컴포저블 함수를 사용할 수 있다.

setContent 뿐만 아니라 글 초기에 말했던 ViewCompositionStrategy도 설정해야 한다.

ViewCompositionStrategy를 설정하지 않으면 발생하는 문제

class XXXFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?,
    ): View {
        return ComposeView(requireContext()).apply {
            setContent {
                OdyTheme {
                    XXXScreen()
                }
            }
        }
    }
}

일단 아까 좋지 못한 예시로 보여준 코드의 문제점을 자세히 살펴보자.

기본적으로 컴포지션은 Window에 detach될 때 dispose된다.

Window에서 detach된다는 것은 여러 경우가 있다. 곧 뷰가 소멸되거나, 컨테이너가 뷰에서 벗어나는 경우 등이다.

즉, Fragment View가 소멸되는 타이밍과 Fragment의 컴포지션이 제거되는 타이밍이 다르다.

여기서 한가지 의문이 생겼다.

그렇다면 " Window에 detach되는 것"은 Fragment의 어떤 생명주기에서 발생될까?

구글링을 열심히 해본 결과 명확한 답을 찾을 수 없었다..

(Window에 detach되는 것과 Activity에 detach되는 것은 다르기 때문에, onDetach() 이전에 컴포지션이 제거될 것이라 생각한다)

어쨌든 Fragment에서 뷰가 소멸되는 onDestroyView()과는 완전히 대응되지 않아서 이러한 문제가 발생한다는 것은 알겠다!

만약 Fragment View가 소멸되지 않았는데 Fragment의 컴포지션이 제거된다면?

View는 남아있는데 컴포지션이 제거되어 처음부터 다시 컴포지션이 될 것이다.

이 경우 기존 컴포지션에서 사용되고 있던 State들은 사라진다.

즉, 기존 State들이 유실되어 부자연스러운 UI가 나타날 수 있다.

예를 들어 LazyColumn의 스크롤 상태가 보존되지 못하고 갑자기 화면 가장 상단으로 스크롤이 이동할 수도 있을 것이다.

이는 좋지 못한 사용자 경험으로도 이어질 수 있으니 최대한 지양해야 한다.

또는 Fragment View는 소멸되었는데 컴포지션은 살아있다면, 메모리 누수로 이어질 수 있다.

ViewCompositionStrategy의 역할

이제 Fragment에서 ViewCompositionStrategy 없이 컴포즈를 사용하면 어떤 문제가 발생하는지 이해했다.

그렇다면 ViewCompositionStrategy는 어떤 역할을 하길래 이러한 문제를 해결해 주는지 알아보자.

ViewCompositionStrategy

ViewCompositionStrategy는 컴포지션을 언제 제거해야 하는지 정의하는 것이다.

Fragment 컴포지션이 제거되는 시점이 Fragmen View의 소멸 시점과 달라서 생기는 문제라면,

컴포지션이 제거되는 시점을 코드 상으로 커스텀하면 되는 것이다!

ViewCompositionStrategy 종류

현재는 ViewCompositionStrategy에 4가지 종류가 존재한다.

ViewCompositionStrategy에 대한 글이 아니므로 간단히만 살펴보려고 한다.

DisposeOnDetachedFromWindow
- 뷰가 Window에서 detach되면 컴포지션이 제거된다.
DisposeOnDetachedFromWindowOrReleasedFromPool
- 뷰가 Window에서 detach되면 컴포지션이 제거된다.
- Pooling Container의 뷰가 Window에서 detach되거나, 풀이 가득찬 경우 컴포지션이 제거된다.
- (뷰가 Pooling Container에 포함되지 않는다면 DisposeOnDetachedFromWindow와 동일)
- 더 자세히 알고 싶다면 링크 참고
DisposeOnLifecycleDestroyed
- 인자로 들어온 Lifecycle이 소멸되면 컴포지션이 제거된다.
DisposeOnViewTreeLifecycleDestroyed
- 연결된 뷰에서 가져온 ViewTreeLifecycleOwner가 소멸되면 컴포지션이 제거된다.

ViewCompositionStrategy의 기본값

현재 모든 컴포지션의 ViewCompositionStrategy 기본값은 DisposeOnDetachedFromWindowOrReleasedFromPool이다.

ViewCompositionStrategy.Default 내부를 확인해보면 단순히 DisposeOnDetachedFromWindowOrReleasedFromPool만 반환하고 있다.

(공식문서에도 나와있듯 충분히 기본값이 변경될 여지가 있어보인다.)

즉, 별도로 ViewCompositionStrategy를 설정하지 않으면 Window에서 detach될 때 컴포지션이 제거된다는 것을 알 수 있다.

Fragment의 ViewCompositionStrategy

class XXXFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?,
    ): View {
        return ComposeView(requireContext()).apply {
            setViewCompositionStrategy(
                ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed,
            )
            setContent {
                OdyTheme {
                    XXXScreen()
                }
            }
        }
    }
}

다시 Fragment의 ViewCompositionStrategy로 돌아와보자.

위 코드는 글 초반에 본 좋은 예시의 코드다.

네 종류의 ViewCompositionStrategy 중 DisposeOnViewTreeLifecycleDestroyed를 사용했다.

즉, 명시적으로 "Fragment View가 소멸될 때 컴포지션도 제거해줘"라고 설정했기 때문에,

Fragment View의 생명주기와 동일한 시점에 컴포지션이 제거된다는 것이 보장되는 것이고, State도 유실되지 않을 수 있는 것이다!

class XXXFragment : Fragment() {
    override fun onCreateView(
        inflater: LayoutInflater,
        container: ViewGroup?,
        savedInstanceState: Bundle?,
    ): View {
        return ComposeView(requireContext()).apply {
            setViewCompositionStrategy(
                ViewCompositionStrategy.DisposeOnLifecycleDestroyed(this@XXXFragment.viewLifecycleOwner)
            )
            setContent {
                OdyTheme {
                    XXXScreen()
                }
            }
        }
    }
}

DisposeOnViewTreeLifecycleDestroyed이 아닌 DisposeOnLifecycleDestroyed을 사용할 수도 있다.

위처럼 명시적으로 인자로 Fragment View의 LifecycleOwner를 전달해주면,

DisposeOnViewTreeLifecycleDestroyed를 사용한 것과 동일하게 Fragment View가 소멸될 때 컴포지션도 제거된다.

Activity에서는 ViewCompositionStrategy를 사용하지 않는 이유

그런데 왜 Acticity에서는 ViewCompositionStrategy를 따로 설정하지 않았는지 의문이 들 수도 있다.

이유는 Fragment와 Activity의 생명주기 관리 방식의 차이 때문이다.

먼저 Fragment의 생명주기를 보자.

Fragment는 Fragment 자체의 생명주기와 Fragment View의 생명주기가 다르다.

Fragment 생명주기가 Fragment View의 생명주기 보다 길기 때문에,

Fragment는 살아있는데 Fragment View가 여러번 생성/소멸될 수 있다.

즉, 뷰가 소멸된 후에도 참조가 남아있다면 메모리에서 해제되지 못하고 메모리 누수로 이어질 수 있기 때문에 주의해야 한다.이러한 관점에서 컴포지션의 생명주기와 Fragment View 생명주기를 완전히 동일시켜야 안정적이다.

반면에 Activity의 생명주기는 Activity의 생명주기와 Activity View의 생명주기가 동일하다.

Activity가 소멸되면 Activity View도 소멸되고 컴포지션 또한 제거된다.

즉, 특별한 설정 없어도 Activity View와 컴포지션은 함께 정리된다.

이러한 차이 때문에 Fragment에서는 항상 Activity 보다 추가적인 설정이 필요한 것 같다.

(데이터 바인딩에서 binding 객체의 참조를 명시적으로 제거한 것처럼..)

마무리

이렇게 마음 한구석 찝찝했던 Fragment의 ViewCompositionStrategy에 대해 알아봤다!

코드의 생산성을 위해 프로젝트를 Compose로 마이그레이션하고 있지만, 이것저것 새롭게 알게 되는 것이 많아 즐거운 마음으로 마이그레이션하고 있다.

100% Compose를 목표로 틈틈히 마이그레이션 중이다~!

현재 마이그레이션 진행 중인 오디 프로젝트의 깃허브 링크를 끝으로 글을 마무리한다.

https://github.com/woowacourse-teams/2024-ody

GitHub - woowacourse-teams/2024-ody: 더 이상 "너 어디야?"라고 물어보지 마세요. 약속을 더욱 즐겁고 편안

더 이상 "너 어디야?"라고 물어보지 마세요. 약속을 더욱 즐겁고 편안하게, 여러분의 우정을 더욱 돈독하게 만들어 드릴게요. - woowacourse-teams/2024-ody

github.com

잘못된 내용이 있다면 피드백 부탁드립니다! (--) (__)

참고 자료

https://developer.android.com/develop/ui/compose/migrate/interoperability-apis/compose-in-views?hl=ko

https://developer.android.com/reference/kotlin/androidx/compose/ui/platform/ViewCompositionStrategy

https://developer.android.com/guide/components/activities/activity-lifecycle?hl=ko

https://developer.android.com/guide/fragments/lifecycle?hl=ko

https://medium.com/androiddevelopers/jetpack-compose-interop-using-compose-in-a-recyclerview-569c7ec7a583

Paging3+RecyclerView를 Compose로 마이그레이션하기

hrniin — Fri, 4 Apr 2025 20:21:36 +0900

요즘 오디를 Compose로 마이그레이션하고 있다.

오디는 우아한테크코스에서 팀 프로젝트로 개발했던 앱인데,

당시에는 Compose를 모르는 상태였기 때문에 모든 UI가 XML로 구현되어 있다.

틈틈이 마이그레이션을 하는게 요즘 내 힐링이다. 코드가 간결해지는게 눈에 보여서 재밌다 ㅎ

오디의 주소 검색 화면은 Paging3을 사용해 무한 스크롤을 구현했었다.

이 화면을 마이그레이션하며 "Compose에 Paging3를 어떻게 적용할지"에 대해 배운 것들을 정리해 보려고 한다.

이 글은 RecyclerView에서 Compose로 마이그레이션하는 방법을 중점적으로 다룬다.

즉, Paging3와 PagingSource, PagingDataAdapter에 대한 내용을 자세히 다루지 않는다.

가장 먼저, RecyclerView와 Compose 각각의 방법에 대해 요약해 보자면 아래와 같다.

RecyclerView의 Paging3 적용 방법

1. PagingSource를 작성한다.

2. PagingDataAdapter를 작성한다.

3. PagingSource에서 가져온 데이터를 collect한다.

4. Adapter의 submitData를 호출한다.

Compose의 Paging3 적용 방법

1. PagingSource를 작성한다.

2. PagingSource에서 가져온 데이터를 State로 변환한다.

3. LazyList(LazyColumn, LazyRow...)를 사용해 데이터를 화면에 보여준다.

Compose는 (당연하게도) Adapter를 정의할 필요가 없다.

PagingSource를 작성하는 것 외에는, 일반 Compose 구현과 비슷하기 때문에, 더 이해하기 쉽다.

PagingSource는 데이터 소스에서 페이지 별로 데이터를 가져오는 방법을 정의한 객체다.

PagingDataAdapter는 RecyclerView의 Adapter 역할을 한다. 페이징 데이터를 쉽게 처리할 수 있도록 해준다.

그럼 더 자세한 구현 방법을 알아보자.

1. Compose Paging3 의존성 추가

// libs.versions
androidx-compose-paging = { group = "androidx.paging", name = "paging-compose", version.ref = "androidxPaging" }

// build.gradle
implementation(libs.androidx.compose.paging)

Compose에서 Paging을 사용하기 위해서는 별도의 의존성 추가가 필요하다.

2025/04/04 기준 최신 버전은 3.3.6이다.

2. 컴포저블에서 Paging 데이터 가져오기

val addresses = viewModel.address.collectAsLazyPagingItems()

collectAsLazyPagingItems 라는 함수를 통해 PagingData를 Compose에서 사용할 수 있는 상태로 변환한다.

@Composable
public fun <T : Any> Flow<PagingData<T>>.collectAsLazyPagingItems(
    context: CoroutineContext = EmptyCoroutineContext
): LazyPagingItems<T>

collectAsLazyPagingItems의 리시버는 Flow<PagingData<T>>이며, 반환 타입은 LazyPagingItems이다.

바로 이 LazyPagingItems 덕분에 페이지 데이터를 LazyList에서 바로 사용할 수 있는 것이다.

내부적으로는 MutableState 타입의 itemSnapshotList가 Flow를 바라보고 있다.

3. LazyList로 페이지 데이터 띄우기

@Composable
private fun AddressList(
    addresses: LazyPagingItems<Address>,
    onClickAddress: (Address) -> Unit,
) {
    LazyColumn(...) {
        items(count = addresses.itemCount) { index ->
            val address = addresses[index] ?: return@items
            AddressItem(address, onClickAddress)
        }
    }
}

LazyPagingItems와 LazyList를 사용해 페이지 데이터를 화면에 띄워보자.

보다시피 기존에 구현하던 LazyList 방식과 별반 다를게 없다.

LazyPagingItems의 itemCount를 통해 아이템 개수를 전달한다.

fun items(
    count: Int,
    key: ((index: Int) -> Any)? = null,
    contentType: (index: Int) -> Any? = { null },
    itemContent: @Composable LazyItemScope.(index: Int) -> Unit
)
    
inline fun <T> LazyListScope.items(
    items: List<T>,
    noinline key: ((item: T) -> Any)? = null,
    noinline contentType: (item: T) -> Any? = { null },
    crossinline itemContent: @Composable LazyItemScope.(item: T) -> Unit
)

기존 List를 사용했을 때와 차이점은 사용하는 items 함수가 다르다는 것이다.

위 코드에서 첫 번째 함수가 Paging과 함께 사용하는 함수고, 두 번째 함수가 일반적으로 List와 함께 사용하는 함수다.

두 번째 함수의 items 매개변수 타입이 List<T>이므로, Paging에서는 사용할 수 없다.

첫 번째 items 함수

LazyListScope 인터페이스 내부에 정의되어 있다.
아이템의 개수를 전달하고, itemContent에서는 람다의 인자 index를 통해 직접 아이템을 가져온다.

두 번째 items 함수

LazyListScope의 확장 함수 형태다.
아이템 리스트를 전달하고, itemContent에서는 람다의 인자가 아이템이므로, 바로 사용한다.

4. LazyList에 key 지정하기

@Composable
private fun AddressList(
    addresses: LazyPagingItems<Address>,
    onClickAddress: (Address) -> Unit,
) {
    LazyColumn(...) {
        items(
            count = addresses.itemCount,
            key = addresses.itemKey { it.id },
        ) { index ->
            val address = addresses[index] ?: return@items
            AddressItem(address, onClickAddress)
        }
    }
}

LazyList에서는 리컴포지션을 최적화하기 위해 key를 지정한다.

LazyPagingItems를 사용할 때도 itemKey라는 확장 함수를 통해 key를 지정할 수 있다.

public fun <T : Any> LazyPagingItems<T>.itemKey(
    key: ((item: T) -> Any)? = null
)

itemKey 람다의 인자 item을 사용해 어떤 값을 key로 사용할 지 지정한다.

위 예제 코드에서는 Address 객체의 id를 key로 사용했다. ( itemKey { it.id } )

만약 key가 null이라면(기본값), index가 key가 된다.

5. 동적으로 데이터가 로드되지 않는다면

LazyList에서는 무조건 LazyPagingItems 타입을 사용해야 한다.

무한 스크롤의 이점인 지연 로딩이 되지 않을 수 있기 때문이다.

@Composable
fun AddressSearchScreen(
    viewModel: AddressSearchViewModel = hiltViewModel(),
) {
    val addresses = viewModel.address.collectAsLazyPagingItems()

    Scaffold(...) {
        AddressSearchContent(
            addresses = addresses.toList()
        )
    }
}

private fun <T : Any> LazyPagingItems<T>.toList(): List<T> {
    val list = mutableListOf<T>()
    repeat(itemCount) {
        val item = get(it) ?: return@repeat
        list.add(item)
    }
    return list
}

기존에는 위 코드처럼 LazyPagingItems이 아닌 List를 사용했었다.

굳이굳이 LazyPagingItems의 확장 함수 toList()를 작성해 가면서..;;

@Composable
@Preview(showSystemUi = true)
private fun AddressSearchContentPreview() {
    OdyTheme {
        AddressSearchContent(
            addresses = listOf(...),
        )
    }
}

이유는 프리뷰를 더 수월하게 작성하기 위함이다.

LazyPagingItems의 객체를 직접 생성할 수 없기 때문에, 컴포저블의 인자로 LazyPagingItems를 전달할 수 없었다.

그런데 데이터를 로드해 오는 부분에 로그를 찍어보니, 한 번에 모든 데이터를 불러오고 있었다.

즉, List가 아닌 LazyPagingItems를 사용해야 데이터를 동적으로 불러올 수 있다.

지금 생각해 보면 당연하다.. LazyPagingItems 내부의 PagingData에서 스크롤 시 자동으로 새로운 페이지를 불러오고 있기 때문이다.

그렇다면 LazyPagingItems를 사용했을 때 프리뷰는 어떻게 작성할까?

6. LazyPagingItems 프리뷰 작성하기

프리뷰로 확인하려는 컴포저블 함수의 인자로 LazyPagingItems를 전달해야 한다.

하지만 LazyPagingItems의 객체를 직접 생성할 수는 없다.

@Composable
@Preview(showSystemUi = true)
private fun AddressSearchContentPreview() {
    val addresses = listOf(...)

    val pagingData = PagingData.from(addresses)
    val lazyPagingItems = flowOf(pagingData).collectAsLazyPagingItems()

    OdyTheme {
        AddressSearchContent(
            addresses = lazyPagingItems,
        )
    }
}

이 경우 위처럼 프리뷰를 작성한다.

LazyPagingItems는 PagingData를 Flow 형태로 가지고 있다.

즉, PagingData의 Flow를 생성 후 collectAsLazyPagingItems를 호출하여 LazyPagingItems를 생성하면 된다.

7. PagingSource의 LoadState 가져오기

class AddressPagingSource(...) : PagingSource<Int, Address>() {
    override suspend fun load(params: LoadParams<Int>): LoadResult<Int, Address> {
        return runCatching {
            val addresses = addressRepository.fetchAddresses(...).getOrThrow()
            LoadResult.Page(...)
        }.getOrElse { throwable ->
            LoadResult.Error(throwable)
        }
    }

    ...
}

PagingSource에서는 데이터 소스에서 데이터를 가져오다가 오류가 발생한 경우, LoadResult.Error를 반환할 수 있다.

이러한 LoadResult를 UI 계층에서 받아와 에러 핸들링을 해야 하는 경우가 있다. (ex: 토스트, 스낵바, 에러 화면 등)

adapter.addLoadStateListener { loadState ->
    when (loadState.append) {
        LoadState.Loading -> {}
        is LoadState.NotLoading -> {}
        is LoadState.Error -> {}
    }
}

RecyclerView에서는 PagingDataAdapter의 addLoadStateListener를 사용하여 LoadState를 받아왔다.

@Composable
fun AddressSearchScreen(
    viewModel: AddressSearchViewModel = hiltViewModel(),
) {
    val addresses = viewModel.address.collectAsLazyPagingItems()

    Scaffold(...) { innerPadding ->
        when (val state = addresses.loadState.append) {
            LoadState.Loading -> TODO()
            is LoadState.Error -> TODO()
            is LoadState.NotLoading -> TODO()
        }

        AddressSearchContent(...)
    }
}

Compose의 경우 collectAsLazyPagingItems에서 가져온 LazyPagingItems를 통해 loadState에 접근할 수 있다.

class CombinedLoadStates(
    val refresh: LoadState,
    val prepend: LoadState,
    val append: LoadState,
    val source: LoadStates,
    val mediator: LoadStates?
)

addLoadStateListener 와 LazyPagingItems의 loadState는 CombinedLoadStates 타입이다.

CombinedLoadStates는 LoadState를 가지고 있는 일종의 컬렉션이다.

에러 핸들링을 위해 refresh, prepend, append를 주로 사용한다.

refresh: 데이터를 새로고침하거나 처음 데이터를 로드했을 때의 상태
prepend: 데이터의 앞쪽에 새로운 데이터를 추가할 때의 상태 (위로 스크롤)
append: 데이터의 뒤쪽에 새로운 데이터를 추가할 때의 상태 (아래로 스크롤)

요약

컴포저블 함수 collectAsLazyPagingItems를 사용하여 Flow<PagingData<T>>를 LazyPagingItems<T>로 변환한다.
LazyPagingItems를 사용해 LazyList에서 페이지 데이터를 화면에 보여준다.
LazyPagingItems를 사용해 LoadState를 가져올 수 있다.

참고

https://developer.android.com/reference/kotlin/androidx/paging/compose/package-summary

Flow, StateFlow, SharedFlow를 편하게 테스트하는 방법 (feat: Turbine)

hrniin — Sat, 29 Mar 2025 15:07:50 +0900

그동안 Flow의 특성을 고려하지 않거나 가독성이 좋지 않은 상태로 "돌아가는 테스트 코드"를 작성했었다.

그러다보니 내가 짠 테스트인데도 지금 다시 보니 어떤 코드인지 제대로 이해하지 못하는 경우가 꽤나 있었다..

새로운 사이드 프로젝트를 시작하며, 가독성이 좋고 유지보수할 수 있는 테스트를 작성하려고 노력 중이다.

그 과정에서 Turbine 라이브러리를 얕게 학습했는데, 오늘은 이와 관련된 포스팅을 하려고 한다.

Turbine 라이브러리가 무엇인지 간단히 알아보고,

Turbine를 사용한 Flow와 StateFlow, SharedFlow 테스트 방법을 각각 소개한다.

Turbine를 사용하지 않았을 때의 코드와 비교하여 Turbine의 이점을 알아보려고 한다.

Turbine 라이브러리란?

https://github.com/cashapp/turbine

GitHub - cashapp/turbine: A testing library for kotlinx.coroutines Flow

A testing library for kotlinx.coroutines Flow. Contribute to cashapp/turbine development by creating an account on GitHub.

github.com

Flow를 편리하게 테스트할 수 있는 서드파티 라이브러리다.

안드로이드 공식 문서에서도 소개하고 있을 정도로, 많은 사람들이 사용하고 있다.

flowOf("one", "two").test {
    assertEquals("one", awaitItem())
    assertEquals ("two", awaitItem())  
    awaitComplete()
}

Turbine 사용법을 가장 간략하게 표현한 코드다.

가장 먼저 test() 함수가 무엇인지 알아보자.

test 함수

public suspend fun <T> Flow<T>.test(
  timeout: Duration? = null,
  name: String? = null,
  validate: suspend TurbineTestContext<T>.() -> Unit,
)

Flow의 확장 함수 형태인 test()는 Flow의 값을 편리하게 꺼내오고, 어설션할 수 있는 스코프를 제공한다.

매개변수 validate 람다의 리시버 TurbineTestContext를 통해 awaitItem()을 호출할 수 있는 것이다.

awaitItem, awaitComplete, awaitError 함수

interface ReceiveTurbine<T> {
    suspend fun awaitItem(): T
    
    suspend fun awaitComplete()

    suspend fun awaitError(): Throwable
}

TurbineTestContext는 ReceiveTurbine를 구현하고 있기 때문에, 위와 같은 ReceiveTurbine 함수들을 호출할 수 있다.

위 세개의 함수는 test()의 validate 블록 내부에서 사용하는 주요 함수들이다.

Turbine에서는 Flow가 값을 방출했을 때, Flow가 완료되었을 때, 에러가 발생했을 때를 모두 하나의 Event로 본다.

즉, 위 세개의 함수를 통해 기대하는 Event가 발생할 때까지 기다리다가, Event가 발생했다면 Event를 반환하는 것이다.

만약 timeout 동안 Event가 발생하지 않았다면, 예외를 던진다.

awaitXXX 함수의 timeout

app.cash.turbine.TurbineAssertionError: No value produced in 3s

test 함수의 timeout의 기본값은 3초이다.

만약 Flow의 test 블록 내에서 awaitItem()를 호출했는데, 3초 동안 아무런 값이 방출되지 않는다면 위와 같은 오류가 발생한다.

flowOf("one", "two").test(timeout = Duration.parse("PT10S")) {
    assertEquals("one", awaitItem())
    assertEquals ("two", awaitItem())  
    awaitComplete()
}

timeout 매개변수에 Duration을 지정하여 timeout을 커스텀할 수도 있다.

Turbine의 기본적인 함수들을 알아봤으니, Flow를 테스트하는 방법에 대해 알아보자.

Flow 테스트하기

Flow 단일 값 테스트 - Turbine 사용 X

@Test
fun flowTest1() = runTest {
    // given
    val repository = FakeRepository()
    val useCase = UseCase(repository)

    // when
    val actual = useCase()

    // then
    assertThat(actual.first()).isTrue
}

먼저 Turbine 없이 Flow 값 하나만을 테스트하려는 경우다.

이 경우 first()를 사용해 Flow의 가장 첫 번째 항목을 가져올 수 있다.

Flow 단일 값 테스트 - Turbine 사용 O

@Test
fun flowTest1WithTurbine() = runTest {
    // given
    val repository = FakeRepository()
    val useCase = UseCase(repository)

    // when
    val actual = useCase()

    // then
    actual.test {
        assertThat(awaitItem()).isTrue
        awaitComplete()
    }
}

Turbine를 사용하여 이전 코드를 테스트한 코드다.

간단한 테스트인 경우에는 Turbine를 사용했을 때 이점이 두드러지지는 않는다.

awaitItem()으로 값을 받아오고, awaitComplete()로 Flow가 끝났다는 이벤트를 받는다.

// 두 번째 값을 가져옴
flow.drop(1).first()

// 처음 5개의 값을 가져옴
flow.take(5).toList()

// 값이 하나만 방출된 후 Flow가 닫혔는지 확인
flow.single()

// 연산이 무한하지 않은 Flow에서 값의 개수
flow.count()
flow.count { it == 3 }

first()가 아니어도, Flow의 여러 연산들을 통해 Flow의 값을 가져올 수 있다.

순차적으로 Flow 여러 값 테스트 - Turbine 사용 X

toList()를 사용해 Flow 값을 한 번에 가져오는 경우, 전체 값을 가져올 때까지 함수가 중단된다는 단점이 있다.

toList()를 사용하지 않고도, 순차적으로 Flow에 값을 방출하고 Flow의 값을 확인할 수 있다.

@Test
fun flowTest2() = runTest {
    // given
    val dataSource = FakeDataSource()
    val repository = Repository(dataSource)

    val values = mutableListOf<Int>()
    backgroundScope.launch {
        repository.flow().toList(values)
    }

    // when & then
    dataSource.emit(1)
    assertEquals(10, values[0])

    dataSource.emit(2)
    dataSource.emit(3)
    assertEquals(30, values[2])

    assertEquals(3, values.size)
}

Turbine를 사용하지 않는다면, 위 코드처럼 List에 Flow값을 하나씩 저장시키고, List 값을 확인해야 한다.

테스트의 무한 루프를 방지하기 위해 backgroundScope를 사용했다.

기본적으로 runTest는 자식 코루틴이 끝날 때까지 기다린다.

Repository의 Flow는 완료되지 않기 때문에, backgroundScope를 사용하지 않으면 toList()는 영원히 끝나지 않고 테스트도 무한루프를 돌 것이다.

반면 backgroundScope로 생성된 코루틴은 테스트가 끝나면 자동으로 취소된다.

순차적으로 Flow 여러 값 테스트 - Turbine 사용 O

@Test
fun flowTest2WithTurbine() = runTest {
    // given
    val dataSource = FakeDataSource()
    val repository = Repository(dataSource)
    
    // when & then
    repository.scores().test {
        dataSource.emit(1)
        assertEquals(10, awaitItem())

        dataSource.emit(2)
        awaitItem()

        dataSource.emit(3)
        assertEquals(30, awaitItem())
        awaitComplete()
    }
}

Turbine를 사용한 코드는 위와 같다.
Flow를 collect하거나 최종 연산자를 호출하지 않아도, test()를 호출하면 내부적으로 Flow를 collect한다.

List 없이 awaitItem()를 호출하여 Flow의 값을 순차적으로 꺼내온다.

List를 생성하고 List 인덱스에 접근하는 코드들이 사라지게 되어 가독성이 좋다.

StateFlow 테스트하기

StateFlow 테스트 - Turbine 사용 X

@Test
fun stateFlowTest() = runTest {
    // given
    val fakeRepository = FakeRepository()
    val viewModel = ViewModel(fakeRepository)

    // when & then
    assertEquals(0, viewModel.score.value)

    fakeRepository.emit(1)
    assertEquals(1, viewModel.score.value)

    fakeRepository.emit(2)
    fakeRepository.emit(3)
    assertEquals(3, viewModel.score.value)
}

StateFlow는 Flow와 달리 Hot Flow이기 때문에 누군가 구독하지 않아도 값을 방출한다.

또한 항상 하나의 값을 가지고 있다.

즉, Flow의 first(), drop() 등을 사용할 수 있지만, value를 통해 현재의 값을 가져올 수도 있다.

@Test
fun stateFlowTest() = runTest {
    // given
    val fakeRepository = FakeRepository()
    val viewModel = ViewModel(fakeRepository)

    backgroundScope.launch {
        viewModel.score.collect {}
    }

    // ...
}

StateFlow는 Hot Flow지만, Flow.stateIn()을 통해 Flow를 StateFlow로 변환한 경우에는 꼭 collect하는 코드가 필요하다.

collect하지 않는다면, Flow가 활성화되지 않아 StateFlow 값도 업데이트되지 않는다.

StateFlow 테스트 - Turbine 사용 O

fun stateFlowTestWithTurbine() = runTest {
    val fakeRepository = FakeRepository()
    val viewModel = ViewModel(fakeRepository)

    viewModel.score.test {
        assertEquals(0, awaitItem())

        fakeRepository.emit(1)
        assertEquals(1, awaitItem())

        fakeRepository.emit(2)
        fakeRepository.emit(3)
        assertEquals(3, awaitItem())
    }
}

반면에 Turbine를 사용하는 경우, stateIn()을 사용하고 있더라도 collect하지 않아도 된다.

test() 내부적으로 StateFlow를 collect해주고 있기 때문이다.

SharedFlow 테스트하기

SharedFlow 테스트 - Turbine 사용 X

@Test
fun sharedFlowTest() = runTest {
    // given
    val fakeRepository = FakeRepository()
    val viewModel = ViewModel(fakeRepository)

    // when
    launch {
        viewModel.initialize()
    }

    // then
    assertThat(viewModel.event.first()).isEqualTo(3)
}

SharedFlow는 StateFlow와 동일하게 Hot Flow이지만, 값을 가지고 있지 않는다.

일회성으로 방출하는 값을 확인하려면, 새로운 코루틴에서 값을 방출하는 함수를 호출해야 한다.

만약 동일한 코루틴에서 함수를 호출한다면, 값을 어설션하는 것 보다 값을 방출하는 것이 더 빠를 수 있다.

이 경우 SharedFlow의 값을 계속 기다리면서 테스트가 무한 루프를 돌 것이다.

SharedFlow 테스트 - Turbine 사용 O

@Test
fun sharedFlowTestWithTurbine() = runTest {
    // given
    val fakeRepository = FakeRepository()
    val viewModel = ViewModel(fakeRepository)

    // when
    launch {
        viewModel.initialize()
    }

    // then
    viewModel.event.test {
        assertThat(awaitItem()).isEqualTo(3)
    }
}

SharedFlow의 경우 Turbine를 사용했을 때 큰 차이점은 없다.

기존 테스트들과 동일하게 test()와 awaitItem()을 사용한다.

@Test
fun sharedFlowTestWithTurbine() = runTest {
    // given
    val fakeRepository = FakeRepository()
    val viewModel = ViewModel(fakeRepository)

    // when, then
    viewModel.event.test {
    	viewModel.initialize()
        assertThat(awaitItem()).isEqualTo(3)
    }
}

또는 test() 블록 내부에서 when문을 작성해 준다.

이 경우 SharedFlow의 값이 방출된 이후에 어설션을 하더라도, 테스트가 성공한다.

마무리

Turbine가 내부적으로 어떻게 동작하길래 test()와 awaitItem()만으로 테스트를 성공할 수 있는지는 아직 모르겠다.

Flow를 깊이 이해하지 않아도 테스트할 수 있다는 것이 Turbine의 큰 장점일 수도 있겠다.

반면 Turbine 사용 없이 테스트를 작성할 때는, Flow의 특성을 아주 잘 이해해야 올바르게 테스트할 수 있다는 느낌을 받았다.

프로젝트의 테스트 코드 퀄리티를 위해 Turbine를 알아봤지만, 아직 실제 코드에 적용하지는 않았다.

프로젝트가 MVP 단계인 만큼, 복잡한 테스트가 필요하지 않을 거라 판단했기 때문이다.

Turbine는 Flow를 편리하게 테스트할 수 있도록 도와주지만,

무조건적인 외부 라이브러리 사용보다는 상황에 따라 선택하는 것을 선호한다.

Turbine의 test 함수 블록 내에서 사용할 수 있는 유용한 함수들을 정리하고 이 글을 마무리 하려고 한다.

특히 Flow의 완료 시점을 알지 못할 때, awaitComplete() 대신 cancelAndIgnoreRemainingEvents()를 사용한다.

cancelAndConsumeRemainingEvents(): Flow를 취소하고 남은 이벤트를 모두 소비한다. (소비한 결과를 List 형태로 반환)
cancelAndIgnoreRemainingEvents(): Flow를 취소하고 남은 이벤트를 모두 무시한다.
expectMostRecentItem(): 가장 최근의 Flow 값을 가져온다.
cancel(): Flow를 취소한다.

참고

https://jaeryo2357.tistory.com/115

https://developer.android.com/kotlin/flow/test?hl=ko

https://medium.com/@vh.dev/testing-stateflow-and-sharedflow-with-ease-a-guide-to-seamless-testing-using-the-turbine-library-e0fb4ed2de66

Compose Side Effect 이해하기! (2)

hrniin — Mon, 24 Mar 2025 17:18:59 +0900

Compose Side Effect 이해하기! (1)

Side Effect란?컴포즈에서 Side Effect는 컴포저블 함수의 밖에서 발생하는 앱 상태에 대한 변경사항이다.예를 들어 사용자가 버튼을 클릭하면 다른 화면이 열리거나, 앱이 인터넷이 연결되어 있지 않

thdbs523.tistory.com

저번 포스팅에서 Side Effect이 어떤 건지 알아보고,

Side Effect와 관련된 컴포저블 함수 LaunchedEffect, DisposableEffect, SideEffect에 대해 알아봤다.

rememberCoroutineScope
rememberUpdatedState
derivedStateOf
produceState
collectAsStateWithLifecycle
snapshotFlow

이번엔 State를 더 효율적으로 관리하기 위한 여섯 개의 API를 알아보려고 한다!

rememberCoroutineScope

@Composable
inline fun rememberCoroutineScope(
    crossinline getContext: @DisallowComposableCalls () -> CoroutineContext = {
        EmptyCoroutineContext
    }
): CoroutineScope

rememberCoroutineScope는 함수를 호출한 컴포지션의 CoroutineScope를 반환하는 컴포저블 함수다.

따라서 컴포지션을 종료하면 코루틴 스코프도 취소된다.

컴포저블 외부에서 컴포지션의 생명주기와 동일한 코루틴을 실행하려는 경우 주로 사용한다.

rememberCoroutineScope 사용 예시

일부 Compose API는 suspend 함수다.

만약 이 Compose API를 컴포저블 함수 바깥에서 호출해야 한다면, LaunchedEffect를 사용할 수도 없을 것이다.

가장 대표적인 예시로 Snackbar가 있다.

val coroutineScope = rememberCoroutineScope()
val snackBarHostState = remember { SnackbarHostState() }

Scaffold(
    snackbarHost = { SnackbarHost(snackBarHostState) },
) { innerPadding ->
    Button(
        onClick = {
            coroutineScope.launch {
                snackBarHostState.showSnackbar("Button Click")
            }
        },
    ) {
        Text(text = "Snackbar Button")
    }

SnackBarHostState의 showSnackbar 함수는 suspend 함수다.

컴포저블이 아닌 버튼의 onClick 블록에서 실행되기 때문에, LaunchedEffect를 사용할 수 없다.

이때 컴포저블의 생명주기와 동일한 스코프를 통해 코루틴을 생성하면 showSnackbar를 호출할 수 있다.

컴포저블이 종료되면 해당 코루틴도 종료되기 때문에 안전하다.

LaunchedEffect vs rememberCoroutineScope

LaunchedEffect와 rememberCoroutineScope 모두 코루틴을 생성하고 suspend 함수를 호출하기 위해 사용한다.

그럼 LaunchedEffect를 대신해서 rememberCoroutineScope를 사용할 수 있을까?

결론부터 말하자면 그렇지 않다!

LaunchedEffect는 컴포저블 함수이므로 컴포저블 함수 내에서만 호출할 수 있다.

컴포지션과 연관된 Side Effect를 실행하고자 할 때 사용한다.

rememberCoroutineScope는 컴포저블과 동일한 코루틴 스코프를 생성하기 때문에, 컴포저블 외부에서 중단 함수를 호출할 수 있다.

코루틴 스코프로 생성한 코루틴은 컴포지션 여부와 무관하게 실행된다.

만약 컴포저블 함수에서 LauncedEffect 대신 scope.launch 를 사용했다면,

리컴포지션이 발생하여 컴포저블 함수가 호출될 때마다 코루틴이 계속 실행될 것이다.

따라서 리소스를 낭비하게 되며, LaunchedEffect를 대신해서 rememberCoroutineScope를 사용할 수 없다.

둘의 용도를 구분하여 적절히 사용해야 한다.

rememberUpdatedState

@Composable
fun <T : Any?> rememberUpdatedState(newValue: T): State<T>

rememberUpdatedState는 항상 최신 값으로 State를 업데이트하는 컴포저블 함수다.

@Composable
fun <T> rememberUpdatedState(newValue: T): State<T> = remember {
    mutableStateOf(newValue)
}.apply { value = newValue }

내부 구현도 매우 간단하다.

인자로 들어온 newValue로 MutableState를 생성하고, 인자로 들어온 값이 변경될 때마다 value에 새로운 값을 대입한다.

즉, 항상 최신의 값이 State에 반영된다.

rememberUpdatedState 사용 예시

먼저 rememberUpdatedState를 사용하지 않았을 때의 예시를 보자.

@Composable
fun LandingScreen(onTimeout: () -> Unit, modifier: Modifier = Modifier) {
    Box(modifier = modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
        LaunchedEffect(onTimeout) {
            delay(SplashWaitTime)
            onTimeout()
        }

        Image(painterResource(id = R.drawable.ic_crane_drawer), contentDescription = null)
    }
}

위 예시에서는 필요한 데이터를 모두 로드한 후, onTimeout을 실행시켜 랜딩 화면을 종료시킨다. (데이터 로드를 delay로 대체했다)

하지만 위 코드는 문제가 있다.

데이터 로드나 delay와 같은 Side Effect가 실행되는 동안 onTimeout이 변경되면, Side Effect가 끝난 후 최신 상태의 onTimeout이 호출된다는 보장이 없다.

이를 해결하기 위해 rememberUpdatedState를 사용할 수 있다.

@Composable
fun LandingScreen(onTimeout: () -> Unit, modifier: Modifier = Modifier) {
    Box(modifier = modifier.fillMaxSize(), contentAlignment = Alignment.Center) {
        val currentOnTimeout by rememberUpdatedState(onTimeout)

        LaunchedEffect(Unit) {
            delay(SplashWaitTime)
            currentOnTimeout()
        }

        Image(painterResource(id = R.drawable.ic_crane_drawer), contentDescription = null)
    }
}

rememberUpdatedState를 사용하여 onTimeout을 저장한다.

만약 Side Effect가 실행되는 동안 onTimeout이 변경되어도, rememberUpdatedState 내부에서 State를 업데이트한다.

만약 onTimeout이 rememberUpdatedState이 아닌 일반 State였다면 어떨까?

변경사항이 발생하더라도, value에 직접 최신 값을 대입해준 것이 아니기 때문에 이전 예제와 동일한 문제가 발생할 것이다.

반면에 rememberUpdatedState는 값이 변경될 때마다 value에 값을 대입하기 때문에 항상 최신 값이라는 것을 보장한다.

rememberUpdatedState는 람다가 Side Effect 동안 계속 유지되거나, 컴포지션으로 계산되는 값을 참조하는 경우에 사용한다.

LaunchedEffect에서 람다를 호출하는 경우 일반적으로 rememberUpdatedState를 사용한다.

derivedStateOf

@StateFactoryMarker
fun <T : Any?> derivedStateOf(calculation: () -> T): State<T>

derivedStateOf는 다른 State로 새로운 State를 계산하고 싶을 때 사용한다.

derivedStateOf의 calculation 블록은 블록 내부에서 사용된 State가 변경될 때마다 실행된다.

하지만 컴포저블 함수는 기존 값과 계산 결과값이 다를 때만 리컴포지션된다.

derivedStateOf 사용 예시

val showButton = listState.firstVisibleItemIndex > 0

firstVisibleItemIndex는 현재 화면에서 가장 첫 번째로 보이는 리스트 아이템의 인덱스를 나타낸다.

firstVisibleItemIndex는 스크롤할 때마다 변경되기 때문에, showButton도 그만큼 자주 변경되고, 자주 리컴포지션된다.

val showButton by remember {
    derivedStateOf {
        listState.firstVisibleItemIndex > 0
    }
}

하지만 derivedStateOf를 사용하면 true나 false로 값이 변경될 때만 리컴포지션된다.

즉, firstVisibleItemIndex가 변경되어도, 실제 showButton의 값이 변경되었을 때만 리컴포지션되어 최적화할 수 있다.

produceState

@Composable
fun <T : Any?> produceState(
    initialValue: T, 
    producer: suspend ProduceStateScope<T>.() -> Unit
): State<T>

produceState를 사용하면 Compose가 아닌 상태를 Compose State로 변환할 수 있다.

예를 들어 Flow, LiveData, RxJava와 같은 Observable 객체를 State로 변환한다.

하나의 State를 반환하기 때문에, 동일한 값을 설정하면 리컴포지션이 발생하지 않는다.

initialValue를 통해 반환된 State의 초기값을 지정한다.
producer 블록 내에서는 State의 value를 사용해 State에 값을 지정한다.

val currentPerson by
    produceState<Person?>(null, viewModel) {
        val disposable = viewModel.registerPersonObserver { person -> value = person }
        awaitDispose { disposable.dispose() }
    }

코루틴을 사용하지만, 중단되지 않는 경우에도 produceState를 사용할 수 있다.

이 때 produceState 블록의 코루틴이 종료되는 경우 (컴포지션 종료, 데이터 변경, 오류 발생) awaitDispose이 실행된다.

awaitDispose를 사용하여 자원을 해제한다.

@Composable
fun <T> produceState(
    initialValue: T,
    producer: suspend ProduceStateScope<T>.() -> Unit
): State<T> {
    val result = remember { mutableStateOf(initialValue) }
    LaunchedEffect(Unit) {
        ProduceStateScopeImpl(result, coroutineContext).producer()
    }
    return result
}

내부 구현을 보면 MutableState와 LaunchedEffect를 사용하고 있는 것을 알 수 있다.

initialValue를 가진 mutableState를 생성하고, LauncedEffect 내에서 producer를 호출한다.

즉, producer 블록을 실행하는 코루틴은 컴포지션이 시작하면 실행되고, 컴포지션이 종료되면 취소된다.

produceState에 key 지정하기

@Composable
fun <T> produceState(
    initialValue: T,
    vararg keys: Any?,
    producer: suspend ProduceStateScope<T>.() -> Unit
): State<T> {
    val result = remember { mutableStateOf(initialValue) }
    LaunchedEffect(keys = keys) {
        ProduceStateScopeImpl(result, coroutineContext).producer()
    }
    return result
}

LaunchedEffect와 마찬가지로 produceState도 여러 key를 지정할 수 있다.

key들 중 한 값이 바뀔 때마다 producer 블록이 호출된다.

produceState 사용 예시

@Composable
fun DetailsScreen(
    onErrorLoading: () -> Unit,
    modifier: Modifier = Modifier,
    viewModel: DetailsViewModel = viewModel()
) {
    val uiState by produceState(initialValue = DetailsUiState(isLoading = true)) {
        val cityDetailsResult = viewModel.cityDetails
        value = if (cityDetailsResult is Result.Success<ExploreModel>) {
            DetailsUiState(cityDetailsResult.data)
        } else {
            DetailsUiState(throwError = true)
        }
    }
}

위 예시에서는 ViewModel의 값을 통해 State<DetailsUiState>로 변환한다.

일반적으로 ViewModel에서는 Flow나 LiveData로 UiState를 가지고 있다. 또는 State를 직접 가지고 있는 경우도 있다.

보통 결과값에 따라 UiState를 달리하는 로직은 ViewModel에 존재하고, 컴포저블 함수에서는 이를 State로 변환하기만 한다.

따라서 매핑 로직을 작성하기에 적합한 produceState 함수를 사용할 일이 없다.

만약 ViewModel에서 Observable 객체가 아닌 값을 가지고 있거나, 컴포저블 함수에서 직접 데이터를 로드하여 UiState를 매핑해야 하는 경우 사용한다.

Flow나 LiveData를 State로 변환하는 컴포저블 함수도 내부적으로 produceState를 사용하고 있다.

collectAsStateWithLifecycle

@Composable
fun <T : Any?> Flow<T>.collectAsStateWithLifecycle(
    initialValue: T,
    lifecycle: Lifecycle,
    minActiveState: Lifecycle.State = Lifecycle.State.STARTED,
    context: CoroutineContext = EmptyCoroutineContext
): State<T>

collectAsStateWithLifecycle를 사용하면 Flow를 State로 변환할 수 있다.

Flow 값이 수집될 때마다 State가 변경되어 리컴포지션 된다.

@Composable
fun <T> Flow<T>.collectAsStateWithLifecycle(
    initialValue: T,
    lifecycle: Lifecycle,
    minActiveState: Lifecycle.State = Lifecycle.State.STARTED,
    context: CoroutineContext = EmptyCoroutineContext
): State<T> {
    return produceState(initialValue, this, lifecycle, minActiveState, context) {
        lifecycle.repeatOnLifecycle(minActiveState) {
            if (context == EmptyCoroutineContext) {
                this@collectAsStateWithLifecycle.collect { this@produceState.value = it }
            } else withContext(context) {
                this@collectAsStateWithLifecycle.collect { this@produceState.value = it }
            }
        }
    }
}

내부적으로는 위에서 설명했던 produceState를 사용하고 있다.

lifecycle.repeatOnLifecycle은 Android View와 MVVM을 사용하면서 많이 작성했을 코드다.

즉, repeatOnLifecycle을 통해 생명주기에 따라 Flow를 옵저빙해주고, Flow가 collect될 때마다 새로운 State의 value에 넣어주는 것이다.

collectAsState와의 차이

collectAsState는 collectAsStateWithLifecycle와 동일하게, State로 Flow의 값을 수집하는 함수다.

그렇다면 둘의 차이는 뭘까?

함수명에서 알 수 있듯이, collectAsStateWithLifecycle는 생명 주기를 인식한다는 것이다.

collectAsStateWithLifecycle의 매개변수 minActiveState는 기본적으로 Lifecycle.State.STARTED이다.

현재 화면의 생명 주기가 최소 STARTED일 때 값을 수집하고, STOP 이후에는 값을 수집하지 않는다.

즉, 앱이 백그라운드에 있을 때는 값을 수집하지 않기 때문에 불필요한 리소스 낭비를 방지할 수 있다.

minActiveState를 사용해서 값을 수집하거나 중지할 최소 상태를 지정할 수도 있다.

@Composable
fun <T : R, R> Flow<T>.collectAsState(
    initial: R,
    context: CoroutineContext = EmptyCoroutineContext
): State<R> = produceState(initial, this, context) {
    if (context == EmptyCoroutineContext) {
        collect { value = it }
    } else withContext(context) {
        collect { value = it }
    }
}

반면에 collectAsState는 앱이 백그라운드에 있을 때도 계속 값을 수집한다.

그래서 생명 주기를 관리해야 하는 안드로이드가 아닌 다른 플랫폼에서 Compose를 개발할 때 collectAsState를 사용한다.

snapshotFlow

fun <T> snapshotFlow(block: () -> T): Flow<T>

snapshotFlow를 사용하면 State를 Flow로 변환할 수 있다.

블록 내의 State가 변경되면 블록이 실행되고, Flow에 값을 내보낸다,

여기서 주의할 점은 새로운 값이 이전에 내보낸 값과 다른 경우에만 Flow에 값을 내보낸다는 점이다.

연속으로 중복된 값을 내보내지 않는다는 점에서는 Flow의 distinctUntilChanged와 비슷하다.

snapshotFlow 사용 예시

LaunchedEffect(listState) {
    snapshotFlow { listState.firstVisibleItemIndex }
        .map { index -> index > 0 }
        .distinctUntilChanged()
        .filter { it == true }
        .collect {
            MyAnalyticsService.sendScrolledPastFirstItemEvent()
        }
}

위 코드에서 listState.firstVisibleItemIndex는 Flow로 변환되어 firstVisibleItemIndex이 변경될 때마다 값을 내보낸다.

Flow 이점을 활용하여 새로운 값을 계산하고 싶을 때 주로 사용한다.

출처

https://medium.com/androiddevelopers/consuming-flows-safely-in-jetpack-compose-cde014d0d5a3

https://developer.android.com/develop/ui/compose/side-effects?hl=ko

https://developer.android.com/codelabs/jetpack-compose-advanced-state-side-effects?hl=ko&continue=https%3A%2F%2Fdeveloper.android.com%2Fcourses%2Fpathways%2Fjetpack-compose-for-android-developers-3%3Fhl%3Dko%23codelab-https%3A%2F%2Fdeveloper.android.com%2Fcodelabs%2Fjetpack-compose-advanced-state-side-effects#0

https://tourspace.tistory.com/412

Compose Side Effect 이해하기! (1)

hrniin — Thu, 27 Feb 2025 00:21:28 +0900

Side Effect란?

컴포즈에서 Side Effect는 컴포저블 함수의 밖에서 발생하는 앱 상태에 대한 변경사항이다.

예를 들어 사용자가 버튼을 클릭하면 다른 화면이 열리거나, 앱이 인터넷이 연결되어 있지 않을 때의 메시지 등이 될 수 있다.

기본적으로 컴포저블 함수는 Side Effect에 자유로워야 한다.

이때 자유로워야 한다는 말은, 컴포저블 함수를 트리거하기 위해서는 파라미터를 변경하거나 컴포저블을 재호출해야 한다는 뜻이다.

컴포저블 내부에서 컴포저블 외부에 있는 변수나 동작에 영향을 주도록 설계해서는 안 된다.

하나의 컴포저블에 대해 리컴포지션이 여러번 발생할 수 있고, 여러 스레드에서 호출될 수 있기 때문이다.

Side Effect를 이해하고 잘 활용하기 위해, 관련된 컴포저블 함수를 알아보려고 한다!

Side Effect를 처리하기 위해 아래와 같은 함수들이 있다.

LaunchedEffect
DisposableEffect
SideEffect
rememberCoroutineScope
rememberUpdatedState
produceState
derivedStateOf
snapshotFlow

이번 포스팅에서는 LaunchedEffect, DisposableEffect, SideEffect를 각각 알아보고, 비교해 보려고 한다.

나머지 함수들은 다음 포스팅에......!

LaunchedEffect

@Composable
fun LaunchedEffect(
    key1: Any?, 
    block: suspend CoroutineScope.() -> Unit
)

먼저 컴포즈를 개발하며 가장 많이 사용하는 LaunchedEffect이다.

LaunchedEffect는 컴포저블 안에서 안전하게 suspend 함수를 호출하기 위해 사용하는 컴포저블 함수다.

LaunchedEffect의 key

@Composable
fun LaunchedEffect(
    key1: Any?,
    block: suspend CoroutineScope.() -> Unit
)

LaunchedEffect의 매개변수로 key를 전달할 수 있다.

key가 변경되면 LaunchedEffect의 내부 블록이 다시 호출된다.

@Composable
fun LaunchedEffect(
    key1: Any?,
    key2: Any?,
    block: suspend CoroutineScope.() -> Unit
)

@Composable
fun LaunchedEffect(
    key1: Any?,
    key2: Any?,
    key3: Any?,
    block: suspend CoroutineScope.() -> Unit
)

@Composable
fun LaunchedEffect(
    vararg keys: Any?,
    block: suspend CoroutineScope.() -> Unit
)

여러 key 매개변수를 가지는 함수들이 오버로딩되어 있기 때문에, 개수 제한 없이 여러 key를 지정할 수 있다.

여러 key 중 하나라도 변경이 일어나면, LaunchedEffect의 내부 블록이 다시 호출된다.

두 개 이상의 값이 변경될 때 하나의 로직을 수행하고 싶을 때 사용할 수 있다.

상수를 key로 사용하기

LaunchedEffect(Unit) {
    viewModel.fetchMeetings()
}

컴포저블의 수명 주기 동안 한 번만 실행시켜야 하는 로직인 경우, Unit, 1, false처럼 변하지 않는 상수를 key로 사용한다.

예를 들어 ViewModel에서 데이터를 가져오는 함수를 한 번만 호출하기 위해, LaunchedEffect(Unit) { ... }를 사용할 수 있다.

configuration change에도 컴포저블은 리컴포지션되기 때문에, LaunchedEffect(Unit) 내부 블록이 실행된다.

즉, Activity의 onCreate()에서 함수를 호출하는 것과 유사하다.

configuration change마다 호출하지 않으려면 이러한 함수 호출을 ViewModel 내부에서 하는 것이 좋다.

LaunchedEffect의 코루틴 생명주기

LaunchedEffect는 suspend 함수를 호출할 수 있는 함수다.

그렇다면 suspend 함수가 호출되는 코루틴의 생명주기는 어떻게 될까?

먼저 컴포저블이 컴포지션을 시작하면 현재 컴포지션의 CoroutineContext에서 코루틴이 실행된다.

컴포저블이 컴포지션을 종료하면 코루틴이 취소된다.

또한 LaunchedEffect의 key가 변경되면, 기존 코루틴이 취소되고 새 코루틴이 실행된다.

DisposableEffect

@Composable
fun DisposableEffect(
    key1: Any?,
    effect: DisposableEffectScope.() -> DisposableEffectResult
): Unit

DisposableEffect는 key가 변경되면 내부 블록이 다시 실행된다는 점에서 LaunchedEffect와 유사하다.

그런데 DisposableEffect는 컴포저블이 컴포지션을 종료했을 때 자원을 정리해야 하는 경우 사용한다.

DisposableEffect의 onDispose

class DisposableEffectScope {
    inline fun onDispose(
        crossinline onDisposeEffect: () -> Unit
    ): DisposableEffectResult = object : DisposableEffectResult {
        override fun dispose() {
            onDisposeEffect()
        }
    }
}

DisposableEffect의 effect 블록은 DisposableEffectScope를 리시버로 가지고 있다.

DisposableEffectScope는 유일한 함수로 onDispose를 가지고 있는데, 이 함수는 컴포저블이 컴포지션을 종료했을 때 실행된다.

즉, DisposableEffect의 내부 블록에서 onDispose를 호출하여 컴포저블이 종료됐을 때의 로직을 지정해줄 수 있다.

onDispose 사용 예시

DisposableEffect(lifecycleOwner) {
    val observer =
        LifecycleEventObserver { _, event ->
            // ...
        }
    lifecycleOwner.lifecycle.addObserver(observer)
    onDispose {
        lifecycleOwner.lifecycle.removeObserver(observer)
    }
}

예를 들어 LifecycleEventObserver와 함께 DisposableEffect를 사용할 수 있다.

lifecycle이 변경될 때마다 실행할 로직을 작성하고, lifecycleOwner에 observer를 추가한다.

그리고 onDispose 내부에서 removeObserver를 호출하여 컴포저블의 컴포지션이 종료되었을 때 Observer를 제거한다.

onDispose에서 removeObserver를 호출하지 않으면, observer가 lifecycleOwner에 계속 남아있게 되어 메모리 누수나 예상치 못한 버그가 발생할 수 있다.

SideEffect

@Composable
fun SideEffect(
    effect: () -> Unit
)

SideEffect는 컴포저블 내부의 상태를 컴포저블 외부와 공유하기 위해 사용하는 컴포저블 함수다.

SideEffect의 내부 블록 effect는 리컴포지션이 완료될 때마다 실행된다.

LaunchedEffect와 다르게 내부 블록이 suspend 함수가 아니고, UI 스레드에서 동기적으로 실행된다.

@Composable
fun rememberFirebaseAnalytics(user: User): FirebaseAnalytics {
    val analytics: FirebaseAnalytics = remember {
        FirebaseAnalytics()
    }
    SideEffect {
        analytics.setUserProperty("userType", user.userType)
    }
    return analytics
}

Compose의 State와 관련 없는 작업을 수행할 때 주로 사용된다.

예를 들어 로깅이나 통계, 외부 객체 업데이트 등이 될 수 있다.

LaunchedEffect vs DisposableEffect vs SideEffect

LaunchedEffect

특정 시점에만 실행되어야 하는 경우 사용한다.
key가 변경될 때마다 실행된다.

DisposableEffect

자원 해제가 필요한 경우 사용한다.
key가 변경될 때마다 실행된다.
onDispose 함수로 자원을 해제할 수 있다.

SideEffect

리컴포지션이 완료될 때마다 실행되어야 하는 경우 사용한다.

3.3 채널과 플로우 - 핫 데이터 소스와 콜드 데이터 소스

hrniin — Sun, 16 Feb 2025 19:02:08 +0900

우리가 사용하는 대부분의 데이터 소스는 핫 스트림 데이터와 콜드 스트림 데이터 두 가지로 구분할 수 있다.

즉, 이 두 가지의 차이를 이해하는 것이 중요하다.

핫	콜드
컬렉션(List, Set)	Sequence, Stream
Channel	FLow, Rx.Java 스트림

(List, Set과 같은) 컬렉션은 핫이고, Sequence와 자바의 Stream은 콜드다.

Channel은 핫이고, Flow와 (Observable, Single과 같은) Rxlava 스트림은 콜드다.

핫 vs 콜드

핫 데이터 스트림은 열정적이라 데이터를 소비하는 것과 무관하게 원소를 생성한다.

반면에 콜드 데이터 스트림은 게을러서 요청이 있을 때만 작업을 수행하며, 아무것도 저장하지 않는다.

fun main() {
    val l = buildList {
        repeat(3) {
            add("User$it")
            println("L: Added User")
        }
    }

    val l2 = l.map {
        println("L: Processing")
        "Processed $it"
    }

    val s = sequence {
        repeat(3) {
            yield("User$it")
            println("S: Added User")
        }
    }

    val s2 = s.map {
        println("S: Processing")
        "Processed $it"
    }
}

L: Added User
L: Added User
L: Added User
L: Processing
L: Processing
L: Processing

리스트(핫)와 시퀀스(콜드)를 사용할 때 그 차이가 드러난다.

리스트의 빌더와 연산은 즉각 실행된다. 시퀀스는 원소가 실제로 필요할 때까지 빌더와 연산이 실행되지 않는다.

즉, 콜드 데이터 스트림은 (Sequence, Stream, Flow)

무한할 수 있다.
최소한의 연산만 수행한다.
(중간에 생성되는 값들을 저장하지 않기 때문에) 메모리를 적게 사용한다.

중간 연산(map, filter 등)은 이전 시퀀스에 새로운 연산을 추가할 뿐이다.

최종 연산이 호출되기 전까지는 아무런 연산을 수행하지 않고, 최종 연산에서 모든 작업을 실행한다.

fun m(i: Int): Int {
    print("m$i ")
    return i * i
}

fun f(i: Int): Boolean {
    print("f$i ")
    return i >= 10
}

fun main() {
    listOf(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
        .map { m(it) }
        .find { f(it) }
        .let { print(it) }
    // m m2 m3 m4 m5 m6 m7 m8 mg m10 f1 f4 f9 f16 16

    println()

    sequenceOf(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
        .map { m(it) }
        .find { f(it) }
        .let { print(it) }
    // m f1 m2 f4 m3 19 m4 f16 16
}

위 예제에서 시퀀스의 find는 map에게 첫 번째 원소를 달라고 한다.

map은 sequenceOf에게 첫 번째 원소를 받고, map을 수행한 뒤 find에 넘긴다.

find는 위에서 받은 원소(1)가 요구 사항에 부합하는지 확인한다.

요구사항을 만족하지 못한다면, find는 적절한 원소를 찾을 때까지 계속해서 질의한다.

반면에 리스트는 중간 과정에서 모든 원소에 대한 계산을 수행하고, 결과가 담긴 컬렉션을 각각 생성한다.

따라서 리스트는 원소의 처리 순서도 다르고, 컬렉션 처리 과정에서 좀더 많은 메모리를 필요로 하며, 더 많은 연산을 수행한다.

fun m(i: Int): Int {
    print("m$i ")
    return i * i
}

fun main() {
    val l = listOf(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
        .map { m(it) } // ml m2 m3 m4 m5 m6 m7 m8 m9 m10

    println(l) // [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
    println(l.find { it > 10 }) // 16
    println(l.find { it > 10 }) // 16
    println(l.find { it > 10 }) // 16

    val s = sequenceOf(1, 2, 3, 4, 5, 6, 7, 8, 9, 10)
        .map { m(it) }

    println(s.toList()) // [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
    println(s.find { it > 10 }) // m1 m2 m3 m4 16
    println(s.find { it > 10 }) // m1 m2 m3 m4 16
    println(s.find { it > 10 }) // ml m2 m3 m4 16
}

리스트는 원소를 가지고 있는 컬렉션이지만, 시퀀스는 원소를 어떻게 계산할지 정의한 것 뿐이다.

핫 데이터 스트림은

항상 사용 가능한 상태다. (각 연산이 최종 연산이 될 수 있다)
여러 번 사용되었을 때 매번 결과를 다시 계산할 필요가 없다.

핫 채널, 콜드 플로우

val channel = produce {
    while (true) {
        val x = computeNextValue()
        send(x)
    }
}

val flow = flow {
    while (true) {
        val x = computeNextValue()
        emit(x)
    }
}

다시 코루틴으로 돌아와서, 콜드 데이터 스트림인 플로우를 생성해 보자.

플로우를 생성하는 가장 일반적인 방법은 produce 함수와 비슷한 flow를 사용하는 것이다.

private fun CoroutineScope.makeChannel() = produce {
    println("Channel started")
    for (i in 1..3) {
        delay(1000)
        send(i)
    }
}

suspend fun main() = coroutineScope {
    val channel = makeChannel()

    delay(1000)
    println("Calling channel...")
    for (value in channel) {
        println(value)
    }

    println("Consuming again...")
    for (value in channel) {
        println(value)
    }
}

Channel started
(1초 후)
Calling channel...
1
(1초 후)
2
(1초 후)
3
(1초 후)
Consuming again...

채널은 핫 데이터 스트림이기 때문에 소비되는 것과 상관없이 값을 곧바로 생성한 후, 값을 가지고 있는다.

수신자가 얼마나 많은지는 신경쓰지 않는다.

별도의 코루틴에서 계산을 곧바로 수행한다. 따라서 produce는 CoroutineScope 확장 함수의 코루틴 빌더가 된다.

채널은 곧바로 시작되지만, 버퍼의 크기가 0인 랑데뷰인 채널이기 때문에 수신자가 원소를 받을 때까지 중단된다.

각 원소는 단 한 번만 받을 수 있기 때문에, 첫 번째 수신자가 모든 원소를 받으면 두 번째 소비자는 채널이 닫힌 후기 때문에 아무 원소도 받을 수 없다.

private fun makeFlow() = flow {
    println("Flow started")
    for (i in 1..3) {
        delay(1000)
        emit(i)
    }
}

suspend fun main() = coroutineScope {
    val flow = makeFlow()

    delay(1000)
    println("Calling flow...")
    flow.collect { value -> println(value) }
    println("Consuming again...")
    flow.collect { value -> println(value) }
}

(1초 후)
Calling flow...
Flow started
(1초 후)
1
(1초 후)
2
(1초 후)
3
Consuming again...
Flow started
(1초 후)
1
(1초 후)
2
(1초 후)
3

플로우는 콜드 데이터 소스이기 때문에 값이 필요할 때만 생성한다.

flow는 단지 최종 연산이 호출될 때 원소가 어떻게 생성되어야 하는지 정의한 것에 불과하다.

그래서 flow 빌더는 코루틴 빌더가 아니고, 어떠한 처리도 하지 않는다. CoroutineScope가 필요하지 않다.

flow 빌더는 최종 연산의 스코프에서 실행된다.

coroutineScope 같은 코루틴 스코프 함수처럼, 중단 함수의 컨티뉴에이션 객체로부터 스코프를 가지고 온다.

요약

핫 데이터 소스는 열정적이다.
- 가능한 빨리 원소를 만들고 저장하며, 원소가 소비되는 것과 무관하게 생성한다.
- 예를 들어 컬렉션(List, Set), Channel이 있다.

콜드 데이터 소스는 게으르다.
- 일반적으로 원소를 저장하지 않고, 필요할 때 원소를 생성한다.
- 최종 연산에서 값을 생성한다. 중간 과정에서는 무엇을 해야 할지만 정의한 것이다.
- 연산은 최소한으로 수행하며, 무한정일 수 있다.
- 예를 들어 Sequence, 자바 Stream, Flow, RxJava 스트림(Observable, Single)이 있다.

출처

https://www.yes24.com/product/goods/123034354

3.2 채널과 플로우 - 셀렉트

hrniin — Sun, 16 Feb 2025 18:23:48 +0900

코루틴에는 select 함수가 있다. 이 select 함수는 가장 먼저 완료되는 코루틴의 결과를 기다리는 역할을 한다.

또한 여러 개의 채널 중 남은 공간이 있는 채널에 데이터를 보내거나, 여러 개의 채널 중 원소가 존재하는 채널로부터 원소를 받을 수도 있다.

코루틴 사이에 경합을 일으키거나, 여러 개의 데이터 소스로부터 나오는 결괏값을 합칠 수도 있다.

select 함수는 코틀린 코루틴이 출시된 이후부터 사용이 가능했지만, 아직 실험용이다. 즉, API 형태가 바뀔 가능성이 있다.

select를 실제로 사용하는 경우가 드물기 때문에, 안정화될 가능성도 적다.

지연되는 값 선택하기

여러 개의 소스에 데이터를 요청한 뒤, 가장 빠른 응답만 얻는 경우를 생각해 보자.

가장 쉬운 방법은 요청을 여러 개의 비동기 프로세스로 시작한 뒤, select 함수 내부에서 값을 기다리는 것이다.

select 내부에서는 람다 내 Deferred의 onAwait 함수를 호출한다. 또한 람다 내에서 값을 변환할 수도 있다.

suspend fun requestData1(): String {
    delay(100_000)
    return "Data1"

}

suspend fun requestData2(): String {
    delay(1000)
    return "Data2"
}

val scope = CoroutineScope(SupervisorJob())

suspend fun askMultipleForData(): String {
    val defData1 = scope.async { requestData1() }
    val defData2 = scope.async { requestData2() }

    return select {
        defData1.onAwait { it }
        defData2.onAwait { it }
    }
}

suspend fun main(): Unit = coroutineScope {
    println(askMultipleForData())
}

(1초 후)
Data2

하나의 비동기 작업이 먼저 완료되면 select 함수도 바로 끝나기 때문에, 하나의 결괏값만 반환된다.

위 예제에서는 외부의 스코프에서 async 코루틴이 시작된다.

즉, askMultipleForData를 호출한 코루틴을 취소해도, 외부 스코프에서 시작된 async 코루틴은 취소되지 않는다.

suspend fun askMultipleForData(): String = coroutineScope {
    select<String> {
        async { requestData1() }.onAwait { it }
        async { requestData2() }.onAwait { it }
    }
}

suspend fun main(): Unit = coroutineScope {
    println(askMultipleForData())
}

(100초 후)
Data2

coroutineScope를 사용해서 비동기 작업과 select를 하나의 스코프에서 시작시키는 예제를 보자.

스코프는 모든 자식 코루틴이 끝날 때까지 기다리기 때문에, 1초가 아닌 100초 후에서야 Data2를 결과로 받는다.

suspend fun askMultipleForData(): String = coroutineScope {
    select<String> {
        async { requestData1() }.onAwait { it }
        async { requestData2() }.onAwait { it }
    }.also { coroutineContext.cancelChildren() }
}

suspend fun main(): Unit = coroutineScope {
    println(askMultipleForData())
}

(1초 후)
Data2

100초 후 Data2를 결과로 받는 문제를 해결하기 위해, 위처럼 코드를 수정했다.

select가 값을 생성하고 난 후, also 블럭 내부에서 자식 코루틴을 취소시킨다.

이처럼 async와 select를 사용하면 코루틴끼리 경합하는 상황을 쉽게 구현할 수 있지만, 스코프를 명시적으로 취소해야 한다.

suspend fun askMultipleForData(): String = raceOf(
    { requestData1() },
    { requestData2() },
)

suspend fun main(): Unit = coroutineScope {
    println(askMultipleForData())
}

(1초 후)
Data2

스코프를 명시적으로 취소하는 방식은 약간 복잡하기 때문에, 헬퍼 함수를 정의하거나 raceOf 함수를 지원하는 외부 라이브러리를 사용할 수 있다.

추후 raceOf 함수를 직접 구현해 볼 것이다.

위 예제에서는 Splitties 라이브러리의 raceOf를 사용했다.

채널에서 값 선택하기

select 함수는 채널에서도 사용할 수 있다. select 람다 내에서 사용하는 주요 함수는 다음과 같다.

onReceive
- 채널이 값을 가지고 있을 때 선택된다.
- (receive 메서드처럼) 값을 받은 뒤 람다식의 인자로 사용한다.
- select는 람다식의 결괏값을 반환한다.
onReceiveCatching
- 채널이 값을 가지고 있거나 닫혔을 때 선택된다.
- 값을 나타내거나 채널이 닫혔다는 걸 알려주는 ChannelResult를 받아 람다식의 인자로 사용한다.
- select는 람다식의 결괏값을 반환한다.
onSend
- 채널의 버퍼에 공간이 있을 때 선택된다.
- (send 메서드처럼) 채널에 값을 보낸 뒤, 채널의 참조값으로 람다식을 수행한다.
- select는 Unit을 반환한다.

suspend fun CoroutineScope.produceString(
    s: String,
    time: Long
) = produce {
    while (true) {
        delay(time)
        send(s)
    }
}

fun main() = runBlocking {
    val fooChannel = produceString("foo", 210L)
    val barChannel = produceString("BAR", 500L)

    repeat(7) {
        select {
            fooChannel.onReceive {
                println("From fooChannel: $it")
            }
            barChannel.onReceive {
                println("From barChannel: $it")
            }
        }
    }

    coroutineContext.cancelChildren()
}

From fooChannel: foo
From fooChannel: foo
From barChannel: BAR
From fooChannel: foo
From fooChannel: foo
From barChannel: BAR
From fooChannel: foo

select 람다 내부에서는 여러 개의 채널로부터 결괏값을 얻기 위해 onReceive나 onReceiveCatching을 함께 사용한다.

fun main(): Unit = runBlocking {
    val c1 = Channel<Char>(capacity = 2)
    val c2 = Channel<Char>(capacity = 2)

    // 값을 보냄
    launch {
        for (c in 'A'..'H') {
            delay(400)
            select<Unit> {
                c1.onSend(c) { println("Sent $c to 1") }
                c2.onSend(c) { println("Sent $c to 2") }
            }
        }
    }

    // 값을 받음
    launch {
        while (true) {
            delay(1000)
            val c = select<String> {
                c1.onReceive { "$it from 1" }
                c2.onReceive { "$it from 2" }
            }
            println("Received $c")
        }
    }
}

Sent A to 1
Sent B to 1
Received A from 1
Sent C to 1
Sent D to 2
Received B from 1
Sent E to 1
Sent F to 2
Received C from 1
Sent G to 1
Received E from 1
Sent H to 1
Received G from 1
Received H from 1
Received D from 2
Received F from 2

select 함수에서 onSend를 호출하면 버퍼에 공간이 있는 채널에 원소를 보내는 용도로 사용할 수 있다.

요약

select는 가장 먼저 완료되는 코루틴의 결괏값을 기다릴 때나, 여러 개의 채널 중 전송 또는 수신 가능한 채널을 선택할 때 유용하다.

주로 채널과 함께 사용하지만, async 코루틴의 경합을 구현하기 위해 사용할 수도 있다.

출처

https://www.yes24.com/product/goods/123034354