Redis를 만든 사람이 말했다. '아무도 이 코드를 봐선 안 된다. 코드가 담은 아이디어만 보면 된다.' 30개월에 걸친 그의 입장 변화를 추적하고, 1975년의 책이 왜 지금 다시 읽히는지, 그리고 숫자들이 정말 그의 반대편에 서 있는지 끝까지 따져본다.
2026년 7월 13일, Redis를 만든 살바토레 산필리포(Salvatore Sanfilippo) — 인터넷에서는 antirez로 더 유명한 그 사람 — 가 자기 블로그에 글 하나를 올렸습니다. 제목은 「Control the ideas, not the code」.
핵심 문장은 이렇습니다.
"소프트웨어의 아이디어를 당신이 쥐고 있다면, 코드 자체를 들여다보는 것은 차선이고 대개는 무의미합니다."
그리고 조금 뒤, 자기 자신의 프로젝트에 대해 이렇게 씁니다.
"이제 아무도 이 코드를 봐서는 안 됩니다. 코드가 담고 있는 아이디어만 보면 됩니다."
여기서 "이 코드"는 남의 코드가 아닙니다. Redis입니다.
해커뉴스 반응 중 하나가 이 글이 건드린 지점을 정확히 짚습니다. "antirez 같은 훌륭한 프로그래머가 끝났다고 말한다면, 나는 엔지니어로서의 내 미래에 그렇게 확신이 서지 않는다." 또 다른 댓글은 더 날카롭습니다. "이 제안은 전통적인 작업 방식이나 방법론에 도전하는 게 아니다. 프로그래머라는 정체성 자체에 도전한다."
이 글은 그 도전을 진지하게 따라가 봅니다. 그가 왜 이렇게 말하게 됐는지, 그 논증이 어디까지 튼튼한지, 반대편의 숫자들은 무엇을 말하는지, 그리고 이 논쟁이 2026년 한국의 개발 조직에 어떤 의미인지.
antirez 본인이 글 초반에 자기 자격을 설명합니다. 좀 길지만 이 대목이 글 전체의 성격을 규정합니다.
"제 의도는 이렇게 말하는 겁니다 — '나를 보세요. 나는 코드를 쓸 줄 압니다. 나는 AI 뒤에 숨지 않습니다. 그런데도 상황은 바뀌었습니다. 이건 당신의 나약함이 아닙니다. 당신이 AI에 물든 것도 아닙니다. 그저 우리 분야가 놀랍고 동시에 고통스러운(그러나 또한 즐거운) 방향으로 진화하고 있을 뿐입니다.'"
그러면서 자기 트릭을 스스로 공개합니다. "그러니 이건 제 트릭입니다." 자신은 여전히 코드를 쓸 줄 아는 사람이라는 신뢰를 담보로, 겁먹은 사람들에게 "당신 잘못이 아니다"라고 말해주려 한다는 겁니다.
이 사람이 누구인지 잠깐 짚고 갑시다.
| 시기 | 무엇을 했나 |
|---|---|
| 2009 | Redis를 만들어 공개. 이후 15년간 인메모리 데이터스토어의 사실상 표준이 된다 |
| 2020 | “Redis 모험의 끝”이라는 글을 남기고 프로젝트를 떠난다 |
| 2024.12 | “내가 떠난 자리에서부터” — Redis에 복귀한다 |
| 2025.02 | 「우리는 소프트웨어를 파괴하고 있다」 — AI 이야기가 아니다. 의존성 지옥, 무의미한 재작성, 유행 프레임워크를 12개 항목으로 성토한다 |
| 2025.05 | “Redis는 다시 오픈소스다” — 라이선스 환원 |
| 2026.05 | DwarfStar(ds4) 공개 — 순수 C로 밑바닥부터 쓴 로컬 LLM 추론 엔진. Metal·CUDA·ROCm 백엔드. 몇 주 만에 GitHub 스타 1만 5천 |
| 2026.07 | “코드를 보지 마라” |
여기서 세 번째 줄이 중요합니다. 「우리는 소프트웨어를 파괴하고 있다」를 쓴 사람이 「코드를 보지 마라」를 썼습니다. 이 두 글은 모순처럼 보이지만, 실은 같은 이야기의 앞뒤입니다. 그 얘기는 5부에서 하겠습니다.
이 논쟁에서 antirez의 위치가 특이한 이유가 하나 더 있습니다. 그는 지금 이 순간 AI로 진짜 어려운 것을 만들고 있는 사람입니다.
DwarfStar는 트랜스포머 추론 엔진입니다. 어텐션 커널, 양자화, 메모리 레이아웃, GPU 백엔드 세 종류. "AI로 CRUD 앱 만들었어요"와는 난이도가 다릅니다. 그가 글에서 드는 사례들이 설득력을 갖는 것도 이 때문입니다.
이 글만 떼어 놓고 보면 "잘나가던 사람이 AI에 넘어갔다"로 읽기 쉽습니다. 그런데 그의 블로그를 시간순으로 늘어놓으면 전혀 다른 그림이 나옵니다.
특히 두 지점을 눈여겨보세요.
2025년 5월, 그는 「사람이 아직 LLM보다 낫다」를 씁니다. 제목이 곧 입장입니다. "사람의 창의성은 여전히 우위에 있습니다. 우리는 정말로 틀 밖에서 생각할 수 있고, 다른 것들보다 더 잘 작동할 수 있는 이상하고 부정확한 해법을 상상할 수 있습니다. 이건 LLM에게 극도로 어려운 일입니다."
2025년 7월, 「2025년 여름의 LLM 코딩」에서는 이렇게 씁니다. "당신은 여전히 코더입니다. 다만 증강된." 사람이 루프 안에 남아 있어야 가장 날카로운 코드가 나온다는 것이 그때의 방법론이었습니다.
그리고 14개월 뒤, 같은 사람이 "코드를 보지 마라"고 씁니다.
이 간격을 메우는 것이 그 사이의 글들입니다. 2026년 2월의 「자동 프로그래밍」에서 그는 용어를 정리합니다.
| 바이브 코딩 | 자동 프로그래밍 |
|---|---|
| 대충 목표를 말하고 결과물을 받는다 | 사람이 설계 층위마다 개입해 방향을 잡는다 |
| 고장 났을 때만 손을 댄다 | 아키텍처 선택부터 특정 함수의 구현 방식까지 계속 조종한다 |
| 결과물은 LLM의 것 | 결과물은 당신의 것 |
그리고 이 글에서 그의 슬로건이 나옵니다.
"프로그래밍은 이제 자동이다. 비전은 아직 아니다."
2026년 7월의 글은 이 문장의 결론일 뿐입니다. 프로그래밍이 자동이면 프로그래밍의 산출물(코드)을 검수하는 데 시간을 쓸 이유가 줄고, 자동이 아닌 것(비전, 설계)에 시간을 몰아야 한다.
antirez는 자기 주장의 근거를 세 개로 정리합니다. 하나씩 뜯어봅시다.
"이제 당신은 엄청난 양의 코드를 생성할 수 있습니다. LLM의 코드 장황함을 계산에 넣지 않더라도 말입니다. 하루에 5천 줄의 코드를 어떻게 리뷰하란 말입니까?"
이건 철학이 아니라 산수입니다. 코드 리뷰 문헌에서 흔히 인용되는 검토 속도는 시간당 200~400줄 수준입니다. 이 수치를 넣고 계산해 보면 답이 바로 나옵니다.
슬라이더를 만져 보면 알게 되는 것이 하나 있습니다. "우리는 모든 코드를 리뷰합니다"라는 문장은 대부분의 조직에서 이미 사실이 아닙니다. 다만 몇 %를 안 읽고 넘기는지 아무도 계산해 보지 않았을 뿐입니다.
antirez의 도발은 여기에 있습니다. 어차피 깨진 약속이라면, 깨진 채로 죄책감을 안고 갈 것인가, 아니면 약속의 대상을 바꿀 것인가.
"LLM은 국소적으로 최적인 코드를 매우 잘 씁니다. 그리고 큰 아이디어에는 (개선되고 있지만) 더 약합니다. 함수 하나하나, 줄 하나하나를 훑는 게 무슨 의미가 있습니까? 대신 당신이 머릿속에 갖고 있는 설계를 프롬프트하고, 가끔 '그 부분의 설계가 정확히 어떻게 되어 있지? 어떻게 동작하지?'라고 물어보고, 그게 올바른 모델인지 평가해야 합니다. 그게 훨씬 빠릅니다."
이 논증이 제일 강합니다. 줄 단위 리뷰가 잡는 결함과, 설계 검토가 잡는 결함은 종류가 다릅니다.
그가 제안하는 대체 행위가 재밌습니다. 코드를 읽는 대신 모델에게 설계를 설명해 보라고 시키는 것. "그 부분의 설계가 정확히 어떻게 되어 있지?" 모델이 자기 코드의 설계를 말로 설명하게 하고, 그 설명이 당신이 의도한 모델과 맞는지 본다 — 이건 코드 리뷰보다 훨씬 높은 층위의 검증입니다.
"근무일은 8시간입니다. 코드를 읽는다면 그건 트레이드오프입니다. 오늘날 당신 일에서 가장 중요한 부분을 덜 하고 있는 겁니다. 즉, 스스로에게 묻는 것 — 나는 이 소프트웨어로 무엇을 하고 있나? 어떤 새로운 방향을 가고 싶은가? 그리고 새 아이디어, 기능, 최적화 기법을 생각하는 것. 그리고 QA를 많이 하는 것."
이 논증의 핵심은 기회비용입니다. 리뷰가 가치 없다는 게 아니라, 리뷰가 밀어내는 것들이 더 가치 있다는 주장입니다.
그리고 마지막 항목 — "QA를 많이 하는 것" — 은 지나가는 말이 아닙니다. 그는 한 달 전에 글 하나를 통째로 여기에 썼습니다.
「소프트웨어 테스팅의 새 시대」(2026년 6월)에서 그의 주장은 이렇습니다. AI가 만든 코드의 품질은 최상급 수작업에 못 미치지만, AI가 하는 QA는 사람의 관행을 넘어선다.
그의 실제 작업 방식은 이렇습니다.
구체적인 사례가 붙습니다. DwarfStar에서는 에이전트가 여러 대의 기계에 걸친 분산 추론을 검증하고 속도 회귀를 탐지합니다. Redis Arrays에서는 에이전트가 복제를 켠 실제 애플리케이션을 만들어, 여러 사용자 시나리오를 장시간 돌리며 이상 징후를 감시합니다.
이 방식이 겨냥하는 것은 통합 테스트의 공백입니다. 타이밍 문제, 복잡한 셋업이 필요한 시나리오, 자동화가 잘 안 되는 품질 항목들 — 시간이 없어서 사람이 늘 건너뛰던 영역입니다.
여기서 짚고 갈 점. 줄 단위 코드 리뷰는 이런 결함을 거의 못 잡습니다. 경합 조건, 복제 지연 하에서의 동작, 장시간 운용 후의 메모리 거동은 코드를 읽어서 발견되는 종류가 아닙니다. 그러니까 antirez의 제안은 "검증을 줄이자"가 아니라 "검증을 잡히지 않는 곳에서 잡히는 곳으로 옮기자"입니다.
글 중반에 antirez가 던지는 한 문장이 이 논쟁의 지적 계보를 통째로 드러냅니다.
"아이디어를 통제한다. 이 표현, 『맨먼스 미신』에서 기억나십니까? 1970년대의 책이 2000년부터 2020년 사이에 이야기된 많은 것들보다 지금의 소프트웨어 시대에 대해 더 많은 것을 말해 줍니다."
프레더릭 브룩스의 『맨먼스 미신』(1975)에서 나온 개념이 셋 있습니다.
브룩스는 이렇게 썼습니다. "개념적 일관성은 시스템 설계에서 가장 중요한 고려사항이다." 그리고 더 중요한 단서를 붙입니다. "설계는 한 사람의 머리에서, 또는 아주 적은 수의 서로 공명하는 머리들에서 나와야 한다."
이게 2026년에 왜 다시 읽히는지는 자명합니다. 에이전트 열 대가 각자 국소적으로 최적인 코드를 쏟아내는 상황에서, 잃어버리기 가장 쉬운 것이 정확히 개념적 일관성이기 때문입니다.
브룩스는 큰 프로젝트에서도 이 일관성을 지키기 위한 조직 형태를 제안했습니다. 한 명의 '외과의'(수석 프로그래머)가 핵심 설계와 코딩을 하고, 나머지 팀원들은 문서화·테스트·도구·행정 등 주변 업무를 맡는 구조. 창의적 비전은 한 사람의 머리를 통과하되, 팀은 훨씬 큰 규모의 자원을 갖는다는 발상입니다.
에이전트 여러 대를 부리는 개발자는 이 구조를 혼자서 재현하고 있습니다. 51년 전에 제안된 조직도가, 사람을 쓰기엔 너무 비쌌던 그 구조가, 지금은 한 사람이 노트북 한 대로 만들 수 있는 것이 됐습니다.
브룩스는 아키텍트가 '무엇'(외부 명세)을, 구현자가 '어떻게'를 책임진다고 봤습니다. antirez가 "아이디어를 통제하라"고 말할 때 가리키는 자리가 정확히 아키텍트의 자리입니다.
이 글이 불러온 반발 — "그럼 아무나 프로그래머라는 거냐" — 에 대해 antirez는 12일 뒤 「리누스 토르발스가 된다는 것」으로 답합니다.
그의 해석은 이렇습니다. 리누스가 최소한의 동작하는 유닉스 커널을 짠 것 자체는 재능 있는 개발자라면 해낼 수 있는 일이었다. 리누스의 진짜 천재성은 어느 시점에 직접 코딩하기를 멈추고 아키텍트-조정자가 된 것이다. 그는 패치를 줄 단위로 검토하는 대신, 서브시스템 메인테이너들과 방향과 전략에 대해 대화했다. "그는 커널의 설계 개념을 쥐고 있고, 아래의 모든 사람과 계속 대화한다."
그리고 결론.
"잘된 자동 프로그래밍이란 리누스의 역할을 맡는 것을 뜻한다."
이건 "AI가 프로그래밍을 쉽게 만든다"의 정반대 주장입니다. 재능과 경험이 덜 필요한 게 아니라 더 필요하다는 겁니다. 복잡성을 조율하는 능력은 코드를 타이핑하는 능력보다 희소하니까요.
antirez의 글에서 가장 도발적인 대목은 따로 있습니다.
"지금 AI에 반대하며 항의하는 사람들은 왜 지난 10년간의 소프트웨어 상태에는 경악하지 않았습니까? AI 이전, 최근 몇 년간 우리가 도달한 슬롭의 수준은 믿을 수 없을 정도입니다."
이 문장에는 배경이 있습니다. 2025년 2월 그가 쓴 「우리는 소프트웨어를 파괴하고 있다」입니다. AI는 한 번도 언급되지 않는 글에서 그는 12가지를 성토합니다 — 기능을 더하며 복잡도를 계산하지 않는 것, 터무니없는 의존성 사슬, 하위 호환성 포기, 잘 돌아가는 소프트웨어의 무의미한 재작성, 필요 없는데도 유행 언어와 프레임워크를 도입하는 것, "주석은 쓸모없다"는 주장, 소프트웨어를 예술이 아닌 공학으로만 다루는 것…
그리고 이렇게 끝납니다. "우리는 소프트웨어를 파괴하고 있고, 남는 것은 더 이상 우리에게 해킹의 즐거움을 주지 않을 것이다."
그러니까 그가 "슬롭"이라는 말을 쓸 때, 그건 AI가 만든 것을 가리키는 게 아닙니다. 그는 이미 그 전부터 우리를 슬롭 생산자라고 불러 왔습니다.
여기서 그는 DwarfStar 개발 중 겪은 일을 꺼냅니다. 이 일화가 이 글에서 가장 구체적인 부분입니다.
DeepSeek v4와 GLM 5.2, 두 모델의 추론을 완전히 자동화된 방식으로 구현했다.
다만 직접 해 보면 알게 된다 — "XYZ를 구현해 줘"라고 말하고 그게 그냥 동작하는 일은 없다. 어떻게 돌아가는지, 최선의 설계가 뭔지, 특정 성능 수준에 어떻게 도달하는지를 이해해야 한다.
그리고 완성한 구현을 다른 시스템들과 정확성 기준으로 비교해 봤더니 — 다른 구현들 쪽에 오히려 오류가 더 많은 경우가 있었다.
더 파고들자, 로컬 추론 세계가 누적되어 모델 출력을 훼손하는 미묘한 오류들로 가득하다는 걸 발견했다. 예를 들어 인덱스드 어텐션 구현이 망가져(필요보다 많은 일을 해서) 컨텍스트가 일정 한도를 넘으면 성능이 무너지는 문제 같은 것들.
그의 결론은 이겁니다. 이건 다루기 매우 복잡하고, 빠르게 변하고, 추론 그래프가 조금씩 다른 모델이 매일 나오는 분야다. 개발자에게 불공정한 게임이다. 그리고 AI는 여기에 크게 도움이 된다.
그러고는 이렇게 되묻습니다.
"설계 측면의 엄격한 엔지니어링과 테스팅이 GPU 커널을 손으로 짜는 것(또는 읽는 것)보다 훨씬 나은 영역들이 많습니다. 그러니 그 저항의 상당 부분이 이념적인 게 아니라고 확신할 수 있습니까?"
이 질문은 아픕니다. 손으로 짠 코드가 더 정확할 거라는 우리의 믿음이, 이 사례에서는 사실이 아니었기 때문입니다.
여기까지가 진단이고, 처방은 짧고 구체적입니다. 마테오 콜리나(Matteo Collina)가 "Redis의 AI 생성 코드를 다 검수한다고 하지 않았느냐"고 되물은 데 대한 답에서 나옵니다.
antirez는 먼저 인정합니다. 그렇다, 나는 여전히 다 검수한다. Redis Arrays를 구현할 때도, 지금 준비 중인 정렬 집합(sorted set) 메모리 50% 절감 최적화 PR에서도 마음에 안 드는 코드를 고쳐 왔다고.
그런데 왜 하느냐. "사용자에 대한 존중 때문에" 계속한다고 말합니다. Redis는 이제 공용재이고, 많은 프로그래머가 파일을 열어 손으로 고칠 것이기 때문입니다.
"그러나 손이 자유롭다면 무엇을 하겠느냐"는 질문에 그가 내놓는 답이 이 글의 결론입니다.
DESIGN.md가 무엇이어야 하는지도 명시합니다. 각 자료구조를 사람의 언어로 서술한 문서 — 그것이 담고 있는 아이디어, 구현상의 트릭, 설계. 그리고 이렇게 씁니다.
"정렬 집합을 수정하고 싶습니까? 파일을 열고, 설계를 읽고, 그러면 당신이 그 아이디어를 소유하게 됩니다. 에이전트를 열어 올바른 멘탈 모델을 갖고 무엇을 할지 물어볼 수 있습니다. 이게 코드를 리뷰하는 것보다 훨씬 유용합니다."
이 대목이 중요합니다. 그의 제안은 "문서를 잘 쓰자"는 흔한 말이 아닙니다. 코드가 담당하던 '진실의 원천' 자리를 설계 문서로 옮기자는 것입니다.
| 지금까지 | antirez의 제안 |
|---|---|
| 코드가 진실이다. 문서는 낡는다 | 설계 문서가 진실이다. 코드는 그 실행본이다 |
| 이해하려면 코드를 읽어라 | 이해하려면 설계를 읽어라. 코드는 에이전트가 읽는다 |
| 리뷰 = 코드를 사람이 검사 | 리뷰 = 설계를 사람이 검사 + QA를 에이전트가 실행 |
| 신입은 코드를 읽으며 배운다 | 신입은 설계를 읽고 아이디어를 소유한 뒤 에이전트를 부린다 |
그리고 그는 마지막으로 자신의 현재 상태에 대해 놀랍도록 솔직한 말을 남깁니다.
"정렬 집합 메모리 절감에 대한 Fable과 GPT 5.6의 리뷰가 제 리뷰보다 훨씬 많은 오류와 미묘한 경합 조건을 찾아낼 겁니다. 그런데도 저는 제 리뷰를 할 겁니다."
자기 리뷰가 모델의 리뷰보다 못하다는 것을 알면서도 계속한다고 쓰고 있는 겁니다. 이 문장에는 자기 확신이 아니라 자기 인식이 있습니다.
여기까지가 antirez의 논증입니다. 이제 반대편을 봅시다. 2025~2026년에 나온 데이터는 대체로 그의 낙관에 우호적이지 않습니다.
각 카드를 눌러 보시길 권합니다. 요약하면 이렇습니다.
METR의 무작위 대조 시험은 가장 아픈 반증입니다. 자기 저장소를 잘 아는 숙련 오픈소스 개발자 16명, 246개 실제 과제. AI 사용이 허용된 조건에서 이들은 19% 더 느렸습니다. 그런데 실험이 끝난 뒤 같은 사람들이 "AI 덕에 20% 빨라졌다"고 답했습니다. 체감과 측정이 39%p 어긋난 겁니다.
다만 이 실험은 antirez의 주장과 조건이 정확히 반대라는 점도 봐야 합니다. 참가자들은 성숙한 코드베이스에서, 생성된 코드를 읽고 고치며 일했습니다. 그가 "바로 그게 느려지는 이유"라고 지목한 방식입니다.
GitClear의 코드 품질 연구는 구조적 열화를 보여줍니다. 기존 코드를 옮기는(리팩터링) 변경 비중이 2023년 13%에서 2026년 3.8%로 주저앉았고, 복사-붙여넣기는 9.4%(2022)에서 15.7%(2026 상반기)로 올랐습니다. 블록 중복은 2023년 대비 81% 증가해 역대 최고입니다.
리뷰 병목 지표는 antirez의 첫 번째 논증을 그대로 확인해 줍니다. AI가 만든 PR은 리뷰어가 손대기까지 사람 PR보다 4.6배 오래 기다립니다. 수락률은 32.7% 대 84.4%. 조직의 72%가 AI 생성 코드로 인한 프로덕션 장애를 겪었다고 답했습니다.
토론에서 나온 반론 중 실질적인 것 넷을 정리합니다.
| 반론 | 내용 |
|---|---|
| 설계 문서는 무시된다 | “모델은 당신이 억지로 밀어 넣으려는 건 뭐든 기꺼이 무시한다. 아키텍처 문서를 줘도 결국 다 무시하고 새로운 변종의 씨앗을 뿌린다.” DESIGN.md 처방의 실행 가능성에 대한 직격 |
| 방법론 없이는 결함이 쌓인다 | “문제를 통제할 방법론이 없으면 에이전트 코드에도 결함이 누적된다. 어떤 휴리스틱도 100% 정확하지 않다” |
| 논리가 거꾸로다 | “사람은 오류를 범하니까 우리는 코드를 리뷰한다. 그 사람이 오류를 범하는 기계로 대체되는 순간, 우리는 아기를 목욕물과 함께 버리기로 한다?” |
| 코드를 읽는 것이 아이디어를 만든다 | “남의 코드(그리고 LLM이 쓴 코드)를 읽는 행위가 아이디어 자체를 진화시키고 내 이해를 바꾼다” — 아이디어와 코드를 분리할 수 있다는 전제 자체에 대한 반박 |
마지막 반론이 가장 무겁습니다. antirez의 논증은 "아이디어를 먼저 쥐고 있다"를 전제합니다. 그런데 아이디어가 어디서 오느냐고 물으면, 많은 경우 구현하다가 발견한 것입니다. 코드를 쓰다가 "아 이건 이렇게 나눠야 하는구나"를 깨닫는 경험이 흔하지 않습니까?
antirez의 답은 아마 이럴 겁니다 — 그래서 나는 여전히 코드를 쓸 줄 아는 사람으로 남으라고 말했고, 이건 바이브 코딩이 아니라고 못 박았고, 「리누스가 된다는 것」을 따로 썼다고. 하지만 이 답이 충분한지는 열려 있습니다.
이 글에서 antirez가 유일하게 확신 없이 쓴 문단이 마지막입니다.
"경험이 충분치 않아 멘탈 모델을 세울 수 없는 젊은 프로그래머에 대해서만은 의문이 있습니다. 그들이 어떤 코드가 정확히 어떻게 동작하는지 아주 잘 이해해야 할지 아닐지는 아직 모릅니다. 그러나 저는 그들이 프로그램 짜는 법을 배워야 한다고 믿습니다."
그리고 처방을 붙입니다.
| 하라 | 하지 마라 |
|---|---|
| 프로그래밍 언어를 하나 익히고 작은 인터프리터를 만들어 보라 | LLM 출력을 검수하는 일 |
| 작은 데이터베이스를 만들어 보라 | 고객사 웹사이트의 자바스크립트를 리뷰하는 일 |
| 해시 테이블을 직접 구현해 보라 | — |
마지막 문장은 antirez답게 거칩니다. "고객사 웹사이트의 자바스크립트를 리뷰한다고? 그런 것에 시간 낭비하지 마라."
이 대목은 한국 개발 조직에서 특히 뾰족하게 다가옵니다.
antirez의 처방을 조직 언어로 옮기면 이렇습니다. 신입에게 시키는 훈련 과제와 실제 업무를 분리하라. 업무에서는 에이전트를 쓰게 하되, 훈련에서는 도구 없이 작은 시스템을 밑바닥부터 만들게 하라. 두 개를 섞으면 둘 다 망가집니다.
이 논쟁에서 실무로 가져갈 수 있는 것들을 정리합니다. 주의할 점 하나 — "리뷰를 없애라"는 오독입니다. 그의 주장은 리뷰의 대상을 바꾸라는 것입니다.
그리고 하나 더. 이 모든 것의 전제 조건이 있습니다. 당신이 그 소프트웨어의 아이디어를 실제로 쥐고 있어야 합니다. 쥐고 있지 않은 상태에서 코드까지 안 보면, 그건 antirez가 명시적으로 선을 그은 바이브 코딩입니다.
이 글에서 가장 오래 남는 문장은 주장이 아니라 고백입니다.
antirez는 자기 리뷰가 Fable이나 GPT 5.6의 리뷰보다 못하다는 것을 인정합니다. 그런데도 계속하겠다고 합니다. 이유는 성능이 아니라 "사용자에 대한 존중"입니다. Redis는 이제 많은 사람이 열어 보고 손으로 고치는 공용재이기 때문에.
즉 그는 자기 주장의 예외를 자기 자신으로 삼고 있습니다. "대부분의 소프트웨어 프로젝트에는 이 모든 게 더 이상 말이 안 된다"고 쓰면서, 자기가 맡은 프로젝트에서는 말이 안 되는 일을 계속하겠다고 합니다.
저는 이 부분이 이 글에서 가장 정직한 대목이라고 생각합니다. 그는 승리 선언을 하고 있는 게 아닙니다. 자기가 사랑하는 방식이 끝나가고 있다고 말하면서, 그럼에도 끝까지 그 방식을 지키겠다고 말하고 있는 겁니다.
그가 1년 반 전에 쓴 문장을 다시 읽어 봅니다.
"우리는 소프트웨어를 파괴하고 있고, 남는 것은 더 이상 우리에게 해킹의 즐거움을 주지 않을 것이다."
「코드를 보지 마라」는 그 문장에 대한 항복이 아니라 대답에 가깝습니다. 즐거움이 코드를 타이핑하는 데 있었다면 그건 줄어들 겁니다. 하지만 즐거움이 "무엇을 만들 것인가"를 정하는 데 있었다면, 그 부분은 오히려 커졌습니다.
어느 쪽이 당신의 즐거움이었는지는, 아마 각자 다를 겁니다. 그리고 그 답을 아는 것이 앞으로 몇 년간 꽤 중요해질 것 같습니다.
원문과 직접 연결된 글들
반대편 데이터
배경
