Google은 2026년 9월 24일 Android Developers Blog를 통해 Android Studio의 Bring Your Own Agent, 줄여서 BYOA를 공개했습니다. 한 줄 요약은 이렇습니다.

작년 모델을 고를 수 있게 열어준 데 이어, 올해는 에이전트 자체를 가져오게 열었다.

Android 개발자가 아니더라도 주목할 만한 발표입니다. IDE가 에이전트를 직접 제공하는 구조에서 개발자가 원하는 에이전트를 연결하는 구조로 움직이고 있기 때문입니다.

BYOA가 정확히 무엇인가요

최신 Canary인 Rabbit 2부터 프리뷰로 제공되고, 처음부터 나오는 에이전트는 세 가지입니다. Google Antigravity, Claude Agent, Codex입니다. ACP(Agent Client Protocol)를 지키는 에이전트라면 등록해서 쓸 수 있고, 경로는 Settings > Tools > AI > Agents에 있는 에이전트 레지스트리입니다.

연결 방식은 거창하지 않습니다.

1. Canary 채널의 최신 Android Studio로 업데이트
2. 에이전트 창에서 에이전트 선택 (Claude Agent / Codex / Antigravity)
3. 쓰던 요금제로 로그인하거나 API 키 입력

구조를 그림으로 그리면 이렇습니다.

예전 IDE
개발자 → Gemini 내장 에이전트 → 코드 변경

BYOA 이후
개발자 → 고른 에이전트 (Claude / Codex / Antigravity)
        → Android Studio의 프로젝트 정보 + 빌드·실행 도구
        → 코드 변경 → 빌드·테스트 → 확인 → 재수정

Google이 내세우는 이득도 이 그림 위에 있습니다. 에이전트가 Android 프로젝트 그래프, 빌드 설정, 플랫폼 정보를 받아서 더 정확하게 일하고, 대화하다가 막히면 IDE 도구를 그대로 이어 쓴다는 것입니다. 한 에이전트의 할당량이 떨어지거나 결과가 마음에 안 들면 다른 에이전트가 이어받을 수 있습니다. 요금제 입장에서는 각자 쓰던 걸 가져오는 형태라 기업용과 개인용 요금제를 함께 쓸 수 있습니다.

Gemini를 계속 쓰는 흐름도 남아 있습니다. 내장 에이전트로 Gemini를 바로 쓰는 방식은 유지되고, 최신 Gemini 모델과 더 많은 할당량을 원하면 Antigravity 에이전트를 고르라는 안내가 붙습니다. Gemini Flash 3.8 같은 최신 모델 접근, Google AI Pro나 Ultra 로그인, Gemini API 키의 토큰 기준 과금이 그쪽에 묶여 있습니다. Gemini Enterprise를 쓰는 조직은 내장 에이전트든 Antigravity든 Google Cloud 쪽 보안·프라이버시 조건이 유지된다는 설명입니다.

갑자기 떨어진 기능이 아닙니다

BYOA는 올해 초부터 Agent Mode가 권한과 검증 쪽으로 조금씩 바뀌어 온 연장선에 있습니다. 같이 보면 이해가 빠릅니다.

2026년 1월 Otter 3에서는 Bring Your Own Model이 들어왔습니다. Anthropic, OpenAI 같은 외부 모델을 API 엔드포인트와 키로 연결해서 IDE 기능에 쓰는 방식입니다. 같은 릴리스에서 바뀐 것들이 지금 보면 다 검증 루프 부품입니다.

- 바뀐 파일을 모아 보여주는 changes drawer (파일 단위 keep·revert)
- 기기에 직접 배포해서 스크린샷·Logcat 확인, adb shell input 조작
- Figma·Notion 같은 원격 MCP 서버 연결
- 자연어로 쓰는 여정 테스트 (Journeys)

7월 Quail 2에서는 병렬 대화가 들어왔습니다. UI 리팩터 하나, ProGuard 수정 하나, 문서 생성 하나를 탭을 나눠 동시에 돌리는 방식입니다. 같은 파일을 건드리면 충돌이 날 수 있다는 주의와 함께 나왔고, App Quality Insights의 크래시를 에이전트 채팅으로 바로 넘겨서 Fix with AI로 고치는 연결도 이때 정리됐습니다.

그리고 파일 수정 같은 행동에 대한 명시적 권한 제어가 Agent Mode에 들어가 있습니다. 자동 승인 옵션을 켤 수도 있지만, 기본값은 사람이 보고 승인하는 쪽에 가깝습니다. AGENTS.md 같은 저장소 단위 지시 파일 지원도 같은 흐름입니다. 에이전트에게 매번 말로 설명하지 말고, 저장소에 규칙을 적어두라는 것입니다.

정리하면 방향은 꽤 분명합니다.

코드 편집기
→
에이전트 실행 환경
(repo context + tool + permission + verification loop)

왜 IDE 단축키보다 검증 루프가 중요해지는가요

앞으로 경쟁력이 특정 IDE 단축키를 잘 쓰는 능력보다 에이전트에게 repo context·tool·permission·verification loop를 어떻게 제공하는가로 이동할 가능성이 큽니다. 이유를 구체적으로 들어보겠습니다.

에이전트가 코드를 고치는 것 자체는 이제 흔해졌습니다. 차이는 고친 다음에 벌어집니다. 빌드가 도는지, 테스트가 깨지지 않았는지, 실패 로그가 다음 지시에 자동으로 들어가는지, 위험한 명령 전에 승인이 걸리는지에서 갈립니다. 이 루프가 IDE 안에 있으면 개발자는 결과를 기다리면 되고, 루프가 밖에 있으면 사람이 복붙으로 메워야 합니다.

빠른 에이전트 + 수동 검증
→ 사람은 빨라진 만큼 검토 노동이 는다

보통 에이전트 + 자동 검증 루프
→ 사람은 결과만 보고 승인하면 된다

그래서 BYOA 발표를 "Android Studio가 외부 에이전트를 허용했다"로만 읽으면 절반만 본 것입니다. 나머지 절반은 IDE 자체가 점점 코드 편집기가 아니라 에이전트가 도는 실행 환경이 되고 있다는 점입니다. 어떤 에이전트를 쓰든 프로젝트 정보, 빌드·실행 도구, 권한, 검증 루프를 IDE가 제공한다는 구상입니다.

오늘의 액션: 내 프로젝트의 검증 루프를 세어보세요

Android 개발자가 아니어도 해볼 게 있습니다. 지금 쓰는 프로젝트에서 이 질문에 답해보세요.

1. 에이전트가 바꾼 파일을 한곳에 모아 볼 수 있는가?
2. 파일 단위로 되돌리기가 되는가?
3. build / test가 자동으로 도는가?
4. 실패 로그가 다음 지시에 자동으로 들어가는가?
5. 위험한 명령 전에 승인이 걸리는가?
6. 규칙 파일이 저장소에 있는가? (AGENTS.md, CLAUDE.md 등)

1~2개만 빠져도 에이전트는 빨라지는데 사람은 불안해집니다. IDE를 바꾸기 전에 이 여섯 개를 먼저 메우는 편이 효과가 큽니다. 작은 예로 Agent에게 "빌드 에러를 고쳐줘"라고 시켰을 때, 고치고 → 빌드 돌리고 → 실패하면 다시 고치는 과정을 사람 손 없이 도는지 보면 됩니다. 이 루프가 도는 프로젝트와 안 도는 프로젝트는 에이전트 체감이 완전히 다릅니다.

함께 읽으면 좋은 글

참고 자료

이 주제를 직접 따라가며 배우고 싶다면

에이전트에게 일을 맡기되 검증과 권한이 있는 흐름으로 통제하는 연습이 필요하다면, CLAUDE.md·Skills·Hooks·Subagents·MCP를 실제 프로젝트에 쌓는 과정이 이 글의 검증 루프 이야기와 바로 이어집니다.