Executive Summary

주요 수치

출처: Fu 외, OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration arXiv:2609.11148(2026-09-10) 5절·6절

논문 서론은 산업 현장의 LLM 데이터 준비가 미로로 무너지는 지점을 셋으로 적는다. 첫째는 데이터 사일로다. 수십 개 출처에서 온 코퍼스가 수백 장의 물리 테이블에 흩어져 있어서, 데이터셋을 가로질러 무엇이 어디 있는지 찾는 일부터 어렵다. 둘째는 비싼 피처 엔지니어링이다. 피처를 하나 추가하려면 그 피처가 닿는 데이터셋마다 작업을 손으로 맞춰야 한다. 그 대목에는 저자들이 따옴표까지 붙여 옮긴 사내 사례가 붙어 있다. 피처 하나 때문에 엔지니어가 "작업 캔버스에 테이블 106개를 끌어다 놓아야" 했다.

셋째는 끊긴 계보다. UDF 로직이 코드베이스 곳곳에 흩어져 중앙 버전 관리가 없고, 그래서 같은 피처의 정의가 자리마다 어긋난다. 계보와 피처 정의가 체계적으로 기록되지 않으니, 어떤 데이터와 피처 변경이 뒤따르는 학습과 모델 품질에 어떤 영향을 줬는지 팀이 믿을 만하게 되짚지 못한다. 논문은 이 항목을 설계 요구사항으로 옮겨 적으면서 낡은 계보가 정의 표류와 재현 불가능한 결과를 부른다고 썼다.

앞의 둘은 규모가 키운 문제다. 출처가 늘고 데이터가 커져서 생겼으니 더 빠른 엔진과 더 큰 클러스터가 어느 정도는 갚아 준다. 셋째는 그렇지 않다. 클러스터를 두 배로 늘려도 어떤 필터가 어떤 코퍼스를 얼마나 깎았는지는 여전히 어디에도 적혀 있지 않다. 규모 문제 둘 옆에 품질 문제가 하나 섞여 있고, 이 글이 따라가려는 것은 그 하나다.

되짚지 못하는 큐레이션은 학습이 끝난 뒤에 곤란해진다. 모델 품질이 지난번보다 나빠졌을 때 물어야 할 것은 어느 필터를 언제 바꿨고 그 필터가 어느 코퍼스를 얼마나 깎았느냐다. 그 기록이 없으면 남는 선택지는 둘뿐이다. 전부 다시 돌리거나, 그냥 넘어가거나. 어느 쪽을 골라도 다음번에 같은 질문이 다시 온다.

계보가 남아 있으면 되돌릴 범위도 좁아진다. 지난 8월에 다룬 규정 개정 재라벨링 사례에서는 계보를 따라 개정에 걸리는 항목만 지목한 쪽이 과거 데이터의 14.7%만 다시 평가해, 전체를 다시 라벨링한 경우와 0.5%포인트 차이의 정확도를 얻었다. 기록이 없으면 그 14.7%를 지목할 방법이 없으니 남는 것은 앞의 두 선택지뿐이다.

OmniTable은 피처를 1급 메타데이터로 올려 이 기록을 강제한다. 계산 로직, 입출력 의존성, 실행 환경 선호, 버전 이력이 카탈로그에 원자적으로 등록된다. 계산이 끝나면 시스템이 피처 ID와 버전과 타임스탬프와 실행 엔진을 계보로 적고 컬럼 상태를 갱신한다. 모든 행에는 전역 기본키가 하나씩 붙어 있어서, 출처와 처리 단계와 파생 피처를 가로지르는 정렬도 단건 조회도 계보 감사도 같은 키 위에서 돈다.

구조를 한 줄로 줄이면 논리 통합과 물리 분리다. 사용자에게는 모든 출처와 처리 단계와 파생 피처가 표 한 장의 컬럼으로 보인다. 행을 더하는 일은 수집이고, 컬럼을 더하는 일은 피처 선언이다. 그 아래에서 저장은 여러 물리 테이블로 쪼개져 있고, 카탈로그가 논리와 물리 사이의 지도와 피처 의존성을 들고 있다. 사용자가 SQL을 쓰면 카탈로그가 그것을 물리 실행 계획으로 옮긴다.

프로덕션 숫자가 이 분리를 눈에 보이게 한다. 웹과 코드와 PDF와 지도 미세조정 네 도메인을 합쳐 35페타바이트, 3,050억 레코드가 논리 테이블 네 장에 담겨 있고 그 아래 물리 테이블은 열여섯 장이다. 가장 큰 웹 테이블 한 장에만 25페타바이트와 3,000억 레코드가 들어 있고, 논리 컬럼이 800개를 넘으며 그중 등록된 피처가 200개를 넘는다. 물리 쪽은 컬럼 접근 빈도에 따라 여섯 장으로 나뉘어 있다.

물리 쪽을 계속 손보는 일은 선택이 아니다. 저자들은 백그라운드 압축과 분할을 있으면 좋은 기능으로 미뤄 뒀다가 석 달 만에 작은 파일이 쌓여 쿼리 지연이 3~5배 나빠졌고 컬럼 수가 엔진 한계에 부딪혔다고 돌아본다. 물리 배치가 계속 진화하지 않으면 PB 규모로 계속 쓰는 시스템은 몇 주 만에 못 쓰게 된다는 문장이 그 절의 결론이다.

저자들은 같은 결론을 실험으로도 확인했다. 백그라운드 압축과 행·열 분할을 끈 판본을 따로 돌려 봤다. 1페타바이트 아래에서는 처리량이 비슷하지만 25페타바이트 구간에서 시간당 5테라바이트로 내려가고, 논리 컬럼을 200개에서 2,500개까지 늘리는 실험에서는 1,200개를 넘어서는 지점부터 일부 질의가 아예 실패해 사람이 테이블을 다시 설계해야 했다. 배치를 계속 손보는 쪽은 같은 두 구간에서 처리량을 유지했고, 컬럼이 열두 배 넘게 늘어나는 동안 응답 시간은 1.53배 안에서 머물렀다. 손보는 일이 선택이 아니라는 말은 이 차이를 가리킨다.

비교는 지도 미세조정 데이터를 준비하는 실제 시나리오 하나에서 이뤄졌다. 8개 출처에서 지시 데이터를 모으고, 품질 점수와 안전 준수와 도메인 분류를 맡는 피처 12개를 계산하고, 골라낸 고품질 부분집합을 제거 실험용으로 내보내는 작업이다. 피처 12개 가운데 9개는 CPU UDF, 3개는 GPU 추론이다. 입력 배치와 필터 임계값은 양쪽에 똑같이 고정했다.

기존 방식에서 시간이 어디로 갔는지는 단계별로 나뉘어 있다. 8개 소스 테이블을 찾아 변환 스크립트를 쓰고 데이터를 복사하는 데 약 2일. 피처를 되채우는 데 약 9.5일. 이 단계에서 엔지니어는 피처 노드 12개와 테이블 8장을 곱한 약 96개 노드를 오케스트레이션 캔버스에 배치하고, 잘못된 파라미터와 나쁜 레코드 탓에 실패가 거듭됐고 그때마다 손으로 수습했다. 마지막으로 결과 테이블 8장을 다중 조인으로 엮어 내보내는 데 약 2.5일. 합이 14일이고 손으로 한 조작이 45단계, 파이프라인이 24개, 관련 물리 테이블이 35장이었다.

같은 작업이 OmniTable에서는 수집 0.5일, 피처 백필 1.7일, 필터 추출 0.3일로 끝난다. 수집은 명령 여덟 번이고, 백필은 피처 정의 12개를 등록한 뒤 계획 하나를 돌리면 의존성 해석과 엔진 배정과 파라미터 조정과 장애 격리가 따라온다. 추출은 논리 테이블에 SQL 한 번이다. 손으로 한 조작은 12단계, 명령은 10개, 대상은 논리 와이드 테이블 한 장이다.

백필에서 줄어든 7.8일이 어디서 나왔는지도 분해돼 있다. 연산자 퓨전이 입출력 부담에서 약 1.5일, UDF 단위 장애 격리가 원인 조사와 재시도에서 약 2~3일, 적응형 튜닝이 파라미터 탓 실패에서 약 1~2일을 덜어 냈다. 서로 겹치는 몫이 있어 합치면 5~6.5일이고 나머지는 스케줄링 개선에서 왔다. 퓨전만 따로 재면 CPU 시간이 55.9% 줄고 스캔 횟수가 8분의 1이 되며 종단간 시간이 38시간에서 14시간으로 내려간다.

장애 격리 하나만 떼어 낸 실험도 있다. 500기가바이트 배치 약 6억 레코드에 수학 콘텐츠를 골라내는 fastText 피처를 되채우는 작업이었고, 그중 약 3만 1천 건이 텍스트가 지나치게 길거나 인코딩이 깨져 메모리 초과를 일으켰다. 비율로는 0.005%다. 기존 방식에서는 이 0.005% 때문에 테라바이트급 작업 전체가 죽었고, 원인을 찾아 레코드를 빼고 다시 제출하는 일을 세 번 돌려 약 52시간이 걸렸다. 그중 18시간이 사람 손이었다. 레코드 단위로 가두면 같은 작업이 한 번에 약 6.2시간에 끝나고 사람이 개입한 횟수는 0이며, 문제가 된 31,247건은 오류 테이블에 적힌다. 0.005%가 52시간을 부르는 구조에서는 실패의 크기와 비용이 비례하지 않는다.

사람이 실제로 기다리는 자리는 대개 조회다. 전역 ID 인덱스를 켜면 단건 조회의 P50 지연이 8.3초, P99가 14.7초다. 인덱스 없이 물리 테이블을 다 훑으면 같은 값이 184초와 612초 이상이 된다. 집계 질의는 OLAP 쪽으로 넘겨 94~154배 빨라지고 전부 10초 안에 답이 온다. 필터를 걸어 내보내는 처리량은 1테라바이트에서 25페타바이트까지 시간당 18~23테라바이트로 유지된다. 이상한 레코드를 하나 발견하고 분포를 확인하고 부분집합을 뽑는 한 줄기가 배치 제출이 아니라 대화형 질의가 된다.

이 수치를 옮길 때 두 가지를 같이 적어야 한다. 비교 대상인 기존 방식은 외부 시스템이 아니라 OmniTable 이전의 사내 워크플로를 이력 기록과 운영 로그로 재구성한 자체 기준선이다. 그리고 저자 19명이 전원 앤트그룹 소속이라, 자사 시스템의 전후 비교를 자사가 적은 기록이다. VLDB 산업 트랙 최우수 논문으로 뽑혔다는 사실이 그 구조를 바꾸지는 않는다.

여기부터는 논문에 없는 해석이다. 데이터 준비도를 말할 때 가장 먼저 나오는 숫자는 대개 용량이다. 몇 테라바이트를 모았고 몇 건을 라벨링했는가. 그런데 이 논문이 실제로 판 것은 용량이 아니라 사람이 한 번 판단하고 다시 돌리기까지 걸리는 시간이다. 14일이면 필터 기준을 바꿔 보자는 제안이 2주짜리 결정이 된다. 2.5일이면 같은 제안이 실험이 된다. 바꿔 보고 아니면 되돌리는 선택지가 생기는 지점이 그 사이 어딘가에 있다.

그래서 우리 조직에 돌려줄 질문도 용량을 묻지 않는다. 며칠이 걸리는지, 무엇이 기록에 남는지를 묻는다.

• 피처나 필터를 하나 바꾸는 데 며칠이 걸리는가. 답이 주 단위라면 팀은 이미 바꾸지 않는 쪽을 고르고 있다.
• 어떤 필터가 어떤 코퍼스를 얼마나 깎았는지가 조회 가능한 기록으로 남아 있는가. 사람 기억과 문서에만 남아 있다면 없는 것과 크게 다르지 않다.
• 엔지니어링 시간의 몇 퍼센트가 장애 원인을 찾는 데 쓰이는가. 앤트그룹에서는 격리 장치를 넣기 전 이 항목이 30~40%였다.

이 속도는 자원을 더 써서 얻었다. 레코드 단위로 장애를 가두는 데 실행 비용이 3~5% 더 들고, 자주 읽는 컬럼을 미리 만들어 두는 데 저장 공간이 8~15% 더 든다. 작은 파일을 합치는 압축 작업도 클러스터 자원의 5~8%를 상시 가져간다. 되짚을 수 있는 상태를 유지하는 값이 그 정도라는 뜻이고, 논문이 그 값을 숨기지 않은 점은 신뢰할 만하다.

마지막 교훈은 사람 이야기다. 알고리즘 엔지니어는 SQL로 살고 SQL로 숨 쉬며, 테이블 하나 더 만들고 질의 하나 더 쓰는 것이 본능이라고 저자들은 적었다. 그 습관을 먼저 버리라고 요구하는 대신 논리 와이드 테이블이 평범한 SQL을 받게 만들고, 피처 템플릿으로 등록을 몇 분 안에 끝내게 하고, 계보를 조회 가능한 테이블로 뒀다. 가치를 주기 전에 워크플로 변경부터 요구하는 시스템은 채택되지 않고 우회된다는 문장으로 그 절이 끝난다. 데이터 준비도를 올리려는 조직도 어쩌면 도구를 고르기 전에 이 순서를 먼저 물어야 한다.

여기까지 읽어 주셔서 감사하다. 원문은 arXiv:2609.11148에서 전문을 볼 수 있고, 학회지에는 PVLDB 19권 12호 4276~4289쪽으로 실렸다. 이 글의 수치는 초록과 본문 5절, 6절에서 직접 확인했다. 우리 팀의 큐레이션 한 바퀴가 며칠인지 재 본 적이 있다면 어떤 단위로 쟀는지 나눠 주시면 좋겠다.

(주)페블러스 데이터 커뮤니케이션팀
2026년 9월 12일

• 1.Fu, Y. et al. (2026). "OmniTable: A Unified Wide-Table System for Petabyte-Scale LLM Data Curation and Exploration." arXiv:2609.11148. VLDB 2026 Best Industry Paper, PVLDB 19(12), 4276–4289.