이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
안드로이드 앱 아키텍처를 설계할 때 가장 먼저 고민하는 것은 화면 간 데이터가 어떻게 흐르고 어디서 관리되는가입니다. 이 부분을 초반에 정하지 않으면 화면이 늘어날수록 의존 관계가 복잡해지기 때문입니다.
개인 프로젝트에서 목록 화면에서 선택한 데이터를 상세 화면에 넘기는 구조를 만들 때, 처음에는 인텐트로 직접 전달했습니다. 화면이 2개일 때는 괜찮았지만, 3개 이상의 화면이 생기면서 데이터 전달 경로가 복잡해지고 오류가 잦아졌습니다. ViewModel을 도입하여 데이터를 화면과 분리하니 각 화면이 독립적으로 관리되었습니다. 실패는 처음부터 구조를 잡지 않고 기능 구현부터 시작한 것이었습니다.
아키텍처는 기능이 없을 때 설계하는 것이 좋습니다. 기능이 붙은 후에 구조를 바꾸는 것은 비용이 훨씬 큽니다.
안드로이드 아키텍처 설계에서 UI·비즈니스 로직·데이터 레이어를 명확히 분리하는 것이 중요하다고 생각합니다. 레이어가 섞이면 수정할 때마다 연쇄 영향이 생기거든요.
앱 프로젝트에서 처음엔 액티비티 안에 API 호출과 UI 업데이트 코드를 함께 넣었는데, 특정 기능을 수정할 때마다 UI 코드까지 같이 봐야 하는 상황이 됐습니다. Repository 패턴으로 데이터 접근을 분리하고, 로직을 ViewModel로 올리니 UI는 상태 변화에 반응하는 역할만 하게 됐어요. 단위 테스트도 ViewModel 단독으로 작성할 수 있게 됐습니다. 실패는 분리 후 레이어 간 콜백 처리를 어떻게 할지 처음에 몰라서 코드가 어지러워진 것이었어요.
레이어 분리는 코드 정리가 아니라, 각 레이어가 독립적으로 변경 가능한 구조를 만드는 것입니다.
안드로이드 아키텍처를 설계할 때 화면이 회전하거나 백그라운드로 갔다가 돌아왔을 때 상태가 어떻게 유지되는가를 꼭 고려하게 됩니다.
앱을 처음 만들 때 가로·세로 전환이 되면 입력한 데이터가 사라지는 문제가 생겼습니다. 생명주기를 이해하지 못하고 액티비티에 상태를 직접 저장했기 때문이었어요. ViewModel로 상태를 분리하니 화면이 재생성되어도 데이터가 유지됐습니다. 이후 백그라운드로 갔다가 돌아오는 상황에서 SavedStateHandle을 추가로 적용했어요. 실패는 생명주기 개념을 모르고 기능 구현에만 집중했다가 나중에 전체 구조를 고쳐야 했던 것이었습니다.
안드로이드 아키텍처는 생명주기를 이해하는 것에서 시작합니다. 생명주기를 모르면 기능은 되는데 상태가 틀리는 버그를 계속 마주치게 됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 삼성전자 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.