Subquadratic: Efficiency is Intelligence

포비·2026년 5월 7일

알아보자

목록 보기
104/111

긴 컨텍스트 LLM의 병목을 정면으로 건드린 SubQ 이야기

들어가며

요즘 LLM을 실제 서비스에 붙이다 보면 자주 마주치는 문제가 있다.

모델이 똑똑한 것과 별개로, 넣을 수 있는 정보의 양에는 한계가 있다. 코드베이스 전체, 수개월치 PR 기록, 긴 계약서 묶음, 연구 논문 수십 편, 장기 대화 기록을 한 번에 넣고 싶어도 현실에서는 비용과 속도가 먼저 막힌다.

그래서 지금까지 많은 AI 시스템은 RAG, 벡터 DB, 문서 chunking, 요약, 검색, agent orchestration 같은 우회로를 만들어왔다. 문제는 이 우회로들이 꽤 복잡하고, 때로는 중요한 맥락을 놓친다는 점이다.

이 지점에서 등장한 회사가 Subquadratic이고, 이들이 공개한 모델이 SubQ다.

Subquadratic의 슬로건은 “Efficiency is intelligence”다. 효율이 단순한 최적화가 아니라, 더 큰 지능을 가능하게 하는 조건이라는 뜻으로 읽힌다.

Subquadratic은 무엇을 만들고 있나

Subquadratic은 긴 컨텍스트 작업을 위한 새로운 LLM 아키텍처를 만들고 있다고 주장하는 AI 연구 및 인프라 회사다.

공식 홈페이지에서 SubQ는 다음과 같은 특징을 내세운다.

  • 12M 토큰 reasoning
  • 150 tokens per second
  • 주요 LLM 대비 약 1/5 비용
  • Subquadratic sparse-attention architecture
  • API 제공
  • SubQ Code 제공
  • OpenAI-compatible endpoints 지원
  • Streaming과 tool use 지원

핵심 메시지는 간단하다.

기존 Transformer 기반 모델은 입력 길이가 길어질수록 attention 계산 비용이 급격히 커진다. SubQ는 이 문제를 모델 구조 차원에서 바꾸겠다는 것이다.

왜 “Subquadratic”이 중요한가

Transformer의 self-attention은 기본적으로 각 토큰이 다른 모든 토큰과 관계를 계산한다.

입력 토큰이 1,000개라면 토큰 간 비교는 대략 1,000 x 1,000 규모가 된다. 입력이 2배가 되면 계산량은 단순히 2배가 아니라 약 4배로 증가한다. 이것이 흔히 말하는 O(n²), 즉 quadratic scaling 문제다.

짧은 문장이나 일반적인 채팅에서는 큰 문제가 아닐 수 있다. 하지만 컨텍스트가 수십만, 수백만 토큰으로 커지면 이야기가 달라진다.

긴 컨텍스트에서 quadratic attention은 다음과 같은 문제를 만든다.

  1. 입력 처리 비용이 빠르게 증가한다.
  2. 응답 전 대기 시간이 길어진다.
  3. 전체 문서를 넣는 대신 일부만 검색해서 넣는 구조가 필요해진다.
  4. 검색, 요약, chunking 과정에서 중요한 맥락이 손실될 수 있다.
  5. agent가 여러 번 호출되면서 오류가 누적될 수 있다.

Subquadratic이 노리는 지점은 바로 이 병목이다.

“모든 토큰 쌍을 다 계산할 필요가 없다면, 정말 중요한 관계만 골라서 계산할 수 있지 않을까?”

SubQ의 주장은 여기서 출발한다.

SSA: Subquadratic Sparse Attention

Subquadratic은 SubQ의 핵심 기술로 SSA를 소개한다.

SSA는 Subquadratic Sparse Attention 또는 Subquadratic Selective Attention으로 설명된다. 공식 기술 글에서는 SSA가 긴 컨텍스트 검색, 추론, 소프트웨어 엔지니어링 작업을 위해 설계된 선형 확장 attention 메커니즘이라고 설명한다.

기존 dense attention은 모든 토큰 쌍을 비교한다. 반면 SSA는 각 query가 실제로 봐야 할 중요한 위치를 content-dependent 방식으로 선택하고, 선택된 위치에 대해서만 attention을 계산한다고 설명된다.

여기서 중요한 점은 “고정 패턴”이 아니라는 것이다.

예를 들어 sliding window sparse attention은 가까운 주변 토큰만 보거나, 미리 정해진 간격의 토큰만 보는 식으로 계산량을 줄인다. 이런 방식은 빠를 수 있지만, 중요한 정보가 패턴 밖에 있으면 놓칠 수 있다.

SubQ가 강조하는 SSA의 차별점은 모델이 위치가 아니라 내용에 따라 어디를 볼지 결정한다는 점이다. 다시 말해, 관련 정보가 문서 앞쪽에 있든 뒤쪽에 있든 의미적으로 중요하다면 찾아가도록 설계했다는 주장이다.

정리하면 SSA가 노리는 세 가지는 다음과 같다.

  1. 긴 컨텍스트에서도 계산량과 메모리를 선형에 가깝게 유지한다.
  2. 위치가 아니라 내용 기반으로 중요한 토큰을 선택한다.
  3. 멀리 떨어진 정보도 검색하고 추론에 활용할 수 있게 한다.

이 주장이 실제로 안정적으로 검증된다면, 긴 컨텍스트 AI 시스템의 설계 방식이 크게 달라질 수 있다.

SubQ가 공개한 주요 수치

Subquadratic 공식 사이트와 기술 글에서 공개한 대표 수치는 다음과 같다.

항목공개된 내용
컨텍스트12M token reasoning
속도150 tokens per second
비용주요 LLM 대비 약 1/5
아키텍처Fully sub-quadratic sparse-attention architecture
12M 토큰 기준attention compute 거의 1,000배 감소 주장
1M 토큰 기준dense attention 대비 52.2배 prefill speedup 주장
RULER @ 128KSubQ 1M-Preview 95.0%
MRCR v2 8-needle 1MSubQ 1M-Preview 65.9%
SWE-Bench VerifiedSubQ 1M-Preview 81.8%

이 숫자들이 주목받는 이유는 단순히 “컨텍스트가 크다”가 아니라, “긴 컨텍스트를 더 싸고 빠르게 처리하면서도 benchmark 성능을 유지한다”는 주장에 있다.

LLM에서 긴 컨텍스트는 단순한 스펙 경쟁이 아니다.

컨텍스트 창이 크더라도 모델이 그 안의 정보를 제대로 찾고 연결하지 못하면 의미가 없다. 그래서 중요한 것은 nominal context window가 아니라 functional context window다.

  • Nominal context window: 모델이 입력으로 받을 수 있다고 광고하는 최대 토큰 수
  • Functional context window: 모델이 실제로 안정적으로 검색하고 추론할 수 있는 토큰 범위

SubQ가 진짜로 증명해야 하는 부분은 후자다.

RULER, MRCR, SWE-Bench Verified는 무엇을 보는가

SubQ가 공개한 benchmark를 이해하려면 각 benchmark가 무엇을 평가하는지 알아야 한다.

RULER

RULER는 긴 컨텍스트 모델이 단순히 “needle-in-a-haystack”처럼 한 가지 정보를 찾는 능력만 보는 것이 아니라, multi-hop retrieval, aggregation, variable tracking, selective filtering 같은 더 복잡한 long-context 행동을 평가하기 위해 만들어진 benchmark다.

즉, 긴 문서 안에서 필요한 정보를 찾고, 여러 정보를 연결하고, 조건에 따라 걸러내는 능력을 본다.

SubQ는 RULER @ 128K에서 95.0%를 기록했다고 공개했다.

MRCR v2

MRCR v2는 긴 컨텍스트 안에 흩어진 여러 근거를 찾아 연결하는 능력을 평가하는 benchmark로 설명된다.

단순히 하나의 사실을 찾는 것이 아니라, 여러 위치에 흩어진 정보를 종합해야 하므로 실제 업무에 더 가까운 긴 컨텍스트 테스트라고 볼 수 있다.

SubQ는 MRCR v2 8-needle 1M 설정에서 65.9%를 기록했다고 공개했다.

SWE-Bench Verified

SWE-Bench Verified는 실제 GitHub issue를 바탕으로 모델이 코드베이스를 이해하고 문제를 해결하는 patch를 만들 수 있는지 평가하는 benchmark다.

SubQ는 SWE-Bench Verified에서 81.8%를 기록했다고 공개했다.

이 수치는 코딩 agent나 코드베이스 분석 도구 관점에서 특히 중요하다. 긴 코드베이스 전체를 한 번에 보고 추론할 수 있다면, 기존의 파일 검색, 요약, 여러 agent 호출에 의존하던 방식이 줄어들 수 있기 때문이다.

SubQ가 바꾸려는 개발 경험

Subquadratic이 내세우는 대표 사용 사례는 코드다.

공식 사이트는 SubQ Code를 “coding agents를 위한 long-context layer”로 설명한다. Claude Code, Codex, Cursor 같은 환경에 연결해 코드베이스를 매핑하고, 많은 토큰을 요구하는 질문에 더 빠르게 답하도록 돕는 구조다.

현재 대규모 코드베이스에서 AI를 활용할 때 흔한 흐름은 이렇다.

  1. 관련 파일을 검색한다.
  2. 필요한 부분만 잘라 prompt에 넣는다.
  3. 모델이 답변한다.
  4. 부족하면 다시 검색한다.
  5. 여러 번 반복하면서 context를 보강한다.

이 방식은 현실적이지만 한계도 있다.

검색이 잘못되면 중요한 파일이 빠지고, 요약 과정에서 인터페이스나 제약 조건이 손실될 수 있다. 여러 번 호출하면 각 호출 사이에 맥락이 압축되거나 왜곡된다.

SubQ가 주장하는 접근은 다르다.

가능하면 코드베이스 전체, PR 기록, 장기 작업 상태를 하나의 큰 context 안에 넣고 모델이 직접 추론하게 하자는 것이다.

이게 가능해지면 개발자는 다음과 같은 질문을 더 자연스럽게 던질 수 있다.

  • 이 저장소 전체에서 인증 로직이 어떻게 흐르는가?
  • 이 변경이 어떤 테스트와 모듈에 영향을 줄 수 있는가?
  • 최근 6개월 동안 이 기능과 관련된 PR은 어떤 방향으로 바뀌었는가?
  • 이 버그는 단일 파일 문제가 아니라 구조적 문제인가?
  • 기존 설계 철학을 깨지 않고 수정하려면 어디를 건드려야 하는가?

이런 질문은 단일 파일이나 짧은 snippet만으로는 답하기 어렵다. 긴 컨텍스트가 실제로 잘 작동한다면, AI coding assistant의 사용 방식 자체가 달라질 수 있다.

RAG를 대체할 수 있을까

SubQ의 메시지를 보면 “RAG가 필요 없어질 수 있다”는 인상을 받을 수 있다. 하지만 조금 더 신중하게 봐야 한다.

긴 컨텍스트 모델이 강력해지면 RAG의 필요성은 줄어들 수 있다. 특히 전체 문서나 전체 코드베이스를 한 번에 넣을 수 있다면, 검색으로 일부 chunk만 골라 넣는 방식의 약점은 줄어든다.

하지만 RAG가 완전히 사라진다고 단정하기는 어렵다.

RAG는 단순히 컨텍스트 창을 아끼기 위한 기술만은 아니다. 최신 데이터를 연결하고, 출처를 추적하고, 권한별 데이터 접근을 통제하고, 대규모 지식베이스에서 필요한 정보를 빠르게 찾는 역할도 한다.

따라서 더 현실적인 변화는 다음에 가깝다.

기존:
RAG가 모델의 부족한 context를 보완한다.

변화 가능성:
긴 컨텍스트 모델이 기본 추론을 담당하고, RAG는 최신성, 권한, 출처, 데이터 라우팅을 담당한다.

즉, SubQ 같은 모델이 성공하더라도 RAG가 완전히 사라진다기보다 역할이 바뀔 가능성이 크다.

왜 사람들이 기대하면서도 의심하는가

SubQ의 발표가 흥미로운 이유는 분명하다.

만약 SubQ가 주장하는 수치가 실제 서비스 환경에서도 재현된다면, 긴 컨텍스트 AI의 비용 구조가 바뀔 수 있다. 전체 코드베이스, 긴 문서 묶음, 장기 agent memory, 대규모 기업 데이터를 더 직접적으로 다룰 수 있게 된다.

하지만 동시에 조심해야 할 이유도 있다.

공식 기술 글은 comprehensive model card가 아직 공개 예정이라고 밝히고 있다. 공식 홈페이지에도 technical report가 coming soon으로 표시되어 있다. 즉, 현재 공개된 정보만으로는 학계나 외부 개발자가 완전히 재현 가능한 수준의 검증 자료가 충분하다고 보기는 어렵다.

VentureBeat 같은 외부 보도도 이 지점을 짚는다. SubQ의 수치가 매우 인상적이지만, 공개된 benchmark는 아직 제한적이며, 일반 추론, 수학, 다국어, 안전성, 실제 API 환경에서의 독립 평가가 더 필요하다는 관점이다.

또한 긴 컨텍스트 benchmark는 평가 방식에 따라 결과가 달라질 수 있다. 같은 모델도 prompt 구성, 평가 harness, 캐시 정책, 하드웨어, batch size, 추론 설정에 따라 속도와 비용이 달라질 수 있다.

그래서 지금 SubQ를 볼 때 가장 안전한 태도는 이렇다.

“흥미로운 아키텍처 주장이다. 하지만 아직은 공개 model card, 기술 리포트, 외부 독립 평가가 더 필요하다.”

Subquadratic이 중요한 이유

그럼에도 Subquadratic이 중요한 이유는 문제 정의가 정확하기 때문이다.

현재 AI 제품 개발에서 많은 비용은 모델 자체의 지능 부족보다 context 관리에서 발생한다.

개발자는 문서를 쪼개고, 검색 파이프라인을 만들고, vector DB를 튜닝하고, 관련 context를 고르고, agent 사이의 상태를 이어 붙인다. 이 과정은 필요하지만 복잡하다. 그리고 복잡한 시스템은 실패 지점도 많다.

Subquadratic은 이 문제를 “더 좋은 검색”이 아니라 “더 효율적인 모델 구조”로 풀겠다고 말한다.

이 관점은 의미가 있다.

AI 시스템의 다음 단계가 더 긴 작업, 더 긴 기억, 더 큰 코드베이스, 더 복잡한 기업 데이터라면, context를 다루는 능력은 단순한 부가 기능이 아니라 핵심 경쟁력이 된다.

효율이 좋아지면 같은 비용으로 더 많은 정보를 볼 수 있다.
더 많은 정보를 안정적으로 볼 수 있으면 더 깊은 추론이 가능해진다.
그래서 “Efficiency is intelligence”라는 문장은 단순한 마케팅 문구가 아니라, 긴 컨텍스트 AI 시대의 중요한 방향성을 담고 있다.

개인적인 해석

SubQ가 정말로 성공한다면 가장 먼저 영향을 받을 영역은 coding agent와 enterprise AI일 가능성이 크다.

특히 코드베이스 분석은 긴 컨텍스트의 가치가 바로 드러나는 분야다. 코드에는 함수 정의, 타입, 테스트, 설정, 히스토리, 문서, PR 논의가 서로 얽혀 있다. 일부 파일만 보고 답하면 그럴듯하지만 틀린 답이 나오기 쉽다.

긴 컨텍스트 모델이 전체 구조를 한 번에 볼 수 있다면 다음과 같은 변화가 가능하다.

  • 대규모 리팩토링 계획 수립
  • 저장소 전체 dependency 분석
  • 테스트 영향 범위 추정
  • 오래된 PR과 현재 코드의 관계 파악
  • 장기 작업 상태 유지
  • agent 간 coordination 비용 감소

반면 법률, 금융, 의료, 보안 같은 고위험 영역에서는 단순히 긴 문서를 넣을 수 있다는 것만으로 충분하지 않다. 출처 추적, 검증 가능성, 접근 권한, privacy, audit log가 함께 필요하다.

즉, SubQ의 기술이 실제로 강력하더라도 제품화의 핵심은 “긴 컨텍스트를 얼마나 책임 있게 다루는가”가 될 것이다.

정리

Subquadratic의 SubQ는 기존 Transformer의 quadratic attention 병목을 정면으로 겨냥한 모델이다.

공식 발표에 따르면 SubQ는 12M 토큰 reasoning, 선형에 가까운 attention scaling, 1M 토큰에서 52.2배 prefill speedup, RULER와 MRCR, SWE-Bench Verified에서 경쟁력 있는 결과를 내세운다.

이 주장이 사실이라면 긴 컨텍스트 AI의 경제성이 크게 바뀔 수 있다. RAG, chunking, multi-agent orchestration 중심의 현재 AI 시스템 설계가 더 단순해질 가능성도 있다.

하지만 아직은 신중해야 한다. 기술 리포트와 종합 model card가 공개 예정이고, 외부 독립 평가가 더 필요하다. 지금 단계에서 SubQ는 “검증이 끝난 표준”이라기보다 “긴 컨텍스트 AI의 방향을 바꿀 수 있는 흥미로운 후보”에 가깝다.

그럼에도 이 프로젝트는 볼 가치가 있다.

LLM의 발전이 단순히 더 큰 모델, 더 많은 파라미터, 더 비싼 추론으로만 이어지는 것이 아니라, 더 효율적인 구조를 통해 더 넓은 맥락을 다루는 방향으로 갈 수 있음을 보여주기 때문이다.

긴 컨텍스트가 AI 제품의 핵심이 되는 시대라면, Subquadratic이 던진 질문은 꽤 중요하다.

“정말 모든 토큰이 모든 토큰을 봐야 할까?”

이 질문에 대한 답이 바뀌면, 우리가 AI 시스템을 설계하는 방식도 바뀔 수 있다.

근데 약간 사기느낌 나긴하는데 모르겠다 싼데 빠르다? 솔직히 말도안될것같긴함;;

참고자료

profile
무엇이든 필요한 것을 합니다. https://mint-middle-1e5.notion.site/2b7655e8316980ad9422d96a6f3947de

0개의 댓글