MCP 연결 전 권한과 로그를 먼저 설계하는 법

MCP를 도입한다는 말은 대개 AI에게 사내 문서, 일정, 고객 티켓, 데이터베이스를 보여 주겠다는 뜻으로 시작합니다. 화면에서는 서버 주소 하나를 추가하는 일처럼 보이지만, 운영에서 중요한 질문은 그 다음입니다. 모델이 어떤 정보를 읽을 수 있고, 어디까지 실행할 수 있으며, 문제가 생기면 누가 무엇을 되돌릴 수 있을까요?

Model Context Protocol은 AI 애플리케이션과 외부 도구·데이터를 연결하기 위한 프로토콜입니다. 2026-07-28 기본 명세는 메시지와 기능을 스키마로 정의하고, HTTP 연결에는 별도 인증 체계를 둡니다. 즉 MCP는 연결을 쉽게 만드는 규격이지, 권한 설계나 운영 책임을 대신 정해 주는 제품은 아닙니다.

처음 연결하는 운영자라면 서버 수를 빨리 늘리기보다 한 가지 실제 업무를 안전하게 끝내는 흐름을 먼저 만들어 보는 편이 좋습니다. 이 글에서는 문서 검색이나 티켓 조회처럼 결과를 되돌릴 필요가 적은 작업에서 출발해, 쓰기 작업으로 넓혀 갈 때 확인할 기준을 정리합니다.

먼저 업무 경계를 한 문장으로 적는다

서버 이름이 아니라 사용자가 얻을 결과를 먼저 적어야 합니다. 예를 들어 '고객 티켓을 처리한다'는 너무 넓습니다. '최근 7일간 열린 티켓을 조건별로 찾아 요약한다'처럼 읽기만 하는 결과로 좁히면 필요한 데이터와 권한을 검토하기 쉬워집니다.

이 문장이 없으면 도구 목록이 계속 커집니다. 검색을 위해 붙인 서버에 수정 기능도 넣고, 편의를 위해 관리자 권한 토큰도 공유하는 식입니다. 나중에 사고가 났을 때 어떤 기능이 정말 필요했는지 판단하기도 어려워집니다.

처음 연결할 작업은 아래 조건을 만족하는 것이 좋습니다.

• 결과가 잘못되어도 원본 데이터가 바뀌지 않는 조회 작업입니다.
• 테스트에 쓸 계정이나 샘플 데이터가 준비되어 있습니다.
• 사람이 결과를 한 번 읽고 맞는지 판단할 수 있습니다.
• 실패했을 때 연결을 끄는 방법이 문서화되어 있습니다.

읽기 권한과 실행 권한을 같은 토큰에 넣지 않는다

MCP 서버가 외부 시스템을 호출하면 서버가 가진 자격 증명의 범위 안에서 일이 진행됩니다. 그래서 처음부터 편한 관리자 토큰 하나를 모든 도구에 전달하는 방식은 피해야 합니다. 조회용 토큰과 변경용 토큰을 분리하고, 변경 권한은 실제로 필요한 서버와 작업에만 부여하는 편이 낫습니다.

HTTP 기반 MCP 인증을 쓴다면 현재 명세는 OAuth 기반 발견과 토큰 검증을 다룹니다. 토큰을 URL에 넣지 않고 요청 헤더로 보내며, 서버는 자신을 대상으로 발급된 토큰인지 확인해야 합니다. 이 요구는 특정 구현체의 옵션이 아니라, 다른 서비스용 토큰이 실수로 재사용되는 위험을 줄이기 위한 경계입니다.

권한을 나눌 때는 역할 이름보다 동작을 기준으로 확인하세요. '편집자' 권한이 있더라도 실제로 티켓 댓글 작성, 상태 변경, 파일 내려받기 중 무엇을 할 수 있는지 목록으로 확인해야 합니다. 한 도구가 여러 동작을 제공한다면 읽기와 쓰기를 별도 도구로 쪼개는 선택도 검토할 수 있습니다.

입력 스키마는 모델의 추측 범위를 줄이는 장치다

명세는 프로토콜 메시지와 구조를 스키마로 표현합니다. 운영자가 도구 입력을 느슨한 문자열 하나로 받으면, 모델은 날짜 형식·대상 ID·필수 조건을 문맥으로 추측해야 합니다. 반대로 필요한 필드와 허용 값을 좁히면 잘못된 호출을 실행 전에 걸러낼 수 있습니다.

예를 들어 티켓 조회 도구라면 요청자의 자연어를 그대로 넘기지 말고, 시작일·종료일·상태·최대 건수처럼 검증 가능한 필드를 둡니다. 상태는 허용 목록에서만 받고, 최대 건수에는 상한을 두며, 날짜가 뒤집혔을 때는 명확한 오류를 반환합니다. 변경 도구라면 대상의 현재 상태와 바꿀 값을 모두 다시 보여 주도록 설계하는 것이 좋습니다.

도구를 공개하기 전에는 적어도 다음 입력을 직접 실행해 보세요.

• 정상적인 값 한 건과 결과 형식이 약속대로 맞는지 확인합니다.
• 필수 값이 비어 있을 때 실행 대신 이해할 수 있는 오류가 나오는지 확인합니다.
• 너무 큰 건수, 잘못된 날짜, 존재하지 않는 ID가 시스템을 과도하게 조회하지 않는지 확인합니다.
• 쓰기 요청은 승인 전에는 변경이 일어나지 않는지 확인합니다.

승인 지점은 호출 전과 결과 확인 후에 나눈다

사람 승인 단추를 하나 넣는다고 안전해지지는 않습니다. 승인 화면에 무엇이 표시되는지가 더 중요합니다. 사용자는 어떤 시스템에, 어떤 대상에, 어떤 변경을 할지 읽을 수 있어야 합니다. '작업을 실행할까요?'만 보여 주면 자동화의 추측을 사람이 그대로 승인하게 됩니다.

변경 작업에는 최소한 대상 식별자, 변경 전 값, 변경 후 값, 영향 범위, 실행 주체를 함께 보여 주세요. 대량 작업이라면 처음 한 건만 시험 실행해 결과를 확인한 뒤 나머지를 진행하는 방식이 안전합니다. 되돌릴 수 없는 삭제나 외부 발송은 더 강한 별도 확인과 실행 제한이 필요합니다.

승인 뒤에도 검증은 남습니다. API가 200을 돌려줬다고 원하는 상태가 저장됐다는 뜻은 아닙니다. 변경 후 다시 조회해 대상 상태를 확인하고, 그 결과를 작업 기록에 남겨야 합니다. 이 재조회 단계가 있어야 권한 부족, 비동기 처리 지연, 일부 실패를 발견할 수 있습니다.

로그는 디버깅용이면서 동시에 안전장치다

문제가 생긴 뒤에 'AI가 그렇게 했다'는 설명만으로는 원인을 찾을 수 없습니다. 어느 사용자의 어떤 요청이 어느 도구 호출로 바뀌었는지, 입력 검증은 통과했는지, 외부 시스템 응답은 무엇이었는지 연결해 볼 수 있어야 합니다.

로그에는 요청 시간, 서버와 도구 이름, 대상 식별자, 승인 여부, 결과 코드, 재시도 횟수, 변경 후 확인 결과를 남기면 좋습니다. 반면 접근 토큰, 비밀번호, 원문 민감정보를 그대로 기록하면 로그 자체가 새로운 유출 지점이 됩니다. 비밀값은 마스킹하고, 필요한 경우에도 최소한의 식별 정보만 남기세요.

운영 알림도 실패 횟수만 세면 부족합니다. 같은 대상에 반복 호출되는지, 승인 없이 쓰기 호출이 시도되는지, 응답 시간이 평소보다 길어지는지를 함께 보면 일찍 멈출 근거가 생깁니다. 연속 실패 시 자동 실행을 중지하고 담당자에게 넘기는 규칙은 작은 서버에도 필요합니다.

복구 절차는 배포 전에 시험한다

실패를 가정하면 설계가 달라집니다. 서버가 응답하지 않을 때 재시도 횟수와 시간 제한은 얼마인지, 외부 API가 부분 성공을 반환하면 어느 항목을 다시 확인할지, 잘못된 변경을 어떤 권한으로 되돌릴지 정해야 합니다. 단순히 '재시도한다'고 적는 것만으로는 부족합니다.

처음에는 복구가 쉬운 조회 업무로 시작하고, 쓰기 기능은 한 건 단위의 시험과 재조회가 통과된 뒤에만 열어 두세요. 오류가 반복되면 자동화를 잠시 꺼도 서비스의 원래 업무가 계속 가능한지 확인해야 합니다. MCP 연결을 해제하거나 토큰을 폐기하는 비상 절차와 담당자를 한 곳에 기록해 두면 사고 대응 시간이 크게 줄어듭니다.

첫 연결 전 점검표

아래 질문에 모두 답할 수 있다면 작은 범위의 MCP 연결을 시작할 준비가 된 것입니다.

1. 이 서버가 해결할 한 가지 업무와 읽기·쓰기 범위는 무엇인가요?
2. 최소 권한 토큰을 분리했고, 토큰을 로그나 URL에 남기지 않나요?
3. 입력값의 필수 항목과 허용 범위, 오류 응답을 테스트했나요?
4. 쓰기 작업 전에 변경 대상과 영향 범위를 사람이 확인하나요?
5. 실행 뒤 실제 상태를 다시 조회하고, 필요한 로그는 남기되 비밀값은 마스킹하나요?
6. 연속 실패, 부분 성공, 잘못된 변경이 생겼을 때 중지·복구·연락할 방법이 있나요?

MCP의 장점은 연결의 형식을 통일해 주는 데 있습니다. 그러나 신뢰는 서버를 몇 개 연결했는지가 아니라, 권한을 얼마나 좁혔는지와 실패했을 때 얼마나 빨리 멈추고 확인할 수 있는지에서 만들어집니다. 첫 서버는 작고 되돌릴 수 있게 시작한 뒤, 실제 로그와 사용자 확인 과정을 바탕으로 다음 권한을 열어 가는 편이 오래 갑니다.