[태그:] AI 최신 이슈

Claude Sonnet 4.5를 API에서 사용 중이라면 이제 교체 일정을 잡아야 합니다. Anthropic은 2026년 9월 30일 claude-sonnet-4-5-20250929의 지원 종료를 공지했고, Claude API에서의 종료 예정일을 2026년 11월 30일로 제시했습니다. 권장 대체 모델은 claude-sonnet-5-5입니다. 이는 오늘 당장 모든 호출이 중단됐다는 뜻이 아닙니다. 운영팀이 남은 기간에 호출 경로를 찾고, 응답 형식과 비용을 다시 검증하라는 신호에 가깝습니다. Anthropic 공식 릴리스 노트와 모델 지원 종료 안내를 기준으로 핵심을 정리했습니다.

이미지 안내: 이 글의 대표 사진과 본문 사진은 GPT로 만든 실사형 연출 이미지입니다. 실제 직원이나 직접 API 성능 측정 현장을 촬영한 사진이 아닙니다.

1. 무엇이 언제 바뀌나: 날짜와 적용 범위부터 구분

이번 공지의 주체는 Anthropic이며, 대상은 특정 날짜가 붙은 Sonnet 4.5 API 모델 ID입니다. 공지일은 9월 30일, Claude API 종료 예정일은 11월 30일입니다. 약 두 달의 이전 기간이 있지만, 마감일에 맞춰 일괄 교체하기보다 트래픽을 나눠 이동해야 장애를 줄일 수 있습니다. 테스트와 실제 운영에는 여유를 두되, 날짜가 변경될 수 있으므로 배포 직전에는 공식 페이지를 다시 확인하세요.

확인 항목	공식 안내	실무 해석
기존 모델 ID	claude-sonnet-4-5-20250929	코드·설정·프록시·기록에서 정확히 검색
공지일	2026년 9월 30일	새 종료 일정이 발표된 날
Claude API 종료 예정	2026년 11월 30일	그 전에 호환성 검사와 전환 완료
권장 대체 모델	claude-sonnet-5-5	이름 교체만으로는 충분하지 않음

Anthropic 문서에는 Claude API 외에도 Bedrock, Google Cloud, Microsoft Foundry, Claude Platform on AWS 같은 제공 경로가 나옵니다. 그러나 이번 릴리스 노트에서 11월 30일이라고 명시한 범위는 Claude API입니다. 다른 클라우드의 실제 비활성화 시각과 모델 ID는 해당 서비스의 공지를 별도로 확인하세요. 단일 날짜를 모든 플랫폼에 그대로 적용하면 잘못된 긴급 조치를 하게 될 수 있습니다.

2. Sonnet 5.5로 옮기면 어떤 코드가 깨질 수 있나

Anthropic의 Sonnet 5.5 공식 마이그레이션 가이드는 Sonnet 4.5에서 이동할 때 누적해서 적용해야 할 변경을 나열합니다. 기존 요청에 thinking 필드를 넣지 않았다면 4.5에서는 사고 과정이 꺼졌지만 5.5에서는 적응형 사고가 기본으로 켜집니다. 같은 프롬프트라도 지연 시간과 토큰 사용량이 달라질 수 있으므로 기본값을 무심코 유지하지 마세요. 전면적인 사고 과정이 필요 없는 업무는 가이드의 between_tools 설정을 검토할 수 있지만, 높은 effort 설정과의 조합에는 제한이 있습니다.

4.5의 수동 사고 예산 thinking: {"type":"enabled","budget_tokens":...}은 5.5에서 오류가 납니다. 새 모델에서는 adaptive와 output_config.effort로 전환해야 하며, 예전 budget 값을 effort 단계에 일대일로 대응시키는 공식 공식은 없습니다. 비기본 temperature, top_p, top_k도 제거해야 합니다. 강제 도구 선택인 tool_choice의 any·tool은 400 오류를 일으키므로 auto와 엄격한 도구 입력 검증 방식을 검토하세요.

대화 끝에 assistant 메시지를 미리 채우는 방식도 새 모델에서 허용되지 않습니다. 구조화된 출력이나 시스템 지침으로 의도를 옮겨야 합니다. 도구 입력은 문자열 연결이 아니라 표준 JSON 파서로 처리하고, 응답의 텍스트·사고·도구 블록은 type별로 읽어야 합니다. 스트리밍 화면에서 도구 사이의 텍스트를 그대로 보여 주던 앱은 응답 블록 처리 방식까지 확인해야 합니다.

4.5에서 흔한 설정	5.5 전환 시 조치	검증 방법
사고 필드 생략	기본 adaptive 동작을 전제로 effort 재설정	지연·출력 토큰·정확도 비교
budget_tokens	adaptive와 effort로 교체	저·중·고 effort 반복 실행
강제 tool_choice	auto와 strict 도구 검토	400 오류와 도구 호출 성공률
assistant prefill	구조화된 출력·명시적 지침으로 이전	응답 형식 회귀 테스트
비기본 샘플링 값	해당 파라미터 제거	실패 요청 로그 확인

3. 가격 비교: 명목 단가는 낮지만 실제 청구액은 다시 계산

공식 가격표의 Claude API 기본 텍스트 단가를 보면 Sonnet 4.5는 입력 100만 토큰당 3달러, 출력 15달러이고 Sonnet 5.5는 입력 2달러, 출력 10달러입니다. 단순 단가로는 각각 약 33% 낮습니다. 하지만 같은 한국어 문장이라도 새 토크나이저에서는 토큰 수가 달라질 수 있습니다. Anthropic 가이드는 Sonnet 4.5 등 이전 모델 대비 같은 텍스트에 약 30% 더 많은 토큰이 생성될 수 있다고 안내하며, 실제 증가는 내용에 따라 달라진다고 단서를 붙입니다.

Claude API 기본 요금	Sonnet 4.5	Sonnet 5.5	주의
입력 / 100만 토큰	$3	$2	토큰 수가 같을 때의 단가 비교
출력 / 100만 토큰	$15	$10	사고·응답 길이를 포함해 재측정
5분 캐시 쓰기 / 100만	$3.75	$2.50	캐시 정책별 사용량 변동
캐시 읽기 / 100만	$0.30	$0.20	히트율을 별도로 확인

예를 들어 동일한 작업에서 예전 모델이 입력 10만·출력 1만 토큰을 썼다면 명목 단가 합계는 0.45달러입니다. 새 모델이 정확히 같은 토큰 수를 쓴다면 0.30달러지만, 토큰 수와 도구 호출 횟수·캐시 히트율이 바뀌면 청구액도 달라집니다. 이 예시는 계산법을 보여 주는 가정일 뿐 직접 실행 결과가 아닙니다. Bedrock과 Google Cloud의 지역·라우팅 요금은 별도이므로 자신의 실제 청구 경로로 계산해야 합니다.

4. 실제 성능: 공식 수치와 이 글이 확인하지 못한 것

이 글을 작성하면서 유료 Claude API로 직접 A/B 테스트를 실행하지 않았습니다. 따라서 ‘우리가 측정한 지연 시간’이나 한국어 실무 품질 점수는 제시하지 않습니다. 대신 Anthropic이 공개한 Sonnet 5.5 발표 자료의 일부 수치를 제공사 측정값으로 표시합니다. 아래 수치는 Sonnet 5.5와 Sonnet 5의 공식 평가 비교이지, 종료 대상인 Sonnet 4.5와의 동일 조건 직접 비교가 아닙니다.

공식 평가	Sonnet 5.5	비교 모델	조건·측정 주체
Terminal-Bench 4.0, 에이전트 코딩	70.6%	Sonnet 5 10.3%	Anthropic 공개 자료; 명령줄 다단계 작업, 세부 실행 조건은 시스템 카드 참조
CursorBench 4.0, 다중 파일 코딩	55.5%	Sonnet 5 34.1%	Anthropic 공개 자료; 실제 Cursor 작업을 바탕으로 한 평가
OSWorld 2.1, 컴퓨터 사용	80.1%	Sonnet 5 57.0%	Anthropic 공개 자료; 양쪽 모두 partial 조건
동일 텍스트 토큰화	이전 모델 대비 약 30% 증가 가능	Sonnet 4.5 등	Anthropic 마이그레이션 문서의 안내; 실제 문장·설정별 차이

평가 표본·도구·effort·채점 방식은 공식 시스템 카드에서 원문을 확인해야 합니다. 벤치마크 하나로 모든 회사의 고객 상담, RAG, 한국어 문서 작성 결과를 예측할 수 없습니다. 특히 Sonnet 4.5에서 옮기는 팀에게 필요한 핵심 수치는 자사 작업의 성공률과 작업당 비용입니다. 신규 모델의 공식 점수가 높아도 특정 JSON 스키마나 내부 지식 검색 체인에서는 퇴행이 생길 수 있습니다. 신뢰할 만한 독립적 동일 조건 4.5→5.5 비교는 이 글에서 확인하지 못했습니다.

5. 하루 만에 끝내지 않는 안전한 전환 순서

1. 사용처 목록화: 저장소 코드뿐 아니라 환경 변수, 프롬프트 관리 도구, 워크플로 설정, 배치 작업, 서버리스 함수, 제휴 서비스 호출의 모델 ID를 검색합니다. 각 경로에 담당자와 일일 호출량을 붙입니다.
2. 요청 형식 정리: 공식 마이그레이션 체크리스트를 기준으로 사고 예산, 샘플링, 강제 도구 호출, prefill, 출력 형식, 컴퓨터 사용 도구 버전을 검사합니다. 단순 문자열 교체 PR과 API 형식 수정 PR을 분리하면 검토가 쉽습니다.
3. 대표 평가셋 구축: 실제 고객 데이터는 비식별화하고, 문의 응대·코드 수정·문서 추출·도구 호출 등 주요 흐름별로 20~50개 사례를 준비합니다. 실패하기 쉬운 길고 복잡한 입력도 섞습니다.
4. 동일 조건 반복: 같은 입력·도구 스키마·상태·타임아웃을 두 모델에 적용하고 각 사례를 여러 번 실행합니다. 새 모델은 effort 수준이 변수이므로 한 단계만 재지 말고 최소 두세 단계를 비교합니다. 성공률뿐 아니라 p50/p95 지연, 입력·출력·캐시 토큰, 오류 종류, 작업당 청구액을 기록합니다.
5. 점진 배포: 내부 테스트 뒤 소량의 운영 트래픽으로 이동하고 품질·비용·에러율을 관찰합니다. 종료일 전에 롤백 기준과 담당자를 정해 두고, 전환 완료 뒤에도 폐기 ID를 검색해 잔여 호출을 없앱니다.

테스트 표는 사례 ID, 모델 ID, effort, 입력 해시, 성공 기준, 성공/실패, 지연, 입력 토큰, 출력 토큰, 캐시 읽기·쓰기, 도구 호출 횟수, 총비용으로 만들면 재현성이 좋아집니다. 결과가 다르면 프롬프트를 먼저 맞추고 도구 정의가 동일한지 확인한 뒤 다시 실행하세요. API 키와 운영 권한이 없는 상태에서 결과를 상상해 기입하면 마이그레이션 판단이 왜곡됩니다.

6. 자주 생기는 실패 사례와 배포 전 체크리스트

첫 번째 실패 사례는 모델 ID만 바꾸고 예전 budget_tokens를 남겨 400 오류가 발생하는 것입니다. 두 번째는 도구 호출을 반드시 요구하는 기존 설정을 유지해 새로운 모델의 강제 도구 제한과 충돌하는 경우입니다. 세 번째는 기본 사고 동작과 토크나이저 차이를 고려하지 않아 max_tokens와 월 예산이 예상보다 빨리 소진되는 경우입니다. 네 번째는 이전 모델의 prefill에 의존하던 JSON 응답이 통째로 실패하는 경우입니다. 어느 경우도 모델이 단순히 ‘성능이 나쁘다’는 결론으로 처리하면 원인을 놓칩니다.

• 운영 중인 모든 claude-sonnet-4-5-20250929 사용처와 담당자를 확인했는가?
• Anthropic Claude API와 다른 클라우드 제공 경로의 종료 일정을 구별했는가?
• 공식 가이드의 4.5→5.5 변경 사항을 코드와 프롬프트 양쪽에서 점검했는가?
• 한국어 대표 작업을 같은 입력·도구·타임아웃으로 반복 측정했는가?
• 지연·정확도·도구 성공률·작업당 비용의 허용 기준과 롤백 조건을 정했는가?
• 11월 30일 이전에 트래픽 이전과 잔여 호출 제거를 마칠 수 있는가?

7. FAQ: 가장 많이 헷갈리는 세 가지

Q. 10월 1일부터 Sonnet 4.5 API가 바로 끊기나요?
A. 아닙니다. Anthropic 릴리스 노트는 9월 30일을 지원 종료 공지일로, 11월 30일을 Claude API 종료 예정일로 적었습니다. 예정일과 실제 운영 상태는 배포 직전 다시 확인해야 합니다.

Q. Sonnet 5.5가 더 싸니 월 청구액도 무조건 줄까요?
A. 기본 토큰 단가는 낮지만 실제 토큰 수, 기본 사고 동작, 캐시 사용량, 이미지 입력 비용이 달라질 수 있습니다. 같은 평가셋으로 작업당 비용을 다시 계산해야 합니다.

Q. Bedrock이나 Google Cloud도 같은 날 종료되나요?
A. 이번 공식 릴리스 노트의 11월 30일 문구는 Claude API를 가리킵니다. 파트너 플랫폼은 각자의 모델 가용성·일정을 확인하는 것이 안전합니다. 모델 ID 형식도 제공 경로별로 다를 수 있습니다.

Q. 기존 대화 기록을 새 모델에 그대로 넘겨도 되나요?
A. 사고 블록은 모델과 대화 기록에 묶이므로, 중간 내용을 수정하거나 다른 모델의 블록을 재사용할 때 처리 방식이 달라질 수 있습니다. 공식 가이드에 따라 append-only 대화와 블록 type 처리를 검증하세요.

공식 확인 자료와 업데이트 방법

• Claude Platform 릴리스 노트 — 2026년 9월 30일 지원 종료 공지
• Anthropic 모델 지원 종료 목록
• Sonnet 5.5 마이그레이션 체크리스트
• Sonnet 5.5 모델 사양과 가용성
• Claude API 공식 가격표
• Anthropic의 평가 결과와 방법론 안내

기준 시점은 2026년 10월 1일 한국 시간입니다. 가격·종료일·제공 지역은 바뀔 수 있습니다. 이 글은 제공사 공식 자료를 해석한 것이며, 직접 API 호출로 성능을 측정했다는 주장이 아닙니다.

2026년 9월 29일(미국 발표일), OpenAI가 GPT-6.1 Sol을 공개했습니다. API 모델 식별자는 gpt-6.1-sol입니다. 이번 소식의 핵심은 ‘새 이름’보다도 GPT-6 Astra에 가까운 복잡한 작업 성능을 더 낮은 단가로 제공하겠다는 주장에 있습니다. 다만 이 글의 성능 결과는 대부분 OpenAI가 공개한 평가 자료이며, 저희가 유료 API로 직접 재현한 결과는 아닙니다. 표에는 평가 이름과 조건을 함께 적고, 독자가 자기 업무에서 비교하는 방법까지 정리했습니다.

1. GPT-6.1 Sol은 무엇이 달라졌나

공식 API 변경 로그는 GPT-6.1 Sol을 코딩과 전문 업무를 위한 새 모델로 소개합니다. 모델 페이지에 따르면 1,050,000토큰의 입력 컨텍스트, 최대 128,000토큰 출력, 텍스트·이미지 입력과 텍스트 출력을 지원합니다. 오디오는 지원하지 않습니다. 사용 가능한 추론 강도는 low·medium·high·xhigh·max이며 기본값은 medium입니다. 이전 GPT-6 Sol에서 가능했던 none은 새 모델에서 지원하지 않습니다.

도구 호출은 Responses API를 써야 합니다. Chat Completions에서 텍스트 응답은 가능하지만 도구 호출까지 하던 코드를 모델 이름만 바꿔서는 안 됩니다. 이 제약은 자동화, 검색, 파일 처리, 코딩 에이전트에 특히 중요합니다. OpenAI의 GPT-6 사용 가이드도 기존 gpt-6-sol 사용자에게 전환 전에 마이그레이션 설정을 확인하라고 권합니다.

이미지는 생성형 AI로 만든 연출 사진입니다. 사진 속 인물은 실제 직원이나 직접 성능 시험에 참여한 사람이 아니며, 화면도 실제 벤치마크 결과를 보여주는 장면이 아닙니다.

2. 실제 성능: 어떤 평가에서 얼마나 좋아졌나

OpenAI 공식 발표에 공개된 수치는 제공사 측정값입니다. 일부 평가의 절대 점수는 본문 텍스트에 공개되지 않고 차이값만 설명되어 있으므로, 없는 숫자를 채워 넣지 않았습니다. 모델별 추론 강도와 도구 구성이 다르면 수치를 단순히 한 줄 순위처럼 읽어서는 안 됩니다.

평가·용도	공개된 결과	조건·방법과 해석
DeepSWE v1.1, 실제 코드베이스의 장기 소프트웨어 작업	GPT-6.1 Sol이 Astra와 동률이라고 OpenAI 발표. 이전 GPT-6 Sol의 최고 점수보다 6.4%p 높다고 설명	원본 작업 기반의 에이전트 평가. 비교 대상의 추론 강도·도구·작업당 비용을 동일 조건으로 다시 확인해야 함. 제공사 측정값
AutomationBench 1.0.6, 47개 도구를 사용하는 다단계 업무 자동화	medium에서 이전 Sol 대비 +4.8%p, Opus 5.5 대비 +2.2%p	영업·마케팅·운영·지원·재무·인사 업무 흐름을 평가. 특정 벤더의 도구 구성이나 실패 복구 설정이 실사용 결과를 바꿀 수 있음. 제공사 측정값
OSWorld 2.0 오프라인 집합, 컴퓨터 조작	max에서 이전 Sol 대비 +7%p, Astra보다 2.1%p 낮음	v2026.08.08 오프라인 집합의 partial reward. 완전한 작업 성공률로 바꾸어 읽으면 안 됨. 제공사 측정값
사실성 평가, 과거 오류 신고 대화	low에서 사실 오류가 포함된 응답 비율이 이전 Sol 11.4%에서 새 Sol 7.7%로 감소	과거에 사용자가 오류를 신고한 익명화 대화로 구성된 어려운 표본. 일반 질문의 오류율을 뜻하지 않음. 제공사 측정값
Terminal-Bench Science 0.1, 과학 작업	max에서 이전 Sol 점수의 두 배 이상. 새 Sol 평균 $5.47/작업, Astra $23.80/작업, Opus 5.5 $23.21/작업	코드·터미널 도구로 분석·시뮬레이션 등을 수행. OpenAI 발표에서 Astra 최고 점수 68.1%를 명시하지만 새 Sol 절대 점수는 본문에 기재되지 않음. 제공사 측정값

GDP.pdf 문서 이해 평가에서도 OpenAI는 새 Sol이 Opus 5.5보다 높은 점수와 낮은 작업당 비용을 보였다고 설명합니다. 다만 공개 페이지의 서술만으로는 모든 비교 설정과 표본을 충분히 복원하기 어렵습니다. 경쟁사 모델 수치를 그대로 가져와 ‘항상 더 낫다’고 결론 내리지 않은 이유입니다. 독립적인 동일 조건 평가가 축적되기 전에는 공식 결과를 방향을 잡는 단서로만 활용해야 합니다. 평가 출처는 발표문과 그 안에서 연결한 각 벤치마크 설명입니다.

3. 가격 비교: 토큰 단가와 작업당 비용은 다르다

아래는 OpenAI 모델 페이지의 표준 처리, 100만 토큰당 미국 달러 가격입니다. 입력 길이 272,000토큰 이하인 요청을 기준으로 하며 세금, 환율, 검색·컴퓨터 사용 같은 별도 도구 비용은 제외합니다. 초장문 요청은 가격 배율이 달라질 수 있습니다.

모델	입력	캐시 입력	캐시 쓰기	출력
GPT-6.1 Sol	$2.00	$0.10	$2.50	$10.00
GPT-6 Sol	$2.00	$0.20	$2.50	$10.00
GPT-6 Astra	$10.00	$1.00	$12.50	$50.00

출처는 새 Sol, 기존 Sol, Astra의 공식 가격표입니다. 새 Sol은 일반 입력·출력 단가가 기존 Sol과 같고, 캐시 읽기만 50% 저렴합니다. Astra와 비교하면 일반 입력·출력은 5분의 1 수준입니다.

예를 들어 캐시 없이 입력 10만 토큰, 출력 1만 토큰을 쓰는 가상 계산은 새 Sol 약 $0.30, Astra 약 $1.50입니다. 이는 실제 요청의 청구액이나 실행 시간을 측정한 것이 아닙니다. 같은 작업에서 모델이 더 오래 추론하거나 도구를 더 자주 호출하면 총비용은 달라집니다. 공식 발표의 ‘작업당 비용’과 가격표의 ‘토큰당 비용’을 구분해야 합니다. 272,000 입력 토큰을 넘는 요청은 전체 요청에 입력·캐시 2배, 출력 1.5배 요율이 적용된다는 모델 페이지 주의사항도 확인하세요.

4. 누구에게 적합한가: 활용 시나리오

첫째, 코드 수정과 테스트를 반복하는 팀은 GPT-6.1 Sol을 기본 후보로 놓고 Astra를 난도가 높은 예외 처리 단계에만 쓰는 구성을 시험할 수 있습니다. 단, DeepSWE에서 동률이라는 발표만으로 특정 사내 저장소에서의 버그 수정 성공률을 보장할 수는 없습니다. 둘째, 정형 문서에서 근거를 추출해 보고서를 작성하는 팀은 표·각주·이미지 이해의 누락률을 비교할 수 있습니다. 셋째, 브라우저나 업무 도구를 조작하는 에이전트는 완료율뿐 아니라 잘못된 클릭, 승인 누락, 되돌리기 가능성까지 평가해야 합니다.

가격만 보고 모든 요청을 새 모델로 바꾸기보다 난도별 라우팅이 현실적입니다. 짧은 분류·재작성처럼 검증이 쉬운 업무는 더 저렴한 모델을 남겨 두고, 여러 자료를 종합하거나 복잡한 도구 작업을 수행하는 구간에서 새 Sol을 시험하세요. 최고 품질이 꼭 필요한 의학·법률·재무 판단이나 고난도 과학 연구는 모델 응답 자체보다 전문 검토 체계를 우선해야 합니다. OpenAI도 가장 어려운 과학 연구에는 Astra를 권합니다.

5. 이전 GPT-6 Sol에서 옮기는 순서

1. 기존 요청의 모델 식별자를 기록하고 동일한 테스트 입력을 보존합니다. 무작정 모델 문자열만 교체하지 않습니다.
2. Responses API를 사용하는지 확인합니다. 도구 호출이 있다면 Chat Completions 기반 호출을 새 모델로 그대로 옮기지 않습니다.
3. 기존 reasoning.effort: "none" 또는 minimal 설정을 점검합니다. 새 Sol은 둘 다 지원하지 않으므로 먼저 low로 시작해 비용과 품질을 비교합니다.
4. 캐시 키·반복 프롬프트와 입력 토큰 길이를 점검합니다. 반복 사용이 많을수록 낮아진 캐시 읽기 단가가 의미 있을 수 있지만 캐시 쓰기 비용도 함께 계산합니다.
5. 전체 트래픽을 한 번에 바꾸지 말고 일부 작업을 병렬 평가한 뒤 실패율·수정 시간·비용·지연을 확인합니다.

특히 ‘도구를 못 쓰는 응답’과 ‘응답 자체가 실패하는 요청’을 구별해야 합니다. 새 모델은 Chat Completions에서 텍스트 대화가 가능해도 도구 호출은 Responses API가 필요합니다. none 설정으로 받는 오류를 품질 저하로 오해하지 않도록 마이그레이션 전에 요청 로그를 샘플링하세요. 공식 마이그레이션 안내의 파라미터 및 처리 지역 조건도 확인하는 것이 좋습니다.

6. 직접 재현하는 성능 시험표

이번 글에는 직접 테스트 결과가 없습니다. 동일 입력과 설정을 쓰는 작은 사내 평가부터 시작하면 광고 문구보다 유용한 결론을 얻을 수 있습니다. 예를 들어 실제 업무에서 개인정보를 제거한 코드 수정 20건, 문서 질의 20건, 다단계 업무 10건을 고릅니다. 이전 Sol·새 Sol·Astra에 같은 프롬프트, 같은 도구, 같은 테스트 데이터, 가능한 한 같은 추론 강도와 반복 횟수를 적용합니다. 난수와 외부 도구의 변동도 기록해야 합니다.

기록 항목	평가 방법	주의점
정답·완료율	사전에 작성한 채점표로 사람이 블라인드 검토	부분 성공과 완전 성공을 구분
지연	첫 토큰 시간과 전체 완료 시간을 각각 반복 측정	네트워크·도구 대기 시간을 분리
토큰·비용	응답 usage와 실제 청구 항목을 보관	캐시·도구·처리 모드 반영
수정 부담	사람이 결과를 고치는 시간과 오류 유형 기록	빠른 초안이 더 많은 검토를 유발할 수 있음

각 사례를 최소 세 번 반복하고 평균뿐 아니라 실패 사례를 남기세요. 동일 조건에서 실패 원인을 분류해야 ‘빠르지만 틀린 답’, ‘정답이지만 승인 단계 누락’, ‘품질은 같지만 캐시 이득’처럼 실제 의사결정에 필요한 차이가 보입니다. 독립 평가 수치가 공개되더라도 사내 데이터와 도구 환경이 다르면 결과가 달라질 수 있습니다.

7. 실패 사례와 운영 체크리스트

실패 사례 하나는 기존 Sol의 none 추론 설정을 그대로 유지해 요청이 거절되는 경우입니다. 다른 사례는 Chat Completions에서 함수 호출이 되던 워크플로를 새 Sol로 옮기며 도구 사용을 기대하는 것입니다. 또 캐시 읽기 가격만 비교하고 캐시 쓰기, 길어진 출력, 웹 검색 비용을 빼면 예상 절감액이 과장됩니다. 벤치마크의 ‘partial reward’를 완전 성공률처럼 표현하는 것도 독자에게 잘못된 기대를 줍니다.

• 공식 모델 ID와 API 접근 권한 확인
• Responses API 도구 호출 필요 여부 확인
• 추론 강도 none·minimal 제거
• 가격표의 272K 입력 토큰 경계 및 처리 모드 확인
• 개인정보·기밀정보를 평가 샘플에서 제거
• 부분 성공, 재시도, 사람의 수정 시간까지 기록
• 되돌릴 수 있도록 기존 모델 설정과 비교 결과 보관

8. 자주 묻는 질문

Q1. GPT-6.1 Sol이 GPT-6 Astra보다 항상 좋은가요?

아닙니다. 제공사 발표는 코딩·컴퓨터 사용·전문 업무의 일부 평가에서 Astra에 가까운 성능을 주장하지만, 과학 작업에서는 Astra 최고 점수 68.1%를 별도로 강조합니다. 자신의 업무 데이터에서 동조건으로 검증해야 합니다.

Q2. 기존 GPT-6 Sol과 가격이 완전히 같나요?

일반 입력 $2, 출력 $10은 같지만 캐시 입력은 100만 토큰당 $0.20에서 $0.10으로 낮아졌습니다. 캐시 쓰기와 초장문 요청, 별도 도구 비용을 포함하면 총비용은 사용 패턴에 따라 달라집니다.

Q3. ChatGPT에서도 바로 선택할 수 있나요?

공식 발표 시점에는 일반 Chat에서 제공되지 않고, 지원 대상의 ChatGPT Work·Codex 및 OpenAI API에서 이용할 수 있다고 안내합니다. 실제 계정의 표시 여부는 요금제와 워크스페이스 설정에 따라 확인해야 합니다.

Q4. 이 글의 벤치마크는 직접 측정했나요?

아닙니다. 표의 성능 결과는 OpenAI가 공개한 제공사 측정값입니다. 저희가 API를 실행해 지연이나 정확도를 재현하지 않았으며, 독립 평가와도 구분해 읽어야 합니다.

9. 결론

GPT-6.1 Sol은 기존 Sol과 같은 일반 토큰 단가에서 캐시 읽기 비용을 낮추고, OpenAI의 여러 제공사 평가에서 코딩·자동화·컴퓨터 조작 능력 향상을 보여 준 새 후보입니다. 그렇지만 벤치마크 한두 개나 ‘Astra에 가깝다’는 표현만으로 실무 전환을 결정하면 안 됩니다. 같은 데이터와 도구, 추론 설정으로 반복 평가하고 사람의 검토 시간까지 포함해 작업당 비용을 비교하는 것이 합리적입니다.

공식 확인 자료

공식 자료: API 변경 로그, GPT-6.1 Sol 모델 페이지, OpenAI 발표와 제공사 측정 결과, GPT-6 사용·전환 가이드, API 가격표.

2026년 9월 28일 Anthropic이 Claude Sonnet 5.5를 공개했다. API 식별자는 claude-sonnet-5-5다. 코딩 에이전트나 문서 업무에 Sonnet 5를 쓰고 있다면, 이번 발표의 핵심은 토큰 단가 인상 없이 성능과 처리 속도를 높였다는 점이다. 다만 모델 이름만 교체하면 기존 요청이 400 오류를 낼 수 있어 마이그레이션 확인이 먼저다. 이 글은 공식 자료와 독립 평가가 공개한 수치를 구분해 가격, 실제 성능, 적용 절차를 살펴본다.

본문의 인물·업무 장면 이미지는 GPT로 만든 가상 사진이다. 실제 직원이나 필자가 API 성능을 직접 시험하는 장면을 촬영한 사진이 아니다. 이 글에서도 유료 API를 호출해 직접 재현 테스트를 하지는 않았다. 수치는 각 측정 주체가 공개한 결과로만 설명한다.

무엇이 출시됐고 어디에서 쓸 수 있나

Claude Sonnet 5.5는 Claude API뿐 아니라 Amazon Bedrock, Claude Platform on AWS, Google Cloud, Microsoft Foundry에서 제공된다고 Anthropic은 안내한다. 텍스트·이미지를 입력으로 받고 텍스트를 출력한다. 기본 컨텍스트 창은 100만 토큰, 일반 요청의 최대 출력은 12만 8천 토큰이다. 긴 문서를 한 번에 넣을 수 있다는 뜻이지 긴 입력에서 언제나 정확한 답을 보장한다는 뜻은 아니다. 긴 문맥의 검색·인용 정확도는 실제 업무 문서로 따로 확인해야 한다.

새 모델의 기본 추론 수준은 Claude API에서 high이고, 적응형 추론이 기본으로 켜져 있다. 코드 작성과 검토, 다단계 도구 사용, 문서·슬라이드·스프레드시트 제작처럼 결과물을 반복해서 다듬는 작업이 주요 활용처다. 공개 모델 설명은 상대적인 지연시간을 ‘빠름’으로 표시하지만 밀리초 단위의 보편적인 응답시간을 제시하지 않는다. 자신의 네트워크와 요청 길이에 적용할 지연 수치를 발표 자료에서 그대로 가져오면 안 된다.

항목	Claude Sonnet 5.5	확인할 점
Claude API 모델 ID	claude-sonnet-5-5	플랫폼별 모델 ID는 다를 수 있음
출시일	2026년 9월 28일	제공 지역·계정 권한은 플랫폼에서 확인
입력·출력	텍스트·이미지 → 텍스트	이미지 생성 모델은 아님
컨텍스트·최대 출력	100만·12만 8천 토큰	Batch API 베타에는 별도 출력 한도
기본 추론 설정	적응형 추론, high 노력 수준	이전 Sonnet의 thinking 설정을 그대로 복사하지 않기

사양과 플랫폼 범위는 Anthropic의 Sonnet 5.5 모델 페이지와 Claude Platform 릴리스 노트를 기준으로 했다.

가격 비교: 토큰 단가와 작업당 비용을 따로 보자

Anthropic의 Claude API 기본 가격은 입력 100만 토큰당 2달러, 출력 100만 토큰당 10달러다. Sonnet 5와 같은 기본 토큰 단가다. 5분 캐시 쓰기는 2.50달러, 1시간 캐시 쓰기는 4달러, 캐시 읽기는 0.20달러다. 배치 API에는 입력·출력에 50% 할인이 표시돼 있다. 플랫폼별 청구, 긴 입력, 부가 기능과 캐시 조건은 실제 견적에서 확인해야 한다.

모델	입력 100만 토큰	출력 100만 토큰	해석
Claude Sonnet 5.5	$2	$10	새 Sonnet의 기본 요금
Claude Sonnet 5	$2	$10	기본 단가는 같음
Claude Opus 5.5	$4	$20	복잡한 판단 작업용 상위 선택지
GPT-6 Sol	$2	$10	OpenAI 표준 요금의 짧은 입력 구간 기준

예를 들어 캐시가 없고 한 작업에 입력 1만 토큰, 출력 2천 토큰을 썼다면 Sonnet 5.5의 기본 토큰 비용은 약 0.04달러다. 같은 토큰량에서 Opus 5.5는 약 0.08달러다. 이 계산은 토큰 단가만 곱한 예시다. 실제 작업에서는 모델마다 추론·도구 호출 횟수와 출력 길이가 달라 같은 요청이라도 청구액이 달라진다. Anthropic이 제시한 ‘작업당 최대 30% 절약’도 제공사 측정값이며 모든 고객에게 적용되는 할인율이 아니다. 경쟁 모델의 캐시·긴 입력·처리 등급 요금도 서로 다르므로 표의 단가만으로 최저비용 모델을 결정할 수 없다.

Claude 요금은 공식 모델 사양과 공식 가격표, GPT-6 Sol은 OpenAI API 변경 기록의 출시 가격을 참조했다.

실제 성능: 공개 측정값이 말하는 범위

아래 수치는 필자의 직접 테스트가 아니다. 첫 세 줄은 Anthropic 발표에 실린 제공사 측정값이며, GDPval-AA 줄은 평가사 Artificial Analysis가 운영한 독립 평가를 별도 원본 순위표에서 확인했다. 측정 방법과 모델의 노력 수준이 다르면 숫자를 한 줄로 이어 단순 순위를 매겨서는 안 된다.

시험·평가 조건	Sonnet 5.5	비교 수치	측정 주체·방법과 한계
Terminal-Bench 4.0, 명령줄에서 여러 단계를 수행하는 코딩 과제	70.6%	Sonnet 5 10.3%, Opus 5.5 66.4%	Anthropic 발표의 제공사 측정값. Opus 5.5는 xhigh 노력 수준의 최고 점수로 표기. 동일 추론 예산 비교로 읽지 말 것.
FrontierCode 1.1 Main, 코드 변경이 사람의 추가 수정 없이 병합 가능한지 평가	46.2% (max), 52.1% (xhigh)	Sonnet 5 42.4%, Opus 5.5 54.4%, GPT-6 Sol 49.3%	Anthropic 발표의 제공사 측정값. 노력 수준마다 결과가 달라 최고값만 묶어 우열을 단정할 수 없음.
OSWorld 2.1, 컴퓨터 조작 과제의 부분 성공 판정	80.1%	Sonnet 5 57.0%, Opus 5.5 81.8%	Anthropic 발표의 제공사 측정값. 부분 성공 기준이며 실제 회사 시스템의 성공률이 아님.
GDPval-AA v2.1, 다양한 직업의 실제형 업무 결과물 평가; 적응형 추론 max	Elo 1844 ±24	Sonnet 5 max 1449 ±22, Opus 5.5 max 1846 ±23	Artificial Analysis 운영 독립 평가의 공개 순위표. Sonnet 5.5는 출시 전 배포본에서 평가됐고 구조화 출력 버그가 이후 수정됨.

표본 수와 세부 시행 절차는 평가마다 다르다. Terminal-Bench는 다단계 터미널 작업, FrontierCode는 실제 병합 가능성, OSWorld는 화면 조작, GDPval-AA는 직업별 산출물을 평가한다. 공개 발표 표만으로 각 시험의 전체 표본과 재시도 정책을 일괄 확인할 수 없다. 세부 조건은 Anthropic 출시 발표에서 연결한 시스템 카드와 Artificial Analysis 원본 순위표를 함께 확인해야 한다. 특히 GDPval-AA의 Sonnet 5.5와 Opus 5.5는 2점 차인데 각 수치의 신뢰구간이 겹친다. 이 차이만으로 실사용 우열을 단정하기 어렵다.

Anthropic은 Sonnet 5.5의 출력 생성이 Sonnet 5보다 30% 이상 빠르다고 설명한다. 이는 제공사 측정 주장이다. 첫 토큰까지의 지연, 한국에서의 왕복 시간, 긴 프롬프트 처리 시간과 도구 호출 성공률이 이 글에서 독립적으로 검증된 것은 아니다. 실제 업무에는 평균뿐 아니라 최악 지연과 재시도율을 측정해야 한다.

모델을 바꾸기 전에 확인할 다섯 가지 API 변경

첫째, Sonnet 5에서 사전 추론을 끄기 위해 쓰던 thinking: {"type":"disabled"}는 Sonnet 5.5에서 오류를 낸다. 사전 추론 없이 도구 사이의 짧은 진행 메모만 허용하려면 thinking: {"type":"between_tools"}를 쓴다. 이 설정은 low·medium·high 노력 수준에서만 허용된다. xhigh·max를 쓰려면 적응형 추론으로 전환한다. 둘째, tool_choice의 any와 특정 tool 강제 지정은 400 오류를 낸다. 자동 선택과 엄격한 도구 스키마를 조합하는 편이 문서상 대안이다.

셋째, 보존된 thinking 블록은 모델과 대화에 결합된다. 모델을 바꾸거나 이전 메시지·도구 정의를 수정하면 과거 블록이 버려지거나 계정 설정에 따라 요청이 거절될 수 있다. 넷째, Claude API와 Google Cloud에서 예전 computer_20251124 컴퓨터 사용 도구는 지원하지 않으며 computer_toolset_20260801로 옮겨야 한다. 다섯째, 일부 advisor 조합도 지원 대상에서 빠진다. 응답의 도구 호출 사이 텍스트가 thinking 블록으로 이동하는 변화도 있으므로 스트리밍 화면에 글이 멈춘 것처럼 보이지 않는지 확인한다.

플랫폼별 차이가 있다. 예컨대 예전 컴퓨터 도구에 대한 Bedrock 동작은 Claude API·Google Cloud와 같지 않다. 실제 배포 환경의 문서에 맞춰 코드를 수정해야 한다. 요청 전후 예시는 Sonnet 5.5 마이그레이션 가이드와 변경점 상세 문서에 있다.

단계별 활용법: 작은 업무부터 전환하기

1. 작업을 나눈다. 저장소 전체 수정, 문서 초안, 문의 분류를 한 덩어리로 평가하지 말고 성공 기준이 다른 작업으로 구분한다. Sonnet 5.5는 범위가 명확한 코딩·문서 업무에 우선 배치하고, 복잡한 열린 문제는 Opus 5.5 등과 별도로 비교한다.
2. 기존 요청을 기록한다. 현재 Sonnet 5의 모델 ID, thinking 유형, 노력 수준, 도구 선택, 캐시 사용량을 남긴다. 평가에 사용할 입력에는 개인정보와 비밀키를 제거한다.
3. 깨지는 설정을 먼저 고친다. disabled thinking과 강제 tool_choice를 검색한다. 컴퓨터 도구를 쓰면 플랫폼별 도구 버전도 확인한다. 프롬프트와 모델 ID를 한꺼번에 바꾸면 결과 차이의 원인을 분리하기 어렵다.
4. 동일 조건으로 비교한다. 같은 작업 입력·도구·시간 제한·채점 기준에서 Sonnet 5와 5.5를 여러 차례 실행한다. 성공률, 사람이 고친 횟수, 출력 토큰, 총 청구액, p50·p95 지연을 기록한다.
5. 점진적으로 배포한다. 오류가 큰 작업은 기존 모델로 되돌리는 경로를 남기고, 성공 기준을 넘긴 유형만 새 모델에 보낸다. 장문 입력과 이미지 입력은 별도 사례로 검증한다.

예를 들어 코드 리뷰 보조라면 ‘오류 위치를 찾았는가’와 ‘수정안이 테스트를 통과했는가’를 따로 채점한다. 문서 요약이라면 근거 문장 링크, 누락 항목, 잘못 단정한 숫자를 확인한다. 공식 벤치마크에서 높은 점수를 받았어도 우리 팀의 파일 형식과 도구 호출 방식에서는 실패할 수 있다.

실패 사례와 발행 전 체크리스트

흔한 실패는 모델 ID만 바꾼 뒤 첫 요청이 400 오류로 끝나는 경우다. 원인은 Sonnet 5의 disabled thinking이나 강제 도구 선택일 수 있다. 또 긴 대화를 잘라 재전송하면서 thinking 블록 앞의 내용이 바뀌면 보존 블록 검사에 걸릴 수 있다. 이런 문제는 성능 하락이라기보다 API 계약 변경이다. 요청 본문과 오류 코드, 적용한 플랫폼을 함께 기록해야 원인을 구분할 수 있다.

비용에서도 실패가 생긴다. 토큰 단가가 같다는 이유로 예산을 그대로 두었는데, 에이전트가 도구를 더 많이 호출하면 작업당 청구액이 늘 수 있다. 반대로 한 번에 끝나는 비율이 높아지면 비용이 줄 수 있다. 따라서 월간 예산보다 먼저 대표 작업 20~30건의 성공당 비용을 계산해 보는 편이 낫다. 이 수량은 독자가 시작할 수 있는 평가 예시이지 모델 성능의 공식 표본 수가 아니다.

• 모델·플랫폼별 정확한 ID와 사용 권한을 확인했는가?
• thinking, effort, tool_choice, 컴퓨터 도구 버전을 점검했는가?
• 캐시 읽기·쓰기와 장문 입력의 청구 조건을 분리했는가?
• 성공률과 실패 유형을 사람이 확인했는가?
• 출시 자료의 제공사 측정값과 독립 평가를 구분했는가?
• 개인정보를 뺀 동일 입력을 반복해 성능을 다시 볼 수 있는가?

직접 비교를 재현하는 간단한 평가표

이 글은 API 키를 사용한 직접 테스트를 수행하지 않았다. 독자가 확인하려면 먼저 실제 업무에서 자주 발생하고 정답 또는 승인 기준을 정할 수 있는 과제를 고른다. 각 과제에 같은 입력 파일, 같은 시스템 지시, 같은 도구 권한과 시간 제한을 적용한다. 두 모델의 기본 노력 수준이 다르면 기본값 비교와 동일 노력 수준 비교를 분리한다. 각 과제를 적어도 여러 번 반복하고 순서를 섞어 캐시와 서버 상태의 영향을 줄인다.

기록 항목	적는 방법	판정 예시
정답·완료율	미리 정한 채점 기준으로 사람이 확인	통과/부분 통과/실패
도구 호출	호출 수, 오류 수, 재시도 수 분리	같은 결과에 필요한 호출이 줄었는가
속도	첫 응답과 전체 완료까지의 p50·p95	최악 지연도 허용 범위 안인가
토큰·비용	입력·출력·캐시 사용량과 청구액 기록	성공한 작업 1건당 비용
안전성	잘못된 출처, 과도한 파일 수정, 개인정보 노출 확인	사람의 수정 필요 여부

독립 순위표도 측정 시점과 배포본이 달라질 수 있다. Artificial Analysis가 시험한 Sonnet 5.5 출시 전 배포본에는 구조화 출력에 영향을 줄 수 있는 버그가 있었고 이후 수정됐다고 Anthropic은 밝혔다. 따라서 현재 API의 정확한 결과는 자신의 업무 평가로 다시 확인해야 한다.

자주 묻는 질문

Q1. Sonnet 5.5가 Sonnet 5보다 무조건 저렴한가?

기본 입력·출력 토큰 단가는 같다. 적은 토큰과 도구 호출로 일을 끝내면 작업당 비용이 내려가지만, 더 긴 추론이나 재시도가 생기면 반대가 될 수 있다. 캐시 조건과 사용 플랫폼까지 포함해 계산해야 한다.

Q2. 100만 토큰을 넣으면 긴 문서를 완벽히 이해하나?

컨텍스트 한도는 받아들일 수 있는 입력 범위다. 중요한 조항을 놓치지 않는다는 보증은 아니다. 실제 문서에 대한 근거 인용·누락·오답률을 따로 평가하고, 필요하면 문서를 나눠 검증한다.

Q3. Sonnet 5 코드의 모델명만 바꾸면 바로 작동하나?

아니다. thinking 유형, 강제 도구 선택, 보존된 thinking 블록, 컴퓨터 도구 버전 등에서 오류가 날 수 있다. 마이그레이션 가이드의 요청 예시를 적용한 뒤 작은 범위에서 시험한다.

Q4. 공식 벤치마크 숫자를 우리 서비스의 예상 성공률로 써도 되나?

안 된다. 공개 평가는 특정 과제·도구·노력 수준에서 얻은 수치다. 서비스의 입력 품질, 한국어 자료, 외부 도구와 검수 기준이 다르므로 동일 조건을 설계해 직접 측정해야 한다.

공식 확인 자료

• Anthropic: Claude Sonnet 5.5 출시 발표와 성능 표
• Claude Platform: 2026년 9월 28일 릴리스 노트
• Claude Sonnet 5.5 공식 모델 사양·가격
• Sonnet 5.5 새 기능과 깨지는 변경
• Sonnet 5.5 마이그레이션 가이드
• Artificial Analysis GDPval-AA 독립 평가 순위표
• OpenAI API 변경 기록: GPT-6 Sol 출시 요금

정리하면 Sonnet 5.5는 Sonnet 5와 같은 기본 토큰 단가로 새 성능과 속도를 제시한다. 실제 이득은 업무 유형과 추론 설정에 따라 달라진다. 먼저 깨지는 요청 설정을 고친 뒤 동일한 업무 과제로 품질, 시간, 성공당 비용을 측정하는 것이 도입 판단의 출발점이다.

2026년 9월 28일 확인 · 오늘의 AI 생활실험실

OpenAI가 9월 22일 GPT-6 Sol과 GPT-6 Luna를 API에 공개했습니다. 둘 다 텍스트와 이미지를 입력받아 텍스트를 생성하고, Responses API와 Chat Completions에서 사용할 수 있습니다. 이름만 보면 Astra의 작은 버전처럼 보이지만 실제 선택 기준은 훨씬 구체적입니다. Sol은 복잡한 코딩과 에이전트 업무의 균형형, Luna는 반복량이 많은 정형 업무의 비용형에 가깝습니다.

가장 눈에 띄는 변화는 가격입니다. Sol의 표준 단가는 입력 100만 토큰당 2달러, 출력 10달러이고 Luna는 입력 0.10달러, 출력 0.50달러입니다. 다만 27만 2천 토큰을 넘는 긴 입력, 캐시 쓰기, Fast 처리, 지역 처리를 사용하면 단가가 달라집니다. 단순히 기본 가격표만 보고 월 예산을 계산하면 실제 청구액과 차이가 날 수 있습니다.

이 글은 유료 API를 직접 실행한 체험기가 아닙니다. OpenAI의 공식 출시 글, 모델 문서, 가격표, 시스템 카드와 공개 평가 설명을 교차 확인해 정리했습니다. 성능 수치는 제공사 측정값과 외부 평가 주체가 운영한 시험을 구분해 해석하며, 공개되지 않은 반복 횟수나 분산은 추정하지 않습니다. 본문 사진 3장은 가상의 한국인 성인을 표현한 AI 생성 실사 이미지이며 실제 직원이나 직접 성능 테스트 장면이 아닙니다.

1. GPT-6 Sol과 Luna, 무엇이 다른가

OpenAI API 변경 기록은 모델 ID를 각각 gpt-6-sol, gpt-6-luna로 안내합니다. 두 모델 모두 105만 토큰 문맥 창과 최대 12만 8천 출력 토큰을 지원합니다. Sol의 지식 기준일은 2026년 4월 20일, Luna는 2026년 5월 18일입니다. 최신 사건을 자동으로 안다는 뜻은 아니므로 현재 정보가 필요한 작업에는 웹 검색이나 자체 검색 계층을 연결해야 합니다.

항목	GPT-6 Sol	GPT-6 Luna
권장 용도	복잡한 코딩, 판단이 필요한 에이전트 업무	범위가 명확한 대량·반복 업무
모델 ID	gpt-6-sol	gpt-6-luna
문맥 창	1,050,000토큰	1,050,000토큰
최대 출력	128,000토큰	128,000토큰
추론 강도	none·low·medium·high·xhigh·max	none·low·medium·high·xhigh·max
지식 기준일	2026-04-20	2026-05-18
입력/출력	텍스트·이미지 입력, 텍스트 출력	텍스트·이미지 입력, 텍스트 출력

기본 추론 강도는 두 모델 모두 medium입니다. Responses API에서는 웹 검색, 파일 검색, 코드 인터프리터, 호스티드 셸, 컴퓨터 사용, MCP 같은 도구를 지원합니다. Chat Completions의 함수 호출은 reasoning_effort를 none으로 둔 경우에만 지원된다는 모델 문서의 제한도 확인해야 합니다. 기존 코드를 모델 이름만 바꾸는 방식으로 이전하면 이 차이에서 오류가 날 수 있습니다.

2. 가격 비교: Astra보다 얼마나 저렴한가

공식 API 가격표의 표준 처리·짧은 문맥 기준으로 Sol은 Astra의 5분의 1, Luna는 Astra의 100분의 1 수준의 입력·출력 단가입니다. 캐시 읽기는 일반 입력의 10%, 캐시 쓰기는 일반 입력의 125%입니다. 이전 GPT-5.6 계열과 비교하면 OpenAI는 Sol과 Luna의 가격이 각각 약 50% 내려갔다고 설명합니다.

모델	입력	캐시 입력	캐시 쓰기	출력
GPT-6 Astra	$10.00	$1.00	$12.50	$50.00
GPT-6 Sol	$2.00	$0.20	$2.50	$10.00
GPT-6 Luna	$0.10	$0.01	$0.125	$0.50

표의 금액은 100만 토큰당 미국 달러이며 표준 처리의 짧은 문맥 구간입니다. 예를 들어 입력 10만 토큰과 출력 1만 토큰을 한 번 사용하면 단순 계산상 Sol은 약 0.30달러, Luna는 약 0.015달러입니다. 같은 요청을 Astra로 처리하면 약 1.50달러입니다. 환율, 도구 호출비, 재시도, 이미지 입력 토큰, 캐시 쓰기 비용은 별도로 더해야 합니다.

3. 27만 2천 토큰을 넘으면 요청 전체가 비싸진다

두 모델은 입력이 272,000토큰을 넘으면 긴 문맥 요금을 적용합니다. 초과분만 비싸지는 방식이 아니라 요청 전체의 입력과 캐시 관련 단가가 2배, 출력 단가가 1.5배가 됩니다. Sol은 입력 4달러·캐시 입력 0.40달러·캐시 쓰기 5달러·출력 15달러, Luna는 입력 0.20달러·캐시 입력 0.02달러·캐시 쓰기 0.25달러·출력 0.75달러입니다.

회의록, 이전 대화, 도구 결과, 원문 문서를 습관적으로 모두 붙이면 이 경계를 쉽게 넘습니다. 긴 문맥이 성공률을 올리지 못한다면 검색으로 필요한 구간만 가져오고 오래된 도구 출력을 압축하는 편이 경제적입니다. EU 데이터 레지던시는 표준 처리에서만 가능하며, 지원되는 지역 처리는 10% 할증됩니다. Batch와 Flex는 표준 단가의 50%, Fast는 해당 단가의 2배라는 점도 처리 방식 선택에 반영해야 합니다.

4. 실제 성능: 공식 수치를 어떻게 읽어야 하나

공식 출시 발표는 전문 업무, 코딩, 컴퓨터 사용 평가를 공개했습니다. AutomationBench 1.0.6은 47개 도구를 사용해 영업·마케팅·운영·지원·재무·인사 업무를 끝까지 수행하는 시험입니다. GPT-6 Sol xhigh는 33.2%, 작업당 비용 0.27달러로 보고됐습니다. 같은 표에서 Astra low는 30.3%이지만 비용은 Sol의 3.9배, Claude Opus 5 max는 26.9%이지만 비용은 11.1배였습니다.

평가	모델·설정	공개 결과	해석 시 주의
AutomationBench 1.0.6	GPT-6 Sol xhigh	33.2%, $0.27/작업	OpenAI가 정리한 평가, 도구 47개 사용
Agents’ Last Exam V1	GPT-6 Sol max	56.4%	55개 하위 산업의 장기 전문 업무
DeepSWE v1.1	GPT-6 Sol max	68.8%	Fable 5 xhigh 69.9%보다 1.1%p 낮음
DeepSWE v1.1	GPT-6 Luna max	66.6%	저비용이지만 max 추론 조건
OSWorld 2.0 offline	GPT-6 Sol xhigh	60.5%	2026-08-08 오프라인 세트의 부분 보상

이 수치들은 출시사가 선택하고 정리한 결과이므로 제공사 측정값으로 봐야 합니다. AutomationBench, Agents’ Last Exam, DeepSWE, OSWorld는 외부 평가 프로젝트이지만 어떤 추론 설정·도구 버전·시간 제한을 적용했는지에 따라 결과가 달라질 수 있습니다. OpenAI는 경쟁 모델 수치 일부를 공개 보고서에서 가져왔다고 밝히며, 실제 ChatGPT와 연구 환경은 시스템 프롬프트와 도구가 달라 결과가 다를 수 있다고 설명합니다.

반복 횟수, 실행별 편차, 한국어 과제 성능은 출시 글의 요약표만으로 충분히 확인되지 않습니다. 따라서 68.8%와 66.6%의 차이를 모든 코딩 업무의 우열로 일반화하면 안 됩니다. 특히 Luna의 최대 추론은 값싼 토큰 단가와 별개로 출력 토큰과 시간이 늘 수 있으므로 작업당 비용을 함께 기록해야 합니다.

5. 코딩과 에이전트 업무에는 Sol이 먼저다

요구사항이 자주 바뀌고 여러 파일을 수정하며 테스트까지 통과해야 하는 업무라면 Sol을 우선 후보로 두는 편이 합리적입니다. GPT-6 Sol 모델 문서는 복잡한 코딩과 에이전트 워크플로를 대표 용도로 제시합니다. 다만 공식 점수가 높더라도 저장소 규칙을 어기거나 불필요한 파일을 수정하면 실제 업무에서는 실패입니다.

1. 최근 실제 이슈와 풀리퀘스트에서 재현 가능한 과제 20개를 고릅니다.
2. 모델별로 같은 저장소 상태, 같은 도구 권한, 같은 시간 제한을 적용합니다.
3. low·medium·high를 먼저 비교하고 xhigh·max는 어려운 과제에만 제한합니다.
4. 테스트 통과뿐 아니라 변경 범위, 코드 스타일, 리뷰 수정 횟수를 기록합니다.
5. 성공한 작업 1건당 총 토큰과 도구 비용을 계산합니다.

처음부터 전 요청을 max로 돌리면 품질 차이보다 비용과 대기 시간이 먼저 커질 수 있습니다. 기본 medium으로 시작해 실패가 반복되는 과제만 단계적으로 올리는 라우팅이 실무적입니다. Astra는 모호한 고난도 문제와 긴 자율 작업에 남겨 두고, Sol을 기본 작업 모델로 두는 2단 구조도 검토할 만합니다.

6. 분류·추출·요약은 Luna로 비용을 낮춘다

GPT-6 Luna 모델 문서는 범위가 분명하고 대량인 업무를 권장합니다. 고객 문의 라우팅, 문서 메타데이터 추출, 정형 요약, 간단한 품질 검사, 후보 목록 생성처럼 출력 형식이 명확한 작업이 대표적입니다. 구조화 출력과 함수 호출을 사용하면 후처리 오류를 줄일 수 있습니다.

업무	권장 시작점	승격 조건
문의 분류	Luna none/low	모호한 다중 의도면 medium 또는 Sol
문서 필드 추출	Luna low	표·이미지 혼합 실패가 반복되면 Sol
긴 보고서 요약	Luna medium	근거 연결·상충 분석이 필요하면 Sol
코드 수정	Sol medium	장기 자율 작업은 high 이상 또는 Astra
브라우저 업무	Sol high	실패 비용이 크면 Astra와 사람 검토

Luna가 싸다는 이유로 모든 요청을 몰아넣으면 재시도와 사람 검토가 늘어 총비용이 오를 수 있습니다. 반대로 간단한 추출까지 Sol이나 Astra로 처리하면 품질 차이가 거의 없는 구간에 비용을 쓰게 됩니다. 업무별 합격 기준을 먼저 정하고 실패한 경우에만 상위 모델로 승격하는 방식이 가장 관리하기 쉽습니다.

7. 캐시가 실제 비용을 좌우한다

GPT-6 계열의 캐시 읽기는 일반 입력의 10% 가격입니다. OpenAI는 고정 프롬프트 앞부분을 재사용하기 쉽게 캐시 동작을 개선했고, 추론 강도와 사용 가능한 도구를 바꿔도 앞선 문맥 캐시를 보존할 수 있다고 설명합니다. 명시적 캐시 중단점을 사용하면 어느 접두사까지 재사용할지 조정할 수도 있습니다.

운영에서는 긴 시스템 지침, 도구 정의, 회사 정책, 공통 문서를 앞에 두고 매 요청마다 바뀌는 사용자 입력을 뒤에 둡니다. 캐시 쓰기는 일반 입력의 1.25배이므로 대화 한 번으로 끝나는 프롬프트에는 이득이 작을 수 있습니다. 반복 횟수와 캐시 적중률을 함께 보면서 손익분기점을 계산해야 합니다. 개인 식별 정보나 비밀키를 캐시 키에 넣어서는 안 됩니다.

8. 이전할 때 생기는 대표적인 실패

실패 상황	원인	예방 방법
함수 호출이 작동하지 않음	Chat Completions에서 추론 강도를 none 이외로 사용	Responses API로 이전하거나 none 조건 확인
예산이 갑자기 증가	272K 입력 경계를 넘겨 전체 요청에 긴 문맥 단가 적용	요청별 입력 토큰 알림과 문맥 압축 적용
Luna 재시도가 많음	모호한 판단 업무까지 저비용 모델에 배정	실패 조건을 정의해 Sol로 자동 승격
캐시 적중률이 낮음	공통 접두사의 순서와 내용이 매번 변함	고정 지침을 앞에 두고 변동 입력을 뒤에 배치
공식 점수와 현업 결과가 다름	도구·언어·시간 제한·채점 기준 차이	자사 과제와 동일 조건으로 반복 평가

또 하나의 함정은 Fast 처리입니다. 더 빠른 응답이 필요하더라도 토큰 단가가 2배이므로 전체 업무에 켜기보다 사용자 대기 시간이 중요한 요청에만 적용하는 편이 좋습니다. 지역 처리는 규정 준수에 필요한 경우가 있지만 10% 할증과 지원 조건을 확인해야 합니다. 비용 최적화는 모델 하나를 고르는 문제가 아니라 모델·추론 강도·처리 등급·캐시를 함께 설계하는 문제입니다.

9. 직접 재현하는 성능·비용 테스트

현재 이 글에는 실제 API 키로 수행한 직접 테스트가 없습니다. 독자가 자기 환경에서 재현할 수 있도록 평가 절차를 제시합니다. 과제는 최소 20개, 각 조건은 최소 3회 반복하고 모델 이름을 가린 뒤 결과를 채점하는 것을 권합니다.

1. 업무별 정답 또는 합격 기준을 문서화합니다. 주관 평가라면 두 명 이상이 독립 채점합니다.
2. Sol과 Luna에 같은 입력, 같은 도구, 같은 제한 시간을 적용합니다.
3. 첫 응답 시간, 전체 완료 시간, 입력·캐시·추론·출력 토큰을 분리해 기록합니다.
4. 도구 호출 성공률, 재시도 횟수, 사람 수정 시간을 측정합니다.
5. 평균만 보지 말고 중앙값과 상위 95% 지연, 실행별 편차를 함께 봅니다.
6. 마지막에 총비용을 합격한 작업 수로 나눠 ‘성공 1건당 비용’을 계산합니다.

예를 들어 Luna가 요청당 20배 저렴해도 성공률이 낮아 Sol로 재시도하고 사람이 수정한다면 작업당 비용 차이는 크게 줄어듭니다. 반대로 명확한 분류 업무에서 Luna가 같은 합격률을 유지한다면 대량 처리 비용을 크게 낮출 수 있습니다. 공식 벤치마크는 후보를 고르는 신호이고 최종 결정은 자사 업무의 반복 측정값이어야 합니다.

10. 도입 전 체크리스트

• 모델 ID를 별칭이 아닌 gpt-6-sol 또는 gpt-6-luna로 기록했다.
• Responses API와 Chat Completions의 함수 호출 조건 차이를 확인했다.
• 272,000토큰 긴 문맥 경계와 전체 요청 할증을 예산에 반영했다.
• 캐시 읽기와 캐시 쓰기를 따로 집계한다.
• Batch·Flex·Fast·지역 처리의 배수를 구분했다.
• 업무별로 Luna에서 Sol, Sol에서 Astra로 승격하는 기준이 있다.
• 직접 테스트라고 쓸 수 있는 재현 로그와 설정을 보관한다.
• 법률·의료·재무·인사처럼 영향이 큰 결과에는 사람 승인을 둔다.
• 공식 점수를 독립 검증 결과처럼 표현하지 않는다.
• 기존 모델로 즉시 돌아갈 수 있는 모델 라우팅 스위치를 준비했다.

11. 자주 묻는 질문

GPT-6 Sol과 Luna 중 무엇부터 써야 하나요?

복잡한 코딩, 여러 도구를 거치는 판단 업무라면 Sol부터 시작하세요. 분류·추출·정형 요약처럼 범위가 명확하고 호출량이 많다면 Luna부터 시험하는 편이 좋습니다.

GPT-6 Astra를 완전히 대체하나요?

아닙니다. OpenAI도 Astra를 최고 성능 모델로 안내합니다. 모호한 고난도 문제와 긴 자율 작업은 Astra가 후보이고, 비용과 처리량을 함께 봐야 하는 일상 업무는 Sol·Luna가 후보입니다.

문맥 창이 105만 토큰이면 항상 많이 넣어도 되나요?

아닙니다. 272,000토큰을 넘으면 요청 전체에 긴 문맥 단가가 적용됩니다. 긴 입력이 실제 성공률을 높이는지 먼저 측정하고 검색·압축을 사용하세요.

표의 성능 수치는 독립 평가인가요?

시험 자체는 외부 프로젝트가 포함되어 있지만 이 글에 인용한 비교표는 OpenAI 출시 발표가 선택해 정리한 제공사 공개값입니다. 독립 반복 검증과 동일하게 보지 않습니다.

한국어 성능도 공식 점수로 확인할 수 있나요?

출시 글의 주요 표만으로는 한국어 업무의 반복 성능을 판단하기 어렵습니다. 실제 한국어 문의·문서·코드 리뷰 과제를 같은 조건으로 세 번 이상 비교하는 것이 안전합니다.

12. 결론: 모델 이름보다 라우팅 기준이 중요하다

GPT-6 Sol과 Luna의 핵심은 Astra급 기능을 모든 요청에 쓰는 대신 작업 난이도와 비용에 맞춰 나눌 수 있게 됐다는 점입니다. Sol은 복잡한 실무의 기본 모델, Luna는 명확한 대량 업무의 비용 모델로 출발점이 다릅니다. 기본 단가만 보면 Luna가 압도적으로 저렴하지만 재시도와 사람 수정까지 포함한 작업당 비용을 계산해야 진짜 차이가 보입니다.

가장 현실적인 도입 순서는 Luna low 또는 medium에서 시작해 합격 기준을 통과하지 못하면 Sol medium 또는 high로 올리고, 실패 비용이 큰 일부 업무만 Astra에 맡기는 것입니다. 여기에 캐시 적중률과 272K 경계 알림을 붙이면 비용 변동을 줄일 수 있습니다. 공식 점수는 후보를 좁히는 자료로 쓰고, 최종 선택은 같은 입력·같은 도구·같은 시간 제한으로 반복한 자사 결과에 맡기세요.

공식 확인 자료

• OpenAI API 변경 기록
• GPT-6 Sol·Luna 공식 출시 발표
• GPT-6 Sol 모델 문서
• GPT-6 Luna 모델 문서
• OpenAI API 공식 가격표
• GPT-6 모델 이전·사용 가이드
• 공식 모델 선택 가이드
• GPT-6 시스템 카드·평가 자료

2026년 9월 22일 확인 · 오늘의 AI 생활실험실

스페이스XAI(SpaceXAI, 옛 xAI)가 9월 21일 Grok 4.7을 API에 공개했습니다. 50만 토큰 문맥, 이미지 입력, 네 단계 추론 강도, 웹 검색·코드 실행 도구를 지원하며 짧은 문맥 기준 입력 100만 토큰당 2달러, 출력 6달러입니다. 그러나 “신형이니 무조건 갈아타자”는 결론은 이릅니다. 공개 성능표는 제공사 측정값이고, 비교 모델의 실행 설정은 공개되지 않았으며, 장문 요청은 단가가 두 배로 올라갑니다.

이 글은 스페이스XAI의 공식 출시문·모델 문서·가격표를 교차 확인한 분석입니다. 이 블로그가 유료 API로 직접 성능을 측정한 후기가 아닙니다. 독립 평가 기관의 충분한 Grok 4.7 결과도 아직 확인되지 않아, 제공사 수치와 독자가 재현할 시험 절차를 분리했습니다. 글에 사용한 사진 3장은 가상 성인을 표현한 AI 생성 실사 이미지이며 실제 직원이나 직접 테스트 장면이 아닙니다.

1. Grok 4.7에서 실제로 바뀐 것

스페이스XAI 공식 릴리스 노트는 API 모델 식별자를 grok-4.7로 명시합니다. 용도는 코딩, 에이전트 작업, 지식 업무입니다. 공식 모델 문서에 따르면 문맥 창은 500,000토큰이고 지식 기준일은 2026년 5월입니다. 텍스트와 이미지를 입력할 수 있지만 출력은 텍스트입니다. 텍스트 출력 한도는 별도로 두지 않았다고 안내합니다.

항목	공식 사양	도입 전 해석
모델 ID	grok-4.7	별칭 대신 고정 ID로 시험 기록
문맥 창	500,000토큰	기억 정확도나 전량 활용을 보장하지 않음
입출력	텍스트·이미지 입력, 텍스트 출력	음성·영상 생성 모델과 혼동 금지
추론 강도	low·medium·high·xhigh	기본값은 high, 비용·시간을 함께 측정
API	Responses, Chat Completions	신규 개발은 상태·도구 처리 요구에 맞춰 선택
도구	함수 호출·웹·X 검색·코드 실행	도구 호출료와 권한 통제를 별도 계산

Grok 4.7은 Responses API에서 reasoning.encrypted_content를 요청 여부와 관계없이 반환합니다. 다중 턴에서는 이 추론 항목을 변경하지 않고 다음 입력에 다시 보내야 문맥이 이어집니다. Chat Completions 동작은 같지 않으므로 두 API의 응답 구조를 섞어 구현하면 안 됩니다.

2. Grok 4.6과 비교해 무엇이 개선됐나

공식 출시 발표는 이전 4.6보다 더 큰 기반 모델을 사용하고, 장시간 걸리는 어려운 과제 비중을 높여 강화학습을 더 오래 수행했다고 설명합니다. 자기 검증과 긴 문맥 관리, Grok Bot 환경 이해를 개선했다고도 밝힙니다. 다만 이 설명은 제공사의 설계 주장이지 모든 기업 데이터에서 확인된 결과가 아닙니다.

중요한 변화는 단가를 올리지 않고 공식 벤치마크 수치를 개선했다는 점입니다. Grok 4.6과 4.7의 표준 API 가격과 50만 토큰 문맥은 같습니다. 따라서 기존 4.6 사용자라면 먼저 동일한 프롬프트·도구·합격 기준으로 A/B 시험을 만들기 쉽습니다. 반면 4.5나 4.3에서 이동하는 경우 캐시 가격과 문맥 한도가 달라 전체 비용을 다시 계산해야 합니다.

3. 실제 성능: 공식 벤치마크를 어떻게 읽을까

아래 수치는 모두 스페이스XAI가 공개한 제공사 측정값입니다. 공식 각주는 시험 이름과 결과, 그리고 Grok 4.7의 DeepSWE 점수에 붙은 별표가 high effort라는 사실만 밝힙니다. 각 모델을 어떤 추론 강도와 도구 권한으로 실행했는지는 공개하지 않았습니다. 실행 조건을 확인할 수 없으므로 작은 점수 차이를 모델 자체의 확정적 우열로 해석하면 안 됩니다.

시험	Grok 4.7	Grok 4.6	GPT-5.6 Sol	Fable 5.1
CursorBench 4.0	46.3%	40.4%	41.7%	51.8%
DeepSWE v1.1	71.0%*	65.2%	72.7%	70.0%
EEBench	64.0%	53.0%	39.4%	56.4%
AA Briefcase v1.1	1,657	1,546	1,487	1,678
Terminal-Bench 4.0	38.0%	20.3%	37.3%	57.9%
Harvey Legal Agent	19.6%	15.8%	2.5%	6.7%
HealthBench Professional	56.7%	48.5%	60.5%	62.1%
GDPval	1,695 Elo	1,605 Elo	미공개	1,735 Elo

* 별표는 Grok 4.7의 DeepSWE 점수가 high effort 결과라는 공식 표기입니다. 공개 페이지는 시험 이름과 결과는 제공하지만 각 표본 수, 모든 실행 매개변수, 반복 횟수와 분산을 한 표 안에서 충분히 설명하지 않습니다. 따라서 “코딩 1위”처럼 단순화하면 안 됩니다. CursorBench와 Terminal-Bench에서도 순위가 다르고, 의료·법률 수치는 실제 전문 판단이나 안전성을 보장하지 않습니다.

출시 직후라 동일 버전의 신뢰할 만한 독립 평가 결과는 아직 충분히 확인되지 않았습니다. 후속 독립 평가가 나오면 모델 스냅샷, 추론 강도, 도구 허용 범위, 반복 횟수가 같은지 먼저 확인해야 합니다. 이 글은 제공사 표를 실제 사용 경험으로 표현하지 않습니다.

4. 가격표: 20만 토큰에서 단가가 바뀐다

공식 API 가격표는 프롬프트가 200,000토큰 미만이면 입력·캐시 입력·출력이 각각 100만 토큰당 $2·$0.50·$6이라고 안내합니다. 프롬프트가 200,000토큰 이상이면 요청의 모든 토큰에 장문 단가 $4·$1·$12가 적용됩니다. 초과분만 비싸지는 방식이 아닙니다.

구간	입력 100만 토큰	캐시 입력	출력
프롬프트 20만 미만	$2.00	$0.50	$6.00
프롬프트 20만 이상	$4.00	$1.00	$12.00
미국 지역 엔드포인트	글로벌 토큰 요금의 1.1배

예를 들어 입력 150,000토큰과 출력 10,000토큰을 쓰면 캐시가 없을 때 약 $0.36입니다. 입력이 220,000토큰으로 늘고 출력이 10,000토큰이면 장문 단가가 전체 요청에 적용되어 약 $1.00입니다. 환율, 서버 도구 호출료, 재시도와 실패 요청은 별도입니다.

웹 검색과 코드 실행은 토큰 비용 외에 호출 비용이 붙습니다. X 검색은 2026년 9월 21일 정오(PT)부터 반환한 게시물과 프로필 수 기준으로 과금 방식이 바뀐다고 가격표가 안내합니다. 에이전트가 몇 번 호출할지 고정되지 않으므로 월 예산은 질문 수가 아니라 성공한 작업당 총비용으로 계산하세요.

5. 캐시와 장문 문맥에서 비용을 지키는 방법

공식 문서는 Responses API의 prompt_cache_key, Chat Completions의 x-grok-conv-id를 권장합니다. 같은 대화를 같은 서버로 라우팅해 캐시 적중 가능성을 높이기 때문입니다. 키를 생략하면 캐시가 차가운 서버에 배정돼 반복 프롬프트도 전체 입력 요금이 나올 수 있습니다.

1. 고정 시스템 지침과 도구 정의를 프롬프트 앞쪽에 둡니다.
2. 업무·사용자별 안정적인 캐시 키를 정하되 개인정보를 키에 넣지 않습니다.
3. 응답의 실제 캐시 토큰과 cost_in_usd_ticks를 로그로 확인합니다.
4. 장기 에이전트는 컨텍스트 압축을 검토하되 압축 전후 핵심 조건이 유지되는지 시험합니다.
5. 200,000토큰 경계 전후의 비용과 성공률을 따로 집계합니다.

50만 토큰을 사용할 수 있다는 사실이 매 요청에 모든 문서를 넣으라는 뜻은 아닙니다. 검색으로 필요한 조각만 찾고, 오래된 도구 결과와 중복 로그를 제거하는 편이 비용과 오류를 함께 줄일 수 있습니다. 긴 문맥에서는 “찾아냈는가”와 “정확히 사용했는가”를 별도로 채점하세요.

6. 코딩 에이전트에 적용하는 단계별 방법

첫 적용은 저장소 전체 자동 수정이 아니라 작은 읽기 전용 진단부터 시작하는 편이 안전합니다. Responses API 안내에 맞춰 모델 응답과 도구 실행을 분리하고, 실제 파일 변경은 서버의 정책으로 제한하세요.

1. 과제 선정: 재현 가능한 버그 10개와 코드 설명 과제 10개를 준비합니다.
2. 기준 고정: 같은 저장소 커밋, 테스트 명령, 시간 제한, 추론 강도를 사용합니다.
3. 읽기 전용 실행: 검색·파일 읽기만 허용하고 원인 분석 정확도를 먼저 평가합니다.
4. 패치 단계: 별도 작업공간에서만 수정하게 하고 전체 테스트와 변경 범위를 확인합니다.
5. 도구 오류 시험: 명령 실패, 파일 없음, 테스트 시간 초과를 일부러 넣습니다.
6. 비용 계산: 재시도와 도구 호출까지 더해 합격한 패치 1건당 비용을 비교합니다.

실무에서는 코드를 많이 쓴 결과보다 변경한 줄이 요구사항을 만족하고 기존 기능을 깨뜨리지 않았는지가 중요합니다. 모델이 “테스트 통과”라고 말한 것과 실제 CI 결과를 분리해 저장하세요. 배포·병합·삭제는 사람이 검토하는 승인 단계로 남겨 두는 것이 좋습니다.

7. 문서·기획·분석 업무의 활용 방안

업무	AI에게 맡길 범위	사람이 확인할 항목
긴 회의 자료	쟁점과 결정 후보 추출	참석자·날짜·책임자 원문 대조
제품 요구사항	누락 조건·충돌 탐색	사업 우선순위와 최종 범위
경쟁사 조사	공식 문서 분류·비교표 초안	출처 날짜·지역·요금제 조건
데이터 분석	코드 초안·이상치 후보	표본·단위·재현 결과

장문 모델의 장점은 자료를 많이 넣는 데서 끝나지 않습니다. 답변에 근거 위치를 요구하고, 찾지 못한 항목은 “미확인”으로 남기게 해야 검토 시간이 줄어듭니다. 의료·법률·재무처럼 결과 영향이 큰 업무에서는 Grok 4.7의 제공사 벤치마크 점수를 전문가 검토의 대체 근거로 사용하면 안 됩니다.

8. 자주 발생할 실패와 수정 방향

실패 상황	원인 후보	수정 방향
비용이 예상보다 두 배 이상	20만 토큰 경계 초과	요청별 프롬프트 토큰과 적용 단가 기록
캐시가 거의 적중하지 않음	캐시 키 누락·앞부분 변경	안정적 키와 고정 접두부 사용
다중 턴에서 맥락 손실	암호화 추론 항목을 다시 보내지 않음	응답 항목을 변경 없이 다음 입력에 포함
코드는 생성했지만 테스트 실패	도구 결과를 모델 말로만 판단	실제 종료 코드와 테스트 로그를 판정 기준으로 사용
출력 지연이 커짐	xhigh와 과도한 출력	medium/high 대조 시험과 출력 형식 제한

Fast 변형은 같은 모델을 더 빠른 인프라에서 제공하고 가격은 두 배지만, 현재 공개 xAI API에서는 사용할 수 없습니다. Cursor와 Grok Build의 Fast 경험을 API 지연 성능으로 일반화하지 마세요. 미국 지역 엔드포인트도 데이터 처리 위치와 10% 요금 가산을 함께 검토해야 합니다.

9. 독자가 재현할 실제 성능 시험표

직접 API 키와 통제된 실행 환경이 있을 때만 직접 테스트라고 부를 수 있습니다. 아래 절차는 아직 수행하지 않은 권장 설계입니다. Grok 4.7과 현재 운영 모델을 같은 입력·도구·시간 제한으로 각각 최소 3회 실행하세요.

측정 항목	방법	기록값
업무 성공률	사전 합격 기준을 모두 충족한 실행 수/전체	성공·부분 성공·실패
첫 응답 지연	요청 전송부터 첫 토큰까지	중앙값과 상위 95%
완료 시간	마지막 도구 결과와 최종 답변까지	초 단위
도구 성공률	유효한 인수로 끝난 호출/전체 호출	중복·오류 포함
토큰	입력·캐시·추론·출력 분리	요청별 합계
작업당 비용	전체 토큰·도구 비용/성공 작업	달러와 원화 환산 시점

코딩은 테스트 통과뿐 아니라 불필요한 변경, 보안 경고, 리뷰 시간을 확인합니다. 문서 업무는 사실 오류와 근거 누락, 표 계산 재현성을 채점합니다. 모델 이름을 가리고 평가하면 기대 편향을 줄일 수 있습니다. 결과가 세 번뿐이면 평균 하나로 결론 내지 말고 실행별 편차를 함께 공개하세요.

10. 도입 전 체크리스트

• 계정에서 grok-4.7 접근과 실제 속도 제한을 확인했다.
• 20만 토큰 전후의 단가와 미국 지역 10% 가산을 비용표에 반영했다.
• 캐시 키, 암호화 추론 항목, 컨텍스트 압축 동작을 개발 환경에서 검증했다.
• 웹·X 검색과 코드 실행의 도구 비용 및 호출 상한을 정했다.
• 모델 출력과 실제 도구 결과를 분리해 로그에 남긴다.
• 쓰기·배포·삭제 권한에는 사람 승인과 되돌리기 절차가 있다.
• 개인정보·영업비밀은 최소한만 전달하고 보관 기간을 정했다.
• 기존 모델로 돌아갈 수 있는 라우팅과 중단 기준을 준비했다.

11. 자주 묻는 질문

Grok 4.7은 Grok 4.6보다 비싼가요?

표준 API의 토큰 단가와 50만 토큰 문맥은 같습니다. 다만 사용량·출력 길이·도구 호출과 20만 토큰 경계 때문에 실제 작업당 비용은 달라질 수 있습니다.

Grok 4.7 Fast를 API에서 선택할 수 있나요?

현재 공식 문서는 Fast가 Cursor와 Grok Build에서만 제공되고 공개 xAI API에는 없다고 명시합니다. 일반 API 모델 ID와 혼동하지 마세요.

공식 벤치마크만 보고 주력 모델로 바꿔도 되나요?

권장하지 않습니다. 비교 설정과 표본 정보가 완전히 같지 않고 독립 평가가 아직 충분하지 않습니다. 실제 업무 20개 이상을 같은 조건으로 반복해 성공률·지연·비용을 함께 보세요.

50만 토큰을 항상 채우는 것이 좋은가요?

아닙니다. 20만 토큰부터 전체 요청에 장문 요금이 적용됩니다. 관련 문서만 검색하고 압축하며, 긴 문맥이 실제 성공률을 높이는지 검증해야 합니다.

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

아닙니다. 스페이스XAI가 공개한 제공사 측정값입니다. 직접 유료 API 시험은 수행하지 않았고, 독자가 재현할 절차를 별도로 제시했습니다.

12. 결론: 점수보다 작업당 성공 비용으로 판단하자

Grok 4.7은 같은 가격의 4.6보다 여러 제공사 시험에서 개선됐고, 긴 코딩·지식 업무와 도구 사용을 겨냥한 분명한 업데이트입니다. 동시에 20만 토큰 장문 요금, 설정이 다른 비교표, 공개 API에 없는 Fast 변형은 도입 판단에서 놓치기 쉬운 조건입니다.

가장 현실적인 시작은 기존 4.6 또는 운영 모델과 제한된 A/B 시험을 만드는 것입니다. 성공 여부, 첫 토큰과 최종 완료 시간, 도구 호출 성공률, 캐시 적중, 재시도를 포함한 작업당 비용을 기록하세요. 이 기준을 통과할 때만 읽기 전용 업무에서 수정 업무로 범위를 넓히면 홍보 문구가 아니라 자기 서비스의 증거로 결정할 수 있습니다.

공식 확인 자료

• 스페이스XAI 개발자 릴리스 노트
• Grok 4.7 모델 사양과 API 예제
• Grok 4.7 공식 발표와 제공사 벤치마크
• 스페이스XAI 공식 가격표
• 추론 강도 설정 안내
• 프롬프트 캐싱 안내
• 컨텍스트 압축 안내
• Responses API 안내

2026년 9월 15일 확인 · 오늘의 AI 생활실험실

회의 녹음을 글로 바꾸는 일에서 정말 아까운 시간은 변환 버튼을 누른 뒤가 아니라, 잘못 적힌 이름과 숫자를 다시 듣고 고치는 순간입니다. Microsoft가 9월 10일 발표한 Azure AI Speech LLM 2607은 이런 다국어 인식과 전문용어 처리를 개선한 업데이트입니다. 무엇이 달라졌는지, 공개 성능표를 어디까지 믿어도 되는지, 우리 녹음으로 어떻게 검증할지를 함께 살펴봅니다.

자료의 범위: 이 글은 공식 문서와 공개 리더보드를 확인한 분석입니다. Azure API로 직접 성능 시험을 수행하지 않았습니다. 아래 활용 사례는 적용 제안이며 비용 계산은 가정입니다. 이미지 3장은 모두 가상의 성인을 표현한 AI 생성 실사형 이미지로, 실제 직원이나 직접 테스트를 촬영한 사진이 아닙니다.

1. 2607 업데이트에서 달라진 핵심

Microsoft는 2605 대비 혼합 언어, 이름·도메인 용어, 문장부호·숫자 표기 개선과 최대 3배 빠른 지연 성능을 발표했습니다. 또한 전문용어를 일반 프롬프트에 섞는 대신 전용 phrase list 매개변수로 전달하는 사용법을 강조합니다. 서비스 쪽에 자동 배포되는 업데이트이며, 발표 본문은 Fast API 이용을 명시합니다. Microsoft 공식 발표

변화	업무에서 확인할 점
대화 중 언어 전환 인식 개선	한국어 문장 속 영문 제품명이 누락되는지
숫자·문장부호 처리 개선	금액·날짜·소수점·부정 표현이 보존되는지
전용 phrase list	중요한 용어의 인식률과 잘못된 삽입을 함께 평가
2605 대비 최대 3배 속도 주장	동일 녹음의 전체 완료 시간을 별도 측정

2607은 업데이트 이름이지 API의 model에 임의로 넣을 값이 아닙니다. 기존 Speech 리소스와 선택한 전사 기능을 확인해야 합니다.

2. Fast 전사와 LLM Speech, 무엇을 선택할까

Fast transcription은 녹음 파일을 받아 결과를 동기식으로 돌려주는 전사 API입니다. 녹음을 빠르게 처리한다는 말과, 마이크 입력에 실시간 응답하는 스트리밍 서비스라는 말은 다릅니다. 회의가 끝난 뒤 회의록을 만드는 경우부터 적용하는 편이 평가 범위를 잡기 쉽습니다.

기능	Fast 기본	LLM Speech	MAI-Transcribe-2
음성 전사·화자 구분	지원	지원	지원
번역	미지원	지원	미지원
사용자 프롬프트	미지원	지원	미지원
스테레오 채널 처리	지원	지원	미지원
phrase list·타임스탬프	지원	지원	지원

위 표는 공식 기능 비교이지 인식 정확도 순위가 아닙니다. 지원 표시는 모든 언어·설정 조합에서 같은 품질을 보장하지 않습니다. LLM Speech와 MAI-Transcribe-2도 서로 다른 경로이므로 모델별 옵션을 섞지 마세요. Fast transcription 기능·입력 안내

3. 실제 성능: 제공사 측정값부터 분리해서 보기

공식 발표의 숫자와 공개 평가 사이트의 숫자는 출처와 비교 기준이 다릅니다. 먼저 제공사 주장에 어떤 빈칸이 있는지 확인하면 과장된 기대를 줄일 수 있습니다.

제공사 발표 항목	확인된 내용	해석의 한계
속도, Microsoft 내부 평가	2605 대비 최대 3배 빠름	발표문에 절대 지연·p95·전체 표본 상세 없음
다국어·고유명사 품질	개선 방향을 설명	한국어 WER 개선율 수치는 제시하지 않음
전사 예시 비교	두 음성 입력의 결과 예시	두 사례로 모든 녹음의 품질을 일반화할 수 없음

출처는 위 Microsoft 발표이며 모두 제공사 측정값 또는 제공사 설명입니다. 최대치는 평균치가 아닙니다. 업로드 시간, 파일 길이, 동시 요청, 네트워크 조건까지 합친 업무 완료 시간이 같은 비율로 줄어든다고 계산해서는 안 됩니다. 실제 요금도 응답 대기 시간과 별개로 살펴봐야 합니다.

4. 외부 공개 평가: 영어 WER 4.53%의 의미

9월 15일 열어 본 Open ASR Leaderboard의 최신 표는 9월 11일 갱신 표시였습니다. 기본 영어 단문 평가에서 다음 값이 확인됐습니다. WER은 낮을수록 좋고, 아래 모델들은 속도 지표 RTFx가 NA로 표시되어 있어 속도 순위를 만들 수 없습니다.

리더보드 모델 표기	평균 WER	기본 순위
zoom/scribe_v2_pro	4.38%	1
microsoft/azure-speech-07-2026	4.53%	2
modulate/multilingual	4.56%	3
elevenlabs/scribe_v2	4.84%	6
microsoft/azure-speech-06-2026	4.91%	8

Open ASR의 실제 표와 About 방법론을 직접 확인했습니다. 기본 10개 데이터셋 항목의 매크로 평균이며 AMI·GigaSpeech·LibriSpeech·비공개 대화 자료 등이 포함됩니다. 선택 항목을 바꾸면 평균과 순위도 바뀝니다. 6월 모델과 7월 모델의 차이는 0.38%포인트지만, 6월 표기를 공식 발표의 2605와 같은 것으로 단정하지 않았습니다.

이는 Microsoft 자체 홍보표와 구분되는 외부 공개 평가입니다. 다만 공동체가 기여하는 리더보드이지, 이 블로그가 독립 재실험한 결과는 아닙니다. 공개 코드와 제출 절차는 확인했지만 이 모델의 개별 실행 로그까지 감사하지 않았습니다. 비공개 세트는 운영진이 평가한다고 설명합니다. 평가 저장소와 재현 절차

가장 중요한 제한은 한국어 회의 점수가 아니라는 점입니다. 또 이 평가는 문장부호·대소문자 등을 정규화하므로 깔끔한 숫자 표기나 회의록 문체의 품질까지 같은 점수로 설명할 수 없습니다. 영어 평균이 좋아도 우리 회사 제품명과 겹쳐 말하는 음성은 따로 검사해야 합니다.

5. 한국어 지원과 이용 범위를 먼저 확인하기

LLM Speech의 공식 입력 언어 목록에는 Korean이 포함됩니다. Speech 언어 표에는 ko-KR이 있고, 지역 표의 Korea Central에는 Fast transcription 지원 표시가 있습니다. 하지만 언어 지원과 리소스 지역 지원, 특정 업데이트의 계정별 배포 여부는 다른 조건입니다. 이 글에서 사용자 Azure 계정의 실제 접근권한을 확인한 것은 아닙니다. 언어 표 · 지역 표

도입 전에는 새 Foundry 포털의 Speech to text에서 Fast transcription을 선택해 테스트 파일을 넣고 Transcript와 JSON을 함께 살펴보세요. 공식 Fast 입력 제한은 5시간 미만이면서 500MB 미만입니다. WAV·MP3 등 지원 형식도 확인해야 합니다. 경계값에 맞춰 대용량 파일을 한 번에 넣기보다 대표 구간으로 먼저 검증하는 방법을 권합니다.

한국어 단일 녹음은 예상 언어를 지정한 경우와 자동 감지를 비교하고, 한영 혼합 녹음은 실제 언어 전환을 담은 별도 세트로 검사하세요. 한국어 지원이라는 한 줄만 보고 사투리, 짧은 약어, 잡음 속 발화를 모두 같은 수준으로 처리한다고 기대하지 않는 것이 좋습니다.

6. 전문용어는 긴 프롬프트보다 관리 가능한 용어 목록으로

Phrase list는 모델을 다시 훈련하는 기능이 아니라, 인식 시 특정 단어를 더 중요하게 보도록 돕는 힌트입니다. 공식 문서는 Fast·실시간·LLM Speech 등의 사용을 안내하며, batch transcription에는 적용되지 않는다고 설명합니다. 힌트가 정답을 강제로 보장하는 것도 아닙니다. Phrase list 공식 가이드

처음부터 회사 용어집 전체를 넣기보다는 자주 틀리는 제품명·프로젝트명·약어 20개 정도로 작게 시작해 보세요. 이는 권장 실험 규모이지 API의 최대 허용 개수가 아닙니다. 어떤 음성에서 틀렸는지, 올바른 표기는 무엇인지, 추가 후 다른 단어가 오인식되는지까지 함께 기록해야 합니다.

예를 들어 가상의 프로젝트명 ‘해온랩’이 반복해서 일반 단어로 바뀐다면 용어 후보에 추가하고, 해당 이름이 전혀 없는 녹음에도 시험합니다. 정답 이름이 더 잘 나오는 것만 보고 성공으로 판단하면, 평범한 대화에 브랜드명을 잘못 끼워 넣는 부작용을 놓칠 수 있습니다. 용어 목록에도 버전과 변경 이유를 남기세요.

7. 개발자가 확인할 요청 구조

공식 LLM Speech 예시는 아래 전사 경로와 api-version=2025-10-15를 사용합니다. enhancedMode를 켜고 task를 transcribe로 지정하는 구조입니다. 여기에 phraseList 같은 설정을 조합할 수 있습니다. 다음은 공식 구조를 바탕으로 만든 설명용 예시이며, 실제 요청을 실행하거나 성공을 확인한 코드는 아닙니다. LLM Speech API 안내

POST /speechtotext/transcriptions:transcribe?api-version=2025-10-15
multipart/form-data:
  audio: 사용 권한이 있는 녹음 파일
  definition:
  {
    "enhancedMode": {"enabled": true, "task": "transcribe"},
    "phraseList": {"phrases": ["해온랩", "가상프로젝트"]}
  }

인증은 공식 문서의 Microsoft Entra ID 방식 또는 리소스 키 구성을 따르고, 실제 키는 서버의 비밀 저장소에 둡니다. 블로그 예시·클라이언트 코드·공개 저장소에 넣으면 안 됩니다. 여기서 언어를 생략한 것은 다국어 기본 동작을 설명하기 위한 것이며, 모든 녹음에 생략이 최선이라는 뜻은 아닙니다.

응답 본문의 durationMilliseconds를 요청 지연으로 착각하지 마세요. 오디오 길이와 실제 호출에 걸린 시간은 별도로 기록해야 합니다. 오류가 나면 우선 리소스 주소·API 버전·파일 형식·선택 기능을 대조하고, 같은 파일을 무한 재전송하지 않도록 재시도 횟수와 예산 한도를 둡니다.

8. 가격: 시간당 표시와 초 단위 과금 구분

공식 가격 페이지는 Speech to Text를 초 단위로 과금한다고 설명하고, 현재 LLM Speech가 Fast Transcription과 같은 가격·SKU ID를 공유한다고 안내합니다. 확인한 공개 페이지에서는 금액이 $-로 표시되어 계정·지역별 확정 단가를 확보하지 못했습니다. 이를 무료라고 해석하거나 기억 속 단가로 채우지 않았습니다. Azure Speech 공식 가격

실제 선택한 지역과 계약의 시간당 단가를 C라고 놓으면, 30분 녹음 100개의 단순 전사량은 50시간이고 기본 산술 비용은 50×C입니다. C가 가정상 0.40달러라면 20달러, 1달러라면 50달러입니다. 두 숫자는 현재 Azure 요금이 아니라 예산 민감도를 보여 주는 가정입니다. 할인·부가 기능·저장·네트워크·세금·환율·재시도 비용은 제외했습니다.

비교할 때는 “한 번 호출에 얼마”보다 “검수 완료된 녹음 한 시간에 얼마”를 보세요. 전사 API 비용이 낮아도 이름과 숫자를 고치는 시간이 늘면 전체 비용은 높아질 수 있습니다. 반대로 몇 초 빠른 결과보다 사람의 재청취 시간을 줄이는 것이 더 중요할 때도 있습니다.

9. 회의록·인터뷰·자막에 적용하는 세 가지 흐름

회의록: 전사문에서 곧바로 최종 결정을 자동 확정하지 마세요. 먼저 발언과 시간 정보를 보존하고, 별도 요약 단계에서 결정·담당자·기한을 추출한 뒤 원문 위치로 돌아가 확인하는 흐름을 제안합니다. “아직 확정하지 않았다”라는 발언의 부정이 빠지면 문장이 매끄러워도 잘못된 회의록입니다.

인터뷰: 질문과 답변을 정리하되 실제로 하지 않은 말을 자연스럽게 보충하지 않게 합니다. 녹음 권한이 있는 파일만 쓰고, 사람 이름과 회사명은 필요한 범위의 용어 목록으로 관리하세요. 인용문을 외부에 내보내기 전에는 해당 음성을 재청취하고 편집한 문장과 원발화를 구분하는 절차가 필요합니다.

영상 자막: 전사 정확도 외에 화면에 머무는 시간, 한 줄 길이, 문장 분리, 전문용어 표기의 일관성을 따로 검사합니다. 단어 수준 시간 정보가 있어도 곧바로 보기 좋은 자막이 되는 것은 아닙니다. 조용한 설명 영상과 음악·배경 소음이 섞인 장면을 나누어 샘플을 구성하세요.

세 흐름 모두 원음 → 전사 → 편집·요약 → 검수로 역할을 나누고 원음 위치와 변경 이력을 남기는 것이 핵심입니다.

10. 우리 업무에서 재현하는 30개 녹음 평가

다음은 이 글의 제안이며 이미 수행한 실험이 아닙니다. 조용한 한국어, 한영 혼합, 잡음, 고유명사, 숫자, 겹쳐 말하기를 포함한 녹음 30개를 준비합니다. 각 조건은 같은 원음·지역·기능·동시성에서 3회씩 비교하세요. 먼저 5개로 요청 구성을 확인한 뒤 범위를 늘리면 시행착오를 줄일 수 있습니다.

평가 항목	기록 방법	주의점
WER·CER	사람이 확정한 정답과 단어·문자 오류 비교	띄어쓰기·숫자 정규화 규칙을 고정
이름·금액 정확성	핵심 항목 정답 수와 누락·삽입 수	전체 평균과 별도로 기록
완료 시간	업로드 시작부터 응답 수신까지 p50·p95	소표본 p95를 서비스 보장으로 해석하지 않음
성공률·재시도	전체 시도 중 사용 가능한 결과 비율	실패한 요청도 분모에 포함
업무 비용	API·저장·재처리와 사람 검수 시간	가장 빠른 성공 사례만 선택하지 않음

WER은 치환·삽입·삭제를 정답 단어 수로 나눈 값이고, CER은 문자 단위로 계산합니다. 둘은 다른 지표이므로 한 표의 동일 열에 섞으면 안 됩니다. RTFx는 음성 길이를 처리 시간으로 나눈 속도 지표입니다. 한국어 평가에서는 띄어쓰기와 숫자 표기 정책을 먼저 고정하고 원문 정확성과 읽기 편의성을 나누어 채점하는 방법을 권합니다. WER·CER·RTFx 정의

용어 목록이 없는 설정 A와 짧은 목록을 넣은 설정 B부터 비교하면 변경의 효과를 해석하기 쉽습니다. 합격 기준은 “중요한 이름·금액을 사람이 확인하기 전 외부 전송 금지”처럼 실제 위험과 연결하세요. 모델 이름을 가리고 검수하면 새 버전에 대한 기대가 채점에 영향을 주는 것도 줄일 수 있습니다.

11. 자주 생기는 실패와 도입 체크리스트

화자 구분은 사람의 신원을 인증하는 기능이 아닙니다. speaker 번호가 나온다고 그 번호가 특정 직원이라는 뜻은 아니며, 언어 감지가 켜졌다고 화자 라벨도 자동으로 생기는 것이 아닙니다. Fast 요청에서는 diarization을 명시적으로 설정하고 응답의 speaker를 확인해야 합니다. 기능별 요청 속성이 다르므로 실시간 SDK 예시를 그대로 옮기지 마세요. 언어 감지·화자 구분 설정

대표적인 실패는 읽기 좋은 전사문을 사실상 정답으로 취급하는 것입니다. 숫자 한 자리, 부정어 하나, 발언자 한 명의 연결이 달라져도 중요한 의미가 바뀝니다. 낮은 평균 오류율만 보고 검수 단계를 없애기보다, 업무에서 치명적인 필드에 사람 확인을 집중하는 설계가 낫습니다.

• 녹음의 처리 권한과 외부 전송 가능 범위를 확인했는가?
• 선택 리소스·지역·API 버전·기능을 기록했는가?
• 한국어와 혼합 언어를 각각 평가했는가?
• 용어 힌트의 개선과 잘못된 삽입을 모두 확인했는가?
• 실패·재시도·검수 시간을 예산에 반영했는가?
• 원음 보관 기간·접근 권한·삭제 절차를 정했는가?
• 서비스 업데이트 후 같은 회귀 시험을 다시 돌릴 수 있는가?

12. 자주 묻는 질문과 결론

한국어에서도 무조건 3배 빨라지나요?

그렇게 확인되지 않았습니다. 공식 최대 속도 주장은 특정 제공사 평가이고, 공개 영어 리더보드의 Azure 속도 값도 NA입니다. 한국어 원음의 전체 완료 시간을 별도로 측정해야 합니다.

Phrase list를 쓰면 모델을 다시 학습하나요?

아닙니다. 요청 시 인식에 도움을 주는 힌트입니다. 자주 틀리는 용어부터 작은 목록으로 시작하고, 없는 단어가 잘못 추가되는지도 함께 확인하세요.

2607을 쓰려면 기존 앱을 전부 바꿔야 하나요?

Microsoft는 서비스 측 자동 배포를 안내합니다. 다만 LLM Speech·기본 전사·실시간 경로가 동일한 설정이라는 뜻은 아닙니다. 내 애플리케이션이 사용하는 API와 옵션을 확인하고 회귀 시험을 하세요.

회의 요약까지 한 번에 맡겨도 되나요?

전사 품질과 요약 품질은 별개의 문제입니다. 원음과 전사문의 연결을 유지한 뒤 별도 요약·검수 단계로 나누는 방법을 권합니다. 중요한 결정과 금액은 사람이 승인하도록 남겨 두세요.

이번 업데이트의 가치는 순위 한 줄보다 “내 녹음의 이름과 숫자를 덜 고쳐도 되는가”로 판단하는 편이 좋습니다. 공개 영어 점수는 유용한 출발점이고, 최종 선택은 같은 한국어 녹음에 대한 오류·시간·비용·검수 부담을 함께 기록한 뒤 내려야 합니다.

공식 확인 자료

• Microsoft 2607 발표 — 2026년 9월 10일
• LLM Speech 요청 구조·지원 언어
• Fast transcription 기능·입력 제한
• Phrase list
• Azure Speech 가격과 과금 조건
• 지역별 지원 · 언어별 지원

2026년 9월 14일 확인 · Microsoft의 9월 10일 공식 발표 기준

말로 디자인을 요청하고, 결과를 보며 다시 수정하는 서비스는 어디까지 만들 수 있을까요? Microsoft는 GPT-Live 1과 GPT Image 2.5 두 모델을 Foundry에서 제공한다고 발표했습니다. 이번 소식의 핵심은 새로운 OpenAI 모델의 최초 공개가 아니라, Azure를 사용하는 개발팀이 음성 대화와 이미지 생성·편집을 연결할 선택지가 넓어졌다는 점입니다.

다만 “음성으로 요청하면 모든 작업을 알아서 끝낸다”라고 이해하면 곤란합니다. 음성을 처리하는 모델, 이미지를 만드는 모델, 요청 순서와 권한을 관리하는 서버는 역할이 다릅니다. 이 글에서는 모델 선택, 가격 계산, 실제 성능 자료의 한계, 서비스에 붙이는 순서를 나눠 살펴봅니다. 실제 Azure API 성능 테스트는 수행하지 않았으며, 아래 활용법과 평가 절차는 도입 제안입니다. 사진 3장은 모두 가상 성인 인물의 업무 장면을 표현한 실사풍 AI 생성 이미지이며 실제 직원·제품 화면·시험 현장을 촬영한 것이 아닙니다.

1. 무엇이 새로 제공됐나: 모델 세 가지의 역할

Foundry에서 확인할 모델 식별자는 아래와 같습니다. 세 모델을 한 요청에 넣는다는 뜻은 아닙니다. 사용자가 말하는 동안 음성 대화를 이어 가고, 필요할 때 별도 이미지 작업을 호출하는 구성이 기본적인 설계 방향입니다.

모델	중심 역할	먼저 검토할 업무
gpt-live-1	듣기와 말하기가 겹치는 실시간 음성 대화	음성 상담, 말로 지시하는 작업 도우미
gpt-image-2.5-flare	빠른 일상 이미지 생성과 반복 수정	초안 후보, 여러 배경 시안
gpt-image-2.5-sunburst	정밀한 이미지 편집과 일관성 중심 작업	상품 형태를 보존하는 최종 시안

역할 구분은 제공사의 제품 설명을 바탕으로 한 선택 기준이지, 우리 업무에서 측정된 순위가 아닙니다. Flare로 후보를 좁히고 정밀 편집이 필요한 결과만 Sunburst로 검토하는 방식을 시험할 수 있습니다. 반대로 한 모델만으로 합격 기준을 충족한다면 복잡한 분기 구조를 추가할 이유는 줄어듭니다. Microsoft 공식 제공 발표

2. 정식 제공과 내 계정의 사용 가능 여부는 다르다

Microsoft Learn의 모델 비교표는 GPT Image 2.5 Sunburst와 Flare를 일반 제공(GA)으로 표시합니다. 그러나 특정 한국 리전, 모든 구독, 원하는 처리량에서 즉시 배포할 수 있다는 의미까지 포함하지는 않습니다. 이번 확인에서는 한국 리전별 제공 여부와 사용자 계정의 할당량을 검증하지 않았습니다.

도입 담당자는 Foundry 모델 카탈로그에서 모델 버전, 선택 가능한 리전, 배포 방식, 할당량을 확인하고 화면의 호출 예제를 기준으로 연결해야 합니다. 모델 식별자와 사용자가 붙인 배포 이름도 구분하세요. Azure의 이미지 호출 예제에서 요구하는 배포 이름 자리에 다른 이름을 넣으면 모델이 제공 중이어도 요청이 실패할 수 있습니다. 실제 계정에 없는 엔드포인트를 추측해 만들지 않는 편이 안전합니다.

음성의 이미지 입력은 특히 주의할 항목입니다. Microsoft 발표에는 이미지까지 포함한 멀티모달 경험이 소개되어 있지만, OpenAI 직접 API의 GPT-Live 1 모델 카드는 이미지와 비디오를 미지원으로 표시합니다. 따라서 이 글은 “Live 모델 하나가 사진도 직접 이해한다”고 단정하지 않습니다. 음성·이미지 기능을 서버에서 연결하는 구조와 음성 모델 자체의 입력 지원은 별개이며, Azure 배포의 정확한 지원 범위는 해당 문서와 계정에서 추가 확인해야 합니다. Microsoft 이미지 사용 가이드 · OpenAI GPT-Live 1 사양

3. 가격 비교표: 시간과 토큰을 섞지 않기

아래는 Microsoft의 9월 10일 발표 표를 9월 14일 다시 확인한 미국 달러 기준입니다. 해당 발표는 Foundry 통합 가격 페이지에 세부 정보가 추후 반영될 예정이라고 안내하므로, 표를 계정별 최종 견적이나 확정 청구서로 해석하지 마세요. 음성은 시간, 이미지는 입력·출력 토큰이 기준입니다.

항목	Sunburst	Flare
텍스트 입력 100만 토큰	$5	$5
캐시된 텍스트 입력 100만 토큰	$1.25	$1.25
이미지 입력 100만 토큰	$8	$8
캐시된 이미지 입력 100만 토큰	$2	$2
이미지 출력 100만 토큰	$30	$30

GPT-Live 1의 Foundry 발표 가격은 오디오 시간당 $3입니다. 단순 환산하면 분당 $0.05입니다. OpenAI 직접 API도 분당 $0.05이며 초 단위 청구와 백엔드 모델·도구 별도 과금을 명시합니다. 하지만 그 초 단위 규칙을 Azure에도 그대로 적용할 근거까지 확인한 것은 아닙니다. 실제 Foundry 청구 단위, 세션 시간 산정, 추가 서비스 비용은 별도로 확인하세요.

두 이미지 모델의 공개 토큰 단가가 같다는 점도 중요합니다. Flare가 빠르다는 설명을 “출력 토큰 한 개가 더 싸다”로 바꾸면 틀립니다. 이미지 한 장에 필요한 토큰, 수정 횟수와 사람의 검수 시간이 달라질 수 있으므로 결과물당 비용을 비교해야 합니다. OpenAI 카드 역시 GPT Image 2와 토큰 단가는 같지만 기존 Image 2 계산기로 Image 2.5의 토큰 소비를 추정할 수 없다고 명시합니다. Flare 가격과 제한 · Sunburst 가격과 제한

4. 실제 성능: 확인된 수치와 빈칸을 함께 보기

Microsoft는 Flare가 GPT Image 2보다 지연이 50% 낮으면서 이미지 품질이 높다고 설명합니다. 아래에서는 이를 제공사 측정값으로만 표시합니다. 발표 글에 시험 이름, 해상도·품질 설정, 표본 수와 절대 지연이 함께 제시되지 않아 한국 사용자 환경에 같은 비율을 보장할 수 없습니다.

항목·측정 주체	공개 결과	조건·해석 한계
Flare 지연 / Microsoft 제공사 측정값	GPT Image 2 대비 50% 낮음	시험명·설정·표본·절대 초 단위 값 미공개
Sunburst 연속 편집 / Microsoft 시연	여러 번 수정하는 이미지 예시	정량 벤치마크 아님, 전체 성공률 알 수 없음
Live 대화 / 공식 기능 설명	동시 듣기·말하기와 중간 끼어들기 처리	한국어 지연·도구 성공률 수치 미확인

성능 출처는 위의 Microsoft 원문입니다. 이번 조사 범위에서는 Foundry의 세 모델을 동일 조건에서 비교한 신뢰할 만한 독립 측정 결과를 확인하지 못했습니다. OpenAI 직접 API의 결과나 다른 클라우드의 결과를 Azure 실측으로 바꿔 적지도 않았습니다.

지연 50% 감소는 정확도 50% 향상이나 전체 업무가 두 배 빨라진다는 뜻이 아닙니다. 이미지 생성이 빨라도 파일 전송, 사용자 재요청, 서버 대기, 최종 검수에 시간이 들 수 있습니다. 경쟁 모델까지 포함한 비교는 동일 입력·설정으로 새로 측정해야 하며, 조건이 다른 홍보 수치를 한 표에 줄 세워 우열을 정하는 것은 피해야 합니다.

5. 비용 계산 예시: 사진 한 장 정액 요금이 아니다

계산 방식을 익히기 위해 캐시 없는 이미지 요청에서 텍스트 입력 1,000토큰, 이미지 입력 2,000토큰, 이미지 출력 5,000토큰이 사용됐다고 가정해 보겠습니다. 실제 테스트나 특정 해상도 사진의 토큰 소비량을 뜻하지 않는 임의의 사용량 예시입니다.

가정한 사용량	계산	금액
텍스트 입력 1,000	1,000 ÷ 100만 × $5	$0.005
이미지 입력 2,000	2,000 ÷ 100만 × $8	$0.016
이미지 출력 5,000	5,000 ÷ 100만 × $30	$0.150
이미지 요청 합계	위 세 항목 합산	$0.171

음성 10분을 시간당 $3로 비례 계산하면 $0.50이고, 위 이미지 요청을 한 번 더하면 $0.671입니다. 이 합계는 Azure의 최종 청구 단위를 검증한 금액이 아니며, 별도 추론 모델·도구·저장소·네트워크·재시도·세금은 제외했습니다. “10분 상담에 사진까지 이 가격”이라는 상품 견적으로 쓰면 안 됩니다.

운영 기록에는 성공한 요청만 남기지 마세요. 한 장을 승인받기 위해 네 번 생성했다면 네 번의 실제 과금량을 합쳐야 합니다. 권장 지표는 ‘전체 모델·인프라 비용과 사람 수정 비용 ÷ 최종 승인 이미지 수’입니다. 캐시 할인도 반복 입력이 실제 적중했을 때만 계산하고, 할인된 입력과 일반 입력을 중복 계산하지 않도록 사용량 항목을 나눕니다.

6. 활용방안: 음성으로 상품 배경을 수정하는 도우미

작은 온라인 상점에서 컵 사진의 배경 후보를 만드는 업무를 예로 들겠습니다. 아래는 이미 성공 사례로 검증한 프로젝트가 아니라, 위험이 낮은 시안 제작부터 시작하기 위한 설계 제안입니다. 원본의 사용 권한을 확인하고 고객 사진이나 민감한 주문 자료는 첫 시험에서 제외합니다.

1. 사용자가 “이 컵은 그대로 두고 배경만 밝은 주방으로 바꿔줘”라고 말합니다.
2. 서버가 바꿀 부분과 보존할 부분을 분리한 작업 기록을 만들고 새 요청 번호를 붙입니다.
3. Flare로 시안 후보를 생성하고, 음성 화면에는 작업 진행 상태를 표시합니다.
4. 사용자가 “창문은 빼줘”라고 수정하면 최신 지시를 새 작업에 연결합니다. 기존 호출의 취소 가능 여부는 API별로 확인합니다.
5. 정밀 수정이 필요하면 Sunburst로 검토한 뒤 컵의 손잡이·비율·무늬가 원본과 같은지 사람이 비교합니다.
6. 사용자가 승인한 결과만 내려받거나 게시 단계로 넘깁니다.

여기서 핵심은 모델 이름보다 작업 상태입니다. 오래 걸린 첫 번째 응답이 뒤늦게 도착해 최신 결과를 덮어쓰지 않도록 요청 번호를 비교해야 합니다. 음성 대화가 매끄럽더라도 이미지 생성, 저장, 게시 권한을 자동으로 모두 부여하지 않습니다. 결제나 외부 공개처럼 되돌리기 어려운 단계는 서비스가 정한 승인 규칙을 따로 적용하세요.

7. 개발 시작 순서와 옵션 고르기

처음부터 음성·이미지·검색을 한꺼번에 연결하면 오류 원인을 찾기 어렵습니다. 먼저 이미지 한 장의 생성과 저장을 확인하고, 다음에 편집, 마지막에 음성 요청을 연결하세요. 각 단계에서 요청 식별자, 완료 여부, 오류 유형과 사용량을 기록하면 어느 구간이 병목인지 구분하기 쉽습니다.

Microsoft 비교표에서 두 Image 2.5 모델은 low·medium·high·xhigh·max·auto 품질 옵션을 지원합니다. 다만 통제된 비교에서는 auto로 맡기기보다 같은 명시적 설정을 사용하고, 해상도와 입력 파일도 고정하는 편이 해석에 유리합니다. 같은 설정 이름이 내부 계산량까지 완전히 같다는 뜻은 아니므로 실제 토큰 사용량도 함께 남깁니다.

시범 적용은 권한을 최소화한 개발 리소스에서 진행하고, Foundry가 보여 주는 배포 이름·엔드포인트·지원 API 버전을 사용하세요. API 키를 웹페이지 코드나 블로그 예제에 넣지 않고 서버 쪽 비밀 저장소 또는 적절한 관리형 인증을 사용합니다. 최대 대기시간, 반복 횟수, 사용자당 사용량 한도를 구현하고 제한에 걸렸을 때의 안내도 준비합니다. 확인하지 않은 Azure 음성 호출 코드를 OpenAI 예제의 주소만 바꿔 배포하지 마세요.

8. 직접 재현하는 성능 평가표

이 블로그는 유료 Azure API를 실행해 측정하지 않았습니다. 아래는 독자가 자신의 계정에서 수행할 수 있는 평가 설계입니다. 대표 이미지 작업 20개를 준비하고 모델별 3회씩 반복하면 한 모델당 60개 결과가 생깁니다. 예산이 작으면 5개 과제로 먼저 절차를 점검한 뒤 확장하세요.

평가 항목	기록 방법	주의할 점
편집 정확도	필수 조건 통과 수 ÷ 전체 결과 수	형태 보존과 배경 변경을 별도 채점
완료 지연	요청 시작부터 파일 사용 가능까지	전송·대기 포함 여부 고정
토큰·비용	실제 사용량과 과금 기록 합산	실패·재시도도 포함
도구 호출 성공률	올바른 도구·인수·완료를 모두 만족한 비율	도구 선택과 실제 실행을 구분
수정 부담	승인까지 사람 수정 횟수와 시간	모델명을 가리고 평가

음성은 조용한 방, 배경 소음, 문장 중간 수정처럼 조건을 나눕니다. 같은 대본과 장치·네트워크 조건에서 첫 반응 시간, 발화 중단 반응, 최종 지시 반영 여부를 기록하세요. “말을 멈췄다”와 “이전 이미지 작업까지 취소됐다”는 서로 다른 성공 조건입니다. 익명화한 시험 자료를 사용하고 녹음 보관 여부와 삭제 시점도 정해 둡니다.

결과에는 모델 버전, 리전, 날짜, 품질·해상도, 입력 파일, 반복 횟수를 함께 적습니다. 평균과 중앙값을 확인하고 느린 사례도 따로 남기되, 작은 표본에서 계산한 p95를 서비스 보장값처럼 설명하지 마세요. 데이터가 부족한 칸은 미측정으로 남기는 것이 임의의 숫자를 채우는 것보다 유용합니다.

9. 자주 생기는 실패와 복구 방법

상품 자체가 달라지는 경우: 배경만 바꾸라는 말이 있어도 손잡이나 문양이 변할 수 있습니다. 원본과 나란히 비교해 보존 조건을 하나씩 검사하고, 실패하면 공개하지 않고 다시 검토합니다. 모델 변경보다 지시 범위와 원본 품질을 먼저 점검할 필요도 있습니다.

응답이 늦어 중복 실행하는 경우: 네트워크 오류만 보고 같은 작업을 무한 재전송하면 비용과 중복 결과가 늘어날 수 있습니다. 이미 완료된 작업인지 확인하고, 제한된 재시도와 대기 간격을 적용합니다. 업무 단계의 중복 방지와 모델 호출 자체의 중복 방지는 구분해서 설계해야 합니다.

배포를 찾지 못하거나 429가 발생하는 경우: 공식 가이드는 배포 이름 확인과 호출 제한 대응을 안내합니다. 이름 오류에 재시도만 반복하지 말고 연결 설정을 확인하세요. 429에 대해서는 요청 빈도와 동시성을 낮추고 사용량 한도에 맞춰 대기시킵니다. Microsoft 오류 안내

음성 확인을 작업 승인으로 오해하는 경우: 짧은 맞장구가 이미지 게시나 주문 변경 승인인지 분명하지 않을 수 있습니다. 결과 설명과 외부 실행 확인을 분리하고, 인식이 불명확하면 실행하지 않는 흐름을 마련하세요. 빠른 응답보다 올바른 작업을 한 번 수행하는 것이 중요합니다.

10. 배포 전 체크리스트

• 계정의 모델 버전·리전·할당량과 실제 호출 경로를 확인했는가?
• 음성 입력 범위와 이미지 생성 역할을 분리했는가?
• Azure 청구 단위와 별도 모델·저장·도구 비용을 확인했는가?
• 원본 사용 권한, 개인정보 제외, AI 생성 표시를 준비했는가?
• 오래된 결과가 최신 결과를 덮어쓰지 않도록 처리했는가?
• 비용·대기시간·재시도 상한과 사람이 검토할 조건이 있는가?
• 동일 조건 반복 평가에서 얻은 합격 기준과 중단 기준을 기록했는가?

11. 자주 묻는 질문

Flare가 빠르니 Sunburst는 필요 없나요?

그렇게 단정할 수 없습니다. 빠른 초안과 정밀 편집의 합격 조건은 다를 수 있습니다. 다만 이름이나 등급만 보고 비싼 운영 구조를 만들지 말고, 실제 승인율과 총비용으로 필요성을 판단하세요.

Azure와 OpenAI 직접 API 가격이 같으면 완전히 같은 서비스인가요?

공개 단가가 같아도 리전, 인증, 할당량, 청구 세부 조건과 운영 환경이 같다는 뜻은 아닙니다. 사용하는 제공 경로의 문서와 계정을 기준으로 판단해야 합니다.

50% 낮은 지연이 한국어 음성에도 적용되나요?

아닙니다. 해당 수치는 Microsoft가 설명한 Flare 이미지 모델과 GPT Image 2의 비교입니다. GPT-Live 1 한국어 응답 지연이나 전체 앱 속도에 옮겨 적용할 수 없습니다.

개인 블로그에 바로 연결해도 되나요?

먼저 비공개 시안 제작으로 시험할 수 있습니다. 공개 전 사실·저작권·인물 표현을 검수하고, 생성 이미지가 실제 현장 사진으로 오인되지 않도록 표시하세요. 자동 생성과 자동 공개는 별도의 운영 결정입니다.

12. 결론: 대화 경험과 운영 품질을 함께 설계하자

이번 Foundry 제공 소식은 Azure 환경에서 음성으로 요청하고 이미지를 다듬는 작업을 시험할 계기가 됩니다. 선택의 기준은 “최신 모델인가”보다 “어떤 실패를 줄이고 어느 비용까지 감당할 것인가”여야 합니다. 음성에는 대화의 흐름, 이미지에는 결과물의 보존 조건, 서버에는 요청 상태와 권한 통제를 맡기세요. 실제 계정의 제공 범위를 확인하고 작은 반복 평가를 끝낸 뒤 운영 범위를 넓히는 것이 이 글의 제안입니다.

공식 확인 자료

• Microsoft Foundry 제공 발표·가격·성능 주장
• Microsoft Learn 이미지 API 사용·모델 비교
• OpenAI GPT-Live 1 모델 카드
• OpenAI GPT Image 2.5 Flare 모델 카드
• OpenAI GPT Image 2.5 Sunburst 모델 카드
• OpenAI API 출시 이력

2026년 9월 12일 확인 · 오늘의 AI 생활실험실

AI 모델을 연결한 서비스는 잘 돌아가는데, 어느 날 지원 종료 안내가 도착하면 무엇부터 해야 할까요? 이름이 비슷한 최신 모델로 바꾸기만 하면 끝날 것 같지만 실제로는 응답 형식, 호출 경로, 비용과 품질을 함께 확인해야 합니다. 이번 글은 Amazon Bedrock의 새 수명주기 정책을 읽는 법과 개발팀이 이전을 준비하는 방법을 정리합니다.

공식 문서의 적용 기준은 Bedrock에서 2026년 9월 7일 이후 출시된 모델입니다. 모든 기존 모델을 같은 날 종료한다는 공지가 아닙니다. 문서의 최초 게시 시각은 확인하지 못했으므로 오늘 발표된 정책이라고 표현하지 않습니다. 아래 운영 절차는 적용 제안이며, 실제 AWS 계정에서 마이그레이션이나 성능 시험을 수행한 후기가 아닙니다. 이미지 3장은 가상의 업무 장면을 표현한 AI 생성 실사 이미지입니다.

1. 새 정책에서 반드시 구분할 두 날짜

모델 카드에는 종료할 수 있는 가장 이른 경계를 뜻하는 EOL no sooner than과 종료 전 예고 구간인 Legacy period가 표시됩니다. 전자를 확정 종료일로 읽으면 안 됩니다. 모델이 Legacy에 들어갈 때 실제 EOL 날짜가 추가됩니다. 예고기간은 모델별 6개월 또는 45일이며 대부분은 6개월입니다. Bedrock 이용자는 원 개발사의 직접 API 일정이 아니라 Bedrock의 해당 모델 일정을 확인해야 합니다. AWS 새 수명주기 정책

표시 항목	읽는 방법	할 일
Active	현재 운영 중인 상태	대체 후보와 검증 자료 준비
Legacy	퇴역 예정 구간	실제 EOL 전에 이전 완료
EOL	지원 종료	기존 호출 지속을 기대하지 않기
no sooner than	그 날짜보다 일찍 종료하지 않음	확정 종료일 칸과 분리 기록

Legacy에서는 신규 고객의 도입과 새 Provisioned Throughput 생성이 제한되고, 기존 고객도 15일간 사용하지 않으면 접근을 잃을 수 있습니다. EOL 이후에는 별도 계속 이용 약정 같은 예외가 없다면 요청이 실패하며, 자동 이전도 되지 않습니다. 이 숫자를 서비스 보장이나 모든 계정의 접근권한 보장으로 해석하지 마세요.

2. 9월 7일 이전 모델과 이후 모델 비교

기준은 내가 가입한 날짜나 코드를 배포한 날짜가 아니라 해당 모델의 Bedrock 출시일입니다. 이전 모델용 공식 문서는 최소 12개월의 출시 후 존속과 최소 6개월의 Legacy 구간을 안내합니다. 또한 2026년 2월 1일 이후 EOL인 모델은 Legacy 시작 후 최소 3개월이 지나 공개 연장 접근 구간에 들어갈 수 있으며 가격이 높아질 수 있습니다. 실제 적용일과 요금 공지를 따로 확인해야 합니다. 이전 모델 정책과 종료 일정표

구분	9월 7일 이전 출시	9월 7일 이후 출시
확인 문서	Legacy 정책 페이지	새 정책 + 모델 카드
주요 기간	출시 후 최소 12개월	카드의 no sooner than
예고 구간	최소 6개월	모델별 6개월·45일

서로 다른 정책의 숫자를 합쳐 임의의 종료일을 계산하지 않는 것이 중요합니다. 팀의 관리표에는 확인일과 원문 링크를 남기고, 확정 날짜가 없으면 미정으로 유지하세요. 날짜가 비어 있다는 사실도 운영 정보입니다. 담당자가 임의로 채워 넣은 달력은 실제 공지보다 위험할 수 있습니다.

3. 실제 모델 카드 예시: Astra는 45일 종료 대상인가

9월 12일 확인한 AWS GPT-6 Astra 카드에는 Bedrock 출시일 2026년 9월 8일, no sooner than 2027년 9월 8일, Legacy 최소 6개월, EOL 날짜 N/A, 상태 Active가 표시됩니다. 따라서 이 카드로부터 “Astra가 45일 뒤 종료된다”거나 “2027년 9월 8일 종료가 확정됐다”는 결론을 낼 수 없습니다.

카드 예시는 날짜 해석을 설명하기 위한 것이며 특정 모델을 무조건 추천하는 뜻은 아닙니다. 이름이 같아도 모델 ID, 지원 API와 엔드포인트가 다를 수 있습니다. 예를 들어 카드의 기본 식별자는 openai.gpt-6-astra이고, bedrock-runtime의 교차 리전 호출에는 us.openai.gpt-6-astra 또는 global.openai.gpt-6-astra가 안내됩니다. 모든 호출 방식에 같은 문자열을 넣으면 된다고 생각하지 마세요.

한국에서 개발한다는 사실과 한국 리전 안에서만 처리된다는 사실도 다릅니다. In-Region은 지정 리전 안에서, Geo는 정해진 지리 범위에서, Global은 지원되는 세계 여러 리전에서 처리하는 방식입니다. 서울 출발점이 표시돼도 Global이면 국내 처리만을 의미하지 않습니다. 개인정보가 있는 업무는 가격보다 먼저 허용된 처리 범위를 확인하세요. AWS 리전별 모델 지원표

4. 가장 먼저 만드는 모델 사용 대장

운영팀에 권하는 출발점은 복잡한 대시보드가 아니라 한 장짜리 사용 대장입니다. 서비스 이름, 소유자, 호출 경로, 모델 식별자, 리전, 수명주기 상태, 확정 EOL, 대체 후보, 마지막 검증일을 적습니다. 같은 모델을 챗봇과 야간 배치가 함께 쓰면 두 업무를 별도 행으로 관리하세요. 하나를 고쳤다고 다른 호출도 바뀌는 것은 아닙니다.

GetFoundationModel은 모델 세부 정보를 반환하며 modelDetails.modelLifecycle에서 상태와 수명주기 관련 필드를 확인할 수 있습니다. 콘솔의 표시와 공식 문서를 함께 대조하고, 응답에 없는 날짜를 추정하지 마세요. GetFoundationModel 응답 명세

아래는 AWS CLI가 설치되고 조회 권한과 인증이 준비된 환경에서 활용할 읽기 전용 명령의 형태입니다. 대문자 자리는 실제 모델 ID와 리전으로 바꿉니다. 이 글에서는 실행하지 않았고, 리전이나 모델에 따라 결과 또는 지원 범위가 달라질 수 있습니다.

aws bedrock get-foundation-model --model-identifier MODEL_ID --region REGION --query "modelDetails.{id:modelId,lifecycle:modelLifecycle}"

AWS CLI 공식 참조를 함께 보세요. 403을 받았다면 모델이 종료됐다고 단정하지 말고 권한을 확인해야 합니다. 조회 실패를 빈 결과로 바꿔 정상 처리하지 않고, 오류와 확인 담당자를 대장에 남기는 편이 좋습니다. 계정 비밀키나 원문 고객 데이터를 이 대장에 넣을 필요는 없습니다.

5. 실제 성능: 이전 성공은 호출 성공과 다릅니다

이번 변경은 모델 능력을 높였다는 발표가 아니라 운영 정책입니다. 따라서 정책 자체의 정확도·속도 벤치마크나 이전 모델 대비 상승률은 적용 대상이 아닙니다. 이 글에는 제공사 측정값 또는 독립 평가 결과를 가장한 임의 점수를 넣지 않았습니다. 동일 조건의 직접 API 시험도 수행하지 않았으므로 아래는 독자가 재현할 평가 설계입니다.

AWS는 프로그램 평가, 사람 평가, 별도 LLM을 심사자로 쓰는 평가 등을 제공합니다. 평가 방식의 존재가 특정 모델의 성능 보장은 아닙니다. 채점 모델의 취향과 업무상 정답도 다를 수 있어 중요한 사례에는 사람 확인이 필요합니다. Bedrock 평가 방식

검증 항목	기록할 값	주의할 점
업무 성공	필수 조건 통과 수 / 전체 실행	실패·거절·타임아웃도 분모에 포함
정확성	정답·원문과 일치 여부	유창함과 사실성을 분리
응답 시간	첫 응답·전체 완료의 p50/p95	같은 경로·부하에서 측정
토큰 사용	입력·출력·캐시 토큰	재시도 비용을 빠뜨리지 않기
도구 호출	스키마·실행·결과 연결 통과 수	문법 통과만 성공으로 보지 않기
수정 부담	사람 검토 시간·수정 개수	자동 채점과 별도로 기록

Converse 명세에는 metrics.latencyMs와 토큰 사용량 필드가 있습니다. 이를 수집하되 서버 지연 값과 사용자 화면에 최종 결과가 뜨기까지의 시간은 구분하세요. 지원하지 않는 기능이나 다른 API에서는 각 명세를 확인해야 합니다. 문서의 예시 응답에 든 지연 숫자를 실측값처럼 인용해서는 안 됩니다. Converse 응답 명세

AWS의 심사 모델 기반 지표 중 Correctness는 정답 여부, Completeness는 질문을 빠짐없이 답했는지, Faithfulness는 주어진 맥락에 충실한지를 봅니다. 사내 규정 답변에는 근거 충실성을, JSON 추출에는 필드 정확성을 함께 보도록 평가표를 설계할 수 있습니다. 평가 지표 정의

6. 재현 가능한 비교를 위한 5단계

1. 업무 표본 고정: 익명화한 대표 사례 30개를 고릅니다. 쉬운 요약뿐 아니라 누락 정보, 긴 입력, 잘못된 형식도 섞습니다.
2. 정답 기준 고정: 필수 출력 필드와 허용하지 않는 행동을 미리 적습니다. 모델 결과를 본 뒤 합격 기준을 유리하게 바꾸지 않습니다.
3. 조건 기록: 날짜, 모델 ID, API, 리전, 프롬프트, 도구, 추론 설정과 출력 제한을 저장합니다. 서로 지원하지 않는 옵션은 억지로 동일하게 맞추지 않고 차이를 공개합니다.
4. 반복 실행: 기존 모델과 후보를 각 사례에서 3회 비교하는 설계를 제안합니다. 30개 × 3회는 모델당 90회이며 실험 결과가 아닌 권장 표본입니다.
5. 검토와 판단: 모델 이름을 가리고 결과를 채점한 뒤 실패 유형, 시간, 비용을 합쳐 봅니다. 작은 표본의 p95를 운영 보장치라고 부르지 않습니다.

예산이 부족하면 5개 사례로 연결 상태를 먼저 확인하고 범위를 늘리세요. 다만 연결 확인에 성공했다는 이유로 본 실험을 생략해서는 안 됩니다. 짧은 질문에서는 비슷했던 두 모델이 긴 대화나 여러 도구를 잇는 작업에서 다르게 움직일 수 있습니다. 실험 중 실제 결제나 고객 메시지를 보내지 않도록 테스트 도구와 가상 데이터를 사용하세요.

7. 가격 비교는 단가보다 성공한 작업당 비용

Bedrock 가격은 모델, 처리 경로와 이용 방식에 따라 달라집니다. 이전 모델의 토큰 단가와 후보의 토큰 단가만 옆에 놓으면 실제 비용 차이를 놓칠 수 있습니다. 평가 모델 사용료, 병행 시험, 저장·로그 비용과 사람이 고치는 시간도 별도 예산 항목으로 둡니다. 최신 단위와 조건은 Bedrock 공식 가격표에서 확인하세요.

성공한 작업당 비용 = 실패와 재시도를 포함한 총 운영·검토 비용 ÷ 승인된 결과물 수라는 기준을 제안합니다. 예를 들어 두 후보가 모두 100회 실행됐고 총비용이 각각 12달러와 15달러, 승인 결과가 60개와 90개라면 각각 0.20달러와 약 0.167달러입니다. 이는 설명용 가상 계산이며 실제 모델 요금이나 성능 측정이 아닙니다.

더 싼 요청이 더 싼 완료 작업을 뜻하지 않는다는 점만 보세요. 반대로 품질 차이가 거의 없고 수정도 적다면 낮은 비용의 후보가 합리적일 수 있습니다. 캐시 적중을 늘릴 계획이라면 최초 쓰기와 보존 조건을 빼지 말고, 반복 요청과 처음 보는 요청을 나눠 시험하는 편이 해석하기 쉽습니다.

8. 전환 당일을 위한 체크리스트와 실패 사례

아래 순서는 AWS가 보장하는 공식 일정이 아니라 팀 운영을 위한 제안입니다. 담당자가 직접 확인한 항목만 완료로 표시하고, 미확인 항목을 빈 체크로 남기세요.

• 현재 사용 중인 모델 ID와 실제 호출 위치를 모두 찾았는가?
• 후보가 필요한 API·입력 유형·리전과 업무 조건을 지원하는가?
• 동일 평가표로 기존 모델과 후보를 비교했는가?
• 오류 증가·품질 저하·비용 초과 시 중단 기준을 정했는가?
• 테스트 환경에서 작은 비중의 트래픽부터 검증했는가?
• 되돌릴 대상도 그 시점에 이용 가능한 모델인지 확인했는가?
• 야간 배치와 낮은 빈도의 작업까지 전환했는가?

가상 실패 사례 1: 웹 챗봇만 바꾸고 월말 보고서 배치를 놓쳤습니다. 평일 화면은 정상이라도 드문 작업은 나중에 실패할 수 있습니다. 업무별 소유자를 기록하고 실행 빈도가 낮은 작업도 시험해야 합니다.

가상 실패 사례 2: 응답에 JSON이 있으니 성공이라고 판단했지만 필요한 금액 필드가 빠졌습니다. 스키마 검사와 업무 규칙 검사를 나누고, 필수 필드 누락을 실패로 기록하세요.

가상 실패 사례 3: 장애가 나면 예전 모델로 돌아가면 된다고 생각했는데 이미 이용할 수 없었습니다. 롤백은 설정 파일을 되돌리는 행위가 아니라 실제 작동하는 대체 경로를 준비하는 일입니다. 전환 전후에 같은 표본을 실행해 확인해야 합니다.

9. 자주 묻는 질문

내가 9월 7일 이후 가입했으면 새 정책인가요?

가입 시점이 기준은 아닙니다. 해당 모델의 Bedrock 출시일을 먼저 확인하세요. 여러 모델을 쓴다면 정책 적용도 모델별로 나누어 관리하는 것이 맞습니다.

최신 모델이면 이전 테스트를 생략해도 되나요?

권하지 않습니다. 서비스가 요구하는 출력 형식과 한국어 표현, 근거 정확성, 실행 시간은 별도의 문제입니다. 모델 전체에 대한 평판보다 내 업무의 합격 기준이 먼저입니다.

정확한 EOL 날짜가 없으면 지금 할 일이 없나요?

사용 대장과 평가 표본을 준비할 수 있습니다. 날짜가 공지된 뒤에야 호출 위치와 담당자를 찾기 시작하면 검증에 쓸 시간이 줄어듭니다.

이 글이 우리 서비스의 이전 완료를 보장하나요?

아닙니다. 공식 문서 해설과 검증 절차 제안입니다. 계정 권한, 계약 조건, 데이터 처리 범위와 실제 호출 결과는 각 운영 환경에서 확인해야 합니다.

10. 마무리: 모델도 운영 의존성으로 관리하세요

지원 종료 공지를 읽는 핵심은 겁을 내며 즉시 모든 모델을 바꾸는 데 있지 않습니다. 우리 서비스가 무엇에 의존하는지 알고, 변경할 때 같은 기준으로 확인할 수 있어야 합니다. 오늘은 사용 중인 모델 세 개만 골라 식별자, 소유자, 마지막 검증일과 대체 후보를 적어보세요. 그 작은 대장이 다음 출시 소식이나 종료 공지를 실제 행동으로 바꾸는 출발점이 됩니다.

공식 확인 자료

• 신규 출시 모델 수명주기 정책
• 기존 모델 정책 및 종료 일정
• Astra 모델 카드
• 모델 정보 조회 API
• 리전과 호출 경로
• 평가 방식 안내
• 평가 지표 정의
• Converse 지연·사용량 명세
• 현재 가격과 청구 조건

2026년 9월 11일 23시(KST) 정정 · 오늘의 AI 생활실험실

중요 정정: DeepSeek 공식 변경 로그와 가격표가 업데이트되어 V4 Pro API는 9월 14일 이후에도 기존 과금 방식으로 계속 제공됩니다. 이 글의 앞선 자동 전환·마감 시각 안내는 더 이상 적용되지 않아 수정했습니다. 구형 Flash·Vision Exp의 V4.1 Flash 연결과 Pro의 계속 제공은 서로 다른 정책입니다. 업데이트된 공식 변경 로그 · 현재 가격표

DeepSeek V4.1 Flash는 9월 10일 공개되어 API에서 사용할 수 있습니다. 다만 모든 기존 모델이 새 Flash로 바뀌는 것은 아닙니다. 9월 11일 23시 재확인한 공식 문서에 따르면 V4 Pro는 9월 14일 이후에도 유지됩니다. 새 모델의 성능·가격과 사용 중인 모델의 제공 정책을 따로 확인해야 합니다.

가격이 낮아지고 이미지를 이해한다고 해서 기존 코드를 그대로 운영해도 된다는 뜻은 아닙니다. 이 글은 출시·가격·성능을 구분하고, 무엇을 먼저 시험할지 제안합니다. 직접 API를 실행한 후기가 아니며 제공사 자료와 독립 기관의 측정 결과를 명시합니다. 인물·로봇 사진은 AI 생성 가상 장면으로 실제 DeepSeek 직원이나 제품 실험 사진이 아닙니다.

1. 정책 변경: V4 Pro 계속 제공, 구형 Flash는 별도

새 호출 이름은 deepseek-flash입니다. 이전 V4 Flash와 Vision Exp는 종료됐고 기존 이름은 V4.1 Flash로 연결됩니다. 반면 V4 Pro API는 2026년 9월 14일 이후에도 계속 제공되며 과금 방식도 유지됩니다. 변경 시 추가 공지를 하겠다는 안내이므로 종료 시각이나 자동 전환을 확정해 쓰면 안 됩니다. 이는 V4.1 Pro 출시일이 발표됐다는 뜻도 아닙니다. 현재 공식 변경 로그

호환 별칭은 연결 오류를 줄이는 장치이지 결과물의 동일성을 보장하는 장치가 아닙니다. 모델 이름을 바꾸지 않았는데 문장 길이, JSON 구조, 함수 선택이나 응답 시간이 달라질 수 있으므로 이전 결과를 비교 기준으로 남겨 두세요. 운영 계정의 실제 접근권한과 서비스 상태는 별도로 확인해야 합니다.

2. 무엇이 바뀌었고 누구에게 필요한가

공식 모델 카드는 텍스트·이미지를 읽고 텍스트를 생성하는 구조를 설명합니다. 이미지 생성 모델이라는 뜻은 아닙니다. 사진 속 상황을 설명하거나 화면과 오류 메시지를 함께 분석하는 후보로 볼 수 있지만, 실제 업무 정확도는 입력 자료로 검증해야 합니다. 그림을 그리거나 음성을 합성하는 기능과 혼동하지 마세요.

실무에서는 모델 크기보다 입력과 결과물의 관계가 중요합니다. 상품 사진에서 보이는 요소를 추출하는 일, 긴 지침과 소스 코드를 함께 확인하는 일, 표의 숫자와 설명을 대조하는 일은 서로 다른 평가가 필요합니다. 한 가지 시험에서 좋은 점수를 받았다고 세 가지를 모두 잘한다고 가정하지 않는 편이 좋습니다.

활용 후보	AI에게 맡길 일	검수 기준
이미지 자료 정리	보이는 요소와 설명 초안	없는 물건·문구를 만들지 않는지
개발 지원	재현 조건 확인과 최소 수정	테스트 통과·무관한 변경 여부
보고서 작성	근거별 주장과 수치 정리	원문 위치·날짜·합계 일치

위 표는 이 블로그의 적용 제안이며 고객사의 실제 성과 사례가 아닙니다. 처음에는 공개 자료나 익명화한 샘플로 읽기 전용 작업을 맡기세요. 계정 변경이나 외부 게시처럼 되돌리기 어려운 동작은 결과 검증과 권한 통제를 갖춘 뒤 별도 단계로 다루는 것이 좋습니다.

3. 실제 성능: 제공사 측정값 비교

아래는 DeepSeek 모델 카드의 비교표에서 네 가지 평가를 골랐습니다. 단위는 %이며 높을수록 좋습니다. DeepSWE는 Resolved, 나머지는 Pass@1입니다. 제공사 측정값이지 이 블로그의 직접 실험이 아닙니다.

평가	V4.1 Flash	V4 Pro	V4 Flash	GPT-5.6 Sol
GPQA Diamond	90.9	92.4	89.9	94.1
Terminal-Bench 4.0	31.2	12.4	7.0	39.9
DeepSWE v1.1	74.2	62.7	54.4	73.0
AutomationBench	54.8	43.2	37.7	45.8

V4.1은 최대 추론 강도 100, temperature 1.0·top_p 0.95 조건입니다. Terminal은 DeepSeek Harness Minimal·1M 문맥, DeepSWE는 mini-SWE, AutomationBench는 공식 실행 환경을 사용합니다. DeepSWE 실행 환경 비교는 과제당 8회 샘플입니다. 경쟁 모델의 모든 조건까지 같다는 뜻은 아닙니다. 공식 모델 카드와 평가 조건

제 해석은 명확합니다. GPQA에서는 Pro와 Sol보다 낮지만, 이 표의 자동화와 DeepSWE에서는 개선이 나타납니다. 따라서 “모든 영역에서 상위 모델을 이겼다”가 아니라 우리 작업이 어떤 평가와 닮았는지 살펴봐야 합니다. Terminal-Bench 2.1과 4.0은 다른 시험이므로 숫자를 이어 붙여 향상률을 계산하면 안 됩니다.

4. 독립 평가: 낮은 단가와 작업당 비용은 다르다

Artificial Analysis의 독립 비교도 참고했습니다. 9월 11일 조회한 두 모델은 모두 Max Effort이며 이전 모델은 V4 Flash 0731입니다. 종합 지표와 실제 작업 비용을 분리해서 읽는 것이 핵심입니다.

독립 평가 항목	V4.1 Flash	V4 Flash 0731
Intelligence Index v4.3	40	35
작업당 비용	$0.27	$0.22
작업당 출력 토큰	89K	62K

해당 지표는 여러 평가를 가중 결합한 값이며 작업 비용은 그 평가의 평균이지 질문 한 번의 정액요금이 아닙니다. 단가 인하가 작업당 비용 절감을 보장하지 않는 사례로 읽을 수 있습니다. 독립 비교 원문 · 평가 방법

속도 페이지는 10,000 입력 토큰 조건과 최근 72시간 중앙값 표시 정책을 안내합니다. 조회 당시 요약표와 FAQ의 출력 속도 값이 서로 달라 이 글에서는 단일 수치로 확정하지 않았습니다. 이런 실시간 페이지는 날짜·설정·표 위치를 함께 저장해야 재현 가능한 비교가 됩니다. 독립 API 속도·지연 측정

한국어 정확도, 우리 서비스의 p95 지연, 특정 도구 호출 성공률은 위 종합 점수만으로 알 수 없습니다. 측정 자료가 없는 항목은 미확인으로 남기고 아래 시험표에 직접 기록하세요. 답변 첫 글자가 빨리 나오는 것과 검증된 결과물이 빨리 완성되는 것도 다른 문제입니다.

5. 가격표와 한국 시간대별 비용

공식 요금은 미국 달러·100만 토큰 기준입니다. 문맥 1M, 최대 출력 384K를 안내하며 계정 접근과 실제 사용량은 별도 확인이 필요합니다. 일반 입력은 캐시 미적중을 뜻합니다.

V4.1 Flash 요금	피크	비피크
입력·캐시 미적중	$0.30	$0.15
입력·캐시 적중	$0.006	$0.003
출력	$1.20	$0.60

한국 기준 피크는 월~금 10:00~13:00, 15:00~19:00이고 나머지는 비피크입니다. 현재 V4 Pro 피크 단가는 일반 입력 $1.32·출력 $3.96이며 기존 과금 방식이 유지됩니다. 새 Flash를 직접 선택해 사용하는 경우에는 위 Flash 가격표를 적용합니다. 공식 가격·시간대·전환 조건

이 블로그의 산술 예시로 입력 10만 토큰·출력 1만 토큰을 모두 캐시 없이 사용하면 피크는 $0.042, 비피크는 $0.021입니다. 같은 사용량 1,000회는 각각 $42와 $21입니다. 세금·환전·서버·도구·재시도·사람 수정 비용은 제외했고, 출력에는 과금 대상 추론 토큰까지 포함했다고 가정했습니다. 실제 청구액이나 직접 측정한 성능값이 아닙니다.

마감이 없는 자료 분류를 비피크에 예약하는 것은 검토할 수 있지만 고객 응답을 무작정 늦추면 서비스 품질이 손해일 수 있습니다. 요금 구간의 경계를 넘는 긴 작업은 청구 기록으로 확인하세요. 문서에 없는 구간별 정산 방식을 임의로 단정하지 않는 것이 안전합니다.

6. API 이전에서 놓치기 쉬운 호환성

Responses 형식을 지원한다고 모든 기능이 같은 것은 아닙니다. DeepSeek 문서는 previous_response_id·conversation·background를 지원하지 않고, 내장 web_search·file_search·computer_use 등을 무시한다고 설명합니다. 미지원 매개변수가 오류 없이 무시될 수도 있으므로 HTTP 성공만으로 기능 작동을 판정하지 마세요. Responses 호환성 표

검색이 필요한 보고서라면 실제 검색 도구를 연결하고 호출 기록을 확인하세요. 모델이 “찾아봤다”고 쓰는 문장은 검색 실행 증거가 아닙니다. 대화 상태도 앱에서 이전 입력과 결과를 연결하는 방식으로 검증해야 합니다. 모델 공급자와 API 형식, 실행 도구를 각각 구분하면 이전 문제를 찾기 쉬워집니다.

추론은 기본 활성화·high이며 API에서는 low·high·max를 안내합니다. 모델 카드의 숫자 강도 100을 API에 그대로 넣는다고 가정하지 마세요. thinking 모드에서 temperature 설정은 효과가 없고, 도구가 포함된 Chat Completions 대화는 이전 reasoning_content 전달 규칙도 확인해야 합니다. 추론 설정과 도구 대화

7. 모델을 바꾸기 전에 해볼 단계별 점검

아래 절차는 공식 의무 사항이나 9월 14일 이전 필수 작업이 아니라, 모델을 직접 변경할 때 운영 위험을 줄이기 위한 제안입니다. V4 Pro를 유지할지 Flash를 시험할지 실제 업무 결과로 판단하세요.

1. 호출 목록 정리: 설정 파일과 배포 환경에서 사용하는 모델명, API 경로, 도구를 기록합니다. 비밀키 원문은 기록하지 않습니다.
2. 대표 입력 고정: 자주 쓰는 한국어 질문, 숫자 추출, 함수 호출, 긴 대화, 이미지 읽기 과제를 준비합니다.
3. 정답 기준 작성: 출력 형식, 필수 근거, 금지 동작, 허용 지연과 예산을 모델 실행 전에 정합니다.
4. 새 이름으로 소규모 시험: 운영 데이터 복사본과 읽기 전용 도구를 사용해 기존 결과와 대조합니다.
5. 실패도 기록: 오류·재시도·수동 수정까지 비용에 포함하고 문제가 있는 과제를 따로 분류합니다.
6. 복구 경로 준비: 구형 별칭으로 돌아가는 것이 구형 모델 복원이 아님을 고려해 대체 공급자나 수동 처리 경로를 준비합니다.

시험 결과는 모델 이름만 남기지 말고 확인 시각, 추론 강도, 입력 길이, 도구 버전과 최종 승인 여부를 묶어 저장하세요. 자동 배포가 있는 서비스라면 작은 비율의 작업부터 전환해 오류 원인을 관찰하고, 중단 기준을 먼저 정하는 편이 좋습니다.

8. 실제 활용 프롬프트와 실패 사례

이미지 자료 정리에는 “첨부한 상품 사진에서 확인되는 색상·형태만 표로 추출하고, 브랜드·가격·소재처럼 사진만으로 모르는 값은 미확인으로 남겨줘”라고 요청해 보세요. 표를 잘 만든 것보다 보이지 않는 정보를 만들어내지 않았는지가 합격 기준입니다.

개발 작업에는 “제공한 오류 재현 절차와 관련 파일을 확인하고 최소 수정안을 제안해줘. 의존성 추가와 운영 배포는 하지 말고, 실행한 테스트와 실행하지 못한 항목을 구분해줘”라고 범위를 정하세요. 실제 파일과 테스트 도구가 연결되지 않았다면 실행 결과를 주장하지 못하도록 해야 합니다.

보고서에는 “첨부 자료의 주장마다 원문 위치와 날짜를 붙이고, 합계는 계산 도구 결과로 검증해줘. 관찰 사실과 원인 가설을 나눠줘”라는 요청이 출발점입니다. 자료를 많이 넣는 것보다 필요한 근거를 식별하고 틀린 결론을 걸러낼 기준을 주는 것이 중요합니다.

실패 상황	확인할 증거	대응 제안
성공 응답인데 검색이 없음	도구 실행 기록	실제 검색 경로 연결
짧은 질문인데 비용 증가	추론·출력·재시도 토큰	강도와 출력 범위 재시험
이미지 숫자가 틀림	원본 확대와 필드별 정답	중요 숫자 별도 검수
전환 뒤 JSON 처리 실패	원시 응답·스키마 검증	파서와 예외 처리 점검

9. 우리 업무에서 재현할 평가표

예산이 허용하면 대표 과제 20개를 같은 조건에서 모델별 3회 반복하는 방식을 제안합니다. 적은 예산이라면 5개로 예비 시험한 뒤 늘리세요. 이는 제안하는 시험 설계일 뿐 이 블로그가 이미 실행한 실험이 아닙니다. 비교 중에는 입력 자료와 도구 권한을 바꾸지 않아야 원인을 분리할 수 있습니다.

항목	기록할 값
정확도	사전 합격 조건을 모두 만족한 비율
도구 성공	올바른 함수·인수·최종 상태의 일치율
시간	첫 응답과 검증 완료까지 각각 측정
토큰	일반 입력·캐시 입력·추론·답변
총비용	실패·재시도·사람 수정 포함

평균뿐 아니라 느린 사례도 살펴보되 작은 표본의 p95를 서비스 보장값으로 홍보하지 마세요. 개인정보가 들어간 입력을 공유 평가표에 그대로 남기지 말고 필요한 통계와 익명화한 실패 유형만 기록하세요. 운영자가 보지 않은 데이터가 로그나 이미지에 섞이지 않았는지도 점검해야 합니다.

10. 자주 묻는 질문과 도입 체크리스트

V4 Pro를 계속 지정하면 이전 모델이 유지되나요?

현재 공식 문서는 V4 Pro API를 9월 14일 이후에도 기존 과금 방식으로 계속 제공한다고 명시합니다. 향후 변경은 추가 공지 대상입니다. 이미 종료된 구형 Flash·Vision Exp 별칭과 혼동하지 마세요.

독립 평가가 있으니 직접 시험은 생략해도 되나요?

일반 성향을 보는 참고 자료일 뿐 우리 업무의 한국어 정확도나 처리시간 보증이 아닙니다. 자주 발생하는 실패부터 재현하는 것이 좋습니다.

비피크에 실행하면 전체 운영비도 절반인가요?

해당 토큰 단가는 절반이지만 서버·도구·사람 수정 비용까지 절반이 되는 것은 아닙니다. 성공한 결과물 한 건에 들어간 전체 비용으로 비교하세요.

이미지를 이해하면 자동으로 그림도 만들어주나요?

입력 이해와 이미지 생성은 다른 기능입니다. 이 글에서 다룬 모델의 출력을 이미지 생성 도구의 결과로 혼동하지 마세요.

• 실제 호출 모델과 최신 제공 정책을 확인했는가?
• 숫자·한국어·JSON·도구·이미지 과제를 시험했는가?
• 성능 수치의 측정 주체와 조건을 기록했는가?
• 토큰 단가가 아닌 작업당 총비용을 계산했는가?
• 실패 시 수동 처리와 대체 경로가 준비됐는가?

이번 출시의 실용적인 결론은 새 모델을 무조건 채택하라는 것이 아닙니다. 모델별로 다른 최신 제공 정책을 확인하고, 저렴한 단가가 우리 업무의 품질과 최종 비용에서도 이점으로 이어지는지 확인하자는 것입니다. 가격과 접근 조건은 실제 사용 전에 공식 페이지에서 다시 확인하세요.

공식 확인 자료 및 독립 평가

• DeepSeek 공식 출시 공지
• 공식 API 변경 로그
• 모델 사양·가격·제공 정책
• 제공사 모델 카드·평가 조건
• Responses 호환 범위
• 추론·도구 대화 설정
• Artificial Analysis 독립 비교
• 독립 API 성능 측정