2026 AI Agent Engineer 학습 커리큘럼 (2) 8·12주 — Week 0–6

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

시리즈 목차

• 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 학습 커리큘럼 (2) 8·12주 — Week 0–6

4. 8주 집중 커리큘럼 (요약표)

전제: Python·async·FastAPI·Docker에 이미 익숙. 하루 평일 3h / 주말 5h. 목표는 동작하는 Agent 시스템 1개와 Eval이다.

5. 12주 실무 커리큘럼 (주차별 풀 디테일)

전제: Python 중급, async·FastAPI 기본기 있음(없으면 아래 Week 0 먼저). 하루 평일 2~3h / 주말 4~6h.

각 주차 형식: 목표 · 개념 · 반드시 이해할 내용 · 구현 · 실습 · 프로젝트 · 테스트 · 완료 기준

Week 0 (선택) — 개발 기반 점검

아래 중 자신 없는 항목이 하나라도 있으면 1주 투자한다.

• Python: typing(Generic/Protocol/TypedDict), dataclass vs Pydantic, async/await·asyncio.gather·TaskGroup, async context manager, generator/async generator, decorator, 의존성 주입 패턴, 예외 계층 설계, 구조적 로깅(structlog 또는 logging + JSON).
• Backend: REST·HTTP 시맨틱, SSE vs WebSocket, 인증(API key/JWT), rate limiting, background task, 큐(Redis), DB 트랜잭션·격리 수준.
• Infra: Linux 기본, Docker(레이어·멀티스테이지), 환경 변수, 프로세스·시그널, 포트·네트워크, reverse proxy, GitHub Actions.
• 완료 기준: [ ] async httpx 클라이언트로 동시 10요청 + 재시도 구현 [ ] FastAPI + SSE 스트리밍 엔드포인트 [ ] 멀티스테이지 Dockerfile + compose로 app+postgres+redis 기동 [ ] GitHub Actions로 lint+test 자동화

Week 1 — Model Interface: 프레임워크 없는 LLM 클라이언트

목표: 프레임워크 없이 OpenAI·Anthropic API로 스트리밍 채팅, structured JSON 출력, 멀티턴 대화 루프를 구현하고, 토큰·비용·지연을 정확히 계측한다.

개념: Transformer/attention(개요), token·tokenizer, embedding, context window, inference, temperature·top-p·sampling, structured output, function/tool calling, streaming(SSE 파싱), prompt caching.

반드시 이해할 내용

• LLM vs Chatbot vs Workflow vs Agent vs Autonomous Agent vs Multi-Agent — 각각의 자율성·제어 위치 차이.
• provider별 차이: 메시지 포맷, tool 스펙, 스트리밍 이벤트 구조, 캐시 동작, 요금(입력/출력/캐시 read/write).
• 스트리밍은 청크 파싱과 상태 누적의 문제다. 토큰 사용량은 스트림 종료 이벤트에서 온다.

구현 — llm/

llm/
  client.py      # LLMClient 추상 인터페이스: chat(), stream(), 동일 시그니처
  openai.py      # OpenAI 구현
  anthropic.py   # Anthropic 구현
  types.py       # Message, ToolSpec, Usage(Pydantic)
  cost.py        # provider×모델 단가 테이블 → Usage → USD
  retry.py       # 지수 백오프 + 지터, 재시도 가능 오류 분류

• stream()은 async generator로 델타 텍스트를 yield하고, 종료 시 Usage를 확정한다.
• 모든 호출에 request_id, 시작/종료 타임스탬프, Usage, 비용을 구조적 로그로 남긴다.

실습

• 동일 프롬프트 20개를 두 provider에 던져 출력 길이 / p50·p95 지연 / 호출당 비용 비교표를 만든다.
• structured output: 같은 스키마를 (a) JSON mode, (b) tool 모드로 강제 → 파싱 실패율을 비교한다.

프로젝트: P1 — LLM CLI Assistant

• 스트리밍 REPL, /model 전환, 대화 히스토리 파일 저장/로드, 세션 비용 합계 표시, Ctrl-C graceful 취소.

테스트

• [ ] mock transport로 스트리밍 청크 파싱 단위 테스트(부분 청크·분할 UTF-8 포함)
• [ ] 비용 계산: 알려진 Usage → 기대 USD (테이블 값 고정)
• [ ] 재시도: 429/503에서만 재시도, 400은 즉시 실패
• [ ] structured output 스키마 위반 시 복구 경로

완료 기준

[ ] 두 provider를 동일 인터페이스로 호출 가능
[ ] 스트리밍·비용·지연을 계측하고 로그로 남김
[ ] structured output을 스키마로 강제하고 검증
[ ] 프레임워크(LangChain 등) 의존성 0

Week 2 — Tool Engineering: registry와 단일 tool loop

목표: LLM이 도구를 고르고 호출한 뒤 결과를 받아 다음 행동을 정하는 단일 스텝 tool loop를 구현한다(반복 루프는 Week 9).

개념: tool schema, tool_choice, parallel tool calls, JSON mode vs tool mode, 인자 검증, 도구 예외 처리, 타임아웃·재시도, 결과 검증.

반드시 이해할 내용

• 도구 스키마도 프롬프트 토큰이다. 도구가 20개면 호출마다 수천 토큰이 든다. 선택 정확도와 비용 사이의 트레이드오프다.
• 도구 실패는 세 종류다: 인자 검증 실패, 실행 예외, 타임아웃. 각각 모델에 돌려줄 메시지가 달라야 한다.
• parallel tool call: 모델이 도구 N개를 동시에 요청하면 N개 결과를 모두 되먹여야 한다.

구현 — tools/

tools/
  registry.py    # name -> (handler, ToolSpec). LLM용 스키마 목록 생성
  base.py        # Tool 프로토콜: name, description, args_model(Pydantic), run()
  builtins/
    calculator.py
    http_get.py
    read_file.py
  executor.py    # tool call -> 검증 -> 실행(타임아웃) -> ToolResult(성공/실패 구분)

• executor가 인자를 args_model로 파싱한다. 실패하면 검증 오류를 그대로 모델에 넘긴다.
• 실행은 asyncio.wait_for로 타임아웃을 걸고, 예외는 ToolResult(ok=False, error=...)로 포장한다.

실습

• 도구 3개를 등록한 뒤, 모델이 잘못된 인자를 내도록 유도한다(예: calculator에 문자열). 검증 경로를 확인한다.
• http_get에 느린 URL을 넣고 타임아웃을 유도한다. 모델이 대안을 고르는지 관찰한다.

프로젝트: P2 — Tool-Calling Agent (단일 루프, 도구 최대 5개: calculator, http_get, read_file, write_file, list_dir)

테스트

• [ ] 스키마 검증 실패 → 구조화된 오류가 모델에 전달됨
• [ ] 도구 예외 → 루프가 죽지 않고 오류를 되먹임
• [ ] parallel tool call → 모든 결과가 순서 무관하게 매칭
• [ ] 타임아웃 → ToolResult(ok=False) 로 처리

완료 기준

[ ] registry에 도구를 등록하면 스키마가 자동 생성됨
[ ] 3종 도구 실패를 각각 다르게 처리
[ ] 단일 tool loop(요청→실행→되먹임→최종 답변)가 안정 동작

Week 3 — Prompt/Instruction 설계 + 프롬프트 인젝션 실패 모드

목표: 시스템 프롬프트 계층을 설계하고, 직접·간접 프롬프트 인젝션을 재현한 뒤 기초 방어를 적용한다.

개념: system/user prompt, instruction hierarchy, few-shot vs zero-shot, role prompt, delimiter, structured prompt, prompt template, prompt injection(direct/indirect), jailbreak.

반드시 이해할 내용

• Prompt Engineering의 한계: 프롬프트만으로 풀리던 문제 상당수는 Context Engineering 문제다(무엇을 넣을지가 아니라 어떻게 쓸지).
• indirect injection: 도구가 가져온 웹페이지·파일 내용에 "이전 지시를 무시하고..."가 들어 있는 경우. Agent에서 가장 현실적인 위협이다.
• 프롬프트 회귀: 프롬프트를 고치면 다른 케이스가 깨진다. 그래서 프롬프트도 버전·테스트 대상이다.

구현 — prompts/

prompts/
  templates.py   # 이름+버전 태그가 붙은 템플릿, 렌더 시 변수 검증
  layers.py      # system 프롬프트를 계층으로 조립(역할/정책/포맷/컨텍스트)
  injection_suite.py  # 12+ 인젝션 케이스(직접/간접/도구결과/파일)

실습

• read_file 도구가 읽는 파일 안에 악성 지시를 넣고 Agent가 탈취되는지 재현한다.
• delimiter와 "도구 결과는 데이터이지 지시가 아니다" 역할 분리로 완화한 뒤, 인젝션 스위트 통과율을 측정한다.

프로젝트: P2에 인젝션 스위트를 회귀 테스트로 추가한다.

테스트

• [ ] 인젝션 스위트 12케이스 중 통과율 기록(baseline → 방어 후)
• [ ] 프롬프트 버전 변경 시 기존 케이스 회귀 확인

완료 기준

[ ] 시스템 프롬프트를 계층으로 조립하고 버전 관리
[ ] 직접·간접 인젝션을 각각 재현
[ ] 기초 방어(delimiter·역할 분리·출력 검증)로 통과율 개선을 수치로 제시

Week 4 — Context Engineering: Context Manager 직접 구현 (핵심)

목표: 소스별 컨텍스트를 조립·예산 배분·우선순위·압축하는 Context Manager를 직접 구현한다.

개념: context window, context selection·injection·compression·pruning·isolation·routing·caching·retrieval·budget.

반드시 이해할 내용

• 컨텍스트 문제: context rot(누적 오염), context pollution(관련 없는 정보), overflow(초과), lost-in-the-middle(중간 정보 무시), stale/duplicate context.
• prompt caching과 세그먼트 순서: 캐시 히트를 위해 불변 프리픽스(system)를 앞에 두고, 가변 부분을 뒤에 둔다.
• 예산 초과 시 선택지: truncation, 요약(비용 발생), 세그먼트 드롭. 각각 품질·비용·지연에 미치는 영향이 다르다.

구현 — context/manager.py

Segment(kind, content, priority, ttl, token_estimate)
kinds: system | user_profile | memory | retrieved | tool_result | repository | current_task

ContextManager.build(segments, budget) ->
  1) 필수 세그먼트(system, current_task) 확보
  2) 남은 예산을 우선순위·recency로 배분
  3) 초과 시 전략(truncate | summarize | drop) 적용
  4) 캐시 프리픽스 정렬
  -> (messages, budget_report)

실습

• 예산 4k 토큰에 세그먼트 6개(합계 9k)를 넣고 truncation / summarize / drop 3전략의 응답 품질을 골든셋으로 비교한다.
• 동일 대화를 20턴 진행하며 context rot이 나는 지점을 관찰한다. compaction 주기를 튜닝한다.

프로젝트: Context Manager 라이브러리 — 독립 패키지 + 벤치마크 스크립트(예산 대비 품질 곡선 그래프).

테스트

• [ ] 예산 준수: 출력 토큰 추정치 ≤ budget
• [ ] 우선순위 보존: system·current_task는 절대 드롭 안 됨
• [ ] 결정적 truncation: 동일 입력 → 동일 출력
• [ ] 캐시 프리픽스: 불변 세그먼트가 항상 맨 앞

완료 기준

[ ] 6종 세그먼트를 예산 안에서 조립
[ ] truncate/summarize/drop 3전략을 구현하고 비교 데이터 보유
[ ] context rot을 재현하고 compaction으로 완화
[ ] 예산 대비 품질 곡선을 그래프로 제시

Week 5 — RAG: pgvector 프로덕션 파이프라인 + 검색 평가

목표: pgvector 기반 ingest + 하이브리드 검색 + reranking을 갖춘 /search·/answer API를 만들고, 검색 품질을 지표로 평가한다.

개념: chunking, embedding, vector search, hybrid search(BM25+vector), metadata filter, reranking, query expansion, multi-query retrieval, contextual retrieval. Vector RAG vs Graph RAG vs Hybrid RAG vs Agentic RAG.

반드시 이해할 내용

• chunking 전략(고정 크기 / 문장 / 구조 기반 / contextual)이 recall에 미치는 영향.
• 하이브리드 검색: 벡터는 의미, BM25는 정확한 용어. RRF(reciprocal rank fusion)로 결합한다.
• reranking은 recall을 precision으로 바꾸는 단계다. 비용·지연이 추가된다.
• 검색 평가 지표: recall@k, precision@k, MRR, NDCG(검색), faithfulness·answer relevance(생성).

구현 — rag/

rag/
  ingest.py      # 로드 -> chunk -> (contextual) -> embed -> upsert(pgvector + tsvector)
  search.py      # hybrid: vector + BM25 -> RRF -> rerank
  answer.py      # retrieved -> ContextManager 세그먼트 -> LLM -> 인용 포함 답변
  eval.py        # 골든셋(query, relevant_doc_ids, ideal_answer) 러너
api.py           # FastAPI: POST /search, POST /answer (SSE)

실습

• chunking 3전략 × recall@5 / MRR / faithfulness 측정 표.
• query expansion on/off 비교.

프로젝트: P3 — RAG Agent — 문서 지식베이스에 질문하는 Agent, 답변에 인용 포함, /answer는 SSE 스트리밍.

테스트

• [ ] retrieval eval: 골든셋에서 recall@5 ≥ 목표치
• [ ] faithfulness judge: 근거 없는 주장 탐지
• [ ] 회귀: chunking·프롬프트 변경 시 지표 하락 시 CI 실패
• [ ] 메타데이터 필터가 검색 결과를 실제로 제한

완료 기준

[ ] 하이브리드 검색 + reranking 동작
[ ] recall/precision/MRR/faithfulness를 측정하고 baseline 저장
[ ] 검색 품질 회귀를 CI에서 자동 차단
[ ] 답변에 검증 가능한 인용 포함

Week 6 — Memory Engineering: 추출·저장·충돌·decay

목표: 대화에서 메모리를 추출→타입별 저장→회수하고, 모순을 감지·해결하는 영속 개인 Agent를 만든다.

개념: working / short-term / long-term / episodic / semantic / procedural memory. memory write / update / delete / conflict / decay / retrieval.

반드시 이해할 내용

• RAG(외부 문서 검색) ≠ Memory(이 사용자·세션에 대해 학습한 것). 저장·갱신 로직이 다르다.
• 충돌: "사용자는 서울 거주" vs "사용자는 부산으로 이사" — 타임스탬프·신뢰도로 해결한다.
• decay: 오래되고 참조되지 않은 메모리는 가중치를 낮추거나 아카이브한다.

구현 — memory/

memory/
  extractor.py   # 대화 턴 -> MemoryItem[] (type, content, confidence, source_turn)
  store.py       # Postgres: episodic / semantic / procedural 테이블
  retrieval.py   # query -> recency*relevance 스코어 -> top-k
  reconcile.py   # 신규 아이템 vs 기존 -> merge / supersede / conflict-flag
  decay.py       # 스케줄러: 미참조 아이템 가중치 감소

실습

• 모순되는 사실 2개를 다른 턴에 주입한다. 충돌 감지와 해결 로그를 확인한다.
• 20세션 뒤 retrieval이 관련 메모리를 정확히 불러오는지 측정한다.

프로젝트: P4 — Memory Agent — 세션을 넘어 사용자를 기억하는 개인 비서. Context Manager의 memory 세그먼트로 통합한다.

테스트

• [ ] 추출 정확도: 골든 대화 → 기대 MemoryItem 집합
• [ ] 충돌 해결: supersede 시 이전 값이 비활성화
• [ ] retrieval: 관련 메모리 recall
• [ ] decay 스케줄이 실제로 가중치를 낮춤

완료 기준

[ ] write/update/delete/conflict/decay 전 수명주기 구현
[ ] 모순 주입 테스트를 통과(충돌 감지+해결)
[ ] Memory가 Context Manager 세그먼트로 주입됨