모바일 개발자 이력서 예시

헬스케어와 커머스 도메인에서 6년간 iOS와 안드로이드 애플리케이션을 개발했습니다. 마루헬스케어 재직 당시 HealthKit과 Google Fit을 연동해 걸음 수와 심박 데이터를 수집하는 화면을 구현했고, 백그라운드 동기화 주기와 배터리 소모 기준을 팀과 함께 검토했습니다. 온빛커머스에서는 월 활성 사용자 95만 명 규모의 iOS 앱에서 상품 상세와 리뷰 영역을 담당하며, 화면 성능과 네트워크 예외 처리를 개선했습니다. 특정 플랫폼이나 기능 구현에만 매몰되지 않고, 사용자가 화면을 마주하는 조건을 먼저 확인하며 개발 범위를 정하는 방식으로 일해 왔습니다. 초기 렌더 시간과 스크롤 성능에 한계가 있었습니다. 온빛커머스 상품 상세 화면은 이미지와 리뷰가 동시에 노출되는 구조였기에, 화면 구성을 전면 변경하기보다 이미지 프리페치와 셀 재사용 구조를 우선 조정했습니다. 기존 상품 상세의 기능 범위를 유지하면서 사용자가 가장 먼저 체감하는 구간을 줄이는 데 집중한 결과, 초기 렌더 시간을 1.9초에서 0.8초로 단축했고 스크롤 프레임 드랍 구간을 제거했습니다. 약전계 환경에서는 요청 실패 12종을 유형별로 분류한 뒤 재시도 정책과 캐시 노출 기준을 문서화해 팀 규약으로 확정했고, 관련 문의 유입을 월 40건에서 11건으로 줄였습니다. 이러한 과정은 기능 구현과 운영 조건을 함께 살피는 업무 기준을 쌓는 계기가 되었습니다. [핵심 역량] - 월 활성 사용자 95만 명 iOS 앱의 상품 상세·리뷰 개발 - 이미지 프리페치·셀 재사용 구조 개선 - HealthKit·Google Fit 기반 활동 데이터 수집 - SwiftUI 기반 iOS 공통 컴포넌트 32종 정리 - iOS·안드로이드 플랫폼별 화면 사양 조정

상품 상세와 리뷰는 사용자가 구매를 결정하기 전 반복해서 확인하는 화면이기에, 기능의 완성도와 로딩 속도 및 네트워크 상태별 안내가 사용자 경험에 직접적인 영향을 준다고 판단했습니다. 온빛커머스에서 월 활성 사용자 95만 명 규모의 iOS 앱을 개발하며 이러한 점을 확인했습니다. 이미지와 리뷰가 함께 노출되는 상품 상세 화면에서는 초기 렌더 시간이 1.9초에 달했고, 약전계 환경에서는 요청 실패가 12종으로 나뉘어 사용자 문의로 이어졌습니다. 화면을 크게 재설계하기보다 이미지 프리페치와 셀 재사용 구조를 먼저 조정하고, 오류 유형별 재시도 정책과 캐시 노출 기준을 정리했습니다. 그 결과 초기 렌더 시간은 0.8초로 단축되었고, 관련 문의 유입은 월 40건에서 11건으로 감소했습니다. 헬스케어 앱 개발 경험은 사용 조건을 기준으로 기능을 판단하는 데 영향을 주었습니다. 걸음 수와 심박 데이터를 수집할 때는 HealthKit과 Google Fit의 플랫폼 차이를 먼저 정리하고, 백그라운드 동기화 주기와 배터리 소모 기준을 함께 검토했습니다. 두 플랫폼의 공통 리포트 사양을 정리한 결과 화면 차이를 8건에서 3건으로 축소했습니다. 모든 플랫폼의 동작을 동일하게 만드는 것보다 공통 사용자 경험을 유지하면서 OS별 제약을 수용하는 편이 적절하다는 기준을 세웠습니다. 상품 상세와 리뷰 기능에서도 기존 기능을 유지할 부분과 플랫폼·네트워크 조건에 맞춰 다르게 처리할 부분을 나누며, 사용자가 체감하는 성능과 안정성을 기준으로 개발하려 합니다.

사내 공통 UI 컴포넌트 라이브러리를 주도하면서, 화면마다 흩어져 있던 버튼·입력·모달 구현을 iOS 공통 컴포넌트 32종으로 정리했습니다. SwiftUI 기반 프리뷰와 사용 예제를 문서화하여 신규 화면에서 컴포넌트 적용 기준을 명확히 확인하도록 했고, 팀원 4명을 대상으로 사용 교육을 진행했습니다. 이전에는 화면별 구현 차이를 확인하는 데 별도 조율이 필요했지만, 이제는 공통 규격과 예제를 기준으로 검토할 수 있는 구조가 마련되었습니다. 개발 속도만 앞세우기보다 반복되는 구현을 분리하고 이후 화면에서도 재사용할 수 있는 단위를 정하는 것이 제 업무 기준입니다.