Nexus 논문에서 관심이 간 부분은 예측값 하나를 받기 전에 작업을 나누는 방식이다. 과거 수치를 정리하고, 함께 주어진 문맥을 읽고, 큰 흐름과 세부 변화를 따로 본 뒤 합친다. 한 번의 답변이 틀렸을 때 입력 문제인지 해석 문제인지 찾기 어려웠던 경험과 연결해서 읽게 됐다.
다만 작업을 나누면 예측이 자동으로 좋아진다는 뜻은 아니다. 잘못된 뉴스가 들어오면 여러 에이전트가 같은 오류를 다른 표현으로 되풀이할 수 있다. 전망을 설명하는 문장이 자세해도 그 설명이 실제 원인을 입증하지는 않는다. 복잡한 구조를 도입하기 전에 비교 조건부터 정해야 한다.
이 글은 2026년 5월 공개된 Nexus v1 논문의 구조와 결과표를 읽고 작성한 검토다. 코드를 실행해 성능을 재현하지 않았다. 뒤에 제시한 업무 예측 실험은 제안이며, 주가 전망이나 투자 수익을 검증한 결과도 아니다.
Nexus가 나누는 일과 내가 덧붙이고 싶은 도구는 다르다
Nexus는 맥락 정리, 거시·미시 전망 생성, 예측 합성과 보정이라는 단계로 구성된다. 과거 오차에서 만든 지침을 검증한 뒤 사용하는 보정 과정도 포함한다. 논문은 Zillow의 미국 도시별 주간 재고와 주식 일곱 종목 등을 평가한다. 여기까지가 논문의 설계와 평가 범위다. 논문 원문
내가 M365 Copilot의 Analytics agent로 Python 분석을 돌려 봤던 경험은 이 논문을 이해하는 데 연상이 됐다. 하지만 둘이 같은 구현이라는 뜻은 아니다. Nexus를 “LLM에 Python을 붙여 계산을 맡기는 시스템”으로 요약하면 논문이 설명하는 자체 수치 예측과 문맥 추론의 초점이 흐려진다.
내 업무 시스템에서는 날짜 정렬, 결측 확인, 오차 계산을 코드로 수행하고 LLM에 사건 정리나 설명 초안을 맡기는 구성을 고려할 수 있다. 이것은 Nexus의 성능을 그대로 가져오는 방법이 아니라 별도의 설계다. 코드가 있다고 계산이 저절로 정확해지는 것도 아니다. 단위 변환과 날짜 기준을 잘못 구현하면 같은 오류를 빠르게 반복한다.
분리의 장점은 특정 단계의 입력과 출력을 검사할 자리가 생긴다는 데 있다. 원자료가 맞는데 사건 요약이 틀렸는지, 전망을 합칠 때 근거 없는 수치를 넣었는지 추적할 수 있다. 이 이점을 얻으려면 중간 결과를 실제로 저장하고 검토해야 한다. 에이전트 이름만 여러 개 붙인 것으로는 충분하지 않다.
논문이 제시한 평균 성과와 모든 조건의 승리는 다르다
초안에서는 Nexus가 비교 모델을 일관되게 앞섰다고 적었다. 그러나 v1의 표 2에는 반례가 있다. Gemini 기반 주식 장기 예측에서 CoT 기준 모델의 MAPE는 0.1357, Nexus는 0.1379이고, RMSE도 각각 24.9644와 25.1986이다. 이 두 지표는 낮을수록 좋으므로 그 조건에서는 Nexus가 더 좋지 않다. 결과표를 포함한 원문
이 차이만으로 Nexus 전체가 무의미하다고 판단할 수도 없다. 의미 있는 질문은 어떤 자료와 예측 기간에서 도움이 되고 어디서 비용에 비해 이득이 적은가다. 같은 구조라도 장기와 단기, 숫자만 주는 조건과 문맥을 주는 조건을 분리해야 한다.
논문이 평가 자료를 모델의 지식 기준 시점 이후로 구성했다고 설명하는 점도 저자들의 평가 조건으로 읽어야 한다. 여기서 각 제공 모델의 실제 학습 자료나 누수 가능성까지 독립적으로 확인한 것은 아니다. 공개 시점 이후라는 설명만으로 모든 기억·검색 누수를 배제했다고 확정하지 않는다.
재현 실험을 한다면 논문과 같은 조건을 맞추는 실험과 내 업무 자료로 검토하는 실험을 분리하겠다. 입력, 버전, 예측 기간이 다른 결과를 논문 재현 성공이라고 부르지 않는다. 내 자료에서 좋게 나왔더라도 그것은 그 자료의 결과이고, 논문보다 일반적으로 우수하다는 증거는 아니다.
뉴스는 사건 날짜와 공개 날짜를 함께 보관한다
예측 실험에서 가장 먼저 막고 싶은 것은 미래 정보가 과거 입력으로 들어오는 일이다. 6월 1일의 수요를 예측하는데 6월 10일 기사가 “6월 초 수요가 급증했다”고 설명한다면, 사건은 6월 초여도 기사는 예측 시점에 이용할 수 없었다. 기사 본문에서 사건 날짜만 뽑아 연결하면 미래를 이미 아는 실험이 된다.
따라서 문맥 자료에는 사건 날짜, 최초 공개 시각, 수집 시각, 원문 URL과 수정 여부를 구분해 둔다. 예측 시점 이전에 공개된 자료만 사용하는지 확인한다. 웹페이지가 나중에 갱신됐다면 오늘 읽은 본문이 당시 본문과 같은지도 별도 문제다. 원래 상태를 확보하지 못하면 해당 자료를 과거 실험에서 제외하거나 한계로 남겨야 한다.
숫자 자료도 같은 문제가 있다. 나중에 수정되는 통계를 최신 다운로드 파일로만 평가하면 당시에는 알 수 없던 값이 들어갈 수 있다. 최초 발표치가 필요한 실험인지 최종 확정치 예측인지부터 정한다. 측정 대상이 다르면 결과를 해석하는 질문도 달라진다.
LLM이 웹을 자유롭게 검색하도록 열어 두면 입력 파일을 잘라 둔 것만으로 시간 제한이 성립하지 않는다. 재현 실험에서는 허용한 자료 묶음만 제공하고 외부 접근을 통제하는 구성이 필요하다. 외부 접근이 있었는지 로그로 확인할 수 없다면 시점 통제가 확인됐다고 보고하지 않는다.
작은 업무 실험은 단순한 예측과 먼저 비교한다
직접 시험한다면 주가보다 공개 가능한 주간 문의 건수처럼 단위가 명확한 자료부터 시작하고 싶다. 다음은 제안한 설계다. 예측 기준일마다 다음 네 주의 문의 건수를 예측하고, 그 시점까지 공개된 운영 일정만 문맥으로 제공한다. 실제 문의 기록에 고객 식별 정보가 있다면 집계와 접근 권한 검토가 먼저다.
비교 대상은 마지막 관찰값 유지, 계절 패턴을 이용한 단순 기준, 숫자만 읽는 LLM, 같은 숫자와 문맥을 읽는 LLM, 단계를 나눈 구성으로 둔다. 계절 기준은 해당 자료에 의미 있는 주기가 있고 충분한 과거가 있을 때만 사용한다. 검증하지 않은 계절성을 편의상 강제하지 않는다.
모든 구성에 같은 과거 길이와 같은 미래 평가 구간을 준다. 가장 복잡한 구성에만 더 좋은 문맥이나 더 많은 재시도 기회를 주면 구조의 이득과 입력·예산의 이득을 구분하기 어렵다. 사용한 정보량과 호출 횟수도 함께 기록한다.
한 번 좋은 결과가 나온 주를 고르지 않고 여러 예측 기준일을 앞으로 이동시키며 비교한다. 시간순 분할은 미래를 학습 자료로 섞는 무작위 분할과 목적이 다르다. scikit-learn의 TimeSeriesSplit 설명도 시간 순서를 고려하는 분할을 다룬다. 자료 간격과 예측 목표에 맞는 분할을 직접 확인해야 하며, 해당 클래스를 썼다는 이유만으로 모든 누수가 사라지는 것은 아니다. TimeSeriesSplit 문서
오차 지표는 단위와 실제 손실에 맞춰 고른다
문의 건수의 평균 절대 오차가 20건이라는 말은 현장에서 어느 정도인지 이해하기 쉽다. 반면 여러 도시나 종목을 합친 원단위 오차는 규모가 큰 계열의 영향을 강하게 받을 수 있다. 숫자를 한 줄로 만들기 전에 계열별, 예측 거리별 결과를 함께 보는 이유다.
MAPE는 비율로 보여서 편하지만 실제값이 0일 때 정의되지 않고 0에 가까울 때 불안정해질 수 있다. 0건인 주가 있는 문의 수요라면 그대로 적용할 수 없다. RMSE는 큰 오차에 더 민감하므로 큰 실패를 중요하게 볼 때 참고할 수 있지만, 이상치 하나가 결과에 미친 영향도 확인해야 한다. Forecasting: Principles and Practice의 정확도 평가
실제 운영에서는 과소 예측과 과대 예측의 손실이 다를 수 있다. 문의를 적게 예상해 응답이 밀리는 비용과 인력을 남겨 두는 비용은 동일하지 않다. 이런 비대칭을 반영하려면 업무 담당자와 별도의 손실 기준을 정한다. 사후에 우승 모델을 만들기 위해 지표를 바꾸지 않도록 평가 전에 기록하는 편이 좋다.
그럴듯한 설명의 점수와 숫자의 오차도 나눠 본다. 설명이 자료와 일치하는지, 존재하지 않는 사건을 만들지 않았는지 검사할 수 있다. 그러나 설명의 설득력을 미래값 정확도의 대리 지표로 쓰지는 않는다. 예측 숫자는 틀렸는데 설명이 훌륭한 경우가 얼마든지 가능하기 때문이다.
보정 규칙을 만든 자료와 마지막 시험을 분리한다
과거 실패를 보고 규칙을 추가하는 방식에는 장점이 있지만, 최근 사건 하나를 일반 법칙으로 만들 위험도 있다. 행사 직후 문의가 늘었다고 다음 모든 행사에 같은 증가율을 적용하면 규모, 채널, 요일 차이를 놓칠 수 있다. 규칙에는 근거 자료와 적용 조건, 아직 확인되지 않은 부분을 함께 적어야 한다.
실험에서 보정 규칙을 만들었다면 개발 구간에서 수정하고 별도의 검증 구간에서 채택 여부를 판단한다. 최종 시험 결과를 본 뒤 규칙을 고쳤다면 그 구간은 더 이상 손대지 않은 시험이 아니다. 결과를 잘 보이게 하려고 이름만 최종 시험으로 유지하지 않는다.
내가 남길 실행 기록에는 자료 버전, 기준일, 허용 문맥, 모델 식별자, 프롬프트, 보정 규칙, 중간 결과, 최종 예측과 비용이 들어간다. 다시 실행했을 때 다른 답이 나올 수 있으므로 시도 횟수와 선택 방식도 적는다. 좋은 답 하나만 골라 저장하면 반복 사용 시의 불안정성이 보이지 않는다.
복잡한 구성이 단순 기준보다 낫지 않거나 검토 비용이 커지면 도입을 멈출 수 있어야 한다. 이때 얻은 실패 기록과 자료 정리 규칙도 남길 가치가 있다. 에이전트를 많이 쓰는 것이 실험의 성공 조건은 아니다.
가격을 잘 맞히는 것과 투자 수익은 별개다
주식 데이터가 등장하더라도 예측 오차가 작다는 결과를 수익 보장으로 옮기면 안 된다. 실제 거래에는 시점, 매매 비용, 유동성, 포지션 크기, 위험 한도 등이 추가된다. 가격 수준을 잘 맞혔는데 방향을 잘못 예측할 수도 있고, 좋은 기간을 사후 선택한 전략은 미래에 재현되지 않을 수 있다.
이 글의 실험 설계는 예측 시스템을 평가하기 위한 교육용 검토다. 특정 종목이나 매매를 권하지 않는다. 나는 먼저 작은 업무 자료에서 시간 누수를 막고 단순 기준과 비교할 수 있는지 확인하려 한다. 그 과정을 통과한 뒤에야 단계 분리가 어느 오류를 줄였는지 이야기할 수 있다.
참고자료
- Das 외, Nexus: An Agentic Framework for Time Series Forecasting: 논문 서지와 초록.
- Nexus v1 HTML 원문: 단계 구성, 데이터 범위, 결과표와 한계 확인.
- scikit-learn, TimeSeriesSplit: 시간 순서를 보존하는 검증 분할의 동작과 조건.
- Hyndman·Athanasopoulos, Forecasting: Principles and Practice, 정확도 평가: 예측 오차, MAE·RMSE·MAPE와 평가 자료 구분.