이 블로그의 연재 이력을 살펴보면, AI를 활용한 프로그래밍을 다룬 글이 상당수 있다. 일부는 2024년 1월까지 거슬러 올라간다(예:
https://antirez.com/news/140). 필자는 업계에서 어느 정도 인정받는 프로그래머다. 그렇기에 나이 든 개발자로서 억지로 흐름을 쫓을 필요는 없다고 생각해왔다. 최근에는 Redis에 다시 합류했고, 로컬 LLM 추론을 위한 새로운 오픈소스 소프트웨어도 개발 중인데 커뮤니티에서 좋은 반응을 얻고 있다. 그런데도 왜 사람들이 듣기 싫어하는 말을 계속 하는 걸까? 왜 미래의 프로그래밍이 어떻게 달라질지 끊임없이 선언하는 걸까? 변화에 덜 준비된 이들—나보다 젊은 경우도 많고, 나와 달리 이런 흐름을 미리 예견하지 못한 이들—이 겪을 충격을 조금이라도 줄여주고 싶기 때문이다. (2022년, ChatGPT가 등장하기도 전에, 지금 실현된 많은 것들과 앞으로 일어날 것들을 예고한 책을 출판했다. 그래서 이 말이 자만으로 들리지 않으리라 믿는다.)
사실 이건 일종의 전략이다. 점점 더 많은 프로그래머들이 AI로 인해 개발 방식이 근본적으로 달라지고 있음을 실감하면서도, 어떻게 해야 할지 갈피를 잡지 못하고 있다. 코드를 주된 산출물로 바라보지 않는, 완전히 다른 방식으로 개발에 임해도 괜찮은지 확신하지 못한다. 자신의 분야를 배신하는 것 같은 죄책감까지 느낀다. 그래서 필자는 이렇게 말하고 싶다. "나를 봐라. 나는 코드를 짤 줄 안다. AI 뒤에 숨지 않는다. 그런데도 세상은 바뀌었다. 이건 당신의 약점이 아니고, AI에 물든 것도 아니다. 우리 분야가 놀랍도록—고통스럽고, 동시에 설레는 방향으로—진화하고 있을 뿐이다."
그래서 어제 X에서 이런 말을 했다. 지금 많은 프로그래머들이 코드를 들여다보는 데 집중한 나머지 본래 발휘할 수 있는 역량을 충분히 펼치지 못하고 있다고. 진심으로 그렇게 생각한다. 단, 이 말이 최종 결과물만 던져놓고 기다리는 식의 바이브 코딩(vibe coding)을 하라는 뜻은 아니다. 핵심은 이것이다. 소프트웨어의 아이디어를 장악하고 있다면, 코드 자체를 직접 들여다보는 건 최선이 아니며 종종 무의미하다. 이유는 다음과 같다.
1. 이제는 방대한 양의 코드를 생성할 수 있다. LLM이 코드를 장황하게 작성하는 특성을 고려하지 않더라도(이는 대부분 프롬프트를 잘못 작성한 탓이기도 하다). 매일 5,000줄의 코드를 어떻게 다 리뷰하겠는가?
2. LLM은 국소적으로 최적화된 코드를 작성하는 데는 탁월하지만, 큰 그림의 설계에는 상대적으로 취약하다(물론 개선되고 있다). 함수 하나하나, 줄 하나하나를 훑어보는 게 무슨 의미가 있나? 대신 염두에 둔 설계를 프롬프트로 제시하고, 때로는 "이 부분의 설계가 정확히 어떻게 되어 있나? 어떻게 동작하나?"라고 물어보며, 그 모델이 적합한지 판단하는 편이 훨씬 빠르다.
3. 하루 업무 시간은 8시간이다. 코드를 읽는 데 시간을 쓴다는 건 트레이드오프다. 오늘날 가장 중요한 업무—즉, "이 소프트웨어로 무엇을 하려는가? 다음에는 어떤 방향으로 나아갈 것인가?"를 스스로에게 묻는 일—에 할애할 시간이 줄어든다. 새로운 아이디어와 기능, 최적화 방법을 구상하고, QA에 충분히 시간을 투자하는 것도 마찬가지다.
아이디어를 장악하는 것. 《맨먼스 미신(The Mythical Man Month)》에 나오는 이 표현이 기억나는가? 1970년대 책 한 권이 2000년부터 2020년 사이에 나온 수많은 이야기들보다 지금 이 시대에 대해 더 많은 진실을 담고 있다. AI에 반기를 드는 이들이 지난 10년간 소프트웨어의 참담한 현실에는 왜 경악하지 않았는지 묻고 싶다. AI 이전에 우리가 경험한 슬롭(slop)의 수준은 실로 믿기 어려운 것이었다. 한 가지 더 말하겠다. 슬롭이 무엇인지 생각해보자. DwarfStar 프로젝트에서 두 LLM(DeepSeek v4와 GLM 5.2)의 추론을 완전 자동화된 방식으로 구현했다. 하지만 직접 해보면 알겠지만, "XYZ를 구현해줘"라고 한마디 하고 곧바로 작동하는 결과물을 얻을 수는 없다. 작동 원리를 이해하고, 최선의 설계를 파악하고, 목표로 하는 성능 수준에 도달하는 방법을 알아야 한다. 이후 정확성 검증을 위해 다른 시스템의 구현과 비교해봤는데, 다른 구현에 오류가 더 많은 경우도 있었다. 더 깊이 조사할수록 로컬 추론 생태계에는 누적된 미묘한 오류들이 가득했다. 어텐션(attention) 구현의 문제로 컨텍스트가 일정 한도를 넘어서면 성능이 급격히 저하되거나(인덱스 기반 어텐션 구현이 필요 이상의 연산을 수행하는 등), 모델 출력 품질을 떨어뜨리는 이슈들이 곳곳에 있었다. 이는 도메인 자체가 다루기 까다롭고 변화 속도가 빠른 데다, 추론 그래프가 미묘하게 다른 모델들이 매일 쏟아지는 환경이기 때문이다. 개발자 입장에서는 불공평한 게임이다. 그런데 AI는 이 상황에서 엄청난 도움이 된다. 엄밀한 설계와 테스트가 GPU 커널을 손으로 직접 작성하거나 읽는 것보다 훨씬 효과적인 도메인이 얼마나 많은가. 그렇다면 그 저항의 상당 부분이 이념적인 것은 아닐까?
어제 Matteo Collina가 내 트윗에 이런 질문을 남겼다. "Redis에서 AI가 생성한 코드를 전부 직접 확인한다고 하지 않았나요?" 좋은 질문이다. 맞다, 그렇게 하고 있다. 하지만 솔직히 말하면, 지금 이 시점에서 그건 해야 한다고 생각해서 하는 일이지, 실제로 유의미하다고 믿어서 하는 일이 아니다. GPT 5.5 출시 이후부터 그런 생각이 들기 시작했고, Fable과 GPT 5.6 Sol이 나온 지금은 더욱 그렇다. 물론 마음에 들지 않는 방식으로 작성된 코드를 발견하기도 한다. 하지만 다른 Redis 기여자들이 작성한 파일을 열어보면 훨씬 심한 경우도 있다. 그들이 나쁜 개발자라서가 아니라, 코딩 스타일은 결국 취향의 문제이기 때문이다. 필자는 가독성을 위해 매우 깔끔한 코드를 추구하는 편이라, Redis Arrays를 구현하는 동안 여러 부분을 수정했다. Redis 정렬된 집합(sorted set)의 50% 메모리 절감 최적화 작업에서도 같은 방식으로 진행 중이며, 곧 PR로 제출할 예정이다. 하지만 이 작업이 더 이상 의미 있다고 느껴지지 않는다. 이제는 누구도 코드 자체를 들여다볼 게 아니라, 코드에 담긴 아이디어를 봐야 한다. 그럼에도 사용자들에 대한 존중으로 계속해왔다. Redis는 이제 수많은 개발자들이 파일을 열어 직접 수정하는, 폭넓게 쓰이는 도구가 됐다. 하지만 완전히 자유롭게 결정할 수 있다면? 리뷰에 쓰는 시간 전부를 QA에 쏟고, 다음 최적화 아이디어를 구상하고 적용하고, LLM을 활용해 DESIGN.md 파일을 작성하는 데 쓸 것이다. 각 자료구조를 사람이 읽을 수 있는 언어로 기술하고, 아이디어와 구현 기법, 설계를 담은 문서 말이다. 그것이 미래에는 훨씬 더 유용할 것이다. 정렬된 집합을 수정하고 싶다면? 파일을 열고 설계 문서를 읽는다. 그러면 아이디어를 이해하게 된다. 에이전트를 열고 올바른 멘탈 모델(mental model)로 무엇을 해야 할지 물어볼 수 있다. 코드를 리뷰하는 것보다 훨씬 유용한 접근이다.
Fable과 GPT 5.6이 정렬된 집합 메모리 절감 코드를 리뷰한다면, 내가 직접 검토하는 것보다 훨씬 더 많은 오류와 미묘한 레이스 컨디션(race condition)을 잡아낼 것이다. 그래도 계속 직접 리뷰할 것이다. 하지만 대다수의 소프트웨어 프로젝트에서 이런 방식은 더 이상 합리적이지 않다. 대신 아이디어를 장악하는 데 집중하라. 품질과 테스트, 그리고 만들고자 하는 소프트웨어에 대한 명확한 비전에 집중하라. 세상은 바뀌었고, 그 과정은 고통스럽다. 하지만 이미 깊이 썩어 들어간 소프트웨어 세계를 개선할 기회로도 가득 차 있다.
한 가지 의문이 드는 건 경험이 부족해 아직 멘탈 모델을 형성하지 못한 젊은 프로그래머들에 관한 부분이다. 특정 코드가 어떻게 동작하는지 깊이 이해하는 것이 그들에게 필요한지 아닌지는 아직 알 수 없다. 다만 프로그램을 작성하는 방법은 배워야 한다고 생각한다. 그러나 LLM이 생성한 출력을 검토하는 것이 그 올바른 방법인지는 확신하지 못한다. 어떤 프로그래밍 언어를 배우고 작은 인터프리터, 작은 데이터베이스, 해시 테이블 같은 것을 직접 구현해보는 편이 훨씬 더 유익할 수 있다. 고객사 웹사이트의 자바스크립트 코드를 리뷰하는 것? 절대 아니다. 그런 것에 시간을 낭비하지 마라.
