Embedded AI Engineers: 마케팅·채용·재무 팀 안에 AI 엔지니어를 두라는 Andrew Ng의 제안

코딩 에이전트 덕분에 엔지니어 한 명이 만들 수 있는 양이 크게 늘었으니, 이제는 AI 엔지니어를 마케팅·채용·재무 같은 현업 부서 안에 앉히는 편이 훨씬 합리적이라는 제안입니다. 실제로 해 보려면 엔지니어보다 먼저 부서의 업무 목록과 우선순위를 정할 사람, 그리고 부서 데이터에 대한 권한 규칙이 있어야 합니다.

요약

Andrew Ng은 2026년 11월 6일 The Batch 378호 첫머리 서한에서 AI와 일자리 이야기로 시작합니다. LinkedIn 데이터에 따르면 AI가 만드는 데 기여한 일자리가 200만 개이고 AI Engineer는 7개 주요 경제권에서 가장 빨리 늘어나는 직업 상위 10위 안에 듭니다. 고통스러운 해고가 있었다는 점은 인정하지만, 이 데이터를 보면 AI가 대량 실업을 부른다는 주장은 맞지 않는다고 봅니다. 그가 새 직무 가운데 가장 흥미롭게 보는 것은 Embedded AI Engineer(현업 부서 안에 배치된 AI 엔지니어)입니다. 이들은 마케팅·인사·재무 같은 부서에서 업무 자동화를 만들고 동료가 AI를 쓰도록 돕습니다.

이 배치가 지금 맞는 이유로 Ng은 생산성을 듭니다. 코딩 에이전트가 나오기 전에도 엔지니어를 다른 부서에 두는 팀이 가끔 있었습니다. 하지만 엔지니어 한 명이 만들 수 있는 양이 적어 효과가 작았습니다. AI로 개발 생산성이 오른 지금은 계산이 달라졌습니다. Ng의 일부 팀은 실제로 AI 엔지니어를 마케팅, 채용, 재무 등에 배치했습니다. 엔지니어는 다른 부서의 일을 배웠고 부서는 더 나은 시스템과 AI에 대한 훨씬 깊은 이해를 얻었습니다. 만들 아이디어는 늘 엔지니어의 역량을 넘었습니다. Ng은 그 이유를 이렇게 짚습니다. “the bottleneck is not coding, but product management, workflow redesign”. 여기에 판단 업무가 더해집니다. 아래에서 다섯 가지 작동 원리와 Ng 팀의 사례를 본 뒤, 따라 할 때 필요한 기술·현업 디테일을 붙입니다.

핵심 메커니즘

Embedded AI Engineer: 부서 안에 앉아 부서의 일을 시스템으로 바꾸는 엔지니어

Embedded AI Engineer는 IT 조직이 아니라 현업 부서 안에서 일하는 AI 엔지니어입니다. 부서의 반복 업무와 데이터를 곁에서 보고 코딩 에이전트를 써서 자동화와 앱을 직접 만듭니다. 요청서를 받아 순서를 기다리는 구조가 아니어서 부서 사람이 말한 문제가 며칠 안에 돌아가는 도구가 됩니다. 반복 업무가 많고 여러 시스템을 손으로 오가는 부서에서 효과가 큽니다. 반대로 업무가 대부분 사람 사이 협상이거나 데이터가 거의 없는 부서라면 전담 배치보다 순회 지원이 낫습니다. 가상 예시로, 재무팀에 앉은 엔지니어가 월말마다 사흘씩 걸리던 법인카드 증빙 대조를 자동화 흐름으로 바꾸고 남은 예외 건만 담당자가 보게 하는 식입니다.

코딩 에이전트 이후의 계산: 엔지니어 한 명이 부서 하나를 받칠 수 있게 됐다

Ng이 이 배치를 지금 권하는 근거는 생산성입니다. 예전에는 엔지니어 한 명을 마케팅팀에 두어도 만들 수 있는 것이 적어 인건비만큼의 효과를 내기 어려웠습니다. 코딩 에이전트(코드 작성과 수정을 맡아 하는 AI 도구)가 구현 시간을 줄이면서 같은 한 명이 부서 하나의 자동화·분석·앱을 감당할 수 있게 됐다는 것입니다. 서한은 생산성이 몇 배 올랐는지 숫자로 밝히지 않습니다. 이 계산은 부서의 반복 업무가 충분히 많을 때 성립합니다. 자동화할 거리가 몇 건뿐이면 한 엔지니어가 여러 부서를 돌며 맡는 편이 맞습니다.

다섯 가지 일: 자동화, 분석, 데이터 기반, 앱, 교육

서한은 부서에 앉은 AI 엔지니어가 할 일을 다섯 가지로 듭니다. 첫째는 워크플로 자동화입니다. 둘째는 대시보드를 만들고 데이터를 분석해 인사이트를 발표하는 일입니다. 셋째는 부서가 쓸 데이터 기반을 만드는 일이고, 넷째는 맞춤 앱을 직접 만들거나 외부 앱을 사서 붙이는 일입니다. 다섯째는 동료에게 AI 엔지니어링과 AI 활용법을 가르쳐 그들이 스스로 더 많이 하게 만드는 일입니다. 다섯째가 앞의 넷과 다른 점은 엔지니어의 역량 한계를 푸는 장치라는 것입니다. Ng이 엔지니어가 아닌 사람도 AI의 도움으로 소프트웨어 만드는 법을 배우라고 권하는 것과 같은 맥락입니다. 다만 그는 AI 엔지니어링 역량을 갖춘 개발자가 여전히 훨씬 많은 일을 할 수 있다고 덧붙입니다.

새 병목: 코딩보다 기획, 워크플로 재설계, 판단

Ng의 팀에서 부서에 둔 엔지니어들은 늘 일감이 넘쳤습니다. Ng은 구현이 아니라 그 앞 단계가 좁아졌다고 봅니다. 무엇을 만들지 고르고 범위를 정하는 product management(제품 기획·우선순위 결정), 기존 업무 흐름을 AI가 들어갈 자리에 맞게 다시 짜는 workflow redesign(워크플로 재설계), 그리고 무엇이 맞는지 사람이 정해야 하는 판단 업무입니다. 이 세 가지에는 여전히 사람의 품이 많이 든다고 그는 말합니다. 그래서 엔지니어 한 명만 부서에 보내면 금세 막힙니다. 우선순위를 정하고 바뀐 업무 흐름에 책임질 부서 쪽 사람이 함께 있어야 합니다. 가상 예시로, 채용팀이 “지원자 응대를 자동화하자”고만 하면 엔지니어는 어느 단계를 사람이 남겨야 하는지 정할 수 없습니다. 채용 담당자가 단계별로 사람이 결정할 곳을 표시해 줘야 일이 진행됩니다.

양방향 학습: 엔지니어는 업무를, 부서는 AI를 배운다

배치의 효과는 시스템에서 그치지 않습니다. Ng은 엔지니어가 마케팅·채용·재무의 일하는 방식을 배우고, 부서는 AI를 훨씬 깊이 이해하게 됐다고 전합니다. 엔지니어가 부서 용어와 판단 기준을 알게 되면 요건을 옮기는 단계가 줄어듭니다. 부서 사람들은 옆자리에서 만들어지는 과정을 보며 무엇이 자동화하기 쉽고 무엇이 어려운지 감을 잡습니다. 이 효과를 노린다면 엔지니어를 짧게 파견하고 끝내기보다 한 부서에 몇 달 이상 머물게 하는 편이 낫습니다. 서한은 배치 기간을 밝히지 않았습니다.

통념과 다른 주장

저자가 든 사례

Ng의 팀: 마케팅·채용·재무에 AI 엔지니어를 배치

• 상황: 코딩 에이전트로 엔지니어 생산성이 오른 뒤, Ng의 일부 팀이 엔지니어를 현업 부서에 두는 방식을 시도했습니다.
• 한 일: AI 엔지니어를 마케팅, 채용, 재무와 그 밖의 부서에 배치했습니다.
• 결과: 엔지니어는 다른 부서의 일을 배웠고, 부서는 더 나은 시스템과 AI에 대한 훨씬 깊은 이해를 얻었습니다. 만들 아이디어는 늘 엔지니어 역량을 넘었습니다. 회사 이름, 인원, 기간, 절감 수치는 서한에서 밝히지 않았습니다.
• 연결: Embedded AI Engineer, 새 병목, 양방향 학습.

기술 디테일: 부서에 앉은 엔지니어가 첫 달에 깔 것

아래 필드명, 설정값, 구성은 실행 제안이자 가상 예시입니다. 서한은 특정 도구나 모델을 밝히지 않았습니다.

부서 요청은 구조화된 backlog로 받습니다(새 병목). 아이디어가 역량을 넘는다면 무엇부터 할지 정하는 기준이 먼저 있어야 합니다. 요청 하나를 레코드 하나로 적고 엔지니어와 부서 오너가 매주 같은 표를 보고 순서를 정합니다.

{
  "request_id": "FIN-007",
  "team": "재무",
  "owner": "결산 담당 과장",
  "task": "법인카드 사용 내역과 증빙 영수증 대조",
  "frequency": "월 1회, 3일 소요",
  "hours_per_month": 24,
  "systems": ["카드사 내역 CSV", "경비 시스템", "공유 드라이브 영수증"],
  "sensitivity": "중간: 개인 카드번호 마스킹 필요",
  "human_decision": "불일치 건 처리 여부",
  "build_or_buy": "build",
  "success_metric": "월 대조 시간, 누락 건수"
}

순위는 hours_per_month가 크고 human_decision이 좁은 요청부터 매깁니다. human_decision을 채우지 못한 요청은 워크플로 재설계가 끝나지 않은 것이므로 구현에 넣지 않습니다.

자동화 한 건은 같은 뼈대로 만듭니다(다섯 가지 일 중 워크플로 자동화). 트리거, 데이터 조회, LLM 단계, 규칙 검사, 사람 승인의 다섯 칸입니다. LLM 단계는 자유 문장 대신 JSON 스키마로 출력하게 하고 temperature 0으로 둡니다. 스키마 검증에 실패하면 2회까지 다시 부르고 그래도 실패하면 사람 대기열로 넘깁니다. 배포 전에는 과거 사례 50건을 정답지로 만들어 돌립니다. 담당자 판단과 95% 이상 일치하기 전에는 사람 승인을 빼지 않습니다. 모델은 회사가 승인한 모델 하나로 시작하고 정답지 기준을 넘기면 더 싼 모델로 바꿔 같은 시험을 다시 돌립니다.

대시보드와 분석은 부서가 정한 정의 위에서 만듭니다(대시보드·분석). 코딩 에이전트에게 SQL을 쓰게 하면 빠릅니다. 하지만 “활성 고객”이나 “채용 리드타임” 같은 지표 정의가 사람마다 다르면 숫자가 엇갈립니다. 지표마다 정의 문장, 계산식, 담당자를 한 파일에 적고 에이전트가 그 파일을 참조해 쿼리를 쓰게 합니다. 검증을 마친 쿼리는 저장소에 남겨 다음 분석에서 다시 씁니다.

데이터 기반은 읽기 전용 뷰와 마스킹부터 깝니다(데이터 기반). 부서에 앉은 엔지니어는 원천 시스템에 바로 쓰지 않고 부서용 읽기 전용 뷰에서 시작합니다. 채용·인사 데이터는 이름, 연락처, 평가 결과를 마스킹하고 행 단위 권한을 둡니다. 재무 데이터는 금액을 바꾸는 쓰기 작업을 사람 승인 뒤에만 허용합니다. 서비스 계정과 호출 로그는 중앙 IT가 관리합니다.

만들지 살지는 세 가지로 가릅니다(앱 구축·도입). 이미 쓰는 SaaS에 같은 기능이 있으면 연동합니다. 부서 고유 규칙이 많아 설정으로 맞추기 어려우면 직접 만듭니다. 쓰기 권한이 큰 앱은 직접 만들더라도 중앙 IT 코드 리뷰를 거쳐 배포합니다. 앱마다 소유자, 읽는 데이터, 쓰는 데이터, 효과 지표를 카탈로그에 올립니다.

동료 교육은 졸업 기준을 둡니다(동료 교육). 주 1회 1시간 오픈 세션을 열고 자주 쓰는 프롬프트와 자동화 템플릿을 부서 공용 폴더에 모읍니다. 부서원 한 명이 엔지니어 도움 없이 자동화 한 건을 끝까지 만들면 그 사람을 다음 교육의 보조로 세웁니다.

막히는 경우	증상	대응
요청은 많은데 순위가 없음	엔지니어가 목소리 큰 요청부터 처리	backlog 표로 주 1회 부서장과 순위 확정
사람 결정 지점이 정해지지 않음	자동화가 끝까지 못 가고 멈춤	human_decision 미기재 요청은 구현 보류
LLM 출력이 흔들림	같은 입력에 다른 결과	JSON 스키마, temperature 0, 정답지 50건 회귀 시험
민감 데이터 노출	인사 정보가 로그에 남음	마스킹 뷰, 로그 필드 제외 목록
앱이 늘어 관리가 안 됨	같은 기능의 앱 여러 개	카탈로그 월 1회 점검, 90일 미사용 앱 보관 처리

현업 실행 디테일: 누가, 언제, 무엇을

서한은 엔지니어를 부서에 배치하고, 엔지니어가 다섯 가지 일을 하며, 병목은 기획과 판단에 있다고 전합니다. 아래 역할, 보고선, 일정, 기준은 이를 바탕으로 새로 짠 가상 예시입니다.

역할	맡는 일
부서장(스폰서)	시범 부서 확정, backlog 순위 최종 결정, 12주 판정
Embedded AI Engineer 1명	업무 관찰, 자동화·분석·앱 구축, 동료 교육
부서 업무 오너 1~2명	요청 정리, 사람이 결정할 지점 표시, 결과 검증
중앙 AI·IT 플랫폼팀	데이터 권한, 코드 리뷰, 보안 점검, 도구 계약
개인정보·보안 담당	인사·재무 데이터 마스킹 기준 승인
HR	배치 엔지니어의 직무 정의, 평가 기준, 경력 경로

보고선. 실선은 부서장, 점선은 중앙 엔지니어링 조직에 두는 방식을 권합니다. 일의 순위는 부서가 정하고, 코드 품질과 보안 기준은 중앙이 지키게 하려는 것입니다. 엔지니어 평가는 부서장과 중앙 리더가 함께 합니다.

준비물. 부서 업무 목록과 담당자별 월 소요 시간, 부서가 쓰는 시스템과 파일 위치, 최근 3개월 반복 업무 사례 10건, 데이터 민감도 분류, 이미 쓰는 SaaS 목록이 필요합니다.

기간	할 일	산출물
1~2주	업무 관찰, 부서원 인터뷰, backlog 작성	요청 20건 안팎의 backlog, 시간 기준선
3~6주	빠른 성과 2~3건 구축, 읽기 전용 데이터 뷰	가동 중인 자동화, 절감 시간 기록
7~10주	대시보드·데이터 기반, 주 1회 교육	부서 지표 정의 파일, 교육 자료
11~12주	효과 정리, 판정 회의	진행·보완·중단 결정서

부서에 물을 것.

1. 매달 가장 오래 걸리는 반복 업무는 무엇이고, 몇 시간이 드나요?
2. 그 업무에서 사람이 꼭 판단해야 하는 지점은 어디인가요?
3. 그 일을 하려고 몇 개의 시스템이나 파일을 오가나요?
4. 결과가 틀리면 누가, 언제 알게 되나요?
5. 지금 IT에 요청하고 기다리는 일 가운데 가장 오래된 것은 무엇인가요?

진행 판정 기준(예시). 12주 안에 자동화 3건 이상이 실제로 돌고 절감 시간이 월 40시간을 넘으며 부서원 2명 이상이 혼자 자동화 한 건을 만들었다면 다른 부서로 넓힙니다. 자동화는 돌지만 부서원이 아무도 직접 만들지 못했다면 교육 비중을 높여 6주 더 봅니다. backlog의 절반 이상에서 사람 결정 지점을 정하지 못했다면 엔지니어가 아니라 업무 오너 지정부터 다시 합니다.

AX 적용 제언. 첫 부서는 반복 업무가 많고 결과를 숫자로 확인할 수 있는 곳이 좋습니다. 재무 결산, 채용 운영, 마케팅 캠페인 집계가 대표적입니다. 순서는 업무 오너 지정, backlog, 빠른 성과, 교육입니다. 엔지니어를 뽑기 전에 부서장이 업무 오너를 먼저 지정해야 Ng이 말한 병목을 피할 수 있습니다. 엔지니어는 그 부서 일에 호기심이 있는 사람을 고르고 HR과 함께 경력 경로를 정해 두어야 이탈을 막습니다. 한 부서에서 판정 기준을 넘기면 부서마다 한 명씩 늘리기보다, 교육을 마친 부서원이 일부를 맡는 구조로 넓히는 편이 비용 면에서 낫습니다.

원문 사례

항목	내용
원문	DeepLearning.AI The Batch 378호(2026.11.6) 첫머리 서한, Andrew Ng
일자리 데이터	LinkedIn: AI가 기여한 일자리 200만 개, AI Engineer는 7개 주요 경제권에서 급성장 직업 상위 10위
일자리 손실	고통스러운 해고가 있었다고 인정, 대량 실업 주장은 데이터와 맞지 않는다고 봄
도표	LinkedIn의 가장 흔한 AI 빌더 직무, AI 직무 공고에서 AI Engineer·ML Engineer 비중이 가장 높음
핵심 제안	AI 엔지니어를 마케팅·인사·재무 등 현업 부서에 배치
배경	코딩 에이전트 이전에는 생산성이 낮아 배치 효과가 작았음
맡는 일	워크플로 자동화, 대시보드·분석·발표, 데이터 기반, 앱 구축·도입, 동료 교육
Ng 팀의 경험	마케팅·채용·재무 등에 배치, 엔지니어는 부서 업무를, 부서는 AI를 배움
병목	코딩이 아니라 기획, 워크플로 재설계, 판단 업무
전망	AI 엔지니어의 기회는 많은 사업 분야에서 끝이 없어 보이며, 채택이 퍼질수록 수요가 늘 것
모두에게	개발자가 아니어도 AI 도움으로 소프트웨어 만드는 법을 배우면 좋다

핵심 개념

AI Engineer

LLM과 AI 도구를 써서 실제로 돌아가는 애플리케이션과 자동화를 만드는 엔지니어입니다. 모델 자체를 학습시키는 ML Engineer와 구분해 부릅니다.

ML Engineer

머신러닝 모델을 학습시키고 배포·운영하는 엔지니어입니다.

코딩 에이전트

지시를 받아 코드를 쓰고 고치고 실행해 보는 AI 도구입니다. 서한은 특정 제품을 들지 않았습니다.

워크플로 자동화

사람이 여러 시스템을 오가며 하던 반복 업무를 트리거와 단계로 엮어 자동으로 돌리는 것입니다.

Backlog

만들 거리를 한곳에 모아 우선순위대로 쌓아 둔 목록입니다.

내 메모

TODO: 내 생각 추가

원문은 DeepLearning.AI The Batch 378호(2026.11.6)의 첫머리 서한으로, Andrew Ng이 썼습니다. 이 노트는 그중 서한 부분만 다뤘고 같은 호의 뉴스 기사는 다루지 않았습니다. 요약, 핵심 메커니즘의 원문 설명, 통념과 다른 주장, 사례, 원문 사례 표는 서한 내용을 AX Review가 다시 정리했습니다. 200만 개와 상위 10위는 서한이 인용한 LinkedIn 데이터입니다. 핵심 개념의 뜻풀이와 언제 쓰고 언제 안 쓰는지에 대한 설명은 일반적인 정의로 보탰습니다. JSON 예시, 자동화 뼈대, 데이터 권한, 막히는 경우 표, 역할·보고선·일정·판정 기준, 인포그래픽은 서한에 없는 내용으로 새로 작성했고 그 안의 필드명과 숫자는 가상 예시입니다. 전체 내용은 원문 페이지에서 볼 수 있습니다.