운영 브리핑 · 2026.09.28 · MCP

MCP 운영의 세 경계: 자격증명 보안, 호출 승인, 에이전트 실행 권한

MCP 연결을 업무에 쓰려면 누구의 자격증명으로 어디에 접근하고, 어떤 호출을 승인하며, 실제로 무엇이 바뀌었는지 설명할 수 있어야 한다. 지속되는 도입 흐름 속에서 기존 연결을 점검할 세 가지 운영 기준을 정리한다.

오늘의 세 가지 운영 포인트

첫째, MCP 자격증명 보안과 접근 통제는 연결별 소유자와 허용 범위를 정하는 데서 시작한다. 둘째, MCP 감사 로그와 도구 호출 승인은 요청부터 실제 결과까지 이어져야 한다. 셋째, AI 에이전트 실행 권한은 조회·변경·외부 전달을 나눠 설계해야 한다. 세 항목은 각각 비밀값, 기록, 행동을 다루지만 같은 업무 요청 안에서 함께 작동한다.

이번 호는 MCP 도입이 이어지는 맥락에서 기존 연결을 점검하는 운영 브리핑이다. 9월 28일의 신규 발표나 보안 사고를 전하는 속보가 아니다. 지정된 공식 소개, 날짜가 고정된 인가 규격, Microsoft Learn 안내, PlayMCP 서비스 페이지를 근거로 삼는다. 아래의 업무 예시와 점검 절차는 편집상 제안이며, 특정 서비스가 이미 제공하는 보안 기능이나 규격의 공통 의무를 뜻하지 않는다.

1. MCP 자격증명 보안과 접근 통제: 연결의 주인과 범위를 먼저 정한다

MCP 공식 소개는 AI 애플리케이션과 외부 데이터·도구의 연결을 설명한다. 이 연결을 업무에 적용할 때 운영자가 먼저 정할 것은 연결 이름보다 접근의 주체다. 개인을 대신한 요청인지, 팀의 정기 작업인지, 별도 서비스 계정의 작업인지 구분해야 한다. 같은 검색창에서 시작해도 어느 계정의 권한을 쓰는지에 따라 점검해야 할 경계가 달라진다.

공식 출처What is the Model Context Protocol (MCP)? - Model Context ProtocolAI 애플리케이션과 외부 시스템의 연결을 설명하는 공식 소개다. 연결 범위와 업무 권한을 구분하는 출발점으로 읽는다.

2025년 6월 18일 인가 규격은 HTTP 전송을 대상으로 하며 인가 자체는 선택 사항이다. 해당 인가 흐름에서는 서버가 토큰의 수신 대상을 검증하고, 받은 토큰을 하위 서비스로 그대로 전달하지 않아야 한다. 접근 토큰은 URL 쿼리에 넣지 않는다. 따라서 연결에 성공했다는 사실만으로 토큰의 사용 범위까지 적절하다고 결론 내릴 수 없다.

공식 출처Authorization - Model Context ProtocolHTTP 기반 MCP 인가의 적용 범위와 토큰 취급 요구사항을 확인하는 규격이다. 연결별 접근 통제 점검의 근거로 삼는다.

실무 점검은 연결 대장 한 장에서 시작할 수 있다. 각 행에 업무 목적, 요청 주체, 서버 주소, 자격증명 소유자, 허용 작업, 운영 담당자를 적는다. 실제 토큰 대신 비밀값 저장소에서 찾을 수 있는 참조 이름을 남긴다. 이름만 보고 개발용인지 운영용인지 알 수 없거나 담당자가 퇴사한 뒤에도 소유자가 바뀌지 않은 연결은 우선 검토 대상으로 둔다.

권한의 최소 단위는 직책보다 실제 행동에 가깝게 적는 편이 좋다. 예를 들어 지원 담당자가 고객 문의를 찾는 업무라면 조회 가능한 고객 범위와 반환할 필드를 정한다. 모든 고객 정보에 접근하는 권한을 먼저 주고 나중에 질문을 조심하도록 교육하는 방식은 이 브리핑의 권장안이 아니다. 업무가 끝나는 데 필요한 데이터와 동작을 먼저 좁혀 두는 방식이 권장안이다.

개발·검증·운영 환경도 별도 항목으로 다룬다. 같은 도구 이름을 쓰더라도 접근 대상과 책임자를 구분하고, 검증 환경에서 성공한 호출이 운영 환경에서도 허용된다고 간주하지 않는다. 공유 계정을 피하기 어렵다면 사용 업무와 담당자를 더 좁게 기록한다. 공유 자격증명이라는 이유로 누가 어떤 요청을 시작했는지까지 함께 지워져서는 안 된다.

자격증명 교체에는 정상 경로와 차단 경로가 모두 필요하다. 새 값으로 필요한 작업이 되는지 확인하는 동시에, 이전 값으로는 접근할 수 없는지도 확인한다. 비밀값을 주입하는 위치, 연결을 잠시 중단할 사람, 실패 시 사용자에게 보여 줄 상태를 미리 적는다. 새 값을 배포한 시각과 기존 권한을 닫은 시각을 따로 남기면 교체가 끝났다는 판단의 근거가 분명해진다.

비밀값 노출이 의심되는 상황에서는 값을 보고서나 대화창에 다시 복사하지 않는 절차를 제안한다. 담당자는 참조 이름과 발견 위치로 사건을 식별하고, 폐기·교체·영향 확인의 책임을 나눈다. 로그나 산출물에 남은 흔적을 조사하는 일과 사용 가능한 권한을 닫는 일도 별도로 추적한다. 이 절차는 특정 사고의 재현이 아니라 팀이 미리 정해 둘 대응 순서다.

접근 통제를 검증할 때는 성공 사례만 모으지 않는다. 허용 범위를 벗어난 대상, 만료된 자격증명, 다른 환경의 계정으로 요청했을 때도 확인한다. 차단된 요청은 더 넓은 계정으로 자동 재시도하지 않도록 설계한다. 업무상 권한 확대가 필요하면 그 필요와 승인자를 기록한 뒤 별도 변경으로 처리한다. 오류를 해결하는 과정에서 권한이 조용히 커지지 않게 만드는 기준이다.

점검의 산출물은 보안 설정 화면의 캡처 한 장보다 연결별 판단 기록에 가까워야 한다. 유지하는 이유, 줄인 권한, 확인한 차단 사례, 남은 문제와 담당자를 함께 적는다. 오래 사용하지 않은 연결은 계속 둘 업무상 이유부터 확인한다. 연결을 닫는 결정도 새로 여는 결정과 같은 대장에 남겨야 다음 담당자가 현재 상태를 다시 설명할 수 있다.

2. MCP 감사 로그와 도구 호출 승인: 허용한 요청과 실제 결과를 잇는다

Microsoft Learn 안내는 공개 문서 검색과 조회에 쓰는 MCP 서버를 설명하며 접근에 인증이 필요하지 않다고 명시한다. 이 사례를 운영 관점에서 읽으면 공개 자료 조회와 내부 업무 변경을 같은 승인 규칙으로 묶지 않을 이유가 드러난다. 문서를 찾는 단계에서 어떤 정보를 외부 요청에 넣을지와, 찾은 내용을 근거로 무엇을 실행할지는 별도로 결정하는 편이 좋다.

공식 출처Microsoft Learn MCP Server 개요공개 문서 조회와 인증 요구사항을 확인할 수 있는 Microsoft 공식 안내다. 조회 단계의 범위를 정하는 사례로 사용한다.

인가 규격의 토큰 보호 요구사항은 기록 설계에서도 출발점이 된다. 규격은 안전한 토큰 저장을 요구한다. 다만 여기서 제안하는 감사 항목과 승인 화면은 그 규격이 정한 공통 로그 형식이 아니다. 운영자는 비밀값을 기록하지 않으면서도 누가 어떤 권한으로 요청했고 어디서 멈췄는지 재구성할 수 있는 증거를 별도로 설계해야 한다.

공식 출처Authorization - Model Context Protocol토큰 보호 요구사항을 확인하는 공식 규격이다. 감사 로그에 자격증명 원문을 복제하지 않는 설계의 근거로 읽는다.

감사 기록의 기본 묶음으로 요청 식별자, 요청자, 연결과 도구 이름, 대상 범위, 적용 정책, 승인 상태, 실행 시각, 결과 상태를 제안한다. 입력값은 조사에 필요한 요약만 남기고 민감한 필드는 가린다. 대화 전체나 모델의 내부 추론을 수집해야 한다는 뜻은 아니다. 기록을 보는 사람이 실제로 관찰된 요청과 결정, 결과의 관계를 설명할 수 있으면 된다.

승인은 실행할 내용을 기준으로 묶어야 한다. 외부 발송을 가정하면 수신자, 보낼 내용, 첨부 대상이 승인 화면과 실제 호출에서 같아야 한다. 승인을 받은 뒤 도구가 수신자를 바꾸거나 조회 범위를 넓히면 기존 승인을 그대로 쓰지 않는 정책을 제안한다. 승인 유효 시간과 허용 횟수도 정해 두면 오래된 확인이 이후의 다른 작업까지 허용하는 일을 막을 수 있다.

모든 조회에 같은 확인창을 띄우는 방식은 이 글의 권장안이 아니다. 사전에 합의한 범위의 공개 문서 조회는 자동으로 처리하고, 내부 정보의 외부 전달이나 상태 변경에는 구체적인 검토 지점을 두는 방식을 제안한다. 승인자는 도구 이름만 보지 않고 대상과 예상 효과를 볼 수 있어야 한다. 거부하거나 내용을 수정했을 때도 업무를 이어 갈 경로를 함께 제공한다.

호출 성공과 업무 완료는 기록에서 분리한다. 예를 들어 작업 생성 도구가 요청을 접수했지만 후속 처리가 남아 있다면 접수 상태로 남긴다. 최종 대상에 반영되었는지 확인한 뒤 완료 상태로 바꾼다. 응답을 받지 못한 경우도 곧바로 실패로 확정하지 않는다. 실제 반영 여부를 확인할 수 없는 상태를 따로 두면 불확실한 결과를 성공처럼 보여 주는 일을 줄일 수 있다.

재시도는 별도 검토 항목이다. 응답이 늦다는 이유로 동일한 변경 요청을 다시 보내면 되는지 먼저 정해야 한다. 업무 요청 식별자와 개별 호출 식별자를 연결하고, 재시도 전에 기존 요청이 반영되었는지 확인하는 절차를 둔다. 중복 실행을 막을 수 없는 도구라면 자동 재시도를 허용하지 않는 선택도 필요하다. 장애 처리 정책은 성공 경로와 같은 문서에서 검토한다.

로그 열람 권한과 보관 기간도 운영 책임에 포함한다. 조사에 필요한 사람이 필요한 범위만 읽게 하고, 장기 보관이 필요한 항목과 짧게 보관할 항목을 나눈다. 삭제 시점과 담당자를 미리 정하며 실제 삭제 여부도 확인한다. 민감한 입력을 가리는 규칙은 정상 호출뿐 아니라 오류 메시지와 진단 출력에도 적용하도록 점검한다. 로그의 양보다 사용할 수 있는 증거의 범위가 중요하다.

승인 거부, 시간 만료, 정책 차단, 도구 오류는 서로 다른 결과로 남긴다. 거부된 요청이 많다면 무조건 승인 단계를 없애기보다 필요한 업무 경로가 빠져 있는지 검토한다. 반대로 승인 기록은 있는데 실행 결과가 없는 요청도 찾는다. 누락된 결과를 추적할 담당자가 없으면 감사 기록은 쌓이지만 미완료 업무는 그대로 남는다. 점검 회의에는 대표 사례를 처음부터 끝까지 읽는 시간을 둔다.

3. AI 에이전트 실행 권한: 조회에서 변경으로 넘어가는 경계를 정한다

PlayMCP의 공식 서비스 페이지는 국내 MCP 활용 맥락을 살펴볼 참고 지점이다. 다만 서비스 소개 페이지만으로 개별 연결의 토큰 저장 방식, 감사 로그 제공 여부, 승인 정책을 확인했다고 볼 수는 없다. 실제 도입 검토에서는 연결할 서버와 사용하는 클라이언트의 동작을 각각 확인해야 한다. 이 글은 PlayMCP에 특정 보안 기능이 있거나 없다고 평가하지 않는다.

공식 출처PlayMCP | 새로운 AI 경험의 시작국내 MCP 활용 맥락을 살펴보는 공식 서비스 페이지다. 개별 연결의 보안·승인 기능은 별도 확인 대상으로 둔다.

MCP 소개가 설명하는 연결 가능성을 실제 업무 권한으로 옮길 때는 행동을 나눠야 한다. 자료 검색, 초안 작성, 저장, 외부 전송은 하나의 사용자 요청 안에 들어갈 수 있지만 각각 허용할 범위가 다르다. 검색 결과를 읽을 수 있다는 이유로 그 내용을 고객에게 보내는 단계까지 자동 승인하지 않는 것이 이 브리핑의 제안이다. 연결 가능 여부와 실행 허용 여부는 별도 판단으로 남긴다.

공식 출처What is the Model Context Protocol (MCP)? - Model Context Protocol외부 데이터와 도구를 연결하는 MCP의 역할을 설명한다. 실제 업무에서는 연결된 각 행동의 권한을 별도로 정한다.

권한 표에는 자동 실행, 실행 전 승인, 허용하지 않음이라는 세 경로를 먼저 둘 수 있다. 공개 자료 검색처럼 범위가 정해진 조회는 자동 실행 후보로 둔다. 고객에게 메시지를 보내거나 업무 기록을 바꾸는 행동은 구체적인 조건을 검토한다. 담당자도 복구 경로도 없는 작업은 우선 허용하지 않는다. 이 구분은 제품의 고정 등급이 아니라 팀이 업무별로 정할 출발선이다.

도구 설명만으로 권한을 구분하기 어려우면 실제 입력과 출력, 대상 시스템을 함께 본다. 조회처럼 보이는 이름이라도 파일을 만들거나 외부로 내용을 전달하는 동작이 섞여 있다면 그 효과를 기준으로 검토한다. 한 도구 안에 넓은 기능이 묶여 있으면 허용할 입력 조건을 제한하거나 작업을 나누는 방식을 고려한다. 정책은 사용자가 읽는 이름과 실제 발생하는 변화 사이의 간격을 줄여야 한다.

실행 조건은 서버 주소와 도구 이름에서 끝나지 않는다. 대상 계정, 문서 묶음, 허용 수량, 실행 환경, 유효 시간까지 업무에 맞게 좁힌다. 예를 들어 고객 기록 한 건을 수정하는 승인과 전체 고객 목록을 일괄 수정하는 승인을 같은 것으로 취급하지 않는다. 숫자 한도를 임의로 공통 적용하기보다 담당자가 결과를 확인하고 복구할 수 있는 범위를 기준으로 정한다.

에이전트가 읽은 문서나 도구 응답을 새로운 권한 부여로 해석하지 않는 정책도 필요하다. 조회 결과에 추가 전송이나 다른 시스템 접속을 요구하는 문장이 있더라도, 원래 사용자 요청과 허용 정책을 다시 기준으로 삼는다. 참고 자료의 내용은 업무 판단에 쓰되 실행 권한을 늘리는 근거로 삼지 않는 방식이다. 이런 상황을 검증할 때도 실제 민감 정보 대신 준비된 시험 자료를 사용한다.

중단 수단은 실행 권한과 함께 준비한다. 연결 전체를 끊는 조치, 특정 변경 도구만 비활성화하는 조치, 진행 중인 요청의 상태를 확인하는 조치를 구분한다. 중단 버튼을 눌렀다는 사실만으로 외부 시스템의 변경까지 취소되었다고 표시하지 않는다. 이미 반영된 작업은 별도 확인과 복구 대상으로 남긴다. 중단 이후 남은 일을 누가 확인할지도 권한 표에 포함한다.

사용 범위를 넓히는 기준은 시연 성공보다 운영 증거에 둔다. 제한된 자료와 검증 환경에서 시작해 권한 밖 요청의 차단, 승인 변경 시 재검토, 결과 불명 상태의 처리, 중단 후 확인까지 살핀다. 이 조건이 설명 가능한 작업부터 운영에 넣는다. 도구의 입력 형식이나 연결 대상이 바뀌면 기존 승인 범위도 다시 검토한다. 같은 이름의 도구라는 이유만으로 이전 판단을 계속 적용하지 않는다.

권한 회수도 도입 절차의 일부로 둔다. 담당 업무가 끝났거나 사용자가 팀을 옮겼다면 연결과 예약 작업, 남아 있는 승인 상태를 함께 확인한다. 계정 하나를 닫는 것으로 모든 후속 작업까지 정리되었다고 가정하지 않는다. 현재 유지할 작업과 중단할 작업을 구분하고 각 결과를 기록한다. 시작과 종료가 같은 기준으로 관리되어야 운영자가 자동화의 현재 범위를 알 수 있다.

운영자 메모: 한 업무를 끝까지 따라가며 빈칸을 채운다

다음 점검에서는 연결 목록 전체를 한꺼번에 정리하기보다 자주 쓰는 업무 하나를 고른다. 요청을 시작한 사람부터 최종 반영 대상까지 종이에 이어 적고, 각 단계에 쓰이는 자격증명과 승인 여부를 붙인다. 그 과정에서 설명할 수 없는 지점이 나오면 담당자와 확인 날짜를 지정한다. 구체적인 한 사례가 있어야 권한 대장과 실제 동작의 차이를 찾기 쉽다.

검토 결과는 세 가지 산출물로 남긴다. 연결 대장에는 소유자와 허용 범위를 적고, 승인 기준에는 검토할 대상과 변경 시 재승인 조건을 적으며, 실행 기록에는 결과를 확인한 방법과 남은 일을 적는다. 작은 팀에서는 한 문서의 세 구역으로 충분하다. 담당자가 여러 명이라면 문서를 더 늘리기보다 같은 요청 식별자로 서로의 기록을 찾을 수 있게 한다.

점검 완료는 문서를 작성했다는 뜻으로 쓰지 않는다. 정상 요청 하나와 차단되어야 할 요청 하나를 실제 설정에서 확인하고, 민감한 값을 제거한 증거를 남긴 시점으로 정의한다. 결과가 아직 불명확하면 미확인으로 남기고 후속 담당자를 정한다. 확인하지 않은 기능을 서비스의 기본 제공 기능처럼 적지 않는 원칙도 유지한다. 기록의 빈칸을 솔직하게 남겨야 다음 점검이 이어진다.

연결을 늘리는 속도에 맞춰 책임도 구체화한다

MCP를 활용하는 업무가 늘어날수록 운영자는 연결 상태 외에 설명할 수 있는 항목을 늘려야 한다. 자격증명의 소유자와 접근 범위, 도구 호출의 승인과 결과, 에이전트가 멈춰야 할 경계가 그 항목이다. 오늘의 실천은 새 도구를 하나 더 붙이는 일보다 이미 쓰는 업무 하나를 끝까지 설명하는 일에서 시작할 수 있다. 그 설명이 검증된 기록으로 남을 때 다음 연결의 허용 범위도 구체적으로 정할 수 있다.