왜 시계열 예측은 늘 숫자만 맞추려다 무너질까.
Nexus라는 논문을 읽고 나서 제일 먼저 든 생각은, 이 문제를 모델 성능의 문제가 아니라 작업 분해의 문제로 봐야 한다는 점이었다. 논문은 시계열 예측을 단순한 외삽이 아니라, 뉴스나 이벤트 같은 비정형 문맥까지 함께 추론해야 하는 agentic reasoning 문제로 다시 정의한다. 나는 이 관점이 꽤 설득력 있다고 봤다. 예측이란 결국 과거 숫자를 이어붙이는 일이 아니라, 숫자가 왜 그렇게 움직였는지 설명할 수 있어야 하는 일이기 때문이다.
숫자만 보는 모델이 왜 자꾸 흔들리는가
논문의 출발점은 단순하다. TSFM 같은 시계열 전용 모델은 숫자 패턴에는 강하지만, 현실 세계의 텍스트 신호를 모른다. 반대로 LLM은 뉴스, 공시, 사건 설명을 잘 읽지만, 숫자 자체의 시간적 구조를 안정적으로 다루는 데는 약하다. 둘 중 하나만 쓰면 항상 빈칸이 남는다. 숫자만 보면 충격 이벤트를 놓치고, 텍스트만 보면 계절성이나 추세를 놓친다.
이 구조는 투자나 업무 분석에서 늘 보던 문제다. 리서치 회사에서 보고서를 읽을 때도 결국 같은 일이 벌어진다. 숫자는 맞는데 맥락이 틀리거나, 맥락은 그럴듯한데 시점이 틀린다. 그래서 이 논문이 단순히 "LLM도 예측 잘함"이라고 말하는 것보다, 예측 파이프라인을 어떻게 나눌 것인가에 더 큰 의미가 있다고 느꼈다.
논문이 흥미로운 지점은 여기서 monolithic prompting을 버린다는 점이다. 하나의 거대한 프롬프트에 다 넣고 답을 받는 대신, 맥락 정리, 거시 전망, 미시 전망, 마지막 합성 단계를 분리한다. 이건 모델을 더 똑똑하게 만든다기보다, 모델이 생각할 수 있는 형태로 일을 쪼개는 방식이다. 사람도 같은 문제를 한 번에 풀지 못하면, 먼저 큰 흐름을 보고 다음에 세부를 본다. Nexus는 그 과정을 에이전트 구조로 옮긴 셈이다.
내가 납득한 부분은 Python을 붙였을 때다
이 논문을 더 현실적으로 만들어준 건, 내가 M365 Copilot의 Analytics agent로 직접 분석을 돌려본 경험이다. Analytics agent가 Python 코드를 만들어서 분석해주니, 생각보다 분석을 잘했다. LLM이 숫자 계산을 "직접" 잘 못하는 문제와, LLM이 Python을 도구로 써서 "간접"으로 잘 푸는 문제는 완전히 다르다.
이 차이가 Nexus의 핵심과 닿아 있다. LLM 단독으로 수치를 예측하게 두면 불안정하다. 하지만 LLM에게 역할을 나눠 주고, 필요한 경우 코드 생성과 검증을 붙이면 이야기가 달라진다. 즉, 모델이 숫자를 머릿속에서 암산하는 게 아니라, 분석 절차를 설계하고 실행하게 만들면 된다. 내가 보기에 이게 agentic forecasting의 진짜 실용 포인트다.
"LLM은 계산기다"라는 말은 반쯤 맞고 반쯤 틀리다. 정확히는 "LLM은 계산을 수행하는 인간형 조정자다"에 가깝다. 직접 수식을 잘못 외우는 대신, Python, 데이터 조회, 백테스트, 시각화 같은 도구를 엮어서 문제를 푼다. 그러면 계산의 정확도는 코드가 책임지고, 해석의 폭은 LLM이 책임진다. M365 Copilot에서 Analytics agent가 잘 동작했던 것도 이 조합 덕분이었을 것이다.
숫자를 잘 아는 모델보다, 숫자를 잘 다루는 에이전트가 더 유용하다.
이 논문이 투자 분석에 던지는 힌트
Nexus는 주가나 부동산 같은 변동성 큰 데이터에 대해, 과거 숫자와 문맥 신호를 분리해서 다룬다. 이건 투자 분석에서도 꽤 직관적이다. 예를 들어 실적 시즌에는 과거 차트보다 가이던스, 업황 뉴스, 메모리 가격 같은 문맥이 더 중요해지고, 평상시에는 추세와 계절성이 더 중요해진다. 하나의 모델이 모든 국면을 동일한 방식으로 처리하려고 하면 자주 삐끗한다.
그래서 이 논문을 읽으면서 "에이전트가 예측을 한다"는 말보다 "에이전트가 예측 문제를 분해한다"는 말이 더 정확하다고 느꼈다. Macro agent는 큰 방향을 보고, micro agent는 단기 변동을 보고, synthesizer는 둘을 합친다. 여기에 calibration loop까지 붙여 과거 오차를 규칙으로 바꾸면, 단순 생성기가 아니라 점점 튜닝되는 분석 시스템이 된다. 이건 실제 업무 시스템에서 꽤 강한 패턴이다.
내 관점에서는 여기서 중요한 건 정답률보다 재현성이다. 한 번 맞추는 모델은 많다. 그런데 왜 맞았는지 설명하고, 어떤 조건에서 틀리는지 남기고, 다음 예측에 반영하는 시스템은 적다. Nexus가 보여주는 건 바로 그 부분이다. 예측 자체보다 예측을 만드는 과정이 자산이 된다.
결국 LLM은 숫자 계산을 잘 못한다. 그게 오히려 정상이다. 대신 Python으로 분석을 시키고, 에이전트가 그 분석 절차를 조립하게 하면 된다. 그러면 LLM은 숫자 그 자체보다 숫자를 다루는 작업 흐름에서 강해진다. 그리고 그 지점부터는 예측도, 리서치도, 분석도 전부 에이전트 설계 문제로 바뀐다. 결국 좋은 모델을 고르는 일보다, 좋은 분해를 설계하는 일이 더 중요해진다.
이 논문을 해설 중심으로 읽으면, 핵심은 성능 수치 하나가 아니다. 오히려 어떤 종류의 정보를 어느 단계에서 처리하게 만들었는지에 가깝다. 원시 숫자를 바로 던지지 않고 먼저 정리하고, 그다음 거시와 미시를 갈라 보고, 마지막에 다시 합치는 구조는 생각보다 범용적이다. 이런 구조가 예측 문제뿐 아니라, 문서 요약이나 리서치 브리핑 같은 작업에도 그대로 확장될 수 있다고 본다. 한 번에 잘하는 모델을 찾는 대신, 잘 나뉜 역할을 가진 에이전트 묶음을 만드는 쪽이 더 현실적이다.
논문의 구조를 조금 더 보자. Nexus는 Contextualization, Dual-Resolution Forecast Outlook Generation, Forecast Synthesis and Calibration이라는 세 단계를 둔다. 처음에는 원시 숫자와 텍스트를 정리하고, 그다음에는 거시 전망과 미시 전망을 따로 만들고, 마지막에는 둘을 합쳐 최종 예측을 낸다. 이 순서는 단순히 공정 단계를 늘린 것이 아니라, 각 단계가 서로 다른 종류의 오류를 담당하게 만든 설계다. 한 단계 안에 모든 오류를 몰아넣으면 어디서 실패했는지 나중에 복구하기 어렵기 때문이다.
특히 calibration은 흥미롭다. 과거 예측 오차를 그냥 로그로 남기는 것이 아니라, 그 오차에서 규칙을 뽑아 다음 예측에 반영한다. 이건 사람이 리서치 메모를 남기고 다음 주에 다시 보는 것과 닮아 있다. "이번에는 왜 틀렸나"를 구조화해두면, 다음번에는 같은 실수를 반복할 확률이 줄어든다. Nexus가 말하는 agentic forecasting은 결국 이런 식의 학습 루프를 시스템 안에 넣는 일이다.
논문에서 평가한 데이터셋도 눈여겨볼 만하다. Zillow 부동산 메트릭과 변동성 큰 주식 7종목인데, 둘 다 LLM 지식 컷오프 이후 데이터를 썼다. 즉, 모델이 학습할 때 본 적 없는 기간에 대해 평가했다는 뜻이다. 이 조건이 중요한 이유는, LLM이 과거 데이터를 단순히 기억해서 맞추는 게 아니라 구조적으로 추론했는지를 검증해야 하기 때문이다. 컷오프 이후 데이터에서도 Nexus가 TSFM과 강한 LLM 베이스라인을 상대로 일관되게 앞섰다는 건, 에이전트 구조 자체가 예측 성능에 기여한다는 증거다.
결국 중요한 건 모델 하나가 아니라, 모델이 숫자와 문맥을 어떻게 나눠 생각하게 만드느냐다.