앤드류 응이 채용 공고 1만 건 이상을 분석해 내놓은 AI 엔지니어링 기술 지도에는 기술 20개가 있습니다. 다대구가 세어 보니 그중 9개, 45%가 코드를 직접 짜는 일이 아니라 에이전트를 부리고 무엇을 만들지 정하는 일이었습니다.
앤드류 응은 8월 14일 자신의 뉴스레터 The Batch에서 ‘AI 엔지니어링 기술 지도’를 공개했습니다. 팀과 함께 채용 공고 1만 건 이상을 분석하고, AI 전문가와 채용 관리자, 리크루터를 수십 차례 인터뷰해 추린 결과라고 밝혔습니다.
그가 꼽은 큰 축은 네 가지입니다. AI 앱을 만들고 배포하는 능력, 소프트웨어 공학 기본기, 코딩 에이전트를 쓰는 능력, 그리고 무엇을 만들지 정하고 개발을 이끄는 능력입니다. 그런데 이 지도를 세부 기술 단위로 펼치면 무게중심이 어디로 옮겨 갔는지 보입니다.
1. 기술 20개 중 9개는 코드 밖에 있습니다
DeepLearning.AI가 9월 17일 갱신한 지도에는 축마다 세부 기술이 적혀 있습니다. AI 앱 개발·배포가 6개, 소프트웨어 기본기가 5개, 코딩 에이전트 사용이 5개, 개발 이끌기가 4개로 모두 20개입니다.
코딩 에이전트 축의 5개는 작업 흐름 지휘, 에이전트에게 맡길 범위 정하기, 결과 검토, 에이전트와 작업 환경 맞추기, 에이전트 기초입니다. 개발 이끌기 축의 4개는 개발 반복 주도, 제품 결정, 소통과 리더십, 주도적 책임입니다.
이 두 축을 합치면 9개로 전체의 45%입니다. 절반 가까운 기술이 직접 타이핑하는 일보다 에이전트에게 무엇을 시키고, 나온 결과를 어떻게 판단할지에 걸려 있습니다.
응은 직함보다 기술을 강조했습니다. 모든 개발자가 클라우드를 다룰 줄 알아도 ‘클라우드 엔지니어’ 직함은 일부만 달고 있듯, AI 엔지니어링 기술도 풀스택·데이터·데브옵스 개발자 모두에게 필요하다는 설명입니다.
2. 결과를 예측할 수 없어서 평가가 중심에 옵니다
첫 번째 축은 한 가지 차이에서 출발합니다. AI 앱은 결과를 미리 알 수 없다는 점에서 일반 소프트웨어와 다르다는 겁니다. 언어 모델에 질문을 넣어도 무엇이 나올지 모르고, 학습시킨 모델이 새 데이터에 어떤 답을 낼지도 모릅니다.
그래서 응은 만들고, 살피고, 다음에 할 일을 정하는 반복을 핵심 기술로 봤습니다. 평가 기준을 세우고 틀린 사례를 분석하는 일이 첫 번째 축 안에 들어간 이유입니다.
첫 번째 축의 세부 기술 6개도 이 흐름을 따릅니다. 언어 모델 기초, 모델에 근거 자료 붙이기, 에이전트 시스템 만들기, 평가 중심 개발, 실제 서비스 운영, 머신러닝 기초입니다. 모델 이름을 아는 것보다 모델에 무엇을 넣고 결과를 어떻게 잴지가 더 큰 몫을 차지합니다.
두 번째 축인 기본기도 같은 맥락입니다. 응은 에이전트가 어떤 절충을 하는지 모르는 채 ‘바이브 코딩’을 하면 나쁜 선택이 쌓인다고 경고했습니다. 비용, 확장성, 안정성, 속도 사이의 절충을 알아야 에이전트에게 정확한 맥락을 줄 수 있다는 겁니다.
3. 개발자가 기획자 일도 맡기 시작했습니다
네 번째 축 설명이 가장 직설적입니다. 응은 9월 11일 글에서, 예전에는 기획자와 디자이너가 무엇을 만들지 정하고 개발자는 만들기만 했지만 이제 그 경계가 흐려지고 있다고 썼습니다.
AI 엔지니어링에 능숙한 개발자는 기획서가 없으면 직접 쓰고, 기획서가 다루지 않는 결정을 스스로 내립니다. 응은 기본적인 디자인 감각과 사업 감각도 갖추라고 덧붙였습니다. 반대로 기획자와 디자이너도 AI로 직접 만드는 쪽으로 오고 있다고 봤습니다.
세 번째 축인 코딩 에이전트 사용도 같은 방향입니다. 응은 에이전트에 얼마나 끼어들고 얼마나 맡겨 둘지 아는 것, 맥락을 관리하는 것, 계획과 실행 사이에서 저울질하는 것을 꼽았습니다. 에이전트가 스스로 결과를 확인하도록 검증 도구나 평가를 넣어 주는 일도 개발자 몫으로 적었습니다.
4. 빨라졌다는 체감과 측정은 아직 어긋납니다
구현 속도가 정말 빨라졌는지는 생각보다 재기 어렵습니다. 연구기관 METR은 2025년 초 숙련 오픈소스 개발자 16명에게 실제 작업 246개를 맡겨 실험했습니다. AI를 쓸 수 있을 때 오히려 19% 더 오래 걸렸습니다.
개발자들은 시작 전 24% 빨라질 거라 예상했고, 끝난 뒤에도 20% 빨라졌다고 믿었습니다. 다대구가 계산하면 체감과 실측 사이가 39%포인트 벌어진 셈입니다. METR은 지금 이 결과에 ‘낡은 결과’라는 표시를 달아 두었습니다.
METR은 이 차이를 평균 40%포인트 과대평가로 정리했습니다. 사람은 AI가 일을 얼마나 줄였는지 스스로 잘 재지 못한다는 뜻입니다.
2025년 8월 다시 시작한 실험은 결론을 내지 못했습니다. AI 없이 일하기 싫다며 참여를 거절하는 개발자가 크게 늘었고, 에이전트 여러 개를 동시에 돌리는 개발자는 작업 시간을 재기도 어려웠습니다. METR은 2026년 2월 이 데이터가 믿을 만한 신호가 못 된다고 밝혔습니다.
참가자 구성도 바뀌었습니다. 처음 실험의 개발자 10명과 새로 모은 47명이 참여했고, 사례비는 시간당 150달러에서 50달러로 줄었습니다. 원래 참가자들은 18%, 새 참가자들은 4% 빨라진 것으로 나왔지만, 신뢰구간이 0을 넘나들어 METR은 지금은 2025년 초보다 빨라졌을 가능성이 높다는 정도로만 말했습니다.
METR이 2026년 2~4월 기술직 349명에게 물은 설문에서는 일의 가치가 2026년 3월 기준 2배로 늘었다는 답이 중앙값이었습니다. 1년 전은 1.3배로 기억했고, 1년 뒤는 2.5배를 예상했습니다. 같은 사람들이 답한 ‘속도’는 3배로, 가치보다 1.5배 높았습니다.
응답자 중앙값은 AI를 한 달 더 쓰는 대가로 연봉의 29%를 포기하겠다고 답했습니다. 체감은 이렇게 큽니다. 다만 METR 직원들의 답이 모든 집단 중 가장 낮았고, METR은 설문이 실측보다 과장되기 쉽다고 스스로 적었습니다.
5. 지금 준비하는 개발자가 해 볼 일
저는 이 두 자료를 겹쳐 보면 응의 지도가 왜 이렇게 생겼는지 설명된다고 봅니다. 구현 속도는 이제 재는 것조차 어려울 만큼 흔해졌고, 남는 차이는 무엇을 만들지 정하고 결과가 맞는지 가려내는 데서 납니다.
연습은 작은 결과물 하나로 네 축을 다 거쳐 보는 방식이 흔히 쓰입니다. 누가 어떤 불편을 겪는지 한 문장으로 적고, 해결됐다고 판단할 기준을 먼저 정합니다. 그다음 코딩 에이전트로 작은 기능을 만들고, 정상 입력과 틀린 입력을 넣어 어디서 실패하는지 기록합니다.
기록에는 결과 화면과 함께 선택한 이유를 남깁니다. 어떤 데이터를 줬고, 어떤 오류를 찾았고, 고친 뒤 무엇이 달라졌는지입니다. 실행 시간과 비용까지 적어 두면 운영 쪽 기본기를 보여 주는 자료가 됩니다.
지도 자체도 공부 목록으로 쓸 수 있습니다. DeepLearning.AI 페이지에서 기술마다 설명과 핵심 항목을 펼쳐 볼 수 있고, 이 지도에 맞춘 강좌 시리즈는 아직 대기자 명단만 받고 있습니다. 영어 페이지지만 기술 이름이 짧아 번역기로도 충분히 읽힙니다.
채용 공고를 볼 때도 직함에 AI가 들어갔는지보다 누가 결과를 평가하는지, 배포한 뒤 어떤 문제를 책임지는지를 찾아보는 게 좋습니다. 그 내용을 네 축과 맞춰 보면 지금 경험으로 지원할 수 있는지, 무엇을 더 배워야 하는지가 드러납니다.
앞서 다룬 카파시의 HackerTube는 이 지도의 좋은 예입니다. 코드는 에이전트가 짰지만, 어떤 댓글을 추천으로 칠지, 몇 명·몇 달을 기준으로 삼을지는 사람이 정했습니다. 아마 앞으로 AI 엔지니어 면접도 이런 기준을 어떻게 정했는지 묻는 쪽으로 옮겨 갈 겁니다.
본문 그래프 1점은 METR 설문 결과로 다대구가 작성했고, 기술 수 비율은 DeepLearning.AI 기술 지도로 다대구가 직접 셌습니다. 대표 이미지: 다대구 생성 이미지.
