파라미터 덩어리 너머로, 기억과 스킬을 조립하는 언어모델

최근 arXiv에 공개된 Beyond the Parameter Monolith: Reconstructive Memories, Executable Skills, and Residual Assembly for Language Models(arXiv 2610.04012)는 언어모델의 능력을 하나의 공유 파라미터 체계로 전부 업데이트하는 대신 독립적으로 만든 문서 상태와 결정적인 실행 스킬이 타입 있는 제안을 공유 언어모델 상태에 보태는 FEM-ASM이라는 구성을 제안합니다. 이 글에서는 그 제안이 왜 나왔는지, 잔차 연산자와 Multi-Mesh 실험과 기억 저장소가 각각 무엇을 보여주고 무엇을 보여주지 않는지를 차례로 따라가겠습니다. 참고로 원문 논문으로 이어지는 링크는 제목 아래에 걸려 있습니다.

저는 이 논문을 처음 펼쳤을 때 목차보다 부제에서 오래 멈췄습니다. reconstructive memories, executable skills, residual assembly라는 세 단어가 서로 다른 논문에서 따로 놀던 주제처럼 보였기 때문입니다. 그런데 저자는 이 셋을 하나의 문장으로 묶습니다. 기억은 복원하는 것이고, 스킬은 실행하는 것이며, 합치는 일은 조립하는 것이라는 식으로요. 이런 문장을 보면 저는 보통 의심부터 합니다. 말은 그럴듯한데 실제로 돌아가는 구조가 있느냐고요. 그래서 이번 글에서는 주장보다 장치를 먼저 보려고 합니다. 무엇이 어디에서 만들어지고, 어디에서 만나고, 어긋났을 때 누가 책임지고 맞추는지를요.

여러분이 운영 중인 서비스를 하나 떠올려 보셔도 좋습니다. 밤사이 문서가 수만 건 쌓이고, 계산 규칙이 조금씩 바뀌고, 모델은 내일 아침에도 같은 API 뒤에서 답해야 하는 상황입니다. 이때 모델 전체를 다시 학습시키는 일은 너무 무겁고, 프롬프트에 문서를 덧붙이는 일은 너무 임시방편처럼 느껴질 때가 있죠. 그렇다면 문서에서 만든 상태와 정확히 동작하는 계산기를 모델 바깥이 아니라 모델의 상태에 직접 붙일 수는 없을까요. 이 논문은 바로 그 질문에서 출발합니다.

왜 하나의 파라미터 덩어리에 모든 일을 맡겼을까

지금의 언어모델은 대체로 하나의 거대한 파라미터 덩어리로 배웁니다. 새로운 지식이 들어오면 그 덩어리 어딘가가 조금씩 바뀌고, 새로운 능력이 필요해도 같은 덩어리 안에서 가중치가 조정됩니다. 이 방식은 단순해서 강합니다. 학습 파이프라인도 하나이고, 서빙할 때 들고 있어야 할 것도 결국 그 모델이라는 점에서 마음이 편하죠.

그런데 운영 측면에서 보면 이 단순함이 점점 비싸집니다. 문서 몇 개가 바뀌었다고 전체를 다시 만질 수는 없고, 계산 규칙 하나가 바뀌었다고 모델 전체의 거동을 다시 검증하는 일은 부담이 큽니다. 더구나 지식을 외우는 일과 계산을 정확히 수행하는 일은 서로 다른 종류의 일인데, 우리는 그 둘을 같은 가중치 업데이트라는 하나의 통로로 밀어 넣고 있습니다. 그러다 보니 무엇을 고쳤을 때 무엇이 달라졌는지 추적하기가 어렵습니다. 버전 관리라는 말도 모델 가중치 앞에서는 자주 무력해지고요.

저는 이 대목에서 저희가 새 아키텍처를 볼 때 늘 확인하는 기준을 떠올렸습니다. 저희가 새로운 AI 아키텍처를 볼 때도 benchmark 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 봅니다. 이 논문도 숫자를 내세우기 전에 구조의 책임 소재를 바꾸려고 합니다. 모든 능력을 하나의 공유 파라미터 체계로 녹이는 대신, 독립적으로 만든 것들이 각자의 형태로 기여하고 나중에 맞추는 쪽으로요.

그렇다면 유한요소법이라는 말은 왜 나왔을까요. 공학에서 큰 구조물을 한 번에 해석하지 않고 작은 요소로 나눠 각각 푼 뒤 경계에서 맞춰 붙이는 방식이 있는데, 저자는 언어모델도 그렇게 나눠 볼 수 있지 않겠느냐고 묻습니다. 이 비유가 그럴듯하게 들리면서도 한편으로는 걱정됩니다. 물리 시뮬레이션의 경계 조건과 언어의 문맥이 같은 방식으로 맞춰질 수 있을까요. 이 질문을 들고 다음 장면으로 넘어가 보겠습니다.

유한요소법이라는 낯선 비유가 눈에 밟힌 이유

유한요소법은 낯설게 들리지만 발상은 소박합니다. 다리 전체를 한 번에 계산하지 않고, 작은 조각마다 변형과 힘을 따로 구한 뒤 조각들이 맞닿는 점에서 어긋나지 않게 조정합니다. 각 조각은 자기 모양과 재료에 맞게 풀 수 있고, 전체는 경계에서의 약속으로 유지됩니다. 그래서 어느 조각이 바뀌어도 전체를 처음부터 다시 풀지 않아도 되는 경우가 많죠.

이 논문이 FEM-ASM이라고 부르는 구성도 결이 같습니다. 독립적으로 만든 문서 상태와 결정적으로 동작하는 실행 스킬이 각자의 자리에서 타입 있는 제안을 만들고, 그 제안들이 공유 언어모델 상태에 모입니다. 그리고 공통 인터페이스 노드에 붙은 제안들은 명시적인 잔차 연산자가 맞추어 줍니다. 말하자면 각자 계산하고 나중에 경계에서 화해시키는 구조입니다.

여기서 제가 흥미롭게 본 부분은 독립이라는 단어의 쓰임입니다. 독립이라고 해서 서로 모르는 채로 각자 답을 내라는 뜻이 아닙니다. 만들 때는 따로 만들되, 합쳐질 때는 어디에 어떻게 붙을지가 미리 정해져 있다는 뜻에 가깝습니다. 문서 상태는 문서에서 왔고, 스킬은 정해진 계산을 수행했으며, 그 결과가 어떤 타입으로 어떤 노드에 붙는지가 약속되어 있습니다. 그래서 합치는 단계에서는 내용을 다시 해석하기보다 어긋난 정도를 재고 조정하는 일에 집중할 수 있습니다.

물론 비유가 구조를 보장하지는 않습니다. 유한요소법에서는 경계에서의 연속성이라는 물리적 조건이 분명한데, 언어모델에서는 무엇이 연속되어야 하는지가 훨씬 모호합니다. 토큰 분포일까요, 문장의 의미일까요, 아니면 다음 토큰을 고르는 경향일까요. 저는 그래서 이 비유를 증명이라기보다 설계 약속으로 읽었습니다. 어디까지를 따로 만들고 어디에서 맞출지를 정해두자는 약속 말입니다. 이 약속이 실제로 지켜지는지는 뒤에 나오는 장치들을 봐야 알 수 있습니다.

이것은 MoE도 RAG도 아니다

이름만 들으면 기존 방법과 헷갈리기 쉽습니다. 전문가를 여럿 두고 골라 쓰는 구조 아닌가, 아니면 문서를 검색해서 붙이는 방식 아닌가 하는 생각이 먼저 듭니다. 그런데 논문이 그리는 그림은 둘과 조금씩 어긋납니다. 이 차이를 먼저 정리해야 뒤의 실험이 헷갈리지 않습니다.

MoE를 떠올려 보겠습니다. MoE는 토큰마다 몇 개의 전문가를 고르고 그 전문가의 가중치로 계산합니다. 고르는 일과 계산하는 일이 모델 안에 함께 있습니다. 반면 FEM-ASM에서 문서 상태는 미리 따로 만들어질 수 있고, 스킬은 결정적인 실행으로 결과를 내놓습니다. 모델이 그 자리에서 가중치로 계산하는 것과, 바깥에서 정해진 절차로 구한 값을 타입 있는 제안으로 받는 것은 성격이 다릅니다. 하나는 내부의 선택이고 다른 하나는 외부에서 온 약속된 기여에 가깝습니다.

RAG와의 차이도 분명합니다. RAG는 외부 문서를 찾아 프롬프트에 덧붙이고 모델이 그 텍스트를 읽게 합니다. 텍스트로 설득하는 방식이죠. FEM-ASM은 문서를 텍스트로 붙이는 대신 문서에서 만든 상태를 직접 가져와 공유 상태에 붙입니다. 검색된 문장을 모델이 다시 해석하는 단계를 줄이고, 상태 대 상태로 만나게 하려는 시도입니다. 읽어보면 아시겠지만, 이 차이는 작아 보여도 시스템의 책임이 어디에 있는지를 바꿉니다. 텍스트로 붙이면 해석의 책임이 모델의 attention에 남고, 상태로 붙이면 만드는 쪽과 맞추는 쪽에 책임이 나뉩니다.

그렇다면 메모리 캐시나 에이전트 기억과도 다릅니다. 과거 대화를 저장해 두는 기능도 아니고, 디코딩 중에 키와 값을 아껴 쓰는 장치도 아닙니다. 여기서 말하는 기억은 복원 가능한 형태로 버전 관리되는 요소이고, 스킬은 실행하면 같은 입력에 같은 출력을 내는 결정적인 모듈입니다. 저는 이 구분이 마음에 들었습니다. 이름이 그럴듯해서가 아니라, 각 장치가 실패했을 때 탓할 곳이 달라지기 때문입니다. 기억이 틀리면 복원 과정을 보고, 스킬이 틀리면 실행 출력을 보면 됩니다.

문서가 먼저 만들어지고 제안이 모이는 흐름

이제 데이터가 어떻게 흐르는지 따라가 보겠습니다. 출발점은 문서입니다. 문서를 통째로 모델에 밀어 넣는 대신, 문서마다 상태를 따로 만듭니다. 이 상태는 문서의 내용을 복원할 수 있는 형태로 보관되고, 나중에 필요할 때 꺼낼 수 있습니다. 버전도 함께 관리됩니다. 문서가 바뀌면 해당 상태만 다시 만들면 되고, 다른 문서의 상태를 전부 손댈 필요는 없습니다.

다음으로 스킬이 있습니다. 스킬은 학습된 가중치로 어림하는 모듈이 아니라, 정해진 절차를 실행하는 결정적인 장치에 가깝습니다. 이를테면 산술 같은 과제에서는 실제로 계산을 수행하고 그 결과를 내놓습니다. 이 결과가 그냥 숫자로 던져지는 것이 아니라, 모델이 신경망으로 그려낼 수 있는 관찰 형태로 바뀝니다. 뒤에서 다시 다루겠지만, 결과를 어떤 모양으로 보여주느냐가 생각보다 크게 작용합니다.

이렇게 만들어진 것들은 타입 있는 제안이라는 형태로 공유 언어모델 상태에 기여합니다. 타입이 있다는 말은 아무 데나 섞이는 것이 아니라 어디에 붙을 수 있는지가 정해져 있다는 뜻입니다. 같은 인터페이스 노드에 여러 제안이 붙을 수 있고, 그 제안들은 서로 어긋날 수 있습니다. 문서 A의 상태가 가리키는 방향과 문서 B의 상태가 가리키는 방향이 다를 수 있고, 스킬의 계산 결과가 문서의 기억과 다를 수도 있죠.

저는 여기서 흐름을 머릿속으로 한 번 돌려봤습니다. 문서가 많아질수록 제안도 많아질 텐데, 그때마다 모델이 모든 제안을 처음부터 다시 읽는다면 조립식이라는 말이 무색해집니다. 그래서 provenance가 통제된 질의 구성이 뒤에 등장합니다. 어떤 제안이 어디에서 왔는지를 알면서 필요한 것만 주소로 찾아오게 하는 장치입니다. support를 의식한 어휘 인덱스가 기억 요소들을 찾아갈 수 있게 돕는 것도 같은 맥락입니다. 전부 펼쳐 놓고 고르는 것이 아니라, 출처를 따지면서 필요한 것만 붙이는 것이죠. 이 장면이 실제로 얼마나 잘 동작하는지는 뒤의bounded attachment 실험이 아니라 제한된 붙임 실험에서 조심스럽게 다뤄집니다.

서로 다른 제안을 하나로 맞추는 잔차 연산자

서로 다른 제안이 한곳에 모이면 어긋남이 생깁니다. 이 논문에서 잔차라는 말을 쓰는 이유가 여기에 있습니다. 각각의 제안이 저마다의 답을 주장할 때, 그 차이를 재고 조정하는 연산자를 따로 두겠다는 것입니다. 모든 능력을 하나의 파라미터 업데이트로 섞는 대신, 어긋난 만큼을 명시적으로 다루겠다는 발상입니다.

이 연산자가 붙는 자리가 공통 인터페이스 노드입니다. 말하자면 여러 제안이 같은 주소로 배달되는 지점입니다. 문서 상태에서 온 제안과 스킬에서 온 제안이 같은 노드에 붙으면, 연산자는 그 제안들을 견주어 공유 상태를 조정합니다. 저는 이 장면을 회의실에 비유하면 이해가 쉬웠습니다. 각자 자료를 들고 와서 같은 안건에 의견을 붙이면, 누군가는 그 의견들의 차이를 정리해야 합니다. 그 정리 담당이 잔차 연산자입니다. 물론 회의실의 비유는 여기까지입니다. 실제 연산자는 학습되거나 설계된 조정 규칙으로 동작하니까요.

여기서는 조금 조심해서 읽을 필요가 있습니다. 잔차 연산자가 있다고 해서 모든 충돌이 깔끔하게 풀리는 것은 아닙니다. 제안이 서로 정면으로 contradicted될 때, 이를테면 문서끼리 사실이 다르게 적혀 있을 때 어떤 제안을 살려야 하는지는 여전히 어려운 문제입니다. 연산자는 어긋남을 재는 자이지, 진실을 가려내는 심판은 아니니까요. 저는 그래서 이 연산자를 만능 해결사라기보다 책임의 분리로 봅니다. 만드는 쪽은 제안의 품질에 책임지고, 맞추는 쪽은 어긋남을 다루는 데 책임지는 식으로요.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 제안이 수천 개로 늘어나면 이 조정 비용은 어떻게 될까요. 매번 모든 제안을 다 맞추는 일은 조립식의 장점을 갉아먹을 수 있습니다. 그래서 제한된 붙임 실험이 중요합니다. 일부 증거만 붙였을 때 효과가 어떻게 달라지는지를 재는 일은, 연산자가 감당해야 할 범위를 가늠하는 일이기도 합니다. 이 대목은 뒤에서 다시 짚겠습니다.

attention을 빼고도 언어모델이 돌아갈까

이 논문에서 제가 가장 오래 쳐다본 실험은 Multi-Mesh라는 프로토타입입니다. attention 없이 인과적 언어모델링을 학습한다는 설명을 보면, 요즘 논문에서 흔히 보는 과장처럼 느껴질 수 있습니다. 그런데 저자는 한 발 물러선 표현을 함께 둡니다. 학습은 되지만 경쟁력 있는 일반 능력을 입증하지는 못했다는 식으로요. 저는 이런 문장을 보면 오히려 신뢰가 갑니다. 안 되는 것을 안 된다고 적어 두는 편이 다음 연구의 시간을 아껴주니까요.

attention을 뺀다는 것은 Transformer에서 문맥을 섞는 도구를 빼는 일입니다. 그 빈자리를 메시 구조와 제안과 잔차 조정으로 메워 보겠다는 것인데, 언어가 어느 정도까지 굴러가는지를 보는 데 의의가 있습니다. 실제로 인과적 언어모델링이 학습된다는 것은, 이 조립식 구조가 아주 기초적인 다음 토큰 예측의 고리는 만들 수 있다는 뜻입니다. 다만 그것이 곧바로 실용적인 모델이 된다는 뜻은 아닙니다. 일반 능력이라는 말에는 추론과 지식과 지시를 따르는 일까지 들어 있는데, 프로토타입은 그 넓은 범위를 보여주지 않습니다.

저는 이 결과를 실패로 읽지 않습니다. 새로운 하드웨어를 만들 때 처음에는 전구에 불이 들어오는지만 확인하는 것과 비슷합니다. 불이 들어왔다고 해서 도시의 전력을 맡길 수는 없지만, 회로가 끊어지지 않았다는 사실은 다음 설계의 출발점이 됩니다. Multi-Mesh도 그런 자리라고 봅니다. 조립과 잔차 조정만으로 언어의 기초 고리가 돌아간다는 것을 보였고, 그 다음에 무엇을 얹어야 일반 능력이 될지는 남겨 두었습니다.

그렇다면 이 흐름은 어디에서 이어질 수 있을까요. attention을 다시 들여오는 것일 수도 있고, 메시의 연결을 더 촘촘하게 만드는 것일 수도 있습니다. 혹은 문서 상태와 스킬 제안을 더 잘 만드는 쪽일 수도 있죠. 저는 특히 후자가 궁금했습니다. 기초 회로가 돌아가는 것을 확인했다면, 다음 병목은 제안의 품질일 가능성이 크기 때문입니다. 기억이 얼마나 정확히 복원되는지, 스킬의 출력이 얼마나 잘 전달되는지가 그 다음을 가를 것 같습니다.

다섯만 개가 넘는 기억이 말하는 솔직한 성적표

기억 저장소에 대한 숫자는 이 논문에서 드물게 구체적인 장면입니다. 버전 관리되는 저장소에 52,809개의 복원 기억 요소가 들어 있고, 전체 예산은 17억 개 안팎의 실수 값 근처이며, 토큰 정확도는 75% 안팎이라고 보고됩니다. 저는 이 숫자보다 그 뒤의 구조가 더 중요하다고 봅니다. 숫자는 성적표이고, 구조는 공부 방식이니까요. 하지만 성적표가 솔직하다는 점도 짚고 싶습니다. 75%는 복원이 불완전하다는 뜻을 숨기지 않습니다.

52,809개라는 수는 어떻게 읽어야 할까요. 문서마다 상태를 따로 만든다는 설계에서는 자연스러운 규모입니다. 문서가 늘어나면 요소도 늘어납니다. 전체를 하나의 가중치 덩어리로 외우는 대신, 요소 단위로 나눠 보관한다는 발상이 숫자로 드러난 것이죠. 17억이라는 예산도 같은 맥락에서 봐야 합니다. 모델 전체 파라미터와 직접 비교하기보다, 기억이라는 별도의 저장 공간에 얼마를 쓰는지로 읽는 편이 정확합니다. 토큰을 75% 맞춘다는 것은 네 개 중 세 개는 맞고 하나는 어긋난다는 뜻인데, 복원용 기억으로는 아쉬운 성적입니다.

그런데 저는 여기서 멈칫했습니다. 75%라는 숫자가 낮다고 해서 이 구조가 쓸모없다고 말할 수 있을까요. 복원이 불완전해도, provenance가 통제된 질의로 필요한 것만 골라 쓸 수 있다면 이야기가 달라집니다.全部를 통째로 올리는 것이 아니라 실제 질문과 관련된 요소만 주소로 찾아 붙인다면, 불완전한 기억이라도 도움이 될 수 있습니다. support를 의식한 어휘 인덱스가 바로 그 주소 체계입니다. 어떤 기억이 어떤 질문에 답할 수 있는지를 따져가며 찾아오게 돕는 것이죠.

운영의 아침을 떠올리면 이 차이는 꽤 크게 느껴집니다. 밤사이 문서가 바뀌어도 해당 요소만 다시 만들면 되고, 질의할 때는 전체 저장소를 통째로 올리지 않고 필요한 것만 붙일 수 있다면 버전 관리와 서빙이 모두 가벼워집니다. 물론 75%라는 복원율이 실제 답변 품질로 어떻게 이어지는지는 따로 봐야 합니다. 복원 정확도와 답변 정확도는 같은 측정이 아니니까요. 저는 그래서 이 장면을 가능성半 한계半으로 읽었습니다. 나눠서 관리한다는 방향은 분명하고, 복원의 품질은 아직 갈 길이 남았다는 식으로요.

계산 결과를 어디에 놓느냐가 결과를 바꾼다

산술 스킬에 대한 실험은 이 논문에서 가장 손으로 만져지는 장면입니다. 같은 계산 결과라도 어떻게 보여주느냐에 따라 신경망이 그려내는 답이 달라진다는 것입니다. 반복되는 전역 결과 벡터를 매번 똑같이 보여주는 것보다, 위치별 결과 관찰을 주는 쪽이 훨씬 낫다고 보고됩니다. 저는 처음에 이 말을 보고 고개를 갸웃했습니다. 정답이 같은데 보여주는 모양이 뭐가 그리 중요할까 싶어서요.

곰곰이 생각해 보면 사람도 비슷하게 배웁니다. 칠판에 답만 크게 적어 두는 것보다, 풀이의 각 자리에서 무엇이 나왔는지를 보여주는 쪽이 다음 문제를 푸는 데 도움이 됩니다. 신경망의 그리기 과정도 비슷한 구석이 있습니다. 전역 벡터는 정답이라는 사실만 알려주고, 위치별 관찰은 어디에서 무엇이 나왔는지를 알려줍니다. 그리기라는 작업의 입장에서는 후자가 훨씬 친절한 힌트입니다.

여기서 치환 실험이 의미를 가집니다. 스킬의 출력을 바꾸면 모델이 선호하는 답도 바뀐다는 것입니다. 이 장면은 모델이 스킬 출력을 실제로 쓰고 있다는 증거로 읽힙니다. 외워둔 답을 내는 것이라면 스킬 출력을 바꿔도 답이 그대로여야 하는데, 그렇지 않았다는 것이죠. 저는 이 해석에 대체로 동의하면서도 한 가지를 덧붙이고 싶습니다. 의존한다는 것과 정확하다는 것은 다릅니다. 스킬에 기대고 있다는 것은 보였지만, 그 기대가 항상 옳은 방향인지는 스킬의 정확도와 전달 방식에 달려 있습니다. 그래서 위치별 관찰이라는 결과가 더 중요합니다. 의존하는 구조를 만들었다면, 다음에는 의존할 만한 형태로 주는 일이 남으니까요.

좋은 건 알겠는데, 이걸 실제로 어떻게 연결할까요. 산술처럼 답이 분명한 과제에서는 스킬의 역할이 또렷합니다. 그런데 답이 하나로 정해지지 않는 과제에서는 스킬의 출력을 어떤 타입으로 어떤 노드에 붙여야 할지가 모호해집니다. 이 논문은 산술이라는 또렷한 사례에서 전달 방식의 원리를 보여주는 데까지 갑니다. 그 너머의 모호한 과제들은 다음 연구의 몫으로 남습니다.

일부만 붙여 보는 실험이 말해주는 것과 말해주지 않는 것

이 논문을 읽을 때 가장 조심해야 할 대목이 바로 여기입니다. 선택된 증거를 붙였을 때 효과가 어떻게 달라지는지를 재는 제한된 붙임 시연이 있는데, 이를 전체 저장소를 통째로 올렸을 때의 효과로 읽으면 안 됩니다. 저자도 그 선을 긋고 있습니다. 일부를 붙여 본 결과는 일부를 붙여 본 결과일 뿐, 수십억 개 값으로 된 저장소 전체를 올리는 일의 효용을 입증하지는 않는다는 것입니다.

이 구분은 생각보다 중요합니다. 조립식 구조에서는 붙이는 범위가 곧 비용이기 때문입니다. 몇 개의 요소만 붙이는 실험에서 효과가 보였다고 해서, 수만 개를 붙이는 실제 운영에서도 같은 그림이 나온다고 보장할 수 없습니다. 붙이는 양이 늘어나면 잔차 연산자가 다뤄야 할 어긋남도 늘고, 질의 구성과 인덱스의 부담도 커집니다. 그래서 저는 이 실험을 낙관이 아니라 측정으로 읽었습니다. 선택된 증거를 쓸 수 있게 만드는 일이 어느 정도의 효과를 내는지를 잰 것이죠.

provenance가 통제된 질의 구성과 support를 의식한 어휘 인덱스도 같은 선상에서 봐야 합니다. 이 장치들은 필요한 기억을 찾아오게 돕지만, 찾은 기억이 항상 옳다는 것을 보장하지는 않습니다. 출처를 따진다는 것은 잘못된 출처를 걸러낼 가능성을 높이는 일이지, 정답을 찍어주는 일이 아닙니다. 저는 그래서 이 장치를 주소 체계로 이해했습니다. 좋은 주소 체계가 있어도, 그 주소에 있는 집이 튼튼한지는 별개의 문제니까요.

그렇다면 이 실험을 어떻게 활용해야 할까요. 저는 순서대로 읽는 편이 좋다고 봅니다. 먼저 일부를 붙였을 때 효과가 있다는 것을 확인하고, 다음에 붙이는 범위를 넓히면서 어디에서 이득이 꺾이는지를 보고, 마지막에 전체 운영 비용과 견주어 판단하는 것입니다. 이 논문은 그 첫 단계를 밟았습니다. 첫 단계만으로 전체를 말할 수는 없지만, 첫 단계 없이는 다음 질문도 없습니다.

조립식 모델이 남기는 질문과 제가 지켜보고 싶은 장면

앞에서 미뤄둔 질문으로 돌아올 차례입니다. 조립식으로 만든다고 해서 무엇이 정말 좋아질까요. 저는 세 가지로 나눠서 봅니다. 첫째는 고치는 일입니다. 문서가 바뀌면 해당 기억만 다시 만들면 되고, 계산 규칙이 바뀌면 해당 스킬만 갈아 끼우면 됩니다. 둘째는 찾는 일입니다. 출처를 따지면서 필요한 것만 붙일 수 있다면 매번 전체를 뒤지는 수고를 덜 수 있습니다. 셋째는 맞추는 일입니다. 어긋남을 명시적인 연산자로 다룬다면, 어디에서 무엇이 어긋났는지를 추적하기 쉬워집니다.

하지만 묻고 싶은 것도 많습니다. 잔차 연산자가 감당할 수 있는 어긋남의 크기는 어디까지일까요. 문서끼리 사실이 다를 때 어떤 제안을 살릴지는 누가 정할까요. 75% 안팎의 복원율은 실제 질문 답하기에서 어느 정도의 손실로 이어질까요. 수만 개 규모에서 잘 돌아간 주소 체계가 수백만 개에서도 같은 비용으로 돌아갈까요. Multi-Mesh가 보여준 기초 고리가 일반 능력으로 자라려면 무엇이 더 필요할까요. 이 질문들은 논문을 깎아내리기 위한 것이 아니라, 다음 실험을 구체적으로 만들기 위한 것입니다.

제가 앞으로 보고 싶은 것은 두 장면입니다. 하나는 버전이 바뀌는 장면입니다. 문서가 업데이트되고 기억 요소가 갈아 끼워질 때, 질의 결과와 최종 답이 어떻게 달라지는지를 보여주는 실험입니다. 조립식이라면 마땅히 잘해야 하는 일이고, 잘한다면 이 구조의 존재 이유가 분명해집니다. 다른 하나는 스킬이 늘어나는 장면입니다. 산술을 넘어선 스킬들이 같은 인터페이스에 붙을 때, 잔차 연산자가 서로 다른 종류의 제안을 어떻게 맞추는지를 보는 일입니다. 스킬이 하나일 때와 여러 개일 때의 풍경은 꽤 다를 수 있습니다.

이 논문을 덮고 나서 가장 오래 남은 생각은 이런 것입니다. 우리가 모델을 키운다는 말을 할 때, 그 말은 대체로 하나의 덩어리를 더 크게 만든다는 뜻이었습니다. 그런데 이 논문은 크기를 묻기 전에 구성을 묻습니다. 무엇을 따로 만들고, 무엇을 실행으로 맡기고, 어디에서 맞출 것인지를 먼저 정하자는 것이죠. 저는 그 순서가 마음에 들었습니다. 더 많은 계산을 얹는 일도 필요하지만, 이미 아는 것을 다시 계산하지 않고 정확히 실행되는 것을 믿고 쓰는 구조도 생각해 볼 만합니다. 앞으로 모델이 더 커질수록 몇십억 개인가보다 그 숫자가 무슨 일을 하는가가 더 자주 중요해질 것 같습니다. 이 논문은 그 질문을 조립이라는 단어로 던진 셈입니다.