인스타그램 다이렉트는 안드로이드 사용자 인터페이스를 기존의 Android View 시스템에서 Jetpack Compose로 이전하여, AI 네이티브 사용자 인터페이스 코드베이스를 구축함으로써 AI 코딩 에이전트가 더 쉽게 이해하고 수정하며 유지보수할 수 있도록 했습니다. 인스타그램 엔지니어에 따르면, 이번 이전으로 사용자 인터페이스의 코드 양이 50% 감소했고, 각 AI 에이전트 세션의 토큰 비용도 33% 절감됐습니다.
인스타그램 엔지니어들이 제시한 핵심 관점은 “AI 네이티브 아키텍처 설계는 상당한 이점을 가져온다”는 것입니다. 개발자가 각 컴포넌트를 하나씩 개별적으로 이전하는 방식이 아니라, 기본 아키텍처가 올바른 구현 방안을 생성하기에 적합한지 평가하는 데 중점을 두어야 합니다. 실제로 그들이 지적하듯이, “AI 도구는 종종 저항이 가장 작은 경로를 선택하므로” 이로 인해 “숨은 버그, 기술 부채, 성능 저하”가 발생할 가능성이 큽니다.
인스타그램 엔지니어들은 AI 최적화된 코드베이스를 설계한다는 것은 상태 관리, 예측 가능한 동작, 그리고 개발 패턴 측면에서 올바른 아키텍처 경계를 설정하는 것을 의미하며, 이를 통해 AI 에이전트의 ‘최소 저항 경로’가 최적의 변환 결과로 이어지도록 만든다고 설명합니다. 그들의 목표는 단순히 AI가 설계상의 결함을 보완하도록 하는 것이 아니라, AI 에이전트가 실제로 코드를 어떻게 수정하는지를 이해한 뒤 그에 맞춰 코드베이스를 설계하는 데 있습니다.
AI 에이전트는 본래 저항이 가장 작은 경로를 선택하므로, 설계 단계에서부터 해당 경로가 결국 정확하고 고품질의 코드를 생성하도록 보장해야 하며, 동시에 잘못된 설계 결정이 실행되기 어렵고 비용이 크게 증가하도록 해야 합니다.
또 다른 핵심 원칙은 컨텍스트 의존성을 최대한 줄이는 것입니다. 즉, AI 에이전트가 특정 코드베이스에 대한 지식에 의존하지 않도록 하고, 검증된 모범 사례와 익숙한 패턴을 우선적으로 활용하게 함으로써 보다 신뢰할 수 있는 결과를 도출하도록 돕는 것입니다.
이번 이전은 팀 전체의 정상적인 업무에 영향을 주지 않은 채 원활히 완료되었으며, 엔지니어들은 이전 기간에도 계속해서 새로운 기능을 출시할 수 있었습니다. AI 지원 워크플로우는 이미 표준화되어 일관성을 높였고, 팀 내 공통 아키텍처 규격 및 모범 사례와도 일치하도록 보장됩니다.
이러한 방법을 통해 Jetpack Compose로의 이전으로 UI 코드 양이 50% 감소했으며, 동시에 AI 에이전트의 실행 시간은 35% 단축되었고, 각 에이전트 세션당 토큰 비용은 33% 절감되었으며, 엔지니어와 에이전트 간의 상호작용 횟수도 32% 줄어들었습니다.
주요 과제 중 하나는 이전 작업으로 인해 성능 저하가 발생하지 않도록 하는 것이었습니다. 팀은 세 가지 핵심 생산 지표에 집중했는데, 바로 화면을 열고 나서 사용 가능해지는 데까지 걸리는 상호작용 응답 시간, 모든 화면 콘텐츠가 완전히 로드되는 데 걸리는 전체 로드 시간, 그리고 화면 콘텐츠의 스크롤이 얼마나 부드럽게 이루어지는지를 평가하는 스크롤 성능입니다.
프로덕션 환경에서는 이러한 지표들을 런타임 모니터링을 통해 추적하며, A/B 테스트를 수행하여 이전 버전의 UI와 이전 후의 Compose UI를 비교하고 이전이 성능에 미치는 영향을 평가할 수 있도록 합니다.
Instagram 엔지니어들이 발견한 중요한 점은, 성능을 신뢰성 있게 평가하려면 전체 화면을 Compose로 이전한 후에야만 가능하다는 것입니다. 이렇게 하면 성능 측정 결과를 왜곡시킬 수 있는 기존 View 컴포넌트의 잔여 요소를 제거할 수 있습니다.
이는 Compose UI 컴포넌트가 자체 프레임워크에서 추상화되어야 함을 의미하며, 동시에 RecyclerView 및 LazyColumn과의 호환성도 유지해야 합니다. 또한 A/B 테스트를 위해 런타임 시 기능 플래그를 통해 두 구성 요소 간에 전환할 수 있어야 한다는 점도 중요합니다.
결국 팀은 기존의 RecyclerView(원래는 새로운 Compose 컴포저블을 담기 위한 컨테이너로 남겨져 있던)를 대체하여, Compose에서 스크롤 가능한 목록을 효율적으로 렌더링하기 위한 기본 솔루션인 LazyColumn을 도입했습니다.
마지막으로, 이번 이전 작업은 애플리케이션의 다른 부분들의 시작 성능까지 개선했다는 점을 언급할 필요가 있습니다. 그 이유 중 하나는 Compose의 런타임 예열 비용이 애플리케이션 세션당 한 번만 발생하기 때문에, 이후의 Compose 기반 인터페이스들은 이미 초기화된 런타임 환경을 활용할 수 있어 해당 비용을 다시 부담하지 않아도 된다는 점입니다.
원문 링크: https://www.infoq.com/news/2026/10/instagram-compose-migration/