모바일 개발자 면접 준비 예시

저는 온빛커머스 상품 상세의 첫 화면 진입부터 주요 이미지와 리뷰가 표시될 때까지를 초기 렌더로 잡고, 같은 기기와 네트워크 조건에서 기존 화면과 개선 화면을 비교했습니다. 측정 기록을 보니 큰 이미지가 순차적으로 내려오고 셀 재사용 때 이미지 요청이 겹치면서 첫 표시와 스크롤이 모두 늦어졌습니다. 먼저 화면에 가까운 이미지 위주로 프리페치 범위를 좁히고, 셀에서 이전 이미지 요청을 정리하도록 재사용 흐름을 손봤습니다. 그 결과 초기 렌더는 1.9초에서 0.8초로 줄고 프레임 드랍 구간도 사라졌습니다. 이후에는 체감보다 측정 조건을 고정하는 것이 우선이라는 기준을 갖게 됐습니다.

저는 온빛커머스에서 약전계 환경 요청 실패 사례를 화면과 요청 결과 기준으로 모아 12종으로 분류했습니다. 응답이 지연되거나 연결이 끊긴 경우와, 서버가 명시적으로 오류를 돌려준 경우를 구분하고 데이터 변경 가능성도 함께 봤습니다. 읽기 요청은 재시도 가능한 조건과 횟수를 제한하고, 마지막 정상 응답이 유효한 경우에만 캐시를 보여주도록 기준을 정리했습니다. 반대로 변경 요청은 중복 처리 위험이 있어 무조건 다시 보내지 않고 사용자에게 현재 상태를 안내하도록 했습니다. 이 기준을 문서화해 팀 규약으로 만들었고 관련 문의는 월 40건에서 11건으로 줄었습니다. 오류별 위험을 구분해야 안정성과 최신성을 함께 지킬 수 있음을 배웠습니다.

저는 마루헬스케어에서 걸음 수와 심박 데이터를 갱신할 때 최신성을 높이려고 동기화를 자주 하면 배터리 소모와 백그라운드 실행 제약이 커지는 점을 먼저 확인했습니다. HealthKit과 Google Fit의 권한 흐름과 백그라운드 동작을 각각 정리하고, 화면을 열었을 때 최신 데이터를 확인하는 경로와 백그라운드 갱신을 분리했습니다. 사용자가 필요로 하는 데이터 갱신 시점과 기기에서 허용되는 실행 조건을 기준으로 주기를 조정하고, 반복 실행 시 배터리 사용도 점검했습니다. 공통 리포트 사양을 정리하면서 플랫폼 간 화면 차이를 8건에서 3건으로 줄였습니다. 동작을 억지로 같게 하기보다 공통 경험과 운영 제약을 함께 맞추는 것이 중요하다고 배웠습니다.

저는 개인 출시한 습관 기록 앱에서 알림 시각이 맞지 않는다는 사용자 리뷰 12건을 모아 발생 기기와 시간대가 공통으로 언급되는지 비교했습니다. 서버 없이 예약하는 구조에서 기기 시간대가 바뀌어도 기존 예약 시각이 남을 수 있다고 보고, 예약 생성과 시간대 변경 시각을 나누어 재현했습니다. 이후 현지 기기 시간대를 기준으로 예약 시각을 다시 계산하도록 수정하고 업데이트를 배포했습니다. 배포 뒤 2주간 스토어 콘솔의 주간 설치·삭제 추이를 비교해 반응을 살폈지만, 이 수치만으로 오류 해결이나 만족도를 단정하지는 않았습니다. 리뷰를 재현 조건으로 바꾸고 수정 뒤에도 지표의 한계를 함께 보는 습관을 얻었습니다.

저는 온빛커머스에서 상품 상세의 초기 렌더와 스크롤을 각각 나눠 살폈습니다. 먼저 동일한 기기와 진입 조건에서 화면 첫 표시까지의 시간, 이미지 표시 시점, 스크롤 중 끊김을 기록해 기준선을 만들었습니다. 다음으로 이미지 로딩과 셀 재사용 흐름을 확인해 프리페치 범위를 조정하고, 각 변경 뒤 같은 조건으로 다시 측정했습니다. 그 결과 초기 렌더는 1.9초에서 0.8초로 줄고 프레임 드랍 구간이 없어졌습니다. 같은 문제가 생기면 먼저 지표를 분리해 병목을 좁히고, 한 번에 한 요소씩 바꿔 효과와 부작용을 비교하겠습니다. 화면을 크게 바꾸기 전에 사용자가 기다리는 구간부터 줄이는 것이 제 기준입니다.

저는 온빛커머스에서 상품 정보를 읽어 오는 요청이 약전계에서 끊기는 사례를 대표 유형으로 삼았습니다. 응답 지연과 연결 단절을 서버 오류와 구분하고, 같은 읽기 요청을 제한된 조건에서 재시도하도록 했습니다. 마지막 정상 응답이 있고 내용이 허용 범위 안에서 유효할 때는 캐시를 보여주되, 오래된 정보를 새 정보처럼 보이지 않도록 갱신 상태를 함께 안내하는 기준을 정리했습니다. 요청 실패 12종을 이렇게 나누어 재시도와 캐시 노출 조건을 문서화했고, 관련 문의는 월 40건에서 11건으로 감소했습니다. 모든 실패를 다시 보내기보다 요청 성격과 데이터 최신성을 함께 판단해야 한다는 점을 배웠습니다.

저는 온빛커머스에서 화면마다 달랐던 버튼과 입력, 모달을 반복 사용 여부와 동작 규칙을 기준으로 나눠 SwiftUI 공통 컴포넌트 32종으로 정리했습니다. 프리뷰와 사용 예제를 함께 만들어 화면 구현자가 상태와 간격을 빠르게 확인하게 했고, 팀원 4명에게 적용 기준도 공유했습니다. SwiftUI와 UIKit이 함께 있는 화면이라면 우선 변경 빈도와 화면 경계, 기존 동작 의존성을 살펴 공통 규격부터 정하고 작은 영역에서 교체 비용과 사용성을 검증하겠습니다. 제가 해 온 일은 공통 컴포넌트 정리이며, 두 기술의 공존 구조를 직접 전환한 경험과는 구분합니다. 재사용은 구현을 한곳에 모으는 데서 끝나지 않고 적용 기준까지 공유해야 효과가 난다고 배웠습니다.

저는 사진 리뷰 업로드 실패를 다룬 경험은 없지만, 온빛커머스에서 요청 실패 12종을 분류해 재시도와 캐시 기준을 정리한 경험이 있습니다. 업로드를 맡는다면 사진 선택, 변환, 전송 시작, 서버 응답, 화면 상태 반영으로 단계를 나누고 각 단계의 실패 기록과 재현 조건을 먼저 모으겠습니다. 특히 서버 응답이 불분명할 때 같은 사진을 다시 보내면 중복 등록될 수 있으므로 요청 식별과 기존 업로드 상태 확인을 우선하겠습니다. 실패 지점별 안내와 재시도 가능 조건을 정하고, 첫 3개월에는 실패율과 중복 제출 여부를 함께 살피겠습니다. 오류 유형에 따라 정책을 달리해야 사용자의 불안과 반복 요청을 줄일 수 있다고 생각합니다.

저는 크래시 상위 원인을 분석해 핫픽스로 대응한 경험은 없습니다. 가장 가까운 경험은 온빛커머스 상품 상세 성능 개선으로, 초기 렌더와 스크롤 병목을 확인해 이미지 프리페치와 셀 재사용 구조를 조정했고 초기 렌더를 1.9초에서 0.8초로 줄였습니다. 또 약전계 오류 문의를 유형별로 정리해 관련 문의를 월 40건에서 11건으로 낮췄습니다. 입사 후 첫 1개월에는 크래시와 성능 지표의 기준선을 확인하고 상위 원인을 재현 조건과 연결하겠습니다. 이후에는 원인별 수정과 배포 뒤 지표 변화를 확인하는 루틴을 익혀 운영 대응 역량을 채우겠습니다.

저는 사진 리뷰 업로드 실패율을 낮춘 경험은 없습니다. 온빛커머스에서는 상품 상세와 리뷰 노출을 맡았고, 약전계 요청 실패 12종을 분류해 오류별 재시도와 캐시 기준을 정리했습니다. 이 과정에서 단순히 다시 요청하는 대신 실패 유형과 사용자에게 보여줄 상태를 구분했고, 관련 문의는 월 40건에서 11건으로 줄었습니다. 입사 후 3개월 동안 사진 선택부터 서버 응답과 화면 반영까지 실패 지점을 나누고, 재현 조건과 실패율을 기준선으로 삼겠습니다. 중복 등록 가능성과 재시도 조건을 함께 검증해 사용자 안내와 복구 흐름을 개선하겠습니다.

저는 온빛커머스에서 화면마다 달랐던 네트워크 오류 처리를 공통 규칙으로 정리할 때, 먼저 실제 실패 사례 12종과 각 화면의 기존 동작을 나란히 정리했습니다. 무조건 재시도하면 중복 요청이나 불필요한 대기가 생기고, 캐시를 항상 보여주면 오래된 정보가 최신처럼 보일 수 있어 요청 성격과 데이터 유효성을 우선 기준으로 삼았습니다. 화면별 차이는 필요한 예외로 분리하고, 공통 기준은 재시도 조건과 캐시 노출 조건으로 문서화해 팀 규약으로 확정했습니다. 이후 관련 문의가 월 40건에서 11건으로 줄었습니다. 사용자에게 일관된 안내를 주되 예외를 없애기보다 근거 있는 규칙으로 관리하는 것이 중요하다고 배웠습니다.

저는 마루헬스케어에서 iOS와 Android 리포트 화면을 비교해 불일치 8건을 유형별로 정리했습니다. 날짜 범위와 요약 항목처럼 양쪽에서 같은 의미로 보여줄 수 있는 부분은 공통 사양으로 맞췄고, 백그라운드 갱신 시점처럼 운영체제의 실행 제약이 다른 부분은 억지로 동일하게 만들지 않고 예외로 남겼습니다. 이 기준으로 화면 차이를 3건까지 줄였고, 남은 차이는 사용자가 보는 결과보다 갱신 시점의 차이에 집중되도록 정리했습니다. 공통화는 차이를 모두 없애는 일이 아니라 사용자의 이해를 해치지 않는 범위에서 차이를 설명 가능하게 만드는 일이라고 배웠습니다.