VS Code 1.138 Agent PR 생성 후, Mac 빌드는 어디에 둘까? 2026

문제: VS Code 1.138 Agent PR 생성은 끝났지만 Xcode 작업을 같은 호스트에서 재현하기 어렵습니다.
빠른 해법: PR 생성은 Agent Host에 두고, 일반 테스트는 독립 CI에, Xcode·서명·Apple 플랫폼 검증은 독립 클라우드 맥에 배치합니다.

이 기준은 iOS·macOS 팀, Agent Host와 CI Runner의 책임을 나누려는 플랫폼 엔지니어, 비용을 통제하면서도 공유 호스트 오염을 피하려는 AI 코딩 팀에 적합합니다. 저위험 원형만 임시로 한 호스트에서 처리하고, 서명이나 배포가 들어가는 순간 환경을 분리해야 합니다.

최종 업데이트: 2026년 9월 20일. VS Code 기능 상태는 VS Code 1.138 공식 릴리스 노트와 Agent Host 구조 문서로 확인했으며, 보호된 브랜치와 필수 검사는 GitHub 공식 문서로 다시 대조했습니다.

세 가지 상태 구분

VS Code 1.138의 Agent Host 세션에서 PR을 검토하고 생성할 수 있습니다. 초안 상태를 선택하거나 합병 관련 옵션을 설정할 수도 있습니다. 다만 이것은 “PR이 만들어졌다”는 뜻이지, “검사가 통과했다”거나 “코드가 출시 가능하다”는 뜻은 아닙니다.

다음 세 상태를 PR 화면과 운영 기록에서 분리해야 합니다.

• PR 생성 완료: 변경 커밋과 검토 요청이 원격 저장소에 존재합니다.
• 검사 통과: 지정된 CI 작업이 해당 커밋을 대상으로 성공했습니다.
• 출시 가능: 필수 검사, 사람 승인, 보호된 브랜치 규칙, 서명 및 플랫폼 회귀까지 충족했습니다.

Agent Merge가 실험 기능으로 표시되는 동안에는 자동 합병을 배포 승인과 같은 의미로 해석하면 안 됩니다. GitHub 보호 브랜치 문서도 필수 상태 검사와 승인 규칙을 별도 통제 영역으로 다룹니다.

PR에는 최소한 다음 증거를 연결하십시오.

• 변경된 커밋 식별자와 작업 브랜치
• 실행한 검사 이름과 성공 또는 실패 로그
• 실행 환경과 의존성 버전
• 실패 후 재시도 여부
• 승인자와 실제 합병 주체

주의: Agent가 PR을 만들 수 있다는 사실은 저장소 규칙을 우회할 권한을 뜻하지 않습니다. Agent의 저장소 신원, 브랜치 쓰기 권한, 검사 결과의 발행 주체를 각각 확인해야 합니다.

코드 종류별 환경 배치

순수 웹 코드, 여러 운영체제에서 동작하는 라이브러리, 컨테이너 기반 서비스라면 새 Mac을 바로 추가할 필요가 없습니다. 정적 분석, 단위 테스트, 컨테이너 빌드가 일반 Runner에서 재현되고 Apple 전용 의존성이 없다면 Agent Host는 수정과 PR 생성만 맡고, GitHub Actions Runner 선택 문서에 맞는 CI 작업으로 검증을 넘기면 됩니다.

반대로 다음 조건이 하나라도 있으면 독립 클라우드 맥을 기본값으로 두십시오.

• Xcode 프로젝트 또는 Apple 시스템 프레임워크를 빌드합니다.
• 시뮬레이터나 실제 기기에서 동작을 확인해야 합니다.
• 인증서, 프로비저닝 프로파일, 서명 키가 필요합니다.
• 장시간 빌드가 Agent 세션의 작업을 점유합니다.
• CI에서 사용하는 일반 실행기가 Mac 환경을 재현하지 못합니다.

Apple의 시뮬레이터 및 실제 기기 실행 안내는 플랫폼 검증이 단순한 소스 코드 검사와 다르다는 점을 보여줍니다. 따라서 컨테이너가 성공했더라도 Xcode 빌드 성공으로 대체할 수 없습니다.

Agent Host에서 직접 Xcode를 실행하면 초기 판단은 빠릅니다. 그러나 Agent가 남긴 임시 파일, 설치된 패키지, 변경된 환경 변수와 인증 정보가 다음 작업에 영향을 줄 수 있습니다. 독립 Mac 빌드 계층은 작업마다 새 작업 공간을 만들고 결과물을 보존하기 쉬워 재현성이 높습니다.

시나리오별 선택표

표의 핵심은 장비 이름이 아니라 책임의 분리입니다. Agent Host는 변경을 제안하고, CI는 같은 커밋을 반복 검사하며, Mac 계층은 Apple 플랫폼에서 실제로 실행되는 결과를 증명합니다.

원격 작업과 장시간 점유

Agent Host가 원격 서버나 클라우드 맥에 있다면 세 가지 저장 위치를 분리해서 설계하십시오.

1. 코드 작업 공간은 Git 커밋과 브랜치로 복구할 수 있어야 합니다.
2. 작업 상태는 세션 연결이 끊겨도 재조회할 수 있는 저장소에 남겨야 합니다.
3. 빌드 산출물과 로그는 작업 공간과 분리된 보관 영역에 업로드해야 합니다.

GitHub Actions 아티팩트 문서를 참고하면 로그와 산출물을 작업 실행과 함께 보존하는 방식의 기준을 세울 수 있습니다. 워크플로 로그 문서도 실패 원인을 나중에 확인할 수 있는 로그 관리 방식을 설명합니다.

클라이언트 연결이 끊겼다고 작업이 자동으로 복구 가능한 것은 아닙니다. 실제 운영 전에는 다음을 직접 확인해야 합니다.

• 작업 중단 뒤 같은 커밋으로 재연결되는가
• 중단된 Xcode 작업이 새 작업으로 안전하게 재실행되는가
• 이전 작업의 임시 파일과 인증 정보가 남지 않는가
• 다른 운영자가 작업 상태와 산출물을 인계받을 수 있는가
• 실패와 재시도가 PR에 구분되어 표시되는가

장시간 Xcode 작업은 전용 큐로 보내야 합니다. 생성 코드를 기다리는 Agent Host에 빌드 대기까지 맡기면, 모델 작업과 플랫폼 검증이 서로의 자원을 잠식합니다. 자체 호스팅 Runner 안내처럼 실행기 그룹과 라벨을 나누는 방식이 환경 구분에 유용합니다.

병렬 PR과 용량 판단

여러 Agent가 동시에 PR을 만들면 모델 생성 속도보다 다른 구간이 먼저 막힐 수 있습니다. 대표적인 병목은 의존성 설치, 테스트 큐, Xcode 작업, 실패 재시도, 사람 승인입니다. 그러므로 Agent 세션 수를 그대로 Mac 수로 환산하지 마십시오.

각 작업에서 다음 시간을 별도로 기록하십시오.

• 큐에 들어간 시점부터 실행 전까지의 대기 시간
• 실제 의존성 설치와 빌드에 걸린 실행 시간
• 실패 후 재시도 횟수와 재시작 시간
• 검토와 승인에 걸린 시간
• 산출물 보관 및 다음 단계 전달 시간

대기만 길고 Mac이 실제로 유휴 상태라면 큐 규칙이나 우선순위를 고쳐야 합니다. Mac이 계속 점유되고 실패 재시도가 겹친다면 탄력적인 Mac 용량을 검토해야 합니다. 서명 작업은 일반 테스트와 같은 큐에 넣지 말고, 접근 권한이 낮은 공유 풀과 별도 권한의 보호 풀로 나누는 편이 안전합니다.

경험상 가장 위험한 구성은 Agent가 코드를 바꾸고, 같은 신원으로 검사 결과를 만들며, 같은 자격 증명으로 서명까지 수행하는 구조입니다. 결과가 성공해도 누가 무엇을 검증했는지 설명하기 어렵습니다.

독립 FAQ

Agent Host에서 PR을 만들었는데 CI가 필요한 이유

필요합니다. Agent Host는 변경과 PR 생성에 적합하지만, 결정적 검사의 독립 실행 주체가 되면 결과의 신뢰 경계가 흐려질 수 있습니다. CI는 동일한 커밋을 깨끗한 실행 환경에서 검사하고, 로그와 산출물을 PR에 연결해야 합니다. 그래야 생성 완료와 검사 통과를 별도 상태로 설명할 수 있습니다.

Agent가 만든 iOS PR의 Xcode 실행 위치

Xcode와 시뮬레이터, Apple 전용 프레임워크가 포함되면 독립 클라우드 맥에서 실행하십시오. Agent Host 원격 실행은 빠른 확인에는 쓸 수 있지만, 작업 공간 오염과 장시간 점유를 추적하기 어렵습니다. 서명과 배포 후보 생성은 별도 권한의 Mac 작업으로 분리해야 합니다.

Agent Host와 GitHub Actions Runner를 한 Mac에 둘 수 있는 조건

저위험 원형, 비밀 정보가 없는 테스트, 짧은 작업, 재현 가능한 초기화 절차가 모두 있을 때만 임시로 허용할 수 있습니다. 보호된 저장소, 서명 키, 배포 자격 증명, 장시간 Xcode 작업이 포함되면 분리하십시오. 한 Mac을 유지한다면 작업 공간 초기화와 실행 로그를 독립적으로 확인해야 합니다.

동시에 생성된 PR의 Mac 큐 운영법

PR 개수나 Agent 수가 아니라 실제 실행 시간을 기준으로 큐를 설계하십시오. 일반 테스트와 Xcode 빌드, 서명 작업에 각각 라벨과 우선순위를 부여하고, 대기 시간과 재시도 시간을 함께 기록해야 합니다. 반복적으로 대기가 발생할 때만 탄력 풀을 늘리고, 단순한 설정 문제라면 먼저 큐 정책을 고쳐야 합니다.

세 층 구조와 최종 선택

기본 구조는 다음과 같이 두면 됩니다.

• Agent Host: 코드 수정, 브랜치 작업, PR 생성
• 결정적 CI: 정적 검사, 일반 단위 테스트, 컨테이너 기반 검증
• 독립 클라우드 맥: Xcode 빌드, 시뮬레이터·기기 회귀, 서명 및 Apple 플랫폼 전달

현재 구조를 유지해도 되는 경우는 저위험 원형이고, 서명 정보가 없으며, 일반 Runner에서 결과가 재현되고, Xcode 작업이 별도 큐를 막지 않을 때입니다. 빌드 계층을 분리해야 하는 경우는 Apple 플랫폼 의존성이나 보호 저장소가 생겼을 때입니다. 탄력 용량을 추가할 경우는 분리된 Mac 큐에서 실제 대기와 재시도가 반복되고, 작업 우선순위를 조정해도 병목이 남을 때입니다.

지금 Agent Host와 Xcode 빌드를 같은 Mac에 두고 있다면 공유 작업 공간 오염, 장시간 점유, 서명 권한 노출이 실제 약점입니다. 기존 CI만으로는 Apple 플랫폼 결과를 증명하기 어렵고, 일반 Runner를 늘리는 것만으로는 Xcode 환경을 만들 수 없습니다. 이런 경우에는 먼저 세 층 표로 현재 PR 흐름을 표시한 뒤, 필요한 작업에만 kvmsync 클라우드 맥을 배정하는 방식이 비용과 재현성을 함께 관리하기 쉽습니다. 사용 가능한 환경과 운영 조건은 kvmsync 서비스 안내에서 확인하고, 이미 Mac 큐가 밀린다면 kvmsync 요금 안내와 비교해 기본 풀과 피크 풀을 나누어 검토하십시오.