데이터를 모두 모은 뒤 분석을 시작하는 팀과 데이터가 유입되는 즉시 분포의 변화를 감지하는 팀의 운영 효율은 시간이 갈수록 메울 수 없는 격차를 만들어낸다. 정적 데이터셋에 최적화된 기존의 알고리즘을 실시간 스트리밍 환경에 억지로 끼워 맞추는 방식은 결국 메모리 점유율의 폭발과 처리 지연이라는 한계에 부딪히기 마련이다. 특히 분포 간의 거리를 측정하는 최적 운송(Optimal Transport) 분야에서 이러한 차이는 단순한 성능 문제를 넘어 시스템의 생존 문제로 직결된다.
Sliced Wasserstein이 머신러닝의 표준이 된 이유
전통적인 Wasserstein 거리는 두 확률 분포 사이의 최소 이동 비용을 계산하는 강력한 도구다. 하지만 고차원 데이터에서 이 거리를 직접 계산하려면 엄청난 연산량이 필요했다. 이를 해결하기 위해 등장한 것이 Sliced Wasserstein(SW) 거리다. SW는 고차원 데이터를 무작위 방향으로 투영(Projection)하여 1차원 문제로 변환한 뒤, 정렬된 샘플 간의 거리를 평균 내는 방식을 취한다.
많은 개발자가 SW를 선택했던 이유는 명확하다. 1차원에서의 최적 운송은 단순히 데이터를 정렬하는 것만으로 해결되기 때문에 계산 복잡도가 획기적으로 낮아지기 때문이다. 오프라인 학습이나 정적 이미지 생성 모델의 손실 함수로 SW를 활용할 때, 이 방식은 수학적 견고함과 연산 효율성을 동시에 제공하는 최적의 선택지였다. 당시에는 전체 데이터셋을 메모리에 올리고 정렬하는 과정이 당연한 상식으로 통용되었다.
메모리 릭과 지연 시간: 배치 처리의 한계점
문제는 데이터가 '흐르기' 시작할 때 발생한다. IoT 센서 데이터, 실시간 사용자 로그, 혹은 지속적으로 업데이트되는 금융 시장 데이터와 같은 스트리밍 환경에서는 '전체 데이터셋'이라는 개념 자체가 모호하다. 기존의 SW 방식을 그대로 적용하려면 유입되는 모든 샘플을 메모리에 저장해야 한다.
이 경우 메모리 복잡도는 데이터의 양 $N$에 비례하여 $O(N)$으로 증가하게 된다. 수백만 개의 샘플이 매초 쏟아지는 환경에서 이는 치명적이다. 또한, 새로운 데이터가 추가될 때마다 전체 데이터를 다시 정렬해야 하므로 연산 지연(Latency)이 누적된다. 필자가 과거에 실시간 이상 탐지 시스템을 구축할 때 느꼈던 가장 큰 갈증도 바로 이것이었다. 윈도우(Window) 크기를 조절하며 타협점을 찾으려 애썼지만, 윈도우가 작으면 정확도가 떨어지고 크면 시스템이 뻗어버리는 딜레마는 배치를 전제로 한 알고리즘의 구조적 한계였다.
Stream-SW: 멈추지 않는 데이터 흐름을 타는 법
최근 제안된 Streaming Sliced Wasserstein(Stream-SW)은 이러한 병목을 근본적으로 해결하기 위해 설계되었다. 이 방식의 핵심은 데이터를 모두 저장하지 않고도 누적된 통계량을 바탕으로 SW 거리를 실시간 업데이트하는 데 있다. 전체 데이터를 정렬하는 대신, 스트리밍 샘플을 순차적으로 처리하며 분포의 추정치를 갱신하는 알고리즘을 도입한 것이다.
Stream-SW의 가장 큰 장점은 메모리 효율성이다. 데이터가 무한히 들어오더라도 메모리 사용량을 일정 수준(Constant) 혹은 매우 완만하게 유지할 수 있다. 이는 배치 기반 방식이 가졌던 $O(N)$의 메모리 부담을 획기적으로 줄여준다. 또한, 새로운 샘플이 들어올 때마다 증분 업데이트(Incremental Update)를 수행하므로, 전체 데이터를 다시 계산할 필요가 없어 실시간 응답성이 보장된다. 이는 단순히 속도가 빨라진 것을 넘어, 하드웨어 자원이 제한된 엣지 컴퓨팅 환경에서도 정교한 분포 비교가 가능해졌음을 의미한다.
도입 전 반드시 고려해야 할 트레이드오프
기존의 배치 기반 SW에서 Stream-SW로 전환하려는 팀이라면 반드시 챙겨야 할 몇 가지 주의사항이 있다. 첫째는 추정 오차(Estimation Error)다. 전체 데이터를 한 번에 보고 계산하는 방식에 비해, 스트리밍 방식은 근사치를 사용하므로 약간의 오차가 발생할 수밖에 없다. 특히 데이터의 분포가 급격하게 변하는 '컨셉 드리프트(Concept Drift)' 상황에서 알고리즘이 얼마나 빠르게 새로운 분포를 추종하는지 모니터링해야 한다.
둘째는 투영 방향(Projections)의 관리다. SW의 정확도는 무작위로 뽑은 투영 방향의 개수에 의존한다. 스트리밍 환경에서는 이 투영 방향들을 고정할 것인지, 아니면 주기적으로 갱신할 것인지에 대한 설계가 필요하다. 투영 방향이 너무 많으면 실시간성이 저하되고, 너무 적으면 분포의 특징을 제대로 포착하지 못한다. 필자의 판단으로는 초기 도입 시에는 투영 방향을 고정하되, 메모리 여유분에 따라 점진적으로 늘려가며 최적의 지점을 찾는 것이 현명하다.
지속 가능한 AI 인프라를 위한 필자의 제언
솔직히 말해, 모든 프로젝트에 Stream-SW가 필요한 것은 아니다. 데이터셋의 크기가 고정되어 있고 학습 시간이 충분한 오프라인 환경이라면 기존의 배치 방식을 유지하는 것이 구현의 단순함 측면에서 유리하다. 하지만 당신의 서비스가 초 단위로 변하는 데이터를 다루고 있고, 인프라 비용 절감과 실시간성 확보가 지상 과제라면 이야기는 달라진다.
기술의 발전은 '더 큰 모델'을 만드는 방향뿐만 아니라 '더 효율적인 흐름'을 만드는 방향으로도 흐르고 있다. 이제는 데이터를 쌓아두고 고민하는 대신, 흐르는 데이터 속에서 즉각적인 통찰을 얻어낼 수 있는 구조로 체질을 개선해야 할 때다. 지금 바로 운영 중인 시스템의 메모리 프로파일을 확인해 보라. 만약 데이터가 늘어남에 따라 메모리 그래프가 우상향하고 있다면, 그것이 바로 Stream-SW로 갈아타야 할 가장 명확한 신호다.
참고: arXiv CS.LG (Machine Learning)