빌드 로그를 읽게 하려던 AI Agent가 어느 순간 파이프라인 변경 권한까지 요구하고 있습니까?

2026년 9월 3일 기준, TeamCity 2026.2 MCP는 기업 시험 운영에 넣을 수 있지만 바로 운영 배포선에 연결해서는 안 됩니다. 이번 주에는 안전 모드, 프로젝트 전용 계정, 읽기 전용 진단부터 검수하고 변경 작업은 테스트 프로젝트에만 제한하십시오. Xcode 서명은 격리된 신뢰 원격 맥 노드에서 계속 처리해야 합니다. 공식 출시 기록은 TeamCity 2026.2에 파이프라인 조회, 생성, 수정, 삭제 도구가 추가됐다고 확인합니다.

이 글은 Claude Code, Codex, Cursor 같은 외부 Agent를 TeamCity에 연결하려는 개발 생산성 책임자를 위한 내용입니다.
권한 상속과 감사 증거를 검토하는 보안 담당자, Xcode 빌드 풀과 원격 맥 용량을 관리하는 플랫폼 팀에도 맞습니다.

마지막 업데이트: 2026년 9월 3일. TeamCity 2026.2 출시 기록, MCP 연동 문서, 역할 및 토큰 문서를 기준으로 내용을 확인했습니다.

01

분기별 운영 판단

능력 기업 시험 단계 운영 확대 판단
로그와 상태 조회 안전 모드에서 허용 프로젝트 범위와 감사 기록이 확인되면 확대
개인 빌드 실행 제한된 테스트 프로젝트에서 허용 브랜치, Agent Pool, 취소 절차를 검증한 뒤 제한적 허용
파이프라인 변경 테스트 프로젝트와 비운영 브랜치만 허용 변경 전후 차이, 승인, 롤백이 모두 남을 때 검토
프로젝트 또는 파이프라인 삭제 기본 차단 별도 승인과 복구 훈련 없이는 운영 금지

TeamCity 2026.2 MCP의 도구 목록에 변경 기능이 있다는 사실과, 실제 Agent가 어떤 작업을 수행할 수 있다는 사실은 다릅니다. 후자는 사용자 역할, 프로젝트 권한, 토큰 범위, MCP 실행 모드와 실제 요청 결과를 함께 확인해야 합니다. MCP 연동 공식 문서를 기준으로 기능 목록을 확인하되, 호환성이나 운영 안정성을 문서만으로 추정해서는 안 됩니다.

02

플랫폼 책임자의 연결 범위

플랫폼 담당자는 MCP 서버가 TeamCity의 제어면에 들어오는 경로를 관리합니다. 먼저 전용 사용자로 연결하십시오. 기존 관리자 계정을 재사용하면 Agent에 필요 이상으로 넓은 프로젝트와 작업이 노출될 수 있습니다. TeamCity의 역할과 권한은 공식 권한 설명에서 역할별로 대조해야 합니다.

검수는 다음 순서로 진행하면 됩니다.

  • 전용 사용자로 MCP 인증을 완료합니다.
  • 허용할 프로젝트와 금지할 프로젝트를 목록으로 고정합니다.
  • 로그 조회, 빌드 조회, 빌드 실행을 각각 시험합니다.
  • 파이프라인 생성, 수정, 삭제는 기능별로 분리해 차단 여부를 확인합니다.
  • 부모 프로젝트의 권한 상속으로 범위가 넓어지지 않았는지 확인합니다.
  • 사용하지 않는 권한과 도구를 제거하고 승인 담당자를 기록합니다.

OAuth PKCE를 사용하는 접속과 사용자 토큰을 사용하는 접속은 같은 방식으로 다루면 안 됩니다. 인증 흐름, 토큰 보관 위치, 만료 및 폐기 책임자를 접속 문서에 남기십시오. 토큰의 실제 권한 범위는 TeamCity 접근 토큰 문서와 REST 권한 문서를 함께 보며 확인해야 합니다.

주의: MCP 연결 성공은 안전한 연결의 증거가 아닙니다. 금지 프로젝트의 목록, 로그, 빌드 상태가 노출되지 않는지 실제 계정으로 확인해야 합니다.

03

보안팀의 최소 권한 증거

보안 담당자가 받아야 할 자료는 설정 화면 한 장이 아닙니다. 다음 증거를 한 묶음으로 보관해야 합니다.

  • OAuth 동의 화면과 인증 주체
  • 토큰 범위와 발급 목적
  • 역할 권한 내보내기 결과
  • 부모 프로젝트에서 상속된 권한
  • 허용 프로젝트와 차단 프로젝트의 실제 접근 결과
  • 토큰 폐기 후 요청 실패 결과
  • 세션 종료 뒤 재접속 차단 결과

TeamCity의 REST 권한 체계는 권한 이름만 읽고 판단하기보다 실제 요청 결과로 검수해야 합니다. REST 권한 공식 문서의 권한 설명과 테스트 로그를 연결해 보관하십시오.

관리자 전역 토큰 하나를 여러 Agent가 공유하는 방식은 피해야 합니다. 담당자 변경 때 누가 폐기할지 알 수 없고, 사고 발생 시 어떤 Agent가 요청했는지 추적하기 어렵기 때문입니다. 전용 계정, 제한된 토큰, 명확한 만료 정책을 각각 지정해야 합니다.

04

프로젝트 책임자의 변경 검수

프로젝트 담당자는 “읽을 수 있다”와 “바꿀 수 있다”를 별개의 승인 대상으로 다뤄야 합니다. 읽기 도구는 샌드박스 프로젝트에서 로그와 구성 정보를 확인합니다. 실행 도구는 실패한 작업을 취소할 수 있는지까지 봐야 합니다. 변경 도구는 차이 기록과 승인자를 남긴 뒤에만 시험하십시오.

권장 검수 절차는 다음과 같습니다.

  • 샌드박스 프로젝트를 별도로 생성합니다.
  • 비운영 브랜치에 의도적으로 작은 변경을 요청합니다.
  • 변경 전 구성과 변경 후 구성을 저장합니다.
  • 승인 없는 변경이 거부되는지 확인합니다.
  • 승인된 변경을 되돌리고 이전 구성으로 복구합니다.
  • 삭제 요청은 복구 가능한 사본을 만든 뒤 차단 결과만 확인합니다.

Brave Mode는 이 과정에서 기본 운영 모드가 아니라 제한 실험 모드로 취급해야 합니다. 격리 프로젝트, 지정 담당자, 정해진 시간대라는 세 조건을 동시에 두십시오. 설정을 켠 뒤에는 반복 요청, 잘못된 대상 프로젝트, 승인 없는 변경을 재현하고 TeamCity의 사용자 작업 추적 문서에 따라 기록이 남는지 확인해야 합니다.

장점은 분명합니다. Agent가 로그 확인과 반복 진단을 빠르게 수행할 수 있습니다. 단점도 분명합니다. 파이프라인 변경은 작은 오타가 빌드 흐름과 배포 승인에 영향을 줄 수 있고, 삭제 작업은 복구 자료가 없으면 운영 중단으로 이어질 수 있습니다.

05

Mac 플랫폼팀의 신뢰 경계

MCP는 TeamCity 제어면의 입구입니다. 생산 맥에 직접 로그인하는 통로가 되어서는 안 됩니다. TeamCity Agent의 통신 구조는 공식 Agent 통신 문서로 확인하고, Agent Pool은 공식 풀 설정 문서에 따라 용도별로 분리하십시오.

권장 구분은 다음과 같습니다.

  • 일반 진단: 로그와 상태 확인이 가능한 제한된 풀
  • 비신뢰 코드 검증: 별도 계정과 별도 풀
  • 일반 Xcode 빌드: 승인된 저장소와 고정된 작업 환경
  • 공식 서명 및 배포: 신뢰된 풀과 고정 파이프라인

MCP 사용자에게 macOS 로컬 계정, SSH, VNC 또는 Keychain 접근 권한을 주지 마십시오. 서명 인증서는 Agent 작업에 필요한 범위에서만 사용하고, 비신뢰 빌드가 서명 풀로 라우팅되지 않는지 작업 기록으로 확인해야 합니다. 원격 맥을 하위 빌드 풀로 검토한다면 원격 맥의 개인정보 보호 기준도 함께 점검하십시오.

최소한 다음 동작을 실제 Xcode 프로젝트로 재현해야 합니다.

  • 일반 테스트 빌드가 격리 풀에 들어가는지 확인합니다.
  • 서명 없는 검증 작업이 인증서에 접근하지 못하는지 확인합니다.
  • 승인된 배포 작업만 서명 풀에 배치되는지 확인합니다.
  • Agent 재시작 뒤 작업이 다른 풀로 잘못 이동하지 않는지 확인합니다.
  • 빌드 취소 뒤 임시 파일과 인증 정보가 남지 않는지 확인합니다.

노드 성능, 재시작 시간, 복구 성공 여부는 TeamCity 문서에서 가져올 수 없습니다. 조직의 실제 Mac, 네트워크, Xcode 프로젝트로 측정해야 합니다. 공개된 호환성 설명만으로 생산 맥의 격리 결과를 단정하지 마십시오.

06

감사팀의 중단 능력

운영 승인에는 정상 동작보다 실패 시 멈출 수 있는지가 더 중요합니다. 감사 및 운영 담당자는 다음 중단 훈련을 수행해야 합니다.

  • 전용 토큰을 폐기하고 새 요청이 거부되는지 확인합니다.
  • OAuth 세션을 종료하고 기존 세션의 재사용을 차단합니다.
  • Brave Mode를 끈 뒤 변경 도구가 제한되는지 확인합니다.
  • 반복 빌드를 취소하고 대기 작업이 다시 실행되지 않는지 확인합니다.
  • 잘못된 파이프라인 변경을 이전 버전으로 되돌립니다.
  • TeamCity 제어면 장애 때 수동 승인과 기존 빌드 흐름으로 전환합니다.
  • 맥 노드 장애 때 서명 작업을 다른 승인된 경로로 보내지 않고 보류합니다.

고빈도 REST 요청, 중복 빌드, 구성 오변경, 삭제 요청은 감사 로그만으로 놓칠 수 있습니다. 요청량, 사용자, 프로젝트, 결과, 취소 여부를 함께 모니터링해야 합니다. 복구가 끝난 뒤에는 권한과 파이프라인이 원래 상태인지 다시 대조하십시오. 업그레이드 뒤 MCP 권한이나 동작이 바뀌었는지도 TeamCity 업그레이드 안내에서 재확인해야 합니다.

07

경영진의 방출 결정

기술 책임자는 검수 결과를 세 가지 결론으로 정리하면 됩니다.

  • 통과: 읽기 진단, 제한된 빌드 실행, 테스트 프로젝트 변경, Mac 풀 격리와 중단 훈련을 모두 확인한 경우
  • 제한 운영: 읽기와 수동 승인 빌드만 허용하고 변경 및 삭제는 차단한 경우
  • 보류: 프로젝트 범위, 토큰 폐기, 감사 추적, 서명 노드 라우팅 중 하나라도 증거가 없는 경우

통과 이후에도 모든 프로젝트를 한 번에 열 필요는 없습니다. 먼저 실패 영향이 낮은 팀과 테스트 저장소에서 작업량을 관찰하십시오. 빌드 대기 증가, Agent Pool 부족, 서명 작업 집중이 확인되면 MCP 권한을 넓히기보다 노드 용량과 라우팅을 먼저 조정해야 합니다. 맥 미니 렌탈을 검토한다면 서울 원격 맥 구성처럼 실제 사용 지역과 연결 조건을 비교한 뒤 테스트 풀부터 구성하십시오.

08

FAQ

TeamCity MCP의 파이프라인 권한

TeamCity 2026.2 MCP가 파이프라인 생성, 수정, 삭제 도구를 제공한다는 점은 공식 출시 기록에 나와 있습니다. 하지만 실제 실행 권한은 MCP 사용자의 TeamCity 역할과 프로젝트 권한에 종속됩니다. 따라서 기본적으로 허용된다고 가정하지 말고, 읽기와 변경을 분리한 테스트 계정으로 각각 확인해야 합니다.

지정 프로젝트만 노출하는 권한 설정

특정 프로젝트만 보이게 하려면 전용 계정과 제한 토큰을 사용하고 부모 프로젝트의 상속 권한을 함께 확인해야 합니다. 금지된 프로젝트의 목록, 로그, 빌드 결과를 실제 요청으로 시험하십시오. 권한 화면에서 차단된 것처럼 보여도 상속이나 공유 역할 때문에 범위가 넓어질 수 있습니다.

Brave Mode의 기업 운영 범위

Brave Mode는 장시간 운영의 기본 설정으로 삼기보다 격리 프로젝트에서 제한적으로 평가하는 편이 안전합니다. 담당자와 시간대를 정하고, 변경 전후 차이, 승인 기록, 취소, 복구 결과를 남기십시오. 이 증거가 없으면 운영 배포선에 적용하지 않는 결론이 합리적입니다.

iOS 서명 맥의 분리 방식

AI Agent가 실행하는 일반 진단과 비신뢰 코드 검증은 서명 노드와 다른 Agent Pool로 보내야 합니다. 공식 서명은 검토된 고정 파이프라인만 접근하도록 구성하고, MCP 사용자에게 SSH, VNC, 로컬 계정, Keychain 권한을 부여하지 마십시오. 실제 Xcode 프로젝트로 인증 정보의 흐름과 작업 라우팅을 검증해야 합니다.

09

현재 환경과 원격 맥의 선택

현재 사내 물리 맥만 사용하는 방식은 장비 구매와 교체 주기를 직접 부담해야 하고, 원격 근무 팀마다 환경을 맞추기 어렵습니다. 클라우드 가상 환경은 macOS 기능, Xcode 서명, 네트워크 정책이 실제 장비와 다를 수 있습니다. 공용 Mac 한 대에 모든 TeamCity 작업을 몰아넣으면 권한 경계와 장애 영향도 함께 커집니다.

반대로 VpsMesh의 원격 맥은 먼저 격리된 Agent Pool의 하위 노드로 시험할 수 있습니다. 실제 Xcode 프로젝트, 노드 재시작, 작업 라우팅을 확인한 뒤 장기 빌드 풀이나 전용 서명 노드로 확대하는 방식이 적합합니다. 장기 고정 부하나 물리 USB 장치가 반드시 필요한 조직에는 직접 구매가 더 맞을 수 있습니다. 임시 CI 용량이나 검수 환경이 필요한 경우에는 VpsMesh 원격 맥 서비스를 기준으로 테스트 범위와 접근 정책을 먼저 협의하십시오.