Notice

[팁]주옥같은 안드로이드 팁

Recent Posts

Recent Comments

Link

« 2026/08 »
일	월	화	수	목	금	토
						1
2	3	4	5	6	7	8
9	10	11	12	13	14	15
16	17	18	19	20	21	22
23	24	25	26	27	28	29
30	31

Tags more

Archives

Today

Total

관리 메뉴

오늘도 공부

AI 애플리케이션을 잘 만드는 개발자는 무엇이 다른가 본문

AI 애플리케이션을 잘 만드는 개발자는 무엇이 다른가

행복한 수지아빠 2026. 8. 24. 11:58

Andrew Ng의 AI Engineering Skills Map ① — Building and Deploying AI Applications

AI 애플리케이션 개발은 기존 소프트웨어 개발과 상당히 다릅니다.

전통적인 프로그램에서는 같은 입력을 넣으면 대부분 예상 가능한 결과가 나옵니다.

하지만 LLM이나 머신러닝 모델은 그렇지 않습니다.

같은 프롬프트를 사용하더라도 답변이 달라질 수 있고, 새로운 데이터에 대해 어떤 결과가 나올지 완벽하게 예측하기도 어렵습니다.

그래서 AI 엔지니어링에서 중요한 것은 단순히 LLM API를 호출하는 능력이 아닙니다.

예측하기 어려운 AI 컴포넌트를 이용해 신뢰할 수 있는 시스템을 만드는 능력

Andrew Ng는 이를 위해 필요한 역량을 다음 6가지로 정리합니다.

LLM Foundations
Grounding Models with Data
Building Agentic Systems
Evaluation-Driven Development
Operating in Production
Machine Learning Foundations

하나씩 살펴보겠습니다.

1. LLM Foundations

LLM이 어떻게 동작하는지 이해하기

LLM을 제대로 활용하려면 먼저 모델의 기본 동작을 이해해야 합니다.

단순히

"GPT API를 호출할 줄 안다."

정도로는 부족합니다.

최소한 다음 개념을 이해해야 합니다.

Tokenization
Context Window
Sampling
Reasoning
Knowledge Cutoff
Cache
Tool Calling
Multimodal Model
Fine-tuning
Self-hosting

예를 들어 모델에게 매우 긴 문서를 통째로 Context Window에 넣을 수도 있습니다.

하지만 항상 좋은 선택은 아닙니다.

Context가 길어질수록

비용이 증가하고
응답 시간이 늘어나며
중요한 정보가 묻힐 수 있습니다.

따라서 개발자는 판단해야 합니다.

전체 데이터를 Context에 넣을 것인가?

아니면

필요한 데이터만 검색해서 가져오게 할 것인가?

이런 판단을 하기 위해 LLM의 기본 구조를 이해해야 합니다.

2. Grounding Models with Data

AI에게 좋은 데이터를 제공하는 방법

LLM의 성능은 모델 자체만으로 결정되지 않습니다.

AI에게 어떤 Context를 제공하느냐가 매우 중요합니다.

초기 LLM 애플리케이션에서는 주로 RAG + Vector Search 구조가 많이 사용되었습니다.

대표적인 구조는 다음과 같습니다.

사용자 질문
↓
Embedding
↓
Vector Search
↓
관련 문서 검색
↓
LLM Context에 삽입
↓
답변 생성

하지만 지금의 Grounding 기술은 훨씬 다양해졌습니다.

데이터 특성에 따라 다른 구조를 선택할 수 있습니다.

Vector Database

문서나 자연어 검색에 적합합니다.

예:

사내 문서
매뉴얼
고객 문의
기술 문서

Knowledge Graph

개체와 관계가 중요한 데이터에 적합합니다.

예:

사용자 → 회사 → 프로젝트 → 제품

처럼 관계 중심의 정보를 표현할 수 있습니다.

Structured Data

CRM이나 ERP 같은 구조화된 데이터는 SQL이나 Semantic Layer를 사용할 수 있습니다.

예:

고객 정보
주문 기록
재고
매출
사용자 활동

여기서 중요한 질문은 이것입니다.

이 데이터를 AI에게 어떤 방식으로 제공하는 것이 가장 좋은가?

그리고 데이터를 한 번 연결했다고 끝나는 것도 아닙니다.

PDF, HTML, 이미지, 문서 등을 AI가 사용할 수 있는 형태로 변환하고 지속적으로 업데이트해야 합니다.

즉 AI 시대에는 Data Engineering과 Context Engineering의 경계도 점점 가까워지고 있습니다.

3. Building Agentic Systems

AI에게 일을 맡기는 시스템 만들기

단순한 LLM 애플리케이션은 이런 구조입니다.

사용자
→ Prompt
→ LLM
→ Answer

하지만 Agentic System은 다릅니다.

예를 들어 리서치 에이전트라면 다음과 같이 움직일 수 있습니다.

질문 분석
↓
검색
↓
자료 읽기
↓
추가 검색 결정
↓
정보 정리
↓
초안 작성
↓
검증
↓
최종 답변

여기서 LLM은 단순히 답변을 생성하는 것이 아니라

다음에 무엇을 해야 할지 결정합니다.

Andrew Ng는 Agentic System을 크게 두 종류로 볼 수 있다고 설명합니다.

Workflow

미리 정해진 순서대로 실행합니다.

예:

Research → Summarize → Write → Review

Agent Loop

AI가 상황에 따라 다음 행동을 스스로 선택합니다.

예:

Think
→ Tool
→ Observe
→ Think
→ Tool
→ Observe
→ Answer

Agent를 만들 때 필요한 판단

Agentic System을 설계할 때는 의외로 많은 결정을 해야 합니다.

예를 들어 다음과 같습니다.

어떤 작업을 연결할 것인가?

A → B → C

어떤 작업을 병렬 처리할 것인가?

예:

Search A

Search B

Search C

세 검색이 서로 의존하지 않는다면 동시에 실행할 수 있습니다.

어떤 작업을 코드로 처리할 것인가?

모든 것을 LLM에게 맡길 필요는 없습니다.

정확한 계산이나 규칙 기반 작업은 일반 코드가 더 적합할 수 있습니다.

어떤 Tool을 제공할 것인가?

Agent가 사용할 수 있는 도구는 다양합니다.

Web Search
Database
API
MCP
CLI
Browser
Sandbox
Python

Memory와 Context 관리

Agent가 오랫동안 작업하면 Context가 계속 커집니다.

따라서 다음도 설계해야 합니다.

Short-term Memory
Long-term Memory
Session Memory
Context Compression
Summary
Retrieval

특히 긴 작업에서는 모든 대화를 계속 Context에 넣는 방식보다 필요한 정보만 유지하거나 다시 검색하는 구조가 중요합니다.

언제 Multi-Agent를 사용할 것인가?

모든 문제에 Multi-Agent가 필요한 것은 아닙니다.

간단한 문제는 Single Agent가 더 효율적일 수 있습니다.

하지만 역할이 명확히 나뉘는 작업에서는 Multi-Agent 구조를 고려할 수 있습니다.

예를 들면 콘텐츠 제작 시스템을 이렇게 나눌 수 있습니다.

Research Agent

자료 조사

↓

Writer Agent

초안 작성

↓

Fact Checker

사실 확인

↓

Editor Agent

문장 개선

↓

Publisher Agent

게시 형식 변환

이것이 바로 Agent Orchestration입니다.

4. Evaluation-Driven Development

AI 개발에서 가장 중요한 기술 중 하나

Andrew Ng는 AI 시스템 개발에서 중요한 역량으로 Eval과 Error Analysis를 특히 강조합니다.

AI 개발에서 흔히 발생하는 문제는 이것입니다.

프롬프트를 수정합니다.

결과를 봅니다.

괜찮아 보입니다.

다시 수정합니다.

하지만 이렇게 개발하면 개선이 실제로 일어나고 있는지 알기 어렵습니다.

따라서 AI 시스템에서는 다음 루프가 필요합니다.

Build
↓
Run
↓
Evaluate
↓
Error Analysis
↓
Improve
↓
Run Again

이것을 Evaluation-Driven Development라고 볼 수 있습니다.

Eval은 어떻게 할까?

평가 방법은 여러 가지가 있습니다.

1. Deterministic Evaluation

코드로 명확하게 검사합니다.

예:

JSON 형식이 맞는가?
필수 필드가 있는가?
숫자 범위가 맞는가?
URL 형식이 올바른가?

2. LLM-as-a-Judge

다른 LLM에게 결과를 평가하게 합니다.

예:

이 답변이 사용자의 질문에 정확히 답했는지
1~5점으로 평가하세요.

3. Human Evaluation

사람이 직접 평가합니다.

특히 다음과 같은 요소는 사람 평가가 중요할 수 있습니다.

자연스러움
유용성
브랜드 톤
창의성
사용자 만족도

중요한 것은 Eval 자체도 평가해야 한다는 것

Eval을 만들었다고 끝나는 것이 아닙니다.

Eval 자체가 실제 품질을 제대로 측정하고 있는지도 확인해야 합니다.

예를 들어 LLM Judge가 좋은 답변과 나쁜 답변을 제대로 구분하지 못한다면 평가 시스템 역시 개선해야 합니다.

따라서 실제 AI 시스템은 다음과 같이 움직입니다.

AI System

↓

Eval System

↓

Eval의 정확성 검증

↓

Eval 개선

↓

AI System 개선

즉 평가 시스템 역시 하나의 제품입니다.

5. Operating in Production

AI를 실제 서비스로 운영하기

Prototype과 Production은 완전히 다른 문제입니다.

Demo에서는 잘 작동하던 AI가 실제 사용자에게 공개되면 예상하지 못했던 문제가 발생합니다.

예를 들어

이상한 질문
매우 긴 입력
Prompt Injection
잘못된 검색 결과
API 장애
모델 업데이트
비용 폭증
응답 지연

등이 나타납니다.

따라서 Production에서는 Observability가 중요합니다.

무엇을 관찰해야 할까?

대표적으로 다음을 추적할 수 있습니다.

Quality

답변 품질

Latency

응답 시간

Cost

Token 비용

Error

실패율

Tool Usage

Tool 호출 성공률

Retrieval

검색 정확도

Security

Prompt Injection이나 데이터 유출 위험

AI 시스템에는 Drift도 존재한다

서비스를 운영하다 보면 사용자의 질문 유형이 달라질 수도 있습니다.

모델이 업데이트될 수도 있습니다.

데이터베이스 내용도 바뀝니다.

따라서 시간이 지나면서 기존 Eval 성능이 떨어질 수 있습니다.

이 때문에

Monitoring + Regression Test

가 필요합니다.

새로운 모델이나 프롬프트를 적용하기 전에 기존 Eval Dataset을 다시 실행해서 성능이 떨어지지 않았는지 확인하는 것입니다.

비용과 Latency도 AI Engineering이다

AI 서비스를 대규모로 운영하면 작은 비용 차이가 큰 차이를 만듭니다.

예를 들어 한 요청에 1센트가 든다고 가정해 보겠습니다.

하루 100만 요청이면

$10,000 / day

가 됩니다.

따라서 Production에서는 모델 정확도만 볼 수 없습니다.

다음 요소를 함께 고려해야 합니다.

Quality

Cost

Latency

이 세 가지 사이의 트레이드오프가 존재합니다.

이를 개선하기 위해 다음과 같은 방법을 사용할 수 있습니다.

Smaller Model
Model Routing
Caching
Distillation
Fine-tuning
Prompt Optimization
Context Reduction
Workflow Simplification

6. Machine Learning Foundations

LLM 시대에도 ML 기본기가 필요한 이유

LLM이 등장하면서 Machine Learning을 공부할 필요가 없어졌다고 생각할 수도 있습니다.

하지만 Andrew Ng는 반대로 이야기합니다.

좋은 LLM 엔지니어들은 대부분 Machine Learning과 Deep Learning에 대한 기본적인 이해를 가지고 있다는 것입니다.

특히 다음 개념은 여전히 중요합니다.

Supervised Learning
Reinforcement Learning
Training / Validation / Test
Bias
Variance
Overfitting
Error Analysis
Data Engineering
Accuracy
Precision / Recall

그 이유는 LLM도 결국 확률적 Machine Learning 시스템이기 때문입니다.

Bias와 Variance 사고방식

예를 들어 AI 시스템의 성능이 낮을 때 단순히

"프롬프트를 더 잘 써야겠다."

라고 판단해서는 안 됩니다.

문제의 원인을 분석해야 합니다.

모델 문제인가?

모델 능력이 부족한가?

데이터 문제인가?

Context가 부족한가?

Retrieval 문제인가?

잘못된 문서를 검색하는가?

Prompt 문제인가?

지시가 명확하지 않은가?

Tool 문제인가?

Agent가 잘못된 Tool을 사용하는가?

Evaluation 문제인가?

평가 기준 자체가 잘못되어 있는가?

이것이 바로 머신러닝에서 오랫동안 사용해 온 Error Analysis 사고방식입니다.

결국 AI Engineering은 반복의 기술이다

AI 시스템을 만드는 과정을 한 줄로 표현하면 다음과 같습니다.

Build → Measure → Analyze → Improve → Repeat

기존 소프트웨어에서는 설계를 먼저 충분히 한 뒤 구현하는 방식이 비교적 잘 작동했습니다.

하지만 AI 시스템은 결과가 불확실하기 때문에 실제로 만들어 보고 결과를 확인하면서 다음 행동을 결정해야 하는 경우가 많습니다.

그래서 AI 엔지니어에게 중요한 능력은

첫 번째 버전을 완벽하게 만드는 능력

보다

결과를 보고 다음 실험을 정확하게 결정하는 능력

에 가깝습니다.

6가지 역량을 하나의 시스템으로 보면

Andrew Ng가 설명한 6가지 역량은 서로 독립적이지 않습니다.

다음과 같이 연결됩니다.

LLM Foundations

모델을 이해한다.

↓

Grounding

좋은 Context를 제공한다.

↓

Agentic Systems

AI가 Tool을 사용하며 작업하도록 만든다.

↓

Evaluation

결과를 측정한다.

↓

Production

실제 환경에서 관찰하고 운영한다.

↓

Machine Learning Foundations

문제의 원인을 분석하고 개선한다.

그리고 다시 처음으로 돌아갑니다.

이 구조는 결국 하나의 거대한 Feedback Loop입니다.

실전 학습 로드맵으로 바꾼다면

이 내용을 공부 순서로 바꾸면 다음과 같이 구성할 수 있습니다.

STEP 1. LLM 기본기

Token
Context Window
Prompt
Structured Output
Tool Calling
Multimodal

↓

STEP 2. Grounding

Embedding
Vector DB
RAG
Hybrid Search
Knowledge Graph
Structured Data

↓

STEP 3. Agent

Tool
Workflow
Agent Loop
Memory
MCP
Multi-Agent

↓

STEP 4. Evaluation

Golden Dataset
Deterministic Eval
LLM Judge
Human Eval
Error Analysis

↓

STEP 5. Production

Logging
Tracing
Monitoring
Guardrails
CI/CD
Cost Optimization

↓

STEP 6. Machine Learning

Supervised Learning
Deep Learning
Bias / Variance
Error Analysis
Data Engineering

앞으로 AI 개발자의 핵심 경쟁력

AI 개발에서 중요한 것은 가장 최신 모델을 가장 빨리 사용하는 것만은 아닙니다.

모델은 계속 바뀝니다.

GPT, Claude, Gemini와 같은 모델뿐만 아니라 새로운 모델과 Agent Framework도 계속 등장할 것입니다.

하지만 그 위에서 반복되는 핵심 질문은 크게 달라지지 않습니다.

어떤 모델을 사용할 것인가?

어떤 데이터를 Context로 제공할 것인가?

어떤 Tool을 연결할 것인가?

어떤 Workflow를 구성할 것인가?

결과가 좋은지 어떻게 평가할 것인가?

실패 원인은 무엇인가?

Production에서 비용과 Latency를 어떻게 관리할 것인가?

이 질문에 체계적으로 답할 수 있는 사람이 AI Engineering을 잘하는 개발자에 가까워질 것입니다.

정리

Andrew Ng가 제시한 Building and Deploying AI Applications의 핵심 역량은 다음 6가지입니다.