앤드류 응이 AI 엔지니어링 스킬맵을 공개했다. 채용 공고 1만 건 이상을 분석하고, 전문가와 채용 담당자를 수십 명 인터뷰하고, 설문까지 돌려서 뽑았다는 네 가지 역량이다. 본인 표현으로는 “방대한 데이터에 클러스터링을 돌린 것과 비슷한 과정”이라고 한다.
- AI 애플리케이션 구축과 배포
- 소프트웨어 엔지니어링 기본기
- 코딩 에이전트 활용
- 빌드 형성하기 (shaping the build)
오늘 아침에 읽었는데, 목록만 옮겨 적으면 딱히 남는 게 없을 것 같아 몇 번 다시 읽으며 구조를 좀 뜯어봤다.
그가 붙인 단서 하나가 먼저 눈에 걸렸다. 그는 “AI 엔지니어”라는 직함이 아니라 “AI 엔지니어링 역량” 이라고 표현했다. 요즘 모든 개발자가 클라우드를 다룰 줄 알아야 하지만 클라우드 엔지니어라는 직함을 가진 사람은 소수인 것과 같다는 비유를 든다. 풀스택이든 데이터 엔지니어든 결국 다 필요해진다는 이야기다. 어쩌면 이 단서가 목록보다 중요할지도 모르겠다.
1. 나란한 목록이 아니라 층이다
네 항목이 같은 층위에 있는 것처럼 제시돼 있는데, 읽어보면 그렇지 않다.
②는 나머지와 나란히 놓일 항목이 아니라, 나머지가 성립하는 조건이다.
응 본인의 설명에서 이미 드러난다. 소프트웨어 기본기를 이야기하면서 그는, 기본기가 없으면 코딩 에이전트가 어떤 트레이드오프를 하고 있는지 모른 채 결과물을 받게 된다고 지적한다. 어떤 맥락을 줘야 할지 모르기 때문이라는 것이다. 그리고 기본기가 있어야 “소프트웨어 엔지니어링의 정확한 언어로” 에이전트를 조종할 수 있다고 덧붙인다.
그렇다면 ②는 ③과 나란한 항목이 아니다. ③이 성립하기 위한 전제조건이다. 운전을 잘한다와 길을 안다를 같은 줄에 놓은 셈이다. 길을 모르면 운전을 아무리 잘해도 엉뚱한 데로 간다.
그래서 다시 쌓아보면 이렇게 된다. 바닥에 기본기가 있고, 그 위에서 코딩 에이전트가 속도를 만들고, 그 위에서 확률적인 부품을 다루는 능력이 붙고, 맨 위에 무엇을 만들지 정하는 일이 온다. 순서가 이렇게 정리되면 학습 순서도 자연스럽게 나온다.
2. 네 항목 전부에 같은 것이 들어 있다
항목을 하나씩 다시 읽다가 좀 이상한 걸 발견했다. 네 개 전부에 같은 게 박혀 있었다.
넷 다 “무엇이 맞는지 어떻게 아는가”로 수렴한다.
AI 앱 구축에서 그가 핵심 역량으로 꼽은 건 모델을 잘 고르는 게 아니라 “규율 있는 평가와 오류 분석 루프를 돌리는 능력”이다.
소프트웨어 기본기는 트레이드오프를 인식하는 능력이라고 설명된다. 트레이드오프를 안다는 건 결국 무엇이 어디서 틀어질 수 있는지를 안다는 뜻이다.
코딩 에이전트 항목에서는 아예 대놓고 나온다. 에이전트가 스스로 루프를 닫게 하려면 “검증기나 평가를 제공하라”고 한다. 에이전트에게 답을 주는 게 아니라 채점표를 주라는 이야기다.
빌드 형성하기는 스펙을 정하는 일인데, 스펙을 정한다는 건 무엇이 완료 상태인지를 정의하는 일이다. 그것도 결국 검증 기준이다.
응은 이 넷을 묶어서 이야기하지 않았지만, 다시 읽으면 네 항목이 전부 “무엇이 맞는지 어떻게 아는가” 라는 한 가지 질문의 다른 얼굴처럼 보인다.
이유는 간단하다. 코드 쓰는 일이 싸지면 틀린 것을 빨리 만드는 일도 같이 싸진다. 생산 속도가 열 배가 되면 잘못된 방향으로 달리는 속도도 열 배가 된다. 그래서 병목이 만드는 쪽에서 판별하는 쪽으로 옮겨간다.
전에 LLM 평가 방법을 정리하면서 평가가 그 자체로 모델링 작업이 됐다고 썼는데, 이 지도를 보니 그게 평가 도구를 만드는 사람만의 이야기가 아니었던 것 같다.
3. 모델을 만드는 능력이 목록에 없다
읽다가 한 번 멈칫했던 지점이다.
네 항목 어디에도 “모델을 학습시키는 능력”이 없다. 머신러닝과 딥러닝이 언급되긴 하는데, AI 앱 구축 항목에서 알아야 할 구성 요소 목록에 LLM, 컨텍스트 엔지니어링, RAG, 에이전틱 워크플로와 나란히 들어가 있을 뿐이다. 이해의 대상이지 만드는 대상이 아니다.
데이터 과학을 해온 입장에서는 좀 서늘한 대목이다. 몇 년 전만 해도 이 분야에서 실력을 증명하는 방법은 모델을 잘 만드는 것이었다. 지금 이 지도에서 모델 학습은 선택 가능한 부품 중 하나로 내려와 있다.
물론 이건 응이 AI 엔지니어링을 정의하는 방식의 결과이기도 하다. 모델을 만드는 일은 연구에 가깝고, 이 지도는 애플리케이션을 만드는 사람을 위한 것이니까. 다만 채용 공고 1만 건에서 뽑은 결과가 이렇다는 건 시장이 이미 그렇게 움직이고 있다는 뜻이기도 하다.
4. 지도에서 흐리게 그려진 곳
지도는 그려진 것만큼 안 그려진 것도 봐야 한다. 세 군데가 걸렸다.
빠졌다기보다, 흐리게 그려진 곳을 알고 봐야 한다는 뜻이다.
배포 이후. 첫 항목이 “구축과 배포”인데, 배포는 한 단어로만 등장하고 그 뒤 이야기가 거의 없다. 실제로는 배포되는 순간부터 추론 비용이 발생하고, 품질이 조용히 떨어지고, 관측이 안 되면 그걸 알아채지도 못한다. 예전에 정리했던 것처럼 장애는 대개 모델 바깥에서 시작되는데, 그 바깥이 이 지도에서는 얇게 그려져 있다.
도메인 지식. 네 항목 어디에도 없다. 네 번째 항목의 “비즈니스 맥락과 고객 목표를 이해한다”에 살짝 걸치기는 하는데, 실무에서는 무엇을 만들지가 대개 도메인에 의해 결정된다. 금융에서 이 거래를 자동 승인해도 되는지는 소프트웨어 지식으로 답할 수 없는 종류의 질문이다.
그리고 방법론 자체의 시차. 이건 방법론에 대한 지적인데, 채용 공고 1만 건은 이미 시장이 합의한 것만 담고 있다. 회사가 아직 이름을 못 붙인 역량은 공고에 안 적힌다. 응은 “지금뿐 아니라 가까운 미래에도 중요한 역량”을 찾았다고 했지만, 클러스터링은 데이터의 중심을 찾지 가장자리를 찾지 않는다. 그래서 이 지도는 미래의 예보라기보다 지금 합의된 것의 선명한 사진에 가깝다고 본다.
이건 흠이라기보다 성격에 가깝다. 지금 무엇을 배워야 할지 정하는 데는 선명한 사진이 오히려 더 쓸모 있다. 다만 이 지도만 보고 “여기 없는 건 안 중요하다”고 읽으면 곤란하다는 뜻이다.
5. 개인적인 견해
이 목록이 진짜 하는 말은 “만드는 사람에서 판단하는 사람으로” 아닐까 싶다. 네 항목 중 셋이 판단에 관한 것이다. 무엇이 틀릴 수 있는지 알고(기본기), 에이전트에게 채점표를 쥐여주고(코딩 에이전트), 무엇이 완료인지 정한다(빌드 형성). 실제로 손을 움직이는 부분은 점점 줄어드는 방향으로 그려져 있다.
이건 요즘 여러 곳에서 같은 결론이 나오고 있다는 점에서 더 그럴듯해 보인다. FDE라는 직군을 들여다봤을 때도 코드 비중이 70%라고 해놓고 정작 마지막에 남는 건 스코핑과 이해관계자 조율이었다. 출발점이 전혀 다른 두 자료가 같은 데로 도착하면 대체로 신호다.
그리고 좀 현실적인 이야기 하나. 이 목록에서 혼자 공부하기 제일 어려운 게 네 번째다. 기본기는 책이 많고, 코딩 에이전트는 쓰면서 늘고, 평가는 도구가 있다. 그런데 무엇을 만들지 정하는 감각은 실제 사용자와 실제 실패 없이는 늘지 않는다. 응이 MVP를 언제 빨리 내보내고 언제 천천히 갈지 아는 게 중요하다고 한 것도 같은 맥락일 것이다.
그래서 이 지도는 학습 목록보다, 자기 일에 네 번째를 연습할 자리가 있는지 점검하는 용도로 쓰는 게 나을 것 같다. 앞의 셋은 마음먹으면 어디서든 늘릴 수 있지만, 네 번째는 자리가 없으면 늘릴 방법이 없다.
함께 보면 좋은 글:
참고 자료
- Andrew Ng, The AI Engineering Skills Map (2026년 8월 15일)
본 글은 2026년 8월 15일 공개된 글을 읽고 정리했다. 네 가지 역량의 구분과 각 항목의 설명은 원문에 있는 것이고, 이를 층으로 다시 배치한 것과 검증이라는 축으로 묶어 읽은 것, 그리고 지도에서 흐린 부분에 대한 지적은 내 해석이다. 원문은 앞으로 각 항목을 더 자세히 풀어낼 예정이라고 밝히고 있어, 여기서 짚은 부분 중 일부는 이후 글에서 다뤄질 수도 있다.