이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
안드로이드 앱에서 네트워크 요청과 UI 상태를 연결하는 데 Coroutines와 Flow를 함께 썼습니다. Coroutines는 suspend 함수로 비동기 호출을 직렬처럼 읽히게 해줘서, 중첩 콜백 체인을 정리하는 데 큰 도움이 됐습니다. StateFlow로 UI 상태를 단방향으로 흘려보내면서 화면 회전이나 백그라운드 복귀 시 상태가 유지되는 흐름을 안정적으로 만들 수 있었습니다. 어려웠던 건 Flow 연산자 체인에서 오류 처리였는데, catch를 어느 위치에 두느냐에 따라 다운스트림 영향이 달라져서 초반에 헷갈렸습니다.
구조적 동시성 덕분에 화면이 사라질 때 자동으로 취소되는 것이 메모리 누수 방지에 실질적으로 도움이 됐습니다.
Coroutines와 Flow를 쓰면서 가장 불편했던 점은 문제가 생겼을 때 어디서 값이 달라졌는지 추적하기 어렵다는 것이었습니다. 연산자 체인이 길어질수록 map·filter·flatMapLatest가 중첩되면서 중간 값이 어떻게 흘러가는지 로그로 확인하기 어려웠습니다.
onEach를 삽입해 값을 찍어보는 방식이 임시방편이 됐는데, 나중에 지우는 걸 잊어서 프로덕션 코드에 로그가 남은 적도 있었습니다. 다음 프로젝트에서는 한 체인에 연산자를 3개 이상 쌓지 않는 규칙을 팀에서 잡았고, 덕분에 디버깅 시간이 눈에 띄게 줄었습니다.
Flow는 선언적 파이프라인이라 간결하지만, 길어지면 추적 비용이 올라간다는 점을 직접 경험했고, 지금도 긴 체인보다 짧게 끊어 쓰는 편입니다.
Flow를 더 깊게 쓰게 된 계기는 토스트 메시지 같은 일회성 이벤트를 어떻게 보낼지 고민하면서였습니다. 처음에는 LiveData로 처리했는데, 화면이 재구성될 때 같은 이벤트가 다시 보이는 문제가 반복됐습니다. SharedFlow로 교체하면서 구독 시점 이후 발행된 이벤트만 받는 구조가 됐고, 화면 재구성 시 중복 이벤트가 사라졌습니다. replay=0 설정이 핵심이었는데, 처음에 이 값이 무슨 의미인지 몰라서 1로 두었다가 중복 이벤트가 재현됐습니다. 공식 문서와 실험을 반복하면서 Hot Flow와 Cold Flow의 차이를 제대로 이해하게 됐고, 이후에는 이벤트 용도에 맞게 SharedFlow와 StateFlow를 구분해서 쓰는 기준이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넛지헬스케어 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.