AI VIDEO BRIEFING
AI 에이전트 아키텍처 설계법: 실행·컨텍스트·컴퓨트 세 계층을 분리해야 하는 이유
AI 에이전트를 6개월만 만들어도 구조를 다시 쓰게 된다. 실행·컨텍스트·컴퓨트 세 계층으로 나누고 가장 오래 가는 실행 계층에 투자하라는 개발자 콘퍼런스 발표를, 재개 가능성과 관측성 관점에서 정리했다.

핵심 메시지
쉽게 이해하기
AI 에이전트를 만들어 본 사람이라면 익숙한 경험이 있다. 반년 전에 공들여 짠 구조가 어느새 맞지 않아 다시 쓰게 되는 일이다. 새 모델이 나오고, 프레임워크 버전이 올라가고, 도구를 호출하는 표준이 바뀌면 기존 설계가 어긋나기 시작한다. 이 발표는 그 현상을 불평이 아니라 전제로 받아들이자고 말한다. 중요한 것은 무엇이 살아남았는지가 아니라, 살아남은 부분이 우연인지 설계의 결과인지다.
발표자는 흔히 그려지는 부품 나열식 다이어그램 대신 개념적인 세 계층을 제시한다. 첫째는 실행 계층으로, 흐름과 상태·내구성·재시도가 일어나는 두뇌에 해당한다. 둘째는 컨텍스트 계층으로 모델과 프롬프트, 도구, 메모리가 들어가며 가장 자주 바뀐다. 셋째는 컴퓨트 계층으로 샌드박스와 런타임, 자동화하는 브라우저처럼 실제로 일을 처리하는 손이다.
이렇게 나누는 이유는 계층마다 수명이 다르기 때문이다. 프롬프트는 운이 좋아야 몇 주, 모델은 몇 달을 버틴다. 반면 실행 계층은 잘 설계하면 몇 년을 쓸 수 있다. 문제는 대부분의 팀이 세 층을 한 덩어리로 묶어 둔다는 점이다. 그러면 수명이 짧은 층이 긴 층까지 끌어내려, 모델 하나 바꾸려다 시스템 전체를 다시 쓰는 상황이 생긴다.
그래서 발표는 실행 계층에 투자하라고 권한다. 실행 계층은 코드를 신뢰성 있게 돌리고, 각 작업이 언제·어떻게·완료되는지를 관리하는 시스템으로 정의된다. 세 시간짜리 작업이 38번째 단계에서 실패했다면 처음부터 다시 돌리는 대신 그 지점에서 이어가야 하고, 그러려면 상태가 실행 과정 바깥에 내구성 있게 저장돼야 한다. 크론과 이벤트, API, 사람의 개입, 서브에이전트 호출 같은 다양한 시작 방식도 함께 지원해야 한다.
발표자는 앞으로 6개월 사이 늘어날 구조들, 예컨대 백그라운드 에이전트나 스스로 상태를 점검하며 도는 루프형 시스템을 예로 든다. 이들은 길게 돌고 비동기이며 위임이 많아, 실행 기록을 사람과 에이전트 모두가 들여다볼 수 있어야 한다. 30분마다 지표를 점검해 이상하면 조사 에이전트를 부르고, 주 단위로 그 판단이 적절했는지 되돌아보는 세 개의 함수만으로도 개선 루프가 만들어진다는 예시가 소개된다.
주요 인사이트
- '무엇을 쓰느냐'보다 '무엇을 분리해 두었느냐'가 수명을 결정한다. 프레임워크가 편해 보여도 오케스트레이션이 체인 안쪽에 묻혀 있으면 나중에 갈아끼울 수 없다.
- 긴 작업일수록 상태를 메모리나 디스크에 두면 안 된다. 실패는 예외가 아니라 기본값이므로, 재개 가능성은 기능이 아니라 설계 전제로 다뤄야 한다.
- 관측성은 모델 호출 로그만으로 부족하다. 트리거부터 데이터베이스 오류, 권한 문제, 성능까지 한 세션의 흐름이 이어져 보여야 디버깅과 개선이 가능하다.
- 실행 계층은 사용자 입력과 결과가 모두 지나가는 길목이라, 에이전트를 평가하고 점수 매기기에도 가장 좋은 자리다. 좋아요·싫어요 대신 'PR이 열렸는가', '리포트가 저장됐는가' 같은 결과 기반 지표를 붙일 수 있다.
- 3개월 전 프레임워크는 지금 필요한 장기 실행·비동기·위임형 구조를 염두에 두고 만들어지지 않았다. 결국 자기 시스템의 뼈대는 직접 설계해야 한다는 뜻이다.
자주 묻는 질문
왜 하필 실행 계층에 투자하라고 하나요?
발표자는 프롬프트가 몇 주, 모델이 몇 달 단위로 바뀌는 데 비해 실행 계층은 제대로 설계하면 몇 년을 쓸 수 있다고 봅니다. 모델·컨텍스트·샌드박스를 바꿔도 실행 계층은 그대로 남을 수 있기 때문에, 여기서 추상화를 잘 잡아두면 나머지가 빠르게 바뀌어도 전체를 다시 쓰지 않아도 된다는 논리입니다.
샌드박스에 상태를 저장하면 왜 문제가 되나요?
샌드박스는 설계상 일회성이고 상태를 남기지 않는 환경입니다. 코드를 실행하고 브라우저를 다루고 파일을 만지는 데는 적합하지만, 내구성이나 스냅숏을 여기에 의존하면 상태가 사라졌을 때 복구가 어려워집니다. 발표자는 샌드박스를 손, 실행 계층을 두뇌로 보고 순서와 내구성은 실행 계층이 책임져야 한다고 설명합니다.
백그라운드 에이전트가 특히 어려운 이유는 무엇인가요?
요청과 응답이 오가는 대화형과 달리 사람이 기다리고 있지 않고, 수십 분에서 몇 시간까지 돌면서 수백 번의 도구 호출을 합니다. 그 과정에서 최소 한 번은 실패가 나기 마련인데, 관측 수단이 없으면 무엇이 언제 잘못됐는지조차 알 수 없어 디버깅 자체가 불가능해집니다.
원문과 출처
이 글은 원본 영상의 자막을 바탕으로 한국어 독자를 위해 요약했습니다. 전체 맥락과 최신 정보는 원문에서 확인하세요.
YouTube 원본 영상 보기 ↗