상시 가동 에이전트 만들기

Executive Summary

잠든 에이전트를 이벤트가 깨운다: 상시 가동 에이전트는 같은 에이전트 루프에 기본 구성 요소 다섯 개를 두른 설계다

정의와 배경: 상태를 지니고 먼저 움직이는 에이전트, 모델의 판단이 나아지고 비용이 내려가 다시 늘었다

원문은 상시 가동 에이전트를 상태를 지니고(stateful) 먼저 움직이는(proactive) 에이전트로 정의한다. 세션을 넘어 컨텍스트를 관리한다. 직접적인 감독 없이도 행동한다. 그 밑에서 도는 것은 다른 에이전트와 같은 핵심 루프다. 차이는 루프를 둘러싼 바깥 구조에 있다. 원문은 바깥 구조의 기본 구성 요소가 에이전트가 언제 깨어나는지, 실행 사이에 무엇이 이어지는지, 일의 결과가 어떻게 사용자에게 닿는지를 통제한다고 쓴다.

저자는 발행일(2026-11-13) 기준 몇 달 사이에 상시 가동 에이전트가 다시 늘었다고 쓴다. 그는 그 이유를 최근 모델의 발전에서 찾는다. 발전한 모델 덕분에 상시 가동 에이전트를 돌리기가 더 현실적이 됐다는 것이다. 근거로 드는 변화는 둘이다. 최신 모델이 사용자의 의도를 더 안정적으로 이해하고 언제 확인을 구할지 더 잘 안다는 것, 지능의 값이 내려가고 있다는 것이다.

원문은 비용 하락의 혜택을 장기 작업이 가장 크게 본다고 쓴다. 예로 든 수치는 장기 코딩 벤치마크 하나의 결과다. 원문은 이 벤치마크에서 Opus 5.5가 과제 하나를 해결하는 데 든 비용이 Opus 5보다 78% 적었다고 쓴다. 일반 작업 부하에서는 40% 적었다고 함께 적는다.

원문에 따르면 Anthropic의 고객들은 이런 경험을 자기 제품에 넣는 방법을 묻기 시작했다. 기존 에이전트를 더 먼저 움직이게 바꾸려는 회사가 있다. 처음부터 새로 만들려는 회사도 있다.

실행 주기: 잠든 시간이 대부분이고, 깨어 있는 실행은 짧다

'상시 가동'은 사용자 경험을 묘사하는 말이다. 원문은 상시 가동 에이전트가 실제로 '상시 가동'하지 않는다고 쓴다. 에이전트가 깨어 일하는 한 구간을 원문은 실행이라 부른다. 실행은 이벤트를 받는 데서 시작한다. 에이전트는 맡은 일을 끝낸 뒤 무슨 일이 있었는지를 저장한다.

실행은 세션 안에서 돈다. 세션은 메시지와 도구 호출의 기록이다. 실행이 끝나면 에이전트는 다시 잠든다.

이벤트 인박스: 모든 이벤트를 내구성 목록 하나에 받고, 워커 하나가 꺼내 실행한다

원문은 이벤트 출처가 에이전트를 직접 부르는 대신 이벤트를 인박스에 넣게 하라고 쓴다. 워커가 인박스에서 이벤트를 꺼낸다. 대부분의 AI 에이전트는 사용자가 메시지를 보낼 때만 돈다. 상시 가동 에이전트는 웹훅, 예약 작업, 백그라운드 작업 같은 여러 종류의 이벤트에 깨어난다.

출처마다 에이전트를 직접 부르게 하면 실패하는 경로가 생긴다. 원문이 드는 예는 둘이다. 동시에 도착한 이벤트 두 개가 서로 경쟁하는 실행을 띄울 수 있다. 크래시 한 번에 이벤트 하나가 통째로 사라질 수 있다.

가장 단순한 인박스는 세 부분으로 이루어진다.

• 내구성 목록은 이벤트를 담는다. 보통 데이터베이스 표다.
• 핸들러는 이벤트를 목록에 쓴다. 보통 HTTP 엔드포인트다.
• 워커는 목록에서 이벤트를 읽는다. 보통 백그라운드 서비스다.

인박스는 이벤트마다 상태를 기록한다. 출처가 붙인 고유 식별자로 중복 이벤트를 걸러 낼 수 있다. 원문은 관계형 데이터베이스가 인박스에 잘 맞는다고 쓴다. 이벤트 하나가 새 행 하나로 덧붙는다. 원문은 처음에는 사용자 한 명당 인박스 하나로 시작하라고 권한다. 병렬성이 더 필요하면 더 잘게 나눠도 된다.

새 이벤트가 오면 핸들러는 이벤트를 인박스에 쓴 뒤 워커를 깨운다. 워커는 대기 중인 이벤트를 읽어 실행을 시작한다. 사용자의 답장처럼 앞선 일을 잇는 이벤트는 기존 세션을 재개한다. 나머지 이벤트는 새 세션을 연다. 워커는 이벤트를 에이전트 루프에 넘긴 뒤 실행이 끝나기를 기다린다. 실행이 끝나면 해당 이벤트를 완료로 표시한다.

원문은 구현 세부가 까다로워질 수 있다고 보고 실무 지침 넷을 든다.

• 핸들러는 이벤트를 빨리 수신 확인한다. 웹훅 제공자처럼 느린 응답을 실패로 치는 출처가 있다. 핸들러도 가벼운 검사는 할 수 있다. 프롬프트 인젝션 검사 같은 깊은 검증은 실행 안에서 한다.
• 인박스가 기준 원천(source of truth)이다. 워커는 깨어나면 인박스에서 최신 이벤트부터 가져온다. 워커가 실행 도중에 죽어도 새 워커가 같은 이벤트를 집어 다시 시도할 수 있다.
• 인박스 하나에는 활성 워커를 하나만 둔다. 이 규칙이 실행 두 개가 같은 일을 겹쳐 하거나 서로의 결과를 덮어쓰는 일을 막는다. 실행 도중에 새 이벤트가 오면 고를 수 있는 길은 셋이다. 다음 실행으로 미루거나, 지금 실행에 합치거나, 지금 실행을 끊고 다시 시작한다.
• 워커는 대기 중인 이벤트를 묶어 처리한다. 사용자가 메시지 여러 개를 잇달아 보내면 워커가 그것들을 실행 하나로 합친다. 에이전트는 한 번만 답하면 된다.

타이머: 인박스와 따로 저장하고, 스케줄러가 때가 된 타이머를 인박스 이벤트로 바꾼다

타이머는 인박스와 함께 상시 가동 에이전트가 먼저 움직이게 한다. 타이머는 후속 확인(follow-up)과 정기 일정(schedule)으로 나뉜다. 후속 확인은 에이전트가 스스로 정한 기한이다. 답장이 왔는지 확인하는 일이 예다. 정기 일정은 알려진 주기로 되풀이되는 작업이다. 매일 보내는 뉴스레터가 예다.

원문 그림 3은 후속 확인을 에이전트가, 정기 일정을 사용자가 정하는 것으로 그린다. 타이머는 인박스와 분리된 자기 내구성 저장소에 둔다. 보통 데이터베이스 표 하나를 더 쓴다. 원문은 인박스에 지금 처리할 수 있는 이벤트만 두라고 쓴다. 후속 확인과 정기 일정은 비슷한 스키마를 공유할 수 있다. 정기 일정은 반복 규칙을 하나 더 기록한다.

타이머는 스스로 실행을 시작하지 않는다. 스케줄러가 저장소를 일정한 간격으로 조회해 때가 된 타이머를 작동시킨다. 스케줄러는 보통 백그라운드 서비스다. 한 번 돌 때마다 스케줄러가 하는 일은 아래와 같다.

1. 저장소를 훑어 때가 된 타이머를 찾는다.
2. 타이머를 종류에 맞게 갱신한다. 후속 확인은 완료로 표시한다. 정기 일정은 기한을 다음 회차로 옮긴다.
3. 인박스에 이벤트를 넣은 뒤 워커를 깨운다.

스케줄러는 직접 만들어도 된다. 내구성 실행 엔진(durable execution engine)을 써도 된다.

메모리: 다시 찾아볼 수 없는 것만 파일로 남기고, 워커보다 오래 사는 저장소에 둔다

메모리는 서로 끊긴 실행 사이의 연속성을 맡는다. 상시 가동 에이전트는 여러 실행에 걸쳐 일하기 때문이다. 메모리도 인박스·타이머처럼 자기 저장소를 가져야 한다. 원문은 Anthropic 제품에서 메모리를 파일 디렉터리로 구현했다고 쓴다. 예로 Claude Code의 auto memory와 Messages API의 메모리 도구(memory tool)를 든다.

상시 가동 에이전트라면 이 디렉터리를 내구성 저장소에 연결한다. 보통 데이터베이스나 객체 저장소다. 메모리가 워커보다 오래 살아남게 하려는 배치다. 원문의 경험칙은 에이전트가 다시 찾아볼 수 없는 것만 메모리에 담는 것이다. 이슈 트래커처럼 다른 시스템에 이미 있는 정보는 그 위치를 가리키는 포인터만 저장한다.

원문이 저장 대상으로 꼽는 메모리는 네 종류다.

• 사용자 지시: 에이전트 행동에 관한 사용자 지시는 파일 하나에 따로 저장한다. 매 실행이 시작될 때 읽어 들인다. 사용자가 늘 곁에서 에이전트를 조종하지는 않는다. 지시가 실행을 넘어 이어져야 하는 이유다.
• 사용자 노트: 에이전트가 사용자에 관해 알게 된 것을 저장한다. 사용자의 역할, 선호, 사용자가 준 교정이 예다. 파일 하나로 시작해도 된다. 노트가 늘면 작은 파일 여러 개로 나눈다. 나눈 뒤에는 실행이 시작될 때 색인만 읽는다. 세부가 필요하면 에이전트가 개별 파일을 컨텍스트로 가져온다.
• 지난 메시지: 에이전트는 사용자에게 이미 말한 내용을 추적해 같은 말을 되풀이하지 않는다. 실행이 시작될 때 읽는 별도 파일에 저장해도 된다. 워커가 에이전트와 사용자 사이의 최근 메시지 몇 개를 불러와도 된다.
• 작업 진행: 진행 중인 작업마다 진행 파일을 하나 둔다. 파일에는 끝낸 일과 남은 일을 적는다. 새 실행은 이 파일을 읽어 앞선 실행이 멈춘 곳에서 이어 간다. 사용자 노트처럼 실행이 시작될 때는 색인만 읽는다. 세부는 필요할 때 개별 파일에서 가져온다.

원문이 그림 4로 보이는 예시 구성은 instructions.md, index.md, reported.md를 매 실행이 시작될 때 읽는다. notes/ 폴더와 progress/ 폴더는 필요할 때 읽는다. 에이전트는 실행 중에 메모리에 쓴다.

위 네 종류는 실행 중에 저장하는 메모리다. 원문은 여기에 dreaming을 더할 수 있다고 쓴다. dreaming은 지난 세션을 돌아보며 메모리를 다듬는다. 낡은 항목을 바꿀 수 있다. 여러 실행에 걸쳐서만 드러나는 패턴도 찾는다. 원문은 자세한 내용을 Anthropic의 에이전트 메모리 글로 넘긴다.

컨텍스트 창 안: 매 실행에 붙는 고정 부담은 작게 두고, 길어진 세션은 압축하거나 새로 연다

매 실행은 같은 고정 부담(overhead)을 지고 시작한다. 에이전트는 일하기 전에 시스템 프롬프트, 도구 정의, 메모리 파일을 읽는다. 원문은 이 초기 컨텍스트를 작게 유지하라고 권한다. 비용을 낮추려면 프롬프트 캐싱을 쓰라고도 권한다.

새 세션은 고정 부담과 실행을 일으킨 이벤트만 들고 시작한다. 기존 세션은 앞선 실행들의 메시지와 도구 호출을 다시 불러온다. 원문은 세션이 너무 길어지면 오래된 메시지를 압축(compaction)하거나 새 세션을 열라고 쓴다. 두 방법 모두 세부를 잃는다. 원문은 남아야 하는 것을 일하는 도중에 메모리에 저장해 두라고 쓴다.

권한: 실행이 사용자의 접근권을 쥐고 무인으로 도는 자리라 위험이 가장 크다

원문은 상시 가동 에이전트가 가장 큰 위험을 지는 곳으로 권한을 꼽는다. 실행은 사용자의 접근권을 쥐고 있다. 설계상 사람이 지켜보지 않는 상태로 돈다. 에이전트는 도구 호출마다 스스로 진행할지, 막을지, 승인을 기다릴지 정해야 한다. 원문은 권한의 구성 요소가 다른 에이전트가 쓰는 것과 같다고 쓴다.

• 자격 증명 저장소: 상시 가동 에이전트가 쓸모 있으려면 비밀번호나 액세스 토큰 같은 민감한 사용자 자격 증명이 필요할 때가 많다. 원문이 드는 권장 패턴은 에이전트 환경 밖의 프록시다. 에이전트는 자격 증명 없이 요청을 보낸다. 프록시가 진짜 자격 증명을 끼워 넣은 뒤 요청을 전달한다.
• auto mode: 상시 가동 에이전트는 사용자가 계속 입력하지 않아도 일할 수 있어야 한다. 원문은 Anthropic이 Claude Code의 auto mode로 이 문제의 한 형태를 이미 다뤘다고 쓴다. 원문에 따르면 auto mode는 분류기로 위험이 큰 동작을 검토한다. 분류기가 위험하다고 판단한 동작은 막는다. Claude는 막힌 동작 대신 더 안전한 방법을 찾는다. 가장 중요한 결정에는 여전히 사용자 검토가 필요하다.
• 보류된 도구 호출(deferred tool call): 원문은 Claude Code에서 훅이 도구 호출을 보류하고 사용자의 추가 입력을 기다릴 수 있다고 쓴다. 같은 패턴이 상시 가동 에이전트에도 맞는다. 어떤 동작 전에 설명이나 승인이 필요할 때다.

보류된 도구 호출은 답을 기다리는 동안 에이전트를 막지 않는다. 원문이 그리는 흐름은 아래와 같다.

1. 호출을 보류하면 실행이 끝난다. 세션은 호출 도중의 상태로 저장된다.
2. 요청이 사용자에게 보인다. 원문은 MCP Apps로 만든 대화형 카드를 예로 든다.
3. 사용자의 답이 인박스의 이벤트로 돌아온다.
4. 그 이벤트가 새 실행을 시작한다. 새 실행은 저장된 세션에 사용자 입력을 넣어 재개한다.

답을 기다리는 동안 워커는 다른 이벤트를 처리할 수 있다.

아웃박스: 사용자는 결과만 받고, 정식 아웃박스는 속도 조절이나 오류 복구가 필요할 때만 둔다

상시 가동 에이전트의 사용자는 결과와 약간의 세부만 받는다. 대부분의 AI 에이전트는 응답을 생성하는 대로 사용자에게 스트리밍한다. 사용자는 Claude가 문제를 추론하는 과정부터 도구 호출, 답 작성까지 따라 읽는다. 상시 가동 에이전트는 일 대부분을 백그라운드에서 한다. 단계별 과정 전체는 사용자에게 가지 않는다.

원문은 실행이 끝나는 방식을 셋으로 적는다.

• 에이전트가 아웃박스로 메시지를 보낸다.
• 에이전트가 보낼 것이 없다고 판단한다.
• 에이전트가 보류된 도구 호출로 권한이나 추가 입력을 요청한다.

원문은 상시 가동 에이전트 대부분이 메시지를 사용자에게 바로 전달하는 'send' 도구 하나로 충분하다고 쓴다. 정식 아웃박스는 에이전트의 메시지 속도를 조절하거나 에이전트가 오류에서 복구하게 하려 할 때만 필요하다.

정식 아웃박스는 나가는 메시지를 담는 별도 표로, 이벤트 인박스에 대응한다. 워커에 대응하는 것은 디스패처다. 보통 백그라운드 서비스인 디스패처는 대기 중인 메시지를 읽어 무엇을 전달할지 정한다. 고른 메시지를 사용자에게 보낸다. 보류된 도구 호출의 요청은 아웃박스를 거쳐 가도 된다. 인터페이스에 바로 보여 줘도 된다.

원문은 전달 다음 과제로 에이전트가 보내는 메시지 수의 조율을 든다. 너무 많이 보내는 에이전트는 시끄러워진다. 너무 적게 보내는 에이전트는 사용자가 알아야 할 일을 놓친다. 원문은 그 균형을 찾으려면 평가(evals)를 만들라고 권한다. 실무에서는 에이전트가 조용히 시작해 시간이 지나며 사용자의 주의를 더 얻어 가는 편이 낫다고 쓴다.

맞물리는 방식: 이벤트가 실행을 열고, 사용자의 답과 타이머가 다시 이벤트가 되어 고리를 닫는다

모든 실행은 인박스의 이벤트 하나로 시작한다. 원문이 그리는 실행 한 번은 다섯 요소를 아래 순서로 지난다.

1. 워커가 인박스에서 이벤트를 집는다. 이벤트는 사용자 메시지, 웹훅, 타이머 가운데 하나다.
2. 워커가 실행을 띄운다. 에이전트는 새 세션이나 기존 세션에서 깨어난다.
3. 에이전트가 메모리를 읽어 기준선을 잡는다.
4. 에이전트가 권한 안에서 행동한다.
5. 에이전트가 알게 된 것을 메모리에 고쳐 쓴다.
6. 실행이 끝나면 에이전트가 아웃박스에 행 하나를 넣는다. 디스패처가 그 메시지를 사용자에게 전달한다.

이 연결이 주기를 이룬다. 실행은 나중에 에이전트를 다시 깨울 타이머를 걸 수 있다. 사용자가 메시지에 답하면 그 답이 인박스의 이벤트로 돌아온다. 실행 하나하나는 짧다. 주기는 끝없이 돈다. 원문은 이 끝없는 주기가 에이전트를 늘 켜져 있는 것처럼 느끼게 한다고 쓴다.

상시 가동 에이전트의 '상시'는 깨어 있는 시간의 길이가 아니라 잠든 에이전트를 다시 깨우는 길이 끊기지 않는 데서 나온다.

원본 (완역)

지난 몇 달 동안 우리는 상시 가동 에이전트(always-on agent)가 다시 부상하는 것을 지켜봤다.

상시 가동 에이전트는 상태를 유지하고(stateful) 능동적이다(proactive). 세션을 넘나들며 컨텍스트를 관리하고, 직접 감독하지 않아도 행동한다는 뜻이다. 그 밑바탕에서는 다른 에이전트와 같은 핵심 루프로 돌아간다. 다른 점은 그것을 둘러싼 아키텍처다. 이 아키텍처는 기본 구성 요소(primitive)로 짜여 있다. 이 요소들이 에이전트가 언제 깨어날지, 실행(run)과 실행 사이에 무엇이 이어질지, 작업 결과가 사용자에게 어떻게 닿을지를 제어한다.

이런 부상은 주로 최근의 모델 발전 덕분이다. 모델이 발전하면서 상시 가동 에이전트를 운영하는 일이 더 현실적이 되었다. 첫째, 최신 모델은 판단력이 더 좋다. 사용자의 의도를 이해하는 일과 언제 사용자에게 확인을 구할지 아는 일에서 더 믿을 만하다. 둘째, 지능이 싸지고 있다. 가장 큰 혜택을 보는 쪽은 장기 작업이다. 예를 들어 장기 코딩 벤치마크 하나에서 Opus 5.5는 해결한 작업당 비용이 Opus 5보다 78% 적었다. 일반적인 워크로드에서는 40% 적었다.

고객들은 이런 경험을 자사 제품에 어떻게 넣을 수 있는지 우리에게 묻기 시작했다. 어떤 회사는 기존 에이전트를 더 능동적으로 만들고 싶어 하고, 어떤 회사는 처음부터 새로 만들려 한다.

이 글은 상시 가동 에이전트를 떠받치는 기본 구성 요소를 하나씩 나누어 살펴보고, 그 요소들이 어떻게 맞물리는지 짚어 본다.

상시 가동 에이전트를 움직이는 주기

상시 가동 에이전트는 실제로 “상시 가동”하지 않는다. 이 말은 사용자 경험을 묘사할 뿐이다.

실제로 에이전트는 대부분의 시간을 잠든 채 보내다가 주기적으로 깨어나 일을 한다. 한 번 일하는 구간을 실행이라고 부른다. 실행에서 에이전트는 이벤트를 받고, 작업을 마친 뒤, 무슨 일이 있었는지에 관한 정보를 저장한다. 실행은 세션 안에서 일한다. 세션은 메시지와 도구 호출의 기록(transcript)이다. 실행이 끝나면 에이전트는 다시 잠들고, 이 주기가 끝없이 반복된다.

핵심 기본 구성 요소

상시 가동 에이전트를 둘러싼 아키텍처에는 다섯 가지 핵심 기본 구성 요소가 있다. 이벤트 인박스, 타이머, 메모리, 권한, 아웃박스다. 하나씩 살펴보자.

이벤트 인박스(Event inbox)

대부분의 AI 에이전트는 사용자가 메시지를 보낼 때만 동작한다. 반면 상시 가동 에이전트는 웹훅, 예약 작업, 백그라운드 잡을 비롯한 여러 종류의 이벤트로 촉발될 수 있다.

솔깃한 방법 하나는 이벤트 소스마다 에이전트를 직접 호출하게 하는 것이다. 하지만 이 방법에는 실패 유형이 몇 가지 있다. 예를 들어 두 이벤트가 동시에 도착하면 서로 경합하는 실행이 시작될 수 있고, 크래시가 나면 이벤트 하나가 통째로 사라질 수 있다.

여기서 이벤트 인박스가 나선다. 모든 소스는 에이전트를 호출하는 대신 이벤트를 인박스로 보내고, 워커가 거기서 이벤트를 가져간다.

가장 단순한 형태는 다음 세 가지 요소로 이루어진다.

• 이벤트를 담는 내구성 목록. 보통 데이터베이스 테이블이다.
• 목록에 이벤트를 쓰는 핸들러. 보통 HTTP 엔드포인트다.
• 목록에서 이벤트를 읽는 워커. 보통 백그라운드 서비스다.

인박스는 이벤트마다 상태를 추적해야 한다. 이벤트는 소스가 붙인 고유 식별자를 기준으로 중복을 걸러 낼 수 있다. 인박스에는 관계형 데이터베이스가 잘 맞는다. 이벤트 하나를 새 행 하나로 덧붙이면 된다. 사용자당 인박스 하나로 시작하기를 권한다. 병렬성이 더 필요하면 더 잘게 나눌 수 있다.

새 이벤트가 들어오면 핸들러가 그 이벤트를 인박스에 쓰고 워커를 깨운다. 워커는 대기 중인 것을 모두 읽고 실행을 시작한다. 사용자의 답장처럼 이전 작업을 이어 가는 이벤트는 기존 세션을 재개하고, 나머지는 모두 새 세션을 시작한다.

그다음 워커는 이벤트를 에이전트 루프에 넘기고, 실행이 끝나기를 기다린 뒤, 해당 이벤트를 완료로 표시한다. 구현 세부는 까다로워질 수 있다. 몇 가지 모범 사례는 다음과 같다.

• 핸들러는 이벤트에 빠르게 수신 확인을 보내야 한다. 웹훅 제공자 같은 일부 소스는 느린 응답을 실패로 간주한다. 핸들러가 가벼운 검사는 해도 된다. 다만 프롬프트 인젝션 확인 같은 더 깊은 검증은 실행 중에 해야 한다.
• 인박스가 진실의 원천(source of truth)이어야 한다. 워커는 깨어나면 먼저 인박스에서 최신 이벤트를 가져와야 한다. 그래야 워커가 실행 도중 죽어도 새 워커가 같은 이벤트를 집어 다시 시도할 수 있다.
• 인박스 하나에는 한 번에 활성 워커가 하나만 있어야 한다. 그래야 두 실행이 같은 일을 중복하거나 서로의 결과를 덮어쓰지 않는다. 실행 도중 새 이벤트가 나타나면 다음 실행으로 넘기거나, 현재 실행에 합치거나, 중단하고 다시 시작하는 방법 중 하나를 고를 수 있다.
• 워커는 대기 중인 이벤트를 한데 묶어 처리해야 한다. 예를 들어 사용자가 메시지를 연달아 여러 개 보내면 워커가 이를 실행 하나로 합칠 수 있다. 그러면 에이전트는 한 번만 답하면 된다.

타이머(Timers)

타이머는 이벤트 인박스와 함께 상시 가동 에이전트를 능동적으로 만든다. 타이머는 대체로 두 범주 중 하나에 속한다. 후속 확인(follow-up)과 정기 일정(schedule)이다. 후속 확인은 답장이 왔는지 확인하는 일처럼 에이전트가 스스로에게 정하는 기한이다. 반면 정기 일정은 매일 보내는 뉴스레터처럼 정해진 주기로 반복되는 작업이다.

타이머는 인박스와 분리된 자체 내구성 저장소에 둔다. 보통 또 하나의 데이터베이스 테이블이다. 인박스에는 바로 처리할 수 있는 이벤트만 있어야 한다. 후속 확인과 정기 일정은 비슷한 스키마를 공유할 수 있다. 다만 정기 일정은 반복 규칙도 추적해야 한다.

타이머는 혼자서 실행을 시작하지 않는다. 대신 스케줄러(보통 백그라운드 서비스)가 일정한 간격으로 저장소를 폴링하고, 기한이 된 것을 모두 발동시킨다. 스케줄러는 한 번 돌 때마다 다음 일을 한다.

1. 저장소를 훑어 기한이 된 타이머를 찾는다.
2. 타이머마다 범주에 따라 갱신한다.
   1. 후속 확인은 완료로 표시해야 한다.
   2. 정기 일정은 기한을 다음 회차로 갱신해야 한다.
3. 인박스에 이벤트를 추가하고 워커를 깨운다.

스케줄러는 직접 서비스를 만들어도 되고 내구성 실행 엔진(durable execution engine)을 써도 된다.

메모리(Memory)

상시 가동 에이전트는 서로 끊긴 수많은 실행에 걸쳐 일하고, 연속성을 유지하려고 메모리에 의존한다.

이벤트 인박스나 타이머와 마찬가지로 메모리에도 자체 저장소가 있어야 한다. Claude Code의 auto memory나 Messages API의 메모리 도구(memory tool) 같은 우리 제품에서는 메모리를 파일 디렉터리로 구현한다. 상시 가동 에이전트라면 이 디렉터리가 내구성 저장소에 대응해야 한다. 보통 데이터베이스나 객체 저장소다. 그래야 메모리가 워커보다 오래 살아남는다.

경험칙으로 보면, 메모리에는 에이전트가 다시 찾아볼 수 없는 것만 담아야 한다. 이슈 트래커처럼 다른 시스템에 이미 있는 정보라면 그 대신 포인터를 저장해야 한다. 상시 가동 에이전트가 저장해야 할 메모리의 종류는 다음과 같다.

• 사용자 지시: 에이전트의 행동에 관해 사용자가 준 지시는 모두 별도 파일에 저장하고 매 실행 시작 때 불러와야 한다. 사용자가 늘 곁에서 에이전트를 조종해 줄 수는 없다. 그래서 지시는 실행과 실행 사이에 이어져야 한다.
• 사용자 노트: 에이전트는 사용자에 관해 알게 된 것을 저장해야 한다. 사용자의 역할, 선호, 사용자가 준 정정 사항 같은 것이다. 파일 하나로 시작해서 노트가 늘어나면 작은 파일 여러 개로 옮겨 갈 수 있다. 후자의 경우 각 실행 시작 때는 인덱스만 불러온다. 에이전트는 더 자세한 내용이 필요할 때 개별 파일을 컨텍스트로 가져올 수 있다.
• 지난 메시지: 에이전트는 같은 말을 되풀이하지 않도록 사용자에게 이미 전한 내용을 추적해야 한다. 이 내용을 각 실행 시작 때 불러오는 별도 파일에 저장할 수도 있고, 워커가 에이전트와 사용자 사이의 최근 메시지 몇 개를 불러오게 할 수도 있다.
• 작업 진행 상황: 진행 중인 작업마다 에이전트는 한 일과 남은 일을 담은 진행 파일을 유지해야 한다. 그러면 어떤 새 실행이든 그 파일을 읽고 이전 실행이 멈춘 지점부터 이어 갈 수 있다. 사용자 노트와 마찬가지로 각 실행 시작 때는 인덱스만 불러온다. 에이전트는 더 자세한 내용이 필요할 때 개별 파일을 컨텍스트로 가져올 수 있다.

아래 도식은 구성 예 하나를 보여 준다.

지금까지 설명한 것은 모두 실행 중에 저장하는 메모리다. 여기에 dreaming을 더할 수도 있다. dreaming은 지난 세션을 돌아보며 메모리를 추려 정리한다. dreaming은 낡은 항목을 교체하고, 여러 실행에 걸쳐서만 드러나는 패턴을 찾아낼 수 있다. 더 알고 싶다면 에이전트 메모리에 관한 우리 글이 이 내용을 더 자세히 다룬다.

컨텍스트 창 안에서

에이전트는 일을 시작하기 전에 시스템 프롬프트, 도구 정의, 메모리 파일을 불러온다. 이 초기 컨텍스트라는 “고정 부담(overhead)”은 모든 실행에 들어간다. 그래서 이를 가볍게 유지하고 프롬프트 캐싱으로 비용을 낮추기를 권한다.

새 세션은 이 컨텍스트 고정 부담과 실행을 촉발한 이벤트만 가지고 시작한다. 반면 기존 세션은 앞선 실행들의 메시지와 도구 호출을 다시 불러온다.

세션이 너무 길어지면 오래된 메시지를 압축(compaction)하거나 새 세션을 시작할 수 있다. 두 방법 모두 세부 정보를 잃는다. 그러니 계속 남아야 하는 것은 작업하는 동안 그때그때 메모리에 저장해야 한다.

권한(Permissions)

상시 가동 에이전트의 위험이 가장 크게 몰리는 곳이 권한이다. 실행은 사용자의 접근 권한을 쥐고 있고, 설계상 지켜보는 사람 없이 동작한다. 에이전트는 도구 호출마다 스스로 진행할지, 막을지, 승인을 기다릴지 정해야 한다.

권한을 이루는 요소는 다른 에이전트가 쓰는 것과 같다.

• 자격 증명 저장소: 상시 가동 에이전트가 쓸모 있으려면 비밀번호나 액세스 토큰 같은 민감한 사용자 자격 증명이 필요한 경우가 많다. 권장 패턴은 에이전트 환경 밖에 프록시를 두고, 이 프록시가 나가는 요청에 자격 증명을 붙이는 방식이다. 에이전트는 자격 증명 없이 요청을 보내고, 프록시가 요청을 전달하기 전에 실제 자격 증명을 주입한다.
• Auto mode: 상시 가동 에이전트는 사용자가 계속 입력하지 않아도 일할 수 있어야 한다. 우리는 Claude Code의 auto mode로 이 문제의 한 형태를 이미 다뤘다. auto mode는 분류기로 위험도가 높은 동작을 검토하고, 분류기가 위험하다고 판단한 동작을 막는다. 그러면 Claude가 더 안전한 방법을 찾을 수 있다. 하지만 가장 중요한 결정에는 여전히 사용자의 검토가 필요하다.
• 보류된 도구 호출(deferred tool call): Claude Code에서는 훅(hook)이 도구 호출을 보류하고 사용자의 추가 입력을 기다릴 수 있다. 같은 패턴이 상시 가동 에이전트에도 적용된다. 상시 가동 에이전트도 특정 동작을 하기 전에 추가 설명이나 승인이 필요할 수 있기 때문이다. 호출이 보류되면 실행은 끝나고, 세션은 호출 도중 상태로 저장된다. 요청은 사용자에게 표시되고(예: MCP Apps로 만든 대화형 카드를 통해), 사용자의 답은 인박스에 이벤트로 돌아온다. 그 이벤트가 새 실행을 시작하고, 새 실행은 사용자의 입력을 가지고 저장된 세션을 재개한다. 보류된 호출이 응답을 기다리는 동안 워커는 다른 이벤트를 처리할 수 있다. 그래서 에이전트가 막히지 않는다.

아웃박스(Outbox)

대부분의 AI 에이전트에서는 응답이 생성되는 대로 사용자에게 스트리밍된다. 그래서 사용자는 Claude가 문제를 추론하고, 도구를 호출하고, 답을 쓰는 과정을 따라갈 수 있다.

반면 상시 가동 에이전트는 일의 대부분을 백그라운드에서 한다. 사용자는 단계별 전 과정 대신 결과와 몇 가지 세부 사항을 받는다.

실행은 다음 세 가지 중 하나로 끝날 수 있다.

• 에이전트가 아웃박스로 메시지를 보낸다.
• 에이전트가 보낼 것이 없다고 판단한다.
• 에이전트가 보류된 도구 호출로 권한이나 추가 입력을 요청한다.

대부분의 상시 가동 에이전트는 메시지를 사용자에게 바로 전달하는 “전송(send)” 도구 하나로 충분하다. 정식 아웃박스는 에이전트가 보내는 메시지의 속도를 조절하고 싶거나, 에이전트가 오류에서 복구할 수 있게 하고 싶을 때만 필요하다.

아웃박스는 나가는 메시지를 담는 별도 테이블로, 이벤트 인박스에 대응한다. 워커에 대응하는 디스패처도 있다. 디스패처는 보통 백그라운드 서비스다. 디스패처는 대기 중인 메시지를 읽고, 무엇을 전달할지 정한 뒤, 그 메시지를 사용자에게 보낸다. 보류된 도구 호출에서 나온 요청은 아웃박스를 거칠 수도 있고 인터페이스에 바로 표시될 수도 있다.

전달 말고도, 에이전트가 메시지를 얼마나 보낼지 조정하는 일이 중요하다. 너무 많이 보내는 에이전트는 시끄러워지고, 너무 적게 보내는 에이전트는 사용자가 알아야 할 것을 놓친다. 적절한 균형을 찾으려면 평가(evals)를 만들기를 권한다. 실제로는 에이전트가 조용하게 시작해서 시간이 지나며 사용자의 관심을 더 얻어 가는 편이 낫다.

모든 요소가 맞물리는 방식

다섯 가지 기본 구성 요소는 다음과 같이 맞물린다.

모든 실행은 인박스의 이벤트에서 시작한다. 그 이벤트가 사용자 메시지든, 웹훅이든, 타이머든 마찬가지다. 워커가 이벤트를 집으면 실행을 개시하고, 새 세션이나 기존 세션에서 에이전트를 깨운다. 에이전트는 메모리를 읽어 기준선을 잡고, 권한 범위 안에서 행동한 뒤, 새로 알게 된 것으로 메모리를 갱신한다. 실행이 끝나면 에이전트는 아웃박스에 행 하나를 넣고, 디스패처가 그 메시지를 사용자에게 전달한다.

이것들이 모여 하나의 주기를 이룬다. 실행은 나중에 에이전트를 다시 깨울 타이머를 설정할 수 있고, 사용자가 메시지에 답하면 그 답은 인박스에 이벤트로 돌아온다. 실행 하나하나는 짧지만 주기는 끝없이 계속된다. 에이전트가 상시 가동하는 것처럼 느껴지게 만드는 것이 바로 이 점이다.

감사의 말

William Hu가 썼다. 기여해 준 Rodrigo Olivares와 Michael Segner에게 특별히 감사한다.

원본 링크·인용

원문 주소와 원문이 건 링크 20개

원문

• Building always-on agents — 한국어 페이지 — 한국어 로캘 주소(/ko/).
• Building always-on agents — 영문 원본. 한국어 페이지의 canonical 주소.

저자 William Hu(Applied AI @ Anthropic) · 발행 2026-11-13 · Anthropic claude.com Resources › Articles · 카테고리 Best practices · 제품 태그 Claude Platform · 감사 Rodrigo Olivares, Michael Segner

본문 링크 11개 — 원문 등장 순서

1. 「Building effective AI agents」 — 도입부 둘째 문단, 앵커 'core loop'
2. 「비용과 지능 최적화」 — 도입부 셋째 문단, 앵커 'one long-horizon coding benchmark'
3. 「Claude가 프로젝트를 기억하는 방법」 — 메모리 절 둘째 문단, 앵커 'auto memory'
4. 「메모리 도구」 — 메모리 절 둘째 문단, 앵커 'memory tool'
5. 「The components of agent memory」 — 메모리 절 dreaming 문단, 앵커 'post on agent memory'
6. 「프롬프트 캐싱」 — 메모리 절의 「컨텍스트 창 안에서」 소절 첫 문단, 앵커 'prompt caching'
7. 「압축 개요」 — 같은 소절 셋째 문단, 앵커 'compact the older messages'
8. 「AI 에이전트 안전하게 배포하기」 — 자격 증명 관리 — 권한 절 자격 증명 저장소 항목, 앵커 'recommended pattern'
9. 「How we built Claude Code auto mode」 — 권한 절 auto mode 항목, 앵커 'auto mode'
10. 「Hooks 참조」 — 도구 호출 보류 — 권한 절 보류된 도구 호출 항목, 앵커 'a hook can defer a tool call'
11. 「MCP Apps」 — 같은 항목, 앵커 'MCP Apps'

원문 페이지 목차 4개

• The cycle behind the always-on agent — 첫째 절, 실행 주기
• The core primitives — 둘째 절, 기본 구성 요소 다섯 개
• How everything fits together — 셋째 절, 다섯 요소의 연결
• Acknowledgements — 감사의 말

원문 카테고리

• Best practices — 원문 페이지 머리의 분류 표시

원문 페이지의 관련 아티클 4개

• The Claude Tag guide for startups — claude.com, 2026-11-13
• How Curative is building a national provider network with agents on Claude — claude.com 고객 사례, 2026-11-10
• Safely scaling multi-agent teams with Claude Fable 5.2 — claude.dev 블로그, 2026-11-09
• Which Claude model should you build with? — claude.dev 블로그, 2026-11-09

기타

용어와 원문 페이지

용어

표의 왼쪽은 이 문서가 쓰는 낱말, 오른쪽은 원문 낱말이다.

auto memory, auto mode, dreaming, MCP Apps는 기능 이름이라 원문 그대로 쓴다. Messages API, Claude Code, Opus 5.5, Opus 5 같은 제품·모델 이름도 옮기지 않는다.

원문 페이지

claude.com 한국어 페이지(/ko/)는 이 글을 번역하지 않고 영문 본문을 그대로 싣는다. 제목과 데크도 영문이다. 이 문서의 완역은 그 영문 본문을 옮긴 것이다. 한국어 페이지와 영문 페이지의 본문 텍스트는 글자 단위로 같다. 두 페이지의 차이는 둘이다.

• 사이트 크롬의 언어. 한국어 페이지는 분류·제품·날짜("2026년 11월 13일")·읽기 소요 시간·공유·목차 표기와 하단 관련 아티클 영역을 한국어로 보여 준다.
• 문서 링크의 언어. 본문 링크 11개 가운데 Claude 문서로 가는 7개는 한국어 페이지에서 한국어 문서(platform.claude.com/docs/ko/…, code.claude.com/docs/ko/…)를 가리킨다. 영문 페이지의 같은 링크는 /docs/en/ 아래의 영문 문서를 가리킨다. anthropic.com 글 3개와 modelcontextprotocol.io 문서 1개는 두 페이지가 같다. 이 문서의 링크는 한국어 페이지의 것이다.

그림 7장은 두 페이지가 같은 파일을 쓴다. 그림 7장의 대체 텍스트(alt)도 두 페이지가 같은 영문이다. 그림 안의 라벨은 원문 그대로 영어다.

수록 범위

원문 본문, 그림 7장, 링크 20개를 모두 싣는다. 본문 링크 11개는 완역의 같은 자리에 있다. 목차 앵커 4개, 카테고리 링크 1개, 관련 아티클 4개를 포함한 링크 20개 전부는 원본 링크·인용 블록에 모았다. 원문 페이지의 공유 버튼과 관련 아티클 안내 문구는 옮기지 않는다.