Lightbuild를 사용한 선언적 에이전트 지원 Android 빌드

안녕하세요.

제 이름은 후안 세바스티안 오비에도입니다.

저는 Android 개발자 환경팀의 제품 관리자입니다.

오늘 스콧과 함께 Android 앱을 위한 새로운 실험용 빌드 환경인 Lightbuild를 미리 살펴보게 되어 기쁩니다.

이 프로젝트의 배경과 철학, 그리고 지금이 Android 프로젝트 구성 방식을 재고할 적기라고 생각하는 이유를 설명하겠습니다.

또한 이 새로운 접근 방식이 Android 앱 개발의 미래를 어떻게 준비하는지도 살펴보겠습니다.

먼저 현재 상황에 대한 배경을 살펴보겠습니다.

Gradle과 명령형 빌드 스크립트를 사용하면 개발자가 빌드에 관한 거의 모든 것을 프로그래매틱 방식으로 정의할 수 있습니다.

예를 들어 Git 기록을 기반으로 버전 코드를 동적으로 계산하는 로직을 사용하거나 애셋을 변환하는 맞춤 작업을 정의할 수 있습니다.

// build.gradle.kts
android {

  compileSdk = 37

  buildTypes {

    debug {

      // Custom logic in build script
      val commit = providers.exec {
        commandLine("git", "rev-parse",
                    "--short", "HEAD")
      }.standardOutput.asText.get()
       .trim()

      versionNameSuffix = "-$commit"

    }

  }

}

Gradle과 함께 AGP 또는 Android Gradle 플러그인이 있습니다. 이 플러그인은 Gradle의 범용 엔진을 가져와 Android 도구 모음에 맞게 조정합니다.

Gradle과 AGP는 함께 현재 수백만 개의 프로덕션 앱의 빌드 구성 환경을 지원하는 동적 시스템을 형성합니다.

이러한 유연성으로 인해 개발 도구는 특정 아키텍처 수명 주기 내에서 작동합니다.

프로젝트를 열거나 브랜치를 전환하거나 빌드 파일을 수정할 때 IDE는 코드 완성 및 코드 탐색과 같은 기능을 지원할 수 있도록 프로젝트 구성에 대한 명확한 맵과 명확한 이해가 필요합니다.

빌드 파일은 명령형 튜링 완전 언어로 작성되므로 IDE가 구성을 파악하는 유일한 일반적인 방법은 빌드 스크립트를 실행하는 것입니다.

IDE 동기화 중에 빌드 시스템은 구성 단계를 거칩니다.

빌드 스크립트를 평가하고, 플러그인 로직을 실행하고, 프로젝트 모델을 구성합니다.

이렇게 하면 Android 스튜디오의 프로젝트 뷰가 실제 프로젝트 구성과 일치하게 됩니다.

개발자로서 가장 중요하게 생각하는 것은 훌륭한 Android 앱을 개발하여 사용자에게 제공하는 것입니다.

하지만 빌드 스크립트를 관리하고, AGP를 최신 상태로 유지하고, 프로젝트를 IDE와 동기화하는 데는 시간과 노력이 필요합니다.

Google과 더 광범위한 생태계 전반에서 이 영역의 개발자 환경을 개선하기 위한 여러 이니셔티브가 진행 중입니다.

선언적 Gradle 및 Kotlin 도구 모음과 같은 이니셔티브는 실행 가능한 빌드 스크립트를 선언적 빌드 구성으로 대체하는 것을 목표로 합니다.

Android 스튜디오에는 AGP 업그레이드 어시스턴트가 있어 AGP 버전을 변경하는 데 필요한 변경사항을 안내합니다.

또한 상담사가 AGP를 업그레이드하기 위해 설치하고 따를 수 있는 업그레이드 기술도 제공합니다.

또한 개발자가 프로젝트를 동기화하고 가져올 때 더 나은 환경을 제공할 수 있도록 단계적 동기화 및 탄력적 동기화와 같은 영역에 투자하고 있습니다.

이러한 각 노력은 퍼즐의 한 조각을 타겟팅하므로 개발자는 앱을 만드는 데 더 많은 시간을 할애하고 프로젝트를 빌드하고 빌드 파일을 관리하고 프로젝트를 동기화하는 데 더 적은 시간을 할애할 수 있습니다.

이러한 노력과 함께 우리는 더 광범위한 질문을 던졌습니다.

프로젝트를 구성하는 방식을 처음부터 다시 구상한다면 어떨까요?

오늘날 최신 Android 앱의 아키텍처를 살펴보면 대대적인 모듈화로의 전환이 이루어지고 있습니다.

대규모 코드베이스에는 UI 모듈, 기능 모듈, 도메인 모듈, 데이터 모듈 등 수십 개 또는 수백 개의 모듈이 있는 경우가 많습니다.

루트 애플리케이션에는 맞춤 패키징이 필요할 수 있지만, 대부분의 라이브러리 모듈은 표준화된 반복 가능한 패턴을 따릅니다.

빌드 파일에 임의의 실행 코드가 있을 필요는 없습니다.

구조와 종속 항목을 명확하게 명시하는 방법만 있으면 됩니다.

이러한 관찰을 바탕으로 Lightbuild를 만들게 되었습니다.

Lightbuild는 두 가지 핵심 요소를 기반으로 합니다.

첫째, 구성을 위해 선언적 문법을 사용하여 빌드 구성과 로직을 명확하게 분리합니다.

둘째, 사전 종속 항목 해결을 통해 빠른 IDE 동기화 환경을 제공합니다.

각 핵심 요소를 자세히 살펴보면서 일상적인 워크플로에 어떤 영향을 미치는지 알아보겠습니다.

선언적 빌드 구성의 핵심 요소부터 살펴보겠습니다.

화면 왼쪽에 있는 파일을 살펴보세요.

이는 현재 모듈의 구성을 나타냅니다.

// build.gradle.kts

plugins {
   alias(libs.plugins.android.library)
   alias(libs.plugins.kotlin.compose)
}

val gitCommit = providers.exec {
   commandLine("git", "rev-parse", "--short", "HEAD")
}.standardOutput.asText.get().trim()

android {
   namespace = "com.example.app"
   compileSdk = 37

   defaultConfig {
       minSdk = 24
       buildConfigField("String", "GIT_COMMIT",
                        "\"$gitCommit\"")
   }
   buildFeatures {
        compose = true
        buildConfig = true
   }
}

dependencies {
  implementation(platform(libs.androidx.compose.bom))
  implementation(libs.androidx.compose.ui)
  implementation(libs.androidx.compose.ui.graphics)
  ...

이 파일은 실행 가능한 코드이므로 로컬 변수 정의, 커스텀 도우미 함수 또는 규칙 플러그인 호출, 조건문, 인라인 작업 정의를 포함할 수 있습니다.

IDE가 이 구성이 무엇으로 확인되는지 알기 위해서는 실제로 스크립트를 실행해야 합니다.

이제 화면 오른쪽에 있는 파일을 살펴보세요.

이는 유사한 모듈의 Lightbuild 구성입니다.

# lightbuild.yaml

group: "com.example"
version: "1.0.0"

platform: android
type: library

android:
 namespace: "com.example.app"
 compileSdk:
   version:
     release:
       apiLevel: 37
 minSdk:
   version:
     release:
       apiLevel: 24
 dependencies:
   maven:
     - androidx.core:core-ktx:1.10.1
     - androidx.lifecycle:lifecycle-runtime-ktx:2.6.1
     - androidx.activity:activity-compose:1.8.0

이 파일은 순수하게 선언적인 데이터입니다.

로컬 변수 정의, 커스텀 도우미 함수 호출, 조건문 또는 인라인 태스크 정의가 없습니다.

모듈 유형, SDK 타겟, 종속 항목을 명확하게 명시합니다.

새 엔지니어가 팀에 합류하여 이 파일을 열면 해독해야 할 맞춤 빌드 관용구가 없으며, 모든 Lightbuild 프로젝트의 모든 Lightbuild 모듈은 즉시 읽을 수 있는 동일한 언어를 사용합니다.

구성 및 로직의 분리는 인간이 읽을 수 있는 가독성을 높이는 데도 좋지만, Agent Assist 워크플로에는 더욱 혁신적인 변화를 가져옵니다.

개발자가 워크플로의 일부로 에이전트를 채택함에 따라 이러한 에이전트는 빌드 구성을 읽고 수정할 수 있어야 합니다.

하지만 실제로 프로젝트를 빌드하는 것 외에는 구성 변경의 부작용을 예측할 방법이 없습니다.

구성 파일에 한 줄을 추가하면 프로젝트의 다른 위치에 있는 동적으로 계산된 변수 또는 규칙 플러그인과 충돌할 수 있습니다.

Lightbuild에서 프로젝트 구성은 결정론적 정적 데이터 그래프입니다.

즉, 에이전트는 그래프를 검사하고 모듈 토폴로지를 이해하며 알려진 스키마를 사용하여 수정할 수 있습니다.

에이전트는 구조화된 데이터를 읽고 쓰는 것만으로 모듈 목록, 종속 항목 목록 및 해당 버전을 확인하고, 종속 항목을 업데이트하거나, 완전히 새로운 기능 모듈을 추가할 수 있습니다.

이를 통해 프로젝트 구성이 에이전트 지원 워크플로의 핵심 요소가 됩니다.

이 시점에서 강조하고 싶은 또 다른 세부정보는 Lightbuild가 빌드 시스템의 플러그인이 아니라 빌드 엔진의 인터페이스라는 점입니다.

오늘 출시되는 Lightbuild 프리뷰 버전은 Gradle을 실행 엔진으로 사용합니다.

하지만 Lightbuild에서 사용한 아키텍처 접근 방식 덕분에 IDE인 Android 스튜디오는 프로젝트를 Lightbuild 프로젝트로 인식하고 처리합니다.

이제 개발자 생산성과 흐름에 관한 두 번째 핵심 요소인 빠른 IDE 동기화를 살펴보겠습니다.

개발자가 워크플로의 일부로 에이전트를 채택하더라도 Android 스튜디오는 여전히 대화형 작업에 필수적인 도구입니다. 예를 들어 Compose UI 미리보기를 검토하거나, 문제 조사 과정에서 디버거의 코드를 단계별로 실행하거나, 프로파일러로 성능을 분석하는 데 사용됩니다.

프로젝트 구성은 결정론적 정적 데이터 그래프이므로 IDE는 프로젝트를 이해하기 위해 스크립트 평가 단계를 거치거나 플러그인 코드를 실행할 필요가 없습니다.

프로젝트를 열거나, 빌드 파일을 수정하거나, 브랜치를 전환할 때 IDE가 해당 정보를 빠르게 처리하여 도구로 바로 이동할 수 있습니다.

이러한 속도와 안정성이 가능한 이유 중 하나는 Lightbuild가 종속 항목을 처리하는 방식에 있습니다.

일반적으로 종속 항목을 선언할 때 빌드 시스템은 전이 종속 항목 트리를 거쳐 버전 정보를 수집하고 충돌을 해결해야 합니다.

Lightbuild에서는 종속 항목이 변경될 때마다 도구가 전이 종속 항목 정보를 자동으로 계산하여 각 모듈 디렉터리 내의 resolved.deps 파일에 작성합니다.

이렇게 하면 나중에 프로젝트를 다시 열거나 다시 빌드할 때 IDE와 빌드 도구 모두 전이 종속 항목 정보를 다시 계산할 필요가 없습니다.

이러한 파일을 소스 제어에 체크인하는 것이 좋습니다. 이렇게 하면 검토를 위해 팀원에게 변경사항을 보낼 때 팀원이 전이 종속 항목 정보에 변경사항이 있는지 확인할 수 있고, 팀원의 머신에서 전이 종속 항목 정보를 다시 계산할 필요가 없습니다.

또한 이 정보를 소스 제어에 체크인하면 나와 팀원, CI/CD 파이프라인이 매번 동일한 종속 항목 버전으로 빌드할 수 있습니다.

Lightbuild가 Android 스튜디오 Canary에서 초기 프리뷰로 제공되며 독립형 CLI 도구를 통해서도 제공된다는 소식을 알려드립니다.

이 버전의 Lightbuild는 실험용이므로 프로덕션 애플리케이션을 빌드하고 유지하는 데 필요한 모든 기능이 포함되어 있지는 않습니다.

데모 및 실험 프로젝트에서 Lightbuild를 사용해 보는 동안 프로덕션 애플리케이션에는 AGP와 Gradle을 계속 사용하세요.

지금 바로 goo.gle/lightbuild에서 시작해 보세요. 제품이 발전하는 과정에서 여러분의 의견을 반영할 수 있도록 많은 피드백을 부탁드립니다.

이제 스콧에게 프레젠테이션을 넘겨 Lightbuild가 실제로 작동하는 모습을 보여드리겠습니다.

후안, 감사합니다.

제 이름은 스콧 마이어스입니다.

저는 Android 개발자 관계 엔지니어입니다. 저희는 한동안 Lightbuild를 개발해 왔으며, 오늘 여러분께 실제로 사용해 보고 직접 경험해 볼 수 있는 방법을 보여드리게 되어 기쁩니다.

가장 먼저 해야 할 일은 후안이 언급한 링크(goo.gle/lightbuild)로 이동하거나 Lightbuild를 검색하는 것입니다.

그러면 시작하는 데 필요한 모든 단계가 포함된 문서 페이지로 이동합니다. 여기에는 Android 스튜디오의 Canary 버전 설치가 포함됩니다. 아직 프리뷰 단계이며 Android 스튜디오의 안정화 버전에는 아직 포함되지 않았기 때문입니다.

또한 Lightbuild를 사용한 에이전트 환경의 이점을 최대한 누릴 수 있도록 설치할 수 있는 Lightbuild CLI도 있습니다.

설정이 완료되면 제 컴퓨터에서처럼 최신 Android 스튜디오 Canary를 실행할 수 있습니다.

이제 실제로 데모 Lightbuild 프로젝트를 만드는 과정을 단계별로 살펴보고, 지금 바로 이 작업을 수행하는 방법을 보여드리겠습니다.

먼저 새 프로젝트 마법사로 이동합니다.

I'll choose, the Empty Activity, hit Next.

이제 일반적인 프로젝트 세부정보 화면이 표시되지만 하단에 새로운 옵션이 있습니다.

빌드 구성 언어에서 Lightbuild를 선택할 수 있습니다.

'완료'를 누르기 전에 실험 기능이라는 알림이 표시됩니다.

그러면 프로젝트가 IDE와 동기화되고 실행되어 작업할 준비가 된 것을 바로 확인할 수 있습니다.

이제 일반적인 Lightbuild 프로젝트의 프로젝트 구조를 살펴보겠습니다.

이것은 새 애플리케이션을 만들 때 제공되는 기본 Android 템플릿입니다.

'Hello, world!'라고만 표시됩니다.

간단하게 시작할 수 있는 방법입니다.

프로젝트의 루트 수준에 project.lightbuild.yaml이라는 파일이 있습니다.

이렇게 하면 전체 프로젝트의 전역 설정이 표시됩니다.

따라서 프로젝트에 이름을 지정하고, 프로젝트의 모든 모듈을 나열하고, 종속 항목을 가져오는 외부 저장소를 지정한 다음, 프로젝트의 여러 부분에 전역적으로 적용되는 버전을 지정할 수 있습니다.

여기에는 app과 app-core라는 두 개의 모듈이 있습니다.

모든 Lightbuild 프로젝트에는 모듈이 두 개 이상 있기 때문입니다.

앱 모듈이 하나 이상, 라이브러리 모듈이 하나 이상 있어야 하기 때문입니다.

그 이유는 잠시 후에 설명해 드리겠습니다.

먼저 이 앱 모듈을 살펴보겠습니다.

여기에서 확장하면 모듈의 루트 수준에 lightbuild.yaml 파일이 있는 것을 볼 수 있습니다. 이 파일은 모든 모듈에 있습니다.

여기에는 몇 가지 기본 정보가 있습니다.

물론 Android 플랫폼을 개발하고 있습니다.

이 모듈은 애플리케이션 유형입니다.

SDK 타겟 버전, 애플리케이션 ID 등을 나열한 다음 이 애플리케이션 모듈이 종속된 모든 모듈을 나열할 수 있습니다.

이 애플리케이션 모듈에서 흥미로운 점은 표준 Android 템플릿과 약간 다르다는 것입니다. 소스 폴더에 아무것도 없습니다.

따라서 Lightbuild에서 애플리케이션 모듈에는 소스 코드가 포함되지 않습니다.

이 앱 모듈은 자주 변경되지 않지만 빌드하는 데 시간이 걸리기 때문입니다.

따라서 모든 애플리케이션 코드를 라이브러리 모듈 내에 보관하면 앱 모듈의 모든 항목을 다시 계산하고 다시 패키징할 필요가 없으므로 각 빌드가 더 빠르게 진행됩니다.

다음으로 이 애플리케이션 모듈이 종속된 라이브러리 모듈인 app-core 모듈을 살펴보겠습니다.

이 모듈에는 실제로 소스 코드가 있습니다.

여기에 기본 로직이 있습니다.

'Hello, world!'라고만 표시됩니다.

이 모듈의 lightbuild.yaml 파일을 살펴보면 라이브러리 유형임을 알 수 있습니다.

여기에서는 SDK 버전 번호도 설정하지만 이 모듈 내에 있는 모든 외부 종속 항목을 나열합니다.

또한 단위 테스트와 계측 테스트도 선언합니다.

다음으로, 후안이 언급한 또 다른 파일을 살펴보겠습니다. 모든 모듈에는 resolved.deps 파일이 있습니다.

이 파일은 Lightbuild에서 자동으로 생성됩니다.

따라서 직접 수정해서는 안 되지만 이 모듈 내에서 해결된 모든 종속 항목의 목록이 포함됩니다.

따라서 모든 종속 항목과 전이 종속 항목이 이미 여기에 있습니다.

즉, IDE에서 애플리케이션을 열거나 빌드를 만들 때 이 문제를 파악할 필요가 없습니다. 이미 사전에 파악되어 프로젝트에 체크인되어 있기 때문입니다.

다음으로 Lightbuild가 프로젝트 동기화를 통해 개발자 환경을 실제로 개선하는 방법을 보여주는 예를 살펴보겠습니다.

이제 루트 수준 project.lightbuild.yaml로 돌아왔습니다. 여기에는 애플리케이션의 모든 모듈을 나열하는 전역 설정이 있습니다.

일반적으로 구성 또는 빌드 구성 파일을 수정할 때 동기화 버튼이 표시되는데, 후안이 설명한 프로세스 때문에 이 모든 작업을 처리하는 데 시간이 걸립니다. 이 프로세스에서는 모든 빌드 스크립트를 실행하여 부분 빌드를 수행한 다음 해당 모델을 IDE와 동기화해야 합니다.

이 작은 프로젝트에 꽤 큰 변화를 주겠습니다.

모듈 중 하나를 삭제하겠습니다.

저장 버튼을 누르기 전에 이 모듈이 IDE에서 인식되는 것을 볼 수 있습니다. 여기에서 굵게 표시되어 있기 때문입니다.

소스 디렉터리와 테스트 디렉터리를 인식했습니다.

변경사항을 적용한 후 저장하면 이 모듈이 프로젝트에서 즉시 사라지는 것을 확인할 수 있습니다.

변경사항을 다시 실행취소하고 저장을 누르면 바로 원래대로 돌아갑니다.

이것이 Lightbuild가 프로젝트에 제공하는 빠른 IDE 동기화의 예입니다.

또한 Android 스튜디오에서 익숙한 모든 일반 명령어를 실행할 수 있습니다.

실행 버튼을 누르면 됩니다.

앱을 컴파일하고 여기에서 실행합니다.

이 데모 앱은 크지 않지만 확대하여'Hello Android'라고 표시되는 것을 보여드리겠습니다.

테스트 파일로 이동하여 여백에서 실행하는 방식으로 평소와 같이 테스트를 실행할 수 있습니다.

그리고 실제로 백그라운드에서 Lightbuild를 호출하여 이러한 테스트를 실행합니다.

이 모든 것이 예상대로 작동합니다.

하지만 다음으로는 Android 스튜디오를 사용하지 않고 다른 에이전트 플로우를 사용하는 경우 Lightbuild를 사용하는 방법을 보여드리겠습니다.

이를 위해 명령줄이 있습니다.

Lightbuild의 CLI에서 기본 도움말 명령어를 실행해 보겠습니다.

그리고 이 프로젝트에서 보이는 모든 오타는 제 책임입니다.

Lightbuild에는 여러 가지 명령어가 내장되어 있습니다. 죄송합니다. 프로젝트 외부에서 실행하고 있습니다.

계속 그렇게 말해요.

예, 라이브 데모입니다.

먼저 Lightbuild 명령어를 실행하기 전에 Lightbuild 프로젝트를 만들어 보겠습니다.

이를 위해 새 프로젝트 템플릿을 만드는 표준 명령줄 도구인 android create를 사용하겠습니다.

empty-activity-lightbuild 템플릿을 사용하고 앱 이름을 Lightbuild Demo로 지정한 후 데모 출력 디렉터리에 넣겠습니다.

이제 해당 디렉터리로 이동하여 lightbuild -h를 입력하면 Lightbuild에서 사용할 수 있는 모든 명령어가 표시됩니다.

빌드, 정리, 테스트 등 예상할 수 있는 많은 작업이 있습니다.

하지만 새로운 기능도 몇 가지 있습니다.

resolve 명령어가 있는데, 이 명령어는 실제로 프로젝트의 종속 항목을 실행하고 앞에서 보여드린 resolved.deps 파일을 생성합니다.

또한 쿼리 명령어를 사용하면 사용자와 에이전트가 프로젝트의 구조를 더 잘 이해할 수 있습니다.

먼저 새로운 쿼리 명령어를 보여드리겠습니다.

명령줄을 사용하여 이 프로젝트의 구조를 살펴보면 Android 스튜디오 데모에서 사용한 것과 동일합니다.

하지만 이 정보만으로는 프로젝트가 어떻게 구성되어 있는지 알 수 없습니다.

따라서 Lightbuild 쿼리를 실행하고 이 앱 모듈을 살펴본 다음 이 특수 문법을 사용하여 '이 앱 모듈 아래에 있는 모든 항목을 표시해 줘'라고 말합니다.

앱 모듈 내에서 빌드할 수 있는 다양한 타겟이 포함된 표가 표시됩니다.

따라서 디버그 및 출시 바이너리 모두에 대한 APK와 AAB가 있습니다.

앱 타겟을 실행하면 모든 항목이 빌드됩니다.

출력을 JSON으로 지정하는 방법도 있습니다.

그렇게 하면, 아, 죄송합니다.

오늘도 오타가 많네요.

대화형 Lightbuild 도움말을 사용하여 올바르게 진행하고 있는지 확인해 보겠습니다.

음…

네, 작동할 것입니다.

좋습니다.

제가 무엇을 잘못하고 있는지 알려주실 수 있는 분은 이 강연이 끝난 후에 말씀해 주세요.

하지만 이 표 대신 Lightbuild 명령어를 JSON으로 출력할 수도 있습니다. 이 방법이 에이전트에게 더 쉽습니다.

--format json…

형식입니다.

아, 죄송합니다.

감사합니다.

실시간 개발자 의견입니다.

감사합니다.

네, 맞습니다. 출력 명령어도 있는데, 이 부분은 여러분의 도움을 받아 시연해 볼 수 있을 것 같습니다.

따라서 타겟 대신 파일을 출력하면 빌드 내의 모든 다양한 바이너리 위치가 표시됩니다.

따라서 이 기능은 개발자와 에이전트가 Lightbuild를 사용하여 명령줄에서 프로젝트를 탐색하고 더 잘 이해할 수 있는 방법입니다.

그런 다음 앞서 언급한 lightbuild resolve 명령어를 사용하여 모든 resolved.deps 파일을 생성합니다.

이 버전에는 몇 가지 추가 기능도 있습니다.

예를 들어 잠긴 종속 항목 매개변수가 있는데, 이 매개변수를 사용하면 파일을 생성하는 대신 파일의 콘텐츠를 빌드 구성에 선언한 종속 항목과 비교합니다.

차이가 있으면 알려주고 빌드가 실패합니다.

따라서 이러한 해결된 종속 항목 파일은 잠금 파일 역할을 할 수 있습니다. 예를 들어 프로덕션을 위해 CI/CD 시스템에서 앱을 빌드하는 경우 빌드 중에 종속 항목이 변경되는지 알고 싶을 것입니다.

또한 Lightbuild에는 테스트 기능이 내장되어 있으며, 예를 들어 명령줄에서 바로 이 라이브러리 모듈의 모든 테스트를 실행할 수도 있습니다.

한 가지 더 보여드리고 싶은 것이 있습니다.

사용할 수 있는 모든 매개변수와 하위 명령어의 전체 목록을 제공하는 도움말도 제공됩니다.

에이전트에서 사용할 수 있으므로 에이전트의 출력입니다.

좋습니다.

지금까지 Lightbuild를 사용한 간단한 프로젝트를 살펴봤으니 이제 좀 더 야심 찬 프로젝트를 보여드리겠습니다.

Android팀에서 제공하는 Now in Android라는 샘플 앱이 있습니다. 이 앱은 최신 Android 기능을 제공하고, 사용 방법을 보여주며, 몇 가지 권장사항을 보여줍니다.

모듈성이 높은 애플리케이션입니다.

약 32개의 모듈로 나뉘어 있습니다.

GitHub에서는 다음과 같이 표시됩니다.

하지만 Android 스튜디오로 다시 전환하겠습니다. 여기서는 이미 에이전트를 사용했습니다.

Now in Android 프로젝트를 Lightbuild로 변환하기 위해 Gemini Argon을 사용하고 있었습니다.

이것은 Google에서 게시한 것이 아니라 제가 직접 한 것입니다.

project.lightbuild.yaml의 이 프로젝트에는 다양한 모듈이 있지만, 여전히 매우 빠르게 열리고 이 IDE와 매우 빠르게 동기화됩니다.

이 프로젝트에서 주목할 만한 또 다른 점은 데모 빌드와 프로덕션 빌드를 모두 사용하기 위해 일부 빌드 버전을 사용했다는 것입니다. 각 빌드는 앱을 표시하는 방식이 약간 다릅니다.

데모 버전은 기본 제공 데이터 소스를 사용하고 프로덕션 버전은 실제로 네트워크에 연결하여 데이터를 가져옵니다.

Lightbuild에서 다양한 빌드 구성이나 제품 버전과 같은 항목을 처리하는 방식은 애플리케이션 모듈로 이동하여 이 애플리케이션 모듈이 데모 애플리케이션임을 지정하는 것입니다.

따라서 모든 핵심 구성요소에 의존하지만 앱의 데모 버전에만 적용되는 특수 설정도 가져옵니다.

이렇게 하면 여러 애플리케이션 모듈을 가질 수 있습니다.

각각은 앱의 유료 또는 무료 버전을 나타낼 수 있습니다.

또한 애플리케이션 모듈이 코드가 없는 빈 셸이므로 훨씬 더 빠르게 빌드되고, 라이브러리가 변경될 때마다 해당 라이브러리만 다시 컴파일하면 앱을 다시 빌드할 수 있다는 이점도 있습니다.

Now in Android 앱이 32개의 서로 다른 모듈과 함께 Lightbuild로 성공적으로 빌드되는지 살펴보겠습니다.

네, 여기 있습니다.

이러한 실험을 통해 알게 된 또 다른 사실은 Lightbuild가 필요한 모든 빌드 기능을 지원하지는 않는다는 점입니다.

예를 들어 Now in Android 앱은 Hilt를 사용하기 위해 Hilt 플러그인을 사용하는데, Lightbuild는 아직 이러한 기능을 지원하지 않습니다.

그래서 에이전트가 해결 방법을 찾아냈고, 프로젝트 자체의 코드를 크게 변경하지 않고도 Hilt 지원을 받을 수 있었습니다.

이러한 모든 모듈의 모든 코드는 원래 저장소와 동일합니다.

하지만 Lightbuild를 직접 실험하고 데모할 때 반드시 염두에 두어야 할 점은 현재 프로젝트의 모든 항목이 빌드 구성 측면에서 지원되는 것은 아니라는 점입니다.

이러한 이유로 Lightbuild는 아직 프리뷰 단계이며 Android 스튜디오 Canary에서만 사용할 수 있습니다.

이제 슬라이드로 돌아가겠습니다.

지금까지 설명한 내용을 요약하자면, Lightbuild는 Android를 위한 새로운 빌드 플랫폼으로, 현재 실험 단계에 있습니다.

선언적 빌드 구성이 있으므로 빌드 구성에서 실행 코드를 실행하지 않으며, 빠른 IDE 동기화와 더 효율적인 빌드로 많은 유용한 기능을 사용할 수 있습니다.

최고 수준의 AI 에이전트 지원을 제공하며, 명령줄에서 오늘 시연을 도와주신 모든 기능을 사용할 수 있습니다.

따라서 사용해 보고 데모 및 실험 프로젝트에 사용해 보시기 바랍니다.

또한 후안과 저, 그리고 팀의 엔지니어들이 에이전트 AI 부스에서 여러분의 질문에 답변해 드릴 예정입니다.

감사합니다.