AI 애플리케이션을 구축하고 배포하는 여섯 가지 핵심 역량

AI 엔지니어링을 잘한다는 것은 정확히 무엇을 뜻할까요. 프롬프트를 잘 쓰는 것, 최신 모델 API를 빨리 붙이는 것, 에이전트 프레임워크를 능숙하게 다루는 것만으로는 충분하지 않습니다. 모델이 놀라운 데모를 한 번 만드는 일과, 그 모델을 실제 사용자가 반복해서 믿고 쓸 수 있는 제품으로 만드는 일 사이에는 넓은 공학의 영역이 있습니다.

Andrew Ng는 최근 공개한 AI Engineering Skills Map에서 AI 엔지니어링의 최상위 역량을 네 가지로 정리했습니다.

1. AI 애플리케이션 구축과 배포
2. 소프트웨어 엔지니어링 기초
3. 코딩 에이전트 활용
4. 무엇을 만들지 구체화하는 능력, Shaping the build

Ng의 설명에 따르면 이 지도는 1만 건 이상의 채용공고, AI 전문가와 채용 담당자를 대상으로 한 구조화 인터뷰, 설문 응답과 온라인 자료를 분석해 만들었습니다. 이번에 공개한 후속 글은 그중 첫 번째인 AI 애플리케이션을 구축하고 배포하는 능력을 다시 여섯 가지로 나눕니다. LLM 기초, 데이터 그라운딩, 에이전트 시스템, 평가 주도 개발, 프로덕션 운영, 머신러닝 기초입니다.

이 분류는 현재 AI 제품을 만드는 사람에게 꽤 좋은 지도를 제공합니다. 다만 여섯 항목을 별도의 공부 목록으로 읽으면 핵심을 놓치기 쉽습니다. 실제 현장에서는 모델, 데이터, 에이전트, 평가, 운영이 서로의 입력과 제약이 됩니다. 이들을 하나로 묶는 문장은 다음과 같습니다.

AI 엔지니어링은 확률적으로 움직이는 부품을 측정하고 통제해, 반복해서 쓸 수 있는 소프트웨어 시스템으로 만드는 공학입니다.

전체 지도부터 다시 그려보기

Ng의 전체 지도에는 중요한 균형이 있습니다. AI 제품 역량만으로 AI 엔지니어링을 정의하지 않았다는 점입니다. 모델을 이해하고 배포하는 능력 옆에 전통적인 소프트웨어 공학, 코딩 에이전트 활용, 문제와 제품을 구체화하는 능력을 같은 높이에 놓았습니다. 좋은 모델을 고르는 것만큼 요구사항, 인터페이스, 테스트, 보안, 유지보수, 사용자 관찰이 중요하다는 뜻입니다.

이 지도를 이력서의 키워드 목록으로 쓰는 것은 쉽습니다. 더 유용한 방법은 각 역량을 검증 가능한 산출물로 바꾸는 것입니다. "RAG를 안다"보다 검색 실패를 분류한 평가셋과 데이터 최신성 목표를 보여주는 사람이 강합니다. "에이전트를 만들었다"보다 상태 전이, 도구 권한, 중단 조건과 실패 복구 방식을 설명할 수 있는 사람이 강합니다.

AI 소프트웨어의 차이는 의미적 불확실성입니다

전통적인 소프트웨어도 완전히 예측 가능하지는 않습니다. 네트워크는 끊기고, 사용자는 예상하지 못한 입력을 넣고, 분산 시스템은 타이밍에 따라 다른 상태를 만듭니다. 다만 같은 입력과 상태에서 같은 코드 경로가 실행되면 결과를 비교적 명확한 규칙으로 판정할 수 있습니다.

AI 소프트웨어에는 다른 종류의 불확실성이 더해집니다. 답변이 문법적으로 자연스럽고 형식 검사를 통과해도 사실과 다를 수 있습니다. 같은 뜻을 여러 표현으로 말할 수 있어 정확한 문자열 비교가 어렵습니다. 정답이 하나가 아니거나, 품질이 사용자의 맥락과 업무 결과에 달린 경우도 많습니다. 모델, 프롬프트, 검색 결과, 도구 상태 중 하나만 바뀌어도 전체 행동이 달라집니다.

그래서 개발 과정도 달라집니다.

• 전통 소프트웨어의 대표 루프: 명세 → 구현 → 단위 테스트 → 배포
• AI 애플리케이션의 대표 루프: 과제 정의 → 작은 구현 → 출력 관찰 → 오류 분류 → 평가셋 갱신 → 모델·데이터·흐름 수정 → 다시 측정

두 번째 루프에서는 중간 결과가 다음 행동을 결정합니다. 처음부터 완벽한 설계도를 그리기보다 작은 수직 단면을 만들고, 실제 오류가 어디서 생기는지 본 뒤 다음 실험을 고릅니다. 이것이 Ng가 말한 AI 개발의 반복성이며, 숙련된 엔지니어의 차이는 모델에 아는 것이 많은가보다 다음에 무엇을 바꿔야 하는지 증거로 판단할 수 있는가에서 드러납니다.

이제 여섯 역량을 하나씩 살펴보겠습니다.

1. LLM 기초: 모델의 능력보다 실패 경계를 이해하기

LLM 기초는 Transformer 수식을 외우는 과목만을 뜻하지 않습니다. 모델이 입력을 토큰으로 바꾸고, 문맥을 참고해 다음 토큰을 생성하며, 확률분포에서 결과를 선택한다는 사실이 실제 제품 결정에 어떤 영향을 주는지 이해하는 능력입니다.

알아야 할 핵심

• 토큰화: 같은 문장도 언어와 토크나이저에 따라 토큰 수가 달라집니다. 비용, 문맥 길이, 다국어 성능을 모두 바꿉니다.
• 문맥 창: 길다고 모든 정보를 똑같이 잘 쓰는 것은 아닙니다. 중요한 근거의 위치, 중복, 잡음, 지시 충돌을 함께 봐야 합니다.
• 생성 설정: 온도와 샘플링은 다양성과 재현성을 바꿉니다. 추론 노력 수준은 품질뿐 아니라 지연과 비용을 바꿉니다.
• 지식과 최신성: 사전학습 지식의 기준 시점과 실제 업무 데이터의 최신성은 별개입니다. 최신 정보가 필요하면 외부 근거를 연결해야 합니다.
• 도구 호출과 구조화 출력: 자연어 생성과 외부 행동은 다른 위험을 가집니다. 호출 스키마, 유효성 검사, 재시도와 승인 장치가 필요합니다.
• 모델 선택: 가장 큰 모델 하나를 모든 단계에 쓰는 것이 정답은 아닙니다. 분류, 추출, 계획, 검증에 서로 다른 모델이나 코드가 더 나을 수 있습니다.

이 기초가 부족하면 두 가지 극단으로 흐릅니다. 하나는 모델을 일반 소프트웨어 함수처럼 과신하는 것이고, 다른 하나는 모델을 통제할 수 없는 마법으로 취급하는 것입니다. 전자는 조용한 오류를 만들고, 후자는 측정할 수 있는 개선 기회를 놓칩니다.

검증 가능한 산출물: 후보 모델별 품질·비용·지연 비교표, 컨텍스트 예산표, 실패 사례 모음, 모델 교체 조건.

대표 실패: 벤치마크 1위 모델을 골랐지만 실제 언어와 문서 형식에서 성능이 낮음, 긴 문서를 통째로 넣어 중요한 지시가 묻힘, 매번 큰 추론 모델을 써서 제품 단가가 맞지 않음.

LLM 기초의 목적은 "이 모델이 똑똑하다"고 말하는 것이 아닙니다. 어떤 조건에서 무엇을 맡길 수 있고, 어디부터 다른 장치가 필요한지 설명하는 것입니다.

2. 데이터 그라운딩: RAG보다 넓은 컨텍스트 공학

LLM은 주어진 문맥 안에서 답을 만듭니다. 기업용 애플리케이션의 품질은 모델 자체보다 필요한 순간에 올바른 데이터가 문맥에 들어오는가에 좌우되는 경우가 많습니다. 초기에는 이를 벡터 검색 기반 RAG로 거의 동일시했지만, 지금의 선택지는 훨씬 넓습니다.

상황	우선 검토할 방식	주의할 점
짧고 항상 필요한 규칙	시스템 프롬프트에 직접 포함	길어지면 우선순위 충돌과 비용 증가
긴 문서에서 의미가 비슷한 부분 찾기	벡터 검색과 재순위화	청킹, 임베딩, 필터, 인용 위치 평가 필요
정확한 이름·번호·약어 검색	키워드 또는 하이브리드 검색	형태소와 오탈자, 동의어 처리 필요
관계와 경로가 중요한 지식	지식 그래프 또는 Graph RAG	그래프 구축·갱신 비용과 관계 품질
고객·주문·재무 같은 구조화 데이터	SQL 도구와 시맨틱 레이어	권한, 정의 일관성, 쿼리 안전성
모델이 필요할 때만 자료를 골라야 함	검색 도구를 제공해 온디맨드 조회	도구 선택 오류, 호출 비용, 중단 조건
문서 전체의 미묘한 맥락이 중요함	긴 문맥에 직접 포함	중요 정보 회수율과 입력 비용을 실측

Google Cloud의 RAG 참조 아키텍처는 이 문제를 단순한 검색 API가 아니라 수집과 제공의 두 하위 시스템으로 나눕니다. 문서를 파싱하고, 청크로 나누고, 임베딩하고, 색인하고, 변경분을 갱신하는 데이터 파이프라인이 먼저입니다. 그 위에서 검색, 재순위화, 프롬프트 조립과 답변 생성이 동작합니다.

실무의 병목은 자주 벡터 데이터베이스 바깥에 있습니다.

1. 원문을 누가 소유하고 누가 볼 수 있는가
2. PDF 표, 이미지, 주석과 HTML을 어떤 구조로 변환할 것인가
3. 문서가 바뀌면 언제 색인을 갱신할 것인가
4. 삭제된 자료가 검색 결과와 캐시에서도 사라지는가
5. 답변의 어느 문장이 어느 근거에서 나왔는지 추적할 수 있는가
6. 검색하지 못한 것과 검색했지만 잘못 답한 것을 구분할 수 있는가

이 때문에 데이터 그라운딩은 RAG 파이프라인 구축보다 컨텍스트 공급망 설계에 가깝습니다. 품질, 최신성, 권한, 계보를 함께 관리해야 합니다.

검증 가능한 산출물: 데이터 소스 지도, 문서 변환 스키마, 검색 평가셋, 근거 회수율, 최신성 목표, 권한 테스트, 답변별 출처 추적.

대표 실패: 관련 문서는 찾았지만 잘못된 버전을 제시함, 검색 성능만 측정하고 최종 답변의 근거 충실도를 보지 않음, 사용자 권한보다 넓은 자료를 문맥에 넣어 정보가 노출됨.

3. 에이전트 시스템: 자율성의 크기보다 경계의 선명도

에이전트라는 말은 서로 다른 시스템을 한데 묶어 부릅니다. Anthropic의 에이전트 설계 가이드는 이를 두 축으로 구분합니다.

• 워크플로: 코드가 미리 정한 경로를 따라 모델과 도구를 호출합니다.
• 에이전트: 모델이 현재 상태를 보고 다음 행동과 도구를 반복적으로 선택합니다.

실제 제품은 둘 사이의 연속선에 있습니다. 분류 후 서로 다른 프롬프트로 보내는 라우팅, 여러 독립 분석을 병렬로 돌리는 병렬화, 초안을 만들고 평가한 뒤 고치는 평가자 루프, 모델이 파일과 브라우저와 코드를 오가며 계획을 수정하는 하네스가 모두 포함됩니다.

중요한 설계 원칙은 결정적인 일은 코드에, 모호한 판단은 모델에 맡기는 것입니다. 세율 계산, 권한 확인, 금액 한도, 데이터 삭제, 스키마 검증처럼 규칙이 명확한 일은 코드가 더 빠르고 싸고 검증하기 쉽습니다. 반면 문서의 의미를 해석하고, 예외를 분류하고, 다음 조사 경로를 고르는 일은 모델의 일반화 능력이 유용합니다.

에이전트 설계에서 결정해야 할 것

1. 상태와 목표: 무엇이 완료된 상태이고, 진행 상황을 어디에 기록할 것인가
2. 도구: API, MCP, CLI, 브라우저, 코드 실행 가운데 무엇을 허용할 것인가
3. 권한: 읽기와 쓰기, 외부 전송, 결제, 삭제를 어떤 승인 단계로 나눌 것인가
4. 메모리: 세션 안의 작업기억, 장기 사용자 기억, 검색 가능한 지식 저장소를 어떻게 분리할 것인가
5. 컨텍스트 관리: 긴 실행에서 무엇을 유지하고 요약하고 버릴 것인가
6. 중단 조건: 성공, 실패, 비용 초과, 반복, 불확실성 임계값에서 언제 멈출 것인가
7. 폴백: 도구가 실패하거나 모델이 확신하지 못할 때 코드, 다른 모델, 사람에게 어떻게 넘길 것인가
8. 오케스트레이션: 한 에이전트로 충분한가, 병렬 탐색이나 권한 분리가 다중 에이전트를 정당화하는가

MCP 명세는 도구 연결을 host, client, server로 나누고 보안 경계를 명시합니다. 표준 연결 규격이 생겼다고 안전이 자동으로 생기는 것은 아닙니다. 입력 검증, 접근 통제, 사용자 확인, 시간 제한, 감사 로그는 애플리케이션이 설계해야 합니다.

다중 에이전트도 마찬가지입니다. 역할 이름을 여러 개 붙였다고 성능이 오르지 않습니다. 과제가 독립적으로 나뉘고, 병렬화가 지연을 줄이거나 탐색 다양성을 높이며, 중간 결과를 검증할 방법이 있을 때 의미가 있습니다. 그렇지 않으면 비용과 실패 경로만 늘어납니다.

검증 가능한 산출물: 상태 전이도, 도구 계약, 권한 표, 최대 단계·비용·시간 한도, 중단 조건, 실패 복구 시나리오, 공격 입력 테스트.

대표 실패: 데모에서는 끝까지 가지만 같은 행동을 반복함, 읽기만 필요한 업무에 광범위한 쓰기 권한을 줌, 도구 실패를 사실로 오인해 자연어로 꾸며 냄, 필요 없는 다중 에이전트가 서로의 오류를 증폭함.

4. 평가 주도 개발: 마지막 시험이 아니라 개발의 나침반

Ng는 AI 시스템을 잘 만드는 사람을 가르는 가장 중요한 특성으로 규율 있는 평가와 오류 분석 루프를 꼽습니다. 이유는 단순합니다. AI 개발에는 바꿀 수 있는 것이 너무 많습니다. 모델, 프롬프트, 검색, 청킹, 도구, 메모리, 흐름, 온도, 재시도, 후처리 가운데 무엇을 먼저 고칠지 평가가 정해 주지 않으면 개발이 체감과 데모에 끌려갑니다.

좋은 평가는 처음부터 거대한 벤치마크일 필요가 없습니다. 실제 과제를 대표하는 30~100개의 사례와 명확한 실패 분류에서 시작할 수 있습니다.

1. 과제를 정의합니다. 입력, 기대 결과, 허용 오차, 실패 비용을 적습니다.
2. 실제 출력을 봅니다. 평균 점수보다 먼저 대표 성공과 실패를 사람이 읽습니다.
3. 오류를 분류합니다. 검색 실패, 지시 위반, 계산 오류, 근거 없는 주장, 도구 실패, 권한 위반처럼 원인별로 나눕니다.
4. 평가 방식을 고릅니다. 코드, 모델 판정, 사람 평가를 적절히 섞습니다.
5. 한 가지 가설을 바꿉니다. 모델과 프롬프트와 검색을 한꺼번에 바꾸지 않습니다.
6. 전체와 세부 구간을 다시 봅니다. 평균 향상이 특정 언어, 고객군, 긴 문서의 악화를 가리지 않는지 확인합니다.
7. 새 실패를 평가셋에 추가합니다. 운영에서 발견된 오류가 다음 회귀 테스트가 됩니다.

세 가지 채점기를 섞는 법

채점 방식	잘 맞는 과제	장점	위험
결정적 코드 평가	JSON 형식, 정확한 수치, 도구 성공, 금지 행동	빠르고 싸며 재현 가능	의미 품질과 부분 정답을 놓침
LLM 판정	요약 품질, 근거 충실도, 지시 준수, 비교 평가	확장성과 의미 판정의 균형	판정 편향, 위치 효과, 모델 공모 오류
사람 평가	고위험 결정, 취향, 새 오류 탐색, 판정기 검증	실제 사용자 가치에 가까움	느리고 비싸며 평가자 간 차이

Anthropic의 에이전트 평가 가이드가 강조하듯 에이전트 평가는 단일 답변 평가보다 어렵습니다. 여러 단계에서 도구와 상태가 바뀌고, 같은 목표에 서로 다른 경로로 도달할 수 있기 때문입니다. 최종 답만 맞았는지뿐 아니라 불필요한 호출, 금지된 접근, 비용, 복구 여부와 경로 품질도 봐야 합니다.

평가기도 평가해야 합니다. 사람 판정과 얼마나 일치하는지, 긴 답변을 선호하지는 않는지, 정답의 위치에 영향을 받는지, 자신의 답변 스타일을 편애하는지 확인해야 합니다. 평가셋이 제품의 실제 분포를 놓치면 점수는 오르는데 사용자는 불만인 상황이 생깁니다.

검증 가능한 산출물: 대표 과제 데이터셋, 오류 분류표, 채점 기준, 평가기 검증 결과, 구간별 점수, 변경 전후 비교, 출시 임계값.

대표 실패: 데모 다섯 개만 보고 출시함, 전체 평균만 보아 고위험 구간의 악화를 놓침, LLM 판정 결과를 사람과 대조하지 않음, 테스트셋에 맞춰 프롬프트를 과도하게 조정함.

5. 프로덕션 운영: 품질·비용·지연·위험을 함께 관리하기

AI 애플리케이션이 프로덕션에 들어가면 실험실에서 보지 못한 입력을 만납니다. 사용자 표현이 달라지고, 문서 분포가 바뀌고, 외부 API가 느려지고, 모델 제공자가 버전을 바꾸며, 공격자가 프롬프트를 조작합니다. 따라서 관측 가능성은 CPU와 오류율을 보는 전통적인 모니터링을 넘어야 합니다.

무엇을 기록하고 보아야 하는가

• 입력과 출력: 개인정보를 보호하면서 재현에 필요한 표본과 해시를 보관합니다.
• 실행 경로: 어떤 프롬프트, 모델, 검색 결과, 도구, 메모리와 정책 버전을 거쳤는지 추적합니다.
• 품질: 정답률 하나가 아니라 근거 충실도, 완료율, 사용자 수정률, 에스컬레이션율을 봅니다.
• 비용: 입력·출력 토큰, 도구 호출, 재시도, 검색과 인프라 비용을 성공한 결과 단위로 계산합니다.
• 지연: 평균뿐 아니라 상위 95·99퍼센타일, 첫 응답 시간, 도구별 지연을 나눕니다.
• 위험: 프롬프트 인젝션, 민감정보 노출, 권한 초과, 금지 행동, 비정상 호출 패턴을 감시합니다.

전통적인 CI/CD는 같은 테스트를 통과하면 배포할 수 있었습니다. AI 시스템의 회귀 검사는 통계적입니다. 전체 평가가 조금 좋아져도 특정 언어와 고객군이 나빠질 수 있고, 샘플링 때문에 반복 실행의 분산이 생길 수 있습니다. 모델과 프롬프트를 바꿀 때는 고정 평가셋, 반복 측정, 위험 구간, 비용과 지연을 함께 비교해야 합니다.

운영은 최적화 단계이기도 합니다. 작은 모델로 라우팅하기, 반복 문맥 캐시하기, 검색 범위 줄이기, 불필요한 에이전트 단계를 코드로 치환하기, 배치 처리하기, 미세조정이나 지식 증류를 검토하기가 모두 여기에 들어갑니다. 중요한 기준은 토큰당 가격이 아니라 허용 품질의 성공 결과 한 건을 만드는 총비용입니다.

NIST AI Resource Center가 AI 위험관리의 실행 도구로 테스트, 평가, 검증과 확인을 강조하는 이유도 같습니다. 프로덕션 신뢰성은 출시 전 모델 점검으로 끝나지 않고, 실제 사용에서 측정하고 대응하는 운영 체계에서 만들어집니다.

검증 가능한 산출물: 실행 trace, 품질·비용·지연 대시보드, 위험 경보, 회귀 파이프라인, 점진 배포와 롤백 절차, 사고 대응 runbook, 데이터 보존 정책.

대표 실패: 모델 버전을 바꿨지만 과거 출력을 재현할 수 없음, 오류율은 정상인데 답변 품질이 하락함, 평균 지연만 보아 일부 사용자의 긴 대기를 놓침, 장애 때 사람 업무로 넘기는 경로가 없음.

6. 머신러닝 기초: 불확실한 시스템을 진단하는 공통 언어

최근의 AI 애플리케이션은 사전학습된 모델 API를 조합하는 경우가 많습니다. 그렇다고 머신러닝 기초가 덜 중요해진 것은 아닙니다. 오히려 모델 내부를 직접 학습시키지 않더라도 실험 결과를 올바르게 해석하려면 더 필요합니다.

• 편향과 분산: 시스템이 일관되게 틀리는지, 입력이나 실행마다 흔들리는지 구분합니다.
• 데이터 분할과 누수: 평가 사례가 학습·프롬프트 예시·검색 색인에 새어 들어가지 않았는지 확인합니다.
• 분포 변화: 개발 데이터와 실제 사용자 데이터가 어떻게 다른지 봅니다.
• 정밀도와 재현율: 놓치면 위험한 과제와 잘못 경보하면 비싼 과제의 임계값을 다르게 정합니다.
• 캘리브레이션: 모델의 자신감 표현과 실제 정답 가능성이 맞는지 살핍니다.
• 오류 분석: 어떤 구간이 전체 성능의 병목인지 정량과 정성으로 찾습니다.
• 학습 방식: 지도학습, 미세조정, 선호학습, 강화학습이 무엇을 바꾸고 어떤 새 실패를 만들 수 있는지 이해합니다.

예를 들어 검색 기반 답변의 정확도가 80퍼센트라고 합시다. 머신러닝적 사고는 여기서 멈추지 않습니다. 검색이 실패한 비율, 검색은 성공했지만 생성이 틀린 비율, 문서 유형별 차이, 사람 사이의 정답 불일치, 신뢰구간과 반복 분산을 나눠 봅니다. 그래야 임베딩을 바꿀지, 프롬프트를 고칠지, 문서 전처리를 손볼지, 사람 검토를 넣을지 결정할 수 있습니다.

검증 가능한 산출물: 데이터 분할 근거, 구간별 오류 분석, 실험 설계, 신뢰구간, 임계값 선택 근거, 분포 변화 점검, 학습 데이터 계보.

대표 실패: 평가 데이터가 검색 색인에 포함되어 성능이 부풀려짐, 평균만 보고 작은 고위험 집단을 놓침, 모델 미세조정으로 한 행동은 좋아졌지만 다른 지시 준수가 나빠짐.

머신러닝 기초는 모델을 처음부터 훈련하는 사람만의 기술이 아닙니다. 불확실한 출력에서 신호와 잡음을 분리하고, 다음 실험을 설계하는 언어입니다.

여섯 역량은 하나의 개발 루프로 움직입니다

여섯 항목의 관계를 선형 학습 순서로 보면 안 됩니다. 머신러닝 기초가 오차를 읽는 언어를 제공하고, LLM 기초가 사용할 부품의 능력과 경계를 정합니다. 데이터 그라운딩이 필요한 사실과 업무 맥락을 공급하고, 에이전트 시스템이 여러 단계와 행동을 연결합니다. 평가는 어느 변경이 효과가 있는지 고르며, 프로덕션 운영은 실제 실패를 다시 평가와 개발로 돌려보냅니다.

역량	시스템에서 맡는 역할	서로 연결되는 지점
머신러닝 기초	오차와 실험을 해석	평가 기준과 데이터 설계의 바닥
LLM 기초	모델 능력과 실패 범위 결정	모델 선택, 문맥, 비용과 지연
데이터 그라운딩	근거와 최신 맥락 공급	검색 품질, 권한, 답변 충실도
에이전트 시스템	판단과 행동을 여러 단계로 조립	도구, 상태, 메모리, 중단과 복구
평가 주도 개발	다음 변경의 우선순위 결정	모든 구성 요소를 같은 목표로 정렬
프로덕션 운영	실사용 성능과 위험을 관찰	새 실패를 평가셋으로 되돌림

이 구조에서 가장 중요한 변화는 평가의 위치입니다. 평가를 마지막에 품질팀이 하는 검수로 두면 개발 속도를 따라잡지 못합니다. 제품 관리자와 도메인 전문가가 좋은 결과를 정의하고, 엔지니어가 이를 실행 가능한 평가로 만들며, 운영팀이 실사용 실패를 다시 공급해야 합니다. 평가가 팀 사이의 공용 언어가 됩니다.

실제로 무엇부터 만들고 배울 것인가

처음부터 여섯 분야를 모두 깊게 공부한 뒤 제품을 시작할 필요는 없습니다. 작은 과제를 끝까지 관통하는 수직 단면을 만들면서 배워야 연결이 보입니다.

1단계: 과제와 실패 비용을 적습니다

"고객 지원을 자동화한다"가 아니라 "배송 문의에서 주문 상태를 조회해 근거와 함께 답하고, 환불 요청은 사람에게 넘긴다"처럼 입력, 결과, 권한과 실패 비용을 적습니다. 어떤 오류는 불편이고 어떤 오류는 금전·법적 위험인지 구분합니다.

2단계: 가장 단순한 수직 단면을 만듭니다

한 모델 호출과 최소한의 코드로 20~30개 실제 사례를 돌립니다. 복잡한 에이전트나 벡터 데이터베이스를 먼저 넣지 않습니다. 기본선이 있어야 추가 복잡성의 가치를 측정할 수 있습니다.

3단계: 출력에서 첫 평가셋을 만듭니다

좋은 사례와 나쁜 사례를 직접 읽고 실패 유형을 5~10개로 나눕니다. 형식과 정확한 값은 코드로, 의미 품질은 명확한 기준을 가진 모델 또는 사람으로 채점합니다.

4단계: 가장 큰 오류 원인을 고칩니다

지식 부족이면 그라운딩을, 추론 부족이면 모델을, 반복 단계가 필요하면 워크플로를, 입력 품질이 문제면 데이터 파이프라인을 고칩니다. 유행하는 기술이 아니라 오류 분포가 아키텍처를 결정하게 합니다.

5단계: 자율성은 필요한 만큼만 추가합니다

경로가 고정된 과제는 코드 기반 워크플로로 둡니다. 사전에 분기 수를 알 수 없고 환경을 관찰하며 계획을 수정해야 할 때 에이전트 루프를 씁니다. 도구별 최소 권한과 명시적 중단 조건을 함께 넣습니다.

6단계: 제한된 사용자에게 배포합니다

관측과 롤백 없이 전체 사용자에게 열지 않습니다. 실행 trace, 비용, 지연, 사용자 수정, 사람 에스컬레이션을 기록하고, 예상하지 못한 실패를 모읍니다.

7단계: 실사용 실패를 회귀 테스트로 바꿉니다

사고를 일회성 수정으로 끝내지 않습니다. 같은 실패가 다시 나오는지 자동으로 확인하는 사례를 평가셋에 넣습니다. 배포할수록 시스템의 시험지가 좋아져야 합니다.

8단계: 품질이 고정된 뒤 비용과 지연을 줄입니다

작은 모델 라우팅, 캐시, 병렬화, 검색 축소, 워크플로 단순화, 미세조정과 자체 호스팅을 검토합니다. 최적화 전후에 같은 평가를 돌려 품질을 희생하지 않았는지 확인합니다.

성숙도는 기능 수가 아니라 닫힌 루프의 깊이로 봐야 합니다

단계	시스템의 모습	다음 단계로 가기 위한 증거
1. API 통합	프롬프트와 모델 호출로 데모 구현	실제 사례, 기본선, 첫 오류 분류
2. 근거 있는 워크플로	데이터 검색과 결정적 단계를 연결	검색·답변 분리 평가, 권한, 최신성
3. 평가되는 에이전트	도구와 상태를 사용해 여러 단계를 수행	경로 평가, 중단 조건, 공격 테스트, 폴백
4. 학습하는 프로덕션 시스템	실사용 실패가 평가와 배포 기준을 갱신	구간별 품질, 회귀, 롤백, 비용·지연·위험 최적화

이 표에서 단계가 높아질수록 에이전트 수나 모델 크기가 반드시 커지는 것은 아닙니다. 오히려 잘 운영되는 4단계 시스템은 필요 없는 모델 호출을 코드로 바꾸고, 자율성의 범위를 줄였을 수 있습니다. 성숙함은 복잡성의 양이 아니라 복잡성을 왜 넣었고 어떤 증거로 유지하는지 아는 상태입니다.

채용과 팀 설계는 프레임워크 이름보다 증거를 물어야 합니다

이 스킬맵을 채용에 쓴다면 "어떤 에이전트 프레임워크를 써봤는가"만 묻는 것은 약한 질문입니다. 도구 이름은 빨리 바뀌고, 라이브러리 사용 경험이 시스템 판단력을 보장하지 않습니다. 다음 질문이 더 많은 것을 드러냅니다.

• 처음 만든 기본선은 무엇이었고, 가장 큰 오류 유형은 무엇이었는가
• 평가셋은 실제 사용자 분포를 어떻게 대표했는가
• 검색 실패와 생성 실패를 어떻게 구분했는가
• 왜 그 단계는 코드가 아니라 LLM이 결정해야 했는가
• 도구 권한, 최대 비용, 중단과 사람 승인 조건은 무엇이었는가
• 모델이나 프롬프트 변경으로 어떤 구간이 좋아지고 나빠졌는가
• 실사용 사고가 어떻게 회귀 테스트와 운영 절차로 바뀌었는가
• 성공 결과 한 건의 총비용과 상위 지연은 얼마였는가

강한 AI 엔지니어는 성공한 데모만 보여주지 않습니다. 실패 표본, 평가 기준, 버린 접근, 트레이드오프와 복구 설계를 함께 설명합니다. 시스템을 잘 만들었다는 주장을 시스템 밖의 증거로 검증할 수 있게 합니다.

팀도 한 사람이 여섯 분야의 최고 전문가가 될 필요는 없습니다. 다만 공통 언어는 필요합니다. 도메인 전문가는 좋은 결과와 위험을 정의하고, 데이터 엔지니어는 근거의 품질과 권한을 책임지며, AI 엔지니어는 모델·도구·평가를 연결하고, 플랫폼과 보안팀은 운영 경계를 만듭니다. 이들이 같은 trace와 평가셋을 볼 수 있어야 합니다.

이 지도에 덧붙여야 할 세 가지

Ng의 여섯 항목은 기술 지도로 유용하지만, 실제 제품에서는 세 가지가 더 명시적으로 보여야 합니다.

첫째, 도메인과 제품 판단

무엇이 좋은 답인지, 어떤 실패가 치명적인지, 사람이 언제 개입해야 하는지는 모델 지식만으로 정할 수 없습니다. 이것은 전체 지도의 네 번째 축인 Shaping the build와 연결됩니다. 평가가 기술적으로 정교해도 잘못된 목표를 측정하면 제품은 잘못된 방향으로 최적화됩니다.

둘째, 보안·개인정보·거버넌스

에이전트가 외부 시스템을 읽고 쓰기 시작하면 보안은 별도 체크리스트가 아니라 아키텍처가 됩니다. 최소 권한, 데이터 목적 제한, 감사 가능성, 승인, 보존과 삭제를 설계 초기부터 넣어야 합니다. Anthropic의 에이전트 신뢰성 연구가 자율성이 커질수록 인간 통제와 도구 권한을 함께 보라고 강조하는 이유입니다.

셋째, 조직의 책임 경계

품질 저하가 모델 때문인지, 데이터 때문인지, 도구 때문인지 모호하면 사고 대응도 모호해집니다. 프롬프트, 데이터 소스, 평가셋, 운영 정책의 소유자와 변경 승인 절차가 필요합니다. 기술적으로 뛰어난 프로토타입이 조직 안에서 오래 살아남지 못하는 이유는 종종 이 책임 경계가 없기 때문입니다.

결론: 프롬프트 기술에서 시스템 학습 능력으로

AI 엔지니어링 초기에 주목받은 기술은 프롬프트와 모델 선택이었습니다. 지금도 중요하지만 그것만으로 제품을 설명하기는 어렵습니다. 모델은 더 강해졌고 도구 연결은 쉬워졌지만, 실제 현장에서 남은 어려움은 올바른 데이터를 공급하고, 행동의 경계를 정하고, 품질을 측정하고, 실패에서 학습하며, 비용과 위험을 통제하는 일입니다.

Andrew Ng의 여섯 역량은 이 변화를 잘 포착합니다. LLM 기초는 부품의 경계를 알려주고, 데이터 그라운딩은 근거를 공급하며, 에이전트 시스템은 판단과 행동을 조립합니다. 머신러닝 기초는 오차를 해석하고, 평가 주도 개발은 다음 실험을 고르며, 프로덕션 운영은 현실의 실패를 다시 학습으로 돌려보냅니다.

그래서 AI 엔지니어의 가장 중요한 결과물은 한 번의 영리한 답변이 아닙니다. 어제의 실패가 오늘의 평가가 되고, 오늘의 평가가 내일의 더 나은 시스템으로 이어지는 반복 구조입니다. 신뢰할 수 없는 부품으로 신뢰할 수 있는 제품을 만드는 힘은 모델 안보다 이 닫힌 루프에 더 많이 쌓입니다.

---

주요 출처

• Andrew Ng, AI Engineering Skills Map 전체 지도
• Andrew Ng, Building and Deploying AI Applications 해설
• Anthropic, Building effective agents
• Anthropic, Demystifying evals for AI agents
• Anthropic, Trustworthy agents in practice
• Google Cloud, RAG reference architectures
• Model Context Protocol, Architecture
• NIST AI Resource Center

이 글은 Andrew Ng가 공개한 역량 지도를 출발점으로 공식 기술 문서와 운영 가이드를 대조해 재구성한 독립 분석입니다. 원문의 조사 표본과 세부 가중치는 전체 공개되지 않아 방법론의 재현성까지 검증한 것은 아닙니다. 특정 프레임워크나 모델을 권하는 글이 아니라 AI 제품 개발 역량의 구조를 설명하는 글입니다.