레디스(Redis)를 만든 개발자 안티레즈(Salvatore Sanfilippo)가 2026년 7월 13일 자신의 블로그에 “Control the ideas, not the code”라는 글을 올렸다. 그는 “많은 프로그래머가 지금 코드를 들여다보는 데 시간을 쓰기 때문에 오히려 영향력을 덜 발휘하고 있다”는 자신의 X(트위터) 발언을 풀어 설명하면서, AI가 만든 코드를 한 줄씩 검토하는 습관이 이제는 손해에 가깝다고 주장했다. 이 글이 다루는 것은 바이브 코딩(결과물만 보고 프롬프트만 던지는 방식)을 하라는 권유가 아니라, 검토의 대상을 코드가 아니라 설계로 옮기라는 제안이다.
안티레즈는 자신이 여전히 레디스의 AI 생성 코드를 전부 검토한다고 밝히면서도, 이 검토가 “필요하지만 대체로 무의미한 일”이 되어 가고 있다고 말한다. 그 이유를 세 가지로 정리한다.
왜 코드를 다 읽는 것이 손해가 되는가
첫째, 근무시간은 하루 8시간으로 고정돼 있다. AI가 만들어내는 코드량은 이 제약과 무관하게 늘어난다. 안티레즈는 “하루 5천 줄을 어떻게 매번 리뷰하느냐”고 반문한다. 둘째, LLM은 지역적으로 최적인 코드를 쓰는 데는 강하지만 큰 설계 판단에는 상대적으로 약하다. 그런데 줄 단위로 코드를 훑는 방식은 이 지역 최적화의 결과만 보여줄 뿐, 설계가 틀렸는지는 잘 드러내지 않는다. 셋째, 하루 안에서 코드를 읽는 데 쓰는 시간만큼 다른 일에 쓸 시간이 줄어든다. 안티레즈가 꼽는 “다른 일”은 소프트웨어의 다음 방향을 정하는 판단, 새 기능과 최적화 아이디어 구상, 그리고 QA다.
대안으로 그가 제시하는 방법은 코드 대신 설계를 검증하는 것이다. 함수와 줄을 스캔하는 대신 “이 부분의 설계가 정확히 어떻게 되어 있나, 어떻게 작동하나”를 모델에게 묻고, 그 답이 자신이 그리는 모델과 일치하는지 판단한다. 설계가 맞으면 그 아래 구현은 대체로 설계를 따라가기 때문에, 같은 시간에 더 근본적인 오류를 잡을 수 있다는 논리다.
본인이 검증한 “슬롭”은 무엇이었나
안티레즈의 주장에 무게를 더하는 것은 그가 최근 직접 만든 로컬 LLM 추론 프로젝트 DwarfStar의 경험이다. 그는 이 프로젝트에서 DeepSeek v4와 GLM 5.2 두 모델의 추론 구현을 자동화된 방식으로 만들었지만, 그 과정에서 “구현하라고 말만 해서는 작동하는 결과가 나오지 않는다”는 점, 즉 설계와 성능 목표를 사람이 정확히 이해해야 한다는 점을 확인했다고 썼다. 그는 자신의 구현을 다른 로컬 추론 시스템과 정확성 기준으로 비교했고, 다른 구현체들이 오히려 더 많은 오류를 담고 있었다고 밝혔다. 그가 예로 든 오류는 컨텍스트 길이가 특정 한도를 넘으면 성능이 떨어지는 인덱스 어텐션(indexed attention) 구현 결함으로, 필요 이상의 연산을 수행하는 방식으로 잘못 구현된 사례였다.
이 경험이 그가 말하는 “슬롭(slop)”의 정의로 이어진다. 그는 슬롭을 AI가 만들었다는 이유만으로 나쁜 코드로 규정하지 않는다. 대신 로컬 추론처럼 매일 조금씩 다른 모델이 쏟아지는, 복잡하고 빠르게 변하는 영역에서 사람이 손으로 GPU 커널을 짜고 읽는 방식이 오히려 오류를 쌓이게 만든다고 본다. 이런 도메인에서는 설계와 테스트를 중심에 둔 엄격한 엔지니어링이, 사람이 직접 짜거나 읽는 저수준 구현보다 더 나은 결과를 낼 수 있다는 것이다.
DESIGN.md는 코드 대신 무엇을 남기는가
안티레즈는 레디스에서 자신이 “매우 깔끔한 코드”를 쓰려고 하고, 그래서 Redis Arrays 구현 때도 다른 기여자의 코드를 직접 고쳤다고 밝힌다. 진행 중인 정렬 집합(sorted set)의 메모리 50% 절감 최적화에서도 같은 방식으로 리뷰를 계속할 계획이라고 말한다. 그럼에도 그는 이 리뷰가 “더는 유용하지 않다”고 느낀다며, 손이 자유롭다면 그 시간을 다음 최적화 아이디어를 구상하고 QA를 늘리는 데, 그리고 LLM에게 각 자료구조의 설계 의도와 구현 트릭을 사람이 읽을 수 있는 언어로 정리한 DESIGN.md 문서를 만들게 하는 데 쓰겠다고 적었다.
이 문서의 역할은 명확하다. 누군가 정렬 집합을 수정하려 할 때, 코드 대신 DESIGN.md를 먼저 읽고 그 자료구조가 담은 아이디어를 파악한 뒤 에이전트에게 올바른 멘탈 모델을 주고 작업을 맡길 수 있게 하는 것이다. 안티레즈는 이 편이 코드를 처음부터 리뷰하는 것보다 “훨씬 더 유용할 것”이라고 본다. 그는 동료 개발자 Matteo Collina가 “레디스의 AI 생성 코드를 전부 확인한다고 하지 않았느냐”고 반문한 데 대해, 자신이 여전히 사용자를 향한 책임 때문에 그렇게 하고 있을 뿐이며, Fable과 GPT 5.6 Sol 같은 모델의 상호 리뷰가 자신의 리뷰보다 더 많은 미묘한 경쟁 조건(race condition)과 오류를 찾아낼 것이라고 인정한다.
이 조언이 통하지 않는 경우는 무엇인가
안티레즈는 이 전환에 예외를 둔다. 충분한 경험이 없어 아직 자신만의 멘탈 모델을 세우지 못한 주니어 개발자에게는 이 방식을 그대로 권하지 않는다. 그는 이들이 프로그래밍 언어를 배우고, 작은 인터프리터·데이터베이스·해시 테이블을 직접 구현해 보는 것이 여전히 필요하다고 본다. 다만 LLM이 낸 결과물을 검토하는 것이 그 학습에 최선의 방법인지는 확신하지 못한다고 덧붙인다. 반면 특정 고객을 위한 웹사이트의 자바스크립트 코드처럼 반복적이고 저부가가치인 작업은 “시간 낭비할 필요가 없다”고 잘라 말한다.
그가 이 글을 쓰는 이유도 분명히 밝힌다. 2024년 1월부터 AI 프로그래밍에 관한 글을 꾸준히 써 온 그는, 자신이 관심을 유지하려는 나이 든 개발자가 아니라 이미 레디스에 복귀했고 새 오픈소스 로컬 LLM 추론 프로젝트로 좋은 반응을 얻은 현역 개발자임을 강조한다. 그 위치에서 그는 “나는 여전히 코드를 짤 수 있다. AI 뒤에 숨는 게 아니다. 다만 상황이 바뀌었을 뿐이다”라는 메시지를 통해, 코드를 덜 들여다보게 된 개발자들이 이를 자신의 약점으로 여기지 않기를 바란다고 썼다.
출처: Salvatore Sanfilippo (antirez), “Control the ideas, not the code” (2026-07-13)