MCP 수정 제안으로 노션 공지 한 문단 다듬기

Business 계정이어도 연결 도구부터 봅니다

회사에서 허용한 외부 AI 앱에 Notion이 연결돼 있다면 제공 도구 목록을 먼저 살핍니다. 제안을 만드는 notion-create-suggested-edit와 변경안을 읽는 notion-get-suggested-edit가 있는지 확인하면 됩니다. 수락과 거절을 처리하는 세 번째 도구는 notion-resolve-suggested-edit입니다.

특히 관리자가 도구를 골라 제공하는 workspace-owned 연결은 구별해야 합니다. 10월 29일 확인한 공식 문서의 해당 연결 지원 목록에는 수정 제안 도구 3개가 빠져 있습니다. 유료 요금제를 쓴다는 이유만으로 같은 기능이 보이는 것은 아닙니다. 목록에 없다면 회사가 허용한 이용 범위를 담당자에게 묻고 채팅에서 교정안만 받는 방식으로 끝낼 수 있습니다.

페이지 권한도 따로 적용됩니다. 제안 생성에는 댓글 권한이 필요하고 수락에는 편집 권한이 필요합니다. 도구가 보여도 권한 오류가 난다면 연결의 capability도 확인할 항목입니다. 생성과 처리는 insert comments가 필요합니다. 조회에는 read comments가 필요하고 수락에는 update content가 추가로 필요합니다. 관리자에게는 실패한 도구 이름과 오류 내용을 전달하면 됩니다.

MCP 수정 제안 도구는 Business 또는 Enterprise 요금제가 필요합니다. 다른 요금제에서는 업그레이드 안내를 반환합니다. 문장 한 번을 다듬으려고 구독부터 바꾸기보다는 현재 연결에서 가능한 작업인지 먼저 가리는 편이 낫습니다.

시험할 공지는 한 문단이면 됩니다

처음부터 여러 팀이 함께 편집하는 공지 전체를 맡길 필요는 없습니다. 회사에서 외부 AI 사용을 허용한 비민감 시험 페이지를 준비하고 평범한 텍스트 한 문단을 대상으로 고릅니다. 이름이 비슷한 페이지를 검색하게 두기보다 대상 페이지 링크를 대화에 직접 붙이면 작업 대상을 명확히 할 수 있습니다.

다만 페이지 하나를 요청문에 지정하는 것만으로 연결 권한이 그 페이지에 한정되지는 않습니다. Notion MCP는 연결 사용자의 기존 권한을 따릅니다. 외부 AI 앱에 어떤 문서를 넘길 수 있는지부터 회사 기준에 맞춰 판단해야 합니다.

날짜와 담당자처럼 바뀌면 곤란한 정보도 미리 고릅니다. 예를 들어 행사 참여 공지라면 신청 마감일과 신청 대상이 유지돼야 합니다. 문장이 짧아졌다는 이유만으로 신청 조건 하나가 빠진 변경안을 받아들이면 안 됩니다.

MCP 수정 제안을 요청하는 3단계

AI가 제안을 만들 때는 대상 페이지를 page_id로 지정하고 바꿀 원문을 old_text에 넣습니다. 새 문장은 new_text입니다. 기본 동작은 원문을 새 문장으로 바꾸는 replace이며 new_text가 비어 있으면 삭제 제안이 됩니다. 공지를 다듬는 작업이라면 새 문장이 빠진 채 삭제만 제안되지 않았는지도 살필 항목입니다.

아래는 실제 계정에서 실행한 결과가 아닌 예시 시나리오입니다. 대상 페이지 링크를 먼저 붙인 뒤 요청문을 보냅니다.

1. AI가 대상 페이지를 notion-fetch로 읽도록 요청합니다. 바꿀 원문은 조회 결과에서 그대로 가져와야 하며 페이지 안에서 정확히 한 번만 나타나야 합니다.
2. 복사용 요청문으로 한 문단의 제안을 만듭니다. 도구가 반환한 제안 링크와 대기 상태를 받으면 생성 여부를 판단할 수 있습니다.
3. 제안 링크를 열어 변경 전후를 읽고 Notion 화면에서 직접 수락하거나 거절합니다.

이 페이지의 첫 공지 문단을 더 짧고 공손하게 다듬는 수정 제안을 하나 만들어 주세요.
날짜와 담당자 및 신청 조건은 그대로 유지해 주세요.
수정 제안 도구를 쓸 수 없다면 본문을 직접 바꾸는 대신 채팅에 변경 전후 문장만 보여 주세요.
제안을 만들었다면 링크를 알려 주고 수락과 거절은 제가 Notion 화면에서 처리하도록 남겨 주세요.

본문이 그대로여도 제안은 만들어졌을 수 있습니다

MCP 수정 제안 생성 응답에는 suggested_edit_url과 pending 상태가 포함됩니다. 이 링크가 변경안을 확인할 출발점입니다. notion-fetch는 수락된 본문만 보여 주므로 페이지를 다시 조회했을 때 예전 문장이 나온다는 이유로 제안을 계속 만들면 안 됩니다.

채팅에서 전후 차이를 보고 싶다면 받은 링크로 notion-get-suggested-edit를 조회하도록 요청할 수 있습니다. diff에는 변경 전후가 나오고 allowed_actions에는 연결 사용자가 할 수 있는 수락이나 거절 작업이 표시됩니다.

Notion 화면에서는 제안 위에 마우스를 올려 수락 또는 거절을 선택합니다. 수락하면 페이지 본문이 바뀌고 거절하면 제안이 사라집니다. 문장 끝의 정중함보다 신청 대상과 마감일이 원문대로 남았는지 먼저 읽습니다. 편집 권한이 없어 수락할 수 없다면 편집 가능한 담당자에게 제안 링크를 전달하는 것으로 작업을 넘길 수 있습니다.

요청문에 수락을 맡기지 않았다고 적는 것은 작업 지시입니다. 기술적으로 수락을 차단하는 권한 설정은 아닙니다. 처리 도구에는 실행 전 확인을 유도하는 destructiveHint 표시가 있지만 이를 따르는지는 AI 앱에 달려 있습니다. 사람이 반영을 결정하려면 앱이 내미는 실제 도구 실행 요청도 살펴야 합니다.

도구가 없거나 원문이 달라졌다면

도구 미제공 상태라면 MCP 수정 제안을 본문 직접 수정으로 대체할 이유가 없습니다. 채팅에서 받은 변경 전후 문장만 비교한 뒤 필요한 부분을 사람이 옮기면 됩니다. 연결 없이 초안 문장만 다듬고 싶다면 관련 글인 ‘ChatGPT 공지문 다듬기’가 더 가까운 작업입니다.

MCP 수정 제안이 오류로 끝났다면 HTTP 400이나 validation_error만으로 원인을 정하지 않습니다. 세부 원인은 additional_data.tool_error_code에 담깁니다. 원문을 못 찾은 경우와 같은 문장이 여러 곳에 있는 경우는 다음에 읽어야 할 내용이 다릅니다.

suggested_edit_no_match는 지정한 원문과 일치하는 곳을 찾지 못한 경우입니다. notion-fetch로 대상 페이지의 현재 본문을 다시 읽고 old_text가 그 조회 결과에서 가져온 문장인지 대조합니다. AI가 기억으로 고쳐 쓴 문장이나 이전 대화의 문장을 그대로 다시 보내는 대신 최신 조회 결과를 기준으로 대상을 잡습니다.

suggested_edit_multiple_matches는 같은 원문이 여러 곳에서 잡힌 경우입니다. 페이지를 다시 읽되 해당 문장 앞뒤도 함께 봅니다. 짧은 마감 안내가 공지 두 곳에 똑같이 있다면 그 문장만으로는 바꿀 곳을 고를 수 없습니다. 실제 조회 결과에서 주변 문장을 포함한 원문을 골라 페이지 안의 한 곳으로 특정해야 합니다.

suggested_edit_conflict는 바꾸려는 범위가 다른 대기 제안과 겹친 경우입니다. 원문을 다른 표현으로 추측해 재시도할 문제가 아닙니다. Notion 화면에서 해당 범위의 기존 제안을 살피고 링크가 있다면 notion-get-suggested-edit로 변경 전후와 가능한 작업을 읽습니다. 기존 제안을 어떻게 처리할지 결정한 뒤 같은 범위의 작업을 이어갑니다.

대기 중인 MCP 수정 제안 자체를 고치려면 기존 제안을 거절한 뒤 새로 만들어야 합니다. 댓글 권한으로는 자기 제안을 거절할 수 있고 다른 사람의 제안까지 거절하려면 편집 권한이 필요합니다.

누군가 제안이 걸린 원문을 바꿨다면 그 제안은 stale 상태가 됩니다. 이 상태에서는 읽거나 수락할 수 없고 거절은 가능합니다. 기존 제안을 처리한 후 최신 본문을 다시 읽어 새 제안을 만드는 순서로 돌아갑니다.

이 안내는 2026년 10월 29일 확인한 공식 문서를 바탕으로 합니다. 실제 계정의 동작과 한국어 교정 품질은 시험하지 않았습니다. 외부 AI 앱의 요금과 사용량 과금도 확인하지 않았으므로 연결 전에 별도로 살펴야 합니다. 시작할 때 할 일은 회사에서 허용한 연결의 도구 목록에 notion-create-suggested-edit가 있는지 보는 것입니다.