10월 26일 월요일

상시형 에이전트를 몇 시간의 도구 호출 루프가 아니라 몇 주 동안 복구 가능하게 일하는 시스템으로 만들려면 어떤 계층을 함께 설계해야 하는가?

출발점은 모델이 도구를 호출하고 결과를 받아 다음 행동을 고르는 작은 루프다. 그러나 이 루프를 사용자의 터미널에만 두면 노트북이 닫히는 순간 시간적 지속성도 사라진다. 강연이 제시하는 상시형 구조는 중앙 서버가 대화 상태, 큐, 모델 루프, 외부 서비스 연결을 맡고, 별도 Linux 컴퓨터가 파일, 셸, 브라우저 같은 실행 환경을 제공하는 분리에서 시작한다. 여기서 ‘항상 켜짐’은 모든 자원을 계속 가동한다는 뜻이 아니다. 메시지나 예약 작업이 들어오면 서버가 상태를 불러오고 필요할 때만 컴퓨터를 깨운 뒤, 작업이 끝나면 상태를 저장하고 다시 잠재우는 수명주기가 핵심이다. 이 구조만으로도 충분하지 않다. 재시도 때 이미 끝낸 단계를 반복하지 않는 내구성 워크플로, 장기 기억과 컨텍스트 압축, 필요한 도구만 불러오는 동적 발견, 비가역 행동의 승인, 외부 입력의 신뢰 경계, 장기 수행을 재현하는 평가가 서로 맞물려야 한다. 결국 모델의 지능과 제품의 능력 사이를 메우는 것은 지속성·복구성·비용·보안을 함께 다루는 하네스다.

1. 01

   상태와 실행 환경을 분리한다

   에이전트 루프와 장기 상태를 서버에 두고, 실제 컴퓨터 조작은 교체 가능한 별도 환경에 둔다. 루프까지 가상 머신 안에 넣으면 보안 업데이트나 장애 대응 때 머신과 대화 상태를 함께 흔들 수 있다. 반대로 서버가 상태·큐·모델 호출을 보존하면 Linux 컴퓨터만 다시 만들 수 있다. 강연의 Firecracker 가상 머신 사례는 스냅샷과 재기동, 봇별 브라우저 분리를 제공하지만, 격리는 권한 통제를 대체하는 완성된 보안책이 아니라 한 계층이다. 따라서 설계 검증은 머신 교체 뒤에도 대화·파일·진행 지점을 일관되게 복원하는지, 서로 다른 에이전트의 브라우저와 파일이 실제로 분리되는지를 함께 확인해야 한다.

2. 02

   이벤트를 깨우고, 중복 없이 이어간다

   직접 메시지뿐 아니라 Slack, 이메일, 회의, 예약 루틴도 에이전트를 깨울 수 있으므로 트리거 라우터는 중복 사건을 합치고 요청 우선순위와 알림 필요성을 판별해야 한다. 단순 큐는 장애 뒤 처음부터 재생해 이미 보낸 요청이나 계산을 중복할 수 있다. 진행 지점을 저장하는 내구성 워크플로는 완료 단계를 건너뛰고 다음 단계부터 재개한다. 강연자는 Temporal을 예로 들지만, 제품이 검증해야 할 본질은 단계별 상태 기록과 재시도의 중복 안전성이다. 사용자가 진행 중인 계획을 자연어로 바꿀 때는 해당 입력을 뒤쪽 작업보다 우선 처리하고, 빠르게 연속된 메시지는 하나의 의도로 묶을지 결정하는 정책도 필요하다. 복구 시험은 프로세스·머신·도구 호출이 각각 중단된 경우를 나눠 완료 단계가 반복되지 않고 보류된 사용자 승인이 유지되는지도 확인해야 한다.

3. 03

   기억과 도구는 컨텍스트 예산으로 설계한다

   긴 작업을 모든 대화와 도구 설명을 한 번에 넣는 방식으로 버틸 수는 없다. 지속 선호, 날짜별 기록, 임시 메모를 나누고 자세한 지식은 파일에서 필요할 때 검색해야 한다. 도구도 전체 스키마를 매 요청에 싣기보다 이름을 먼저 보여 주고 선택된 세부만 불러오는 편이 작업 공간과 비용을 지킨다. 프롬프트 접두부와 도구 순서를 안정적으로 유지해 캐시를 살리고, 한계에 닿기 전에 핵심 정보를 보존하는 압축을 수행하되 압축 손실 자체를 설계 변수로 다뤄야 한다. 캐시가 따뜻할 때 압축을 미리 수행하는 운영도 가능하지만, 압축본에서 날짜·결정·미완료 항목이 빠지는지를 평가하지 않으면 비용 절감이 장기 정확성의 손실로 바뀐다.

4. 04

   오케스트레이터와 도우미의 경계를 세운다

   주 에이전트가 모든 셸 출력과 비싼 작업을 직접 품으면 작업 기억이 빠르게 오염된다. 오케스트레이터는 전체 목표, 우선순위, 사용자 조정을 유지하고, 서브에이전트는 별도 상태에서 긴 도구 작업을 수행한 뒤 결과만 돌려주는 편이 낫다. 다만 이는 컨텍스트 창을 무한하게 만드는 기술이 아니다. 도우미도 실패 뒤 재개할 상태와 스킬을 가져야 하며, 사용자는 진행 상황을 확인하거나 중지할 수 있어야 한다. 범용 셸과 전용 도구의 선택도 호출 비중, 효율, 사람이 검토할 때의 가독성을 함께 본다. 중간 출력은 파일로 밀어내더라도 최종 보고에는 사용한 입력, 완료한 단계, 남은 위험을 남겨 주 에이전트가 결과를 재검증할 수 있게 해야 한다.

5. 05

   자율성의 경계를 실행 전에 둔다

   가상 머신을 분리해도 외부 이메일이나 웹훅의 문구를 사용자 지시처럼 해석하면 프롬프트 인젝션에 노출된다. 외부 콘텐츠를 불신 가능한 데이터로 표시하고, 실제 지시와 권한 경계를 분리해야 한다. 이메일·Slack 발송처럼 되돌리기 어려운 행동은 초안 확인을 거치고, 자격 증명은 모델 대화 밖에서 다루며, 셸 명령은 별도 검토 계층으로 확인할 수 있다. 발표자의 자동 검토 우위 주장은 경험적 평가일 뿐 보안 보장이 아니므로 사람 승인과 격리, 비밀 보호를 함께 유지해야 한다.

6. 06

   평가 주기를 작업 길이에 맞춘다

   짧은 질의응답 평가만 통과한 모델을 한 달짜리 업무에 투입하면 출시 주기와 검증 주기가 어긋날 수 있다. 제품팀은 실제 실패를 평가 항목으로 바꾸고 하네스, 프롬프트, 도구 연결을 수정하는 일상 루프를 만들어야 한다. 동시에 모델이 몇 주·몇 달 일할 때의 기억 회상, 실패 복구, 잘못된 도구 호출, 알림 과잉을 장기 시나리오로 검증해야 한다. 현재 모델의 약점을 보완한 복잡한 인터페이스를 고정하기보다, 모델 변화에 따라 없애거나 다시 조립할 수 있는 단순한 경계를 유지하는 것이 중요하다.

구현 순서는 기능 목록이 아니라 실패 경로에서 정하는 편이 안전하다. 먼저 서버 상태와 실행 컴퓨터의 수명주기를 분리하고, 각 단계의 재개 지점과 중복 방지 규칙을 정한다. 다음으로 기억·도구·캐시의 예산을 계측하고, 외부 입력·비밀·비가역 행동의 승인 경계를 코드와 인터페이스에 드러낸다. 마지막으로 실제 장기 작업의 실패를 평가에 넣어 복구성과 선제 알림의 품질을 반복 검증한다. 이때 관측 가능성은 부가 기능이 아니다. 어떤 트리거가 작업을 깨웠고, 어느 상태에서 재개했으며, 어떤 도구와 승인을 거쳤는지 명확히 추적할 수 있어야 실패를 평가 사례로 바꾸고 하네스를 고칠 수 있다. 상시형이라는 이름의 가치는 켜져 있는 시간보다, 중단 뒤 정확히 이어가고 조용히 기다리며 필요한 순간에만 안전하게 행동하는 능력에 있다. 이 기준을 만족하지 못한다면 모델 호출이 아무리 유능해도 장기 동료가 아니라 오래 살아 있는 단일 세션에 머문다.