MCP 리소스 변경 알림 검수MCP resources updated 재조회MCP resources list_changed 차이MCP 구독 응답 인수

MCP 리소스 변경 알림 검수, 이전 본문이 답변에 남는 이유

MCP 리소스 변경 알림 뒤 이전 본문을 쓰는지 검수합니다. 자료 목록과 개별 URI의 갱신 범위, 재조회 실패와 구독 복구 때 답변에 쓸 근거를 가상 입력 9건으로 확인합니다.

이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스

발행 ·알파카랩스

2026년 11월 기준, MCP 리소스 변경 알림 뒤에는 해당 URI의 캐시를 무효화하고 다시 읽습니다. 재조회에 실패하면 최신 근거 확인을 보류합니다.

출고 승인 지침 파일을 개정했는데 에이전트가 어제 기준으로 답합니다. 운영 로그에 알림 도착만 남아 있다면 어느 판본을 모델에 넘겼는지부터 확인합니다. 가상 예시에서는 개정 전후의 URI를 유지하고 본문 판본만 바꿉니다.

알림이 오면 무엇을 다시 조회하나요?#

2026년 7월 MCP 리소스 명세는 목록 변경에 notifications/resources/list_changed를, 특정 자료의 변경에 notifications/resources/updated를 사용합니다. 전자는 다시 resources/list로 볼 범위를 알려줍니다. 후자는 변경된 URI를 알려주므로 선택 중인 자료라면 resources/read로 본문을 다시 읽습니다.

2026년 7월 MCP 캐시 명세에 따르면 관련 알림을 받으면 캐시 유효 시간이 남아도 해당 응답을 바로 오래된 사본으로 봅니다. 이때 실제 서버에 읽기 요청이 갔는지, 이후 모델에 어느 판본을 전달했는지 기록합니다. 답변이 개정된 지침을 따르는지와 인용한 본문이 같은지를 대조합니다. 명세는 재조회 오류 때 오래된 응답을 제공하는 선택을 허용합니다. 이 글의 출고 지침처럼 최신 근거가 필요한 업무에서는 새 읽기 결과를 확인할 때까지 답변을 보류하도록 정합니다.

같은 자료를 두고 어떤 입력을 검수할까요?#

다음 JSON은 가상 인수표의 한 행입니다. 요청 메시지, 실제 지침 내용, 표준 응답 스키마는 포함하지 않습니다. 표의 각 행은 선택 자료가 이전 판본인 상태에서 독립적으로 시작합니다.

{
  "자료": "guide://shipping/approval",
  "알림": "notifications/resources/updated",
  "갱신 전": "판본-v1",
  "재조회 성공": "판본-v2",
  "답변의 근거": "판본-v2",
  "재조회 실패": "최신 근거 확인 대기"
}
가상 입력앱에서 할 일답변에 쓸 자료의 기대 상태
선택 자료의 변경 알림만 도착해당 URI 캐시를 무효화하고 재조회최신 근거 확인 대기
같은 URI 재조회에서 새 판본 확인선택 자료 재조회판본-v2
알림 뒤 읽기 함수가 이전 로컬 사본만 반환캐시를 무효화하고 서버 읽기 확인최신 근거 확인 대기
알림 뒤 재조회가 시간 초과선택 자료 재조회최신 근거 확인 대기
알림 뒤 현재 사용자 접근 거절선택 자료 재조회현재 사용자에게 인용 금지
다른 자료 URI의 변경 알림알림의 다른 URI 확인선택 자료 유지
자료 목록 변경 알림목록 재조회선택 자료 상태 별도 확인
구독 연결이 끊겼다가 복구구독 복구와 선택 자료 재조회판본-v2
구독 수락 알림에 선택 URI가 없음조회 직전 직접 읽기판본-v2
2026년 11월 14일 가상 입력 9건으로 답변에 쓸 자료의 기대 상태를 대조했습니다. 앱에서 할 일은 운영 설계 예시입니다. 구독 복구와 직접 읽기의 성공 표본에는 판본-v2를 넣었습니다. 실제 MCP 서버나 에이전트의 답변 품질을 시험한 결과는 아닙니다.

구독이 끊기거나 일부만 승인되면 어떻게 하나요?#

2026년 7월 구독 명세에 따르면 서버는 subscriptions/listen의 첫 알림인 notifications/subscriptions/acknowledged의 params.notifications로 수락 범위를 알립니다. 클라이언트는 params.notifications.resourceSubscriptions에 보고 싶은 URI를 적고, 목록 변경이 필요하면 같은 필터의 resourcesListChanged도 요청합니다. 목록·개별 알림의 지원 여부는 각각 서버의 resources.listChanged, resources.subscribe 선언에서 확인하고, 요청한 필터와 첫 알림의 수락 범위를 대조합니다. 새 스트림이 생겼다는 사실만으로 끊긴 동안 본문이 그대로였다고 판단하지 않습니다.

구독을 복구했을 때 선택 자료도 다시 읽는 방식은 앱의 운영 선택입니다. 구독을 쓰기 어려운 환경이라면 최신 자료가 필요한 작업 직전에 직접 읽기로 합의할 수 있습니다. 목록에서 URI가 빠졌다면 현재 사용자 권한으로 해당 URI의 상태를 별도로 확인합니다. 원본이 없거나 본문 읽기가 거절됐다고 확인되면 이전 사본을 답변에 인용하지 않습니다.

2025년 11월 MCP 리소스 명세에서는 개별 자료 구독에 resources/subscribe를 사용합니다. 연동 중인 클라이언트와 서버가 사용하는 판본을 먼저 확인하세요. 처음 받은 URI로 본문을 읽어 모델에 넘기는 단계는 MCP 리소스 링크 검수에서 더 자세히 확인할 수 있습니다.

명세와 운영 기준은 어디에서 확인하나요?#

알파카랩스는 공개 업무 자동화 서비스에서 연동 범위와 예외 재처리, 운영 인수 조건을 협의한다고 안내합니다. 알림 수락 범위나 자료 판본을 고정하는 방식은 연동하는 서비스와 함께 결정합니다. 프로토콜 판본, 권한 또는 자료 저장 방식이 바뀌면 같은 가상 표본으로 다시 검수합니다. 업무 자동화·API 연동 안내

MCP 리소스 변경 알림 FAQ#

변경 알림을 받으면 바로 새 본문을 모델에 넣을 수 있나요?

변경 알림은 변경된 URI를 알려줍니다. 해당 URI의 이전 캐시를 무효화한 뒤 서버에서 다시 읽은 본문을 모델에 전달합니다. 최신 근거가 필요한 작업은 재조회 성공을 확인할 때까지 보류합니다.

목록 변경과 개별 자료 변경은 어떻게 구분하나요?

목록 변경은 사용할 수 있는 자료의 목록을 다시 확인할 신호입니다. 개별 자료 변경은 지정된 URI의 본문을 다시 확인할 신호입니다.

구독 응답에 내 URI가 없으면 어떻게 하나요?

그 URI의 변경 알림을 받을 수 있다고 가정하지 않습니다. 구독 조건을 다시 확인하고 최신 자료가 필요한 작업이라면 실행 직전에 직접 읽습니다.

연결이 복구되면 마지막 판본을 계속 써도 되나요?

연결이 끊긴 동안 변경됐을 수 있습니다. 최신 기준이 필요한 업무에서는 구독을 복구한 뒤 선택 자료도 다시 읽는 방식으로 검수합니다.

목록에 자료가 있어도 본문 읽기가 거절되면 어떻게 하나요?

현재 사용자의 읽기 권한과 오류 결과를 따릅니다. 보관한 이전 사본을 답변 근거로 넘기지 않고 자료 확인이 필요하다고 표시합니다.

비식별 판본으로 갱신 인수 범위를 정합니다#

검수할 자료의 이전·새 판본, 변경 알림, 재조회가 실패했을 때의 기대 상태를 비식별 표본으로 준비합니다.

자료 갱신의 인수 기준을 정리합니다

첫 범위 협의에서 비식별 자료 판본과 알림으로 갱신 인수표를 정리합니다. 소요 시간은 자료와 연동 범위를 확인한 뒤 협의합니다.

자료 갱신 인수표 초안 협의
자료 갱신 인수표 초안 협의