디퓨전 LLM(dLLM), 토큰을 하나씩 뽑던 시대가 끝나가는 이유

💡 글의 핵심 3줄 요약

1. 디퓨전 LLM은 토큰을 왼쪽부터 하나씩 생성하는 자기회귀 방식과 달리, 노이즈 상태에서 문장 전체를 병렬로 다듬어가며 완성하기 때문에 같은 하드웨어에서 5~10배 빠른 생성 속도를 냅니다.
2. Inception Labs의 Mercury는 H100 한 장에서 초당 1,000토큰 이상을 생성했고, 구글은 2026년 6월 오픈 웨이트 모델인 DiffusionGemma를 Apache 2.0 라이선스로 공개하며 생태계를 넓히고 있습니다.
3. 코드 자동완성, 에이전트 워크플로우처럼 지연 시간이 곧 사용성인 영역부터 디퓨전 LLM이 파고들고 있지만, 품질과 서빙 인프라 호환성 문제는 아직 검증이 더 필요합니다.

여러분은 ChatGPT 같은 서비스에서 글자가 왼쪽부터 또박또박 흘러나오는 모습을 보면서 "왜 꼭 한 글자씩 나와야 하지?"라는 생각을 해본 적 없으신가요? 사실 그 모습은 연출이 아니라 모델의 구조적 한계입니다. 지금까지의 대규모 언어 모델은 거의 전부 자기회귀(Autoregressive) 방식, 그러니까 앞의 토큰을 보고 다음 토큰 하나를 예측하는 과정을 수천 번 반복하며 문장을 만들어 왔습니다.

그런데 2026년 들어 이 오래된 전제를 정면으로 뒤집는 흐름이 뚜렷해지고 있습니다. 바로 이미지 생성에서 검증된 확산(Diffusion) 기법을 텍스트 생성에 적용한 디퓨전 LLM, 줄여서 dLLM입니다. 오늘은 이 기술이 어떤 원리로 동작하는지, 왜 지금 주목받는지, 그리고 실무에 어떤 의미가 있는지 차근차근 풀어보겠습니다.

자기회귀 방식의 태생적 병목, 무엇이 문제였을까

자기회귀 모델의 생성 과정은 본질적으로 순차적입니다. 1,000개의 토큰을 만들려면 모델의 순전파(Forward Pass)를 1,000번 돌려야 하죠. 아무리 GPU가 빨라져도 이 반복 횟수 자체는 줄일 수 없습니다. 마치 아무리 숙련된 타이피스트라도 한 손가락으로만 타자를 쳐야 한다면 속도에 물리적 한계가 있는 것과 같습니다.

이 구조는 두 가지 실질적인 문제를 만듭니다. 첫째는 지연 시간입니다. 코드 자동완성처럼 사용자가 결과를 기다리는 시간이 곧 제품 경험인 서비스에서, 긴 응답은 그 자체로 이탈 요인이 됩니다. 둘째는 비용입니다. 순차 생성은 GPU의 병렬 연산 능력을 온전히 활용하지 못하기 때문에, 같은 하드웨어에서 뽑아낼 수 있는 처리량에 한계가 생깁니다.

물론 업계도 손을 놓고 있지는 않았습니다. 추측 디코딩(Speculative Decoding)으로 작은 모델이 초안을 쓰고 큰 모델이 검증하게 하거나, KV 캐시를 쥐어짜는 온갖 최적화가 등장했죠. 하지만 이런 기법들은 어디까지나 순차 생성이라는 뼈대 위의 개선이었습니다. 디퓨전 LLM은 그 뼈대 자체를 바꾸자는 제안입니다.

디퓨전 LLM의 동작 원리, 노이즈에서 문장을 조각하다

이미지 생성 모델인 Stable Diffusion을 써보신 분이라면 감이 오실 겁니다. 무작위 노이즈로 가득한 캔버스에서 시작해, 여러 번의 디노이징(Denoising) 단계를 거치며 점점 선명한 그림을 만들어내는 방식이죠. 디퓨전 LLM은 이 아이디어를 텍스트에 옮겨 왔습니다.

동작 과정을 단순화하면 이렇습니다. 먼저 생성할 문장 전체를 마스킹된(가려진) 토큰들로 채워 놓습니다. 그리고 모델이 매 단계마다 문장 전체를 한꺼번에 바라보면서, 확신이 높은 위치의 토큰부터 병렬로 채워 넣습니다. 몇 번의 반복(Refinement) 단계를 거치면 전체 문장이 완성되죠. 조각가가 돌덩이 전체를 보며 큰 형태부터 잡고 점점 세부를 다듬는 과정과 비슷합니다.

이 방식의 장점은 명확합니다. 1,000개의 토큰을 만드는 데 1,000번의 순전파가 아니라, 수십 번 수준의 디노이징 단계면 충분합니다. 각 단계에서 여러 토큰이 동시에 확정되기 때문입니다. 게다가 문장을 왼쪽에서 오른쪽으로만 보는 것이 아니라 양방향 문맥을 모두 참고하므로, 문장 중간을 수정하거나 빈칸을 채우는(Infilling) 작업에도 구조적으로 유리합니다. 코드 편집처럼 앞뒤 문맥이 모두 중요한 작업과 궁합이 좋은 이유입니다.

Mercury부터 DiffusionGemma까지, 2026년 dLLM 생태계 지형도

이론은 예전부터 있었지만, 시장이 움직이기 시작한 것은 최근 일입니다. 포문을 연 것은 Inception Labs의 Mercury였습니다. 최초의 상용 디퓨전 LLM인 Mercury는 H100 GPU 한 장에서 초당 1,000토큰이 넘는 생성 속도를 기록했습니다. 코드 특화 모델인 Mercury Coder Mini는 초당 약 1,109토큰까지 도달했는데, 이는 비슷한 체급의 자기회귀 모델보다 5~10배 빠른 수치입니다.

구글도 빠르게 움직였습니다. 2025년 구글 I/O에서 공개된 실험 모델 Gemini Diffusion은 초당 약 1,479토큰이라는 속도를 보여주며 가능성을 증명했고, 2026년 6월에는 오픈 웨이트 모델인 DiffusionGemma를 Apache 2.0 라이선스로 공개했습니다. 토큰을 블록 단위로 병렬 디노이징하는 방식으로 기존 대비 약 4배 빠른 생성을 내세우고 있죠. 연구용 데모가 아니라 누구나 내려받아 파인튜닝할 수 있는 오픈 모델이 나왔다는 점에서, 생태계 확산의 신호탄이라고 볼 수 있습니다.

학계에서도 LLaDA 같은 오픈 디퓨전 모델 연구가 이어지며 자기회귀 모델과의 성능 격차를 좁혀 왔습니다. 흥미로운 활용법도 등장했습니다. 디퓨전 모델이 빠르게 초안을 생성하고, 검증된 자기회귀 모델이 이를 한 번의 순전파로 확인하는 하이브리드 파이프라인입니다. 500토큰짜리 초안을 0.5초 안에 만들고 검증까지 1초 이내에 끝내는 식으로, 품질과 속도를 동시에 잡으려는 시도가 실제 서비스에 적용되고 있습니다.

개발자 입장에서 무엇이 달라질까

가장 먼저 체감될 영역은 코드 자동완성과 에디터 내 AI 기능입니다. 타이핑을 멈추는 순간 제안이 도착해야 하는 이 영역에서, 생성 속도는 곧 기능의 존재 이유입니다. 실제로 상용 dLLM들이 가장 먼저 공략한 시장도 코드 생성이었습니다.

에이전트 워크플로우도 큰 수혜자입니다. 에이전트는 한 번의 작업을 위해 내부적으로 수십 번의 LLM 호출을 반복하는데, 호출 하나하나의 지연이 누적되면 전체 작업 시간이 분 단위로 늘어납니다. 개별 호출이 5배 빨라진다면 에이전트의 반복 루프 전체가 실용적인 속도로 내려오게 되죠.

다만 냉정하게 봐야 할 부분도 있습니다. 최고 수준의 자기회귀 모델과 비교하면 복잡한 추론 품질에서는 아직 검증이 더 필요하고, 지금까지 자기회귀 모델을 중심으로 최적화된 서빙 인프라(KV 캐시, 스트리밍 처리 등)와의 호환성도 과제로 남아 있습니다. 모든 워크로드를 dLLM으로 바꾸는 것이 아니라, 지연 시간에 민감한 영역부터 선별적으로 도입되는 그림이 당분간의 현실적인 시나리오일 것입니다.

결론: 생성 속도의 문법이 바뀌고 있다

정리해 보겠습니다. 디퓨전 LLM은 토큰을 하나씩 뽑는 자기회귀의 순차성을 버리고, 문장 전체를 병렬로 디노이징하며 완성하는 새로운 생성 패러다임입니다. Mercury가 상용화의 물꼬를 트고 DiffusionGemma가 오픈 웨이트로 진입 장벽을 낮추면서, 2026년 현재 이 기술은 실험실을 벗어나 실제 프로덕션으로 이동하는 중입니다.

물론 자기회귀 모델이 하루아침에 사라지지는 않을 겁니다. 하지만 코드 자동완성, 에이전트 루프, 실시간 응답이 필요한 서비스처럼 속도가 곧 가치인 영역에서는 이미 판이 흔들리기 시작했습니다. 새로운 프로젝트에서 LLM 서빙을 설계하신다면, 이제 "어떤 모델을 쓸까"와 함께 "어떤 생성 방식을 쓸까"도 선택지에 올려두시길 권합니다. 기술의 흐름이 바뀌는 지점은 언제나 이렇게 조용히 시작되니까요.