Bosch 안드로이드 개발자 인터뷰 경험

https://medium.com/@avula.koti.realpage/bosch-android-developer-interview-experience-d6d15cfe207c

 

그들이 물어본 Kotlin과 Compose 질문들, 

그리고 한 시니어 개발자가 실제로 어떻게 답변했는지

 

지난 달, 제 동료 아라빈드가 보쉬에서 시니어 안드로이드 개발자 (코틀린, 컴포즈, 아키텍처) 인터뷰를 봤습니다.

만약 당신이 보쉬인터뷰를 경험해본적이 있다면 이미 그 분위기를 알고 있을 것입니다.

 

체계적이고, 분석적이며, 진짜 엔지니어링 깊이에 집중하는 면접스타일 

 

아라빈드는 8년이상의 안드로이드 개발경험을 가지고 있고,

탄탄한 코틀린 기초와 견고한 아키텍쳐 지식을 갖추고 있습니다.

그는 자신있게 면접장에 들어갔지만 

나와서 이렇게말했습니다.

"최근 몇 년간 봤던 안드로이드 면접 중 가장 기술적인 인터뷰 였습니다."

아래는 그가 어떤 질문을 받았는지, 왜 그 질문을 했는지, 그가 어떻게 답변했는지까지 라운드별로 전체 정리입니다.

 

1라운드: 기술 심층 면접 - 코틀린, 동시성, 컴포즈 

이 라운드는 완전히 기술 중심으로 진행되었고, 70분 동안 이어졌습니다.

면접관은 보쉬의 시니어 안드로이드 엔지니어였으며, 코틀린 내부 동작 원리, 코루틴, 성능, 그리고 컴포즈 기본기에 강하게 초점을 맞추고 있었습니다.

 

1. 코틀린: 왜 보쉬는 자바보다 코틀린을 더 선호하나요? 

아라빈드의 대답

코틀린은 null-safety, 코루틴, 더 깔끔한 데이터클래스, 상태 모델링을 위한 sealed class를 제공하고, 전체적으로 코드의 예측 가능성을 높여줍니다.

보일러 플레이트가 줄어들기 때문에 버그 도 감소합니다.

보쉬의 자동차 산업용처럼 규모가 큰 앱에서는 코드의 신뢰성이 매우중요합니다.

보쉬는 예측 가능성, 유지보수성을 중시하기 때문에 이 답변을 좋게 평가했습니다.

 

2. 코루틴 vs 스레드 각각 언제 선택해야하나요? 

아라빈드의 답변

"실제 병렬성이 필요하거나, 로우 레벨 네이티브 코드화 상호작용 할때에는 쓰레드를 사용합니다.

반면 , 앱 내부의 구조화된 동시성이 필요한 작업 

예를 들어 네트워크 요청, 데이터 베이스 처리, 스트리밍, UI 업데이트, 백그라운드 작업 에는 코루틴을 사용합니다"

그는 이어서 이렇게 설명했습니다.

"코루틴은 가벼운 스레드가 아닙니다,

디스패쳐 위에서 동작하는 동시성 프레임워크입니다.

코루틴의 진짜 힘은 취소와 구조화된동시성입니다."

이 답변이 면접관에게 강한 인상을 주었습니다

 

3. CoroutineScope 잘못 사용 - 'GlobalScope에서 코루틴을 실행하면 어떤일이 발생하나요?"

그의 답변

• GlobalScope로 실행된 코루틴을 직접 취소하지 않는 한 계속 살아남습니다.
• 이로 인해 메모리 누수가 발생할 수 있습니다
• 그리고 구조화된 동시성 원칙을 깨뜨립니다.

그는 실제 사례도 언급했습니다.

"Analytics 모듈에서 GlobalScope를 잘못 사용해 절대로 종료되지 않는 job이 생성된 것을 본적이 있습니다. 이를 applicationScope와 올바른 supervision을 사용하도록 수정했습니다."

면접관들은 이런 실무 경험 기반 답변을 높게 평가했습니다.

 

4. Compose - 리컴포즈션은 실제로 어떻게 동작하나요? 

아라빈드는 이렇게 명확하게 설명했습니다.

• Composable은 모두 상태가 변경되면 다시 실행될 수 있는 함수입니다
• Compose는 컴포저블 내부에서 어떤 state 를 읽는지 추적합니다.
• 그 state가 변경되면, 컴포즈는 그 state에 의존하는 컴포저블만 다시 실행합니다.
• 모든 UI가 리컴포지션 되는것이 아니라, 변경한 state에 의존하는 노드만 리컴포지션됩니다.

그리고 그가 이렇게 말했습니다.

키는 정말 중요합니다 LazyColumn에서 키를 잘못사용하면 전체 리컴포지션이나 리스트 깜빡임이 발생할 수 있습니다.

이 라운드는 난이도가 높았습니다.

컴포즈를 그냥 쓸줄아는지가 아니라 정확히 이해하고 있는지를 확인하려는 질문이었습니다.

 

5. State Hosting: 왜 컴포즈는 state hosting을 권장하나요?

아라빈드의 설명

• UI를 stateless하게 만들기 때문에 테스트하기 쉬워집니다.
• 부모 컴포넌트가 UI 상태를 제어하고 관리할 수 있게 됩니다. 
• 화면 간에 상태 불일치를 방지할 수 있습니다.

그는 실제로 한 예시를 보여줬습니다.

컴포즈 내부에서 잘못 관리된 상태가 어떻게 문제를 만드는지,

그리고 그 상태를 hoisting 하여 해결한 사례

이를 본 면접관이 말했습니다

"좋습니다. 대부분에 지원자들이 컴포즈에서 상태 때문에 어려움을 겪습니다"

 

2라운드: 시스템 디자인 + 안드로이드 아키텍쳐 (난이도 높은 라운드)

이 라운드는 정말 보쉬 스타일이었습니다.

깊고, 체계적이며, 장기적인 유지보수성을 중심으로 진행됐습니다.

 

1. 보쉬 차량 관리 (fleet management) 앱을 위한 확장 가능한 아키텍처를 설계하세요.

이게 라운드의 핵심 질문이였습니다.

면접관이 원하는 것 

• 멀티모듈 아키텍쳐
• 오프라인 우선 기능
• Domain-Data-UI의 깨끗한 레이어링
• 명확한 경계
• 컴포즈 기반 UI 구조
• 백그라운드 동기화 아키텍쳐

아라반드의 제안 

아키텍쳐 레이어

• 도메인 -> Usecase, 비즈니스 로직
• 데이터 -> Repository, caching, network source
• UI -> 컴포즈 스크린 + ViewModel

모듈 구성 

• 네트워크
• 데이터베이스
• 트래킹
• map-core
• vehicle-profile
• app-ui

멀티모듈을 사용하는 이유 

• 빌드 시간 단축
• 재사용 가능한 컴포넌트(보쉬에는 내부에 여러 앱이 있음)
• 신규 개발자 온보딩 쉬움

Offline-first 전략 

• Room + Flow ->로컬 데이터 변경을 즉시 UI에 공급
• WorkManager -> 실패 시 재시도 & 백오프 로직
• 도메인 로직 기반 캐시 무효화 규칙 설계

면접관이 인상깊게 본 핵심 포인트

10초마다 차량 상태를 동기화 한다고 해서 UI가 10초마다 리컴포지션 될 필요는 없습니다

동기화는 Repository 층에서 격리 시키고, UI에 필요한 변화만 전달합니다.

보쉬는 '실전적이고 깊은 아키텍처 사고방식' 을 매우 좋아합니다

 

2. 컴포즈를 많이 사용하는 화면에서 성능을 어떻게 보장하나요 ?

아라빈드가 언급한 내용 

• remember 올바르게 사용하기
• 무거운 로직은 컴포저블 내부가 아닌 외부로 이동시키기
• 파생 계산에는 derivedStateOf 사용
• 상태 변화를 관찰 할 때는 SnapShotFlow 사용 
• LazyColumn에서는 Key를 올바르게 지정하기
• 불필요한 리컴포지션을 막기 위해 Stable 클래스를 사용하기

면접관의 평가

"좋습니다, 많은 시니어 개발자도 이 질문에 제대로 답 못합니다"

 

3. UI 상태를 어떤 디자인 패턴으로 관리하나요?

그의 답변

• MVI 패턴 사용
• UI State는 sealed class 로 표현
• Reactive UI를 위하 Flow 사용

그리고 그는 Compose에 MVI가 적합한 이유를 이렇게 설명했습니다.

"Compose는 단방향 데이터 흐름을 선호함으로, MVI가 자연스럽게 잘 맞습니다."

 

3라운드 코딩 과제 

보쉬는 90분짜리 코딩 챌린지를 내줬습니다.

단순한 리트코드 문제 트릭이 아니라 실제 앱 구조 문제였습니다.

 

과제 내용:

API에서 장비 목록을 받아오고, Compose 리스트로 보여주며, 즐겨 찾기 기능을 제공하고,

즐겨찾기 상태를로컬에 저장하는 작은 앱을 구현하세요. 

 

아라빈드의 풀이 방식

• 네트워크 통신 Ktor
• 로컬 저장 : Room
• 아키텍처: MVVM과 Repository
• 리스트 렌더링: LazyColumn과 키 설정
• UI 상태 유지: rememberSaveable
• 로컬 변경 감지: Flow 기반 업데이트
• sealed class로 상태 예외 처리 

며접관들이 특히 집중해서 본 부분

• 클린 코드
• 관심사 분리 soc)
• 테스트 가능 구조
• 컴포즈 성능 관리 
• 거대 클래스 없이 역할 분리

그는 95% 를 구현해내며 매우 강한 퍼포먼스를 보여줬습니다.

 

4라운드: 매니저 면접 + 문화 적합성 

이 라운드는 예상보다 솔직하고, 실제 업무에서 마주치는 문제들에 초점을 두었습니다

 

1. 아키텍트와 의견 충돌이 있을 때 어떻게 대처하나요?

그의 답변:

"데이터에 집중합니다. 아키텍쳐 결정을 증명할 때에는 앱 실행 시간, 메모리 사용량, 

리컴포지션 발생 횟수, 빌드 시간 영향 같은 지표로 설명합니다.

면접관들은 극 감정적으로 대처하지 않고 엔지니어링 기반 사고로 해결한다는 점을 높게 평가했습니다.

 

2. 주니어 개발자들을 어떻게 멘토링하나요?

판단하려는 마음이 아니라, 가르칠려는 마음으로 코드리뷰를 합니다.

그리고 그 주니어가 기능을 처음부터 끝까지 직접 맡아보게하여 자신감을 쌓도록 돕습니다.

 

3. 앱 모듈을 재 설계했던 경험을 말해보세요.

그는 실제 사례를 설명했습니다.

하나의 거대한 모듈을 5개의 작은 모듈로 나누어 빌드 시간 40%을 감소 시킨경험

보쉬는 모듈화 철학을 중요하게 여기기 때문에 이부분을 높게 평가했습니다.

 

최종 HR 라운드 

아주 간단했습니다. 

다음 항목만 확인했습니다.

• 커뮤니케이션
• 퇴사 시 인수기간
• 연봉 기대치
• 왜 보쉬인가
• 장기적인 안정성에 대한 생각

아라빈드는 보쉬에 안정성, 엔지니어링 중심 문화가 자신과 잘 맞는다고 강조했습니다.

 

최종 결과 

일주일 후 그는 합격 제안을 받았습니다.

그에게 전달된 피드백

• 탄탄한 Kotlin 기초 
• 매우 강한 컴포즈 이해도
• 뛰어난 아키텍처 사고
• 클린 코드 + 모듈러 디자인
• 조직 문화와의 높은 적합성