머신러닝 추론: 학습된 모델이 프로덕션에서 가치를 창출하는 방식

새 요청이 프로덕션 애플리케이션에 도달하면 머신러닝 모델은 최신 컨텍스트를 평가하고 결과를 생성한 뒤 다음 동작을 결정하는 시스템에 이를 반환해야 합니다. 이 모든 과정에 주어진 시간은 단 몇 초에 불과할 수 있습니다.

바로 그 순간이 추론입니다. 애플리케이션이 조치를 취할 수 있도록 학습된 모델을 라이브 데이터에 적용하는 과정입니다. 프로덕션에서 추론은 이를 둘러싼 전체 런타임 경로에 의존합니다. 이 경로의 어느 한 부분이라도 중단되거나 느려지거나 학습 시 사용한 로직에서 벗어나면, 예측이 너무 늦게 도착하거나 현실과 너무 어긋나 더 이상 유용하지 않을 수 있습니다.

Snowflake의 Applied Field Engineering 수석 AI/ML 아키텍트인 Trace Smith는 이러한 신뢰성 문제가 단순히 속도만의 문제가 아닌 이유를 이렇게 설명합니다. “사기 감지와 예측 유지 보수 같은 실시간 ML 애플리케이션에서는 지연 시간과 확장성이 주목받지만, 프로덕션을 흔드는 것은 대개 일관성입니다. 변환, 피처 로직, 서빙을 통합하면 학습-서빙 스큐를 방지하고 대규모 환경에서도 예측의 신뢰성을 유지할 수 있습니다.”

머신러닝 추론은 학습된 모델을 사용해 이전에 보지 못한 새로운 입력 데이터에서 출력을 생성하는 프로세스입니다. 출력은 모델과 작업에 따라 예측, 확률 점수, 분류, 임베딩, 생성된 응답 또는 추출된 필드가 될 수 있습니다.

추론 파이프라인은 일반적으로 소스 데이터와 결과를 사용하는 머신러닝 시스템 사이에 위치합니다. 이 파이프라인은 필요한 피처를 조회하고, 입력을 모델이 기대하는 형식으로 변환하며, 모델 스코어링을 실행합니다. 그런 다음 원시 출력을 활용 가능한 형태로 변환해 테이블, 애플리케이션, 추론 엔드포인트 또는 다운스트림 프로세스에 전달합니다.

이 흐름은 단순해 보이지만, 추론 파이프라인은 학습 과정에서 모델이 전제한 조건을 유지해야 합니다. 예를 들어 추론 시점에 피처를 다르게 계산하면, 같은 컬럼이라도 학습 시점과는 다른 비즈니스 개념을 나타낼 수 있습니다. 또 전처리를 일관되게 적용하지 않으면, 모델은 학습했던 값과 다른 형식, 스케일 또는 분포의 값을 입력받을 수 있습니다. 프로덕션에서 추론은 출력의 신뢰성을 유지할 수 있도록 주변 데이터 경로를 충분히 일관되게 유지해야 합니다.

학습은 모델이 배우는 과정입니다. 일반적으로 지도 학습에서는 레이블이 지정된 과거 데이터 같은 학습 데이터에서 패턴을 포착할 수 있도록 내부 파라미터(가중치)를 조정합니다. 일반적으로 컴퓨팅 집약적이며, 새 데이터가 제공되거나 성능이 저하되거나 예측 대상이 바뀔 때 주기적으로 실행되는 경우가 많습니다.

추론은 그 다음 단계로, 모델을 새로운 입력에 적용하는 과정입니다. 프로덕션 추론은 요청, 행, 이벤트, 파일 또는 프롬프트 전반에서 반복적으로 실행됩니다.

두 단계가 요구하는 인프라 조건은 크게 다릅니다. 학습은 일반적으로 컴퓨팅 집약적이지만 유한한 작업입니다. 작업이 시작되어 몇 시간 동안 실행된 뒤 종료될 수 있습니다. 추론은 지속적으로 수행되며 지연 시간에 민감합니다. 예를 들어 사기 탐지 모델의 경우, 트랜잭션 시작부터 승인까지의 시간이 밀리초 단위로 측정될 수 있습니다.

비용 구조도 비슷한 비대칭성을 보입니다. 대규모 모델 훈련에는 상당한 컴퓨팅이 필요할 수 있지만, 이는 일회성 또는 주기적으로 발생하는 비용입니다. 반면 추론은 모델이 운영되는 전체 기간 동안 실행되며, 대개 대량으로 발생합니다.

오프라인 평가에서 우수한 성능을 보인 모델도 추론 파이프라인이 오래된 입력을 제공하거나 지연 시간 예산을 초과하거나 다운스트림 시스템이 구문 분석할 수 없는 형식의 출력을 생성하면 프로덕션에서 성능이 떨어질 수 있습니다. 모델 품질과 추론 품질은 서로 관련되어 있지만 별개의 문제입니다.

머신러닝 추론의 주요 유형은 서로 다른 타이밍과 배포 요구 사항을 반영합니다. 어떤 유형을 사용할지 결정할 때는 모델이 예측을 생성하는 방식뿐 아니라 출력이 필요한 시점과 모델을 실행할 수 있는 위치까지 고려해야 합니다.

배치 추론

배치 추론은 일반적으로 일정에 따라 또는 정의된 데이터 파이프라인의 일부로 많은 레코드를 한 번에 스코어링합니다. 이 방식은 예측이 필요해지기 전에 미리 생성할 수 있을 때 가장 유용합니다. 예를 들어 야간에 고객 점수를 갱신하거나, 카탈로그 업데이트 전에 제품 데이터를 보강하거나, 계획 워크플로우가 시작되기 전에 예측치를 생성하는 경우가 여기에 해당합니다.

핵심 요구 사항은 처리량, 작업 안정성, 출력 처리입니다. 시스템은 예상 데이터 볼륨을 처리하고, 가용 시간 내에 작업을 완료하며, 다운스트림 분석, 애플리케이션 또는 운영 팀이 활용할 수 있는 위치에 결과를 기록해야 합니다.

배치 추론은 예측 출력 자체가 데이터 자산이 되는 워크플로우에 적합한 경우가 많습니다. 이탈 점수, 추천 테이블, 수요 예측, 문서 분류 결과는 저장하고 다른 데이터와 조인하며 보고, 계획 또는 애플리케이션 워크플로우 전반에서 재사용해야 할 수 있습니다.

실시간 또는 온라인 추론

실시간 추론은 온라인 추론이라고도 하며, 요청에 대한 응답으로 예측을 생성합니다. 애플리케이션이 입력을 추론 엔드포인트로 보내면 모델이 해당 입력을 스코어링하고 애플리케이션이 응답을 받습니다.

온라인 추론은 일반적으로 예측이 즉각적인 상호작용이나 의사 결정에 영향을 미칠 때 사용됩니다. 결제 승인 시점의 사기 감지, 활성 세션 중 콘텐츠 순위 지정, 실시간 대화에서의 next-best-action 프롬프트는 모두 타이밍을 놓치기 전에 예측이 도착해야 제대로 작동합니다.

실시간 추론에는 모델을 로드된 상태로 유지하고, 요청을 수락하며, 스코어링을 실행하고, 애플리케이션의 지연 시간 예산 안에 응답을 반환할 수 있는 모델 서빙 인프라가 필요합니다. 결과를 기다리는 시스템이 있기 때문에 요청별 지연 시간, 동시성, 콜드 스타트 동작, 서비스 수준 목표를 관리해야 합니다.

이러한 추론 유형은 피처 가용성에 대한 요구 수준도 더 높입니다. 모델이 최근 사용자 행동, 재고 상태 또는 트랜잭션 컨텍스트에 의존한다면, 추론 파이프라인은 이러한 입력을 빠르고 일관되게 가져올 수 있는 신뢰할 수 있는 경로를 갖춰야 합니다.

스트리밍 추론

스트리밍 추론은 예약된 배치나 동기식 요청을 기다리지 않고 이벤트가 도착하는 즉시 데이터를 지속적으로 스코어링합니다. 모델은 센서 판독값, 로그 이벤트, 클릭스트림 데이터와 같은 입력 스트림을 처리하고, 그 결과를 준실시간으로 다운스트림 시스템에 전달합니다.

스트리밍 추론은 운영 모니터링, 리스크 스코어링, 경고 워크플로우와 밀접하게 맞물리는 경우가 많습니다. 모델 출력은 이벤트를 라우팅하거나, 점수를 업데이트하거나, 검토를 트리거하거나, 이미 스트림을 처리 중인 다운스트림 시스템에 컨텍스트를 추가할 수 있습니다. 스트리밍 추론 파이프라인은 이벤트 처리, 피처 최신성, 출력 전달을 조율해야 합니다.

엣지 추론

엣지 추론은 중앙 집중식 환경이 아니라 디바이스 또는 로컬 시스템에서 모델을 실행합니다. 이 유형은 지연 시간, 연결성, 개인정보 보호 또는 데이터 전송상의 제약으로 중앙 집중식 추론을 적용하기 어려운 경우에 많이 사용됩니다. 엣지 추론은 모바일 애플리케이션, 센서, 차량, 카메라, 산업 시스템처럼 데이터 원천 가까이에서 예측이 이루어져야 하는 환경에서 많이 사용됩니다.

엣지 환경의 제약은 컴퓨팅, 메모리, 전력이 제한적이라는 점입니다. 일반적으로 모델은 디바이스의 제한된 조건 안에서 안정적으로 실행될 수 있도록 양자화, 프루닝, 지식 증류 등을 통해 먼저 압축해야 합니다.

모델이 프로덕션에 배포되면 팀은 모델 동작과 런타임 동작을 모두 설명하는 지표가 필요합니다. 정확도, 정밀도, 재현율 등 모델 품질 지표도 중요하지만, 추론 파이프라인이 지연 시간 목표를 충족하는지, 필요한 볼륨을 처리하는지, 지속 가능한 비용으로 출력을 생성하는지는 보여주지 못합니다.

측정해야 할 지표는 추론 패턴에 따라 달라집니다. 배치 작업은 일반적으로 처리량, 완료 시간, 예측당 비용을 중점적으로 봅니다. 온라인 추론은 지연 시간, 오류율, 콜드 스타트 동작을 중점적으로 봅니다. LLM 추론에서는 토큰 수준 지표가 추가됩니다. 출력 길이, 생성 속도, 컨텍스트 크기가 지연 시간과 비용에 직접적인 영향을 미치기 때문입니다.

추론 최적화에는 모델과 파이프라인이라는 두 가지 시작점이 있습니다.

모델 측면에서는 크기와 정밀도가 주요 변수입니다. 양자화는 가중치와 활성값의 수치 정밀도를 낮춥니다. FP32에서 INT8로 전환하면 메모리 사용량이 줄어들고 호환되는 하드웨어에서 처리량이 향상되는 경우가 많지만, 팀은 프로덕션 환경과 유사한 데이터로 정확도 저하 위험을 검증해야 합니다. 프루닝은 출력 품질에 거의 기여하지 않는 파라미터를 제거하여, 여전히 정확도 기준을 충족하는 모델의 컴퓨팅 및 메모리 요구 사항을 줄입니다. 지식 증류는 더 작은 모델을 학습시켜 더 큰 모델의 동작을 근사하도록 하는 기법입니다. 전체 모델의 정확도는 높지만 대상 서빙 환경에 비해 비용이 너무 많이 들거나 속도가 너무 느릴 때 유용합니다.

파이프라인 측면에서는 배칭이 가장 쉽게 적용할 수 있는 수단입니다. 요청을 함께 그룹화하면 하드웨어 사용률과 처리량이 향상되지만 지연 시간이 발생하며, 배치 워크로드는 실시간 엔드포인트보다 이러한 지연을 더 쉽게 감수할 수 있습니다. 동적 배칭은 유입 트래픽에 따라 그룹 크기를 조정하여 이러한 상충되는 요구 사항의 균형을 맞추는 데 도움이 됩니다.

하드웨어 선택은 비용과 성능을 좌우합니다. CPU는 처리량이 낮거나 컴퓨팅 집약도가 낮은 워크로드에 적합한 반면, GPU는 배치 크기와 모델 크기가 충분한 활용률을 뒷받침할 때 딥러닝 추론에서 상당한 처리량 이점을 제공합니다.

모델 형식과 런타임은 이식성과 실행 속도에 영향을 줍니다. ONNX는 팀이 여러 프레임워크와 런타임 전반에서 모델을 표현할 수 있는 방법을 제공합니다. TensorRT는 계층 융합, 정밀도 보정, 커널 선택, 그래프 최적화와 같은 기법을 통해 GPU에서 딥러닝 추론을 최적화할 수 있습니다.

LLM 추론에는 추가적인 튜닝 고려 사항이 있습니다. 프롬프트 길이, 컨텍스트 윈도우 사용량 및 최대 출력 토큰 제한은 모두 요청당 컴퓨팅 비용에 영향을 줍니다. KV 캐시는 이전 컨텍스트의 어텐션 키-값 계산을 저장하므로 모델이 각 토큰마다 이를 다시 계산하지 않아도 됩니다. 추측 디코딩은 더 작은 드래프트 모델로 토큰을 제안하고 더 큰 모델이 이를 검증하는 방식이며, 검증 과정에서 충분한 드래프트 토큰이 승인되면 처리량을 높일 수 있습니다. 근사 방식의 변형은 품질을 일부 희생하는 대신 속도를 높일 수 있습니다.

최적화하려면 무엇을 최적화할지 먼저 알아야 합니다. 지연 시간 감소와 처리량 개선에는 서로 다른 접근 방식이 필요한 경우가 많으며, 두 가지 모두 비용 목표와 충돌할 수 있습니다. 최적화하기 전에 측정하는 팀은 한 문제를 해결하려다 다른 문제를 만드는 상황을 피할 수 있습니다.

ML 추론에는 거버넌스 요구 사항이 적용될 수 있는 데이터, 모델, 출력이 모두 사용됩니다. 예를 들어 입력 데이터에 민감한 필드가 포함될 수 있고, 모델이 일부 사용 사례에는 승인되었지만 다른 사용 사례에는 승인되지 않았을 수 있습니다. 따라서 팀은 어떤 데이터가 사용되었는지, 어떤 모델 버전이 출력을 생성했는지, 누가 결과에 액세스할 수 있는지, 그리고 예측이 이를 사용하는 워크플로우에 적합한지 파악해야 합니다. 데이터 계보, 액세스 제어, 모델 메타데이터, 모델 모니터링은 모두 이러한 맥락을 확립하는 데 도움이 됩니다.

추론 출력이 재사용 가능한 데이터 자산이 될 때는 거버넌스가 특히 중요합니다. 명확한 소유권, 버전 관리, 액세스 정책이 없으면 이러한 출력을 감사하거나 설명하거나 안전하게 재사용하기 어려울 수 있습니다.

프로덕션 추론 워크플로우는 곧 데이터 워크플로우입니다. 모델에는 엔터프라이즈 데이터 시스템에서 가져온 입력이 필요하며, 출력은 일반적으로 다시 동일한 시스템으로 돌아가야 합니다. 고객 레코드에 조인되거나, BI 도구가 읽는 테이블에 기록되거나, 다운스트림 파이프라인으로 전달되는 방식입니다.

Snowflake는 두 가지 컴퓨팅 엔진인 웨어하우스 SQL 엔진과 Snowpark Container Services를 통해 모델 추론을 지원합니다. Snowflake Model Registry는 두 가지 모두에 대한 통합 인터페이스를 제공합니다.

높은 처리량이 필요한 배치 워크로드의 경우 Snowflake Batch Inference Jobs는 Snowpark Container Services를 사용하여 정적 데이터 세트 또는 주기적으로 업데이트되는 데이터 세트의 대규모 스코어링을 위한 분산 컴퓨팅을 제공합니다. 여기에는 Snowflake 스테이지에 저장된 비정형 데이터도 포함됩니다. 실시간 서빙의 경우 Snowflake는 Snowpark Container Services를 통해 모델을 관리형 HTTP 엔드포인트로 배포할 수 있도록 지원하여, 모델 배포가 기반 데이터가 상주하는 동일한 환경에 계속 연결되도록 합니다.

Cortex AI Functions는 거버넌스가 적용되는 데이터에 대한 LLM 기반 분석으로 추론을 확장합니다. 여기에는 텍스트 생성, 임베딩, 추출, 감성 분석, 요약, 번역과 AI_PARSE_DOCUMENT 같은 함수를 통한 멀티모달 문서 처리가 포함됩니다. 이러한 기능은 데이터를 외부 시스템으로 이동하지 않고 Snowflake에 이미 저장된 데이터를 대상으로 실행됩니다.

핵심 가치는 아키텍처 일관성입니다. 추론 워크로드마다 서로 다른 실행 패턴이 필요할 수 있지만, 프로덕션 팀이 이미 사용하는 데이터, 모델 관리, 출력 워크플로우와 계속 연결된 상태를 유지할 수 있습니다. Snowflake는 추론을 해당 추론이 의존하는 엔터프라이즈 데이터 가까이에 유지하면서 워크로드에 맞는 패턴을 선택할 수 있는 방법을 팀에 제공합니다.

추론 아키텍처는 데이터 경로를 따라야 합니다. 모델에는 학습 시 사용한 로직과 일치하는 입력이 필요하고, 파이프라인에는 워크플로우의 타이밍 요구 사항을 충족할 만큼 충분한 컴퓨팅이 필요하며, 출력은 분석, 애플리케이션 또는 다운스트림 시스템이 사용할 수 있는 위치에 도달해야 합니다. 이러한 요소를 분리하면 데이터 이동과 중복이 발생하고, 피처 로직이나 출력 처리에서 불필요한 드리프트가 발생할 여지가 생깁니다.

추론을 엔터프라이즈 데이터 가까이에서 실행하면 팀이 모델 출력을 고립된 모델 응답이 아니라 프로덕션 데이터로 취급하는 데 도움이 됩니다. 그 결과 소스 데이터에서 모델 스코어링을 거쳐 비즈니스 조치로 이어지는 경로가 더 안정적이 되며, 데이터를 준비하고 모델을 실행하며 출력을 사용하는 시스템 간 전달 과정도 줄어듭니다.