에이전트 아키텍처의 반감기는 6개월 — Dan Farrelly (Inngest CTO)

1. 핵심 주장 (What)

Inngest의 CTO 겸 공동창업자 Dan Farrelly는 "6개월 이상 에이전트를 만들어봤다면, 아마 최소 한 번은 아키텍처를 다시 짜봤을 것"이라는 관찰에서 발표를 시작한다. 새 모델, 새 프레임워크(혹은 프레임워크 버전), 새로운 tool calling 표준, 새로운 패턴이 나올 때마다 기존 아키텍처가 안 맞아버리는 건 불평할 일이 아니라 그냥 현재의 현실이라는 것이다.

그는 에이전트 시스템을 세 개의 개념적 레이어로 나눠 생각하라고 제안한다. 특정 컴포넌트나 다이어그램이 아니라 "멘탈 모델"로서의 레이어다.

1. 실행 레이어(Execution layer) — "뇌(brain)"에 해당. 플로우, 상태, durability, 재시도(retry)가 일어나는 곳.
2. 컨텍스트 레이어(Context layer) — "지식(knowledge)"에 해당. 모델, 프롬프트, 툴, 메모리. 가장 빠르게 변하는 레이어.
3. 컴퓨트 레이어(Compute layer) — "손(hands)"에 해당. 샌드박스, 런타임, 브라우저 등 자동화 실행 환경.

핵심 주장은, 이 세 레이어 각각에 서로 다른 "반감기(half-life)"가 있다는 것. 반감기란 원래 방사성 붕괴에서 쓰는 과학 용어로, 어떤 것이 절반으로 줄어드는 데 걸리는 시간을 뜻한다. 그는 아키텍처에도 이 개념이 적용된다고 본다.

• 프롬프트의 반감기: 운이 좋아야 몇 주(때로는 단 일주일).
• 모델의 반감기: 운이 좋아야 몇 개월.
• 실행(execution)의 반감기: 제대로 설계했다면 수년.

결론적 테제는 단순하다: 레이어별로 생각하고, 서로 분리(decouple)하라. 그리고 그중에서도 실행 레이어에 투자하라는 것 — 여기가 안정적인 층이라서, 제대로 추상화해두면 6개월마다 큰 컴포넌트를 다시 쓸 필요가 없어진다는 것이다.

2. 근거와 논리 (Why)

많은 팀이 이 세 레이어를 전부 하나로 뭉쳐버리는 게 문제라고 지적한다. 그렇게 되면 한 레이어의 반감기가 다른 레이어를 "끌고 내려가는" 현상이 생긴다 — 이게 바로 기술 부채의 또 다른 이름이라는 것.

팀들이 선택하는 접근법 세 가지 모두 이런 문제에 취약하다:

• 프레임워크를 골랐을 때: 시작은 마법처럼 쉽지만
• 프론티어 랩 등에서 미리 만들어진 harness를 가져왔을 때
• 처음부터 직접 커스텀으로 전체 시스템을 만들었을 때 (몇 주~몇 달 소요)

이 세 경우 모두에서 공통적으로 나타나는 문제는: 추상화가 아예 없거나, 너무 고수준이거나, 레이어들이 뒤섞여버리는 것. 오케스트레이션이 체인이나 프레임워크 안 깊숙이 파묻혀서 뭐가 일어나는지 알 수 없고, 상태(state)가 샌드박스 안에 보관되고, 재시도 로직이 프롬프트 로직과 뒤엉킨다. 결과적으로 거의 모든 걸 다시 쓰지 않고는 이 중 어느 하나도 교체할 수 없는 상태가 된다.

그래서 그는 "변화를 받아들이되(embrace the change), 안정적인 레이어에 투자해서 추상화를 제대로 해두라"고 말한다. 실행 레이어를 "코드를 안정적으로 실행하고, 각 작업이 언제 어떻게 완료되는지(혹은 완료되지 않는지)를 관리하는 시스템 — 그 인프라와는 독립적으로" 라고 정의한다.

에이전트 아키텍처에서 실행 레이어가 담당하는 전체 생명주기는 다음과 같다: 계획(plan), 모델 호출, 코드 실행, 서브에이전트 호출, 루프, 재시도, 조율(coordinate). 모델을 바꾸든 컨텍스트를 바꾸든 샌드박스를 바꾸든, 실행 레이어 자체는 그대로 유지될 수 있어야 한다는 게 핵심 로직이다.

3. 구체적 사례/데이터 (How)

실행 레이어가 반드시 해야 할 세 가지 일:

1. 재개 가능성(Resumability) — 실행 레이어는 실패 후 처음부터 다시 시작하지 않고 이어서 재개할 수 있어야 한다. 에이전트가 갈수록 더 장시간 작업을 처리하기 때문에, LLM 호출이 실패하든 툴 호출이 실패하든 어디서든 문제가 생길 수 있다는 걸 전제해야 한다. 예를 들어 38번째 스텝에서 실패했다면 처음부터 다시가 아니라 그 지점에서 재시도/대기/계속 진행할 수 있어야 하며, 그렇지 않으면 토큰, 비용, 시간, 이미 완료한 작업을 잃게 된다. 이를 위해 3시간짜리 실행이라도 상태를 메모리나 디스크에 담아두면 안 되고, 상태는 작업 외부에, durable하게 존재해야 한다. 그렇지 않으면 수동 체크포인팅이나 로그 기반 상태 복원 같은 걸 억지로 짜맞추게 되고, 이런 추상화는 결국 다른 레이어로 새어 들어가 변경을 더 어렵게 만든다.

2. 유연한 호출(invocation) 패턴의 결합 — 크론(cron), 이벤트 트리거, API, human-in-the-loop, 서브에이전트, 동적 워크플로우를 모두 다룰 수 있어야 하고, 동기/비동기/지연 호출이 다 가능해야 한다. 이게 안 되면 harness 로직이 큐, 워커, 폴링, 백오프, 스케줄링 같은 개념을 떠안게 되고 결국 나쁜 추상화가 쌓인 뒤죽박죽 시스템이 된다.

3. 세션 전체에 걸친 관찰가능성(observability) — LLM 호출·툴 호출뿐 아니라 DB 에러, 권한 문제, 트리거, 성능까지 트리거부터 전체 스택을 아우르는 풀 세션 트레이스가 있어야 디버깅과 개선이 가능하다.

샌드박스에 대한 견해: 샌드박스는 본질적으로 ephemeral(일시적)하고 stateless(무상태)하게 설계돼야 하며, 여기에 durability나 스냅샷, 상태를 담으려는 건 안티패턴이라고 지적한다. 실행 레이어가 분리돼 있으면, 실행 레이어가 샌드박스에 컨텍스트·순서·durability를 부여하는 구조가 된다 — "샌드박스는 손, 실행은 뇌"라는 비유.

앞으로 6개월 트렌드: background agents, dynamic workflows, autonomous loops, agent factories 등 최근 컨퍼런스에서 계속 나오는 트렌드들은 전부 장시간 실행되고(long-running), 비동기적이며(asynchronous), 위임(delegated)되는 구조라는 공통점이 있다. 그래서 사람이든 에이전트든 이걸 끝까지 들여다볼 수 있는(inspectable) 구조가 필요하다.

• 예시 1: 백그라운드 에이전트 — 요청-응답이 아니라 몇 분~몇 시간 걸릴 수 있고 200번 정도 툴 호출이 일어날 수 있으며 그중 최소 한 번은 실패가 거의 보장된다. 제대로 된 인프라와 관찰가능성 없이는 디버깅 자체가 불가능하다.
• 예시 2: 루프 아키텍처 — 그가 정의하는 "루프"는 지속적으로 혹은 스케줄대로 실행되면서 시스템 상태를 목표/기준과 비교 평가하고 다음 행동을 결정하는 시스템이다. 이를 위해 크론, 서브에이전트 위임, 조사 가능한 히스토리, 신뢰성이 필요하며 "3개월 전 프레임워크는 이런 걸 다루도록 설계되지 않았다"고 지적한다.

코드 예시 (3개 함수로 이루어진 루프):

1. 헬스체크 크론 — 30분마다 실행, 핵심 시스템 지표를 모아 LLM에게 "이거 건강한가? 더 조치가 필요한가?"를 물음
2. 트라이아지(triage) 에이전트 — 헬스체크에서 이상 신호가 나오면 트리거됨. 더 상세한 컨텍스트/지표를 모아 LLM에 넘기고, 루프를 돌며 툴을 호출해 근본 원인을 찾음. 샌드박스를 띄우고 코드를 클론하거나 커밋을 분석하는 등 몇 분 이상 걸리는 무거운 작업일 수 있음
3. 리뷰어(reviewer) 함수 — 매주 실행되어 그 주의 히스토리를 보고 트라이아지 시스템이 실제로 잘 작동했는지 평가(프롬프트를 조정해야 하는지, 더 나은 지표가 필요한지, 과잉 반응하고 있는지 등). 이를 위해 실행 로그를 조회해 "이 에이전트가 뭘 실행했는지, 어떤 서브에이전트를 fan-out 했는지, 어떤 워크플로우를 호출했는지"를 이해할 수 있어야 함

4. 시사점과 액션 아이템

• 실행 레이어는 사용자 입력과 시스템 전체 실행 사이에 위치하기 때문에, 사용자 피드백·액션·세션 결과가 전부 이 레이어를 통과한다. 그래서 실행 레이어는 자연스럽게 관찰가능성과 스코어링(scoring)의 허브가 되기 좋은 위치다.
• 애플리케이션을 개선하려면 이 데이터가 전부 연결돼 있어야 하고, 코드가 실제로 어떻게 실행되는지와 맞물려 있어야 한다.
• 실행 레이어를 잘 계측해두면, 단순한 "좋아요/싫어요" 대신 **결과 기반 스코어(outcome-based score)**를 만들 수 있다. 예를 들어 트라이아지 결과로 실제 PR이 열렸는지, 리서치 에이전트가 만든 리포트가 저장됐는지 같은 이벤트를 세션에 붙여서 실제 성공 여부를 판단할 수 있다.
• Inngest는 바로 이 실행 레이어 역할을 하는 durable execution 시스템으로, 어떤 모델/프레임워크/툴(컨텍스트 레이어)이나 어떤 샌드박스/브라우저(컴퓨트 레이어)를 붙이든 durable steps, 이벤트 트리거, 스케줄링, agent-to-agent 조율, 풀 세션 트레이스를 인프라 관리 없이 제공한다고 소개한다.
• 실무 액션 아이템: 에이전트 시스템을 설계할 때 프레임워크나 프롬프트, 모델 선택에 매몰되지 말고, 먼저 "우리 시스템의 실행 레이어는 무엇인가"를 정의하라. 상태를 외부화·durable하게 만들고, 재개 가능성을 처음부터 설계에 넣고, 크론/이벤트/API/human-in-the-loop을 하나의 실행 프리미티브로 다룰 수 있게 만들고, 트리거부터 끝까지 풀 세션 트레이스를 남겨라. 이렇게 하면 6개월마다 모델이나 프롬프트, 샌드박스가 바뀌어도 실행 레이어 자체는 다시 쓰지 않아도 된다.

핵심 요약 (20줄)

1. Inngest CTO Dan Farrelly는 "6개월 이상 에이전트를 만들었다면 이미 최소 한 번은 아키텍처를 다시 썼을 것"이라는 관찰로 발표를 시작한다.
2. 새 모델, 새 프레임워크, 새 tool calling 표준이 나올 때마다 기존 아키텍처가 안 맞는 건 불평이 아니라 지금의 현실이라고 말한다.
3. 그는 에이전트 시스템을 실행(execution)·컨텍스트(context)·컴퓨트(compute) 세 개의 개념적 레이어로 나눠 생각하라고 제안한다.
4. 실행 레이어는 "뇌"로, 플로우·상태·durability·재시도를 담당한다.
5. 컨텍스트 레이어는 "지식"으로 모델·프롬프트·툴·메모리를 뜻하며 가장 빠르게 변하는 레이어다.
6. 컴퓨트 레이어는 "손"으로 샌드박스·런타임·브라우저 자동화를 뜻한다.
7. 핵심 개념은 "반감기(half-life)" — 프롬프트는 몇 주, 모델은 몇 개월, 제대로 만든 실행 레이어는 수년간 살아남을 수 있다.
8. 문제는 대부분의 팀이 세 레이어를 다 뭉쳐버려서, 한 레이어의 반감기가 다른 레이어를 끌고 내려가는 것이며 이것이 기술 부채의 또 다른 이름이다.
9. 프레임워크를 쓰든 미리 만든 harness를 가져오든 처음부터 직접 짜든, 추상화가 없거나 너무 높거나 레이어가 뒤섞이는 문제는 공통적으로 나타난다.
10. 그의 테제는 단순하다: 레이어별로 생각하고 서로 분리하되, 특히 실행 레이어에 투자하라는 것.
11. 실행 레이어는 코드를 안정적으로 실행하고 각 작업의 완료 여부·시점·방식을 관리하는 시스템으로, 인프라와는 독립적이어야 한다.
12. 실행 레이어의 첫 번째 필수 요건은 재개 가능성 — 38번째 스텝에서 실패해도 처음부터 다시가 아니라 그 지점에서 이어갈 수 있어야 하며, 이를 위해 상태는 메모리·디스크가 아니라 외부에 durable하게 존재해야 한다.
13. 두 번째 요건은 유연한 호출 패턴 — 크론, 이벤트, API, human-in-the-loop, 서브에이전트, 동적 워크플로우를 동기·비동기·지연 방식으로 모두 결합할 수 있어야 한다.
14. 세 번째 요건은 트리거부터 전체 스택까지 아우르는 풀 세션 관찰가능성으로, 이게 없으면 디버깅과 개선이 불가능하다.
15. 그는 샌드박스가 원래 일시적이고 무상태이도록 설계돼야 하며, 여기에 durability나 상태를 담는 건 안티패턴이라고 지적한다 — "샌드박스는 손, 실행은 뇌".
16. 앞으로 6개월간 부상할 백그라운드 에이전트, 동적 워크플로우, 자율 루프, 에이전트 팩토리는 모두 장시간·비동기·위임 구조라는 공통점이 있어 실행 레이어가 필수적이다.
17. 예시로 든 "개선 루프"는 30분마다 도는 헬스체크 크론, 이상 신호 시 근본 원인을 찾는 트라이아지 에이전트, 매주 시스템 성능을 평가하는 리뷰어 함수 등 3개 함수로 구성된다.
18. 실행 레이어는 사용자 입력과 시스템 실행 사이에 위치하기 때문에 자연스럽게 관찰가능성과 스코어링의 허브가 되며, PR이 실제로 열렸는지 등 결과 기반 스코어를 만들 수 있게 해준다.
19. Inngest는 바로 이 실행 레이어 역할을 하는 durable execution 시스템으로, 어떤 모델·프레임워크·샌드박스를 붙이든 durable steps, 이벤트 트리거, 풀 세션 트레이스를 인프라 관리 없이 제공한다고 소개한다.
20. 결론적으로 harness를 만들 때 레이어 구조를 이해하고 변화의 속도를 받아들이되, 실행 레이어의 프리미티브를 제대로 갖춰두면 그 위의 모든 것이 6개월마다 훨씬 쉽게 진화할 수 있다.