아마존 베드록에서 GLM 5.3 출시

코딩 및 에이전트 기반 작업 부하는 AI 모델에게 이전보다 더 많은 요구를 하고 있습니다: 수백 개의 파일을 포함하는 저장소를 리팩토링하고, 맥락을 잃지 않은 채 다시간에 걸리는 에이전트 기반 워크플로우를 유지하며, 각 단계에서 도구를 활용하여 복잡한 시스템 문제를 해결해야 합니다. 오픈-웨이트 모델로 이러한 요구를 충족시키려면 역사적으로 자체 인스펙션 인프라를 구축하고 운영해야 했습니다.

Z.ai의 GLM 5.3 (Zhipu AI)가 이제 Amazon Bedrock에서 사용할 수 있습니다. Hugging Face Hub에 공개된 GLM 5.3은 코딩 및 장기적인 에이전트 작업에 최적화된 753B 파라미터의 혼합 전문가 모델입니다. 특히 Z.ai는 이 모델이 뛰어난 사이버 보안 기능을 갖추고 있다고 보고했습니다. Amazon Bedrock에서는 전역 인출, 프롬프트 캐싱 및 서비스 계층을 포함한 완전 관리형 API를 통해 사용할 수 있으며, 어떤 인프라도 관리할 필요가 없습니다. Bedrock에서 GLM 5.3에 대한 접근은 자격이 있는 기업 고객에게 제공됩니다.

이 글에서는 OpenAI와 호환되는 API를 사용하여 Amazon Bedrock에서 GLM 5.3을 실행하는 방법을 보여줍니다. 또한 프롬프트 캐싱을 통해 비용과 지연 시간을 줄일 수 있습니다. 그 다음에는 오픈소스 AI 침투 테스트 에이전트인 Strix를 사용하여 자신의 애플리케이션에 대한 승인된 보안 테스트를 실시하는 현실적인 에이전트형 워크플로우에서 모델을 활용합니다.

GLM 5과 비교했을 때 새로운 점은 무엇인가요?

GLM 5는 올해 초 아마존 베드록에 출시되었습니다. GLM 5.3은 동일한 라인업을 기반으로 하며, 여러 중요한 개선점이 포함되어 있습니다.

• 더 강력한 코딩: Z.ai는 DeepSWE, Terminal Bench 3.0, FrontierSWE를 포함한 다양한 코딩 벤치마크에서 경쟁적인 성능을 보인다고 주장합니다. 또한 자체 내부 코딩 벤치마크에서는 GLM 5.2보다 50% 향상된 결과를 보고했습니다. GLM 5와의 직접적인 비교는 보고되지 않았는데, 향상 정도가 너무 크기 때문에 GLM 5.1 발표 이후 벤치마크 테스트 자체를 업데이트해야 했기 때문입니다.
• 등장하는 사이버 보안 기능: 보안 작업에 대한 벤치마크 성능이 뛰어나기 때문에, 이 모델은 방어적 보안 워크플로우에 매우 적합합니다. 예를 들어, Z.ai는 출시 시 CyberGym 벤치마크에서 84.5의 선도적인 점수를 측정했습니다.
• 더 넓은 Amazon Bedrock 통합: 지역 간 인식 프로필, 암시적 및 명시적 프롬프트 캐싱, 그리고 Invoke 및 Converse와 함께 OpenAI와 호환되는 Responses 및 Chat Completions API의 기능 동등성 향상.

주요 기능들

• 프론티어 코딩 및 에이전트 성능. GLM 5.3은 복잡한 시스템 공학 및 장기적인 에이전트 작업을 위한 설계입니다. 여기에는 다단계 추론, 도구가 보완된 워크플로우, 그리고 대규모 코드 기반에서의 지속적인 맥락 관리가 포함됩니다.
• 유연한 API 접근. OpenAI와 호환되는 Responses 및 Chat Completions API, 또는 Amazon Bedrock Invoke 및 Converse API를 통해 GLM 5.3을 호출할 수 있습니다.
• 프롬프트 캐싱. GLM 5.3은 기본적으로 암시적(자동) 프롬프트 캐싱을 지원하며, Responses 및 Chat Completions API에서는 명시적인 캐시 제어 기능(권장)도 제공됩니다. 각 턴마다 큰 시스템 프롬프트나 저장소 컨텍스트를 다시 전송해야 하는 에이전트형 워크로드의 경우, 캐싱을 통해 지연 시간과 입력 비용을 모두 줄일 수 있습니다.
• 서로 다른 지역 간 추론. GLM 5.3은 미국 내 서로 다른 지역 간 추론(us.zai.glm-5.3)과 글로벌 서로 다른 지역 간 추론(global.zai.glm-5.3) 프로필을 통해 사용할 수 있습니다. 선택한 AWS 지역으로 요청을 보내면, Amazon Bedrock이 각 요청을 안전하게 라우팅하여 처리합니다. 자세한 내용은 Amazon Bedrock 사용자 가이드를 참조하십시오.
• 서비스 티어. 시간 민감성이 낮은 작업에 대해 비용을 최적화하려면 Flex를 선택하세요. 지연 시간이 중요한 요청에 우선순위를 두고 더 높은 가격을 지불하려면 Priority를 선택하세요. 기본적인 가격과 속도의 균형을 원한다면 Standard를 선택하세요.

전제 조건

다음 사용 예시를 위해서는 다음이 필요합니다:

1. Amazon Bedrock에 접근할 수 있는 AWS 계정.
2. AWS Identity and Access Management(IAM) 권한를 통해 기본 모델과 대상 인퍼런스 프로필을 호출할 수 있습니다: bedrock:InvokeModel, bedrock:InvokeModelWithResponseStream, 및 bedrock:CallWithBearerToken.
3. (코드 기반 데모의 경우) Python 3.10 이상.
4. (선택적 보안 테스트 데모용으로만) Docker를 설치하고 bedrock 추가 기능이 포함된 Strix를 설치하세요.

Amazon Bedrock 콘솔에서 GLM 5.3을 시도해 보세요

AWS 관리 콘솔에서 GLM 5.3에 프롬프트를 전송하기 시작할 수 있습니다. 코드를 작성하거나 개발자 도구를 설치할 필요가 없습니다. 시작하려면 Amazon Bedrock로 이동한 다음 왼쪽 사이드바 메뉴에서 Test > Playground를 선택하세요.

이 플레이그라운드 인터페이스에서 모델 목록에서 GLM 5.3을 선택한 후 채팅 UI를 통해 첫 번째 프롬프트를 전송할 수 있으며, 다음 스크린샷과 같습니다:

그림 1: 아마존 Bedrock 콘솔에서 GLM 5.3과 대화하기

Responses API를 사용하기 시작하세요

프로그래밍 방식으로 bedrock-runtime 엔드포인트를 통해 모델을 호출할 수 있습니다. 이를 통해 OpenAI와 호환되는 Responses 및 Chat Completions API와, Amazon Bedrock의 Invoke 및 Converse API를 GLM 5.3용으로 사용할 수 있습니다. 새로운 애플리케이션의 경우 OpenAI와 호환되는 API가 더 완전한 기능 세트를 지원하므로 권장됩니다.

Amazon Bedrock은 OpenAI와 호환되는 통합에 필요한 API 키 생성을 지원합니다. 하지만 가능한 경우 장기간 사용되는 API 키보다는 단기간 사용되는 자격 증명을 선호하는 것이 더 좋습니다.

다음 예제에서는 OpenAI Python SDK를 사용하여 Python에서 Responses API를 호출하고, aws-bedrock-token-generator 라이브러리를 이용해 표준 AWS 명령줄 인터페이스(AWS CLI) 자격증명로부터 단기 토큰을 생성할 것입니다.

1. 필요한 패키지들을 설치하세요.

   pip install -U openai aws-bedrock-token-generator

2. 다음 코드를 bedrock-request.py로 저장하세요.

   from aws_bedrock_token_generator import provide_token
   from openai import OpenAI
   
   region = "us-west-2"  # Your source AWS Region
   
   client = OpenAI(
       api_key=provide_token(region=region),
       base_url=f"https://bedrock-runtime.{region}.amazonaws.com/openai/v1",
   )
   
   resp = client.responses.create(
       input="Refactor this Python function to be iterative instead of recursive: ...",
       model="global.zai.glm-5.3",
   )
   
   print(resp.output_text)

3. 스크립트를 실행하면 모델의 출력 결과가 표시됩니다.

   python bedrock-request.py

명시적인 프롬프트 캐싱을 통한 추론 최적화

장기간 지속되는 코딩 및 지식 작업 흐름은 시스템 프롬프트, 도구 정의, 또는 저장소 파일과 같은 여러 대화 턴을 통해 안정적인 컨텍스트를 다시 전송하는 경우가 많습니다.

Amazon Bedrock용 GLM 5.3은 기본적으로 암시적 프롬프트 캐싱을 지원하며, 이를 통해 동일한 초기 프롬프트 전제를 공유하는 반복적인 호출의 응답 지연 시간과 입력 토큰 비용을 줄일 수 있습니다.

명시적 프롬프트 캐싱 모드를 사용하면 재사용 가능한 프롬프트 전제를 명확하게 지정할 수 있으며, 이는 암시적 캐싱보다 캐시 히트율을 더욱 향상시키고(따라서 지연 시간과 비용을 절감할 수 있음) 합니다.

다음 예제와 같이 GLM 5.3에서 명시적 프롬프트 캐싱을 사용하려면:

1. 요청 시 prompt_cache_options를 통해 명시적인 캐싱 모드를 선택하세요.
2. 입력 콘텐츠 블록에 하나 이상의 prompt_cache_breakpoint 마커를 추가하여 재사용 가능한 프롬프트 전제의 끝(포함)을 표시하세요. 각 브레이크포인트는 캐싱에 적합하도록 최소 1,024개의 토큰을 포함해야 합니다.

resp = client.responses.create(
    model="global.zai.glm-5.3",
    # Enable explicit caching mode:
    extra_body={"prompt_cache_options": {"mode": "explicit"}},
    input=[
        {
            "type": "message",
            "role": "system",
            "content": [
                {
                    "type": "input_text",
                    "text": SYSTEM_PROMPT,
                    # A long, static system prompt is a great target for caching:
                    "prompt_cache_breakpoint": {"mode": "explicit"},
                },
            ]
        },
        {
            "type": "message",
            "role": "user",
            "content": [
                {
                    "type": "input_text",
                    "text": USER_INPUT,
                    # Multiple breakpoints can also be defined, for layered cache:
                    "prompt_cache_breakpoint": {"mode": "explicit"},
                },
            ],
        },
    ],
)

if resp.usage.input_tokens_details.cached_tokens:
    print("Hit cache!")

더 많은 정보가 필요한 경우, Amazon Bedrock 사용자 가이드의 prompt caching 섹션을 참조하십시오.

예시적인 에이전트형 워크로드: 스트릭스를 이용한 승인된 보안 테스트

GLM 5.3의 장점을 직접적으로 활용할 수 있는 워크로드 중 하나는 자체 애플리케이션의 자동 보안 테스트입니다. Strix는 오픈소스 AI 침투 테스트 에이전트로, 코드를 동적으로 실행하여 취약점을 찾고 증상 확인 테스트를 통해 그 취약점을 검증합니다. 현재 Strix 문서는 GLM 5.3을 기본 모델로 사용하고 있습니다. 귀하는 Strix를 제3자 인퍼런스 제공자를 대신하여 Amazon Bedrock에서 GLM 5.3을 사용하도록 설정할 수 있으므로, 모델 인퍼런스는 AWS 계정의 통제 하에 실행됩니다.

당신이 소유한 또는 명시적으로 허가를 받은 애플리케이션만 테스트하세요. 당신이 소유하지 않은 시스템에 무단으로 보안 테스트를 진행하는 것은 대부분의 지역에서 불법이며 AWS 사용 정책을 위반합니다. 이 설명에서는 OWASP Juice Shop라는, 당신의 컴퓨터에서 로컬로 실행되는 의도적으로 취약한 샘플 애플리케이션을 대상으로 합니다.

자체로 오픈소스 에이전트를 실행하는 것 외에 완전히 관리되는 지속적인 보안 테스트를 원한다면, AWS Continuum는 관리 서비스로 주문형 침투 테스트 및 기타 보안 분석을 제공합니다. 이 두 방식은 상호 보완적입니다: Strix과 같은 오픈소스 에이전트는 개발자가 주도하는, 실시간에 맞는, 그리고 깊이 맞춤화 가능한 로컬 빌드에 대한 테스트를 제공하는 반면, AWS Continuum은 대규모로 관리되는 평가를 수행합니다.

승인된 보안 테스트를 실행하기

1. 로컬에서 예시인 Juice Shop target 애플리케이션을 시작하세요.

   docker run --rm -p 3000:3000 bkimminich/juice-shop

2. Strix을 Amazon Bedrock에서 GLM 5.3을 사용하도록 설정하세요. Strix은 내부적으로 LiteLLM를 사용하므로 (Amazon Bedrock에 대한 문서에서 설명된 바와 같이), AWS CLI 자격증이 자동으로 인식됩니다. 이는 API 키가 필요하지 않다는 것을 의미하지만, AWS_PROFILE 및 AWS_REGION과 같은 환경 변수를 설정하여 연결을 구성하는 것이 좋습니다. 현재 LiteLLM은 bedrock/global.zai.glm-5.3를 해결하지 못하고 있습니다. 이 문제가 해결될 때까지는 다음 코드와 같이 Converse API 경로와 Amazon 리소스 이름(ARN)을 명시적으로 지정해야 합니다:

   # Fill in the REGION and ACCOUNT_ID placeholders below before running!
   export STRIX_LLM="bedrock/converse/arn:aws:bedrock:{AWS_REGION}:{AWS_ACCOUNT_ID}:inference-profile/global.zai.glm-5.3"

3. 로컬 타겟에 스트릭스를 실행하세요.

   strix --target http://localhost:3000

4. 루트 Strix 에이전트가 작업을 완료할 때까지 기다린 후, 그 결과를 검토하세요.

Strix은 하위 에이전트 팀을 구성하여 위협 영역을 파악하고 다양한 잠재적 취약성 범주를 탐색하며, 각 발견 사항을 실제 PoC를 통해 검증하려고 합니다. 이를 통해 잘못된 긍정 결과를 처리하는 데 드는 시간을 최소화할 수 있습니다. 성공적인 실행 결과는 각 발견 사항에 대한 심각도, 증거 및 복구 지침이 포함된 보고서를 생성합니다.

다음 비디오는 예제 애플리케이션에서 Strix를 설정하고 실행하며 결과를 탐구하는 전체 과정을 보여줍니다.

그림 2: GLM 5.3 및 Strix를 사용하여 예제 보안 테스트 실행

정리하기

Juice Shop 컨테이너를 중단하세요 Ctrl+C 실행 중인 터미널에서, 또는 실행하기 docker ps 컨테이너 ID를 찾아서 그것을 중단하세요 docker stop <container-id>. Amazon Bedrock 인스펙션은 지속적인 리소스이 없는 티켓 기반 결제 방식이므로, 요청이 완료된 후 추가 비용은 발생하지 않습니다. 이 설명을 위해 Amazon Bedrock API 키를 생성했지만 더 이상 필요하지 않다면 Amazon Bedrock 콘솔에서 그 키를 삭제하세요.

가용성

GLM 5.3을 Amazon Bedrock 콘솔에서 시도해 보세요. OpenCode과 같은 코딩 도우미를 사용하여 사용하거나, Kimi K3와 함께한 최근의 글에 설명된 방법대로 사용하거나, 지원되는 API를 통해 자체 애플리케이션을 연결할 수도 있습니다.

아마존 베드록이 귀사의 팀을 어떻게 지원할 수 있는지에 관심이 있나요? 우리와 연락하세요 대화를 시작하세요.

저자들에 대하여