장시간 AI 에이전트를 방치하지 않기 위한 Runbook: Memory · Model · Remote 승인 구현 체크리스트

AI 에이전트는 「1회의 채팅으로 보조하는 도구」에서, 장시간 움직이고, 여러 화면을 넘나들며, 기억을 유지하고, 도중에 인간의 승인을 기다리는 실행 주체로 변하고 있습니다.

2026년 5월 하순의 영어권 1차 정보에 따르면, GitHub Copilot Memory의 스코프 제어, Copilot model rules, Anthropic의 agent containment, OpenAI Codex의 Goal mode와 locked computer use, GitHub Copilot remote control, Google DeepMind의 multi-agent research workflow가 모두 같은 방향을 가리키고 있습니다.

이 기사에서는 뉴스에서 확인할 수 있는 사실과, 그로부터 도출되는 실무상의 설계 판단을 구분하면서, 장시간 AI 에이전트를 본番·업무 환경에서 사용하기 전에 만들어야 할 Runbook을 정리합니다.

장시간 AI 에이전트는 프롬프트를 상세하게 만드는 것만으로는 안전하게 운용할 수 없습니다. 최소한, 다음의 Runbook을 먼저 만듭니다.

Runbook 항목	결정할 것	실패했을 때 발생하는 일
Memory Scope	user / repo / org / session 중 어디에 기억할 것인가	개인의 취향과 리포지토리 사실이 섞임
...

한마디로 말하면, 장시간 AI 에이전트 운용의 중심은 「맡길 태스크」가 아니라 「멈추는 법 · 잊는 법 · 모델 선택 · 중간 승인의 기록」 입니다.

GitHub는 2026년 5월 26일, Copilot Memory에 삭제, repository-level off switch, Copilot CLI의 /memory, 저장 시 스코프 표시 등의 제어를 추가했다고 발표했습니다.

원문: "Clearer scope at capture time"

일본어 번역: 기억을 저장하는 시점에, 보다 명확한 스코프를 나타냅니다.

인용원: Copilot Memory has more controls for deletion, scope, and the Copilot CLI

해당 기사에서는 저장 대상이 user-level preference인지 repository-level fact인지를 permission prompt로 명시한다고 설명되어 있습니다.

Memory는 「AI가 똑똑해지는 기능」이 아니라, 영속화되는 설정 데이터로서 다루어야 합니다. 특히 다음의 혼동이 위험합니다.

섞어서는 안 되는 것	이유
개인의 취향	다른 멤버에게 전파되면 리뷰 방침이 왜곡됨
...

Runbook에는 다음과 같이 Memory의 분류를 명기합니다.

agent_memory_policy:
user_level:
allowed:
...

GitHub는 2026년 5월 26일, Copilot Business / Enterprise를 대상으로 조직별로 이용 가능한 Copilot model을 제어할 수 있는 targeted model rules를 public preview로 발표했습니다.

원문: "fine-grained control beyond enterprise-wide defaults"

일본어 번역: enterprise 전체의 기본 설정을 넘어선 세밀한 제어.

인용원: Target Copilot models to organizations with model rules

장시간 AI 에이전트에서는 모델 선택이 결과물의 품질, 비용, 데이터 경계, 책임 소재와 직결됩니다. 개인이 그 자리에서 모델을 선택하는 운용이 아니라, 용도별 model route를 고정합니다.

model_route_policy:
default:
allowed_models:
...

중요한 것은 모델을 「성능 랭킹」으로 선택하지 않는 것입니다. 업무에서는 정확도뿐만 아니라 데이터 취급, 감사 로그, 비용 상한, 계약 조건, 장애 시의 롤백(Rollback)도 모델 선정 조건이 됩니다.

Anthropic은 2026년 5월 25일, Claude across products의 containment 설계에 대해, agent의 능력과 액세스 범위가 넓어질수록 blast radius를 억제하는 설계가 중요해진다고 설명했습니다.

원문: "how to cap the blast radius"

일본어 번역: 영향 범위(blast radius)를 어떻게 제한할 것인가.

인용원: How we contain Claude across products

본 기사에서는 영구 메모리 (persistent memory), CLAUDE.md, 마운트된 워크스페이스 (mounted workspace), 예약된 / 장시간 실행되는 에이전트 (scheduled / long-running agents)의 상태 디렉토리 (state directories) 등, 세션 (session)을 넘어 남는 컨텍스트 (context)가 증가함에 따라 영구 메모리 오염 (persistent memory poisoning)의 리스크가 증가한다고도 설명하고 있습니다.

장시간 에이전트는 1회의 도구 호출 (tool call)보다, 남겨진 상태가 다음 실행 시 재로드되는 것이 더 위험합니다.

Runbook에서는 에이전트의 상태 (state)를 다음 4가지 유형으로 분류합니다.

상태 분류	예	처리 방식
Ephemeral (휘발성)	현재의 추론 메모, 탐색 로그	세션 종료 시 폐기
...

특히 외부 입력으로부터 얻은 문자열을 그대로 메모리나 설정 파일에 저장하는 것은 피해야 합니다. 저장하기 전에 다음 검사를 거칩니다.

state_persistence_gate:
  before_write:
    - classify_source_trust
...

OpenAI는 2026년 5월 21일 ChatGPT Release Notes를 통해 Codex의 Appshots, Goal mode, browser annotations, locked computer use, browser use improvements를 발표했습니다.

원문: "keep longer tasks moving"

한국어 번역: 더 긴 태스크를 계속 진행시키기.

인용원: ChatGPT - Release Notes

해당 릴리스에서는 Goal mode를 통해 결과와 성공 조건 (success criteria)을 정의하고, 이를 Codex app / IDE extension / CLI에서 사용할 수 있게 되었다는 점도 설명되어 있습니다.

장시간 에이전트에게는 "무엇을 해주길 원하는가"뿐만 아니라, 언제 멈춰야 하는가를 전달해야 합니다.

agent_goal_contract:
  objective: "의존성 라이브러리 업데이트의 영향을 조사하고, 필요한 최소한의 수정안을 작성한다"
  success_criteria:
    ...

이러한 계약 (contract)이 없으면, 에이전트는 "계속 진행하는 것"을 성공으로 오해합니다. 업무 운영에서는 진행하는 능력만큼이나, 정지·보류·인간 확인으로 돌아오는 능력이 중요합니다.

GitHub는 2026년 5월 18일, Copilot CLI 세션 (session)의 원격 제어 (remote control) 기능이 GitHub.com과 GitHub Mobile에서 일반 제공(GA)되었다고 발표했습니다.

원문: "Approve or deny permission requests"

한국어 번역: 권한 요청을 승인하거나 거부할 수 있습니다.

인용원: Take your local GitHub sessions anywhere

기사에서는 CLI나 IDE에서 시작한 세션을 웹이나 모바일에서 모니터링하고, 진행 중에 추가 지시를 내리며, 구현 계획이나 차이점 (diff)을 확인할 수 있다고 설명합니다.

원격 제어 (Remote control)는 자리를 비운 중에도 작업을 멈추지 않기 위해 유효합니다. 반면, 승인이 채팅하는 느낌으로 가벼워지면, 나중에 "누가 무엇을 허가했는지"가 모호해집니다.

Runbook에서는 원격 승인을 다음과 같이 분류합니다.

승인 유형	예	필수 로그
Read approval (읽기 승인)	private repo 읽기, 로그 확인	대상 경로 (path), 이유, 승인자
...

승인 로그는 에이전트 UI에만 가두지 말고, Issue, PR, 감사 대장 (audit log), 티켓 (ticket) 등 팀이 나중에 검색할 수 있는 곳에도 남겨야 합니다.

Google DeepMind는 2026년 5월 19일, Co-Scientist를 Gemini를 이용한 멀티 에이전트 AI 시스템 (multi-agent AI system)으로 소개했습니다.

원문: "iteratively generates, debates, and evolves"

한국어 번역: 반복적으로 생성하고, 토론하며, 진화시킵니다.

인용원: Co-Scientist: A multi-agent AI partner to accelerate research

해당 기사에서는 generation agent, reflection agent, ranking agent, evolution agent, meta-review agent 등의 역할이 설명되어 있습니다.

멀티 에이전트 (multi-agent)를 도입한다면, "여러 에이전트가 열심히 한다"가 아니라, 리뷰 공정 (review process)으로서 설계해야 합니다.

multi_agent_review_flow:
generator:
role: draft_options
...

여기서 위험한 점은, sub-agent의 출력을 "내부에서 생성되었으므로 신뢰할 수 있다"라고 취급하는 것입니다. 외부 웹(Web), 고객 입력, 이슈(issue) 본문, 로그 파편을 읽은 sub-agent의 출력은, 구조화되어 있더라도 원래의 신뢰도(reliability)를 그대로 이어받습니다.

장시간 AI 에이전트를 도입하기 전에, 다음 체크리스트를 작성합니다.

Memory (메모리)

• user-level memory와 repository-level memory의 차이를 명문화했다
• memory 저장 시 source, owner, retention, 삭제 방법을 기록한다
• 외부 입력에서 얻은 문자열을 shared memory에 직접 저장하지 않는다
• memory를 무효화하는 절차를 Runbook(런북)에 기재했다

Model (모델)

• 조직·리포지토리·데이터 분류별 허가 모델을 정의했다
• preview model을 customer data task에서 사용하지 않는다
• 고위험 작업에서는 human reviewer(인간 검토자)를 필수화했다
• model 변경 시의 차분 검증 항목을 결정했다

Remote (원격 실행 환경)

• file scope, network allowlist, credential scope를 분리했다
• session 종료 시 파기할 state(상태)를 결정했다
• 영구 state의 기동 시 scan(스캔)을 포함했다
• destructive command(파괴적 명령)는 agent가 직접 실행하지 않는다

Approval (승인)

• remote 승인의 종류를 read / write / external / irreversible로 구분했다
• 승인자, 이유, 대상, payload summary를 기록한다
• publish / deploy / delete / billing은 별도 경로의 인간 승인을 거치게 했다
• 동일한 에러가 반복될 경우 정지하는 조건을 넣었다

Multi-agent Review (멀티 에이전트 리뷰)

• generator, critic, verifier, ranker, human owner를 분리했다
• sub-agent 출력에 원본 데이터의 trust level(신뢰 수준)을 첨부한다
• 최종 판단을 에이전트 간의 다수결로 결정하지 않는다
• evidence table(증거 테이블) 없는 제안은 채택하지 않는다

장애 대응 중의 회피책(workaround)을 repository memory에 저장하면, 몇 주 후에도 에이전트가 이를 오래된 제약 사항으로 취급할 가능성이 있습니다. 임시 대응은 session log 또는 incident ticket에 남기고, shared memory로 승격시키지 않습니다.

고성능 모델을 사용하면 된다는 판단은 업무 관점에서 불충분합니다. 고객 데이터, 계약 조건, 로그 보존, 비용 상한, 감사 요건에 따라 model route(모델 경로)를 결정해야 합니다.

remote control(원격 제어)에서는 짧은 승인 요청이 늘어납니다. 승인 메시지뿐만 아니라 대상 작업, 차분(diff), payload summary, rollback(롤백) 방법을 기록하지 않으면 나중에 설명할 수 없습니다.

sub-agent가 외부 웹이나 이슈 본문을 읽고 요약했을 경우, 그 출력은 "내부 에이전트의 발언"이 아니라 "외부 입력을 가공한 것"입니다. trust level을 높이지 말고, verifier(검증기)를 통과시켜야 합니다.

long_running_agent_runbook:
owner: platform-ai-team
applies_to:
...

최근 AI 뉴스를 보면, 에이전트는 "오래 작동할 수 있고", "기억할 수 있으며", "원격으로 승인할 수 있고", "여러 에이전트가 함께 사고할 수 있는" 방향으로 나아가고 있습니다.

그 진화에 맞춰 운영 측면에서도 변화가 필요합니다. 지금 당장 만들어야 할 것은 마법의 프롬프트가 아닙니다.

Memory의 저장 범위, 모델의 허가 규칙, 실행 환경의 경계, remote 승인 로그, multi-agent 리뷰 공정을 정리한 Runbook입니다.

장시간 AI 에이전트는 방치해도 되는 자동화가 아니라, 정지 방법까지 설계된 실행 기반(execution platform)으로 다루어야 합니다.

• Copilot Memory에 삭제, 범위 및 Copilot CLI를 위한 더 많은 제어 기능 추가 - GitHub Changelog
• 모델 규칙을 통해 조직에 특정 Copilot 모델을 지정 - GitHub Changelog
• 다양한 제품 전반에서 Claude를 격리하는 방법 - Anthropic
• ChatGPT - 릴리스 노트 - OpenAI Help Center
• 로컬 GitHub 세션을 어디서나 사용하세요 - GitHub Blog
• Co-Scientist: 연구를 가속화하는 멀티 에이전트 (multi-agent) AI 파트너 - Google DeepMind