Recurrent Looped Transformer

앞선 계산을 다음 토큰으로 잇기 — 쉽게 읽는 Recurrent Looped Transformer

RLT는 직전 토큰에서 만든 내부 상태를 다음 토큰 계산으로 넘기는 Transformer다. 긴 순서 정보를 다루는 작은 알고리즘 과제에서 일부 강점이 있었지만, 효과는 과제와 층 배분에 따라 크게 달랐고 순차 계산 비용도 늘었다.

Jiphyeonjeon Team2026-09-238 min read쉬운 읽기상세 읽기
recurrent-looped-transformerlatent-reasoningrecurrent-decoderencoder-memoryrl-replayhardware-co-designsliding-window-attentionpaper-review

Paper: Yifan Zhang; Jichen Feng; Shihan Qin (2026). "Recurrent Looped Transformer" (RLT-1). Technical report. PDF · 프로젝트 페이지

긴 입력을 읽을 때 언어 모델은 앞 문장을 참고한다. 그런데 보통 Transformer의 각 토큰 계산은 “앞을 훑어 참고하는 일”에 가깝다. RLT는 여기에 작은 변화를 넣는다. 바로 전 토큰을 처리하며 만든 내부 작업 상태를 다음 토큰의 출발점으로 넘긴다. 한 줄씩 계산하던 사람이 방금 쓴 중간 메모를 다음 줄에도 들고 가는 모습에 가깝다.

이 아이디어만으로 모델이 더 똑똑해졌다고 말할 수는 없다. 이 글은 공식 PDF의 2026년 9월 17일 개정본을 기준으로 한다. 9월 12일 초기본은 실험 없는 19쪽 보고서였다. 개정본은 41쪽으로 늘었고 여섯 가지 작은 알고리즘 과제의 실험을 추가했다. 어떤 과제에서는 학습 때보다 긴 입력에서도 잘 작동했지만, 다른 과제에서는 효과가 약하거나 초기값에 민감했다.

먼저, 무엇이 달라졌나

토큰(token)은 단어 전체가 아니라 모델이 처리하는 작은 텍스트 조각이다. 일반적인 다음 토큰 예측은 지금까지의 토큰을 보고 다음 조각을 고른다. RLT도 그 일을 한다. 차이는 각 위치에서 두 종류의 기억을 쓴다는 데 있다.

첫째는 문맥 메모리다. 인코더가 이미 읽은 토큰을 인과적으로 처리해 만든 키·값(KV) 정보다. 쉽게 말해 “앞부분에서 무엇을 찾을 수 있는가”를 빠르게 찾아보는 색인이다. 둘째는 순환 상태다. 디코더가 바로 전 위치까지 처리하며 만든 마지막 작업 결과와, 최근 몇 위치의 작은 캐시다.

새 토큰이 오면 RLT는 현재 토큰의 인코더 표현과 직전 순환 상태를 게이트로 섞는다. 게이트는 두 정보 중 어느 쪽을 얼마나 넣을지 조절하는 문이다. 그 뒤 디코더가 문맥 메모리와 최근 캐시를 읽어 새 상태를 만들고 다음 토큰의 확률을 낸다. 이 새 상태는 다시 다음 위치로 간다. 논문 §2, pp. 2–4

예를 들어 A와 B를 바꾼 뒤, C와 D를 바꾼 뒤… 같은 순서 문제를 생각해 보자. 답을 내기 위해서는 지금까지 적용한 교환의 결과를 계속 갱신해야 한다. RLT의 순환 상태는 그 “현재까지의 판”을 다음 단계로 보내는 통로다. 그렇다고 상태가 원문 전체를 대신 저장하는 것은 아니다. 전체 문맥은 인코더 메모리에서 찾고, 순환 상태는 이전 계산을 이어 주는 역할을 한다.

RLT-1의 인과적 인코더와 순환 디코더를 나란히 보여 주는 구조도. 왼쪽은 토큰별 인코더 KV 메모리, 오른쪽은 이전 디코더 상태와 슬라이딩 윈도 어텐션가 현재 토큰 업데이트로 이어지는 경로를 표시한다.

파란 경로는 앞 문맥을 찾는 메모리이고, 주황 경로는 직전 계산 상태를 다음 위치로 넘긴다. 프롬프트를 읽을 때와 답을 생성할 때 같은 상태 갱신을 쓰는 구조다. 원논문 Figure 1, p. 1을 그대로 인용했다(2026년 9월 17일 개정판).

왜 “looped”라고 부르나

RLT의 디코더는 토큰을 하나 처리할 때마다 이전 디코더의 결과를 다시 입력으로 받는다. 따라서 토큰이 길어질수록 상태가 지나온 계산 경로도 길어진다. 저자들은 이를 고정된 토큰당 블록 수 안에서 시간 방향 계산 경로를 늘리는 방법으로 설명한다.

하지만 공짜는 아니다. 인코더는 알려진 프롬프트를 병렬로 처리할 수 있어도, 순환 디코더는 앞 상태가 나온 뒤에야 다음 상태를 만들 수 있다. 그래서 생성뿐 아니라 답 생성을 시작하기 전에 입력 프롬프트를 처리하는 prefill 단계에서도 순서대로 디코더를 갱신해야 한다. “긴 문맥을 더 잘 다룰 수 있다”는 가능성과 “순차 대기 시간이 늘어난다”는 비용을 같이 갖는 설계다. 논문 §1, §2.4

이 구조는 프롬프트의 끝에서 상태를 지우지 않는다. 프롬프트를 한 번에 넣었든 조금씩 넣었든, 같은 토큰 이력과 같은 연산을 썼다면 같은 상태로 이어지도록 설계됐다. 이는 서비스 요청을 어디서 나눴는지가 모델의 의미를 바꾸지 않게 하려는 성질이다. 다만 실제 구현에서는 커널·정밀도·캐시 처리까지 같아야 한다. 설계상의 동치가 곧바로 모든 구현의 수치적 일치를 보장하지는 않는다.

실험은 무엇을 비교했나

패리티는 0과 1로 된 입력에서 1의 개수가 홀수인지 짝수인지 맞히는 과제다. 순열 상태 추적은 물체의 자리를 차례로 바꾼 뒤 최종 배치를 맞히는 과제이고, 모듈러 산술은 계산 결과를 정해진 수로 나눈 나머지를 구하는 과제다. 긴 입력을 따라 계산 상태를 유지하는 능력을 작게 떼어 시험한다.

현행 개정본은 총 8개의 논리적 층을 인코더와 디코더에 어떻게 나눌지 비교했다. 5+3은 인코더 5층, 순환 디코더 3층이라는 뜻이다. 4+4, 5+3, 6+2, 7+1, 8+0 다섯 구성과 8층 decoder-only Transformer를, 덧셈·패리티·모듈러 산술·순열 상태 추적 등 여섯 과제에서 비교했다. 각 구성은 같은 훈련·평가 데이터와 세 초기값으로 학습했다. 논문 §3.1, p. 5

관찰 논문이 보고한 값 이렇게 읽을 점
패리티 일반화 256비트에서 5+3·7+1은 세 시드 모두 100%, Transformer는 50.07±1.63% 이 과제에서는 일부 순환 배분이 긴 입력에 유리했다.
교환 기반 순열 추적 512연산에서 4+4는 55.70±25.78%, Transformer는 0.85±0.30% 상태를 이어 가는 과제에서 차이가 컸지만, RLT 쪽 변동도 컸다.
덧셈 훈련한 1–8자리 밖에서는 32자리에서 모든 평균이 약 15–17% 순환 연결이 폭 밖 일반화를 해결하지는 않았다.

첫 두 결과는 흥미롭지만 “RLT가 Transformer보다 낫다”는 결론으로 줄이면 틀린다. 패리티에는 5+3·7+1이, 긴 교환 순열에는 4+4가 좋았다. 두 자리만 맞바꾸는 교환 연산과 달리, 다섯 원소 전체의 재배열을 한 번의 입력으로 주는 표준 순열 추적에서는 모든 모델의 정확도가 낮았다. 모듈러 산술의 경우 일부 구성은 성공한 시드와 거의 우연 수준인 시드가 함께 나왔다. 즉, 어느 층을 순환 계산에 배분할지가 과제의 계산 형태와 맞아야 했다. 논문 §3.2–3.5, pp. 6–8

8층 모델의 길이 일반화 6개 패널. 덧셈, 패리티, 두 mod-5 과제, 표준 S5, swaps S5에 대해 RLT-1 깊이 분할과 Transformer의 정확도를 길이별로 비교하며, 세 초기화 시드의 평균과 표준편차 막대를 함께 표시한다.

학습 때보다 입력이 길어질수록 성능이 어떻게 달라지는지 본 8층 실험이다. 훈련 길이 안의 검증 손실로 고른 체크포인트에 대해 세 초기값의 평균과 표준편차를 그렸으며, 과제마다 잘 작동하는 층 배분과 변동 폭이 다르다. 원논문 Figure 4, p. 10을 그대로 인용했다(2026년 9월 17일 개정판).

숫자를 읽을 때 남는 조건

이 실험은 언어 이해 벤치마크나 대형 모델 서빙 시험이 아니다. 폭 512의 약 2,500만~2,900만 파라미터 모델을 CPU FP32에서 학습한 알고리즘 과제 실험이다. 각 결과는 세 초기값의 평균과 표본 표준편차다. 특히 큰 표준편차는 모델이 방법을 안정적으로 배웠다는 뜻이 아니라, 초기화에 따라 성공 여부가 갈렸다는 신호다.

또한 덧셈은 정답 앞 토큰을 입력으로 주는 teacher forcing 정확도로 측정했다. 실제 생성 중 이전 답을 잘못 낸 뒤에도 끝까지 풀 수 있는지를 직접 보여 주는 지표는 아니다. 저자들도 길이 밖 덧셈이 약해지고 표준 순열 추적은 어렵다고 보고한다. 이 결과는 순환 경로가 특정 상태 추적 문제에 도움이 될 수 있다는 증거다. 다만 범용 추론·대규모 학습 효율·실제 서비스 지연을 검증하지는 않았다.

이 설계를 언제 검토할까

입력이 길어질수록 “현재까지 누적한 작업 상태”가 중요한 문제라면 RLT의 생각은 검토할 만하다. 예를 들면 순서대로 갱신되는 형식 언어, 프로그램 실행 추적, 여러 단계의 상태 전이처럼 이전 계산 결과 자체가 다음 계산의 재료가 되는 경우다. 반대로, 짧은 지연 시간과 병렬 prefill이 중요하거나 과제가 상태를 길게 보존할 필요가 없다면 순환 디코더의 대가가 더 클 수 있다.

실무에서 볼 질문은 단순하다. (1) 다음 단계가 직전 계산 결과를 정말 필요로 하는가, (2) 그 이득을 위해 prefill의 순차 비용을 감수할 수 있는가, (3) 인코더와 디코더 층의 배분을 과제별로 검증했는가, (4) 길이 밖·다른 초기값·실제 생성 조건에서도 재현되는가. 이 네 질문에 답하기 전에는 RLT를 일반 목적의 대체 구조로 부르기 어렵다.

마무리

RLT의 제안은 단순하다. 토큰마다 새 문맥을 읽을 뿐 아니라, 방금 끝낸 계산 상태도 다음 계산으로 넘기자는 것이다. 현행 원문의 결과에 따르면 이 생각은 긴 패리티와 일부 순열 상태 추적에 도움이 될 여지가 있다. 동시에 모든 과제에 맞는 층 배분은 없으며, 일부 결과는 초기값에 민감했고, 순차 계산 비용도 피할 수 없었다.

이 논문은 “상태를 이어 가야 하는 계산에는 어떤 순환 배치가 맞는가”라는 실험 질문을 다룬 연구로 읽는 편이 정확하다.

9월 17일 개정본의 구조·실험 설정·결과와 한계는 상세 읽기에서 더 자세히 다룬다.

References

Zhang, Y., Feng, J., & Qin, S. (2026). Recurrent Looped Transformer (RLT-1; revised September 17, 2026). Technical report. https://yifanzhang-pro.github.io/recurrent-looped-tranformer/Recurrent_Looped_Transformer.pdf