구글 에이전트 스미스, 구글 코드 25% 작성: API 팀이 알아야 할 점

TL;DR

Google의 사내 AI 코딩 에이전트인 Agent Smith가 이제 회사 신규 프로덕션 코드의 25% 이상을 생성하고 있습니다. Copilot과 같은 자동 완성 도구와 달리 Agent Smith는 백그라운드에서 비동기적으로 작동하며, 사람의 개입 없이 코드를 작성하고 테스트하며 반복합니다. API 팀에게는 코드베이스의 1/4이 기계 생성될 때 계약 안정성, 테스트 범위, 문서 불일치, 검토 워크플로에 대한 의문이 제기됩니다.

서론

2026년 3월 실적 발표에서 Google CEO 순다르 피차이는 전체 소프트웨어 산업을 멈칫하게 할 만한 수치를 공개했습니다: 이제 Google에서 생산되는 신규 코드의 25% 이상이 AI가 생성한 코드입니다.

이것은 자동 완성도 아닙니다. 개발자들이 수락한 Copilot 제안도 아닙니다. 이것은 AI 생성 후 프로덕션에 배포되는 코드입니다. 이 도구는 내부적으로 Agent Smith(매트릭스의 자가 복제 악당에 대한 오마주)라고 불리는데, Google의 180,000명 이상의 직원들 사이에서 너무 인기가 많아 회사는 인프라 부담을 관리하기 위해 접근을 제한해야 했습니다.

Agent Smith는 오늘날 대부분의 개발자가 사용하는 AI 코딩 도구와는 다른 범주에 속합니다. Copilot과 Claude Code가 실시간으로 지원하는 반면, Agent Smith는 백그라운드에서 작동합니다. 엔지니어는 작업을 할당하고 자리를 비웠다가 나중에 돌아와 완료된 작업을 검토합니다.

API 개발 팀에게 “AI 지원”에서 “AI 생성” 코드로의 이러한 전환은 실제적인 질문을 제기합니다. 코드베이스의 25%가 자율 에이전트에 의해 작성될 때, API 계약을 어떻게 안정적으로 유지할 수 있을까요? 기계 생성 엔드포인트를 테스트가 커버하도록 어떻게 보장할 수 있을까요? 문서가 불일치하는 것을 어떻게 방지할 수 있을까요?

💡

Apidog의 통합 API 라이프사이클 플랫폼은 인간이든 AI 에이전트든 변경을 수행하는지에 관계없이 설계, 테스트, 목(mock), 문서를 동기화 상태로 유지합니다. Apidog을 무료로 사용하여 에이전트 방어적인 API 워크플로를 구축해 보세요.

button

이 글은 Agent Smith가 무엇을 하는지, 다른 AI 코딩 도구와 어떻게 다른지, 그리고 API 팀이 무엇을 준비해야 하는지에 대해 자세히 설명합니다.

Agent Smith는 무엇을 하는가

비동기 자율 코딩

Agent Smith는 IDE에 앉아 당신이 타이핑하기를 기다리지 않습니다. 백그라운드에서 비동기적으로 작동합니다. 워크플로는 다음과 같습니다:

엔지니어가 자연어로 작업을 설명합니다.
Agent Smith는 작업을 하위 작업으로 나눕니다.
여러 파일에 걸쳐 코드를 작성합니다.
테스트를 실행하고 실패 시 반복합니다.
엔지니어는 완료된 작업을 검토합니다.

이것은 Copilot의 인라인 제안이나 Claude Code의 대화형 세션과는 근본적으로 다릅니다. Agent Smith는 티켓을 받아 몇 시간 동안 사라졌다가 풀 리퀘스트를 가지고 돌아오는 주니어 개발자에 가깝습니다.

엔지니어는 Google의 내부 채팅 플랫폼을 통해 모바일 장치에서도 작업을 위임하고 진행 상황을 확인할 수 있습니다. 이 도구는 직원 프로필과 관련 문서에 자동으로 액세스하여 Google의 내부 지식 기반에서 컨텍스트를 가져옵니다.

Gemini 및 Antigravity 기반 구축

Agent Smith는 Google의 Gemini 모델 제품군에서 실행되며, Google의 방대한 내부 코드베이스 및 문서에 액세스할 수 있는 검색 시스템으로 강화되었습니다. 이는 Google의 기존 에이전트 코딩 플랫폼인 Antigravity를 기반으로 구축되었지만, 자율적인 작업 분해 및 실행으로 확장됩니다.

검색 증강이 핵심입니다. Agent Smith는 고립된 상태에서 코드를 생성하지 않습니다. Google의 내부 코드베이스에서 유사한 패턴을 검색하고, 기존 구현을 참조하며, 내부 코딩 규칙을 따릅니다. 이러한 컨텍스트 인식 덕분에 25% 규모의 프로덕션 품질 출력이 가능합니다.

“신규 코드의 25%”가 의미하는 것

피차이의 수치는 맥락이 필요합니다. “신규 코드의 25%”는 다음 코드를 의미합니다:

AI에 의해 생성된 것이며, 자동 완성된 것이 아닙니다.
코드 검토를 통과합니다 (인간 엔지니어는 여전히 Agent Smith의 결과물을 검토합니다).
프로덕션 시스템에 배포됩니다.
Google의 모든 엔지니어링 결과물에 걸쳐 측정됩니다.

이것은 Google 전체 코드베이스의 25%가 AI 생성이라는 의미가 아닙니다. 오늘날 작성되는 신규 코드의 25%가 Agent Smith에서 나온다는 의미입니다. 새로운 코드는 기존의 인간이 작성한 코드베이스에 추가되는 것이기 때문에 이러한 구별은 중요합니다. 그러나 그 궤적은 분명합니다: 이 비율은 증가하고 있으며, 피차이는 이를 전략적 이점으로 강조했습니다.

Agent Smith가 다른 AI 코딩 도구와 다른 점

AI 코딩 도구 스펙트럼

도구	모드	상호작용	범위	프로덕션 코드인가요?
GitHub Copilot	실시간 자동 완성	IDE 내 인라인	라인/함수 수준	인간 승인 후
Claude Code	대화형 세션	대화형	다중 파일 변경	인간 검토 후
Cursor Agent	백그라운드 + 대화형	IDE 내장	프로젝트 수준	인간 검토 후
Agent Smith	비동기 자율	작업 위임	전체 기능 구현	인간 검토 후
KAIROS (미출시)	상시 실행 데몬	백그라운드 모니터링	저장소 전반	미정

Agent Smith는 이 스펙트럼의 자율적인 끝에 위치합니다. 유일하게 더 나아간 단계는 인간 검토 없이 완전히 자율적으로 배포하는 것이겠지만, 아직 어떤 주요 도구도 그렇게 하지 않으며 (해서도 안 됩니다).

API 팀에게 비동기가 중요한 이유

실시간 AI 코딩 도구(Copilot, Claude Code)는 개발자의 작업 흐름 내에서 작동합니다. 개발자는 AI가 작성하는 것을 보고, 컨텍스트를 이해하며, 즉시 수정합니다.

비동기 에이전트는 이러한 역학 관계를 바꿉니다. Agent Smith가 API 엔드포인트를 작성하면 개발자는 사후에 이를 검토합니다. 검토는 생성 컨텍스트와 분리됩니다. 이는 다음을 의미합니다:

개발자가 에이전트가 특정 응답 형식을 선택한 이유를 이해하지 못할 수 있습니다.
API 계약 변경 사항이 표준 코드 검토에서 명확하지 않을 수 있습니다.
관련 아티팩트(테스트, 문서, 목)가 업데이트되지 않았을 수 있습니다.
검토자가 전체 영향을 확인하지 않으면 치명적인 변경 사항이 간과될 수 있습니다.

AI가 API 코드를 작성할 때 무엇이 문제가 되는가

API 계약 불일치

API 계약은 서비스와 소비자 간의 합의입니다: 엔드포인트, 요청/응답 스키마, 상태 코드, 오류 형식. 인간 개발자가 API를 수정할 때, 일반적으로 OpenAPI 사양을 업데이트하고, 소비자에게 알리며, 변경 사항의 버전을 지정합니다.

자율 에이전트가 API를 수정할 때, 이러한 조정 단계는 자동으로 발생하지 않습니다. Agent Smith는 테스트를 통과하는 코드를 작성합니다. 그러나 테스트는 이전에 작성된 것만 다룹니다. 에이전트가 기존 테스트를 통과하지만 다운스트림 소비자에게 영향을 미치는 방식으로 응답 스키마를 변경하면, 프로덕션에서 문제가 발생합니다.

예시 시나리오:

Agent Smith에게 "프로필 엔드포인트에 사용자 기본 설정을 추가"하는 작업이 주어집니다.
GET /api/users/{id} 응답에 preferences 필드를 추가합니다.
기존 테스트는 추가 필드의 부재를 단언하지 않기 때문에 통과합니다.
프런트엔드 팀의 TypeScript 타입에 preferences가 포함되어 있지 않습니다.
모바일 앱의 엄격한 JSON 파싱이 예상치 못한 필드에서 오류를 발생시킵니다.

코드는 올바릅니다. 테스트는 통과합니다. 그러나 계약은 깨졌습니다.

테스트 범위 격차

AI가 생성한 코드에는 AI가 생성한 테스트가 함께 제공되며, AI 에이전트는 회귀를 방지하는 테스트보다는 자신이 구축한 것을 검증하는 테스트를 작성하는 경향이 있습니다. 이는 맹점을 만듭니다: 테스트는 새로운 동작이 작동함을 확인하지만, 기존 동작이 보존됨을 확인하지는 않습니다.

API 엔드포인트의 경우, 이는 다음을 의미합니다:

응답 시간 벤치마크가 테스트되지 않을 수 있습니다.
오류 응답 형식이 표준 오류 스키마와 다를 수 있습니다.
속도 제한 동작이 검증되지 않을 수 있습니다.
인증 예외 경우가 다뤄지지 않을 수 있습니다.
페이지네이션 동작이 기존 엔드포인트와 다를 수 있습니다.

문서 불일치

API 문서가 코드 주석이나 OpenAPI 사양에서 생성되는 경우, 에이전트가 수정한 코드는 문서에 자동으로 전파되어야 합니다. 그러나 많은 팀은 문서를 별도로 관리합니다. Agent Smith가 엔드포인트를 추가하거나 응답 스키마를 수정할 때, 문서 업데이트는 에이전트가 수행할 수도 있고 안 할 수도 있는 별도의 작업이 됩니다.

자동 생성된 문서라도 설명, 예시, 사용법 노트는 AI 에이전트가 갖지 못하는 인간의 컨텍스트를 필요로 합니다. 에이전트는 엔드포인트가 무엇을 하는지 문서화할 수 있습니다. 하지만 왜 존재하는지, 누가 사용하는지, 어떤 절충안이 설계로 이어졌는지에 대해서는 문서화할 수 없습니다.

검토 피로

코드의 25%가 AI 생성이라면, 코드 검토의 25%는 AI 결과물을 검토하는 것입니다. AI 생성 코드는 문법적으로 일관되고 잘 구조화되어 있어 얼핏 보면 "괜찮아" 보입니다. 그러나 괜찮아 보이는 것이 컨텍스트 내에서 올바른 것과 같지는 않습니다.

검토자들은 새로운 도전에 직면합니다: 코드는 잘 읽히지만, 아키텍처 결정, 팀 규칙, 또는 검토자의 머릿속에는 있지만 에이전트의 프롬프트에는 없는 명시되지 않은 요구사항과 일치하지 않을 수 있습니다. 시간이 지남에 따라 AI 생성 코드에 대한 검토 피로는 형식적인 승인으로 이어질 수 있으며, 이는 버그가 배포되기 시작하는 지점입니다.

에이전트 방어적인 API 워크플로 구축 방법

1. API 계약을 진실의 원천으로 만드세요.

디자인 우선 API 개발은 에이전트로 인한 불일치를 방지하는 가장 강력한 방어책입니다. OpenAPI 사양이 진실의 원천일 때, 계약을 위반하는 모든 코드 변경은 감지할 수 있습니다.

디자인 우선 방식 없이:

코드 변경 → 테스트 통과 → 배포 → 계약 위반

디자인 우선 방식 사용 시:

사양이 계약을 정의 → 코드는 사양과 일치해야 함 → 계약 유효성 검사로 불일치 감지

Apidog의 시각적 API 디자이너는 코드를 작성하기 전에 엔드포인트, 스키마 및 응답 형식을 정의할 수 있도록 합니다. Agent Smith(또는 다른 에이전트)가 코드를 생성할 때, 불완전할 수 있는 기존 테스트가 아니라 사양에 따라 유효성을 검사합니다.

2. 단위 테스트 대신 계약 테스트를 사용하세요.

단위 테스트는 내부 동작을 검증합니다. 계약 테스트는 서비스 간의 계약을 검증합니다. AI 에이전트가 API를 수정할 때, 계약 테스트는 단위 테스트가 놓칠 수 있는 변경 사항을 잡아냅니다.

계약 테스트 예시:

// This test fails if the response shape changes,
// even if the new shape is "valid"
describe("GET /api/users/:id contract", () => {
  it("returns expected schema", async () => {
    const response = await request(app).get("/api/users/123");

    expect(response.body).toMatchSchema({
      type: "object",
      required: ["id", "name", "email", "created_at"],
      properties: {
        id: { type: "string" },
        name: { type: "string" },
        email: { type: "string", format: "email" },
        created_at: { type: "string", format: "date-time" }
      },
      additionalProperties: false  // This catches unexpected fields
    });
  });
});

additionalProperties: false 라인은 중요합니다. 이것이 없으면 응답에 필드를 추가하는 에이전트는 모든 테스트를 통과합니다. 이것이 있으면 모든 스키마 변경에 명시적인 계약 업데이트가 필요합니다.

Apidog은 API 사양에서 계약 테스트를 자동화합니다. 스키마를 한 번 정의하면 Apidog이 수동 테스트와 CI/CD 실행 모두에서 모든 응답을 스키마에 대해 검증합니다.

3. 사양 유효성 검사에 따라 배포를 제한하세요.

CI/CD 파이프라인에 API 사양 유효성 검사를 추가하세요. 코드(인간 또는 AI 생성)가 배포되기 전에 선언된 계약과 일치하는지 확인하세요:

# CI/CD pipeline step
- name: Validate API contract
  run: |
    # Diff the current spec against the running implementation
    apidog run --test-scenario-id CONTRACT_TESTS
    
    # Fail if any contract violations found
    if [ $? -ne 0 ]; then
      echo "API contract violation detected. Review changes."
      exit 1
    fi

이는 Agent Smith의 계약 위반 변경 사항이 프로덕션에 도달하기 전에 잡아냅니다.

4. API 변경 시 사양 업데이트를 요구하세요.

개발 규칙을 만드세요: API 동작을 수정하는 모든 PR은 해당 OpenAPI 사양 업데이트를 포함해야 합니다. AI 생성 PR의 경우, 에이전트가 사양을 업데이트하거나 병합 전에 인간이 이를 수행해야 합니다.

Apidog에서 사양 변경은 다음으로 자동으로 전파됩니다:

API 문서
목 서버 응답
테스트 단언
클라이언트 SDK 타입

이 연쇄적인 작용은 계약이 변경될 때 어떤 아티팩트도 불일치하지 않도록 보장합니다.

5. 프로덕션에서 API 동작을 모니터링하세요.

계약 테스트와 사양 유효성 검사에도 불구하고, 프로덕션 모니터링은 사전 프로덕션 테스트에서 놓치는 것을 잡아냅니다. 다음을 추적하세요:

응답 스키마 위반: 응답이 선언된 스키마와 일치하지 않을 때 로그를 남깁니다.
새로운 필드 출현: 사양에 없는 응답 필드에 대해 경고합니다.
오류율 변경: AI 생성 엔드포인트는 다른 오류 분포를 가질 수 있습니다.
지연 시간 변화: 에이전트가 작성한 코드는 다른 성능 특성을 가질 수 있습니다.
트래픽 패턴 변경: 새로운 엔드포인트는 예상치 못한 트래픽 패턴을 받을 수 있습니다.

6. API 검토를 코드 검토와 분리하세요.

표준 코드 검토는 "이 코드가 작동하는가?"를 묻습니다. API 검토는 "이 변경이 소비자에게 영향을 미치는가?"를 묻습니다.

AI 생성 API 변경에 대해 별도의 검토 체크리스트를 만드세요:

이 변경이 기존 소비자에게 영향을 미치는가?
OpenAPI 사양이 업데이트되었는가?
하위 호환되지 않는 변경 사항은 버전이 지정되었는가?
오류 응답이 기존 오류 형식과 일치하는가?
새로운 엔드포인트가 예시와 함께 문서화되었는가?
다운스트림 팀에게 통지되었는가?

궤적: 자율 코딩이 향하는 곳

오늘날의 Agent Smith 대 미래의 Agent Smith

25%를 기록한 Agent Smith는 시작점에 불과합니다. 세르게이 브린은 2026년 3월 영업 타운홀에서 AI 에이전트를 "핵심 초점"이라고 불렀습니다. 도구가 개선되고, 접근 제한이 완화되며, 워크플로가 적응함에 따라 25%라는 수치는 증가할 것입니다.

다른 회사들도 유사한 시스템을 구축하고 있습니다:

Claude Code의 KAIROS (소스 코드에서 유출): GitHub 웹훅 구독 및 백그라운드 워커를 갖춘 상시 실행 데몬
GitHub Copilot 에이전트 모드: 자율 파일 편집 기능을 갖춘 다단계 코딩 작업
Amazon의 CodeWhisperer: 자동 완성에서 에이전트 기반 워크플로로 확장

업계의 추세는 분명합니다: AI 코딩 도구는 "지원자"에서 "자율 기여자"로, 그리고 "백그라운드 인프라"로 나아가고 있습니다. 몇 년 안에 질문은 AI가 API 코드를 작성하는지 여부가 아니라, 얼마나 많이 작성하는지가 될 것입니다.

API 팀이 지금 준비해야 할 것

디자인 우선은 더 이상 선택 사항이 아닙니다. 에이전트가 코드를 작성할 때 API 사양은 유일한 안정적인 아티팩트입니다. 에이전트 도입이 시급해지기 전에 지금 당장 이를 진실의 원천으로 만드세요.

계약 테스트 인프라에 투자하세요. 코드 작성자가 암묵적인 규칙을 이해하지 못할 때 단위 테스트만으로는 충분하지 않습니다. 계약 테스트는 이러한 규칙을 명시적으로 인코딩합니다.

아티팩트를 동기화하는 도구를 선택하세요. 분리된 도구(개별 API 클라이언트, 개별 테스트 러너, 개별 목 서버, 개별 문서 생성기)는 에이전트가 악용할 수 있는 불일치 기회를 만듭니다. Apidog과 같은 통합 플랫폼은 모든 것을 동기화 상태로 유지합니다.

AI 생성 코드에 대한 검토 프로세스를 구축하세요. 표준 코드 검토는 API 계약 위반을 잡아내지 못합니다. API 변경 사항에 특화된 체크리스트와 자동화된 유효성 검사를 만드세요.

Apidog을 무료로 사용하여 다음 코드 변경이 인간 개발자, Agent Smith 또는 어떤 자율 코딩 도구에서 오든 일관성을 유지하는 API 워크플로를 구축해 보세요.

button

FAQ

Google Agent Smith란 무엇인가요?

Agent Smith는 Google의 Gemini 모델 제품군과 Antigravity 플랫폼을 기반으로 구축된 Google의 내부 AI 코딩 에이전트입니다. 백그라운드에서 비동기적으로 작동합니다: 엔지니어는 작업을 할당하고, Agent Smith는 실시간 인간 상호작용 없이 코드를 작성하고, 테스트하며, 반복합니다. 2026년 3월 기준으로 Google 신규 프로덕션 코드의 25% 이상을 생성했습니다.

Agent Smith는 Google 외부에서 사용할 수 있나요?

아니요. Agent Smith는 Google 직원으로 제한되는 내부 도구입니다. Google은 공개 출시 계획을 발표하지 않았습니다. 이 기술은 Copilot Agent Mode 및 Claude Code와 유사하지만, Google의 내부 코드베이스 및 문서 시스템과 더 깊이 통합되어 있습니다.

AI 생성 코드가 API 계약을 위반할 수 있나요?

그럴 수 있습니다. AI 에이전트는 테스트를 통과하는 코드를 작성하지만, 테스트가 API 계약의 모든 측면을 다루지 못할 수 있습니다. 스키마 변경, 새로운 응답 필드, 다른 오류 형식, 행동 수정 등이 테스트를 통과하면서 다운스트림 소비자에게 영향을 미칠 수 있습니다. 계약 테스트와 디자인 우선 개발은 이를 방지합니다.

API 팀은 Agent Smith에 대해 걱정해야 할까요?

Agent Smith 자체가 Google 내부 도구이므로 직접적으로 걱정할 필요는 없습니다. 하지만 Agent Smith가 대표하는 추세에 대해서는 그렇습니다. 유사한 자율 코딩 도구(Copilot Agent Mode, KAIROS 등)가 여러분의 팀에 도달할 것입니다. 지금부터 디자인 우선 개발, 계약 테스트 및 통합 도구를 통해 API 워크플로를 준비하는 것이 자율 에이전트를 안전하게 도입할 수 있는 기반을 마련합니다.

AI 에이전트가 API를 손상시키는 것을 어떻게 방지할 수 있나요?

OpenAPI 사양을 진실의 원천으로 삼는 디자인 우선 개발을 사용하세요. additionalProperties: false를 포함한 계약 테스트를 추가하여 예상치 못한 스키마 변경을 감지하세요. 사양 유효성 검사에 따라 배포를 제한하세요. 사양, 테스트, 목(mock), 문서를 자동으로 동기화하는 Apidog과 같은 통합 플랫폼을 사용하세요.

AI 지원 코드와 AI 생성 코드의 차이점은 무엇인가요?

AI 지원 코드(Copilot 제안, Claude Code 세션)는 인간의 감독 하에 실시간으로 작성됩니다. 개발자는 각 변경 사항을 보고 승인합니다. AI 생성 코드(Agent Smith)는 실시간 인간 개입 없이 비동기적으로 생성됩니다. 개발자는 사후에 완료된 작업을 검토합니다. 이러한 차이는 검토 역학을 변화시키고 감지되지 않은 계약 위반 위험을 증가시킵니다.

AI 에이전트가 API 개발자를 대체할까요?

아닙니다. Agent Smith는 여전히 인간의 작업 정의, 코드 검토 및 배포 승인을 필요로 합니다. 2026년 3월 MIT 연구는 AI가 개발자 생산성을 향상시키지만, 인간이 제공하는 판단력, 컨텍스트 인식 및 아키텍처적 사고를 대체하지는 않는다는 것을 확인했습니다. 역할은 코드 작성에서 작업 정의, 결과물 검토 및 시스템 일관성 유지로 전환됩니다.

핵심 요점

Google의 Agent Smith는 비동기 자율 작업을 통해 신규 프로덕션 코드의 25%를 생성합니다.
이는 AI 지원 코드에서 AI 생성 코드로의 전환을 나타내며, API 팀의 검토 역학을 변화시킵니다.
자율 에이전트가 엔드포인트와 스키마를 수정할 때 API 계약 불일치가 주요 위험 요소입니다.
OpenAPI 사양을 진실의 원천으로 삼는 디자인 우선 개발은 계약 위반을 방지합니다.
엄격한 스키마 유효성 검사를 통한 계약 테스트는 단위 테스트가 놓치는 변경 사항을 감지합니다.
Apidog과 같은 통합 플랫폼은 사양, 테스트, 목(mock), 문서를 동기화하여 불일치를 방지합니다.
자율 코딩 에이전트를 향한 추세는 가속화되고 있습니다. 지금 바로 API 워크플로를 준비하세요.

25%를 기록한 Agent Smith는 시작에 불과합니다. 오늘날 에이전트 방어적인 API 워크플로를 구축하는 기업들이 내일 자율 코딩 도구를 안전하게 도입할 수 있을 것입니다.