앱 MVP Jetpack Compose 강한 스키핑: 컴파일러·재구성·검증을 나누는 5가지 기준

앱 MVP Jetpack Compose 강한 스키핑: 컴파일러·재구성·검증을 나누는 5가지 기준

직접 답변: Compose 기반 Android MVP에서 강한 스키핑을 검토할 때는 “현재 컴파일러에서 이 모드가 기본 적용되는가”, “각 composable이 다시 구성될지 또는 건너뛸지 어떤 값 비교로 판단되는가”, “람다 메모이제이션이 실제 화면의 상태 갱신과 어떤 관계가 있는가”, “핵심 사용자 흐름을 어떤 조건으로 다시 검수할 것인가”를 분리해야 합니다. Gradle 옵션 한 줄이 있거나 빌드가 통과했다는 사실만으로 특정 화면이 빨라졌거나 출시 검수가 끝났다고 보지 마세요.

Android 공식 문서에 따르면 강한 스키핑은 Compose 컴파일러 모드이며, Kotlin 2.0.20에서는 기본으로 사용 설정됩니다. 이 모드는 불안정한 파라미터를 가진 composable도 skippable로 만들 수 있고, composable 안의 람다를 자동으로 메모이제이션합니다. 그러나 문서의 컴파일러 규칙만으로 특정 앱의 성능 수치·APK 크기·오류 감소·전환 성과를 확정할 수는 없습니다. 이 글은 MVP 팀이 구현 상태와 실기기 관찰을 섞지 않기 위한 운영 점검 가이드입니다.

먼저 “컴파일러의 후보 판단”과 “사용자 흐름의 결과”를 분리합니다

Compose에서 재구성은 상태가 바뀐 뒤 관련 UI를 다시 평가하는 과정입니다. 공식 안정성 문서는 파라미터의 안정성을 바탕으로 composable을 건너뛸 수 있는지 판단한다고 설명합니다. 따라서 컴파일러가 어떤 함수를 skippable로 표시할 수 있다는 정보와, 사용자가 탭·입력·스크롤을 했을 때 화면이 올바르게 갱신되는 관찰은 같은 증거가 아닙니다.

예를 들어 목록, 네트워크 응답, 화면 상태, 이벤트 핸들러가 얽힌 MVP에서는 객체가 새로 만들어졌는지, 값이 실제로 변했는지, UI가 기대한 시점에 다시 그려졌는지, 프레임 지연이 관찰됐는지를 한 문장으로 합치기 쉽습니다. 팀의 기록은 컴파일러 버전·모듈 설정·변경한 화면·테스트 기기·재현 단계·관찰 결과를 나눠야 원인과 다음 조치를 구분할 수 있습니다.

기준 1: 기본 적용 여부와 모듈 설정을 먼저 확인합니다

Android 공식 문서는 Kotlin 2.0.20에서 강한 스키핑이 기본으로 사용 설정된다고 안내합니다. 더 이른 릴리스에서는 Compose 컴파일러 Gradle 설정으로 활성화할 수 있습니다. 반대로 프로젝트 전체가 같은 Kotlin·Compose 컴파일러 조합인지, 특정 모듈만 다른 설정을 쓰는지, 빌드 산출물이 현재 검토 대상인지까지는 각 팀의 실제 구성에서 확인해야 합니다.

“기본값이므로 검토 불필요”도, “옵션을 넣었으므로 모든 화면이 개선”도 근거가 부족합니다. 먼저 배포 후보를 만든 정확한 커밋과 모듈, 컴파일러 구성, 검토한 화면을 연결하세요. 설정 변경은 시작 증거일 뿐이며, 화면의 상태·이벤트·접근성·오류 처리까지 통과했다는 증거는 아닙니다.

기준 2: 안정·불안정 값의 비교 기준을 구별합니다

강한 스키핑이 켜진 상태에서 Compose는 이전 값과 현재 값을 비교해 composable을 건너뛸지 판단합니다. 공식 문서에 따르면 불안정한 파라미터는 인스턴스 동등성(===)으로, 안정한 파라미터는 객체 동등성(equals())으로 비교합니다. 모든 비교가 같은 방식이라는 가정은 상태 변경 문제를 설명하는 데 도움이 되지 않습니다.

공식 안정성 안내는 mutable 속성이 있는 타입처럼 Compose가 변경 여부를 알기 어려운 타입을 불안정하게 볼 수 있다고 설명합니다. 하지만 모든 모델에 곧바로 어노테이션을 붙이는 일은 별도 설계 판단입니다. UI 모델, 상태 보관 위치, 변경 알림 계약을 먼저 읽고, 필요한 경우에만 문서가 설명한 안정성 도구와 진단 방법을 검토하세요.

앱 MVP의 Compose 화면 검수 기준을 함께 정리하기

기준 3: 람다 자동 메모이제이션과 이벤트 결과를 분리합니다

강한 스키핑에서는 composable 내부 람다가 자동으로 remember 처리될 수 있으며, 캡처 값을 키로 사용합니다. 공식 문서는 이때도 불안정한 키는 인스턴스 동등성, 안정한 키는 객체 동등성으로 비교한다고 설명합니다. 따라서 자동 메모이제이션이 있다는 사실은 클릭·입력·저장·오류 안내가 제품 요구대로 동작한다는 인증서가 아닙니다.

특히 콜백이 화면 상태, ViewModel, 목록 항목, 네트워크 응답을 함께 참조한다면 팀은 “무엇을 캡처했는가”, “그 값이 바뀌었을 때 어떤 이벤트가 발생했는가”, “UI가 어떤 상태를 보여야 하는가”를 구분해 테스트합니다. 필요하면 공식 문서가 소개한 @DontMemoize와 @NonSkippableComposable의 의미를 읽되, 예외 어노테이션 추가 자체를 문제 해결 또는 품질 보증으로 표현하지 마세요.

기준 4: 코드 변경과 측정·관찰을 별도 단계로 둡니다

강한 스키핑은 더 많은 composable을 skippable로 표시하고 람다를 기억하도록 만드는 컴파일러 동작입니다. 공식 문서는 생성 코드가 늘어 APK 크기에 작은 영향이 있을 수 있다고도 설명합니다. 다만 그 예시는 문서의 특정 샘플에 관한 내용이며, 다른 앱의 크기나 성능 결과로 일반화할 수 없습니다.

그래서 MVP의 출시 기록에는 최소한 변경 전후 빌드 식별자, 테스트 기기·OS, 핵심 시나리오, 입력 순서, 기대 UI 상태, 실제 관찰, 오류·지연 여부, 재현 가능성을 따로 남깁니다. 성능을 측정할 필요가 있다면 실험실 측정과 운영 신호를 섞지 않고, 현재 팀이 선택한 도구·조건·한계를 명시하세요. 실기기 한 번의 관찰을 모든 사용자·모든 기기의 성능 개선으로 확장하지 않습니다.

기준 5: 예외 처리와 출시 판단을 분리합니다

특정 composable을 스킵하지 않게 하거나 특정 람다를 메모이제이션하지 않게 하는 선택은 가능합니다. 하지만 그 선택은 무엇이 달라지는지 이해한 뒤, 재현 가능한 화면 조건에서 검토해야 합니다. 기본 모드·개별 예외·상태 모델·테스트 결과·배포 승인 기록은 서로 대신할 수 없습니다.

출시 직전에는 강한 스키핑의 사용 여부뿐 아니라 로그인 전후, 목록 갱신, 입력 오류, 화면 복귀, 접근성 동작처럼 서비스의 핵심 흐름을 다시 확인하세요. Compose 상태를 관리하는 방식과 UI 변경을 분리해 보려면 앱 MVP 상태 복원: 회전·시스템 종료 뒤 되돌릴 것 5가지도 함께 참고할 수 있습니다. 이 글은 특정 코드 구조, 성능 목표, 출시 승인 또는 사용자 경험 결과를 확정하지 않습니다.

출시 전 5분 체크리스트

• 현재 배포 후보의 Kotlin·Compose 컴파일러 조건과 모듈 설정을 기록했는가?

• 안정·불안정 파라미터와 실제 변경 방식을 이름이 아니라 코드 기준으로 확인했는가?

• 람다의 캡처 값·이벤트 결과·기대 UI 상태를 분리했는가?

• 테스트 기기·OS·입력 순서·관찰 결과를 빌드 성공과 별도로 남겼는가?

• 예외 어노테이션이나 설정 변경을 출시 완료 증거로 과장하지 않았는가?

자주 묻는 질문

Kotlin 2.0.20 이상이면 강한 스키핑을 따로 켜야 하나요?

Android 공식 문서는 Kotlin 2.0.20에서 강한 스키핑이 기본 사용 설정이라고 안내합니다. 실제 모듈의 Compose 컴파일러 구성과 현재 빌드 결과는 별도로 확인하세요.

불안정한 파라미터가 있으면 항상 다시 구성되나요?

강한 스키핑에서는 restartable composable이 불안정한 파라미터가 있어도 skippable이 될 수 있습니다. 다만 스킵 여부는 이전 값과의 비교 결과에 따라 달라지며, 불안정한 값은 인스턴스 동등성으로 비교됩니다.

강한 스키핑을 켜면 앱이 빨라졌다고 발표해도 되나요?

아닙니다. 컴파일러 동작 설명만으로 특정 앱의 속도·프레임·사용자 경험 결과를 확정할 수 없습니다. 핵심 사용자 흐름에서 실제 조건을 고정해 관찰한 결과를 별도로 기록해야 합니다.

모든 람다를 직접 remember로 감싸야 하나요?

강한 스키핑에서는 composable 내부 람다가 자동으로 메모이제이션될 수 있습니다. 다만 코드의 의도와 캡처 값의 변경 경계는 별도로 검토하고, 자동 동작을 전체 화면 검수의 대체로 보지 마세요.

내 앱의 Compose 상태·검수 경계를 점검하기

출처

• Android Developers — Strong skipping mode

• Android Developers — Stability in Compose