안드로이드 면접 질문 50선 (기본편)

안드로이드 면접 질문을 찾는다면 Android 개발자 면접 준비는 이제 Kotlin, Coroutine, Jetpack Compose까지 한 번에 잡아야 합니다. Activity 생명주기만 외우던 방식으로는 답변이 금방 얇아집니다.

 

면접 질문 목록을 많이 모아도 막상 입으로 말하려고 하면 멈칫할 때가 있습니다. 질문을 몰라서라기보다, 답변을 어떤 순서로 꺼내야 하는지 정리가 안 되어 있기 때문입니다.

 

이번 글에서는 50개 질문을 전부 같은 깊이로 나열하기보다, 기본 질문 20개와 모든 질문에 적용할 답변 틀을 먼저 잡습니다. 본문은 기본편 하나로도 바로 공부를 시작할 수 있게 구성했습니다.

안드로이드 면접 질문, 요즘은 어디까지 물어볼까

예전 Android interview questions 글을 보면 Activity lifecycle, Intent, Service 정도에서 끝나는 경우가 많습니다. 그 질문들이 여전히 중요하지 않다는 뜻은 아닙니다. 다만 실무 Android 앱의 기본 단위가 Kotlin, coroutine, reactive stream, Compose, 테스트, 정책까지 넓어지면서 면접관이 확인하려는 범위도 함께 넓어졌습니다.

 

처음 준비할 때 가장 흔한 실수는 질문을 난이도순으로 외우려는 것입니다. 오히려 범주를 먼저 나눠두면 낯선 꼬리 질문이 나와도 어디에 붙여서 생각해야 할지 보입니다.

Android 면접 준비 범위를 네 묶음으로 정리한 준비 지도

 

준비 범위는 크게 네 묶음으로 보면 편합니다. Android 기본기는 Activity, Fragment, Intent, Context, 권한, 저장소, 스레드, ANR을 포함합니다. Kotlin과 비동기 영역은 null-safety, data class, sealed class, Coroutine, Flow, StateFlow, SharedFlow로 이어집니다.

 

Architecture와 UI는 ViewModel, Repository, UI state, UDF, Jetpack Compose를 묶어서 봐야 합니다. 마지막으로 실무 품질 영역에는 테스트, 성능, Gradle과 AGP, 보안, 개인정보, Play 정책, 대화면 대응이 들어갑니다. 모든 내용을 같은 깊이로 외우기보다, 어떤 질문이 어느 범주에서 나오는지 먼저 잡는 쪽이 훨씬 덜 흔들립니다.

준비 영역	핵심 질문 방향	답변에서 보여줄 것
Android 기본기	생명주기, 컴포넌트, 권한, ANR	OS 동작을 기준으로 설명하는 힘
Kotlin과 비동기	Coroutine, Flow, 상태 스트림	main-safety와 cancellation 감각
Architecture와 Compose	ViewModel, UI state, recomposition	상태 소유권과 화면 설계 기준
실무 품질	테스트, 성능, 정책, 보안	재현 가능하게 검증하는 태도

답변 퀄리티를 올리는 5단계 프레임

좋은 답변은 길이가 아니라 구조에서 갈립니다. 용어 정의만 말하고 끝내면 신입 수준의 암기처럼 들리고, 프로젝트 사례만 길게 말하면 질문의 핵심을 놓치기 쉽습니다. 그래서 모든 질문을 같은 틀로 짧게 정리해보는 연습이 필요합니다.

 

면접에서는 다음 다섯 단계를 머릿속에 두면 좋습니다. 정의, 이유, 구현, 실수, 실무 예시입니다. 이 순서를 외우라는 뜻이 아니라, 답변이 한쪽으로 치우치지 않게 잡아주는 난간처럼 쓰면 됩니다.

정의, 이유, 구현, 실수, 실무 예시로 이어지는 면접 답변 흐름

 

단계	말할 내용	짧은 예시
정의	용어를 한두 문장으로 설명	ViewModel은 화면 상태를 보관하는 컴포넌트입니다.
이유	왜 필요한지 연결	configuration change에도 상태를 유지하기 쉽습니다.
구현	Android에서 쓰는 방식	StateFlow로 UI state를 노출할 수 있습니다.
실수	흔한 오해나 버그	ViewModel에 Activity Context를 오래 들고 있으면 위험합니다.
실무 예시	프로젝트 상황으로 마무리	검색 화면의 로딩, 성공, 오류 상태를 하나의 state로 관리합니다.

예를 들어 "ViewModel은 왜 쓰나요?"라는 질문을 받았다고 해보겠습니다. 아쉬운 답변은 "화면 회전에도 데이터가 유지돼서 씁니다"에서 끝납니다. 면접에서는 이렇게 정리하면 좋습니다. "ViewModel은 화면 단위의 UI state를 관리하기 위해 사용합니다. configuration change에도 상태를 유지할 수 있고, UI 로직을 Activity나 Fragment에서 분리해 테스트하기 쉬워집니다. 다만 ViewModel이 View나 Activity Context를 직접 오래 참조하면 메모리 릭 위험이 있으므로, 화면에 필요한 상태와 이벤트만 노출하도록 설계합니다."

기본기 질문 20개: Activity부터 ANR까지

기본 질문은 면접 초반의 체온계처럼 쓰입니다. 여기서 답변이 흔들리면 뒤의 Kotlin, Compose, 성능 질문을 잘 말해도 신뢰가 덜 쌓입니다. 반대로 기본기를 차분히 설명하면 모르는 심화 질문이 나와도 대화가 이어집니다.

Activity, Intent, Thread, ANR처럼 기본 질문을 범주로 묶어 보는 지도

Activity와 Fragment

1. Activity lifecycle을 설명해보세요.
Activity는 생성, 시작, 재개, 일시정지, 중지, 소멸 흐름을 갖습니다. 면접에서는 메서드 이름을 줄줄이 외우기보다, 화면이 사용자에게 보이는지, 포커스를 갖는지, 리소스를 정리해야 하는지로 나눠 설명하는 편이 낫습니다.
꼬리 질문: onPause와 onStop에서 각각 무엇을 처리할지 물어볼 수 있습니다.

 

2. configuration change가 발생하면 어떤 일이 일어나나요?
화면 회전, 다크 모드 변경, 언어 변경처럼 configuration이 바뀌면 Activity가 재생성될 수 있습니다. 그래서 화면 상태를 Activity 필드에만 두면 사라질 수 있고, ViewModel이나 saved state를 함께 고려해야 합니다.
꼬리 질문: 상태 보존과 UI 재구성을 어떻게 나눌지 이어질 수 있습니다.

 

3. Fragment를 쓸 때 lifecycle owner를 왜 구분해야 하나요?
Fragment 자체의 lifecycle과 Fragment view의 lifecycle은 다릅니다. View binding, collect, observer를 view lifecycle에 맞추지 않으면 view가 사라진 뒤에도 참조가 남아 메모리 릭이나 중복 업데이트가 생길 수 있습니다.
꼬리 질문: viewLifecycleOwner를 언제 쓰는지 설명할 수 있어야 합니다.

 

4. back stack은 어떻게 관리되나요?
Android의 back stack은 사용자의 탐색 흐름을 보관합니다. Activity와 Fragment, Navigation Component를 쓸 때 모두 "사용자가 뒤로 가기를 눌렀을 때 어떤 화면으로 돌아가야 하는가"를 기준으로 설명하면 답변이 자연스럽습니다.
꼬리 질문: 딥링크로 들어온 화면의 back stack을 어떻게 만들지 물을 수 있습니다.

Context, Intent, Manifest

5. Context는 무엇이고 Activity Context와 Application Context는 어떻게 다른가요?
Context는 앱 리소스, 시스템 서비스, 앱 환경에 접근하는 통로입니다. Activity Context는 화면과 생명주기에 묶이고, Application Context는 앱 프로세스 범위에 가깝습니다. 화면을 띄우거나 테마가 필요한 작업에는 Activity Context가 필요할 수 있습니다.
꼬리 질문: 잘못된 Context 보관이 왜 메모리 릭으로 이어지는지 자주 이어집니다.

 

6. explicit intent와 implicit intent 차이는 무엇인가요?
explicit intent는 실행할 component를 직접 지정합니다. implicit intent는 action, category, data를 바탕으로 처리 가능한 앱을 시스템이 찾습니다. 공유나 외부 앱 연동에서는 편하지만, 민감한 동작은 보안상 더 조심해야 합니다.
꼬리 질문: chooser, package 지정, exported 설정으로 이어질 수 있습니다.

 

7. exported component 설정은 왜 중요하나요?
exported는 다른 앱이 해당 component를 호출할 수 있는지와 관련됩니다. 외부에 열 필요가 없는 Activity, Service, Receiver를 열어두면 의도하지 않은 호출이나 보안 문제가 생길 수 있습니다. 면접에서는 "앱 간 통신의 문을 어디까지 열 것인가"로 설명하면 이해가 쉽습니다.
꼬리 질문: intent filter가 있을 때 exported를 어떻게 판단하는지 물을 수 있습니다.

 

8. Manifest에는 어떤 정보가 들어가나요?
Manifest에는 앱의 component, 권한, feature, intent filter, target SDK 같은 실행과 배포에 필요한 선언이 들어갑니다. 단순 설정 파일이 아니라 OS와 Play 정책이 앱을 이해하는 출입구라고 보는 편이 좋습니다.
꼬리 질문: permission 선언과 runtime permission 요청의 차이를 물을 수 있습니다.

Thread, Process, ANR

9. main thread를 막으면 왜 문제가 되나요?
main thread는 UI 렌더링과 사용자 입력 처리를 담당합니다. 여기서 네트워크, 파일 I/O, 큰 계산을 오래 수행하면 화면이 멈추고 입력 처리도 늦어집니다. 답변은 "느려진다"보다 "UI 이벤트 루프가 막힌다"로 말하는 쪽이 정확합니다.
꼬리 질문: 어떤 작업을 Dispatcher.IO로 보내야 하는지 이어질 수 있습니다.

 

10. ANR은 어떤 상황에서 발생하나요?
ANR은 앱이 일정 시간 안에 사용자 입력이나 시스템 이벤트에 응답하지 못할 때 발생합니다. 원인은 main thread blocking, BroadcastReceiver에서 오래 걸리는 작업, lock 경합처럼 다양합니다. 면접에서는 "ANR이 뜨면 trace를 보고 main thread가 어디서 막혔는지 확인한다"까지 말하면 실무감이 납니다.
꼬리 질문: StrictMode, trace, vitals를 어떻게 볼지 물을 수 있습니다.

 

11. Service와 WorkManager를 어떻게 구분하나요?
Service는 백그라운드에서 실행되는 component이지만, 최신 Android에서는 백그라운드 실행 제한과 foreground service 정책을 함께 고려해야 합니다. WorkManager는 지연 가능하고 보장되어야 하는 작업, 예를 들어 로그 업로드나 동기화에 적합합니다.
꼬리 질문: 즉시 실행, 지연 가능, 반복 작업을 어떻게 나눌지 이어집니다.

 

12. BroadcastReceiver는 언제 쓰나요?
BroadcastReceiver는 시스템이나 앱에서 발생한 broadcast를 받는 component입니다. 짧게 처리하고 끝나는 이벤트에 맞고, 오래 걸리는 작업은 WorkManager 같은 수단으로 넘기는 편이 안전합니다.
꼬리 질문: implicit broadcast 제한과 manifest 등록 여부를 물을 수 있습니다.

권한, 저장소, 보안

13. runtime permission은 왜 필요한가요?
runtime permission은 민감한 권한을 설치 시점이 아니라 사용 맥락에서 요청하도록 만든 장치입니다. 면접에서는 권한 API 사용법만 말하기보다, 사용자가 왜 지금 이 권한이 필요한지 이해할 수 있게 UX를 설계해야 한다고 덧붙이면 좋습니다.
꼬리 질문: 권한 거부, 다시 묻지 않음, 설정 화면 이동을 어떻게 처리할지 이어질 수 있습니다.

 

14. internal storage와 external storage를 어떻게 구분하나요?
internal storage는 앱 전용 공간에 가깝고, external storage는 사용자와 다른 앱의 접근 가능성을 더 신중히 봐야 합니다. Android 버전에 따라 scoped storage 정책도 함께 고려해야 하므로, 저장 위치는 데이터 민감도와 공유 필요성을 기준으로 선택합니다.
꼬리 질문: 이미지 파일 공유 시 content URI를 어떻게 줄지 물을 수 있습니다.

 

15. ContentProvider나 content URI를 안전하게 공유하려면 무엇을 조심해야 하나요?
파일 경로를 직접 노출하기보다 content URI와 일시적 권한 부여를 사용하는 편이 안전합니다. Provider를 외부에 열어야 한다면 exported, permission, URI 범위를 함께 확인해야 합니다.
꼬리 질문: FileProvider와 grantUriPermission 흐름을 물을 수 있습니다.

 

16. Intent redirection 같은 보안 이슈를 어떻게 설명할 수 있나요?
Intent redirection은 외부에서 받은 intent를 검증 없이 다시 실행하면서 예상하지 못한 component가 열리는 문제로 설명할 수 있습니다. Android 16 이후에는 관련 hardening도 언급할 수 있지만, 기본은 입력 검증, 명시적 component 지정, exported 최소화입니다.
꼬리 질문: 외부 딥링크를 처리할 때 어떤 validation을 넣을지 이어질 수 있습니다.

기본기 보강 질문

17. Android 앱 프로세스가 종료될 수 있는 상황은 무엇인가요?
시스템 메모리가 부족하거나 사용자가 앱을 종료하거나, 백그라운드 제한 상황에서 프로세스가 사라질 수 있습니다. 그래서 화면 상태와 영속 데이터의 경계를 분리해야 합니다.
꼬리 질문: process death 이후 복구해야 할 최소 상태를 어떻게 고를지 물을 수 있습니다.

 

18. 메모리 릭은 왜 생기고 어떻게 줄이나요?
더 이상 필요 없는 객체가 참조 체인 때문에 해제되지 못하면 메모리 릭이 생깁니다. Activity Context를 오래 보관하거나 listener를 해제하지 않거나, Fragment view 참조를 정리하지 않는 상황이 대표적입니다.
꼬리 질문: LeakCanary, lifecycle-aware API, weak reference의 한계를 물을 수 있습니다.

 

19. 앱 시작 속도가 느릴 때 먼저 무엇을 확인하나요?
Android vitals 기준으로 startup은 cold, warm, hot으로 나눠 볼 수 있고, Play Console은 TTID 기준으로 과도한 시작 시간을 경고할 수 있습니다. 공식 기준에서는 cold 5초 이상, warm 2초 이상, hot 1.5초 이상이 문제 신호가 될 수 있습니다. 면접에서는 main thread 초기화, Application 작업, lazy initialization, Baseline Profile을 순서대로 말하면 좋습니다.
꼬리 질문: 측정 없이 감으로 최적화하지 않는다는 태도가 중요합니다.

 

20. targetSdkVersion을 올릴 때 어떤 검증을 하나요?
targetSdkVersion을 올리는 일은 숫자 변경이 아니라 behavior change를 받아들이는 작업입니다. 권한, 백그라운드 실행, 파일 접근, 보안 정책, Play 제출 요건을 확인하고 회귀 테스트 계획을 세워야 합니다.
꼬리 질문: compileSdkVersion과 targetSdkVersion의 차이를 물을 수 있습니다.

Kotlin, Coroutine, Flow는 기본편에서 어디까지 봐야 할까

코틀린 면접 질문은 Android 면접 안에서 거의 기본 영역이 됐습니다. 다만 기본편에서 모든 API를 깊게 비교할 필요는 없습니다. 처음에는 "왜 Kotlin이 Android 코드의 안정성을 높이는가"와 "비동기 처리를 main-safe하게 만드는가"에 집중하면 됩니다.

 

Kotlin은 null-safety, data class, sealed class, value class의 쓰임을 먼저 잡으세요. null-safety는 NullPointerException 가능성을 컴파일 단계에서 줄이는 장치로 설명하면 됩니다. data class는 값 객체 표현에, sealed class는 제한된 상태나 결과 타입 표현에, value class는 얇은 타입 안정성에 연결하면 답변이 덜 추상적입니다.

 

extension function과 scope function은 편리하지만 과하게 쓰면 읽는 사람이 흐름을 놓칠 수 있습니다. 그래서 면접에서는 "코드를 짧게 만드는 도구"라고만 말하지 말고, 팀 코드에서 가독성과 디버깅 비용을 같이 본다고 답하는 편이 좋습니다. 실제로 준비하다 보면 apply, also, let을 예쁘게 설명하는 데 시간을 많이 쓰는데, 면접관은 대개 그보다 null 처리와 책임 분리를 더 보고 싶어 합니다.

기본편에서 잡을 비동기 답변 기준

Coroutine은 Thread 자체가 아니라 suspend와 dispatcher를 통해 스레드를 효율적으로 쓰는 동시성 모델로 설명하세요. suspend function은 오래 걸리는 작업을 중단 가능한 형태로 표현하고, blocking 작업을 수행하는 계층이 main-safe하게 dispatcher를 바꿔주는 책임을 갖는다고 말하면 균형이 좋습니다.

Flow는 여러 값을 순차적으로 내보낼 수 있는 coroutine 기반 stream입니다. 일반 Flow는 cold 특성이 있어 collect 같은 terminal operator가 호출될 때 producer가 동작한다고 설명하면 됩니다. StateFlow는 화면 상태처럼 현재 값이 중요한 흐름에, SharedFlow는 이벤트나 브로드캐스트성 흐름에 가깝다고 말할 수 있습니다.

 

stateIn, shareIn, backpressure, one-off event 처리, lifecycle 중복 수집 같은 주제는 심화 학습으로 남겨두면 됩니다. 기본편에서는 Thread와 Coroutine의 차이, suspend의 의미, Dispatcher, structured concurrency, cancellation, Flow와 StateFlow의 역할까지만 말로 풀 수 있으면 충분합니다.

Architecture와 Jetpack Compose 질문은 답변의 결이 다르다

Architecture 질문은 정답 이름을 맞히는 시험이 아닙니다. MVVM, MVI, Clean Architecture를 안다고 말하는 것보다, 왜 그 구조가 필요한지와 어디까지 적용하면 과한지 설명하는 쪽이 더 중요합니다.

 

ViewModel은 configuration change 대응만을 위한 도구로 말하면 답변이 좁아집니다. 공식 Android 문서의 흐름에 맞춰 보면 ViewModel은 screen-level UI state를 관리하는 위치에 가깝습니다. UI state는 화면을 그리는 데 필요한 값의 immutable snapshot으로 설명할 수 있고, event는 위로 올라가고 state는 아래로 내려가는 UDF 구조와 연결됩니다.

 

Repository는 data source를 감추고, 화면이나 domain layer가 데이터 접근 방식을 직접 알지 않아도 되게 만드는 경계입니다. Room에서 오든, 네트워크에서 오든, 캐시에서 오든 호출자는 일관된 API로 데이터를 받습니다. 다만 작은 앱에 무거운 계층을 모두 넣는 것이 항상 좋은 설계는 아닙니다. 면접에서는 "앱 규모, 테스트 전략, 변경 가능성에 따라 조정한다"는 균형을 보여주는 것이 좋습니다.

 

Jetpack Compose 면접은 선언형 UI와 recomposition을 중심으로 흐릅니다. Compose에서는 상태가 바뀌면 composable이 새 데이터로 다시 호출될 수 있고, 변경된 부분만 재구성하려고 합니다. 그래서 composable 본문은 빠르고, 같은 입력에 같은 UI를 내고, side effect를 함부로 만들지 않아야 합니다.

 

기본편에서는 remember와 rememberSaveable, state hoisting 정도만 또렷하게 말하면 됩니다. remember는 recomposition 사이의 값을 기억하지만 configuration change까지 보존하려면 rememberSaveable을 고려해야 합니다. state hoisting은 상태를 더 적절한 소유자로 올려 재사용성과 테스트 가능성을 높이는 방식이라고 설명하면 자연스럽습니다. LaunchedEffect, DisposableEffect, rememberUpdatedState는 기본 개념을 잡은 뒤 따로 깊게 비교하면 좋습니다.

테스트, 성능, 정책 질문은 실무 감각을 보는 영역이다

Android developer interview questions에서 점점 중요해지는 부분은 "만들 수 있는가"보다 "검증하고 운영할 수 있는가"입니다. 특히 주니어 면접에서도 테스트 기준, 성능 측정 방식, Play 정책 대응을 가볍게 물어보는 경우가 있습니다.

테스트, 성능, 정책, 보안까지 확장되는 2026 Android 면접 체크리스트

 

테스트 질문은 local test와 instrumented test 차이에서 시작하면 됩니다. local test는 개발 머신이나 CI에서 빠르게 도는 단위 검증에 가깝고, instrumented test는 실제 Android framework나 기기 환경이 필요한 검증에 씁니다. ViewModel이나 use case는 unit test로 분리하고, UI 흐름과 framework 통합은 instrumented test나 UI test로 남기는 기준을 말하면 좋습니다.

 

Compose UI test에서는 semantics와 testTag를 함께 언급하면 답변이 실무적으로 들립니다. 화면의 텍스트만 잡아 테스트하면 문구 변경에 취약할 수 있고, 의미 있는 semantics를 붙이면 접근성과 테스트 안정성을 같이 챙길 수 있습니다.

 

성능 질문은 "Profiler로 봅니다"에서 멈추면 아쉽습니다. startup을 cold, warm, hot으로 나누고, TTID와 TTFD 같은 관점을 이해하고, main thread blocking과 초기화 순서를 확인한다고 말해야 합니다. Android vitals 기준으로 cold startup 5초 이상, warm startup 2초 이상, hot startup 1.5초 이상은 과도한 시작 시간으로 경고될 수 있습니다.

 

Baseline Profiles도 알아두면 좋습니다. 공식 Android 문서에서는 포함된 code path에 대해 첫 실행 성능을 약 30% 개선할 수 있다고 설명합니다. 이 숫자는 "무조건 빨라진다"는 보장이 아니라, startup이나 핵심 사용자 흐름을 profile에 넣고 Macrobenchmark로 측정해 확인해야 하는 근거로 쓰는 편이 안전합니다.

2026년 기준으로 챙길 변화

• 2025년 8월 31일부터 Google Play 신규 앱과 업데이트는 Android 15, API 35 이상 target 요구를 받습니다.
• 2026년 4월에는 Android Gradle Plugin 9.2.0 minor release가 공개됐고, 2026년 6월 26일 기준 문서에서 API level 37.0 지원이 확인됩니다.
• 2026년 6월 30일 기준 Android 17, API 37 자료가 Android Developers에 공개되어 있습니다.

AGP와 Gradle 질문은 build.gradle 문법만 묻는 흐름에서 조금 벗어나고 있습니다. Gradle, JDK, AGP 호환성, version catalog, build cache, R8 keep rule 영향, CI test report 같은 주제로 이어질 수 있습니다. 보안과 정책 쪽에서는 target API 요구, Data safety, runtime permission UX, third-party SDK 데이터 흐름을 함께 보는 편이 좋습니다.

 

Android 16과 Android 17 같은 최신 플랫폼 정보는 모든 세부 기능을 외우라는 의미가 아닙니다. 면접에서는 "새 SDK를 설치하고 compileSdk와 targetSdk의 차이를 이해한 뒤, behavior change를 읽고 회귀 테스트를 설계한다"는 습관을 보여주는 정도가 더 현실적입니다. 기본편에서는 최신 버전 이름을 암기하기보다, 변화가 왔을 때 어떤 문서를 읽고 어떤 테스트로 확인할지 말할 수 있는지가 더 중요합니다.

FAQ: 안드로이드 면접 준비에서 자주 묻는 질문

신입도 Android 면접에서 Coroutine을 알아야 하나요?

알아두는 편이 좋습니다. 다만 신입에게 바로 복잡한 Flow operator나 dispatcher 튜닝을 기대하는 경우는 많지 않습니다. Thread와 Coroutine의 차이, suspend function의 의미, main thread를 막지 않는 이유, cancellation이 왜 필요한지 정도를 말할 수 있으면 기본선은 잡힙니다. 프로젝트에서 Retrofit, Room, ViewModel과 함께 Coroutine을 썼다면 그 흐름을 자기 말로 설명해보세요.

Jetpack Compose 질문은 얼마나 준비해야 하나요?

Compose만 쓰는 팀도 있고 View 기반 코드가 남아 있는 팀도 있습니다. 그래서 "Compose를 안다"보다 선언형 UI, state, recomposition, state hoisting을 설명할 수 있는지가 중요합니다. remember와 rememberSaveable 차이, ViewModel에서 state를 내려주는 방식, side effect를 composable 본문에 직접 두지 않는 이유까지 준비하면 기본편 수준에서는 충분합니다. 기존 View와의 interoperability를 한 문장으로라도 말할 수 있으면 더 좋습니다.

GitHub 면접 질문 모음만 봐도 충분한가요?

질문 목록을 보는 것은 출제 범위를 훑는 데 도움이 됩니다. 문제는 오래된 목록일수록 Compose, Flow, Baseline Profile, Play 정책, adaptive UI 같은 주제가 빠져 있을 수 있다는 점입니다. 목록을 그대로 암기하기보다 각 질문을 정의, 이유, 구현, 실수, 실무 예시로 다시 말해보세요. 그 과정에서 답변이 비는 부분이 실제 공부할 지점입니다.

회사별 면접 후기는 어떻게 참고하는 게 좋나요?

회사별 후기는 분위기와 질문 결을 파악하는 자료로만 쓰는 편이 안전합니다. 특정 회사가 같은 질문을 계속 묻는다고 단정하면 준비가 좁아질 수 있습니다. 후기에서 반복되는 키워드를 뽑고, 그 키워드를 공식 문서 기준과 자신의 프로젝트 경험으로 다시 정리해보세요. "어떤 회사에서 나왔다"보다 "왜 이 질문을 물었을까"를 보는 쪽이 오래 남습니다.

2026년 기준으로 Android 16/17까지 외워야 하나요?

세부 기능을 모두 외울 필요는 없습니다. Android 16과 Android 17은 최신 SDK와 behavior change를 읽고 대응하는 습관의 예시로 보는 편이 좋습니다. targetSdkVersion을 올릴 때 어떤 문서를 확인하고, 어떤 기능을 회귀 테스트하고, Play 정책 일정과 어떻게 맞출지 설명할 수 있으면 충분히 실무적인 답변이 됩니다. 최신 버전 이름보다 대응 프로세스가 더 중요합니다.

마무리: 오늘 바로 시작할 3단계

첫 번째로, 기본기 질문 20개를 소리 내서 말해보세요. 글로 보면 아는 것 같은데 말로 꺼내면 빠지는 부분이 바로 보입니다. 답변은 정의, 이유, 구현, 실수, 실무 예시 순서로 1분 안에 정리해보면 됩니다.

 

두 번째로, Kotlin, Coroutine, Flow와 Compose 기본 개념을 Android 화면 구조와 연결하세요. null-safety는 안정성, Coroutine은 main-safety, Flow는 상태 흐름, Compose는 state와 recomposition으로 이어지면 답변이 자연스럽습니다.

 

세 번째로, 테스트와 성능, 정책은 자신의 프로젝트 사례와 묶어 준비하세요. 직접 운영 경험이 많지 않다면 공식 기준을 바탕으로 "어떤 순서로 확인하겠다"는 계획을 말하면 됩니다. 질문을 많이 보는 것보다, 같은 질문에 얼마나 구조적으로 답하는지가 중요합니다.