TheArchive of
메뉴

Series / Learning path

Agent Engineering

에이전트 패턴에서 비동기 실행, 상태, 스트리밍, 런타임까지 프로덕션 시스템의 핵심을 순서대로 다룹니다.

Learning Path

제어 흐름에서 프로덕션 계약까지

현장에서 Agent backend를 만들며 부딪힌 문제를 설계 원칙과 구현 패턴으로 정리한 학습 경로입니다.

어디서 시작할까요?

목적에 맞는 시작점

처음부터 읽기에이전트 설계의 여섯 가지 패턴: 도구 호출부터 사람의 승인까지Agent의 제어 흐름과 패턴부터 시작합니다.전체 구조 먼저 보기Agent Backend 한 장 지도: API, Queue, Worker, State, SSE는 어떻게 연결되는가API, Queue, Worker, State와 SSE의 책임을 한 장에 봅니다.

Stage 1

설계와 전체 구조

에이전트의 제어 패턴과 이를 실행할 backend의 전체 책임 경계를 먼저 그립니다.

Agent와 backend는 각각 무엇을 책임해야 하는가?

01–022편
  1. 01

    foundation

    에이전트 설계의 여섯 가지 패턴: 도구 호출부터 사람의 승인까지

    거대한 자율 루프 대신, 경계가 분명한 제어 흐름을 조합하는 법

    →
  2. 02

    foundation

    Agent Backend 한 장 지도: API, Queue, Worker, State, SSE는 어떻게 연결되는가

    실행 architecture의 책임 경계 — mental model, failure mode, 선택적 deep dive

    →

Stage 2

실행과 오케스트레이션

비동기, 스레드, 워커와 parent-child run으로 실행을 분리하고 조정합니다.

오래 걸리는 실행을 어떻게 분리하고 병렬화할 것인가?

03–064편
  1. 03

    foundation

    에이전트는 왜 Async가 필요한가: 기다리는 동안 다른 일을 시키는 법

    LLM, DB, 검색 API를 기다리는 시간을 동시성으로 바꾸는 실행 모델

    →
  2. 04

    foundation

    Async, Thread, Process: Agent Worker를 이해하기 전에 알아야 할 것

    기다리는 작업, blocking SDK, CPU-bound 계산에는 서로 다른 실행 도구가 필요하다

    →
  3. 05

    foundation

    Worker는 Thread가 아니다: Agent 실행을 API 서버에서 분리하는 이유

    동시성 기본 요소와 실행 수명 주기의 책임을 구분하는 Agent backend 설계

    →
  4. 06

    foundation

    Multi-Agent는 Agent를 여러 개 띄우는 것이 아니다: Parent Run, Fan-out, Fan-in

    Child run의 lifecycle, 격리된 state와 부분 실패를 하나의 실행 트리로 다루는 법

    →

Stage 3

상태와 내구성

영속 상태, 실시간 투영, event와 session ownership의 경계를 구분합니다.

실행 상태는 어디에 저장되고 누구에게 속하는가?

06–072편
  1. 06

    foundation

    Agent State는 어디에 있어야 하는가: PostgreSQL, Redis, Checkpoint

    영속 기록, 실시간 투영, 재개 snapshot은 서로 다른 실패를 견딘다

    →
  2. 07

    foundation

    State는 Event가 아니다: 실시간 Agent UI 설계법

    Snapshot으로 화면을 복원하고 timeline과 cursor로 변화를 놓치지 않는 법

    →

Stage 4

안전한 실행과 복구

승인, 멱등성, 재시도, 취소, checkpoint와 권한 경계를 하나의 복구 계약으로 연결합니다.

중복·장애·취소·권한 오류를 어떻게 견딜 것인가?

08–081편
  1. 08

    foundation

    Agent Tool은 정확히 한 번 실행될 수 있을까: 승인, 멱등성, 재시도

    송금 Tool을 두 번 실행하지 않기 위해 사용자 의도와 실행 결과를 연결하는 법

    →

Stage 5

전달과 운영 경계

스트리밍, runtime, 배포, 관측과 과부하 제어를 프로덕션 전달 계층으로 묶습니다.

실행 사실을 어떻게 전달하고 관찰하며 운영할 것인가?

09–102편
  1. 09

    foundation

    Agent가 일하면서 말하게 하기: SSE, Generator, Redis Streams

    Async generator로 snapshot과 event를 HTTP 연결에 안전하게 흘려보내는 법

    →
  2. 10

    foundation

    LangGraph는 Architecture가 아니다: Runtime의 정확한 위치

    Graph state와 애플리케이션 state를 분리해 worker, Redis, DB, 브라우저의 책임을 설계하는 법

    →

Applied Track

Inference Serving · vLLM

내부 GPU에서 vLLM으로 서빙하는 이유, 튜닝, 성능 진단까지 이어지는 선택형 실전 경로

Applied Track · 3편

Inference Serving · vLLM

내부 GPU에서 모델을 선택하고, 튜닝하고, 병목을 진단하는 실전 과정

  1. 01

    foundation2026년 9월 19일

    왜 내부 GPU에서 vLLM으로 LLM을 서빙하는가?

    보안·데이터 통제·비용·성능 관점에서 내부 오픈소스 LLM과 vLLM 도입을 판단하기

  2. 02

    implementation2026년 9월 22일

    vLLM 튜닝이란 무엇인가?

    GPU가 적을 때 LLM을 서빙하는 방법

  3. 03

    implementation2026년 9월 24일

    vLLM은 왜 느려졌을까?

    TTFT·TPOT·KV cache로 병목을 찾는 법