AI AgentEngineering
2026 AI Agent Engineer 학습 커리큘럼 (5) 프로덕션·포트폴리오·체크리스트
Production Ready 분류, 피해야 할 학습법, 포트폴리오 기준, 단계별 완료 체크리스트.
송민성6분 읽기
이 글은 5편짜리 시리즈의 5편입니다.
시리즈 목차
- 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 학습 커리큘럼 (5) 프로덕션·포트폴리오·체크리스트
10. Production Ready / Emerging / Experimental 분류
판단 축: (a) API·동작 안정성, (b) 프로덕션 채택 사례, (c) 문서·생태계 성숙도, (d) 대체재 대비 이점의 명확성.
Production Ready — 지금 프로덕션에 써도 되는 것
| 기술 | 판단 근거 |
|---|---|
| Python 3.13 / uv / Pydantic / FastAPI / httpx / pytest | 광범위 채택, 안정적 API, 성숙한 문서. Agent와 무관하게 검증됨. |
| OpenAI API · Anthropic API (chat, tool calling, streaming, structured output) | 핵심 기능 안정. 요금·한도 예측 가능. 다수 프로덕션. |
| PostgreSQL + pgvector | 성숙. 벡터 검색을 별도 인프라 없이. |
| Redis (큐·캐시·rate limit) | 표준. |
| Docker / Compose / GitHub Actions | 표준 CI/CD. |
| OpenTelemetry (tracing·metrics) | 벤더 중립 관측 표준. Agent trace에 직접 적용. |
| MCP (Model Context Protocol) | 2025 표준화 후 클라이언트·서버·SDK 생태계가 빠르게 성숙. 도구 연결의 사실상 표준으로 정착. |
| Next.js / TypeScript / Tailwind | 프론트 표준. |
| RAG 기본 패턴 (chunk·embed·hybrid search·rerank) | 잘 정립된 레시피. 평가 방법도 성숙. |
| LLM-as-a-judge (편향 완화 적용 시) | 방법론 정착. 한계(편향)도 잘 문서화됨. |
Emerging — 프로덕션 채택되고 있으나 API·모범사례가 아직 이동 중
| 기술 | 판단 근거 |
|---|---|
| LangGraph | 실사용 많음. 상태·체크포인트 모델 유용. 다만 API·패턴이 계속 진화. |
| PydanticAI | 타입 안정 Agent에 강점. 생태계는 성장 중. |
| OpenAI Agents SDK | provider 제공 런타임. 채택 초기, 기능 확장 중. |
| LlamaIndex | RAG 유틸로 성숙했으나 Agent 기능은 이동 중. |
| Agentic RAG / contextual retrieval | 효과 입증되나 구현 표준화 전. 비용·지연 트레이드오프 큼. |
| Trajectory eval / agent eval 프레임워크 | 필요성 합의됨. 도구·지표 표준은 형성 중. |
| Structured output 강제 (스키마·제약 디코딩) | provider별 신뢰도·문법 지원이 다름. 개선 중. |
| Temporal / Prefect for agents | 장기 실행·재시도에 강점. Agent 특화 패턴은 아직 관용구 정착 전. |
| Prompt caching 활용 전략 | 효과 크나 provider별 규칙·수명이 달라 이식성 낮음. |
Experimental — 연구·PoC 단계, 프로덕션 의존 금지
| 기술 | 판단 근거 |
|---|---|
| DSPy (프롬프트/파이프라인 자동 최적화) | 강력한 아이디어. 운영 안정성·디버깅·재현성은 미성숙. |
| Multi-agent debate / swarm / blackboard | 특정 벤치에서 이득. 비용·지연·불안정성이 커서 일반 프로덕션엔 시기상조. |
| 자율 다일(multi-day) Agent | 신뢰성·비용 통제·안전이 미해결. |
| Self-improving / self-modifying Agent | 안전·평가 프레임워크 부재. 격리된 실험만. |
| 장기 기억(long-term memory) 프레임워크 | 충돌·decay·프라이버시 처리가 제각각. 직접 구현이 아직 더 안전. |
| Graph RAG (지식그래프 기반) | 특정 도메인에서 유효. 구축·유지 비용이 커서 범용 아님. |
| LLM 기반 코드 실행 자율 배포(사람 승인 없이) | 금지. HITL 필수. |
분류를 대하는 법: Production Ready로 코어를 짓는다. Emerging은 격리된 모듈로 들여와 eval로 검증한다. Experimental은 별도 브랜치·별도 예산으로만 다룬다. "새롭다"는 이유로 코어에 넣지 않는다.
11. 피해야 할 잘못된 학습 방법
| 안티패턴 | 왜 나쁜가 | 대신 |
|---|---|---|
| 프레임워크부터 시작 (LangGraph로 첫 Agent) | 추상화가 원리를 가린다. 문제 생기면 프레임워크 내부를 못 본다. | 각 계층을 vanilla로 만든 뒤 프레임워크와 비교. |
| 튜토리얼 코드 복사 | 설계 감각이 안 생긴다. 변형을 못 한다. | 스펙을 받고 직접 설계·구현. 튜토리얼은 읽고 덮기. |
| Happy path만 구현 | 실제 Agent 실패의 90%가 엣지에서 온다. | 무한 루프·도구 실패·인젝션·컨텍스트 초과·비용 폭발·데드락을 의도적으로 재현. |
| Eval 없이 "느낌"으로 개선 | 개선인지 회귀인지 모른다. | L2부터 모든 프로젝트에 골든셋 + 회귀 게이트. |
| Observability를 나중으로 | 계측 지점을 놓치고, 비결정적 버그를 못 잡는다. | Harness 만들 때부터 span emit. |
| 비용·토큰 측정 안 함 | Agent는 호출당 수십~수백 LLM 콜. 단가 모르면 사업성 없음. | 모든 실행에 token/latency/cost/success 기록. cost per successful task를 KPI로. |
| Context = 프롬프트 문자열 이어붙이기 | 예산·우선순위·압축이 없어 품질이 무너진다. | Context Manager를 별도 컴포넌트로. |
| 단일 Agent도 못 만들고 멀티에이전트 | 불안정한 노드 여러 개 = 디버깅 불가능. | 안정적 단일 Loop → 그다음 Graph. |
| 벤치마크 점수 좇기 | 벤치 ≠ 당신의 실제 태스크. | 도메인 골든셋을 직접 만들어 측정. |
| 모델 교체로 문제 해결 시도 | 대부분은 harness·context·loop 문제. | trace를 보고 원인 계층을 특정. |
| 무한 루프/비용 상한 없이 배포 | 한 번의 폭주로 청구서 폭발. | 배포 전 7종 정지 조건 + cost guard 필수. |
| HITL 없이 되돌릴 수 없는 액션 자동화 | 잘못된 배포·삭제·이메일·머지. | payment/delete/deploy/migration/email/merge는 무조건 gate. |
| 인젝션을 "프롬프트로 막으면 됨" | 간접 인젝션은 프롬프트만으로 못 막는다. | allowlist + sandbox + output validation 다층. |
| 프롬프트를 버전·테스트 없이 수정 | 한 케이스 고치면 다른 케이스가 깨진다. | 프롬프트도 버전 태그 + 회귀 스위트. |
12. 취업 및 포트폴리오 기준
GitHub 리포지토리 (프로젝트마다)
text
project/
├── app/{agents,context,graph,harness,loops,memory,tools,evals,api}/
├── tests/
├── evals/ # 골든셋 + 러너 + baseline 결과
├── docs/
│ ├── architecture.md # 다이어그램 + 데이터 흐름
│ └── decisions.md # 왜 이 설계인지 (ADR)
├── AGENTS.md # Agent 스펙 (역할·도구·정지조건·gate)
├── pyproject.toml
├── Dockerfile
├── docker-compose.yml
└── README.md # 실행법 + 아키텍처 요약 + eval 결과표 + cost/latency 표반드시 보여줄 4가지 증거
- Trace viewer 스크린샷 — 한 실행의 span 트리(node → loop → llm/tool). "관측 가능한 Agent"를 보여 준다.
- Eval regression 리포트 — baseline vs 현재, 케이스별 통과/실패, 지표 표. "eval-driven"을 보여 준다.
- 비용 대시보드 — cost per successful task, p95 latency, retry rate. "운영을 안다"를 보여 준다.
- Security 테스트 결과 — 인젝션 스위트 통과율(baseline → 방어 후), exfiltration 차단. "안전을 안다"를 보여 준다.
지표로 말하기 (이력서·면접)
- "Autonomous coding agent: task success 62% → 84%, cost/successful task $0.11, p95 latency 8s, human escalation rate 9%."
- "RAG: recall@5 0.71 → 0.88 (contextual retrieval + rerank), faithfulness judge 0.93."
- "멀티에이전트 워크플로우: 단일 Agent 대비 성공률 +12%p, 비용 2.3배, 지연 1.8배 — 검증 분리가 필요한 태스크에서만 채택."
면접 대비 질문 (직접 설명할 수 있어야 함)
- Harness와 model의 책임 경계는? Coding agent 성능은 어디서 오는가?
- Context rot을 어떻게 감지하고 완화했나?
- Agent Loop의 정지 전략 7가지와 각각의 트리거는?
- LLM-judge의 편향 종류와 완화 방법은?
- 멀티에이전트를 쓰지 말아야 할 경우는?
- 간접 프롬프트 인젝션을 프롬프트만으로 막지 못하는 이유와 다층 방어는?
cost per successful task가 왜cost per task보다 나은 지표인가?
대표 프로젝트 3개 (포트폴리오 상단)
- RAG + Eval API (P3) — 검색 품질을 측정·회귀 방지.
- Autonomous Coding Agent (P7) — harness + loop, 수치로 증명.
- Production AI Agent Platform (Final) — 전 계층 통합, 운영 런북.
자기 평가표 (목표 도달 여부)
| 역량 | 목표 | 자기 평가 |
|---|---|---|
| Context Engineering | L4 | ☐ L1 ☐ L2 ☐ L3 ☐ L4 |
| Tool Engineering | L4 | ☐ L1 ☐ L2 ☐ L3 ☐ L4 |
| Harness Engineering | L4 | ☐ L1 ☐ L2 ☐ L3 ☐ L4 |
| Loop Engineering | L4 | ☐ L1 ☐ L2 ☐ L3 ☐ L4 |
| Graph Engineering | L3~L4 | ☐ L1 ☐ L2 ☐ L3 ☐ L4 |
| Evaluation Engineering | L4 | ☐ L1 ☐ L2 ☐ L3 ☐ L4 |
| Agent Security | L3 | ☐ L1 ☐ L2 ☐ L3 ☐ L4 |
| Production Architecture | L4 | ☐ L1 ☐ L2 ☐ L3 ☐ L4 |
13. 단계별 완료 체크리스트
Phase A — Foundations (Week 1–3 / 24주: 1–3)
text
[ ] 프레임워크 없이 두 provider를 동일 인터페이스로 호출
[ ] 스트리밍 파싱·토큰·비용·지연 계측
[ ] structured output을 스키마로 강제하고 검증
[ ] tool registry + 단일 tool loop(3종 실패 처리)
[ ] 시스템 프롬프트 계층화 + 버전 관리
[ ] 직접·간접 프롬프트 인젝션 재현 + 기초 방어 수치Phase B — Context & Retrieval (Week 4–6 / 24주: 4–7)
text
[ ] Context Manager: 6종 세그먼트 · 예산 준수 · 우선순위 보존
[ ] truncate/summarize/drop 3전략 + 품질 곡선
[ ] context rot 재현 + compaction 완화
[ ] 하이브리드 검색 + reranking
[ ] recall/precision/MRR/faithfulness baseline + CI 회귀 게이트
[ ] Memory 전 수명주기(write/update/delete/conflict/decay)
[ ] 모순 주입 테스트 통과
[ ] Memory·RAG가 Context Manager 세그먼트로 통합Phase C — Protocol / MCP (Week 7 / 24주: 8–9)
text
[ ] MCP 서버·클라이언트 양쪽 직접 구현
[ ] tools + resources + prompts
[ ] stdio·HTTP transport 양쪽 동작
[ ] 도구 동적 발견 → registry 자동 통합
[ ] 권한 경계·에러 전파·poisoning 방어 테스트Phase D — Harness (Week 8 / 24주: 10–12)
text
[ ] 모든 도구 실행이 permission + sandbox + trace + budget 통과
[ ] 위험 도구 격리를 침투 시도로 검증
[ ] token/time/iteration budget 컷 각각 동작
[ ] verify(test/lint/type/security)를 harness가 호출
[ ] execution trace로 한 실행을 완전 재구성Phase E — Loop (Week 9 / 24주: 13–15)
text
[ ] plan-act-observe-evaluate 루프가 harness 위에서 동작
[ ] 7종 정지 조건(max_iter/timeout/token/cost/progress/dedup/escalation) 전부 구현·테스트
[ ] 진행 정체 감지 → escalation 리포트
[ ] 중복 행동 감지 → 차단
[ ] 실제 이슈 벤치 성공률·cost per successful task 기록Phase F — Graph (Week 10 / 24주: 16–18)
text
[ ] vanilla graph engine: 조건부 엣지 · 병렬+join · 체크포인트 · human gate
[ ] 동일 그래프를 LangGraph로 재구현 + 트레이드오프 문서
[ ] 멀티에이전트 워크플로우가 안정적으로 종료 또는 escalate
[ ] 체크포인트에서 재개
[ ] "멀티에이전트를 쓰지 말아야 할 때" 판단 기준 정리Phase G — Evaluation (Week 11 / 24주: 19–21)
text
[ ] deterministic + LLM-judge + trajectory eval을 한 러너에서
[ ] 8개 agent 지표 계산 + baseline 저장
[ ] judge 편향 측정(위치·장황함) + 완화 적용
[ ] 회귀를 CI에서 자동 차단
[ ] (24주) 온라인 eval / shadow 실행 + 오프라인 지표 정합Phase H — Production (Week 12 / 24주: 22–24)
text
[ ] 전 계층이 OpenTelemetry span으로 관측 + replay 가능
[ ] 다층 방어로 injection·exfiltration 차단(수치 제시)
[ ] 되돌릴 수 없는 액션 전부 human gate 통과
[ ] cost governance(per-run + daily cap + alert) 동작
[ ] circuit breaker → fallback 무중단
[ ] Docker Compose 원커맨드 기동
[ ] CI 게이트: lint → type → test → eval(regression) → build
[ ] e2e smoke: UI → API → worker → graph → 결과
[ ] (24주) 운영 런북 + 부하 테스트(동시 100요청 p95)최종 도달 확인
text
[ ] Context / Harness / Loop / Graph / Eval을 각각 vanilla로 구현했다
[ ] 각 프로젝트에 eval·trace·비용 측정이 있다
[ ] Final Platform이 원커맨드로 뜨고 CI 게이트를 통과한다
[ ] 포트폴리오에 4가지 증거(trace/eval regression/cost/security)가 있다
[ ] 배운 것을 남에게 설명할 수 있다 (면접 질문 목록 전부)부록 — 학습 원칙 요약
- Framework First 금지 — Vanilla Python → 아키텍처 이해 → Framework.
- Tutorial Copy 금지 — 스펙을 받고 직접 설계.
- Production 중심 — Toy example 대신 운영 가능한 구조.
- Evaluation 필수 — 모든 Agent 프로젝트에 eval.
- Observability 필수 — 모든 실행이 trace로 남는다.
- 비용 측정 — token / latency / cost / success rate를 항상 기록.
- 실패 사례 학습 — Infinite Loop · Tool Failure · Hallucination · Context Overflow/Pollution · Prompt Injection · Agent Deadlock · Graph Failure · Memory Poisoning · Cost Explosion을 의도적으로 재현.