이 블로그의 과거 글을 한번 돌아봐 달라. AI로 프로그래밍하는 것에 대한 글이 많다. 그중 몇 개는 2024년 1월까지 거슬러 올라간다(이 글처럼: https://antirez.com/news/140). 어쨌든 나는 비교적 널리 알려진 프로그래머다. 의미를 좇는 늙은이처럼 여전히 ‘루프’ 안에 머물러야 할 필요가 있는 사람도 아니다. 최근 Redis에 다시 합류했고, 지금은 로컬 LLM 추론을 위한 새로운 오픈소스 소프트웨어를 개발하고 있는데 커뮤니티의 반응도 좋다. 그런데도 왜 나는 사람들이 듣고 싶어 하지 않는 말을 계속하는가? 왜 미래의 프로그래밍이 기본적으로 어떤 모습일지를 계속 선언하는가? 나보다 변화에 덜 준비된 사람들, 종종 나보다 젊은 사람들, 그리고 나와 달리 그런 일들이 다가오고 있음을 보지 못했던 사람들이 받을 충격을 조금이라도 줄이고 싶다는 절박함 때문이다(2022년, ChatGPT가 존재하기도 전에 나는 지금 일어난 많은 일들과 앞으로 일어날 것이라 믿는 일들을 미리 알린 책을 출간했다. 그래서 자의식 과잉처럼 들리지 않고도 이렇게 말할 수 있다고 생각한다).

그래서 내 방식은 일종의 트릭이다. 사람들은 프로그래밍이 AI로 인해 완전히 바뀌고 있음을 점점 더 느끼면서도 무엇을 해야 할지 모른다. 코드를 주된 산출물로 여기며 들여다보지 않고도 정말로 완전히 다른 방식으로 코딩을 시작해도 되는 건지 확신이 없다. 마치 자신의 분야를 배신하는 것 같다고 느낀다. 그래서 내가 나타나 “나를 봐라, 나는 코드를 쓸 수 있다, 알지 않나, AI 뒤에 숨어 있는 게 아니다. 그런데도 세상은 바뀌었다. 이건 너의 약함이 아니고, 네가 AI에 세뇌된 것도 아니다. 단지 우리 분야가 놀랍고도 고통스러운(그러나 동시에 즐거운) 방향으로 진화하고 있을 뿐이다”라고 말하려는 것이다.

그래서 어제 X에서 나는 이 시점에 많은 프로그래머들이 코드를 들여다보기 때문에 본래 낼 수 있는 영향력보다 적은 영향력을 내고 있다고 믿는다고 말했다. 나는 진심으로 그렇게 믿는다. 그리고 이는 최종 결과물만 달라고 해서 바이브 코딩하라는 뜻이 아님을 밝혀둔다. 요점은 이것이다. 소프트웨어의 아이디어를 통제하고 있다면, 코드 자체를 들여다보는 것은 비효율적이며 종종 무의미하다. 이유는 다음과 같다.

1. 이제 엄청난 양의 코드를 생성할 수 있다. LLM 특유의 장황함을 감안하지 않더라도 그렇다(그 장황함은 대부분 LLM에게 제대로 지시하지 못해서 생기는 것이기도 하다). 매일 5천 줄의 코드를 어떻게 리뷰하라는 말인가?
2. LLM은 국소적으로 최적화된 코드를 작성하는 데는 매우 뛰어나지만, 큰 그림의 아이디어에서는 약하다(물론 개선되고 있다). 함수 단위로, 한 줄 한 줄 훑는 것이 무슨 의미가 있나? 대신 머릿속에 있는 설계를 프롬프트로 제시하고, 때로는 “그 부분의 설계는 정확히 어떻게 되어 있지? 어떻게 동작하지?”라고 물은 뒤, 그것이 올바른 모델인지 평가해야 한다. 훨씬 빠르다.
3. 근무 시간은 8시간이다. 코드를 읽는 것은 트레이드오프다. 오늘날 업무에서 가장 중요한 일을 덜 하게 되는 것이다. 즉, 스스로에게 묻는 일이다. 나는 이 소프트웨어로 무엇을 하고 있는가? 어떤 새로운 방향으로 나아가고 싶은가? 그리고 새로운 아이디어, 기능, 최적화 트릭을 고민하고, 많은 QA를 수행하는 일이다.

아이디어를 통제하라. 『The Mythical Man-Month』에 나오는 이 표현을 기억하는가? 70년대의 책 한 권이 2000년부터 2020년 사이에 나온 많은 이야기보다 오늘날 소프트웨어 시대에 대해 더 많은 것을 알려준다. 지금 AI에 반대하며 항의하는 사람들은 왜 지난 10년간 소프트웨어의 상태에 경악하지 않았는가? AI 이전 최근 몇 년간 우리가 마주한 엉망진창(slop)의 수준은 믿기 어려울 정도다. 한 가지 더 말하겠다. slop이란 무엇인가? 나는 DwarfStar에서 두 LLM(DeepSeek v4와 GLM 5.2)에 대한 추론을 완전히 자동화된 방식으로 구현했다. 하지만 직접 해보면 알게 된다. 그저 “XYZ를 구현해 줘”라고 말한다고 해서 동작하는 것을 볼 수 없다는 사실을. 어떻게 동작하는지, 무엇이 최선의 설계인지, 어떻게 특정 수준의 성능에 도달할 수 있는지를 이해해야 한다. 그런 다음 정확성을 검증하기 위해 다른 시스템들과 구현을 비교했는데, 다른 구현들이 때로는 더 많은 오류를 포함하고 있음을 발견했다. 더 조사해 보니 로컬 추론 세계는 미묘한 오류들로 가득했고, 그 오류들이 누적되어 모델 출력을 망치고 있었다. 예를 들어 어텐션 구현의 문제로 컨텍스트가 일정 길이를 넘으면 성능이 급격히 떨어지는 현상, 인덱싱된 어텐션 구현이 망가져서(예컨대 필요 이상으로 많은 연산을 수행하는) 생기는 문제 등이었다. 이는 다루기 매우 복잡하고 빠르게 변화하며, 추론 그래프가 서로 약간씩 다른 모델들이 매일 쏟아져 나오는 분야의 결과다. 개발자에게는 불공정한 게임이다. 그런데 AI는 이런 부분에서 큰 도움이 된다. 설계 측면에서의 엄격한 엔지니어링과 테스트가 GPU 커널을 손으로 직접 작성하는(혹은 읽는) 것보다 *훨씬* 나은 영역이 많이 있다. 그렇다면 그 저항의 대부분이 이념적인 것이 아니라고 확신할 수 있는가?

Matteo Collina가 어제 내 트윗에 답글로 물었다. 하지만 Redis에서는 AI가 생성한 코드를 전부 확인한다고 하지 않았느냐고. 정말 좋은 질문이다. 그렇다, 나는 확인한다. 하지만 이제 와서 보면 그것은 내가 *해야만* 하는 일이면서도 대부분은 무의미하다고 믿는 일이다. GPT 5.5가 출시된 이후로는 부분적으로 그랬고, 이제 Fable과 GPT 5.6 Sol이 나온 뒤로는 더욱 그렇다. 그렇다, 나는 마음에 들지 않는 코드 작성 방식을 찾아내곤 한다. 하지만 다른 Redis 기여자들이 작성한 다른 Redis 파일들을 열어보면 *훨씬 더* 엉망인 경우가 있다. 그들이 좋은 코더가 아니어서가 아니라, 취향의 문제이기 때문이다. 나는 코드가 읽기 쉽기를 바라기 때문에 매우 깔끔한 코드를 작성한다. 그래서 Redis Arrays를 구현하는 동안에도 수정을 가했다. 지금 Redis sorted set의 메모리 50% 절감 최적화에서도 같은 일을 하고 있다. 곧 PR로 제출할 예정이다. 하지만 이제는 이게 더 이상 유용하다고 느껴지지 않는다. 더 이상 아무도 이 코드를 들여다봐서는 안 된다. 코드가 담고 있는 아이디어만 봐야 한다. 내가 계속 이렇게 해온 것은 사용자에 대한 존중 때문이다. Redis는 이제 널리 쓰이는 유용한 존재가 되었고, 많은 프로그래머들이 파일을 열어 손으로 직접 수정할 것이다. 하지만 내 손이 자유롭다면, 대신 무엇을 하겠는가? 리뷰에 쓰고 있는 모든 시간을 더 많은 QA를 하고, 다음 최적화 아이디어를 고민해 적용하며, LLM을 이용해 각 자료구조를 인간의 언어로 설명하고 그 안에 담긴 아이디어, 구현 트릭, 설계를 담은 DESIGN.md 파일을 작성하는 데 쓰고 싶다. 미래에는 그게 훨씬 더 유용할 것이다. sorted set을 수정하고 싶은가? 파일을 열어 설계를 읽으면 아이디어를 소유하게 된다. 그러면 에이전트를 열고 올바른 멘탈 모델을 가지고 무엇을 해야 할지 물을 수 있다. 이는 코드를 리뷰하는 것보다 훨씬 유용하다.

Fable과 GPT 5.6이 sorted set 메모리 절감에 대해 수행하는 리뷰는 내 리뷰가 찾아낼 수 있는 것보다 훨씬 더 많은 오류와 미묘한 레이스 컨디션을 잡아낼 것이다. 그럼에도 나는 리뷰를 할 것이다. 하지만 대다수의 소프트웨어 프로젝트에서는 이 모든 것이 더 이상 의미가 없다. 대신 아이디어를 통제하는 데 집중하라. 품질, 테스트, 그리고 출시하고 싶은 소프트웨어에 대한 명확한 구상에 집중하라. 세상은 바뀌었고 고통스럽지만, 이미 완전히 썩어 있던 소프트웨어 세상을 개선할 기회로 가득하기도 하다.

젊은 프로그래머들에 대해서만 한 가지 의문이 있다. 경험이 부족해 멘탈 모델을 구축하지 못하는 이들이다. 특정 코드 조각이 어떻게 동작하는지 아주 잘 이해해야 할지 아닐지는 아직 모른다. 하지만 나는 그들이 프로그램을 작성하는 법을 배워야 한다고 믿는다. 다만 LLM의 출력을 확인하는 것이 그들이 해야 할 올바른 일인지는 확신이 서지 않는다. 어떤 프로그래밍 언어를 배워 작은 인터프리터, 작은 데이터베이스, 해시 테이블 등을 직접 구현해 보는 것이 훨씬 더 유용할지도 모른다. 고객을 위해 웹사이트의 자바스크립트 코드를 리뷰하는 일이라면? 제발, 그런 쓰레기 같은 데 시간 낭비하지 마라.