Opus 5.5는 프롬프트 두 번만으로 작동하는 가중치와 코드를 만들어 냈음. 첫 번째로 https://divagr.com/blog/qwenputer와 관련 소스를 읽고, FPGA 기반 에뮬레이션처럼 이 기법으로 NES의 칩과 RAM을 구현할 수 있는지, 필요한 모델 크기와 원래 클럭 속도 달성 가능성을 살펴보라고 요청함.
어떤 모델을 써도 느릴 것이라는 도표가 나왔지만, 재미로 해볼 만해서 두 번째로 “느려도 괜찮으니 실제로 만들어 보자. 가중치와 ROM을 지정해 실행할 CLI가 필요하다”고 요청함.
놀라운 결과지만, 사실 참고 자료와 적합성 테스트가 잘 갖춰진 과제이기도 함. 오랫동안 축적된 고전 게임 에뮬레이션 자료가 있고, Opus는 정답 명령 실행 기록이 3천 개 넘게 있는 테스트를 찾아 그에 맞춰 구현함. 가중치 생성에 활용한 원본 Qwenputer 저장소도 필수적이었음.
좋은 참고 자료, 명세, 적합성 테스트, 명확한 방향이 주어졌을 때 이런 모델이 무엇을 할 수 있는지 잘 보여 줌.
에뮬레이터는 아니지만, 나도 비슷한 분야의 다른 프로젝트가 사용하는 테스트를 가져와 검증하는 작업을 하고 있음. 아는 친구는 Claude에 Gherkin 형식의 테스트 기준을 넣는데, 결과가 엄청나게 좋아진다고 함.
좋은 정답 기준이 얼마나 큰 도움이 되는지 생각하게 됨. Qwenputer와 훌륭한 NES 참고 자료가 그런 역할을 한 셈임. 인간에게도 교사, 백과사전, 학위와 박사과정 같은 기준이 필요한 듯함.
원리적으로 LLM 가중치 안에 작은 가상 머신을 컴파일할 수 있을 듯함. 그 안에서 Python 인터프리터, 셸, sed·cat·grep 같은 도구를 실행하면, 느린 자기회귀 토큰 생성으로 외부 도구를 호출하는 대신 웹 검색을 제외한 모든 작업을 행렬 곱셈만으로 내부 실행할 수도 있음.
일괄 처리하도록 최적화하거나, LLM의 순전파 과정을 한 단계씩 따라가는 gdb 같은 프로그램도 가능할 듯함. 그냥 엉뚱한 상상이지만 흥미로움.
고정 기능 영역의 가중치는 유지한 채 학습하면, 자기 추론 단계 안에서 그 도구들을 사용하는 법을 본래부터 아는 모델이 나올까?
꼭 가중치에 넣을 필요 없이, LLM과 별도의 내부 고정 기능 블록을 결합해도 흥미로울 듯함. 여기에 잠재 공간 추론까지 결합하면 가능성이 더 커짐. 잘 정의된 문법만 따르는 기호 실행 엔진이 특히 유용할 것 같고, Lisp도 괜찮을 듯함.
이런 기발한 구현이 좋지만, 어셈블리 코드 골프를 좋아하는 입장에서는 효율이 끔찍하게 느껴짐. 결정론적 프로그램이 AI보다 얼마나 효율적인지 새삼 실감하게 됨.
엄청나게 강력하고 효율적인 하드웨어에서 로컬 추론이 보편화되면, 가게 폐점 시간을 물었다가 잠깐 딴짓한 뒤 위로 스크롤하는 대신 다시 물어보는 날이 올 것임.
내 개인적인 LLM 활용 변화는 이랬음. 2년 전에는 장난감 같았고, 18개월 전에는 일부 작업만 가능했으며, 1년 전에는 사람이 꼼꼼히 검토해야 하는 코드를 만드는 정도였음. 6개월 전부터는 가끔 다시 시키는 것만으로 좋은 결과물을 출시했고, 3개월 전에는 하위 에이전트를 띄우는 에이전트의 관리자처럼 일하게 됨. 한 달 전에는 그 어느 때보다 빠르게 유용한 결과물을 많이 내고 있었음.
지금은 분야별 전문 에이전트 집단이 자율적으로 작업하고, 분야와 남은 사용량에 따라 집단을 바꿔 가며 이전보다 10배를 출시하고 리뷰 품질도 두 배로 높이고 있음. 규모는 날마다 커지고 실행·평가 체계도 스스로 개선함.
다음 주에는 에이전트들이 코드 골프를 우선하고, 그다음 주에는 모든 것이 어셈블리로 작성될지도 모름. 3년 만에 한 바퀴 돌아 제자리로 오는 셈임.
nesformer가 실제 콘솔보다 150~290배 느리다는 점이 좋음. 이런 프로젝트는 LLM과 일반 프로그램 사이의 막대한 연산량 차이를 드러내 줌.
예전에 LLM이 매 프레임 운영체제 전체를 환각으로 만들어 내면 된다는 얘기를 봤는데, 기술적으로 가능하다는 것은 입증된 듯함. 하지만 수천 배 느린 데다 연산량도 수천 배 필요하다면, 일반 운영체제와는 수백만 배 차이가 나는 셈임.
운영체제 전체를 매 프레임 생성하는 건 LLM의 매우 부적절한 용도임. 그나마 더 적합한 이미지·영상 모델을 포함해도 좋은 AI 활용법은 아님. DLSS처럼 게임 화면을 프레임 단위로 생성하는 기술은 나오고 있지만, 그래픽뿐 아니라 게임 환경 전체를 AI로 만들면 시간적 일관성 때문에 실제 플레이보다 시연이 더 그럴듯해 보임.
반면 필요한 기능의 코드를 그때그때 AI가 만드는 방식은 언젠가 꽤 잘 작동할 수 있음. 지금은 보안, 데이터 무결성, 테스트를 편법으로 통과하려는 경향 때문에 신뢰하기 어렵지만 장기적으로는 가능할 듯함.
이건 조금 다름. 트랜스포머로 거의 회로 수준의 에뮬레이션을 하는 방식임. CPU를 흉내 내도록 학습한 모델보다도 비효율적일 수 있지만, 학습된 근사가 아니라 정확한 에뮬레이션이라는 장점이 있음.
사람이 사실을 떠올릴 때 “아, 기억난다”로 끝내는 대신, 머릿속에서 해시값을 계산하고 데이터베이스 조회 절차를 따라간다면 훨씬 느려지는 것과 비슷함.
Electron도 결국 쓰게 만들었으니, LLM 방식 역시 간신히 쓸 만한 수준으로 만들어 밀어붙일 것 같음.
연산량 차이가 크다는 데는 동의하지만, 150~300배는 프레임워크나 언어 선택에 따른 격차보다 조금 더 큰 정도이기도 함. 모든 것을 LLM으로 처리하는 방식의 범용성을 생각하면 꽤 놀라움.
운영체제 생성에 “환각”이라는 표현이 맞는지도 모르겠음. 그렇다면 Windows 11 자체도 환각이라고 할 수 있지 않을까? 이 시스템이 백만 배 느리다고 보지는 않지만, 설령 그렇더라도 무어의 법칙을 고려하면 최악은 아님. 지금이 출발점임.
CSS 애니메이션만으로 CPU를 구현하는 것과 똑같음. 튜링 완전성을 재미있게 가르치는 방법은 되겠지만, 그 밖에는 별 의미가 없어 보임.
CPU만 모사할 줄 알았는데, Gated DeltaNet 구조로 RAM까지 모델 내부에 구현했다는 점이 놀라움. 내가 이해한 바로는 CPU, ROM, RAM을 모두 모델이 내부적으로 처리하고, 초기화 이후 외부 입력은 컨트롤러 이벤트뿐임.
대부분이 비어 있어 1GB 가중치를 약 3MB로 압축할 수 있다는 부수적인 장점도 있음.
그런데 “Nintendo라는 물건은 없다”고 하지 않았나? 당시 광고에서는 Mario도 고마워한다고 함.
nesformer는 CHIP-8과 RISC-V CPU를 Qwen3.5-4B에 컴파일한 Divyansh Agrawal의 Qwenputer를 기반으로 함. 컴파일러와 함께 Gated DeltaNet 상태를 기계의 메모리로 쓰는 기법을 재사용한다는 게 멋짐. Qwenputer도 정말 흥미로움.
이 작업의 의의를 잘 모르겠음. 디지털 논리 회로를 가중치 집합으로 표현할 수 있다는 건 당연한 것 아닌가? 내가 놓친 게 있을까?
누군가에게는 새로운 사실인 듯함. “LLM은 결정론적이지 않다”는 비판에 반박하는 데도 도움이 됨.
재미있으니까 하는 것임.
어떤 프로젝트는 가능한 것을 보여 주는 것만으로 충분하고, 만드는 즐거움 자체가 목적이 되기도 함. 다만 여기에는 놀이 자체를 넘어선 의의가 있다는 뉘앙스가 느껴지는데, 나도 그게 무엇인지는 잘 모르겠음.
이 작업과 원본 Qwenputer 모두 기술적으로 흥미롭지 않은 저질 결과물이라고 봄. 그런데 HN에서는 열광함.
README에 탐욕적 디코더가 나오는데, T>0으로 확률적 실행을 하면 어떻게 될지 궁금함. 분위기대로 돌아가는 NES가 될까, 아니면 그냥 멈출까?