Git 워크트리와 격리된 권한으로 여러 AI 코딩 에이전트를 안전하게 실행하는 방법

각 코딩 에이전트에 별도의 브랜치와 작업 디렉터리를 제공한 다음, 프로세스의 파일, 자격 증명, 네트워크 접근을 별도로 제한하세요. Git 워크트리는 수정 사항 간의 실수로 인한 간섭을 줄여 주지만, 보안 샌드박스는 아닙니다. 안전한 병렬 워크플로에는 이해하기 쉬운 저장소 상태와 강제 가능한 런타임 권한이 모두 필요합니다.

이 가이드는 로컬 워크트리 명령어, 작업 범위에 따른 접근 권한, 독립적인 테스트 설정, 사람이 검토하는 통합 절차를 보여 줍니다. 직접 소유하거나 수정 권한이 있는 저장소를 사용하고, 폐기 가능한 작업부터 시작하세요. 이 절차는 특정 도구에 종속되지 않습니다. 코딩 에이전트 인터페이스가 일부 과정을 자동화할 수는 있지만, 기본적인 경계는 여전히 확인해야 합니다.

에이전트가 하나의 작업 공간을 공유하면 어떤 문제가 생길까요?

에이전트 둘이 커밋하지 않은 수정 사항을 덮어쓰거나, 같은 종속성 파일을 변경하거나, 다른 작업의 임시 상태를 프로젝트의 의도된 설계로 해석할 수 있습니다. 테스트가 실행되는 동안 변경되는 디렉터리를 대상으로 테스트를 실행할 수도 있습니다. 어느 에이전트도 안정된 리비전을 테스트하지 않았기 때문에, 그 결과로 발생한 실패를 재현하기 어려울 수 있습니다.

문제는 소스 파일에만 국한되지 않습니다. 공유 포트, 데이터베이스 이름, 캐시, 픽스처 디렉터리, 백그라운드 프로세스는 변경 내용이 서로 다른 모듈에 있더라도 간섭을 일으킬 수 있습니다. 한 에이전트가 다른 에이전트가 사용 중인 서비스를 중지하거나, 아직 편집 중인 스키마에서 파일을 다시 생성할 수도 있습니다.

멀티 에이전트 협업 안내에서는 작업 경계와 종속성이 어떻게 간섭을 줄이는지 설명합니다. 작업자를 더 투입하기 전에 각 작업의 결과물, 허용된 수정 범위, 종속성, 승인 테스트를 명시하세요. “같은 기능을 함께 작업한다”는 것은 독립적인 변경을 위한 충분한 합의가 아닙니다.

별도의 디렉터리를 사용하면 실수로 서로 간섭할 가능성이 줄어들고, 별도의 보안 컨텍스트를 사용하면 프로세스가 접근할 수 있는 대상을 제어할 수 있습니다. 두 목적을 구분해 두어야 브랜치가 잘 분리된 것을 비공개 파일이나 프로덕션 서비스에 대한 보호로 착각하지 않습니다.

별도의 클론 대신 워크트리를 사용해야 하는 경우

Git 워크트리는 하나의 저장소에서 여러 브랜치의 작업 디렉터리를 동시에 사용해야 할 때 유용합니다. 실험에 더 독립적인 저장소 설정이나 다른 원격 저장소 구성이 필요하다면 별도의 클론이 더 적합할 수 있습니다. 어느 쪽도 그 자체만으로 운영체제 사용자가 비밀 정보나 다른 디렉터리에 접근하는 것을 제한하지는 않습니다.

실제 워크플로에 따라 선택하세요. 워크트리를 사용하면 브랜치별 검토가 편리해질 수 있고, 별도의 클론을 사용하면 일부 파괴적인 실험을 저장소 수준에서 더 쉽게 격리할 수 있습니다. 신뢰할 수 없는 코드나 더 광범위한 실행 위험에 대비하려면 소스를 어떻게 체크아웃했는지와 관계없이 적절히 격리된 런타임을 사용하세요.

이 표는 계획 수립을 위한 참고 자료일 뿐, 보안 인증이 아닙니다. 에이전트가 실제 셸에서 볼 수 있는 파일과 서비스를 포함해, 의존하려는 경계를 테스트하세요.

표지: 편집상 식별 목적으로 변경 없이 사용된 Conductor 공식 브랜드 키트 워드마크. 제품 마크의 소유권은 해당 소유자에게 있으며, 어떠한 제휴 관계도 암시하지 않습니다.

에이전트마다 브랜치와 워크트리를 하나씩 만들려면 어떻게 해야 하나요?

검증되고 검토된 기준에서 시작하세요. 브랜치를 변경하기 전에 기존 작업을 저장하고, 작업 디렉터리가 깨끗하다고 가정하지 말고 직접 확인하세요. 다음 예시는 검토된 기준이 main인 로컬 저장소를 가정합니다. 프로젝트에 적합한 기준을 사용하세요. 브랜치 이름이 잘못된 명령을 복사한 뒤 강제로 성공시키지 마세요.

git status --short
git branch --show-current
git worktree list
git switch main
git worktree add -b agent/docs ../agent-docs main
git worktree add -b agent/tests ../agent-tests main
git worktree list

각 에이전트에 자체 워크트리의 경로와 범위가 한정된 작업을 지정하세요. 기준 커밋을 기록하고 조율이 필요한 공유 파일을 설명하세요. 편의를 위해 개인 개발 환경 전체를 각 디렉터리에 복사하지 마세요. 자격 증명과 관련 없는 비공개 자료가 중복될 수 있습니다.

다음의 엔드투엔드 순서를 따르세요:

1. 저장소가 깨끗하거나 안전하게 보존되었는지 확인하고 검토된 기준 브랜치를 선택하세요.
2. 각 작업마다 고유한 브랜치와 워크트리를 만드세요.
3. 작업에 필요한 맥락만 제공하고 완료 조건을 명확히 하세요.
4. 작업에 필요한 경우에만 전용 범위 지정 자격 증명을 구성하세요.
5. 테스트마다 서로 다른 임시 경로, 포트, 폐기 가능한 서비스 상태를 지정하세요.
6. 통합을 제안하기 전에 각 diff와 테스트 결과를 확인하세요.
7. 프로젝트의 검토 절차와 저장소 제어를 거쳐 병합하세요.
8. 필요한 근거는 보존하고, 완료된 워크트리는 일반적인 방법으로 제거하며, 임시 액세스 권한을 해제하세요.

이 명령은 저장소 상태를 만들지만 샌드박스를 구성하지는 않습니다. 에이전트 도구에 자체 워크스페이스 관리자가 있다면, 인터페이스 밖에서도 동일한 계약을 이해할 수 있도록 생성된 브랜치와 경로를 점검하세요.

키, 환경 파일, 토큰을 격리하는 방법

작업 트리는 개발자의 전체 자격 증명 집합을 물려받아서는 안 됩니다. 작업에 필요한 저장소 및 서비스 권한만 부여된 전용 ID를 사용하세요. 비밀 정보는 승인된 저장소에 보관하고, 프롬프트나 작업 파일 또는 커밋된 .env 파일에 넣지 말고 도구에서 지원하는 방식을 통해 전달하세요.

GitHub 토큰 문서에서는 토큰 권한과 수명 주기를 설명합니다. 실제로 필요한 범위 중 가장 좁은 권한과 적절한 만료 기간을 설정하고, 토큰을 폐기할 방법을 마련하세요. 소스를 읽는 데 필요한 토큰이 워크플로 파일을 수정하거나, 풀 리퀘스트를 병합하거나, 저장소를 관리할 권한까지 의미하지는 않습니다.

환경 변수는 값을 전달하는 수단이지, 완전한 격리 경계가 아닙니다. 하위 프로세스가 환경 변수를 상속할 수 있으며, 디버깅 명령이나 로그를 통해 값이 노출될 수도 있습니다. 각 워커에 어떤 변수가 전달되는지 검토하고, 테스트에 프로덕션 값을 공유하지 마세요. 시뮬레이션할 수 있는 서비스에는 테스트용 자격 증명을 사용하세요.

OWASP 비밀 정보 관리 지침에서는 접근 제어와 키 교체에 관한 배경 정보를 제공합니다. 에이전트가 필요하지 않은 비밀 정보를 읽었다면, 정보 유출이 확인되지 않았더라도 구성 문제로 간주하세요. 모델이 스스로 주의를 돌리기를 기대하는 대신, 환경에서 불필요한 접근을 불가능하게 하거나 의도적으로 제한해야 합니다.

컨테이너 또는 샌드박스로 접근을 제한하는 방법

실제 구성을 점검하세요. 사용자 ID, 마운트된 경로, 네트워크 정책, 권한, 소켓, 사용 가능한 자격 증명을 확인하세요. 호스트의 홈 디렉터리와 컨테이너 엔진 소켓을 마운트한 컨테이너는 작업 폴더를 훨씬 넘어서는 접근 권한을 가질 수 있습니다. “샌드박스”라는 표시만으로 해당 리소스가 제한된다고 볼 수는 없습니다.

Docker 보안 개요에서는 중요한 런타임 고려 사항을 설명합니다. 플랫폼에서 지원하는 제어 기능을 사용해 권한을 줄이고, 필요한 데이터만 마운트하며, 서비스 상태를 분리하세요. 작업 범위 밖에 있어야 하는 위치에 워커가 접근할 수 있는지 테스트하세요. 접근이 차단되면 제어 기능이 작동 중이라는 유용한 증거가 됩니다.

네트워크 접근 권한은 작업에 필요한 범위에 맞춰야 합니다. 작업에 패키지 레지스트리와 저장소 호스트는 필요하더라도, 임의의 외부 대상이나 프로덕션 데이터베이스까지 필요하지 않을 수 있습니다. 강제 적용할 수 있는 계층에서 제어하고 예외는 문서화하세요. 종속성 설치를 위해 인증서 검사를 비활성화하지 마세요. 실제 신뢰 또는 연결 문제를 해결하세요.

루트리스 Docker 문서에서는 데몬과 컨테이너의 권한을 줄이는 한 가지 방법을 설명합니다. 그렇다고 모든 워크로드가 무해해지거나 마운트와 비밀 정보를 검토할 필요가 없어지는 것은 아닙니다. 실행하는 코드와 호스트 환경의 중요도에 맞춰 격리 방식을 선택하세요.

변경 사항은 어떻게 검토하고 병합해야 하나요?

커밋뿐 아니라 커밋되지 않은 작업도 검토하세요. 에이전트는 관련 파일을 커밋에서 누락하거나 제안된 브랜치와 다른 작업 디렉터리를 테스트하면서 작업을 완료했다고 보고할 수 있습니다. 실제 결과를 밝히도록 요청한 뒤 독립적으로 점검하세요.

git -C ../agent-docs status --short
git -C ../agent-tests status --short
git diff --stat main...agent/docs
git diff main...agent/docs
git diff --stat main...agent/tests
git diff main...agent/tests

각 작업 트리에서 프로젝트 관련 검사를 실행하고, 상호작용이 중요한 경우 통합된 리비전에서도 다시 실행하세요. 공유 계약, 생성된 파일, 의존성 업데이트를 검토하세요. 검토 중 기준 브랜치가 바뀌면 어떤 검토 근거가 오래된 것인지 확인하세요. 승인 대상이었던 코드를 변경하면서 승인된 것처럼 보이게 해서는 안 됩니다.

GitHub의 보호된 브랜치 문서에서는 워크플로를 보완할 수 있는 리포지토리 측 제어 기능을 설명합니다. 중대한 변경 사항의 최종 승인은 에이전트가 제안서를 작성할 권한과 분리하세요. 검토 에이전트가 또 다른 관점을 제시할 수는 있지만, 병합의 유일한 결정권자가 되어서는 안 됩니다.

저희 에이전트 자동 수정 검토 가이드에는 관련 승인 체크리스트가 있습니다. 충돌이 발생하면 먼저 의도한 동작을 해결하세요. 계약을 설명하지 않은 채 모델에 충돌 표시만 제거해 달라고 하면, 파일은 깔끔해져도 잘못된 동작이 결합될 수 있습니다.

승인된 작업을 안전하게 보존하고 통합한 뒤에는 일반적인 정리 방법을 사용하세요.

git worktree list
git worktree remove ../agent-docs
git worktree remove ../agent-tests
git branch -d agent/docs
git branch -d agent/tests

거부를 우회하는 강제 옵션은 추가하지 마세요. 작업 트리가 지저분하거나 Git에서 병합된 것으로 간주하지 않는 브랜치는 점검해야 합니다. 미완성 변경 사항을 보존하고, 무엇을 제거할지 결정하기 전에 이력을 파악하세요.

병렬 실행 중에는 무엇을 모니터링해야 하나요?

작업의 소유권, 프로세스 수명, 리소스 사용량, 외부 요청, 검토를 기다리는 결과 대기열을 모니터링하세요. 작업이 끝난 뒤에도 계속 실행되는 워커는 인증 정보를 계속 사용하거나 공유 서비스를 변경할 수 있습니다. 워커를 어떻게 중지하는지, 실제로 중지되었는지는 어떻게 확인하는지 정하세요.

각 작업에 적절한 예산과 에스컬레이션 조건을 설정하세요. 종속성 오류가 반복되거나, 예상치 못한 권한을 요청하거나, 범위를 벗어난 수정이 발견되면 무제한으로 재시도하지 말고 점검하세요. 로그는 유용하게 유지하되 비밀 값이나 불필요한 사적 내용은 기록하지 마세요.

저희 개인 에이전트 권한 체크리스트는 접근 권한 검토를 준비하는 데 도움이 됩니다. Conductor 전환 분석은 작업의 이식성을 유지해야 하는 이유도 보여 줍니다. 오케스트레이션 제품을 바꾸더라도 커밋, 작업 상태, 검토 증거가 유지되어야 합니다.

다음 작업을 시작하기 전에 필요한 임시 자격 증명이 취소되었는지, 백그라운드 서비스가 정리되었는지, 완료된 브랜치의 처리 방침이 정해졌는지 확인하세요. 활성 에이전트 수가 아니라 수용된 작업량과 검토자의 수고를 측정하세요. 통합이 병목이라면 대기열에 결과물을 더 추가하지 말고 진행 중인 작업량을 줄이세요.

정리하기 전에 Git 기록 밖에 있는 자료는 복구 가능한 파일 작업 절차를 확인하세요. 추적되지 않은 데이터 세트, 로컬 구성 파일 또는 외부 서비스 상태에는 별도의 복구 계획이 필요할 수 있습니다.

자주 묻는 질문

두 에이전트가 하나의 브랜치를 안전하게 사용할 수 있나요?

공동 작업을 조정할 수는 있지만, 독립적인 에이전트에는 일반적으로 각각 별도의 브랜치와 작업 디렉터리를 제공해야 합니다. 그렇지 않으면 수정 사항과 테스트 결과의 출처를 파악하고 재현하기 어려워집니다.

.env를 .gitignore에 추가하면 에이전트가 해당 내용을 볼 수 없게 되나요?

아니요. 무시 규칙은 Git 추적 여부에 영향을 줄 뿐, 파일 시스템 읽기 권한에는 영향을 주지 않습니다. 불필요한 비밀 정보는 작업자가 접근할 수 있는 환경 밖에 두세요.

모든 에이전트에게 변경 사항을 병합할 수 있는 토큰을 줘야 하나요?

아니요. 작업에 필요한 권한만 부여하세요. 변경 제안 권한과 보호된 브랜치에 변경 사항을 수용할 권한은 서로 다릅니다.

워크트리 제거가 진행되지 않으면 어떻게 해야 하나요?

커밋되지 않았거나 추적되지 않은 작업이 있는지 디렉터리를 살펴보고, 중요한 내용을 보존하세요. 강제 옵션을 일상적인 정리 방법으로 사용하지 마세요.

각 브랜치에서 테스트를 통과하면 충분한가요?

변경 사항이 서로 영향을 주는 경우에는 그렇지 않습니다. 실제 통합된 리비전을 대상으로 관련 검사를 실행하고 경계 간 동작을 점검하세요.

결론

안전한 병렬 코딩에는 소스 격리와 런타임 및 자격 증명 제어가 함께 필요합니다. 워크트리를 사용하면 변경 사항을 분리하고 검토하기 쉬우며, 전용 권한과 적절히 구성된 샌드박스는 에이전트가 접근할 수 있는 범위를 제한합니다.

깨끗한 기반에서 시작하고, 각 작업에 명확한 담당자와 계약을 정한 뒤, 검토 가능한 결과물만 통합하세요. 정리하기 전에 증거를 보존하고, 임시 접근 권한을 취소하며, 수용된 결과물이 조정 비용을 정당화할 때만 동시 작업을 늘리세요.