antirez(Salvatore Sanfilippo)의 글 Control the ideas, not the code는 AI 시대에 프로그래머가 무엇을 통제해야 하는지를 다시 묻는다. 코드 그 자체가 아니라, 소프트웨어에 담긴 아이디어·설계·방향을 손에 쥐는 일이 중심이 된다는 주장이다.

왜 이 이야기를 계속하는가

antirez는 2024년 1월부터 AI 프로그래밍에 대해 글을 써 왔다. Redis에 복귀했고, 로컬 LLM 추론용 오픈소스(DwarfStar)도 만들고 있다. 그럼에도 사람들이 듣기 싫어하는 이야기를 반복하는 이유는, 변화에 덜 준비된 사람들 — 종종 자신보다 젊은 사람들 — 의 충격을 줄이려는 의도라고 밝힌다.

그의 전략은 일종의 트릭이다. 프로그래머들이 AI 때문에 분야가 바뀌고 있다는 불안을 느끼고, 코드를 주요 산출물로 보지 않는 방식이 배신처럼 느껴질 때, “나처럼 코드를 쓸 줄 아는 사람도 인정한다. 이것은 네 약점이 아니라 분야의 진화"라고 말해 주려는 것이다. 변화는 고통스럽지만 동시에 기쁨이 섞인 방향으로 가고 있다고 본다.

코드를 보면 영향력이 줄어든다

어제 X에서 그는 이렇게 말했다. 많은 프로그래머가 코드를 보기 때문에, 가질 수 있는 영향력보다 덜 영향을 미치고 있다. 이것은 “최종 제품만 요청하는 바이브 코딩"을 옹호하는 말이 아니다. 핵심은 다음이다.

소프트웨어의 아이디어를 통제하고 있다면, 코드 자체를 들여다보는 일은 차선이고 종종 무의미하다.

이유는 세 가지다.

1) 생성량이 리뷰 가능 범위를 넘는다

이제 하루에도 많은 코드를 만들 수 있다. LLM의 장황함까지 감안하지 않더라도 마찬가지다. 매일 5,000줄을 사람이 리뷰한다는 가정 자체가 현실적이지 않다.

2) LLM은 국소 최적에 강하고 큰 아이디어에 약하다

LLM은 국소적으로 괜찮은 코드를 잘 쓴다. 큰 설계 아이디어에는 아직 약하지만 개선 중이다. 그렇다면 함수 단위·줄 단위 스캔의 이득은 작다. 대신 머릿속의 설계를 프롬프트로 밀어 넣고, “그 부분의 설계가 정확히 무엇인가? 어떻게 동작하는가?“를 물은 뒤, 그 모델이 맞는지 평가하는 편이 훨씬 빠르다.

3) 하루 8시간은 트레이드오프다

코드 읽기는 공짜가 아니다. 읽기에 쓰는 시간은 오늘 가장 중요한 일에서 빠진다. antirez가 꼽는 중요 일은 다음과 같다.

  • 이 소프트웨어로 무엇을 하고 있는가
  • 어떤 새 방향으로 갈 것인가
  • 새 아이디어, 기능, 최적화 트릭
  • 많은 QA

즉 코드 리딩 습관은 “성실함"이 아니라 기회비용 문제다.

Mythical Man-Month가 다시 맞다

“아이디어를 통제한다"는 표현은 The Mythical Man-Month에서도 나온다. 1970년대 책이 2000~2020년의 많은 이야기보다 현재 소프트웨어 시대를 더 잘 설명한다는 것이다.

그는 반문한다. 지금 AI에 저항하는 사람들은 지난 10년의 소프트웨어 상태에는 왜 그토록 공포를 느끼지 않았는가. AI 이전에도 슬롭의 수준은 이미 믿기 어려울 정도였다. 그렇다면 지금의 저항 중 상당 부분은 이데올로기적이지 않은가.

DwarfStar 사례: “구현해 줘"로는 안 된다

DwarfStar에서 DeepSeek v4와 GLM 5.2 추론을 상당 부분 자동으로 구현했다고 한다. 그러나 “XYZ를 구현해"라고만 하면 동작하는 결과가 나오지 않는다. 다음이 필요하다.

  • 동작 원리 이해
  • 더 나은 설계 선택
  • 목표 성능에 도달하는 경로

그는 구현을 다른 시스템과 정합성 비교했고, 다른 구현에 더 많은 오류가 있는 경우도 발견했다. 로컬 추론 세계에는 미묘한 오류가 쌓여 모델 출력을 망가뜨리는 문제가 있다. 예로, 컨텍스트가 일정 한계를 넘으면 성능이 기울어지는 어텐션 구현 버그(인덱싱된 어텐션이 필요 이상으로 일을 하는 식) 등이 있다.

도메인은 복잡하고 빠르게 바뀌며, 추론 그래프가 모델마다 조금씩 다른 새 모델이 매일 나온다. 개발자에게 불리한 게임이다. 여기서 AI는 큰 도움이 된다. 많은 영역에서 설계 쪽의 엄밀한 엔지니어링과 테스트 가 GPU 커널을 손으로 쓰거나 읽는 일보다 훨씬 낫다.

Redis 코드 리뷰는 왜 아직 하는가

Matteo Collina가 물었다. “Redis용 AI 생성 코드는 전부 검사한다고 하지 않았나?”

antirez의 답은 솔직하다. 그렇다, 검사한다. 그러나 이제는 해야 하는 일 이지 유용한 일 은 아니라고 본다. GPT-5.5 이후, 그리고 Fable과 GPT-5.6 Sol 이후 그 경향이 더 강해졌다.

코드를 열어 보면 마음에 안 드는 구현을 찾는다. 하지만 다른 Redis 기여자가 쓴 파일을 열면 그보다 훨씬 나쁜 코드도 있다. 실력이 없어서가 아니라 취향 의 문제다. 그는 가독성을 중시해 Redis Arrays 구현에서 코드를 손봤고, 정렬 집합(sorted sets) 50% 메모리 절감 최적화 PR에서도 같은 일을 한다. 그러나 더 이상 유용하다고 느끼지 않는다.

아무도 그 코드를 보지 말고, 코드가 담은 아이디어만 보면 된다고 본다. 그럼에도 리뷰를 계속하는 이유는 사용자에 대한 존중 때문이다. Redis는 흔히 쓰이는 소프트웨어라, 많은 프로그래머가 파일을 열고 손으로 고친다.

손이 자유롭다면 그는 리뷰 시간을 다른 곳에 쓰겠다고 한다.

  • 더 많은 QA
  • 다음 최적화 아이디어를 생각하고 적용
  • LLM으로 DESIGN.md를 작성: 각 자료구조를 인간 언어로 기술하고, 담긴 아이디어·구현 트릭·설계를 남김

미래에 더 유용한 것은 이쪽이다. sorted sets를 수정하려면 설계 문서를 읽고 아이디어를 소유한 뒤, 올바른 정신 모델로 에이전트에게 무엇을 할지 묻는 방식이 코드 리뷰보다 낫다.

Fable과 GPT-5.6이 sorted sets 메모리 절감 변경에서 찾아낼 오류·미묘한 레이스 조건은 그의 리뷰보다 많을 가능성이 크다. 그래도 그는 리뷰를 한다. 하지만 대부분의 소프트웨어 프로젝트에서는 더 이상 말이 되지 않는다.

초보 프로그래머에 대한 유일한 유보

경험 부족으로 정신 모델을 아직 못 만든 젊은 프로그래머에 대해서만 그는 유보를 둔다. 특정 코드 조각을 아주 깊이 이해해야 하는지는 아직 모른다. 다만 프로그램을 쓰는 법을 배워야 한다 고 본다.

그런데 LLM 출력을 검수하는 일이 그 학습의 정답인지는 회의적이다. 다음이 더 유익할 수 있다.

  • 프로그래밍 언어를 익힌다
  • 작은 인터프리터를 만든다
  • 작은 데이터베이스를 만든다
  • 해시 테이블을 구현한다

고객 웹사이트의 JavaScript를 리뷰하며 시간을 쓰는 일은, 그가 보기에 시간을 낭비하는 일이다.

결론 및 시사점

한 줄 결론: AI 시대 프로그래머의 핵심 역할은 코드를 줄 단위로 소유하는 것이 아니라, 소프트웨어의 아이디어·설계·품질 기준을 소유하는 일이다.

antirez의 주장은 “코드를 전혀 보지 말라"는 방임이 아니다. 코드를 보는 행위의 한계효용 이 급격히 떨어졌다는 진단에 가깝다. 생성량은 폭증했고, LLM은 국소 구현에서 사람을 압도하기 시작했으며, 사람의 시간은 방향·설계·검증으로 써야 이득이 크다.

실무적으로 옮기면 세 가지가 선명해진다.

  1. 설계를 프롬프트와 문서로 먼저 고정한다. 구현 전에 “무엇이 옳은 모델인가"를 합의한다.
  2. 검증과 QA에 사람 시간을 재배치한다. 줄 리뷰 대신 동작·경계·성능·정합성을 본다.
  3. 학습 경로를 분리한다. 숙련자는 아이디어 통제와 검증에, 초보자는 작은 시스템 구현으로 정신 모델을 쌓는 쪽에 힘을 준다.

세계는 바뀌었고 고통스럽지만, 이미 썩어 있던 소프트웨어 세계를 개선할 기회도 가득하다. 그 기회는 더 많은 코드를 읽는 데서 오지 않는다. 더 나은 아이디어를 통제하는 데서 온다.

관련 포스트