관리형 에이전트가 이제 Harness의 통제를 받습니다

오후 네 시, 한 개발자의 Claude Code 세션이 요금제 변경에 일할 계산을 추가하려고 Billing API에 작업 세션을 엽니다. 20분 뒤, 그 세션이 아직 작업 중일 때 backend-fixer 프로필로 예약된 Archyl 실행이 청구서 반올림에 관한 티켓을 가져갑니다. 이 티켓도 Billing API 안에 있습니다.

이번 주까지 예약된 실행은 이렇게 동작했습니다. 관리형 실행이 원래 그랬듯 자기 작업 세션을 열었습니다. 프리플라이트 게이트는 warn을 반환했고, 사유는 1 target element(s) are being worked on by other active sessions — coordinate before changing them였습니다. 이 판정은 실행의 이벤트 피드에 표시되었습니다. 그리고 실행은 그대로 시작되었습니다. 판정에 따라 행동하는 것이 아무것도 없었고, 예약된 실행을 지켜보며 조율할 사람도 없었기 때문입니다.

솔직하게 말하겠습니다. 호스팅된 실행에서 이 감싸기는 대부분 겉치레였습니다. 게이트는 표시되고 무시되었습니다. 에이전트가 변경한 파일은 세션에 연결되지 않았기 때문에, 메모리는 작업 설명에 우연히 언급된 요소에 쌓였습니다. 그리고 세션은 한 줄짜리 요약으로 닫혀서, 다음 에이전트가 배울 것이 거의 없었습니다.

이번 주에 그것이 바뀌었습니다. 이제 Harness가 관리형 실행을 조종하고, 호스팅된 실행과 로컬 코딩 에이전트가 같은 모델 위에서 협업합니다.

에이전트를 실행하는 것은 쉬운 부분이 되어 가고 있습니다

이 분야에서 가장 큰 이름 세 곳이 이제 에이전트가 실행될 호스팅 환경을 제공합니다. Anthropic 문서는 Claude Managed Agents를 "관리형 인프라에서 실행되는, 미리 구축되고 구성 가능한 에이전트 harness"라고 설명하며, 클라우드 또는 자체 호스팅 샌드박스, 지속 세션, cron 기반 예약 실행을 제공합니다. 9월 10일 공개 베타로 발표된 OpenAI의 Agents API는 에이전트 루프를 OpenAI 인프라에서 실행하고 "오케스트레이션, 장시간 실행 세션, 컨텍스트 관리"를 처리합니다. 같은 날 발표된 Cursor Projects는 전용 클라우드 머신에 코디네이터 에이전트를 둡니다. 이 에이전트는 서브에이전트에게 일을 위임하며, 스케줄에 따라 실행되거나 당신의 pull request를 따라갈 수 있습니다.

모두 좋은 제품이고, 같은 방향을 가리킵니다. 샌드박스, 도구 루프, 세션, 스케줄은 목록에서 고르는 것이 되어 가고 있습니다.

런타임이 스스로 알 수 없는 것은 당신의 시스템입니다. 청구서 코드가 어느 container에 속하는지. 누가 소유하는지. 소비자들이 의존하는 계약. 어떤 경계를 의도적인 것으로 만든 결정. 그리고 아무도 보고 있지 않을 때 중요한 부분, 즉 이 런타임이 시작하지 않은 에이전트까지 포함해 다른 어떤 에이전트가 지금 어느 부분에서 작업하고 있는지.

그 지식은 런타임 안에 있을 수 없습니다. 당신의 에이전트가 모두 한 런타임에서 실행되는 것은 아니기 때문입니다. 어떤 것은 노트북에서, 어떤 것은 CI에서, 어떤 것은 호스팅된 워커에서 실행됩니다. 그래서 우리는 이렇게 생각합니다. 당신의 런타임, 우리의 아키텍처. 무엇이 에이전트를 실행하든, 에이전트가 따르는 모델은 같습니다.

4월에 출시한 Archyl의 관리형 에이전트 실행도 그런 런타임 중 하나입니다. 이번 주부터 그에 걸맞게 동작하기 시작했습니다. 실행을 실시간으로 보고 조종할 수도 있습니다.

이제 실행이 거부될 수 있고, 그 이유도 전달됩니다

협업은 선택 사항입니다. 각 에이전트 프로필의 협업 항목에 새 설정 다른 에이전트의 작업 존중이 생겼고, 기본값은 꺼짐입니다. 켜면 실행은 작업 세션을 배타적으로 열고, 다음에 무슨 일이 일어날지는 게이트 판정이 결정합니다.

다른 에이전트가 같은 요소에 리스를 잡고 있으면 실행은 거부됩니다. 그 에이전트가 누군가의 노트북에 있는 Claude Code든 다른 관리형 실행이든 마찬가지입니다. 실행은 아무것도 복제하기 전에 끝나고, 게이트 이벤트에는 실행 거부됨이 표시되며, 사유에는 누가 거기서 무슨 작업을 하고 있는지가 나옵니다. 앞에서 본 오후의 경우는 이렇습니다.

session denied by preflight gate: "Billing API" is being worked on by
claude-code/vincent (add proration to plan changes)

형식은 실제 그대로이고, 작업은 예시입니다. 아침에 이 실행을 보는 사람은 누구와 이야기해야 하는지 정확히 압니다.

게이트가 경고만 하는 경우, 예를 들어 error 수준 가드레일이 작업에 적용되는 경우에는 실행이 시작되지도, 실패하지도 않습니다. 조직의 동시 실행 슬롯을 차지하지 않은 채 승인 대기 중 상태로 기다립니다. 실행 페이지에는 사유가 나열되고, 승인하고 시작과 실행 취소가 표시됩니다.

승인은 예전 판정을 그대로 통과시키는 것이 아닙니다. 게이트를 다시 평가하므로, 실행이 기다리는 동안 로컬 에이전트가 그 요소에 리스를 잡았다면 승인된 실행도 거부됩니다. 24시간 안에 아무도 승인하지 않은 실행은 취소됩니다.

대기 중인 실행이 아무것도 점유하지 않는 이유

실행이 기다리는 동안 그 세션은 폐기됩니다. 경고를 낸 세션은 취소되고, 리스도 함께 사라지며, 승인하면 새 세션이 열립니다. 리스를 유지하는 편이 더 신중해 보이겠지만 실제로는 더 나쁩니다. 아무도 승인하지 않는 실행이 하루 동안 다른 모든 에이전트를 그 요소에서 떼어 놓고, 실제로는 아무것도 작업하지 않는데 무언가 작업 중이라고 각 에이전트에게 알리게 되기 때문입니다.

이는 8월에 그은 선을 따릅니다. 리스는 어드바이저리이며, 잠금이 아닙니다. 배타성은 프로필이 요청하는 것이지 플랫폼이 강제하는 것이 아니며, 사람을 기다리는 실행은 아무것도 차지하지 않습니다.

Guard가 워커 안으로 들어왔습니다

세션은 의도를 다룹니다. Guard는 무엇이 쓰이는지를 다룹니다. 로컬 에이전트는 8월부터 Claude Code 훅으로 Guard를 써 왔고, 이제 관리형 실행도 워커 안에서 같은 검사를 받습니다.

프로젝트에 연결된 저장소가 있으면, 에이전트가 하는 모든 write_file과 edit_file은 변경이 반영되기 전에 프로젝트의 적합성 규칙과 대조됩니다. critical 위반이 있으면 쓰기가 거부되고, 에이전트는 어떤 규칙에 왜 걸렸는지 읽게 됩니다.

blocked by Archyl Guard: 1 critical architecture violation(s) in
backend/internal/adapter/http/handlers/invoice.go. Change the content so it
conforms, then write again:
- [critical] No direct database access from HTTP handlers — move the query behind a service

에이전트는 쿼리를 옮기고 다시 씁니다. high 위반은 경고와 함께 쓰기를 반영합니다. 검사 자체가 실패하거나 시간 초과되면 쓰기는 반영됩니다. Guard는 자신의 오류 때문에 에이전트를 막지 않습니다. 자신이 관리하는 작업을 망가뜨리는 거버넌스 검사는 결국 꺼지기 마련이기 때문입니다.

각 검사에는 세션 ID도 담겨 있어, 에이전트가 작업하는 동안 파일을 실행의 세션에 연결합니다. 이것은 두 섹션 뒤에서 중요해집니다.

에이전트는 자기 세션을 알지만, 소유하지는 않습니다

실행의 프롬프트는 이제 세션을 명시하고, 플랫폼이 세션을 열었으며 닫을 것이라고 에이전트에게 알려 줍니다. "따라서 호출할 세션 도구는 없습니다." 에이전트는 두 번째 세션을 열 수도, 이 세션을 일찍 끝낼 수도 없습니다. 수명 주기는 플랫폼의 몫이며, 실행이 언제 끝났는지 아는 것은 플랫폼뿐입니다.

에이전트가 소유하는 것은 작업에 대한 자신의 보고입니다. 끝내기 직전에 report_outcome을 한 번 호출해, 정직한 요약, ADR로 남길 만한 결정, 끝내지 못한 작업에 대한 후속 작업, 그리고 의지한 브리핑 메모리를 전달합니다. 도구 설명은 상황에 따른 발견을 결정에 넣지 말라고 안내합니다. 결정은 이후 세션에 다시 제시되고, 디버깅 메모가 누군가를 구속해서는 안 되기 때문입니다.

결과는 작업이 이루어진 곳에 남습니다

실행이 끝나면 Archyl은 먼저 실행이 변경한 파일을 세션에 연결합니다. 이것으로 세 가지 빈틈 중 가장 조용했던 것이 해결됩니다. 세션이 리스를 잡는 요소는 작업 설명에서 추론되는데, 작업 설명은 추측일 뿐입니다. 변경된 파일은 실제로 일어난 일입니다. 이제 메모리는 티켓에 언급된 모든 것이 아니라, 실제 작업이 건드린 요소로 갑니다.

그다음 세션을 닫고, 요약을 그 요소들의 메모리로 저장하며, 에이전트가 사용했다고 밝힌 메모리에 점수를 줍니다. 이것이 메모리 랭킹이 학습하는 신호입니다.

결정은 실행이 성공했을 때만 기록됩니다. 결정은 프로젝트 메모리가 되고 Architecture Change Request(아키텍처 변경 요청) 초안을 열어, 모델이 어떻게 따라잡아야 할지 사람이 검토하게 합니다. 실패한 실행은 다음 시도에 필요한 요약과 후속 작업은 남기지만, 결정은 기록하지 않습니다. 완료되지 않은 작업에는 내세울 근거가 없습니다.

실행 페이지는 이 모든 것을 작업 세션 결과 카드에 보여 줍니다. 요약, 결정, 후속 작업, 건드린 요소, 인용된 메모리, 그리고 Change Request 링크입니다. 다른 세션이 점유한 요소에는 다른 작업 세션이 점유 중 표시가 붙으므로, 다른 누군가의 리스 안에서 코드를 수정한 실행이 눈에 띄지 않고 넘어가지 않습니다.

두 종류의 에이전트, 하나의 모델

여러 에이전트, 하나의 아키텍처가 닿으려던 조각이 바로 이것입니다. 프로세스를 공유하지 않는 에이전트 사이의 양방향 협업입니다.

관리형 실행은 managed-agent/<profile name>으로 세션을 엽니다. 이 글 첫머리의 장면을 뒤집어 보겠습니다. 예약된 실행이 Billing API에서 작업 중일 때 한 개발자가 거기서 Claude Code를 시작합니다. 이제 그 브리핑에는 실행이 충돌로 표시됩니다.

- **Conflicts** (someone else is already working here):
  - Billing API — held by managed-agent/backend-fixer: fix rounding on prorated invoices

로컬 에이전트는 그 요소를 변경하기 전에 조율하라는 안내를 받고, Fleet 콘솔에는 두 세션이 모두 표시되며, 어느 쪽이 끝나든 다른 쪽이 다음번에 읽을 메모리를 남깁니다.

이번 주에 함께 출시한 것

나머지가 이 위에 서 있으니 짧게 정리합니다. 이제 프로필에 기본 제공 스킬과 도구 허용 목록이 들어가서, 읽기 전용 리뷰어를 read_file, list_*, get_*로 제한할 수 있습니다. 워커 heartbeat가 멈춘 실행을 감지해 정리하고, 각 실행의 API 키는 실행이 끝나면 폐기되며, 실패한 실행도 작업 내용을 드래프트 pull request로 게시합니다. 실행은 항상 Archyl 자체 워커에서 이루어지며, BYO가 활성화되어 있으면 조직의 AI 제공자를 사용합니다.

하지 않는 것

협업은 Harness를 쓰는 에이전트만 봅니다. 리스는 에이전트가 세션을 열었기 때문에 존재합니다. 세션 없이 저장소를 편집하는 에이전트는 게이트에 보이지 않으며, 다른 에이전트의 작업을 존중하는 실행도 그 바로 옆에서 시작됩니다.

워커는 테스트를 실행하지 않습니다. 워크스페이스 파일 도구(읽기, 쓰기, 편집, 목록, grep)는 있지만 셸은 없습니다. 프로젝트를 빌드하거나 테스트 스위트를 돌릴 수 없으므로, 결과 카드가 깨끗하다는 것은 쓰기가 Guard를 통과했다는 뜻이지 코드가 컴파일된다는 뜻이 아닙니다. 그 일은 여전히 CI가 합니다.

에이전트의 결정은 검토되지 않은 상태입니다. 결과 카드의 결정은 누군가 Change Request를 검토하기 전까지는 에이전트의 주장일 뿐입니다. 그 검토가 핵심이며, 형식적인 절차가 아닙니다.

Guard에는 대조할 기준이 필요합니다. 연결된 저장소가 없으면 쓰기 검사도 없고, 적합성 규칙이 비어 있으면 모든 쓰기가 통과합니다.

어디서 시작할까

사람이 손으로도 변경하는 코드를 대상으로 스케줄에 따라 실행되는 프로필 하나를 골라, 협업에서 다른 에이전트의 작업 존중을 켜세요. 나머지 프로필은 그대로 두세요.

실행이 거부되면, 사유에 겹친 에이전트와 작업이 나옵니다. 지금까지는 그런 겹침이 아무도 모르게 지나갔을 것입니다.

관리형 에이전트 실행, 작업 세션, Guard, 메모리는 archyl의 일부입니다. 위에서 언급한 모든 설정은 관리형 에이전트 실행 문서에 있고, 로컬 쪽은 Harness 가이드에 있습니다. 함께 읽을 글: 여러 에이전트, 하나의 아키텍처, 코딩 에이전트를 위한 작업 세션, AI 코딩 에이전트를 위한 메모리, 관리형 에이전트 실행 출시 소식.