MCP와 AI 시스템 연결

AI host가 calendar, issue tracker와 file system을 각각 독자적인 plugin으로 연결하면 같은 discovery, schema, permission과 error 처리를 제품마다 다시 구현하게 됩니다. MCP는 이 연결에서 교환하는 message와 capability 표현을 공통화해 host와 server 조합을 늘리기 쉽게 만듭니다. 하지만 실제 일정 규칙이나 issue 권한은 여전히 각 domain service가 소유합니다.

따라서 MCP 도입의 성공 기준은 connector 수가 줄었다는 것만이 아닙니다. Server revision이 바뀌어도 host가 capability를 협상하고, 허용되지 않은 resource는 보이지 않으며, tool 실패가 사용자에게 복구 가능한 상태로 전달되어야 합니다. 기존 REST API와 queue를 server 내부에서 계속 쓰는 구조도 정상이며 protocol 경계와 domain 경계를 구분해야 합니다.

한 desktop host가 local file server와 remote CRM server에 연결될 때 두 server는 서로 다른 신뢰 수준을 가집니다. Local process도 설치 package가 변조될 수 있고, remote server는 network와 token leakage 위험이 있습니다. Host는 server가 보낸 tool 설명을 그대로 정책으로 믿지 않고 사용자가 허용한 target과 action을 다시 대조해야 합니다.

Client는 단순 network socket 이상의 상태를 관리합니다. 초기화된 protocol version, 지원 capability, outstanding request와 취소 신호를 session에 묶어야 합니다. 연결이 끊긴 뒤 새 session을 만들 때 이전 요청이 실제로 실행됐는지 모를 수 있으므로 상태 변경 tool은 server가 발급한 operation identity로 결과를 재조회할 수 있어야 합니다.

사내 규정 문서는 resource로 제공해 host가 필요한 부분을 선택하도록 할 수 있고, “주간 보고서 작성” 형식은 사용자가 고르는 prompt가 될 수 있습니다. 실제 ticket 생성은 tool입니다. 세 가지를 구분하면 읽을 정보와 실행할 행동, 사용자가 명시적으로 시작하는 template을 서로 다른 동의와 UI로 표현할 수 있습니다.

이름만으로 분류하면 위험합니다. `previewInvoice`가 호출 시 view counter나 임시 row를 만든다면 side effect가 있는 tool로 취급해야 합니다. Resource URI도 현재 사용자의 tenant와 permission을 확인해야 하고 prompt 안의 지시는 신뢰할 수 없는 외부 text를 포함할 수 있습니다. 각 primitive의 data source와 실행 효과를 contract test로 확인해야 합니다.

오류는 transport가 끊긴 것인지, JSON message가 유효하지 않은지, tool input이 업무 규칙을 위반했는지에 따라 다음 행동이 달라집니다. 첫 경우에는 같은 session을 복구하거나 결과를 조회할 수 있고, 두 번째는 client와 server version을 확인해야 하며, 세 번째는 사용자가 입력을 고쳐야 합니다. 하나의 “실패” 문자열은 이 결정을 model의 추측에 맡깁니다.

특히 결제나 삭제처럼 상태를 바꾸는 요청은 timeout을 실패로 단정하면 안 됩니다. Server가 변경을 commit한 뒤 응답만 유실될 수 있기 때문입니다. Client가 만든 idempotency key를 같은 업무 operation에 재사용하고 status endpoint로 최종 결과를 확인하면 중복 실행 없이 불확실성을 해소할 수 있습니다.

Token은 사용자의 모든 권한을 복사한 만능 열쇠가 아니라 특정 audience와 scope, 만료 시간을 가진 위임 증거여야 합니다. MCP server가 받은 token을 다른 service에 그대로 전달하면 원래 의도하지 않은 resource에서도 사용할 수 있습니다. Server는 필요한 downstream용 token을 별도 교환하고 각 호출에서 subject와 resource 관계를 다시 확인해야 합니다.

감사 기록에는 prompt 전체를 무조건 저장하기보다 누가, 어떤 client와 tool revision으로, 어느 대상에, 어떤 승인과 policy 결과를 거쳐, 어떤 상태 변화를 만들었는지 남깁니다. 민감한 입력은 hash나 비식별 식별자로 연결하고 원문 접근은 별도 통제합니다. 이 구조가 있어야 사고 때 행위를 재구성하면서 개인정보 보존 범위도 제한할 수 있습니다.

가상의 재고 server는 조회 tool의 필수 인자를 productId에서 sku로 바꿨습니다. 연결과 목록 조회는 성공하지만 기존 client의 호출은 새 schema와 맞지 않습니다. 기존 client가 오래된 schema를 cache한 상태도 별도 조건으로 둡니다. Server의 목록만 최신이라고 해서 이미 시작한 실행이 새 계약을 알고 있다는 보장은 없습니다.

회귀 fixture는 이전 요청을 그대로 보내는 경우와 새 인자로 변환한 경우를 나눕니다. 변환이 필요하면 누가 어떤 규칙으로 ID를 매핑하는지 기록하고 단순 이름 치환으로 의미가 같다고 가정하지 않습니다. 상품 ID와 SKU가 일대일인지, variant별로 여러 값이 생기는지를 작은 표로 확인합니다. 변환이 불가능한 입력은 추측하지 않고 명시적 오류로 남겨 잘못된 상품 조회를 막습니다.

반환값에서 재고 수량이 빠졌을 때 빈 문자열이나 0으로 자동 대체하면 품절로 오판할 수 있습니다. 필수 field 누락을 contract failure로 보고 구매 결정 단계까지 전달하지 않습니다. 수량 0을 정상 반환하는 fixture도 함께 둡니다. 필드가 있는 0과 필드 자체의 부재를 구분해야 실제 품절과 계약 파손을 서로 다른 후속 행동으로 연결할 수 있습니다.

승인 기록에는 protocol revision, 발견한 tool schema, 변환기 version과 실제 fixture 결과를 함께 둡니다. Server 업데이트 뒤 이 묶음을 다시 실행해야 연결 여부만으로는 보이지 않는 파손을 찾습니다. 승인한 schema와 현재 발견한 schema가 다르면 재검토 이유를 남깁니다. 바뀐 항목이 선택적 추가인지 필수 의미 변경인지 대조해야 불필요한 전체 중단을 피할 수 있습니다.

교육용 fixture는 같은 사용자와 유효한 서명을 갖지만 다른 자원을 대상으로 한 token을 제공합니다. MCP server는 tool 실행 전에 이 token을 거절해야 하며 사용자 이름이 같다는 이유로 통과시키면 안 됩니다. 거절 뒤 원래 tool 함수가 호출되지 않았는지 확인합니다. 오류 status가 맞더라도 내부 조회를 먼저 수행했다면 접근 차단의 시점은 이미 늦었습니다.

다음 fixture는 올바른 자원용 token으로 다른 tenant의 주문 ID를 조회합니다. 첫 검사는 token 대상, 두 번째 검사는 업무 객체 소유권을 확인하므로 둘 중 하나만 통과해서는 조회 결과를 반환하지 않습니다. 두 fixture를 분리해야 audience 검사 하나로 모든 권한을 보장했다는 오판을 막습니다. 사용자, scope와 객체 소유권의 어느 값이 달라졌는지 증거에 표시합니다.

감사에는 거부 이유의 분류, 자원 식별자와 정책 revision을 남깁니다. 원본 token이나 주문 개인정보를 복사하지 않아도 어느 경계가 거절했는지 확인할 수 있게 합니다. 운영자가 재현할 수 있는 거부 코드와 익명 요청 ID를 사용합니다. 실패 원인 확인에 필요하지 않은 credential 본문을 남기면 진단 자료가 또 다른 인증정보 저장소가 됩니다.

이 절은 원격 authorization 경계를 다룹니다. 로컬 stdio 실행과 원격 HTTP 실행의 credential 전달 방식은 같다고 가정하지 말고 선택한 transport와 protocol revision의 문서를 별도로 확인합니다. 배포 문서에 실제 transport를 적어 다른 예제의 보안 가정을 자동으로 가져오지 않습니다. 연결 위치가 달라지면 신뢰 주체와 credential 수명 관리도 다시 점검합니다.

가상의 문서 tool 결과에 정상 문단과 외부 전송 지시를 함께 넣습니다. 통과 조건은 정상 문단의 답변 근거는 사용할 수 있지만 전송 지시가 새로운 tool 실행을 승인하지 않는 것입니다. 안전한 근거 문단을 사용할 때도 source ID를 답변에 연결합니다. 주입 지시를 거절했다는 사실만으로 남은 문단의 사실성과 최신성이 자동 검증되는 것은 아닙니다.

별도 fixture는 권한 거부를 반환하고 다른 fixture는 실제 검색 결과 0건을 반환합니다. 두 상태의 사용자 안내와 재시도 정책이 다르다는 것을 검사해야 오류를 숨기는 빈 배열 변환을 잡을 수 있습니다. 권한 거부에 자동으로 더 넓은 검색을 붙이지 않는지도 확인합니다. 접근할 수 없는 자료를 다른 tool로 찾으려는 행동은 같은 사용자 목표라도 별도 권한 검토가 필요합니다.

정상 응답의 필수 field를 제거해 host 검증에서 멈추는지도 봅니다. Model이 빠진 값을 자연스럽게 추측하면 오류를 읽기 좋은 문장으로 바꿨을 뿐 업무 계약은 복구되지 않았습니다. 정상 값을 담은 응답과 빈 문자열을 담은 응답을 함께 시험합니다. 속성 이름이 있다는 이유만으로 업무에 필요한 값이 채워졌다고 인정하지 않아야 형식 성공과 의미 실패를 구분합니다.

최종 trace는 요청한 tool, 검증된 결과 유형, 거부한 후속 행동과 사용자에게 전달한 상태를 연결합니다. 이 기록으로 연결 계층의 성공과 업무 판단의 실패를 동시에 설명할 수 있습니다. 정책 변경 뒤에는 이전 공격 fixture와 정상 문서 fixture를 같이 실행합니다. 거부율만 높아지고 정상 질문에 필요한 자료도 모두 막히면 도구 통합의 기능 조건은 충족되지 않습니다.