요약
1년 새 코드의 90% 이상을 AI 에이전트가 쓰게 됐지만, 연구와 글쓰기에는 아직 사람 손이 필요합니다.
세일즈포스 AI 연구소의 연구 엔지니어 벤 스톨로비츠가 1년 전에 이어 두 번째로 자신의 AI 사용법을 정리했습니다. 작년 이맘때는 마이크로소프트 윈도 AI 팀에 있었고, 지금은 토큰 비용으로 한 달에 약 3,000달러를 씁니다.
왜 중요한가
- 자동완성에 머물던 AI 코딩이 1년 만에 에이전트 여러 개를 동시에 부리는 일로 바뀌었음을 실제 사용 기록으로 보여 줍니다.
- 기계가 코드를 써도 설계 판단과 취향은 여전히 사람이 맡아야 좋은 결과가 나온다는 점을 경험으로 확인해 줍니다.
- 오픈소스 모델도 에이전트 코딩에 충분한 수준이라고 봐서, 최상위 모델 값이 올라도 대안이 있다고 판단했습니다.
핵심 내용
- Claude Code, Codex 등 코딩 에이전트 5~6개를 각자 다른 Git 워크트리(한 저장소의 작업 폴더를 여러 개 두는 기능)에서 동시에 돌립니다.
- 에이전트가 올린 PR은 한 줄씩 보지 않고 구조와 패턴 위주로 검토하며, 그냥 두면 엉성한 코드가 나온다고 했습니다.
- 올해 가장 잘한 작업은 바이브 코딩으로 만든 약 4,000줄을 손으로 짠 수백 줄로 바꾼 일이었다고 꼽았습니다.
- 여섯 개의 대화를 한꺼번에 관리하는 일은 직접 코딩할 때보다 훨씬 진이 빠진다고 털어놨습니다.
- 문헌 검색과 공부에는 LLM을 먼저 쓰지만, 새로운 연구와 글 첨삭에는 아직 미덥지 않다고 평가했습니다.
HN 반응
- 일부 이용자는 "코드 작성은 해결됐다"는 말과 손으로 짠 코드가 최고 성과였다는 경험이 서로 어긋난다고 지적했습니다.
- 생산성 향상이 이미 크다는 주장에, 사용자로서는 소프트웨어가 나아진 것을 체감하지 못한다는 반론이 맞섰습니다.
이런 글을 볼 때마다 인지 부조화가 너무 심하게 느껴집니다.
소프트웨어에서 사람의 감각과 경험은 어디서 나온다고 보시는 겁니까?
이게 나아질 거라고 기대하는 이유가 뭡니까? LLM에 기대는 사람이 늘수록 학습 데이터의 질은 떨어질 테니, 지금은 출력이 좋아진 것처럼 보여도 결국 모델은 나빠지기 시작할 거라고 저는 예상합니다.
위의 경험들을 다 겪고도 이런 말을 하다니 이상합니다. 그 경험들은 우리 모두 공감할 거라고 생각하는데요.
생산성이 좋아진 것처럼 보인다는 이유로, 우리는 왜 의미와 이해를 이렇게나 많이 내주려는 걸까요?
저는 글쓴이가 아닌 게 분명하지만, "소프트웨어에서 사람의 감각과 경험은 어디서 나온다고 보시는 겁니까?"라는 질문에 다른 관점을 하나 보태고 싶어서 씁니다.
저는 27년 동안 온갖 언어로 코드를 써 왔습니다. 대단한 코드는 아니었지만 그걸로 돈을 벌었고, 커리어를 쌓았고, 여러 번 삶을 더 낫게 바꿔 놓기도 했습니다. 그런 제가 보기엔 코딩이 그 여정에서 중요한 부분이었던 적은 없습니다! 말씀하신 대로 인지 부조화일 수도 있겠지만, 저는 감각이 탐험과 시행착오에서, 그리고 새로운 방식이 일을 더 낫게 해 줄 수 있다면 열린 마음으로 낡은 방식을 바꿀 의지에서 나온다고 믿습니다!
음식이나 음악에 대한 취향과 비슷합니다! 어떤 음식은 맛없을 거라고 생각할 수 있지만, 먹어 보기 전에는 확신할 수 없습니다. 감이 맞아서 정말 끔찍한 맛일 때도 있고, 뜻밖에 깜짝 놀랄 때도 있죠. 음악도 마찬가지입니다. 제 평생 취미인데, 어떤 장르나 아티스트가 별로라고 생각했더라도 직접 앉아서 한번 들어 보고 그들이 하려는 이야기를 듣기 전에는 판단이 맞는지 확실히 알 수 없습니다.
소프트웨어에서 감각과 경험을 얻으려면 코드를 많이 짜야 한다는 뜻으로 댓글을 쓰신 거라면, 정중하게 동의하지 않습니다. 틀린 말씀은 아니지만, 그런 뜻이었다면 코드의 중요성을 과장하신 거라고 생각합니다. 이 경우에도 위의 비유처럼 중요한 건 탐험입니다. 다양한 언어, 패러다임, 해법, 스택을 써 보는 일이죠. 안타깝게도 인간에게는 시간이 한정돼 있어서, 판단을 내릴 만큼 빠르게 시도하고 탐험할 수가 없습니다!
제가 LLM에서 진심으로 좋아하는 점은 대부분 탐험 능력입니다. 늘 해 보고 싶었던 새로운 것들을 실제 제품으로 만들어 보고, 그 경험 전체에 대한 의견을 형성할 수 있으니까요.
그나저나 글을 다 쓰고 나니, 늘 그렇듯 제가 틀렸을 수도 있겠다는 생각이 듭니다! 당신이 맞을 수도 있고요. 감각은 아주 주관적이고, 그걸 얻는 일은 아주 개인적인 일이니까요! 그러니 여기서는 옳고 그름이 중요하지 않다고 생각합니다!
맞는 말씀이고, 거기에 더하자면 대부분의 경우 "결과물에 대한 감각"이 "구현에 대한 감각"보다 훨씬 중요합니다.
분명히 달마다 나아지고 있고, 학습 데이터가 나빠져서 붕괴한다는 얘기는 처음부터 환상이었습니다.
"생산성이 좋아진 것처럼 보일 뿐"이라는 결론은 근거가 없습니다. 지금은 생산성 향상이 실재하고 엄청나다는 게 너무나 분명합니다.
제가 보기에 앞뒤가 안 맞는 건, 사람들이 코드 리뷰와 최적화에 지나치게 큰 가치를 둔다는 점입니다.
최적화의 상당수는 시기상조라고 생각합니다. QA 테스트에서 문제를 못 찾았다면, 애초에 그다지 중요한 문제가 아니었을 가능성이 큽니다.
아키텍처가 완벽하지 않았더라도, 진짜 결함을 알게 된 뒤에 나중에 바꾸는 비용이 이제는 극도로 저렴합니다. 에이전트가 몇 시간이면, 거의 알아서 해 줍니다.
프로덕션에 내보내기 전에 큰 변경을 검증하는 데 QA 노력을 꽤 많이 잡아야 하겠지만, 그게 걸림돌이 될 정도는 아니라고 봅니다.
그래요? 그게 어디 있는데요? 그렇게 분명하다면 왜 사용자인 저한텐 안 보이죠? 지난 1년간 제가 자주 쓴 소프트웨어 중에 그 "실재하고 엄청난" 개선을 보여 준 건 하나도 없습니다. 아예 발전이 없다는 말이 아니라, LLM이 등장한 뒤로 발전 속도가 빨라지지는 않았다는 겁니다.
소프트웨어 생산성의 그 반짝이는 새 시대가 실제 사용자에게 영향을 주기를 저는 아직도 기다리고 있습니다.
저는 제 개인 생활에 큰 영향을 주는 도구를 여럿 직접 만들었습니다(칼로리·식단 기록 앱, 오랜 세월 익힌 여러 방법을 조합해 돌아가는 아주 맞춤형인 할 일 앱, 저한테 맞게 정보를 더 잘 띄워 주는 개인 지식 베이스). 하지만 개인용 앱이라 공개할 생각은 없습니다.
축하드려요? 저는 새 프로그래밍 언어를 배울 때 가끔 이런 걸 몇 시간 만에 하나씩 만들곤 했습니다.
당신 얘기라고 받아들이지는 마세요. 배경을 모르니까요. 다만 여기서 스스로를 엔지니어라고 부르면서 이런 식으로 말하는 사람 중 상당수가 애초에 프로그래밍을 제대로 할 줄 알긴 했나 싶은 생각이 들기 시작합니다.
그래요, dimitrios 님은 새 언어를 배우면서 두어 시간 만에 UI에 백엔드까지 갖춘 완성도 높은 앱을 만들었군요.
게다가 그걸 구현하는 동안 다른 작업도 두세 개 병렬로 돌렸고요. AI로 하는 것처럼요.
그러시겠죠, dimitrios 님 :)
저는 React를 배울 때 그렇게 했는데, 두어 시간이 아니라 밤새 걸렸습니다.
아니요, 완성도 높고 기능이 다 갖춰진 건 아니었습니다. 하지만 핵심 기능만 있는 기본 POC라면요? 요즘 React 튜토리얼은 죄다 할 일 앱 아닌가요?
어쨌든 제 요점은 제가 무슨 존 헨리라도 되는 것처럼 보이려는 게 아니었습니다(비꼬는 투로 "축하드려요"라고 한 건 안 해도 될 말이었네요, 죄송합니다). AI 기반 개발의 소음에 묻혀서 우리가 잊고 있다는 말을 하고 싶었습니다. 짧은 시간에 엄청나게 생산적이었던 놀라운 소프트웨어 엔지니어들이 있었다는 걸요(저를 그 부류에 넣는 건 아닙니다). 예를 들어 꽤 오래전에, 유명한 Go 개발자 두 사람이 HTTP 패키지를 통째로 다시 쓰는 라이브 방송을 경외하며 본 적이 있습니다. 그것도 하룻밤 사이에요.
"이걸 빨리 만들었어요" 말고, AI가 쓸모 있는지 가늠할 새 지표가 필요합니다.
제 말은, 전부 합치면(제가 직접 쓰려고 만든 모든 도구를 통틀어) 코드가 30만 줄쯤 된다는 겁니다. 좋은 지표는 아니지만, 두어 시간 만에 뚝딱 만들 수 있는 양은 아니죠.
아, 그리고 특히 음식 기록 부분은요, 아니요, 몇 년 전에는 두어 시간 만에 그걸 못 만들었습니다. 음식 사진을 찍으면 내 개인 "레시피" 라이브러리를 기준으로 추정치를 내 주는 건 vLLM이 나오기 전까지는 대형 연구 프로젝트였거든요.
시중에 (AI 이전부터) 무료 버전이 스무 개쯤 있을 텐데, 당신 것도 별 차이 없을 게 뻔합니다. 그냥 시간과 토큰을 낭비하고 스스로 뿌듯해하면서, 그게 어떻게든 "생산성"이고 "소프트웨어의 엄청난 개선"으로 일반화될 수 있다고 느끼는 거잖아요.
1년 전에는 생산성이 아직 엄청나지 않았고 도입도 소수에 그쳤기 때문일 수 있습니다.
그 두 가지 모두 크게 달라졌으니, 1년 뒤에는 분명히 변화가 보일 거라고 생각합니다(엄청나진 않더라도 어느 정도는요).
참고로 한 가지 예를 들면, 제 모바일 앱은 첫 릴리스를 제출할 준비를 하는 데 거의 풀타임으로 6개월이 걸렸습니다.
처음에는 4월에 GPT-5.4를 썼습니다.
다른 개발자들이 뭘 만들고 있는지는 제가 말할 수 없고, 주말에 뚝딱 만든 쓰레기를 내놓는 사람이 없을 리도 없습니다.
코드 리뷰를 하는 회사와 팀은 같은 속도로 적응하지 못하고 있습니다.
최종 사용자가 그 이점을 확실히 체감하기까지는 몇 달 더 걸릴 거라고 봅니다.
말하자면 최전선에서 일하는 사람으로서, 저는 제가 더 전체 그림을 잘 보고 있다고 생각합니다.
QA 테스트는 성능이 정말 끔찍한 수준이 아니면 놓친 최적화 기회를 찾아내지 못합니다. 끔찍한 경우에도, 쉬운 최적화를 놓쳐서 끔찍한 건지 기능을 희생해야만 해결되는 끔찍함인지는 구분하지 못하고요.
느린 함수의 결과를 캐시해서 앱이 잘 돌아간다면 QA는 문제없이 통과합니다. 그 느린 함수를 최적화하면 빨라질 수 있다면 캐시를 빼고 더 단순하고 견고한 앱을 만들 수 있지만, QA는 그걸 절대 알려 주지 못합니다.
그러니까 그 시나리오에서는 캐시 덕분에 어차피 빨랐으니 QA를 문제없이 통과한 겁니다.
더 단순하고 견고한 구현을 얻자고 그걸 리뷰하고, 이해하고, 개선하는 데 시간을 들일 가치가 있을까요? 제 생각엔 노력이 5~10배는 더 듭니다.
나중에 성능이 부족하다고 밝혀지면 그때 에이전트에게 그 느린 함수를 다시 살펴보게 하면 됩니다.
제가 최적화가 시기상조라고 한 게 그런 뜻입니다.
이게 반대 방향에도 적용됩니까? LLM이 끼워 넣는 섣부른 최적화나, 말도 안 되게 많은 쓸모없는 테스트는 얼마나 열심히 막아야 하죠?
대개는 그럴 가치가 없다고 생각합니다.
테스트 스위트가 너무 오래 걸리면 나중에 정리하면 되고, 새 MR마다 테스트 케이스를 일일이 따지느라 시간을 더 쓸 필요는 없습니다.
테스트 케이스 유지보수도 수천 개가 있어도 사소한 일이 됐습니다. master에서 파이프라인이 빨갛게 되면 새 채팅 버튼을 누르고, 간결한 지침을 담아 둔 /check-pipeline을 실행합니다. 그러면 실패 원인을 조사해서 금방 해결해 줍니다.
RL은 학습 데이터에 의존하지 않습니다. 수학 대격변(mathocalypse)은 어딘가에서 더 좋은 학습 데이터를 찾아서 일어난 게 아닙니다.
OpenAI가 의도적이든 아니든 수학자들의 채팅 기록으로 학습했을 가능성을 의심할 만한 이유가 있습니다. 그 수학자들은 같은 문제를 직접 풀어 보려고 OpenAI를 적극 활용하던 사람들입니다.[1] 그 수학자들이 올바른 길을 가고 있었고 해법에 가까워지고 있었다면, 그건 "어딘가에서 더 좋은 학습 데이터를 찾은 것"으로 볼 수 있습니다.
[1] https://cybernews.com/ai-news/openai-accused-stealing-another-mathematicians-work/
죄송하지만 사후 학습(post-training)이 실제로 돌아가는 방식을 보면, 2026년에 개인정보를 걸러 낸 실제 데이터가 RL 워밍업 용도로 OpenAI의 프로덕션 데이터 믹스에 직접 들어갔을 방법은 사실상 없고, 이 데이터가 영향을 미치는 범위에서도 그건 간접적이고 프로세스 결정 수준에서의 영향입니다. 제가 더 구체적으로 말하려는 건, AI 회사가 이렇게 순진하게 "사용자 대화록으로 직접 학습한다"는 식의 통념을 아직도 가진 사람들이 있는데, 첫째로 그건 틀렸고, 둘째로 계속 발전하기 위한 전략으로는 오히려 역효과라는 겁니다. "대화록에서 사람이 평가가 아직 다루지 못하는 특이한 일을 시도함 -> 그 문제 유형 전반을 포괄하는 합성 구성물을 만듦 -> 그 실패를 포괄하도록 설계한 검증기 세트로 RL" 이게 그 루프입니다... """플라이휠"""은... 진단입니다! 와! 그러니 이렇게 프로세스 개선을 이끄는 데이터 활용은 학습 과정에서 일어나는 일에 분명 확산적인 인과적 영향을 주겠죠? 하지만 그 프로세스 영향 중 "특정 수학자의 특정 직관이 학습 데이터로 새어 들어간다"처럼 보이는 건 거의 없습니다.
OpenAI의 양심 없는 사람들(그리고 맨 꼭대기부터 그게 그 회사 문화입니다)이 자기들이 다루던 문제의 관련 접근법을 찾으려고, 혹은 살펴볼 문제를 찾으려고 사용자 대화록을 검색하고, 그걸 바탕으로 모델을 조정했다는 건 충분히 그럴듯합니다.
우연히 그렇게 됐거나 학습 데이터에 들어갔을 가능성은 낮다는 데 동의합니다(불가능하지는 않지만요). 하지만 에이전트가 문제를 풀 때 쓰던 컨텍스트 안에 들어 있었을 수는 얼마든지 있습니다.
어느 쪽이든 증거는 없지만, 그렇게 하는 데 필요한 데이터는 전부 그들 손에 있었습니다.
관련 수학자인 Tristan Buckmaster가 나온 Numberphile 유튜브 채널의 인터뷰를 봤는데, 본인은 앤트로픽 사람들이 OpenAI에 직접 만나서 흘린 경우에 더 가깝다고 생각한다고 하더군요. 그들이 보던 분야에 대한 힌트만 있으면 같은 접근법에 도달하는 게 (어느 정도는) 쉬웠을 수 있고, 실제로 OpenAI가 내놓은 나비에-스토크스 논문도 그들의 접근법을 쓴다고 합니다.
RL은 두 가지 중 하나를 바탕으로 작동합니다. (1) 시스템에 대한 문자 그대로의 규칙 집합, 또는 (2) 학습 데이터입니다. 전자는 (현대의 대부분) 수학이나 게임처럼 규칙이 완벽하게 갖춰진 분야에 딱 들어맞습니다. 우리 규칙과 모델이 엄청나게 좋은 물리나 로봇공학 같은 분야에서도 RL은 거의 가치를 더하지 못합니다. 한 걸음만 더 나가 화학이나 날씨 같은 복잡한 물리 시나리오로 가면, 다시 거의 전적으로 (2) 데이터에 의존하게 됩니다. 아직 충분히 탐구되지 않은 엄밀한 규칙 체계를 가진 분야가 몇 개 더 있을 수는 있습니다(노력을 좀 들이면 프로그래밍이 여기서 진전을 볼 수 있을 거라고 봅니다. 회로 배치 같은 것일 수도 있고, 사람들이 lean 같은 법률 체계를 만들기로 한다면 법률도 가능하겠죠...). 하지만 AI가 겨냥하는 문제 대부분은 데이터에 의존합니다.
그게 모델이 새로운 브레인스토밍이나 연구 아이디어 발상을 잘하게 될 거라는 좋은 근거가 되는지 잘 모르겠습니다. 창의성과 통찰력에 대해 확장 가능하면서 신호가 뚜렷한, 검증 가능한 보상을 어디서 얻습니까?
코드 작성이 더 이상 필요 없다고 말하는 사람은 애초에 코딩을 그리 잘하던 사람이 아니었을 거라고 생각합니다. 저는 최고 수준의 모델이 할 수 있는 일도 봤고 사람들이 "좋다"고 부르는 것도 봤는데, 감흥이 없습니다.
그래도 저는 생각이 반반입니다. 코딩을 잘 못하던 사람들이 더 나은 누군가에게 코드를 맡기게 되니 코드 품질이 도약할 수도 있습니다. 반면 "신경 쓰는" 사람이 줄어서 코드 품질이 떨어질 수도 있고요.
부럽네요.
그런 입장을 가진 분은 최상위 개발자들하고만 일하는 엄청난 행운을 누렸고, 오픈소스 프로젝트는 읽지도 써 보지도 않은 분이라고 생각합니다.
작년 모델이 만드는 코드도 제가 같이 일해 본 개발자 중 적어도 50%보다는 낫습니다. 오늘날의 최전선 모델은 아마 75%보다 낫고요. 사람이 만들어 온 코드가 (평균적으로) "좋았거나" 적어도 충분히 괜찮았다면, 지금 존재하는 모델은 "좋은" 코드를 만들고 있는 겁니다.
문제는 이기려면 상위 1~10%에 들어야 한다는 겁니다. 같은 엔지니어들과 경쟁하고 있으니까요. 평균보다 조금 나은 정도는 해고되지 않을 만큼만 "충분히 괜찮은" 수준입니다.
게다가 그 엔지니어들 모두가 이제 같은 모델을 쓸 수 있으니 기준은 이미 올라갔습니다. 그래서 LLM으로 무장한 엔지니어들 중에서도 상위 1%에 들어야 합니다. LLM이 좋아지기만 바라고 있을 수는 없습니다. AI는 위대한 평등 장치가 아니라, 사실상 정반대입니다.
코딩이 해결됐다고 말하는 사람 대부분은 일회성 실험을 돌리려고 버리는 코드를 쓰는 ML 엔지니어였습니다. 결과를 얻은 뒤 코드를 사실상 "보관"해 버릴 수 있다면, 코딩이 해결됐다고 말하는 이유를 이해할 수 있습니다. 유지보수는 문제가 아니니까요.
맞아요, 그리고 API나 이어 붙이거나, 사실상 UI 템플릿을 쓰는 일이라 "틀릴" 일이 거의 없는 웹 쪽 사람들도요.