GitHub Copilot App 다중 Agent 설정법

증상: 여러 Issue를 동시에 맡겼지만 파일 충돌과 재작업이 늘어납니다.
가장 빠른 해결법: 처음에는 의존성이 낮은 두 작업만 분리하고, 각 세션에 작업 위치, 브랜치, 모드, 권한, 테스트 기준과 병합 담당자를 지정합니다.

이 글은 GitHub Copilot App 다중 Agent를 처음 구성하는 고급 개발자, 여러 저장소를 관리하는 유지 보수 담당자, 팀용 개발 환경을 준비하는 플랫폼 팀을 위한 실행 안내서입니다. 더 많은 Agent를 켜는 방법보다, 병렬 작업을 중단해야 하는 조건까지 함께 다룹니다.

마지막 업데이트: 2026년 7월 28일. GitHub 공식 문서와 2026년 7월 변경 기록을 기준으로 확인했습니다.

먼저 두 작업으로 범위를 고정합니다

첫 실험은 문서 수정과 독립 테스트처럼 서로 같은 파일과 핵심 로직을 건드리지 않는 작업으로 잡습니다. 작은 결함 수정도 가능하지만, 인증 흐름이나 공통 데이터 모델처럼 여러 기능이 참조하는 영역은 첫 병렬 실험에서 제외하는 편이 안전합니다.

각 Agent Sessions에 다음 내용을 따로 입력합니다.

• 작업 목적과 입력 Issue
• 수정해도 되는 파일과 금지된 디렉터리
• 실행해야 하는 테스트
• 완료로 인정할 조건
• 변경하지 않고 보고만 해야 하는 위험 요소
• 최종 결과를 검토하고 PR을 합칠 담당자

예를 들어 첫 번째 세션에는 문서의 설치 절차만 맡기고, 두 번째 세션에는 기존 테스트 파일 안의 독립된 테스트 케이스 추가만 맡깁니다. 두 세션 모두 같은 설정 파일이나 공통 모듈을 수정하지 못하게 제한합니다.

GitHub 공식 안내에 따르면 GitHub Copilot App은 여러 격리 세션을 실행하고, 각 세션을 별도 Git worktree와 브랜치에서 운영할 수 있습니다. 다만 작업 공간이 분리되어도 요구사항과 설계 판단까지 자동으로 조정되는 것은 아닙니다. (docs.github.com)

주의: 첫 실행에서 코드 작성, 대규모 리팩터링, 데이터베이스 변경을 한 번에 시키지 마십시오. 성공 여부를 판단하기 어려워지고, 충돌 원인도 작업 분할인지 Agent의 판단인지 구분하기 어렵습니다.

GitHub Copilot App 다중 Agent 실행 위치를 고릅니다

세션을 만들 때 GitHub Copilot App은 새 작업 트리, 현재 로컬 저장소, 클라우드 샌드박스 같은 실행 위치를 선택하도록 합니다. 작업의 파일 범위와 필요한 운영체제가 무엇인지 먼저 확인한 뒤 위치를 정해야 합니다.

로컬 작업 트리

로컬 작업 트리는 기존 개발 환경과 가장 가깝습니다. 이미 설치된 의존성, 사내 인증, 로컬 테스트 도구를 사용할 수 있다는 장점이 있습니다. 반면 여러 세션이 동시에 빌드와 테스트를 실행하면 디스크, 메모리, 프로세스, 포트가 서로 영향을 줄 수 있습니다.

다음 조건이면 로컬 작업 트리를 우선 선택합니다.

• 코드 변경이 작고 테스트가 짧습니다.
• 로컬 인증이나 사내 네트워크가 필요합니다.
• macOS 또는 Xcode가 필요한 작업입니다.
• 결과를 즉시 확인해야 합니다.

클라우드 샌드박스

클라우드 샌드박스는 GitHub가 제공하는 격리된 임시 Linux 환경입니다. 공개 미리 보기 상태이므로 팀의 기본 배포 환경으로 고정하기보다, 독립 테스트나 Linux 기반 빌드 검증부터 적용하는 편이 좋습니다. 클라우드 환경은 로컬 자원을 덜 사용하고 여러 세션을 분리하기 쉽지만, macOS 전용 도구와 Xcode 프로젝트를 그대로 대체하지는 못합니다. (github.blog)

다음 조건이면 클라우드 샌드박스로 되돌립니다.

• 로컬 저장소 접근 없이 재현 가능한 테스트입니다.
• Linux에서 실행되는 빌드나 정적 분석입니다.
• 장시간 실행으로 개발용 컴퓨터를 계속 점유하기 어렵습니다.
• 세션을 다른 기기에서 이어서 확인해야 합니다.

Git worktree와 현재 저장소

현재 저장소를 여러 Agent가 직접 공유하면 파일이 덮어써질 수 있습니다. 따라서 같은 저장소에서 코드 변경을 병렬로 진행할 때는 새 Git worktree와 독립 브랜치를 기본값으로 둡니다. 단, Git worktree는 파일 수준의 겹침을 줄일 뿐입니다. 같은 API의 동작을 서로 다르게 해석하거나 테스트 기준을 바꾸면 논리 충돌은 그대로 남습니다.

여러 Agent 수정 충돌을 줄이는 경계를 정합니다

같은 저장소에서 두 세션을 실행할 때는 파일 목록보다 책임 영역을 먼저 나눠야 합니다.

예를 들어 다음처럼 분리합니다.

• Agent A: docs/와 설치 문서
• Agent B: 독립 테스트 파일과 테스트 데이터
• 담당자: 공통 설정, 패키지 잠금 파일, 핵심 모듈

공통 모듈을 둘 이상의 Agent가 동시에 수정해야 한다면 병렬 작업을 중단하고 순차 작업으로 바꿉니다. 특히 다음 작업은 함께 맡기지 않는 것이 좋습니다.

• 동일한 함수나 클래스의 대규모 리팩터링
• API 응답 형식 변경과 그에 따른 클라이언트 수정
• 데이터베이스 스키마 변경과 마이그레이션
• 패키지 버전 변경과 빌드 설정 변경
• 배포 파일, 비밀 값, 인증 설정 수정

커밋도 작업 단위에 맞춰 작게 유지합니다. 문서와 테스트를 한 커밋에 섞지 말고, 기능 변경과 자동 생성 파일을 분리합니다. 그래야 PR 검토자가 변경 목적을 빠르게 확인할 수 있고, 한 작업만 되돌리기도 쉽습니다.

작업 분할 조건을 먼저 확인합니다

병렬 Agent 작업은 다음 조건을 모두 만족할 때 시작합니다.

• 의존성이 낮으면 병렬로 실행합니다. 한 작업의 결과를 다른 작업이 즉시 받아야 하지 않아야 합니다.
• 완료 기준이 명확하면 병렬로 실행합니다. 통과해야 할 테스트나 검토할 문서 범위가 있어야 합니다.
• 수정 영역이 분리되면 새 작업 트리와 브랜치를 사용합니다.
• 실패를 되돌릴 수 있으면 Interactive 또는 Plan으로 시작합니다.
• 결과를 사람이 검토할 수 있으면 각 세션에 PR 또는 검토용 산출물을 요구합니다.

반대로 하나라도 만족하지 못하면 단일 Agent로 전환합니다. 특히 첫 작업의 결과가 두 번째 작업의 입력이 되는 순차 흐름이라면, Agent 수를 늘려도 대기 시간이 줄지 않습니다. GitHub도 병렬 실행은 독립적으로 분해할 수 있는 작업에 적합하며, 본질적으로 순차적인 요청에는 이점이 작을 수 있다고 설명합니다. (docs.github.com)

저장소와 의존성을 나누어 연결합니다

여러 저장소가 연결된 작업은 주 저장소, 의존 저장소, 인터페이스 계약의 순서를 정해야 합니다.

예를 들어 주 저장소가 내부 라이브러리의 새 API를 사용해야 한다면 다음 순서를 따릅니다.

1. 의존 라이브러리의 인터페이스 변경을 먼저 정의합니다.
2. 해당 변경을 설명하는 테스트 또는 계약 문서를 추가합니다.
3. 의존 라이브러리의 PR을 검토합니다.
4. 주 저장소에서 새 버전을 참조하도록 수정합니다.
5. 통합 테스트와 배포 전 검증을 실행합니다.

두 세션이 각각 다른 저장소를 읽어야 한다면 필요한 권한만 부여합니다. 읽기만 필요한 저장소에 쓰기 권한을 주지 말고, 패키지와 서브모듈을 어떤 방식으로 가져오는지 시작 전에 확인합니다. SSH 키, 패키지 저장소 토큰, 사내 인증이 자동으로 전달된다고 가정해서는 안 됩니다.

GitHub Copilot App의 조직 정책과 세션 권한은 관리자가 별도로 통제할 수 있습니다. 2026년 7월 27일 변경 기록에는 앱 접근 정책을 CLI 정책과 분리해 관리할 수 있게 되었다고 안내되어 있으므로, 팀 도입 전에는 개인 설정뿐 아니라 조직 정책도 확인해야 합니다. (github.blog)

세션 모드와 모델을 작업 위험도에 맞춥니다

세션 모드는 속도 설정이 아니라 사람의 개입 수준을 정하는 제어 장치입니다.

• Interactive: 변경마다 방향을 조정해야 하는 결함 분석, 낯선 코드, 보안 관련 수정에 적합합니다.
• Plan: 범위가 넓지만 실행 전에 설계를 확인해야 하는 리팩터링과 여러 저장소 작업에 적합합니다.
• Autopilot: 파일 범위와 완료 기준이 명확한 문서 수정, 독립 테스트, 반복적인 CI 실패 수정에 적합합니다.

모델은 작업의 복잡도에 맞춥니다. 단순한 이름 변경이나 문서 작업에는 가벼운 모델을 선택하고, 여러 모듈의 원인을 추적하는 결함에는 더 높은 추론 수준을 선택합니다. GitHub Copilot App에서는 세션마다 모델과 추론 수준을 바꿀 수 있으며, 자동 선택을 사용하면 작업 복잡도에 따라 모델이 선택됩니다. (docs.github.com)

Autopilot은 승인 없이 계속 진행할 수 있으므로 데이터베이스 마이그레이션, 릴리스, 비밀 값, 알 수 없는 설치 스크립트에는 사용하지 않습니다. 자동 실행은 작업이 명확할 때만 허용하고, 중단 조건을 프롬프트에 명시합니다. (docs.github.com)

운영 경험: “테스트가 통과할 때까지 수정하라”보다 “이 디렉터리 안에서 이 테스트만 실행하고, 실패 원인이 범위를 벗어나면 중단하라”가 훨씬 안전합니다. 중단 조건이 없으면 Agent는 목표 달성을 위해 수정 범위를 계속 넓힐 수 있습니다.

장시간 테스트와 macOS 작업을 분리합니다

장시간 테스트와 빌드는 병렬화하기 전에 실행 위치를 먼저 결정해야 합니다. 로컬 세션은 현재 개발 환경을 그대로 활용할 수 있지만, 여러 빌드가 동시에 실행되면 개발용 컴퓨터의 반응성이 떨어질 수 있습니다. 클라우드 샌드박스는 Linux 기반 격리 환경이므로 macOS 전용 도구나 Xcode 빌드에는 적합하지 않습니다.

다음 기준으로 선택합니다.

• macOS, Xcode, iOS 시뮬레이터가 필요하면 관리 가능한 Mac 환경을 사용합니다.
• Linux 패키지 설치와 단위 테스트만 필요하면 클라우드 샌드박스를 검토합니다.
• 실행 시간이 길고 결과를 나중에 확인해도 되면 원격 상시 환경을 검토합니다.
• 사내 네트워크, 하드웨어 장치, 서명 인증서가 필요하면 클라우드 샌드박스를 기본값으로 두지 않습니다.

Mac에서 장시간 병렬 개발을 운영해야 한다면 원격 Mac 개발 환경 안내와 구성 주문 안내를 먼저 확인하십시오. 다만 환경을 추가하는 것만으로 병렬 작업이 안전해지는 것은 아니며, 저장소 경계와 권한 설계가 먼저입니다.

PR 결과를 한 번에 합치지 않습니다

각 세션은 다음 형식으로 결과를 남겨야 합니다.

• 변경한 파일과 변경하지 않은 파일
• 실행한 명령과 테스트 결과
• 통과하지 못한 테스트
• 남아 있는 위험
• 사람이 확인해야 하는 설계 결정
• PR에서 다른 작업과 충돌할 가능성이 있는 부분

병합 순서도 정합니다. 보통 문서와 독립 테스트를 먼저 검토하고, 공통 모듈 변경을 마지막에 처리합니다. 의존 라이브러리 변경이 있다면 의존 저장소 PR을 먼저 합친 뒤 주 저장소 작업을 검증합니다.

평가 지표는 실행한 Agent 수가 아닙니다. 다음 항목을 기록해야 합니다.

• 실제 충돌이 발생한 PR 수
• 충돌 뒤 재작업한 이유
• 사람이 PR을 검토하는 데 걸린 시간
• 테스트 실패가 코드 결함인지 환경 문제인지
• 병렬 작업을 중단하고 순차 처리한 시점

이 기록이 있어야 “더 많이 실행했다”와 “더 빨리 납품했다”를 구분할 수 있습니다.

두 가지 운영안을 비교합니다

GitHub Copilot App은 새 작업 트리, 로컬 저장소, 클라우드 샌드박스에서 세션을 시작할 수 있지만, 클라우드 샌드박스는 공개 미리 보기라는 점을 운영 정책에 반영해야 합니다. (docs.github.com)

첫 설정을 위한 실행 순서

1. 공개적으로 재현 가능한 테스트 저장소 또는 안전한 작업 브랜치를 준비합니다.
2. 문서와 독립 테스트처럼 서로 의존하지 않는 두 작업을 고릅니다.
3. 각 작업의 허용 파일, 금지 파일, 완료 기준을 작성합니다.
4. GitHub Copilot App에서 각각 새 작업 트리와 별도 브랜치를 선택합니다.
5. 세션별로 Interactive 또는 Plan을 먼저 적용하고, 작업이 충분히 명확할 때만 Autopilot으로 전환합니다.
6. 모델과 추론 수준을 작업 난이도에 맞게 지정합니다.
7. 테스트 명령, 중단 조건, 결과 보고 형식을 프롬프트에 포함합니다.
8. 두 세션이 만든 변경을 각각 PR로 검토합니다.
9. 충돌률과 재작업 원인을 기록한 뒤 세 번째 병렬 작업 여부를 결정합니다.

현재 로컬 자원이나 인증 환경이 병목이라면 도움말 센터에서 원격 Mac 운영 조건을 확인할 수 있습니다. 장시간 Mac 빌드가 실제 제한으로 확인된 경우에만 원격 환경을 추가하는 편이 비용과 관리 부담을 줄입니다.

두 개의 저위험 작업을 끝낸 뒤에도 충돌과 재작업이 적고, 사람이 PR을 검토할 수 있다면 세션을 늘려도 됩니다. 반대로 공통 모듈 수정이 반복되거나 검토 시간이 병렬 작업보다 길어지면 즉시 단일 세션으로 되돌리십시오.

현재 방식이 로컬 컴퓨터 하나에 여러 빌드와 테스트를 몰아주는 구조라면, 자원 경쟁과 인증 공유, 작업 중단 문제가 먼저 나타납니다. 그렇다고 Mac 환경을 바로 추가할 필요는 없습니다. 문서와 독립 테스트는 로컬 또는 클라우드 샌드박스로 처리하고, 장시간 테스트나 macOS 빌드가 실제 병목으로 확인될 때만 Macstripe의 원격 Mac 환경을 비교하는 순서가 더 합리적입니다. 이 방식이면 필요하지 않은 상시 자원을 피하면서도, 여러 Agent Sessions를 안정적으로 유지할 수 있습니다.