AI 인프라 자동화 #1 에이전트가 일을 할 수 있는가

인프라 팀 업무의 상당수가 Slack에서 시작된다.

• 비용 리포트를 만들고, 이상 징후를 분석해서 댓글을 단다
• 파라미터 추가 요청이 오면 Terraform으로 반영한다
• 배포 현황을 집계해서 주간 리포트를 만든다
• 모니터링 알림이 뜨면 관련 지표를 모아서 공유한다

한 건에 15~30분이지만, 매일 2~3건씩 반복되면 주 5~10시간을 차지한다. 그보다 더 큰 문제는, 사람은 반복에 지치면 놓친다는 것이다. 놓친 이상은 발견될 때까지 조용히 누적된다.

이 업무들의 공통점이 있다. Slack에서 시작하고, 여러 도구(AWS CLI, Terraform, Jira, Datadog)를 조합해야 하고, 판단이 필요하다. 단순 스크립트로는 안 된다.

기술적 제약도 있었다. 프로덕션 AWS 계정에 접근하므로 잘못된 명령 하나가 서비스에 영향을 줄 수 있다. Slack, AWS, Jira, Datadog 등 이질적인 외부 서비스를 하나의 흐름으로 엮어야 한다. 무엇보다 LLM은 비결정론적이다. 같은 입력에 다른 출력이 나올 수 있고, 할루시네이션이 발생할 수 있다. 이 불확실성을 통제하면서 프로덕션에 올리려면, 별도의 안전장치를 설계해야 했다.

Claude Agent SDK와 MCP(Model Context Protocol)를 활용해서, 이러한 제약을 보완하면서 Slack 채널의 인프라 업무를 자동화하는 에이전트 시스템을 만들기로 했다.

flowchart TB
    subgraph 트리거
        Cron[스케줄러<br/>APScheduler]
        Event[Slack 이벤트<br/>Socket Mode]
    end

    subgraph 시스템[" "]
        direction LR
        subgraph 외부도구[" "]
            subgraph MCP[MCP 서버]
                S[Slack]
                J[Jira]
                D[Datadog]
            end
            subgraph CLI[명령어 실행]
                AWS[AWS CLI]
                Local[로컬 명령어]
            end
        end
        subgraph 코어
            subgraph 트리아지
                KW[키워드 필터] --> Haiku[Haiku 3.5<br/>분류]
            end
            Pre[Python 전처리<br/>API 호출 · 비용 합산] --> Agent[에이전트<br/>Claude Agent SDK<br/>Opus 4.5]
            Haiku --> Agent
            subgraph 저장소
                Log[실행 로그]
                Transcript[트랜스크립트]
            end
            Agent --> 저장소
            Agent --> Safe[SafeBash 필터]
        end
    end

    Cron --> Pre
    Event --> KW
    Agent --> MCP
    Safe --> CLI

    style 트리거 fill:#e8f4fd,stroke:#4a90d9
    style 시스템 fill:none,stroke:none
    style 외부도구 fill:none,stroke:none
    style 코어 fill:#e8f8e8,stroke:#5ba85b
    style 저장소 fill:#f5f5f5,stroke:#999999
    style MCP fill:#e8d5f5,stroke:#7b2fbe
    style CLI fill:#e0f2f1,stroke:#26a69a

MCP로 Slack, Jira, Datadog을 에이전트에 연결하고, AWS CLI는 SafeBash 필터를 통해 실행한다. 에이전트가 Slack에서 메시지를 읽고, 필요한 데이터를 조회하고, 분석 결과를 다시 Slack 스레드에 쓴다.

첫 번째 자동화 대상으로 비용 분석을 골랐다. 가장 반복적이고, 판단이 필요하며, 자동화 효과가 클 것 같았다. 기존에 Lambda로 일일 비용 리포트를 Slack에 올리는 구조가 있었고, 이 리포트를 AI가 읽고 분석하는 에이전트를 만든 뒤, 주간·월간으로 확장했다.

위 다이어그램의 구조는 처음부터 있었던 게 아니다. Claude Code와 대화하면서 요구사항을 하나씩 구체화하고, 점진적으로 잡아간 결과다.

Human: 주기적으로 실행 가능한 형태의 컨트롤 프로세스가 있고 거기에 agent들을 등록하면 되겠지? 로컬에서 운영하더라도 나중에 그대로 git 올려서 서버에 내려서 쓸 수 있는 구조로

AI: YAML 설정 + APScheduler + Agent SDK 구조로 가겠습니다. 에이전트별 스케줄과 MCP 서버를 YAML에 정의하고, 코드 변경 없이 에이전트를 추가하는 구조입니다.

구조가 잡히자 바로 다음 질문이 나왔다. 프로덕션 AWS 계정에 연결되는 에이전트가 잘못된 명령을 실행하면?

Human: 에이전트들이 읽기 모드로만 동작하게 안전장치 넣고 싶은데

AI: 3중 안전장치로 가겠습니다.

레벨	내용
1. YAML	allowed_tools로 도구 제한
2. 코드	safe_bash.py로 명령어 패턴 검사
3. 프롬프트	에이전트 지시사항에 “AWS는 읽기만” 명시

프롬프트 하나에만 의존하면 우회될 수 있으니, 설정·코드·프롬프트 3개 레이어로 겹치는 구조다. 이렇게 잡은 아키텍처 위에서 첫 에이전트를 만들었다.

기존에 Lambda가 매일 AWS 비용을 집계해서 Slack에 리포트를 올리는 구조가 있었다. 숫자는 올라오는데, 누군가가 그걸 열어보고 “이거 정상인가?” 판단해야 했다. 놓치는 날이 생기면 그날의 비용 급증이 다음 날엔 기준선이 되어버린다. 잡지 못한 낭비는 매일 반복되며 쌓여간다.

이 리포트를 AI가 읽고 분석하면 어떨까?

Claude Agent SDK로 Slack 채널의 비용 리포트를 읽고, 전일 대비 변동을 분석하고, 이상 징후 탐지 시 담당자를 멘션하는 에이전트를 만들었다. 일일 분석이 안정된 후, 주간 보고서는 Lambda 없이 Agent SDK + MCP만으로 구성했다. 이 글은 그 과정에서 만난 할루시네이션, 산술 오류, 오탐을 프롬프트 반복으로 해결해 나간 기록이다.

프롬프트에 MSP 비용 API 엔드포인트와 인증 방법을 넣어주고, 4개 계정의 비용 조회부터 분석, Slack 리포트 작성까지 에이전트가 전부 수행하게 했다. 돌려봤더니 리포트가 올라왔는데, 뭔가 이상했다.

Human: RI 비용이 아니고 S3 작업이 주 비용이라고? 이상한데?? 그리고 Glue는 항상 사용하던 건데 갑자기 사용한다고?? 결과 정확한지 크로스체크 작업 실행

AI (재조회 후): 크로스체크 완료했습니다. 제가 처음 리포트에서 완전히 잘못 분석했습니다.

• S3가 주 비용이라고 했는데? → 틀림. 변동 미미
• Glue가 신규라고 했는데? → 틀림. 원래 계속 사용하던 서비스
• 실제 원인인 RDS 급감($2,745 감소)은 언급조차 안 함

왜 틀렸는지 분석을 요청했다.

Human: 지금 에이전트가 틀린 원인 분석

AI: 왜 틀렸는지 분석해봤습니다.

1. 데이터 조회 불완전 — 필요한 API 호출 8개(4계정 × 2기간) 중 1개만 조회
2. 할루시네이션 — 조회하지 않은 데이터를 추측으로 채움
3. 검증 없이 발송 — 불완전한 데이터로 바로 리포트 작성

8개 호출해야 하는데 1개만 성공하고, 나머지 7개는 API 실패였다. 문제는 에이전트가 실패한 7개를 재시도하는 대신, 그럴듯한 가짜 데이터를 만들어서 리포트를 완성한 것이다.

Human: 프롬프트에 검증 규칙을 넣어봐. API 8개 전부 성공해야만 리포트 작성하게 하고, 데이터가 불완전하면 리포트를 아예 만들지 마

AI (검증 규칙 추가 후):

## 데이터 검증 규칙 (필수!)
1. 필수 API 호출: 8개 (4계정 × 2기간)
2. 모든 API 호출 성공 확인 후 리포트 작성
3. 조회한 데이터만 사용 (추측/가정 절대 금지)

다시 테스트. API 8개 전부 호출했다. 그래도 숫자가 맞지 않았다.

Human: CloudFront $0.07 이것도 이상해 너무 낮아 값이, ElastiCache도 너무 낮아 이상해. RDS는 RI만 $3,000일 텐데? 값이 이상해 정확한지 정정해줘

AI (직접 재조회 후): 에이전트가 서비스별 합산을 완전히 잘못 계산했습니다!

서비스	실제 합산	에이전트 계산	결과
CloudFront	$303.32	$0.07	완전 틀림
RDS	$240.68	$79.48	틀림
ElastiCache	$90.33	$0.00	완전 틀림

API는 다 호출했는데, 4개 계정의 동일 서비스 비용을 합산하는 산술 연산을 틀렸다.

프롬프트에 “4개 계정의 동일 서비스를 합산하라"는 규칙을 추가하고 다시 테스트.

AI (3번째 테스트 결과):

서비스	실제 합산	에이전트	결과
CloudFront	$303.32	$303.33	정확 ✓
RDS	$240.68	$0.00	틀림 ✗
EC2	$955.22	$242.53	틀림 ✗

Human: 프롬프트로 산술 연산을 정확하게 만드는 건 한계가 있는 것 같아. API 호출이나 계산은 Python이 하고, AI는 분석만 하게 구조로 구성할 수 있어?

AI: 좋습니다! 계산 로직을 코드로 분리하겠습니다.

1. Python이 MSP 비용 API 호출 → 8개 데이터 조회
2. Python 코드로 서비스별 합산 계산
3. 계산된 결과를 프롬프트에 포함
4. 에이전트는 계산된 데이터로 분석+리포트만 작성

아키텍처를 바꿨다.

변경 전: 에이전트 → API 호출 → 계산 → 분석 → 리포트
변경 후: Python → API 호출 → 계산 → 에이전트 → 분석 → 리포트

Python이 API를 호출하고 합산한다. 에이전트는 계산된 데이터를 받아서 분석과 리포트만 쓴다. 실행 시간은 4분에서 27초로, 비용은 $1.87에서 $0.22로 줄었고, 할루시네이션은 사라졌다. 결정론적(Deterministic) 작업과 비결정론적(Non-deterministic) 작업을 분리한 것이다. 같은 입력이면 항상 같은 결과가 나와야 하는 API 호출과 산술 연산은 코드가 하고, LLM은 분석과 판단에만 집중한다. 이후 만든 모든 분석 에이전트(주간, 월간, Datadog)에 동일한 패턴을 적용했다.

비용 분석 에이전트는 데이터를 읽고 리포트를 쓰는, 읽기 전용 업무다. 다음 단계로 실제 인프라를 변경하는 에이전트를 만들기로 했다.

첫 대상은 Parameter Store 등록이다. Slack에서 “이 파라미터를 dev 환경에 추가해줘"라는 요청을 받으면, Terraform IaC 파일을 수정하고, apply하고, git push까지 하는 작업이다. 한 건에 15분, 반복적이고 정형화된 업무다.

비용 분석은 읽기 전용이라 잘못돼도 리포트를 다시 쓰면 된다. 하지만 이번에는 다르다. 에이전트가 프로덕션 인프라를 변경한다. 잘못되면 서비스에 영향을 준다.

프롬프트에 정보 수집 → 승인 → 실행 흐름을 넣고 테스트 채널에서 첫 실행을 했다. 에이전트는 사용자에게 이렇게 응답했다:

정리하면 이렇게 되는겨:

서비스:    billing-api
파라미터:  test.name
값:        1111111
환경:      dev

*작업 계획*
1. Jira 티켓 생성 (DEV 프로젝트)
2. IaC 리포 git pull
3. local.tf에 블록 추가
4. terraform apply
5. 커밋 & 푸시
6. 완료 댓글

이대로 진행해도 되겠쥬?

문제가 보였다. 내부 절차 전체를 사용자에게 노출하고, 사용자에게 직접 승인을 구하고 있었다.

Human: 작업 계획을 유저에게 공유 하지마. 진행 여부 체크를 하는 플로우를 넣기로 했잖아

작업 계획을 사용자에게 보여주지 않도록 수정했다. 그런데 승인 구조에도 문제가 있었다. 에이전트가 요청한 사람에게 직접 “진행할까유?“라고 묻고 있었다. 요청자가 스스로 승인하는 구조는 승인 게이트가 아니다.

Human: 작업 승인 권자를 @으로 호출해서 승인 여부를 물어서 생성하라고 해야지만 진행해

Human: @infra 로 하자

이 피드백으로 3가지가 동시에 바뀌었다:

1. 내부 절차 비공개: 작업 계획(Jira, git, terraform)을 사용자에게 노출하지 않음
2. 승인 라우팅: 요청자가 아닌 @infra 그룹에게 승인 요청
3. “절대 하지 말 것” 규칙 신설: “이대로 진행해도 되겠쥬?” 같은 직접 확인을 금지

수정 후 에이전트의 응답은 이렇게 바뀌었다:

확인 완료했쥬! 정리하면 이렇겨:

서비스:    billing-api
파라미터:  test.name
값:        1111111
환경:      dev
경로:      /dev/billing-api/test.name

@infra 승인 부탁드려유!

작업 계획이 사라지고, 승인 요청이 인프라 팀으로 갔다. 사용자는 요청만 하면 되고, 내부 절차는 모른다.

수정된 에이전트를 운영하던 중, 테스트로 “지금 등록된 파라미터 스토어 리스트 줄 수 있어?“라고 물었다. 에이전트는 IaC 파일을 읽어서 전체 파라미터 목록을 덤프했다.

Human: 사용자가 할 수 있는 동작이 무한이 될 수 있는게 걱정되. 파라미터 스토어 등록과 관련된 정보만 수집하고, 새로운 정보를 주지 않아야 하고, 가장 중요한건 어떤 변경도 하면 안된다는거야

이 피드백으로 “범위 제한” 규칙이 추가됐다:

## 범위 제한
이 에이전트의 역할은 파라미터 스토어 등록 정보 수집 → 승인 요청까지입니다.

### 승인 전 금지 동작 (절대 금지)
- 파일 시스템 변경
- Terraform / Git 명령 실행
- Jira 티켓 생성
- 내부 데이터(local.tf 내용, 파라미터 목록) 사용자에게 공유
- 등록과 무관한 질문에 답변

시스템 프롬프트는 3,328자에서 10,076자로 3배 늘었다. 늘어난 건 기능이 아니라 제약 조건이다. 최소 권한 원칙(Principle of Least Privilege)을 프롬프트에 적용한 것이다. 할 수 있는 것을 나열하는 대신, 하면 안 되는 것을 명시했다. 에이전트의 자유도를 제한할수록 안전해진다.

위에 나온 과정 자체가 검증이다. 에이전트 출력을 그대로 믿지 않고, 실제 데이터와 대조해서 숫자가 맞는지 확인했다. 아키텍처 변경 후에도 동일한 크로스체크를 반복해서 정확성을 확인했다.

에이전트가 AWS CLI를 실행하므로 안전 필터(SafeBash)를 만들었다. 읽기 전용 명령만 화이트리스트로 허용하고 나머지는 차단하는 구조다.

이 필터를 신뢰하기 전에, AI에게 공격을 시켰다. 안전장치를 만든 AI가 아닌 다른 세션에서, “이 필터를 우회할 수 있는 방법을 찾아라"는 Red Teaming을 수행한 것이다.

Human: 지금 코드 봤을 때 더 개선해야 할 거 있나?

AI (14개 파일 전체 리뷰 후): Critical 6건, High 6건, Medium 4건 발견.

#	이슈	위치	설명
7	SafeBash 파이프 우회 가능	safe_bash.py:55	`

Human: #7 우선 처리

AI (safe_bash.py 분석 후): 현재 패턴의 우회 가능한 공격 벡터 6가지:

공격 패턴	우회 이유
`	/bin/bash`
`	env rm file`
`	tee secret.txt`
aws ce get-cost ; /bin/sh	; 체이닝 미차단. 화이트리스트가 시작만 확인하므로 뒤에 뭘 붙여도 통과

마지막이 가장 위험했다. ;은 쉘에서 “앞 명령이 끝나면 뒤 명령도 실행하라"는 의미다. aws ce get-cost ; rm -rf /처럼 화이트리스트에 등록된 명령 뒤에 ;으로 위험한 명령을 붙이면, 필터는 앞부분만 보고 통과시키고 뒤의 명령도 함께 실행된다. 명령 체이닝 차단(; && ||), 절대경로 우회 차단, 추가 위험 명령(tee, xargs, env) 패턴을 반영해서 수정했다.

프로덕션 채널에 바로 연결하지 않았다. 3단계 Staged Rollout(단계적 배포)으로 Blast Radius(장애 영향 범위)를 점진적으로 넓혔다.

먼저 격리된 평가 환경(Isolated Evaluation Environment)인 테스트 전용 채널에서 개발자 1명이 반복 검증했다. 이 Sandbox 단계에서 엣지 케이스와 의도하지 않은 동작을 찾아내고 수정하는 사이클을 반복했다. 다음으로 소수 인원이 참여하는 내부 채널로 이동하는 Canary 단계를 거쳤다. 실제 사용자의 자연어 입력과 예상치 못한 요청 패턴을 확인했다. 검증이 완료된 에이전트만 프로덕션 타겟 채널에 연결했다.

모든 에이전트 실행은 두 가지로 기록된다. 애플리케이션 로그는 트리아지 판정, 에이전트 선택, 실행 시간, 비용 등 시스템 수준의 동작을 기록하고, JSON 트랜스크립트는 에이전트가 어떤 도구를 호출했고, 어떤 판단을 내렸고, 최종 출력이 무엇이었는지를 기록한다. 두 로그를 조합하면 전수 감사(Audit)가 가능하다. 이 기록은 샌드박스뿐 아니라 프로덕션에서도 동일하게 동작한다. 트랜스크립트를 리뷰하면서 의도하지 않은 동작을 잡아내고, 프롬프트를 수정하는 사이클을 반복했다.

에이전트가 안전하게 동작하려면, 잘못된 메시지가 에이전트를 호출하지 않아야 한다. Slack 채널의 모든 메시지가 에이전트를 트리거하면 오작동과 비용 낭비가 발생한다.

2단계 트리아지로 이를 차단한다:

flowchart LR
    Msg[Slack 메시지] --> KW{키워드 필터}
    KW -->|매칭 없음| Drop1[무시]
    KW -->|매칭| Haiku{Haiku 3.5 분류}
    Haiku -->|대화/잡담| Drop2[무시]
    Haiku -->|인프라 요청| Agent[에이전트 실행]

    style Msg fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
    style KW fill:#fef3c7,stroke:#f59e0b,color:#78350f
    style Haiku fill:#fef3c7,stroke:#f59e0b,color:#78350f
    style Drop1 fill:#f3f4f6,stroke:#9ca3af,color:#4b5563
    style Drop2 fill:#f3f4f6,stroke:#9ca3af,color:#4b5563
    style Agent fill:#d1fae5,stroke:#10b981,color:#064e3b

1. 키워드 필터 (결정론적): “파라미터”, “비용”, “배포” 등 사전 정의된 키워드로 1차 필터링. 매칭되지 않는 메시지는 즉시 무시한다.
2. Haiku 3.5 분류 (비결정론적): 키워드에 매칭된 메시지를 경량 모델(Haiku)이 분류한다. “이 메시지가 실제로 인프라 요청인지, 단순 대화인지” 판단해서 적절한 에이전트를 결정하고, 에이전트 호출에 필요한 사전 컨텍스트를 준비한다.

Haiku에는 외부 도구(Slack, Jira, Datadog)를 연결하지 않았고(mcp_servers={}), 에이전틱 루프를 1회로 제한했다(max_turns=1). 멀티스텝 작업이 불가능하고, 분류와 라우팅만 수행하는 구조다. 이 구조의 부수적 이점은 비용과 응답 속도다. 트리아지 단계에서 대부분의 메시지가 걸러지기 때문에, 고비용 모델(Opus, 건당 약 $0.5)은 실제 인프라 요청에만 투입된다. 분류 자체는 경량 모델인 Haiku(건당 약 $0.0002)로 처리해서 비용을 아끼고, 응답도 1초 이내로 빠르다.

에이전트가 읽기 전용 분석을 넘어 변경 작업(Parameter Store 등록, K8s 서비스 생성 등)을 수행하려면, 사람의 명시적 승인이 필요하다. 에이전트가 수립한 실행 계획을 사람이 검토하고, 승인해야만 실제 변경이 이루어진다. 에이전트의 판단이 틀렸거나 의도와 다른 계획을 세웠을 때, 실행 전에 차단할 수 있는 마지막 방어선이다.

sequenceDiagram
    participant User as 사용자
    participant Agent as 에이전트
    participant Gate as 승인 게이트
    participant Approver as 승인권자

    User->>Agent: "파라미터 추가해줘"
    Agent->>Agent: 분석 후 실행 계획 수립
    Agent->>Gate: [APPROVAL_REQUIRED] 블록 출력
    Gate->>Gate: 스레드 상태 → awaiting_approval
    Gate->>Approver: Slack 스레드에 계획 게시
    Approver->>Gate: "승인"
    Gate->>Gate: 승인권자 검증 (user_id 확인)
    Gate->>Agent: 승인된 계획으로 재실행
    Agent->>User: 실행 결과 보고

동작 방식:

1. 에이전트가 변경이 필요하다고 판단하면 [APPROVAL_REQUIRED] 블록을 출력한다
2. 시스템이 이를 감지하고 스레드 상태를 awaiting_approval로 전환한다
3. 지정된 승인권자만 “승인” 또는 “거부"를 입력할 수 있다
4. 승인되면 에이전트가 이전에 수립한 계획대로 작업을 실행한다

읽기 전용 작업(비용 분석, 리포트 작성 등)은 승인 없이 바로 실행된다. 승인 게이트는 변경 작업에만 적용되며, 승인권자의 user_id를 검증하기 때문에 권한 없는 사용자가 승인을 우회할 수 없다.

이 글에서 다룬 건 비용 분석과 파라미터 등록 두 가지지만, 같은 구조로 7개 이상의 에이전트가 프로덕션에서 운영 중이다.

핵심 과제는 반복 업무를 자동화하면서 LLM의 불확실성을 통제하는 것이었다. 할루시네이션은 결정론적 작업(API 호출, 계산)을 코드로 분리해서 해결했고, 무분별한 실행은 트리아지와 승인 게이트로 막았다. 격리된 환경에서 충분히 검증한 뒤 프로덕션에 올렸고, 모든 실행은 감사 로그로 남긴다.

주 5~10시간이던 반복 업무가 자동으로 처리되고, 사람은 승인과 예외 케이스에만 개입한다. 반복 작업에서 번 시간은 아키텍처 개선이나 장애 예방 같은, 더 깊이 고민해야 하는 일에 쓸 수 있게 됐다.

에이전트 시스템에 필요한 핵심 기능은 세 가지였다:

1. Tool Use (도구 호출): 에이전트가 외부 도구를 직접 호출할 수 있어야 한다. Slack 메시지를 읽고, AWS CLI로 데이터를 조회하고, 다시 Slack에 결과를 쓰는 과정을 하나의 흐름에서 수행해야 한다.
2. MCP 지원 (외부 서비스 네이티브 연동): Slack, Jira, Datadog 같은 외부 서비스를 API 래핑 없이 네이티브로 연결할 수 있어야 한다. 서비스가 추가될 때마다 연동 코드를 작성하면 유지보수 부담이 커진다.
3. 긴 컨텍스트 (맥락 유지): 비용 데이터 조회 → 계정별 비교 → 이상 징후 탐지 → 리포트 작성까지, 멀티스텝 분석에서 앞선 맥락을 잃지 않아야 한다.

초기에는 Cursor에서 여러 모델을 써봤는데, 개인적으로 Opus 4.5의 신뢰도가 가장 높았다. 이 모델을 더 자유롭게 쓸 수 있는 Claude Code 환경으로 옮겼고, n8n도 고려했지만 AI와 대화하면서 만들어가는 방식에 맞지 않아서 Claude Agent SDK를 선택했다. Agent SDK + MCP 조합은 위 세 가지 기능을 모두 충족하고, 로컬 업무 환경을 에이전트로 그대로 이식할 수 있으며, API를 별도 구매하지 않아도 계정 사용량 안에서 바로 써볼 수 있었다.

• 종합 성능: llm-stats.com 기준 241개 모델 중 종합 1위(2026년 2월). 코딩, 대화, 소프트웨어 엔지니어링 전 영역에서 상위권이다
• 충분한 컨텍스트: 200K 토큰 컨텍스트로, Slack으로 인입되는 인프라 업무를 조회부터 분석, 리포트 작성까지 맥락을 잃지 않고 처리한다
• 지시 준수: IFEval 기준 프론티어 모델 간 차이는 크지 않지만, 프롬프트에 명시한 분석 기준과 판단 임계값을 충분히 신뢰할 수준으로 따른다
• 에이전틱 유연성: n8n 같은 워크플로우 도구는 실행 흐름을 사전에 정의해야 한다. 에이전트는 상황에 따라 어떤 도구를 어떤 순서로 쓸지 동적으로 판단하므로, 예상하지 못한 입력이나 예외 상황에 유연하게 대응할 수 있다

• 비용: 입력 토큰 $5.00/M으로, GPT-5.2($1.75/M)·Gemini 3 Pro($2.00/M) 대비 2.5~3배 비싸다
• 속도: 프론티어 모델 중 느린 편이다. Sonnet 4.5 대비 체감 3~10배, Gemini 3 Pro·GPT-5.2 대비로도 응답 속도가 떨어진다
• 벤더 락인: 프론티어 모델마다 강점이 다르다. Opus 4.5는 대규모 코드베이스(SWE-bench 80.9%), Gemini 3 Pro는 프론트엔드 UI(WebDev Arena 1위), GPT-5.2는 추론(GPQA 92.4%). 작업 특성에 맞춰 모델을 조합하면 각각의 강점을 살릴 수 있지만, Claude Agent SDK 기반이라 모델 선택의 폭이 좁다. 다른 LLM을 전환하거나 조합하려면 프레임워크를 재설계해야 한다