안드로이드 앱 아키텍처 설계 시 고려 요소를 묻는 질문은 특정 패턴의 이름을 아는지가 아니라, 기능을 만들기 전에 구조부터 먼저 생각하는 습관이 있는지를 보는 자리입니다. 데이터 흐름, 레이어 분리, 생명주기 관리 중 무엇을 축으로 잡든, 그 판단이 실패 경험에서 나온 것인지가 관건입니다. 고려 요소·결정 근거·사용자 경험·기술적 제약이 하나의 사건 안에서 이어져야 합니다.
면접관은 무엇을 보나
앱 아키텍처 설계에서 고려한 요소의 흔적이 답에 있어야 합니다. 없으면 면접관이 '왜 그 요소가 중요한가요?'를 추가로 묻는 경우가 자주 보입니다.
선택한 요소에 대한 근거를 제시한 흔적이 있어야 합니다. 없으면 면접관이 '그 이유는 무엇인가요?'를 추가로 질문하는 자리가 자주 보입니다.
사용자 경험을 고려한 흔적이 답에 있어야 합니다. 없으면 면접관이 '사용자 피드백은 어떻게 반영했나요?'를 묻는 경우가 많습니다.
기술적 제약을 인식한 흔적이 답에 있어야 합니다. 없으면 면접관이 '어떤 제한 요소가 있었나요?'를 추가로 묻는 경우가 자주 보입니다.
읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?
모범 답변의 결
안드로이드 아키텍처에서 상태 관리와 데이터 흐름 설계 경험
안드로이드 앱 아키텍처를 설계할 때 가장 먼저 고민하는 것은 화면 간 데이터가 어떻게 흐르고 어디서 관리되는가입니다. 이 부분을 초반에 정하지 않으면 화면이 늘어날수록 의존 관계가 복잡해지기 때문입니다.
개인 프로젝트에서 목록 화면에서 선택한 데이터를 상세 화면에 넘기는 구조를 만들 때, 처음에는 인텐트로 직접 전달했습니다. 화면이 2개일 때는 괜찮았지만, 3개 이상의 화면이 생기면서 데이터 전달 경로가 복잡해지고 오류가 잦아졌습니다. ViewModel을 도입하여 데이터를 화면과 분리하니 각 화면이 독립적으로 관리되었습니다. 실패는 처음부터 구조를 잡지 않고 기능 구현부터 시작한 것이었습니다.
아키텍처는 기능이 없을 때 설계하는 것이 좋습니다. 기능이 붙은 후에 구조를 바꾸는 것은 비용이 훨씬 큽니다.
안드로이드 레이어드 아키텍처와 테스트 용이성의 관계 경험
안드로이드 아키텍처 설계에서 UI·비즈니스 로직·데이터 레이어를 명확히 분리하는 것이 중요하다고 생각합니다. 레이어가 섞이면 수정할 때마다 연쇄 영향이 생기거든요.
앱 프로젝트에서 처음엔 액티비티 안에 API 호출과 UI 업데이트 코드를 함께 넣었는데, 특정 기능을 수정할 때마다 UI 코드까지 같이 봐야 하는 상황이 됐습니다. Repository 패턴으로 데이터 접근을 분리하고, 로직을 ViewModel로 올리니 UI는 상태 변화에 반응하는 역할만 하게 됐어요. 단위 테스트도 ViewModel 단독으로 작성할 수 있게 됐습니다. 실패는 분리 후 레이어 간 콜백 처리를 어떻게 할지 처음에 몰라서 코드가 어지러워진 것이었어요.
레이어 분리는 코드 정리가 아니라, 각 레이어가 독립적으로 변경 가능한 구조를 만드는 것입니다.
화면 생명주기와 데이터 보존 관련 경험 서술
안드로이드 아키텍처를 설계할 때 화면이 회전하거나 백그라운드로 갔다가 돌아왔을 때 상태가 어떻게 유지되는가를 꼭 고려하게 됩니다.
앱을 처음 만들 때 가로·세로 전환이 되면 입력한 데이터가 사라지는 문제가 생겼습니다. 생명주기를 이해하지 못하고 액티비티에 상태를 직접 저장했기 때문이었어요. ViewModel로 상태를 분리하니 화면이 재생성되어도 데이터가 유지됐습니다. 이후 백그라운드로 갔다가 돌아오는 상황에서 SavedStateHandle을 추가로 적용했어요. 실패는 생명주기 개념을 모르고 기능 구현에만 집중했다가 나중에 전체 구조를 고쳐야 했던 것이었습니다.
안드로이드 아키텍처는 생명주기를 이해하는 것에서 시작합니다. 생명주기를 모르면 기능은 되는데 상태가 틀리는 버그를 계속 마주치게 됩니다.
전문가의 심화 해설
기능부터 만들다 겪은 문제에서 구조 도입으로 이어지는 구조
이 질문에 강한 답은 처음에 구조 없이 기능부터 구현했을 때 벌어진 구체적 문제(화면이 늘면서 의존 관계가 꼬였다, 화면 회전 시 데이터가 사라졌다)를 먼저 제시하고, 그 문제를 해결하기 위해 도입한 구조(ViewModel, Repository 패턴)를 설명한 뒤, 그 구조가 왜 근본적인 해결이었는지를 원리로 설명하는 순서를 따릅니다. 이 구조가 통하는 이유는 아키텍처 패턴의 필요성은 이론으로 먼저 이해되기보다 문제를 겪은 뒤에야 체감되기 때문입니다. 패턴 이름부터 나열하면 왜 그 패턴이 필요했는지가 드러나지 않고, 문제-도입 순서로 말하면 그 패턴을 실제로 써본 사람의 답이 됩니다.
처음부터 설계했는가 문제를 겪은 뒤 구조를 바꿨는가
합격선을 가르는 지점은 처음부터 완벽한 아키텍처를 설계했다고 말하는 답과, 기능 구현에 매몰됐다가 나중에 구조를 갈아엎어야 했던 비용을 인정하는 답 사이에 있습니다. 처음부터 구조를 잡지 않고 기능 구현부터 시작한 것이 실패였다는 인정은, 그 비용을 몸으로 겪어봤다는 증거로 읽힙니다. 반대로 처음부터 완벽했다는 답은 실제로 여러 화면과 복잡한 상태를 다뤄본 적이 없거나 경험을 미화했다는 인상을 줄 수 있습니다. 구조를 바꾼 시점과 그때 들었던 재작업 비용을 구체적으로 밝히는 것이 이 지점을 가릅니다.
'지금 다시 설계한다면 어떤 점을 달리할까요' 라는 되물음
세 후속 질문 중 가장 성찰을 요구하는 것은 재설계 시 달라질 점을 묻는 질문입니다. 이 질문이 어려운 이유는 앞서 말한 설계가 최선이었다고만 답해온 경우 이 질문에서 답할 거리가 없어지기 때문입니다. 실제로 그 프로젝트를 진행하며 아쉬웠던 지점(레이어 분리 후 콜백 처리 방식을 더 일찍 정리했어야 했다는 등)을 하나 준비해두고, 그것이 왜 아쉬웠는지와 지금이라면 어떻게 다르게 할지를 답할 수 있어야 합니다. 아쉬운 점이 없다고 답하면 그 경험을 되짚어보지 않았다는 인상을 주고, 지나치게 많은 아쉬움을 나열하면 당시 설계 자체의 완성도가 낮았다는 인상을 줄 수 있습니다.
프로젝트 규모에 따라 강조할 아키텍처 요소가 달라진다
이 질문의 답은 다뤄본 프로젝트가 개인 소규모 프로젝트인지 여러 명이 협업한 프로젝트인지에 따라 강조점을 다르게 잡아야 합니다. 개인 프로젝트라면 데이터 흐름이나 생명주기 관리처럼 화면 단위의 구조적 문제가 축이 되고, 협업 프로젝트라면 레이어 분리를 통한 테스트 가능성이나 여러 사람이 동시에 작업할 수 있는 구조처럼 협업 효율과 관련된 요소가 축이 됩니다. 이 구분이 필요한 이유는 협업 규모가 커질수록 아키텍처가 해결해야 하는 문제의 성격이 개인의 편의에서 팀의 생산성으로 옮겨가기 때문입니다.
패턴 이름만 언급하고 이유를 설명하지 않는 함정
흔한 함정은 MVVM이나 클린 아키텍처 같은 패턴 이름만 언급하고 왜 그 패턴을 선택했는지, 그 패턴이 실제로 어떤 문제를 해결했는지는 설명하지 않는 것입니다. 이것이 함정인 이유는, 패턴 이름은 문서 검색으로도 알 수 있는 정보라 그 자체로는 지원자가 실제로 그 패턴을 써봤는지 증명하지 못하기 때문입니다. 면접관이 확인하려는 것은 패턴을 아는지가 아니라 그 패턴이 필요했던 구체적 상황과 판단 근거이며, 이름만 언급하는 답은 반드시 그 이유를 되묻는 질문을 부르고 그 자리에서 얕음이 드러납니다.
이어질 수 있는 꼬리질문
다른 요소들도 고려했었나요?
다양한 요소를 비교했는지 답하는 것이 좋습니다. 각 요소의 상대적 중요성을 답하는 답이 좋습니다.
지금 다시 설계한다면 어떤 점을 달리할까요?
과거 설계에 대한 반성을 짚는 답이 좋습니다. 어떤 부분을 개선했을지 강조하는 답이 강합니다.
이 요소가 중요한 이유는 무엇인가요?
선택한 요소의 중요성을 구체적으로 설명하는 답이 좋습니다. 명확한 근거를 제시하는 것이 필요합니다.
흔히 빠지는 실수
- MVVM이나 클린 아키텍처 같은 패턴 이름만 언급하고 왜 그 패턴이 필요했는지는 설명하지 않습니다.
- 처음부터 완벽하게 설계했다고만 말해 구조를 바꾼 시행착오가 드러나지 않습니다.
- 개인 프로젝트 규모의 경험을 협업 프로젝트의 문제인 것처럼 부풀려 답합니다.
- 기술적 제약을 언급하지 않아 실제로 제약 안에서 판단해본 경험인지 드러나지 않습니다.
- 재설계 시 달라질 점을 묻는 질문에 아쉬운 점이 없다고 답해 성찰이 부족해 보입니다.
이 질문이 나온 회사
실제 면접에서 이 질문이 확인된 회사입니다.