이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
향후 OS 업데이트에 대응하기 위해 가장 중요하게 생각하는 것은 플랫폼 의존 코드를 비즈니스 로직과 분리해두는 것입니다. OS 업데이트 때마다 API 변경 영향이 특정 레이어에만 집중되면, 수정 범위가 좁아지고 다른 기능에 사이드 이펙트가 줄어듭니다. iOS 개발 경험에서 폐기 예정 API가 포함된 코드를 어댑터 패턴으로 감싸두자, 이후 업데이트에서 어댑터 내부만 교체하면 됐습니다.
베타 버전 테스트를 정식 출시 전에 하는 것이 중요한데, Xcode 베타나 Android Preview 환경에서 앱을 먼저 빌드해보면 호환성 문제를 미리 파악할 수 있습니다. 프라이버시 정책 변화가 매년 강화되는 추세라 권한 관련 코드는 OS 정책을 주기적으로 확인하는 루틴을 만들어두는 것이 유용합니다. OS 업데이트 대응은 미리 분리된 구조가 변경 비용을 줄인다는 결을 배웠습니다.
Android OS가 업데이트될 때 Deprecated API 경고가 코드에 쌓이는 걸 보고도 급하지 않아 미뤄두다가 나중에 한꺼번에 대응해야 했던 경험이 있습니다. 마이너 업데이트에서는 괜찮았는데, 메이저 업데이트에서 앱이 죽는 상황이 생겼습니다.
이후엔 IDE에서 Deprecated 경고가 뜨면 즉시 대체 API로 교체하는 습관을 만들었습니다. targetSdkVersion을 항상 최신에 맞추고, 베타 채널 기기에서 먼저 돌려보는 방식으로 조기에 확인하게 됐습니다.
이 경험으로 OS 업데이트 대응은 업데이트 직전이 아니라 평소에 경고를 쌓지 않는 것에서 시작된다는 걸 배웠습니다. 경고 하나를 미루면 다음 메이저 업데이트에서 뭉텅이로 돌아옵니다.
OS 업데이트 대응을 위해 베타 채널 기기 한 대로만 검증하다가 특정 제조사 기기에서만 나타나는 문제를 놓친 경험이 있습니다. 베타에서 통과한 코드가 실제 출시 기기에서 오동작했습니다.
이 경험으로 모든 기기를 직접 검증하는 건 현실적으로 불가능하다는 한계를 받아들이게 됐습니다. 대신 영향 사용자가 많은 기기 모델 상위 3개를 우선 검증 대상으로 삼는 방식을 정했습니다. 나머지는 `Firebase Test Lab`으로 클라우드 기기에서 자동 테스트를 돌려 보완했습니다.
이 경험으로 OS 업데이트 대응에서 완벽한 검증보다 우선순위를 정한 검증이 현실적이라는 걸 배웠습니다. 한계를 인정하고 커버 범위를 설계하는 것이 더 나은 접근이었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 iMBC 모바일 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.