Andrew Ng — AI Engineering Skills Map
한 줄: 설치 가이드가 아니라 「빌드를 잡는」 AI Engineering 스킬 맵이다. 네 축은 빌드 루프·제품 결정·소통·높은 주체성이다.
Andrew Ng(@AndrewYNg)의 X 아티클 AI Engineering Skills Map: Shaping the build(2026-09-11)을 역할 지도로 다시 짠 메모다.
초안 작성·문장 정리에 AI를 사용했다. 해석은 작성자 것이며 원문과 다를 수 있다. 아래 예시는 원문에 나온 것만이다.
이 글이 푸는 문제
예전에는 PM·디자이너가 스펙을 잡고 개발자가 구현했다. AI가 한 사람의 빌드 속도를 올리면서 그 분업이 그대로 유지되기 어렵다. Ng가 말하는 AI 엔지니어는 스펙의 실행자만이 아니라 무엇을 만들지·다음 루프를 어떻게 돌릴지에도 개입한다. (반대로 PM·디자이너도 빌드에 들어온다.)
원문은 도구 튜토리얼도, 벤치 비교도 아니다. 역할 경계가 흐려진 시대의 역량 지도다. 핵심 명제는 단순하다. build만 하지 말고, shape the build.
AI로 코드가 빨라진다고 제품·방향이 자동으로 좋아지지는 않는다. 맵이 가리키는 것은 모델이 아니라 사람이 루프를 쥐는 방식이다.
예전 분업 vs shape the build
| 예전 분업에 가깝게 | Ng가 그리는 AI Engineering | |
|---|---|---|
| 역할 | 스펙은 PM·디자인, 구현은 엔지니어 | 빌드하는 사람이 다음 수·빈 칸에도 개입 |
| 속도 | 핸드오프가 병목 | AI로 개인 빌드 속도↑ → 경계가 흐려짐 |
| 성공 척도 | 태스크·티켓 완료 | 만든 가치, 루프를 전진시켰는지 |
| 한 줄 | build | shape the build |
스킬 맵 (네 축)
| 축 | 한 줄 |
|---|---|
| Driving the build loop | 코드→피드백→다음 결정 루프를 높은 속도로 직접 돌린다 |
| Making product decisions | 스펙 밖·스펙 없음에서도 제품·디자인·비즈니스 감각으로 방향을 잡는다 |
| Communicating and leading | 풀스택을 넘어 마케팅·재무·법무 등과 정렬하고, 조직의 AI 인식을 돕는다 |
| High-agency ownership | 탑다운을 기다리지 않고 문제를 보고·제안·실행하되, 완료가 아니라 가치로 잰다 |
네 축은 병렬 체크리스트라기보다 한 사람의 빌드 책임 범위를 그린 지도에 가깝다.
빌드 루프를 돈다는 것
차이는 「누가 다음 스텝을 고르느냐」다. Ng는 능숙한 AI 엔지니어가 제품 비전·프로젝트 단계·기술 실현 가능성·핵심 리스크·노력·예산을 함께 보고 루프를 밀어 올린다고 본다. 성숙한 프로젝트에서는 핵심 지표를 정의하고 그 개선까지 프로젝트 관리로 가져간다.
루프에 들어가기 전에 실제로 고르는 것은 이런 쪽이다. 지금 필요한 정보가 사용자 피드백인지 기술 실험(예: 모델 학습)인지, 이번 배치가 빠른 프로토타입·MVP·기능 추가·엔터프라이즈급 투자 중 무엇인지, 작은 배치로 자주 출시할 수 있는지. 결정은 비전·단계·실현 가능성·리스크·노력·예산을 같이 넣고, 성숙 단계라면 지표 개선을 이번 루프 목표로 잡는다.
원문 샘플: 다음 스텝으로 고를 수 있는 것들
- 기술 개념·사용자 기능을 검증하는 빠른 프로토타입
- 가치를 보여 주기 위한 MVP(minimum viable product)
- 기능 추가 vs 엔터프라이즈급 시스템에 투자
- 속도를 유지하려고 작은 배치로 자주 출시
- 사용자·이해관계자 피드백을 받을 때 vs 기술 실험(예: 모델 학습)으로 정보를 모을 때
샘플이 말하는 바는 「항상 MVP」가 아니라, 지금 루프에 맞는 다음 한 수를 스스로 고른다는 쪽이다.
제품 결정 = PM이 되는 것?
원문은 「개발자가 PM이 되어야 한다」고 말하지 않는다. 스펙이 비운 칸을 채울 수 있어야 한다는 쪽에 가깝다. 스펙 없이 빌드하라는 요청을 받으면 스펙을 스스로 잡을 줄 안다.
제품 감각(product sense)·기본 디자인 감각·기본 비즈니스 감각(go-to-market, 시장 규모, unit economics, P&L)을 말하고, 그 뿌리로 user empathy를 둔다. 방향이 실제 니즈인지 한 줄로 적고, 기능만 되는지뿐 아니라 쓰기 좋은지를 본다. 비즈니스 숫자는 전부 외우는 게 아니라 이번 트레이드오프에 닿는 것만 짧게 본다. 공감 입력은 단계에 맞는 규모를 고른다.
원문 샘플: 사용자 공감을 다듬는 방법의 폭
- 2–3명 비공식 인터뷰
- 수백 명 설문
- 대규모 A/B 테스트
- 수천·수백만 사용자 행동 분석
규모만 다른 도구가 아니라, 공감을 계속 업데이트하는 입력 채널로 적혀 있다.
넓어진 범위와 소통
전문 영역(예: 프론트엔드)이 풀스택으로 넓어지던 흐름의 연장선이다. AI Engineering은 그 너머 — 프로젝트에 영향을 주는 다른 기능 — 로도 연다. 그래서 소통은 부가 스킬이 아니라 빌드를 전진시키는 축이 된다.
이슈에 마케팅·재무·법무 정렬이 필요한지, 사용자와 말해 공감을 키울 짧은 대화가 필요한지, 비엔지니어에게 가능/불가능을 설명할 한 문장이 있는지를 같이 본다. 조직의 AI 인식은 그 설명에서 자란다.
원문 샘플: 범위가 닿는 곳
- 프로젝트에 영향을 주는 마케팅·재무·법무 등과 정렬·조율
- (기초로) 사용자와 말해 공감을 키우는 소통
- 엔지니어링 밖 동료에게 어떤 이니셔티브가 기술적으로 가능/불가능한지 설명하며 조직의 AI 인식을 돕기
High-agency: 간극을 메우는 자리
많은 사람(일부 임원 포함)이 AI로 무엇을 할 수 있는지, 어떤 방향이 좋은지 아직 모른다. 기술 역량이 그 빈칸을 메울 수 있다.
주체성은 문제를 보고, 해결책을 제안하고, 실행까지 한 줄로 잇는 일이다. 조직의 우선순위·제약은 존중하되, 세밀한 탑다운 지시는 기다리지 않는다. 이니셔티브를 end-to-end로 소유하고, 이슈에 책임지며, 모호함 속에서 움직이고, 좌절을 견딘다. 막히면 end-to-end 소유·이슈 책임·모호함·좌절 중 지금 막힌 지점을 먼저 본다. 측정 단위는 태스크 완료가 아니라 만든 가치다.
원문 샘플: 주체성이 하는 일
- 문제를 보고, 해결책을 제안하고, 실행한다
- 조직의 우선순위·제약은 존중하되, 세밀한 탑다운 지시는 기다리지 않는다
- 이니셔티브를 end-to-end로 소유하고, 이슈에 책임지며, 모호함 속에서 움직이고, 좌절을 견딘다
- 측정 단위는 태스크 완료가 아니라 만든 가치
맵 밖 습관도 한 줄로 남는다. 프론티어를 따라가고, 도구·워크플로를 튜닝하며 스킬에 계속 투자한다 — 네 축과 별도로 스킬 자체를 키우는 루프다. DeepLearning.AI는 원문에서 이 스킬 세트를 키우는 데 초점을 둔다고만 밝힌다.
한계
이 맵은 코스 커리큘럼이나 도구 목록이 아니다. 「네 축을 외우면 AI 엔지니어」처럼 읽으면 장르를 놓친다. 샘플·루프 선택은 레시피가 아니라 고르는 일의 폭을 보여 줄 뿐이다. High-agency도 조직 제약을 무시하라는 뜻이 아니라, 빈 칸을 메우되 존중과 실행을 같이 가라는 쪽에 가깝다.
남는 정리
이 문서를 「동기부여 에세이」로만 읽으면 축이 흐려진다. AI Engineering을 구현 스킬이 아니라, 빌드 루프·제품·소통·주체성을 묶은 역할 지도로 읽는 쪽이 원문의 장르에 맞다. 샘플은 각 축이 실제로 무엇을 고르는 일인지 보여 주는 재료다.
출처
- Andrew Ng, AI Engineering Skills Map: Shaping the build (2026-09-11): https://x.com/i/article/2098450134883594240
- 소개 포스트: https://x.com/AndrewYNg/status/2098459474608672916
- 작성자: Andrew Ng — Coursera 공동창업, Stanford CS adjunct, 전 Baidu AI / Google Brain
스킬 맵 정리. AI 보조 작성.
댓글