이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
둘의 근본 차이는 화면을 어떻게 그리느냐라고 봅니다. 기존 방식은 화면 구조를 미리 만들어 두고, 데이터가 바뀌면 그 요소를 찾아 일일이 고치는 쪽입니다. Compose는 지금 상태면 화면이 이래야 한다고 기술해 두면, 상태가 바뀔 때 알아서 다시 그리는 쪽입니다. 그래서 차이가 나뉩니다. 기존 방식은 찾아 고치는 코드가 늘수록 어디서 안 바뀌었는지 추적이 어렵고, Compose는 그 수작업이 줄어듭니다. 학부 프로젝트에서 상태에 따라 여러 군데를 직접 바꾸다 한 곳을 빠뜨려 화면이 어긋난 경험이 있는데, Compose로 같은 화면을 짜니 그 부류 버그가 줄었습니다. 다만 대가도 있습니다.
상태가 바뀔 때 다시 그리는 범위를 잘못 잡으면 불필요하게 자주 그려져 느려질 수 있어, 그 경계를 신경 써야 합니다. 그래서 신기술이라 덮어놓고가 아니라, 상태에 따라 화면이 자주 바뀌는 화면일수록 이득이 크다고 봅니다.
저는 둘을 기존 방식의 불편을 겪고 나서 비교하게 됐습니다. 기존 방식에서 화면을 짤 때, 구조를 정의하는 곳과 그걸 코드에서 찾아 바꾸는 곳이 떨어져 있어, 화면 하나 고치려면 두 군데를 오갔습니다. 빠뜨리면 데이터는 바뀌었는데 화면만 안 바뀌는 버그가 났습니다. Compose는 화면 모양과 그것을 결정하는 상태가 한 자리에 있어, 그 왕복과 누락이 줄었습니다. 그게 핵심 차이라고 봅니다. 다만 덮어놓고 낫다고 보진 않습니다.
이미 기존 방식으로 크게 짜인 화면을 통째로 옮기는 건 비용이 크고, 익숙하지 않으면 다시 그려지는 흐름을 잘못 짜 오히려 느려질 수 있습니다. 그래서 저는 새로 만드는 화면이나 상태 변화가 잦은 화면부터 적용하는 게 맞다고 봅니다. 신기술 여부보다 옮길 가치가 비용보다 큰지로 판단합니다.
Compose와 기존 방식을 저는 무엇을 얻고 무엇을 내주는지로 정리합니다. Compose는 상태와 화면을 한곳에 둬 수작업 갱신과 그 누락 버그를 줄이는 이득이 있습니다. 대신 다시 그려지는 범위를 제대로 못 잡으면 성능을 잃는 비용과, 기존 자산·익숙함을 버려야 하는 전환 비용을 치릅니다. 기존 방식은 그 반대입니다.
예측 가능하고 익숙하지만, 상태가 복잡해질수록 갱신 코드가 늘어 추적이 어렵습니다. 그래서 선택은 거의 상태 변화가 얼마나 잦고 복잡한가로 갈립니다. 학부 때 정적인 화면을 굳이 새 방식으로 짰다가 이득은 거의 없고 학습 비용만 든 경험이 있어, 지금은 변화가 잦은 화면일수록 Compose, 거의 안 바뀌는 화면이면 굳이 안 옮기는 쪽으로 봅니다. 신기술이라 좋은 게 아니라 상황이 그 거래를 정당화할 때 좋다고 생각합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.