AI가 프로그래밍을 바꾸는 시대에, 코드를 일일이 들여다보기보다 소프트웨어의 아이디어와 설계를 통제하는 일이 왜 더 중요해졌는지에 대한 글.
antirez 1시간 전. 조회수 7798. 이 블로그의 지난 기록을 보라. AI로 프로그래밍하는 것에 관한 블로그 글이 많이 있고, 그중 몇 개는 2024년 1월까지 거슬러 올라간다(예를 들어 이것: https://antirez.com/news/140). 어쨌든 나는 비교적 잘 알려진 프로그래머다. 나는 주목받고 싶어 하는 늙은이가 되어 여전히 "루프 안"에 남아 있을 필요가 없고, 최근 Redis에 다시 합류했으며, 지금은 로컬 LLM 추론을 위한 새로운 오픈 소스 소프트웨어도 개발하고 있고 이것은 커뮤니티에서 좋은 반응을 얻었다. 왜 나는 사람들이 듣고 싶어 하지 않는 말을 계속할까? 왜 나는 미래의 프로그래밍이 기본적으로 어떻게 될지를 계속 선언할까? 그 이유는 나보다 변화에 덜 준비된 사람들, 종종 나보다 젊고, 그리고 나와는 달리 이런 일들 중 많은 것을 미리 보지 못한 사람들에게 닥칠 충격을 줄이고 싶은 충동을 느끼기 때문이다(나는 2022년에 ChatGPT가 존재하기도 전에, 지금 벌어진 많은 일들과 내가 믿기로는 앞으로 일어날 다른 일들을 미리 알린 책을 출간했으니, 이것을 자아도취적으로 들리지 않게 말할 수 있다고 느낀다).
그래서 내가 하는 일에는 일종의 요령이 있다. 사람들은 점점 더 프로그래밍이 AI에 의해 완전히 바뀌고 있다고 느끼지만, 자신이 무엇을 해야 하는지, 정말로 코드를 주된 결과물로 많이 보지 않으면서 완전히 다른 방식으로 코딩을 시작해도 되는지 모른다. 그들은 마치 자기 분야를 배신하는 듯한 느낌을 받는다. 그래서 내 의도는 나타나서 이렇게 말하는 것이다. "나를 봐라, 나는 코드를 쓸 수 있다. 알다시피 나는 AI 뒤에 숨는 게 아니다. 그런데도 상황은 바뀌었다. 이것은 너의 약함이 아니고, 네가 AI에 홀린 것도 아니다. 그저 우리 분야가 믿을 수 없을 정도로 그리고 고통스럽게(하지만 또한 즐겁게) 진화하고 있을 뿐이다."
이것이 바로 내가 어제 X에서, 많은 프로그래머가 지금 시점에서는 코드를 보기 때문에 자신이 낼 수 있는 것보다 더 적은 영향을 내고 있다고 믿는다고 말한 이유다. 나는 정말로 그렇게 믿는다. 그리고 이것이 단지 최종 결과물만 요청하면서 대충 vibe code 하라는 뜻은 아니라는 점에 주목하라. 핵심은 이렇다. 당신이 소프트웨어의 아이디어를 통제하고 있다면, 코드 자체를 들여다보는 일은 비효율적이며 종종 무의미하다. 이유는 다음과 같다.
이제는 매우 많은 코드를 생성할 수 있다. LLM 코드의 장황함까지 고려하지 않더라도 그렇다(그 장황함 역시 대부분은 우리가 그것들에게 제대로 지시하지 못하는 데서 오는 결과이기도 하다). 매일 5천 줄의 코드를 어떻게 리뷰할 것인가?
LLM은 국소적으로 최적인 코드를 쓰는 데는 매우 뛰어나고, 큰 아이디어에서는 더 약하다(하지만 개선되고 있다). 함수 하나하나, 줄 하나하나를 훑는 것이 무슨 의미가 있는가? 대신 당신이 머릿속에 가진 설계를 프롬프트로 주고, 때때로 "그 부분의 설계는 정확히 어떤가? 어떻게 작동하는가?"라고 물으며, 그것이 올바른 모델인지 평가해야 한다. 훨씬 빠르다.
노동 시간은 8시간이다. 코드를 읽는다면, 그것은 트레이드오프다. 당신은 오늘날 업무에서 가장 중요한 부분, 즉 스스로에게 이렇게 묻는 일을 덜 하게 된다. 나는 이 소프트웨어로 무엇을 하고 있는가? 내가 나아가고 싶은 새로운 방향은 무엇인가? 그리고 또한 새로운 아이디어, 기능, 최적화 요령을 생각하는 일도 덜 하게 된다. 그리고 많은 QA도 덜 하게 된다.
아이디어를 통제하는 것. 이 표현을 Mythical Man Month에서 기억하는가? 그렇다, 70년대의 한 책이 현재의 소프트웨어 시대에 대해 2000년부터 2020년까지 말해진 많은 것보다 더 많은 것을 알려준다. 지금 AI에 반대하며 항의하는 사람들은 왜 지난 10년간의 소프트웨어 상태에는 경악하지 않았는가? AI 이전 최근 몇 년 동안 우리가 도달했던 엉망진창의 수준은 믿기 어려울 정도다. 한 가지를 더 말하겠다. 엉망진창이란 무엇인가? 나는 DwarfStar로 두 개의 LLM(DeepSeek v4와 GLM 5.2)에 대한 추론을 완전히 자동화된 방식으로 구현했지만, 직접 해보라. 당신은 단순히 "XYZ를 구현하라"라고 말하고 그것이 작동하는 것을 볼 수 없다는 사실을 알게 될 것이다. 사물이 어떻게 작동하는지, 최선의 설계가 무엇인지, 특정 수준의 성능에 어떻게 도달할지를 이해해야 한다. 그런 다음 나는 구현의 정확성을 다른 시스템들과 비교했고, 다른 구현들이 때때로 더 많은 오류를 포함하고 있음을 발견했다. 더 조사해 보니, 로컬 추론 세계는 미묘한 오류들로 가득 차 있고 그것들이 누적되어 모델 출력에 손상을 주고 있었다. attention 구현의 문제 때문에 컨텍스트가 일정 한계를 넘으면 성능이 기울어지는데, 이는 indexed attention 구현이 망가져 있어서(예를 들어 필요 이상으로 더 많은 작업을 하기 때문에) 발생하는 문제들이다. 기타 등등. 이것은 다루기 매우 복잡하고, 빠르게 변하며, 추론 그래프에서 모델들이 서로 조금씩 다른 채로 매일 출시되는 분야의 결과다. 개발자에게는 불공정한 게임이다. 그런데 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 메모리 절감을 리뷰하면, 내 리뷰가 밝혀낼 수 있는 것보다 훨씬 더 많은 오류와 미묘한 race condition을 찾아낼 것이다. 그래도 나는 그것을 할 것이다. 하지만 대다수 소프트웨어 프로젝트에서는 이 모든 것이 더 이상 말이 되지 않는다. 대신 아이디어를 통제하는 데 집중하라. 품질, 테스트, 그리고 자신이 출하하고 싶은 소프트웨어에 대한 구상을 갖는 데 집중하라. 세상은 바뀌었고 그것은 고통스럽지만, 이미 완전히 썩어 있던 소프트웨어 세계를 개선할 기회로도 가득하다.
내게 한 가지 의문이 있는 것은 아직 충분한 경험이 없어서 정신 모델을 만들 수 없는 젊은 프로그래머들에 대해서뿐이다. 그들이 주어진 코드 조각이 어떻게 작동하는지 아주 잘 이해해야 할지 아닐지는 아직 알 수 없다. 하지만 나는 그들이 프로그램을 작성하는 법은 배워야 한다고 믿는다. 그렇지만 LLM 출력물을 확인하는 일이 그들이 해야 할 올바른 일인지는 확신이 없다. 그들이 어떤 프로그래밍 언어를 배우고, 작은 인터프리터, 작은 데이터베이스, 해시 테이블 등을 구현해 보는 것이 훨씬 더 유용할 수 있다. 고객을 위한 어떤 웹사이트의 Javascript 잡동사니를 리뷰한다고? 맙소사, 그런 헛된 일에 시간을 낭비하지 마라. blog comments powered by Disqus
