[태그:] AI 활용

공식 발표일: 2026년 9월 10일 · 확인일: 2026년 9월 11일

OpenAI가 Agents API를 공개 베타로 출시했습니다. 이전에는 모델 호출, 대화 상태, 도구 실행기, 작업 재개, 로그 수집을 애플리케이션이 따로 엮어야 했다면, 이제는 관리형 Codex 하네스가 세션 오케스트레이션과 문맥 압축, 복구를 맡습니다. 개발자는 에이전트의 모델·지시문·도구를 정하고, 실행 환경을 OpenAI 호스팅 또는 자체 호스팅으로 선택할 수 있습니다.

이번 발표는 새로운 기반 모델의 점수 경쟁보다 오래 실행되는 에이전트를 서비스에 넣는 방식을 바꾸는 API 출시입니다. 공개 엔드포인트는 /v1/agents/sessions이며 현재 요청에는 OpenAI-Beta: agents=v1 헤더가 필요합니다. 이 글은 직접 API를 실행한 후기가 아닙니다. OpenAI 공식 문서에서 확인한 기능, 비용 구조, 보안 조건과 독자가 같은 조건으로 재현할 평가 방법을 구분해 정리합니다.

Agents API 핵심 요약: 누가 먼저 살펴봐야 하나

가장 먼저 검토할 팀은 코드 수정, 문서 분석, 사고 조사, 데이터 질의처럼 한 번의 모델 응답으로 끝나지 않는 업무를 운영하는 팀입니다. 반대로 짧은 분류나 요약 한 번이면 끝나는 서비스는 Responses API를 직접 호출하는 편이 구조와 비용을 파악하기 쉬울 수 있습니다.

기존 모델 호출과 무엇이 달라졌나

Responses API는 모델이 텍스트를 만들고 도구를 요청하는 기반을 제공합니다. Agents API는 그 위에서 여러 번의 모델 호출과 도구 실행이 이어지는 작업을 지속형 세션으로 관리합니다. 세션에는 에이전트 설정, 대화, 저장된 작업이 유지되고, 유휴 상태에 새 메시지를 보내면 새 턴이 시작됩니다. 실행 중 메시지를 보내면 현재 턴을 조정하는 입력으로 처리됩니다.

관리형 하네스는 샌드박스에서 명령과 코드를 실행하고 파일을 수정하며, 관련 스킬을 적용하고 MCP 서버와 연결할 수 있습니다. 문맥이 길어지면 이전 작업을 요약해 창을 관리하고, 하위 에이전트에 일부 작업을 맡기거나 중단된 지점에서 세션을 이어 갈 수도 있습니다. 다만 환경을 none으로 만들면 내장 셸과 파일 작업 공간, 실행기 MCP를 쓸 수 없습니다. 이 경우 애플리케이션 함수 도구 또는 원격 MCP 중심으로 구성해야 합니다.

세션이 실제로 움직이는 순서

1. 에이전트를 정합니다. 모델, 지시문, 함수 도구, MCP 서버와 추론 설정을 구성합니다. 같은 설정을 여러 세션에서 쓸 때는 에이전트를 저장하고 agent_id를 재사용할 수 있습니다.
2. 환경을 선택합니다. 실행이 필요 없으면 none, 관리형 Linux 작업 공간이 필요하면 openai_hosted, 사설망이나 전용 이미지를 써야 하면 self_hosted를 선택합니다.
3. 세션과 첫 입력을 만듭니다. stream: true를 지정하면 생성 요청에서 첫 턴의 이벤트를 바로 받을 수 있습니다.
4. 진행 상황을 확인합니다. 스트림 또는 웹훅으로 상태 변화를 받고, 저장된 아이템과 턴을 조회합니다.
5. 성공을 판정합니다. agent.session.turn.completed를 확인하되 도구별 성공 여부도 따로 검사합니다. 단순히 세션이 idle이라는 사실만으로 성공으로 처리하면 안 됩니다.
6. 후속 작업을 보냅니다. 같은 세션 ID에 추가 입력을 보내 기존 문맥과 결과를 이어 갑니다. 실행 중 방향을 바꾸려면 현재 턴을 조정합니다.
7. 산출물을 보존하고 정리합니다. 필요한 파일을 먼저 내려받은 뒤 더 쓸 필요가 없는 세션을 삭제합니다.

OpenAI 호스팅과 자체 호스팅, 선택 기준

OpenAI 호스팅 샌드박스는 Python, Node.js, 명령줄 도구가 있는 Linux 작업 공간을 제공합니다. 작업 디렉터리는 /workspace이며 필요한 Python·시스템·npm 패키지, 초기 설정 명령, 입력 파일, 환경 변수, 스킬과 플러그인을 세션 설정에 넣을 수 있습니다. 같은 구성을 반복한다면 환경 템플릿을 재사용할 수 있습니다.

실제 성능: 공식 자료가 보여 주는 것과 보여 주지 않는 것

Agents API 자체의 성공률이나 기존 직접 구현 대비 지연시간을 비교한 공식 표준 벤치마크는 현재 문서에서 확인되지 않았고, 신뢰할 수 있는 독립 평가도 아직 확인되지 않았습니다. 따라서 “에이전트 개발이 몇 배 빨라진다”거나 “작업 성공률이 자동으로 높아진다”고 단정할 근거는 없습니다.

공식 추적 문서에는 기록된 세션 예시 하나가 공개돼 있습니다. 루트 에이전트와 하위 에이전트 2개가 참여한 한 턴에서 10회 도구 호출, 252,468토큰, 완료까지 1분 37초가 표시됩니다. 추적에는 에이전트 스팬 3개, 모델 생성 스팬 11개, 도구 스팬 10개가 포함됩니다. 이는 기능을 설명하기 위한 단일 기록 예시이며 일반적인 속도나 비용의 대표값이 아닙니다.

가격과 비용 계산: API 이용료는 한 줄이 아니다

Agents API에는 모든 것을 포함한 단일 작업당 가격이 제시된 것이 아닙니다. 모델 호출은 선택한 모델의 API 단가, OpenAI 도구는 해당 도구 단가, OpenAI 호스팅 샌드박스는 표준 컨테이너 단가가 각각 적용됩니다. 외부 MCP나 자체 호스팅 인프라 비용도 별도입니다.

한 작업의 예상 비용은 다음처럼 계산하는 편이 안전합니다.

총비용 = 루트 모델 호출 + 하위 에이전트 호출 + 캐시 읽기·쓰기 + OpenAI 도구 + 샌드박스 시간 + 외부 서비스 + 재시도

공식 사용량 필드는 입력 토큰, 캐시 입력 토큰, 출력 토큰, 추론 토큰을 보여 주지만 최선 노력 방식입니다. 캐시 쓰기 가격이 있는 모델에서도 Agents API 사용량 필드가 별도 캐시 쓰기 수치를 노출하지 않을 수 있어, 이 값만으로 정확한 모델 비용을 계산할 수 없다는 제한도 문서에 명시돼 있습니다. 예산 경보와 실제 청구 데이터를 함께 봐야 합니다.

10분 빠른 시작: 최소 권한부터 설정하기

애플리케이션 API 키에는 세션 작업용 api.agents.read, api.agents.write와 모델 추론용 api.responses.write 권한이 필요합니다. 키는 에이전트의 샌드박스 밖에 보관합니다. 현재 공개 베타에서는 SDK가 베타 헤더를 자동으로 붙이지만 cURL 사용 시 직접 추가해야 합니다.

from openai import OpenAI

client = OpenAI()

with client.beta.agents.sessions.create(
    agent={
        "model": "gpt-6-astra",
        "instructions": "작업을 수행하고 실제 실행 결과와 오류를 보고하세요.",
    },
    environment={"type": "openai_hosted"},
    input="현재 폴더의 파일 트리를 만드는 스크립트를 작성하고 실행하세요.",
    stream=True,
) as events:
    for event in events:
        print(event.type)

위 코드는 공식 빠른 시작을 한국어 작업으로 단순화한 예시입니다. 실제 배포에서는 완료 이벤트와 도구 오류, 생성 파일, 예상 출력, 사용량을 함께 검증하세요.

직접 재현하는 성능·비용 평가 절차

다음은 공개 벤치마크가 부족한 새 API를 실제 서비스 조건에서 검증하는 방법입니다. 같은 모델과 입력을 사용하는 기존 오케스트레이터를 기준군으로 두고 Agents API를 비교군으로 둡니다.

1. 실제 개인정보를 제거한 대표 과제 30~100개를 준비합니다. 코드 수정, 문서 분석, 도구 조회처럼 서비스의 핵심 유형을 비슷한 비율로 섞습니다.
2. 모델, 추론 강도, 도구 설명, 데이터 스냅샷, 동시성, 최대 실행 시간을 고정합니다.
3. 업무 성공 기준을 실행 전에 정의합니다. 예를 들어 테스트 통과, 필요한 필드 채움, 허용된 파일만 변경, 출처 일치 여부를 자동 채점합니다.
4. 기존 방식과 Agents API 방식을 각 과제마다 최소 3회 실행해 우연한 네트워크 변동을 줄입니다.
5. 작업 성공률, 완전 성공까지 걸린 p50·p95 시간, 모델 호출 수, 도구 호출 성공률, 재시도율, 전체 토큰, 샌드박스 시간을 저장합니다.
6. 하위 에이전트를 켠 경우 루트와 하위 사용량을 분리하고 병렬 실행이 경과 시간과 비용에 미친 영향을 따로 계산합니다.
7. 스트림 끊김, 도구 500 오류, 세션 재개, 시간 초과를 의도적으로 주입해 중복 실행과 복구 성공률을 확인합니다.
8. 품질이 같은 결과만 비용 비교에 포함합니다. 낮은 성공률로 싸게 끝난 실행을 비용 개선으로 계산하지 않습니다.

보안과 승인 설계에서 놓치기 쉬운 부분

에이전트가 만든 코드는 환경에 노출된 파일, 자격 증명, 네트워크에 접근할 수 있습니다. 따라서 사용자나 업무별로 데이터를 공유하면 안 되는 경우 별도 격리 환경을 사용하고, 애플리케이션별 전용 OpenAI 프로젝트를 만드는 것이 기본입니다. 외부 통신은 승인된 엔드포인트만 허용하고, 실행기 MCP와 원격 MCP가 각각 어느 위치에서 연결되는지 구분해야 합니다.

애플리케이션 API 키를 샌드박스에 넣지 마세요. 자체 호스팅 실행기는 연결 전용 환경 키를 CODEX_API_KEY로 사용하며, 이 키는 다른 API 작업을 승인하지 못합니다. 제3자 자격 증명은 가능하면 환경에 직접 주입하지 말고 승인된 요청에만 비밀을 붙이는 브로커를 통하게 합니다. 장기 비밀은 비밀 저장소에 보관하고 노출이 의심되면 즉시 폐기·교체해야 합니다.

자주 생기는 실패와 해결법

세션이 idle인데 작업이 끝났다고 처리했다

idle은 현재 실행 중이 아니라는 상태일 뿐 성공을 뜻하지 않습니다. 완료·실패·취소 이벤트와 각 도구의 결과, 최종 산출물을 함께 확인합니다.

스트림이 끊긴 뒤 같은 요청을 다시 보내 중복 작업이 생겼다

세션과 저장 아이템을 먼저 조회해 턴이 계속 실행됐는지 확인합니다. 외부 쓰기 도구에는 작업 ID와 멱등성 키를 넣어 같은 결제나 게시가 두 번 일어나지 않게 합니다.

비용이 예상보다 크게 나왔다

한 작업 안에서 모델이 여러 번 호출되고 하위 에이전트와 재시도가 더해질 수 있습니다. 루트와 하위 턴 사용량, 도구·컨테이너 시간, 캐시 적중을 모두 합산하고 과제별 최대 호출·시간 예산을 둡니다.

샌드박스에서 사내 서비스가 연결되지 않는다

OpenAI 호스팅 환경의 네트워크 정책과 원격 MCP 접근 가능성을 확인합니다. 사설망이나 전용 소프트웨어가 필요하면 자체 호스팅 환경으로 옮기되 실행기 연결과 종료 책임도 함께 가져와야 합니다.

추적 화면의 토큰 값이 비어 있다

사용량은 최선 노력 값이며 늦게 도착하거나 null일 수 있습니다. 0으로 계산하지 말고 미확정 상태로 저장한 뒤 청구·예산 데이터와 대조합니다.

배포 전 체크리스트

• 공개 베타 변경 가능성을 감안해 SDK 버전과 베타 헤더를 기록했는가?
• 애플리케이션 키에 agents 읽기·쓰기와 responses 쓰기 최소 권한만 부여했는가?
• 애플리케이션 API 키와 제3자 비밀을 샌드박스 밖에 보관하는가?
• 환경 없음, OpenAI 호스팅, 자체 호스팅 중 요구 사항에 맞는 방식을 골랐는가?
• 완료 이벤트와 실제 도구 결과를 모두 검증하는가?
• 외부 쓰기 도구에 멱등성 키와 승인 절차가 있는가?
• 스트림 단절 뒤 조회 우선, 재시도 후순서 원칙을 구현했는가?
• 루트·하위 에이전트·재시도·도구·컨테이너를 포함한 작업당 비용을 계산하는가?
• 추적 로그의 입력·출력에 개인정보나 비밀정보가 남지 않는지 점검했는가?
• 대표 과제로 성공률, p95 완료 시간, 복구 성공률을 배포 전 측정했는가?

자주 묻는 질문

Agents API는 기존 Agents SDK와 같은 것인가요?

같지 않습니다. Agents API는 OpenAI가 관리하는 Codex 하네스와 지속형 세션을 제공하는 API이고, Agents SDK는 애플리케이션 코드에서 에이전트 흐름을 구성하는 개발 도구입니다. 요구하는 실행 위치와 운영 책임을 비교해 선택해야 합니다.

모든 작업에 OpenAI 호스팅 샌드박스가 필요한가요?

아닙니다. 함수 도구나 원격 MCP만 필요하면 환경을 none으로 둘 수 있습니다. 코드 실행과 파일 작업이 필요하면 호스팅 환경을 고르고, 사설망·전용 이미지가 필요하면 자체 호스팅을 검토합니다.

세션을 유지하면 비용이 자동으로 줄어드나요?

보장되지 않습니다. 동일한 앞부분이 반복되면 프롬프트 캐시가 도움이 될 수 있지만, 긴 이력이 여러 모델 호출에서 계속 처리되면 총 토큰은 커질 수 있습니다. 같은 품질의 작업당 총비용으로 비교해야 합니다.

공개 베타인데 바로 프로덕션에 써도 되나요?

작은 읽기 전용 업무부터 제한적으로 검증하는 것이 안전합니다. 변경 가능성, 사용량 집계 지연, 장애 복구, 승인과 멱등성을 먼저 확인하고 중요한 쓰기 작업은 사람 승인을 유지하세요.

공식 성능 수치만으로 기존 오케스트레이터보다 낫다고 판단할 수 있나요?

아닙니다. 공개 문서의 1분 37초·252,468토큰 예시는 하나의 기록된 추적 사례이지 비교 벤치마크가 아닙니다. 동일 모델·도구·과제로 직접 A/B 평가해야 합니다.

공식 확인 자료

• OpenAI API 변경 로그 — Agents API 공개 베타 발표
• Agents API 개요 — 관리 범위, 핵심 개념, 가격 구조
• Agents API 빠른 시작 — 권한, 베타 헤더, 세션 실행 예시
• Agents API 아키텍처 — 환경 없음·호스팅·자체 호스팅 비교
• 세션 실행과 이어가기 — 턴, 스트리밍, 후속 입력
• OpenAI 호스팅 샌드박스 — 패키지, 파일, 환경 설정과 비용
• 샌드박스 보안 — 격리, 네트워크, 자격 증명 원칙
• 관측과 사용량 — 토큰 집계와 비용 해석 한계
• 추적 — 모델 응답, 도구 호출, 하위 에이전트 분석

Agents API의 가치는 모델 한 번의 점수보다 오래 실행되는 작업의 상태, 복구, 도구, 추적을 하나의 운영 단위로 묶는 데 있습니다. 공개 베타 단계에서는 읽기 전용 과제부터 시작해 작업 성공률과 p95 시간, 전체 비용, 장애 뒤 복구 성공률을 먼저 측정하세요. 그 결과가 기존 방식보다 낫고 보안 경계가 명확할 때 쓰기 권한을 단계적으로 넓히는 것이 안전합니다.

공식 발표일: 2026년 9월 8일 · 확인일: 2026년 9월 9일

OpenAI가 Responses API에 Prompt Cache Diagnostics를 정식 공개했습니다. 긴 시스템 지시문, 도구 정의, 예시 문서가 반복되는 AI 에이전트는 프롬프트 캐시가 제대로 재사용되면 입력 비용과 처리 부담을 줄일 수 있습니다. 문제는 캐시 적중률이 갑자기 떨어져도 기존에는 모델 변경, 도구 스키마 수정, 키 변경, 대화 압축 중 무엇이 원인인지 찾기 어려웠다는 점입니다. 이번 기능은 현재 응답과 이전의 완료된 응답을 비교해 캐시 재사용을 막은 첫 번째 분류 원인과 놓친 토큰 규모를 알려줍니다.

지원 범위는 GPT-5.6 이상 호환 모델의 Responses API입니다. 진단 자체에는 추가 요금이 없지만 추가 기준 요청과 재시도는 정상 과금됩니다. 이 글은 직접 테스트가 아니며, 공식 OpenAI 문서와 독자가 재현할 측정 방법을 구분해 정리합니다.

왜 Prompt Cache Diagnostics가 중요한가

프롬프트 캐시는 답변을 저장하는 기능이 아니라 여러 요청 앞부분의 반복 토큰을 재사용하는 방식입니다. 고객 지원 정책, 코드 저장소 안내, 도구 정의, 평가 루브릭처럼 길고 안정적인 내용이 앞에 놓일수록 효과가 커질 수 있습니다.

요청 ID나 현재 시간이 고정 지시문 안에 들어가거나 도구 순서, 모델, 서비스 등급, 추론 강도가 바뀌면 기대한 접두부가 재사용되지 않을 수 있습니다. cached_tokens만으로는 원인을 알기 어렵지만 새 진단 필드는 먼저 확인할 차이를 알려줍니다.

작동 방식: previous_response_id와 비교 ID를 구분하자

진단을 요청하려면 현재 요청의 prompt_cache_options.comparison_response_id에 최근 완료된 기준 응답 ID를 넣습니다. 이 ID는 현재 요청이 같은 접두부를 재사용할 것으로 기대했던 비교 대상입니다. 비교 응답은 같은 조직에서 생성된 최근의 완료 응답이어야 하며, 진단 기록은 짧은 기간만 유지됩니다.

자주 혼동하는 값이 previous_response_id입니다. 이것은 이전 대화 문맥을 현재 요청에 이어 주는 값이지, 캐시 진단을 요청하는 값이 아닙니다. 반대로 comparison_response_id는 비교 기준만 정하며 그 응답의 대화 내용을 불러오지 않습니다. 멀티턴 대화에서는 두 값에 같은 응답 ID를 넣을 수 있지만 역할은 다릅니다. 애플리케이션이 대화 기록을 직접 관리한다면 전체 기록을 input으로 보내고 비교 ID만 지정할 수도 있습니다.

GPT-5.6 이상에서 캐시 가능한 공통 접두부는 최소 1,024토큰을 충족해야 합니다. 짧은 지시문에 진단만 붙였는데 계속 적중이 없으면 먼저 입력 길이와 실제 공통 구간을 확인해야 합니다. 진단 기록이 만료된 경우에는 응답 자체가 API에서 조회되더라도 comparison_response_not_found가 나올 수 있습니다.

실제 성능과 비용: 확인된 사실, 계산 예시, 아직 모르는 것

이 기능이 모델의 정답률이나 생성 품질을 높인다는 공식 벤치마크는 공개되지 않았습니다. 진단은 요청의 생성 방식을 바꾸지 않으며, 비교가 준비되지 않아도 본 요청을 막거나 실패시키지 않습니다. OpenAI 문서는 진단 결과가 최선 노력 방식이며 모든 캐시 미스를 분류하지 못할 수 있다고 설명합니다. 따라서 “진단을 켜면 응답이 몇 퍼센트 빨라진다”는 수치를 만들면 안 됩니다.

비용 효과는 공식 단가의 상대 배수로 계산할 수 있습니다. OpenAI 가이드의 계산 예시는 일반 입력을 1로 둘 때 캐시 읽기를 0.1, 캐시 쓰기를 1.25로 반영합니다. 공통 접두부가 12,000토큰이고 총 10회 요청에서 첫 요청이 전부 캐시에 기록되고 다음 9회가 전부 재사용된다고 가정해 보겠습니다. 캐시가 없으면 입력 토큰 등가 비용은 12,000×10=120,000입니다. 캐시를 쓰면 12,000×1.25 + 12,000×0.1×9 = 25,800이므로 이 가정에서는 공통 접두부 입력 비용이 약 78.5% 줄어듭니다.

이는 실측이나 보장된 절감률이 아니라 완전 적중과 같은 처리 등급을 가정한 계산입니다. 실제 총비용에는 새 입력, 출력, 도구, 미스와 재시도를 포함해야 합니다. 모델·처리 등급·컨텍스트 길이에 따라 단가도 달라지므로 사용량과 전체 비용, p50·p95 지연시간을 함께 봅니다.

Python으로 첫 캐시 진단 요청 보내기

아래는 두 번째 요청이 첫 번째 응답을 대화와 진단의 기준으로 모두 사용하는 최소 예시입니다. API 키는 코드에 넣지 말고 OPENAI_API_KEY 환경 변수로 관리합니다. 고정 지시문은 실제로 1,024토큰 이상의 유용한 정책·예시 문서라고 가정합니다.

from openai import OpenAI

client = OpenAI()
policy = open("support-policy.txt", encoding="utf-8").read()

first = client.responses.create(
    model="gpt-5.6",
    instructions=policy,
    input="환불 규정을 세 문장으로 요약해 주세요.",
    prompt_cache_key="support-policy:v3",
)

second = client.responses.create(
    model="gpt-5.6",
    instructions=policy,
    previous_response_id=first.id,
    input="세일 상품에도 같은 규정이 적용되나요?",
    prompt_cache_key="support-policy:v3",
    prompt_cache_options={
        "comparison_response_id": first.id,
    },
)

diag = second.prompt_cache_diagnostics
print(diag)
print(second.usage.input_tokens_details.cached_tokens)

스트리밍 요청에서는 완료 이벤트인 response.completed의 event.response.prompt_cache_diagnostics를 읽습니다. 첫 턴에는 비교할 응답이 없으므로 비교 ID를 빼고, 이후 턴부터 직전의 완료 응답 ID를 보관해 넘기면 됩니다. 고장 수정 전후를 비교할 때는 같은 기준 ID를 유지해야 변화의 효과를 보기 쉽습니다.

결과 유형과 캐시 미스 원인 8가지

prompt_cache_diagnostics.type은 네 가지 결과를 반환할 수 있습니다. cache_hit이면 비교에서 미스가 감지되지 않았다는 뜻이지만, 요청 전체가 캐시됐다는 뜻은 아닙니다. 실제 재사용량은 반드시 사용량 필드의 cached_tokens로 확인합니다. cache_miss에는 원인과 놓친 토큰 추정값이 따라올 수 있습니다. comparison_response_not_found는 기준 기록이 없거나 만료된 경우이고, unavailable은 결론을 낼 수 없거나 모델이 지원하지 않는 경우입니다.

진단은 첫 번째 분류 원인만 보고하므로 하나를 고친 뒤 같은 기준으로 다시 확인합니다. 대화 압축처럼 의도적인 변화는 미스가 생겨도 전체 입력과 총비용을 더 낮출 수 있습니다.

운영에 적용하는 단계별 방법

1. 기준 워크로드를 고릅니다. 1,024토큰 이상의 고정 지시문을 반복하는 흐름을 선택합니다.
2. 고정 부분을 앞에 둡니다. 정책·도구·예시를 먼저, 질문·시간·요청 ID는 뒤에 둡니다.
3. 키 정책을 정합니다. support-policy:v3처럼 버전을 나타내는 안정적 키를 씁니다.
4. 기준 응답 ID를 저장합니다. 최근 완료된 응답과 상태·시각을 함께 보관합니다.
5. 진단과 사용량을 함께 기록합니다. 원인, 토큰, 모델, 등급, 지연시간을 한 로그에 남깁니다.
6. 한 번에 한 원인만 고칩니다. 여러 설정을 동시에 바꾸지 않습니다.
7. 여러 요청으로 확인합니다. 최소 30회의 비용, p50·p95, 미스율을 봅니다.
8. 배포 전후를 비교합니다. 프롬프트와 도구 스키마 버전을 함께 기록합니다.

직접 재현하는 성능 테스트 절차

독립 공개 평가는 아직 확인되지 않았습니다. 다음 절차는 답변 품질이 아니라 캐시 미스 원인과 비용·지연시간 회귀를 찾는 능력을 확인합니다.

1. 민감정보를 제거한 대표 요청 30개와 2,000~12,000토큰의 고정 접두부를 준비합니다.
2. 모델, 추론 강도, verbosity, 도구 순서, 처리 등급, 지역, 동시성을 고정합니다.
3. 진단을 끈 기준군과 같은 요청에 진단을 켠 비교군을 각각 3회 이상 반복합니다.
4. 의도적으로 키, 도구 순서, 모델, 입력 앞부분을 하나씩 바꿔 올바른 원인 코드가 나오는지 확인합니다.
5. 각 요청의 cached_tokens, cache_write_tokens, type, reason, p50·p95 지연시간, 전체 비용을 저장합니다.
6. 원인을 수정한 뒤 같은 비교 응답 ID로 다시 요청하고 놓친 토큰이 줄었는지 확인합니다.
7. unavailable과 만료 응답 비율을 별도로 집계해 진단 가능성 자체도 측정합니다.
8. 최종적으로 월간 입력 비용 절감액과 장애 분석 시간을 계산해 운영 가치가 있는지 판단합니다.

배포 전 체크리스트

• GPT-5.6 이상 지원 모델과 Responses API를 사용하고 있는가?
• 공통 접두부가 최소 1,024토큰을 충족하는가?
• 변하는 시간·사용자 질문·요청 ID를 고정 지시문 뒤에 배치했는가?
• prompt_cache_key가 요청마다 무작위로 바뀌지 않는가?
• 모델, 서비스 등급, 추론 강도, verbosity, 도구 순서를 로그에 남기는가?
• 최근 완료된 같은 조직의 응답을 비교 기준으로 사용하는가?
• cache_hit만 믿지 않고 실제 cached_tokens를 확인하는가?
• 추가 기준 요청과 재시도의 정상 비용을 예산에 포함했는가?
• 진단 기록의 짧은 보관 기간을 장애 대응에 반영했는가?

자주 생기는 실패와 해결법

comparison_response_not_found가 계속 나온다

기준 응답이 오래됐거나 완료되지 않았거나 다른 조직에서 만들어졌을 수 있습니다. 최근에 정상 완료된 같은 조직의 응답을 선택하고, ID 저장 시점과 상태를 함께 기록합니다. 응답 본문이 조회된다고 진단 기록도 남아 있다는 뜻은 아닙니다.

cache_hit인데 cached_tokens가 기대보다 작다

cache_hit은 비교 대상 접두부에서 미스가 감지되지 않았다는 뜻이지 전체 입력이 재사용됐다는 뜻은 아닙니다. 예를 들어 2,500토큰 요청에서 기준의 2,000토큰만 재사용되고 500토큰은 새 입력일 수 있습니다. 실제 과금 분석은 사용량 필드로 합니다.

원인을 고쳤는데 또 cache_miss가 나온다

진단은 첫 분류 원인만 알려줍니다. 키 변경을 고친 다음에는 도구 순서나 추론 강도 변화가 다음 원인으로 나타날 수 있습니다. 한 항목씩 수정하고 같은 기준으로 반복 비교합니다.

prompt_cache_key를 같게 했는데 적중하지 않는다

키는 관련 요청의 라우팅을 도울 뿐 캐시 적중을 보장하지 않습니다. 앞부분 토큰, 모델, 도구, 스키마, 서비스 등급을 함께 확인합니다. 트래픽이 다른 머신으로 넘치는 상황에서는 같은 키여도 첫 요청이 미스가 될 수 있습니다.

진단을 켠 뒤 응답이 실패할까 걱정된다

진단은 본 요청을 막지 않습니다. 비교가 준비되지 않으면 unavailable일 수 있으므로 진단 필드가 없어도 정상 응답을 처리합니다.

자주 묻는 질문

Prompt Cache Diagnostics는 Chat Completions API에서도 되나요?

공식 공개 범위는 GPT-5.6 이상 지원 모델의 Responses API입니다. 다른 API에서 같은 필드가 동작한다고 가정하지 말고 공식 변경 로그와 API 참조를 확인해야 합니다.

진단을 켜면 추가 요금이 붙나요?

진단 자체는 추가 비용이 없고 별도 비율 제한도 사용하지 않습니다. 다만 비교를 위해 새 기준 요청을 만들거나 수정 확인용 요청을 반복하면 그 요청은 일반 API 단가와 제한을 적용받습니다.

comparison_response_id가 이전 내용을 다시 불러오나요?

아닙니다. 비교 기준만 선택하며 이전 응답의 대화 내용을 불러오거나 저장하지 않습니다. 대화 연결이 필요하면 previous_response_id를 별도로 사용합니다.

Zero Data Retention 조직에서도 사용할 수 있나요?

공식 문서상 호환됩니다. 이 기능을 위해 원문 프롬프트나 모델 출력은 저장하지 않고, 구성 메타데이터·토큰 추정·캐시 민감 콘텐츠 비교용 해시가 조직 범위에서 짧은 기간 유지됩니다.

이 글의 비용 절감률은 직접 테스트 결과인가요?

아닙니다. 78.5% 예시는 공식 가이드의 캐시 읽기·쓰기 배수에 12,000토큰, 10회 요청, 완전 적중이라는 가정을 적용한 계산입니다. 실제 서비스의 지연시간과 비용은 제시한 재현 절차로 측정해야 합니다.

공식 확인 자료

• OpenAI API 변경 로그 — Prompt Cache Diagnostics GA 발표
• OpenAI 공식 Prompt Cache Diagnostics 가이드 — 필드·원인 코드·한계
• OpenAI 공식 Prompt Caching 가이드 — 캐시 동작·최적화·비용 계산
• OpenAI Responses API 요청 참조 — prompt_cache_options와 응답 필드
• OpenAI API 공식 가격표 — 입력·캐시 읽기·캐시 쓰기 단가
• OpenAI 공식 대화 상태 가이드 — previous_response_id 사용법

Prompt Cache Diagnostics는 자동 적중 기능이 아니라 재사용이 끊긴 이유를 추적하는 운영 도구입니다. 같은 모델과 설정, 안정적인 키, 변하지 않는 접두부를 유지하고 진단과 사용량을 함께 보세요. 긴 프롬프트를 반복하는 서비스의 최종 판단은 자신의 요청으로 측정한 비용과 p95 지연시간에 두는 것이 맞습니다.

공식 발표일: 2026년 9월 8일 · 확인일: 2026년 9월 9일

OpenAI가 이미지 생성·편집용 API 모델 gpt-image-2.5-sunburst와 gpt-image-2.5-flare를 공개했습니다. 두 모델은 Image API와 Responses API의 이미지 생성 도구에서 바로 선택할 수 있습니다. 핵심은 단순히 “새 이미지 모델이 나왔다”가 아닙니다. 빠른 대량 생성은 Flare, 여러 번 수정해도 원본의 인물·구도·제품을 지키는 정밀 편집은 Sunburst로 역할이 분리됐다는 점입니다.

이 글은 출시 직후의 공식 자료를 기준으로 모델 ID, 가격, 실제 성능 주장과 측정 한계, API 사용법, 재현 가능한 비교 절차를 정리합니다. 필자는 이번 글을 위해 두 API를 직접 호출해 속도나 품질을 측정하지 않았습니다. 따라서 체감 후기를 사실처럼 쓰지 않고 OpenAI 제공사 측정값, 공개된 안전성 평가, 외부 초기 평가 발언을 구분해 설명합니다.

GPT Image 2.5에서 먼저 알아야 할 7가지

1. 정밀 편집 중심 모델은 gpt-image-2.5-sunburst입니다.
2. 빠른 일상 생성 중심 모델은 gpt-image-2.5-flare입니다.
3. 고정 버전이 필요하면 각각 gpt-image-2.5-sunburst-2026-09-08, gpt-image-2.5-flare-2026-09-08 스냅샷을 사용할 수 있습니다.
4. 텍스트와 이미지를 입력으로 받고 이미지를 출력합니다. 오디오와 비디오는 지원 대상이 아닙니다.
5. 품질 설정은 low, medium, high, xhigh, max, auto를 지원합니다.
6. 두 모델의 토큰 단가는 같지만 실제 이미지 한 장의 비용은 사용 토큰과 품질·크기에 따라 달라질 수 있습니다.
7. OpenAI는 Flare가 GPT Image 2보다 높은 품질을 내면서 지연시간은 50% 낮다고 밝혔습니다. 이는 제공사 측정값이며 독립 표준 벤치마크 결과와는 구분해야 합니다.

Sunburst와 Flare, 어떤 차이가 있나

공식 모델 카드에서 Sunburst는 “이미지 생성과 편집을 위한 가장 유능한 모델”, Flare는 “빠르고 품질이 높은 일상 이미지 생성 모델”로 소개됩니다. 같은 가격표를 쓰지만 목표가 다릅니다. 전자상거래 상세 페이지의 제품만 남기고 배경을 바꾸거나, 인물의 얼굴과 의상을 보존하면서 여러 장면을 만드는 작업처럼 수정 정확도가 중요한 경우에는 Sunburst가 우선입니다. 반면 소셜 콘텐츠 시안, 검색 결과용 썸네일, 아이디어 스케치처럼 빠르게 여러 후보를 확인해야 할 때는 Flare가 합리적입니다.

기본 모델 이름은 시간이 지나며 동작이 갱신될 수 있습니다. 생성 품질이 사업 지표나 승인 절차와 연결된 서비스라면 개발 중에는 기본 ID를 써도 되지만, 운영 배포와 회귀 테스트에서는 날짜가 붙은 스냅샷으로 고정하는 편이 안전합니다.

실제 성능: 확인된 수치와 아직 모르는 것

출시 글에서 OpenAI는 Images 2.5가 Images 2.0보다 이미지 생성 지연시간을 최대 50% 줄였다고 설명합니다. API 항목에서는 Flare가 GPT Image 2보다 높은 품질을 제공하면서 지연시간이 50% 낮다고 적었습니다. 또 초기 고객인 Manus 평가팀은 자체 평가에서 Flare가 GPT Image 2보다 2~4배 빠르면서 높은 품질을 보였다고 밝혔습니다. 다만 이 발언에는 요청 수, 해상도, 품질 설정, 지역, 동시성 같은 세부 방법론이 공개되지 않았으므로 독립 표준 벤치마크로 보기는 어렵습니다.

시스템 카드에는 시각 품질이 아니라 안전성 스택의 자동 평가가 공개돼 있습니다. 모든 정책 범주를 대상으로 위반 이미지를 만들도록 설계한 공격적 프롬프트 세트에서 최종적으로 사용자에게 제시된 유해 이미지 비율은 Sunburst 1.09%, Flare 1.41%, Images 2.0 기준선 1.64%였습니다. OpenAI는 이 테스트가 실제 트래픽에서 위반 요청이 나타나는 빈도를 대표하지 않으며, 자동 라벨 오류와 범주별 표본 수 차이도 있다고 명시합니다. 따라서 이 수치는 “화질 점수”가 아니라 고정된 적대적 테스트 세트에서 안전 장치가 놓친 비율입니다.

출시 시점에 프롬프트 준수, 문자 렌더링, 인물 동일성, 편집 영역 보존을 동일 조건으로 비교한 신뢰할 만한 독립 공개 평가 자료는 아직 확인하기 어렵습니다. 그러므로 “모든 작업에서 Sunburst가 최고”, “Flare가 항상 두 배 빠르다”라고 단정하면 안 됩니다. 서비스에 넣기 전에는 아래의 재현 절차로 자신의 이미지 유형을 측정해야 합니다.

가격표와 이미지 한 장의 실제 비용 계산

두 모델은 같은 토큰 단가를 사용합니다. 텍스트 입력은 100만 토큰당 5달러, 캐시된 텍스트 입력은 1.25달러입니다. 이미지 입력은 100만 토큰당 8달러, 캐시된 이미지 입력은 2달러, 이미지 출력은 30달러입니다. 이미지 모델은 텍스트를 출력하지 않으므로 텍스트 출력 요금은 없습니다.

단가가 같아도 한 장 가격이 같다는 뜻은 아닙니다. 공식 가이드는 모델과 품질 설정에 따라 토큰 사용량이 달라질 수 있으므로 응답의 usage를 확인하라고 안내합니다. 총비용은 “텍스트 입력 토큰×5달러/100만 + 이미지 입력 토큰×8달러/100만 + 이미지 출력 토큰×30달러/100만”으로 계산합니다. Responses API에서는 이미지 생성 비용 외에 상위 텍스트 모델의 토큰 비용도 더해집니다. 스트리밍에서 partial_images를 요청하면 부분 이미지 한 장마다 이미지 출력 토큰 100개가 추가됩니다.

운영 예산은 한 번의 성공 생성 비용보다 승인된 결과 한 장을 얻기까지의 재시도 횟수가 더 중요합니다. Flare가 첫 시안을 빠르게 많이 만들더라도 수정 실패로 네 번 재생성하면 비용이 커질 수 있습니다. 반대로 Sunburst가 느려도 편집 영역을 잘 보존해 재시도가 줄면 최종 결과당 비용이 낮아질 수 있습니다.

Image API로 첫 이미지 생성하기

한 번의 프롬프트로 생성하거나 편집할 때는 Image API가 단순합니다. 공식 Python SDK의 최소 형태는 다음과 같습니다. API 키는 코드에 직접 넣지 말고 OPENAI_API_KEY 환경 변수에 저장합니다.

from openai import OpenAI
import base64

client = OpenAI()

result = client.images.generate(
    model="gpt-image-2.5-flare",
    prompt=(
        "한국의 작은 로스터리에서 바리스타가 새 메뉴를 준비하는 "
        "자연스러운 편집 사진, 부드러운 아침빛, 글자와 로고 없음"
    ),
)

image_bytes = base64.b64decode(result.data[0].b64_json)
with open("cafe-concept.png", "wb") as f:
    f.write(image_bytes)

기획 단계에서는 Flare로 후보를 만들고, 채택한 시안을 정밀하게 다듬을 때 Sunburst로 전환하는 방식이 실용적입니다. 단, 모델을 바꾸면 동일 프롬프트라도 구도와 세부 표현이 달라질 수 있으므로 완성 단계에서 처음부터 다시 비교해야 합니다. 조직 설정에 따라 GPT Image 모델 사용 전에 API Organization Verification이 필요할 수도 있습니다.

Responses API가 더 적합한 경우

대화형 편집, 여러 번의 수정, 텍스트 모델의 판단과 이미지 생성을 한 흐름으로 묶고 싶다면 Responses API가 맞습니다. 상위 모델을 지정하고 image_generation 도구의 model에 Sunburst 또는 Flare를 넣습니다. 이전 응답 ID를 이어 주면 “배경만 더 따뜻하게”, “제품 모양은 그대로 두고 그림자만 줄여줘” 같은 다단계 편집 흐름을 만들 수 있습니다.

response = client.responses.create(
    model="gpt-6-astra",
    input="친근한 AI 캐릭터와 한국 직장인이 협업하는 가로형 사진을 만들어줘",
    tools=[{
        "type": "image_generation",
        "model": "gpt-image-2.5-sunburst"
    }],
)

멀티턴 편집에서는 매 요청마다 유지해야 할 조건을 짧게 반복하는 편이 좋습니다. 예를 들어 “인물의 얼굴·포즈·의상과 카메라 구도는 유지하고 배경 조명만 바꾼다”처럼 변경 대상과 불변 조건을 분리합니다. 입력 파일 ID를 이용한 이미지 전달, 대화 문맥 유지, 도구 호출을 함께 쓰는 제품이라면 Image API보다 Responses API의 이점이 큽니다.

업무별 권장 선택법

처음부터 하나의 모델로 모든 작업을 통일할 필요는 없습니다. 라우팅 규칙을 “초안은 Flare, 사람이 고른 결과의 정밀 수정은 Sunburst”로 시작한 뒤 실제 승인률과 비용으로 조정하면 됩니다.

직접 재현하는 성능 테스트 절차

공개된 품질 벤치마크가 충분하지 않으므로 같은 입력, 같은 출력 크기, 같은 품질 설정, 같은 지역과 시간대에서 비교해야 합니다. 최소 30개 프롬프트를 생성 10개, 제품 편집 10개, 인물·스타일 보존 10개로 나누고 각 조건을 3회 이상 반복합니다.

1. 민감정보를 제거한 실제 업무 프롬프트 30~50개를 고정합니다.
2. Flare, Sunburst, 기존 GPT Image 2에 동일한 프롬프트와 참조 이미지를 제공합니다.
3. quality, size, 출력 형식, 동시성, 재시도 정책을 같게 맞춥니다.
4. 요청 시작부터 최종 응답까지의 p50·p95 지연시간을 기록합니다.
5. 응답 usage의 텍스트·이미지 입력·출력 토큰과 요청별 비용을 저장합니다.
6. 세 명 이상의 평가자가 모델 이름을 가린 상태에서 프롬프트 준수, 편집 영역 보존, 인물 동일성, 문자 오류를 1~5점으로 채점합니다.
7. 한 장 비용이 아니라 승인 결과당 비용과 평균 재시도 횟수를 계산합니다.
8. 평균만 보지 말고 실패율, 중앙값, p95, 안전 필터 차단 비율을 함께 비교합니다.

실전 적용 체크리스트

• 초안과 정밀 편집의 모델 라우팅 기준을 문서화했는가?
• 운영에서는 날짜가 붙은 스냅샷으로 회귀 테스트했는가?
• 모든 요청의 usage, 지연시간, 오류 코드, 재시도 횟수를 저장하는가?
• 참조 이미지에 개인정보·초상권·저작권 문제가 없는가?
• 변경 대상과 유지 대상을 프롬프트에서 분리했는가?
• auto만 쓰지 않고 주요 품질 단계의 비용을 비교했는가?
• 부분 이미지 스트리밍의 추가 토큰 비용을 반영했는가?
• 사람이 최종 검수해야 하는 브랜드·인물·제품 영역을 지정했는가?
• C2PA 메타데이터와 워터마크 정책을 후처리 과정까지 확인했는가?

자주 생기는 실패와 해결법

모델 이름을 찾을 수 없다는 오류

계정과 조직의 접근 상태, SDK 버전, 모델 ID 철자를 확인합니다. 조직에 따라 API Organization Verification이 필요할 수 있습니다. 기본 ID가 불안정하다면 날짜가 붙은 2026-09-08 스냅샷으로 재현합니다.

편집하지 말아야 할 부분까지 바뀌는 문제

“배경을 바꿔줘”만 쓰지 말고 유지할 요소를 구체적으로 적습니다. 인물 얼굴, 포즈, 의상, 제품 실루엣, 카메라 위치를 불변 조건으로 나열하고 한 번에 한 속성만 수정합니다. 승인용 편집은 Sunburst부터 비교합니다.

예상보다 비용이 커지는 문제

토큰 단가만 보고 한 장 가격을 고정값으로 가정하면 안 됩니다. 응답의 사용량과 부분 이미지 수, 참조 이미지 입력, 상위 Responses 모델 비용, 재시도까지 합산합니다. 품질을 높이기 전에 채택률이 실제로 개선되는지 확인합니다.

공식 속도 수치가 우리 서비스에서 재현되지 않는 문제

공식 50% 수치는 제공사 측정값입니다. 네트워크 거리, 계정 등급, 동시성, 이미지 크기와 품질이 다르면 결과도 달라집니다. 같은 리전과 조건에서 최소 3회 이상 반복하고 평균보다 p95를 우선 확인합니다.

문자와 로고가 깨지는 문제

이미지 안의 긴 문구는 후편집 도구에서 넣는 것이 안전합니다. 생성 단계에는 글자가 들어갈 빈 공간과 구조만 요청하고, 정확한 상표나 고지 문구는 디자인 파이프라인에서 검수해 삽입합니다.

자주 묻는 질문

Flare와 Sunburst의 토큰 가격은 다른가요?

공식 문서상 토큰 단가는 같습니다. 하지만 모델과 품질 설정에 따라 실제 토큰 사용량이 달라질 수 있으므로 이미지 한 장의 총비용이 항상 같다는 뜻은 아닙니다.

기존 GPT Image 2를 바로 교체해도 되나요?

신규 통합은 2.5 모델로 검토할 만하지만 운영 교체는 회귀 테스트 후 진행해야 합니다. 동일 프롬프트, 참조 이미지, 크기, 품질로 속도·승인률·결과당 비용을 비교하세요.

가장 빠른 모델은 무엇인가요?

공식 설명에서는 Flare가 빠른 일상 이미지 생성용입니다. 다만 실제 지연시간은 설정과 계정 환경에 따라 달라지므로 자신의 p50·p95 측정이 필요합니다.

정밀한 제품 사진 편집에는 무엇이 맞나요?

제품 외형과 구도를 보존해야 한다면 Sunburst를 먼저 시험하는 편이 맞습니다. 초안 탐색을 Flare로 하고 최종 수정만 Sunburst로 처리하는 혼합 방식도 유용합니다.

이 글의 성능 평가는 직접 테스트인가요?

아닙니다. 공식 발표와 시스템 카드, 공개된 초기 고객 발언을 구분해 정리했습니다. 직접 측정값을 만들지 않았으며, 독자가 동일 조건으로 검증할 수 있는 절차를 제시했습니다.

공식 확인 자료

• OpenAI API 변경 로그 — 2026년 9월 8일 출시 항목
• OpenAI API 모델 카드 — GPT-Image-2.5 Sunburst
• OpenAI API 모델 카드 — GPT-Image-2.5 Flare
• OpenAI 이미지 생성 API 가이드 — API 선택·사용법·비용 계산
• OpenAI API 공식 가격표
• OpenAI 제품 발표 — ChatGPT Images 2.5 소개
• OpenAI Deployment Safety Hub — ChatGPT Images 2.5 시스템 카드

정리하면 Flare는 속도와 반복 탐색, Sunburst는 편집 정밀도와 완성도에 초점이 맞춰진 API 모델입니다. 출시 자료의 50% 지연시간 감소는 매력적이지만 제공사 측정값이라는 점을 기억해야 합니다. 모델 이름만 바꾸기보다 실제 업무 프롬프트로 승인률, p95 지연시간, 재시도, 사용 토큰을 함께 측정하면 어느 모델이 더 싸고 빠른지 제대로 판단할 수 있습니다.

회의 한 시간을 녹음했는데 몇 초 만에 화자별 자막과 단어별 시간이 나온다면, 회의록·상담 분석·영상 자막 제작의 작업 방식이 크게 달라집니다. Microsoft는 2026년 9월 3일 MAI-Transcribe-2를 Microsoft Foundry의 Azure Speech에서 공개 프리뷰로 출시했습니다. 모델 식별자는 MAI-Transcribe-2이며, 한국어를 포함한 60개 언어를 지원합니다.

이번 세대의 핵심은 정확도만이 아닙니다. 여러 사람의 발화를 나누는 화자 분리, 단어별 타임스탬프, 전문용어 힌트, 말버릇을 남기는 원문형과 다듬어진 문장형의 선택이 한 API에 들어왔습니다. 출시 프로모션 가격은 2026년 12월 31일까지 오디오 1시간당 0.10달러입니다.

다만 “세계에서 가장 정확하고 빠르고 저렴하다”는 Microsoft의 표현을 그대로 결론으로 받아들이면 곤란합니다. 독립 평가에서는 정확도 2위, 속도 4위권이며, 더 싼 모델도 있습니다. 이 글은 Microsoft 공식 문서와 독립 Artificial Analysis 측정값을 구분하고, 한국어 업무에 도입하기 전에 무엇을 직접 재현해야 하는지까지 정리합니다.

MAI-Transcribe-2에서 달라진 핵심

MAI-Transcribe-2는 파일 기반 음성을 텍스트로 바꾸는 비스트리밍 음성 인식 모델입니다. Microsoft Learn은 현재 기능을 공개 프리뷰로 표시하며 서비스 수준 계약(SLA)이 없고 운영 워크로드에 권장되지 않는다고 안내합니다. 따라서 새 프로젝트의 제한된 구간에서 먼저 시험하고, 장애 시 기존 음성 인식 모델로 돌아갈 경로를 마련해야 합니다.

• 60개 언어: 이전 MAI-Transcribe-1.5의 43개 언어에서 확대됐고 한국어 ko도 포함됩니다.
• 화자 분리: 발화 구간마다 화자 번호와 시작·지속 시간을 반환합니다.
• 단어별 타임스탬프: 자막 정렬, 특정 단어 검색, 오디오 편집에 쓸 수 있습니다.
• 키워드 바이어싱: 제품명·인명·약어·의학 및 기술 용어를 힌트로 제공합니다.
• 두 가지 문체: verbatim은 추임새와 말실수를 남기고, clean은 읽기 좋게 다듬습니다.
• 자동 언어 감지: 언어를 지정하지 않아도 감지하며 일부 혼합 언어 대화의 코드 스위칭을 지원합니다.

회의록처럼 읽을 문서에는 clean, 콜센터 품질 검수나 법적 기록처럼 실제 발화가 중요한 경우에는 기본값인 verbatim이 적합합니다. 키워드 목록은 정답을 강제로 삽입하는 기능이 아니라 인식 확률을 높이는 힌트이므로, 사람이 최종 원문을 확인해야 합니다.

실제 성능: 독립 AA-WER 2.0%의 의미

가장 참고할 만한 외부 자료는 Artificial Analysis의 비스트리밍 음성 인식 리더보드입니다. 이 평가는 약 8시간 분량의 세 데이터셋을 사용합니다. AA-AgentTalk 50%, 정제된 VoxPopuli 25%, 정제된 Earnings22 25%를 오디오 길이로 가중해 단어 오류율(AA-WER)을 계산합니다. WER은 낮을수록 좋고, 속도 계수는 오디오 몇 초를 처리 시간 1초에 변환하는지를 뜻하므로 높을수록 좋습니다.

2026년 9월 7일 확인 기준 정확도 1위는 1.7%의 Alibaba Fun-Realtime-ASR-preview이고, MAI-Transcribe-2는 2.0%로 2위입니다. 속도는 Nova-3 606.1배, Telnyx 경유 Nova-3 470.7배, Nova-2 442.9배가 더 높습니다. 따라서 MAI-Transcribe-2의 강점은 모든 단일 지표 1위가 아니라 낮은 오류율·높은 배치 속도·낮은 가격을 동시에 만족하는 균형에 있습니다.

이 수치는 영어 중심의 비스트리밍 시험이며 10분 오디오에서 최근 7일 중앙 속도 계수를 산출합니다. 짧은 전화 음성, 실시간 부분 자막, 한국어 방언, 여러 사람이 겹쳐 말하는 회의 성능을 그대로 보장하지 않습니다. 일부 경쟁 모델은 파일 길이 제한 때문에 약 9분 또는 30초로 나눠 평가됐으므로, 완전히 같은 요청 경로라고 단정해서도 안 됩니다.

FLEURS 1위와 서로 다른 두 WER 수치

Microsoft 모델 카드는 FLEURS 테스트 분할에서 언어를 미리 알려주지 않고 60개 언어를 자동 추론했다고 설명합니다. Microsoft 뉴스룸은 이 조건의 평균 WER을 5.2%라고 발표합니다. 반면 공식 모델 소개 페이지의 이전 세대 비교표는 “상위 25개 언어 평균”을 3.4%로 적고, MAI-Transcribe-1.5는 3.7%로 표시합니다.

3.4%와 5.2%는 충돌하는 성능표가 아니라 평가 언어 집합이 다릅니다. 잘 지원되는 25개 언어의 평균이 전체 60개보다 낮은 것은 자연스럽습니다. 한국어 한 항목의 WER이나 방언별 결과는 공식 자료에 따로 공개되지 않았으므로, “한국어도 3.4%”라고 쓰면 안 됩니다.

속도와 비용은 얼마나 개선됐나

Microsoft 공식 모델 페이지는 1시간 오디오의 모델 추론 시간을 약 10초로 제시합니다. MAI-Transcribe-1.5의 약 20초보다 두 배 빠른 제공사 측정값입니다. 독립 Artificial Analysis의 속도 계수도 195.1배에서 410.7배로 약 2.1배 높아져 방향은 일치합니다. Microsoft는 GPT Transcribe보다 10배, Scribe v2보다 7배, Gemini 3.5 Transcribe보다 5배 빠르다고 설명하지만, 해당 수치는 Artificial Analysis의 비스트리밍 측정 조건을 전제로 이해해야 합니다.

출시 가격은 2026년 12월 31일까지 오디오 1시간당 0.10달러입니다. 1,000분으로 환산하면 약 1.67달러이며, 이전 세대의 시간당 0.36달러보다 72.2% 낮습니다. 매달 10,000시간을 처리한다면 단순 API 비용은 프로모션 기간에 약 1,000달러입니다. 재시도, 저장, 네트워크, 후처리, 사람 검수 비용은 별도입니다.

이 계산은 공개된 단가만 곱한 값입니다. 프로모션 종료 뒤 가격은 공식 자료에서 확인해야 하며, 현재 가격을 영구 단가로 예산에 고정하면 안 됩니다. 또한 더 낮은 단가의 모델도 존재하므로 “시장 최저가”라는 주장은 비교 대상과 무료·오픈웨이트 실행 비용을 어떻게 잡느냐에 따라 달라집니다.

API 사용법과 파일 제한

Microsoft Learn 사용 문서에 따르면 Microsoft Foundry Speech 리소스를 만들고 Fast Transcription API의 enhancedMode를 켠 뒤 모델 이름을 지정합니다. 요청 주소는 다음 형식입니다.

POST https://{resource}.cognitiveservices.azure.com/
speechtotext/transcriptions:transcribe?api-version=2025-10-15

{
  "enhancedMode": {
    "enabled": true,
    "model": "MAI-Transcribe-2",
    "modelOptions": {
      "timestamps": "word",
      "transcribeStyle": "clean"
    }
  },
  "diarization": {"enabled": true},
  "phraseList": {
    "phrases": ["MAI-Transcribe-2", "Microsoft Foundry"]
  }
}

지원 파일은 WAV, MP3, FLAC이며 모델 카드 기준 최대 300MB 또는 2시간입니다. 문서는 영어, 한국어, 일본어, 중국어 등을 포함한 60개 언어를 열거합니다. 모델 카드는 전 세계에서 접근 가능하다고 설명하지만 요청은 East US, West US, West US 2, North Europe, Central India, Southeast Asia로 라우팅됩니다. 개인정보와 데이터 거주 요건이 있는 조직은 실제 배포 리전과 계약 조건을 먼저 확인해야 합니다.

API 키는 코드나 로그에 넣지 말고 Azure Key Vault 또는 안전한 비밀 변수로 관리하세요. 의료·법률·인사 통화는 전사 결과가 그럴듯해도 사실 오류가 위험하므로, 타임스탬프로 원음과 빠르게 대조하는 검수 화면이 필요합니다.

화자 분리와 단어 타임스탬프 활용법

화자 분리를 켜면 응답의 각 구간에 speaker, offsetMilliseconds, durationMilliseconds가 포함됩니다. 단어 단위 타임스탬프를 함께 켜면 “누가 언제 어떤 단어를 말했는지”를 검색할 수 있습니다. 상담원과 고객의 발화 비율, 회의 참석자의 결정 문장, 자막의 클릭 재생, 개인정보가 나온 순간의 음소거에 활용할 수 있습니다.

1. 먼저 화자 분리 없이 원문 정확도를 측정합니다.
2. 그다음 같은 파일에서 화자 분리를 켜고 화자 변경 지점의 오류율을 기록합니다.
3. 단어 타임스탬프와 실제 음성 시작점의 차이를 30개 이상 표본으로 확인합니다.
4. 전문용어 목록을 넣기 전후로 해당 단어의 정답률과 일반 단어의 오인식을 함께 봅니다.
5. clean이 의미나 부정을 임의로 바꾸지 않는지 원문형과 비교합니다.

화자 번호는 실제 사람의 이름이 아닙니다. 여러 파일에 걸쳐 같은 화자를 자동으로 동일 인물로 유지한다고 가정해서도 안 됩니다. 긴 회의는 구간을 나눌 때 화자 번호가 달라질 수 있으므로, 별도의 화자 임베딩이나 수동 매핑 절차가 필요할 수 있습니다.

한국어 직접 재현 테스트 설계

이 글에서는 Azure 구독과 MAI-Transcribe-2 API 키로 실제 호출하지 않았습니다. 따라서 직접 사용 후기나 한국어 지연시간을 만들어내지 않았습니다. 아래는 독자가 자신의 환경에서 재현할 수 있는 시험 절차입니다.

1. 자료 구성: 표준어 회의, 전화 통화, 카페 소음, 겹침 발화, 숫자·영문 제품명, 한국어와 영어 혼합 등 6종을 각 10분 이상 준비합니다.
2. 정답 원고: 두 사람이 원음을 듣고 정답 전사를 만든 뒤 불일치를 합의합니다.
3. 동일 조건: MAI-Transcribe-2와 기존 모델에 같은 음원, 같은 파일 형식, 같은 리전에서 각 3회 이상 요청합니다.
4. 정확도: 전체 WER뿐 아니라 숫자, 고유명사, 부정 표현, 화자 변경 오류를 따로 집계합니다.
5. 지연: 업로드 시작부터 응답 완료까지 p50과 p95를 기록하고 서버 추론 시간과 구분합니다.
6. 비용: 성공 호출과 재시도를 모두 더해 최종 검수 완료된 오디오 1시간당 비용을 계산합니다.
7. 운영 품질: 429·5xx 오류율, 화자 수 정확도, 타임스탬프 오차, 사람이 수정한 시간을 측정합니다.

통과 기준은 제품마다 달라야 합니다. 자막 검색은 몇 개의 조사 오류를 허용할 수 있지만, 의료 기록의 약 이름이나 금융 상담의 금액은 단 한 번의 오류도 심각할 수 있습니다. WER 평균 하나보다 중요한 단어의 가중 오류율을 함께 보세요.

도입할 때 자주 실패하는 이유

첫째, 영어 독립 평가를 한국어 품질 보증으로 해석하는 경우입니다. AA-WER은 비교에 유용하지만 한국어 데이터가 아닙니다. 한국어 방언과 숫자·영문 혼합을 별도 시험해야 합니다.

둘째, 모델 추론 10초를 전체 응답시간으로 홍보하는 경우입니다. 업로드, 네트워크, 큐 대기, 후처리와 파일 길이에 따라 사용자가 느끼는 시간은 달라집니다.

셋째, 화자 분리 번호를 신원으로 저장하는 경우입니다. 번호는 구간을 나누는 표식일 뿐 실제 직원이나 고객의 이름을 인증하지 않습니다.

넷째, clean 결과만 보관하는 경우입니다. 읽기는 편하지만 추임새·말실수·반복이 사라질 수 있습니다. 규제나 분쟁 가능성이 있는 업무는 원음과 원문형 전사를 함께 보존하세요.

다섯째, 프로모션 단가를 장기 예산으로 확정하는 경우입니다. 0.10달러는 2026년 말까지의 한시 가격입니다. 종료 후 가격과 리전별 과금을 다시 확인해야 합니다.

여섯째, 프리뷰를 대체 경로 없이 핵심 업무에 연결하는 경우입니다. SLA가 없으므로 실패·할당량 초과·리전 장애 시 기존 모델 또는 사람 전사로 전환하는 절차가 필요합니다.

도입 전 체크리스트

• 공개 프리뷰이며 SLA가 없음을 이해했다.
• 한국어와 실제 녹음 환경으로 별도 평가 데이터를 만들었다.
• 전체 WER, 중요 단어, 화자 분리, 타임스탬프 오차를 따로 본다.
• 평균 속도뿐 아니라 업로드 포함 p50·p95를 기록한다.
• 프로모션 종료 뒤 가격을 예산 시나리오에 포함한다.
• 키와 음성 파일의 저장·접근·삭제 정책을 정했다.
• 의료·법률·금융 결과는 사람이 원음과 대조한다.
• 장애와 할당량 초과 시 대체 모델 또는 수동 절차가 있다.
• 동일 입력·동일 설정·반복 실행으로 경쟁 모델을 비교한다.

자주 묻는 질문

한국어를 지원하나요?

네. Microsoft Learn의 60개 언어 목록에 한국어 코드 ko가 포함됩니다. 다만 한국어 전용 WER은 공개되지 않았으므로 실제 음원으로 검증해야 합니다.

실시간 자막에 바로 쓸 수 있나요?

이번 공개 수치와 Artificial Analysis 결과는 주로 파일 기반 비스트리밍 처리입니다. 실시간 자막은 짧은 오디오 조각, 첫 부분 결과 지연, 결과 안정성, 네트워크 흔들림을 별도로 시험해야 합니다. Microsoft 문서는 Voice Live 입력 전사에도 모델을 설정할 수 있다고 설명하지만 같은 성능 수치를 보장하지는 않습니다.

화자 이름까지 자동으로 알 수 있나요?

화자 분리는 서로 다른 목소리를 번호로 나눌 뿐 사람의 실제 이름을 확인하는 신원 인증 기능은 아닙니다. 일정·참석자 정보와 연결하더라도 사람이 검증해야 합니다.

1시간을 정말 10초에 처리하나요?

Microsoft 모델 카드의 예시이자 제공사 측정값입니다. 독립 평가에서도 높은 처리 속도가 확인됐지만 파일 업로드와 대기 시간을 포함한 실제 지연은 리전과 부하에 따라 달라집니다.

가격은 계속 시간당 0.10달러인가요?

아닙니다. 발표 자료는 2026년 12월 31일까지의 한시 가격이라고 명시합니다. 이후 가격은 Azure의 최신 가격표에서 다시 확인하세요.

결론: 1위라는 문구보다 균형을 보자

MAI-Transcribe-2는 독립 AA-WER 2.0%로 정확도 2위, 410.7배 실시간 속도로 최상위권, 1,000분당 1.67달러라는 낮은 프로모션 비용을 동시에 기록했습니다. 이전 세대보다 언어 수가 43개에서 60개로 늘었고, 화자 분리와 단어별 타임스탬프까지 추가되어 회의·상담·자막 제작에 실질적인 변화가 있습니다.

반면 모든 지표에서 단독 1위는 아니며, 공개 자료만으로 한국어 현장 품질을 확정할 수 없습니다. 프리뷰와 한시 가격이라는 조건도 큽니다. 가장 안전한 도입 순서는 작은 한국어 데이터셋을 만들고, 동일 파일을 경쟁 모델과 세 번 이상 비교하고, 정확도·p95 지연·사람 수정 시간·최종 작업당 비용을 함께 계산한 뒤 제한적으로 확대하는 것입니다.

공식 확인 자료

• Microsoft Foundry 공식 출시 발표
• Microsoft AI 뉴스룸 발표
• Microsoft AI 모델 소개 및 이전 세대 비교
• MAI-Transcribe-2 공식 모델 카드
• Microsoft Learn API 사용 문서
• Microsoft Foundry 모델 카탈로그
• Artificial Analysis 독립 비스트리밍 STT 리더보드

Microsoft가 2026년 9월 4일 Microsoft Foundry에서 이미지 생성 모델 MAI-Image-2.6과 MAI-Image-2.6-Flash를 공개 프리뷰로 선보였습니다. 이번 업데이트의 핵심은 단순히 예쁜 한 장을 만드는 데 있지 않습니다. 최대 5장의 참조 이미지를 함께 쓰는 편집, 웹 검색을 활용하는 생성, 자동 종횡비 선택, 제품 사진과 인물·문자 표현 개선처럼 실제 제작 파이프라인에 필요한 기능을 한 묶음으로 제공한다는 점입니다.

다만 “Arena 2위”, “두 배 이상 빠름”이라는 문구만 보고 바로 운영 시스템을 바꾸면 곤란합니다. 품질 순위는 사람의 선호 투표이고, 속도·효율 수치는 Microsoft가 측정한 제공사 자료입니다. 공개 프리뷰라 서비스 수준 계약도 적용되지 않습니다. 이 글에서는 확인 가능한 모델 ID와 API, 가격, 벤치마크 조건, 문서 사이의 차이, 한국 팀이 직접 재현할 테스트 방법까지 구분해 정리합니다.

한눈에 보는 MAI-Image-2.6과 Flash

정리하면 품질을 최우선으로 하는 최종본에는 2.6, 빠른 반복과 대량 생성에는 Flash가 먼저 검토 대상입니다. Microsoft는 Flash가 2.6과 같은 생성·편집 기능을 더 빠르고 낮은 가격으로 제공한다고 설명합니다. 하지만 두 모델 모두 프리뷰이므로 장기 운영에서 버전 고정, 재현성, 장애 대응을 별도로 점검해야 합니다.

무엇이 달라졌나: 다섯 장 참조와 웹 그라운딩

가장 실무적인 변화는 다중 참조 편집입니다. 제품 모양, 캐릭터 얼굴, 브랜드 색, 촬영 구도, 배경 분위기처럼 서로 다른 기준 이미지를 최대 5장까지 한 요청에 넣을 수 있습니다. 쇼핑몰이라면 상품 정면 사진과 소재 확대 사진, 착용 분위기, 배경 레퍼런스를 함께 주고 한 번에 방향을 잡는 방식입니다. 한 장만 참고할 때보다 무엇을 보존하고 무엇을 바꿀지 명시하는 것이 중요합니다.

웹 그라운딩은 Bing Search에서 현재 정보를 가져와 프롬프트 해석에 보조 문맥으로 쓰는 기능입니다. 최근 장소나 실제 사물처럼 학습 시점 이후 정보가 필요한 장면에 도움이 될 수 있습니다. 그렇다고 결과 이미지가 사실 검증을 통과했다는 뜻은 아닙니다. 검색 결과 선택과 시각화 과정에서 오류가 생길 수 있으므로 뉴스, 의료, 법률, 제품 사양처럼 정확성이 중요한 이미지는 사람이 원문과 결과를 대조해야 합니다.

자동 종횡비를 켜면 모델이 프롬프트와 참조 이미지를 보고 출력 비율을 선택합니다. 빠른 탐색에는 편리하지만, 광고 매체 규격이 정해진 팀은 폭과 높이를 명시하는 편이 안전합니다. Microsoft Learn의 현재 API 문서는 폭·높이를 각각 최소 768픽셀로 두고, 총 픽셀 수를 1,048,576 이하로 제한합니다. 출력은 PNG이며 응답의 Base64 데이터를 디코딩해 저장합니다.

실제 성능: 공식 주장과 독립 Arena 결과를 분리해서 보기

현재 공개된 성능 근거는 두 종류입니다. 첫째는 Microsoft가 발표문에서 밝힌 속도와 효율 비교이고, 둘째는 독립 서비스 Arena의 익명 쌍대 비교 투표입니다. 두 자료는 측정 대상과 방법이 완전히 다르므로 한 표 안에서도 출처와 조건을 분리해 읽어야 합니다.

Arena 결과는 현재 확인 가능한 유용한 독립 신호입니다. 사용자가 두 결과를 익명으로 보고 선호를 고르는 방식이라 실제 사람이 느끼는 완성도를 반영합니다. 반면 프롬프트 분포가 각 회사의 업무와 같지 않고, 새 모델은 투표 수와 신뢰구간이 안정되는 데 시간이 필요합니다. 또한 1332점과 1382점의 차이가 특정 한국어 상품 사진에서 그대로 재현된다고 단정할 수 없습니다.

이 글에서는 실제 Azure 구독과 MAI API 키로 직접 호출하지 않았으므로 “직접 테스트” 결과를 제시하지 않습니다. 특히 발표문에는 Flash의 정확한 평균 지연시간, p95 지연, 요청당 출력 토큰, 표본 수가 공개되지 않았습니다. 따라서 아래 재현 절차로 같은 입력을 반복 실행하고 품질·지연·비용을 함께 기록하는 것이 더 믿을 만합니다.

가격 비교: Flash는 출력 단가가 절반

위 절감률은 Microsoft가 공개한 토큰 단가를 단순 계산한 값입니다. 요청 한 번의 실제 비용은 프롬프트 길이, 참조 이미지 수와 해상도, 출력 크기, 서비스가 계산한 이미지 토큰에 따라 달라집니다. “한 장에 얼마”로 바꾸려면 같은 설정으로 최소 30회 실행하고 Azure 비용·사용량 로그에서 총 입력·출력 비용을 나눠야 합니다. 환율, 세금, 리전, 계약 할인도 별도입니다.

작업 선택은 간단합니다. 최종 광고 한 장의 실패 비용이 큰 경우 2.6을, 수십 개 상품의 초안이나 개인화 변형을 만들 때는 Flash를 먼저 시험합니다. Flash로 후보를 넓게 만든 뒤 2.6으로 최종본을 다시 생성하는 2단계 운영도 가능하지만, 모델 간 결과가 완전히 이어진다는 보장은 없으므로 참조 이미지와 프롬프트를 함께 보관해야 합니다.

API 사용법과 현재 제한

Foundry 프로젝트에서 모델을 배포할 때 모델 이름은 MAI-Image-2.6 또는 MAI-Image-2.6-Flash, 버전은 2026-07-31, SKU는 Global Standard를 사용합니다. 생성 엔드포인트는 /mai/v1/images/generations, 편집 엔드포인트는 /mai/v1/images/edits입니다. 인증은 Azure API 키 또는 Microsoft Entra ID 토큰을 지원합니다.

POST https://<resource-name>.services.ai.azure.com/mai/v1/images/generations
Content-Type: application/json
api-key: <환경변수에서 읽은 키>

{
  "model": "<배포 이름>",
  "prompt": "따뜻한 자연광의 한국 소형 브랜드 제품 사진, 흰 배경",
  "width": 1024,
  "height": 1024,
  "auto_aspect_ratio": false,
  "web_grounding": false
}

키를 코드와 저장소에 직접 적지 말고 환경변수나 Azure Key Vault에서 읽어야 합니다. 편집 요청은 JPEG 또는 PNG를 multipart 형식으로 전송하며 결과는 PNG입니다. API 문서상 프롬프트 최대 문맥은 32,000토큰이고, 출력의 총 픽셀 수는 1,048,576 이하입니다. Microsoft 발표문은 1.5K 출력도 언급하지만 현재 Learn 문서의 픽셀 제한과 표현이 맞지 않습니다. 프리뷰 시점에는 실제 배포 화면과 API 오류 메시지를 최종 기준으로 삼고, 문서가 정리되기 전까지 1024×1024 안에서 검증하는 편이 안전합니다.

기본 RPM도 넉넉하지 않습니다. Learn 문서상 Global Standard는 무료 티어가 0 RPM이고, 티어 1은 2 RPM, 티어 2는 4 RPM, 티어 3은 6 RPM, 티어 4는 8 RPM, 티어 5는 10 RPM입니다. 대량 카탈로그를 처리하려면 지수 백오프, 작업 큐, 중복 요청 방지 키, 실패 이미지 재시도 한도를 설계하고 필요하면 할당량 증가를 요청해야 합니다.

한국 팀을 위한 재현 가능한 성능 테스트

1. 고정 과업을 만든다. 한국어 간판, 한글 패키지, 동일 인물 유지, 제품 색 보존, 배경 교체, 1:1·4:5·16:9 변형 등 6개 과업을 정하고 과업당 프롬프트 10개를 준비합니다.
2. 조건을 맞춘다. 두 MAI 모델과 비교 모델에서 가능한 한 같은 해상도와 참조 이미지를 사용합니다. 자동 종횡비와 웹 그라운딩은 처음에는 끄고, 기능 효과를 볼 때만 한 항목씩 켭니다.
3. 반복 실행한다. 프롬프트마다 최소 3회 생성해 우연히 잘 나온 한 장만 고르는 문제를 줄입니다. 요청 시작·완료 시각, HTTP 상태, 재시도 수, 과금량을 저장합니다.
4. 블라인드 평가한다. 모델명을 가리고 두 명 이상이 지시 준수, 한글 정확도, 인물·손 자연스러움, 제품 동일성, 편집 영역 밖 보존을 1~5점으로 채점합니다.
5. 지연과 비용을 함께 본다. 평균보다 중앙값과 p95를 기록하고, 성공 이미지 한 장당 비용을 계산합니다. 실패 생성과 재시도 비용도 포함해야 실제 운영비가 됩니다.
6. 30일 뒤 재검증한다. 프리뷰 모델은 동작이나 버전이 바뀔 수 있으므로 프롬프트, 참조 이미지 해시, 모델 버전, 실행 날짜를 보관합니다.

실패하기 쉬운 도입 방식

첫째, Arena 순위를 품질 보증서로 쓰는 경우입니다. 선호 투표 2위는 강한 신호지만 우리 회사의 로고, 한국어, 의류 패턴, 특정 인물 보존을 보장하지 않습니다. 실제 프롬프트 묶음으로 승인률을 측정해야 합니다.

둘째, 참조 이미지 다섯 장을 설명 없이 넣는 경우입니다. 어떤 이미지에서 얼굴을, 어떤 이미지에서 색을, 어떤 이미지에서 구도를 가져와야 하는지 적지 않으면 기준이 충돌합니다. “1번은 제품 형태를 보존, 2번은 색만 참고, 3번은 배경 분위기만 참고”처럼 역할을 지정하세요.

셋째, 웹 그라운딩 결과를 사실로 확정하는 경우입니다. 검색을 썼더라도 최종 이미지는 생성물입니다. 현존 인물, 상표, 행사, 지도, 안전 표지의 정확성은 별도로 검토하고, 권리·초상권·상표 사용 정책도 확인해야 합니다.

넷째, 프리뷰 모델을 승인 절차 없이 운영에 연결하는 경우입니다. 프리뷰에는 SLA가 없고 기능 제약이나 버전 변경이 생길 수 있습니다. 생성 실패 시 대체 모델, 수동 제작 전환, 배포 버전 기록, 비용 상한을 마련해야 합니다.

다섯째, 속도만 보고 Flash를 고르는 경우입니다. 대량 생성에서는 빠른 모델의 장점이 크지만 수정 횟수가 늘면 작업당 비용과 납기가 오히려 나빠질 수 있습니다. 한 번의 호출 가격이 아니라 최종 승인본 한 장까지 걸린 총 호출 수를 비교하세요.

도입 전 체크리스트

• 두 모델이 모두 공개 프리뷰이며 SLA가 없음을 이해했는가?
• 배포 리전과 Global Standard 사용 가능 여부를 확인했는가?
• 프롬프트·참조 이미지·모델 버전·실행 날짜를 기록하는가?
• API 키를 코드나 로그에 노출하지 않는가?
• 한국어 문자, 인물, 손, 제품 색, 로고 보존을 별도 항목으로 평가하는가?
• p50·p95 지연, 실패율, 재시도, 승인 이미지당 비용을 함께 보는가?
• 웹 그라운딩 결과와 상표·초상권·사실 정확성을 사람이 검토하는가?
• 할당량 초과와 401·404 오류에 대한 재시도·대체 절차가 있는가?

자주 묻는 질문

MAI-Image-2.6을 바로 상용 서비스에 써도 되나요?

기술적으로 배포할 수 있지만 Microsoft는 프리뷰 기능에 SLA가 없고 운영 워크로드에 권장하지 않는다고 명시합니다. 제한된 사용자와 낮은 위험의 콘텐츠로 검증하고, 장애 시 대체 경로와 사람 검수 단계를 두는 것이 좋습니다.

Flash가 품질도 완전히 같은가요?

Microsoft Learn은 같은 생성·편집 기능을 더 빠르고 저렴하게 제공하는 변형이라고 설명합니다. 기능 목록이 같다는 뜻이지 모든 프롬프트에서 시각 품질이 같다는 뜻은 아닙니다. 제품 일관성, 작은 문자, 복잡한 인물 장면을 각각 비교하세요.

Arena 2위면 GPT-Image-2 다음으로 좋다고 보면 되나요?

2026년 9월 4일 전체 텍스트→이미지 연구소 순위에서는 그렇습니다. 다만 Arena는 익명 사람 선호의 종합 순위이며 비용, 속도, 법적 요구, 한글 정확도, 사내 브랜드 일관성을 직접 평가하지 않습니다. 용도별 테스트가 최종 판단 기준입니다.

발표문의 1.5K와 API 문서의 1,048,576픽셀 제한 중 무엇을 따라야 하나요?

현재 호출 구현에서는 최신 Microsoft Learn API 문서와 배포 화면을 우선하세요. 문서상 폭·높이는 각각 최소 768픽셀이고 총 픽셀은 1,048,576 이하입니다. 1.5K가 실제 계정에서 허용되는지는 배포 리전과 모델 버전에서 별도로 확인해야 합니다.

한 장당 비용은 얼마인가요?

공식 가격이 토큰 단위라 프롬프트와 입력 이미지, 출력 설정 없이 한 장당 고정 가격을 말할 수 없습니다. 같은 조건으로 반복 생성한 뒤 Azure 비용 로그의 총액을 승인된 이미지 수로 나누는 방식이 가장 실용적입니다.

결론: 순위보다 제작 성공률로 결정하자

MAI-Image-2.6은 공개 선호 평가에서 상위권에 올랐고, 최대 5개 참조 이미지와 웹 그라운딩, 자동 종횡비를 결합해 제작 도구로서 매력이 커졌습니다. Flash는 공개 가격 기준으로 입력과 출력 단가를 크게 낮춰 대량 작업에 유리합니다. 반면 두 모델 모두 프리뷰이고, 속도·효율의 상세 측정 조건이 충분히 공개되지 않았으며, 발표문과 API 문서 사이에 효율 비율과 출력 해상도 표현의 차이도 보입니다.

따라서 가장 좋은 도입 순서는 “랭킹 확인 → 작은 재현 테스트 → 사람의 블라인드 품질 평가 → 승인 이미지당 비용 계산 → 제한된 운영 적용”입니다. 한국어 문자와 제품·인물 일관성은 일반 리더보드가 대신 판단해 주지 않습니다. Flash와 2.6을 같은 프롬프트로 비교하고 실제 수정 횟수까지 기록하면, 어느 모델이 우리 업무에서 더 빠르고 저렴한지 객관적으로 결정할 수 있습니다.

공식 확인 자료

• Microsoft Foundry Blog — MAI-Image-2.6 및 Flash 공개 발표
• Microsoft Learn — MAI 이미지 모델 배포와 생성·편집 API
• Microsoft Learn — Foundry 모델 배포 방법
• Microsoft Learn — Foundry 모델 리전 가용성
• Microsoft Learn — Azure가 제공하는 Foundry 모델 목록과 정책
• Microsoft Foundry — 공식 모델 카탈로그
• Arena — 2026년 9월 텍스트→이미지 공개 리더보드

기준일: 2026년 9월 4일

Google이 2026년 9월 3일 Gemini API에 Lyria 3.5 음악 생성 모델 두 종을 공개했습니다. 짧은 반복 음원과 빠른 아이디어 확인을 위한 lyria-3.5-clip-preview, 절·후렴·브리지 구조를 갖춘 긴 곡을 위한 lyria-3.5-pro-preview입니다. 두 모델 모두 텍스트와 이미지를 입력으로 받고 44.1kHz 스테레오 MP3를 생성합니다.

이번 공개의 핵심은 웹 서비스에서만 쓰던 음악 모델을 개발자가 Gemini API의 새 Interactions API로 호출할 수 있게 됐다는 점입니다. 다만 두 모델 모두 Preview이며, 공개 문서에는 표준화된 음악 품질 벤치마크 점수와 Lyria 3.5 전용 가격표가 아직 명확히 제시되지 않았습니다. 따라서 “더 자연스럽다”는 제공사 설명과 실제 서비스 도입 판단을 구분해야 합니다.

Lyria 3.5 API에서 공개된 핵심 사양

Gemini API 공식 변경 로그는 9월 3일 공개 사실과 두 모델 ID를 기록하고 있습니다. Lyria 3.5 음악 생성 가이드에는 Python, JavaScript, REST 호출 예제와 응답 구조가 정리돼 있습니다.

Clip과 Pro를 어떤 순서로 써야 하나

공식 가이드는 먼저 Clip 모델로 프롬프트를 빠르게 시험한 뒤, 방향이 정해졌을 때 Pro로 전체 곡을 만들 것을 권장합니다. Clip은 길이가 30초로 고정돼 있어 영상 오프닝, 짧은 루프, 분위기 샘플을 비교하기 쉽습니다. Pro는 절과 후렴, 브리지, 인트로와 아웃트로처럼 곡 구조를 프롬프트에 넣고 수 분 길이의 결과를 만들 때 적합합니다.

서비스 설계에서는 두 모델을 별도 제품처럼 취급하는 편이 좋습니다. 사용자가 먼저 장르, BPM, 악기, 조성, 분위기를 고르고 Clip 세 개를 비교한 뒤 선택한 프롬프트만 Pro로 보내면 불필요한 긴 곡 생성을 줄일 수 있습니다. 같은 프롬프트에서도 결과가 달라질 수 있으므로 생성 ID, 프롬프트 버전, 모델 ID, 생성 시간을 함께 기록하세요.

1. Clip으로 30초 샘플을 생성합니다.
2. 장르와 악기, BPM, 분위기 일치 여부를 사람이 확인합니다.
3. 선택한 프롬프트에 곡 구조와 목표 길이를 추가합니다.
4. Pro로 전체 곡을 생성합니다.
5. 가사, 발음, 반복 구간, 음질, 권리 조건을 확인한 뒤 저장합니다.

Interactions API 호출과 응답에서 주의할 점

Lyria 3.5는 새 Interactions API를 사용합니다. REST 기준으로 /v1beta/interactions에 모델 ID와 입력을 보내며, 응답은 하나의 문자열만 오는 구조가 아닙니다. steps 안의 model_output 단계에 가사·곡 구조를 담은 텍스트 블록과 Base64 오디오 블록이 나뉘어 들어갑니다.

from google import genai
import base64

client = genai.Client()
interaction = client.interactions.create(
    model="lyria-3.5-clip-preview",
    input="30초 길이의 차분한 로파이 피아노 연주곡. 82 BPM, 보컬 없음.",
)

if interaction.output_audio:
    with open("music.mp3", "wb") as file:
        file.write(base64.b64decode(interaction.output_audio.data))

if interaction.output_text:
    print(interaction.output_text)

간단한 작업은 SDK의 output_audio와 output_text 편의 속성으로 충분합니다. 가사와 오디오가 여러 단계에 걸쳐 섞인 결과를 정확히 기록하려면 steps를 직접 순회해야 합니다. 오디오 데이터가 크므로 로그에 Base64 전체를 남기지 말고 파일 저장 성공 여부와 해시, 생성 ID만 기록하는 것이 안전합니다.

이미지로 음악을 만들 때 지켜야 할 입력 규칙

Lyria 3.5는 텍스트와 함께 최대 10장의 이미지를 받을 수 있습니다. 여행 사진의 색감으로 배경음을 만들거나 제품 영상의 장면별 분위기를 잡는 데 쓸 수 있습니다. 이미지는 곡의 정확한 음표를 지정하는 입력이 아니라 분위기와 시각적 맥락을 제공하는 참고 자료로 보는 편이 좋습니다.

여러 이미지를 넣을 때는 “첫 번째 이미지는 새벽의 고요함, 두 번째 이미지는 도시의 속도감”처럼 각 이미지의 역할을 텍스트에서 구분하세요. 이미지 파일은 Base64로 전달하므로 요청 크기와 메모리 사용량을 확인하고, 촬영자와 인물의 동의가 없는 사진이나 사내 비밀이 담긴 화면을 보내지 않아야 합니다.

• 장르와 악기, BPM, 조성, 분위기를 구체적으로 적습니다.
• 가사가 필요하면 지시와 가사를 분리하고 언어를 명시합니다.
• [Intro], [Verse], [Chorus], [Bridge] 같은 구조 표식을 사용합니다.
• 보컬이 필요 없으면 “instrumental only” 또는 “보컬 없음”을 명시합니다.
• 이미지별 역할과 곡의 어느 구간에 반영할지 설명합니다.

실제 성능: 공개 수치와 확인되지 않은 부분

Google은 Lyria 3.5가 이전 세대보다 음악적 구조, 가사 품질, 보컬의 자연스러움과 발음, 템포·길이 제어를 개선했다고 설명합니다. API 문서는 구조적 일관성, timed lyrics, 전체 악기 편성, 자연스러운 보컬을 강조합니다. 하지만 현재 공식 개발자 문서에는 문제 수, 평가자 수, 비교 모델, 블라인드 테스트 방식과 점수표가 공개돼 있지 않습니다.

따라서 이 글은 직접 API 성능 시험을 했다고 주장하지 않습니다. 현재 환경에 Lyria 3.5 접근 권한과 과금 계정이 없어 생성 지연과 성공률을 재현 측정하지 않았습니다. 정식 도입 전에는 같은 20개 프롬프트를 Clip과 Pro에 각각 세 번 실행하고, 음악 담당자가 모델 이름을 가린 상태에서 평가하는 방법이 현실적입니다.

평가표에는 프롬프트 준수, 구조 준수, 한국어 발음, 잡음과 왜곡, 반복의 자연스러움, 생성 성공률, 평균·p95 시간, 재시도 횟수, 곡 한 개당 총비용을 기록하세요. 제공사 측정값과 내부 테스트를 분리하면 홍보 문구를 실제 서비스 품질로 오해하는 일을 줄일 수 있습니다.

가격은 반드시 3.5 모델 ID로 다시 확인해야 한다

Gemini Developer API 가격 페이지에는 현재 Lyria 3 Clip과 Pro Preview 가격이 각각 요청당 0.04달러와 0.08달러로 표시돼 있습니다. 그러나 표의 모델 ID는 lyria-3-clip-preview와 lyria-3-pro-preview이며 새 3.5 모델 ID가 아닙니다. 3.5 가격이 같다고 단정하지 말고 결제 콘솔과 최신 가격표에서 실제 SKU를 확인해야 합니다.

무료 등급은 제공되지 않는 것으로 표시돼 있으며 Preview 모델은 안정 버전보다 제한이 더 엄격할 수 있습니다. 공식 rate limits 문서는 한도를 프로젝트 단위로 적용하고, 계정 등급과 모델에 따라 RPM과 일일 요청 수가 달라진다고 설명합니다. 운영 전 AI Studio에서 현재 프로젝트의 실제 한도를 확인하세요.

사용자에게 한 번의 생성 버튼을 제공하더라도 실패 재시도, 여러 후보 생성, Pro 승격 때문에 실제 비용은 요청당 표시 가격보다 커질 수 있습니다. 성공한 최종 곡 한 개에 사용된 전체 요청 수를 기준으로 비용을 계산하고 공식 결제·지출 한도 문서의 프로젝트별 cap도 설정하는 것이 좋습니다.

저작권·안전·워터마크와 서비스 제한

공식 문서는 특정 아티스트의 목소리를 요구하거나 저작권이 있는 가사를 생성하도록 요청하면 안전 필터에 의해 차단될 수 있다고 안내합니다. 모든 생성 오디오에는 사람이 듣기 어려운 SynthID 오디오 워터마크가 포함됩니다. 서비스 화면에서는 결과가 AI로 생성됐다는 사실을 이용자가 이해할 수 있게 표시하는 편이 좋습니다.

현재 Lyria 3.5는 단일 턴 생성 방식입니다. 만들어진 곡을 다음 요청에서 직접 편집하거나 일부 구간만 교체하는 다중 턴 수정은 지원하지 않습니다. “드럼만 조금 줄여줘” 같은 반복 편집 경험을 제공하려면 원본 프롬프트를 수정해 새 곡을 만들고 이전 결과와 비교하는 버전 관리가 필요합니다.

직접 작성하지 않은 가사, 인물 사진, 고객이 올린 이미지의 처리 권한도 확인해야 합니다. 생성 전에 이용 약관에 동의받고 업로드 파일의 보관 기간과 삭제 방법을 알려주세요. 상업적 사용 가능 여부는 서비스 약관과 지역 법률, 입력 자료의 권리를 별도로 검토해야 하며 모델이 생성했다는 사실만으로 모든 권리가 자동 해결되지는 않습니다.

도입 순서와 실패 사례 체크리스트

1. Gemini API 프로젝트에서 Lyria 3.5 접근 가능 여부와 실제 모델 ID를 확인합니다.
2. Clip 20개 평가 세트와 합격 기준을 먼저 만듭니다.
3. Interactions API의 단계별 응답과 Base64 저장 로직을 구현합니다.
4. 재시도에는 생성 ID와 멱등성 처리를 두어 중복 과금을 추적합니다.
5. 가사·이미지 업로드의 권리 확인과 개인정보 제거 절차를 추가합니다.
6. Clip에서 통과한 프롬프트만 Pro로 보내는 흐름을 만듭니다.
7. 일부 사용자에게만 열고 생성 성공률, 지연, 비용, 신고율을 기록합니다.

첫 번째 흔한 실패는 기존 GenerateContent 예제를 그대로 복사하는 것입니다. Lyria 3.5 문서는 Interactions API와 steps 구조를 사용하므로 응답 파서를 별도로 작성해야 합니다. 두 번째는 가격표의 Lyria 3 항목을 3.5 가격으로 가정하는 것입니다. 세 번째는 MP3 파일만 저장하고 가사와 곡 구조 텍스트, 모델 ID, 프롬프트 버전을 버리는 것입니다.

네 번째는 특정 가수의 목소리나 기존 노래 가사를 그대로 요구하는 것입니다. 차단 가능성뿐 아니라 권리 문제도 생길 수 있습니다. 다섯 번째는 같은 프롬프트가 항상 같은 결과를 준다고 가정하는 것입니다. 공식 문서도 결과가 호출마다 달라질 수 있다고 밝히므로 캐시 키와 사용자 경험을 생성 결과 단위로 설계해야 합니다.

자주 묻는 질문

Lyria 3.5는 지금 Gemini API에서 쓸 수 있나요?

공식 변경 로그와 개발자 가이드는 두 Preview 모델을 Gemini API에서 사용할 수 있다고 안내합니다. 계정과 프로젝트별 접근 범위, 지역, rate limit은 AI Studio에서 다시 확인해야 합니다.

Clip으로 1분 음악을 만들 수 있나요?

아닙니다. Clip은 항상 30초입니다. 더 긴 곡은 Pro 모델을 사용하고 목표 길이와 구조를 프롬프트에 명시해야 합니다.

이미지만 넣어도 음악을 만들 수 있나요?

공식 예제는 텍스트와 이미지를 함께 보내는 방식을 보여줍니다. 최대 10장의 이미지를 넣을 수 있으며 이미지가 곡의 분위기에 어떻게 영향을 주어야 하는지 텍스트로 설명하는 편이 좋습니다.

생성한 음악을 바로 상업적으로 써도 되나요?

모델 기능과 상업적 이용 권리는 별개입니다. 최신 Gemini API 약관, 입력한 가사와 이미지의 권리, 배포 플랫폼 정책, 지역 법률을 확인해야 합니다.

공식 확인 자료

• Gemini API Release notes
• Generate music with Lyria 3.5
• Google 공식 Lyria 3.5 소개
• Gemini Developer API pricing
• Gemini API rate limits
• Gemini API billing

Preview 모델의 ID, 가격, 제한은 바뀔 수 있습니다. 실제 배포 직전 공식 문서와 콘솔을 다시 확인하세요.