OpenShip MCP 배포, 수동 배포와 선택 기준

핵심 요약

OpenShip MCP 배포는 개발 환경과 미리 보기 환경에서 먼저 자동화하고, 운영 환경에서는 사람이 승인하는 방식이 가장 안전합니다.
AI Agent에는 상태 조회, 로그 확인, 배포 계획 작성과 제한된 실행만 맡기고, 비밀값 변경·데이터 이전·운영 배포·되돌리기 확인은 사람에게 남겨야 합니다.
이 글은 세 부류의 팀을 위한 내용입니다.
미리 보기 환경을 AI Agent로 자동 배포하려는 개인 개발자, 팀 단위의 배포 기록과 승인 절차가 필요한 소규모 개발팀, 운영 환경의 배포 권한을 어디까지 열지 판단하는 기술 책임자가 대상입니다.
마지막 업데이트: 2026년 8월 1일.

OpenShip MCP 배포는 개발 환경과 미리 보기 환경에서 먼저 자동화하고, 운영 환경에서는 사람이 승인하는 방식이 가장 안전합니다. AI Agent에는 상태 조회, 로그 확인, 배포 계획 작성과 제한된 실행만 맡기고, 비밀값 변경·데이터 이전·운영 배포·되돌리기 확인은 사람에게 남겨야 합니다.

이 글은 세 부류의 팀을 위한 내용입니다. 미리 보기 환경을 AI Agent로 자동 배포하려는 개인 개발자, 팀 단위의 배포 기록과 승인 절차가 필요한 소규모 개발팀, 운영 환경의 배포 권한을 어디까지 열지 판단하는 기술 책임자가 대상입니다.

마지막 업데이트: 2026년 8월 1일. OpenShip MCP 문서와 공식 저장소, MCP 권한 문서를 기준으로 내용을 확인했습니다. 공식 문서에 없는 승인 기능이나 보안 보장은 추정하지 않았습니다. OpenShip MCP 공식 문서

OpenShip MCP 배포가 맡을 수 있는 작업

OpenShip 공식 문서는 MCP를 통해 AI Agent가 배포, 프로젝트와 인프라를 다룰 수 있다고 설명합니다. 다만 실제로 보이는 도구는 고정된 전체 목록이 아닙니다. 연결된 OAuth 승인 범위나 개인 접근 토큰의 권한에 따라 달라집니다. 문서상 MCP 접점은 POST /api/mcp이며, 도구 목록은 tools/list 요청으로 확인할 수 있습니다.

따라서 “MCP를 연결하면 AI Agent가 모든 배포를 실행한다”라고 이해하면 안 됩니다. 먼저 다음처럼 작업을 나누는 편이 좋습니다.

읽기 작업: 배포 상태, 프로젝트 정보, 실행 로그 확인
계획 작업: 새 배포에 필요한 브랜치, 대상 환경, 변경 내용을 정리
제한 실행: 미리 보기 생성, 이미 정해진 프로젝트에 대한 재배포
사람 승인 작업: 운영 배포, 비밀값 교체, 도메인 변경, 데이터 이전
사후 확인 작업: 상태와 로그를 읽고 건강 상태를 보고

OpenShip 문서에는 OAuth와 개인 접근 토큰이라는 두 가지 인증 방식이 설명되어 있습니다. 읽기 전용 토큰과 프로젝트·서버·저장소 범위를 좁힌 토큰도 사용할 수 있습니다. 각 도구 호출마다 권한 검사가 다시 적용된다는 점은 유용하지만, 이것만으로 운영 승인 절차가 생기는 것은 아닙니다.

미리 보기 환경과 공유 테스트 환경

개인 개발자의 미리 보기

개인 프로젝트의 미리 보기에서는 MCP의 장점이 분명합니다. AI Agent가 코드 변경을 확인하고 배포를 실행한 뒤 로그를 읽어 실패 원인을 요약할 수 있습니다. 수동 CLI 방식보다 대화 흐름이 짧고, 명령어를 복사하는 과정에서 생기는 오타도 줄어듭니다.

다만 대상 프로젝트와 자원 범위는 처음부터 제한해야 합니다. 개인 토큰 전체 권한을 연결하면 테스트용 Agent가 다른 프로젝트나 서버를 볼 수 있습니다. 미리 보기 자동화의 기본 범위는 다음 정도가 적절합니다.

특정 저장소와 특정 프로젝트만 허용
읽기 권한을 기본값으로 설정
미리 보기 배포만 실행 가능하게 구성
운영 서버와 운영 도메인은 토큰 범위에서 제외
실패한 배포와 생성된 자원은 담당자가 정리

OpenShip은 CLI, 웹 화면, 데스크톱 화면과 MCP를 같은 배포 흐름에 연결합니다. CLI는 명령을 직접 통제하기 쉽고, MCP는 자연어 요청과 로그 해석을 한 흐름으로 묶기 쉽습니다. 공식 CLI와 배포 방식 안내와 공식 저장소의 소개 문서를 함께 확인하면 현재 제공되는 조작 경로를 구분하기 좋습니다.

공유 테스트 환경의 팀 협업

여러 명이 하나의 테스트 환경을 함께 쓰면 속도보다 추적성이 중요해집니다. Agent가 하나의 공유 토큰으로 모든 배포를 실행하면 누가 어떤 요청을 했는지 팀 내부 기록과 실제 권한 기록이 어긋날 수 있습니다. 반대로 구성원마다 CLI를 따로 사용하면 실행 주체는 분명하지만, 명령 결과와 배포 이유가 여러 터미널에 흩어집니다.

팀 환경에서는 다음 네 가지를 분리해야 합니다.

사용자별 인증 또는 팀별 책임자 인증
배포 대상 프로젝트와 서버의 범위
동시에 실행할 수 있는 배포 수
변경 전후의 알림과 기록 보존

충돌 배포는 먼저 실행 중인 배포의 대상과 커밋을 확인해야 합니다. 새 요청이 같은 환경을 덮어쓰려 하면 Agent는 즉시 실행하지 말고, 기존 배포가 끝났는지와 새 변경이 이전 변경을 포함하는지 보고해야 합니다. 잘못된 배포가 이미 시작되었다면 마지막 정상 버전과 현재 실행 상태를 사람이 확인한 뒤 되돌리기를 결정합니다.

운영 방식	AI Agent 역할	사람 역할	권한 기본값
개인 미리 보기	생성, 로그 확인, 반복 배포	자원 정리	좁은 프로젝트 범위
공유 테스트	상태 확인, 계획 작성, 제한 실행	충돌 승인, 변경 공지	읽기 중심
운영 환경	계획과 상태 보고	실행 승인, 비밀값 변경	운영 실행 제외

OpenShip MCP와 CLI 배포의 차이

MCP와 CLI는 서로 완전히 다른 배포 엔진이라기보다, 같은 배포 기능을 호출하는 조작 방식이 다릅니다. OpenShip 공식 문서도 CLI, 웹 화면, 데스크톱 화면, MCP를 배포를 다루는 경로로 설명합니다.

비교 항목	MCP	CLI
입력 방식	자연어와 도구 호출	명령어와 스크립트
피드백	상태 해석과 요약에 유리	원문 로그와 종료 코드 확인에 유리
권한 통제	토큰 범위와 승인 범위에 의존	실행 계정과 셸 권한에 의존
반복 작업	Agent가 조건을 읽고 이어가기 쉬움	고정 스크립트 재현성이 높음
장애 대응	원인 분석과 다음 조치 제안에 유리	Agent가 없어도 직접 실행 가능
운영 적합성	제한된 단계에 적합	승인 뒤 사람이 직접 실행하기 쉬움

CLI의 가장 큰 장점은 AI Agent가 중단되어도 배포 경로가 남는다는 점입니다. 반대로 MCP는 로그를 읽고 관련 작업을 연결하는 데 유리하지만, 모델이 잘못된 대상을 선택하거나 변경 의도를 오해할 가능성을 별도로 관리해야 합니다.

실무에서는 MCP와 CLI 중 하나만 고르기보다 역할을 나누는 편이 낫습니다. Agent는 계획과 진단을 담당하고, 승인된 실행 명령은 사람이 CLI나 통제된 작업 노드에서 실행하도록 구성할 수 있습니다.

운영 환경의 승인 경계

운영 환경을 AI Agent에 바로 맡겨도 되는가

운영 환경의 직접 배포는 기본값으로 열지 않는 편이 좋습니다. 특히 다음 네 가지 작업은 배포 성공 여부만으로 안전성을 판단할 수 없습니다.

비밀값과 접근 토큰 변경
데이터베이스 구조 변경과 데이터 이전
운영 도메인과 외부 연결 설정 변경
되돌리기 뒤 실제 서비스 상태 확인

OpenShip MCP 공식 문서는 권한 범위를 좁힐 수 있다고 설명하지만, 문서에서 모든 운영 배포에 별도의 사람 승인 단계가 자동으로 적용된다고 확인되지는 않습니다. 그러므로 승인 절차는 팀의 운영 규칙으로 추가해야 합니다. MCP의 권한 모델은 안전한 출발점이지만, 승인 체계와 변경 관리의 대체재는 아닙니다.

권장 흐름은 네 단계입니다.

AI Agent가 변경 내용과 대상 환경을 읽습니다.
AI Agent가 실행 계획과 예상 영향 범위를 작성합니다.
담당자가 계획, 변경 파일, 비밀값 변경 여부를 확인합니다.
제한된 권한으로 실행하고 사람이 건강 상태를 확인합니다.

MCP 표준의 권한 문서도 보호된 서버에 토큰을 사용하고, 잘못된 인증에는 401, 권한 부족에는 403 응답을 사용할 수 있도록 정의합니다. 그러나 표준 인증은 “누가 호출할 수 있는가”를 다루며, “누가 운영 배포를 최종 승인하는가”까지 대신 결정하지는 않습니다. MCP 공식 인증 규격

권한 등급	허용 작업	승인 필요
읽기	상태, 로그, 프로젝트 정보 조회	상황에 따라 없음
계획	변경 내용 분석, 배포 계획 생성	실행 전 필요
제한 실행	미리 보기와 지정 테스트 환경 배포	팀 규칙에 따라 승인
민감 작업	비밀값, 도메인, 데이터 이전	항상 사람 승인
운영 실행	운영 배포와 트래픽 전환	사람 승인과 확인

장애 진단과 되돌리기 책임

AI Agent가 로그를 읽고 오류 원인을 묶어 주는 것은 적합합니다. 예를 들어 빌드 실패, 환경 변수 누락, 연결 실패처럼 로그에 단서가 있는 문제는 Agent가 빠르게 분류할 수 있습니다. 하지만 수정안을 바로 적용할지는 오류의 영향 범위에 따라 달라집니다.

자동 실행을 허용해도 되는 조건은 제한적입니다.

변경 대상이 미리 보기 또는 테스트 환경일 것
데이터 손실 가능성이 없을 것
되돌릴 버전이 확인되어 있을 것
실패 시 사람이 접근할 CLI 또는 웹 화면이 남아 있을 것

되돌리기 책임은 Agent가 아니라 승인된 담당자에게 남겨야 합니다. Agent는 정상 버전을 제안하고 되돌리기 명령을 준비할 수 있지만, 성공 판정은 실제 건강 확인으로 끝내야 합니다. OpenShip은 이전 버전으로 되돌리는 기능을 안내하지만, 서비스별 건강 확인 항목까지 자동으로 보장한다고 해석해서는 안 됩니다. OpenShip 공식 서비스 안내

되돌리기 절차는 다음처럼 고정합니다.

장애 시작 시각과 마지막 정상 버전을 기록합니다.
로그와 상태 화면에서 현재 배포가 끝났는지 확인합니다.
담당자가 되돌리기 대상을 승인합니다.
이전 버전으로 되돌립니다.
웹 요청, 핵심 기능, 데이터 연결을 직접 확인합니다.
원인 분석이 끝날 때까지 같은 변경의 재배포를 막습니다.

지속 실행 노드와 원격 팀

개발자의 노트북을 계속 켜 두는 방식은 개인 실험에는 가능하지만, 팀 운영의 제어면으로는 불안정합니다. 노트북이 잠자기 상태가 되거나 네트워크가 끊기면 AI Agent의 작업도 중단될 수 있습니다. 원격 팀이 지속적인 자동화를 원한다면 별도의 통제된 실행 노드를 두는 편이 낫습니다.

실행 노드에는 최소한 다음 조건이 필요합니다.

사용자와 Agent의 접근 권한 분리
인증 정보의 저장 위치와 사용 범위 분리
명령, 결과, 실패 기록의 보존
실행 노드 설정과 인증 정보의 백업
Agent 중단 시 사람이 접속할 수 있는 CLI 또는 웹 화면

관리 화면을 인터넷에 그대로 공개하는 것은 원격 협업의 해결책이 아닙니다. 접근 제어, 네트워크 제한, 인증 정보 격리와 긴급 접속 절차를 별도로 설계해야 합니다. MCP의 HTTP 인증 흐름에서도 토큰 보호와 권한 범위 검증이 핵심으로 다뤄지며, PKCE 사용과 안전한 토큰 보관이 권장됩니다.

배포 전 결정 체크리스트

아래 항목을 모두 확인한 뒤 MCP 실행 권한을 열어야 합니다.

[ ] 대상이 미리 보기, 테스트, 운영 중 어디인지 구분했습니다.
[ ] Agent 토큰에서 사용하지 않는 프로젝트와 서버를 제외했습니다.
[ ] 읽기 권한과 실행 권한을 분리했습니다.
[ ] 운영 배포 전에 사람의 승인 단계를 정했습니다.
[ ] 비밀값 변경과 데이터 이전을 자동 실행 범위에서 제외했습니다.
[ ] 마지막 정상 버전과 되돌리기 담당자를 정했습니다.
[ ] Agent가 중단되어도 사용할 CLI 또는 웹 화면을 남겼습니다.
[ ] 되돌리기 후 확인할 건강 검사 항목을 문서화했습니다.
[ ] 공유 테스트 환경의 충돌 배포 처리 순서를 팀에 알렸습니다.
[ ] 원격 실행 노드의 접근 기록과 인증 정보 백업 방식을 확인했습니다.

최종 조합은 다음이 기본값입니다.

환경	권장 방식	이유
개발	MCP 자동화	반복 작업과 피드백 속도가 중요함
미리 보기	제한된 MCP 실행	자동화 이득이 크고 영향 범위가 좁음
공유 테스트	계획 후 제한 실행	충돌과 책임 소재를 관리해야 함
운영	사람 승인 후 실행	데이터와 외부 서비스 영향이 큼
긴급 장애	사람 주도 CLI 또는 화면	Agent 장애와 무관한 접속 경로가 필요함

현재 사용 중인 방식이 개인 컴퓨터나 한 사람의 CLI에 의존한다면, 접속이 끊길 때 배포가 중단되고, 인증 정보가 여러 장비에 흩어지며, 팀원이 같은 환경을 동시에 조작하기 어렵다는 문제가 생깁니다. 장기 운영에서 이런 구조는 장애 때 책임 소재와 복구 순서를 더 복잡하게 만듭니다. 지속 온라인 환경이 필요하다면 개인 장비 대신 접근 제어와 인수인계 절차를 갖춘 원격 실행 노드를 검토하는 편이 낫습니다.

kvmboot의 도움말 센터에서 원격 실행 환경과 권한 분리 조건을 먼저 확인한 뒤, 팀의 배포 정책에 맞는 맥 미니 렌탈 환경을 검토할 수 있습니다. 운영 제어면을 개인 노트북에 두지 않고, 필요한 기간에만 kvmboot 원격 맥 환경을 사용하는 방식이 임시 테스트와 지속 온라인 작업을 분리하는 데 더 적합합니다.