이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.
TL;DR
AI 에이전트 기술은 6개월마다 스택이 바뀔 정도로 빠르게 진화하며 기존 아키텍처를 계속 재작성하게 만든다. 이를 해결하기 위해 에이전트 시스템을 실행(Execution), 컨텍스트(Context), 컴퓨트(Compute) 계층으로 분리하고, 특히 실행 계층을 독립적인 내구성(durability)과 관측 가능성(observability)을 갖춘 기반으로 구축해야 한다. 이러한 계층 분리는 모델이나 도구가 바뀌어도 전체 시스템을 재작성할 필요 없이 유연하게 대응할 수 있는 구조를 제공한다.
챕터별 상세
에이전트 아키텍처의 문제: 스택의 휘발성
에이전트 기술은 6개월마다 새로운 표준이 등장하며 기존 아키텍처를 무용지물로 만든다. RAG, ReAct, 프롬프트 체이닝, 오케스트레이터-워커, MCP, CLI 등 새로운 트렌드가 나올 때마다 전체 시스템을 재작성하는 상황이 반복된다. 이는 단순한 불만이 아니라 기술 발전 속도가 아키텍처 수명을 앞지르는 현실이다.
에이전트 아키텍처의 3계층 모델
에이전트 시스템은 실행(Execution), 컨텍스트(Context), 컴퓨트(Compute)의 3개 계층으로 구성된다. 실행 계층은 두뇌 역할을 하며 흐름, 상태, 내구성, 재시도를 담당한다. 컨텍스트 계층은 지식 역할을 하며 모델, 프롬프트, 도구, 메모리, RAG를 포함한다. 컴퓨트 계층은 손 역할을 하며 샌드박스, 런타임, 브라우저를 담당한다.
아키텍처의 반감기(Half-life) 개념
아키텍처의 각 계층은 서로 다른 속도로 가치가 하락한다. 프롬프트는 수주, 모델은 수개월 내에 교체될 가능성이 높다. 반면 실행 계층은 올바르게 설계하면 수년간 유지될 수 있다. 계층을 결합하면 한 계층의 변화가 전체 시스템을 재작성하게 만드는 기술적 부채가 된다.
실행 계층(Execution Layer)의 정의
실행 계층은 코드의 신뢰성 있는 실행을 담당하는 시스템이다. 작업의 수행 방법, 시기, 완료 여부를 관리하며, 실행되는 인프라와는 독립적으로 작동한다. 이 계층이 안정적이어야 상위 계층의 변화에도 시스템 전체를 재작성하지 않고 유연하게 대응할 수 있다.
내구성 있는 실행: 재시작이 아닌 재개
에이전트 작업은 장시간 실행되는 경우가 많으므로 실패 시 처음부터 다시 시작하지 않고 중단된 지점에서 재개할 수 있어야 한다. 이를 위해 상태는 작업 외부의 내구성 있는 저장소에 보관되어야 한다. 3시간짜리 작업에서 38번째 단계가 실패해도 1단계부터 다시 시작하지 않고 38단계부터 재개하여 비용과 시간을 절감한다.
유연한 호출과 비동기 조율
에이전트는 크론, 이벤트, API, 승인 등 다양한 방식으로 호출될 수 있어야 한다. 또한 서브 에이전트나 동적 워크플로를 동기 또는 비동기 방식으로 호출하고 조율하는 기능이 필요하다. 실행 계층은 이러한 다양한 호출 패턴을 통합하여 관리하는 역할을 수행한다.
세션 전체의 관측 가능성
에이전트 디버깅을 위해서는 LLM 호출뿐만 아니라 데이터베이스 오류, 권한 문제, 성능 지표 등 세션 전체의 흐름을 추적해야 한다. 트리거부터 최종 결과까지 전체 스택의 트레이스를 확보하지 못하면 시스템 개선이 불가능하다. 실행 계층은 이 모든 과정을 기록하는 허브 역할을 한다.
샌드박스와 실행의 분리
샌드박스는 코드를 실행하는 환경이지만 상태를 유지하지 않는 휘발성 공간이다. 샌드박스를 내구성 있는 상태 저장소로 사용하려는 시도는 안티 패턴이다. 실행 계층이 샌드박스에 컨텍스트, 순서, 내구성을 제공하여 샌드박스는 오직 코드 실행이라는 본연의 역할에 집중하게 해야 한다.
실전 예시: 백그라운드 에이전트
백그라운드 에이전트는 요청-응답 방식이 아니며 사용자가 기다리지 않는다. 3시간 동안 수백 번의 도구 호출을 수행하며 최소 한 번 이상의 실패가 발생할 확률이 높다. 적절한 실행 계층 없이는 이러한 에이전트를 디버깅하거나 운영하는 것이 불가능하다.
실전 예시: 루프 아키텍처
루프 아키텍처는 주기적으로 시스템 상태를 평가하고 다음 작업을 결정하는 시스템이다. 크론 에이전트가 상태를 확인하고, 문제가 있으면 트리아지 에이전트를 호출하며, 마지막으로 리뷰 에이전트가 전체 성능을 평가한다. 이 과정은 실행 계층의 내구성과 관측 가능성에 의존한다.
코드 구현: 헬스 체크와 트리아지
헬스 체크 함수는 30분마다 실행되어 메트릭을 수집하고 LLM으로 상태를 평가한다. 상태가 비정상이면 트리아지 에이전트를 호출한다. 트리아지 에이전트는 상세 메트릭과 최근 배포 정보를 결합하여 근본 원인을 분석한다. 이 코드는 실행 계층의 내구성 기능을 활용하여 안정적으로 작동한다.
코드 구현: 리뷰어 함수
리뷰어 함수는 매주 실행되어 지난주 인시던트 기록을 바탕으로 트리아지 에이전트의 성능을 평가한다. 성공률, 평균 지속 시간 등을 분석하여 에이전트의 개선점을 도출한다. 이 함수는 실행 계층의 관측 데이터를 활용하여 시스템의 지속적인 개선 루프를 완성한다.
에이전트 평가와 피드백 루프
에이전트의 성능을 평가하기 위해서는 사용자 피드백과 실행 결과를 연결해야 한다. 실행 계층은 트레이스와 스코어를 연결하여 인사이트를 도출하는 최적의 장소이다. 단순히 성공 여부만 판단하는 것이 아니라, 배포 성공 여부 등 실제 비즈니스 성과와 연결된 지표로 에이전트를 평가해야 한다.
javascript
export const infraHealthCheck = ingest.createFunction(
{ id: "infra-health-check" },
{ cron: "*/30 * * * *" }, // Every 30 minutes
async ({ step }) => {
const metrics = await step.run("fetch-service-metrics", async () => { /* fetch error rates, latency, memory, CPU */ });
const assessment = await step.run("assess-health", async () => {
return await callLLM(`Given these service metrics, classify overall system health as "normal", "degraded", or "critical". Explain your reasoning. Metrics: ${JSON.stringify(metrics)}`);
});
if (assessment.status === "degraded" || assessment.status === "critical") {
await step.invoke("trigger-incident", { function: incidentTriage });
}
}
);30분마다 실행되는 크론 작업으로, 서비스 메트릭을 수집하고 LLM을 통해 시스템 상태를 평가하여 문제가 있을 경우 인시던트 트리거를 호출하는 예시
용어 해설
- 내구성 있는 실행(Durable Execution)
- — 작업 중 실패가 발생해도 처음부터 다시 시작하지 않고, 상태를 유지하며 중단된 지점부터 재개하는 방식이다. 에이전트의 신뢰성과 복구 가능성을 확보하는 데 필수적이다.
- 오케스트레이션(Orchestration)
- — 여러 에이전트, 도구, 작업 간의 복잡한 흐름을 제어하고 조율하는 과정이다. 에이전트 시스템에서 작업의 순서와 의존성을 관리하는 핵심 메커니즘이다.
- 관측 가능성(Observability)
- — 시스템 내부 상태를 외부에서 파악할 수 있도록 로그, 트레이스, 메트릭 등을 기록하는 것이다. 에이전트의 의사결정 과정과 오류 원인을 디버깅하는 데 필수적이다.
언급된 리소스
문서Inngest
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료
출처 · 인용 안내
원문 발행 2026. 07. 21.수집 2026. 07. 21.출처 타입 YOUTUBE
인용 시 "요약 출처: AI Trends (aitrends.kr)"를 표기하고, 사실 확인은 원문 보기 기준으로 진행해 주세요. 자세한 기준은 운영 정책을 참고해 주세요.
