이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Jetpack Compose로 안드로이드 UI를 처음 코드로만 작성해봤습니다. XML 방식과 비교했을 때 상태와 UI의 분리가 명확해져서, 상태가 바뀌면 UI가 자동으로 재구성되는 구조가 훨씬 직관적이었습니다. UI 로직을 일반 Kotlin 코드로 단위 테스트할 수 있다는 점도 강점이었고, 기존 View 기반에서 인스트루먼테이션 테스트가 필요하던 것을 대체할 수 있었습니다. 다만 러닝 커브가 있어서 초반에 리컴포지션 범위를 잘못 설정해 불필요한 재렌더링이 발생하는 문제를 겪었고, 상태 관리 범위를 의식적으로 좁히는 습관이 중요하다는 것을 배웠습니다. Code-based UI는 선언형 사고방식으로의 전환 비용을 치르면 유지보수성이 뚜렷하게 올라간다는 것을 이 프로젝트에서 확인했습니다.
iOS 앱 개발 공부를 하면서 SwiftUI를 사용해 코드로만 UI를 작성하는 방식을 처음 경험했습니다. Storyboard 방식에서는 화면 구성을 시각적으로 확인하면서 만들 수 있었는데, SwiftUI에서는 상태 변화가 화면에 어떻게 반영되는지를 코드로 명확하게 표현해야 했습니다. 처음에는 어떤 데이터를 어디서 관리해야 하는지가 헷갈렸는데, 뷰가 상태를 직접 소유하는 경우와 상위에서 전달받는 경우를 구분하는 원칙을 이해하고 나니 구조가 명확해졌습니다. 코드 기반 UI의 장점은 여러 화면에서 공통으로 쓰는 컴포넌트를 함수로 만들어서 재사용하는 것이 쉽다는 것이었고, Storyboard에서는 비슷한 화면을 복사해서 쓰던 것이 코드로는 공통 컴포넌트 하나로 관리됐습니다. 다만 기존 UIKit 코드와 혼용하는 상황에서는 두 방식의 경계를 관리하는 것이 추가 비용이 된다는 것도 경험했습니다.
팀 프로젝트에서 코드 기반 UI 방식을 사용했을 때 코드 리뷰 과정이 Storyboard 방식과 다르다는 것을 경험했습니다. Storyboard에서는 XML 형태로 저장되어서 코드 리뷰에서 실제로 무엇이 바뀌었는지를 파악하기 어려웠는데, 코드 기반에서는 UI 변경 사항이 코드 diff에서 바로 보였습니다. 리뷰어가 어떤 컴포넌트가 어떤 상태에서 어떻게 보이는지를 코드를 읽으면서 추적할 수 있었고, 리뷰 시간이 줄었습니다. 코드 기반 UI의 장점은 UI가 코드로 표현되기 때문에 버전 관리와 코드 리뷰의 맥락에서 다루기 쉽다는 것이라는 것을 이 경험에서 배웠습니다. 다만 프리뷰가 없는 환경에서는 UI 결과를 확인하려면 실행을 해봐야 하는 경우가 있어서, 빠른 시각적 확인이 필요한 초기 설계 단계에서는 코드 기반 방식이 느리게 느껴지기도 했습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 무신사 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.