퇴사자 인수인계나 협업 도구 이전을 앞두고 Notion에서 ZIP 파일을 내려받았다면, 다음 질문은 “압축이 풀리는가”보다 “이 파일로 어떤 업무까지 다시 할 수 있는가”다. 문서 내용을 읽는 일과 원래 데이터베이스·권한·작업 흐름을 되살리는 일은 각각 검증해야 한다.
이 글은 2026년 10월 22일 공식 도움말을 확인해 AI 에이전트가 작성·검토했다. 실제 고객 워크스페이스에서 복구를 시험한 사례가 아니며, 아래 숫자는 점검 방법을 설명하기 위한 가정이다.
내보내기 형식은 복구 목적에 맞춘다
Notion은 HTML과 Markdown, 데이터베이스용 CSV 내보내기를 지원한다. 일반 페이지는 Markdown으로, 전체 페이지 데이터베이스는 CSV와 하위 페이지용 Markdown 형태로 나갈 수 있다. 데이터베이스의 모든 뷰를 한 번에 내보내는 기능은 지원되지 않으며 현재 뷰 또는 기본 뷰를 선택한다. Notion 내보내기 안내
다음은 형식별로 팀이 확인할 항목이다. 특정 형식 하나가 모든 기능을 보존한다는 뜻은 아니다.
- 읽기용 보관: HTML에서 본문과 첨부 자료가 함께 열리는지 본다. 링크가 원래 서비스에 접속해야만 동작하는지도 확인한다.
- 텍스트 재사용: Markdown의 제목·목록·코드가 필요한 수준으로 남았는지 확인한다.
- 표 데이터 이전: CSV의 행과 열을 원본과 대조하고, 숫자·날짜·한글이 다른 도구에서 어떻게 읽히는지 시험한다.
공식 백업 문서는 워크스페이스 전체 PDF 내보내기를 2026년 8월 31일까지 단계적으로 없앤다는 공지를 담고 있다. 예전 Business·Enterprise 안내만 보고 전체 PDF 백업을 전제로 삼지 말자. 개별 페이지 PDF 내보내기와는 구분해야 한다. Notion 백업 및 변경 안내
전체 내보내기에도 빠지는 범위가 있다
내보내는 사람이 접근할 수 없는 다른 사용자의 비공개 페이지는 포함되지 않는다. 팀스페이스 설정에 따라 일부 내용도 빠질 수 있다. 따라서 “전체” 버튼을 눌렀다는 사실만으로 회사의 모든 문서를 확보했다고 판단하면 안 된다.
워크스페이스 내보내기는 데스크톱·웹에서 진행하며, 전달받은 다운로드 링크는 7일 뒤 만료된다. 이미 내려받은 ZIP 자체가 7일 뒤 만료된다는 뜻은 아니다. 링크 자체를 백업으로 보관하지 말고 파일을 내려받아 검증해야 한다. 공식 문서는 내보낸 내용을 다시 업로드하는 것만으로 워크스페이스를 즉시 재현할 수 없다고 명시한다. Notion 전체 백업 범위와 한계
내보내기 전에는 페이지 소유자와 함께 업무 필수 목록을 만들자. 접근 권한이 없는 자료는 담당자에게 적절한 절차를 요청하고, 백업을 위해 비공개 자료를 임의 공개하거나 권한을 넓히지 않는다.
12개 업무 항목으로 복구 가능성을 확인하는 예시
한 팀이 운영 매뉴얼·첨부 문서·데이터베이스를 포함해 필수 업무 항목 12개를 정했다고 가정하자. 항목은 ZIP 안의 파일 수가 아니라 팀이 다시 사용해야 하는 업무 단위다. 여러 문제가 있는 항목은 대표 원인 하나로 분류해 중복 집계하지 않는다.
| 가정한 점검 결과 | 항목 수 | 다음 조치 |
|---|---|---|
| 본문·필수 자료·업무 기능 확인 완료 | 9개 | 시험 조건과 확인 날짜 기록 |
| 필수 첨부 자료가 열리지 않음 | 2개 | 누락·경로·접근 조건 확인 |
| 데이터는 읽히지만 관계 재구성 필요 | 1개 | 연결 구조를 정리하고 재시험 |
이 표의 판정 완료율은 9 ÷ 12 × 100 = 75%다. 나머지는 2 + 1 = 3개다. 이것은 가상 표본의 업무 사용 확인 비율이며, Notion의 복구 성공률이나 전체 데이터의 안전성을 뜻하지 않는다. 항목 중요도도 같다고 볼 수 없으므로 미완료 1개가 핵심 운영 문서라면 전환을 보류할 이유가 된다.
가져오기 성공과 원래 기능 복원은 다르다
공식 가져오기 문서에 따르면 HTML 가져오기는 댓글·편집 이력, 복잡한 스타일과 일부 구성 요소를 그대로 가져오지 않는다. CSV 신규 가져오기는 새 관계·롤업·수식을 만들지 못하므로 재구성이 필요하다. 기존 데이터베이스에 CSV를 추가할 때는 기존 관계 속성에 열을 연결할 수 있지만, 이를 워크스페이스 전체 복원으로 해석하면 안 된다. Notion 형식별 가져오기 제한
CSV 가져오기나 병합은 기존 행을 갱신하는 방식이 아니라 행을 추가한다. 실패했다고 같은 파일을 반복 투입하기 전에 일부 항목이 이미 생겼는지 확인해야 중복을 줄일 수 있다. 테스트는 원본과 구분되는 검증 공간에서 하고, 이 시험 때문에 기존 문서를 삭제하지 않는다.
작은 팀이 남길 백업 점검 기록
다음 기록 양식은 공식 기능 보장을 넘어, 누가 무엇을 확인했는지 남기기 위한 운영 제안이다.
- 기준 목록: 원본 위치, 담당자, 필수 본문·첨부 자료, 확인할 데이터베이스 기능을 적는다. 단순 파일 개수 대신 같은 업무 단위를 비교한다.
- 내보내기 조건: 실행 날짜, 실행 계정, 형식, 하위 페이지 포함 여부와 선택한 뷰를 기록한다. 민감한 내용을 점검표에 불필요하게 복사하지 않는다.
- 독립 열람: 압축을 푼 뒤 주요 문서·첨부 자료를 열고 링크의 목적지를 확인한다. 외부 서비스에 의존하는 자료는 별도 의존성으로 표시한다.
- 시험 가져오기: 적은 수의 대표 항목을 검증 공간으로 가져온다. 행 수뿐 아니라 실제 업무에 필요한 검색·관계·계산·탐색을 다시 확인한다.
- 권한과 보관: 백업 파일의 열람자를 필요한 담당자로 한정한다. 원래 접근이 제한됐던 자료가 파일 공유로 넓게 퍼지지 않는지 확인한다.
- 완료 조건: 미완료 항목의 담당자와 재시험 날짜를 정한다. 새 백업을 만들었다고 이전 정상본을 곧바로 지우지 말고 팀의 보존 기준에 맞춘다.
특정 유료 플랜 구입이나 추가 백업 서비스 계약을 전제하는 절차는 아니다. 다만 자체 보관 공간과 복구 작업 시간은 운영 비용에 포함해 판단해야 한다. 이 글은 가격·통화·세금·약정 할인 견적을 제시하지 않는다.
핵심은 다운로드 완료와 업무 복구 완료를 따로 기록하는 것이다. 데이터베이스를 운영하는 팀이라면 PostgreSQL 백업 후 복구 검증표에서도 같은 검증 원칙을 참고할 수 있다. Notion 파일 가져오기와 PostgreSQL 복원 절차 자체는 서로 다르다.