이 블로그의 과거 기록을 한번 보라. AI를 활용한 프로그래밍에 대한 글이 많다. 그중 몇 개는 2024년 1월까지 거슬러 올라간다(예를 들면 이런 글: https://antirez.com/news/140). 어쨌든 나는 비교적 인정받는 프로그래머다. 나는 관종 늙은이처럼 여전히 관심을 끌어야 할 필요가 없다. 최근에 Redis에 복귀했고, 지금은 커뮤니티에서 좋은 반응을 얻은 로컬 LLM 추론용 오픈소스 소프트웨어도 새로 개발하고 있다. 그런데도 왜 사람들이 듣기 싫어하는 말을 계속하는 걸까? 왜 미래의 프로그래밍이 기본적으로 어떤 모습일지를 계속 예고하는 걸까? 나보다 변화에 덜 대비된 사람들, 대개 나보다 젊고 나와 달리 이런 변화를 전혀 예상하지 못했던 사람들이 겪을 충격을 조금이라도 줄이고 싶다는 절박함 때문이다(2022년에 나는 ChatGPT가 존재하기도 전에 많은 것을 미리 예고한 책을 냈고, 지금 그중 많은 것이 현실이 됐으며 앞으로 일어날 것이라 믿는 다른 것들도 있다. 그래서 자만처럼 들리지 않고 이렇게 말할 수 있다고 생각한다).

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

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

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

아이디어를 통제하는 것. 『인월의 신화』에 나오는 그 표현을 기억하는가? 70년대에 나온 그 책이 2000년부터 2020년 사이에 나온 많은 글들보다 지금의 소프트웨어 시대에 대해 더 많은 것을 말해준다. 지금 AI에 반대하며 항의하는 사람들은 지난 10년간 소프트웨어의 상태를 보고 왜 경악하지 않았던 걸까? AI 이전 최근 몇 년간 우리가 마주한 엉망진창의 수준은 믿기 어려울 정도다. 한 가지 더 말해주겠다. 엉망진창이란 무엇인가? 나는 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 sets의 메모리를 50% 절약하는 최적화에 대해서도 다시 그렇게 하고 있고, 곧 PR을 올릴 예정이다. 하지만 이제는 이게 더 이상 유용하다고 느껴지지 않는다. 더 이상 아무도 이 코드를 들여다봐서는 안 되고, 코드가 담고 있는 아이디어만 봐야 한다. 나는 사용자에 대한 예의 때문에 계속 그렇게 해왔다. Redis는 이제 보편적으로 유용한 것이 되었고, 많은 프로그래머들이 파일을 열어 직접 수정할 것이다. 하지만 내 손이 자유롭다면 내가 대신 무엇을 하겠는가? 리뷰에 쓰고 있는 모든 시간을 더 많은 QA를 하고, 다음 최적화 아이디어를 고민해 적용하며, LLM을 이용해 각 자료구조를 인간의 언어로 설명하는 DESIGN.md 파일을 쓰는 데 쓸 것이다. 거기에는 그 자료구조가 담고 있는 아이디어, 구현 트릭, 설계가 담긴다. 앞으로는 그게 훨씬 더 유용할 것이다. sorted sets를 수정하고 싶은가? 파일을 열어 설계를 읽으면 아이디어를 온전히 소유하게 된다. 그러면 올바른 멘탈 모델을 가지고 에이전트를 열어 무엇을 해야 할지 물을 수 있다. 이게 코드를 리뷰하는 것보다 훨씬 유용하다.

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

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