"이 프로젝트, 납기 못 맞출 것 같은데." PM이라면 수없이 삼키는 말이다. 보통의 예측 모델에 물으면 답은 "지연된다" 아니면 "아니다", 둘 중 하나로 돌아온다. 맞히긴 하는데, 그래서 뭘 해야 할지는 알려주지 않는다.
LimiX-2는 여기서 한 걸음 더 간다. "지연된다"는 답과 함께, 그 지연이 어떤 변수들과 얽혀 있는지 연결 지도의 실마리까지 내놓는다. 예측을 넘어 변수 사이의 연결 지도를 그려주는 셈이다. 다만 이 모델은 원인과 결과의 방향까지 알려주진 않는다. 이 명확한 선 위에서, LimiX-2는 무엇을 새로 해냈을까?
먼저 용어 하나. 여기서 표란 행과 열로 정리된 데이터를 말한다. 매출 기록, 고객 명단, 프로젝트 진행표가 다 여기 속한다. LimiX-2는 이런 표를 다루는 파운데이션 모델이다. 파운데이션 모델은 한 번 크게 학습해두면 여러 과제에 두루 쓰는 범용 AI를 가리킨다.
회사에서 다루는 데이터는 대부분 사실 표다. 고객 명단, 센서 로그, 설문 응답이 전부 행과 열로 된 정형 데이터다. 문제는 표마다 생김새가 제각각이라는 점이다. 데이터셋마다 열의 개수도, 의미도, 크기도 달라서 하나의 모델로 다 덮기가 어렵다. 그래서 현장에서는 데이터가 바뀔 때마다 XGBoost 같은 모델을 처음부터 새로 학습시키는 방식이 오래된 관행으로 굳어졌다. XGBoost는 표 데이터 예측에 오래 쓰여 온 대표적인 기계학습 모델이다.
이 관행을 깨려는 시도가 최근의 '테이블 파운데이션 모델'이다. 대표적인 게 PFN 계열인데, 이들은 새 데이터를 다시 훈련시키지 않고 예제 몇 개만 맥락으로 보여주면 바로 예측한다. 이렇게 그 자리에서 보여준 예시만 보고 즉석에서 추론하는 방식을 인컨텍스트 학습이라고 한다.
그런데 여기에도 한계가 있었다. 논문은 이를 "타깃 중심"이라 표현한다. 오로지 정답을 맞히는 데만, 수학적으로는 '주어진 데이터와 맥락에서 정답이 나올 확률'을 높이는 데만 최적화돼 있다는 뜻이다. 지연 예측으로 바꾸면, "지연된다"는 답은 주지만 그 답이 어떤 요인들과 얽혀 나왔는지는 들여다보지 않는다. LimiX-2가 노린 지점이 바로 여기다.
시험을 앞둔 두 학생을 떠올려 보자. 한 학생은 기출문제의 정답을 통째로 외운다. 똑같은 문제가 나오면 맞히지만 조금만 비틀면 흔들린다. 다른 학생은 왜 그렇게 풀리는지 원리를 익힌다. 처음 보는 변형 문제도 풀고, "이 조건을 바꾸면 답이 어떻게 달라질까"라는 질문에도 대응한다. 현실의 모델이 둘 중 하나로 딱 갈리진 않고 정도의 문제지만, 기존 방식이 전자 쪽이었다면 LimiX-2는 후자 쪽으로 무게를 옮겼다.
원리를 익히는 학생처럼, LimiX-2는 데이터가 생겨나는 원리 자체를 배우려 한다. 정답뿐 아니라 입력 데이터까지 함께 보면서, 이 데이터에서 입력과 출력이 어떻게 함께 생겨나는지 그 전체 구조를 통째로 이해하려는 것이다. 논문은 이 접근을 CMN(Contextual Mechanism Networks)이라 부르는데, 논문의 표현을 빌리면 "타깃 중심 예측에서 메커니즘 지향 결합 모델링으로의 전환"이다. 그 안에는 두 가지 핵심 장치가 있다.
하나는 CCMM이라는 사전학습 방식이다. 사전학습이란 본 과제에 들어가기 전에 미리 대규모로 배워두는 단계를 말한다. CCMM은 표의 일부 칸을 가린 뒤 주변 맥락을 참고해 그 칸을 복원하도록 훈련한다. 언어 모델이 문장의 빈 단어를 맞히며 문맥을 배우듯, LimiX-2는 표의 칸들을 가리고 주변 정보로 맞히게 함으로써 변수들 사이의 관계를 익힌다. 정답 열만 가리는 게 아니라 데이터 곳곳의 빈칸을 맞히게 해서, 모델이 데이터의 전체 구조를 파악하도록 유도한다.
다른 하나는 학습 데이터다. LimiX-2는 SCM(구조적 인과 모델)이 만들어낸 합성 데이터로 배운다. SCM은 "무엇이 무엇의 원인인가"를 명시적으로 담아 데이터를 찍어내는 틀이고, 합성 데이터는 실제 수집한 데이터가 아니라 이 틀로 인공 생성한 데이터다. 지연 예측으로 풀어보면, 가상의 데이터 속에서 '숙련된 PM의 부재'가 '요구사항 변경'과 '일정 지연'을 함께 일으키는 시나리오까지, 데이터가 생겨날 수 있는 온갖 경우를 미리 겪게 한 셈이다. 그 덕에 실제 세계의 표를 처음 마주해도 그 뒤에 숨은 생성 원리를 추론할 밑바탕이 생긴다.
이렇게 다양한 생성 원리를 담은 대규모 합성 데이터를, 스케일링 법칙에 맞춰 설계한 대형 모델로 학습시켰다. 스케일링 법칙이란 데이터와 모델 크기를 키울수록 성능이 예측 가능하게 오른다는 경험 법칙이다. 핵심은 '예측 가능하게'다. 규모를 얼마나 키우면 성능이 어디까지 오를지 미리 가늠하고 거기에 맞춰 설계할 수 있다는 뜻이고, 그만큼 모델 개발이 운이나 감의 영역이 아니라 계획과 통제가 가능한 공학의 영역에 가까워졌다는 의미다. LimiX-2도 덩치를 즉흥적으로 불린 게 아니라 이 규칙에 따라 규모를 설계했다는 것이 논문의 설명이다.
성과는 두 갈래다. 첫째, 예측 성능이다. TabArena, TALENT, BCCO 세 평가에서 LimiX-2는 데이터셋 특화 모델과 테이블 파운데이션 모델을 모두 앞섰다. 앞엣것은 각 데이터에 따로 학습시킨 전통적 강자들을, 뒤엣것은 PFN 계열을 가리킨다. 두 진영을 동시에 넘었다는 게 핵심이다. 구체적인 수치와 데이터셋 규모는 공개된 논문 본문의 실험 섹션에 담겨 있다. 이 글에서는 개별 수치를 하나하나 옮기기보다 '세 평가에서 두 진영을 모두 앞섰다'는 결론에 초점을 두되, 더 정밀한 비교가 필요하면 본문 실험 결과를 직접 확인하길 권한다.
둘째, 그리고 어쩌면 더 흥미로운 성과는 인과 인식이다. CMN 덕분에, 모델이 어떤 변수에 주목하는지를 나타내는 내부 신호가 변수 사이의 인과적 연결을 담아낸다. 그 결과 어떤 변수가 어떤 변수와 연결돼 있는지를 보여주는 인과 뼈대를 복원할 수 있다(§5.5). 지연 예측으로 돌아오면, 기존 모델이 "지연된다"만 줄 때 LimiX-2는 "어떤 변수들이 지연과 맞물려 있는가"의 실마리까지 내놓는다. 예측기이면서 동시에 데이터 구조를 들여다보는 분석 도구가 되는 셈이다.
여기가 넘지 말아야 할 선이다. 이 실험이 입증한 건 변수 사이의 '연결 여부', 즉 방향 없는 뼈대까지다. 어느 쪽이 원인이고 어느 쪽이 결과인지 방향을 가리거나, 개입 효과나 실무 원인 진단까지 보인 건 아니다. 글 첫머리에 그어둔 선이 바로 이것이다.
온틀은 AI 프로젝트 매니저를 파견하는 SaaS다. AI PM이 실제로 다루는 데이터의 상당 부분은 화려한 텍스트가 아니라 표다. 태스크 목록, 진행률, 리소스 배분, 응대 기록 같은 정형 데이터가 판단의 뼈대다.
고객이 갑자기 납기를 2주 당겨달라고 했다고 하자. 기존 예측기라면 "지연 위험 높음"에서 끝이다. AI PM이 담당자에게 경고는 띄우지만, 담당자는 왜 그런지를 몰라 다음 손을 쓰기 어렵다. 여기에 LimiX-2 식 모델이 붙으면, "지연 위험 높음"과 함께 그 위험과 맞물린 변수들의 연결 지도가 같이 나온다. 이를테면 특정 모듈의 미결 태스크 수, 리뷰 대기 건수 같은 것들이다.
이 지도를 어떻게 읽느냐가 중요하다. 이건 원인과 결과를 가려주는 '진단 도구'가 아니라, 어떤 변수들을 함께 들여다봐야 할지 알려주는 '탐색의 출발점'이다. AI PM은 이걸 받아 "이 모듈과 리뷰 큐부터 보자"고 다음 손을 정한다. 결론을 단정하지는 않되, 어디부터 볼지는 좁혀준다. 담당자 입장에서 "지연됩니다"라는 통보와 "이 두 군데부터 보시죠"라는 안내는, 다음 행동으로 이어지는 정도가 다르다.
실용성도 있다. 온틀은 여러 고객사, 여러 프로젝트에 PM을 파견하는데 조직마다 표 구조가 제각각이다. 조직마다 모델을 새로 훈련하는 대신, 예시 몇 개만 맥락으로 보여주면 바로 작동하는 인컨텍스트 방식은 다수 고객을 빠르게 온보딩해야 하는 파견형 SaaS에 매력적이다. 물론 이는 논문이 직접 주장한 바가 아니라 온틀의 제품 철학으로 바라본 응용 가설이다. 하지만 표의 구조를 읽는 이런 기술은 글을 읽는 언어 모델과 역할을 나눠 ─ 한쪽은 문서와 대화를, 한쪽은 표 뒤의 연결을 맡아 ─ 더 정교한 판단으로 이어질 여지가 분명히 있다.
아닙니다. 2026년 9월 공식 모델 페이지에 가중치와 추론 코드가 공개됐지만, 그렇다고 당장 현업 도구를 대체하는 완제품이라기보다 표 데이터 AI가 어느 방향으로 가는지 보여주는 신호로 읽는 게 맞습니다. 기존 파이프라인은 유지하면서 흐름을 지켜보는 쪽을 권합니다.
개념상 다릅니다. 인컨텍스트 방식은 그 자리에서 보여준 예시를 '참고만' 해서 추론하는 것이지, 모델 자체를 다시 훈련시키는 게 아닙니다. 예시는 판단의 재료로 쓰일 뿐 모델의 기억으로 굳지 않습니다. 물론 실제 도입 시 데이터가 어디에 머무는지는 운영 환경에 따라 별도로 점검해야 할 사안입니다.
이 글에서 다룬 온틀 활용은 제품 탑재 발표가 아니라, 연구가 가리키는 방향이 우리 제품의 지향과 맞닿는다는 해석입니다. 정형 데이터 위에서 예측을 넘어 '설명 가능한 조언'을 지향한다는 점에서 눈여겨볼 가치가 있다는 뜻이며, 실제 적용은 별개의 검증을 거칠 사안입니다.