이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 SwiftUI로 iOS 앱을 처음 만들며 Declarative UI를 경험했습니다. 처음에는 상태가 바뀌면 UI가 자동으로 갱신된다는 개념이 직관적이어서 빠르게 프로토타입을 만들었습니다. 그런데 공유 상태가 여러 뷰에 퍼지면서 예상치 못한 재렌더링이 발생했고, @ObservedObject와 @StateObject의 수명 주기 차이를 제대로 이해하지 못한 것이 원인이었습니다. 상태 소유권 규칙을 정리한 뒤 뷰 계층을 다시 설계하니 불필요한 렌더링이 사라지고 스크롤 성능이 눈에 띄게 개선됐습니다. 이 경험으로 Declarative UI는 상태 흐름을 먼저 설계하지 않으면 오히려 디버깅이 복잡해진다는 것을 배웠습니다.
학부 프로젝트에서 Jetpack Compose로 처음 화면을 짜다가 리스트가 스크롤될 때마다 깜빡이는 문제를 겪었습니다. 원인을 찾아보니 리스트 아이템에 key를 지정하지 않아 전체 재구성이 반복적으로 일어나는 것이었습니다. Declarative UI에서는 상태가 바뀔 때 변경된 부분만 재구성되어야 하는데, key가 없으면 어떤 항목이 바뀐 건지 판단하지 못합니다. key를 명시하고 remember로 불필요한 재계산을 막으니 깜빡임이 사라졌습니다. 처음에는 Compose가 알아서 최적화해준다고 생각했는데, 개발자가 힌트를 줘야 한다는 걸 그때 배웠습니다. 이후로 Declarative UI를 쓸 때는 key 전략과 상태 범위를 먼저 설계하는 습관이 생겼습니다.
인턴 기간에 SwiftUI로 폼 화면을 만들면서 텍스트 필드가 포커스를 잃을 때마다 입력값이 초기화되는 버그를 겪었습니다. 원인을 찾아보니 @State로 선언한 변수가 뷰 재구성 시마다 초기값으로 돌아가는 것이었습니다. Declarative UI는 뷰를 함수처럼 취급하기 때문에, 상태를 올바른 범위에 두지 않으면 재구성 때 날아갑니다.
@StateObject로 범위를 올리고 외부에서 주입하는 구조로 바꾸니 문제가 해결됐습니다. 이전에는 UIKit처럼 뷰가 한 번 그려지면 상태가 유지된다고 생각했는데, Declarative에서는 어디서 상태를 갖느냐가 설계의 핵심이라는 걸 직접 겪고 나서야 실감했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.