Andrew Ng의 AI Engineering Skills Map 완벽 정리: AI 엔지니어에게 필요한 4대 역량과 실전 로드맵

AI 시대에 개발자는 무엇을 배워야 할까?

 

생성형 AI와 코딩 에이전트가 빠르게 발전하면서 소프트웨어를 만드는 방식이 크게 달라지고 있습니다. 이제는 개발자가 모든 코드를 직접 작성하지 않아도 됩니다. 자연어로 요구사항을 설명하면 코딩 에이전트가 코드를 만들고, 테스트를 실행하고, 오류를 수정하고, 때로는 배포와 운영까지 도와줍니다.

 

그러나 여기서 새로운 문제가 생깁니다.

 

코드를 직접 작성하는 시간이 줄어들수록 개발자의 실력은 무엇으로 평가될까요? 단순히 프롬프트를 잘 쓰는 능력만 있으면 충분할까요? AI가 만들어 준 결과를 그대로 사용하는 것과 실제 서비스로 운영 가능한 시스템을 만드는 것 사이에는 어떤 차이가 있을까요?

 

Andrew Ng과 DeepLearning.AI가 제시한 AI Engineering Skills Map은 이 질문에 대한 하나의 실용적인 답입니다. 이 지도는 특정 직함으로서의 ‘AI 엔지니어’만을 위한 목록이 아닙니다. 풀스택 개발자, 데이터 엔지니어, DevOps 엔지니어, 머신러닝 엔지니어, 제품을 만드는 창업자까지 AI를 활용해 소프트웨어를 만드는 모든 사람에게 필요한 역량을 정리한 프레임워크입니다.

 

이 글에서는 AI Engineering Skills Map의 전체 구조를 살펴보고, 네 가지 핵심 역량과 그 아래의 세부 기술을 하나씩 설명하겠습니다. 마지막에는 이 지도를 실제 학습 순서와 프로젝트에 어떻게 적용할지도 정리하겠습니다.

 

AI Engineering Skills Map은 어떻게 만들어졌을까?

 

Andrew Ng의 설명에 따르면 이 지도는 1만 건이 넘는 채용 공고 분석, AI 전문가와 채용 담당자 및 리크루터를 대상으로 한 구조화된 인터뷰, 설문조사와 기타 온라인 데이터의 종합을 바탕으로 만들어졌습니다.

 

여기서 중요한 점은 ‘AI 엔지니어’라는 직함의 업무만 분석한 것이 아니라는 사실입니다. AI Engineering Skills는 하나의 직업명보다 넓은 개념입니다. 앞으로는 개발자의 직함이 무엇이든 클라우드, 데이터, AI 모델, 코딩 에이전트, 제품 의사결정과 연결된 역량이 필요하다는 관점입니다.

 

원문 시리즈의 제목은 Part 1부터 Part 5까지 이어지지만, 최상위 구조는 네 가지입니다.

 

첫째, AI 애플리케이션을 구축하고 배포하는 능력

둘째, 소프트웨어 엔지니어링 기본기

셋째, 코딩 에이전트를 효과적으로 사용하는 능력

넷째, 무엇을 만들지 결정하고 빌드를 주도하는 능력

 

이 네 가지는 따로 떨어져 있지 않습니다. AI 애플리케이션을 만들려면 소프트웨어 기본기가 필요하고, 코딩 에이전트를 활용하려면 시스템 구조를 이해해야 하며, 어떤 제품을 만들지 결정하려면 사용자와 비즈니스에 대한 이해가 필요합니다.

 

1. AI 애플리케이션 구축과 배포

 

AI 애플리케이션은 전통적인 소프트웨어와 중요한 차이가 있습니다. 전통적인 프로그램은 같은 입력에 대체로 예측 가능한 결과를 냅니다. 반면 LLM이나 머신러닝 모델은 같은 시스템 안에서도 출력이 달라질 수 있고, 새로운 입력에 어떤 결과를 낼지 미리 완벽하게 알기 어렵습니다.

 

따라서 AI 엔지니어는 단순히 모델을 호출하는 데 그치지 않고, 불확실한 AI 구성요소를 포함한 시스템을 측정하고 조정하고 운영해야 합니다. Andrew Ng은 이 역량을 여섯 가지 세부 영역으로 나눕니다.

 

1-1. LLM 기초

 

LLM 기초는 모델의 이름을 많이 아는 것이 아닙니다. 모델이 입력을 어떻게 토큰화하고, 컨텍스트를 어떻게 처리하며, 다음 토큰을 어떤 방식으로 생성하는지 이해하는 능력입니다.

 

이 기초가 있으면 다음과 같은 결정을 더 잘할 수 있습니다.

 

어떤 작업에 텍스트 모델과 멀티모달 모델 중 무엇을 사용할 것인가?

컨텍스트 윈도우에 무엇을 넣고 무엇을 제외할 것인가?

모델의 지식 기준일과 최신 데이터의 차이를 어떻게 보완할 것인가?

샘플링 파라미터와 추론 노력 수준을 어떻게 조정할 것인가?

툴 호출이 필요한가, 단순한 텍스트 생성으로 충분한가?

캐시를 활용해 비용과 지연 시간을 줄일 수 있는가?

파인튜닝이나 자체 호스팅이 필요한가?

 

LLM을 잘 활용하는 개발자는 프롬프트만 바꾸지 않습니다. 모델 선택, 입력 구성, 출력 형식, 툴 사용, 비용과 지연 시간 사이의 관계를 함께 판단합니다.

 

1-2. 데이터로 모델을 그라운딩하기

 

LLM은 학습 데이터만으로 답하게 두면 현재 조직의 문서, 고객 정보, 최신 정책을 알 수 없습니다. 그래서 모델이 적절한 데이터를 참고하도록 만드는 그라운딩이 필요합니다.

 

초기에는 벡터 검색 기반 RAG가 대표적인 방법이었지만, 실제 시스템에서는 더 다양한 선택지가 있습니다.

 

문서 내용을 벡터 인덱스에 저장할 것인가?

관계가 중요한 데이터에는 지식 그래프를 사용할 것인가?

고객 기록이나 재무 데이터에는 구조화된 데이터의 시맨틱 레이어를 사용할 것인가?

정보를 프롬프트에 넣을 것인가, 모델이 툴을 통해 필요할 때 가져오게 할 것인가?

PDF, HTML, 이미지, 표를 어떻게 LLM이 처리할 수 있는 형태로 바꿀 것인가?

데이터가 오래되거나 중복되거나 잘못된 상태로 들어가지 않게 하려면 어떻게 할 것인가?

 

RAG를 붙였다는 사실 자체가 좋은 AI 시스템을 의미하지는 않습니다. 검색 품질이 낮거나 청킹이 잘못되거나 데이터가 오래되면 모델은 더 그럴듯하게 틀릴 수 있습니다. 따라서 데이터의 수집, 정제, 변환, 검색, 갱신까지 전체 파이프라인을 설계해야 합니다.

 

1-3. 에이전트 시스템 구축

 

에이전트 시스템은 하나의 프롬프트를 실행하는 챗봇보다 복잡합니다. 미리 정해진 순서로 여러 LLM 호출을 연결하는 워크플로부터, 모델이 다음 행동을 스스로 결정하는 에이전트 하네스까지 다양한 형태가 있습니다.

 

AI 엔지니어는 다음을 결정해야 합니다.

 

어떤 작업은 순차적으로 실행하고 어떤 작업은 병렬화할 것인가?

어떤 단계는 일반 코드로 처리하고 어떤 단계는 LLM에 맡길 것인가?

모델이 호출할 수 있는 도구는 무엇인가?

MCP, CLI, 샌드박스 실행 환경을 허용할 것인가?

에이전트의 메모리와 장기 컨텍스트를 어떻게 관리할 것인가?

단일 에이전트로 충분한가, 여러 에이전트의 협업이 필요한가?

오류가 발생했을 때 어떤 폴백을 사용할 것인가?

프롬프트 인젝션, 데이터 유출, 권한 오남용을 어떻게 막을 것인가?

 

프로토타입에서 작동하는 에이전트를 만드는 것과 실제 고객 데이터를 다루는 안전한 에이전트를 운영하는 것은 완전히 다른 문제입니다. 운영 단계에서는 권한 제한, 가드레일, 적대적 입력 테스트, 로그 추적, 데이터 거버넌스가 필요합니다.

 

1-4. 평가 주도 개발

 

AI 시스템을 잘 만드는 사람과 그렇지 못한 사람의 차이는 평가와 오류 분석 루프를 운영할 수 있는지에서 나타납니다.

 

전통적인 프로그램은 테스트 케이스가 비교적 명확한 경우가 많지만, AI 애플리케이션은 ‘좋은 답변’의 기준이 복합적입니다. 그래서 먼저 무엇을 측정할지 정의하고, 실제 입력과 실패 사례를 모으고, 평가셋을 만들고, 개선 전후를 비교해야 합니다.

 

평가 방법에는 여러 선택지가 있습니다.

 

정확한 정답이 있는 작업에는 코드 기반의 결정론적 평가

답변의 품질이나 자연스러움을 보는 작업에는 LLM-as-a-judge

위험하거나 중요한 결과에는 사람의 검토

트레이스와 로그를 분석하는 탐색적 데이터 분석

사용자 행동과 비즈니스 지표를 함께 보는 제품 평가

 

중요한 것은 평가 점수 자체가 아니라 평가 결과를 다음 개발의 방향으로 연결하는 것입니다. 무엇이 실패했는지, 실패가 데이터 문제인지 프롬프트 문제인지 모델 문제인지, 또는 제품 설계의 문제인지 구분해야 합니다.

 

1-5. 프로덕션 운영

 

AI 애플리케이션은 운영 환경에서 비용, 지연 시간, 출력 품질, 보안 위험이 동시에 발생합니다. 그래서 개발이 끝났다고 해서 프로젝트가 끝나는 것이 아닙니다.

 

프로덕션 운영에는 다음과 같은 역량이 포함됩니다.

 

실제 사용자 입력과 모델 출력을 관찰하는 시스템

성능 저하와 데이터 드리프트를 감지하는 방법

모델 실패와 프롬프트 인젝션에 대응하는 절차

통계적 평가를 포함한 회귀 테스트

CI/CD와 배포 게이트

모델 선택과 라우팅

증류와 파인튜닝

에이전트 워크플로 단순화를 통한 비용 및 지연 시간 최적화

 

AI 시스템의 운영은 전통적인 서비스 운영보다 더 많은 불확실성을 다뤄야 합니다. 따라서 로그를 남기는 것뿐 아니라 출력 품질을 지속적으로 측정해야 합니다.

 

1-6. 머신러닝 기초

 

LLM을 사용하는 개발자에게도 머신러닝과 딥러닝의 기본기는 필요합니다. 모든 사람이 모델을 직접 학습시켜야 한다는 뜻은 아닙니다. 어떤 문제에 어떤 모델을 적용할 수 있는지, 학습과 추론의 비용은 무엇인지, 데이터의 품질이 결과에 어떤 영향을 주는지 이해해야 한다는 뜻입니다.

 

머신러닝 기초에서 중요한 개념은 다음과 같습니다.

 

지도학습과 강화학습

대표적인 머신러닝과 딥러닝 모델의 특성

정확도와 학습 속도, 추론 속도 사이의 트레이드오프

편향과 분산

오류 분석

학습 데이터와 평가 데이터의 분리

데이터 라벨링과 데이터 품질

 

특히 편향과 분산, 오류 분석, 데이터 엔지니어링은 AI 시스템의 불확실성을 다루는 공통된 사고방식입니다.

 

2. 소프트웨어 엔지니어링 기본기

 

AI 모델이 서비스의 중심에 있더라도, 사용자가 만나는 것은 결국 소프트웨어 애플리케이션입니다. 에이전트가 코드를 대신 작성해 주더라도 어떤 구조가 좋은지, 어떤 트레이드오프가 있는지 모르면 시스템은 빠르게 부채를 쌓게 됩니다.

 

Andrew Ng이 강조하는 소프트웨어 기본기는 다섯 가지입니다.

 

2-1. 풀스택 애플리케이션 구축

 

AI 코딩 도구가 발전하면서 특정 영역만 담당하던 개발자도 점점 더 넓은 범위의 애플리케이션을 만들 수 있게 되었습니다. 그러나 에이전트가 코드를 작성한다고 해서 풀스택 구조를 이해할 필요가 없어지는 것은 아닙니다.

 

다음 개념을 이해해야 합니다.

 

프론트엔드 UI 컴포넌트

백엔드와 API 설계

페이지 렌더링과 캐싱

인증과 권한

상태와 세션 관리

비동기 처리

데이터 영속성

테스트

보안

접근성

 

코딩 에이전트는 익숙하지 않은 영역의 초안을 만들어 줄 수 있지만, 그 결과가 애플리케이션 전체 구조에 어떤 영향을 주는지는 사람이 판단해야 합니다.

 

2-2. 데이터 관리

 

데이터는 애플리케이션의 토대이며 나중에 바꾸기 어려운 자산입니다. 좋은 데이터 관리 능력은 무엇을 저장할지, 얼마나 오래 보관할지, 누가 접근할 수 있는지, 어떤 패턴으로 조회할지를 판단하는 능력입니다.

 

관계형 테이블, 문서형 데이터베이스, 키-값 저장소, 그래프 데이터베이스 중 무엇이 적절한지 선택하고, 트랜잭션과 동시성, 데이터 정합성과 최신성을 고려해야 합니다. 개인정보 보호, 거버넌스, 규제 준수도 포함됩니다.

 

특히 AI 애플리케이션에서는 데이터 구조가 곧 모델의 컨텍스트가 됩니다. 데이터 아키텍처가 잘못 설계되면 에이전트와 LLM은 자신이 무엇을 모르는지도 알 수 없습니다.

 

2-3. 시스템 아키텍처 설계

 

시스템 아키텍처는 기술 스택을 고르는 문제가 아니라 제품의 요구사항과 기술적 선택을 연결하는 문제입니다.

 

사용자는 몇 명인가?

허용 가능한 지연 시간은 얼마인가?

비용과 가용성 중 무엇이 더 중요한가?

모놀리스로 시작할 것인가, 마이크로서비스로 나눌 것인가?

프론트엔드와 백엔드의 경계는 어디에 둘 것인가?

상태는 어디에 저장할 것인가?

어떤 프로그래밍 언어와 런타임, 데이터 기술을 선택할 것인가?

 

빠른 프로토타입에 적합한 구조와 실제 운영 서비스에 적합한 구조는 다를 수 있습니다. 프로젝트가 성장하면서 아키텍처를 다시 설계하거나 데이터 저장 방식을 바꿔야 할 수도 있습니다.

 

2-4. 보안성과 신뢰성

 

AI를 활용하는 서비스는 보안과 신뢰성을 나중에 추가하는 방식으로 만들기 어렵습니다. 테스트 전략, 장애 처리, 권한 설계, 의존성 관리, 비밀정보 보호가 초기부터 필요합니다.

 

단위 테스트와 통합 테스트를 어떤 비율로 적용할지, 외부 API의 장애나 속도 제한을 어떻게 처리할지, 일부 기능이 실패해도 전체 서비스가 무너지지 않도록 어떻게 설계할지 고민해야 합니다.

 

보안도 개발이 끝난 뒤 점검하는 항목이 아니라 설계 단계부터 고려해야 합니다. AI 도구를 이용해 취약점과 의존성 문제를 찾을 수 있지만, 어떤 위험이 중요한지 판단하려면 기본적인 보안 지식이 필요합니다.

 

2-5. 프로덕션 확장과 운영

 

실제 사용자를 받으려면 배포 환경, 릴리스 전략, CI/CD, 클라우드 인프라를 알아야 합니다. 운영 단계에서는 관측 가능성, 알림, 장애 대응, 로그 분석도 필요합니다.

 

트래픽이 늘어나면 서버 확장, 로드밸런싱, 인덱싱, 복제, 샤딩과 같은 선택을 해야 할 수 있습니다. 버전 관리, 코드 리뷰, 의존성 업데이트, 기술 부채 관리 역시 장기적으로 중요합니다.

 

코딩 에이전트는 이런 작업도 도와줄 수 있지만, 시스템의 위험과 현재 단계에 맞는 운영 전략을 결정하는 일은 여전히 엔지니어의 책임입니다.

 

3. 코딩 에이전트를 효과적으로 사용하는 능력

 

코딩 에이전트를 잘 쓴다는 것은 “코드를 만들어 줘”라고 말하는 능력이 아닙니다. 계획, 실행, 검증, 배포, 모니터링의 전체 흐름에서 에이전트의 자율성과 인간의 판단을 적절히 조정하는 능력입니다.

 

Andrew Ng은 코딩 에이전트 활용을 크게 세 단계의 업무 흐름으로 설명합니다.

 

계획: 브레인스토밍, 조사, 코드베이스 이해, 요구사항과 기술 설계, 실행 계획 작성

실행: 코드 작성, 테스트, 검증, 인간의 감독 수준 조정

배포와 모니터링: 배포, 로그 관찰, 문제 발견, 개선과 재배포

 

이 흐름은 한 번으로 끝나지 않습니다. 검증에서 문제가 발견되면 실행 단계로 돌아가고, 운영 중 문제가 나타나면 계획과 설계를 다시 수정해야 합니다.

 

3-1. 워크플로를 지휘하기

 

프로젝트의 각 단계에서 사람과 에이전트가 얼마나 노력해야 하는지 결정해야 합니다. 빠른 프로토타입에서는 긴 문서보다 간단한 프롬프트가 적합할 수 있지만, 이미 많은 사용자가 있는 시스템에서는 상세한 명세와 보안 검토가 필요합니다.

 

속도, 비용, 기술적 위험, 인간의 주의력 사이에서 균형을 잡는 것이 핵심입니다. 어떤 작업은 에이전트에게 맡기고, 어떤 작업은 사람이 직접 소유할지 결정해야 합니다.

 

3-2. 에이전트 자율성 설계

 

에이전트에게 어느 정도의 자율성을 줄지도 중요한 기술입니다. 대화형으로 한 단계씩 확인할 것인지, 큰 작업을 위임할 것인지, 목표를 주고 성공할 때까지 반복하도록 할 것인지 판단해야 합니다.

 

컨텍스트 관리도 중요합니다. 프로젝트가 진행되면서 바뀐 가정과 사용자 피드백, 중요한 설계 결정을 에이전트가 다음 작업에서 활용할 수 있도록 기록해야 합니다.

 

여러 에이전트를 병렬로 실행할 때는 작업 분해와 결과 통합, 사람의 주의력 배분, 권한 설정과 안전장치가 필요합니다. 자율성이 높을수록 권한을 무제한으로 주는 것이 아니라 데이터 유출과 파일 손상, 운영 환경 오작동을 막는 게이트를 설계해야 합니다.

 

3-3. 결과를 검토하고 검증하기

 

코딩 에이전트의 결과는 본질적으로 불확실합니다. 좋은 아이디어를 낼 수도 있지만 버그나 과도한 설계, 보안 취약점을 함께 만들 수도 있습니다.

 

따라서 행동 검증과 기능 검증을 설계해야 합니다. 사용자의 실제 흐름을 테스트하고, 스크린샷이나 로그로 성공 여부를 확인하고, 필요하면 LLM 평가나 사람의 검토를 함께 사용합니다.

 

모든 검증을 자동화할 수 있는 것은 아닙니다. 어떤 영역에서는 자동화된 테스트가 충분하지만, 제품 경험이나 위험한 의사결정처럼 사람의 판단이 필요한 영역도 있습니다.

 

3-4. 에이전트와 작업 환경을 커스터마이징하기

 

에이전트가 효율적으로 작업하려면 코드베이스와 도구, 규칙, 반복 작업을 잘 정리해야 합니다.

 

프로젝트의 아키텍처와 코딩 규칙, 데이터 접근 방식, 중요한 가정을 AGENTS.md나 CLAUDE.md 같은 문서에 기록할 수 있습니다. 반복적인 코드 리뷰나 CI/CD를 훅으로 자동화할 수도 있고, MCP 서버와 플러그인, 도구를 연결해 에이전트가 필요한 정보를 얻도록 만들 수 있습니다.

 

여러 세션과 여러 에이전트가 작업할 때는 상태를 보존하고, 에이전트가 만든 학습과 부채를 정리하는 회고 과정도 필요합니다.

 

3-5. 코딩 에이전트의 작동 원리 이해하기

 

마지막으로 에이전트를 블랙박스로 사용하지 않으려면 기본 구조를 이해해야 합니다. 코드베이스 검색과 검색 결과의 활용, 컨텍스트 윈도우, 툴 호출, MCP, 서브에이전트, 에이전트 하네스가 어떤 역할을 하는지 알아야 합니다.

 

이런 이해가 있으면 에이전트가 왜 과도하게 복잡한 구조를 만들었는지, 왜 목표를 끝까지 달성하지 못했는지, 왜 검증 과정이 빠졌는지 분석할 수 있습니다. 긴 시간 동안 자율 실행시키는 것보다, 적절한 시점에 개입해 방향을 수정하는 것이 더 효과적인 경우가 많다는 점도 판단할 수 있습니다.

 

4. 빌드 자체를 주도하는 능력

 

네 번째 역량인 Shaping the Build는 이 Skills Map에서 가장 중요한 변화의 방향을 보여 줍니다.

 

과거에는 제품 관리자와 디자이너가 무엇을 만들지 정하고, 개발자는 명세를 구현하는 역할을 맡는 경우가 많았습니다. 하지만 AI 도구가 구현 속도를 크게 높이면서 개발자의 역할은 단순한 구현을 넘어 무엇을 만들지 결정하는 방향으로 확장됩니다.

 

Andrew Ng은 이 역량을 네 가지로 나눕니다.

 

4-1. 빌드 루프를 주도하기

 

소프트웨어는 코드를 작성하고, 피드백을 받고, 다음 행동을 결정하는 반복 루프로 만들어집니다. AI 엔지니어는 이 루프를 빠르고 올바르게 돌리는 사람입니다.

 

기술적 가능성을 확인하기 위한 짧은 실험을 할 것인가?

사용자에게 보여 줄 MVP를 만들 것인가?

기능을 추가할 것인가?

사용자 인터뷰나 A/B 테스트를 먼저 할 것인가?

더 신중하게 설계해야 하는 시점인가?

 

프로젝트의 단계, 제품 비전, 위험, 예산과 노력의 크기를 고려해 다음 행동을 결정해야 합니다. 성숙한 제품에서는 핵심 지표를 정의하고 그 지표를 개선하는 방향으로 프로젝트를 운영합니다.

 

4-2. 제품 의사결정하기

 

개발자가 제품 관리자가 되어야 한다는 뜻은 아닙니다. 다만 제품 명세가 다루지 않은 문제에 대해 판단할 수 있어야 한다는 뜻입니다.

 

사용자의 실제 필요를 파악하고, 기능의 우선순위를 정하고, 기본적인 디자인 감각으로 사용하기 편한 결과를 만들며, 시장 규모와 수익 구조를 고려해야 합니다.

 

제품 감각은 사용자 공감에서 출발합니다. 소수의 사용자와 대화하고, 설문조사를 진행하고, A/B 테스트를 하고, 사용자 행동 데이터를 분석하면서 사용자를 더 잘 이해해야 합니다.

 

4-3. 소통하고 리드하기

 

AI Engineering은 개발 조직 안에만 머물지 않습니다. 개발자가 마케팅, 재무, 법무, 영업과 대화하고 프로젝트를 앞으로 움직이는 일이 더 중요해집니다.

 

기술적으로 무엇이 가능한지, 어떤 위험이 있는지, 어떤 일정과 비용이 현실적인지 비개발자에게 설명할 수 있어야 합니다. 반대로 사용자의 문제와 비즈니스 목표를 기술적 요구사항으로 바꾸는 능력도 필요합니다.

 

AI에 익숙하지 않은 조직에서는 AI 엔지니어가 기술을 설명하고 새로운 가능성을 보여 주는 역할을 맡을 수도 있습니다.

 

4-4. 높은 주도권과 오너십

 

High-agency ownership은 누군가가 완벽한 지시를 내려 주기를 기다리지 않고, 문제와 기회를 발견해 끝까지 책임지는 태도입니다.

 

좋은 AI 엔지니어는 다음과 같이 행동합니다.

 

조직이나 고객의 문제를 스스로 발견한다.

가능한 해결책을 제안한다.

작게 실험해 가치를 증명한다.

우선순위를 정하고 실행한다.

문제가 생기면 책임을 회피하지 않는다.

실패와 피드백을 반영해 다시 시도한다.

작업 완료가 아니라 실제로 만든 가치로 성과를 판단한다.

 

AI가 개발자의 실행력을 높인 만큼, 이제는 스스로 올바른 문제를 찾고 끝까지 추진하는 능력이 더 중요해졌습니다.

 

네 가지 역량은 어떻게 연결되는가?

 

AI Engineering Skills Map을 단순한 체크리스트로 보면 안 됩니다. 각각의 역량은 다음과 같이 연결됩니다.

 

AI 애플리케이션 역량은 모델과 데이터를 활용해 기능을 만듭니다.

소프트웨어 기본기는 그 기능을 안정적인 시스템으로 만듭니다.

코딩 에이전트 활용 능력은 계획과 구현, 테스트의 속도를 높입니다.

빌드를 주도하는 능력은 어떤 문제를 어떤 순서로 해결할지 결정합니다.

 

예를 들어 고객센터용 사내 지식 검색 에이전트를 만든다고 해 보겠습니다.

 

먼저 LLM과 RAG, 평가 방법을 이해해야 합니다. 이것이 AI 애플리케이션 역량입니다. 문서 저장과 권한, 인증, API, 로그, 배포 환경을 설계해야 합니다. 이것이 소프트웨어 기본기입니다.

 

그다음 코딩 에이전트에게 코드베이스를 조사시키고, 구현 계획을 세우고, 테스트와 검증을 반복하게 해야 합니다. 이것이 코딩 에이전트 활용 능력입니다. 마지막으로 고객센터 직원이 실제로 어떤 답변을 원하는지, MVP로 무엇을 먼저 검증할지, 개인정보 위험을 어디까지 허용할지 결정해야 합니다. 이것이 빌드를 주도하는 능력입니다.

 

AI Engineering Skills를 배우는 현실적인 순서

 

1단계. 작은 애플리케이션을 직접 배포하기

 

LLM API를 활용한 간단한 웹 애플리케이션을 만들고 실제 사용자가 접근할 수 있게 배포해 보세요. 모델 호출만 해 보는 것과 인증, 데이터 저장, 오류 처리, 비용 관리까지 해 보는 것은 큰 차이가 있습니다.

 

2단계. 평가셋과 오류 분석 루프 만들기

 

좋은 답변과 나쁜 답변의 기준을 정하고, 실제 입력을 모아 평가셋을 만드세요. 프롬프트를 바꿀 때마다 무엇이 좋아지고 무엇이 나빠지는지 기록하세요.

 

3단계. RAG와 데이터 파이프라인 구축하기

 

문서 수집, 정제, 청킹, 임베딩, 검색, 답변 생성, 출처 표시까지 하나의 흐름으로 만들어 보세요. 데이터가 바뀌었을 때 어떻게 갱신되는지도 구현해 보는 것이 좋습니다.

 

4단계. 코딩 에이전트로 계획부터 운영까지 진행하기

 

에이전트에게 코드를 만들어 달라고만 하지 말고, 요구사항을 정리하고, 설계와 실행 계획을 만들고, 테스트하고, 검증하고, 배포와 모니터링까지 진행해 보세요.

 

5단계. 제품 문제를 직접 선택하기

 

누군가가 정해 준 기능을 구현하는 것에서 벗어나 실제 사용자의 문제를 직접 찾고, 작은 MVP를 만들어 피드백을 받아 보세요. 이 과정에서 제품 감각과 주도권이 함께 자랍니다.

 

Vibe Coding과 AI Engineering의 차이

 

Vibe Coding은 빠르게 무언가를 만들어 보는 훌륭한 출발점이 될 수 있습니다. 그러나 만들어진 코드가 곧 좋은 소프트웨어는 아닙니다.

 

AI Engineering은 다음 질문을 포함합니다.

 

이 기능이 실제 사용자의 문제를 해결하는가?

이 시스템은 비용과 지연 시간 측면에서 운영 가능한가?

데이터 접근과 개인정보 보호는 안전한가?

실패했을 때 서비스가 어떻게 동작하는가?

출력 품질을 어떻게 측정할 것인가?

에이전트가 만든 결과를 어떻게 검증할 것인가?

이 제품의 다음 개발 우선순위는 무엇인가?

 

결국 Vibe Coding은 실행 속도를 높이는 방법이고, AI Engineering은 불확실한 AI와 소프트웨어를 제품 가치로 바꾸는 종합 역량입니다.

 

마무리: AI 엔지니어의 핵심은 코드 생성이 아니라 판단이다

 

Andrew Ng의 AI Engineering Skills Map은 AI 시대에 개발자가 무엇을 배워야 하는지를 비교적 균형 있게 보여 줍니다.

 

AI 애플리케이션을 만들 줄 알아야 하지만, 모델 호출만 알아서는 부족합니다. 소프트웨어 기본기가 필요하지만, 전통적인 코딩 문법만 암기해서는 부족합니다. 코딩 에이전트를 활용해야 하지만, 에이전트에게 모든 판단을 맡겨서는 안 됩니다. 제품을 만들어야 하지만, 단순히 주어진 명세를 구현하는 데 머물러서는 안 됩니다.

 

앞으로 강한 AI 엔지니어는 다음 네 가지를 연결하는 사람일 가능성이 높습니다.

 

불확실한 AI 시스템을 설계하고 평가하는 능력

안정적이고 안전한 소프트웨어를 만드는 능력

코딩 에이전트의 자율성과 한계를 조정하는 능력

사용자와 비즈니스에 필요한 것을 스스로 발견하고 추진하는 능력

 

AI가 코드를 더 많이 작성할수록 사람의 역할이 사라지는 것이 아니라, 사람의 역할이 더 높은 수준의 판단으로 이동합니다. 무엇을 만들지 결정하고, 어떤 위험을 감수할지 선택하고, 실제 사용자에게 어떤 가치를 전달할지 책임지는 일은 여전히 사람의 몫입니다.

 

AI Engineering Skills Map은 단순한 공부 목록이 아닙니다. AI 시대에 소프트웨어를 만드는 사람이 기술, 제품, 운영, 리더십을 어떻게 연결해야 하는지 보여 주는 실전 지도입니다.

 

참고 자료

 

1. Andrew Ng and DeepLearning.AI, The AI Engineering Skills Map Part 1

https://charonhub.deeplearning.ai/the-ai-engineering-skills-map/

 

2. Part 2, Building and Deploying AI Applications

https://charonhub.deeplearning.ai/he-ai-engineering-skills-map-in-detail-building-and-deploying-ai-applications/

 

3. Part 3, Software Engineering Fundamentals

https://charonhub.deeplearning.ai/the-ai-engineering-skills-map-in-detail-software-engineering-fundamentals/

 

4. Part 4, Using Coding Agents

https://charonhub.deeplearning.ai/the-ai-engineering-skills-map-in-detail-using-coding-agents/

 

5. Part 5, Shaping the Build

https://charonhub.deeplearning.ai/the-ai-engineering-skills-map-in-detail-shaping-the-build/

 

6. Andrew Ng 공식 글 목록

https://www.andrewng.org/writing/