
40KB에 담긴 AI, 우리는 무엇을 낭비하고 있을까요?
40KB 용량의 Z80 프로세서용 AI 프로젝트를 통해 현대 엔지니어링이 놓치고 있는 최적화의 본질과 제약 속의 창의성에 대해 고찰합니다.
송찬영
CTO

안녕하세요. 풀링포레스트 CTO 송찬영입니다.
최근 우리 팀 엔지니어들과 커피챗을 하다가 "모델이 너무 커서 인퍼런스(Inference) 비용을 감당하기 어렵다"거나 "GPU 리소스가 부족해 실험 속도가 나지 않는다"는 하소연을 들었습니다. 충분히 공감합니다. 거대 언어 모델(LLM)의 시대, 파라미터 수(Parameters)는 지능의 척도처럼 여겨지고, 우리는 무의식적으로 '더 큰 것'이 '더 좋은 것'이라고 믿게 되었습니다. 하지만 며칠 전 우연히 마주친 오픈소스 프로젝트 하나가 제 머리를 둔탁하게 때리는 듯한 충격을 주었습니다.
오늘은 1976년에 나온 8-bit 프로세서, Z80 위에서 돌아가는 AI 이야기를 해보려 합니다.
40KB, 그리고 Z80 프로세서
'Z80-μLM'이라는 프로젝트입니다. 최신 NVIDIA H100 GPU가 아니라, 박물관에나 있을 법한 Z80 프로세서(CP/M 운영체제)에서 구동되는 대화형 AI 모델이죠. 이 모델의 크기는 불과 40KB입니다. 우리가 흔히 쓰는 카카오톡 이모티콘 이미지 한 장보다 작은 용량입니다.
솔직히 처음엔 그저 레트로 마니아들의 '기행' 정도로 치부했습니다. 하지만 코드를 들여다보고 아키텍처를 이해하는 순간, 저는 부끄러움을 느꼈습니다. 우리는 풍족한 리소스에 취해 엔지니어링의 본질인 '최적화'와 '트레이드오프(Trade-off)'를 잊고 있었던 건 아닐까요?
무엇을 버리고 무엇을 취했는가
이 프로젝트의 개발자는 64KB RAM이라는 가혹한 제약 사항 속에서 '대화가 가능한 AI'를 구현하기 위해 극한의 다이어트를 감행했습니다.
첫째, 부동소수점(Floating point) 연산을 완전히 포기했습니다. 모든 계산은 16-bit 정수 연산으로 처리됩니다.
둘째, 가중치(Weight)를 2-bit로 양자화(Quantization)했습니다. -2, -1, 0, +1, 딱 네 가지 값만 가집니다. 이를 통해 1바이트에 4개의 가중치를 우겨넣었죠.
셋째, 입력 데이터를 완벽하게 이해하려는 욕심을 버렸습니다.

가장 흥미로운 지점은 입력 처리 방식입니다. 이 모델은 문맥이나 어순을 정교하게 파악하지 않습니다. 대신 'Trigram 해시 인코딩'을 사용해 입력 텍스트를 128개의 버킷(Bucket)으로 분류합니다. "Hello there"와 "There hello"를 구분하지 못합니다. 하지만 개발자는 이 한계를 명확히 인지하고, 대신 '오타에 강하고(Robust)', '빠르게 반응하는' 특성을 취했습니다.
그 결과, 튜링 테스트를 통과할 만큼 똑똑하진 않지만, 사용자의 입력에 대해 YES/NO/MAYBE 같은 짧고 명확한 대답을 내놓으며 묘한 '성격(Personality)'을 가진 챗봇이 탄생했습니다.
제약이 만들어낸 창의성
우리는 개발을 할 때 종종 '완벽한 범용성'을 목표로 삼습니다. 하지만 비즈니스 현장에서 모든 문제를 GPT-4 같은 거대 모델로 해결할 필요는 없습니다. 고객이 원하는 것이 단순히 "이 제품 재고가 있나요?"에 대한 답이라면, 수십억 개의 파라미터는 낭비일 수 있습니다.
Z80-μLM 개발자는 질문했습니다. "성격을 유지하면서 모델을 얼마나 작게 만들 수 있을까?" 이 명확한 목표가 있었기에 QAT(Quantization-Aware Training)를 적용하고, 불필요한 레이어를 걷어낼 수 있었습니다.
최근 풀링포레스트 내부에서도 비슷한 고민을 하고 있습니다. 특정 도메인의 고객 문의를 처리하는 데에 굳이 무거운 RAG(검색 증강 생성) 파이프라인이 필요한지, 아니면 잘 튜닝된 경량화 모델과 규칙 기반 엔진의 하이브리드가 더 효율적일지 말입니다. 이 40KB짜리 프로젝트는 "기능적이면 충분하다(Functional is enough)"라는 잊혀진 진리를 다시금 일깨워 줍니다.
엔지니어링의 본질로 돌아가며
물론 현업에서 당장 2-bit 양자화 모델을 메인 서비스에 올리자는 이야기는 아닙니다. 다만, 리소스가 부족하다는 핑계를 대기 전에 우리가 해결하려는 문제의 본질을 다시 한번 정의해보면 어떨까요?
정말로 모든 문맥을 이해해야 하는가?
100%의 정확도가 필요한가, 아니면 빠른 응답 속도와 적절한 톤앤매너가 더 중요한가?
우리가 사용하는 라이브러리와 프레임워크는 문제의 크기에 비해 너무 거대하지 않은가?
Z80-μLM은 "모델이 당신을 이해하지 못해도, 당신을 파악할 수는 있다"라고 말합니다. 기술은 도구일 뿐, 중요한 것은 그 도구가 만들어내는 가치입니다.
개발자 여러분, 때로는 최신 논문과 화려한 아키텍처에서 눈을 돌려, 극한의 제약 속에서 동작하는 코드들을 살펴보시길 권합니다. 40KB 속에 담긴 치열한 고민의 흔적이, 막막한 프로젝트를 풀어낼 새로운 영감이 되어줄지도 모릅니다.
오늘도 한정된 자원 속에서 최적의 해답을 찾느라 고군분투하는 여러분을 응원합니다.


