Blog

Apidog에서 GLM-5.3-Flash API 테스트 방법

텍스트 호출, Base64 이미지 페이로드, 도구 호출, 어설션 및 GLM-5.3 비교 실행을 포함하는 GLM-5.3-Flash API용 재사용 가능한 테스트 컬렉션을 구축하세요.

Ashley Goolam

Ashley Goolam

27 August 2026

Apidog에서 GLM-5.3-Flash API 테스트 방법

Apidog 엔터프라이즈

온프레미스 배포

SSO & RBAC

SOC 2 준수

Apidog Enterprise 살펴보기

애플리케이션에서 LLM을 교체하는 것은 한 줄의 변경 사항이지만 훨씬 더 큰 위험을 수반합니다. 모델 ID는 문자열입니다. 이 문자열이 변경하는 것은 응답 지연 시간, 토큰 비용, 출력 형식 안정성, 도구 호출 동작, 그리고 이미지 파이프라인이 제대로 작동하는지 여부입니다.

GLM-5.3-Flash는 이를 구체적으로 보여줍니다. GLM-5.3보다 약 9배 저렴하고, GLM-5.3은 지원하지 않는 이미지를 기본적으로 허용하며, 약 절반의 속도로 생성됩니다. 이것들은 실제적인 장단점이며, 어떤 선택이 자신에게 맞는지 알 수 있는 유일한 방법은 두 모델 모두에 대해 직접 요청을 실행하는 것입니다.

이 가이드는 Apidog에서 GLM-5.3-Flash API를 위한 재사용 가능한 테스트 컬렉션을 설정하는 방법을 안내합니다: 텍스트 호출, 이미지 호출, 도구 호출, 어설션, 그리고 더 큰 모델과의 비교 실행을 포함합니다.

왜 그냥 curl을 사용하지 않나요?

이 엔드포인트를 curl로 테스트할 수 있으며, 저희 API 가이드에서 정확히 그 방법을 보여줍니다. 하지만 첫 번째 호출을 넘어선 순간 두 가지 문제가 발생합니다.

Base64 이미지 페이로드. 스크린샷의 데이터 URL은 수천 자에 달합니다. 이를 터미널에 붙여넣으면 읽을 수 없고, 편집할 수 없으며, 내일 다시 실행할 수 없는 명령이 생성됩니다. 멀티모달 테스트에서는 쉘 히스토리가 더 이상 유용한 도구가 되지 못합니다.

아무것도 검증되지 않습니다. curl 응답은 화면에 표시되는 텍스트일 뿐입니다. 이는 호출이 성공했음을 알려주지, 응답이 애플리케이션이 읽는 필드를 여전히 포함하고 있는지는 알려주지 않습니다. 모델을 변경할 때, 그 차이점이 테스트의 핵심입니다.

저장된 컬렉션은 이 두 가지 문제를 해결합니다. 페이로드는 편집 가능한 요청 안에 존재하며, 어설션은 매번 실행됩니다.

환경 설정

실행마다 변경되는 값으로 환경을 생성하세요. 모델 ID를 변수로 유지하는 것이 중요합니다. 그래야 나중에 전체 컬렉션을 다른 모델로 다시 지정할 수 있기 때문입니다.

변수 값
base_url https://api.z.ai/api/paas/v4
api_key 사용자의 Z.ai 키
model glm-5.3-flash

키를 요청 헤더에 직접 붙여넣는 대신 환경 변수로 저장하세요. 이렇게 하면 내보내거나 팀원과 공유하는 어떤 것에서도 키가 노출되지 않으며, 누군가 컬렉션을 처음 커밋할 때보다 훨씬 중요합니다.

요청 1: 텍스트 완성

{{base_url}}/chat/completions로 POST 요청을 생성합니다.

헤더:

Authorization: Bearer {{api_key}}
Content-Type: application/json

본문:

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "Reply with exactly: OK"}
  ],
  "reasoning_effort": "low"
}

reasoning_effort에 주목하세요. 이 모델에서는 기본값이 max이며, 이는 추론을 출력 토큰으로 청구합니다. 연결 확인에는 완전히 불필요하므로, 여기서는 low로 설정합니다.

응답에 어설션을 추가합니다:

finish_reason 어설션은 사람들이 건너뛰었다가 나중에 후회하는 부분입니다. length 값은 응답이 완료되지 않고 출력 한도에서 잘렸음을 의미합니다. 이 모델의 최대 출력 수치가 소스마다 일치하지 않는다는 점을 고려할 때, 잘림을 명시적으로 포착하는 것은 한 줄의 가치가 있습니다.

요청 2: 이미지 호출

이 요청은 전체 설정의 필요성을 정당화하며, GLM-5.3에는 기본적으로 없는 기능입니다.

동일한 엔드포인트이지만 본문 형태가 다릅니다. content는 타입이 지정된 블록 배열이 됩니다:

{
  "model": "{{model}}",
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "What color is the dominant shape in this image? Answer with one word."},
        {"type": "image_url", "image_url": {"url": "{{test_image_url}}"}}
      ]
    }
  ],
  "reasoning_effort": "low"
}

환경에 test_image_url을 추가하여, 올바른 답변을 알고 있는 안정적이고 공개적으로 접근 가능한 이미지를 가리키도록 하세요. 고정된 이미지에 대한 결정론적 질문은 이것을 데모가 아닌 회귀 테스트로 만듭니다.

로컬 이미지의 경우 동일한 필드가 base64 데이터 URL을 사용합니다. 요청 본문이 읽기 쉽도록 환경 변수로 저장하세요:

data:image/png;base64,iVBORw0go...

어설션:

마지막 어설션은 유용한 카나리(canary)입니다. 이미지는 입력 토큰을 소비하므로, 프롬프트 토큰 수가 증가하지 않으면 이미지가 실제로 처리되지 않은 것이며, 사진을 조용히 무시하면서 200을 반환하는 요청이 됩니다. 이러한 실패는 이 확인 없이는 보이지 않습니다.

비전 경로 및 실패 모드에 대한 자세한 내용은 저희 GLM-5.3-Flash 비전 가이드를 참조하세요.

요청 3: 도구 호출

애플리케이션이 함수 호출을 사용하는 경우, 명시적으로 테스트하세요. 도구 호출 형식은 모든 모델 통합에서 가장 버전에 민감한 부분이며, 공급자 업데이트 후에 가장 깨지기 쉬운 부분입니다.

{
  "model": "{{model}}",
  "messages": [
    {"role": "user", "content": "Is the checkout-api service healthy?"}
  ],
  "tools": [
    {
      "type": "function",
      "function": {
        "name": "get_deployment_status",
        "description": "Returns the current status of a named deployment.",
        "parameters": {
          "type": "object",
          "properties": {
            "service": {"type": "string", "description": "The service name."}
          },
          "required": ["service"]
        }
      }
    }
  ]
}

어설션:

도구 호출의 존재 여부만을 확인하는 대신 함수 이름을 어설션하면 더 미묘한 실패, 즉 잘못된 도구를 호출하는 모델을 포착할 수 있습니다. 하나의 도구만 정의된 경우에는 그럴 가능성이 낮지만, 이 어설션은 비용이 들지 않으며 도구를 추가하더라도 계속 정확합니다.

이미 소유하고 있는 API에서 도구 정의를 생성하는 경우, OpenAPI 스펙을 에이전트 도구로 전환하는 방법을 통해 스키마를 수동으로 작성하지 않고도 이 작업을 수행할 수 있습니다.

GLM-5.3과 비교하기

여기 모델 ID를 환경 변수에 넣는 것의 이점이 있습니다.

환경을 복제하고, model을 glm-5.3으로 변경한 다음, 동일한 컬렉션을 실행하세요. 비교할 세 가지:

추론 노력 설정에 따라 completion_tokens를 면밀히 살펴보세요. reasoning_effort가 기본값인 max일 때, 추론 토큰은 출력으로 청구되므로 짧은 가시적 답변 뒤에 많은 완성 토큰이 숨어 있을 수 있습니다. 동일한 프롬프트를 low, high, max로 실행하고 토큰 수를 읽는 것이 워크로드가 실제로 무엇을 필요로 하는지 결정하는 가장 빠른 방법입니다.

로컬 배포 테스트

가중치를 직접 호스팅하는 경우, vLLM과 SGLang 모두 OpenAI 호환 엔드포인트를 노출합니다. base_url을 서버로 변경하고 동일한 컬렉션을 실행하세요.

이것이 이 스위트의 가장 가치 있는 용도입니다. 양자화된 빌드는 기본적인 채팅 테스트를 통과하더라도 도구 스키마를 잘못 처리하거나 이미지 입력에서 성능이 저하될 수 있으며, 이는 스모크 테스트가 아닌 프로덕션 환경에서 나타나는 실패 유형입니다. 저희 로컬 실행 가이드는 배포 측면을 다룹니다.

CI에 통합하기

컬렉션이 안정화되면, 스케줄에 따라 또는 파이프라인에서 실행하세요. 유용한 트리거:

모델 공급자는 안정적인 ID 뒤에서 모델을 업데이트합니다. 스케줄링된 실행은 사용자로부터 듣는 것이 아니라 동작이 변경되었음을 직접 알아내는 방법입니다.

정상 경로 외에 테스트할 내용

기본 테스트를 통과한 후 추가할 가치가 있는 몇 가지 사례:

마무리

여기서의 가치는 개별 요청이 아니라, 요청들이 반복 가능하다는 점입니다. 30초 안에 재테스트할 수 있는 모델 선택은 9월 9일에 가격이 변경되거나, Z.ai가 다음 개정판을 출시할 때, 또는 누군가 완전히 다른 공급자로 전환을 제안할 때 다시 검토할 수 있는 결정입니다.

Apidog는 무료로 시작할 수 있으며, OpenAI 호환 스키마를 가져오면 각 요청을 수동으로 구축하지 않고도 대부분의 설정을 얻을 수 있습니다. 최종적으로 갖게 되는 컬렉션은 다음 모델 교체가 큰 도약이 아닌 작은 차이(diff)가 되도록 만듭니다.

FAQ (자주 묻는 질문)

Apidog에서 API 설계-첫 번째 연습

API를 더 쉽게 구축하고 사용하는 방법을 발견하세요

무료 회원가입다운로드