DANTINOX: 여러 생성 방식을 한 코드베이스에서 비교하는 법

arXiv에 공개된 DANTINOX: A Unified Framework for Multi-Paradigm Language Modeling (arXiv:2609.17535)은 자기회귀 디코딩과 이산 마스크드 디퓨전과 연속 플로우 매칭을 하나의 모듈형 Transformer 백본과 하나의 API로 묶어, 설정 변경만으로 패러다임을 바꿔 비교할 수 있게 했다고 주장합니다. 원문 논문 링크는 제목 아래에 걸어 두었습니다.

비교가 안 된다는 말이 계속 마음에 남았습니다

제가 이 논문을 집어 든 이유는 성능표 때문이 아니었습니다. 비교가 어렵다는 첫 문장이 오래 마음에 남았기 때문입니다. 언어 생성 연구가 세 가지 패러다임에 걸쳐 넓어지고 있는데, 각자가 따로 떨어진 코드베이스에 살고 있어서 제대로 견주기 어렵다는 진단이었습니다. 이 진단은 읽는 순간 고개가 끄덕여졌는데, 왜냐하면 저도 비슷한 장면을 여러 번 봤기 때문입니다. 같은 아이디어를 두고 이야기하는데, 막상 코드를 열어보면 토크나이저가 다르고 초기화가 다르고 학습 루프가 달라서 도대체 무엇이 이겼는지 알 수 없는 경우 말이죠.

그렇다면 무엇과 무엇을 견준다는 말일까요. 겉으로는 패러다임 대결처럼 보이지만, 속을 들여다보면 구현 대결인 경우가 많습니다. 어느 쪽이 더 좋은 생성 원리를 가졌는지보다, 어느 쪽이 더 손질된 학습 파이프라인을 가졌는지가 승부를 가릅니다. 저는 이 대목에서 논문이 겨냥하는 지점을 읽었습니다. 새로운 생성 원리를 하나 더 내놓겠다는 선언보다, 견주는 판 자체를 고치겠다는 선언으로 말이죠.

이런 종류의 작업은 처음에는 다소 심심하게 느껴질 수 있습니다. 눈에 띄는 점수 상승이 없기 때문입니다. 그런데 저희가 새로운 AI 아키텍처를 볼 때도 점수만 따로 떼어 보지는 않습니다. 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 그런 눈으로 보면 DANTINOX는 점수표보다 실험대의 문제, 그러니까 판을 만드는 일에 가깝습니다. 판이 기울어져 있으면 아무리 열심히 달려도 기록이 남지 않으니까요.

여기서 재미있는 질문이 생깁니다. 하나의 백본으로 세 가지 생성을 모두 떠받친다는 말은 도대체 어떻게 가능한 걸까요. 자기회귀이면서 동시에 디퓨전이라는 말처럼 들리기 때문입니다. 이 의문을 풀기 위해 다음 절에서는 세 가지 생성 방식이 각자 어떤 순서로 문장을 만들어내는지부터 차근차근 짚어보겠습니다.

왼쪽에서 오른쪽으로 쓰는 일과 빈칸을 메우는 일과 천천히 다듬는 일

자기회귀 디코딩은 우리에게 가장 익숙한 쓰기 방식입니다. 왼쪽에서 오른쪽으로 한 토큰씩 내놓고, 방금 내놓은 토큰을 다시 입력으로 받아 다음 토큰을 고릅니다. 문장을 왼쪽부터 차례로 써 내려가는 모습과 겹쳐 보이는데, 그래서 추론 과정이 직관적으로 읽힙니다. 앞부분이 정해지면 뒷부분의 선택지가 좁혀지고, 그 좁혀진 선택지 위에서 다시 다음 토큰을 고르는 흐름이 이어지죠. 이 방식이 가진 감각은 순서에 대한 신뢰에 가깝습니다. 이미 쓴 말이 다음 말을 부르는 구조이니까요.

이산 마스크드 디퓨전은 순서를 다르게 씁니다. 처음에는 문장 자리에 가림막을 여러 개 깔아두고, 그 가림막을 조금씩 벗기면서 빈칸을 메워갑니다. 왼쪽부터 차례로 쓰는 대신, 전체 길이를 먼저 잡아둔 뒤에 내용을 채우는 셈입니다. 이때 한 번에 하나의 빈칸만 메울 수도 있고, 여러 빈칸을 함께 풀 수도 있어서, 병렬로 다듬는 재미가 생깁니다. 생각해보면 사람도 초고를 쓸 때 비슷한 전략을 씁니다. 전체 분량을 먼저 정해두고, 비어 있는 대목부터 하나씩 메워가는 식이죠.

연속 플로우 매칭은 또 다른 감각으로 문장에 접근합니다. 토큰이라는 딱 떨어지는 조각을 직접 고르기보다, 연속된 공간에서 벡터를 출발점부터 도착점까지 부드럽게 이동시키는 흐름을 학습합니다. 처음에는 흐릿한 상태에서 시작해 점점 또렷한 표현으로 수렴하는 과정이 이어지는데, 이 흐름이 텍스트 생성에서는 연속 임베딩 위에서 일어납니다. 저는 이 대목을 읽으면서, 점토를 빚듯이 형태를 잡아간다고 느꼈습니다. 한 번에 하나씩 쌓는 벽돌식 구성과 달리, 전체를 손바닥으로 매만지며 다듬는 방식에 가깝기 때문입니다.

그렇다면 세 방식은 완전히 다른 모델을 요구할까요. 언뜻 보면 그렇게 생각하기 쉽습니다. 왼쪽부터 쓰는 기계와 빈칸을 메우는 기계와 흐름을 다듬는 기계는 서로 다른 부품으로 만들어졌을 것 같기 때문입니다. 그런데 DANTINOX가 던지는 질문은 바로 여기에서 시작합니다. 생성 순서를 정하는 부분과 문장을 이해하고 표현하는 부분을 나눌 수 있다면, 뒤쪽의 큰 덩어리를 공유할 수는 없을까요. 이 질문을 붙잡고 다음 절로 가보겠습니다.

측정한 차이가 패러다임의 차이인지 묻는 대목이 눈에 들어왔습니다

저는 이 논문에서 가장 눈여겨본 대목으로, 따로 떨어진 코드베이스 때문에 측정한 차이가 패러다임 자체보다 구현의 흔적을 반영한다는 지적을 꼽겠습니다. 이 문장은 짧지만 파장이 있습니다. 우리가 그동안 읽은 비교표 가운데 상당수가 패러다임 대결보다 세팅 대결에 가까웠을지도 모른다는 뜻이 되기 때문입니다. 토크나이저가 다르면 어휘를 자르는 단위부터 달라지고, 초기화가 다르면 학습 초반의 궤적이 달라지며, 학습 인프라가 다르면 배치 처리와 옵티마이저 동작부터 어긋납니다. 이런 조건에서 나온 숫자 차이를 패러다임의 우열로 읽는 일은 조심스럽습니다.

왜 이런 일이 반복될까요. 연구팀마다 손에 익은 도구가 다르고, 각 패러다임이 선호하는 구현 관습이 다르기 때문입니다. 자기회귀 진영은 자기회귀에 잘 맞는 학습 루프를 다듬어 왔고, 디퓨전 진영은 디퓨전에 잘 맞는 스케줄과 마스킹 전략을 다듬어 왔습니다. 각자 자신의 마당에서는 최선을 다한 셈인데, 문제는 마당이 다르다는 데 있습니다. 마당이 다르면 같은 선수끼리 붙어도 기록을 견주기 어렵습니다. 그래서 논문은 판을 하나로 합치자고 제안합니다. 백본 구조와 토크나이저와 초기화 전략과 학습 인프라를 고정해두고, 그 위에서 패러다임을 바꾸자는 것이죠.

(여기서 잠깐, 이런 통합 이야기가 나올 때마다 저는 예전에 여러 팀의 실험 코드를 합쳐본 기억을 떠올립니다. 겉으로는 같은 Transformer라고 적혀 있는데, 열어보면 정규화 위치가 다르고 마스크 처리 순서가 달라서 며칠씩 헤맨 적이 있습니다.) 이런 경험이 있는 분이라면, 논문이 말하는 통일이 얼마나 손이 많이 가는 일인지 바로 감이 오실 겁니다. 이름을 같게 쓰는 것과 실제로 같은 조건에서 돌리는 일은 층위가 다르기 때문입니다.

그렇다면 통일이 정확히 무엇을 고정한다는 말일까요. 다음 절에서는 논문이 새로 내놓은 것과 내놓지 않은 것을 가려보겠습니다. 그래야 이 작업을 점수 경쟁으로 오해하지 않고 읽을 수 있습니다.

새로 내놓은 것은 모델보다 판에 가깝습니다

이 작업을 처음 접하면 "그래서 어느 패러다임이 이겼나요"라는 질문이 먼저 떠오릅니다. 그런데 이 질문은 논문이 겨냥한 자리에서 약간 빗나갑니다. DANTINOX가 내놓은 것은 새로운 대형 모델도 아니고, 어느 패러다임의 승리를 선언하는 점수표도 아닙니다. 내놓은 것은 세 가지 패러다임을 같은 자리에서 돌릴 수 있는 도서관, 그러니까 오픈소스 JAX와 Flax 기반 라이브러리입니다. 저는 이 구분이 글을 읽는 내내 길잡이가 되었습니다. 모델 이야기가 나오면 기대를 접고, 실험 조건 이야기가 나오면 귀를 열면 됩니다.

이 구분이 필요한 이유는 용어가 주는 첫인상 때문입니다. 통합 프레임워크라는 말을 들으면 흔히 만능 모델을 떠올립니다. 하나로 모든 일을 가장 잘하는 모델 말이죠. 그런데 논문이 말하는 통일은 그런 뜻과 거리가 있습니다. 하나의 모듈형 Transformer 백본이 세 가지 생성 방식을 모두 떠받치도록 만든 설계 통일, 그리고 학습과 스트리밍 추론과 벤치마크를 하나의 API로 묶은 절차 통일이 중심입니다. 요컨대 무엇을 돌릴지의 문제보다 어떻게 돌릴지의 문제에 답하려는 시도입니다.

이런 시도를 점수표로만 평가하면 맥을 놓치기 쉽습니다. 점수는 다음에 따라오는 열매에 가깝고, 논문이 손본 것은 열매가 열리는 나무보다 밭의 모양에 가깝기 때문입니다. 밭을 고르게 고르면 그다음부터 열리는 열매를 견줄 수 있지만, 밭을 고르는 일 자체는 당장 달콤한 맛을 내지 않습니다. 그럼에도 밭을 고르는 일이 먼저라는 문제의식이 이 글 전체를 관통합니다. 측정된 차이가 구현의 흔적일 수 있다는 앞선 지적과 정확히 맞물리죠.

그렇다면 밭을 고른다는 말이 구현에서 정확히 어떤 모양일까요. 하나의 백본이 세 가지 생성을 떠받친다는 설계가 궁금해집니다. 다음 절에서는 그 구조를 머릿속에서 실행할 수 있을 정도로 따라가 보겠습니다.

하나의 몸통에 세 가지 걷는 법을 얹는다고 상상해 보시면 됩니다

논문이 그리는 구조를 저는 이렇게 상상했습니다. 몸통 하나가 있고, 그 위에 걷는 법 세 가지를 갈아 끼우는 모습입니다. 몸통에 해당하는 것이 모듈형 Transformer 백본이고, 걷는 법에 해당하는 것이 생성 패러다임입니다. 자기회귀 디코딩으로 걸을 때는 왼쪽에서 오른쪽으로 한 걸음씩 내딛고, 마스크드 디퓨전으로 걸을 때는 가려둔 칸을 여러 개 함께 풀며 나아가고, 플로우 매칭으로 걸을 때는 연속 공간에서 미끄러지듯 이동합니다. 다리는 같은 다리인데 보폭을 떼는 규칙이 달라지는 셈이죠.

이 비유가 성립하려면 몸통과 걷는 법 사이에 분명한 경계가 있어야 합니다. 실제로 논문은 그 경계를 코드 구조로 만들었다고 설명합니다. 토큰을 어떻게 자르고 어떻게 임베딩하는지, 층을 어떻게 쌓고 정보를 어떻게 섞는지 같은 큰 뼈대는 공유하면서, 다음 토큰을 어떤 순서로 풀어낼지 같은 생성 규칙은 갈아 끼울 수 있게 했다는 것입니다. 그래서 토크나이저와 초기화 전략과 학습 인프라를 패러다임에 상관없이 일정하게 둘 수 있습니다. 몸통이 바뀌지 않으니, 걸음걸이의 차이만 따로 떼어 볼 여지가 생기죠.

여기서 저만의 해석을 덧붙이자면, 이런 분리는 연구의 질문을 바꾸는 효과가 있습니다. 이전에는 "우리 파이프라인 전체가 저쪽 파이프라인 전체보다 좋은가"를 물었다면, 이제는 "몸통을 고정한 채 걷는 법만 바꿀 때 무엇이 달라지는가"를 물을 수 있습니다. 질문이 좁아진 것처럼 보이지만, 오히려 답의 보험이 늘어납니다. 달라진 것이 걷는 법뿐이라는 조건이 붙기 때문에, 결과의 원인을 가리키기가 한결 수월해지니까요.

물론 이런 상상에는 한계도 있습니다. 몸통을 공유한다고 해서 모든 구현 차이가 사라지는 것은 아닙니다. 생성 방식마다 필요한 손실 함수와 샘플링 절차가 다르고, 그 절차에 딸린 세부 선택이 또 달라질 수 있기 때문입니다. 논문이 모든 차이를 지웠다고 읽으면 넘겨짚은 셈이 됩니다. 다만 차이가 줄어든 자리가 어디인지, 그리고 남은 차이가 어디에 숨어 있는지를 물을 수 있는 자리가 마련됐다는 점은 분명합니다. 그렇다면 그 자리를 설정 파일 하나로 바꿀 수 있다는 말은 무슨 뜻일까요. 다음 절에서 이어가겠습니다.

설정 하나로 패러다임과 어텐션과 하드웨어 배치를 바꾼다는 말이 뜻하는 것

논문에서 눈에 띄는 표현 가운데 하나는, 생성 패러다임이나 어텐션 메커니즘이나 하드웨어 토폴로지를 바꾸는 일이 설정 변경만으로 가능하다는 대목입니다. 코드를 뜯어고치지 않고도 실험 조건을 갈아 끼울 수 있다는 뜻인데, 이런 문장은 읽을수록 곱씹게 됩니다. 설정 변경이라는 말이 가벼워 보이지만, 그 가벼움 뒤에는 무거운 설계가 숨어 있기 때문입니다. 갈아 끼울 수 있는 부분과 고정되는 부분이 미리 나뉘어 있어야만, 설정 한 줄이 실제로 동작하니까요.

어텐션 메커니즘을 예로 들어보겠습니다. 같은 Transformer 백본이라도 주의를 어떻게 주고받게 할지에 따라 계산의 모양이 달라집니다. 왼쪽만 볼지 양쪽을 함께 볼지, 전체를 한 번에 볼지 창을 나눠서 볼지에 따라 메모리 사용과 속도가 달라지죠. 이런 선택을 설정으로 바꿀 수 있다는 말은, 연구자가 묻고 싶은 질문을 코드 수정 없이 꺼낼 수 있다는 뜻입니다. "주의 범위를 바꾸면 생성 방식마다 타격이 어떻게 달라질까" 같은 질문이 그 예입니다. 저는 이 대목에서 실험의 문턱이 낮아지는 풍경을 떠올렸습니다. 궁금한 게 생겼을 때 새로 코드를 짜는 대신 설정을 고쳐서 바로 돌려보는 풍경 말이죠.

하드웨어 토폴로지 이야기도 같은 선상에서 읽힙니다. 여러 장치가 어떻게 연결되어 있는지, 모델의 조각을 어디에 올려놓을지는 연구실마다 사정이 다릅니다. 토폴로지를 설정으로 바꿀 수 있다는 말은, 같은 실험을 다른 장비 배치에서도 비슷한 절차로 돌릴 수 있다는 뜻으로 읽힙니다. 장비가 바뀌면 으레 코드도 함께 바뀌는데, 그 고리를 끊어내겠다는 의지로 보입니다. 실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 설정 변경이 정말 하드웨어 차이를 지워줄까요, 아니면 절차의 모양만 같게 해줄까요. 저는 후자에 가깝다고 봅니다. 물리적인 대역폭과 메모리는 설정으로 바뀌지 않기 때문입니다. 그럼에도 절차가 같아지면, 적어도 코드가 달라서 생긴 잡음을 걷어낼 수 있습니다.

문제는 그다음입니다. 설정으로 바꿀 수 있는 편리함이, 자칫 조건을 덜 따지게 만들 수도 있습니다. 설정 한 줄로 바꿨다는 말이 곧 공정한 비교라는 뜻은 아니기 때문입니다. 각 패러다임이 좋아하는 학습 신호와 샘플링 절차가 다르면, 같은 몸통 위에서도 유리한 쪽과 불리한 쪽이 갈릴 수 있습니다. 그래서 다음 절에서는 학습과 추론과 벤치마크를 하나의 API로 묶었다는 말이 어떤 보증을 주는지, 또 어떤 보증을 주지 않는지 따져보겠습니다.

학습과 스트리밍 추론과 벤치마크를 같은 선 위에 올린다는 뜻

논문은 학습과 스트리밍 추론과 벤치마크를 위한 하나의 API를 제공한다고 설명합니다. 이 문장을 저는 이렇게 풀어 읽었습니다. 모델을 가르치는 일과 서비스처럼 토큰을 흘려보내는 일과 점수를 재는 일을 서로 다른 도구에 맡기는 대신 같은 손잡이로 다루겠다는 뜻입니다. 따로 떨어진 도구로 재면 자를 댈 때마다 눈금이 어긋나는데, 같은 자를 쓰면 적어도 눈금 탓은 덜 하게 됩니다. 비교 연구에서 이런 정합성은 생각보다 큰 무게를 지닙니다.

스트리밍 추론이 여기에 들어간 점이 눈에 띕니다. 학습 때의 숫자만 맞추는 데서 그치지 않고, 토큰을 하나씩 혹은 묶음씩 내보내는 실제 생성 경로까지 같은 틀 안에서 다루겠다는 의지로 읽히기 때문입니다. 생성 패러다임마다 토큰을 내놓는 리듬이 다른데, 그 리듬을 같은 API 안에서 꺼낼 수 있으면 관찰의 자리가 넓어집니다. 학습 손실이 비슷해도 실제 생성 과정의 감각은 다를 수 있고, 그 감각의 차이가 어디에서 오는지를 물을 수 있게 되니까요. 저는 이 대목에서 논문이 학습 지표 너머를 보려는 태도를 느꼈습니다.

벤치마크 역시 같은 맥락에서 읽힙니다. 점수를 재는 절차가 공유되면, 적어도 재는 방식이 달라서 생긴 차이는 줄어듭니다. 같은 토크나이저로 자르고 같은 초기화에서 출발해 같은 학습 인프라 위에서 돌린 뒤, 같은 절차로 점수를 재면 남는 차이에 대해 더 솔직한 이야기를 나눌 수 있습니다. 물론 점수를 재는 절차가 같아졌다고 해서 모든 공정성 문제가 풀리는 것은 아닙니다. 무엇을 재는지, 어떤 길이와 형식의 입력으로 재는지 같은 선택은 여전히 남아 있기 때문입니다. 그럼에도 재는 손이 같아졌다는 사실은 대화를 시작하기 좋은 자리입니다.

여기서 저희 팀의 기준으로 한 문장만 덧붙이자면, 저희는 벤치마크 숫자를 볼 때 숫자 자체보다 그 숫자가 나온 조건을 먼저 봅니다. 어떤 길이에서 재었는지, 스트리밍 조건은 어땠는지, 배치 크기와 정밀도는 무엇이었는지를 함께 봐야 숫자가 말을 걸어오기 때문입니다. DANTINOX가 하나의 API를 내세운 일은, 바로 그 조건을 같은 언어로 적게 해주는 일로 읽힙니다. 그렇다면 이런 조건 통일이 실제로 공정한 비교로 이어질까요. 다음 절에서는 공정하다는 말의 뜻을 조금 더 엄밀하게 따져보겠습니다.

공정해 보이는 비교가 실제로 공정한지 따지는 법

공정한 비교라는 말은 입에 붙기 쉽지만, 막상 뜯어보면 층이 여럿입니다. 같은 계산량을 썼는지, 같은 메모리를 썼는지, 같은 wall-clock 시간을 썼는지, 같은 데이터를 같은 순서로 먹였는지가 각자 다른 질문이기 때문입니다. 논문이 말하는 통제는 그 가운데 일부를 묶어주는 일입니다. 백본 구조와 토크나이저와 초기화 전략과 학습 인프라를 일정하게 두는 것이죠. 저는 이 통제를 판을 고르는 일이라고 읽었습니다. 판을 고르면 선수들의 발놀림을 보기 쉬워지지만, 선수들의 컨디션까지 같아지는 것은 아닙니다.

왜 그럴까요. 생성 방식마다 학습 신호의 모양이 다르기 때문입니다. 자기회귀는 다음 토큰을 맞히는 신호를 매 걸음마다 받고, 마스크드 디퓨전은 가려진 자리를 푸는 신호를 받으며, 플로우 매칭은 연속 공간에서의 이동 방향을 배우는 신호를 받습니다. 신호가 다르면 같은 걸음 수만큼 걸어도 다리의 피로도가 다릅니다. 같은 에폭을 돌렸다는 말이 곧 같은 노력을 들였다는 뜻이 되지는 않는 셈입니다. 이런 차이를 두고 어느 쪽이 우월하다고 말하기 전에, 무엇을 같게 두었는지를 먼저 밝혀야 합니다. 논문이 같은 API를 강조하는 이유도 여기에 있다고 봅니다. 무엇을 같게 두었는지를 말할 수 있는 언어가 생기기 때문입니다.

여기서는 조금 조심해서 읽을 필요가 있습니다. 통제가 좋아졌다고 해서 패러다임의 순수한 차이만 남는다고 믿으면 넘겨짚기 쉽습니다. 손실 함수의 세부 선택, 마스킹 비율의 스케줄, 샘플링 단계의 수 같은 결정이 여전히 결과에 스며들기 때문입니다. 이런 결정은 패러다임의 일부처럼 보이지만, 동시에 연구자의 손맛이 들어가는 자리이기도 합니다. 그래서 저는 이 논문의 비교를 순수 분리로 읽지 않고, 잡음을 줄인 자리에서의 대화 시작으로 읽었습니다. 완전히 같은 조건이라는 말보다, 무엇이 같고 무엇이 다른지 말할 수 있게 됐다는 말이 더 정확합니다.

그렇다면 이런 대화가 시스템 현실에서는 어떤 모양일까요. JAX와 Flax 위에 올렸다는 선택, 그리고 하드웨어 배치를 설정으로 다룬다는 선택이 실제 운영과 어떻게 맞물리는지 궁금해집니다. 다음 절에서는 그 선택을 시스템 관점에서 읽어보겠습니다.

JAX와 Flax 위에 올렸다는 선택을 시스템 관점에서 읽으면

논문은 구현 기반으로 JAX와 Flax를 택했고, 이를 오픈소스로 내놓는다고 설명합니다. 이 선택은 취향의 문제를 넘어, 실험을 어떻게 돌릴지에 대한 선언에 가깝습니다. JAX 진영의 도구는 함수형 변환과 장치 병렬화에 대한 문법이 비교적 분명하고, 같은 계산을 여러 장치 배치에서 돌리는 실험과 잘 어울립니다. 여러 패러다임을 같은 백본 위에서 돌리겠다는 목표와, 이런 도구 선택은 결이 잘 맞습니다. 저는 그래서 이 선택을 판을 고르는 일의 연장선에서 읽었습니다.

하드웨어 토폴로지를 설정으로 다룬다는 대목도 시스템 관점에서는 뜻이 있습니다. 연구실마다 가진 장비가 다르고, 같은 장비라도 어떻게 묶었는지에 따라 통신 비용이 달라집니다. 이런 차이를 코드 수정 없이 설정으로 표현할 수 있으면, 다른 환경에서도 비슷한 절차를 밟아볼 여지가 생깁니다. 물론 설정이 물리 법칙을 바꾸지는 않습니다. 장치 사이의 대역폭이 좁으면 통신이 병목이 되고, 메모리가 모자라면 배치 크기를 줄여야 합니다. 그럼에도 절차의 모양이 같아지면, 환경이 달라서 생긴 차이와 코드가 달라서 생긴 차이를 가르는 일이 한결 수월해집니다.

여기서 실무적인 장면 하나를 떠올려 보겠습니다. 밤사이 학습 작업이 돌아가고 아침에 결과를 확인하는 팀이 있다고 해보죠. 어젯밤 돌린 자기회귀 실험과 오늘 아침 돌릴 디퓨전 실험이 서로 다른 저장소와 서로 다른 실행 스크립트에 흩어져 있으면, 아침 회의에서 숫자를 견주기 전에 저장소 이야기부터 해야 합니다. 반면 같은 API 아래에서 설정만 바꿔 돌린 기록이라면, 아침 회의는 곧바로 결과 이야기로 들어갈 수 있습니다. 운영 측면에서 보면 이 차이는 작지 않습니다. 실험의 재현 절차가 단순해질수록, 팀이 조건을 따지는 데 쓰는 시간이 줄어들기 때문입니다.

다만 이런 편리함이 곧바로 서빙의 답이 되지는 않습니다. 학습과 스트리밍 추론을 같은 API로 다룬다고 해서, 실제 서비스의 지연 시간과 처리량이 자동으로 좋아지는 것은 아닙니다. 각 생성 방식이 토큰을 내놓는 리듬이 다르고, 그 리듬에 따라 캐싱과 배치 처리의 감각이 달라지기 때문입니다. 논문이 서빙 최적화를 약속한 것으로 읽으면 넘겨짚은 셈이 됩니다. 약속한 것은 같은 자리에서 리듬을 관찰할 수 있는 통로에 가깝습니다. 그렇다면 이런 통로 위에서 앞으로 무엇을 물어야 할까요. 다음 절에서는 catchy한 한 줄 요약이 놓치는 지점을 먼저 짚겠습니다.

한 줄 요약이 놓치는 자리를 먼저 짚고 싶습니다

이 논문을 한 줄로 줄이면 "세 가지 생성 방식을 하나의 라이브러리로 합쳤다" 정도가 됩니다. 틀린 말은 아닙니다. 그런데 이 요약은 논문이 가장 공들인 부분을 흘려보냅니다. 합쳤다는 사실보다, 무엇을 고정하고 무엇을 바꿀 수 있게 했는지가 이 작업의 속살이기 때문입니다. 백본과 토크나이저와 초기화와 학습 인프라를 고정한 채, 패러다임과 어텐션과 하드웨어 배치를 설정으로 바꾸는 구조가 바로 그 속살입니다. 한 줄 요약은 이 구조를 뭉뚱그려서, 마치 만능 모델이 나온 것처럼 들리게 만들 수 있습니다.

이런 오해가 생기는 이유는 통합이라는 단어 때문입니다. 통합이라는 말을 들으면 흔히 성능 통합을 떠올립니다. 가장 좋은 것만 골라 담은 모음집 같은 이미지 말이죠. 그런데 논문이 말하는 통합은 절차의 통합에 가깝습니다. 같은 몸통 위에서 다른 걷는 법을 시험할 수 있는 절차, 같은 손잡이로 학습과 추론과 측정을 다루는 절차가 중심입니다. 저는 이 차이를 읽는 일이 이 글을 이해하는 갈림길이라고 봅니다. 만능 모델을 기대하고 읽으면 심심한 글로 남지만, 실험 절차의 설계로 읽으면 질문이 샘솟는 글로 바뀝니다.

또 하나 놓치기 쉬운 자리는 오픈소스라는 대목입니다. 공개했다는 사실 자체보다, 무엇을 공개했는지가 더 눈에 들어옵니다. 같은 조건에서 돌릴 수 있는 코드를 공개했다는 말은, 다른 팀이 같은 질문을 같은 자리에서 따라와 볼 수 있다는 뜻입니다. "우리 환경에서는 달랐습니다"라는 대답이 가능해지는 것이죠. 이런 따라와 보기 가능성이 쌓이면, 패러다임 논쟁이 각자의 마당에서 외치는 모양에서 벗어나 같은 마당에서 주고받는 모양으로 바뀔 수 있습니다. 물론 공개만으로 이런 변화가 자동으로 오지는 않습니다. 문서와 예제와 유지보수가 따라와야 하고, 그 일은 논문 한 편으로 끝나지 않습니다.

그렇다면 같은 마당이 마련된 뒤에 남는 질문은 무엇일까요. 저는 앞으로 보고 싶은 것들을 마지막 절에 모아두었습니다. 점수 이야기는 잠시 접어두고, 같은 자리에서 비로소 물을 수 있게 된 질문들입니다.

같은 자리에서 비로소 물을 수 있게 된 질문들

제가 앞으로 보고 싶은 것은 새로운 점수표보다, 같은 자리에서만 물을 수 있는 질문들의 목록입니다. 첫째로, 몸통을 고정한 채 걷는 법만 바꿀 때 학습 신호의 효율이 어떻게 달라지는지 궁금합니다. 같은 토크나이저와 같은 초기화에서 출발해도, 다음 토큰 맞히기와 가려진 자리 풀기와 흐름 따라가기는 서로 다른 문법으로 배우기 때문입니다. 같은 걸음 수만큼 걸었을 때 어디에서 더 빨리 안정되고 어디에서 더 오래 헤매는지를 같은 눈금으로 보는 일은, 이전의 흩어진 코드베이스에서는 하기 어려웠던 관찰입니다.

둘째로, 생성 리듬의 차이가 스트리밍 추론에서 어떤 얼굴을 하는지 궁금합니다. 왼쪽부터 하나씩 내놓는 리듬과 여러 빈칸을 함께 푸는 리듬과 연속 공간을 미끄러지듯 이동하는 리듬은, 토큰을 흘려보내는 과정에서의 체감이 다를 수밖에 없습니다. 같은 API 안에서 이 리듬을 꺼내볼 수 있다면, 학습 손실이 비슷해 보이는 두 설정이 실제 생성에서는 왜 다르게 느껴지는지를 물을 수 있습니다. 저는 이 질문이 연구실 점수를 넘어 서비스 감각으로 이어지는 통로라고 봅니다. 밤사이 돌린 실험이 아침 회의의 숫자로만 끝나지 않고, 실제 손끝의 감각으로 이어지는 자리 말이죠.

셋째로, 어텐션 선택과 하드웨어 배치의 상호작용이 궁금합니다. 주의를 어떻게 주고받게 할지와 장치를 어떻게 묶을지는 서로 영향을 주고받습니다. 넓게 보는 주의는 더 많은 통신을 부르고, 좁게 보는 주의는 계산의 모양을 바꾸기 때문입니다. 이런 선택을 설정으로 바꿀 수 있으면, "이 생성 방식은 이 주의 범위에서, 이 장비 배치에서 어떤 표정을 짓는가" 같은 질문을 코드 수정 없이 꺼낼 수 있습니다. 답이 하나로 모이지는 않겠지만, 적어도 질문을 꺼내는 비용이 낮아집니다.

넷째로, 남는 구현 차이를 어떻게 기록할지가 궁금합니다. 몸통을 공유해도 손실 함수와 마스킹 스케줄과 샘플링 단계 같은 결정은 남습니다. 이런 결정을 각 실험마다 같은 언어로 적어두는 관행이 생기면, 나중에 결과를 읽을 때 "무엇이 같았고 무엇이 달랐는지"를 바로 확인할 수 있습니다. 저는 이런 기록의 축적이야말로 이 라이브러리가 줄 수 있는 조용한 선물이라고 봅니다. 당장의 승패보다 오래 남는 것은 결국 기록의 방식이기 때문입니다.

마지막으로, 이 흐름이 어디까지 이어질지 궁금합니다. 세 가지 패러다임을 같은 자리에서 다루는 시도가 자리 잡으면, 다음에는 새로운 생성 방식이 나왔을 때 그것을 같은 마당으로 데려오는 일이 쉬워질 수 있습니다. 새로 나온 아이디어를 따로 떨어진 저장소에서 외치게 두는 대신, 같은 몸통 위에서 같은 절차로 걸어보게 하는 것이죠. 이런 풍경이 쌓이면, 언어 모델 연구의 논쟁이 "누가 이겼는가"에서 "어떤 조건에서 무엇이 달라지는가"로 조금씩 옮겨갈 수 있습니다. 저는 그 옮겨감이 이 작업이 남기는 가장 긴 여운이라고 봅니다. 판이 바로 서면, 달리기의 기록도 비로소 말을 걸어오기 때문입니다.