“이 로드맵대로 공부하면 취업할 수 있다”는 글을 요즘도 종종 봅니다. 그런데 이상하게 예전만큼 그런 말에 눈이 가지 않더라고요. 로드맵이 가리키는 목적지가 반년 뒤에도 그대로 있을 거라는 확신이 없어서 그렇습니다. 남들이 미리 밟아본 길을 따라 걸으면 어딘가에 도착하던 시대는 끝난 것 같습니다. 지금 필요한 건 정해진 목적지로 가는 지도보다 이 혼란기에 적어도 멈춰서지는 않게 해주는 이정표가 아닐까 싶습니다.
마침 그런 이정표로 삼을 만한 글이 하나 올라왔습니다. 스탠퍼드 교수이자 세계적인 AI 대가 앤드류 응(Andrew Ng)이 지난 8월 14일 공개한 아티클 “The AI Engineering Skills Map”입니다. 그는 주요 AI 이론을 정립한 연구자이자, 코세라(Coursera)와 딥러닝.AI(DeepLearning.AI)처럼 유명한 교육 플랫폼을 창립한 교육자이기도 합니다.
그러한 AI 업계의 멘토가 제시한 지도를 따라가며, 이 시대의 생존을 위해 필요한 스킬이 무엇인지, 그 능력을 얻기 위해 실제로 무엇을 할 줄 알아야 할지 정리해 봤습니다.

- Andrew Ng, 〈The AI Engineering Skills Map〉
글에서 이탈릭 체로 처리한 모든 대화체는 아티클에서 인용한 글입니다.
이런 종류의 글은 대개 유명한 분들의 직관에서 나오는 것을 많이 봤습니다. 그런데 이번 스킬 맵의 출처는 데이터라고 합니다. AI 덕분에 전과는 전혀 다른 방식으로 소프트웨어를 만들 수 있게 됐고 기회도 많아졌는데, 정작 AI를 둘러싼 정보 환경은 “시끄럽고 과장으로 가득”합니다. 그래서 지금 배울 가치가 가장 큰 스킬이 무엇인지를 데이터로 추려 보기로 했다는 겁니다. 개발자에게는 무엇을 먼저 배울지 우선순위를, 고용주에게는 숙련된 개발자를 알아보는 기준을 주겠다는 목적으로요.
응 교수의 팀은 1만 건이 넘는 채용 공고를 분석했습니다. AI 전문가와 채용 관리자, 리크루터를 상대로 수십 건의 구조화된 인터뷰를 진행하고 설문과 온라인 데이터까지 종합했고요. 그렇게 뽑아낸 가장 중요한 AI 엔지니어링 스킬이 네 가지입니다.
목록에는 새로운 프레임워크 이름도, 뜨는 도구 이름도 없습니다. 이는 다분히 의도된 것입니다.
응 교수는 이번 스킬 맵이 ‘AI 엔지니어’라는 직무 대신 ‘AI 엔지니어링’이란 영역을 다룬다고 단언합니다. “나는 ‘AI 엔지니어’라는 직무(AI 시스템을 만드는 것이 일인 사람)가 아니라 ‘AI 엔지니어링 스킬’을 이야기한다. 후자가 훨씬 넓기 때문”이라고요. 오늘날 모든 개발자는 클라우드를 다룰 줄 알아야 하지만 ‘클라우드 엔지니어’라는 직함을 가진 사람은 그보다 훨씬 적은 것처럼, 풀스택이든 데이터든 데브옵스든 머신러닝이든 모든 개발자가 AI 엔지니어링 스킬을 필요로 하게 될 거라는 겁니다.
이 관점이 기존 스킬 로드맵과의 가장 큰 차이라고 생각합니다. 특정 직무로 갈아타기 위한 목록이 아니라, 지금 자기 직무를 그대로 가진 채, 새로 더해야 하는 스킬의 목록이라는 거죠. 그럼 하나씩 보겠습니다.
첫 번째 스킬은 AI 애플리케이션을 만들고 배포하는 것입니다. 응 교수는 AI 애플리케이션과 그렇지 않은 애플리케이션의 핵심 차이를 한 문장으로 정리합니다.
“AI 애플리케이션과 AI가 아닌 애플리케이션의 핵심 차이는, 전자는 출력을 예측할 수 없다는 점이다.”
우리는 LLM에 프롬프트를 넣을 때 무엇이 돌아올지 알 수 없습니다. 또, 딥러닝 알고리즘을 학습시킬 때 새 예시에 어떤 예측을 내놓을지 알 수 없습니다. 반면 전통적인 소프트웨어는 훨씬 예측 가능하게 동작하죠. 같은 입력에는 같은 출력이 나오도록 짜는 게 지금까지의 개발이었으니까요.
그렇다면 이 스킬에 능숙하다는 건 무엇을 할 줄 안다는 걸까요. 응 교수에 따르면 LLM, 컨텍스트 엔지니어링, RAG, 에이전틱 워크플로, 머신러닝과 딥러닝 같은 AI의 구성 요소를 이해하는 것이 바탕이 됩니다.
하지만 그가 “무엇보다”라며 강조하는 건 따로 있습니다. 통계적 기법으로 AI 시스템을 측정하고 방향을 잡고 통제해, 더 예측 가능하게 행동하도록 만들 줄 아는 것. 그리고 그 핵심은 규율 있는 평가(eval)와 오류 분석 루프를 굴릴 줄 아는 기술에 있다고 합니다. 예측할 수 없다는 특성을 없앨 수는 없으니, 측정하고 좁혀가는 루프를 사람이 돌릴 줄 알아야 한다는 겁니다.

두 번째는 소프트웨어 엔지니어링 기본기입니다. AI가 코드를 다 짜주는 시대에 기본기라니, 목록에서 가장 의아한 항목일 수 있는데요. 응 교수의 논리는 이렇습니다.
소프트웨어를 엔지니어링한다는 건 비용, 확장성, 신뢰성, 속도 사이에서 트레이드오프를 하는 일이고, 보안과 프라이버시가 여기에 복잡성을 더합니다. 기본기를 이해하면 애초에 어떤 트레이드오프가 존재하는지를 알아볼 수 있습니다. 그 결과 소프트웨어 스택 선택, 시스템 아키텍처 설계, 데이터 저장소 설계, 테스트 같은 결정이 더 나아집니다.
대비되는 인물은 누굴까요? 코딩 에이전트가 어떤 트레이드오프를 하고 있는지도 모른 채 바이브 코딩으로 해법을 만들어내는 미숙한 개발자입니다. 응 교수는 이들의 결과가 나쁜 이유를 “코딩 에이전트에 어떤 컨텍스트를 줘야 하는지 모르기 때문”이라고 짚습니다. 반대로 기본기를 이해하면 “소프트웨어 엔지니어링의 정확한 언어로 코딩 에이전트를 조종해 좋은 트레이드오프를 할 수 있다”고 하고요.
그러니까 기본기를 익혀야 하는 ‘필요’가 바뀐 겁니다. 예전에는 내 손으로 좋은 코드를 짜기 위해 기본기가 필요했다면, 이제는 에이전트에 무엇을 시킬지 정확한 언어로 말하기 위해 필요합니다. 즉, “이 API는 캐시를 두되 무효화 조건을 이렇게 걸어라”라고 말할 수 있는 사람과 “빠르게 만들어줘”라고밖에 못 하는 사람의 차이는, 타이핑 실력이 아니라 트레이드오프를 알아채는 지식에서 갈립니다.

세 번째는 코딩 에이전트 사용하기입니다. 응 교수는 에이전틱 코딩을 효과적으로 쓰는 것이 이제 모든 개발자의 핵심 스킬이라고 말합니다. 그렇다면 ‘숙련된 기술’을 가진 개발자의 모습은 무엇일까요?
이 스킬을 갖춘 사람은 에이전트가 어떻게 동작하는지에 대한 좋은 ‘멘탈 모델’을 가지고 있습니다. 글에 따르면 “에이전트의 한계와 그 한계를 우회하는 방법을 이해하고, 빠르게 방향을 잡아줄 수 있다 — 얼마나 개입하고 얼마나 내버려둘지를 알고 — 그래서 시간과 토큰을 지나치게 낭비하지 않으면서 견고한 소프트웨어”를 만들 수 있다는 뜻입니다. 어느 도구의 어느 기능을 쓸 줄 아느냐가 아니라, 언제 손을 대고 언제 손을 뗄지 판단하는 능력이 진짜 스킬이라는 얘기입니다.
구체적으로 할 줄 알아야 하는 것들 목록도 있습니다. 1) 코딩 에이전트의 컨텍스트를 관리할 줄 알아야 하고, 2) 계획과 실행 사이의 트레이드오프를 할 줄 알아야 합니다. 3) 검증기(verifier)나 평가를 제공해 에이전트가 스스로 루프를 닫도록 도울 줄도 알아야 하죠. 4) 명확한 스펙을 가지고 일하는 법과 굳이 그럴 필요가 없는 때가 언제인지 아는 것, 5) 여러 에이전트를 함께 동작하도록 오케스트레이션하는 법, 6) 에이전트가 프로덕션 데이터베이스를 망가뜨리는 것 같은 함정을 피하는 법도요.
하나하나가 도구 매뉴얼보다는 판단 기준에 가깝습니다.
무엇보다 에이전틱 코딩은 빠르게 진화하고 있습니다. 그래서 코딩 에이전트를 능숙하게 쓴다는 건 최신 실천법을 아는 것뿐 아니라 새로운 도구를 계속 시도해 보고 모범 사례가 바뀔 때마다 자기 워크플로를 진화시키는 루틴을 갖추는 것을 뜻합니다. 오늘 익힌 도구 활용법은 몇 달 지나면 낡은 것으로 바뀝니다. 그래서 이 스킬의 핵심은 빠르게 루틴을 갱신할 힘에 있습니다.

네 번째 스킬의 이름이 ‘무엇을 만들지 형태를 잡기’입니다. 명확한 스펙을 줄수록 코딩 에이전트가 그것을 구현해 내는 능력은 빠르게 좋아지고 있습니다. 그러니 엔지니어의 일은 스펙에 무엇이 들어가야 하는지를 결정하는 쪽으로 옮겨 가고 있습니다. 응 교수는 꽤 단호하게 말합니다. “엔지니어는 더 이상 픽셀 단위까지 완성된 디자인을 받아서 구현만 하도록 요구받는 존재로 스스로를 기대해서는 안 된다.”고요.
대신 요구되는 건 제품, 그리고 비즈니스 맥락과 고객의 목표에 대한 이해입니다. 그래야 무엇을 만들지 형태를 잡고 추진하는 데 참여할 수 있으니까요.
응 교수는 “AI가 전보다 더 큰 주인의식과 주도권을 가질 기회를 준다”고도 덧붙입니다. 흥미로운 문제와 기회를 스스로 발견하고 책임 있게 실행에 옮길 수 있게 됐다는 겁니다. 이 기회를 잡으려면 프로젝트를 앞으로 밀고 나가는 법을 알아야 합니다. 언제 빠르게 MVP를 만들어 사용자에게 가져가 테스트할지, 언제 속도를 늦추고 시간을 더 들여 신중하게 만들지를 아는 것.
만드는 속도 자체는 더 이상 병목이 아니니, 어떤 속도로 만들지 정하는 게 스킬이 된 겁니다. 구현 능력을 갈고닦아 온 사람에게는 불편한 변화일 수 있지만, 방향은 분명해 보입니다.

마지막으로, 이 모든 스킬 밑에 깔려 있는 것은 ‘꾸준히 학습을 멈추지 않겠다’는 마인드셋입니다.
“AI는 계속 빠르게 변하기 때문에, 우리 모두 계속 배우고 스킬을 진화시켜 새롭게 떠오르는 모범 사례를 받아들여야”합니다. 그리고 이 모든 것이 저 4가지 역량을 키우는 토대가 됩니다.
이렇게 보니 네 가지 스킬의 공통점이 보입니다. 전부 외워두면 끝나는 지식이 아니라 계속 굴려야 하는 루프라는 거죠. 코딩 에이전트 워크플로는 모범 사례가 바뀔 때마다 다시 짜야 하고, 무엇을 만들지 정하는 힘도 시장과 모델이 바뀌는 것을 따라가야 합니다. 이제 AI는 스스로 다루는 걸 멈추는 순간 무뎌지다 못해 손에서 사라져 버리는 칼로 변했습니다.
그래서 저는 요즘 자주 쓰이는 ‘언런(unlearn)’이라는 말을 떠올렸습니다. 언제나 새로 배우려는 마음가짐. 대신, 가진 것을 모조리 버리라는 말로 이해하지는 않고 있습니다. 기본기 항목에서 봤듯 옛 지식은 버려지는 게 아니라 쓰는 방식이 바뀌는 것뿐이라고 생각하니까요.
변화의 속도에 압도돼 아무것도 손에 안 잡히는 상태야말로 피해야 할 것이겠죠. 혼란과 두려움에 갇혀 있는 대신, 지금 다룰 수 있는 것을 다뤄 보면서 스스로를 갱신해 나가는 것. 응 교수의 표현으로는 지속 학습 마인드셋, 이것이야말로 진짜 역량이 아닐까 합니다.
여러분은 에이전트에 정확한 언어로 트레이드오프를 말할 수 있나요? 개입할 때와 내버려 둘 때를 제대로 구분하고 있나요? 스펙을 받기만 하는지, 아니면 스스로 스펙을 정하고 있나요?
응 교수의 지도는 목적지를 약속하지 않습니다. 이 네 가지를 익히면 어떤 직함과 어느 정도 연봉에 도달한다는 식의 보장은 어디에도 없습니다. 대신 지금 무엇을 공부하고 익혀야 하는지는 비교적 잘 보여준다고 느낍니다.
그리고 지금 같은 혼란기에는, 어쩌면 그게 바랄 수 있는 전부이자 가장 필요한 것일지도 모르겠습니다.
ⓒ요즘IT의 모든 콘텐츠는 저작권법의 보호를 받는 바, 무단 전재와 복사, 배포 등을 금합니다.