코드가 공짜가 되면, 엔지니어에게는 뭐가 남을까

코딩 에이전트를 켠 개발자는 코드를 741% 더 쓴대요. 8배쯤이에요. 그런데 출시는 30% 빨라지는 데 그친대요.

30%도 작은 숫자는 아니에요. 다만 코드가 8배인데 출시가 1.3배라면 어딘가에서 막혀 있다는 얘기죠.

xychart-beta
  title "에이전트를 켠 뒤 (켜기 전 = 1)"
  x-axis ["작성한 코드", "출시 속도"]
  y-axis 0 --> 9
  bar [8.4, 1.3]

Laurie Voss는 이 숫자에서 이야기를 시작해요. npm을 함께 세웠고, 지금은 Arize AI에서 개발자 관계를 맡고 있는 사람이에요. 10월 24일 AI Engineer 채널에 올라온 「AI Writes the Code. So What's Left for Engineers?」는 27분짜리 발표예요. 발표 순서대로 따라가 볼게요.

코드는 빨라졌는데 리뷰는 그대로예요

Laurie가 보기에 지금 막힌 곳은 코드 리뷰예요. 사람은 리뷰를 더 빨리 할 수가 없거든요. 20년 전 Cisco가 한 대규모 연구를 보면, 시간당 450줄쯤을 넘기면 코드를 읽고 이해하는 능력이 뚝 떨어진대요. 에이전트가 만든 1만 줄짜리 diff를 제대로 보려면 일주일은 걸린다는 계산이 나와요. 물론 그렇게 보는 사람은 없고요.

the cost of producing plausible code has collapsed while the cost of knowing whether to trust that code has stayed exactly the same.

그럴듯한 코드를 만드는 비용은 바닥까지 떨어졌는데, 그 코드를 믿어도 되는지 아는 비용은 그대로예요.

그래서 리뷰도 기계에 맡기는 쪽으로 가고 있어요. Laurie에 따르면 GitHub에서는 코드 리뷰 다섯 건 중 한 건 넘게 Copilot이 하고 있고, OpenAI에서는 사람이 PR을 리뷰할 수는 있어도 꼭 해야 하는 건 아니래요.

문제는 기계 리뷰어가 아직 미덥지 않다는 거예요. AI 리뷰어 넷을 같은 코드에 돌려 봤더니 넷 다 진짜 버그를 찾긴 했는데, 겹치는 버그가 하나도 없었대요. 돌려 볼 가치는 있지만 하나만 믿을 수는 없다는 뜻이죠. 리뷰를 아예 빼 본 사람들도 있었어요. 여섯 달 동안 "코드를 읽지 말라"고 하고 다니던 Dex Horthy는 결국 무대에 올라 틀렸다고 인정했대요. 해 봤더니 엉망이 돼서 시스템을 통째로 갈아엎어야 했다고요. Amazon은 장애 회고 끝에 시니어 엔지니어의 승인을 다시 필수로 만들었고요.

가장 눈에 띈 건 Devin을 만든 Cognition의 벤치마크였어요. "테스트를 통과하느냐" 대신 "이 저장소의 메인테이너라면 이 PR을 머지하겠느냐"를 물었더니, 통과율이 87%에서 54%로 떨어졌대요. 코드 스타일, 부작용, 바깥 시스템, 코드에 적혀 있지 않은 이력까지 판단에 들어가니까요. 그건 메인테이너 머릿속에만 있는 정보예요. Laurie는 이걸 "좋다는 게 뭔지에 대한 감각"이라고 부르고, 발표 끝까지 이 얘기로 돌아와요.

병목은 고쳐도 사라지지 않고 옮겨 가요

여기서 Laurie는 엘리야후 골드랫이 1984년에 쓴 공장 소설 『The Goal』을 꺼내요. 골드랫의 제약 이론은 두 가지를 말해요. 시스템에는 병목이 하나 있고, 병목이 아닌 곳을 빠르게 해 봐야 소용없다는 것. 그리고 병목을 고치면 없어지는 게 아니라 다른 데로 옮겨 간다는 것. 코드는 빨라졌는데 리뷰가 그대로인 지금이 첫 번째 얘기라면, Laurie가 하려는 건 두 번째 얘기예요.

리뷰가 풀리면 다음은 운영이에요. 어떻게 배포하고 어떻게 키울지요. 그다음은 보안이고요. Laurie는 여기서 크게 한 발 건너뛰어요. 운영과 보안도 언젠가는 풀린다고 가정하는 거예요. 사람이 오래 다뤄 온 문제라 쌓인 자료가 많으니까요. 대신 시간은 넉넉히 잡아요. 리뷰는 1년 안에 꽤 나아지겠지만, 운영과 보안까지는 5~10년은 걸릴 거래요.

가정이 하나 더 있어요. 세상이 원하는 소프트웨어는 사실상 끝이 없다는 것. 미용실이나 관공서, 은행 웹사이트가 형편없는 건 잘 만들 줄 몰라서가 아니라 만들 사람이 모자라서라는 거예요. 그렇게 수요도 공급도 끝이 없다면 병목은 어디서 멈출까요. Laurie는 소프트웨어 개발을 잘게 쪼개서, 에이전트가 가져가는 순서대로 줄을 세워요.

flowchart LR
  A["코드 작성<br/>이미 넘어감"] --> B["리뷰 · 유지보수<br/>곧"]
  B --> C["배포 · 확장<br/>그다음"]
  C --> D["무엇을 만들지<br/>무엇이 좋은지<br/>남는다"]

남는 건 "좋다"의 뜻을 정하는 일이래요

고객이 "주문을 관리하고 싶어요"라고 하면, 주문 관리 소프트웨어는 이미 만 개쯤 있어요. 그런데 빵집에 맞는 건 그중 하나뿐이고(그것도 운이 좋아야요), 자동차 부품 가게라면 또 달라요. 그 사람이 말한 "주문 관리"가 그 가게에서 정확히 뭘 뜻하는지 알아내는 게 일의 전부예요. 그 지식은 학습 데이터에도, 모델 가중치에도 없어요. 가게를 하는 사람 머릿속에 있고, 꺼내려면 직접 얘기를 나누는 수밖에 없어요.

이 일은 옮겨 쓸 수도 없어요. 캘린더 앱과 일정 조율 앱은 거의 같은 문제를 푸는데도 요구사항도, "좋다"의 기준도 완전히 달라요. 설정이 수백 개인데도 정작 내가 원하는 건 안 되는 소프트웨어가 그 결과고요(Laurie는 여기서 Jira를 콕 집어요). 그래서 병목은 문제를 설명하고, 문제가 풀렸다는 게 뭔지 정하는 데로 옮겨 가요. 앞으로 10년은 거기 머물 거라는 게 Laurie의 내기예요.

이 대목에서 Fred Brooks가 나와요. Brooks는 1986년에 소프트웨어의 어려움을 둘로 나눴어요. 도구나 언어, 문법에서 오는 우연한 복잡성과 문제 자체에서 오는 본질적인 복잡성이요. 그러면서 어떤 도구도 생산성을 10배로 올려 주지는 못할 거라고 했죠. 어려운 건 본질 쪽이니까요. 코드를 8배 빨리 쓰게 됐는데도 출시가 별로 안 빨라진 지금, Laurie는 Brooks의 예측이 꽤 잘 버티고 있다고 봐요. OpenAI의 Sean Grove도 같은 얘기를 했대요. 코드는 명세를 옮기면서 뭔가를 잃어버린 결과물이고, 명세를 쓰는 사람이 PM이든 마케터든 결국 그 사람이 프로그래머가 된다고요.

그런데 적어 두는 순간 그것도 기계 몫이 돼요. 싸게 검증할 수 있는 건 모델 회사가 학습시켜서 결국 넘어서거든요. Cognition은 "머지할 만하다"의 뜻을 벤치마크로 적어 보려 했고, Cursor의 리뷰 봇 BugBot은 팀이 누른 "싫어요"를 하나하나 규칙으로 바꿔서 지금 4만 4천 개쯤 쌓였대요. Laurie가 운영과 보안도 결국 넘어간다고 보는 이유가 이거예요. 언젠가는 다 적어 둘 수 있으니까요.

그 일을 Laurie는 프로덕트 엔지니어라고 불러요

Andrew Ng의 팀에서 엔지니어보다 PM을 두 배 두자는 제안이 나온 적이 있대요. Ng의 답은 PM을 더 뽑는 게 아니라 두 일을 섞는 거였어요. 사용자를 이해하고 뭘 만들지 직접 정해서 바로 만드는 엔지니어가 가장 빠르다고요.

Laurie는 이게 처음 있는 일이 아니라고 봐요. 1960년대에는 시스템 분석가라는 직업이 있었어요. 코드를 짜지 않고, 현업과 얘기해서 문제가 뭔지 알아내는 게 일이었죠. 이 분석가가 지금의 프로덕트 매니저가 되면서, 한 개 반이던 직업이 두 개로 갈라졌어요. 그게 다시 하나로 합쳐지고 있다는 거예요.

flowchart LR
  A["1960년대<br/>시스템 분석가 + 프로그래머"] --> B["지금까지<br/>PM과 엔지니어, 두 직업"]
  B --> C["앞으로<br/>프로덕트 엔지니어 하나"]

Laurie가 말하는 프로덕트 엔지니어는 사람들에게 필요한 걸 알아내고, 좋은 게 뭔지 정하고, 타이핑은 에이전트에게 맡겨서 내보내는 사람이에요. Gergely Orosz가 2019년에 "제품을 생각하는 엔지니어"를 있으면 좋은 자질로 소개했는데, 이제는 있으면 좋은 게 아니라 꼭 있어야 하는 자질이 됐다고 해요. 시장도 이미 값을 쳐주고 있대요. 비슷한 일을 하는 forward deployed engineer 채용 공고가 2025년 아홉 달 사이 800% 늘었고, 평균 연봉이 24만 달러래요. 시니어 엔지니어 수준이죠.

"그건 프로그래밍이 아니잖아요?" 맞아요, 프로그래밍은 에이전트가 해요. 그래도 소프트웨어 개발인 건 분명하다고 Laurie는 말해요. 2026년에 와서 소프트웨어 개발자와 프로그래머가 서로 다른 일이 됐다는 걸 받아들여야 한대요.

Laurie는 스스로 함정도 짚어요. AI 업계 사람들이 흔히 빠지는 생각, "다른 건 다 자동화돼도 내가 잘하는 일만은 어려워서 안 된다"는 생각이요. 문제를 알아내는 일을 좋아하는 자기가 그걸 가장 어려운 부분이라고 믿고 싶은 건 아닌지, 판단은 청중에게 맡겨요.

그럼 주니어는 어디서 배우나요

예전에 주니어를 키우는 방법은 이랬어요. 요구사항이 꼼꼼히 적힌 티켓을 주고, "이렇게 만들어 오면 뭐가 틀렸는지 알려 줄게" 하는 거요. 그런데 지금 그 일은 코딩 에이전트가 해요. 사람이 할 필요가 없어졌죠.

Laurie가 보여 준 2023년 1월 이후 노동 통계에서 22~25세 엔지니어의 고용은 무너지고 있었어요. 반대로 41~49세는 크게 올랐고요. 앞으로 일어날 일이 아니라 2년째 일어나고 있는 일이에요.

프로덕트 엔지니어를 대놓고 길러 내는 곳은 거의 없어요. 구글의 APM(어소시에이트 프로덕트 매니저) 프로그램이 비슷한 사람을 길러 내는데 1년에 50명이고, 따라 만든 회사들을 다 합쳐도 1년에 천 명 남짓이래요. Laurie는 최소 그 10배는 필요하다고 봐요. 대학은 자료구조를 가르치고 부트캠프는 React를 가르치지만, 빵집 주인 옆에 일주일 앉아 있다가 명세를 들고 돌아오는 법은 아무도 안 가르친다는 거예요. IBM은 신입 직무를 프로그래밍 대신 고객과 얘기하고 명세를 쓰는 일 중심으로 다시 짜고 있대요. Laurie는 이 일을 2년 전에 시작했어야 했다고 말해요.

코드 짜는 게 좋아서 개발자가 된 사람에게

깔끔한 추상화, 끝까지 버티던 버그가 마침내 잡히는 순간, 기계가 시킨 대로 정확히 움직이는 걸 보는 맛. 이게 좋아서 개발자가 된 사람이 많죠. 빵집 주인을 인터뷰하려고 이 일을 시작한 사람은 없을 거예요. Laurie도 이 사람들에게 줄 위로는 없다고 솔직하게 말해요.

대신 이런 얘기를 해요. 타이핑이 좋았다고 생각하는 사람들이 사실 좋아했던 건, 타이핑을 시작하기 직전에 문제가 풀리던 그 순간이 아니었을까요. 그 순간은 없어지지 않아요. 가구 공장이 생긴 뒤에도 목공은 살아남았듯 프로그래밍도 남을 거래요. 가수가 빈방에서 혼자 노래하듯, 좋아서 하는 일로요. 다만 그걸로 1년에 수십만 달러를 받지는 못하겠죠.

앞으로 10년은 험할 거라고 Laurie는 예상해요. 도구가 준비되기 전에 일이 먼저 몰려오고 있고, 주니어를 키울 방법을 찾기 전에 사다리가 먼저 사라졌으니까요. 그래도 컴파일러, 프레임워크, 오픈소스가 나올 때마다 앞 세대의 타이핑이 필요 없어졌고, 그때마다 개발자는 오히려 늘었어요. 10년 뒤에는 지금보다 크고, 대우도 지금만큼 좋고, 대부분 프로덕트 엔지니어링 모양인 직업이 돼 있을 거래요.

그래서 지금 뭘 하면 되냐면요

Laurie가 마지막에 꼽는 건 네 가지예요.

먼저 사람이 코드를 거의 만들지 않는 세상에 대비해요. 망가지면 피해가 크게 번지는 코드가 어디인지 적어 두고, 사람은 그것만 리뷰해요. 나머지는 자동 리뷰가 맡게 될 테니까요. 둘째, 싸게 검증할 수 있는 건 다 맡겨요. 리뷰 절차를 고민하기보다 "이게 좋은지 아닌지 자동으로 가리려면 어떻게 해야 하지"를 고민해서 그걸 에이전트에게 쥐여 주는 거예요.

셋째, 팀에서 제일 잘하는 사람들의 판단을 명세와 루브릭, eval로 옮겨요(eval 회사 사람이라 eval 얘기를 안 할 수가 없다며 Laurie도 웃어요). 머릿속에만 있는 걸 꺼내서 에이전트가 쓸 수 있게 적어 두는 게 프로덕트 엔지니어의 일이라는 거죠.

넷째, 제대로 된 걸 재요. 코드가 741% 늘었다는 건 처음부터 중요한 게 아니었어요. 실제로 얼마나 내보냈는지, 리뷰 코멘트가 실제로 반영되는 비율이 얼마인지, 테스트 통과와 "메인테이너라면 머지하겠다" 사이에 얼마나 차이가 나는지를 재요. 그리고 마지막 리뷰어는 운영 환경이라는 걸 잊지 말라고 해요.

읽으면서 걸렸던 것들

숫자가 많은데, 발표 중에 출처를 하나하나 말하지는 않아요. Laurie도 시간이 없으니 출처는 슬라이드에 적어 두고 "그냥 믿어 달라"고 웃으며 넘어가요. 그래서 이 글의 숫자는 모두 Laurie가 인용한 숫자로 읽어 주세요.

"좋다의 뜻을 정하는 일은 남는다"는 건 결과가 아니라 내기예요. Laurie 스스로 그렇게 부르고, 자기가 좋아하는 일을 제일 어려운 일이라고 믿고 싶은 함정일 수 있다는 것도 인정해요. 소프트웨어 수요가 끝이 없다는 전제도 따로 증명하지 않고요.

얼마 전에 정리한 Max Kanat-Alexander의 발표와 나란히 놓고 보면 재미있어요. 맥스는 오래 쓸 코드일수록 품질이 중요하고, 품질을 챙기는 비용을 낮추라고 했어요. Laurie는 사람은 피해가 크게 번질 코드만 보고, 나머지는 자동으로 검증하라고 해요. 둘 다 결국 "좋다"를 기계가 확인할 수 있는 형태로 적어 두라는 얘기로 모여요.

주니어 이야기는 남 일 같지 않았어요. 저도 주니어라서요. 꼼꼼히 적힌 티켓을 받아 만들고, 선배가 틀린 곳을 고쳐 주며 배우던 자리를 이제 AI가 가져갔어요. Laurie는 앞으로 필요한 게 쓰는 사람 옆에 앉아 뭐가 필요한지 알아내고 명세로 적는 능력이라고 하는데, 그건 학교도 부트캠프도 안 가르친대요. 결국 일하면서 부딪혀 배울 수밖에 없는 것 같아요. 그래서 저는 코드를 AI에게 맡기기 전에, 이걸 쓸 사람이 정말 원하는 게 뭔지부터 묻는 연습을 해 보려고 해요.

Laurie는 이렇게 발표를 마무리해요.

Finding out what people need, writing down what good means, and making it something people like, that is the job now.

사람들에게 필요한 게 뭔지 알아내고, 좋다는 게 뭔지 적어 두고, 사람들이 좋아할 만한 걸로 만드는 것. 이제 그게 우리 일이에요.