프롤로그: 왜 내 앱은 네트워크만 연결하면 멈출까? (ANR과의 전쟁)
안녕하세요, 여러분! 15년 차 안드로이드 개발자이자, 현재 대규모 트래픽을 처리하는 서비스의 리드 개발자로 일하고 있는 동료입니다. 👋 개발자라면 누구나 한 번쯤, 아니 수십 번은 겪어봤을 악몽이 있습니다. 바로 'ANR(Application Not Responding)'과 'UI 프리징(Freezing)' 현상입니다. 사용자가 버튼을 눌렀는데 앱이 3초간 얼음처럼 굳어버리거나, 스크롤 하던 도중 화면이 뚝뚝 끊기는 경험, 혹시 있으신가요? 이는 단순히 "앱이 좀 느리네" 정도의 문제가 아닙니다. 구글 플레이 콘솔(Google Play Console) 통계에 따르면, ANR 발생률이 0.47%를 넘어가면 해당 앱의 노출 순위가 급격히 하락하며, 사용자의 50% 이상이 앱을 즉시 삭제한다는 충격적인 데이터가 있습니다.
솔직히 고백하자면, 저도 주니어 시절에는 메인 스레드(Main Thread)의 절대적인 중요성을 모르고 네트워크 요청이나 무거운 DB 작업을 덜컥 메인 스레드에 올려버린 적이 있습니다. 결과는 참혹했습니다. 와이파이 환경에서는 그럭저럭 돌아가던 앱이, 지하철이나 엘리베이터 같은 불안정한 네트워크 환경에서는 수시로 멈춰 섰습니다. 사용자는 "이 앱 고장 났어! 최악이야"라며 1점짜리 리뷰를 남기고 떠나갔고, 저는 그 리뷰를 보며 밤새 디버깅을 하며 쓴 커피를 들이켜야 했습니다. ☕ 그때 뼈저리게 깨달았습니다. "메인 스레드는 성역이다. 1ms라도 허투루 써서는 안 된다."라는 것을요.
과거에는 이 문제를 해결하기 위해 `AsyncTask`나 `RxJava` 같은 도구들을 사용해 비동기 처리를 구현했습니다. 하지만 `AsyncTask`는 메모리 누수(Memory Leak)의 온상이었고 안드로이드 11부터는 완전히 폐기(Deprecated) 되었습니다. `RxJava`는 강력했지만, 러닝 커브가 너무 높아 신입 팀원이 합류할 때마다 연산자를 이해시키는 데만 몇 달이 걸리기도 했죠. 그런데 말입니다, 코틀린 코루틴(Kotlin Coroutines)이 등장하면서 이 모든 판도가 바뀌었습니다. 마치 복잡한 비동기 처리를 동기 코드처럼 직관적이고 순차적으로 짤 수 있게 된 것이죠. 오늘은 제가 실전 프로젝트에서 겪은 수많은 시행착오와 성공 경험을 바탕으로, 어떻게 하면 코루틴을 활용해 '물 흐르듯 부드러운' 네트워크 통신을 구현할 수 있는지, 그리고 왜 코루틴이 정답인지 아주 상세하게 알려드리겠습니다. 🚀
1. 메인 스레드의 비밀과 16ms의 법칙 (UI 성능의 핵심)
UI 스레드는 왜 멈추면 안 될까요?
안드로이드 시스템의 UI 렌더링 메커니즘을 이해하려면 숫자에 민감해져야 합니다. 대부분의 스마트폰은 초당 60프레임(60fps)으로 화면을 그립니다. 이를 수학적으로 계산해보면, `1000ms / 60 ≈ 16.66ms`가 나옵니다. 즉, 1프레임을 그리는 데 우리에게 주어진 시간은 고작 16ms(밀리초)에 불과합니다. 이 짧은 시간 안에 앱은 레이아웃 측정(Measure), 배치(Layout), 그리기(Draw), 그리고 사용자 터치 입력 처리까지 모두 완벽하게 마쳐야 합니다. 만약 여러분이 네트워크 통신 같은 무거운 작업을 이 메인 스레드에서 수행해서 16ms를 1ms라도 넘겨버리면 어떻게 될까요?
시스템은 약속된 시간에 화면을 갱신하지 못하고 해당 프레임을 건너뛰게 됩니다. 이를 '프레임 드랍(Frame Drop)' 또는 'Jank'라고 부릅니다. 사용자는 이때 화면이 부드럽게 이어지지 않고 뚝뚝 끊기는 불쾌한 느낌을 받습니다. 만약 이 지연 시간이 누적되어 5초를 넘어가면? 안드로이드 시스템의 감시자인 'Activity Manager'와 'Window Manager'가 가차 없이 개입하여 "이 앱은 응답하지 않습니다"라는 공포의 ANR 다이얼로그를 띄우고, 사용자에게 앱을 강제 종료할 권한을 줍니다. 이는 사용자 경험(UX)에 있어 돌이킬 수 없는 최악의 시나리오입니다.
💡 고속도로 비유: 메인 스레드는 1차선 고속도로와 같습니다. 이곳은 아주 빠르게 달리는 스포츠카(UI 렌더링 작업)만 다녀야 합니다. 그런데 갑자기 거대한 컨테이너 트럭(네트워크 요청, DB 조회)이 1차선에 들어와서 짐을 싣고 내린다고 멈춰 섰다고 상상해 보세요. 뒤따르던 모든 스포츠카들이 급정거하고, 도로는 순식간에 주차장이 되어버리겠죠? 코루틴은 이 거대한 트럭을 전용 화물 도로(백그라운드 스레드)로 우회시키는 유능한 교통 경찰 역할을 합니다.
실제 제가 참여했던 월간 사용자(MAU) 100만 명 규모의 이커머스 앱 프로젝트에서의 일입니다. 상품 목록을 스크롤 할 때마다 작은 썸네일 이미지를 로딩하고 캐싱하는 코드가 메인 스레드에서 미세하게 동작하고 있었습니다. 고사양의 최신 갤럭시나 픽셀 폰에서는 티가 나지 않았지만, 저사양 보급형 기기를 사용하는 약 30%의 사용자들에게서 "스크롤이 너무 버벅거린다", "터치가 안 먹힌다"는 불만이 폭주했습니다. 'Systrace'와 프로파일러로 분석해보니, 메인 스레드가 평균 200ms씩 멈추고 있었습니다. 16ms의 12배가 넘는 시간이었죠. 이 경험은 저에게 "네트워크 통신, DB 접근, 무거운 연산은 무조건, 예외 없이 백그라운드로 격리해야 한다"는 철칙을 심어주었습니다.
2. 코루틴(Coroutines): 경량 스레드의 혁명
스레드와 코루틴, 무엇이 다르고 왜 혁명일까요?
많은 개발자분들이 "코루틴은 그냥 스레드 라이브러리 아닌가요?"라고 묻습니다. 하지만 기술적으로 깊이 들어가면 코루틴은 '경량 스레드(Light-weight Thread)'라고 불리며, 전통적인 스레드와는 작동 방식이 완전히 다릅니다. 전통적인 스레드(Thread)는 운영체제(OS) 커널 레벨에서 관리하며, 생성하고 스위칭(Context Switching)하는 데 많은 비용이 듭니다. 스레드 하나를 생성할 때마다 약 1MB 정도의 스택 메모리가 할당되는데, 만약 스레
댓글
댓글 쓰기