안드로이드 실무 면접 질문은 정답 단어를 맞히는 시험과 조금 다릅니다. “MVVM을 썼습니다”, “테스트를 작성했습니다”, “성능을 개선했습니다”에서 멈추면 아쉽습니다. 면접관은 보통 그다음을 듣고 싶어 합니다. 왜 그렇게 나눴는지, 어떻게 검증했는지, 운영 중 문제가 생기면 어떤 순서로 확인할지입니다.
이번 글은 질문 36번부터 50번까지 정리합니다. Architecture design, testing, performance, Gradle과 AGP, R8, security, privacy, Play policy까지 묶어서 실무형 답변으로 연결해보겠습니다.
Architecture 질문은 패턴 이름보다 책임 경계를 본다
36. Android 앱 아키텍처를 어떻게 설명하나요?
좋은 답변은 “UI, domain, data layer로 나눕니다”에서 끝나지 않습니다. UI layer는 화면을 그리고 사용자 이벤트를 전달합니다. ViewModel은 화면 상태를 만들고 보관합니다. Repository는 데이터 소스를 추상화합니다. domain layer나 use case는 비즈니스 규칙이 복잡하거나 여러 ViewModel에서 재사용될 때 선택적으로 둡니다.
면접에서는 “의존성은 안쪽으로 향하게 하고, Android framework 의존은 바깥 계층에 가깝게 둔다”고 말하면 좋습니다. 단, 작은 앱에서 모든 계층을 억지로 넣는 것은 오히려 유지보수 비용이 될 수 있다는 균형도 함께 보여주세요.
37. ViewModel은 어디까지 책임져야 하나요?
ViewModel은 screen-level UI state를 준비하고, 사용자 이벤트를 받아 필요한 작업을 시작하는 위치에 가깝습니다. UI를 직접 참조하거나 Activity Context를 오래 들고 있으면 위험합니다. 또한 너무 많은 비즈니스 규칙을 ViewModel에 몰아넣으면 테스트가 어려워지고 화면마다 중복이 생길 수 있습니다.
답변할 때는 immutable UI state를 노출하고, event는 ViewModel로 올리고, state는 UI로 내려보내는 단방향 데이터 흐름을 언급하면 안정적입니다.
38. Repository와 UseCase는 항상 필요할까요?
항상은 아닙니다. Repository는 데이터 소스를 감추고 호출자에게 일관된 API를 제공할 때 가치가 있습니다. Local DB, remote API, cache, paging, sync가 섞이면 Repository가 거의 필요해집니다. UseCase는 여러 데이터 소스를 조합하거나 비즈니스 규칙이 재사용될 때 유용합니다.
하지만 단순 CRUD 화면에 UseCase를 모두 만들면 파일 수만 늘 수 있습니다. 면접에서는 “변경 가능성, 테스트 전략, 재사용성, 팀 규모를 기준으로 계층을 조절한다”고 말하는 편이 좋습니다.
39. 멀티모듈은 언제 나누나요?
멀티모듈은 빌드 속도, 책임 분리, 팀 병렬 작업, feature ownership, 재사용성 때문에 도입합니다. 하지만 너무 빨리 나누면 의존성 관리와 API 경계가 오히려 부담이 됩니다. 답변은 “모듈을 나누는 기준은 패키지 정리가 아니라 변경 이유와 소유권”이라고 잡으면 좋습니다.
예를 들어 `core:network`, `core:database`, `feature:search`, `feature:profile`처럼 나눌 수 있지만, 실제 앱에서는 의존성 방향과 공개 API를 명확히 두는 것이 더 중요합니다.
40. offline-first나 캐싱 전략을 어떻게 설명하나요?
offline-first는 네트워크가 불안정해도 사용자가 앱을 계속 쓸 수 있게 local source를 중심에 두는 접근입니다. 일반적으로 DB를 single source of truth로 두고, 네트워크 응답을 DB에 반영한 뒤 UI는 DB flow를 관찰합니다. 캐시는 단순히 빠르게 보이기 위한 임시 저장소가 아니라, 데이터 신뢰도와 동기화 정책을 포함합니다.
면접에서는 “데이터 신선도, 충돌 처리, retry, 백그라운드 동기화, 사용자에게 보여줄 stale 상태”까지 말하면 실무감이 살아납니다.
41. DI는 왜 쓰고, Hilt를 쓰면 무엇이 좋아지나요?
DI는 객체 생성 책임을 사용처에서 분리해 테스트 가능성과 교체 가능성을 높이는 방식입니다. Hilt는 Android lifecycle에 맞는 component scope를 제공하고, ViewModel, Activity, Fragment에서 의존성을 주입하기 쉽게 만듭니다. 면접에서는 “테스트에서 fake repository로 교체하기 쉬워진다”는 점을 꼭 연결하세요.
다만 DI 프레임워크를 쓰는 것이 설계를 자동으로 좋게 만들지는 않습니다. 의존성 방향과 책임 분리가 먼저이고, Hilt는 그것을 구현하기 편하게 해주는 도구라고 말하는 편이 정확합니다.
테스트 질문은 빠른 피드백과 신뢰도를 함께 본다
42. local test, instrumented test, UI test를 어떻게 나누나요?
local test는 JVM에서 빠르게 실행되는 테스트입니다. ViewModel, use case, mapper, repository의 순수 로직을 검증하기 좋습니다. instrumented test는 Android framework나 실제 기기 환경이 필요한 검증에 씁니다. UI test는 사용자 흐름이 실제 화면에서 잘 동작하는지 확인합니다.
면접에서는 테스트 피라미드를 떠올리면 좋습니다. 빠른 단위 테스트를 많이 두고, 통합/UI 테스트는 핵심 흐름 위주로 신뢰도를 보강합니다. 모든 것을 UI test로만 검증하면 느리고 깨지기 쉬워집니다.
43. Mock과 Fake는 어떻게 구분하나요?
Mock은 호출 여부나 상호작용을 검증할 때 유용합니다. Fake는 실제처럼 동작하는 가벼운 구현체입니다. Android 면접에서는 ViewModel 테스트에서 fake repository를 두고 성공, 실패, 로딩 상태를 재현하는 예시가 좋습니다.
답변할 때는 “테스트가 구현 세부에 너무 묶이지 않게 한다”는 말을 덧붙이세요. 지나치게 많은 mock 검증은 리팩터링에 약하고, fake는 시나리오를 읽기 쉽게 만들 수 있습니다.
44. Compose UI test에서는 무엇을 조심해야 하나요?
Compose UI test는 semantics tree를 기준으로 노드를 찾습니다. 텍스트만으로 찾으면 문구 변경에 약할 수 있고, 무분별한 `testTag`는 테스트 전용 표식만 늘릴 수 있습니다. 접근성 의미를 살리는 semantics와 꼭 필요한 testTag를 균형 있게 쓰는 것이 좋습니다.
면접에서는 state를 주입해서 화면을 결정적으로 만들고, 네트워크나 시간 의존성을 분리해 flaky test를 줄인다고 설명하면 좋습니다.
성능 질문은 측정 지표와 재현 절차로 답한다
45. 앱 시작 속도가 느릴 때 어떤 순서로 보나요?
먼저 cold, warm, hot startup을 구분합니다. Android vitals는 과도한 시작 시간을 판단할 때 cold 5초 이상, warm 2초 이상, hot 1.5초 이상 같은 기준을 사용합니다. 면접에서 중요한 것은 숫자를 외우는 것보다, 어떤 시작 유형이 느린지 재현하고 trace로 원인을 확인하는 습관입니다.
Application 초기화, ContentProvider 자동 초기화, main thread blocking, 첫 화면 데이터 로딩, 이미지 로딩, DI graph 생성 비용을 순서대로 봅니다. 그 뒤 lazy initialization, App Startup, background prefetch, Baseline Profile을 검토합니다.
46. Macrobenchmark와 Baseline Profile은 왜 언급할 만한가요?
Macrobenchmark는 실제 앱을 대상으로 startup, scrolling, animation 같은 사용자 흐름의 성능을 측정하는 도구입니다. Baseline Profile은 앱의 주요 코드 경로를 미리 컴파일하도록 도와 첫 실행과 핵심 흐름 성능 개선에 기여할 수 있습니다. 공식 문서에서는 Baseline Profiles가 포함된 code path의 첫 실행 성능을 약 30% 개선할 수 있다고 설명합니다.
면접에서는 “profile을 넣으면 무조건 빠릅니다”가 아니라 “핵심 사용자 journey를 Macrobenchmark로 측정하고, Baseline Profile 적용 전후를 비교한다”고 답해야 안전합니다.
47. Jank나 Compose 성능 문제는 어떻게 접근하나요?
Jank는 프레임이 제때 그려지지 않아 화면이 끊겨 보이는 현상입니다. 원인은 main thread 작업, 과도한 recomposition, 무거운 layout, 이미지 처리, I/O, GC 등 다양합니다. Compose에서는 불필요한 state 읽기 범위, 불안정한 parameter, lazy list key, side effect 위치도 확인합니다.
답변은 “Profiler로 봅니다”에서 멈추지 말고, 재현 시나리오를 만들고, trace로 병목을 찾고, 개선 전후 수치를 비교한다고 말하세요.
빌드, 보안, 정책 질문은 운영 감각을 확인한다
48. Gradle과 AGP 질문을 받으면 어디까지 답해야 하나요?
Android Gradle Plugin은 Android 앱을 빌드, 테스트, 패키징하는 중심 도구입니다. 면접에서는 `build.gradle` 문법만이 아니라 Gradle version, AGP version, JDK 호환성, version catalog, build cache, configuration cache, CI 속도까지 물을 수 있습니다.
2026년 6월 기준 Android Developers의 AGP release notes에는 AGP 9.2.0 minor release와 API level 37.0 지원 정보가 공개되어 있습니다. 면접에서는 최신 버전 숫자를 암기하기보다, 업그레이드 시 release notes, deprecated API, build scan, CI 실패 로그, 플러그인 호환성을 확인한다고 답하는 편이 실무적입니다.
49. R8 keep rule은 어떻게 설명하나요?
R8은 코드 축소, 최적화, 난독화를 수행합니다. keep rule은 reflection, serialization, JNI, DI, 외부 SDK처럼 R8이 사용 여부를 정적으로 판단하기 어려운 코드를 보존하기 위해 작성합니다. 너무 넓은 keep rule은 최적화 효과를 떨어뜨리고, 너무 좁으면 런타임 크래시가 생길 수 있습니다.
면접에서는 “릴리즈 빌드에서만 나는 문제를 재현하고, mapping, missing rules, library consumer rules를 확인한다”고 말하면 좋습니다. keep rule은 복붙이 아니라 원인을 좁혀 쓰는 것이 중요합니다.
50. target API, Data safety, 권한, 대화면 대응은 어떻게 준비하나요?
target API 업데이트는 숫자 변경이 아니라 behavior change 대응입니다. Google Play는 target API 요구사항을 정기적으로 업데이트하므로, 제출 일정과 정책 문서를 확인해야 합니다. Data safety는 앱과 SDK가 수집, 공유, 처리하는 데이터 흐름을 사용자가 이해할 수 있게 선언하는 영역입니다.
보안 질문에서는 runtime permission, exported component, intent redirection, deep link validation, 민감정보 저장, 네트워크 보안 설정을 함께 보세요. 대화면 대응은 단순히 태블릿에서 늘려 보이는 문제가 아닙니다. window size class, adaptive layout, foldable, multi-window, navigation pattern 변화까지 고려하면 좋습니다.
실무형 면접 답변 공식
문제 정의 → 선택한 기준 → 구현 방법 → 검증 방법 → 운영 중 주의점 순서로 말해보세요. 실무형 질문은 “무엇을 아는가”보다 “어떤 순서로 판단하는가”를 보여줄 때 답변이 살아납니다.
FAQ: 실무형 Android 면접에서 자주 흔들리는 부분
주니어도 아키텍처 설계를 깊게 말해야 하나요?
깊이보다 기준이 중요합니다. 주니어에게 완벽한 멀티모듈 설계를 기대하기보다, UI와 데이터 접근을 한 파일에 모두 넣으면 왜 어려워지는지, ViewModel과 Repository를 왜 나누는지, 테스트하려면 어떤 의존성을 바꿀 수 있어야 하는지 묻는 경우가 많습니다. 자신의 프로젝트 규모에 맞춰 솔직하게 설명하면 됩니다.
성능 개선 경험이 없으면 어떻게 답하나요?
거창한 개선 사례가 없어도 됩니다. 대신 “어떻게 측정하겠다”를 말할 수 있어야 합니다. startup이면 cold/warm/hot을 나누고, scrolling이면 jank를 재현하고, Compose면 recomposition 범위를 확인합니다. 작은 샘플 앱에서 Macrobenchmark를 한 번 돌려본 경험도 면접 답변의 재료가 됩니다.
Play 정책은 개발자 면접에서 정말 나오나요?
회사와 직무에 따라 다르지만, 배포와 운영을 맡는 Android 개발자라면 충분히 나올 수 있습니다. target API, 권한, Data safety, SDK 데이터 수집, 백그라운드 동작 정책은 실제 출시 일정과 연결됩니다. 세부 조항을 모두 외우기보다, 변경되는 정책을 확인하고 제품에 반영하는 프로세스를 설명하는 쪽이 좋습니다.
참고한 공식 문서
'코딩 > Android' 카테고리의 다른 글
| 안드로이드 면접 질문 50선 2부: Kotlin·Coroutine·Compose 심화 (0) | 2026.07.01 |
|---|---|
| 안드로이드 면접 질문 50선 (기본편) (0) | 2026.07.01 |
| Android targetSdk 37 마이그레이션 완벽가이드 (0) | 2026.06.19 |
| Android Baseline Profile 적용 가이드 (0) | 2026.06.14 |
| XML에서 Compose로 완벽 마이그레이션 - 순서부터 전략까지 (0) | 2026.03.24 |