AI 엔지니어링 필수 4대 역량은?

원문 안내 — 본 글은 앤드류 응(Andrew Ng)이 2026년 8월 14일 DeepLearning.AI의 뉴스레터 The Batch 에 발표한 서신 「The AI Engineering Skills Map」 을 소개하고 해설하는 글입니다.

이매진댓 AI Research 의 독자적인 정리·분석 글이며, 원문의 논지를 전달하기 위해 짧은 인용만 사용했습니다. 원문 전문은 아래 공식 링크에서 직접 읽으실 수 있습니다.

· 원문: The AI Engineering Skills Map — Andrew Ng, The Batch (2026-08-14) · 저자: Andrew Ng · 발행: DeepLearning.AI, The Batch · 인용문의 한국어는 이해를 돕기 위한 것이며, 해석에 차이가 있으면 영문 원문이 우선합니다.

얻어 갈 것 — 스탠포드 AI 현자인 앤드류 응 교수가 제시한 AI 엔지니어링 4대 역량이 무엇이고 왜 이런 역량이 중요한지 배울 수 있습니다.

---

1. AI 시대, 무엇을 배워야 하는가 — 왜 아무도 명확한 답을 주지 못할까?

AI 학습법에 관한 조언은 넘쳐납니다. 문제는 조언의 방향이 제각각이라는 데 있습니다. 누군가는 딥러닝과 파인튜닝을 배워야 한다고 말하고, 누군가는 이제 프롬프트만 잘 작성하면 충분하다고 주장합니다. 또 다른 누군가는 결국 컴퓨터과학의 탄탄한 기본기가 가장 중요하다고 강조합니다.

정보가 부족한 것이 아니라, 오히려 너무 많고 제대로 검증되지 않았다는 것이 문제입니다. 무엇을 믿고 어디에 시간과 자원을 투자해야 하는지 판단하기가 그만큼 어려워졌습니다.

스탠퍼드대학교 교수이자 AI 분야의 세계적 석학인 앤드류 응(Andrew Ng)은 이러한 정보 환경을 “시끄럽고 과장으로 가득 찬(noisy, hype-filled)” 상태라고 표현합니다. 그리고 이 혼란 속에서 보다 본질적인 질문을 던집니다.

지금, 그리고 가까운 미래에 정말로 배울 가치가 있는 역량은 무엇인가?

2. 무엇을 선정했는가보다 ‘어떻게 선정했는가’가 중요하다

앤드류 응이 AI 핵심 역량을 도출하기 위해 활용한 방법은 다음 네 가지로 요약할 수 있습니다.

• 1만 건 이상의 채용공고를 분석해 기업이 실제로 비용을 지불하며 확보하려는 역량을 파악

• AI 전문가, 채용 관리자 및 리크루터를 대상으로 수십 건의 구조화된 인터뷰 수행

• 현업 전문가를 대상으로 한 설문조사를 통해 추가 데이터 수집

• 그 밖의 다양한 온라인 데이터를 종합적으로 검토

그는 이러한 과정을 “대규모 채용공고와 전문가 인터뷰 데이터에서 유사한 역량을 군집화하는 작업”에 비유합니다. 분석의 시간적 범위도 명확합니다. 현재 시장에서 요구되는 역량뿐 아니라 가까운 미래에 중요성이 커질 역량까지 선제적으로 식별하는 것이 목표입니다.

이러한 접근이 중요한 이유는 역량 지도가 특정 전문가 개인의 취향이나 직관이 아니라, 시장 전반에서 관찰되는 수요를 종합해 도출한 결과이기 때문입니다. 단순히 “배워두면 유용한 기술”을 제안하는 수준을 넘어, “시장이 이미 가치를 인정하고 실제로 비용을 지불하고 있는 역량”을 보여주는 지표에 가깝습니다.

개인에게는 제한된 시간과 자원을 어디에 우선적으로 투자할 것인지 판단하는 근거가 됩니다. 조직에는 채용 요건을 설계하고 인재 선발 기준을 구체화하는 참고자료가 됩니다. 앤드류 응 역시 이 작업의 목적을 다음 두 가지로 명확히 제시합니다.

• 개발자가 무엇을 먼저 배워야 할지 우선순위를 정하도록 지원하는 것

• 기업이 필요한 역량을 갖춘 개발자를 효과적으로 채용하도록 돕는 것

다만 이 지도를 절대적인 기준으로 받아들여서는 안 됩니다. 분석에 활용된 채용공고는 미국 시장에 상당 부분 편중되어 있으며, 공고에 명시된 요구사항이 실제 현업의 업무나 필요 역량과 정확히 일치하지 않는 경우도 적지 않습니다.

따라서 이 지도는 시장의 방향성을 판단하기 위한 유용한 근거이지, 모든 개인과 조직에 동일하게 적용할 수 있는 정답표는 아닙니다.

3. 먼저 구분해야 할 것 — ‘AI 엔지니어’가 아니라 ‘AI 엔지니어링 역량’

이번 서신에서 실무적으로 가장 중요한 대목은 용어의 구분입니다. 앤드류 응은 자신이 말하는 대상이 ‘AI 엔지니어’라는 특정 직무가 아니라, ‘AI 엔지니어링 역량(AI engineering skills)’이라고 분명히 선을 긋습니다. 특정 직함보다 해당 역량이 적용되는 범위가 훨씬 넓기 때문입니다.

그가 제시한 비유는 명확합니다. 오늘날 대부분의 개발자는 클라우드를 다룰 수 있어야 하지만, 그렇다고 모두가 ‘클라우드 엔지니어’라는 직함을 갖는 것은 아닙니다. AI 역시 같은 경로를 밟고 있습니다.

앞으로는 풀스택 엔지니어, 데이터 엔지니어, DevOps 엔지니어, 머신러닝 엔지니어는 물론 AI 엔지니어에 이르기까지 사실상 모든 개발 직군에 AI 엔지니어링 역량이 요구될 가능성이 큽니다.

실무적 의미

이 구분은 두 가지 오해를 바로잡습니다.

첫째, “나는 AI 엔지니어가 아니므로 나와는 관련이 없다”고 생각했던 개발자에게도 해당되는 문제입니다. AI 엔지니어링은 일부 전문 직군을 넘어 개발 업무 전반에 통합되는 공통 역량으로 확장되고 있습니다.

둘째, AI를 도입하기 위해 반드시 별도의 AI 전담 직무를 신설해야 한다고 생각했던 조직에도 시사점을 줍니다. 경우에 따라서는 새로운 직함과 조직을 만드는 것보다 기존 인력에게 AI 엔지니어링 역량을 결합하는 편이 더 현실적이고 효과적인 접근일 수 있습니다.

4. 네 가지 핵심 역량 — 무엇이며, 왜 중요한가?

① AI 애플리케이션 구축 및 배포

Building and Deploying AI Applications

앤드류 응은 AI 애플리케이션과 전통적인 비-AI 애플리케이션의 핵심 차이를 하나로 압축합니다. 바로 출력의 예측 가능성입니다.

LLM에 동일하거나 유사한 프롬프트를 입력하더라도 항상 같은 품질의 결과가 나오는 것은 아닙니다. 딥러닝 모델 역시 새로운 데이터에 어떤 예측을 내놓을지 완벽하게 확정할 수 없습니다. 반면 전통적인 소프트웨어는 주어진 입력과 규칙에 따라 상대적으로 예측 가능한 방식으로 작동합니다.

따라서 AI 애플리케이션 구축 역량은 크게 두 개의 층으로 나뉩니다.

첫 번째는 AI 시스템을 구성하는 기술 요소를 이해하고 활용하는 능력입니다.

• 대규모 언어모델(LLM)

• 컨텍스트 엔지니어링

• 검색 증강 생성(RAG)

• 에이전틱 워크플로

• 머신러닝과 딥러닝

두 번째이자 더욱 중요한 역량은 통계적 기법을 활용해 AI 시스템을 측정하고 조정하며, 그 결과를 보다 예측 가능한 범위 안에서 통제하는 능력입니다. 앤드류 응은 이를 위해 규율 있는 평가 체계(evals)와 반복적인 오류 분석 루프가 필요하다고 강조합니다.

실무적 의미

많은 조직이 첫 번째 단계에서 멈춥니다. RAG를 연결하고 에이전트를 작동시켜 인상적인 데모를 만드는 데까지는 성공합니다. 그러나 “이 시스템이 실제로 잘 작동하고 있다는 것을 어떻게 입증할 것인가?”라는 질문에는 답하지 못합니다. 결국 운영 환경에 적용하지 못한 채 시범 프로젝트로 종료됩니다.

데모와 프로덕션 시스템을 가르는 핵심 기준은 평가 체계의 유무입니다.

평가 체계가 구축되어 있으면 모델이나 프롬프트를 변경했을 때 그 변화가 개선인지 퇴보인지 수치로 판단할 수 있습니다. 반대로 평가 기준이 없다면 담당자의 감각과 인상에 의존할 수밖에 없으며, 문제 발생 시 원인을 규명하거나 합리적으로 롤백하기도 어렵습니다. 이러한 불확실성은 운영 과정에서 지속적인 비용으로 누적됩니다.

---

② 소프트웨어 엔지니어링 기본기

Software Engineering Fundamentals

소프트웨어 엔지니어링의 기본기가 네 가지 핵심 역량에 포함되었다는 사실 자체가 중요한 메시지입니다.

앤드류 응에 따르면 소프트웨어 엔지니어링은 본질적으로 비용, 확장성, 안정성 및 개발 속도 사이의 트레이드오프를 판단하는 작업입니다. 여기에 보안과 개인정보 보호까지 더해지면서 의사결정의 복잡성은 더욱 커집니다.

기본기를 갖추었다는 것은 코드를 직접 작성할 수 있다는 의미에 그치지 않습니다. 시스템을 설계할 때 어떤 선택지가 존재하며, 각각의 선택이 어떤 비용과 위험을 수반하는지 인식할 수 있다는 뜻입니다.

그는 이 대목에서 바이브 코딩(vibe coding)의 위험을 직접적으로 지적합니다. 기본기가 부족한 개발자는 코딩 에이전트가 어떤 기술적 트레이드오프를 선택했는지 이해하지 못한 채 결과물을 받아들이게 됩니다. 이러한 선택은 대체로 좋지 않은 결과로 이어질 가능성이 높습니다. 에이전트가 올바른 결정을 내리는 데 필요한 맥락을 사용자가 충분히 제공하지 못하기 때문입니다.

실무적 의미

이 지점은 상당히 반직관적입니다. AI가 코드를 대신 작성해 주기 때문에 기본기가 덜 중요해지는 것이 아닙니다. 오히려 AI가 코드를 작성하기 때문에 기본기는 더욱 중요해집니다.

이제 소프트웨어 엔지니어링 기본기는 직접 코딩하기 위한 지식인 동시에, 코딩 에이전트를 정확하게 지휘하기 위한 언어가 됩니다. 사용자가 기술적 요구사항과 제약조건을 구체적인 언어로 전달할 수 있어야 에이전트도 합리적인 트레이드오프를 선택할 수 있습니다.

예를 들어 다음 두 요청은 같은 코딩 에이전트에 전달되더라도 전혀 다른 결과를 만들어냅니다.

“로그인 기능을 만들어줘.”

vs.

“세션은 서버 측에서 관리하고, 액세스 토큰의 만료 시간은 15분으로 설정해줘. 리프레시 토큰은 사용할 때마다 회전시키고, 인증이 다섯 차례 실패하면 지수 백오프를 적용해줘.”

차이를 만드는 것은 에이전트 자체가 아니라, 사용자가 요구사항을 소프트웨어 엔지니어링의 언어로 구체화할 수 있는지 여부입니다.

---

③ 코딩 에이전트 활용

Using Coding Agents

앤드류 응은 코딩 에이전트 활용 능력을 이제 모든 개발자가 갖춰야 할 핵심 역량으로 규정합니다.

이 역량은 단순히 특정 도구의 사용법이나 프롬프트 작성 요령을 익히는 것에 그치지 않습니다. 에이전트가 어떻게 작동하는지에 대한 적절한 멘탈 모델을 갖추고, 그 한계와 우회 방법을 이해하며, 언제 개입하고 언제 자율적으로 작업하도록 둘 것인지를 판단하는 능력을 의미합니다.

궁극적인 목표는 불필요한 시간과 토큰을 낭비하지 않으면서도 견고하고 신뢰할 수 있는 소프트웨어를 빠르게 만드는 것입니다.

앤드류 응이 제시한 세부 역량은 다음과 같습니다.

• 에이전트가 활용하는 컨텍스트를 효과적으로 관리하는 능력

• 계획 수립과 즉각적인 실행 사이의 트레이드오프를 판단하는 능력

• 검증기(verifiers)와 평가 체계(evals)를 제공해 에이전트가 스스로 피드백 루프를 완성하도록 만드는 능력

• 명확한 명세(spec)를 기반으로 작업하는 방법과, 상세한 명세가 불필요한 상황을 구분하는 능력

• 여러 에이전트를 목적에 맞게 조율하고 오케스트레이션하는 능력

• 에이전트가 프로덕션 데이터베이스를 훼손하는 것과 같은 중대한 사고를 방지하는 능력

여기에 한 가지 중요한 조건이 더해집니다. 에이전틱 코딩 기술은 매우 빠르게 진화하고 있습니다. 따라서 이 분야의 역량은 현재의 모범 사례를 알고 있는 것만으로 완성되지 않습니다. 새로운 도구를 지속적으로 실험하고, 모범 사례가 바뀔 때마다 자신의 업무 방식을 업데이트하는 학습 루틴까지 포함해야 합니다.

실무적 의미

특히 주목할 부분은 “명확한 명세가 굳이 필요하지 않은 상황을 판단하는 능력”까지 핵심 역량에 포함되어 있다는 점입니다.

이는 모든 업무를 더 엄격하고 복잡하게 관리하라는 의미가 아닙니다. 중요한 것은 언제 엄격한 명세와 검증이 필요하고, 언제 빠른 시도와 반복이 더 적절한지를 구분하는 것입니다. 다시 말해, 상황에 맞는 통제 수준을 선택하는 능력이 중요합니다.

또한 프로덕션 데이터베이스 훼손과 같은 사례가 구체적으로 언급되었다는 점도 의미가 있습니다. 이는 단순한 가상의 위험이 아니라, 에이전트를 실제 시스템에 연결하는 과정에서 이미 반복적으로 발생하고 있는 운영상의 사고 유형으로 이해할 필요가 있습니다.

---

④ 무엇을 만들지 구체화하기

Shaping the Build

네 번째 역량은 개발자의 역할을 가장 근본적으로 변화시키는 항목입니다.

앤드류 응의 관찰은 명확합니다. 요구사항과 명세가 충분히 구체적이라면, 코딩 에이전트는 이를 실제 시스템으로 구현하는 데 빠르게 능숙해지고 있습니다. 이에 따라 엔지니어의 역할은 주어진 명세를 구현하는 것에서, 명세에 무엇이 포함되어야 하는지를 결정하는 방향으로 이동하고 있습니다.

그는 엔지니어가 더 이상 픽셀 단위까지 완성된 디자인과 세부 요구사항을 전달받은 뒤 이를 그대로 구현하는 역할에 머물러서는 안 된다고 지적합니다.

효과적인 AI 엔지니어링을 위해서는 제품 감각(product sense)과 함께 비즈니스 맥락 및 고객 목표에 대한 이해가 필요합니다. 그래야 단순히 주어진 기능을 구현하는 것을 넘어, 무엇을 만들어야 하는지 정의하고 제품의 방향을 함께 형성할 수 있습니다.

AI는 엔지니어에게 과거보다 더 큰 주도권과 오너십을 가질 기회를 제공합니다. 스스로 의미 있는 문제와 기회를 발견하고, 이를 책임 있는 방식으로 실행에 옮길 수 있기 때문입니다.

다만 이러한 기회를 실제 성과로 연결하려면 프로젝트를 추진하는 방법까지 이해해야 합니다. 언제 최소기능제품(MVP)을 빠르게 만들어 사용자에게 제시하고 검증할 것인지, 반대로 언제 속도를 늦추고 충분한 검토와 통제를 거쳐 신중하게 개발해야 하는지를 판단할 수 있어야 합니다.

실무적 의미

이는 단순히 “개발자도 기획을 알아야 한다”는 일반적인 조언과는 차이가 있습니다. 보다 본질적인 변화는 구현이 더 이상 가장 큰 병목이 아니게 되면서, 병목의 위치가 기술적 실행에서 판단과 문제 정의로 이동하고 있다는 점입니다.

과거에는 빠르고 정확한 구현 능력이 중요한 차별점이었다면, 앞으로는 다음과 같은 역량의 가치가 더욱 커질 가능성이 높습니다.

• 해결할 가치가 있는 문제를 발견하는 능력

• 고객과 비즈니스의 요구를 구체적인 제품 명세로 전환하는 능력

• 무엇을 만들고 무엇을 만들지 않을지 결정하는 능력

• 빠른 실험과 신중한 구축이 필요한 시점을 구분하는 능력

구현 속도가 빠르게 평준화될수록, 무엇을 만들어야 하는지 판단하고 방향을 제시할 수 있는 사람이 더욱 희소해집니다.

---

5. 네 가지 역량을 관통하는 기반 — 지속적 학습

앤드류 응은 앞서 제시한 네 가지 역량의 기반에 ‘지속적 학습의 마인드셋(a mindset of continuous learning)’이 자리하고 있다고 설명합니다.

AI 기술과 개발 방식은 매우 빠르게 변화하고 있습니다. 현재의 모범 사례가 가까운 미래에도 그대로 유지된다고 장담하기 어렵습니다. 따라서 특정 도구나 기술을 한 번 배우는 것만으로는 충분하지 않습니다. 새로운 방법론을 지속적으로 받아들이고, 자신의 역량과 업무 방식을 함께 진화시켜야 합니다.

이번 서신은 완결된 결론이라기보다 새로운 논의의 출발점에 가깝습니다. 앤드류 응은 앞으로 이어질 서신에서 네 가지 역량을 하나씩 구체화하고, 보다 상세한 ‘AI Engineering Skills Map’을 공유하겠다고 예고합니다.

결국 그가 전달하는 핵심 메시지는 단순합니다.

AI 시대에 필요한 역량은 특정 모델이나 도구를 다루는 기술에만 있지 않습니다. AI 시스템을 신뢰할 수 있는 수준으로 구축하고 평가하는 능력, 소프트웨어 엔지니어링의 기본기, 코딩 에이전트를 효과적으로 통제하는 능력, 그리고 무엇을 만들어야 하는지 판단하는 능력이 함께 필요합니다.

그리고 이 모든 역량은 한 번의 학습으로 완성되지 않습니다. 지속적으로 배우고, 실험하고, 검증하며 자신의 방식을 갱신하는 사람만이 빠르게 변화하는 AI 환경에서 경쟁력을 유지할 수 있습니다.

앤드류 응은 이를 자신의 익숙한 문장으로 마무리합니다.

Keep building!

---

내게 부족한 부분은 무엇인가 ? (자가 진단해보기)

각 항목에 예/아니오로만 답하십시오. 애매하면 아니오입니다.

① AI 애플리케이션 구축·배포

• 내가 만든 AI 기능의 품질을 숫자로 말할 수 있다 (정확도·통과율 등)

• 프롬프트를 바꿨을 때 좋아졌는지 나빠졌는지 자동으로 판정할 수 있다

• 실패 사례를 모아 유형별로 분류해 본 적이 있다 (오류 분석)

• RAG 검색 품질과 최종 답변 품질을 분리해서 측정할 수 있다

② 소프트웨어 엔지니어링 기본기

• 내 시스템의 병목이 CPU인지 IO인지 네트워크인지 근거를 대고 말할 수 있다

• 지금 쓰는 DB를 왜 그것으로 골랐는지 대안과 비교해 설명할 수 있다

• 에이전트가 짜 준 코드에서 보안·성능 문제를 직접 발견한 적이 있다

③ 코딩 에이전트 활용

• 에이전트에게 줄 컨텍스트를 의도적으로 편집한다 (전부 넣지 않는다)

• 에이전트가 스스로 검증하도록 테스트나 검증기를 붙여 준다

• 언제 명세를 쓰고 언제 안 써도 되는지 내 기준이 있다

• 최근 3개월 안에 새 코딩 도구를 하나 이상 시도했다

④ 무엇을 만들지 구체화하기

• 지금 만드는 기능이 어떤 고객의 어떤 문제를 푸는지 한 문장으로 말할 수 있다

• "이건 만들지 말자"고 내가 먼저 제안해 본 적이 있다

• MVP로 빠르게 낼지 신중히 만들지 판단해 본 경험이 있다

판정 — 각 역량에서 '예'가 절반 미만인 항목이 당신의 다음 학습 대상입니다. 네 개 다 절반 미만이면 ②→①→③→④ 순서를 권합니다. 기본기가 나머지 셋의 조종 언어이기 때문입니다.

7. 복사해서 쓰는 프롬프트 2개

기본형 — 역량 갭 진단

너는 시니어 AI 엔지니어링 멘토다.

내 상황:
- 현재 역할: [예: 백엔드 개발자 5년차, Python/Django]
- 최근 6개월 한 일: [예: 사내 문서 검색 챗봇을 RAG로 구축, 사내 배포]
- 자가진단 결과: [위 6장 체크리스트에서 '아니오'였던 항목을 그대로 붙여넣기]
- 목표 시점: [예: 3개월 뒤 AI 기능 팀 리드 지원]

앤드류 응의 AI 엔지니어링 4대 역량(AI 애플리케이션 구축·배포 / 소프트웨어 엔지니어링
기본기 / 코딩 에이전트 활용 / 무엇을 만들지 구체화하기)을 기준으로 다음을 해줘:

1. 내 역량을 네 축으로 각각 1~5점으로 평가하고 점수의 근거를 내가 쓴 사실에서만 인용해라.
2. 가장 투자 대비 효과가 큰 축 하나를 고르고 왜 그것인지 나머지 셋과 비교해 설명해라.
3. 내가 놓치고 있을 가능성이 큰 맹점을 2개 지적해라.

추측이 필요한 부분은 "추측"이라고 표시하고, 내가 주지 않은 정보는 지어내지 마라.

변수 설명

• [현재 역할] — 연차와 주력 스택까지 적으십시오. "개발자"만 쓰면 일반론이 돌아옵니다.

• [최근 6개월 한 일] — 결과물 단위로 적으십시오. 실제 입력 예: "사내 규정 문서 1,200건을 pgvector로 색인해 Slack 봇으로 붙임, 사용자 40명, 평가 체계는 없음"

• [자가진단 결과] — 요약하지 말고 체크리스트 문장을 그대로 붙이십시오.

• [목표 시점] — 기한이 없으면 우선순위가 나오지 않습니다.

고급형 — 8주 학습 계획 수립

역할: 너는 학습 설계자다. 동기부여 대신 실행 가능한 계획만 내놓는다.

입력:
- 우선 공략 역량: [위 기본형 프롬프트의 2번 답변을 붙여넣기]
- 주당 가용 시간: [예: 평일 저녁 1시간 x 4일 = 4시간]
- 사용 가능한 실제 과제: [예: 사내 챗봇의 답변 품질 불만이 접수되고 있음]
- 제약: [예: 회사 데이터는 외부 API로 못 보냄]

제약조건:
- 8주 계획을 주 단위로 짜되, 각 주마다 (a)입력 자료 (b)내가 할 행동
  (c)그 주가 끝났을 때 존재해야 하는 산출물 세 가지를 반드시 적어라.
- 산출물은 "이해했다" 같은 상태가 아니라 파일·코드·문서처럼 확인 가능한 것이어야 한다.
- 강의 시청은 전체 시간의 30%를 넘지 마라. 나머지는 내 실제 과제에 적용하는 시간이다.
- 실패 판정 기준을 각 주마다 한 줄 적어라. 무엇이 안 되면 그 주가 실패인가.

출력 형식:
| 주차 | 입력 | 행동 | 산출물 | 실패 판정 |
표 아래에 "이 계획이 무너질 가능성이 가장 큰 지점" 3개를 적어라.

변수 설명

• [주당 가용 시간] — 정직하게 적으십시오. 실제 입력 예: "주 4시간, 단 격주로 0시간"

• [사용 가능한 실제 과제] — 이 칸이 계획의 성패를 가릅니다. 실제 업무 과제가 없으면 계획은 강의 목록이 됩니다.

• [제약] — 폐쇄망·비용 상한·보안 정책 등. 실제 입력 예: "사내망, 외부 LLM API 금지, 로컬 GPU 1장"

8. 프롬프트를 개선하는 요령 3가지

① 역할이 아니라 판정 기준을 줘라 (출력 형식 축)

나쁜 프롬프트내 AI 역량을 평가해줘.

개선 프롬프트아래 4개 축으로 각각 1~5점을 매기고, 각 점수마다 내가 쓴 사실 중 어느 문장을 근거로 삼았는지 인용해라. 근거로 삼을 문장이 없으면 "근거 부족"이라고 적어라.

차이는 "잘 해줘"가 아니라 채점표를 준 것입니다. 근거 인용을 강제하면 모델이 그럴듯한 총평을 지어내는 경로가 막힙니다.

② 지어내면 안 되는 것을 명시하라 (제약조건 축)

모델은 빈칸을 채우려 합니다. "내가 주지 않은 정보는 지어내지 말고, 추측이면 추측이라고 표시하라"는 한 줄이 경력 진단·계획 수립처럼 사실 기반이어야 하는 작업에서 특히 효과가 큽니다. 위 두 프롬프트에 모두 넣어 둔 이유입니다.

③ 산출물의 형태를 못 박아라 (목표 구체화 축)

"공부하겠다"는 검증이 안 되고 "파일이 존재한다"는 검증이 됩니다. 고급형 프롬프트에서 산출물을 파일·코드·문서처럼 확인 가능한 것으로 제한한 것이 그 장치입니다. 이건 응이 말한 검증기·평가를 붙여 에이전트가 스스로 루프를 닫게 한다는 원리를 학습 계획에 그대로 적용한 것이기도 합니다.

9. 흔한 실패 2가지

실패 1 — 네 역량을 동시에 시작한다

증상: 3주쯤 지나 강의 4개를 각각 20%씩 듣고 있고, 만든 것은 없습니다. 원인: 지도가 네 개를 보여주니 네 개가 다 급해 보입니다. 하지만 이 지도는 우선순위를 정하라고 만들어진 것이지 동시에 하라고 만들어진 게 아닙니다. 교정법: 자가진단에서 가장 낮은 축 하나만 8주 동안 잡으십시오. 나머지 셋은 그 하나를 하는 과정에서 자연히 조금씩 올라갑니다.

실패 2 — 평가(evals) 없이 프롬프트만 계속 고친다

증상: 프롬프트를 20번 고쳤는데 좋아졌는지 확신이 없고, 예전 버전이 더 나았던 것 같은데 되돌릴 수가 없습니다. 원인: 판정 기준이 사람 머릿속에만 있습니다. 응이 evals를 ①번 역량의 핵심 기술로 지목한 이유가 정확히 이 지점입니다. 교정법: 프롬프트를 고치기 전에 테스트 케이스 20개와 기대 답을 먼저 만드십시오. 20개면 충분합니다. 이것이 있으면 이후 모든 변경이 개선인지 퇴보인지 판정됩니다.

10. 결과 확인 체크리스트

이 글을 제대로 활용했다면 지금 다음이 존재해야 합니다.

• 6장 체크리스트에 실제로 표시한 결과가 남아 있다

• 네 축 중 다음 8주에 공략할 축 하나가 정해졌다

• 7장 프롬프트 중 최소 하나를 실행해 받은 답변이 저장되어 있다

• 8주 계획의 1주차 산출물이 무엇인지 한 문장으로 적혀 있다

• 그 산출물을 적용할 실제 업무 과제가 지정되어 있다

11. 다음 행동

오늘 하십시오 — 6장 체크리스트를 표시하고, 7장 기본형 프롬프트에 자기 상황을 넣어 한 번 돌리십시오. 15분이면 끝나고, 이 글에서 가져갈 수 있는 것의 대부분이 거기서 나옵니다.

이번 주에 하십시오 — 고급형 프롬프트로 8주 계획을 뽑고, 1주차 산출물 하나를 실제로 만드십시오. 계획만 있고 산출물이 없으면 2주차에 무너집니다.

원문도 직접 읽으십시오 — 이 글은 요약과 해설입니다. 앤드류 응의 문장과 뉘앙스는 원문에서 직접 읽으실 때 가장 정확합니다. 그는 이 서신을 시리즈의 시작이라고 밝혔으므로, 후속 편을 받아 보시려면 The Batch 를 구독하시는 편이 좋습니다.

---

출처

• Andrew Ng, "The AI Engineering Skills Map", The Batch, DeepLearning.AI, 2026-08-14. https://www.deeplearning.ai/the-batch/the-ai-engineering-skills-map

• 원문 P.S.에 안내된 기여 설문: typeform.com/to/YHqoolF9 (2026-09-04 확인)

저작권 안내 — 「The AI Engineering Skills Map」의 저작권은 Andrew Ng 및 DeepLearning.AI 에 있습니다. 이 글은 원문의 전문 번역이 아니라 소개·해설이며, 논지 전달에 필요한 최소한의 짧은 인용만 사용했습니다. 6장 이후의 자가진단·프롬프트· 학습 계획·실패 사례는 원문에 없는 이매진댓 AI Research 의 자체 작성분입니다.

면책 — 이 글은 학습·경력 판단을 위한 참고 자료이며, 특정 채용·투자·법률에 대한 자문이 아닙니다. 언급된 도구·설문 링크는 2026-09-04 기준이며 이후 변경될 수 있습니다.