당신이 이곳에 온 이유에 대한 짧은 답변: 한 주(province)가 약 50개의 Claude Code 자율 에이전트를 병렬로 실행하여 20시간 만에 4억 6,600만 줄의 코드를 처리했습니다. 이는 Anthropic이 2026년 7월 6일 게시물에서 설명한 내용입니다. Anthropic과 앨버타 정부의 공동 평가에 따르면, 동일한 양의 작업을 전통적인 방식으로 수행했다면 6.5년이 소요되었을 것입니다.

이어지는 기사에서는 정확히 어떤 일이 일어났는지, 어떤 수치가 검증 가능하고 어떤 수치가 독립적인 감사 없는 추정치로 남아 있는지, 그리고 마케팅 프레젠테이션을 엔지니어링 사실로 위장하지 않으면서 어떻게 자신만의 유사한 에이전트 팀을 구성할 수 있는지에 대해 다룹니다.

2026년 7월 6일에 일어난 일

핵심 내용: 2026년 7월 6일, Anthropic은 앨버타 기술 혁신부의 사례를 발표했습니다. 이것은 신제품 출시나 모델 업데이트가 아닙니다. 2025년부터 이미 시행 중인 관행이 매우 큰 규모의 실행을 보여주었다는 보고서입니다.

이날 정확히 무엇이 바뀌었는가: 사이버 보안을 위해 공공 부문에서 Claude Code 에이전트를 이 정도 규모로 적용한 구체적인 사례가 공개되었습니다. 이전까지 이러한 도입은 대개 비공개로 진행되었습니다. 이제 구체적인 수치, 담당 장관의 이름, 그리고 설명된 작업 체계가 존재합니다.

2026년 7월 6일 Anthropic의 데이터에 따르면 사실 관계는 다음과 같습니다:

Anthropic의 설명에 따르면 기반 모델은 Opus와 Sonnet입니다. 이 관행은 해당 부처에 의해 2025년에 이미 시작되었으며 27개 주 부처 전체를 아우르고 있습니다. 따라서 여기서 'Claude Code 에이전트 팀'은 일회성 실험이 아니라, 대규모 공개 실행으로 확장된 작업 프로세스입니다.

별도로 언급된 상징적인 마이크로 케이스(micro-case)는 다음과 같습니다: 25년 전에 5개월 동안 구축했던 한 보조금 프로그램의 레거시(legacy) 포털이 4~5일 만에 재구축되었습니다. 이 또한 외부 검증 결과가 아닌 게시물에 포함된 추정치입니다.

Anthropic이 인용한 네이트 글루비시(Nate Glubish) 장관의 말은 다음과 같습니다: "우리 시스템의 취약점을 검색하고 제거하기 위해 AI를 사용함으로써, 전통적인 방식으로는 수년이 걸렸을 일을 단 몇 시간 만에 완료했습니다." 이는 출처의 인용문이며, 저의 재해석이나 귀하의 결과도 이와 같을 것이라는 약속이 아닙니다.

만약 귀하도 유사한 레거시(legacy) 시스템 환경을 보유하고 있으며, 기업용 VPN이나 해외 결제 카드 없이 감사를 수행할 방법을 고민 중이라면, 모델 부분에 대해서는 아래에서 다시 다루겠습니다. 동일한 코드에 대해 서로 다른 모델 제품군(model families)의 응답을 비교하기 위해서는 하나의 잔액으로 Claude, GPT, Gemini에 통합 접근하는 방식이 유용합니다.

사실과 추정 사이의 경계는 어디인가

이 수치들을 귀하의 발표 자료에 사용하기 전에, 출처에서 밝힌 정직한 주의 사항을 전달합니다: 결과에 대한 독립적인 감사는 수행되지 않았습니다. 4억 6,600만 줄의 코드와 6.5년의 시간 절약 모두 Anthropic과 앨버타 정부의 공동 추정치입니다.

실무적인 의미는 다음과 같습니다:

• "20시간 만에 4억 6,600만 줄"은 선언된 처리량(throughput)이지, 발견된 취약점의 측정된 품질이 아닙니다.
• "통과된 95개 컨트롤(controls)"은 검사 범위를 설명하지만, 게시물에는 수동 분석 후 실제로 확인된 취약점이 얼마나 되는지는 나와 있지 않습니다.
• "4~5일 만에 포털 재구축"은 빌드 속도에 관한 것이지, 새로운 포털이 부하 테스트(load testing) 및 인수 테스트(acceptance testing)를 통과했다는 의미는 아닙니다.

이 구분을 명심하십시오. 커뮤니티에서의 사례 논의는 관심의 신호일 뿐, 품질의 증거는 아닙니다. 다음으로 저는 이 방식을 어떻게 재현할 수 있는지 보여드리겠지만, 결과에 대한 검증은 여전히 귀하의 몫입니다.

실제 Claude Code 에이전트 팀의 모습

핵심: 규모(scale)를 만들어내는 것은 교묘한 프롬프트(prompt)가 아니라 세 가지 요소입니다. 즉, 작업을 독립적인 단위로 분할하는 것, 많은 에이전트를 병렬로 실행하는 것, 그리고 각 리포지토리(repository)에 동일하게 적용되는 엄격한 컨트롤 체크리스트를 갖추는 것입니다.

앨버타(Alberta)의 체계를 반복 가능한 단계로 나누어 보겠습니다. 이는 Anthropic의 설명을 바탕으로 로직을 재구성한 것이며, 그들의 내부 지침은 아닙니다.

1. 인벤토리 조사 (Inventory). 애플리케이션과 리포지토리(repository) 목록을 수집합니다. 이번 사례에서는 1,280개의 애플리케이션과 3,400개의 리포지토리가 대상이었습니다. 목록이 없다면 병렬로 처리할 대상 자체가 없습니다.
2. 작업 단위 분할 (Slicing into work units). 하나의 단위는 하나의 리포지토리 또는 하나의 서비스입니다. 에이전트(agent)는 이를 전체 컨텍스트(context)로 가져올 수 있어야 하며, 다른 작업과 독립적으로 결과를 내놓을 수 있어야 합니다.
3. 고정된 컨트롤 세트 (Fixed set of controls). 앨버타는 각 실행 시 애플리케이션당 약 95개의 보안 컨트롤(security controls)을 검사했습니다. 핵심은 "동일한 세트"라는 점입니다. 그래야 리포지토리 간의 결과를 비교할 수 있습니다.
4. 역할 분담 (Separation of roles). "레드 팀(red team)"과 "블루 팀(blue team)" 에이전트를 배치했습니다. 한 팀은 공격 방법을 찾고, 다른 팀은 방어 체계를 점검하며 수정 사항을 제안합니다. 이를 통해 일회성 스냅샷이 아닌 지속적인 분석이 가능해집니다.
5. 병렬 실행 (Parallel execution). 약 50개의 에이전트가 동시에 작동합니다. 수년이 걸릴 작업을 단 몇 시간으로 단축시킨 것은 단일 에이전트의 속도가 아니라 바로 이 병렬성(parallelism)입니다.
6. 보고서 통합 (Reporting). 결과는 우선순위가 지정된 단일 발견 목록으로 수집되며, 이후 사람이 검토합니다.

주의할 점: 이 체계에는 자율성(autonomy)이라는 마법이 없습니다. 각 에이전트는 고정된 체크리스트(checklist)에 따라 좁고 검증 가능한 작업을 수행합니다. 규모(scale)는 모델이 "스스로 모든 것을 이해해서"가 아니라, 에이전트의 수와 작업 분할의 규율에서 나옵니다.

리포지토리당 최소 컨트롤 체크리스트

앨버타는 95개의 전체 컨트롤을 공개하지 않았으므로, 확장 가능한 소박한 시작 버전을 다음과 같이 제시합니다:

• 코드 및 커밋 히스토리에 하드코딩된 (hardcoded) 비밀번호 및 키;
• 알려진 취약점이 있는 오래된 의존성 (dependencies);
• 서비스 경계에서의 입력 데이터 검증 (validation) 부재;
• 안전하지 않은 SQL 및 템플릿 처리;
• 권한 제한 없는 파일 및 명령 실행 접근;
• 민감한 데이터의 로깅 (logging);
• 엔드포인트의 취약하거나 누락된 인증 (authentication).

각 항목은 명확한 출력 형식을 가진 에이전트용 개별 지침입니다. 통일된 형식은 매우 중요합니다. 형식이 없다면 3,400개의 보고서를 취합하는 과정은 이 프로젝트를 시작한 목적 자체를 무색하게 만드는 수작업이 되어버릴 것입니다.

해외 카드로 인증 및 실행을 설정하는 방법

핵심: 에이전트에는 API 키와 주소가 필요합니다. 만약 당신이 러시아에 있고 VPN이나 해외 카드로 번거로운 과정을 거치고 싶지 않다면, 키와 base_url만 변경하여 동일한 코드와 SDK를 그대로 사용할 수 있습니다.

Anthropic은 자사 인프라를 활용한 정부 사례를 설명하고 있습니다. 러시아 독자들을 위해 솔직하게 말씀드리자면, 체크리스트에 따른 병렬 에이전트라는 접근 방식 자체는 벤더 (vendor)에 의존하지 않습니다. 오직 에이전트가 호출하는 API 엔드포인트 (endpoint)에만 의존할 뿐입니다.

아래는 Python을 사용한 간결한 예시입니다. 파일 하나를 가져와 하나의 컨트롤 항목을 실행하는 단일 리뷰 에이전트를 보여줍니다. 비밀번호는 환경 변수 (environment variables)로 분리되었으며, 키는 코드에 저장되지 않습니다.

import os
from anthropic import Anthropic

...
```

단일 에이전트가 아닌 명령 체계를 구축하려면 review를 풀 (pool)로 감싸면 됩니다. 표준 라이브러리를 이용한 가장 간단한 병렬 처리 방식은 다음과 같습니다:

import concurrent.futures as cf

repos = ["repo_a/main.py", "repo_b/utils.py"]  # 리스트 플레이스홀더 (PLACEHOLDER)
...

작은 max_workers 값과 짧은 리스트로 시작하세요. 앨버타의 약 50개 에이전트는 대규모 파크(park)에서 최적화된 프로세스의 결과물이지, 초기 설정값이 아닙니다. 먼저 출력 형식이 안정적이고 발견된 내용이 허구(hallucination)가 아닌지 확인한 후에 병렬성 (parallelism)을 높이세요.

에이전트에 어떤 모델을 설정해야 하며 비용은 얼마나 드는가

핵심: 체크리스트를 대량으로 실행할 때는 가장 똑똑한 모델보다 저렴하고 빠른 모델이 더 중요합니다. 비싼 모델은 복잡한 발견 사항을 처리하거나 재검증할 때를 위해 아껴두어야 합니다.

Anthropic의 설명에 따르면, 앨버타는 Opus와 Sonnet을 사용했습니다. 논리는 명확합니다. Sonnet은 볼륨을 감당하고, Opus는 더 깊은 분석이 필요한 곳에 투입합니다. 이는 여러분에게도 합리적인 패턴입니다.

역할 선택을 위한 실무 테이블입니다. 비용 수치는 의도적으로 기재하지 않았습니다. 요금은 변동되며, 앨버타 관련 출처에도 명시되어 있지 않기 때문입니다. 실행 시점에 제공업체의 최신 가격표를 확인하세요.

러시아 팀을 위한 별도의 실용적인 팁: 만약 서로 다른 모델 제품군(model families)이 동일한 취약점을 어떻게 바라보는지 비교하고 싶다면, Claude, GPT, Gemini, DeepSeek, Qwen을 하나의 API와 하나의 채팅창을 통해 실행하는 것이 편리합니다. 두 번째 SDK를 설치하거나 에이전트를 다시 작성할 필요 없이, 키(key)와 base_url만 변경하면 됩니다. 결제는 루블화로 러시아 은행 카드, SBP(Faster Payments System) 또는 계좌 이체를 통해 가능하며, VPN이나 해외 카드 없이도 작동합니다. 법인의 경우 계약서, 인보이스 및 정산 서류를 제공합니다. 이것은 모델 자체를 대체하거나 GigaChat이 되는 것이 아니라, 모델 간의 비교나 라우팅(routing)이 필요할 때 호환 가능한 API를 통해 해외 모델에 접근할 수 있는 방법입니다.

오류를 포착하는 방법 및 n8n으로 구축할 가치가 있는가

핵심: 대규모 실행은 모델이 아니라 데이터와 형식(format) 때문에 실패합니다. 쓰레기 출력(garbage output), 제한 사항(limits), 빈 저장소(empty repositories)에 대한 처리를 미리 설계하세요.

가장 먼저 나타날 전형적인 실패 모드(failure modes)는 다음과 같습니다:

• 에이전트가 JSON을 반환하지 않음. 모델이 때때로 구조 주변에 설명을 추가합니다. 전체 프로세스를 중단시키지 말고, 블록을 추출하려는 시도와 함께 '수동 검토 대상으로 표시'하는 폴백(fallback) 전략을 사용하여 항상 파싱하세요.
• 파일이 너무 커서 컨텍스트(Context)에 들어가지 않음. 함수 단위나 크기 단위로 자르세요. 그렇지 않으면 유효해 보이지만 잘려 나간 분석 결과를 얻게 됩니다.
• 오탐(False Positives). 에이전트는 다른 계층에서 차단된 사항을 취약점으로 선언하는 것을 좋아합니다. 따라서 앨버타에는 별도의 검토 역할이 있으며, 최종 목록은 사람이 읽습니다.
• 요청 제한(Rate Limit)에 부딪힘. 50개의 병렬 에이전트를 사용할 경우 빠르게 속도 제한(rate limit)에 도달하게 됩니다. 백오프(backoff)와 큐(queue)를 추가하세요.
• 리포지토리 간 발견 사항의 중복. 동일한 라이브러리 문제가 수백 곳에서 나타날 수 있습니다. 발견된 내용의 시그니처(signature)를 기준으로 중복을 제거하면 사람의 시간을 절약할 수 있습니다.

n8n 및 유사한 자동화 플랫폼에 대하여. 실행 오케스트레이션(orchestration), 보고서 수집 및 알림은 그곳에서 편리하고 시각적으로 구성할 수 있습니다. 하지만 경계를 기억하세요: 자동화 플랫폼은 단계를 조직할 뿐, 단계를 대체하지 않습니다. 모델 호출, 체크리스트 및 발견 사항 검증 자체는 여전히 당신이 작성해야 합니다. 만약 HTTP Request 노드에서 직접 모델을 호출하고 싶다면, 위 코드와 동일한 논리로 호환 가능한 base_url과 환경 변수의 키를 삽입하면 됩니다.

이 케이스가 해결하지 못하는 것

앨버타의 사례가 증명하지 못하거나 제공하지 않는 것들에 대한 솔직한 목록입니다: