HiAPI
블로그

사용 가이드

wan2.7-image-standard 시작 가이드: 역량 범위, API 파라미터와 가격 책정 실무

개발자를 위한 연동 의사결정과 적용 핵심 포인트

Nov 3, 2026
深青色底上的扁平矿物切面几何图,青绿晶面层叠,为 wan2.7-image-standard 上手指南的封面图。

이 모델이 해결하는 문제와 다루지 않는 영역

wan2.7-image-standard는 Alibaba가 제공하는 이미지 생성 모델로, 출력 유형은 이미지이며 역량 범위는 두 가지 작업에 명확히 위치합니다: 텍스트-이미지(text-to-image)와 이미지-이미지(image-to-image). 다시 말해 텍스트 설명을 한 장의 이미지로 변환하거나, 기존 이미지를 기반으로 제어된 재생성을 수행하는 데 능숙합니다. 이 두 경로는 대부분의 콘텐츠 제작, 소재 보완, 스타일 조정 시나리오를 커버합니다.

미리 명확히 해야 할 것은 무엇을 커버하지 않는지입니다. 이미지 편집의 국소 인페인팅(inpainting), 마스크 아웃페인팅(outpainting), 초해상도 업스케일링, 배경 제거 등의 작업은 이 두 가지 역량에 포함되지 않습니다. 비즈니스 파이프라인에서 이런 단계의 비중이 높다면 별도로 모델을 선택해야 하며, 하나의 모델로 모두 처리하기를 기대해서는 안 됩니다. 영상 생성, 3D 자산 생성 역시 그 범주가 아닙니다.

따라서 연동 판단은 세 가지 질문으로 단순화할 수 있습니다:

  • 핵심 요구가 '텍스트 또는 참조 이미지로부터 완전히 새로운 이미지 한 장을 얻는 것'인가? 그렇다면 후보에 해당합니다.
  • 픽셀 수준의 국소 편집 기능이 필요한가? 그렇다면 다른 모델을 추가로 구성해야 합니다.
  • 다운스트림이 생성 결과의 크기와 내용에 엄격한 제약을 두는가? 이는 이미지-이미지 경로에서 얼마나 많은 전처리 작업을 해야 하는지를 결정합니다.

경계를 먼저 명확히 하고 나서 파라미터와 비용을 논의하면 '먼저 연동하고 나서 쓸모없음을 발견하는' 재작업을 피할 수 있습니다.

결정체 내부에 나란히 있는 두 개의 주 절단면이 바로 모델이 지원하는 두 갈래이며, 경계 밖의 작은 결정 조각들은 모델이 처리하지 않는 작업을 나타냅니다.

장당 과금이 의미하는 것

wan2.7-image-standard는 장당 과금 방식을 채택합니다: 성공적으로 한 장의 이미지를 산출할 때마다 비용이 한 번 부과됩니다. 이 방식 자체는 매우 직관적이지만, 예산에 미치는 실제 영향은 단가 자체보다 호출 전략에 달려 있습니다.

핵심 변수는 세 가지입니다:

  • 다중 후보 이미지: 동일한 prompt로 여러 장의 후보를 요청한 뒤 선택한다면, 각 장이 모두 비용에 포함됩니다. 후보 수가 두 배가 되면 단일 요청 비용도 두 배가 됩니다.
  • 실패 재시도: 타임아웃, 파라미터 오류, 콘텐츠가 규정에 맞지 않는다고 판정된 후의 재시도는 유효한 출력이 발생하는 한 비용으로 누적됩니다. 엔지니어링 측면에서 재시도 전략이 공격적일수록 예산 추정이 어려워집니다.
  • 카나리 배포와 부하 테스트: 출시 전 비교 테스트, A/B 실험은 실제로 이미지를 생성합니다. 이 부분은 종종 예산에서 누락됩니다.

간단한 비용 모델을 세워보면: 월 예상 비용 ≈ 일평균 유효 요청 수 × 요청당 평균 산출 이미지 수 × 30. 여기서 '요청당 평균 산출 이미지 수'에는 후보 이미지와 재시도 성공률을 반영해야 하며, 이상적인 경우의 1이 아닙니다.

고빈도 호출 시나리오에서는 비즈니스 측에서 일일 산출 상한을 설정하고 동일 prompt에 대한 결과 캐싱을 권장합니다. 동일 입력이 짧은 시간 내에 반복 요청되는 경우는 데모, 재생, 테스트 환경에서 매우 흔하며, 캐싱은 이 부분의 비용을 바로 제거할 수 있습니다. 구체적인 단가와 최신 과금 기준은 사이트 가격 패널을 기준으로 하며, 본 문서나 과거 이메일의 숫자를 장기 예산 근거로 삼지 마십시오.

단일 결정 조각을 과금 단위로 하여, 재시도와 다중 후보가 분기를 따라 층층이 예산 규모를 확대합니다.

연동 전 파라미터 및 호출 체크리스트

HiAPI.ai 통합 인터페이스로 wan2.7-image-standard를 호출하려면, 연동 테스트 전에 입출력 기준을 확정해야 세부 사항에서 반복적인 재작업이 발생하지 않습니다.

입력 측에서 확인할 요소

  • prompt 표현 규범: 먼저 목표 언어의 설명으로 기준 테스트를 수행하여, 모델이 긴 설명, 부정문, 스타일 단어에 실제로 어떻게 반응하는지 확인한 후 prompt 템플릿화 여부를 결정하십시오. 팀 내부에서 prompt 규약(주체, 장면, 스타일, 부정 제약의 순서)을 유지하여 개인별 작성 차이로 인한 효과 변동을 줄이는 것이 좋습니다.
  • 작업 유형: 텍스트-이미지와 이미지-이미지 호출을 명시적으로 구분하고, 이미지-이미지는 반드시 입력 이미지를 제공해야 합니다. 참조 이미지를 prompt에 섞어 텍스트 설명으로 대체하지 마십시오.
  • 크기와 비율: 모델이 지원하는 크기 범위를 확인하고, 비즈니스 측에서 몇 가지 일반 비율(예: 세로, 정사각, 가로)을 고정하여 매 요청마다 임의 크기를 사용함으로써 이후 레이아웃과 저장 로직이 복잡해지는 것을 피하십시오.
  • 입력 이미지 형식과 용량: 이미지-이미지 경로에서 허용 가능한 형식, 해상도 상한과 파일 크기를 명확히 하고, 필요 시 호출 전에 로컬 압축이나 형식 변환을 수행하십시오.

출력 측에서 확인할 요소

  • 반환 결과 형태: 접근 가능한 이미지 리소스를 직접 반환하는지, 아니면 추가 다운로드 후 저장이 필요한지. 이는 호출 계층에 '이미지 가져오기 + 저장' 함수를 캡슐화해야 하는지를 결정합니다.
  • 결과 유효 기간: 임시 링크를 반환하는 경우 유효 기간 내에 전송 저장을 완료해야 하며, 그렇지 않으면 데이터가 만료됩니다. 이 점은 반드시 출시 전에 실측하십시오.
  • 오류 및 속도 제한 반환 구조: 오류 코드 필드를 미리 확인하여 클라이언트에서 분류 처리할 수 있도록 하고, 모든 실패를 동일한 예외로 간주하여 재시도하지 마십시오.

위 요소들을 연동 체크리스트로 작성하여 연동 테스트 시 항목별로 확인하는 것이 사후 문제 해결보다 훨씬 시간을 절약합니다.

입력 요소가 왼쪽에서 API 통로로 유입되어 최종적으로 오른쪽에서 이미지 자산을 산출합니다. 연동 전에 이 체인상의 각 파라미터를 항목별로 확인해야 합니다.

이미지-이미지 흐름의 엔지니어링 주의점

이미지-이미지는 텍스트-이미지보다 전체 입력 처리 체인이 하나 더 많으며, 엔지니어링 복잡성도 주로 여기에 집중됩니다.

입력 전처리

참조 이미지는 모델이 바로 처리할 수 있는 이상적인 소재인 경우가 드뭅니다. 일반적인 처리에는 모델이 지원하는 형식으로 통일, 해상도를 합리적인 범위로 조정, 필요 시 목표 비율로 크롭하는 것이 포함됩니다. 전처리는 서버 측에서 완료하고 멱등성을 확보하여 동일한 원본 이미지가 반복 처리되지 않도록 하십시오. 동시에 원본 이미지와 처리된 이미지의 대응 관계를 보존하여 효과 추적이 가능하도록 권장합니다.

일관성 검증

이미지-이미지의 핵심 기대는 '참조 이미지의 일부 특징을 유지하면서 prompt에 따라 변화를 주는 것'입니다. 출시 전에 무엇이 합격인지 정의해야 합니다: 주체가 유지되는지, 구도가 유사한지, 스타일 편차가 허용 가능한지. 일반적인 방법은 샘플링 수동 평가에 가벼운 자동 지표(예: 원본 이미지와의 유사도 임계값)를 더해 1차 필터링을 수행하여, 명백히 벗어난 결과를 걸러내고 수동 검토량을 줄이는 것입니다.

입력 콘텐츠의 사전 규정 준수

참조 이미지가 사용자 업로드에서 온 경우, 모델 호출 전에 콘텐츠 검증을 한 번 수행하여 명백히 규정에 맞지 않는 입력이 생성 단계로 들어가는 것을 방지해야 합니다. 이 계층을 생성 이후에 두는 것보다 서버 측에 두는 것이 비용도 절감되고 비즈니스 흐름에도 더 부합합니다.

메타데이터 보존

각 생성 결과에 대해 원본 입력 이미지 식별자, prompt, 크기, 모델명과 호출 시간을 기록할 것을 권장합니다. 이미지-이미지 결과는 입력과 강하게 결합되어 있어, 이 메타데이터 계층이 없으면 이후 문제 재현도 어렵고 효과 귀인도 어렵습니다.

비교 부하 테스트로 어떤 작업을 담당할지 결정

연동 여부를 판단할 때 '기존 방안을 전면 교체'하는 사고방식보다, 후보 모델 풀에 넣고 작업 유형별로 그룹화하여 부하 테스트를 수행하며 어느 작업에서 가성비가 가장 높은지 보는 것을 권장합니다.

그룹화 방식

정교하게 선별한 예쁜 prompt가 아니라 비즈니스의 실제 분포에 따라 테스트 세트를 분할하십시오:

  • 텍스트-이미지: 상품 이미지, 일러스트 스타일 소재, 장면 콘셉트 이미지 등 실제 카테고리별로 그룹화.
  • 이미지-이미지: 참조 이미지 비율, 스타일 전이 정도, 주체 복잡도 각각 몇 단계로 구분.
  • 난이도 계층화: 단순 설명, 긴 설명, 구체적 텍스트 요구 포함, 복잡한 공간 관계 포함 설명을 분리하여 통계.

평가 차원

  • 사용 가능률: 첫 회 결과를 수정 없이 사용할 수 있는 비율로, 실제 비용을 가장 잘 반영하는 항목입니다.
  • 일관성: 동일 prompt를 여러 번 호출했을 때 결과의 안정성으로, 사용자 경험에 영향을 줍니다.
  • 이미지-이미지 충실도: 참조 이미지 특징 유지와 prompt 준수 사이의 균형.
  • 엔드투엔드 지연과 실패율: 비동기 큐가 필요한지를 결정합니다.

조합 결론

모델 결과와 기존 방안을 동일한 테스트 세트에서 비교 채점하면, 보통 '일부 작업 유형은 명백히 더 좋고, 일부는 비슷하며, 소수 시나리오는 기존 방안보다 못한' 분포가 나타납니다. 결론은 작업 분배 규칙으로 작성해야 합니다: 어떤 작업을 wan2.7-image-standard로 라우팅하고, 어떤 작업은 기존 방안을 유지하거나 다른 모델을 선택할지. 이렇게 하면 출시 리스크가 최소화되고 이후 개별 조정도 용이합니다.

이미지 호출을 엔지니어링 체인에 포함시키기

모델 효과는 출시의 일부일 뿐이며, 장기적 경험에 실제로 영향을 주는 것은 호출 계층의 엔지니어링 수준입니다.

재시도와 타임아웃

이미지 호출에 명확한 타임아웃 상한을 설정하고 오류 유형별로 구분 처리하십시오: 네트워크류 오류는 지수 백오프 재시도, 파라미터류 오류는 즉시 실패 및 알림, 재시도하지 않음. 재시도 횟수에는 상한이 있어야 하며 비용 모니터링과 연동해야 합니다. 재시도율이 비정상적으로 높아지는 것은 보통 체인 문제의 초기 신호입니다.

비동기와 큐

이미지 생성 소요 시간은 일반적으로 일반 텍스트 인터페이스보다 깁니다. 사용자 대상 시나리오는 비동기로 처리할 것을 권장합니다: 작업 제출, 작업 식별자 반환, 폴링 또는 콜백으로 결과 획득하여 장기 연결이 붙잡히지 않도록 합니다. 배치 시나리오는 큐로 피크를 완화하고 동시성을 제한하여 순간 트래픽이 속도 제한을 유발해 재시도를 증폭시키는 것을 방지하십시오.

결과 저장

생성 결과는 유효 기간 내에 자체 객체 스토리지로 전송 저장하고 메타데이터(prompt, 작업 유형, 크기, 모델 버전, 타임스탬프)를 기록해야 합니다. 저장 계층에서는 콘텐츠 중복 제거를 권장하며, 동일 입력의 결과를 재사용하면 저장 공간과 호출 비용을 모두 절약할 수 있습니다.

비용과 품질 모니터링

출시 후 세 가지 지표 그룹을 지속적으로 추적하십시오: 일일 산출 이미지 수, 실패 및 재시도 비율, 수동 재작업 비율. 앞의 두 항목은 비용에, 세 번째 항목은 품질에 대응합니다. 산출은 안정적인데 재작업 비율이 상승할 때는 보통 비즈니스 입력 분포가 변했다는 의미이므로 prompt 규범이나 작업 분배 규칙을 재평가해야 합니다.

모델 역량, 장당 과금의 비용 기준과 엔지니어링 체인을 함께 보면, 연동 결정은 일회성 효과 비교가 아니라 지속 가능한 운영 방안이 됩니다. 모델 파라미터 세부 사항과 최신 과금 기준을 확인할 때는 HiAPI.ai의 모델 페이지와 가격 패널을 기준으로 하십시오.

영구 AI 아티팩트로 빌드 시작하기

API 키를 받아 태스크 기반의 하나의 API로 이미지, 비디오, 오디오 모델을 호출하세요.

API 문서 보기