Notion Agent 제안 편집 공개: 문서를 바로 고치기 전에 세울 승인 기준

Notion은 2026년 8월 28일, Agent가 문서를 곧바로 바꾸는 대신 수정안을 제안하도록 하는 기능을 공개했습니다.[1] 국내 팀이 이 기능을 쓸 때 핵심은 "AI가 잘 쓰는가"보다 "어떤 문서는 제안만 허용하고, 누가 승인할 것인가"를 먼저 정하는 일입니다. 초안 작성은 빨라져도 최종 책임은 승인한 사람에게 남기 때문입니다.

확인된 변화

Notion Agent에게 "suggest edits"를 요청하면 줄 단위 수정안을 만들고, 사용자는 위에서 아래로 각 제안을 승인할 수 있습니다.[1]

>

POEMORA의 해석

이 기능은 문서 자동화의 속도 경쟁보다 검토 가능한 변경 이력을 운영 과정에 넣는 쪽에 가깝습니다. 특히 제안서, 정책 문서, 고객 안내문처럼 한 문장이 약속을 바꾸는 문서에 잘 맞습니다.

8월 28일 발표에서 달라진 점

기존 Notion Agent는 워크스페이스와 연결 앱의 맥락을 이용해 페이지와 데이터베이스를 만들거나 편집할 수 있습니다. Agent는 사용자가 볼 수 없거나 편집할 수 없는 콘텐츠에는 접근하지 못하며, 기본적으로 사용자와 같은 권한 범위에서 작동합니다.[3]

이번 발표는 그 편집 방식에 "제안"이라는 중간 단계를 더했습니다. Agent가 바로 본문을 덮어쓰는 대신 추가하거나 지울 문장을 제시하고, 사용자가 항목별로 받아들이거나 거절합니다.[1][2] 작은 표현 수정부터 문법 검토까지, 원문과 변경안 사이를 사람이 확인할 수 있다는 점이 실제 변화입니다.

다만 범위는 분명합니다. 현재 제안 편집은 텍스트, 할 일 목록, 제목, 글머리표, 번호 목록 블록에서 사용할 수 있습니다. 인라인 데이터베이스, 데이터베이스 속성, 미리보기로 열린 페이지에는 제안을 만들 수 없습니다.[2]

모든 문서에 제안 모드를 켤 필요는 없다

제안 단계가 필요한지는 문서의 영향으로 정하는 편이 낫습니다. 개인 회의 메모의 맞춤법을 고치는 일과, 가격·환불·개인정보 문구를 바꾸는 일은 같은 승인 절차를 쓰기 어렵습니다.

다음 세 질문 중 하나라도 "예"라면 제안 편집을 기본값으로 두는 쪽이 안전합니다.

• 이 문장이 고객에게 비용, 일정, 책임을 약속하는가?
• 법무·보안·인사 정책처럼 승인된 표현을 유지해야 하는가?
• 수정한 사람이 아닌 다른 담당자가 최종 책임을 지는가?
• 원문이 바뀐 이유를 나중에 설명해야 하는가?

반대로 개인 초안, 내부 아이디어 메모, 손쉽게 복구할 수 있는 문서는 바로 편집이 더 효율적일 수 있습니다. 승인 절차를 무조건 늘리면 중요한 변경과 사소한 교정이 같은 대기열에 섞입니다.

권한과 승인자를 먼저 정하는 네 단계

Notion의 일반 제안 편집은 페이지에 Can comment 이상 권한이 있어야 사용할 수 있습니다. 페이지가 잠겨 있거나 권한이 부족하면 제안할 수 없습니다.[2] Agent는 사용자의 권한을 따르므로, 넓은 접근권한을 가진 계정에서 실행할수록 검토 대상도 넓어집니다.[3]

1. 문서를 세 등급으로 나눕니다. 개인 초안, 팀 운영 문서, 외부 공개·계약 문서로 구분합니다.
2. 등급마다 편집 방식을 고릅니다. 개인 초안은 바로 편집, 팀 문서는 제안 편집, 외부 문서는 제안 편집과 별도 승인자를 둡니다.
3. 승인자를 이름이 아니라 역할로 정합니다. 담당자가 바뀌어도 "서비스 운영 책임자"나 "개인정보 담당자"처럼 책임이 이어지게 합니다.
4. 반려 이유를 짧게 남깁니다. 사실 오류, 톤 불일치, 최신 정책 미반영처럼 재사용 가능한 기준으로 기록합니다.

페이지 소유자는 제안을 하나씩 수락하거나 거절할 수 있고, 제안에 댓글로 답할 수도 있습니다. 다른 사람이 제안을 남기면 받은 편지함 알림이 전달됩니다.[2] 따라서 승인자를 정했다면 알림을 누가 언제 처리할지도 함께 정해야 합니다.

실제 도입은 작은 문서 한 종류에서 시작한다

첫 적용 대상으로는 반복 작성하지만 최종 검토가 필요한 문서가 좋습니다. 예를 들어 주간 프로젝트 보고서, 고객 미팅 후속 메일 초안, 캠페인 결과 요약처럼 형식은 비슷하고 내용은 매번 달라지는 문서입니다.

일주일 시험 운영 체크리스트

• 같은 유형의 문서 5건 안팎만 대상으로 정합니다.
• Agent에게 참고할 원문과 고치면 안 되는 표현을 함께 지정합니다.
• 모든 요청에 "원문을 직접 바꾸지 말고 제안 편집으로 남겨라"를 넣습니다.
• 승인자는 제안마다 수락·거절하고, 반려 이유를 한 줄로 기록합니다.
• 주말에 반복 반려된 항목을 모아 Agent 지침과 문서 템플릿을 고칩니다.

여기서 볼 것은 생성 속도만이 아닙니다. 승인자가 실제로 읽은 제안 수, 사실 오류로 반려된 항목, 사람이 다시 쓴 문장, 검토 대기 시간도 함께 봐야 합니다. 이 네 가지는 제품사가 발표한 성과 수치가 아니라 POEMORA가 권하는 내부 운영 지표입니다.

제안 편집은 책임을 AI에게 넘기는 기능이 아닙니다. 사람이 책임질 변경을 눈에 보이게 쪼개는 기능에 더 가깝습니다.

국내 실무에서 놓치기 쉬운 두 가지

첫째, 제안 편집이 사실 검증을 대신하지는 않습니다. Agent는 문장을 자연스럽게 다듬을 수 있지만 가격, 일정, 법률 문구, 고객별 조건이 현재 기준과 맞는지는 담당자가 원본 자료와 대조해야 합니다. "문장이 좋아졌다"와 "내용이 맞다"를 따로 승인하는 편이 낫습니다.

둘째, 접근권한과 편집 승인은 다른 문제입니다. Agent가 페이지를 볼 수 있다는 사실은 그 페이지를 자동으로 바꿔도 된다는 뜻이 아닙니다. Notion Agent가 사용자 권한을 따르는다는 공식 설명[3] 위에, 팀이 정한 문서 등급과 승인 규칙을 한 겹 더 얹어야 합니다.

문서 자동화 흐름을 설계할 때는 POEMORA 업무 자동화 서비스처럼 입력 자료, AI 처리, 사람 승인, 최종 반영을 한 화면에서 추적할 수 있게 만드는 것이 좋습니다. 도구를 바꾸기 전에 승인 책임과 예외 처리부터 적어두면 다른 편집 도구로 옮겨도 기준이 남습니다.

지금 정할 한 가지

오늘 바로 결정할 것은 "Agent를 쓸 것인가"가 아닙니다. 우리 팀에서 AI가 직접 고쳐도 되는 문서 한 종류와, 반드시 제안만 남겨야 하는 문서 한 종류를 각각 고르는 일입니다. 그 경계가 있어야 제안 편집이 번거로운 승인함이 아니라 실수하기 어려운 검토 과정이 됩니다.