> ## Documentation Index
> Fetch the complete documentation index at: https://docs.apiyi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# 공식 릴레이 API와 리버스 엔지니어링 API의 차이점은 무엇입니까?

> APIYI는 기본적으로 공식 릴레이 방식입니다. 안정성, 프로토콜 호환성, 캐싱, 동시 실행 수 및 장기적인 지속 가능성 측면에서 공식 릴레이 API와 리버스 엔지니어링 API를 비교하고, Claude_Reverse, Codex_Reverse, Gemini_Reverse 및 공식 릴레이 그룹 중에서 선택하는 방법을 알아보십시오.

## 짧은 답변

**공식 릴레이**는 공급업체의 공식 API 또는 공식 클라우드 마켓플레이스를 통해 전달되는 리소스를 의미합니다. \*\*리버스 엔지니어링(리버스)\*\*은 비공식 인터페이스를 통해 얻은 액세스를 의미합니다. 두 경로가 동일한 모델을 호출하는 경우 단일 턴 응답은 매우 유사할 수 있습니다. 실제 차이는 **안정성, 프로토콜 호환성, 기능 완성도, 캐시 효율성, 동시 실행 수 및 장기적인 지속 가능성**에 있습니다.

* **APIYI는 기본적으로 공식 릴레이입니다.** 리버스 그룹은 개인 학습, 비용에 민감한 워크로드 및 중요하지 않은 작업을 위한 보완 수단입니다.
* 프로덕션 워크로드, 코딩 에이전트 및 기업 고객은 공식 릴레이를 우선적으로 사용하는 것이 좋습니다.
* 개인 학습, 간단한 채팅/번역/요약 및 비용에 민감한 워크로드에는 리버스 그룹을 사용할 수 있습니다.
* APIYI에는 현재 텍스트/코딩 리버스 그룹이 정확히 세 개 있습니다: `Claude_Reverse`, `Codex_Reverse` 및 `Gemini_Reverse`입니다. 다른 공급업체의 텍스트 모델은 기본적으로 공식 릴레이 `Default` / `SVIP` 그룹을 사용합니다.
* 이미지 `-all` / `-vip` 모델은 별도의 리버스 라인이며, 대부분 `Default`에서 제공됩니다. URL 출력을 필요로 하는 일부 모델은 `image2_OSS`을 사용합니다. 정확한 매핑은 콘솔에서 확인하십시오. 이 모델들은 해당 세 그룹에 포함되지 않습니다.
* APIYI는 그룹 이름과 문서에 출처를 표시합니다. 리버스 그룹은 공식 직접 연결로 표시되지 않습니다.

> [!NOTE]
>
> 이는 일반적인 패턴일 뿐, 모든 공식 릴레이 채널이 모든 리버스 채널보다 우수하다는 의미는 아닙니다. 공식 릴레이도 공급업체의 용량 제한에 부딪힐 수 있으며, 일부 워크로드에서는 고품질 리버스 리소스 풀이 속도, 동시 실행 수 또는 안정성 측면에서 일시적으로 더 나을 수 있습니다. 구체적인 채널, 시간대 및 자체 테스트 결과를 기준으로 판단하십시오.

이 문서는 특정 모델 하나가 아니라 APIYI 그룹 전반에 관한 내용입니다. 모델 수준의 차이는 모델 문서를 확인하고 직접 테스트하십시오.

## APIYI의 공식 릴레이 및 역방향 그룹

**그룹**과 **모델**을 구분해야 합니다. 그룹은 token의 채널이며, 모델은 요청의 `model` 필드입니다. APIYI는 그룹을 사용하여 소스와 사용 사례를 구성하지만, 일반 그룹에는 공식 릴레이 이미지 모델과 역방향 이미지 모델이 모두 포함될 수 있습니다.

**APIYI는 기본적으로 공식 릴레이입니다.** 대부분 공식 릴레이인 그룹에는 `Default`, `SVIP`, `ClaudeCode`, `Claude_Enterprise`, `CodexResponses`, `image2Enterprise`, `NB-Enterprise`와 동영상 그룹 `SeeDance2` 및 `Wan&HappyHorse`이 포함됩니다. 전체 목록, 할인 및 모델 지원 범위는 [그룹](https://docs.apiyi.com/ko/groups.md)을 참조하십시오.

### 역방향 그룹(보충용)

| 역방향 그룹 | 지원 범위 | 요율 배수 | 적합한 용도 |
| - | - | - | - |
| `Claude_Reverse` | `claude-fable-5-2` 및 `claude-haiku-5-5`와 같은 최신 출시 모델을 제외한 Claude 모델 24개 | 0.5 | 개인 학습, 비프로덕션 |
| `Codex_Reverse` | `gpt-5.6-*`, `gpt-6-*` 및 `gpt-6.1-*`을 포함한 모델 9개 | 0.5 | 비용에 민감한 Codex 사용, 비프로덕션 |
| `Gemini_Reverse` | Gemini 2.5부터 3.8까지의 모델 11개(Gemini 4 제외) | 0.5 | Gemini CLI, 학습, 비프로덕션 |

역방향 그룹은 보충용이며, 공식 릴레이와 동일한 SLA, 동시 실행 수 또는 기능 완성도를 보장하지 않습니다.

> [!NOTE]
>
> `Default` / `SVIP`은 대부분 공식 릴레이이지만, `gpt-image-2-all`, `gpt-image-2.6-all` 및 `-vip` 시리즈와 같은 역방향 이미지 모델도 포함합니다. 그룹 이름만 확인하지 말고 그룹과 모델을 모두 확인하십시오.

## 핵심 차이점: 모델 지능만이 아닙니다

### 안정성 및 성능

| 차원 | 공식 릴레이 | 리버스 | 비즈니스 영향 |
| - | - | - | - |
| 모델 동작 | 네이티브이며 일관됨 | 대부분 유사하지만 간헐적인 차이 존재 | 단일 턴 답변은 일반적으로 차이가 크지 않음 |
| 모델 진위성 | 검증 가능한 출처 | 공급업체의 투명성에 따라 다름 | 고정 테스트 세트로 검증해야 함 |
| 첫 token | 더 낮고 예측 가능함 | 프록시 또는 대기열이 추가될 수 있음 | 실시간 및 스트리밍 UX에 영향을 줌 |
| 전체 속도 | 공식 부하의 영향을 받음 | 리소스 풀에 따라 달라짐 | 배치 작업을 위해 재시도 및 타임아웃 여유를 확보해야 함 |
| 동시 실행 수 및 피크 | 명시적인 RPM / TPM 또는 쿼터 | 계정 풀 및 스케줄링에 따라 다름 | 피크 시 429 또는 대기열에 걸릴 가능성이 높음 |
| 캐싱 | 완전한 공식 캐시 메커니즘 | 캐시 제어 매개변수가 전달되지 않을 수 있음 | 긴 대화 및 고정 접두사의 비용이 증가함 |

### 프로토콜 및 기능

| 차원 | 공식 릴레이 | 리버스 | 비즈니스 영향 |
| - | - | - | - |
| 매개변수 호환성 | 모든 공식 매개변수 및 구조 지원 | 일부 매개변수가 호환되지 않거나 무시될 수 있음 | 복잡한 호출에 대한 회귀 테스트를 실행해야 함 |
| 스트리밍 | 네이티브이며 표준화됨 | 일반적으로 지원되지만 버퍼링 또는 형식 차이가 있을 수 있음 | 첫 token UX 및 클라이언트 타임아웃을 조정해야 함 |
| Tool Calling / MCP | 네이티브이며 안정적임 | 구조 또는 순서 문제가 발생할 가능성이 더 높음 | 에이전트 작업 성공률이 낮아짐 |
| 구조화된 JSON | 공식 기능에 따라 스키마가 보장됨 | 스키마가 엄격하게 적용되지 않을 수 있음 | 다운스트림 파싱에 허용 범위가 필요함 |
| 멀티모달 | 모든 공식 지원 제공 | 이미지, 오디오 또는 동영상이 누락될 수 있음 | 소량 트래픽으로 멀티모달 워크로드를 검증해야 함 |
| 컨텍스트 길이 | 제약 조건이 명확한 공식 한도 | 리버스 체인에 의해 제한될 수 있음 | 긴 문서 및 대화를 대상으로 스트레스 테스트를 수행해야 함 |
| Thinking / reasoning 제어 | 공식 reasoning 매개변수 및 응답 형식 | 완전히 재현되지 않을 수 있음 | reasoning 예산 및 체인 처리가 영향을 받음 |
| 사용량 및 오류 코드 | 공식 측정 및 명확한 오류 유형 | 추정되거나 잘못 매핑될 수 있음 | 과금 조정 및 재시도에 허용 범위가 필요함 |

### 버전, 규정 준수 및 지속 가능성

| 차원 | 공식 릴레이 | 리버스 | 비즈니스 영향 |
| - | - | - | - |
| 모델 버전 업데이트 | 공식 수명 주기를 따름 | 지연되거나 예고 없이 변경될 수 있음 | 고정 버전에 대한 롤백 계획을 유지해야 함 |
| SLA 및 문제 해결 | 공식 지원 채널 | 리버스 공급업체의 지원에 따라 다름 | 기업은 보장 사항에 중점을 두어야 함 |
| 리소스 및 위험 관리 | 규정을 준수하여 사용하면 상대적으로 통제됨 | 업스트림 계정 풀, 위험 관리 및 인터페이스 변경의 영향을 받음 | 핵심 워크로드를 위한 백업 채널을 유지해야 함 |
| 상업적 규정 준수 | 공급업체의 상업용 API 약관이 적용됨 | 공급업체의 공식 API 약관의 적용을 받지 않음 | 기업용 프로덕션에 사용하기 전에 규정 준수를 평가해야 함 |
| 가격 및 장기 비용 | 투명하며 조달 할인이 가능함 | 더 저렴할 수 있지만 숨은 운영 비용이 더 높음 | 단가만이 아니라 총비용을 계산해야 함 |
| 장기 지속 가능성 | 상대적으로 더 강함 | 비공식 연결의 가용성에 따라 다름 | 장기간 운영되는 프로젝트에는 공식 릴레이를 우선해야 함 |

> [!NOTE]
>
> 리버스 리소스는 공급업체의 공식 상업용 API 약관의 적용을 받지 않습니다. 이 문서는 법률 자문이 아닌 기술 설명입니다. 자체 기업 조달 및 프로덕션 사용에 대한 규정 준수를 평가해야 합니다.

## 단일 턴 품질이 비슷해도 에이전트가 여전히 공식 릴레이를 우선해야 하는 이유

코딩 에이전트의 성공률은 단일 턴 응답으로 결정되지 않습니다. 형식이 잘못된 도구 호출 인수 하나, 누락된 JSON 필드 하나, 중단된 stream 하나만으로도 전체 작업이 실패하고 처음부터 다시 시작될 수 있습니다. 단일 턴 품질이 동일해 보여도 여러 턴에 걸친 성공률은 달라질 수 있습니다.

에이전트 워크로드에서는 다음 세 가지 문제가 증폭됩니다.

* **도구 호출 구조**: 리버스 체인은 매개변수를 다시 작성하거나 무시할 수 있으므로, 잘못된 함수 이름, 인수 순서 또는 중첩 구조가 발생할 가능성이 커집니다.
* **캐시 접두사**: 시스템 prompt, 도구 정의 및 기록은 여러 턴에 걸쳐 긴 접두사를 구성합니다. 리버스 체인이 `cache_control`를 그대로 전달하지 못하면 캐시 적중이 감소하고 비용과 지연 시간이 모두 증가합니다.
* **오류 코드 및 재시도**: 부정확한 오류 매핑으로 인해 재시도 로직이 복구 가능한 오류를 치명적 오류로 처리하거나, 반대로 처리할 수 있습니다.

> [!TIP]
>
> Claude Code, Codex, Gemini CLI 및 OpenClaw 워크플로에서는 기본적으로 공식 릴레이를 우선 사용합니다. 리버스 그룹은 비용 보완용이나 중요하지 않은 작업에만 사용합니다.

## 공식 릴레이를 선호해야 하는 경우와 리버스를 사용해도 되는 경우

| 시나리오 | 권장 사항 | 이유 |
| - | - | - |
| 코딩 에이전트(Claude Code / Codex / Gemini CLI) | 공식 릴레이 선호 | 도구 호출과 다중 턴 작업에는 프로토콜 일관성이 필요합니다 |
| 긴 컨텍스트와 복잡한 다중 턴 채팅 | 공식 릴레이 선호 | 캐시 접두사와 컨텍스트 전달이 더 완전합니다 |
| 단순한 채팅, 번역, 요약 | 리버스 사용 가능 | 단일 턴 품질은 비슷하고 비용은 더 낮습니다 |
| 도구 호출 / MCP 워크플로 | 공식 릴레이 선호 | 매개변수 구조, 순서, 오류 코드의 안정성이 더 높습니다 |
| 동시 실행 수가 높은 배치 생성 | 공식 릴레이 선호; 리버스는 스트레스 테스트 | 동시 실행 수는 공식 쿼터 또는 리버스 리소스 풀에 따라 달라집니다 |
| 이미지 생성 | 공식 릴레이 / 기업 그룹; 성숙한 리버스 옵션 테스트 | 출력 형식, 성공률, 4K 안정성은 크게 다릅니다 |
| 기업용 프로덕션 | 공식 릴레이 | 규정 준수, SLA, 문제 해결 지원이 더 완전합니다 |
| 가격에 매우 민감한 경우 | 먼저 총비용 비교 | 재시도, 실패한 작업, 운영 비용을 포함해야 합니다 |

## 캐싱은 적중률 그 이상입니다

공식 Claude 캐싱에는 명시적인 접두사 일치, `cache_control` 마커, 5분/1시간 TTL이 적용됩니다. `cache_creation_input_tokens` 및 `cache_read_input_tokens` 필드는 쓰기와 읽기를 직접 보여 줍니다. OpenAI는 자동 접두사 캐싱을 사용하고, Gemini는 중간 수준의 적중률을 보이는 암시적 캐싱을 사용합니다.

역방향 체인이 요청을 전달하기만 하고 캐시 제어 매개변수를 완전히 전달하지 못하면 적중률이 떨어집니다. 긴 대화, 고정된 시스템 프롬프트, 대규모 도구 정의는 비용 차이를 더욱 크게 만듭니다. 채널을 선택할 때는 캐싱이 존재하는지만 묻지 말고, 동일한 접두사에 대한 실제 캐시 읽기 비율을 측정해야 합니다.

캐시 작동 방식과 과금에 대한 자세한 내용은 [APIYI가 캐시 과금을 지원합니까?](https://docs.apiyi.com/ko/faq/cache-billing.md)를, Claude 매개변수에 대한 자세한 내용은 [Claude 프롬프트 캐싱](https://docs.apiyi.com/ko/api-capabilities/claude-prompt-caching.md)을 참조하십시오.

## 채널 평가 방법: 다섯 가지 지표

공식 릴레이와 리버스 중에서 선택해야 하는 경우, 고정된 테스트 세트를 실행하고 다음 다섯 가지 수치를 기록합니다.

| 지표 | 계산 방법 | 주의할 점 |
| - | - | - |
| 요청 성공률 | 성공한 요청 ÷ (전체 요청 − 클라이언트 측 4xx) | 자체 매개변수 오류는 제외합니다 |
| 유효 캐시 적중률 | 캐시에서 읽은 token ÷ 입력 token | 동일한 모델, 동일한 접두사, 동일한 그룹이어야 합니다 |
| P95 지연 시간 | 첫 token 소요 시간과 전체 소요 시간을 별도로 측정합니다 | 평균에 의존하지 마십시오 |
| 에이전트 작업 완료율 | 고정된 작업 중 최종적으로 전달된 작업의 비율 | 단일 턴 품질보다 실제 사용량에 더 가깝습니다 |
| 성공한 작업당 비용 | (요청 비용 + 재시도 비용 + 실패한 작업 비용) ÷ 성공한 작업 수 | 실패도 포함합니다 |

공급업체마다 캐시 필드가 다릅니다. Claude는 `cache_read_input_tokens`를 노출하는 반면, OpenAI는 `prompt_tokens_details.cached_tokens`와 같은 필드를 사용합니다. 실제 응답에서 해당 필드를 확인하십시오.

> [!TIP]
>
> 단일 턴 벤치마크는 모델이 답변할 수 있는지만 보여 줍니다. 이 다섯 가지 지표는 해당 채널이 비즈니스를 운영할 수 있는지를 보여 줍니다.

## APIYI 채널 원칙

* **기본값은 공식 릴레이**: APIYI는 기본적으로 공급업체의 공식 API와 공식 클라우드 마켓플레이스를 사용합니다. 리버스는 비용을 보완하기 위한 수단이며, 기본 채널이 아닙니다.
* **출처를 표시합니다**: `Claude_Reverse`, `Codex_Reverse`, `Gemini_Reverse`는 그룹 이름과 문서에서 리버스로 표시됩니다. 이를 공식 직접 연결로 설명하지 않습니다.
* **프로덕션에서는 공식 릴레이를 우선합니다**: `Default`, `SVIP`, `Claude_Enterprise`, `CodexResponses`, `image2Enterprise`, `NB-Enterprise`은 프로덕션 트래픽을 처리합니다. 이미지 모델의 경우 특정 모델의 출처에 따라 선택합니다.
* **복잡한 에이전트에는 공식 릴레이를 사용합니다**: 도구 호출, 멀티턴 작업 및 긴 컨텍스트에는 프로토콜 일관성이 필요합니다.
* **학습 및 비용 최적화에는 리버스를 사용합니다**: 리버스 그룹은 공식 릴레이와 동일한 SLA, 동시 실행 수 또는 기능 완성도를 보장하지 않습니다.
* **엔터프라이즈 고객**: 보장이 중요한 경우 `Claude_Enterprise`, `image2Enterprise` 또는 `NB-Enterprise`을 사용합니다. SLA 및 조달 옵션은 지원팀에 문의하십시오.
* **채널은 변경될 수 있습니다**: 업스트림 리소스, 모델 버전 및 그룹 요율 배수는 변경될 수 있습니다. 콘솔과 [실시간 업데이트](https://docs.apiyi.com/en/live.md)를 기준으로 판단하십시오.

단일 턴 답변만 살펴보면 공식 릴레이와 우수한 리버스 채널은 매우 비슷해 보일 수 있습니다. 공식 릴레이의 진정한 가치는 **동작의 일관성, 예측 가능한 안정성, 완전한 기능 및 장기적인 지속 가능성**에 있습니다. 프로덕션 비즈니스에서는 단순한 단가가 아니라 이 네 가지 요소가 지원 비용과 고객 유지율을 결정합니다.

## 관련 문서

> [card] [그룹](https://docs.apiyi.com/ko/groups.md)
>
> 공급업체 및 모델별 모든 그룹, 요율 배수, 할인 및 선택 지침

> [card] [Tokens 및 그룹](https://docs.apiyi.com/ko/faq/token-and-groups.md)
>
> Tokens를 생성하고 기본 및 대체 그룹 구성

> [card] [그룹이란 무엇입니까?](https://docs.apiyi.com/ko/faq/groups-explained.md)
>
> 사용자 그룹과 token 그룹 비교

> [card] [캐시 과금](https://docs.apiyi.com/ko/faq/cache-billing.md)
>
> Claude, OpenAI 및 Gemini의 캐시 동작 및 과금

> [card] [GPT 이미지: 공식 방식과 역방향 방식 비교](https://docs.apiyi.com/ko/api-capabilities/gpt-image-2/vs-gpt-image-2-all.md)
>
> 이미지 모델의 매개변수, 가격 및 품질 차이

> [card] [모델 가격](https://docs.apiyi.com/ko/models/index.md)
>
> 모든 모델의 가격 및 사양


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.