최근 흥미로운 소식이 하나 나왔습니다. 트랜스포머(LLM) 안에 '컴퓨터'를 심어서, 외부 도구 없이도 C 코드급 프로그램을 모델이 직접 실행하고, 그것도 매우 빠르게 돌린다는 이야기입니다1. 이게 왜 중요하냐면, LLM이 잘하는 "설명"과 못하는 "계산" 사이의 오래된 틈을 메우는 방향이기 때문입니다.
핵심은 간단합니다. 지금까지는 LLM이 계산이 필요하면 파이썬 같은 외부 도구를 호출해 결과만 받아오는 방식이 주류였죠. 그런데 이번 접근은 실행 자체가 모델 내부 토큰 생성 과정에서 일어나며, 그 과정이 '느린 자기회귀 디코딩'의 약점을 정면으로 건드립니다.
LLM이 '생각'은 하는데 '계산'은 못하는 이유
요즘 모델은 어려운 수학 증명 스타일 문제를 그럴듯하게 풀어내는데도, 자릿수 큰 덧셈이나 스도쿠처럼 "정확히" 많은 단계를 밟아야 하는 작업에서 자주 무너집니다. 이유는 모델이 멍청해서가 아니라, 트랜스포머의 기본 작동 방식이 '긴 실행 기록'을 다루기에 불리하기 때문입니다.
트랜스포머는 토큰을 하나 생성할 때마다, 지금까지 쌓인 문맥(프리픽스) 전체를 어텐션으로 훑으며 다음 출력을 정합니다. KV 캐시가 있어도 "과거를 다시 계산"만 줄여줄 뿐, "과거를 훑는 비용" 자체는 길이에 따라 커집니다. 즉, 실행 단계가 길어질수록 한 스텝의 비용도 함께 비싸지는 구조입니다. 트랜스포머가 본질적으로 긴 문맥에서 비용이 커지는 이유가 여기에 있습니다2.
외부 도구 대신 "모델 내부 실행"이 의미하는 것
툴 유즈(tool use)는 실무적으로 매우 유용합니다. 모델이 코드를 쓰고, 인터프리터가 실행하고, 모델이 결과를 말해주면 끝이니까요. 하지만 이 방식은 계산이 "모델 바깥"에서 일어나며, 중간 상태는 대체로 블랙박스입니다.
반면 "모델 내부 실행"은 토큰 스트림 자체가 실행 로그가 됩니다. 예를 들어 스택이 늘고 줄고, 연산이 적용되고, 출력이 나오는 모든 과정이 토큰으로 남습니다1. 이 차이는 단순한 로맨스가 아니라, 신뢰성과 디버깅 가능성으로 이어집니다. 계산이 길어질수록 사람도, 시스템도 "중간을 볼 수 있느냐"가 중요해지니까요.
여기서 흥미로운 포인트는, 이들이 범용 언어를 바로 실행한 게 아니라 C 같은 코드를 WebAssembly 같은 낮은 수준의 명령으로 바꿔 토큰화해 실행하는 쪽을 택했다는 점입니다1. "자연어로 계산을 잘하길 기대"하기보다, "실행하기 쉬운 형태로 컴파일"해서 모델이 따라가기 쉽게 만든 셈이죠.
'기하급수로 빠른 추론'은 결국 어텐션 비용의 재설계다
뉴스의 가장 도발적인 문장은 "추론이 기하급수로 빨라진다"는 표현입니다. 여기서 말하는 포인트는 모델이 갑자기 초지능이 됐다는 뜻이 아니라, 실행 로그(트레이스)를 따라갈 때 필요한 조회 비용을 구조적으로 줄였다는 의미에 가깝습니다.
일반 디코딩은 매 스텝마다 과거 전체를 선형으로 스캔하듯 어텐션을 해야 합니다. 그런데 특정한 제약(예: 헤드 차원을 매우 작게 제한하는 등)을 걸면, 실행에 필요한 "찾기/갱신"을 매번 풀 스캔하지 않고 더 빠르게 처리하는 경로를 만들 수 있다는 주장입니다1. 쉽게 말해, '끝까지 다 뒤져보는' 습관을 버리고 '찾아야 할 것만 빨리 찾는' 데이터 구조처럼 어텐션을 쓰는 느낌에 가깝습니다.
이게 사실이라면, LLM 추론 최적화의 세계가 "커널 튜닝/양자화/병렬화" 중심에서 "디코딩 자체의 알고리즘" 쪽으로도 크게 확장됩니다. 물론 시스템 최적화가 사라지는 건 아닙니다. 예를 들어 torch.compile은 그래프 캡처와 커널 퓨전으로 20~40%대의 실전 속도 향상을 자주 보여주고2, DeepSpeed 같은 서빙 스택은 커널 인젝션·병렬화로 지연시간을 계속 깎습니다3. 다만 이 뉴스는 "한 토큰을 뽑는 방식" 자체를 계산 실행에 맞게 바꾸면, 레이어/커널 최적화와는 차원이 다른 구간이 열린다고 말하는 쪽에 가깝습니다.
시사점
첫째, 앞으로 "LLM은 컴퓨터가 아니다"라는 말은 점점 덜 유용해질 수 있습니다. 중요한 건 철학이 아니라, 어떤 형태로든 모델이 긴 실행을 안정적으로 굴릴 수 있느냐입니다.
둘째, 제품 관점에선 선택지가 늘어납니다. 외부 도구 호출(보안·지연·비용 이슈)을 줄이고 싶다면, 내부 실행은 매력적인 대안이 될 수 있습니다. 특히 브라우저/엣지처럼 네트워크 왕복이 치명적인 환경에선 로컬 실행 최적화 트렌드와도 잘 맞물립니다4.
셋째, 당장 실무자가 가져갈 액션은 "하나로 통일"이 아니라 "워크로드 분리"입니다. 자연어 생성은 기존 최적화(컴파일, 커널, 양자화, 병렬화)를 챙기고, 긴 정확 계산은 툴 유즈를 쓰되, 앞으로는 '내부 실행형 모델/디코더'가 가능한 구간이 있는지 관찰하는 게 좋습니다. 결국 LLM 추론의 미래는 모델 크기만이 아니라, 디코딩과 실행 표현(컴파일)의 설계가 좌우할 가능성이 커졌습니다.
참고
1Executing programs inside transformers with exponentially faster inference
2Transformer (deep learning) - Wikipedia
3Getting Started with DeepSpeed for Inferencing Transformer based Models
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.