Reddit r/LocalLLM에 별난 실험이 올라왔다. Qwen3.5-4B 모델의 가중치 안에 64비트 x86 컴퓨터를 통째로 집어넣었다는 것. u/BlackQuazi가 공개한 Qwenx86-4B-compact가 그 주인공이다. 문장만 읽으면 과장처럼 들리는데, 구조를 들여다보면 나름의 논리가 있다. 다운로드받은 가중치 파일 하나가 곧 계산기를 갖춘 작은 컴퓨터가 되는 셈이다. 댓글 반응은 감탄과 “그래서 왜?”가 절반씩 갈려 있는데, 그 지점이 오히려 읽어볼 가치를 만든다.
트랜스포머 레이어는 보통 방대한 텍스트를 학습하며 채워진 가중치로 구성된다. 이 모델은 다르다. 열세 개 레이어에는 학습으로 얻은 가중치가 아예 없다. 그 자리의 값들은 전부 컴파일러가 계산해 박아 넣은 것. 모델 안쪽에 작은 x86 머신이 상주하고, Qwen이 평소처럼 툴 콜(<tool_call>)을 던지면 가중치 안에서 그 컴퓨터가 도구를 대신 실행한다.
전자계산기, Python 인터프리터, C 컴파일러, 메모 저장소, 물리·화학 수치 조회, Python 공식 문서 조회까지 전부 체크포인트 안에 펌웨어로 들어 있다. 별도의 실행 환경도 없고 외부 API도 없다. 가중치 파일이 곧 실행 환경인 셈이다. compact 버전 기준 GPU 메모리는 9GB 정도라 16GB 카드에서도 돌아간다.
모델 입장에서는 평소와 같은 툴 콜이다. 다른 점은 수신자가 외부가 아니라 자기 자신 안에 있다는 것.
<tool_call>
{"name": "run_c", "arguments": {"code": "printf(\"hello from the weights\");"}}
</tool_call>
발행자가 함께 공개한 Qwenx86 Debugger 스페이스가 이 실험을 가장 잘 보여준다. 실제로 기록된 툴 콜을 하나하나 따라가 보면, 대화 흐름과 x86 레지스터와 플래그, 프로그램 카운터가 가리키는 코드, RAM과 기계 출력이 한 화면에 나열된다. 검증에 통과한 블록들은 타임라인 위에 정리된다. LLM이 도구를 호출하고 그 결과를 받아 적는 익숙한 장면을, CPU 관점에서 다시 보는 셈이다.
재미있는 건 댓글의 온도다. 최상위 댓글은 “내가 너무 멍청해서 이게 왜 유용한지 모르겠다”였고, 이어지는 질문들도 “LLM 안의 CPU는 자기 RAM을 갖고 있나? 그 CPU 위에 다른 LLM을 돌릴 수 있나? 그리고 Doom은 돌아가나?” 같은 방향이었다. “Okay, but why?” 같은 반응도 있었다. 장난스럽지만 방향은 분명하다. 가능성보다 쓸모가 먼저 궁금해진다는 뜻이고, 그건 어느 신기술이나 마찬가지다.
계산기나 단순 스크립트 정도라면, 모델이 백그라운드에서 파이썬을 호출하는 것으로도 충분하다. 그런데 이 접근이 가리키는 건 조금 다른 성질의 문제다. 툴 실행이 모델 가중치 안에서 일어나면, 그 결과는 외부 환경의 불확실성에서 잘라나온다. 네트워크도, 컨테이너도, 샌드박스 우회도 없다. 체크포인트를 받은 사람은 같은 입력에 대해 같은 기계 상태를 얻는다. 디버거가 레지스터 단위까지 기록하는 것도 이 때문이다. 모델이 뭐라고 적었는지가 아니라, 실제로 어떤 명령이 어디서 실행됐는지까지 남는다.
정리하면 이렇다. 계산기나 수치 조회처럼 잘 정의된 작업은 가중치 안에 넣으면 결정적이고 검증 가능해진다. 추론, 요약, 코드 작성처럼 언어 모델이 잘하는 일은 여전히 학습된 레이어 몫이다. 경계를 어디에 둘지가 이 실험이 던지는 실제 질문이다.
당장 실무에 바로 붙일 도구로 보기는 어렵다. 레이어 열세 개를 컴파일러 출력으로 대체했다는 발상 자체가 실험실 성격이고, 댓글의 회의적인 반응도 정당하다. 그래도 인상적인 건 남는다. 모델과 도구의 경계가 프롬프트나 플러그인 수준이 아니라 가중치 수준까지 내려올 수 있다는 증거라서. ‘AI 안에 컴퓨터가 있다’는 말이 은유가 아니게 되는 날이 올지는 아직 모르겠다. 다만 오늘 올라온 글 하나가 그 날의 초안을 조금 앞당겨 준 것은 확실하다.