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과 같은 대규모 코드베이스에 AI를 적용하면 이미 실질적인 생산성 향상을 얻을 수 있습니다. Instagram Direct팀은 더 야심 찬 목표를 세웠습니다. 이 팀은 단순히 기존 코드에 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를 다듬었습니다.

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

마이그레이션 결과는 이 접근 방식이 옳았음을 입증했습니다. 이전된 Instagram Direct 표시 경로의 경우 Jetpack Compose를 통해 팀은 전체 UI 코드 양을 50%줄일 수 있었습니다. AI가 생성하는 코드가 적을수록 출력 품질이 높아지고 작업당 토큰 비용이 낮아집니다. 

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

• 적용된 코드의 문자당: Compose는 엔지니어와 에이전트 간의 상호작용이 32% 적고 에이전트 실행 시간이 35% 적습니다(에이전트가 엔지니어의 요청에 대한 작업을 시작한 시점부터 응답을 반환할 때까지 경과된 시간).
• 에이전트 세션당: Compose를 사용하면 뷰를 사용할 때보다 전반적인 토큰 비용이 33% 감소합니다.

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

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

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

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

성능 최적화 

Instagram Direct는 앱의 가장 중요한 부분 중 하나이며, 사용자는 이 기능이 항상 빠르고 반응성이 뛰어나기를 기대합니다. Jetpack Compose를 채택한다는 것은 사실상 UI를 대대적으로 다시 작성한다는 의미였으며, 가장 중요한 목표는 회귀 없이 고품질 환경을 유지하는 것이었습니다.

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

Instagram은 수천 개는 아니더라도 수백 개의 실적 측정항목을 측정합니다.  Compose 도입에서 가장 중요한 세 가지는 다음과 같습니다.

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

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

이와 같은 이전을 진행하는 일반적인 방법은 소규모로 시작하여 소수의 UI 구성요소를 이전하고 데이터를 수집하고 작동 방식을 연구하는 것입니다. 이러한 초기 결과는 도움이 되지만, 다음과 같은 이유로 Compose 채택에 대한 거짓음성을 제공하므로 부분적인 그림만 보여줍니다.

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

따라서 소규모 이전은 유용하지만 Compose의 전체 영향을 항상 반영하지는 않습니다. 브리징 중단 없이 엔드 투 엔드로 이전되는 노출 영역이 많을수록 실적 측면에서 더 명확하고 우수한 결과를 얻을 수 있습니다.

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

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

이러한 설정의 가장 큰 단점은 모든 목록 항목을 Compose로 완전히 이전한 후에도 핵심 RecyclerView 아키텍처를 통해 기존 뷰 시스템에 크게 의존한다는 것입니다. 자연스러운 다음 단계로, 팀은 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로 유지합니다.
• 부동 소수점 수: 표시 영역의 비율입니다. aheadFraction = 0.5f는 화면의 절반을 미리 구성하므로 절대적인 양은 다양한 폼 팩터를 지원하는 화면 높이에 따라 확장됩니다. 태블릿이나 펼쳐진 폴더블에서는 더 많고 소형 휴대전화에서는 더 적습니다. 

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

onVisibilityChanged를 사용한 노출 로깅

onVisibilityChanged(Compose 1.9.0에 추가됨) API는 Google과 Meta의 기술 파트너십을 통해 얻은 또 다른 주요 결과물입니다. 이 API는 대규모 Jetpack Compose 표시 경로에 컴포저블이 실제로 화면에 표시되는 시점을 파악하는 일관된 방법을 제공하여 과거에 사용된 맞춤 수동 구현을 대체합니다. Instagram Direct 내에서만 이러한 공개 상태 신호가 수백 개의 파일에서 사용되어 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% 절감 등 상당한 성과를 거두었습니다.
• 뷰와 Compose를 결합할 수 있는 다양한 상호 운용 API와 지원이 있지만 개별 작은 구성요소보다는 더 큰 표시 경로를 이전하는 것을 목표로 하세요. 이렇게 하면 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와 Google의 협업을 통해 Compose의 성능을 개선하는 데 기여해 주신 Meta의 Michal Zielinski와 Matthew Du, Google의 Andrei Shikov와 George Mount에게 감사드립니다. Instagram Direct에 Compose를 도입하는 데 도움을 준 Meta의 Gary Ye와 데이터 과학을 통해 이 작업을 지원해 준 Meta의 Gopal Juneja에게도 감사의 말씀을 전합니다.