Redis를 만든 antirez가 이번에는 H3-metal - Mac용 MiniMax-H3 추론 엔진을 공개함
텍스트로 영상과 오디오를 함께 생성하는 모델을 Apple Silicon에서 실행하기 위해 C, Objective-C, Metal로 만든 엔진
범용 AI 프레임워크를 가져다 쓴 것이 아니라 특정 모델을 제대로 실행하기 위한 작고 특화된 구현
최근 antirez가 만든 것들을 따라가 보면 이런 작업이 갑작스럽지는 않음
- Flux 2 Klein 순수 C 기반 추론 : 의존성 제로의 이미지 생성 엔진
- Voxtral Realtime 4B 순수 C 추론 구현 : 실시간 음성 인식
- antirez/ds4 - Metal용 DeepSeek V4 Flash 로컬 추론 엔진 : 언어 모델
이미지, 음성, 언어에 이어 영상까지 반년 만에 범위가 넓어졌지만 구현 방향은 놀라울 정도로 일관됨
가능한 한 적은 의존성, 모델에 특화된 구조, 로컬 실행, 내부 동작을 통제할 수 있는 코드
가장 오래된 시스템 언어 중 하나로 가장 최신의 AI 모델을 구현하고 있음
그런데 같은 시기에 antirez는 얼핏 반대로 들리는 말도 하고 있음
코드가 아니라 아이디어를 통제하라에서, 생성된 코드를 한 줄씩 읽는 일보다 소프트웨어가 담아야 할 아이디어와 설계를 통제하는 데 집중해야 한다고 주장함
C 시스템 프로그래밍으로 이름난 개발자가 이제는 코드 한 줄보다 아이디어를 통제해야 한다고 말하는 상황
이 두 가지가 어떻게 같은 사람에게서 나왔을까?
작고 이해할 수 있는 소프트웨어를 만들던 사람
antirez의 작업을 Redis와 AI로 나누어 보면 최근 행보가 갑자기 바뀐 것처럼 보임
하지만 그가 반복해서 강조해 온 기준을 보면 같은 작업의 연장선에 가까움
우리가 소프트웨어를 망가뜨리고 있음에서는 불필요한 복잡성, 터무니없는 의존성 사슬, 유행하는 프레임워크마다 뛰어드는 문화를 한 문장씩 나열하며 비판함
특히 "바퀴를 다시 만들지 말라"는 조언을 정면으로 반박함
바퀴를 재발명하는 것은 사물이 어떻게 작동하는지 배우는 방법이자 새로운 다른 바퀴를 만드는 첫 단계라는 것
Redis에 대한 본인의 평가도 비슷함
Redis에는 특별한 기술적 신기함이 많지 않음. 시작 단계에서는 유능한 시스템 프로그래머라면 누구나 작성할 수 있는 기본 데이터 구조와 네트워킹 코드의 합에 불과
그럼에도 매우 유용한 소프트웨어가 된 이유는 그 안에 담긴 아이디어와 비전 때문
AI 쪽도 최근에 시작한 일이 아님
본인 설명에 따르면 2003년에 첫 신경망 구현을 만들었고, 이후에도 PyTorch나 C로 소형 GPT 모델을 계속 실험했으며, GGUF 파일을 다루는 gguf-tools를 만들고 이탈리아어로 논문을 해설하는 AI 유튜브 채널도 운영해 옴
Claude 덕분에 구현 속도는 빨라졌지만 기본 개념은 이미 알고 있었다는 것이 본인의 정리
2024년 1월, 변화의 출발점
LLM들과 2024년 초반의 프로그래밍 동향에서 antirez는 LLM을 "많이 아는 바보(savant)" 로 규정함
문서가 부족한 ONNX 모델의 출력 형식을 몇 번의 대화로 해석해내는 식의 작업에서는 확실히 유용했음
반면 C와 시스템 프로그래밍에서는 한계가 뚜렷했음
llama.cpp의 Q6_K 양자화 포맷을 해석시켰을 때 GPT-4는 비트 위치와 부호 확장을 계속 틀렸고, 결국 이 작업은 종이와 펜, 그리고 코드를 직접 읽는 방식으로 해결함
그런데 이 글에서 가장 많이 인용된 대목은 성능 평가가 아님
Would I have been able to do it without ChatGPT? Certainly yes, but the most interesting thing is not the fact that it would have taken me longer:
the truth is that I wouldn't even have tried, because it wouldn't have been worth it.
ChatGPT 없이도 할 수 있었을까? 당연히 가능했겠지만, 가장 흥미로운 것은 더 오래 걸렸을 거라는 사실이 아님
사실은 그럴 가치가 없어서 아예 시도조차 하지 않았을 것
AI가 실력을 대체하는 것이 아니라 시작 장벽을 없앤다는 것
2년 반 뒤 한 사람이 이미지/음성/언어/영상 추론 엔진을 연달아 내놓는 상황을 설명하는 문장이 이미 여기에 있었음
2025년, LLM을 보조자로 두고 사람이 직접 통제하던 시기
인간 개발자가 LLM보다 여전히 더 뛰어난 이유는 제목 그대로임
Redis Vector Sets에서 HNSW 그래프의 링크가 모두 상호 연결인지 검증해야 했는데, 단순한 방법으로는 O(N²)가 되어 2천만 벡터 기준 로딩이 45초에서 90초로 두 배 늘어남
Gemini 2.5 PRO가 내놓은 답은 정렬 후 이진 탐색이라는 표준적인 방법이었고, 더 나은 아이디어를 요구해도 나오지 않았음
antirez는 128비트 누적자에 XOR을 적용해 상호 연결이면 상쇄되어 0이 되는 방식을 고안함
이 시점의 LLM은 아이디어를 검증하고 반론을 구하는 상대, 본인 표현으로는 "스마트한 러버덕"에 가까웠음
이후 LLM을 활용한 코딩 (2025년 여름)에서 평가는 분명히 올라감
버그를 출시 전에 잡고, Amiga용 68000 어셈블리처럼 낯선 영역까지 함께 탐색할 수 있게 됨
그는 이를 페어 디자인이라고 부름
하지만 작업 방식에 대한 요구는 지금 기준으로 보면 놀라울 정도로 엄격함
- 코드 에이전트나 IDE 통합 에이전트 사용을 지양할 것
- RAG처럼 일부 맥락만 보여주는 방식은 성능을 떨어뜨리므로, 코드베이스와 문서를 최대한 통째로 넣을 것
- 과정마다 사람이 직접 코드를 복사·붙여넣으며 흐름을 추적할 것
에이전트가 혼자 코드를 쓰는 시대가 멀지 않았다고 보면서도, 그 시점을 계속 주시하겠다는 정도의 입장
1년 뒤와 비교하기 위해 이 세 줄을 기억해 둘 필요가 있음
2026년 초, 며칠 걸리던 일이 몇 분이 됨
AI에 반대하는 분위기에 휩쓸리지 마세요에서 숫자가 바뀜
- BERT 계열 임베딩 모델 추론용 순수 C 라이브러리를 5분 만에 생성함. 약 700줄, PyTorch 대비 15% 느리지만 동일한 결과
- Redis Streams 내부 구조 변경을 설계 문서만으로 약 20분 만에 재현
- linenoise 라이브러리에 UTF-8 지원 추가: 기존에는 테스트 비용 대비 가치가 낮아 포기했던 작업
antirez는 이 방식을 자동 프로그래밍이라고 부름
만들고 싶은 결과만 말한 뒤 작동 여부도 확인하지 않는 바이브 코딩과는 구분됨
바이브 코더는 기껏해야 작동하지 않는 부분을 보고하는 정도지만, 자동 프로그래밍은 생산자의 소프트웨어 비전을 엄격히 따르는 방식
그래서 "Claude가 이 소프트웨어를 바이브 코딩해줬다"는 표현은 적절하지 않다고 봄
무슨 일이 일어나고 있는지 알면서 만든 것이라면 그것은 본인이 생산한 소프트웨어이고, 자부심을 가져도 된다는 것
그의 표현을 빌리면 프로그래밍은 이제 자동화되었지만 비전은 아직 자동화되지 않았음
AI에 반대하는 분위기에 휩쓸리지 마세요 글에는 뒤에서 다시 등장할 우려도 적혀 있음
공개 모델 덕분에 어느 정도 민주화가 이뤄지고 있지만, 이 균형이 영구적이지 않을 수 있으며 AI 기술이 소수 기업에 집중될 가능성이 있다는 것
Redis Array, 코드를 한 줄씩 읽던 단계
이 방식이 실제 프로젝트에 적용된 사례가 Redis array: 긴 개발 과정의 짧은 이야기
2026년 1월 초에 시작해 약 4개월 뒤 PR로 올라갔고, 첫 달은 통째로 명세에 썼음
두 번째 달부터 자동 프로그래밍으로 구현에 들어갔는데, 여기서 중요한 대목이 나옴
구현이 동작한 뒤에도 sparsearray.c와 t_array.c를 포함한 코드를 한 줄씩 읽으며 검토함
표면적으로 동작하는 코드가 최적이라는 뜻은 아니어서 작은 비효율과 설계 오류를 찾아 수정했고, 여러 모듈을 다시 작성함
주목할 점은 기간이 줄지 않았다는 것
본인 설명으로는 LLM 이전에도 구현 자체는 4개월 안에 가능했을 것이고, 달라진 건 같은 기간에 훨씬 더 많은 일을 했다는 점
한 달 뒤 DS4에 대한 몇 마디에서는 속도가 완전히 달라짐
DeepSeek V4 Flash 로컬 추론 엔진 DwarfStar 4(DS4) 는 일주일 만에 만들어졌고, GPT-5.5의 도움이 없었다면 그 기간에 불가능했을 것이라고 밝힘
대신 첫 일주일은 하루 평균 14시간 작업했고, Redis 초기 몇 달과 비슷한 강도였다고 덧붙임
통제의 단위가 옮겨감
그리고 2026년 8월 현재, 코드가 아니라 아이디어를 통제하라 (원문은 7월에 공개됨)
1년 전에는 "사람이 직접 코드를 복사·붙여넣으며 흐름을 추적하라"였음
지금은 "매일 5,000줄을 검토하는 방식은 현실적이지 않다" 임
Matteo Collina(Platformatic 의 CTO)가 "예전에는 Redis의 AI 생성 코드를 모두 직접 확인한다고 하지 않았느냐"고 묻자, antirez는 지금도 그렇게 하고 있지만 필요해서 하는 일이지 가치가 큰 일이라고 느끼지는 않는다고 답함
이유는 세 가지
- 하루에 수천 줄을 만들 수 있는 상황에서 전부 읽는 것은 물리적으로 불가능
- LLM은 함수 단위의 국소적으로 최적인 코드에는 매우 강하지만 큰 아이디어와 설계에는 상대적으로 약함
- 하루 8시간에서 코드를 읽는 시간은 무엇을 만들지, 다음 최적화는 무엇인지, QA를 어떻게 할지를 포기하는 선택
그래서 생성된 함수를 훑는 것보다 먼저 원하는 설계를 지시하고, "이 부분의 정확한 설계는 무엇인가", "어떻게 동작하는가"를 질문한 뒤 그 모델이 맞는지를 평가하는 편이 더 빠르다고 봄
사람이 통제해야 한다는 원칙을 버린 것이 아님
GPT-5.5를 거쳐 Fable과 GPT-5.6 Sol에 이르면서 주시하던 기준을 넘어섰다고 판단했고, 통제의 단위가 코드 한 줄에서 아이디어와 설계, QA로 이동함
지금 진행 중인 Redis sorted sets의 메모리 사용량 50% 절감 최적화에서는 Fable과 GPT-5.6의 리뷰가 자신이 직접 검토하는 것보다 더 많은 오류와 미묘한 race condition을 찾아낼 것으로 예상한다고 밝힘
AI 생성 코드에서 마음에 들지 않는 부분을 발견하기도 하지만, 다른 Redis 기여자가 쓴 기존 파일에서 더 마음에 들지 않는 코드를 더 많이 본다고도 덧붙임
많은 경우 실력보다 코딩 취향의 차이라는 것
그는 이 글에서 자신의 동기도 직접 밝힘
많은 개발자가 기존 방식에서 벗어나는 일을 자신의 분야를 배신하는 것처럼 느끼고 있으므로, 코드를 직접 쓸 수 있는 프로그래머가 먼저 새로운 방식을 씀으로써 이 변화가 개인의 능력 부족 때문이 아니라 프로그래밍 자체가 바뀌고 있기 때문이라는 메시지를 전하려 한다는 것
소스 코드보다 DESIGN.md
Redis는 많은 개발자가 파일을 직접 열어 수정하기 때문에, 사용자에 대한 존중 차원에서 지금은 생성된 코드를 계속 검토하고 있음
이 제약이 없다면 그 시간을 더 많은 QA, 다음 최적화 아이디어, 그리고 DESIGN.md 작성에 쓰고 싶다고 밝힘
DESIGN.md에는 각 데이터 구조의 핵심 아이디어, 구현 기법, 전체 설계를 사람이 이해할 수 있는 언어로 기록함
sorted sets를 수정하려는 개발자는 수천 줄의 구현을 먼저 읽는 대신 설계 문서에서 정신 모델을 이해하고, 그 모델 안에서 작업하도록 에이전트에 요청하는 방식
이 발상은 갑자기 나온 것이 아님
flux2.c를 공개하며 antirez가 밝힌 성공 요인이 정확히 같은 구조였음
이 프로젝트가 가능했던 이유는 Opus에게 IMPLEMENTATION_NOTES.md 파일을 반드시 사용하도록 지시했기 때문
개발 중 발견한 모든 사항을 이 파일에 누적하고, 항상 최신 상태로 유지하며, 컨텍스트 압축 후 즉시 처리하도록 명시함
지속적으로 갱신되는 설계 문서를 코드보다 상위에 두는 방식이 이미 반년 전에 실전에서 굳어져 있었음
왜 여전히 C이고, 왜 로컬인가
AI를 쓰면 기존 프레임워크를 조합하는 쪽이 더 쉬울 수 있음
llama.cpp에 기여하는 선택지도 있었음
antirez는 반대로 모델마다 작고 독립적인 실행기를 만드는 쪽을 택함
이유는 C에 대한 향수가 아니라 소유권의 문제에 가까움
DS4 논의에서 정리된 근거는 이런 것들임
- 소유하지 않은 성숙하고 다루기 힘든 C++ 코드베이스보다, 직접 소유한 집중된 C 코드베이스에서 작업하는 편이 훨씬 쉬움
- 큰 프로젝트에 필요한 추상화와 일반화 수준은 파일 수를 크게 늘리고, 더 작고 새로운 프로젝트가 더 빠르게 움직일 수 있음
- llama.cpp 유지보수자들은 사람이 검토하지 않은 AI 작성 코드가 대량으로 들어오는 것을 원하지 않음
antirez 본인의 요약은 더 짧음
이제 코드는 싸졌고, 아이디어의 가치가 더 커졌음
코드 생산 비용이 떨어지면 "이미 있는 것을 쓸 것인가"라는 질문의 답도 달라짐
직접 만드는 비용이 협업하고 설득하는 비용보다 싸지는 지점이 생김
다만 이 접근이 처음부터 성능으로 이어진 것은 아님
flux2.c의 초기 공개 당시 Apple M3 Max에서 512×512 이미지 생성은 C/MPS로 49.6초, 당시 비교한 PyTorch/MPS로 5.4초였음
이후 프로젝트가 iris.c로 발전했고, 현재 저장소의 벤치마크에서는 같은 해상도를 C/MPS로 7.6초, PyTorch/MPS로 13초에 생성함
서로 다른 시점의 측정이라 개선 폭을 그대로 비교할 수는 없지만, 초기의 큰 성능 격차가 고정된 한계는 아니었다는 점은 분명함
C 자체가 빠른 것이 아니라, 작고 소유 가능한 코드베이스를 특정 모델과 하드웨어에 맞춰 계속 바꿀 수 있다는 점이 시간이 지나며 차이를 만듦
h3.c에서도 같은 성격의 선택이 보임
메모리가 부족하면 SSD 스트리밍으로 DiT 텐서 저장량을 36.5GiB에서 2.0GiB까지 줄일 수 있지만, 같은 512×512 forward는 1.35초에서 2.49초로 느려짐
속도와 메모리 중 어느 쪽을 우선할지 사용자가 고를 수 있는 구조
얻는 것은 성능 자체가 아니라 성능과 자원을 어디에 쓸지 결정할 수 있는 자유에 가까움
로컬 실행은 조금 다른 문제
antirez는 DS4를 설명하며 AI는 서비스로만 제공되기에는 너무 중요한 기술이라고 못박음
별개로 대규모 LLM의 가중치는 역사의 일부입니다에서는 사라지는 웹을 인터넷 아카이브가 지키듯 공개된 가중치도 보존되어야 한다고 주장함
실행할 수 있는 코드, 연구할 수 있는 가중치, 사라지지 않는 사본
세 가지가 모여 로컬 추론 엔진이라는 형태가 됨
라이선스 사태가 그를 바꿨을까
시간 순서만 놓고 보면 그렇게 해석하고 싶어짐
Redis의 라이선스 변경으로 커뮤니티가 분열됐고, antirez는 떠났던 Redis로 복귀했으며, 이후 Redis는 AGPL을 추가해 다시 오픈소스 라이선스를 제공하기 시작함
그런데 antirez 본인은 다르게 말함
복귀 선언문에서 그는 라이선스 전환이 커뮤니티와의 균열의 주요 원인은 아니라고 주장함
Redis를 떠난 이유도 라이선스가 아니었음
프로젝트 관리 업무가 늘면서 창의적인 작업이 줄었고, 가족과 시간을 보내며 새로운 도전을 하고 싶었기 때문
그동안에도 임베디드 프로젝트, 신경망, Telegram 봇 같은 실험을 이어감
복귀의 계기는 오히려 커뮤니티가 분열되는 것을 목격한 일이었고, 커뮤니티와 회사 사이의 다리 역할을 하는 "전도사"로서 재참여를 고려했다고 밝힘
라이선스 사태가 AI 활용의 원인이라기보다 직접 만들 수 있는 환경, 공개된 코드와 모델, 창작자로 일할 수 있는 여유라는 자신의 기준을 다시 확인한 사건에 가까움
AI는 antirez를 대신한 것이 아님
h3.c, iris.c, voxtral.c, DwarfStar를 보면 AI가 뛰어난 C 개발자를 불필요하게 만든 것처럼 보일 수도 있음
실제로 일어난 일은 반대에 가까움
코드를 입력하고 검토하는 시간이 줄면서 antirez의 설계 취향이 더 많은 프로젝트에 적용되기 시작함
한 사람이 반년 안에 이미지·음성·언어·영상을 넘나들 수 있게 됐지만, 무엇을 만들고 어떤 구조만 남길지는 여전히 그의 판단
DwarfStar의 추론 구현도 "XYZ를 구현해" 라고 요청한 결과가 아니었음
동작 원리와 설계, 성능 목표를 이해하고 다른 구현과 출력을 비교하면서 미묘한 오류를 찾는 과정이 필요했음
그래서 그의 결론은 코드를 보지 않아도 된다는 것이 아니라, 코드 리뷰보다 설계와 테스트에 더 많은 시간을 써야 한다는 쪽에 가까움
남은 질문도 스스로 인정함
경험이 부족해 정신 모델을 만들기 어려운 젊은 개발자에게는 아직 답이 없다는 것
다만 LLM이 만든 코드를 검토하는 것이 좋은 학습법이라고는 보지 않으며, 작은 인터프리터, 작은 데이터베이스, 해시 테이블을 직접 만들어 보는 편이 훨씬 유용할 수 있다고 제안함
처음에 등장했던 바퀴를 다시 만들어 보라는 주장이 여기서 다시 연결됨
Redis를 만든 사람의 다음 작업이 또 하나의 거대한 플랫폼이 아니라 작고 특화된 C 프로그램들의 연속이라는 점도 그래서 흥미로움
AI가 antirez에게서 코드를 빼앗은 것이 아니라, 코드 너머의 아이디어를 더 빠르게 현실로 만들 수 있게 해준 것임