AI 역량은 균일하지 않고 들쭉날쭉합니다. 그렇다면 질문은 이것입니다: 여러분이 선호하는 도구(Codex, Claude Code...)가 실제 클라우드 작업에서는 어떤 성과를 보일까요?

어떤 도구는 코딩 벤치마크에서 최고 점수를 기록하고도 존재하지 않는 리소스를 환각(hallucinate)할 수 있습니다. 코딩, 컴퓨터 사용(computer use), 일반 추론을 위한 기존의 벤치마크는 존재하지만, 클라우드 팀이 실제로 위임하는 작업인 클라우드 관리 작업(cloud management tasks)을 위한 벤치마크는 아직 없습니다.

우리는 그 벤치마크를 구축하고 있습니다. 현재 Codex와 Claude Code가 테스트 중이며, 다른 도구들도 파이프라인에 있습니다. Task 1은 AWS에서 실행됩니다. 템플릿은 클라우드 불가지론적(cloud-agnostic)이며, 향후 Azure와 GCP 재현(replays)이 이어질 예정입니다. 이 포스트는 방법론을 설명하며, 다음에 무엇을 다룰지에 대해 여러분의 의견을 구하는 공개적인 초대장입니다.

방법론 (The methodology)

IaC가 정답지입니다. 우리는 리소스를 구축하기 위해 Terraform을 사용하므로, 그 출력값(outputs)이 실제 정답(ground truth)이 됩니다. 즉, 발견되어야 할 정확한 리소스 ID와 플래그가 지정되지 않아야 할 리소스 ID를 제공합니다. 인간의 라벨링이 필요 없고, 드리프트(drift)가 발생할 일도 없으며, 누구나 동일한 스택을 배포하여 결과를 재현할 수 있습니다.

환경은 두 가지 축을 기준으로 다양합니다.

1. 규모(Size): 콘솔 페이지 하나로 읽을 수 있는 소규모 계정, 중규모, 그리고 수천 개의 활성 종속성(dependencies) 사이에 신호가 숨겨져 있는 대규모 계정.
2. 이력(History): 완전히 IaC로 관리되는 그린필드(greenfield) 계정과, 수년간의 드리프트(drift)와 불완전한 태깅(tagging)이 쌓인 브라운필드(brownfield) 계정. 소규모 그린필드 환경에서만 성능을 발휘하는 도구는 큰 성과를 증명한 것이 아닙니다. 실제 운영 중인 클라우드는 대규모이며 브라운필드입니다.

에이전트는 격리되어 있으며, 검증 가능합니다. 에이전트는 프롬프트, 임시 읽기 전용 자격 증명(read-only credentials), 그리고 해당 세션에 필요한 일시적 권한(ephemeral permissions)만을 가진 빈 컨테이너에서 실행됩니다. 매 실행 시 CloudTrail을 사용하여 에이전트의 활동을 확인합니다.

실행은 반복됩니다. 네트워크 문제나 일시적인 모델 오류를 고려하여 동일한 프롬프트로 3회 실행합니다.

오답은 분류됩니다. 발견됨(Found), 놓침(Missed), 사용 중이지만 플래그가 지정됨(Flagged-though-in-use), 그리고 조작됨(Fabricated): 계정 어디에도 존재하지 않는 ID입니다. 각 항목은 원인과 해결책이 다르기 때문에 별도로 점수를 매깁니다. 모든 조작 후보는 먼저 실제 계정과 대조하여 검증합니다. 우리가 심지 않은 실제 리소스로 판명되는 "환각 (Hallucination)"은 에이전트의 실패가 아니라 고정된 버그 (Fixture bug)입니다. 저희도 직접 겪어봤기에 알고 있습니다. 그 이야기는 이 시리즈의 일부입니다.

첫 번째 작업

우리는 모든 클라우드 팀이 관심을 가질 만한 작업인 AWS에서의 낭비 요소 발견 (Waste discovery)을 선택했습니다.

Terraform은 고립된 리소스 (Orphans: 연결되지 않은 EBS 볼륨, 연결되지 않은 Elastic IP, 연결되지 않은 ENI, 참조되지 않는 보안 그룹, 경로 테이블이 가리키지 않는 NAT 게이트웨이)를 플래그가 지정되어서는 안 되는 사용 중인 방해 요소 (Distractors)와 함께 배치합니다.

낭비 요소가 첫 번째인 이유는 실제 비용 문제이며 정확하게 점수를 매기기 쉽기 때문입니다. 하지만 위의 다른 작업들은 이에 의존하지 않습니다. 보안 감사 (Security audit), 비용 포렌식 (Cost forensics), 아키텍처 재구성 (Architecture reconstruction) 모두 동일한 템플릿에 해당합니다: IaC로 시드(Seed)를 심고, 크기와 이력을 다양화하며, 에이전트를 포함시키고, 결과를 분류합니다.

이 시리즈는 작업이 진행된 순서를 따릅니다: 먼저 모든 것이 공개된 테스트 환경 (Terraform, 프롬프트, 스코어러, 로우 로그) 자체를 다루고, 그다음 결과와 시사점을 다룹니다.

의견을 들려주세요

이 방법론의 약점은 무엇인가요? 브라운필드 고정 환경 (Brownfield fixture)이 실제 계정과 유사해지려면 무엇이 필요할까요? 어떤 방해 요소가 에이전트나 사람을 가장 확실하게 속일 수 있을까요? 이 작업 다음에 어떤 작업이 템플릿에 포함되어야 하며, 어떤 클라우드가 첫 번째 재현 대상이 되어야 할까요?

공개 사항: 저는 클라우드 툴링 (Cloud tooling) 분야에서 일하고 있습니다. 이 벤치마크는 설계 단계부터 특정 벤더에 중립적이며, 결과가 좋지 않더라도 그대로 공개할 것입니다.