핵심 이슈: '배포 이후'를 묻는 세 가지 신호
모델 정확도를 높이는 것보다, 그 모델이 프로덕션에서 예측 가능하게 작동하도록 유지하는 것이 훨씬 어렵습니다. 최근 포착된 세 가지 신호—MLOps 플랫폼의 코스닥 상장, LLM 옵저버빌리티 표준화 논의, 모바일 SLM 실측 데이터—는 모두 같은 질문을 가리키고 있습니다. 배포 버튼을 누른 이후, 우리는 무엇을 측정하고 있는가?
맥락 ①: MLOps 플랫폼의 시장 검증—마키나락스 코스닥 상장
산업 AI 전문 기업 마키나락스가 한국거래소 코스닥 예비심사를 통과하며 올해 상반기 IPO를 예고했습니다. 표면적으로는 기업공개 뉴스지만, 데이터 분석가의 시각에서 더 흥미로운 숫자는 따로 있습니다. 전략적 투자자(GS, 삼성, 포스코, 한화)가 곧바로 고객으로 전환되는 구조로 누적 투자 530억 원, 100건 이상의 버티컬 AI 프로젝트, 전년 대비 2배 이상 수주 증가—이 지표들은 MLOps 플랫폼의 B2B 수요가 실재한다는 시장 검증입니다.
주목할 기술 포인트는 '런웨이(Runway)'가 폐쇄망 환경을 지원한다는 점입니다. 제조·국방 도메인은 클라우드 기반 ML 파이프라인이 기본 가정으로 삼는 인터넷 연결, 외부 API 호출이 원천 차단됩니다. 이 환경에서 모델 개발→배포→운영 전 주기를 통합 지원한다는 것은, 단순한 'Jupyter + 배포 스크립트' 수준이 아니라 에어갭(air-gap) 환경의 MLOps 재현 가능성 문제를 건드립니다. 오픈소스 ML 스택을 그대로 들고 오는 것이 불가능한 환경에서, 이 회사가 어떤 방식으로 모델 버전 관리와 드리프트 감지를 구현하고 있는지—그 기술적 세부가 공개되지 않은 점은 아쉽습니다. 나이스디앤비·이크레더블의 기술성 평가 'A-A' 등급이 이를 어느 정도 대리 검증해주지만, 재현 가능성은 여전히 외부에서 확인하기 어렵습니다.
맥락 ②: LLM 모니터링의 측정 불가능성—OpenLLMetry가 건드리는 핵심
Traceloop의 Nir CEO와 SigNoz의 OpenLLMetry 논의(dev.to)는 LLM 옵저버빌리티의 근본적인 난제를 솔직하게 드러냅니다. 전통적인 ML에는 Accuracy, F1-score, RMSE 같은 명확한 지표가 있었습니다. 그런데 생성형 AI에서는?
"모델 응답이 이전 응답보다 나은지 아닌지, 사람 눈으로 보는 것 외에 방법이 없다."
이것이 지금 LLM 프로덕션 모니터링의 현실입니다. OpenLLMetry가 제안하는 해법은 OpenTelemetry 표준을 LLM 파이프라인에 그대로 적용하는 것입니다. 벡터 DB 조회→프롬프트 구성→LLM 호출→응답 반환의 흐름이 HTTP request-response 패턴과 구조적으로 동일하기 때문에, 단 한 줄의 초기화 코드로 전체 체인의 레이턴시, 토큰 사용량, 비용을 자동 계측할 수 있다는 주장입니다.
여기서 잠깐, '근거는 있나요?'를 물어야 합니다. 자동 계측이 가능한 것은 비용·속도·리소스 지표입니다. 그러나 LLM 모니터링에서 진짜 어려운 부분—응답 품질의 드리프트 감지—은 여전히 미해결입니다. 토큰 수가 줄었다고 품질이 나빠진 걸까요, 아니면 모델이 더 효율적으로 답한 걸까요? 이 둘을 구분하는 자동화된 메트릭이 아직 표준화되지 않았다는 점을 Nir 본인도 인정합니다. OpenLLMetry는 관측 인프라 문제를 해결하지만, 무엇을 관측해야 하는가의 문제는 여전히 열려 있습니다.
맥락 ③: 모바일 SLM 실측—벤치마크와 기기 성능의 괴리
브런치의 TecAce 팀 사례(모바일용 SLM 선정 전략)는 온디바이스 AI의 현실을 수치로 보여주는 드문 사례입니다. Galaxy S25 FE 기기에서 Gemma-2B INT4 모델을 직접 측정한 결과는 교과서보다 솔직합니다.
CPU 환경: 첫 토큰까지 5,000~7,800ms 지연. 대화형 UX에서는 사실상 사용 불가 수준입니다.
GPU 환경: 속도는 개선되었지만, max_tokens 설정값을 다 채우기 전에 OOM(Out of Memory)으로 응답이 잘리는 현상 발생.
하이퍼파라미터 영향도 분석도 실용적입니다. max_tokens가 레이턴시에 미치는 영향이 80% 이상인 반면, temperature는 1% 미만—이 결과는 모바일 온디바이스 환경에서 응답 속도 최적화의 첫 번째 레버는 출력 길이 제어임을 시사합니다. 흥미롭게도 Phi-4-mini는 3.8B 파라미터로 MMLU 67.3%를 기록하지만, 이 팀이 최종 선택한 모델은 Gemma-2B였습니다—Android MediaPipe 생태계 호환성이 순수 벤치마크 점수보다 더 중요한 선택 기준이 된 것입니다. 이건 correlation이 아니라 명확한 인과 관계입니다: 프레임워크 호환성이 없으면 성능 수치는 의미가 없습니다.
시사점: 세 장면이 하나로 수렴하는 지점
세 사례는 표면적으로 다르지만, 하나의 공통 패턴을 드러냅니다: 측정의 어려움이 신뢰성의 병목이 되고 있다는 것입니다.
- 마키나락스의 런웨이는 폐쇄망에서의 모델 상태 추적이라는 측정 문제를 다룹니다.
- OpenLLMetry는 LLM 파이프라인 전체의 관측 가능성이라는 측정 문제를 다룹니다.
- 모바일 SLM 실측은 벤치마크 점수와 실제 기기 성능의 괴리라는 측정 문제를 드러냅니다.
여기에 Forest Code Labs의 Coherence Score(CS) 프레임워크(dev.to)를 더하면 그림이 완성됩니다. CS는 LLM 출력의 구조적 일관성을 8개 범주로 점수화하려는 시도입니다—Sequencing Integrity, Terminology Stability, Assumption Detection 등. BLEU/ROUGE가 표면 유사도를 측정하고, Perplexity가 확률 분포를 측정한다면, CS는 다단계 추론이 제약 조건을 얼마나 유지하는지를 측정합니다. Ground-truth 없이 inference-time에 적용 가능하다는 점이 실용적이지만, "domain별 임계값을 경험적으로 튜닝해야 한다"는 조건은 이 프레임워크의 일반화 가능성에 대한 추가 검증이 필요함을 의미합니다. Ablation study 결과가 궁금한 지점입니다.
전망: MLOps 인프라 투자의 다음 단계
세 가지 방향이 동시에 진행되고 있습니다.
첫째, 옵저버빌리티 표준화. OpenTelemetry가 웹 서비스 모니터링을 표준화했듯, OpenLLMetry 같은 시도가 LLM 파이프라인 계측의 공통 레이어가 될 가능성이 높습니다. 벤더 종속 없이 Pinecone, OpenAI, 자체 데이터베이스를 단일 대시보드에서 관측할 수 있다면, MLOps 팀의 온콜 부담은 실질적으로 줄어듭니다.
둘째, 온디바이스 AI의 하드웨어-소프트웨어 공동 최적화. Gemma-2B INT4가 Galaxy S25 FE에서 GPU OOM을 겪는다는 사실은, 모델 압축 알고리즘만으로는 충분하지 않고 NPU 스케줄러 수준의 튜닝이 필요함을 보여줍니다. 양자화(Quantization)와 NPU 최적화의 결합이 다음 병목입니다.
셋째, 버티컬 MLOps의 IPO 가능성. 마키나락스의 상장은 산업 특화 ML 인프라가 범용 클라우드 AI 서비스와 다른 시장을 형성할 수 있다는 시그널입니다. 폐쇄망, 규제 산업, 하드웨어 제약 환경—이 세 조건이 겹치는 곳에서 버티컬 MLOps의 가격 협상력은 생각보다 강합니다.
실제 운영 환경에서도 이 성능이 나올까요? 배포 버튼은 시작이 아니라 진짜 테스트의 출발점입니다.