프롬프트 한 줄로 앱이 생긴다면, 개발자의 일은 어디서 시작하는가

Google I/O 2026 발표를 처음 들었을 때 반응은 "또 AI 코드 자동완성 얘기겠지"였다. 그런데 실제 내용을 따라가다 보면 결이 다르다는 걸 느끼게 된다. 단순히 코드를 빠르게 쓰는 게 아니라, 소프트웨어 배포 라이프사이클 전체를 하나의 인터페이스에서 다루겠다는 시도다.

---

Android CLI 1.0이 실제로 바꾸는 것

가장 눈에 띄는 건 Android CLI 1.0의 안정화다. AI 에이전트가 Android Studio의 빌드·분석·테스트 기능에 직접 프로그래매틱하게 접근할 수 있는 표준 인터페이스가 열렸다는 의미다.

기존에는 AI 에이전트가 안드로이드 빌드 관련 작업을 처리하려면 터미널 명령어를 해석하거나 파일을 직접 수정하는 방식으로 우회했다. 토큰도 많이 썼고, 컨텍스트 전달도 불완전했다. Android CLI는 이 레이어를 직접 열어준다. Antigravity, Claude Code 같은 외부 에이전트 툴도 이 인터페이스를 통해 Android Studio의 기능을 호출할 수 있다.

구글이 공개한 내부 실험 결과로는 LLM 토큰 사용량이 70% 감소하고, 동일 작업 완료 속도가 3배 빨라졌다고 한다. 이 수치를 액면 그대로 받아들일 필요는 없지만, 에이전트가 빌드 시스템과 직접 대화할 수 있다는 게 어떤 의미인지는 분명하다. CI 파이프라인에서 에이전트 작업의 품질 게이트를 자동화할 수 있는 경로가 생겼다.

---

AI Studio에서 Play Store 내부 트랙까지

이번 발표의 파이프라인은 이렇다. AI Studio에 텍스트 프롬프트를 입력하면 Kotlin + Jetpack Compose 기반의 앱이 생성된다. 브라우저 내 에뮬레이터에서 바로 실행할 수 있고, USB로 연결된 실제 기기에 ADB를 통해 설치할 수도 있다. Google Play 개발자 계정을 연결해두면 내부 테스트 트랙에 한 번의 클릭으로 올라간다.

// AI Studio가 생성하는 전형적인 Compose 구조
@Composable
fun HomeScreen(viewModel: HomeViewModel = viewModel()) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    Scaffold(
        topBar = { TopAppBar(title = { Text("Home") }) }
    ) { paddingValues ->
        when (val state = uiState) {
            is HomeUiState.Loading -> CircularProgressIndicator()
            is HomeUiState.Success -> ContentList(
                items = state.items,
                modifier = Modifier.padding(paddingValues)
            )
            is HomeUiState.Error -> ErrorMessage(message = state.message)
        }
    }
}

구조 자체는 나쁘지 않다. ViewModel 분리, sealed class UiState, collectAsStateWithLifecycle() 같은 권장 패턴도 잘 따른다. 문제는 이 뼈대가 실제 요구사항과 맞닿는 지점부터 생긴다.

---

프로토타입과 출시 사이의 간극

생성된 코드가 시작점이라는 건 발표 자료도 명시하고 있다. 그런데 그 간극이 어떤 성격인지를 구체적으로 짚어둘 필요가 있다. 단순히 "코드가 더 필요하다"는 문제가 아니다.

접근성은 AI가 contentDescription을 넣어줄 수는 있지만, TalkBack 사용자가 실제로 이 화면을 어떻게 탐색할지를 판단하지는 못한다. 보안도 마찬가지다. API 키 관리, 딥링크 검증, 인텐트 노출 여부는 코드 생성 단계에서 담보되지 않는다. 퍼포먼스 쪽에서는 흔히 이런 실수가 나온다.

// 자주 놓치는 recomposition 문제
@Composable
fun ItemList(items: List<Item>) {
    // 매 recomposition마다 정렬 연산이 다시 실행됨
    val sorted = items.sortedBy { it.name }

    // remember로 감싸야 한다
    val sorted = remember(items) { items.sortedBy { it.name } }

    LazyColumn {
        items(sorted, key = { it.id }) { item ->
            ItemRow(item)
        }
    }
}

AI가 생성한 코드에서 key 람다가 빠지거나, remember 없이 expensive한 연산이 Composable 내부에 직접 쓰이는 경우는 자주 보인다. 정적 분석으로는 잡기 어렵고, 실제 스크롤 퍼포먼스를 측정해봐야 드러난다.

이런 판단은 에이전트가 코드를 생성한 뒤에도 개발자가 직접 개입해야 하는 영역이다.

---

에이전트 툴이 잘 맞는 팀과 그렇지 않은 팀

Antigravity 2.0은 AI Studio에서 생성된 프로토타입을 받아서 워크플로우를 자동화하는 오케스트레이션 플랫폼이다. Go로 작성된 새 CLI, 데스크톱 앱, SDK를 포함한다. 이 도구가 가장 효과적인 환경은 팀이 이미 명확한 구조를 갖추고 있을 때다.

저장소 구조, QA 흐름, 리뷰 게이트, 성능 측정 기준선이 정의돼 있는 팀이라면 에이전트가 그 레일 위에서 작업 속도를 높여준다. 반대로 이런 기반이 없는 팀에서 에이전트를 먼저 도입하면, 빠르게 일관성 없는 코드가 쌓인다. 속도는 올라가지만 방향이 흩어진다.

Android CLI가 안정화됐다는 건, 빌드·분석·테스트를 에이전트 워크플로우에 직접 연결할 수 있다는 뜻이기도 하다. 에이전트가 만든 코드가 Lint, 단위 테스트, 인스트루먼테이션 테스트를 통과해야만 다음 단계로 넘어가는 자동화된 게이트를 구성할 수 있게 됐다.

---

이 발표를 어떻게 읽을 것인가

Google I/O 2026의 모바일 발표를 "AI가 앱을 만들어준다"로 읽으면 절반만 본 거다. 더 정확하게는 "AI 에이전트가 참여할 수 있는 표준 인터페이스가 안드로이드 툴체인에 열렸다"는 쪽에 무게가 있다.

Android CLI 1.0은 당장 써볼 수 있는 가장 구체적인 결과물이다. 빌드 자동화, 에뮬레이터 제어, APK 분석을 에이전트 워크플로우에 통합할 수 있는 경로가 생겼다. AI Studio의 앱 생성은 빠른 프로토타이핑 도구로 유용하지만, 그 결과물을 그대로 배포하겠다는 생각은 아직 이르다.

에이전트가 코드를 만들어주는 구간과 개발자가 판단해야 하는 구간을 명확히 구분하고 시작하는 팀이, 이번 변화에서 실질적인 이득을 얻을 것이다.

※ 본 글은 정보 제공 목적이며 특정 제품·서비스의 추천이 아닙니다.