Instagram Direct 엔지니어가 Jetpack Compose로 AI 네이티브 UI 아키텍처를 빌드하고 에이전트 세션당 토큰 비용을 33% 절감한 방법

이 블로그 게시물은 Meta팀과 공동으로 작성되었습니다.

Instagram Direct는 Instagram의 핵심 표시 경로 중 하나로, 매일 수십억 건의 사용자 메시지를 처리합니다. 수년간의 반복을 통해 팀은 기존 Android 뷰 시스템에서 가능한 모든 미세 최적화를 적용했습니다. 하지만 고도로 최적화된 기존 서페이스를 유지하고 확장하면 특히 팀에서 선언적 UI와 AI 코딩 어시스턴트를 점점 더 많이 채택함에 따라 상당한 기술 부채와 엔지니어링 오버헤드가 발생합니다. 

Instagram Direct에 Jetpack Compose를 도입하는 것은 일반적인 UI 현대화 이상의 의미를 지닙니다. 이 팀은 원래 구현보다 50% 더 작은 AI 네이티브 UI 코드베이스를 구축하는 동시에 AI 에이전트 실행 시간 35% 단축, 엔지니어-에이전트 교환 32% 감소, 토큰 비용 33% 절감을 달성했습니다. Google과의 긴밀한 파트너십을 통해 팀은 높은 성능 기준을 유지하면서 Jetpack Compose를 채택했습니다. 성능 최적화를 통해 Meta와 Google은 Instagram뿐만 아니라 더 광범위한 Android 개발자 생태계를 위해 Compose를 개선했습니다.

대규모 코드베이스 현대화

AI는 업계 엔지니어의 일상적인 동반자가 되었으며, Instagram과 같은 대규모 코드베이스에 적용하면 이미 실제 생산성 향상을 얻을 수 있습니다. Instagram 다이렉트팀은 더 야심찬 목표를 설정했습니다. 팀은 기존 코드에 AI 도구를 단순히 적용하는 대신, 설계 단계에서 AI 네이티브가 되도록 코드베이스와 아키텍처를 재설계하여 AI의 영향을 리트로피팅만으로는 달성할 수 있는 수준을 훨씬 뛰어넘는 수준으로 확대했습니다.

Instagram Direct팀은 AI 네이티브 UI 아키텍처를 빌드하기 위한 핵심 구성요소로 Jetpack Compose를 선택했습니다. 선언적 특성으로 인해 코드가 간결하고 예측 가능하며 AI 모델이 추론하기에 구조적으로 더 쉬우며 부작용이 적고, 암시적 상태가 적고, 구성요소 경계가 더 명확합니다.

Jetpack Compose로의 이전에는 신중한 계획이 필요했습니다. 매일 수억 명의 사용자가 Instagram에서 메시지를 보내므로 팀이 기반을 재설계하는 동안 경험에 중단이 없도록 점진적이고 원활하게 마이그레이션해야 했습니다. 이러한 문제의 규모를 설명하자면 개별 UI 구성요소는 160개가 넘는 고유한 상태 순열로 렌더링될 수 있으며 단일 대화 화면만으로도 200개가 넘는 고유한 메시지 유형을 처리합니다.

이 정도 크기의 코드베이스를 Compose로 이전할 때는 손쉬운 방법을 택하여 기존 뷰 계층 구조 내에 Compose UI 구성요소를 삽입하고 싶어질 수 있습니다. 점진적 마이그레이션 중에 증분 단계로 사용하는 것은 완전히 유효합니다. 하지만 장기적으로는 뷰 기반 코드베이스 내에 Compose를 통합하는 데 어려움이 있습니다. AI 도구는 종종 가장 저항이 적은 경로를 택합니다. 선언적 UI 코드와 명령형 UI 코드를 혼합하면 AI가 이를 잘못 혼합하여 미묘한 버그, 기술 부채, 성능 회귀가 발생할 수 있습니다. 

AI 중심 UI 아키텍처 빌드

Instagram 규모에서는 어느 정도의 아키텍처 추상화가 불가피하며, 앱이 성장함에 따라 유지관리할 수 있도록 해줍니다. 모든 RecyclerView 상품 유형이 onBind와 같은 일반적인 수명 주기 후크를 노출하는 맞춤 RecyclerViewItem 기본 클래스의 하위 요소로 모델링되는 일반적인 패턴을 생각해 보세요.

예 1

class ChatItem(
  val features: FeatureFlagProvider
) : RecyclerViewItem<ComposeViewHolder, ChatUiState> {

  // Imperative context:
  // AI could often take the path of least resistance and generate a mutable
  // state here, dispatched outside the ChatUiState. This class survives
  // re-bindings and is shared across multiple items, ultimately leading to
  // unexpected, hard-to-reproduce bugs.
  var isPinned: Boolean = false

  override fun onBind(holder: ComposeViewHolder, uiState: ChatUiState) {
      // Imperative context
      val isPinnedChatsEnabled = features.isEnabled("pinned_chats_feature")

      // Declarative context
      holder.composeView.setContent {

        // Blending imperative and declarative contexts
        if (isPinnedChatsEnabled) {
          Button(onClick = { isPinned = !isPinned }) {
            Text(if (isPinned) "Unpin" else "Pin")
          }
        }
        
        ...
      }
  }
}

위 스니펫에는 두 가지 문제가 있습니다. 먼저 isPinnedChatsEnabled 플래그가 명령형 코드에서 읽힌 다음 Compose 람다 내에서 캡처됩니다. 이는 패러다임 간의 미묘한 결합입니다. 둘째, isPinned는 ChatUiState이 아닌 항목 자체의 변경 가능한 필드로 존재하므로 RecyclerView 재바인딩과 행 간 재활용에서 누출되어 재현하기 어려운 버그가 발생합니다.

항목에 전용 @Composable 함수를 제공하여 코드를 정리해도 동일한 문제가 남아 있습니다.

예 2

class ChatItem(
  val features: FeatureFlagProvider
) : ComposeRecyclerViewItem<ChatUiState> {

  // Imperative context
  val isPinnedChatsEnabled = features.isEnabled("pinned_chats_feature")
  var isPinned: Boolean = false

  // Declarative context
  @Composable
  override fun Content(uiState: ChatUiState) {

 
    // Blending imperative and declarative contexts
    if (isPinnedChatsEnabled) {
      Button(onClick = { isPinned = !isPinned }) {
        Text(if (isPinned) "Unpin" else "Pin")
      }
    }

    ...
  }
}

의도적으로 간단한 예시이지만 더 광범위한 문제를 보여줍니다. AI에 제공되는 경계가 적을수록 시간이 지남에 따라 생성되는 코드의 품질이 낮아집니다. 가드레일과 기술이 도움이 되지만, AI가 마찰을 겪을 때 스스로 차단을 해제하기 위해 가드레일을 우회하는 경우가 많기 때문에 이 두 가지 요소만으로는 충분하지 않습니다.

코드베이스를 AI 친화적으로 만들려면 다음 두 가지 실용적인 규칙을 따라야 합니다. 

• 맞춤 컨텍스트에 대한 종속성 최소화 AI 에이전트가 올바른 변경을 수행하는 데 필요한 맞춤형 코드베이스 관련 지식이 많을수록 출력의 품질이 낮아집니다. 코드베이스가 알려진 권장사항에 가까울수록 AI 결과가 더 좋습니다.
• AI 우선 코드베이스는 자체 경계를 적용해야 합니다. AI 기술로 디자인 격차를 패치하는 것은 확장되지 않습니다. 컨텍스트에 로드된 모든 스킬은 토큰 비용이 발생하고 에이전트의 성능을 저하시킬 수 있기 때문입니다. 대신 아키텍처 자체가 그 무게를 지녀야 합니다. AI 에이전트는 자연스럽게 가장 쉬운 길을 택하므로, 설계에서는 이 길이 올바르고 고품질의 코드로 이어지도록 해야 하며, 잘못된 설계 결정을 표현하기 어렵고 비용이 많이 들도록 해야 합니다.

목록 항목은 자체 추상화로 계속 표현할 수 있지만 이 경우 모든 Compose 코드는 생성자에 있으므로 클래스 멤버나 상태에 액세스할 수 없으며 인수 소스는 생성자뿐입니다. 이렇게 하면 기존 아키텍처를 준수하면서 일반 @Composable 함수와 동일하게 됩니다.

예시 3

class ChatItem(
  val features: FeatureFlagProvider,
  val onPin: (Boolean) -> Unit,
) : ComposeItem<ChatUiState>(

 
   // Compose UI
   content = { uiState: ChatUiState ->
    val isPinnedChatsEnabled = features.isEnabled("pinned_chats_feature")

    if (isPinnedChatsEnabled) {
      Button(onClick = { onPin(!uiState.isPinned) }) {
        Text(if (uiState.isPinned) "Unpin" else "Pin")
      }
    }
    
    ...
  },
)

이 정도 크기의 코드베이스를 이전하는 것은 엄청난 작업입니다. 오랫동안 Direct UI의 대부분을 구성하는 수백 개의 UI 구성요소는 기존 구성요소와 공존해야 했으며 둘 다 병렬로 유지되었습니다. AI 워크플로를 통해 대량의 코드 작성 프로세스를 가속화하여 이러한 병렬 마이그레이션이 가능했습니다. 이 접근 방식을 통해 Direct팀은 기록적인 시간 내에 마이그레이션을 실행할 수 있었으며, 이 과정에서 매일 수백만 명의 경험을 개선하는 기능을 계속 출시하는 다른 팀의 업무를 방해하지 않았습니다.

여러 엔지니어가 이전 중에 빌드된 재사용 가능한 기술과 규칙의 공유 기술 자료에 대해 자체 AI 에이전트를 실행했습니다. 각 엔지니어가 다시 발견하는 대신 팀 전체에서 워크플로와 권장사항을 동기화했습니다. 각 서피스 내에서 팀은 다음 단계로 마이그레이션을 실행했습니다.

• AI로 모든 Compose 코드를 작성합니다.
• UI가 공개 테스트에서 실제 사용자에게 출시될 때까지 특이 사례를 처리하고 성능 격차를 해소하면서 다듬었습니다.

화면당 두 단계로 작업을 나누면 한 엔지니어가 전체 화면을 빠르게 이동하여 아키텍처와 까다로운 특이 사례를 미리 해결할 수 있습니다. 이러한 기반이 마련되면 다른 사용자는 기술적 결정을 내리기 위해 멈추지 않고 UI를 프로덕션 준비 상태로 만드는 데 집중할 수 있으므로 전체 마이그레이션 속도를 유지할 수 있습니다.

마이그레이션 결과는 이 접근 방식을 검증했습니다. 이전된 Instagram 다이렉트 메시지 노출 영역의 경우 Jetpack Compose를 통해 UI 코드의 총량을 50%줄일 수 있었습니다. AI가 생성해야 하는 코드가 적을수록 출력 품질이 높아지고 작업당 토큰 비용이 낮아집니다. 

Instagram Direct의 Android 코드베이스에 대한 내부 데이터 분석에서는 Compose UI에서 작업하는 AI 에이전트 세션을 Android Views를 사용하여 동일한 작업을 수행하는 세션과 비교했습니다. 효율성 향상은 다음 두 가지 측면에서 명확하게 나타났습니다.

• 랜딩된 코드의 문자당: 필요한 엔지니어-상담사 교환이 32% 감소하고 상담사 실행 시간이 35% 감소합니다(상담사가 엔지니어의 요청에 대한 작업을 시작한 시점부터 응답을 반환할 때까지 경과된 시간).
• 상담사 세션당: Compose를 사용하면 Views에 비해 전체 토큰 비용이 33% 감소합니다.

출력 효율성과 일반적인 세션 수는 독립적으로 유용한 결과이므로 두 가지 모두 보고합니다. 엔지니어-에이전트 교환 및 실행 시간 수치는 착륙한 출력 단위당 리소스 사용량을 비교하는 반면, 토큰 수치는 일반적인 에이전트 세션의 총비용을 비교합니다.

또한 이 데이터는 두 프레임워크가 복잡하거나 취약한 코드를 처리하는 방식에 일관된 차이가 있음을 보여줍니다. Meta는 코드 변경의 위험 점수를 사용하여 이를 추적합니다. 이 점수는 전반적인 코드 품질과 변경으로 인해 프로덕션 인시던트가 발생할 가능성을 평가합니다. 이 분석에서는 토큰 소비, 에이전트 실행 시간, 엔지니어와 에이전트 간 상호작용의 복합을 사용하여 에이전트의 리소스 효율성을 측정했습니다. 파일의 위험 점수가 높아지면 AI 에이전트 세션이 자연스럽게 리소스 효율성이 떨어집니다. 

파일의 누적 위험 점수가 두 배로 증가하면 Android 뷰로 구현된 UI가 에이전트 리소스 효율성을 30%감소시킵니다 (랜딩된 문자당). 동일한 상황에서 Jetpack Compose UI의 감소는 9%에 불과합니다.

Google과 Meta의 파트너십을 통해 Instagram Direct팀은 Compose 채택에 새로운 관점을 제시했습니다. UI 재작성뿐만 아니라 코드베이스의 AI 준비성을 고려하여 접근했습니다. 이 작업을 통해 특히 Instagram과 같은 앱 규모에서 적용할 때 AI 우선 코드베이스와 아키텍처를 빌드하는 기반으로 Compose의 강점이 드러났습니다.

성능 최적화 

Instagram 다이렉트는 앱에서 가장 중요한 표면 중 하나이며, 사용자는 항상 빠르고 반응성이 좋다고 생각합니다. Jetpack Compose를 채택한다는 것은 사실상 UI를 대대적으로 다시 작성한다는 의미였으며, 최우선 목표는 회귀 없이 고품질 환경을 유지하는 것이었습니다.

수년간의 반복을 통해 이미 Instagram의 기존 뷰 기반 구현은 매우 높은 성능 기준에 도달했으며, 팀은 완전히 새로운 UI 프레임워크로 전환하면서 동일한 기준을 충족해야 했습니다.

Instagram은 수백, 수천 개의 성능 측정항목을 측정합니다.  Compose 채택의 경우 다음 세 가지가 가장 중요했습니다.

• 상호작용 시간 - 화면을 열고 사용할 수 있을 때까지의 시간입니다.
• 완전히 로드하는 데 걸리는 시간: 화면을 연 시점부터 모든 콘텐츠 (예: 이미지)가 완전히 로드될 때까지의 시간입니다.
• 스크롤 성능 - 프레임이 누락되지 않고 화면이 얼마나 부드럽게 스크롤되는지

이러한 측정항목은 프로덕션에서 런타임에 추적되므로 이전 UI와 마이그레이션된 Compose UI를 비교하는 A/B 테스트를 실행하고 이 노력의 성능 영향을 평가할 수 있습니다.

이러한 마이그레이션에 접근하는 일반적인 방법은 소규모로 시작하여 몇 가지 UI 구성요소를 이동하고, 데이터를 수집하고, 동작 방식을 연구하는 것입니다. 이러한 초기 결과는 유용하지만 다음과 같은 이유로 Compose 채택에 대해 거짓 음성을 제공하여 부분적인 그림만 보여줍니다.

• 대표성이 없음 - 이전된 UI 구성요소 하나가 특정 화면에서의 전반적인 성능에 관한 유용한 데이터를 제공할 수 있습니다. 하지만 일반화할 수 없는 이유로 구성요소마다 다르게 동작하므로 항상 이를 기반으로 추정할 수는 없습니다.
• 상호 운용성 비용: 큰 View 코드베이스 내의 작은 Compose 부분은 두 시스템 간에 예측할 수 없는 브리징 비용을 지불합니다. 이 오버헤드로 인해 측정이 왜곡되므로 초기 소규모 결과는 전체 이전이 실제로 어떤 모습인지 반영하지 않습니다.

따라서 작은 규모의 이전은 유용하지만 Compose의 전체 영향을 항상 반영하지는 않습니다. 중단 없이 엔드 투 엔드로 이전되는 서피스가 많을수록 성능 측면에서 그림이 더 명확해지고 개선됩니다.

Instagram 다이렉트 메시지의 핵심 화면은 다양한 항목 유형의 긴 목록을 중심으로 구축되며, 원래 RecyclerView로 구현되었습니다. 이 아키텍처는 확장성을 위해 맞춤 추상화를 사용하지만 뷰 기반 시스템의 수명 주기에 계속 바인딩됩니다.

팀의 주요 과제는 기존 RecyclerView 기반 아키텍처 내에서 수백 개의 개별 목록 항목을 Compose로 점진적으로 이전하고, A/B 테스트에서 소규모 독립 그룹으로 프로덕션에 출시하는 것이었습니다. 이 모든 과정에서 사용자의 메시지 환경에 눈에 띄는 변화는 없었습니다.

이러한 설정의 가장 큰 단점은 모든 목록 항목을 Compose로 완전히 이전한 후에도 핵심 RecyclerView 아키텍처를 통해 기존 View 시스템에 크게 의존한다는 것입니다. 자연스러운 다음 단계로 팀은 RecyclerView 기반 핵심 아키텍처를 Compose 네이티브 대안인 LazyColumn로 대체하는 데 투자하기로 결정했습니다.

즉, Compose UI 구성요소는 동시에 RecyclerView 및 LazyColumn와 호환되면서도 둘러싸고 있는 프레임워크에서 추상화되어야 합니다. A/B 테스트를 사용 설정하기 위해 런타임에 기능 플래그를 통해 두 가지를 전환할 수 있는 기능도 마찬가지로 중요합니다.

새 Compose 항목은 LazyColumn와 기본적으로 호환되며 중단되지 않는 컴포지션 트리에 연결할 수 있지만, RecyclerView에도 삽입할 수 있도록 상호 운용성 API가 생성되었습니다. 이를 통해 RecyclerView와 나란히 A/B 테스트에서 LazyColumn 설정을 출시할 수 있었습니다. 동일한 Compose 항목을 재사용하고 성능을 개선하면서도 나머지 팀이 기능을 빌드하고 개선하는 데 지장을 주지 않았습니다.

Instagram의 규모, 복잡성, 아주 작은 회귀에도 민감한 특성으로 인해 Jetpack Compose에 고유한 문제가 발생했습니다. 이러한 문제를 해결하려면 반복적이고 실무 중심의 파트너십이 필요했습니다. Google과 Meta 엔지니어는 긴밀히 협력하여 측정항목을 분석하고 뷰 기반 벤치마크를 충족하거나 초과하는 새로운 Compose 기능을 파악하고 설계했습니다. 이 파트너십의 결과로 Jetpack Compose에 다음과 같은 기능이 추가되었습니다. LazyLayoutCacheWindows를 사용한 일시중지 가능한 컴포지션과 가시성 추적입니다. 

LazyLayoutCacheWindows를 사용한 일시중지 가능한 컴포지션

일시중지 가능한 컴포지션 (Compose 1.10에서 기본적으로 사용 설정됨)을 사용하면 비용이 많이 드는 지연 목록 항목을 프레임에 걸쳐 점진적으로 구성하여 버벅거림을 방지할 수 있습니다. LazyLayoutCacheWindow (Compose 1.9에 추가됨)와 함께 사용하면 스크롤 부드러움이 크게 향상됩니다. 최근 Meta 내부 테스트에서 일시중지 가능한 컴포지션을 단일 뷰포트 LazyLayoutCacheWindow와 결합한 결과, 일반 Compose에 비해 분당 대형 프레임 드롭 (LFD/m)이 약 13% 감소했습니다. 캐시 창 자체는 동일한 기준에 대해 약 8% 감소했습니다. LFD/m은 스크롤하는 동안 눈에 띄는 끊김 현상을 추적하기 위해 Meta에서 사용하는 내부 측정항목입니다.

앱에서 LazyLayoutCacheWindow를 사용하면 빠른 스크롤을 지원하기 위해 뷰포트 주변의 픽셀 기반 밴드 내에서 화면 밖 항목을 준비하고 유지합니다. 앱에서 LazyLayoutCacheWindows를 활용하려면 최신 Compose 1.13.0-alpha03을 사용하고 아래 예와 같이 설정하면 됩니다.

val cacheWindow = LazyLayoutCacheWindow(ahead = 150.dp, behind = 100.dp)
// OR
val cacheWindow = LazyLayoutCacheWindow(aheadFraction = 0.5f, behindFraction = 0.3f)

LazyColumn(state = state, cacheWindow = cacheWindow) {
    ...
}

캐시 창을 구성하는 방법에는 두 가지가 있습니다. 둘 다 동일한 내용을 설명합니다. 즉, 오프 스크린 콘텐츠를 얼마나 컴포즈된 상태로 유지할지를 설명하지만 단위는 다릅니다.

• dp: 고정된 절대 길이입니다. ahead = 150.dp는 기기와 관계없이 표시되는 가장자리를 지나 컴포즈된 콘텐츠를 150dp 유지합니다.
• Float: 뷰포트의 비율입니다. aheadFraction = 0.5f는 화면의 절반을 미리 구성하므로 절대량이 화면 높이에 따라 조정되어 다양한 폼 팩터를 지원합니다. 태블릿이나 펼쳐진 폴더블에서는 더 많이, 소형 휴대전화에서는 더 적게 표시됩니다. 

Instagram팀은 다이렉트의 콘텐츠 구조와 항목 크기에 맞게 캐시 창의 부동 소수점 분수를 미세 조정했습니다. 이상적인 값은 특정 UI 매개변수에 따라 다르므로 적절한 균형을 찾으려면 약간의 실험이 필요합니다.

onVisibilityChanged를 사용한 노출 로깅

 onVisibilityChanged (Compose 1.9.0에 추가됨) API는 Google과 Meta의 기술 파트너십의 또 다른 주요 결과였습니다. 이를 통해 대규모 Jetpack Compose 화면에서 컴포저블이 실제로 화면에 표시되는 시점을 일관되게 알 수 있으며, 과거에 사용된 맞춤형 직접 구현을 대체합니다. Instagram 다이렉트 메시지 내에서만 이러한 표시 가능 여부 신호가 수백 개의 파일에 사용되어 UI 요소가 실제로 사용자에게 표시되었는지 여부에 따라 달라지는 제품 품질 측정항목을 지원합니다.

시작 성능

Instagram Direct에 Jetpack Compose를 도입한 결과 앱의 다른 표시 경로에서 예상치 못한 성능 개선이 이루어졌습니다. Jetpack Compose 런타임은 한 번만 지불하는 준비 비용을 부담하며, 메시지는 사용자 세션 초기에 자주 방문하는 트래픽이 많은 표시 경로이므로 Compose를 사용하는 Instagram의 다른 표시 경로에서 눈에 띄는 성능 개선이 이루어졌습니다.

기준 프로필을 사용하여 Instagram Direct 내부의 Compose UI 시작 성능이 최적화되었습니다. 기준 프로필은 설치 시점에 핫 코드 경로를 사전 컴파일하므로 Compose가 처음 실행될 때 빠르게 렌더링됩니다.

Instagram Direct를 Jetpack Compose로 이전하면서 얻은 교훈 

• Jetpack Compose는 즉각적인 투자 수익을 제공합니다. Compose의 이점을 누리기 위해 고급 AI 워크플로를 사용할 필요가 없습니다. 코드가 약 50% 감소하므로 유지관리해야 하는 코드가 줄어들고 버그가 발생할 수 있는 영역도 줄어듭니다.
• AI 네이티브 아키텍처를 설계한 결과 AI 에이전트 실행 시간 35% 감소, 엔지니어-에이전트 교환 32% 감소, 토큰 비용 33% 감소 등 상당한 성과를 거두었습니다.
• 상호 운용성 API가 많고 뷰와 Compose를 함께 결합하는 기능도 지원되지만 개별 작은 구성요소보다는 더 큰 화면을 이전하는 것을 목표로 하세요. 이렇게 하면 UI가 중단되지 않는 단일 컴포지션 계층 구조 내에 유지되고 Compose 네이티브 성능 최적화가 모두 적용됩니다.
• 일시중지 가능한 컴포지션을 LazyLayoutCacheWindow와 페어링: 이 두 가지를 함께 페어링하면 캐시 창만 사용하는 것보다 더 나은 결과를 얻을 수 있습니다. 캐시 창만으로는 무거운 항목이 단일 패스로 구성되려고 시도하여 프레임 예산을 초과할 수 있습니다.
• Compose에 직접 기여하세요. Meta는 Jetpack Compose팀과 파트너십을 맺어 Compose 내에서 의견과 아이디어를 실현했습니다. 오픈소스 툴킷을 사용하면 버그가 수정되고 성능이 개선될 때 모두가 혜택을 누릴 수 있습니다. 의견을 알려주세요.

Jetpack Compose를 채택한 결과 Instagram에서 AI 지원 개발이 크게 개선되었으며 일상적인 UI 엔지니어링이 간소화되었습니다. 선언적 접근 방식은 상용구를 줄이고 상태를 더 쉽게 추론할 수 있도록 하며 전반적인 개발자 생산성을 향상합니다. Instagram 엔지니어링팀은 앱 전반에서 더 많은 서페이스에 Compose를 도입하고 Google과 Meta 간의 지속적인 협업을 통해 Instagram과 Jetpack Compose 사용자 모두에게 더 많은 개선사항을 제공할 수 있기를 기대합니다. 

아직 Compose를 사용해 보지 않았다면 이제 AI 지원을 통해 Jetpack Compose로의 마이그레이션이 그 어느 때보다 쉬워졌습니다.

감사의 말씀. Meta의 Michal Zielinski와 Matthew Du, Google의 Andrei Shikov와 George Mount가 Meta와 Google 간의 협업을 통해 Compose의 성능을 개선해 주셔서 감사합니다. 또한 Instagram Direct에 Compose를 도입하는 데 도움을 준 Meta의 Gary Ye와 데이터 과학을 통해 이 노력을 지원해 준 Meta의 Gopal Juneja에게도 감사드립니다.