모바일 개발자 커리어 로드맵 예시

🔍 커리어 돌아보기

여울트래블

• 수행 레벨은 개선에서 설계 초입까지 올라와 있어요. 숙소 목록에서 이미지 디코딩을 비동기화하고 항목 재사용을 정리해 저사양 기기 초기 렌더를 2.4초에서 1.1초로 줄였고, 결제 수단 5종과 실패 8개 분기를 상태 머신으로 묶었습니다. 기존 기능을 처리한 수준보다 원인을 찾고 구조를 바꾼 작업에 가깝습니다.
• 난이도는 실사용 규모와 운영 책임이 읽힙니다. 월 활성 사용자 180만 명 여행 예약 앱에서 크래시 대시보드와 릴리스 후 48시간 관찰 절차를 만들었고, 크래시 없는 사용자 비율을 99.1%에서 99.7%로 올렸습니다. 다만 장애 규모, 영향 사용자 수, 팀 내 의사결정 범위는 기록에 없어 최종 주도 레벨은 판정 불가입니다.
• 시장 동시대성은 높습니다. Jetpack Compose, Coroutines, Gradle 멀티모듈, CI 파이프라인을 사용했고, 빌드 시간을 11분에서 4분으로 줄였으며 스토어 배포를 90분에서 20분으로 단축했습니다. 플랫폼 엔지니어링과 개발자 경험에 연결되는 재료가 이미 있습니다.

다온소프트

• 수행 레벨은 기능 구현에서 운영 개선으로 상승한 흐름입니다. 현장 점검 앱을 처음부터 만들고 오프라인 저장·동기화를 붙였으며, 사진 압축과 재시도 큐로 업로드 실패율을 12%에서 2%로 낮췄습니다. 화면 단위 구현만 한 경력으로 보기는 어렵습니다.
• 난이도는 네트워크가 불안정한 현장과 60명 작업자라는 사용 맥락이 분명합니다. 입력 단계를 줄여 점검 1건 등록 시간을 4분에서 2분 30초로 단축했고, APK 전달 방식을 사내 배포 링크로 바꿨습니다. 다만 앱 아키텍처 의사결정과 릴리스 품질 지표의 범위는 기록이 얇아 설계 수준은 일부 판정 불가입니다.
• 시장 동시대성은 현재 목표와 직접 연결되는 항목과 과거 방식이 섞여 있습니다. 네트워크 계층 분리와 재시도 큐는 지금도 유효하지만, 메신저로 APK를 전달하던 환경은 현대적인 모바일 플랫폼 운영의 증거로는 약합니다. 당시 문제를 해결한 맥락은 남지만, 최신 빌드·릴리스 체계의 증명은 여울트래블 경력으로 보강됐습니다.

사내 모바일 공통 모듈

• 수행 레벨은 설계와 적용까지 진행한 작업입니다. 앱마다 따로 있던 네트워크·로깅 코드를 공통 모듈로 묶고 두 개 앱에 순차 적용했으며, 마이그레이션 순서를 문서로 남겼습니다. 목표 직무와 가장 직접적으로 맞닿은 경력 항목입니다.
• 난이도는 두 앱 간 설정 차이와 이행 순서를 다뤘다는 점에서 중간 이상입니다. 하지만 모듈 API의 호환성 정책, 버전 배포 방식, 적용 후 빌드·장애 지표는 기록되지 않아 여러 팀이 쓰는 플랫폼을 주도했다고 단정할 수 없습니다. 다음 기록에는 소비 팀 수, 도입 기간, 회귀 건수, 유지보수 방식이 필요합니다.
• 시장 동시대성은 좋습니다. 네트워크와 로깅을 공통화하고 다른 팀이 스스로 붙도록 문서화한 방식은 모바일 플랫폼 팀의 기본 업무와 맞습니다. 다만 저장소 공개나 외부 배포 여부는 없으므로 외부 시장에서 재현 가능한 증거인지는 판정 불가입니다.

📍 현재 위치

성장 사다리로 보면 기능 단위 실행을 이미 넘어 앱 일부 영역의 설계와 운영 개선을 맡는 미들급 후반입니다. 빌드·배포·크래시 대응에서 플랫폼 업무로 옮길 재료가 충분하지만, 모바일 플랫폼 엔지니어의 시니어 신호인 여러 앱 대상 표준 설계, 개발자 경험 지표, 호환성 운영까지는 아직 한 단계가 남아 있어요.

강점

• 최근 기록에서 Gradle 모듈을 검색·예약·마이페이지 기능으로 분리하고 증분 빌드를 3분에서 1분 20초로 줄였습니다. 문제를 측정한 뒤 구조와 캐시 설정을 바꾼 흐름은 플랫폼 후보에게 필요한 원인 분석 신호입니다. 목표 대비로는 빌드 플랫폼 영역을 바로 확장할 수 있는 출발점입니다.
• CI에서 서명·스토어 업로드·릴리스 노트 생성을 연결해 배포 시간을 90분에서 20분으로 낮췄습니다. 개발자의 반복 작업을 파이프라인으로 치환하고 팀의 릴리스 흐름을 바꾼 경험으로 읽힙니다. 목표 대비로는 개발자 경험과 릴리스 플랫폼의 실적이 이미 있습니다.
• 릴리스 후 48시간 동안 크래시와 결제 실패를 관찰하는 절차를 만들고 두 번의 릴리스에서 이슈를 당일 확인했습니다. 배포 전 자동화뿐 아니라 배포 후 운영 신호까지 본 점이 강점입니다. 목표 대비로는 모바일 플랫폼의 품질 게이트와 관찰성으로 확장할 기반이 됩니다.

공백

• 현재 기록은 주로 한 앱의 개선 결과이고, 플랫폼 정책을 여러 앱에 배포하고 버전을 관리한 사례가 부족합니다. 모바일 플랫폼 엔지니어는 공통 모듈 자체보다 소비 팀의 도입 비용, 호환성, 회귀 통제를 책임져야 합니다. 두 앱 공통 모듈 경험이 있지만 소비 팀 수와 운영 지표가 없어 목표 수준의 반복 가능한 플랫폼 오너십으로는 아직 약합니다.
• 개발자 경험을 빌드 시간과 배포 시간으로 측정한 것은 좋지만, 실패율·대기 시간 분포·도입률·업데이트 성공률 같은 플랫폼 지표가 없습니다. 플랫폼 직무에서는 도구를 만든 사실보다 내부 사용자가 얼마나 안정적으로 쓰는지가 중요합니다. 다음 분기에 기준선과 목표치를 직접 정의해야 시장 신호가 완성됩니다.

🧭 목표 대비 격차

이미 준비된 것

• 빌드와 릴리스 자동화는 목표 직무의 핵심 기반에 가깝습니다. Gradle 모듈 분리로 증분 빌드를 3분에서 1분 20초로 줄이고 CI 배포를 90분에서 20분으로 줄인 기록이 있어, 플랫폼 작업을 말이 아니라 전후 수치로 설명할 수 있습니다. 현 직장에서 파이프라인의 공식 오너와 지표를 맡는 경로 A가 가장 빠릅니다.
• 공통 모듈을 두 앱에 적용하고 다른 팀이 붙을 수 있도록 문서를 작성한 경험이 있습니다. 이는 앱 내부 코드 정리보다 플랫폼 소비자를 고려한 설계로 평가받을 수 있습니다. 현 직장 확장과 개인 프로젝트의 문서·릴리스 산출물로 재현성을 높일 수 있습니다.

비어 있는 것

• 여러 소비 팀을 대상으로 한 플랫폼 API와 호환성 운영이 비어 있습니다. 가이드상 모바일 플랫폼 엔지니어는 공통 기반의 모듈화만이 아니라 버전 정책, 마이그레이션, 회귀 통제를 설계해야 하므로 두 앱 적용만으로는 부족합니다. 현재 회사에서 소비 앱을 늘리는 경로 A를 먼저 시도하고, 불가능하면 이직 경로 C를 봐야 합니다.
• 개발자 경험 지표의 범위가 좁습니다. 빌드 시간과 배포 시간을 측정했지만 실패율, 캐시 적중률, 파이프라인 성공률, 릴리스 복구 시간까지 이어지지 않아 플랫폼 투자 우선순위를 결정할 근거가 부족합니다. 현 직장 파이프라인에 지표를 추가하고 개인 프로젝트에서 대시보드 형태로 보완할 수 있습니다.
• 플랫폼 업무를 공식적으로 결정하고 다른 개발자를 움직인 기록이 약합니다. 현재는 빌드와 배포 파이프라인을 혼자 손보고 있지만 공식 역할은 아니므로, 코드 작성 능력과 플랫폼 오너십 사이에 증거 공백이 있습니다. 현 직장의 RFC·리뷰·도입 회의로 우선 메우고, 그런 권한이 구조적으로 없을 때만 플랫폼 팀이 있는 회사로 옮겨야 합니다.
• 대규모 모바일 플랫폼 운영은 개인 프로젝트로 증명할 수 없습니다. 외부 프로젝트에서 여러 팀의 실제 도입 압력과 장애 책임을 재현하기 어렵기 때문입니다. 이 공백은 월 활성 사용자 180만 명 앱의 내부 플랫폼 오너십이나 플랫폼 팀이 분리된 회사의 실서비스 운영으로 채워야 합니다.

🔀 경로 선택

🏢 경로 A · 현 직장 안에서

플랫폼 오너십 공식화

다음 2주 안에 모바일 플랫폼 범위를 빌드, 배포, 공통 모듈로 정의한 1쪽 RFC를 작성하고 팀 리더에게 공식 담당 영역으로 제안하세요. 현재 빌드 11분에서 4분, 배포 90분에서 20분으로 줄인 기록은 개인 최적화가 아니라 팀 플랫폼의 출발점이지만, 공식 책임과 우선순위가 기록되지 않았습니다. RFC 승인 여부, 범위, 의사결정자, 월별 목표를 문서와 회의 기록으로 남기세요.

파이프라인 지표 확장

다음 달부터 CI에 빌드 성공률, 평균·p95 대기 시간, 캐시 적중률, 배포 실패 건수를 수집하는 대시보드를 제안하세요. 기존에는 클린 빌드 11분과 증분 빌드 3분을 측정했으므로, 이제 도구 성능을 팀 사용 경험과 릴리스 안정성으로 연결해야 합니다. 4주 기준선과 개선 전후 수치, 실패 원인별 조치 내역을 저장하세요.

공통 모듈 확장

두 앱에 적용한 네트워크·로깅 모듈을 예약 관련 다른 앱이나 신규 기능까지 확장할 소비 팀을 찾아 버전 정책과 마이그레이션 절차를 제안하세요. 현재 기록에는 두 앱 적용과 문서 작성이 있지만 소비 팀 수, 도입 실패, 호환성 대응이 없어서 플랫폼 오너십 판단이 멈춰 있습니다. 적용 앱 수, 도입 소요 시간, 회귀 건수, 모듈 버전별 변경 내역을 릴리스마다 기록하세요.

릴리스 품질 게이트

현재 릴리스 후 48시간 모니터링 절차를 CI 단계의 품질 게이트와 연결해 크래시, 결제 실패, 권한 회귀를 확인하는 체크리스트를 표준화하세요. 크래시 없는 사용자 비율이 99.1%에서 99.7%로 오른 경험은 운영 근거가 있지만, 플랫폼 역할로 보이려면 사전 차단과 배포 중단 기준까지 필요합니다. 릴리스별 차단 조건, 실제 탐지 건수, 복구 시간, 예외 승인 기록을 남기세요.

🧪 경로 B · 개인 프로젝트로

모바일 빌드 플랫폼

오픈소스 또는 비공개 저장소에 샘플 안드로이드 앱과 Gradle 멀티모듈 템플릿을 만들고 원격 캐시, 병렬 빌드, CI 측정을 포함하세요. 단순 설정 모음은 시장 신호가 약하므로 재현 가능한 실행 절차, 설계 선택 이유, 기준선 대비 빌드 시간과 실패율을 공개해야 합니다. 4주 동안 저장소, 설계 문서, CI 실행 기록, 전후 측정 결과를 산출물로 남기세요.

공통 SDK 배포 도구

네트워크·로깅 공통 모듈을 샘플 앱 두 개가 소비하도록 만들고 버전 업그레이드, 하위 호환성, 마이그레이션 가이드를 포함하세요. 코드만 올리면 통하지 않고 소비 앱의 변경량, API 안정성, 회귀 테스트, 릴리스 노트가 있어야 플랫폼 설계 신호가 됩니다. 6주 동안 모듈 저장소, 샘플 소비 앱, 테스트, 버전 정책 문서를 완성하세요.

모바일 품질 대시보드

Crashlytics와 유사한 실서비스 연동 없이도 샘플 앱의 빌드, 테스트, 배포 결과를 수집해 릴리스 품질 대시보드를 구현하세요. 대시보드 화면보다 실패 분류, 릴리스별 비교, 품질 게이트 판단 규칙이 있어야 현재의 48시간 모니터링 경험을 플랫폼 도구로 확장했다는 신호가 됩니다. 6주에서 8주 동안 설계 문서, 수집 파이프라인, 대시보드 캡처, 가상 장애 시나리오 결과를 남기세요.

개인 프로젝트로는 안 되는 것

개인 프로젝트로는 월 활성 사용자 180만 명 앱에서의 실제 릴리스 장애 대응과 여러 팀의 도입 압력을 증명할 수 없습니다. 이 격차는 현 직장에서 두 앱 이상을 대상으로 공식 플랫폼 오너가 되거나, 플랫폼 팀이 있는 중간 규모 이상의 모바일 서비스 회사에서 실서비스 온콜과 마이그레이션을 맡아야 채워집니다.

🧳 경로 C · 이직 관점

현 시점에는 이직이 필요하지 않아요. 현재 회사는 월 활성 사용자 180만 명, 모바일 팀 6명이고 이미 빌드·배포·공통 모듈·크래시 운영 과제가 있어, 목표 격차 대부분을 내부에서 만들 가능성이 있습니다. 2개 분기 안에 공식 오너십, 소비 앱 확대, 플랫폼 지표를 얻지 못하면 이직을 다시 검토하세요.

성장 중간 플랫폼팀

모바일 사용자가 있고 앱 규모가 커지는 중간 규모 여행·커머스·콘텐츠 회사의 플랫폼 팀을 우선 보세요. 현재 경험인 빌드 11분에서 4분 단축과 배포 90분에서 20분 단축을 포트폴리오로 정리한 뒤, 내부 공통 모듈과 CI 표준을 여러 앱에 적용하는 역할이 명시된 공고에 지원하는 시점이 적절합니다. 실적은 빌드·배포 개선에는 통하지만 여러 소비 팀 운영과 공식 권한은 아직 약하므로 RFC와 도입 지표가 필요합니다.

대규모 앱 플랫폼조직

모바일 앱이 핵심 채널이고 별도 플랫폼 조직이 있는 대규모 서비스 회사를 다음 선택지로 보세요. 두 앱 공통 모듈 적용을 소비 앱 수, 마이그레이션 기간, 회귀 건수로 보강하고 파이프라인 성공률까지 갖춘 뒤에야 플랫폼 설계 역량을 설득하기 쉽습니다. 현재 기록만으로는 단일 앱 개선 전문가로는 강하지만 플랫폼 표준을 전사에 배포한 증거가 부족합니다.

개발자경험 플랫폼팀

빌드 인프라와 개발자 경험을 제품처럼 운영하는 플랫폼 팀이 있는 회사도 맞는 방향입니다. 현 직장에서 2개 분기 동안 공식 담당 범위와 지표를 확보했는데도 업무가 화면 개발로 되돌아가거나 공통 모듈 소비자가 늘지 않을 때, RFC·대시보드·마이그레이션 문서를 갖춘 상태로 지원하세요. Gradle과 CI 실적은 강점이지만 대규모 플랫폼 장애 책임은 이직 후 새로 확보해야 합니다.

🎯 단기 목표 (분기)

• 플랫폼 RFC 승인경로 A · 현 직장

  달성 판정: 빌드·배포·공통 모듈 범위, 담당 권한, 분기 지표가 담긴 RFC 1건과 리뷰·승인 기록이 남으면 달성입니다.

• CI 지표 대시보드 구축경로 A · 현 직장

  달성 판정: 4주간 빌드 성공률, p95 대기 시간, 캐시 적중률, 배포 실패 건수를 수집하고 기준선과 개선 결과를 기록하면 달성입니다.

• 멀티모듈 템플릿 공개경로 B · 개인 프로젝트

  달성 판정: 샘플 앱, Gradle 멀티모듈, 원격 캐시, CI 설정, 설계 문서와 전후 빌드 측정 결과가 저장소에 남으면 달성입니다.

⚠️ 리스크·막힘 지점

• 플랫폼 RFC가 우선순위로 승인되지 않고 화면 기능 일정에 밀리면 현 직장 오너십 계획이 멈춥니다.

  대안RFC를 빌드 파이프라인 한정의 작은 실험으로 줄이고, 4주 측정 결과를 다시 제안 자료로 사용하세요.

• 퇴근 후 시간이 부족해 개인 프로젝트를 90일 안에 완성하기 어렵다면 세 프로젝트를 병렬로 벌리지 마세요.

  대안빌드 템플릿 하나만 선택해 설계 문서, 실행 로그, 전후 수치까지 완성하고 나머지는 보류하세요.