모바일 개발자 면접 질문 TOP 10 - iOS·Android 공통 핵심

들어가며

모바일 개발자 면접, 어떤 질문이 나올지 막막하시죠? "Activity 생명주기 한 번만 더 외우면 되겠지" 하다가, 막상 면접에서는 "왜 그렇게 설계했나요?"가 따라와서 당황하는 경우가 많아요.

면접관이 보는 축은 사실 두 가지예요. 기본기(공식 문서 수준의 정확성)와 트레이드오프 이해(왜 이걸 골랐고, 다른 옵션은 왜 안 골랐는지). 그래서 같은 질문이라도 책에서 본 정의만 말하면 점수를 못 받는 경우가 종종 생겨요.

이 글에서는 iOS·Android 양쪽에서 자주 등장하는 공통 5문항, 그리고 iOS 전용 2문항 + Android 전용 3문항을 다뤄요. 각 질문마다 면접관 의도, 핵심 답변 포인트, 따라오는 follow-up, 그리고 주니어가 자주 빠지는 함정까지 함께 정리했어요. 모의 면접 환경에서 직접 입으로 답해보고 싶다면 트리업의 모의 면접 기능을 활용해보세요.

공통 핵심 5문항

Q1. 앱 생명주기(Lifecycle)에 대해 설명해주세요

면접관 의도 가장 기본 중의 기본인 동시에, 답변의 디테일로 경험치를 가늠하는 질문이에요. "외운 정의"인지 "직접 써본 사람"인지 바로 드러나요.

핵심 답변 포인트

iOS: iOS 13 이후 Scene 기반 생명주기가 기본이에요. 앱 단위 이벤트는 UIApplicationDelegate(AppDelegate), 개별 씬(window)의 UI 단위 이벤트는 UISceneDelegate(SceneDelegate)가 처리해요^[1]. iOS 18.4 이후로는 scene 미적용 앱에 경고 로그가 찍히기 때문에, 신규 프로젝트는 반드시 scene 기반으로 시작하는 게 좋아요^[1].
Android: onCreate → onStart → onResume → onPause → onStop → onDestroy 흐름이에요. 공식 문서에서는 lifecycle을 잘못 다루면 앱 전환 시 크래시, 백그라운드 자원 낭비, 사용자 진행 손실, 화면 회전 크래시가 발생할 수 있다고 명시하고 있어요^[2].

Follow-up

(iOS) willEnterForeground와 didBecomeActive의 차이는?
(Android) onPause와 onStop은 언제 호출되고, 무거운 작업은 어디에서 멈춰야 하나요?

자주 빠지는 함정

AppDelegate에 UI 코드를 넣어버리는 패턴(이제는 SceneDelegate가 그 역할).
"onPause는 화면이 안 보일 때"라고 답해버리기. 사실 onPause는 부분적으로 가려질 때도 호출돼요.

Q2. 메모리 누수는 어떻게 막나요?

면접관 의도 실서비스에서 가장 많이 터지는 이슈예요. "원인 → 진단 → 예방"의 사고 흐름이 있는지를 보고 싶어해요.

핵심 답변 포인트

iOS: 두 객체가 서로를 strong 참조하면 reference count가 0이 되지 않아 누수가 생겨요(strong reference cycle)^[3]. closure에서 [weak self], delegate 프로퍼티에 weak를 붙이는 게 핵심이에요^[3].
Android: ViewModel이 Context, Resources, View, Fragment를 들고 있으면 누수가 발생해요. 공식 문서에 명시된 규칙이에요^[6]. 그 외에도 정적(static) Context 보유, 비정적 inner class(Handler/Listener)가 Activity를 캡처하는 패턴이 단골이에요.

Follow-up

(iOS) weak와 unowned는 언제 다르게 써야 하나요?
(Android) ViewModel에서 Context가 필요하면 어떻게 해결하나요? (Application Context 또는 SavedStateHandle)

자주 빠지는 함정

"ARC가 자동이라 누수 안 나요" — 자동 해제가 사이클까지는 못 풀어요^[3].
"Activity Context 쓰면 됩니다" — Singleton에 Activity Context를 넣는 순간 누수 시작.

Q3. MVVM 같은 아키텍처 패턴은 왜 쓰나요?

면접관 의도 "MVVM 정의를 외우는지"가 아니라 왜 분리해야 하는지를 이해하는지 보고 싶어해요.

핵심 답변 포인트

핵심은 관심사의 분리(Separation of Concerns)예요. Android 공식 가이드도 UI 레이어와 데이터 레이어를 나누고, ViewModel을 state holder로 두는 구조를 권장해요^[7].
MVVM에서 Activity/Fragment(혹은 View, ViewController)는 단순히 상태를 그리는 책임만 갖고, 비즈니스 로직과 상태는 ViewModel이 보유해요. 이렇게 하면 테스트 가능성과 화면 회전·재생성 대응이 한꺼번에 좋아져요^[6]^[7].

Follow-up

MVC, MVP, MVVM, MVI는 어떤 흐름으로 진화했나요?
단방향 데이터 플로우가 왜 중요한가요?

자주 빠지는 함정

"View는 ViewModel을 모르고, ViewModel은 View를 모른다"라는 한 줄로 끝내기. 왜 그렇게 두는지(테스트성, lifecycle 분리)까지 말해야 점수가 나와요.

Q4. 비동기 처리는 어떻게 하시나요?

면접관 의도 모바일은 메인 스레드를 점유하면 곧바로 ANR/끊김으로 이어져요. 비동기 도구의 선택과 lifecycle 안전성을 묻는 질문이에요.

핵심 답변 포인트

iOS: 신규 코드는 async/await 기반 Swift Concurrency가 권장돼요. 기존 GCD 코드도 점진 마이그레이션이 가능해요. (자세한 비교는 Q7에서 다뤄요.)
Android: Kotlin Coroutine이 공식 권장 솔루션이에요^[9]. 핵심은 structured concurrency예요. 새 코루틴은 반드시 CoroutineScope 안에서만 시작하고, 부모가 취소되면 자식이 자동으로 취소돼요^[4].
Android에서는 viewModelScope, lifecycleScope를 쓰면 화면이 사라질 때 코루틴이 자동 취소돼서 lifecycle 누수를 줄일 수 있어요^[9].

Follow-up

Dispatchers.Main, Dispatchers.IO, Dispatchers.Default는 각각 언제 쓰나요?
GlobalScope를 쓰면 안 되는 이유는?

자주 빠지는 함정

GlobalScope.launch로 네트워크 호출을 띄우기 — 화면이 사라져도 작업이 살아남아 누수 위험이 커요.
"suspend면 비동기다"라고 답하기. suspend는 블로킹하지 않을 수 있는 함수일 뿐, 동시성 자체를 의미하지는 않아요.

Q5. 네트워크 캐싱과 오프라인 대응은 어떻게 하나요?

면접관 의도 모바일은 네트워크가 자주 끊겨요. 사용자 경험을 어디까지 책임지는지 보는 질문이에요.

핵심 답변 포인트

공통 전략: 메모리 캐시 + 디스크 캐시 + 서버 캐시 헤더(HTTP Cache-Control, ETag) 3단 구조.
Android에서는 보통 OkHttp의 Cache로 디스크 캐시를 두고, Room을 SSOT(Single Source of Truth)로 두는 패턴이 흔해요. UI는 항상 로컬 DB를 구독해서 그리고, 네트워크는 DB를 갱신하는 흐름이에요. 이는 Android Architecture Guide의 데이터 레이어 권장 구조와도 결이 같아요^[7].
iOS에서는 URLSession의 URLCache, URLRequest.CachePolicy로 캐시를 통제하고, 영구 데이터는 Core Data/SQLite에 보관해요.

Follow-up

ETag와 Last-Modified는 어떻게 다르게 동작하나요?
비행기 모드 전환 시 데이터 동기화는 어떻게 처리하나요?

자주 빠지는 함정

"단순히 응답을 메모리에 저장한다"로 끝. 캐시 만료 정책, 충돌 해결 전략까지 짧게라도 말해두면 좋아요.

iOS 전용 2문항

Q6. Optional과 ARC, 그리고 GC와의 차이를 설명해주세요

면접관 의도 Swift의 정체성을 만드는 두 축이에요. 둘을 묶어 물어보면 "안전한 메모리 모델"을 얼마나 깊이 이해하는지 한 번에 드러나요.

핵심 답변 포인트

Optional: 값이 있을 수도, nil일 수도 있는 타입이에요. 강제 언래핑(!)보다 if let, guard let, ??(nil-coalescing), 옵셔널 체이닝(?.)을 우선 사용해요. 컴파일러가 nil 가능성을 강제로 인지시키기 때문에 NPE 같은 런타임 크래시가 줄어요.
ARC: 컴파일 타임에 retain/release를 자동 삽입해 reference count가 0이 되면 즉시 해제해요^[3]. 결정적 시점 해제가 장점이에요.
GC와의 차이: Kotlin/Android Runtime의 GC는 비결정적 시점에 mark-and-sweep으로 회수해요. ARC는 즉시 해제 + 사이클 수동 관리, GC는 지연 해제 + 사이클 자동 처리라는 트레이드오프가 있어요^[3].

짧은 코드 예시 ``swift class Owner { var pet: Pet? } class Pet { weak var owner: Owner? // strong cycle 방지 } ``

Follow-up

weak와 unowned는 어떤 기준으로 고르나요? (참조 대상이 자기보다 먼저 사라질 가능성이 있으면 weak)
[weak self]는 왜 closure에서 자주 등장하나요?

자주 빠지는 함정

"ARC가 알아서 해주니까 메모리 신경 안 써도 돼요" — strong cycle은 ARC가 못 풀어요^[3].
Optional을 모두 !로 풀어버리기 — IBOutlet 같이 보장된 경우가 아니면 지양해야 해요.

Q7. SwiftUI와 UIKit, 어떤 기준으로 선택하나요?

면접관 의도 "신기술 좋아요!"가 아니라 현실 제약을 따져 결정할 수 있는지 보는 질문이에요.

핵심 답변 포인트

SwiftUI는 선언형 프레임워크로 같은 코드로 iPhone, iPad, Mac, Apple Watch, Apple TV를 타깃할 수 있고, UIKit/AppKit과 상호운용되도록 설계됐어요^[8].
단, iOS 13 이상에서만 동작해요. 더 낮은 deployment target을 지원해야 한다면 UIKit이 필수예요^[8].
기존 UIKit 앱에서는 UIHostingController로 SwiftUI 화면을, UIViewRepresentable로 UIKit 뷰를 SwiftUI에 끼워 넣어 점진 도입할 수 있어요^[8].

선택 기준 요약

상황	권장
신규 프로젝트, iOS 14+ 타깃	SwiftUI 우선
레거시 코드베이스 / iOS 12 이하 지원	UIKit
매우 커스텀한 인터랙션	UIKit 또는 SwiftUI + Representable 혼합

Follow-up

@State, @StateObject, @ObservedObject, @EnvironmentObject는 어떻게 다른가요?
SwiftUI의 view identity와 lifecycle은 UIKit과 어떻게 달라요?

자주 빠지는 함정

"SwiftUI가 무조건 미래"라고만 답하기. 한국 채용 현장에는 UIKit 코드베이스가 여전히 많고, 두 프레임워크는 공존한다는 점을 같이 언급해야 균형 잡혀 보여요^[8].

Android 전용 3문항

Q8. Kotlin Coroutine을 어떻게 쓰시나요?

면접관 의도 단순히 launch를 안다고 답하면 끝나는 질문이 아니에요. structured concurrency를 이해하는지 보는 게 핵심이에요.

핵심 답변 포인트

새 코루틴은 반드시 CoroutineScope 안에서 시작해요. CoroutineScope는 부모-자식 관계와 lifecycle을 책임져요^[4].
부모 코루틴은 자식이 모두 끝날 때까지 기다리고, 부모가 취소되면 자식이 재귀적으로 취소돼요^[4].
Android에서는 viewModelScope(ViewModel이 사라지면 자동 취소), lifecycleScope(LifecycleOwner와 연동) 같은 사전 정의된 scope를 적극 활용해요^[9].

짧은 코드 예시 ``kotlin class UserViewModel : ViewModel() { fun load() = viewModelScope.launch { val user = withContext(Dispatchers.IO) { repo.fetch() } _uiState.value = UiState.Success(user) } } ``

Follow-up

launch와 async의 차이?
Dispatchers.Main, Dispatchers.IO, Dispatchers.Default는 각각 어떤 작업에 쓰나요?

자주 빠지는 함정

GlobalScope.launch를 ViewModel 안에서 사용하기 — lifecycle과 묶이지 않아 누수와 중복 호출이 생겨요.
runBlocking을 메인 스레드에서 호출 — 메인 스레드가 멈춰서 ANR로 이어져요.

Q9. Jetpack Compose와 View 시스템, 어떻게 비교하시나요?

면접관 의도 신구 UI 도구의 트레이드오프를 실제로 따져봤는지를 보는 질문이에요.

핵심 답변 포인트

Jetpack Compose는 선언형 모던 UI 툴킷이에요. 상태가 바뀌면 변경된 부분만 recompose돼요^[5].
Play Store 팀 사례에서는 UI 코드량이 약 50%까지 줄었다고 보고됐어요^[5].
View 시스템은 deprecated가 아니에요. 레거시 코드, 일부 서드파티 SDK, 매우 정적인 UI에서는 여전히 유효해요. 둘은 양방향 interop이 가능해서 점진 마이그레이션이 권장돼요^[5].

비교 표

항목	Jetpack Compose	View 시스템
패러다임	선언형	명령형
코드량	적음	많음
학습 곡선	낮음(처음 시작 시)	익숙한 개발자 다수
성숙도	상승 중	매우 성숙
추천 시점	신규 화면/프로젝트	레거시 유지

Follow-up

recomposition은 언제 일어나고, 언제 skip되나요?
remember와 rememberSaveable의 차이는?

자주 빠지는 함정

"Compose가 항상 더 빠르다" — 잘못 짠 recomposition은 오히려 성능을 깎아요.
View와 Compose 중 양자택일이라고 단정하기 — interop을 통한 공존이 현실 답이에요^[5].

Q10. ViewModel의 생명주기와 화면 회전 시 데이터 보존을 설명해주세요

면접관 의도 configuration change 처리는 Android의 가장 오래된 함정이에요. ViewModel 도입 전후를 이해하는지가 보여요.

핵심 답변 포인트

ViewModel은 ViewModelStoreOwner 범위에서 살아 있어요. Activity가 finish되거나 Fragment가 detach되거나 Navigation back-stack에서 빠질 때까지 메모리에 남아요^[6].
화면 회전 같은 configuration change가 발생하면 Activity는 재생성되지만 ViewModel은 그대로 유지돼서 UI 상태를 다시 가져올 필요가 없어요^[6].
단, 시스템이 프로세스를 종료하는 경우(메모리 회수 등)에는 ViewModel도 사라져요. 이때는 SavedStateHandle로 데이터를 보존해야 해요^[6].
ViewModel은 Context, Resources, View, Fragment를 절대 들고 있으면 안 돼요 — 누수 직행이에요^[6].

Follow-up

ViewModel과 onSaveInstanceState(번들)는 각각 언제 쓰나요?
ViewModel을 두 화면에서 공유하려면 어떤 scope를 쓰나요?

자주 빠지는 함정

"ViewModel은 모든 데이터를 영원히 보관해줘요" — 프로세스 종료에는 약해요. SavedStateHandle을 같이 답해야 완성도가 올라가요^[6].
ViewModel 안에서 Context.getString()을 쓰려고 Context 주입 — Application 범위 클래스(예: AndroidViewModel)나 리소스 ID를 UI에 넘겨 처리하는 게 안전해요.