BRIEFING
24시간 돌아가는 개인 AI Agent는 어떻게 구성해야 하는가
24시간 돌아가는 개인 AI Agent는 어떻게 구성해야 하는가
Scope
핵심 질문
개인 AI Agent를 24시간 안정적으로 실행하려면 모델보다 어떤 운영구조가 먼저 필요한가?
Draft
24시간 Agent의 핵심은 항상 켜진 LLM이 아니라 작업 큐, 상태 저장, 재시도와 알림이다.
구조
- 외부 이벤트나 schedule이 job을 만든다.
- Agent worker가 job을 가져가 모델과 도구를 실행한다.
- 중간 상태는 DB에 저장한다.
- 실패하면 재시도하고 반복 실패는 별도 queue로 보낸다.
- 사람 판단이 필요한 순간만 모바일로 알린다.
모델 프로세스가 재시작돼도 작업이 사라지지 않아야 하므로 상태를 대화 메모리에만 두면 안 된다. 도구를 실행하는 경우에는 읽기·쓰기 권한을 작업별 최소 범위로 제한하고, 결제·삭제·외부 메시지 같은 고위험 행동은 실행 전에 사람의 명시적 승인을 받는다. 외부 이벤트와 가져온 텍스트는 승인 지시가 아닌 비신뢰 데이터로 분리한다. event ID로 중복 job을 걸러내되 그것만으로 결제·삭제·외부 메시지의 중복 실행이 막히지는 않는다. 외부 부작용마다 별도의 작업·대상별 멱등키를 전달할 수 있으면 사용하고, 실행 의도·처리중·완료 상태를 durable outbox나 동등한 저장소에 기록한다. API 응답 전에 worker가 죽어 결과가 불명확하면 공급자의 처리 상태부터 조회·대조한 뒤에만 재시도한다. 멱등성이나 결과 확인이 불가능한 결제·삭제·전송은 자동으로 다시 실행하지 말고 사람의 재승인을 받는다. 실패 종류별로 재시도 횟수·시간을 제한하고 실행기록·실패알림·운영자 중단 경로를 마련해 부분 성공과 재시작을 실제로 시험해야 한다. 이는 운영 설계 조건이지 현재 실행 중인 Agent의 검증 결과는 아니다.
모델 배치
항상 GPU를 점유할 필요가 없다면 요청 시 모델을 호출하는 API 구조가 운영비가 낮다. 로컬 모델을 상시 띄우는 경우에도 Agent runtime과 inference server를 분리하면 업데이트와 장애격리가 쉽다.
결론
24시간 Agent는 chatbot daemon보다 durable job system에 가깝게 설계하는 것이 안정적이다.