Kronos란? 금융 시계열 AI 모델, Chronos·TimesFM과 비교

결론부터 말하면, Kronos는 “주가 예측 AI”를 찾는 사람이 막연히 떠올리는 만능 모델보다는 “금융 OHLCV 데이터에 특화된 연구용 오픈소스 TSFM”에 가깝다. 2025년 8월 2일 arXiv에 공개됐고, 2025년 11월 10일 AAAI 2026 채택 소식이 올라왔으며, 2026년 5월 14일 기준 저장소 규모도 빠르게 커졌다. 다만 공개 모델의 컨텍스트 길이는 짧고, 가장 큰 Kronos-large는 아직 비공개다. 따라서 지금은 “금융 데이터 전용 파운데이션 모델의 방향성”을 읽는 글로 보는 편이 정확하다 (출처: Kronos 논문, Kronos-small 모델 카드, GitHub Repo API).

Kronos는 정확히 어떤 모델인가?

한 문장으로 줄이면, Kronos는 금융 시장의 K-line 데이터를 “언어”처럼 토큰화해서 다음 패턴을 예측하는 디코더 전용 파운데이션 모델이다. 일반적인 시계열 예측 라이브러리보다 더 LLM스러운 사고방식을 금융 OHLCV에 옮긴 셈이다.

금융 캔들스틱을 토큰으로 읽는다

공식 문서 기준 Kronos의 핵심은 2단계다. 먼저 OHLCV 같은 연속형 금융 데이터를 전용 토크나이저가 계층적 이산 토큰으로 바꾼다. 그다음 자기회귀 트랜스포머가 그 토큰 시퀀스를 읽고 미래 K-line을 생성한다. 즉 “수치를 바로 회귀”하기보다 “시장 패턴을 토큰 시퀀스로 번역한 뒤 다음 토큰을 예측”하는 구조다 (출처: Kronos 논문, Kronos-small 모델 카드).

프로젝트의 현재 공개 범위는 생각보다 분명하다

공개 정보는 꽤 명확하다. 학습 데이터는 45개 글로벌 거래소의 120억 개 이상 K-line 레코드다. 공개 모델은 Kronos-mini, Kronos-small, Kronos-base까지이며, Kronos-large는 아직 오픈소스로 나오지 않았다. 라이브 데모도 있지만 범위는 BTC/USDT 24시간 예측 한 종목에 한정된다. “모든 금융시장에 바로 붙는 완성형 예측 엔진”으로 읽기보다, 강한 연구 결과와 빠르게 커지는 오픈소스 프로젝트로 읽어야 한다 (출처: Kronos 논문, Kronos Live Demo, Kronos-small 모델 카드).

저장소도 제품보다 연구 프로젝트 쪽에 가깝다

2026년 5월 14일 기준 GitHub API를 보면 공개 릴리스와 태그는 비어 있다. 즉 버전 릴리스 중심 제품보다는 저장소와 모델 카드, 논문을 중심으로 읽어야 하는 프로젝트다. 반대로 말하면 커뮤니티 활동은 강하다. 공개 메타데이터와 이슈 흐름을 보면 연구 프로젝트 특유의 빠른 확장이 이어지고 있다는 뜻이기도 하다 (출처: GitHub Repo API).

왜 금융에는 범용 TSFM보다 특화 모델이 필요한가?

이 질문이 중요하다. Kronos의 가치는 “시계열 모델이 하나 더 나왔다”가 아니라, 왜 금융 데이터는 범용 TSFM만으로 잘 안 풀리는가를 정면으로 건드린다는 데 있다.

금융 시계열은 노이즈가 심하고 레짐이 자주 바뀐다

금융 시계열은 전력 수요, 소매 판매, 서버 메트릭과 다르다. 같은 시계열이라도 꼬리가 두껍고, 노이즈가 심하고, 시장 레짐이 바뀔 때 분포가 급격히 틀어진다. 논문도 기존 범용 TSFM이 금융 캔들스틱 데이터에서 비사전학습 구조보다 못한 경우가 있었다고 전제한다. Kronos는 바로 이 간극을 메우겠다고 나온 모델이다 (출처: Kronos 논문).

범용 모델의 장점과 특화 모델의 장점은 다르다

여기서 오해하면 안 된다. 범용 TSFM이 나쁘다는 얘기가 아니다. Amazon의 Chronos, Google의 TimesFM, Salesforce의 Moirai, Nixtla의 TimeGPT는 더 넓은 도메인, 더 긴 컨텍스트, 더 다양한 운영 시나리오를 겨냥한다. 반면 Kronos는 금융 K-line이라는 아주 좁고 깊은 문제에 집중한다. 그래서 “범용성”으로 경쟁하기보다 “금융 데이터의 언어”를 더 잘 읽는 쪽으로 승부를 거는 모델이다.

제품화는 결국 하네스와 평가 체계의 문제다

아무리 모델이 좋아도 금융 시스템에 얹는 순간 이야기가 달라진다. 데이터 파이프라인, 백테스트 규칙, 실행 비용, 리스크 관리가 붙기 때문이다. 이 지점은 AI 앱은 프롬프트가 아니라 하네스로 완성된다에서 정리한 문제와 비슷하다. 모델 단품보다 운영 구조가 더 중요해진다.

논문이 말하는 성능 향상은 어디까지 믿어야 하나?

Kronos를 둘러싼 가장 강한 훅은 숫자다. 그런데 이 숫자를 “좋은 연구 결과”로 읽을지, “당장 실전 매매에 쓸 신호”로 읽을지는 완전히 다른 문제다.

논문이 직접 말하는 수치는 강하다

이 수치 자체는 공식 논문과 모델 카드에 반복해서 등장한다. 즉 과장된 2차 요약이 아니라 저자들이 직접 내세우는 핵심 결과다 (출처: Kronos 논문, Kronos-small 모델 카드).

하지만 이 숫자는 PnL이 아니다

여기서 브레이크를 걸어야 한다. RankIC, MAE, generative fidelity는 어디까지나 예측 지표다. 거래 비용, 슬리피지, 체결 가능성, 포트폴리오 구성, 시장 충격은 별도 문제다. Kronos 공식 README도 파인튜닝과 백테스트 예제를 “시연 목적”이라고 못박고, 실제 프로덕션 수준의 퀀트 시스템은 포트폴리오 최적화와 리스크 중립화, 거래 비용 반영이 필요하다고 적는다. 이건 외부 비판이 아니라 프로젝트 문서 자체의 경고다 (출처: Kronos GitHub).

커뮤니티 반응도 아직은 탐색 단계다

2026년 5월 기준 GitHub 이슈를 보면 흥미로운 양면이 있다. 한쪽에서는 상업용 Kronos-large 접근 문의나 실거래 파이프라인 연동 시도가 계속 올라온다. 다른 한쪽에서는 “글로벌 TOP20 자산 장기 백테스트가 부정적이었다”는 오픈 이슈도 있다. 이런 사례는 아직 동료심사된 결론이 아니라 커뮤니티 보고에 가깝다. 다만 분위기 자체는 분명하다. 기대는 크지만, 실전 검증은 아직 흩어져 있다 (출처: Issue #273, Issue #282).

공개된 모델 라인업은 어떻게 나뉘나?

도입 판단에서는 벤치마크보다 이 표가 더 중요할 수 있다. 지금 당장 무엇을 받을 수 있고, 어느 정도 길이의 데이터를 먹일 수 있는지가 실제 사용성을 좌우하기 때문이다.

공개 모델은 세 개, 비공개 모델은 하나다

이 표만 보면 mini가 가장 만만해 보이지만, 기사용 판단은 조금 다르다. mini는 데모나 라이트한 시도에 좋고, 본격 비교의 중심은 small과 base다. 반면 사람들이 가장 궁금해하는 large는 현재 받지 못한다 (출처: Kronos-small 모델 카드).

컨텍스트 길이 512는 생각보다 큰 제약이다

Kronos-small과 Kronos-base의 최대 컨텍스트는 512다. 공식 문서도 입력 길이 lookback이 이를 넘지 않는 것이 좋고, 넘으면 자동 truncation 된다고 밝힌다. 즉 장기 시계열 전체를 길게 물리는 스타일보다, 비교적 짧은 구간의 OHLCV 패턴을 집중해서 읽는 방식에 더 가깝다. 이 점은 긴 문맥이 강점인 TimesFM 2.5와 대비된다 (출처: Kronos-small 모델 카드, TimesFM GitHub).

릴리스 관리보다 저장소 읽기가 더 중요하다

GitHub API 기준으로 2026년 5월 14일 현재 공개 releases와 tags가 비어 있다. 그래서 이 프로젝트는 “최신 버전 changelog”보다 README, 모델 카드, 논문, 이슈를 함께 읽는 편이 맞다. 운영 안정성보다 연구 속도가 앞서는 오픈소스 프로젝트에서 자주 보이는 패턴이다 (출처: GitHub Repo API).

직접 써보려면 어떤 입력과 제약을 알아야 하나?

좋은 점은 시작 방법이 복잡하지 않다는 것이다. 아쉬운 점은 입력 형식과 제약이 꽤 엄격하다는 점이다.

최소 입력은 OHLC, 선택 입력은 volume과 amount다

공식 예제 기준 predict 메서드는 open, high, low, close 컬럼을 필수로 받는다. volume과 amount는 선택이다. 타임스탬프도 별도 시리즈로 넘겨야 한다. 즉 “아무 CSV나 넣으면 된다”는 식은 아니다 (출처: Kronos-small 모델 카드).

pip install -r requirements.txt

from model import Kronos, KronosTokenizer, KronosPredictor

tokenizer = KronosTokenizer.from_pretrained("NeoQuasar/Kronos-Tokenizer-base")
model = Kronos.from_pretrained("NeoQuasar/Kronos-small")
predictor = KronosPredictor(model, tokenizer, max_context=512)

첫 예측 흐름은 짧지만, 데이터 정합성은 중요하다

x_df = df.loc[:lookback-1, ["open", "high", "low", "close", "volume", "amount"]]
x_timestamp = df.loc[:lookback-1, "timestamps"]
y_timestamp = df.loc[lookback:lookback+pred_len-1, "timestamps"]

pred_df = predictor.predict(
    df=x_df,
    x_timestamp=x_timestamp,
    y_timestamp=y_timestamp,
    pred_len=pred_len,
    T=1.0,
    top_p=0.9,
    sample_count=1,
)

StepGuide로 줄이면 아래 순서다.

배치 예측에는 추가 제약이 붙는다

공식 README는 predict_batch도 제공하지만 조건이 까다롭다. 모든 시계열이 같은 과거 길이, 같은 예측 길이를 가져야 하고 필수 컬럼도 동일해야 한다. 여러 자산을 한꺼번에 돌린다고 해서 완전히 자유로운 멀티자산 추론은 아니라는 얘기다 (출처: Kronos GitHub).

Chronos·TimesFM·Moirai·TimeGPT와 무엇이 다른가?

이제 중요한 비교다. Kronos가 좋은지 아닌지는 절대값보다 “무슨 상황에서 누구 대신 쓰는가”로 보는 편이 훨씬 정확하다.

범용성보다 금융 특화가 필요하면 Kronos 쪽이다

표를 한 줄로 읽으면 이렇다. 금융 캔들스틱 자체가 핵심 문제면 Kronos, 더 범용적인 제로샷/운영성은 Chronos, 긴 문맥과 생태계는 TimesFM, 불규칙 시계열과 다변량은 Moirai, 운영 부담을 줄이려면 TimeGPT 쪽이다 (출처: Kronos-small 모델 카드, Chronos GitHub, TimesFM GitHub, Moirai 공식 소개, TimeGPT 소개).

TimesFM과 Kronos는 특히 결이 다르다

TimesFM 2.5는 200M 파라미터에 16k 컨텍스트, XReg 지원까지 갖췄다. 이건 “더 많은 종류의 시계열을 길게 읽는 범용 모델”의 진화다. 반면 Kronos는 작은 공개 모델, 짧은 컨텍스트, 그러나 금융 데이터 전용 토크나이저라는 전혀 다른 선택을 한다. 어느 쪽이 낫다기보다 문제 정의가 다르다 (출처: TimesFM GitHub, Kronos-small 모델 카드).

관리형 서비스가 필요하면 TimeGPT가 더 현실적일 수 있다

Kronos는 오픈 가중치와 저장소 중심 프로젝트다. 반대로 TimeGPT는 API, 이상 탐지, 자체 인프라 배포, Azure 경로까지 문서가 이어진다. 팀이 모델 자체보다 “빨리 붙여서 운영”을 원한다면 TimeGPT 같은 관리형 경로가 더 현실적인 경우도 많다. 이 점은 기사에서 솔직히 적는 편이 오히려 신뢰를 준다 (출처: TimeGPT 소개).

이걸 바로 트레이딩에 써도 되는가?

짧게 답하면 아니다. 적어도 공식 문서를 기준으로는 “곧바로 실거래에 붙여도 되는 모델”이라는 표현을 쓸 수 없다.

공식 README부터 데모용이라고 선을 긋는다

파인튜닝 섹션을 보면 README 자체가 이 파이프라인은 데모용이며, 견고한 퀀트 전략에는 포트폴리오 최적화, 리스크 팩터 중립화, 동적 포지션 사이징, 거래 비용과 슬리피지 모델링이 더 필요하다고 적는다. 이건 굉장히 중요한 문장이다. 많은 AI 글이 이런 대목을 뒤로 미루는데, Kronos는 오히려 공식 문서가 먼저 경고한다 (출처: Kronos GitHub).

라이브 데모는 예측 시각화이지 트레이딩 시스템 증명이 아니다

공개 데모는 BTC/USDT 24시간 예측을 Monte Carlo 샘플링과 함께 보여준다. 보기에는 그럴듯하지만, 이것이 매매 시스템의 기대수익이나 손실 통제를 증명하지는 않는다. 실전은 호가, 체결, 레버리지, 거래소 수수료, 포지션 관리가 붙는다. 데모는 “예측이 어떤 모양으로 나오는가”를 보여주는 창이지, “이대로 돈을 벌 수 있는가”를 검증한 창이 아니다 (출처: Kronos Live Demo).

그래도 가치가 사라지는 것은 아니다

이 말이 “Kronos는 쓸모없다”는 뜻은 아니다. 금융 특화 시계열 표현 학습, 변동성 예측, 합성 데이터 생성, 스트레스 테스트 보강 같은 용도는 충분히 흥미롭다. 특히 기존 규칙 기반 백테스트가 보기 힘든 패턴을 보강하는 연구용 도구로는 매력적이다. 다만 이때도 모델 하나만 믿기보다 별도 평가 하네스가 필요하다.

라이선스와 상업 사용은 어떻게 읽어야 하나?

이 부분은 surprisingly 괜찮으면서도, 동시에 비어 있는 부분이 있다.

공개된 모델은 MIT 라이선스다

Hugging Face 모델 카드와 공식 저장소 문서는 모두 MIT 라이선스를 적고 있다. 즉 공개된 mini, small, base는 상업적 이용이 가능한 오픈소스 프로젝트로 읽으면 된다. “돈 받고 써도 되는가”라는 질문에는 현재 공개 범위에 한해 그렇다고 답할 수 있다 (출처: Kronos-small 모델 카드).

하지만 사람들이 진짜 궁금한 large는 아직 열려 있지 않다

문제는 Kronos-large다. 문서에는 존재하지만 공개 가중치는 없다. 그래서 커뮤니티에서는 상업용 라이선스 문의, 접근 요청, 실제 운영 사례 공유가 계속 올라온다. 이건 “공개된 작은 모델은 써도 되지만, 더 큰 모델 접근 정책은 아직 별도”라는 신호로 읽는 편이 안전하다 (출처: Issue #273).

법무와 보안 검토는 별도로 남는다

체크한 공식 소스는 MIT 라이선스와 모델 사용법은 설명하지만, 학습 데이터 권리 구조나 라이브 데모의 데이터 보존 정책을 길게 설명하지는 않는다. 즉 “오픈소스니까 법무 검토가 필요 없다”는 뜻은 아니다. 특히 금융 서비스로 들어가면 이 부분은 팀 차원의 별도 검토가 필요하다.

지금 도입할 만한 사람은 누구인가?

여기서부터는 실무 판단이다. 모든 사람에게 추천할 모델은 아니다.

지금 봐야 하는 사람

• 금융 OHLCV 중심으로 자체 예측 실험을 돌리는 퀀트 연구자
• 범용 TSFM보다 금융 특화 표현 학습이 궁금한 ML 엔지니어
• 오픈 가중치 기반으로 작은 연구용 프로토타입을 빨리 검증하려는 팀

조금 더 기다려야 하는 사람

• 실거래 PnL 책임이 바로 붙는 운영 팀
• 긴 컨텍스트나 다변량 공변량이 핵심인 시계열 시스템
• 모델 카드보다 관리형 API, SLA, 엔터프라이즈 지원이 먼저 필요한 조직

범용 프런티어 모델 감각이 더 궁금하다면 GPT-5.5 총정리: 성능·벤치마크·가격·반응 (2026), 로컬 GPU에서 모델을 굴리는 현실감이 궁금하다면 RTX 4090에서 직접 돌려본 로컬 코딩 에이전트 후기 — Qwen 3.6 27B (2026)도 함께 읽어둘 만하다.

FAQ: Kronos에 대해 자주 묻는 질문은?

결론: 지금 읽어야 할 한 줄은?