상시 작동하는 AI 에이전트는 열려 있는 대화가 없을 때도 일에 대한 책임을 계속 질 수 있는 에이전트입니다. 과제의 상태를 보존하고, 시간이 흐르거나 바깥세상이 바뀌기를 기다리고, 알맞은 환경에서 재개하며, 다음 결정이 사람의 몫일 때 통제권을 돌려줍니다.
"상시 작동"은 대형 언어 모델이 쉬지 않고 생각한다는 뜻이 아닙니다. 컴퓨터가 밤낮없이 최대 출력으로 자원을 태워야 한다는 뜻도 아닙니다. 에이전트가 끊임없이 메시지를 보내거나 허락 없이 행동한다는 뜻이어서도 안 됩니다. 쓸모 있는 약속은 연속성입니다. 시스템 대부분이 잠들어 있는 동안에도 책임은 살아 있습니다.
프롬프트를 예약하거나 채팅 기록을 남기는 것만으로는 실제 질문에 답할 수 없습니다. 재시작 뒤에 무엇이 남는가, 무엇이 에이전트를 깨우는가, 어디서 일을 이어가는가, 사용자는 어떻게 멈출 수 있는가. 이 질문들에 대한 답이 "24/7"을 구호에서 시스템의 속성으로 바꿉니다.
상시 작동은 가동 시간이 아니라 연속성의 문제다
가동 시간은 프로세스가 돌아가고 있는지를 말합니다. 연속성은 그 일에 여전히 책임지는 주체와 유효한 다음 단계가 있는지를 말합니다.
서명된 계약서가 돌아오는지 지켜보다가, 도착하면 출시 체크리스트를 업데이트하고, 다음 결정을 준비해 달라고 에이전트에게 부탁했다고 해 봅시다. 계약서는 내일 올 수도 있고 다음 주에 올 수도 있습니다. 그 기다림 동안 쓸모 있는 추론은 일어나지 않습니다. 에이전트에게는 열린 채팅도, 계속 데워져 있는 모델 세션도, 받은편지함을 매분 새로 고치는 브라우저도 필요 없습니다. 필요한 것은 그 책임에 대한 지속적인 기록과, 관련 이벤트가 그 책임을 다시 움직이게 할 믿을 만한 방법입니다.
이 차이는 장애가 났을 때 분명해집니다. 프로세스는 계속 돌고 있어도 충돌 뒤에 과제를 잃을 수 있습니다. 다른 시스템은 몇 시간 동안 0까지 줄어들었다가, 이벤트가 오면 상태를 다시 세우고 올바르게 재개할 수 있습니다. 더 의미 있게 상시 작동하는 쪽은 두 번째 시스템입니다.
그래서 지속형 에이전트 인프라는 기다림과 계산을 분리합니다. 예를 들어 Microsoft의 현재 Agent Framework용 Durable Extension은 워커 실행 사이에 상태를 유지하고, 계산 자원이나 모델 토큰을 쓰지 않은 채 일시 정지했다가, 외부 이벤트로 재개하는 에이전트를 설명합니다. Google의 이벤트 기반으로 재개하는 장기 실행 에이전트 가이드도 지속적인 체크포인트와 webhook으로 같은 원칙을 보여 줍니다. 구현 세부는 달라도 아키텍처의 교훈은 같습니다. 상시 작동하는 책임에 늘 돌아가는 모델이 필요한 것은 아닙니다.
믿을 만한 상시 작동 에이전트를 떠받치는 여섯 가지 조건
에이전트를 상시 작동하게 만드는 단일 기능은 없습니다. 이 속성은 여섯 가지 조건이 함께 작동할 때 나타납니다.
이어지는 정체성이 책임을 맡는다
시스템에는 메시지, 이벤트, 권한, 작업, 사용자의 기대를 묶을 수 있는 안정적인 정체성이 필요합니다. 대화마다 운영 맥락을 공유하지 않는 별개의 에이전트가 생긴다면, 나중에 오는 이벤트가 깨울 대상도 없고 일을 이어갈 책임을 지는 주체도 없습니다.
이어지는 정체성에 무한한 기억이 필요한 것은 아닙니다. 사용자가 같은 에이전트로 돌아올 수 있고, 시스템이 어떤 책임이 그 에이전트에 속하는지 안다는 뜻입니다. 개인에 관한 사실, 대화 기록, 작업 상태는 여전히 서로 다른 수명과 통제 방식을 가질 수 있습니다.
작업 상태가 유휴 시간을 견딘다
과제는 처음 프롬프트보다 많은 것을 간직해야 합니다. 재개에 필요한 상태에는 의도한 결과, 완료한 작업, 작업 중인 산출물, 제약, 현재의 걸림돌, 유효한 다음 단계가 포함될 수 있습니다.
그 상태는 평범한 중단을 견딜 만큼 지속적이어야 합니다. 닫힌 브라우저, 잠든 컴퓨터, 배포된 업데이트, 워커 재시작, 며칠의 시간 경과 같은 것들입니다. 대화 기록은 무슨 일이 있었는지 재구성하는 데 도움이 되지만, 재구성은 복구와 같지 않습니다. 믿을 만한 시스템은 깨어날 때마다 긴 대화에서 모델이 진실을 추론하게 하는 대신, 어떤 상태가 기준인지 압니다.
하나의 과제를 여러 의존 관계에 걸쳐 이어가는 더 깊은 방식은 이 범주의 정의와는 별개의 문제입니다. 이 수준에서의 시험은 더 단순합니다. 시스템이 새로 설명을 듣지 않고도 이어갈 수 있을 만큼 유효한 상태를 보존할 수 있는가?
시간과 이벤트가 시스템에 다시 들어올 수 있다
바깥세상의 일은 사용자가 메시지를 보낼 때만 진척되지 않습니다. 마감이 다가옵니다. 파일이 바뀝니다. 답장이 도착합니다. 기기가 다시 온라인이 됩니다. 승인이 다른 애플리케이션에 기록됩니다.
그래서 상시 작동하는 에이전트에게는 대화용 입력창 이상의 것이 필요합니다. 타이머나 외부 이벤트가 그것이 영향을 주는 책임에 닿을 경로가 필요합니다. 그 경로는 webhook, 메시지 큐, 일정, 커넥터, 범위를 좁게 정한 감시 프로세스 등이 될 수 있습니다. 중요한 것은 이벤트를 올바른 에이전트와 올바른 상태에 연결할 수 있다는 점입니다.
그렇다고 모든 이벤트가 완전한 추론 실행을 받을 자격이 있다는 뜻은 아닙니다. 이벤트 기반 운영이 가치 있는 이유는 바로 평가할 일이 생길 때까지 시스템 대부분이 조용히 있을 수 있기 때문입니다. 특정 이벤트가 메인 에이전트를 깨워야 하는지, 그리고 그 깨어남이 사람을 방해해야 하는지는 상시 작동 시스템 자체를 정의하는 것과는 별개의 정책 문제입니다.
일이 재개될 때 실행 환경을 쓸 수 있다
다음 단계를 기억해도 그것을 수행할 곳이 없다면 충분하지 않습니다. 어떤 일은 API로 할 수 있습니다. 어떤 일은 브라우저, 클라우드 컴퓨터, 로컬 기기, 전문 에이전트 런타임이 필요합니다. 책임이 다시 활성화될 때, 다음 단계에 필요한 파일, 도구, 권한을 갖춘 환경을 쓸 수 있어야 합니다.
"쓸 수 있다"는 것이 늘 돌아간다는 뜻은 아닙니다. 클라우드 컴퓨터는 저장소를 유지한 채 잠들었다가 필요할 때 깨어날 수 있습니다. 로컬 기기는 작업이 필요로 할 때까지 연결되지 않은 채로 있을 수 있습니다. 중요한 것은 에이전트가 필요한 환경을 알아보고, 그것이 없을 때 정직하게 대처하는 것입니다.
환경의 경계도 정확성의 일부입니다. Comma의 기기 문서에는 Salix가 오프라인 기기의 일을 다른 컴퓨터로 몰래 옮기지 않는다고 적혀 있습니다. 요청은 실패할 수 있고, 그 기기가 돌아오면 다시 시도할 수 있습니다. 모든 컴퓨터가 서로 바꿔 쓸 수 있는 척하는 것보다 마법 같지는 않지만, 그 일이 의존하는 위치, 접근, 실행 조건을 지켜 줍니다.
복구는 평소 운영의 일부다
상시 작동하는 시스템은 언젠가 재시작, 중복 이벤트, 쓸 수 없는 서비스, 만료된 자격 증명, 끊어진 연결을 만납니다. 그러니 신뢰성이 하나의 프로세스가 영원히 완벽하게 남는 데 의존할 수는 없습니다.
시스템에는 복구 경로가 필요합니다. 지속적인 상태, 체크포인트나 그에 준하는 기준 정보, 횟수에 상한이 있는 재시도, 외부 작업을 반복하지 않는 방법, 그리고 자동 복구가 더는 안전하지 않을 때 눈에 보이는 실패 상태입니다. 이미 확인된 일을 조용히 잊어버리는 재시작은 복구가 아닙니다. 결과를 바꾸지 못한 채 자원만 쓰는 무한 재시도 루프도 복구가 아닙니다.
Comma의 Loop 문서에 구체적인 예가 있습니다. Loop는 체크포인트를 저장했다가 다시 시작할 때 받을 수 있습니다. 장애가 나면 Salix는 상한이 있는 재시도 정책 안에서 그 체크포인트부터 Loop를 다시 시작하고, 실패가 반복되면 Loop를 멈추고 에이전트에게 알립니다. 지속 이벤트, 중복 제거, 배치, 기능 제한을 포함한 전체 구현은 분산 에이전트 하네스를 위한 프로그래밍 가능한 이벤트 루프에서 설명합니다. 제품을 평가할 때는 중단과 복구가 뜻밖의 일이 아니라 계획된 상태인지 확인하세요.
사용자가 연속성을 보고 제한할 수 있다
지속될수록 통제는 더 중요해집니다. 한 번으로 끝나는 채팅은 자연스럽게 끝납니다. 백그라운드 책임에는 이해하기 쉬운 범위, 눈에 보이는 상태, 실제로 작동하는 끄기 스위치가 필요합니다.
사용자는 에이전트가 무엇을 책임지는지, 어떤 출처를 지켜보는지, 어떤 환경을 쓸 수 있는지, 그곳에서 어떤 권한이 있는지 알 수 있어야 합니다. 그 책임을 일시 정지하거나 끝내고, 접근을 취소하고, 이미 만들어진 결과를 되찾을 수 있어야 합니다. 시스템은 침묵을 모든 게 괜찮다는 증거로 다루지 말고, 실패와 결과가 따르는 결정을 드러내야 합니다.
상시 작동과 자율이 같은 말이 아닌 것도 그래서입니다. 지속성은 시스템이 계속 쓸 수 있는 상태로 남는다는 뜻입니다. 자율은 묻지 않고 어떤 결정이나 행동을 할 수 있는지를 뜻합니다. 에이전트는 아주 지속적이면서도 일부러 보수적일 수 있습니다. 준비하고, 확인하고, 정리하고, 기다리면서도 외부에 대한 약속이나 되돌릴 수 없는 선택은 사용자에게 돌려줄 수 있습니다.
끝없는 한 번의 실행이 아닌 네 가지 운영 모드
"상시 작동"이라는 말은 하나의 끊임없는 활동을 떠올리게 합니다. 실제로 쓸모 있는 에이전트는 뚜렷이 다른 몇 가지 모드를 오갑니다.
모델과 도구가 과제를 적극적으로 진척시키는 작업 중일 수 있습니다. 시간, 이벤트, 환경, 사람의 결정이 아직 오지 않아 대기 중일 수 있습니다. 가벼운 감시자가 메인 에이전트를 깨우지 않은 채 좁은 조건을 모니터링 중일 수 있습니다. 또는 사용자가 끝냈거나 장애가 안전한 복구 정책을 넘어섰기 때문에 책임이 중지되었을 수 있습니다.
이 모드들은 신뢰성만큼이나 비용과 주의에도 중요합니다. 모델 추론, 클라우드 계산, 이벤트 수집, 저장소, 외부 API는 저마다 과금 방식이 다를 수 있습니다. 제품은 이것들을 뭉뚱그려 "에이전트가 24/7 돌아갑니다"라는 조건 없는 주장으로 만들어서는 안 됩니다. 조용한 백그라운드 책임은 저장소와 모니터링 자원을 쓰면서도 대형 모델 토큰은 전혀 쓰지 않을 수 있습니다. 활성화된 작업은 모델과 계산 자원을 모두 쓸 수 있습니다. 중지된 책임은 보존된 상태 외에는 어느 쪽도 써서는 안 됩니다.
Comma는 자체 런타임에 이 구분을 반영합니다. Salix는 계속 데워져 있는 샌드박스 밖에서 에이전트를 실행합니다. 컴퓨터 작업이 필요하면, 사용 사이에도 저장소가 유지되는 클라우드 가상 머신을 깨울 수 있습니다. 지속적인 주의를 위해서는 작은 Loop가 메인 에이전트 루프를 계속 활성화하지 않고도 이벤트를 지켜볼 수 있습니다. Loop가 에이전트가 필요하다고 판단할 때만 메인 루프가 실행됩니다.
이 아키텍처는 Comma의 구현일 뿐 보편적인 정의는 아닙니다. 다른 제품은 지속형 워크플로, 큐, 서버리스 함수, 장시간 실행되는 워커를 쓸 수 있습니다. 시험대는 특정 런타임을 쓰느냐가 아니라, 시스템 전체가 유휴 기간 동안 책임을 지켜 내느냐입니다.
상시 작동, 예약 실행, 장기 실행은 서로 다른 약속이다
예약된 자동화는 정해진 시간에 지시를 실행합니다. 이어지는 에이전트 정체성을 유지하지 않고 예정에 없던 변화에 반응하지 않아도 무척 쓸모 있을 수 있습니다. 매일 돌아가는 작업이 고정된 입력으로 보고서를 만든다면, 시스템에 필요한 것은 일정뿐일 수도 있습니다.
장기 실행 워크플로는 여러 단계에 걸쳐 상태를 유지하고 신호를 기다릴 수 있습니다. 모델이 정보를 해석하고, 도구를 고르고, 계획을 조정하는 데 참여하면 에이전트다워집니다. 그 지속형 워크플로가 관련된 새 이벤트를 받고 사용자가 관리하는 경계 안에서 행동할 수 있는 이어지는 에이전트에 속할 때, 비로소 의미 있게 상시 작동합니다.
챗봇도 지난 대화를 기억하고 알림을 줄 수 있습니다. 이런 기능은 사용자에게 연속성을 높여 주지만, 그것만으로 일이 채팅 밖에서도 이어진다는 증거가 되지는 않습니다. 결정적인 질문은 시스템이 당신에 관해 무언가를 기억하느냐가 아닙니다. 진행 중인 책임이 손으로 다시 만들지 않아도 기다리고, 재개하고, 복구되고, 허가된 환경에 닿을 수 있느냐입니다.
이 구분은 과도한 구축도 막아 줍니다. 모든 요청에 상시 작동하는 에이전트가 필요한 것은 아닙니다. 일회성 설명, 고쳐 쓰기, 계산, 브레인스토밍은 대화형 모델로 처리하는 편이 나은 경우가 많습니다. 상시 작동이 그 복잡성만큼의 값을 하는 것은 결과가 시간, 외부의 변화, 여러 작업 환경, 혹은 지금 대화가 끝난 뒤에도 열려 있는 책임에 달려 있을 때입니다.
연속성을 확인하는 실용적인 시험
"상시 작동"을 내세우는 제품을 평가하려면 빈틈이 있는 현실적인 책임을 하나 맡겨 보세요. 정해진 조건을 모니터링하고, 다음 단계를 준비하고, 결과가 따르는 행동 앞에서 멈추라고 요청하세요.
그런 다음 제품이 무엇을 보여 주는지 살펴보세요. 화면을 닫은 뒤 과제는 어디에 저장되나요? 정확히 어떤 조건이 그것을 다시 움직이게 하나요? 작업 자료가 어느 환경에 있는지 아나요? 재시작 뒤에 이미 끝낸 작업을 반복하지 않고 재개할 수 있나요? 이벤트가 중복되거나 필요한 기기가 오프라인이면 어떻게 되나요? 기록을 모두 지우지 않고도 감시를 멈추거나, 접근을 취소하거나, 과제를 끝낼 수 있나요?
마지막으로 당신에게 무엇이 도착하는지 보세요. 모든 이벤트를 전달하는 시스템은 알림 파이프라인을 만든 것이지 반드시 에이전트를 만든 것은 아닙니다. 모든 이벤트에 행동하는 시스템은 가용성과 권한을 혼동한 것입니다. 쓸모 있는 상시 작동 에이전트는 변화를 기존 책임과 연결하고, 이미 허락된 일을 해내고, 주의를 기울이는 것이 결과를 바꿀 때만 주의를 요청합니다.
Comma가 시끄럽지 않으면서도 늘 쓸 수 있는 방법
Comma는 무료 오픈 소스 개인 에이전트로, 대화와 기기를 넘나드는 하나의 이어지는 에이전트를 중심으로 설계되었습니다. 간단한 질문은 채팅에 머물러도 되고, 큰 책임은 Task가 됩니다. Comma는 연결된 앱과 파일에서, 연결된 Mac이나 Linux 기기에서, 또는 필요할 때 깨어나는 클라우드 컴퓨터에서 일할 수 있습니다.
그 상시 작동 계층이 Salix입니다. Comma 에이전트는 받은편지함, 저장소, 피드, API, webhook처럼 범위가 정해진 출처를 지켜보는 Loop를 만들 수 있습니다. Loop는 메인 추론 루프와 따로 실행되고, 작은 체크포인트를 유지하며, 일이 필요할 때 에이전트에게 알릴 수 있습니다. 메인 에이전트가 조용한 시간을 일일이 살필 필요가 없으므로 "늘 쓸 수 있다"가 "늘 모델 토큰을 쓴다"로 바뀌지 않습니다. 그래도 Loop는 빠른 판단 모델이나 다른 서비스를 호출할 수 있으므로 백그라운드 작업이 저절로 무료가 되지는 않습니다. 비용은 Loop가 실제로 무엇을 하느냐에 달려 있습니다.
같은 연속성은 계속 사용자의 통제 아래 있습니다. 연결된 컴퓨터는 사용자가 작업을 허용하기 전까지 읽기 전용으로 시작하고, 기기 접근은 취소할 수 있습니다. Loop에는 기능과 깨우기 횟수 제한이 있습니다. 결정이 사람의 몫일 때 큰 Task는 검토 필요로 돌아올 수 있습니다. Comma는 셀프 호스팅도 할 수 있지만, 그 경우 그 인스턴스를 계속 운영하는 데 필요한 가용성, 업그레이드, 백업, 모델 설정과 그 밖의 인프라는 운영자가 맡습니다.
Comma의 접근은 이 범주의 핵심 문제에 대한 하나의 답입니다. 책임은 지속시키면서, 비싼 계산과 모델과 사용자의 주의는 정말 필요할 때까지 쉬게 하는 것입니다.
자주 묻는 질문
상시 작동하는 AI 에이전트는 모델을 24/7 돌리나요?
아닙니다. 잘 설계된 시스템은 메인 모델이 비활성일 때도 상태를 보존하고 타이머나 이벤트를 기다릴 수 있습니다. 모델은 시스템이 추론이나 생성을 필요로 할 때 실행됩니다. 에이전트가 기다리는 동안에도 가벼운 모니터링, 저장소, 외부 서비스는 자원을 쓸 수 있습니다.
상시 작동하는 에이전트는 자율 에이전트와 같은가요?
아닙니다. 상시 작동은 시간에 걸친 연속성과 가용성을 말합니다. 자율은 사람의 승인 없이 에이전트가 무엇을 결정하거나 할 수 있는지를 말합니다. 상시 작동하는 에이전트는 좁은 권한으로 운영되면서 결과가 따르는 결정을 사용자에게 돌려줄 수 있습니다.
예약된 AI 작업은 상시 작동하는 에이전트인가요?
꼭 그렇지는 않습니다. 일정은 상태 없는 프롬프트를 정해진 시간에 실행할 수 있습니다. 상시 작동하는 에이전트는 여기에 더해 책임과 관련 상태를 보존하고, 적절한 외부 이벤트에 반응하고, 중단에서 복구되며, 지속되는 사용자 통제 범위 안에서 일을 이어갑니다.
에이전트의 컴퓨터는 계속 켜져 있어야 하나요?
필요한 환경에 따라 다릅니다. 클라우드나 서버 쪽 작업은 개인 노트북을 닫아도 계속될 수 있습니다. 특정 로컬 기기에만 있는 파일이나 애플리케이션에 의존하는 작업은 그 기기를 기다려야 합니다. 어떤 클라우드 환경은 저장소를 유지한 채 작업 사이에 잠들 수 있습니다.
상시 작동하는 에이전트가 실패하면 어떻게 되나요?
시스템은 알려진 체크포인트나 지속 상태에서 복구하고, 이미 끝낸 외부 작업을 반복하지 않으며, 상한이 있는 재시도를 써야 합니다. 안전하게 복구할 수 없다면 끝없이 재시도하거나 책임을 조용히 내버리지 말고, 눈에 보이게 멈춰서 무엇이 실패했는지 에이전트나 사용자에게 알려야 합니다.
상시 작동하는 에이전트를 끌 수 있나요?
백그라운드 책임을 일시 정지하거나 끝내고, 그것이 쓰는 접근을 취소할 수 있어야 합니다. "상시 작동"은 허락되었을 때 쓸 수 있다는 뜻이지, 멈출 수 없다는 뜻이 아닙니다. Comma에서는 Loop를 일시 정지하거나 삭제할 수 있고, 연결된 기기에 대한 접근도 취소할 수 있습니다.
에이전트는 잠들 수 있어도 책임은 사라지지 않는다
상시 작동하는 AI 에이전트를 정의하는 것은 끊임없는 모델 활동이 아닙니다. 끊기지 않는 책임의 사슬입니다. 안정적인 주체, 지속되는 상태, 시간과 이벤트가 의미를 갖는 경로, 쓸 수 있는 실행 환경, 복구 가능한 운영, 그리고 사용자의 손에 남는 통제입니다.
이런 조각이 갖춰지면 시스템 대부분은 대부분의 시간 동안 조용히 있을 수 있습니다. 모델은 멈출 수 있습니다. 클라우드 컴퓨터는 잠들 수 있습니다. 사용자는 앱을 닫을 수 있습니다. 일이 재개되는 것은 누군가 "계속해"라고 입력하는 걸 기억해서가 아니라, 책임이 여전히 온전하기 때문입니다.
