3줄 요약

  1. Sebastian Raschka가 2026년 9월 9일 자신의 매거진 Ahead of AI에 새 글을 올렸다. GPT-6 Astra를 써 본 소감과 루프 트랜스포머 해설, 그리고 이 주제의 최신 논문 정리를 한 편으로 묶었다.
  2. 발표 이틀 전 The Information은 내부 정보를 인용해 Astra가 순환 깊이(recurrent depth), 곧 루프 트랜스포머를 쓰고 있으며 이것이 추론 흔적을 흐린다고 보도했다. Raschka는 Astra가 루프 구조를 쓸 가능성은 높다고 보면서도, 루프가 사고 사슬을 감추는 원인이라는 해석에는 반대한다. OpenAI 수석 과학자 야쿠프 파호츠키도 같은 취지로 해명을 내놓았다.
  3. 루프 트랜스포머는 중간 표현을 같은 트랜스포머 블록에 여러 번 통과시켜 유효 깊이를 늘리는 기법이다. 가중치를 공유하므로 파라미터와 가중치 메모리는 줄어든다. 그러나 계산량과 KV 캐시 요구량은 블록을 그만큼 더 쌓은 모델과 같다. 9월에 나온 SMELT 논문은 계산량과 파라미터, KV 캐시를 모두 맞춰 놓고 비교했을 때 루프 쪽이 같은 검증 손실에 도달하는 데 학습 계산을 6.8%에서 18%가량 덜 쓴다고 추정했다.

Astra를 며칠 써 본 소감

Raschka는 Astra를 지금까지 자기가 써 본 모델 가운데 가장 좋은 모델이라고 평가했다. 글쓰기와 수학, 코딩을 포함해 거의 모든 항목에서 전작 GPT-5.6을 앞서지만, 그중에서도 3D 렌더링과 애니메이션 같은 그래픽 작업에서 격차가 유난히 크다고 한다.

코딩 벤치마크 세 종과 난이도 높은 수학 벤치마크 하나에서의 GPT-6 Astra 성적 그림 1. 인기 있는 코딩 벤치마크 세 종과 어려운 수학 벤치마크 하나를 골라 비교한 결과. 출처: Sebastian Raschka, Ahead of AI

그림에 들어가지 않은 성적으로 ARC-AGI-3이 있다. Astra는 99.9%를 기록했고 GPT-5.6 Sol은 7.8%에 그쳤다. 그래도 Raschka는 실제 쓰임에 더 가깝다는 이유로 수학과 코딩, 컴퓨터 사용 쪽 벤치마크를 더 눈여겨본다고 적었다.

여러 에이전트 코딩 과제를 섞어 매기는 Artificial Analysis Coding Agent Index v1.4에서 Astra는 분명히 최전선에 있지만 다른 모델을 크게 따돌리지는 못한다. 코딩만이 아니라 여러 종류의 과제를 섞는 Artificial Analysis Intelligence Index에서도 마찬가지다. Raschka는 이 지표들의 장점으로 독립성을 들었다. 모델 개발사가 스스로 매긴 점수보다 조금 더 믿을 만하다고 봤다.

여기에 그가 덧붙인 단서가 하나 있다. 하니스 구성이 벤치마크마다 다르다는 점이다. GDPval-AA와 AA-Briefcase는 Artificial Analysis가 만든 최소한의 오픈소스 하니스 Stirrup을 여러 모델에 똑같이 씌운다. 반면 Intelligence Index v4.2 안에서도 Terminal-Bench v2.1은 Terminus 2를 쓰고 τ³-Banking은 τ-Bench 하니스를 쓴다. 하니스를 공유하면 조건은 같아진다. 그런데 모델은 보통 하나의 주된 하니스를 염두에 두고 학습되고, 그 하니스도 모델의 강점을 살리도록 설계된다. 이 때문에 일부 에이전트 평가는 Astra가 주로 쓰는 하니스에서 보이는 실력을 과소평가할 수 있다고 그는 본다.

지나가는 말로 적힌 제안 하나도 눈에 띈다. 동료가 권했고 Claude Code 책임자도 추천했다는 이야기라며, 기존 AGENTS.md 내용과 SKILL.md 파일 일부를 지우거나 보관용으로 옮겨 두는 편이 나쁘지 않다고 했다. 이유는 이렇다. 새 모델은 프롬프트를 이해하고 문제를 푸는 데 이미 능숙해졌다. 그런 모델에게 하나하나 손을 잡아 끄는 설명을 붙이면 도리어 운신을 좁혀 더 나쁜 답이 나올 수 있다. 물론 다시 쓸 때의 효율 때문에 설명 파일이 여전히 쓸모 있는 작업 흐름도 있다고 그는 덧붙였다. 그가 말하려는 것은 낡은 설명을 갱신하거나 새로 만들 때가 됐다는 말에 가깝다.

맥 미니 수만 대는 무엇을 하고 있는가

Astra가 특히 강한 이미지와 렌더링 작업은 그래픽 사용자 인터페이스를 다루는 일과 자주 맞물린다. Raschka는 Astra Medium과 High에게 브라우저판 MS 페인트를 마우스로 조작해 자기 사진을 다시 그리게 하는 비교를 실었다. 토큰을 다 써 버리기 싫어서 Extra High와 Max는 돌리지 않았다고 한다.

하니스 안에서 컴퓨터를 다루는 모델이 이번이 처음은 아니다. 그도 올해 초부터 엑셀 경비 처리 같은 인터페이스 작업에 GPT 모델을 써 왔다. 그래도 컴퓨터 사용은 비교적 새 능력이고 아직 덜 익은 느낌이 남아 있다. 그는 이것이 당연하다고 본다. 언어 모델은 텍스트 모델이니 글쓰기와 코딩, API와 명령줄 사용이 먼저 익기 마련이다. 그러나 아직 명령줄을 내주지 않는 도구와 소프트웨어가 많고, 누군가 그 인터페이스를 설계해 줄 때까지 기다릴 이유는 없다. 그는 이 상황을 휴머노이드 로봇에 견주었다. 조립 라인에서 휴머노이드는 전용 기계보다 비효율적이지만 대신 다재다능하다.

OpenAI가 강화학습용으로 맥 미니와 맥 스튜디오를 수만 대 사들였다는 보도가 나온 적이 있다. 이 흐름과 나란히 놓으면 앞뒤가 맞는다. 모델을 실제로 학습시키는 계산은 GPU가 맡고, 맥은 학습이 진행되는 동안 모델이 직접 조작해 보는 운영체제 환경 노릇을 한다. 학습 절차는 이렇게 이어진다.

  1. “앱 xyz를 열고 abc를 하라” 같은 과제를 모델에게 준다.
  2. macOS 화면 스크린샷을 준다. 보통 하니스가 맡는 일이다.
  3. 모델이 마우스와 키보드 동작을 예측한다. 클릭, 키 입력, 스크롤 같은 것들이다.
  4. 그 동작을 맥에서 실행한다. 이것도 하니스가 한다.
  5. 동작 뒤 바뀐 화면을 다시 스크린샷으로 준다.
  6. 과제가 성공하거나 실패할 때까지 2번부터 5번을 되풀이한다.
  7. 성공과 실패 신호, 그리고 검증기를 학습 피드백으로 쓴다. 검증 가능한 보상을 쓰는 일반적인 강화학습(RLVR)과 같은 얼개다.

컴퓨터 사용 학습 절차 개요도 그림 2. 컴퓨터 사용 학습 흐름. 출처: Sebastian Raschka, Ahead of AI

모델은 엔비디아 GPU 위에 얹혀 있고 API를 통해 맥에 연결된다. 엔비디아 CEO는 Astra가 약 10만 개의 그레이스 블랙웰 GPU에서 학습됐다고 언급했다.

Raschka는 앞으로 몇 달 동안 컴퓨터 사용이 오픈소스와 상용 하니스 양쪽 모두의 다음 초점이 될 것으로 본다. 그중에서도 오픈소스 쪽을 중요하게 여기는데, 자기 주력 컴퓨터에 접근 권한을 내주기 전에 하니스를 직접 감사할 수 있어야 한다는 이유에서다.

루프 트랜스포머는 무엇을 되풀이하는가

모델 공개 이틀 전, The Information은 내부 정보를 인용해 Astra가 순환 깊이 또는 루프 트랜스포머라는 개념을 쓴다고 보도했다. Raschka는 언어 모델 아키텍처가 자기 전문 분야이자 오랜 관심사라며, 루프 트랜스포머 기제를 처음부터 풀어 주는 짧은 강의 영상을 따로 만들어 글에 함께 걸었다.

루프 트랜스포머는 아키텍처를 조금 손본 방식이다. 중간 표현을 같은 트랜스포머 블록에 한 번만 통과시키는 대신 여러 번 되풀이해 통과시킨다. 블록을 더 쌓는 쪽과 무엇이 다른가 하면, 이 통과들 사이에 가중치가 그대로 유지된다.

글에서 쓰는 용어 세 가지를 그가 먼저 정리해 두었다. 트랜스포머 블록은 어텐션과 피드포워드 모듈, 정규화, 지름길 연결을 담은 단위다. 논문에서는 흔히 “트랜스포머 층"이라고 부른다. 스택은 트랜스포머 블록의 나열이다. 블록 적용은 입력을 트랜스포머 블록에 한 번 통과시키는 일을 뜻한다.

이 발상 자체는 새롭지 않다. 2018년 Universal Transformers 논문에 이미 기본 골자가 있다. 그래도 설명은 더 간단한 최근 사례에서 출발한다. 7월에 나온 오픈웨이트 모델 Nanbeige4.2-3B다.

Nanbeige는 겉보기에 평범한 트랜스포머인데, 스택 맨 위에서 맨 아래로 돌아가는 주황색 화살표가 하나 더 있다. 입력 텍스트가 토큰이 되어 임베딩 벡터로 바뀌고, 각자 자기 가중치를 가진 22개 블록을 지난다. 여기까지는 다른 모델과 같다. 그다음이 다르다. 첫 통과가 끝난 은닉 상태가 같은 22개 블록으로 되돌아가 블록 1부터 다시 지난다.

Nanbeige4.2-3B를 두 번의 통과로 펼친 그림 그림 3. Nanbeige4.2-3B를 펼치면 같은 22개 블록을 두 번 지나 44번의 블록 적용이 된다. 출처: Sebastian Raschka, Ahead of AI

계산을 펼쳐 보면 블록 적용이 44번이다. 그런데 서로 다른 44개 블록을 가진 재래식 트랜스포머와 달리, 두 번째 22번은 첫 번째의 가중치를 다시 쓴다. 23번째 블록 적용은 블록 1의 가중치를, 24번째는 블록 2의 가중치를 쓰는 식이다. 가중치 한 벌을 더 두지 않고 유효 깊이만 22에서 44로 늘리는 셈이다.

그런데 왜 하필 두 바퀴일까. Nanbeige 논문에 자세한 설명은 없지만, 두 번이 가장 효율적인 구성이었다고 적혀 있다. 두 번에서 세 번으로 늘리면 성능은 오르되 추가 계산 비용이 그만큼의 값을 하지 못했다고 한다.

무엇을 아끼고 무엇을 아끼지 못하는가

22개 블록을 두 번 쓰는 모델은 44개 블록을 가진 모델보다 트랜스포머 블록 파라미터가 대략 절반이다. 가중치를 저장하는 메모리가 그만큼 줄어든다. 여기서 임베딩 층과 출력 층은 논외다. 이 둘은 보통 크고 전체에서 상당한 몫을 차지한다. Nanbeige4.2-3B에서는 30억 파라미터 가운데 25%가량이 여기에 해당하고, 두 층이 가중치를 공유하면 12.5%까지 줄일 수 있다.

재래식 구성과 루프 구성의 파라미터 수 비교 그림 4. 같은 유효 깊이를 재래식으로 만들 때와 루프로 만들 때 필요한 파라미터 수. 출처: Sebastian Raschka, Ahead of AI

루프가 아껴 주지 못하는 것도 두 가지 있다. 첫째는 계산이다. 순전파에서 중간 입력은 어차피 44번의 블록 적용을 지나고, 학습 중 기울기도 공유 스택의 두 반복을 모두 거슬러 흐른다. 옵티마이저가 갱신할 파라미터 수는 줄지만 역전파는 44번의 블록 적용을 전부 통과한다. 그러니 계산 비용은 서로 다른 44개 블록을 두는 것과 비슷하다.

둘째는 KV 캐시다. 가중치를 공유해도 두 번째 통과에서 블록에 들어가는 중간 상태는 첫 번째와 다르다. 그러니 거기서 나오는 키와 값도 다르다. 블록 적용 1번과 23번은 같은 블록 1의 가중치를 쓰지만 각자의 캐시 항목이 따로 필요하다. 결과적으로 22개 블록을 두 번 쓰는 구성의 KV 캐시 요구량은 서로 다른 44개 블록을 가진 모델과 같다. Nanbeige 연구진도 두 통과 사이에 KV 캐시를 공유해 봤다고 한다. 캐시 크기는 절반이 됐지만 모델 성능이 떨어져, 캐시를 따로 두는 쪽을 공개했다.

기술 보고서에는 선택 두 가지가 더 적혀 있다. 하나는 사전학습이 끝난 트랜스포머를 개조하기보다 루프 구조를 처음부터 학습시키는 편이 나았다는 기록이다. 또 하나는 통과 횟수를 늘려 봐야 이득은 조금뿐인데 학습이 느려지고 최적화가 불안정해졌다는 관찰이다.

몇 바퀴를 돌지는 누가 정하는가

Nanbeige는 통과 횟수를 두 번으로 고정했다. 그러나 토큰마다 다르게 정할 수도 있다.

2018년 Universal Transformers는 블록 스택 대신 트랜스포머 블록 하나를 되풀이 적용한다. 여기서는 적응적 정지(adaptive halting)를 살펴본다. 어떤 위치의 토큰은 한두 바퀴만 돌고, 어떤 토큰은 서너 바퀴를 돈다. 계산이 더 필요한 토큰에 계산을 몰아 주자는 발상이다. 방법은 이렇다. 작은 학습 함수가 각 단계마다 위치별 정지 확률을 내놓는다. 바퀴를 돌 때마다 이 확률을 누적하다가 합이 문턱값을 넘으면 그 위치의 반복을 멈춘다. 혹시 몰라 최대 반복 횟수도 함께 걸어 둔다.

Universal Transformer의 적응적 정지 도식 그림 5. Universal Transformer의 적응적 정지. 출처: Sebastian Raschka, Ahead of AI

바이트댄스의 Ouro도 같은 계열이다. Ouro-Thinking 2.6B는 48개 블록으로 이루어진 스택을 네 번 적용한다. 블록 적용이 192번인데 저장하는 가중치는 48개 블록 분량이니 Nanbeige보다 극단적인 사례다. 학습된 출구 게이트가 각 출구에 확률을 매기고 누적 확률의 문턱으로 어느 통과가 최종 출력을 내놓을지 정한다. 실무적인 단서가 하나 붙는다. 공개된 허깅페이스 구현은 출력을 고르기 전에 설정된 통과를 전부 계산하므로, 실질적으로는 루프 수가 4로 고정된 것처럼 보인다고 한다.

2025년 Mixture-of-Recursions는 Universal Transformer를 더 정교하게 다듬은 후속 작업이다. 토큰마다 통과 횟수가 달라지는 것은 같은데, 그 횟수를 정하는 방법이 다르다. 논문 그림에서 되풀이되는 스택은 재귀 블록이라 불리고, 따로 떨어진 첫 블록과 마지막 블록 사이에 놓인다.

Mixture-of-Recursions의 두 가지 라우팅 방식 그림 6. 재귀 깊이를 정하는 두 방법. 왼쪽은 단계마다 어느 토큰을 계속 처리할지 고르고, 오른쪽은 하나의 라우터가 처음에 통과 횟수를 배정한다. Mixture-of-Recursions 논문 그림을 Raschka가 옮긴 것

여기서는 작은 학습 라우터가 결정을 맡는다. 전문가 혼합 모델의 라우팅과 비슷하다. 전문가 혼합 모델이 어느 전문가를 쓸지 고른다면, 여기서는 공유 스택을 몇 번 적용할지를 고른다. 라우터는 토큰의 은닉 표현을 보고 판단하고 그 표현에는 문맥 정보가 들어 있다. 그러니 같은 단어가 늘 같은 횟수를 배정받는 것은 아니다. 어디에 나왔는지, 앞에 무엇이 있었는지에 따라 결정이 달라진다.

논문은 두 가지 라우팅을 살펴본다. 전문가 선택(expert-choice) 방식에서는 재귀 단계마다 어떤 토큰을 처리할지 고르고, 빠져나온 토큰은 이후 단계에서 제외한다. 토큰 선택(token-choice) 방식에서는 라우터가 처음에 한 번 결정해 각 토큰을 한 번, 두 번, 세 번 통과 경로에 배정한다. 두 경우 모두 가중치는 통과들 사이에 공유되고, 유연함은 토큰마다 계산량을 다르게 주는 데서 나온다. 모델과 라우터는 함께 학습되므로 모델이 이 여러 경로를 쓰는 법을 학습 중에 익힌다.

모델 규모와 학습 계산 예산에 따른 검증 손실 비교 그림 7. 네 가지 모델 규모와 세 가지 학습 계산 예산에서의 검증 손실. Mixture-of-Recursions 논문 그림

결과를 보면 모델 규모에 따라 승부가 뒤집힌다. 가장 작은 규모에서는 평범한 트랜스포머가 제일 낫다. 모델이 커지면 Mixture-of-Recursions가 따라붙고 자주 앞선다. 학습 예산이 작을수록 특히 그렇다. 가장 큰 예산에서는 여러 곡선이 서로 가까워진다. 여기에 덧붙일 것이 하나 있다. 같은 학습 계산을 썼다고 처리한 토큰 수까지 같아지지는 않는다. 계산을 건너뛰는 덕분에 Mixture-of-Recursions는 같은 예산 안에서 더 많은 토큰을 처리할 수 있다.

Raschka가 이 사례를 좋아한 까닭은 규모가 얼마나 중요한지를 잘 보여 주기 때문이다. 1억 3500만 파라미터 모델만 보고 판단했다면 정반대의 결론을 냈을 것이라고 그는 적었다. 모델이 충분히 크면 루프 트랜스포머는 같은 계산 예산에서 모델 품질을 올려 준다.

RNN과 무엇이 다른가

깊은 신경망을 다뤄 본 사람이라면 이 되풀이가 낯익을 것이다. 순환 신경망(RNN)의 발상 자체가 앞 반복의 층과 가중치를 다시 쓰는 것이었다.

RNN의 순환과 루프 트랜스포머의 순환 비교 그림 8. RNN의 순환과 루프 트랜스포머의 순환을 나란히 놓은 비교. 출처: Sebastian Raschka, Ahead of AI

두 구조는 무엇을 축으로 되풀이하느냐에서 갈린다. RNN은 시간 단계를 가로질러 가중치를 다시 쓴다. 은닉 상태가 한 토큰에서 다음 토큰으로 실려 간다. 텍스트를 처리할 때 단어를 하나씩 읽고 앞선 단어의 정보를 은닉 상태에 담아 나른다. 루프 트랜스포머에서는 한 토큰의 중간 표현이 트랜스포머 스택을 여러 번 지난다. 되풀이가 아키텍처의 깊이를 따라 일어난다. 토큰들 사이의 정보 전달은 여전히 어텐션이 맡는다. 이 비유가 헷갈린다면 굳이 붙들지 않아도 된다고 Raschka는 적었다. 트랜스포머 블록을 다시 쓰는 방식이고, 가중치를 공유한 채 모델을 키운 것과 비슷하다고 생각하면 간단하다.

Astra는 정말 루프를 쓰는가

루프 트랜스포머가 추론 흔적을 흐리는지 따지려면 먼저 확인할 것이 있다. Astra가 정말 이 개념을 쓰고 있는가.

이것은 아직 소문이고 공식 확인이 없다. 오픈웨이트 모델이라면 직접 확인해 보면 되지만 지금은 검증되지 않은 보도에 기대야 한다. Raschka는 그래도 Astra가 루프 트랜스포머의 요소를 쓰고 있을 것으로 본다. 근거 세 가지를 들었다. 앞의 보도가 있고, 과거 연구에서 유망함을 보인 기법이며, 여기에 OpenAI 수석 과학자의 다음 발언이 더해진다.

Astra를 포함한 우리 현재 프론티어 모델의 계산 그래프 깊이는 GPT-4의 두 배 이내에 있다.

이 문장이 루프 아키텍처를 명시적으로 확인해 주지는 못한다. 재래식 블록을 두 배로 쌓았다는 뜻일 수도 있다. Raschka 자신의 견해로는 Astra의 성능을 만든 주된 원인이 개선된 학습 레시피와 학습 데이터 쪽이다. 루프라는 손질이 조금 도움이 됐을 수는 있어도, The Information이 그 기여를 과대평가하고 있다고 그는 덧붙였다.

루프가 사고 사슬을 감추는가

이제 미뤄 둔 질문을 다룰 차례다. 루프 트랜스포머가 추론 흔적을 흐리는가.

먼저 OpenAI는 o1 시절부터 추론 흔적 대부분을 사용자에게서 감춰 왔다. 최종 사용자 입장에서는 큰 차이가 없다는 뜻이다. 그러니 해석가능성 우려는 주로 모델 개발자 쪽 이야기다.

추론 모델은 최종 답 앞에 중간 단계를 만든다. 이 단계도 평범한 텍스트 토큰으로 되어 있고, 인터페이스에 따라 사용자에게 감춰지기도 한다. 합이 10이고 곱이 21인 두 수를 물으면 모델은 먼저 5와 5를 시도한다. 합은 맞지만 곱이 25다. 그다음 3과 7을 시도하고 두 조건을 다시 확인한다. 모델은 여전히 토큰을 하나씩 만들고 프롬프트와 앞선 토큰을 문맥으로 쓴다. 이 중간 단계가 연습장 노릇을 하면서 최종 답 앞에 계산을 보탠다.

논점은 여기서 갈린다. 추론 흔적의 토큰이 늘면 계산이 는다. 루프 트랜스포머도 토큰이 블록을 더 많이 지나므로 계산이 는다. 그러니 루프 안에서 계산을 더 쓰는 모델은 밖으로 내놓는 생각 토큰을 그만큼 덜 써도 된다고 주장할 수 있다.

실제 숫자는 어떤가. Astra가 GPT-5.6 Sol보다 노력 수준 전반에서 반드시 토큰을 적게 쓰지는 않는다. 그러나 정확도를 고정해 놓고 비교하면 Astra가 Sol보다 적게 쓰는 것은 맞다.

Raschka는 이것을 해석가능성 문제로 보지 않는다. 토큰을 적게 쓴다는 것은 모델이 더 유능해서 실수를 덜 하고 되짚기를 덜 한다는 뜻일 수 있다. 처음부터 더 많이 맞힌다는 말이 된다. 같은 논리가 이전 모델에도 적용된다.

Luna와 Sol의 비슷한 성능 구간에서의 토큰 사용량 그림 9. 비슷한 과제 성능 수준에서 Luna와 Sol이 쓰는 토큰 수. Artificial Intelligence Index v4.3의 수치

작은 모델인 GPT-5.6 Luna는 Sol과 비슷한 성능을 내면서 토큰을 80% 더 쓴다. 그렇다고 Sol이 Luna보다 그만큼 덜 해석 가능하다고 걱정하는 사람은 없다. 더 크고 잘 학습된 모델은 계산을 더 쓰는 대신 문제를 더 효율적으로 푼다. 그래서 토큰을 덜 쓴다는 설명이 더 그럴듯하다.

추론 흔적이 모델 안에서 일어나는 일을 충실히 옮긴다는 보장은 원래 없다. Raschka가 보기에 유효한 우려는 하나뿐이다. 루프 트랜스포머가 재래식 트랜스포머보다 더 자주 가짜 추론 흔적을 내보여 사용자를 일부러 오도하는 경우다. 그런 일이 벌어지고 있다는 강한 증거는 없다.

Astra의 시스템 카드도 추론 흔적의 감시 가능성이 떨어졌다고, Sol에 견주어 다소 후퇴했다고 적어 두었다. 그 후퇴는 흔적이 짧아지고 정보가 줄어든 것과 주로 맞물려 있다고 했다. 그러나 이것으로 루프가 원인이라고 말할 수는 없다. 앞의 Luna와 Sol 사례처럼 길이가 줄어든 일반적 효과일 수 있다.

Raschka가 루프 트랜스포머와 추론 흔적에 대한 생각을 공개하고 몇 시간 뒤, OpenAI 수석 과학자 야쿠프 파호츠키가 다음과 같이 해명을 내놓았다.

혼란스러운 보도가 촉발한 감시 불가능성으로의 경주를 막고 싶다. Astra를 포함한 우리 현재 프론티어 모델의 계산 그래프 깊이는 GPT-4의 두 배 이내에 있다. OpenAI는 첫 추론 모델부터 사고 사슬 감시를 보존하고 활용하려 노력해 왔다. 우리는 이 기법을 매우 중요하게 생각한다. 모델 정렬이 학습 분포 밖으로 어떻게 일반화되는지를 들여다볼 수 있게 해 주기 때문이다. 이 기법은 취약하고, 안타깝게도 나쁜 방향으로 가고 있다고 나는 생각한다. 그러나 그 이유는 아키텍처 변경과 무관하다. 곧 따로 쓰겠다. 그래도 이것을 강화하기 위해 할 수 있는 일이 있고, 그것이 우리 현재 연구 프로그램의 핵심 목표다.

여기서 말한 “혼란스러운 보도"가 The Information의 그 대목을 가리킬 것이라고 Raschka는 읽는다. 루프라는 요소는 사고 사슬 변화와 아무 관련이 없다는 뜻이 된다.

최근 논문 네 편

잠재 추론

2025년 논문 「Scaling up Test-Time Compute with Latent Reasoning: A Recurrent Depth Approach」는 모델이 추론 시점에 루프를 더 쓰는 방법을 연구했다. 35억 파라미터 모델을 8000억 토큰으로 학습시켰다.

Universal Transformer는 같은 블록 하나를 되풀이한다. 반면 이 모델은 Nanbeige처럼 스택을 되풀이한다. 공유 스택 네 블록은 앞쪽 두 블록과 뒤쪽 두 블록 사이에 넣는다. Nanbeige와 또 다른 점도 있다. 공유 스택은 매 루프 시작마다 앞선 루프의 은닉 상태와 함께 초기 블록의 출력을 받는다. 둘을 이어 붙여 학습된 선형 투영을 지난 뒤 네 개의 공유 블록으로 들어간다. 매 통과마다 같은 초기 입력 표현에 접근하게 해 주는 셈이다.

연구진은 학습을 진행하는 동안 루프 수를 무작위로 표집했다. 추론 시점에 서로 다른 계산량으로 일하도록 모델을 준비시키는 조치다. 추론 시점에는 모델을 돌리는 쪽이 8, 32, 64 같은 고정 예산을 고른다. 여기에 토큰별 적응 정지도 붙어 있다. 연속한 두 회차의 다음 토큰 확률 분포가 서로 너무 비슷하면, 곧 KL 발산이 문턱값 아래면 루프를 멈춘다.

이득은 과제에 따라 달랐다. HellaSwag는 여덟 바퀴쯤에서 대체로 평평해지고, GSM8K와 HumanEval은 더 도는 쪽이 이득이었다. 제목에 잠재 추론이 들어가지만 이 모델도 텍스트 사고 사슬을 여전히 만들어 낸다. 루프는 출력 토큰마다 계산을 더 얹어 줄 뿐이다.

기억과 추론을 따로 재면

정보를 저장하는 일과 그것을 써서 문제를 푸는 일은 구분된다. 2025년 6월 논문 「Beyond Parameters: Exploring Virtual Logic Depth for Scaling Laws」는 언어 모델의 암기와 추론을 따로 측정해 이것을 조사했다.

암기 실험에서는 파라미터 수를 고정한 채 루프를 돌려도 저장된 정보량이 거의 그대로였다. 서로 다른 파라미터를 늘려야 용량이 늘었다. 루프가 모델에게 더 많은 지식을 담게 하거나 꺼내게 해 주지는 못한다는 결론이 나온다. 정보 검색은 일단 저장되고 나면 비교적 단순한 일이고, 루프는 무언가를 담아 두는 장치라기보다 계산하는 장치이니 그럴 법하다.

파라미터 수와 블록 적용 횟수에 따른 암기 용량 그림 10. 이 암기 시험에서 용량은 파라미터 수를 따라 늘지만 블록 적용을 늘려도 거의 달라지지 않는다. Zhu 외의 그림에 Raschka가 주석을 더한 것

추론 실험은 결과가 달랐다. 블록을 다시 쓰는 것만으로 파라미터를 늘리지 않고도 다단계 수학 문제 성능이 올랐다. 저장 공간이 늘지 않아도 계산을 더 주면 문제를 푸는 데 도움이 된다고 읽을 수 있다. 물론 모델을 키워도 추론은 개선되지만, 그쪽은 파라미터를 함께 늘리는 방법이다.

조건을 맞춰 놓고 비교하면

2026년 9월에 막 나온 「SMELT: Scaling Laws for Compute-Matched MoE Looped Transformers」는 앞의 비용 비교로 되돌아간다. 이 논문은 토큰당 계산량과 임베딩을 뺀 총 파라미터, KV 캐시 요구량을 대략 맞춰 놓고 루프와 재래식을 견준다.

연구진은 전문가 혼합 아키텍처를 쓰고 트랜스포머 블록의 가운데 절반을 두 번 적용한다. 잠재 추론 논문처럼 앞뒤를 감싸는 구성이라는 점만 빼면 Nanbeige와 비슷하다. 그런 다음 늘어난 블록 적용의 계산을 벌충하려고 은닉 차원을 좁힌다. 그러면 파라미터 수가 줄어드니 전문가를 더해 총 파라미터를 되찾는다. 어텐션 헤드 구성도 손봐 KV 캐시를 비슷하게 맞춘다.

SMELT의 조건 맞춤 예시 그림 11. SMELT 논문 3.2절의 예시를 정리한 개요. 모델 폭과 전문가 수, 블록 적용, 파라미터, 계산량, KV 캐시를 나란히 놓았다

실험은 임베딩을 뺀 파라미터 540억 규모까지 올라간다. 적합시킨 스케일링 곡선에서 연구진은 SMELT가 같은 검증 손실에 도달하는 데 학습 계산을 6.8%에서 18%가량 덜 쓴다고 추정했다. 연구진이 다룬 계산 범위 안에서 나온 추정이다. 루프 트랜스포머가 계산 면에서 제 몫을 하는지 묻는다면, 답이 여기 있다. 같은 계산 예산에서 조금 더 나은 모델을 준다.

토큰 축으로 되먹임하면

2026년 8월 논문 「Full-bandwidth transformer」는 깊이가 아니라 토큰 위치를 가로지르는 순환을 다룬다. 디코딩 단계마다 앞 토큰의 최종 은닉 상태와 새로 뽑힌 토큰의 임베딩을 학습된 게이트로 결합한다. 이것이 다음 순전파의 입력이 된다. 다음 토큰의 계산이 스택 맨 아래에서부터 앞 토큰의 최종 표현에 접근하는 셈이니 잠재 추론과 닮은 데가 있다.

10억 파라미터 기반 모델에서 이 잠재 되먹임 방식은 MATH500의 추론 흔적을 짧게 만들면서 정확도를 유지하거나 개선했다. 그런데 이 단축 효과는 명령어 튜닝을 거치고 나면 사라졌다.

이 결과는 루프가 추론 흔적을 짧게 만드는가라는 앞선 물음과 바로 이어진다. 되먹임 기제가 무엇이고 모델을 어떻게 학습시켰느냐에 따라 답이 달라진다. 게다가 짧아진 흔적이 덜 충실한지는 이 실험으로 알 수 없다. 이 연구의 큰 한계도 하나 남아 있다. 루프 대신 블록을 더 쌓는 재래식 확대가 추론 흔적 길이에 비슷한 효과를 내는지는 시험하지 않았다.

가장 흥미로운 지점

글을 덮고 나서도 마지막 문단의 비유 하나가 자꾸 걸렸다. Raschka는 짧아진 추론 흔적을 두고 대학 수학 시험장을 떠올린다. 잘 준비된 똑똑한 학생은 연습지를 덜 쓰고 되짚는 일도 적다. 그럴듯한 비유인데, 이 비유가 성립하지 않는 지점이 바로 그가 다루려던 문제다. 시험장 감독은 학생의 머릿속을 감시하려던 것이 아니지만, 여기서 연습지는 유일한 감시 창구다. 연습지에 남는 풀이가 짧아지는 이유가 실력이든 다른 무엇이든, 감시자가 들여다볼 수 있는 부분이 줄어든다는 점은 같다.

그가 이것을 모르고 쓴 것은 아니다. Astra 시스템 카드가 감시 가능성 후퇴를 스스로 적어 두었다는 점을 그도 인정하고 넘어간다. 파호츠키도 그 기법이 취약하고 나쁜 방향으로 가고 있다고 했다. 이 세 진술을 나란히 놓으면, 다투는 자리는 현상이라기보다 원인 지목 쪽이다. 흔적이 짧아진다는 데는 모두 동의하고, 그것이 아키텍처 탓인지 아닌지에서 갈린다. 파호츠키가 곧 따로 쓰겠다고 미뤄 둔 그 이유가 무엇인지, 나는 그쪽이 더 궁금해졌다.

출처

Sebastian Raschka, “GPT-6 Astra, Looped Transformers, and Hidden Reasoning”, Ahead of AI, 2026년 9월 9일. 본문 이미지는 모두 원문에서 인용했다. 원문: https://magazine.sebastianraschka.com/p/gpt-6-astra-looped-transformers-and