분명히 해두자면, 이건 Redis의 원작자 또는 그중 한 명이 한 일임
그는 “평균적인 개발자”가 아니고, LLM을 써도 4개월이 걸렸음
그러니 이걸 근거로 모든 개발자에게 Claude Code, Codex, 기타 AI 코딩 도구로 완전히 옮기라고 지시해도 된다는 승인 도장처럼 받아들이면 안 됨
특히 평범한 스타트업 CEO들이 봐야 할 대목임
경험 많은 개발자가 코딩 에이전트를 능숙하게 쓰면 전문성이 더 증폭될 수 있다는 꽤 강한 근거로 보임
“그는 평균적인 개발자가 아니고 LLM을 써도 4개월이 걸렸다”는 부분은 원문을 보면 조금 다름
원문에서는 “LLM 이전에도 구현 자체는 아마 4개월 안에 할 수 있었을 것이다. 달라진 건 같은 기간에 훨씬 더 많은 일을 할 수 있었다는 점”이라고 했음
즉 초기 기간은 원래 4개월이었고, LLM 덕분에 같은 기간 안에 더 많은 작업을 한 것임
그는 평균적이지 않지만, 그의 작업도 당연히 평균적인 작업이 아님
평균적인 개발 업무는 배관 작업과 CRUD에 가까움
현재 쓰는 방식은 이럼
먼저 AI 도움을 받아 상위 설계 문서를 Markdown으로 작성함. 그다음 같은 모델이되 문맥을 빼거나, 다른 모델에게 비판하게 해서 버그·누락·빈틈을 찾게 함. 나중에 보면 뻔한 것들을 항상 찾아냄
그러면 그 발견을 요약하게 해서 첫 번째 AI에 붙여넣고 의견을 묻는다. 합의된 변경을 만들고 반영한 뒤, 어떤 모델도 의미 있는 제안을 못 할 때까지 이런 적대적 라운드로빈을 계속함
이후 AI에게 계획을 만들게 하고, 그 계획도 여러 AI 사이에서 적대적으로 돌림. 결국 꽤 탄탄한 계획이 나옴
그다음 종단 간 테스트 케이스 계획 등으로 넘어감. 시스템 규모에 따라 첫날, 첫 주, 첫 달이 끝날 즈음 코딩 준비가 됨
코드가 만들어지면 그 코드와 명세, 계획을 다른 AI에 붙여넣고 버그·누락·빈틈을 찾게 함. 구현을 맡은 주 AI를 계속 다른 AI로 검증하는 방식임
물론 코드는 직접 읽어야 함. AI가 마감 품질의 세부 polish를 놓치는 걸 봤기 때문임
AI 담론에서는 우리가 완전히 새로운 비감독 개발 패러다임을 열었다고 하지만, 사실상 Google이 10년 동안 코드를 만들어 온 방식과 거의 같음. 다만 신뢰 수준이 다른 인간 대신 AI를 쓰는 것뿐임
비꼬려는 건 아님. 내 작업 흐름도 본질적으로 같고, Google을 비웃자는 것도 아님. 오히려 새로울 건 없다는 뜻임
AI는 효과적인 작업 흐름과 비효과적인 작업 흐름을 모두 엄청나게 가속함. 덕분에 무엇이 효과적이고 무엇이 비효과적인지 훨씬 짧은 시간, 거의 실시간으로 드러남
antirez가 작성했더라도, 이 정도 기능 집합과 최소한의 PR 설명으로 22,000줄 코드 리뷰를 하는 건 악몽처럼 들림
Postgres 같은 주요 오픈소스가 왜 메일링 리스트에서 개발되는지 이해가 감. 중간 설계 결정을 커뮤니티와 논의하고, 관련 기능도 별도 패치로 나누며, 점진적으로 리뷰하고, 릴리스 간격도 띄워서 진행하는 방식임
코드는 주석 포함 총 5,000줄임
희소 배열이 2,000줄 t_array 명령과 상위 계층 구현이 2,000줄
AOF/RDB 코드가 약 500줄
나머지는 테스트, JSON 명령 설명, deps 아래 TRE 라이브러리임
Postgres와 Redis는 성격, 역사, 기여 방식, 개발팀이 극적으로 다른 프로젝트임
사실상 주요 Redis 기능 대부분은 글쓴이가 혼자 만든 작업임
게다가 리뷰어들은 이 일을 잘 알고 보수도 제대로 받음
현재 최고 수준 AI를 써본 내 경험과 매우 비슷함. 인간 지능과 창의성의 대체재와는 거리가 멀지만, 협업자로는 극도로 유용함
AI는 내가 늘 원하던 고무 오리 프로그래밍 오리라고 말하곤 함
코드를 거의 보지 않고도 개발하는 프로젝트들이 있음. 개념, 알고리즘, 아이디어를 내가 쥐고 질문과 힌트를 주며, 특히 제품 방향을 소유하는 식임
하지만 Redis는 아직 아님. 언젠가 서버 소프트웨어에서 이것이 가능해지면, 오늘날의 개발 방식은 끝날 것임
기능, 수정, 경험의 축적은 여전히 가치가 있으니 프로젝트와 저장소는 남겠지만, 프로그래머의 역할은 지금까지 Linus가 커널에 해온 역할과 매우 비슷해질 것임
DeepSeek v4 추론 엔진 같은 일부 프로젝트에서는 이미 그런 식으로 작업 중임
array/regex가 기대되고, LLM으로 능력을 확장한 경험도 매우 흥미로움. 여러 프로젝트에서 조용히 비슷한 시도를 하는 사람이 많음 바이브 코딩과 그에 대한 반발만으로는 이런 작업 방식을 제대로 설명하지 못함
나는 에이전트를 쓴 방식을 전혀 바이브 코딩이라고 보지 않음. 너무 깊이 관여하고, 모든 것을 검증·확인·리뷰하기 때문임
“바이브 코딩”의 문제는 그 용어를 만든 사람이 아주 구체적인 정의를 붙였다는 데 있음. 코드를 보지 않고 그냥 “감”으로 소프트웨어를 만드는 것임
그런데 곧 사람들이 거의 모든 형태의 AI 보조 코딩에 이 말을 쓰기 시작하면서 원래 의미가 빠르게 사라졌음
요약하면, 이제 Redis를 신뢰할 수 없게 됨
LLM 없는 포크는 누가 만들 건가?
제시된 사용 사례 중 일부는 ZSET으로도 가능하지 않나? 성능 관점은 이해하지만, 배열이 선택적으로 희소 표현을 쓰듯 조밀한 값에 대해 ZSET 저장 방식을 선택적으로 최적화하면 새 API 표면 없이도 가능했을 것 같음
정규식 구성요소는 흥미롭지만, 여기서도 언급됐듯 배열 자료구조와는 직교적인 기능으로 보임. 즉 다른 구조에서도 쓸 수 있음. 이건 Lua 스크립팅으로 하는 편이 더 맞지 않나? Lua 성능이 문제라면, 값 범위를 반환하는 어떤 명령 위에도 조합할 수 있도록 OP를 추상화하는 방법도 있을 듯함
Antirez가 이 분야 전문가라는 점은 존중하지만, 이 새 기능 집합 일부는 LLM 주도 개발에서 자주 보이는 해법처럼 느껴짐. 기존 기능을 개선하기보다 새 기능을 만들고, 다른 기능과 조합하는 편이 더 효과적일 수 있는데 기능을 과하게 복잡하게 만드는 식임
아쉽게도 그렇지 않음. 정렬 집합은 스펙트럼의 거의 반대쪽에 있음. 의미론적으로는 깔끔하지만, 스킵 리스트와 배열의 결합 때문에 매우 낭비적임
또한 내부 표현이 배열이 아니라면 범위 질의와 링 버퍼는 필요한 만큼 효율적이고 압축적으로 동작할 수 없음
이론적으로는 무엇으로든 무엇이든 할 수 있지만, 각 API가 할 수 있는 일을 분리해야 사용 사례를 활용해 최적의 내부 구현을 제공할 수 있음
antirez에게 궁금함. 최종 코드로 사실상 원샷 생성을 실험해봤는지? GEPA로 거기까지 갈 수 있을지, 원하는 결과를 끌어내는 유도나 프롬프트 방식에서 배울 점이 있을지도 궁금함
아니면 결론은 모델 제공자들이 학습 데이터를 정리해야 한다는 것일 수도 있음
같은 일을 설명하는 말을 나도 점점 줄이게 됨. 시간이 갈수록 우리가 “그” 작업을 더 자주 하게 되기 때문임
다만 용어를 auto-code로 줄이면 도움이 될 수도 있음
아주 숙련된 개발자들이 요즘 AI와 어떻게 상호작용하는지 보는 건 늘 흥미로움
@antirez: 프로젝트 후반에 겉보기에는 별개의 기능인 정규식 기능을 도입한 건 조금 이상하게 느껴짐. 그 판단 근거를 더 설명해줄 수 있나?
배열이 텍스트 파일에 아주 잘 맞는다는 걸 깨닫고 나니, 떠올릴 수 있는 많은 사용 사례가 결국 파일에서 grep이 필요하다는 사실에 막혔음
그래서 파일에서 AROP에 해당하는 것이 뭘까 생각했고, 답은 ARGREP이었음
이후 사용 사례에 따라 최적 도구를 쓸 수 있도록 빠른 정확 일치와 정규식 일치를 모두 넣었음
그러다 OR로 묶인 여러 문자열에서는 정규식이 잘 최적화되면 더 빠를 수 있다는 걸 발견했고, TRE를 조금 특화했음
Hacker News 의견들
분명히 해두자면, 이건 Redis의 원작자 또는 그중 한 명이 한 일임
그는 “평균적인 개발자”가 아니고, LLM을 써도 4개월이 걸렸음
그러니 이걸 근거로 모든 개발자에게 Claude Code, Codex, 기타 AI 코딩 도구로 완전히 옮기라고 지시해도 된다는 승인 도장처럼 받아들이면 안 됨
특히 평범한 스타트업 CEO들이 봐야 할 대목임
원문에서는 “LLM 이전에도 구현 자체는 아마 4개월 안에 할 수 있었을 것이다. 달라진 건 같은 기간에 훨씬 더 많은 일을 할 수 있었다는 점”이라고 했음
즉 초기 기간은 원래 4개월이었고, LLM 덕분에 같은 기간 안에 더 많은 작업을 한 것임
평균적인 개발 업무는 배관 작업과 CRUD에 가까움
현재 쓰는 방식은 이럼
먼저 AI 도움을 받아 상위 설계 문서를 Markdown으로 작성함. 그다음 같은 모델이되 문맥을 빼거나, 다른 모델에게 비판하게 해서 버그·누락·빈틈을 찾게 함. 나중에 보면 뻔한 것들을 항상 찾아냄
그러면 그 발견을 요약하게 해서 첫 번째 AI에 붙여넣고 의견을 묻는다. 합의된 변경을 만들고 반영한 뒤, 어떤 모델도 의미 있는 제안을 못 할 때까지 이런 적대적 라운드로빈을 계속함
이후 AI에게 계획을 만들게 하고, 그 계획도 여러 AI 사이에서 적대적으로 돌림. 결국 꽤 탄탄한 계획이 나옴
그다음 종단 간 테스트 케이스 계획 등으로 넘어감. 시스템 규모에 따라 첫날, 첫 주, 첫 달이 끝날 즈음 코딩 준비가 됨
코드가 만들어지면 그 코드와 명세, 계획을 다른 AI에 붙여넣고 버그·누락·빈틈을 찾게 함. 구현을 맡은 주 AI를 계속 다른 AI로 검증하는 방식임
물론 코드는 직접 읽어야 함. AI가 마감 품질의 세부 polish를 놓치는 걸 봤기 때문임
비꼬려는 건 아님. 내 작업 흐름도 본질적으로 같고, Google을 비웃자는 것도 아님. 오히려 새로울 건 없다는 뜻임
AI는 효과적인 작업 흐름과 비효과적인 작업 흐름을 모두 엄청나게 가속함. 덕분에 무엇이 효과적이고 무엇이 비효과적인지 훨씬 짧은 시간, 거의 실시간으로 드러남
다른 에이전트도 쓴다고 했는데, 덜 다듬어진 부분을 다른 에이전트가 polish하는 코드 리뷰에서 효과를 봤는지 궁금함. 내 동료들은 강하게 믿지만, 개인적으로는 인간 리뷰어 없이 가치가 있는지 아직 회의적임
“다른 AI에게 묻는다”는 방식은 응용 컴퓨터과학에서는 정립-반정립-종합이 더 잘 맞는지도 모르겠음: https://en.wikipedia.org/wiki/Dialectic#Criticisms
antirez가 작성했더라도, 이 정도 기능 집합과 최소한의 PR 설명으로 22,000줄 코드 리뷰를 하는 건 악몽처럼 들림
Postgres 같은 주요 오픈소스가 왜 메일링 리스트에서 개발되는지 이해가 감. 중간 설계 결정을 커뮤니티와 논의하고, 관련 기능도 별도 패치로 나누며, 점진적으로 리뷰하고, 릴리스 간격도 띄워서 진행하는 방식임
희소 배열이 2,000줄
t_array명령과 상위 계층 구현이 2,000줄AOF/RDB 코드가 약 500줄
나머지는 테스트, JSON 명령 설명,
deps아래 TRE 라이브러리임사실상 주요 Redis 기능 대부분은 글쓴이가 혼자 만든 작업임
게다가 리뷰어들은 이 일을 잘 알고 보수도 제대로 받음
현재 최고 수준 AI를 써본 내 경험과 매우 비슷함. 인간 지능과 창의성의 대체재와는 거리가 멀지만, 협업자로는 극도로 유용함
하지만 Redis는 아직 아님. 언젠가 서버 소프트웨어에서 이것이 가능해지면, 오늘날의 개발 방식은 끝날 것임
기능, 수정, 경험의 축적은 여전히 가치가 있으니 프로젝트와 저장소는 남겠지만, 프로그래머의 역할은 지금까지 Linus가 커널에 해온 역할과 매우 비슷해질 것임
DeepSeek v4 추론 엔진 같은 일부 프로젝트에서는 이미 그런 식으로 작업 중임
array/regex가 기대되고, LLM으로 능력을 확장한 경험도 매우 흥미로움. 여러 프로젝트에서 조용히 비슷한 시도를 하는 사람이 많음
바이브 코딩과 그에 대한 반발만으로는 이런 작업 방식을 제대로 설명하지 못함
그런데 곧 사람들이 거의 모든 형태의 AI 보조 코딩에 이 말을 쓰기 시작하면서 원래 의미가 빠르게 사라졌음
요약하면, 이제 Redis를 신뢰할 수 없게 됨
LLM 없는 포크는 누가 만들 건가?
제시된 사용 사례 중 일부는 ZSET으로도 가능하지 않나? 성능 관점은 이해하지만, 배열이 선택적으로 희소 표현을 쓰듯 조밀한 값에 대해 ZSET 저장 방식을 선택적으로 최적화하면 새 API 표면 없이도 가능했을 것 같음
정규식 구성요소는 흥미롭지만, 여기서도 언급됐듯 배열 자료구조와는 직교적인 기능으로 보임. 즉 다른 구조에서도 쓸 수 있음. 이건 Lua 스크립팅으로 하는 편이 더 맞지 않나? Lua 성능이 문제라면, 값 범위를 반환하는 어떤 명령 위에도 조합할 수 있도록 OP를 추상화하는 방법도 있을 듯함
Antirez가 이 분야 전문가라는 점은 존중하지만, 이 새 기능 집합 일부는 LLM 주도 개발에서 자주 보이는 해법처럼 느껴짐. 기존 기능을 개선하기보다 새 기능을 만들고, 다른 기능과 조합하는 편이 더 효과적일 수 있는데 기능을 과하게 복잡하게 만드는 식임
또한 내부 표현이 배열이 아니라면 범위 질의와 링 버퍼는 필요한 만큼 효율적이고 압축적으로 동작할 수 없음
이론적으로는 무엇으로든 무엇이든 할 수 있지만, 각 API가 할 수 있는 일을 분리해야 사용 사례를 활용해 최적의 내부 구현을 제공할 수 있음
antirez에게 궁금함. 최종 코드로 사실상 원샷 생성을 실험해봤는지? GEPA로 거기까지 갈 수 있을지, 원하는 결과를 끌어내는 유도나 프롬프트 방식에서 배울 점이 있을지도 궁금함
아니면 결론은 모델 제공자들이 학습 데이터를 정리해야 한다는 것일 수도 있음
Salvatore가 Automatic Programming/Coding이라는 용어를 대중화하고 싶어 하는 것 같음. (https://antirez.com/news/159)
물론 LLM은 비결정적이고 범위가 놀랄 만큼 넓다는 점에서 매우 특이하지만, 그렇다고 이 용어가 적용되지 않는 것은 아님
다만 용어를 auto-code로 줄이면 도움이 될 수도 있음
아주 숙련된 개발자들이 요즘 AI와 어떻게 상호작용하는지 보는 건 늘 흥미로움
@antirez: 프로젝트 후반에 겉보기에는 별개의 기능인 정규식 기능을 도입한 건 조금 이상하게 느껴짐. 그 판단 근거를 더 설명해줄 수 있나?
그래서 파일에서 AROP에 해당하는 것이 뭘까 생각했고, 답은 ARGREP이었음
이후 사용 사례에 따라 최적 도구를 쓸 수 있도록 빠른 정확 일치와 정규식 일치를 모두 넣었음
그러다 OR로 묶인 여러 문자열에서는 정규식이 잘 최적화되면 더 빠를 수 있다는 걸 발견했고, TRE를 조금 특화했음