이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
둘의 핵심 차이를 저는 비동기를 어떻게 읽게 하느냐로 봅니다. RxJava는 데이터가 흐르는 파이프를 엮는 쪽이고, Coroutine은 비동기인데도 위에서 아래로 읽히게 쓰는 쪽입니다. 학부 프로젝트에서 같은 네트워크 호출 흐름을 둘로 짜 봤는데, RxJava는 연산자가 길어질수록 흐름을 눈으로 따라가기 어려웠고, Coroutine은 동기 코드처럼 읽혀 디버깅이 수월했습니다. 그래서 단순한 호출·취소 위주면 Coroutine을 선호합니다. 다만 대가가 있습니다.
여러 스트림을 실시간으로 합치고 변환하는 복잡한 데이터 흐름은 RxJava의 연산자가 더 깔끔합니다. 그래서 늘 Coroutine은 아닙니다. 흐름이 단순하고 읽힘이 중요하면 Coroutine, 스트림 합성이 핵심이면 RxJava 쪽으로 가릅니다. 지금도 비동기를 짤 땐 이게 호출 흐름인지 스트림 합성인지를 먼저 봅니다.
제가 비동기에서 가장 신경 쓰는 건 중간에 취소하거나 실패했을 때 깔끔하게 정리되느냐입니다. 예전에 화면을 떠났는데 백그라운드 작업이 안 멈춰 엉뚱한 갱신이 일어난 버그를 겪었습니다. Coroutine은 작업을 화면 수명에 묶어, 화면이 사라지면 같이 취소되는 구조라 그런 누수가 줄었습니다. RxJava도 구독 해제로 되지만, 해제를 빠뜨리기 쉬워 같은 실수를 반복했습니다. 그래서 취소·정리가 중요한 화면 작업은 Coroutine을 선호합니다. 다만 대가는 있습니다.
기존 코드가 RxJava로 크게 짜여 있으면, 섞어 쓰며 전환 비용이 듭니다. 그래서 늘 한쪽은 아니고, 새 코드·수명에 묶이는 작업은 Coroutine, 이미 RxJava로 된 큰 흐름은 그대로 두는 편입니다. 지금도 선택 전에 취소가 자동으로 되는 게 이 작업에 중요한가를 먼저 따집니다.
솔직히 저는 하나만 고집하지 않습니다. 둘은 잘하는 자리가 다릅니다. 호출하고 결과 받고 끝나는 단순 흐름은 Coroutine이 동기 코드처럼 읽혀 유지하기 쉽습니다. 반대로 입력이 계속 들어오고 그걸 실시간으로 거르고 합치는 흐름은 RxJava의 연산자가 같은 일을 훨씬 짧게 표현합니다. 학부 때 단순 호출까지 RxJava로 짰다가, 연산자 체인이 길어져 읽기 어려워진 경험이 있어 이 기준을 세웠습니다. 그 뒤로는 도구를 먼저 정하지 않고, 이 작업이 단발 호출인지 지속 스트림인지를 보고 거기 맞는 걸 고릅니다. 선호를 묻는다면, 단발·취소 중심이면 Coroutine, 스트림 합성이 핵심이면 RxJava지만 그것도 작업 성격이 정당화할 때만이라고 답합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.