이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 MVVM 패턴을 선호합니다. 안드로이드 프로젝트에서 ViewModel을 통해 UI와 비즈니스 로직을 분리하면서, 테스트 코드 작성이 훨씬 쉬워진다는 걸 경험했습니다. 특히 화면 회전이나 상태 변화에서 ViewModel이 데이터를 유지해주는 구조가 안정적이었습니다. MVI는 단방향 데이터 흐름이 명확해서 상태 관리가 예측 가능하지만, 작은 규모의 프로젝트에서는 보일러플레이트가 많아지는 단점이 느껴졌습니다. MVVM이 학습 비용과 생산성 사이의 균형이 좋다고 생각해서, 기본 선택지로 먼저 고려합니다.
패턴 선택은 프로젝트 규모와 팀 상황에 따라 달라지고, 어떤 패턴이든 그 이유를 설명할 수 있는 상태가 더 중요하다고 생각합니다. 팀 코드 리뷰에서 아키텍처 기준을 공유하면 일관성이 유지되고, 협업 비용이 줄어든다는 걸 프로젝트에서 배웠습니다.
저는 MVI 패턴을 선호하는 상황이 점점 늘었습니다. 특히 화면 상태가 복잡하거나 이벤트 흐름이 많아질 때 MVVM의 양방향 바인딩보다 단방향 데이터 흐름이 더 예측 가능했습니다. MVI는 Intent가 State를 거쳐 View로 전달되는 구조라 어떤 이벤트가 어떤 상태를 만들었는지를 추적하기 쉽습니다. 디버깅할 때 상태 변이 경로가 단일하다는 것이 특히 큰 장점이었습니다. 협업 중 다른 팀원이 작성한 코드를 파악할 때도 상태 흐름이 명확해서 이해하는 속도가 달랐습니다. 보일러플레이트가 많아지는 단점은 있지만, 유지보수 단계에서 예측 가능한 코드가 더 중요하다는 것을 경험하고 나서는 그 단점을 감수할 만하다고 생각하게 됐습니다. 물론 단순한 화면에서는 MVVM이 생산성 면에서 여전히 유리하다는 건 함께 인정합니다.
저는 패턴 선택보다 팀 안에서 일관성을 유지하는 것이 더 중요하다는 생각을 갖고 있습니다. MVVM과 MVI 모두 각자 적합한 상황이 있고, 어느 쪽이 절대적으로 더 낫다고 생각하지 않습니다. 화면이 단순하고 팀이 작다면 MVVM이 생산성 면에서 유리하고, 상태가 복잡하고 협업 규모가 크다면 MVI의 단방향 흐름이 예측 가능성을 높여줍니다. 프로젝트에서 새로운 패턴을 도입할 때 팀원 전체가 그 패턴을 이해하고 동일하게 적용할 수 있는지를 먼저 확인했습니다. 아무리 좋은 패턴도 팀 안에서 일관되게 쓰이지 않으면 코드 리뷰 비용이 늘어납니다. 저는 어떤 패턴을 선택하든 그 선택의 이유를 팀과 공유하고 합의하는 방식을 선호합니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 네이버 프론트엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.