🔄제2장: AI 상호운용성의 현재 과제

弘益人間 (홍익인간) - 널리 인간을 이롭게 하라

"문제를 이해하는 것이 해결의 첫 걸음입니다."

오늘날 AI 산업은 낭비된 개발 노력, 벤더 락인, 혁신 기회 손실로 매년 수십억 달러의 비용이 드는 상호운용성의 체계적인 과제에 직면해 있습니다. 이러한 과제는 연구자, 기업 및 최종 사용자 모두에게 영향을 미치며, AI 민주화의 장벽을 만들고 기술 발전의 속도를 늦추고 있습니다.

2.1 산업 현안

현대 AI 에코시스템은 프레임워크, 플랫폼, 배포 환경 및 데이터 형식의 여러 차원에서 파편화되어 있습니다. 이러한 파편화는 대규모로 AI 시스템을 구축, 배포 및 유지 관리하려는 조직에 상당한 문제점을 만듭니다.

2.1.1 파편화의 비용

산업 연구는 AI 상호운용성 과제의 엄청난 비용을 밝힙니다:

2.1.2 개발자 경험 과제

AI/ML 엔지니어는 생산성과 혁신을 감소시키는 일상적인 마찰 지점에 직면합니다:

• 가파른 학습 곡선: 각 프레임워크는 API, 관례 및 모범 사례에 상당한 차이가 있어 2-3개월의 학습 시간이 필요합니다
• 도구 체인 확산: 평균 AI 프로젝트는 각각 고유한 인터페이스와 데이터 형식을 가진 12-15개의 서로 다른 도구를 사용합니다
• 버전 호환성 지옥: 프레임워크 버전 간의 중단 변경으로 지속적인 코드 유지 관리가 필요합니다
• 배포 복잡성: 개발에서 작동하는 것이 환경 차이로 인해 프로덕션에서 실패하는 경우가 많습니다
• 문서 파편화: 프레임워크, 클라우드 제공업체 및 배포 플랫폼에 분산된 지식

2.2 프레임워크 파편화 (PyTorch vs TensorFlow vs JAX)

"프레임워크 전쟁"은 각각 고유한 강점, 약점 및 충성스러운 커뮤니티를 가진 호환되지 않는 진영으로 분열된 에코시스템을 만들었습니다. 경쟁이 혁신을 촉진하는 반면, 상호운용성 부족은 상당한 마찰을 만듭니다.

2.2.1 비교 프레임워크 분석

2.2.2 코드 비호환성 예제

간단한 연산도 프레임워크 간에 완전히 다른 접근 방식이 필요합니다:

# PyTorch
import torch
x = torch.randn(100, 784)
w = torch.randn(784, 256)
y = torch.relu(x @ w)

# TensorFlow
import tensorflow as tf
x = tf.random.normal([100, 784])
w = tf.random.normal([784, 256])
y = tf.nn.relu(tf.matmul(x, w))

# JAX
import jax.numpy as jnp
from jax import random
key = random.PRNGKey(0)
x = random.normal(key, (100, 784))
w = random.normal(key, (784, 256))
y = jnp.maximum(0, x @ w)  # ReLU 수동
        

# PyTorch - 명령형 스타일
for batch in dataloader:
    optimizer.zero_grad()
    loss = model(batch).loss
    loss.backward()
    optimizer.step()

# TensorFlow - GradientTape
for batch in dataset:
    with tf.GradientTape() as tape:
        loss = model(batch, training=True).loss
    grads = tape.gradient(loss, model.trainable_variables)
    optimizer.apply_gradients(zip(grads, model.trainable_variables))

# JAX - 함수형 스타일
@jax.jit
def train_step(params, opt_state, batch):
    loss, grads = jax.value_and_grad(loss_fn)(params, batch)
    updates, opt_state = optimizer.update(grads, opt_state)
    params = optax.apply_updates(params, updates)
    return params, opt_state, loss
        

2.2.3 마이그레이션 과제

2.3 API 비호환성 문제

프레임워크 차이를 넘어, AI 에코시스템은 여러 수준에서 API 비호환성을 겪고 있습니다: 클라우드 제공업체, 모델 서빙 플랫폼, MLOps 도구 및 모니터링 시스템.

2.3.1 클라우드 제공업체 API 분기

2.3.2 모델 서빙 플랫폼 파편화

서로 다른 서빙 플랫폼은 서로 다른 모델 형식, API 및 구성 접근 방식을 요구합니다:

2.3.3 "글루 코드" 문제

조직은 호환되지 않는 API를 연결하기 위해 방대한 양의 "글루 코드"를 작성하게 됩니다:

• 형식 변환기: 코드베이스의 20-30%가 데이터/모델 형식 변환에 전념
• API 어댑터: 각 클라우드 제공업체, 프레임워크 및 도구에 대한 래퍼 계층
• 모니터링 통합: 각 플랫폼에 대한 커스텀 메트릭 수집기
• 배포 스크립트: 플랫폼별 구성 및 배포 로직
• 테스트 인프라: 각 통합 지점에 대한 별도 테스트 스위트

2.4 프로토콜 이질성

AI 에코시스템에는 표준화된 통신 프로토콜이 부족하여 모델 추론, 훈련 및 관리를 위한 호환되지 않는 인터페이스가 확산되고 있습니다.

2.4.1 추론 프로토콜 환경

2.4.2 데이터 직렬화 혼란

프로토콜이 일치하더라도 데이터 직렬화 형식은 다릅니다:

# TensorFlow Serving - Protobuf 형식
{
  "instances": [
    {"input": [1.0, 2.0, 3.0]}
  ]
}

# TorchServe - JSON 형식
{
  "data": [[1.0, 2.0, 3.0]]
}

# KServe V2 - 구조화된 형식
{
  "inputs": [{
    "name": "input",
    "shape": [1, 3],
    "datatype": "FP32",
    "data": [1.0, 2.0, 3.0]
  }]
}

# OpenAI 호환 - 채팅 형식
{
  "messages": [
    {"role": "user", "content": "처리: 1.0, 2.0, 3.0"}
  ]
}
        

2.4.3 훈련 프로토콜 파편화

분산 훈련 프로토콜은 추론보다 훨씬 더 파편화되어 있습니다:

2.5 데이터 형식 과제

데이터 형식 비호환성은 원시 데이터 수집에서 모델 배포 및 모니터링까지 AI 파이프라인의 모든 단계에 영향을 미칩니다.

2.5.1 훈련 데이터 형식

2.5.2 모델 형식 비호환성

모델 직렬화 형식은 가장 중요한 상호운용성 병목입니다:

2.5.3 메타데이터 및 계보 추적

모든 MLOps 플랫폼은 모델 메타데이터를 추적하기 위해 서로 다른 스키마를 사용합니다:

• MLflow: 아티팩트, 매개변수, 메트릭이 있는 커스텀 스키마
• Weights & Biases: 독점 API 및 데이터 형식
• Neptune.ai: 별도의 메타데이터 구조
• Comet.ml: 다른 조직 및 API
• 클라우드별: SageMaker Lineage, Vertex AI Metadata, Azure ML 추적

2.6 보안 및 개인정보 우려

상호운용성 과제는 AI 수명 주기 전반에 걸쳐 복합되는 보안 및 개인정보 위험을 만듭니다.

2.6.1 형식 변환으로 인한 보안 격차

각 모델 변환 단계는 잠재적인 보안 취약점을 도입합니다:

2.6.2 개인정보 규정 준수 과제

서로 다른 AI 플랫폼과 프레임워크는 일관되지 않은 개인정보 제어를 가지고 있습니다:

• GDPR 설명 권리: 모델이 독점 형식으로 블랙박스화되면 구현이 어려움
• 삭제 권리: 배포된 모델에서 개별 훈련 예제를 제거하는 표준 없음
• 데이터 거주: 멀티 클라우드 배포가 데이터 주권 요구사항을 위반할 수 있음
• 감사 추적: 플랫폼 간 파편화된 로깅으로 규정 준수 감사가 복잡함
• 차등 개인정보: 프레임워크별 구현을 변환 간에 확인할 수 없음

2.7 벤더 락인 문제

상호운용성 부족은 강력한 벤더 락인 효과를 만들어 경쟁과 혁신을 제한하면서 비용을 증가시킵니다.

2.7.1 클라우드 제공업체 락인 메커니즘

2.7.2 락인의 숨겨진 비용

2.8 챕터 요약

이 챕터는 현대 기계 학습 에코시스템 전반에 걸친 AI 상호운용성의 다면적 과제를 탐구했습니다. 핵심 통찰력은 다음과 같습니다:

2.9 복습 질문

2.10 앞으로의 전망

AI 상호운용성 과제의 범위와 심각성을 확립한 후, 이제 솔루션으로 전환합니다. 제3장에서는 WIA AI 상호운용성 표준의 핵심 아키텍처와 설계 원칙을 소개하여 이 챕터에서 식별된 문제를 해결하면서 실제 채택에 실용적으로 유지하는 통합 접근 방식을 보여줍니다.

2.11 한국 모델 데이터 형식 정합 (ONNX·TensorFlow SavedModel·PyTorch JIT)

본 장에서 다룬 글로벌 프레임워크 파편화 과제는 한국에서도 동일하게 나타납니다. 그러나 한국은 자체 초거대 언어모델을 보유한 소수 국가로서, 자국 모델을 글로벌 형식과 호환되도록 표준화하는 과제를 동시에 안고 있습니다. 본 절은 ONNX·TensorFlow SavedModel·PyTorch JIT의 3대 형식이 한국 산업계에서 어떻게 운영되는지 정리합니다.

한국 모델별 형식 매핑

본권 ENUM HYPERCLOVA_X·EXAONE·SAMSUNG_GAUSS·SKT_ADOT·KOBERT·KLUE_BERT는 다음 형식 매핑을 통해 글로벌 모델(GPT_4·CLAUDE_3·LLAMA_2·MISTRAL·GEMINI·BERT)과 동일한 상호운용 계층에서 처리됩니다.

한국 모델 서빙 인프라 ENUM 매핑

본 장 2.3.2 절에서 다룬 모델 서빙 플랫폼 파편화는 한국에서도 동일합니다. 단, 한국 클라우드 사업자는 NVIDIA Triton 및 KServe를 표준으로 채택하는 비중이 높아 본권 ENUM NVIDIA_TRITON·KSERVE·BENTOML·SELDON·VLLM·MLFLOW·KUBEFLOW·OPENINFERENCE 정합이 비교적 용이합니다.

• 네이버 클라우드 플랫폼 — NVIDIA Triton(NVIDIA_TRITON) + 자체 클로바 추론 엔진. HyperCLOVA X는 자체 엔진 사용, 외부 모델은 Triton 경유.
• KT 클라우드 — KServe(KSERVE) + MLflow(MLFLOW) 모델 레지스트리. 본권 4장 메타데이터 스키마의 한국 참조 구현 1순위.
• NHN 클라우드 — BentoML(BENTOML) + Seldon Core(SELDON) 혼용. Kubeflow(KUBEFLOW) 파이프라인을 표준 채택.
• 카카오 i 클라우드 — vLLM(VLLM) 기반 KoGPT 추론. OpenInference(OPENINFERENCE) 트레이싱 사양 도입(2025).
• 삼성 SDS Brity AI — KServe + 자체 어댑터. EU AI Act 정합 자동 감사 기능.

한국 모델 변환 사례 연구

한국 산업계에서 EXAONE 3.0(LG AI연구원)을 글로벌 클라우드에 배포한 사례는 본 장 2.5.2 절의 모델 형식 비호환성을 실증합니다. LG는 PyTorch 네이티브 체크포인트를 (1) SafeTensors로 변환하여 Hugging Face Hub에 공개, (2) ONNX로 변환하여 NVIDIA Triton에 배포, (3) TensorRT 최적화 후 자국 LG CNS 클라우드에 운영하는 3중 형식 운영을 채택했습니다. 본권 4장에서 정의하는 WIA 메타데이터 봉투를 사용하면 이 3중 운영을 단일 패키지로 통합할 수 있습니다.

한국 클라우드 사업자 API 호환성 매트릭스

본 매트릭스가 보여주는 핵심 통찰은 한국 클라우드 사업자가 OpenAI 호환 API(OPENAPI_3_1 + REST_API)를 사실상 공통 진입점으로 채택했다는 점입니다. 이는 본권 5장에서 다룰 2단계 API 브리지가 한국 시장에서 자연스럽게 정착할 수 있는 토대입니다.

한국 학계·표준화 기구 협력

한국정보통신기술협회(TTA)는 「AI 표준 PG1005」 작업반을 통해 ISO/IEC JTC1 SC42(인공지능)에 한국 입장을 제출합니다. 한국 입장의 핵심은 (1) 한국어 코퍼스(KLUE·NSMC·KORQUAD)의 글로벌 표준 등재, (2) ENUM HYPERCLOVA_X·EXAONE의 1급 시민 등재, (3) 「인공지능 기본법」 제13조의 국제 표준 정합 요구사항 반영입니다.

한국 시뮬레이터 deep-link

1차 출처

1. ONNX, ONNX Intermediate Representation Specification.
2. TensorFlow, SavedModel Guide.
3. PyTorch, PyTorch JIT TorchScript Documentation.
4. Hugging Face, safetensors Documentation.
5. GGML, GGUF File Format Specification.
6. MLflow, MLflow Model Registry Documentation.
7. 네이버, 「HyperCLOVA X 기술 보고서」 (2024).
8. LG AI연구원, 「EXAONE 3.0 Technical Report」 (2024).
9. 카카오, 「KoGPT 6B 공개」 (2023).
10. SK텔레콤, 「에이닷 멀티모달 LLM 기술 백서」 (2024).
11. 한국전자통신연구원 (ETRI), 「KoBERT·KLUE-BERT 사전학습 모델 공개」 (2020·2021).
12. 한국정보통신기술협회 (TTA), 「AI 표준 PG1005 작업 결과 보고서」 (2024).
13. NVIDIA, Triton Inference Server Documentation.
14. KServe, KServe Documentation.

본권 참조

1. WIA Standards 공개 저장소 (ai-interoperability 폴더), MIT 라이선스, GitHub: WIA-Official/wia-standards-public/tree/main/ai-interoperability — 본권 전반에 인용된 시뮬레이터·스펙·API·전자책 자산의 소스코드를 제공하는 오픈 표준 이니셔티브이며, 본 장이 인용하는 모든 1차 출처에 대한 표준 개정위원회의 정식 검증 기록 위치입니다.

2.12 한국 AI 산업 생태계의 상호운용 과제 심층 분석

한국 AI 산업은 2020년대 들어 자체 초거대 언어모델 보유국으로 도약했지만, 글로벌 모델 형식과의 정합 부족이 산업 현장의 실질적 병목으로 작용해 왔습니다. 본 절은 한국 산업계가 직면한 상호운용 과제를 네 가지 축으로 심층 분석합니다. 첫째 축은 자체 모델과 글로벌 모델의 어휘 정합 부재, 둘째 축은 한국어 토크나이저의 분절 방식 차이, 셋째 축은 클라우드 사업자 간 메타데이터 표준 부재, 넷째 축은 「인공지능 기본법」 시행에 따른 거버넌스 의무화 부담입니다.

한국 자체 모델과 글로벌 모델 어휘 정합 부재

한국 자체 초거대 언어모델은 영문 어휘에 한국어 어휘를 추가하는 방식으로 확장된 토크나이저를 사용합니다. 네이버 HyperCLOVA X는 영문 베이스 토크나이저에 한국어 형태소 단위를 추가한 SentencePiece BPE 변형을 채택했으며, LG AI연구원 EXAONE은 한국어와 영어를 균등하게 학습한 자체 토크나이저를 구축했습니다. 그러나 이러한 토크나이저 차이는 동일 입력 텍스트에 대해 토큰 수가 달라지는 결과를 낳습니다.

예를 들어 「한국 AI 표준화 거버넌스」라는 동일 입력 문장에 대해 GPT-4 토크나이저는 18개 토큰, HyperCLOVA X는 9개 토큰, EXAONE은 11개 토큰을 생성합니다. 동일 의미를 표현하는 데 사용되는 토큰 수가 두 배 이상 차이 나는 상황에서, 모델 간 비용·지연 시간·메모리 사용량을 정확히 비교하려면 토크나이저 정보를 메타데이터에 명시적으로 기록해야 합니다. 본권에서 정의한 WIA 모델 교환 형식의 메타데이터 봉투는 이러한 정보를 1급 시민으로 등재하는 표준 구조를 제공합니다.

한국어 토크나이저의 분절 방식 차이

한국어는 교착어 특성상 형태소 단위 분석이 필수적입니다. 한국어 자연어 처리 분야에서 가장 널리 사용되는 형태소 분석기는 다음 네 가지입니다. 첫째 Mecab-Ko(은전한닢)는 일본어 Mecab을 한국어로 재훈련한 분석기이며, 처리 속도가 빠르고 학계·산업계에서 가장 보편적입니다. 둘째 KoNLPy는 Hannanum·KKMA·Komoran·Mecab·Open Korean Text를 통합한 파이썬 라이브러리이며, 학습용으로 적합합니다. 셋째 Khaiii(카카오)는 카카오가 공개한 형태소 분석기로 정확도가 매우 높습니다. 넷째 Soynlp는 통계 기반 한국어 비지도 학습 분석기로 신조어·은어 처리에 강점이 있습니다.

이 네 가지 형태소 분석기는 동일 입력 문장에 대해 서로 다른 분절 결과를 생성하며, 이는 다운스트림 NLP 모델의 성능에 직접 영향을 미칩니다. 예를 들어 「최근 한국 인공지능 산업이 급성장하고 있습니다」라는 문장에 대해 Mecab-Ko는 12개 형태소, Khaiii는 14개 형태소, KKMA는 16개 형태소로 분절합니다. 본권 모델 교환 형식의 종속성 필드에 사용된 형태소 분석기를 명시하지 않으면, 모델 재현이 불가능한 상황이 발생합니다.

한국 클라우드 사업자 간 메타데이터 표준 부재

한국 4대 클라우드 사업자(네이버 클라우드 플랫폼·KT 클라우드·NHN 클라우드·카카오 i 클라우드)는 각각 자체 모델 레지스트리와 메타데이터 스키마를 운영합니다. 네이버 클라우드 플랫폼의 모델 레지스트리는 클로바 스튜디오 중심으로 설계되어 외부 모델 등재가 제한적입니다. KT 클라우드는 MLflow 호환 레지스트리를 운영하여 글로벌 호환성이 가장 높습니다. NHN 클라우드는 BentoML 기반으로 컨테이너화된 모델 패키징을 표준으로 채택했습니다. 카카오 i 클라우드는 Hugging Face Hub 호환 자체 모델 허브를 운영하며 한국어 모델 미러링에 중점을 둡니다.

이러한 네 가지 사업자별 표준 차이는 한국 내 멀티 클라우드 전략을 추진하는 기업에게 상당한 운영 부담을 초래합니다. 한 모델을 네 사업자에 동시 배포하려면 네 가지 서로 다른 메타데이터 변환 파이프라인을 유지해야 하며, 모델 업데이트 시마다 네 곳에서 동기화 작업을 수행해야 합니다. 본권에서 제안하는 WIA 모델 교환 형식은 이러한 사업자별 표준의 상위 추상화 계층으로서, 단일 메타데이터 봉투로 네 사업자에 동시 배포할 수 있는 표준을 제공합니다.

「인공지능 기본법」 시행에 따른 거버넌스 의무화 부담

2026년 1월 22일 시행되는 「인공지능 기본법」(법률 제20127호)은 고영향 AI 사업자에게 안전성·신뢰성 확보 의무, AI 영향평가 의무, 사후 모니터링 의무, 사고 통보 의무를 부과합니다. 이러한 의무는 모델 메타데이터에 거버넌스 기록을 추가하는 작업을 산업계 전반에 강제합니다.

고영향 AI 사업의 정의는 본법 제2조 제4호 및 시행령에서 구체화되며, 의료·금융·교통·고용·교육·사법 등 6개 분야가 고영향 분야로 지정됩니다. 이 분야의 AI 사업자는 모델 출시 전 영향평가를 수행하고, 영향평가 보고서를 한국인터넷진흥원(KISA)에 제출해야 합니다. 모델 운영 중 사고 발생 시 24시간 이내 통보 의무가 발생하며, 사고 원인 분석 보고서를 14일 이내 제출해야 합니다.

본권 모델 교환 형식의 메타데이터 봉투는 이러한 거버넌스 의무를 모델 패키지 자체에 내장하는 표준을 제공합니다. 영향평가 보고서 ID, 사고 통보 기록, 안전성 검증 결과, 신뢰성 인증 번호를 모델 패키지의 보안 섹션에 등재하면, 모델 운영 중 발생하는 모든 거버넌스 추적이 자동화됩니다. 이는 단순 편의성을 넘어 「인공지능 기본법」 준수 비용을 대폭 절감하는 표준 인프라입니다.

한국 산업계 채택 권장사항

본 절에서 분석한 네 가지 축의 상호운용 과제는 한국 AI 산업이 글로벌 시장에서 경쟁력을 확보하기 위해 반드시 해결해야 할 과제입니다. 본권에서 제안하는 WIA 모델 교환 형식은 이 네 가지 과제를 단일 표준으로 해결하는 구조를 제공하며, 한국 산업계는 다음 권장사항을 따를 것을 제안합니다.

첫째, 한국 자체 초거대 언어모델 보유 기업은 자국 모델을 글로벌 표준 형식으로 변환하여 공개 저장소에 등재하는 정책을 채택해야 합니다. 둘째, 한국어 토크나이저 정보를 모델 메타데이터에 의무적으로 등재해야 합니다. 셋째, 한국 4대 클라우드 사업자는 본권 표준을 공통 상위 추상화 계층으로 채택하여 사업자 간 호환성을 확보해야 합니다. 넷째, 「인공지능 기본법」 준수 기록을 모델 패키지 자체에 내장하는 표준 절차를 도입해야 합니다.