SQL로 8비트 CPU를 만들었다고요? PostgreSQL 위에서 돌아가는 MOS 6502 에뮬레이터

대체 왜 SQL로 CPU를 만드는 거죠?

프로그래밍의 세계에는 "할 수 있으니까 한다"는 부류의 프로젝트가 있어요. 엑셀로 게임 엔진을 만든다든지, HTML로 운영체제를 만든다든지 하는 것들이요. 이번에 소개할 프로젝트 pg_6502도 딱 그런 부류인데요, 놀랍게도 PostgreSQL의 SQL만으로 MOS Technology 6502 8비트 마이크로프로세서를 통째로 에뮬레이션하는 프로젝트예요.

MOS 6502가 뭐냐면, 1975년에 나온 8비트 CPU인데요, 애플 II, 닌텐도 패미컴(NES), 코모도어 64 같은 전설적인 컴퓨터와 게임기에 쓰였던 프로세서예요. 당시 기준으로 엄청 저렴하면서도 성능이 괜찮아서 개인용 컴퓨터 혁명의 핵심 부품이었거든요. 지금도 레트로 컴퓨팅이나 임베디드 교육에서 자주 다루는 칩이에요.

SQL이 이걸 어떻게 처리하나요?

보통 CPU 에뮬레이터는 C나 Rust 같은 시스템 언어로 만들잖아요. 근데 이 프로젝트는 PostgreSQL의 PL/pgSQL(Postgres에서 쓸 수 있는 절차적 프로그래밍 언어)을 사용해서 CPU의 모든 동작을 구현했어요.

이게 뭐냐면, SQL은 원래 데이터를 조회하고 조작하는 용도로 만들어진 언어거든요. "SELECT * FROM users WHERE age > 20" 이런 식으로 쓰는 거죠. 그런데 PostgreSQL의 PL/pgSQL을 쓰면 변수 선언, 조건문, 반복문 같은 일반 프로그래밍 기능을 SQL 안에서 쓸 수 있어요. 이걸로 CPU의 레지스터(A, X, Y 같은 작은 저장 공간), 프로그램 카운터(지금 실행 중인 명령어 위치), 스택 포인터(함수 호출 시 돌아갈 위치를 기억하는 장치) 같은 것들을 전부 PostgreSQL 테이블과 함수로 표현한 거예요.

6502 CPU는 약 56개의 명령어(opcode)를 가지고 있는데, 각 명령어마다 SQL 함수가 하나씩 대응돼요. 예를 들어 LDA(Load Accumulator, 값을 레지스터에 불러오는 명령)는 테이블에서 메모리 값을 읽어서 레지스터 역할을 하는 변수에 넣는 SQL 함수로 구현되는 식이에요. 메모리는 64KB짜리 바이트 배열을 PostgreSQL의 bytea 타입이나 테이블로 표현하고요.

주소 지정 모드(addressing mode)라는 것도 있는데요, 이게 뭐냐면 CPU가 데이터를 찾을 때 "바로 이 값을 써라", "이 주소에 있는 값을 써라", "이 주소에 있는 값을 오프셋만큼 더한 주소의 값을 써라" 같은 다양한 방법이 있거든요. 6502에는 13가지 주소 지정 모드가 있는데, 이것도 전부 SQL로 구현되어 있어요.

이런 프로젝트가 왜 의미 있을까?

"그래서 실용적으로 쓸 데가 있나요?"라고 물으시면, 솔직히 프로덕션에서 SQL로 CPU를 돌릴 일은 없겠죠. 하지만 이런 프로젝트가 주는 가치는 다른 데 있어요.

첫째, CPU 아키텍처를 이해하는 데 정말 좋은 교육 자료예요. 고수준 언어로 에뮬레이터를 만들면 하드웨어의 동작 원리가 추상화 뒤에 숨겨지기 쉬운데, SQL처럼 제약이 많은 언어로 만들면 "레지스터가 정확히 뭘 하는 건지", "fetch-decode-execute 사이클이 실제로 어떤 단계를 거치는 건지" 하나하나 명시적으로 풀어내야 하거든요. 그 과정 자체가 굉장히 좋은 학습이 돼요.

둘째, SQL과 PostgreSQL의 표현력을 보여주는 사례이기도 해요. 사실 SQL은 튜링 완전(Turing complete)한 언어예요. 이게 뭐냐면, 이론적으로 어떤 계산이든 할 수 있다는 뜻이에요. pg_6502는 그 이론을 실제로 증명해 보인 셈이죠. 여러분이 매일 쓰는 PostgreSQL이 얼마나 강력한 도구인지 다시 한번 느낄 수 있는 프로젝트예요.

비슷한 "무모한 도전" 프로젝트들

이런 류의 프로젝트는 개발 커뮤니티에서 하나의 장르처럼 존재해요. 예전에 Tom Dalling이라는 개발자가 Excel 스프레드시트 안에서 CPU를 만든 적이 있고, Conway의 Game of Life 안에서 튜링 머신을 구현한 프로젝트도 유명하죠. SQL 쪽으로 좁히면, SQL로 만든 레이트레이서(3D 렌더러)나 SQL로 구현한 테트리스 같은 프로젝트도 있어요.

이런 프로젝트들의 공통점은, 도구의 한계를 의도적으로 밀어붙여서 도구와 문제 도메인 둘 다에 대한 깊은 이해를 끌어낸다는 거예요. 제약이 창의성을 낳는다는 말이 딱 이런 경우에 해당돼요.

한국 개발자에게 주는 시사점

당장 실무에 적용할 프로젝트는 아니지만, 몇 가지 관점에서 들여다볼 가치가 있어요. 먼저, 기술 면접에서 자주 나오는 "컴퓨터 구조" 개념을 코드로 직접 만져보고 싶다면 이 프로젝트의 소스 코드를 읽어보는 것만으로도 좋은 공부가 돼요. fetch-decode-execute 사이클, 스택 동작, 인터럽트 처리 같은 개념이 SQL 함수로 명확하게 분리되어 있거든요.

또, PostgreSQL을 단순히 데이터 저장소로만 쓰고 있다면, PL/pgSQL의 가능성을 다시 한번 생각해볼 기회이기도 해요. 물론 비즈니스 로직을 전부 DB에 넣으라는 얘기는 아니지만, 적절한 곳에서 PL/pgSQL을 활용하면 애플리케이션 레이어와 DB 사이의 왕복을 줄이는 데 도움이 되기도 하거든요.

마무리

SQL로 CPU를 만든 이 프로젝트는 실용성보다는 "컴퓨터 과학의 본질"과 "도구의 한계 탐구"에 대한 이야기예요. 제약 속에서 무언가를 만들어본 경험이 결국 더 나은 엔지니어로 성장하는 밑거름이 되기도 하니까요. 여러분이라면 어떤 "무모한 도전" 프로젝트를 해보고 싶으세요? 혹시 엑셀이나 SQL로 만들어본 황당한 프로젝트가 있다면 공유해주세요!