지속적 동형성 위한 인터리브 연산 및 메모리 효율적 구현

초록

본 논문은 Vietoris‑Rips 복합체를 점진적으로 생성하면서 영속성 동형성 알고리즘과 동시에 실행하는 인터리브 방식의 계산 모델을 제안한다. 최대 클리크 리스트를 유지해 새로운 간선이 추가될 때 발생하는 새로운 단순체를 효율적으로 찾아 스트림에 공급하고, 불필요한 메모리 사용을 최소화한다. 또한 메모리 사용량을 O(n·k) 수준으로 제한하고, 디스크 기반 저장 전략을 통해 대규모 데이터에서도 실행 가능하도록 설계하였다.

상세 분석

이 논문은 영속적 동형성(persistent homology) 계산에서 가장 큰 병목 중 하나인 메모리 소비 문제를 해결하기 위해 “인터리브 연산”이라는 새로운 패러다임을 도입한다. 전통적인 구현은 전체 Vietoris‑Rips 복합체와 그에 대응하는 단순체 스트림을 미리 생성한 뒤, 영속성 알고리즘에 투입한다. 이 과정에서 복합체의 차수가 k인 경우 O(n^k) 혹은 그보다 더 큰 메모리가 필요해, 수천 개 이상의 점을 다루는 실험에서는 거의 불가능에 가까운 상황이 발생한다.

저자는 먼저 그래프의 최대 클리크(maximal cliques) 집합을 유지한다는 핵심 아이디어를 제시한다. 새로운 간선 e = (s, t)가 추가되면, 기존 최대 클리크 L_s와 L_t의 교집합을 구하고, 이 교집합에 s와 t를 추가한 집합 (L_s ∩ L_t) ∪ {s, t} 가 새로운 클리크가 된다. 이때 발생하는 모든 부분집합이 새로운 단순체이며, 이들을 바로 영속성 알고리즘에 공급한다. Proposition 2.1은 이 과정이 완전하고 중복이 없으며, 기존 클리크는 그대로 유지된다는 수학적 근거를 제공한다.

알고리즘은 다음과 같은 흐름을 가진다. (1) 현재 그래프의 최대 클리크 리스트를 저장한다. (2) 스트림 형태로 들어오는 간선을 하나씩 읽으며, 해당 간선이 포함된 두 정점의 최대 클리크를 조회한다. (3) 교집합을 계산하고, 교집합에 간선을 추가한 새로운 클리크를 만든 뒤, 그 클리크의 모든 부분집합을 생성한다. (4) 중복을 제거하고, 생성된 단순체를 영속성 알고리즘에 즉시 전달한다. 이 과정은 단순히 새로운 간선이 들어올 때마다 로컬하게 수행되므로, 전체 복합체를 메모리에 보관할 필요가 없다.

영속성 알고리즘 자체는 기존의 Edelsbrunner‑Zomorodian 방식(2000)과 Carlsson‑Zomorodian 방식(2005)을 그대로 사용한다. 중요한 점은 영속성 알고리즘이 스트림을 소비하면서 현재까지 완성된 바와 아직 진행 중인 바를 모두 내부 상태에 유지한다는 점이다. 따라서 인터리브 방식으로 단순체를 공급하면, 영속성 계산이 중단 없이 연속적으로 진행될 수 있다.

메모리 사용량 분석에서는 두 부분으로 나뉜다. 첫 번째는 Vietoris‑Rips 복합체를 구성하기 위한 임시 저장소로, 이는 새로운 간선당 발생하는 새로운 클리크와 그 부분집합의 수에 비례한다. 저자는 이 양이 O(n·k) 수준으로 제한된다고 주장한다. 두 번째는 영속성 알고리즘이 유지하는 “마크된 단순체와 캐스케이드(cascade)” 테이블이다. 이 테이블 역시 최악의 경우 O(n·k) 메모리를 차지하지만, 실제 실험에서는 캐스케이드의 길이가 짧아 상수 계수가 크게 감소한다.

또한 논문은 디스크 기반 저장 전략을 제안한다. 전체 거리 행렬(O(n^2) 크기)을 디스크에 순차적으로 기록하고, 필요할 때마다 정렬된 형태로 읽어들여 간선 스트림을 생성한다. 영속성 인터벌이 종료된 뒤에는 해당 인터벌 정보를 디스크에 기록하고 메모리에서 삭제한다. 이렇게 하면 RAM 사용량을 수 GB 수준으로 제한하면서도 테라바이트 규모의 데이터셋을 처리할 수 있다.

전체적으로 이 접근법은 (1) 메모리 사용을 이론적으로 O(n·k)로 제한, (2) 단순체 생성과 영속성 계산을 동시에 진행해 중간 결과를 즉시 활용, (3) 디스크와 메모리의 계층적 활용을 통해 대규모 데이터에 대한 확장성을 확보한다는 점에서 기존 구현보다 큰 진보를 이룬다. 다만, 최대 클리크 리스트를 유지하고 교집합을 계산하는 비용이 그래프가 매우 조밀해질 경우 급격히 증가할 수 있으며, 실제 구현에서는 효율적인 클리크 관리 자료구조(예: Bron‑Kerbosch 변형)와 병렬화가 필요할 것으로 보인다.