Claude Code, Codex, GitHub Copilot과 같은 AI coding agent는 개발자의 PC에서만 동작하는 존재가 아니게 되었습니다.

로컬의 terminal, git worktree, 임시 container, cloud task, GitHub Actions 상의 ephemeral environment. 실행 장소가 분산되면 "모든 agent의 작업 중인 파일을 1대의 PC에서 감시한다"라는 전제가 무너집니다.

AI 에이전트의 실행 환경은 분산됩니다.

그럼에도 불구하고, 변경 사항이 main으로 들어가는 경계는 공유할 수 있습니다.

이 기사에서는 향후 로컬 모니터링만으로 AI 에이전트를 통제하는 것이 어려워지는 이유와, main을 지키기 위해 어디를 공통의 제어면(control plane)으로 두어야 하는지를 정리합니다.

AI coding agent의 작업 장소는 이미 하나가 아니다

동일한 repository에 변경을 제출하는 AI 에이전트라도, 실제 작업 장소는 다릅니다.

• 개발자 PC 상의 일반 directory
• git worktree로 분리한 별도 directory
• remote development environment
• task마다 생성되는 cloud container
• GitHub Actions를 기반으로 한 ephemeral environment
• 회사 고유의 runner나 sandbox

GitHub Copilot cloud agent는 task마다 전용 임시 개발 환경을 사용합니다. Codex에도 worktree와 cloud environment를 사용하는 실행 형태가 있습니다. Claude Code에서는 worktree를 사용하여 여러 session을 분리할 수 있습니다.

• GitHub: About GitHub Copilot cloud agent
• OpenAI: Cloud environments
• Claude Code: Run parallel sessions with Git worktrees

이 구성에서는 모든 작업을 관측할 수 있는 "유일한 로컬 환경"은 존재하지 않습니다.

로컬 모니터링이 어려워지는 3가지 이유

1. push되지 않은 변경 사항은 해당 환경 외부에서 보이지 않는다

agent가 cloud container 내에서 편집하고 있더라도, branch로 push되기 전까지는 GitHub에서 보이지 않습니다.

마찬가지로, 개발자 PC의 미commit 변경 사항도 다른 PC나 GitHub App에서는 확인할 수 없습니다.

이는 모니터링 도구의 성능 부족이 아니라, 아직 공유면(shared surface)으로 나오지 않은 정보이기 때문입니다.

2. agent마다 실행 환경과 권한 모델이 다르다

local CLI, desktop app, cloud agent, self-hosted runner는 file system, network, secret, lifecycle가 다릅니다.

모든 agent의 중간 작업을 공통 모니터링하려고 하면, 각 vendor, 각 runtime, 각 version에 대한 개별 integration이 필요하게 됩니다. 대응하지 않는 agent가 하나라도 섞여 있다면, 그 환경은 모니터링 범위 밖이 됩니다.

3. 임시 환경은 사라진다

ephemeral environment는 task 종료 후에 파기되는 경우가 있습니다.

중간 log나 미commit 차분(diff)을 저장해두지 않으면, 나중에 "무슨 일이 일어나고 있었는지"를 공통된 장소에서 재구성할 수 없습니다.

즉, 로컬이나 sandbox는 작업하는 장소로서는 적합할지 몰라도, 조직 전체의 통합 판단을 남기는 장소는 되지 못합니다.

실행을 지키는 것과 main을 지키는 것은 별개다

AI 에이전트 운용에서는 두 종류의 안전을 구분할 필요가 있습니다.

sandbox는 agent가 부주의한 command를 실행하는 범위를 좁혀줍니다. worktree는 별도 session의 file state가 섞이는 것을 방지합니다.

하지만, 서로 다른 환경에서 완성된 두 개의 PR이 동일한 main으로 들어갈 때, 어떤 순서로 들어가야 하는지까지는 결정하지 않습니다.

git worktree로 분리하더라도 main에서 충돌하는 문제는 로컬의 실행 분리와는 다른 layer입니다.

공통 제어면은 agent 내부가 아닌 GitHub 측에 둔다

Claude Code, Codex, Copilot, 그리고 인간 개발자가 서로 다른 장소에서 작업하더라도, team 개발에서는 통상적으로 다음 흐름으로 집약됩니다.

작업 환경
↓ commit / push
branch
...

이 과정 중에서 vendor에 의존하지 않고 공유할 수 있는 것은 push 이후의 branch와 PR입니다.

따라서 모든 agent의 내부를 감시하기보다는, 다음 사항들을 GitHub 측에서 확인하는 것이 경계를 명확히 할 수 있습니다.

• branch를 조기에 push하기
• draft를 포함하여 PR을 조기에 생성하기
• PR 단독 CI (Continuous Integration) 실행하기
• open PR들끼리 동일한 변경 영역을 향하고 있지 않은지 확인하기
• 반영 순서가 중요하다면, 선행 PR과 후속 PR을 명시하기
• 필요한 check를 ruleset이나 branch protection에 연결하기

여기서의 목적은 agent의 작업을 일일이 지휘하는 것이 아닙니다.

누가 어디서 만들었느냐가 아니라,

무엇이, 어떤 순서로 main에 들어가려고 하는지를 보는 것입니다.

이 경계라면 새로운 AI coding agent가 늘어나더라도, repository 측의 운영 방식을 다시 구축해야 하는 범위를 억제할 수 있습니다.

로컬을 보지 않는 대신, PR을 빠르게 생성한다

GitHub로 나가지 않은 작업은 공통 제어면에서 볼 수 없습니다.

따라서 병렬 agent 운용 시에는 "완성될 때까지 branch를 숨기는" 것보다, 변경 의도를 알 수 있는 시점에 PR을 만드는 것이 조율하기 쉽습니다.

단, PR을 빠르게 만드는 것과 즉시 merge하는 것은 별개입니다.

draft PR이라도 다음 사항들을 공유할 수 있습니다.

• 변경 대상 file
• base와 head의 commit
• 담당하고 있는 목적
• CI의 중간 결과
• 다른 open PR과의 중첩 여부
• merge 전에 대기해야 할 대상

이는 로컬 감시의 빈틈을 agent 내부 감시를 추가하는 것만으로 메우는 것이 아니라, 공유 경계로 나오는 시간을 앞당기는 사고방식입니다.

main 보호로 약속하지 않는 것

GitHub 측을 경계로 삼더라도 다음 사항들까지 해결되지는 않습니다.

• 미push(unpushed)된 변경 사항 발견
• agent의 중복 작업 제로화
• local command 실행 제어
• PR의 구현 품질 증명
• 모든 조합에 의한 사고를 사전에 판정

지킬 범위를 명확히 하는 것이 운영하기에 더 수월합니다.

로컬이나 cloud environment에서는 각각의 sandbox와 권한 제어를 사용합니다. GitHub에서는 공유된 PR과 main으로의 착지를 관리합니다.

이러한 분담을 통해, 관측할 수 없는 중간 작업까지 보이고 있다는 전제를 두지 않아도 됩니다.

Veripsa Core가 설정하는 경계

Veripsa Core는 GitHub 상의 open PR을 merge 전에 확인하고, PR traffic, 대기 상태, Unknown, ACK를 GitHub checks와 필요한 PR comment로 내보내는 GitHub App입니다.

로컬이나 각 cloud agent의 작업 중인 파일은 감시 대상으로 삼지 않습니다.

대상으로 삼는 것은 GitHub로 공유되어 동일한 main을 향하고 있는 변경 사항입니다.

이 설계에서는 Claude Code, Codex, Copilot, 인간 중 누가 PR을 만들었는지 통일할 필요가 없습니다. 작업 장소가 늘어날수록 마지막에 공유되는 통합 경계를 명시하는 의미는 더욱 커집니다.

자주 묻는 질문 (FAQ)

AI 에이전트를 로컬에서만 감시할 수는 없는가?

해당 PC에서 동작하는 agent에는 유효합니다. 하지만 cloud task, remote runner, 별도 PC, vendor 측의 ephemeral environment까지 동일한 감시 범위에 포함되지는 않습니다.

cloud agent의 중간 작업은 어디에서 통제하는가?

각 agent의 sandbox, permission, network policy는 실행 환경 측에서 다룹니다. repository에 들어오는 변경 사항은 push, PR, checks, review, rulesets로 다룹니다.

GitHub에 나온 뒤에는 늦지 않은가?

중복 작업을 줄이는 것만을 목적으로 하면 늦을 수 있습니다. 반면, main으로의 착지를 지키는 경계로서는 PR을 조기에 생성함으로써 관측 시작 시점을 앞당길 수 있습니다.

CI가 Green이라면 충분하지 않은가

CI는 통상적으로 하나의 PR을 base에 대해 검증합니다. 여러 개의 open PR이 서로의 전제 조건을 변경하고 있는 경우, PR 단일의 Green 상태만으로는 착지 순서를 결정할 수 없습니다.

요약

AI coding agent의 실행 장소는 로컬 PC, worktree, remote environment, cloud container로 분산되어 있습니다.

그 모든 것을 하나의 로컬 모니터링으로 커버한다는 전제를 세우기는 어려워집니다.

• sandbox는 하나의 실행을 보호한다
• worktree는 작업 디렉토리(directory)를 분리한다
• CI는 PR 단체를 검증한다
• GitHub의 PR과 checks는 공유된 변경 사항을 다룬다
• main 보호에서는 open PR들 사이의 관계와 착지 순서를 확인한다

agent 내부를 공통의 제어면(control plane)으로 만드는 것이 아니라, 모두가 마지막에 통과하는 GitHub의 통합 경계를 제어면으로 삼는다.

AI 에이전트가 여러 cloud로 분산될수록 이러한 구분이 필요해집니다.

Veripsa Core는 하나의 selected repository에 advisory-only 방식으로 도입하여, 현재의 branch protection을 변경하지 않고도 checks를 관찰할 수 있습니다.

Discussion