1. 문제 정의 (Problem)

대형 언어 모델 (LLM) 공급업체가 급증하면서 각 업체는 고유한 API 형식 (OpenAI Chat Completions, Anthropic Messages, Google GenAI, OpenAI Responses 등) 을 제공하고 있습니다. 이로 인해 다음과 같은 심각한 문제가 발생하고 있습니다.

• 생태계의 파편화: 애플리케이션이 특정 벤더에 강하게 결합 (tight coupling) 되어 이식성이 떨어집니다.
• O(N²) 복잡도: N 개의 공급업체를 서로 연결하려면 양방향 어댑터가 $N(N-1)/2$개 필요하여 통합 비용이 기하급수적으로 증가합니다.
• 현재 솔루션의 한계:
  • SDK 래퍼 (예: LangChain): 애플리케이션 레벨의 추상화를 제공하지만, 원시 API 페이로드의 변환을 지원하지 않습니다.
  • 단방향 프록시 (예: LiteLLM): 하나의 공급업체 (보통 OpenAI) 형식을 '링구아 프랑카'로 사용하여 다른 공급업체를 매핑합니다. 이는 특정 공급업체의 고유 기능 (캐싱 제어, 추론 흔적 등) 을 잃어버리게 만들고, 양방향 변환이나 완전한 중립성을 보장하지 못합니다.

2. 방법론 (Methodology)

저자는 주요 LLM API 들은 구문 (syntax) 은 다르지만, **공통된 의미론적 핵심 (semantic core)**을 공유한다는 관찰에 기반하여 허브 - 스포크 (Hub-and-Spoke) 아키텍처를 도입했습니다.

가. 중개 표현 (Intermediate Representation, IR)

모든 변환은 공급업체 특유의 형식이 아닌, 공급업체 중립적인 IR 을 통해 이루어집니다.

• 9 가지 콘텐츠 모델: 텍스트, 이미지, 오디오, 파일, 도구 호출, 도구 결과, 추론 (Reasoning), 거절 (Refusal), 인용 (Citation) 등 메시지 콘텐츠의 원자적 단위를 정의합니다.
• 10 가지 스트림 이벤트 스키마: 스트리밍 세션의 시작/종료, 콘텐츠 블록, 텍스트/추론 델타, 도구 호출, 사용량 통계 등을 표준화합니다.
• 디자인 목표: 의미론적 완전성, 공급업체 중립성, 양방향 충실도 (Lossless Round-trip), 점진적 확장성.

나. Ops-Composition 아키텍처

각 공급업체 변환기는 하나의 거대한 클래스가 아닌, 4 개의 직교적인 (orthogonal) 모듈로 구성됩니다.

1. ContentOps: 콘텐츠 부분 (텍스트, 이미지, 도구 등) 변환.
2. MessageOps: 메시지 시퀀스, 역할 매핑, 시스템 프롬프트 처리.
3. ToolOps: 도구 정의 및 선택 설정 변환.
4. ConfigOps: 생성 파라미터, 추론 설정, 캐싱 설정 변환.
   이 구조는 관심사의 분리를 통해 코드 재사용성을 높이고, 새로운 공급업체 추가 시 기존 IR 이나 다른 변환기를 수정할 필요 없이 해당 공급업체용 Ops 모듈만 구현하면 됩니다.

다. 스트리밍 및 양방향 변환

• 스트리밍: 각 공급업체가 사용하는 서로 다른 SSE(Server-Sent Events) 형식을 IR 의 10 가지 표준 이벤트로 정규화한 후, 다시 대상 공급업체 형식으로 변환합니다. StreamContext 를 통해 상태 관리 (도구 호출 ID 매핑, 버퍼링 등) 를 수행하여 이벤트 순서를 보장합니다.
• 메타데이터 모드:
  • Strip 모드: 공급업체 특유의 메타데이터를 제거하여 깨끗한 IR 을 생성 (크로스-프로바이더 전달용).
  • Preserve 모드: provider_metadata 필드에 원본 메타데이터를 보존하여 손실 없는 양방향 변환 (A→IR→A) 을 가능하게 함.

3. 주요 기여 (Key Contributions)

1. API 분기의 경험적 분석: 4 대 주요 LLM 공급업체가 구문적 차이는 크지만 공통된 의미론적 핵심을 공유함을 규명하고, 이를 9 가지 콘텐츠 타입과 10 가지 스트림 이벤트로 캡처했습니다.
2. 타입화된 IR 및 변환 아키텍처: 의미론적 불일치가 아닌 구문적 변형에 초점을 맞춘 중립적 IR 과 모듈형 Ops-Composition 구조를 제안했습니다.
3. 스트리밍 지원 양방향 변환: 요청과 응답 페이로드 모두에 대해 공급업체 ↔ IR ↔ 공급업체 변환을 지원하며, 상태 관리가 포함된 청크 단위 스트리밍을 구현했습니다.
4. 실증적 평가 및 배포: 1,364 개의 테스트 (Open Responses 준수 테스트 포함) 를 통과했으며, Argonne 국립연구소의 프로덕션 환경 (Argo-Proxy) 에 배포되어 검증되었습니다.

4. 평가 결과 (Results)

• 정확도 (Fidelity):
  • Round-trip: Preserve 모드에서 모든 필드가 손실 없이 복원됨. Strip 모드에서도 의미론적으로 중요한 필드는 모두 보존됨.
  • Cross-provider: OpenAI, Anthropic, Google, Responses 간 6 가지 조합의 변환 테스트에서 메시지, 도구, 이미지 등 모든 의미론적 콘텐츠가 정확히 유지됨.
  • 스트리밍: 255 개의 스트리밍 테스트 케이스에서 100% 이벤트 순서 정확도를 달성함.
• 성능 (Performance):
  • 변환 오버헤드는 100 마이크로초 (µs) 미만 (중앙값 기준).
  • 단순 텍스트 요청: 2124 µs, 복잡한 멀티턴/도구 호출: 7177 µs.
  • 네트워크 왕복 시간 (50500ms) 및 모델 추론 지연 (100ms10s+) 에 비해 무시할 수준 (<0.01%).
  • LiteLLM 비교: 단방향 변환 (LiteLLM) 과 비교했을 때, LLM-Rosetta 의 2-hop 변환 (OpenAI→IR→Anthropic) 은 단순 텍스트의 경우 오히려 더 빠르거나 (24µs vs 28µs), 복잡한 경우 약 1.6~2.2 배의 오버헤드가 발생하지만, 양방향 변환과 공급업체 중립성이라는 추가 기능을 제공합니다.
• 테스트 커버리지: 4 개 공급업체에 대한 987 개의 변환기 단위 테스트 및 377 개의 IR/기타 테스트 총 1,364 개 통과.

5. 의의 및 결론 (Significance)

• 표준화 패러다임의 전환: 특정 공급업체 형식을 기준으로 삼는 기존 접근법에서 벗어나, 공급업체 중립적인 IR을 통해 진정한 상호운용성을 실현했습니다.
• 실용성: 서브-밀리초 수준의 낮은 오버헤드로 프로덕션 환경 (API 게이트웨이, 오케스트레이션 프레임워크) 에 직접 통합이 가능합니다.
• 유지보수성: 모듈형 아키텍처 덕분에 새로운 API 표준이 등장하거나 기존 API 가 변경될 때, 해당 공급업체의 Ops 모듈만 업데이트하면 되어 확장성이 뛰어납니다.
• 현장 적용: Argonne 국립연구소의 Argo-Proxy 를 통해 실제 연구 환경에서 여러 LLM 공급업체를 단일 엔드포인트로 통합하여 사용하는 것을 성공적으로 입증했습니다.

이 논문은 LLM 생태계의 파편화 문제를 해결하기 위해 컴파일러 설계의 '허브 - 스포크' 패턴을 API 변환에 적용한 성공적인 사례로, 향후 다중 공급업체 아키텍처의 표준적인 접근 방식으로 자리 잡을 것으로 기대됩니다.