왜 다들 둠(Doom)을 돌리려고 할까요?
개발자 커뮤니티에는 오래된 밈이 하나 있어요. "그거 둠 돌아가요?(Can it run Doom?)"인데요. 임신 테스트기, 냉장고, 프린터까지, 화면과 칩이 달린 물건이라면 뭐든 둠을 돌려보는 문화죠. 그런데 이번 이야기는 차원이 달라요. 남이 만든 기기에 둠을 올린 게 아니라, CPU 자체를 밑바닥부터 직접 설계하고 그 위에서 둠을 돌린 뒤 그 과정을 블로그에 풀어낸 이야기거든요. 글쓴이는 이 글이 순식간에 퍼지면서 겪은 후일담까지 함께 담았어요.
1993년 게임인 둠이 왜 아직도 궁극의 테스트냐면요, 요구하는 게 은근히 많아서예요. 32비트 연산이 되는 프로세서, 수 메가바이트의 메모리, 초당 수십 번 화면을 다시 그리는 그래픽 출력, 키 입력 처리까지 전부 필요하거든요. 즉 둠이 돌아간다는 건 '컴퓨터로서 갖출 건 다 갖췄다'는 졸업 증명서 같은 거죠.
CPU를 직접 만든다는 것
CPU를 만든다고 하면 실리콘 공장부터 떠올리기 쉬운데, 이런 프로젝트는 보통 FPGA를 써요. 이게 뭐냐면, 내부 회로를 소프트웨어처럼 다시 구성할 수 있는 칩이에요. Verilog 같은 하드웨어 기술 언어로 '이런 회로를 만들어줘'라고 코드를 쓰면, FPGA가 그 회로로 변신하는 거죠. 레고 블록으로 진짜 동작하는 기계를 조립하는 느낌이에요.
설계는 크게 이런 단계를 거쳐요. 먼저 명령어 집합(ISA)을 정해요. CPU가 알아듣는 단어장 같은 건데, 요즘은 오픈 표준인 RISC-V를 채택하는 경우가 많아요. 그래야 GCC 같은 기존 컴파일러를 그대로 쓸 수 있거든요. 다음은 명령어를 가져오고(fetch), 해석하고(decode), 실행하는(execute) 파이프라인을 회로로 구현하고, 메모리 컨트롤러를 붙여요. 둠을 돌리려면 여기에 프레임버퍼도 필요해요. 메모리의 특정 영역에 픽셀 값을 쓰면 그게 화면에 나가는 구조인데, 키보드 입력도 비슷하게 특정 주소를 읽으면 눌린 키를 알 수 있게 만들어요. 이런 걸 메모리 맵드 I/O라고 불러요. CPU 입장에선 화면도 키보드도 그냥 '특별한 주소의 메모리'인 셈이죠.
소프트웨어 쪽에서는 doomgeneric이라는 포팅용 프로젝트가 효자예요. 원본 둠 소스를 정리해서, 화면 그리기·키 입력·시간 읽기 같은 함수 몇 개만 내 플랫폼에 맞게 구현하면 돌아가게 해둔 코드거든요. 물론 말이 쉽지, 하드웨어 버그는 printf도 디버거도 없는 세계라서, 파형(waveform)을 들여다보며 어느 클럭 사이클에서 값이 잘못됐는지 추적하는 고행이 기다리고 있지만요. 소프트웨어 버그와 하드웨어 버그가 섞여 있으면 어느 쪽 탓인지 가려내는 것부터가 일이에요.
업계 맥락: 하드웨어 자작의 황금기
지금은 이런 도전을 하기에 제일 좋은 시대예요. RISC-V 덕분에 명령어 집합을 라이선스 걱정 없이 쓸 수 있고, 저렴한 FPGA 보드와 오픈소스 툴체인이 갖춰졌고, nand2tetris처럼 논리 게이트부터 게임까지 만들어보는 교육 과정도 잘 정리돼 있거든요. 학부생이나 심지어 고등학생이 자작 CPU를 들고 나오는 사례가 계속 나오는 이유죠.
한국 개발자에게
웹이나 앱 개발만 하다 보면 CPU는 그냥 '알아서 돌아가는 것'이 되기 쉬운데요. 캐시가 왜 중요한지, 컴파일러가 뭘 해주는지 같은 감각은 이런 저수준 경험에서 나와요. 당장 CPU까지는 아니어도, 고전 게임기 에뮬레이터 만들기나 doomgeneric을 라즈베리파이 베어메탈에 포팅해보는 것부터 시작해도 훌륭한 사이드 프로젝트예요. 과정을 블로그로 기록하면 포트폴리오로서의 임팩트는 말할 것도 없고요.
한줄 정리: 둠 구동은 자작 컴퓨터의 졸업식이고, RISC-V와 FPGA 덕분에 그 졸업장은 생각보다 가까이 있어요.
여러분이 '언젠가 해보고 싶은' 저수준 프로젝트는 뭔가요? 에뮬레이터, 자작 OS, 아니면 CPU까지 가보실 건가요?
🔗 출처: Hacker News