Anthropic, 상시 가동 에이전트 설계법 공개, 핵심 구성 5가지

Anthropic이 claude.com 리소스 글 'Building always-on agents'(발행 2026년 11월 13일)에서 상시 가동 에이전트를 만드는 방법을 정리했다. 이벤트 수신함, 타이머, 메모리, 권한, 발신함의 다섯 가지 구성 요소로 에이전트가 언제 깨어나고, 무엇을 이어받고, 결과를 어떻게 사용자에게 전하는지 설계하는 방법을 담았다.

상시 가동 에이전트는 여러 세션에 걸쳐 맥락을 관리하고, 사용자가 직접 감독하지 않아도 먼저 행동하는 에이전트다. Anthropic은 핵심 반복 구조가 다른 에이전트와 같고, 차이는 주변 구조에 있다고 설명했다. 일부 고객사는 기존 에이전트를 더 능동적으로 만들려 하고, 다른 고객사는 처음부터 새로 만들려 한다고 한다.

Anthropic은 최근 몇 달 사이 상시 가동 에이전트가 다시 늘어난 이유로 모델 발전을 꼽았다. 최신 모델은 사용자 의도를 파악하고 언제 확인을 구할지 판단하는 일이 더 믿을 만해졌다. 지능 비용도 떨어지고 있으며, 긴 작업에서 혜택이 가장 크다고 설명했다. 한 장기 코딩 벤치마크에서 Opus 5.5는 Opus 5보다 해결한 작업당 비용이 78% 낮았고, 일반 워크로드에서는 40% 낮았다.

깨어나서 일하고 다시 잠드는 주기

Anthropic에 따르면 상시 가동 에이전트는 실제로 계속 켜져 있지 않다. 대부분 잠든 상태로 있다가 주기적으로 깨어나 일하며, 이 한 번의 작업 구간을 실행(run)이라 부른다. 에이전트는 이벤트를 받아 작업을 마치고 무슨 일이 있었는지 저장한 뒤 다시 잠든다. 실행은 메시지와 도구 호출 기록인 세션 안에서 이뤄진다.

이벤트 수신함은 웹훅, 예약 작업, 백그라운드 작업 등 여러 출처의 이벤트를 받는 곳이다. 출처가 에이전트를 직접 부르면 동시에 온 이벤트가 경쟁하는 실행을 만들거나, 충돌로 이벤트가 사라질 수 있다. 그래서 모든 출처가 수신함에 이벤트를 보내고 작업자(worker)가 가져가게 한다. 가장 단순한 형태는 이벤트를 쌓는 내구성 있는 목록(보통 데이터베이스 표), 이를 기록하는 처리기(보통 HTTP 엔드포인트), 목록을 읽는 작업자(보통 백그라운드 서비스)로 이뤄진다.

수신함은 이벤트마다 상태를 추적하고, 출처의 고유 식별자로 중복을 걸러낼 수 있다. Anthropic은 관계형 데이터베이스에 이벤트를 행으로 추가하는 방식을 권하며, 사용자마다 수신함 하나로 시작하라고 했다. 병렬 처리가 더 필요하면 나눌 수 있다. 사용자 답장처럼 이전 작업을 잇는 이벤트는 기존 세션을 재개하고, 나머지는 새 세션을 연다.

• 처리기는 이벤트를 빨리 확인 응답해야 한다. 웹훅 제공자는 느린 응답을 실패로 보는 경우가 있다. 처리기는 가벼운 점검은 할 수 있으나, 프롬프트 인젝션 점검 같은 깊은 검증은 실행 중에 한다.
• 수신함이 기준 저장소다. 작업자가 실행 도중 죽어도 새 작업자가 같은 이벤트를 가져와 다시 시도할 수 있다.
• 수신함마다 활성 작업자는 하나만 둔다. 실행 중 새 이벤트가 오면 다음 실행으로 넘기거나, 현재 실행에 합치거나, 중단하고 다시 시작할 수 있다.
• 대기 중인 이벤트는 묶어서 처리한다. 사용자가 메시지를 연달아 보내면 한 번의 실행으로 합쳐 답장을 한 번만 한다.

타이머와 메모리

타이머는 수신함과 함께 에이전트가 먼저 움직이게 한다. 답장 확인처럼 에이전트가 스스로 정하는 마감인 후속 확인(follow-up)과, 매일 뉴스레터처럼 정해진 주기로 반복하는 일정(schedule)으로 나뉜다. 타이머는 수신함과 분리된 별도 저장소(보통 또 다른 데이터베이스 표)에 두며, 수신함에는 바로 처리할 이벤트만 둔다. 일정은 반복 주기도 추적해야 한다.

타이머가 직접 실행을 시작하지는 않는다. 스케줄러(보통 백그라운드 서비스)가 일정한 간격으로 저장소를 훑어 기한이 된 타이머를 찾는다. 후속 확인은 완료로 표시하고, 일정은 다음 시각으로 갱신한 뒤 수신함에 이벤트를 넣고 작업자를 깨운다. 스케줄러는 직접 만들어도 되고 내구성 실행 엔진을 써도 된다.

에이전트는 끊어진 여러 실행에 걸쳐 일하므로 메모리로 연속성을 유지한다. Anthropic 제품에서는 Claude Code의 자동 메모리와 Messages API의 메모리 도구가 파일 디렉터리로 구현돼 있다. 상시 가동 에이전트는 이 디렉터리를 데이터베이스나 객체 저장소 같은 내구성 있는 저장소에 연결해 작업자가 사라져도 기억이 남게 해야 한다. 이슈 트래커처럼 다른 시스템에서 다시 찾을 수 있는 정보는 내용 대신 위치 정보만 저장한다.

여기에 드리밍(dreaming)을 더할 수도 있다. 지난 세션을 검토해 메모리를 정리하는 기능으로, 낡은 항목을 교체하고 여러 실행에 걸쳐서만 드러나는 패턴을 찾는다.

실행을 시작하기 전에 에이전트는 시스템 프롬프트, 도구 정의, 메모리 파일을 불러온다. 이 초기 부담은 매 실행에 포함되므로 가볍게 유지하고 프롬프트 캐싱으로 비용을 낮추라고 Anthropic은 권했다. 새 세션은 이 초기 맥락과 실행을 일으킨 이벤트로만 시작하고, 기존 세션은 이전 실행의 메시지와 도구 호출을 되살린다. 세션이 너무 길어지면 오래된 메시지를 압축하거나 새 세션을 시작하는데, 둘 다 세부 내용이 사라지므로 남겨야 할 정보는 미리 메모리에 저장해야 한다.

권한과 발신함

Anthropic은 권한이 상시 가동 에이전트에서 위험이 가장 큰 부분이라고 했다. 실행은 사용자의 접근 권한을 쥔 채 사람 없이 돌아가며, 에이전트는 도구 호출마다 알아서 진행할지, 막을지, 승인을 기다릴지 정해야 한다.

• 자격 증명 저장소: 에이전트에게 비밀번호나 액세스 토큰이 필요한 경우가 많다. 권장 방식은 에이전트 환경 밖의 프록시가 나가는 요청에 자격 증명을 붙이는 것이다. 에이전트는 자격 증명 없이 요청을 보내고, 프록시가 실제 값을 넣어 전달한다.
• 자동 모드: Claude Code의 자동 모드는 분류기가 위험도가 높은 행동을 검토해 위험하다고 판단한 것을 막고, Claude가 더 안전한 방법을 찾게 한다. 가장 중요한 결정에는 여전히 사용자 검토가 필요하다.
• 보류된 도구 호출: Claude Code에서는 훅이 도구 호출을 보류하고 사용자 입력을 기다릴 수 있다. 보류하면 실행이 끝나고 세션이 호출 도중 상태로 저장된다. 요청은 MCP Apps로 만든 대화형 카드 등으로 사용자에게 보이고, 답은 수신함의 이벤트로 돌아와 새 실행이 저장된 세션을 재개한다. 기다리는 동안 작업자는 다른 이벤트를 처리하므로 에이전트가 막히지 않는다.

일반 에이전트는 응답을 생성하는 대로 사용자에게 스트리밍하지만, 상시 가동 에이전트는 대부분 백그라운드에서 일하고 사용자에게 결과와 몇 가지 세부 사항만 전한다. 실행은 에이전트가 발신함에 메시지를 보내거나, 보낼 것이 없다고 판단하거나, 보류된 도구 호출로 승인이나 추가 입력을 요청하며 끝난다.

대부분은 메시지를 사용자에게 바로 보내는 '보내기' 도구로 충분하다. 메시지 속도를 조절하거나 오류에서 복구하려 할 때만 정식 발신함이 필요하다. 발신함은 수신함과 비슷한 별도 표이고, 작업자에 해당하는 디스패처(보통 백그라운드 서비스)가 대기 메시지를 읽어 보낼 것을 정해 전달한다. 보류된 도구 호출의 요청은 발신함을 거치거나 화면에 직접 보여 줄 수 있다.

메시지 양도 조절해야 한다. 너무 많이 보내면 소음이 되고, 너무 적으면 사용자가 알아야 할 것을 놓친다. Anthropic은 적절한 균형을 찾으려면 평가(eval)를 만들라고 권하며, 조용하게 시작해 시간이 지나며 사용자의 관심을 얻어 가는 편이 낫다고 했다.

모든 실행은 사용자 메시지, 웹훅, 타이머 중 하나인 수신함 이벤트로 시작한다. 작업자가 이벤트를 가져가 새 세션이나 기존 세션에서 에이전트를 깨우면, 에이전트는 메모리를 읽어 기준을 잡고 권한 안에서 행동한 뒤 새로 알게 된 것을 메모리에 갱신한다. 실행이 끝나면 발신함에 행을 추가하고 디스패처가 사용자에게 전달한다. 실행이 나중에 에이전트를 다시 깨울 타이머를 설정할 수도 있고, 사용자의 답은 수신함의 이벤트로 돌아온다.