Series / Learning path
Agent Engineering
Agent의 제어 흐름에서 시작해, 실패해도 복구되는 프로덕션 시스템까지 이어지는 5단계 학습 경로입니다.
읽기 경로
설계에서 운영까지, 필요한 순서대로
Agent 백엔드를 설계하고 운영할 때 마주치는 문제를, 구현에 필요한 순서대로 정리했습니다.
빠른 시작
지금 필요한 방식으로 시작하세요
1단계
설계와 전체 구조
에이전트의 제어 패턴과 이를 실행할 backend의 전체 책임 경계를 먼저 그립니다.
Agent와 backend는 각각 무엇을 책임해야 하는가?
- 01→
에이전트 설계의 여섯 가지 패턴: 도구 호출부터 사람의 승인까지
거대한 자율 루프 대신, 경계가 분명한 제어 흐름을 조합하는 법
- 02→
에이전트 백엔드 한 장 지도: API·queue·Worker·state·SSE는 어떻게 연결되는가
실행 구조의 책임 경계: 전체 관점, 실패 상황, 필요한 곳의 자세한 설명
2단계
실행과 오케스트레이션
비동기, 스레드, 워커와 parent-child run으로 실행을 분리하고 조정합니다.
오래 걸리는 실행을 어떻게 분리하고 병렬화할 것인가?
- 03→
에이전트 시스템에 비동기가 필요한 이유: 기다리는 동안 다른 일을 진행하는 법
LLM·데이터베이스·검색 API의 대기 시간을 처리량으로 바꾸는 실행 모델
- 04→
비동기·thread·프로세스: 에이전트 Worker를 이해하기 전에 알아야 할 것
기다리는 작업, 블로킹 SDK, CPU 중심 계산에는 서로 다른 실행 도구가 필요하다
- 05→
Worker는 thread가 아니다: 에이전트 실행을 API 서버에서 분리하는 이유
동시성 도구와 실행 수명 주기의 책임을 구분하는 에이전트 백엔드 설계
- 06→
Multi-Agent는 Agent 여러 개를 띄우는 일이 아니다: Parent Run, Fan-out, Fan-in
Child Run의 수명 주기, 격리된 state와 부분 실패를 하나의 실행 트리로 다루는 법
3단계
state와 내구성
영속 state, 실시간 투영, event와 session ownership의 경계를 구분합니다.
실행 state는 어디에 저장되고 누구에게 속하는가?
- 07→
Agent State는 어디에 있어야 할까: PostgreSQL, Redis, Checkpoint
영속 기록, 실시간 투영, 재개용 snapshot은 각기 다른 장애 상황에 대비한다
- 08→
State는 Event가 아니다: 실시간 Agent UI 설계법
Snapshot으로 화면을 복원하고 timeline과 cursor로 놓친 변화를 안전하게 되돌리는 법
- 09→
Conversation은 Run이 아니다: Session Isolation 설계
지속되는 대화와 한 번의 실행을 분리하고, tenant·user·session·run의 소유권을 지키는 법
4단계
안전한 실행과 복구
승인, 멱등성, 재시도, 취소, checkpoint와 권한 경계를 하나의 복구 계약으로 연결합니다.
중복·장애·취소·권한 오류를 어떻게 견딜 것인가?
- 10→
Agent Tool은 정확히 한 번 실행될 수 있을까: 승인, 멱등성, 재시도
송금 Tool을 두 번 실행하지 않기 위해 사용자 의도와 실행 결과를 연결하는 법
- 11→
Worker가 죽으면 어떻게 되는가: Queue, XREADGROUP, XACK, Retry
전달된 작업과 완료된 작업을 구분하고, 죽은 consumer의 pending job을 안전하게 회수하는 법
5단계
전달과 운영 경계
스트리밍, runtime, 배포, 관측과 과부하 제어를 프로덕션 전달 계층으로 묶습니다.
실행 사실을 어떻게 전달하고 관찰하며 운영할 것인가?
- 16→
Agent가 일하면서 말하게 하기: SSE, Generator, Redis Streams
Async generator로 snapshot과 event를 HTTP 연결에 안전하게 흘려보내는 법
- 17→
LangGraph는 Architecture가 아니다: Runtime의 정확한 위치
Graph state와 애플리케이션 state를 분리해 worker, Redis, DB, 브라우저의 책임을 설계하는 법
- 19→
사용자 요청이 에이전트에서 처리되기까지
사용자가 보낸 요청이 큐와 워커를 거쳐 처리되고, 결과가 다시 화면에 보이기까지
실전 트랙
Inference Serving · vLLM
내부 GPU에서 vLLM으로 서빙하는 이유, 튜닝, 성능 진단까지 이어지는 선택형 실전 경로
실전 트랙 · 3편
Inference Serving · vLLM
내부 GPU에서 모델을 선택하고, 튜닝하고, 병목을 진단하는 실전 과정
- 01
왜 내부 GPU에서 vLLM으로 LLM을 서빙하는가?
보안·데이터 통제·비용·성능을 기준으로 내부 오픈소스 LLM과 vLLM 도입을 판단하는 법
- 02
vLLM 튜닝이란 무엇인가?
제한된 GPU에서 LLM을 안정적으로 서빙하는 방법
- 03
vLLM이 느려졌을 때: TTFT·TPOT·KV cache로 병목을 진단하는 법
증상·지표·가설·한 변수 실험으로 vLLM 서빙 병목을 좁히는 방법