{"title":"Control the ideas, not the code — 코드를 보지 말고 아이디어를 통제하라","url":"https://hugo-blog-static-site.haxlys.workers.dev/posts/control-the-ideas-not-the-code-antirez/","section":"posts","date":"2026-07-15T11:16:55+09:00","lastmod":"2026-07-15T11:16:55+09:00","description":"antirez가 주장하는 AI 시대 프로그래밍의 핵심은 코드를 줄 단위로 읽는 것이 아니라, 설계·의도·품질을 통제하는 일로 이동한다는 점이다.","summary":"antirez(Salvatore Sanfilippo)의 글 Control the ideas, not the code는 AI 시대에 프로그래머가 무엇을 통제해야 하는지를 다시 묻는다. 코드 그 자체가 아니라, 소프트웨어에 담긴 아이디어·설계·방향을 손에 쥐는 일이 중심이 된다는 주장이다.\nIdeas 핵심 정리 핵심 주장: 코드를 계속 보면 오히려 영향력이 줄어들 수 있다. 아이디어를 통제하면 줄 단위 코드 열람은 자주 비효율이 된다. LLM의 강약: 국소적으로 좋은 코드는 잘 쓰지만 큰 설계는 상대적으로 약하다. 함수·줄을 스캔하기보다 설계가 맞는지 묻는 편이 빠르다. 기회비용: 하루 8시간 중 코드 읽기에 쓰면, 방향 설정·아이디어·최적화·QA에 쓸 시간이 줄어든다. 실무 함의: 사람 손이 들어가는 제품에서는 코드 리뷰가 아직 필요할 수 있지만, 장기적으로는 설계 문서와 검증이 더 큰 자산이 된다. 왜 이 이야기를 계속하는가 antirez는 2024년 1월부터 AI 프로그래밍에 대해 글을 써 왔다. Redis에 복귀했고, 로컬 LLM 추론용 오픈소스(DwarfStar)도 만들고 있다. 그럼에도 사람들이 듣기 싫어하는 이야기를 반복하는 이유는, 변화에 덜 준비된 사람들 — 종종 자신보다 젊은 사람들 — 의 충격을 줄이려는 의도라고 밝힌다.\n","content":"antirez(Salvatore Sanfilippo)의 글 Control the ideas, not the code는 AI 시대에 프로그래머가 무엇을 통제해야 하는지를 다시 묻는다. 코드 그 자체가 아니라, 소프트웨어에 담긴 아이디어·설계·방향을 손에 쥐는 일이 중심이 된다는 주장이다.\nIdeas 핵심 정리 핵심 주장: 코드를 계속 보면 오히려 영향력이 줄어들 수 있다. 아이디어를 통제하면 줄 단위 코드 열람은 자주 비효율이 된다. LLM의 강약: 국소적으로 좋은 코드는 잘 쓰지만 큰 설계는 상대적으로 약하다. 함수·줄을 스캔하기보다 설계가 맞는지 묻는 편이 빠르다. 기회비용: 하루 8시간 중 코드 읽기에 쓰면, 방향 설정·아이디어·최적화·QA에 쓸 시간이 줄어든다. 실무 함의: 사람 손이 들어가는 제품에서는 코드 리뷰가 아직 필요할 수 있지만, 장기적으로는 설계 문서와 검증이 더 큰 자산이 된다. 왜 이 이야기를 계속하는가 antirez는 2024년 1월부터 AI 프로그래밍에 대해 글을 써 왔다. Redis에 복귀했고, 로컬 LLM 추론용 오픈소스(DwarfStar)도 만들고 있다. 그럼에도 사람들이 듣기 싫어하는 이야기를 반복하는 이유는, 변화에 덜 준비된 사람들 — 종종 자신보다 젊은 사람들 — 의 충격을 줄이려는 의도라고 밝힌다.\n그의 전략은 일종의 트릭이다. 프로그래머들이 AI 때문에 분야가 바뀌고 있다는 불안을 느끼고, 코드를 주요 산출물로 보지 않는 방식이 배신처럼 느껴질 때, \u0026ldquo;나처럼 코드를 쓸 줄 아는 사람도 인정한다. 이것은 네 약점이 아니라 분야의 진화\u0026quot;라고 말해 주려는 것이다. 변화는 고통스럽지만 동시에 기쁨이 섞인 방향으로 가고 있다고 본다.\n코드를 보면 영향력이 줄어든다 어제 X에서 그는 이렇게 말했다. 많은 프로그래머가 코드를 보기 때문에, 가질 수 있는 영향력보다 덜 영향을 미치고 있다. 이것은 \u0026ldquo;최종 제품만 요청하는 바이브 코딩\u0026quot;을 옹호하는 말이 아니다. 핵심은 다음이다.\n소프트웨어의 아이디어를 통제하고 있다면, 코드 자체를 들여다보는 일은 차선이고 종종 무의미하다.\n이유는 세 가지다.\n1) 생성량이 리뷰 가능 범위를 넘는다 이제 하루에도 많은 코드를 만들 수 있다. LLM의 장황함까지 감안하지 않더라도 마찬가지다. 매일 5,000줄을 사람이 리뷰한다는 가정 자체가 현실적이지 않다.\n2) LLM은 국소 최적에 강하고 큰 아이디어에 약하다 LLM은 국소적으로 괜찮은 코드를 잘 쓴다. 큰 설계 아이디어에는 아직 약하지만 개선 중이다. 그렇다면 함수 단위·줄 단위 스캔의 이득은 작다. 대신 머릿속의 설계를 프롬프트로 밀어 넣고, \u0026ldquo;그 부분의 설계가 정확히 무엇인가? 어떻게 동작하는가?\u0026ldquo;를 물은 뒤, 그 모델이 맞는지 평가하는 편이 훨씬 빠르다.\n3) 하루 8시간은 트레이드오프다 코드 읽기는 공짜가 아니다. 읽기에 쓰는 시간은 오늘 가장 중요한 일에서 빠진다. antirez가 꼽는 중요 일은 다음과 같다.\n이 소프트웨어로 무엇을 하고 있는가 어떤 새 방향으로 갈 것인가 새 아이디어, 기능, 최적화 트릭 많은 QA 즉 코드 리딩 습관은 \u0026ldquo;성실함\u0026quot;이 아니라 기회비용 문제다.\nMythical Man-Month가 다시 맞다 \u0026ldquo;아이디어를 통제한다\u0026quot;는 표현은 The Mythical Man-Month에서도 나온다. 1970년대 책이 2000~2020년의 많은 이야기보다 현재 소프트웨어 시대를 더 잘 설명한다는 것이다.\n그는 반문한다. 지금 AI에 저항하는 사람들은 지난 10년의 소프트웨어 상태에는 왜 그토록 공포를 느끼지 않았는가. AI 이전에도 슬롭의 수준은 이미 믿기 어려울 정도였다. 그렇다면 지금의 저항 중 상당 부분은 이데올로기적이지 않은가.\nDwarfStar 사례: \u0026ldquo;구현해 줘\u0026quot;로는 안 된다 DwarfStar에서 DeepSeek v4와 GLM 5.2 추론을 상당 부분 자동으로 구현했다고 한다. 그러나 \u0026ldquo;XYZ를 구현해\u0026quot;라고만 하면 동작하는 결과가 나오지 않는다. 다음이 필요하다.\n동작 원리 이해 더 나은 설계 선택 목표 성능에 도달하는 경로 그는 구현을 다른 시스템과 정합성 비교했고, 다른 구현에 더 많은 오류가 있는 경우도 발견했다. 로컬 추론 세계에는 미묘한 오류가 쌓여 모델 출력을 망가뜨리는 문제가 있다. 예로, 컨텍스트가 일정 한계를 넘으면 성능이 기울어지는 어텐션 구현 버그(인덱싱된 어텐션이 필요 이상으로 일을 하는 식) 등이 있다.\n도메인은 복잡하고 빠르게 바뀌며, 추론 그래프가 모델마다 조금씩 다른 새 모델이 매일 나온다. 개발자에게 불리한 게임이다. 여기서 AI는 큰 도움이 된다. 많은 영역에서 설계 쪽의 엄밀한 엔지니어링과 테스트 가 GPU 커널을 손으로 쓰거나 읽는 일보다 훨씬 낫다.\nRedis 코드 리뷰는 왜 아직 하는가 Matteo Collina가 물었다. \u0026ldquo;Redis용 AI 생성 코드는 전부 검사한다고 하지 않았나?\u0026rdquo;\nantirez의 답은 솔직하다. 그렇다, 검사한다. 그러나 이제는 해야 하는 일 이지 유용한 일 은 아니라고 본다. GPT-5.5 이후, 그리고 Fable과 GPT-5.6 Sol 이후 그 경향이 더 강해졌다.\n코드를 열어 보면 마음에 안 드는 구현을 찾는다. 하지만 다른 Redis 기여자가 쓴 파일을 열면 그보다 훨씬 나쁜 코드도 있다. 실력이 없어서가 아니라 취향 의 문제다. 그는 가독성을 중시해 Redis Arrays 구현에서 코드를 손봤고, 정렬 집합(sorted sets) 50% 메모리 절감 최적화 PR에서도 같은 일을 한다. 그러나 더 이상 유용하다고 느끼지 않는다.\n아무도 그 코드를 보지 말고, 코드가 담은 아이디어만 보면 된다고 본다. 그럼에도 리뷰를 계속하는 이유는 사용자에 대한 존중 때문이다. Redis는 흔히 쓰이는 소프트웨어라, 많은 프로그래머가 파일을 열고 손으로 고친다.\n손이 자유롭다면 그는 리뷰 시간을 다른 곳에 쓰겠다고 한다.\n더 많은 QA 다음 최적화 아이디어를 생각하고 적용 LLM으로 DESIGN.md를 작성: 각 자료구조를 인간 언어로 기술하고, 담긴 아이디어·구현 트릭·설계를 남김 미래에 더 유용한 것은 이쪽이다. sorted sets를 수정하려면 설계 문서를 읽고 아이디어를 소유한 뒤, 올바른 정신 모델로 에이전트에게 무엇을 할지 묻는 방식이 코드 리뷰보다 낫다.\nFable과 GPT-5.6이 sorted sets 메모리 절감 변경에서 찾아낼 오류·미묘한 레이스 조건은 그의 리뷰보다 많을 가능성이 크다. 그래도 그는 리뷰를 한다. 하지만 대부분의 소프트웨어 프로젝트에서는 더 이상 말이 되지 않는다.\n초보 프로그래머에 대한 유일한 유보 경험 부족으로 정신 모델을 아직 못 만든 젊은 프로그래머에 대해서만 그는 유보를 둔다. 특정 코드 조각을 아주 깊이 이해해야 하는지는 아직 모른다. 다만 프로그램을 쓰는 법을 배워야 한다 고 본다.\n그런데 LLM 출력을 검수하는 일이 그 학습의 정답인지는 회의적이다. 다음이 더 유익할 수 있다.\n프로그래밍 언어를 익힌다 작은 인터프리터를 만든다 작은 데이터베이스를 만든다 해시 테이블을 구현한다 고객 웹사이트의 JavaScript를 리뷰하며 시간을 쓰는 일은, 그가 보기에 시간을 낭비하는 일이다.\n결론 및 시사점 한 줄 결론: AI 시대 프로그래머의 핵심 역할은 코드를 줄 단위로 소유하는 것이 아니라, 소프트웨어의 아이디어·설계·품질 기준을 소유하는 일이다.\nantirez의 주장은 \u0026ldquo;코드를 전혀 보지 말라\u0026quot;는 방임이 아니다. 코드를 보는 행위의 한계효용 이 급격히 떨어졌다는 진단에 가깝다. 생성량은 폭증했고, LLM은 국소 구현에서 사람을 압도하기 시작했으며, 사람의 시간은 방향·설계·검증으로 써야 이득이 크다.\n실무적으로 옮기면 세 가지가 선명해진다.\n설계를 프롬프트와 문서로 먼저 고정한다. 구현 전에 \u0026ldquo;무엇이 옳은 모델인가\u0026quot;를 합의한다. 검증과 QA에 사람 시간을 재배치한다. 줄 리뷰 대신 동작·경계·성능·정합성을 본다. 학습 경로를 분리한다. 숙련자는 아이디어 통제와 검증에, 초보자는 작은 시스템 구현으로 정신 모델을 쌓는 쪽에 힘을 준다. 세계는 바뀌었고 고통스럽지만, 이미 썩어 있던 소프트웨어 세계를 개선할 기회도 가득하다. 그 기회는 더 많은 코드를 읽는 데서 오지 않는다. 더 나은 아이디어를 통제하는 데서 온다.\n관련 포스트 Understanding Is the New Bottleneck - AI 시대의 병목은 이해다 AI 프로토타입 시대에도 여전히 엔지니어가 필요한 이유 Backpressure is all you need — 코딩 에이전트 위임의 병목을 사람에서 시스템으로 옮기기 ","wordCount":967,"tags":["AI","LLM","antirez","Redis","소프트웨어엔지니어링","에이전트","디자인"],"categories":["AI"],"frameworks":["Idea Control","Design over Implementation","Human-AI Division of Labor"],"mental_models":["Mythical Man-Month","Trade-off","Local vs Global Optimality"],"philosophy_type":"engineering-process","schema_type":"TechArticle","actionable":true,"priority":"high","key_points":["코드를 계속 들여다보는 습관이, 아이디어·방향·QA에 쓸 시간을 잠식해 프로그래머의 실질 영향력을 줄일 수 있다.","LLM은 국소적으로 괜찮은 코드를 잘 쓰지만 큰 설계에는 약하므로, 줄 단위 리뷰보다 설계 모델의 옳음을 검증하는 편이 효율적이다.","하루 8시간 제약 아래 코드 읽기는 기회비용이 크며, 무엇을 만들지·다음 방향·최적화·QA가 더 중요한 일이 된다.","Redis처럼 사람이 직접 파일을 열어 수정하는 소프트웨어에서는 코드 리뷰를 유지할 수 있지만, 이상적으로는 DESIGN.md로 아이디어를 소유하게 만드는 쪽이 낫다.","초보 프로그래머는 LLM 출력 검수보다, 인터프리터·DB·해시테이블 같은 작은 시스템을 직접 만들어 정신 모델을 쌓는 편이 유익할 수 있다."],"related":["posts/understanding-is-the-new-bottleneck-geoffrey-litt","posts/yes-we-still-need-engineers","posts/backpressure-is-all-you-need-summary"]}