2026 AI Agent Engineer 학습 커리큘럼 (1) 기술 지도와 역량

이 글은 5편짜리 시리즈의 1편입니다.

시리즈 목차

• 1. 2026 AI Agent Engineer 학습 커리큘럼 (1) 기술 지도와 역량 ← 현재
• 2. 2026 AI Agent Engineer 학습 커리큘럼 (2) 8·12주 — Week 0–6
• 3. 2026 AI Agent Engineer 학습 커리큘럼 (3) 12주 — Week 7–12
• 4. 2026 AI Agent Engineer 학습 커리큘럼 (4) 프로젝트와 아키텍처
• 5. 2026 AI Agent Engineer 학습 커리큘럼 (5) 프로덕션·포트폴리오·체크리스트

아래부터 본편입니다.

2026 AI Agent Engineer 학습 커리큘럼 (1) 기술 지도와 역량

목표: 프롬프트를 잘 쓰는 개발자가 아니라 Context / Harness / Loop / Graph / Eval을 직접 설계하고 운영하는 AI Agent Engineer다. 원칙: Vanilla Python 먼저 → 아키텍처 이해 → 프레임워크. 모든 프로젝트에 Eval·Observability·비용 측정을 넣는다. Happy path 금지. 기준 시점: 2026년 초. 기술 최신성은 "현재 지식 기준"으로 분류한다(웹 검증 미실행).

1. 2026 AI Agent Engineer 전체 기술 지도

Agent 시스템은 아래 계층으로 쌓인다. 각 계층은 아래 계층에 의존하고 위 계층에 계약(interface)을 제공한다. 위로 갈수록 "모델이 아니라 시스템"이 품질을 결정한다.

계층별 핵심 개념

Cross-cutting 역량

• Spec-Driven Development: intent → spec → plan → task → agent → implementation → verification. Spec을 Source of Truth로 관리한다.
• Cost / Token / Latency 최적화: 모든 프로젝트가 token, latency, cost, success rate를 기록한다.
• Agent Backend API 설계: FastAPI, SSE 스트리밍, async worker, job queue, idempotency, rate limit.
• 실행 환경: Docker/Compose, Colima, GitHub Actions, 환경 변수 격리.

2. 갖춰야 할 역량 (왜 / 무엇 / 어디까지 / 다음 연결)

각 역량을 왜 필요한가 → 무엇을 구현하는가 → 어디까지 알아야 하는가(L1~L4) → 다음 역량과 어떻게 연결되는가로 정리한다.

레벨 정의 — L1: 개념 이해 / L2: 코드 구현 / L3: 시스템 설계 / L4: 운영·최적화

2.1 LLM API 구조 이해 — 목표 L3

• 왜: Agent는 결국 LLM 호출의 연쇄다. 토큰·샘플링·요금 모델을 모르면 비용과 지연을 통제하지 못한다.
• 무엇: provider 추상화 클라이언트(OpenAI/Anthropic 동일 인터페이스), 스트리밍 제너레이터, 토큰·비용 카운터, 재시도/타임아웃.
• 어디까지: 스트리밍 프로토콜 파싱, prompt caching 동작, provider별 tool calling 차이를 직접 설명하고 구현한다.
• 다음 연결: 이 클라이언트가 Harness의 최하위 실행 단위가 된다.

2.2 Tool Calling 구현 — 목표 L4

• 왜: 도구 없는 Agent는 텍스트 생성기다. 외부 세계와의 상호작용은 전부 여기서 나온다.
• 무엇: tool registry(이름→핸들러+스키마), 인자 검증(Pydantic), 도구 예외→모델 되먹임, parallel tool call, 타임아웃/재시도.
• 어디까지: 스키마 설계가 토큰 비용과 선택 정확도에 미치는 영향을 측정하고 튜닝한다.
• 다음 연결: registry는 Harness의 핵심 구성요소다. Loop이 이 도구들을 반복 호출한다.

2.3 Structured Output 설계 — 목표 L3

• 왜: Agent 간·단계 간 데이터 전달은 자유 텍스트가 아니라 타입이 필요하다.
• 무엇: JSON schema / tool 모드 강제, Pydantic 모델 검증, 검증 실패 시 복구 프롬프트.
• 어디까지: JSON mode vs tool mode의 신뢰도 차이, 스키마 복잡도와 실패율의 관계.
• 다음 연결: Graph의 state, Eval의 trajectory 기록이 전부 structured output에 의존한다.

2.4 Context Engineering — 목표 L4 (최우선)

• 왜: 2026년 Agent 품질의 최대 변수다. 모델이 아니라 "무엇을 컨텍스트에 넣느냐"가 결과를 가른다.
• 무엇: Context Manager — 세그먼트(system/profile/memory/retrieved/tool_result/task), 토큰 예산, 우선순위 기반 truncation·요약, 캐시 프리픽스 정렬.
• 어디까지: context rot / pollution / overflow / lost-in-the-middle / stale·duplicate context를 재현하고 완화한다. 예산 대비 품질 곡선을 그린다.
• 다음 연결: RAG·Memory의 출력이 Context Manager의 입력이다. Loop의 매 반복이 Context Manager를 다시 호출한다.

2.5 RAG — 목표 L4

• 왜: Agent가 모르는 지식을 주입하는 표준 경로다.
• 무엇: ingest 파이프라인(chunking·embedding·metadata), 하이브리드 검색(BM25+vector), reranking, contextual retrieval, /search·/answer API.
• 어디까지: recall/precision/MRR/NDCG/faithfulness/answer relevance로 검색 품질을 평가하고 회귀를 막는다.
• 다음 연결: retrieval 결과는 Context Manager의 한 세그먼트다. Agentic RAG는 Loop과 결합한다.

2.6 Memory Architecture — 목표 L3

• 왜: RAG는 "문서 검색", Memory는 "이 사용자·이 세션에서 학습한 것". 다른 문제다.
• 무엇: memory extractor(LLM), 타입별 저장소(episodic/semantic/procedural), retrieval(recency+relevance), 충돌 병합, decay.
• 어디까지: memory write/update/delete/conflict/decay 전 수명주기를 구현하고 모순 주입 테스트까지 한다.
• 다음 연결: Memory 출력도 Context Manager 세그먼트다. 장기 개인화 Agent의 핵심이다.

2.7 MCP — 목표 L3

• 왜: 2025년 표준화 이후 도구·리소스 연결의 사실상 표준이다. 자작 통합을 재발명하지 않는다.
• 무엇: Python MCP 서버(tools/resources/prompts), MCP 클라이언트 통합, stdio·HTTP transport, capability negotiation, tool discovery.
• 어디까지: 서버·클라이언트 양쪽을 직접 구현하고 권한 경계·에러 전파를 테스트한다.
• 다음 연결: MCP 서버는 Harness의 tool registry에 도구를 공급한다. 보안 계층에서 "악성 MCP 서버" 위협 모델까지 이어진다.

2.8 Agent Harness 설계 — 목표 L4 (최우선)

• 왜: "좋은 모델 < 좋은 harness". Coding agent 품질의 대부분은 모델 밖(sandbox·permission·verification)에서 나온다.
• 무엇: runtime(도구 실행을 sandbox+permission+trace로 감싸기), execution trace, token/time/iteration budget, verification 훅(test/lint/type/security).
• 어디까지: 위험 도구 격리, 권한 거부 경로, budget 컷, trace 완전성을 운영 수준까지 올린다.
• 다음 연결: Loop이 Harness 위에서 돈다. Graph 노드가 Harness 인스턴스를 소유한다.

2.9 Agent Loop 설계 — 목표 L4 (최우선)

• 왜: 자율성도, 비용 폭발·무한 루프도 루프에서 나온다.
• 무엇: 상태 머신(plan→act→observe→evaluate→stop?), reflection, verifier, 정지 조건(max_iter·timeout·token·cost), progress check, duplicate action detection, human escalation.
• 어디까지: 정지 조건 각각을 테스트하고, 진행 정체를 감지하며, 수렴 실패 시 escalation 경로를 둔다.
• 다음 연결: Graph의 노드 하나가 Loop을 실행한다. Eval의 trajectory eval이 Loop 궤적을 채점한다.

2.10 Multi-Agent Graph 설계 — 목표 L3~L4

• 왜: 단일 Agent로는 못 하는 분업·병렬·검증 분리가 필요할 때.
• 무엇: vanilla graph engine(node/edge/state reducer/조건부 엣지/parallel+join/checkpoint), 그 후 LangGraph와 비교.
• 어디까지: 라우팅 분기, 병렬 join 정합성, 체크포인트 재개, human gate 삽입.
• 다음 연결: 최종 프로젝트의 오케스트레이터다. "언제 멀티에이전트를 쓰지 말아야 하는가"를 판단한다.

2.11 Agent State 관리 — 목표 L3

• 왜: 재개 가능성·감사·replay가 전부 state에 의존한다.
• 무엇: state store(Postgres), reducer 패턴, 체크포인트, Agent State ↔ Memory 분리.
• 어디까지: 동시 실행 시 state 정합성, 부분 실패 후 재개.
• 다음 연결: replay(L7)와 trajectory eval(L6)의 데이터 소스다.

2.12 Agent Evaluation — 목표 L4 (최우선)

• 왜: eval 없이는 개선인지 회귀인지 모른다. "느낌 개발"을 막는 장치다.
• 무엇: Eval Harness — 데이터셋 러너, deterministic/unit/integration eval, LLM-as-judge(pairwise/pointwise), trajectory·tool-use eval, regression DB, CI 게이트.
• 어디까지: judge 편향(위치·장황함) 측정·완화, 회귀 자동 차단, 지표 계산 정확도.
• 다음 연결: 모든 계층의 변경이 Eval Harness를 통과해야 배포한다. 포트폴리오의 핵심 증거다.

2.13 Agent Observability — 목표 L4

• 왜: 프로덕션 Agent는 비결정적이다. trace 없이는 디버깅이 불가하다.
• 무엇: OpenTelemetry span 계측(prompt/context/tool call/result/output/token/latency/cost/error/retry/score), trace viewer, replay 러너.
• 어디까지: 하나의 실행을 span 트리로 완전 재구성하고, replay로 재현한다.
• 다음 연결: Eval의 trajectory 소스이자 Reliability failure analysis의 입력이다.

2.14 Guardrail / Output Validation — 목표 L3

• 왜: 모델 출력을 그대로 믿으면 안 된다. 도구 인자·최종 답변 둘 다 검증한다.
• 무엇: 입력·출력 스키마 검증, 정책 필터, tool 인자 allowlist, 위험 패턴 탐지.
• 다음 연결: Human-in-the-loop의 트리거(위험 탐지 → gate)다.

2.15 Human-in-the-loop — 목표 L3

• 왜: 되돌릴 수 없는 작업(결제·배포·삭제·이메일·머지)은 사람이 승인한다.
• 무엇: action proposal → risk detection → 승인 큐(approve/reject/modify) → 실행.
• 다음 연결: Graph의 human gate 노드로 구현한다. 최종 프로젝트 필수다.

2.16 Agent Security — 목표 L3

• 왜: prompt injection(특히 indirect), tool poisoning, memory/RAG poisoning은 Agent 고유 공격면이다.
• 무엇: tool allowlist, permission, sandbox, secret isolation, input/output validation, audit log, 인젝션 테스트 스위트.
• 어디까지: 간접 인젝션 e2e 재현 → 다층 방어로 차단한다.
• 다음 연결: Harness의 permission·sandbox, HITL의 gate와 결합한다.

2.17 Cost / Token / Latency 최적화 — 목표 L4

• 왜: Agent는 호출당 수십~수백 번 LLM을 부른다. 단가 관리가 사업성을 가른다.
• 무엇: prompt caching, context 예산, 모델 라우팅(저가↔고가), 병렬화, 스트리밍, cost per successful task 대시보드.
• 다음 연결: Eval 지표에 비용을 포함하고, Reliability의 cost governance로 이어진다.

2.18 Agent Backend API 설계 — 목표 L4

• 왜: Agent는 서비스로 배포된다. async worker·큐·idempotency가 없으면 스케일이 불가하다.
• 무엇: FastAPI Agent API, SSE 스트리밍, job queue, async worker, concurrency 제어, rate limit, model fallback, caching, retry, idempotency.
• 다음 연결: 최종 프로젝트의 백엔드다.

2.19 Docker 기반 실행 환경 + CI/CD — 목표 L3

• 왜: 재현 가능한 sandbox와 자동 품질 게이트.
• 무엇: Dockerfile/Compose, Colima, GitHub Actions(lint→type→test→eval), 환경 변수 격리.
• 다음 연결: Harness sandbox, Eval CI 게이트다.

2.20 Production Agent 운영 — 목표 L4

• 왜: 배포는 시작일 뿐이다. 회귀 탐지·알림·fallback·점진적 저하가 곧 운영이다.
• 무엇: SLO, 회귀 탐지, alert, circuit breaker, graceful degradation, 사후 분석 루프.
• 다음 연결: 전체 시스템의 최종 목표다.

3. 학습 순서와 그 이유

1. L0/L1 먼저 — Agent는 async I/O와 LLM 호출의 조합이다. 토큰·스트리밍·tool calling을 직접 다루지 못하면 그 위 계층은 전부 불투명하다.
2. Context를 RAG보다 먼저 — RAG는 컨텍스트를 채우는 한 가지 방법일 뿐이다. Context Manager(예산·우선순위·압축)를 먼저 잡으면 RAG·Memory는 그 안의 세그먼트로 들어온다. 순서를 뒤집으면 프롬프트 문자열 이어붙이기에 갇힌다.
3. RAG → Memory 순서 — 둘 다 retrieval이지만 Memory에는 write/update/conflict/decay라는 추가 수명주기가 있다. RAG으로 검색 평가를 먼저 익혀야 Memory 품질도 측정한다.
4. MCP는 Harness 직전 — MCP는 도구 연결 방식의 표준이다. Harness의 tool registry를 만들기 직전에 배우면 바로 통합된다.
5. Harness → Loop → Graph 순서 (절대 뒤집지 않는다) —

- Harness 없는 Loop = 관측·격리·예산 없는 자율 실행 = 비용 폭발. - 안정적인 단일 Agent Loop 없이 Graph = 불안정한 노드 여러 개 = 디버깅 불가능. - Graph는 여러 개의 안정된 Loop을 조율한다.

1. Eval은 마지막이 아니라 처음부터 — L2(Context)부터 모든 프로젝트에 골든셋과 회귀 게이트를 붙인다. Eval을 12주차로 미루면 그 전 10주가 전부 느낌 개발이 된다. 다만 Eval Harness라는 별도 시스템의 본격 구축은 Loop/Graph 이후에 한다(채점 대상인 trajectory가 그때 생기므로).
2. Observability도 병행 — trace를 나중에 넣으면 계측 지점을 다 놓친다. Harness를 만들 때부터 span을 emit한다.
3. Security/HITL는 통합 단계 — 방어는 대상(도구·메모리·그래프)이 있어야 의미가 있다. 마지막에 다층 방어로 묶는다.
4. 프레임워크는 각 계층의 vanilla 구현 후 — LangGraph는 Graph를 손으로 만든 뒤에, PydanticAI/OpenAI Agents SDK는 Harness/Loop을 손으로 만든 뒤에. 그래야 프레임워크가 무엇을 대신하는지 보인다.