OSF Projects 종료 전에 무엇을 옮길까? 데이터·코드 유지와 Zenodo·Figshare 이전 기준
논문에 인용한 데이터와 코드를 OSF에 공개해 두었거나, 비공개 Project에서 공동연구 파일을 계속 고치고 있다면 같은 질문이 생긴다. 지금 자료를 모두 내려받아 다른 저장소로 옮겨야 하는지, 이미 논문에 적어 둔 주소와 DOI는 어떻게 되는지, 심사자에게 전달한 익명 링크는 계속 작동하는지 판단하기 어렵다.
2026년 9월 30일 기준으로 확인한 핵심 결론은 간단하다. 새 연구의 작업 공간으로 OSF Project를 시작하는 것은 피하되, 이미 공개됐고 수정할 필요가 없는 Project까지 일괄 이전할 필요는 없다. 반면 계속 갱신할 코드·데이터, 새 참여자를 받아야 하는 비공개 협업 공간, OSF API로 파일을 올리는 자동화 작업은 읽기 전용 전환 전에 다른 환경으로 옮겨야 한다. 이전 여부는 서비스 이름보다 공개 상태, 수정 필요성, DOI 유무, 접근 통제 방식으로 결정하는 편이 안전하다.
먼저 OSF 전체가 종료되는 것은 아니다
변경 대상은 주로 파일 저장과 협업에 사용해 온 OSF Projects와 그 하위 Components다. COS의 공식 전환 안내에 따르면 2026년 11월 16일부터 새 Project와 새 Component를 만들 수 없고, 2027년 2월 19일부터 기존 Project는 읽기 전용으로 바뀐다. 공개 자료의 기존 URL과 DOI는 계속 연결되며, 공개 Project는 검색·열람·다운로드가 가능하다는 것이 현재 안내다. 자세한 범위는 OSF Projects Transition과 전환 상세 안내에서 확인할 수 있다.
OSF Registrations와 Preprints는 이 전환의 직접 대상이 아니다. Registration은 연구계획이나 프로토콜을 시점이 고정된 기록으로 남기는 기능이며, Project는 파일을 수정하고 참여자와 협업하는 작업 공간이었다. 따라서 OSF 화면에 프로토콜 PDF를 올렸다는 사실만으로 Registration이 되는 것은 아니다.
가장 빠른 확인법은 OSF 계정의 My Projects와 My Registrations를 각각 살펴보는 것이다. My Registrations에 독립된 기록으로 나타나면 Registration이고, 파일·위키·Components·공동기여자 관리 화면을 중심으로 사용했다면 Project일 가능성이 높다. 공식 Registration 전환 안내도 Project에 업로드한 프로토콜 파일과 정식 Registration을 구분하라고 설명한다.
두 날짜에 실제로 달라지는 것
| 시점 | Projects에서 달라지는 기능 | 연구자가 준비할 일 |
|---|---|---|
| 2026년 11월 16일 | 새 Project와 하위 Component 생성이 중단된다. 기존 Project는 계속 편집할 수 있다. | 새 연구는 다른 협업·저장 환경에서 시작하고, 기존 Project에 새 Component가 필요한 구조 변경은 그 전에 끝낸다. |
| 2027년 2월 19일 | 기존 Project가 읽기 전용으로 바뀌어 파일·위키·메타데이터·기여자를 더 이상 수정하거나 추가할 수 없다. | 수정이 계속될 자료, 공동작업 공간, 심사용 신규 링크, 자동 업로드를 이전한다. |
API를 사용하는 연구실은 날짜별 영향이 더 분명하다. 공식 OSF Projects API 영향 안내에 따르면 새 Project나 Component를 만드는 요청은 2026년 11월 16일부터 실패하고, 기존 Project의 파일이나 메타데이터를 갱신하는 쓰기 작업은 2027년 2월 19일 이후 작동하지 않는다. 정기 분석 결과, 장비 출력, 설문 처리 파일을 OSF로 자동 전송하는 파이프라인은 단순 백업이 아니라 목적지와 인증 정보를 바꾸는 이전 작업이 필요하다.
그대로 두는 편이 나은 자료
이미 공개됐고 완결됐으며 앞으로 파일과 설명을 고칠 필요가 없는 Project는 그대로 두는 것이 기본 선택이다. COS는 이런 공개 콘텐츠를 옮기지 말 것을 권고하며, 기존 URL과 DOI를 유지하겠다고 안내한다. OSF 저장 유지 안내는 같은 자료를 다른 곳에 다시 공개하면 검색 결과와 인용 기록이 갈리고 여러 기여자가 중복 DOI를 만들 위험이 있다고 설명한다.
특히 논문 본문, 데이터 이용문, 학회 발표자료에 OSF DOI가 이미 적혀 있다면 ‘새 저장소가 더 편해 보인다’는 이유만으로 복제본을 발행하지 않는 편이 좋다. 이전해야 할 사유가 있다면 새 저장소의 공개 기록을 먼저 만든 뒤 OSF의 DOI 또는 URL 리디렉션 절차를 요청해야 한다. 단순히 기존 Project를 삭제하면 이미 배포된 링크를 끊을 수 있으므로 삭제는 마지막 단계다.
반대로 공개 Project라도 README 오류, 라이선스 누락, 저자·기여자 정보, 최종 파일을 고쳐야 한다면 2027년 2월 19일 전에 수정해야 한다. 읽기 전용 전환 뒤에는 공개 Project를 비공개로 되돌리거나 메타데이터를 고칠 수 없다는 현재 안내도 고려해야 한다.
이전 가능성이 큰 자료
- 계속 바뀌는 코드와 데이터: 분석 코드 릴리스, 정기 갱신 데이터, 장기 추적조사 파일처럼 새 버전이 생기는 자료다.
- 비공개 공동작업 공간: 새 연구자를 초대하거나 권한을 바꾸고 파일을 함께 수정해야 하는 Project다. 읽기 전용 전환 시점에 접근 권한이 있는 사용자는 계속 볼 수 있지만 이후 새 기여자를 추가할 수 없다.
- 심사마다 새 링크가 필요한 자료: 기존 Project의 view-only link는 읽기 전용 상태에서도 작동할 예정이지만, 2027년 2월 19일 이후 Project용 새 view-only link는 만들 수 없다.
- 자동 업로드 작업: API, 스크립트 또는 외부 서비스가 OSF Project에 새 파일이나 수정 파일을 보내는 경우다.
- 향후 비공개 유지가 중요한 장기 자료: COS는 비공개 Project가 당장은 유지되지만 장래에 별도 변경 가능성이 있으며 사전 통지를 제공할 계획이라고 밝히고 있다. 민감정보는 일반 저장소가 아니라 기관 지침에 맞는 통제 접근 환경을 우선 검토해야 한다.
Registration은 별도로 판단한다. 정식 Registration 자체는 남겨 두고, 이후 계속 변하는 데이터·코드만 외부 저장소에 보관한 다음 DOI를 Registration의 Resources 항목에 연결할 수 있다. 이는 Registration을 저장 공간의 대체재로 쓰는 것보다 연구계획 기록과 결과물을 명확하게 분리하는 방식이다.
Zenodo와 Figshare는 무엇을 기준으로 고를까
두 서비스 모두 범용 연구 저장소이지만 OSF Project와 완전히 같은 협업 공간은 아니다. 분야별 저장소나 기관 저장소가 지정돼 있다면 이를 먼저 확인하고, 적절한 전용 저장소가 없을 때 Zenodo와 Figshare를 비교하는 것이 좋다. COS도 저장소 선택 안내에서 학술지·연구비 제공기관·소속기관의 요구와 분야별 저장소를 우선 확인하라고 권고한다.
| 판단 기준 | Zenodo | Figshare.com 개인 계정 |
|---|---|---|
| 기본 업로드 범위 | 레코드당 최대 100개 파일, 총 50GB. 더 큰 할당량은 별도 요청 조건을 확인해야 한다. | 공식 개인 연구자 안내 기준 20GB 저장 공간과 최대 20GB 개별 파일 업로드를 제공한다. 기관용 한도는 기관 설정에 따라 다르다. |
| 공개 후 수정 | 큰 파일 변경은 새 버전을 만드는 방식이 원칙이다. 각 버전은 별도 식별자를 가지며 서로 연결된다. | 공개 항목의 파일이나 메타데이터를 수정해 다시 발행하면 새 버전이 생성된다. 기본 DOI는 최신 버전으로 연결되며 버전 정보가 구분된다. |
| DOI 준비 | 공개 전에 DOI를 예약할 수 있고, 이미 같은 객체에 DOI가 있으면 기존 DOI를 입력해 중복 발급을 피할 수 있다. | 공개 전 DOI 예약을 지원한다. 공개 항목에는 DataCite DOI가 부여된다. |
| 심사용 공유 | 초안 미리보기 또는 제한 파일 열람 권한을 가진 secret link를 만들 수 있다. 링크 만료일도 설정할 수 있다. | private link가 작성자 필드를 숨기는 익명 페이지를 제공한다고 안내한다. 링크는 영구 인용 주소로 사용하면 안 된다. |
Zenodo의 현재 한도와 공개 후 파일 변경 규칙은 Zenodo 파일 관리 도움말, DOI 예약과 기존 DOI 사용법은 Zenodo DOI 안내, secret link 권한은 Zenodo 링크 공유 안내에서 확인할 수 있다.
Figshare.com은 개인 연구자용 공식 안내에서 20GB 저장 공간, DOI, 공동작업 공간과 private link를 제시한다. 업로드 한도와 기관별 차이는 업로드 도움말에 설명돼 있다. 다만 Figshare의 ‘Project’는 협업 공간이고 공개 공간 자체에는 DOI와 버전 개념이 없으므로, 최종 인용 대상은 Project 안의 개별 item으로 발행해야 한다.
선택을 단순화하면, 비교적 큰 패키지를 하나의 보존 레코드로 공개하고 명시적인 버전 연결을 관리하려면 Zenodo가 이해하기 쉽다. Figshare는 개인 계정의 item·project 구조, private link, 화면 기반 파일 관리가 작업 방식에 맞을 때 검토할 수 있다. 그러나 대용량 유료 서비스, 기관 Figshare, 저장소별 심사 기능은 계약과 기관 설정에 따라 달라지므로 일반 계정 안내를 그대로 적용해서는 안 된다.
익명 심사 링크는 저장소 이름만 보고 결정하면 안 된다
익명 링크가 저자 필드를 숨기더라도 업로드한 파일 내부까지 자동으로 익명화되는 것은 아니다. 문서 속 저자명과 소속, 스프레드시트 속 작성자 정보, 코드의 로컬 경로, README의 연구실 주소, 압축파일명, Git 기록과 주석을 별도로 확인해야 한다. 공개 저장소와 연결된 ORCID, GitHub 주소, 기존 DOI도 저자를 추정할 단서가 될 수 있다.
심사용 링크를 만든 뒤에는 로그인하지 않은 브라우저나 별도 계정에서 직접 열어 보아야 한다. Zenodo의 secret link는 접근 권한을 제공하는 기능이므로 작성자 정보가 어떻게 보이는지 실제 초안 화면에서 확인해야 한다. Figshare는 private link에서 Author 필드를 숨긴다고 안내하지만, Figshare 용어 안내가 설명하듯 이 링크는 출판물에 인용할 영구 주소가 아니다.
안전한 이전은 복사보다 기록 관리가 먼저다
- Project 목록을 분류한다. 공개·비공개, 수정 필요 여부, DOI 유무, Components, add-on, view-only link, API 사용 여부를 표로 남긴다.
- 원본을 내려받는다. OSF의 Project와 각 Component는 별개이므로 각각 다운로드한다. 전체 ZIP에는 파일은 들어가지만 기여자·설정·위키·Registration 같은 메타데이터는 포함되지 않는다. 자세한 범위는 OSF 파일 다운로드 안내를 따른다.
- 메타데이터와 이력을 별도 보존한다. 필요한 경우 Project 메타데이터, 위키와 활동 로그를 따로 내려받는다. OSF 메타데이터·위키·로그 안내는 이 항목들이 파일 ZIP과 분리돼 있음을 설명한다.
- 파일 목록과 체크섬을 만든다. 파일명, 크기, 수정일, SHA-256 체크섬을 기록해 이전 전후 파일이 같은지 비교한다.
- 새 저장소에는 먼저 비공개 초안으로 올린다. 제목, 기여자, 라이선스, 자금지원 정보, README, 데이터 사전과 버전 설명을 검토한 뒤 공개한다.
- DOI 관계를 결정한다. 동일한 객체라면 새 DOI를 무조건 발급하지 않는다. 실질적으로 갱신된 버전이라면 이전 DOI와 새 DOI를 버전 관계로 연결한다.
- 기존 링크의 처리 방법을 확정한다. OSF DOI나 URL이 이미 배포됐다면 COS의 리디렉션 절차를 요청하고, 논문·등록 기록·연구실 웹페이지의 링크도 점검한다.
DataCite는 동일한 내용이 이미 DOI와 함께 공개돼 있다면 똑같은 버전에 다시 DOI를 부여하지 말아야 한다고 안내한다. 변경된 새 버전에는 IsNewVersionOf와 IsPreviousVersionOf, 버전 묶음에는 IsVersionOf와 HasVersion 같은 관계를 사용할 수 있다. 구체적인 관계는 DataCite 버전 연결 안내를 참고할 수 있다.
상황별 최종 체크리스트
- 새 연구: 새 OSF Project를 만들지 말고 협업 공간과 최종 공개 저장소를 구분한다. 필요하면 OSF Registration만 별도로 사용한다.
- 심사 중 논문: 현재 view-only link의 작동 여부와 익명성을 확인한다. 수정본 제출 때 파일을 바꿔야 한다면 새 저장소의 비공개 초안·심사 링크 기능을 준비한다.
- 출판 완료 자료: 공개됐고 완결된 OSF Project는 우선 유지한다. DOI가 있다면 중복 공개보다 기존 기록의 보존을 우선한다.
- 장기 공동연구: 기여자 추가, 권한 변경, 파일 수정, 자동 업로드가 필요한 기능을 2027년 2월 19일 전에 이전한다.
- 민감·통제 데이터: Zenodo나 Figshare의 일반 링크 공유만으로 충분하다고 가정하지 말고 기관 보안·윤리 기준과 승인 문서를 먼저 확인한다.
최종 판단
OSF Projects 전환에 대한 적절한 대응은 ‘모두 옮기기’가 아니다. 완결된 공개 기록은 남기고, 앞으로 바뀔 작업과 권한 관리가 필요한 공간만 옮기는 것이 식별자와 인용 기록을 보호하는 방법이다. 이전 대상이 결정되면 저장 용량보다 먼저 DOI 상태, 버전 구조, 심사 링크, 기관·학술지 정책을 확인해야 한다.
실무 순서는 Project 목록화, 공개 상태와 DOI 확인, 원본·메타데이터 백업, 새 저장소 초안 생성, 익명 링크 점검, 체크섬 비교, DOI 관계와 리디렉션 확정이다. 이 순서를 지키면 서비스 전환을 단순 파일 이동이 아니라 연구 기록의 연속성을 보존하는 작업으로 관리할 수 있다.
검증이 더 필요한 부분
- 본인 OSF 계정에서 Project, Component, Registration, add-on이 실제로 어떻게 구분돼 표시되는지
- 비공개 Project의 모든 공동기여자가 2027년 2월 19일 전에 필요한 접근 권한을 가지고 있는지
- 기존 OSF DOI의 리디렉션 요청에 필요한 관리자 권한과 현재 지원 절차
- Zenodo secret link와 Figshare private link를 비로그인 상태에서 열었을 때 파일 내부 정보까지 익명화됐는지
- 기관용 Figshare의 저장 한도, 검토 절차, DOI·버전 정책이 figshare.com 개인 계정과 다른지
- 투고 학술지가 심사 단계의 비공개 링크, DOI 예약, 출판 후 공개 시점을 어떻게 요구하는지
- 민감정보 이전이 연구윤리 승인서, 동의서, 연구비 계획 또는 기관 보안정책의 변경 승인을 요구하는지
출처 및 확인일
Center for Open Science의 OSF Projects 전환·API·Registration·다운로드 공식 문서, Zenodo 공식 도움말, Figshare 공식 연구자 안내와 도움말, DataCite 공식 지원 문서를 2026년 9월 30일 확인했다. 서비스 화면, 계정 한도와 정책은 이후 변경될 수 있으므로 실제 이전 직전에 각 링크의 최신 내용을 다시 확인해야 한다.
