공식 릴리스 자료에는 NVivo 15.3의 변경 사항이 별도로 기록되어 있습니다(공식 NVivo 15.3 릴리스 자료). 그러나 버전 업데이트가 두 운영 체제의 프로젝트 흐름을 자동으로 같게 만들어 주지는 않습니다. NVivo 15 윈도우 맥 협업은 프로젝트를 계속 손으로 변환하는 방식보다, 주 플랫폼과 인계 지점을 먼저 고정하는 방식이 안전합니다. 윈도우의 전체 기능이 필요하면 윈도우를 주 프로젝트 플랫폼으로 정하고, 맥 사용자는 시험 검수를 통과한 코딩 작업만 맡기십시오.
이 글은 윈도우와 맥 사이에서 NVivo 프로젝트를 교환하는 대학원생, 박사 과정 연구자, 교차 대학 연구팀을 위한 실행 문서입니다. 맥에서 코딩하고 윈도우에서 최종 분석하는 팀, 프로젝트 보관과 데이터 안전을 검토하는 대학 기술 담당자도 대상입니다.
마지막 업데이트: 2026년 8월 29일. NVivo 공식 도움말, 공식 제품 자료와 버전 자료를 기준으로 확인했습니다. 이후 주요 버전이나 프로젝트 형식이 바뀌면 아래 절차를 다시 검수해야 합니다.
SECTION 01왜 직접 열기보다 인계 절차가 먼저인가요?
NVivo 프로젝트는 운영 체제에 따라 사용되는 형식이 다릅니다. 공식 파일 형식 안내와 프로젝트 변환 안내를 기준으로 보면, 윈도우 프로젝트와 맥 프로젝트는 같은 파일을 양쪽에서 아무 조건 없이 계속 열어 쓰는 구조로 보아서는 안 됩니다(공식 파일 형식 안내, 공식 플랫폼 간 변환 안내).
따라서 윈도우에서 만든 프로젝트를 맥에서 바로 열 수 있는지 확인할 때는 다음처럼 판단해야 합니다.
- 변환 또는 가져오기 절차가 필요한 프로젝트라면 원본을 보존한 뒤 복사본으로 진행합니다.
- 코드, 메모, 쿼리, 미디어가 화면에 보인다고 해서 모든 기능이 같은 상태라고 단정하지 않습니다.
- 외부 음성, 영상, 이미지, 복잡한 표와 하이퍼링크는 프로젝트 내부 항목과 별도로 위치를 확인합니다.
- 한쪽에서 보이지 않는 기능은 삭제가 아니라 플랫폼 차이 또는 지원 범위의 차이일 수 있습니다.
- 핵심 분석이 맥에서 실행되지 않으면 맥 사용자의 작업 범위를 즉시 줄입니다.
맥과 윈도우 프로젝트를 반복해서 변환하면 파일 상태를 확인할 기준점이 사라집니다. 누가 언제 어떤 복사본을 변환했는지 추적하기 어렵고, 서로 다른 복사본에서 코딩을 진행한 뒤 합치려 하면 결과 비교 자체가 복잡해집니다. 이런 이유로 수동 변환은 일상 동기화가 아니라 통제된 인계에 한정하는 편이 좋습니다.
SECTION 02첫 단계: 주 프로젝트와 플랫폼 경계를 정하십시오
착수 회의가 끝나기 전에 아래 네 가지를 문서로 고정하십시오.
- 주 프로젝트 파일을 보관할 운영 체제
- 주 프로젝트 책임자와 최종 병합 담당자
- 각 구성원의 운영 체제와 NVivo 주요 버전
- 각 구성원의 자료 접근 범위와 금지 작업
혼합 플랫폼 팀이 어느 시스템에 주 프로젝트를 둘지는 기능 요구로 결정합니다. 윈도우에서 사용할 쿼리, 관계 분석, 보고서 또는 협업 기능이 연구 결과에 직접 연결된다면 윈도우를 주 플랫폼으로 정하는 것이 안전합니다. 맥은 승인된 자료의 코딩이나 읽기 검수처럼 범위가 명확한 작업에 배정합니다.
반대로 맥 사용자가 단순 코딩만 하고 윈도우 담당자가 결과를 다시 확인한다면, 시험 인계에서 코드 구조와 코딩 범위가 일치하는지 확인한 뒤 제한된 맥 작업을 허용할 수 있습니다. “맥 사용자도 프로젝트를 열었다”는 사실만으로 전체 협업을 승인하면 안 됩니다.
주요 버전이 서로 다르면 먼저 버전을 맞추십시오. 맞출 수 없다면 가장 오래된 환경을 기준으로 시험 프로젝트를 만들고, 실제 논문에 사용할 기능을 양쪽에서 확인해야 합니다. NVivo 15.3과 관련된 변경 사항은 공식 릴리스 자료에 적힌 범위만 승인 근거로 사용하십시오.
SECTION 03두 번째 단계: 프로젝트 변환 전 기준 파일을 만드십시오
변환의 입력 조건은 탈감작한 기준 프로젝트와 읽기 전용 원본입니다. 원본 파일을 직접 열어 저장하지 말고, 복사본에 변환 작업을 수행하십시오. 공식 프로젝트 생성 및 협업 안내도 프로젝트 저장 위치와 협업 방식을 별도로 검토하도록 안내합니다(공식 프로젝트 생성 및 협업 안내).
다음 항목을 파일 목록에 기록하십시오.
- 프로젝트 파일 이름, 생성 날짜, 마지막 수정자
- NVivo 주요 버전과 운영 체제
- 코드, 노드, 메모, 쿼리의 존재 여부
- 외부 음성 및 영상 파일의 이름과 저장 위치
- 하이퍼링크, 이미지, 복잡한 표가 포함된 문서
- 변환 전 파일의 해시 또는 기관에서 정한 무결성 기록
- 원본 보관 위치와 복구 담당자
이 단계에서 파일을 하나의 폴더에 모으는 것만으로 외부 링크 문제가 해결되지는 않습니다. 프로젝트가 외부 파일의 경로를 참조하는 구조라면, 다른 컴퓨터에서 같은 경로가 존재하는지 따로 확인해야 합니다. 첨부 파일 링크가 끊어진 경우에는 변환된 프로젝트를 계속 수정하지 말고, 원본과 변환본의 파일 목록을 대조한 뒤 필요한 자료를 새 위치에서 다시 연결하십시오.
.nvp와 .nvpx는 팀 기록에 반드시 남겨야 할 프로젝트 파일 형식입니다. 특정 확장자를 보고 자동으로 안전한 상호 변환이 가능하다고 판단하지 말고, 실제로 사용 중인 NVivo 버전과 플랫폼의 변환 안내를 함께 확인하십시오.
SECTION 04세 번째 단계: 작은 프로젝트로 시험 인계를 수행하십시오
시험 인계의 입력은 실제 연구 자료를 그대로 복사한 파일이 아니라, 개인정보와 민감한 연구 내용을 제거한 작은 기준 프로젝트입니다. 코드, 메모, 쿼리, 미디어, 외부 링크를 각각 포함해야 하지만, 원자료 식별이 가능한 내용은 넣지 마십시오.
진행 순서는 다음과 같습니다.
- 윈도우에서 기준 프로젝트를 복사하고 원본을 읽기 전용으로 보관합니다.
- 맥으로 인계할 복사본을 만들고 파일 형식과 NVivo 주요 버전을 기록합니다.
- 변환 또는 열기 절차를 공식 안내에 따라 수행합니다.
- 양쪽에서 코드 구조, 메모, 쿼리와 미디어 항목의 표시 상태를 비교합니다.
- 외부 영상과 음성의 재생, 위치 이동, 문서 내 표와 이미지 표시를 확인합니다.
- 필요한 결과를 양쪽에서 내보내고 파일 내용과 이름을 비교합니다.
시험 결과는 “통과”, “제한”, “중단”으로 나누십시오. 코드와 메모가 보이고 샘플 코딩 결과가 일치해도, 쿼리 출력이나 미디어 위치가 다르면 전체 협업은 통과가 아닙니다. 공식 내보내기 안내에 맞춰 결과 파일을 별도로 저장하고, 프로젝트 안의 화면 표시와 실제 내보내기 결과를 구분하십시오(공식 파일 내보내기 안내).
SECTION 05네 번째 단계: 같은 자료로 코딩 결과를 대조하십시오
시험 코딩에서는 양쪽 구성원에게 같은 자료 묶음과 같은 코딩 지시를 전달하십시오. 작업량을 크게 잡을 필요는 없지만, 단순 텍스트만 사용하면 플랫폼 차이를 놓칠 수 있습니다. 표와 이미지가 있는 문서, 외부 음성 또는 영상, 메모가 연결된 자료를 포함해야 합니다.
다음 증거를 나란히 확인하십시오.
- 코드의 이름과 계층 구조
- 코딩된 문장 또는 구간의 범위
- 코딩 뒤에 남은 주석과 메모
- 쿼리 조건과 출력 결과
- 미디어의 재생 및 위치 접근
- 외부 링크의 연결 상태
- 내보낸 문서와 그래픽의 내용
NVivo 프로젝트 변환 뒤 첨부 링크가 실패하면, 먼저 링크의 대상 파일이 실제로 존재하는지 확인하십시오. 파일은 있지만 경로가 바뀐 경우와 파일 자체가 누락된 경우는 처리 방법이 다릅니다. 경로를 다시 지정한 뒤 기준 프로젝트와 결과를 재비교하고, 파일이 없다면 원본 보관본에서 복원합니다.
핵심 쿼리가 맥에서 실행되지 않거나 결과가 달라지면 해당 작업은 윈도우 주 플랫폼에서 수행해야 합니다. 이때 맥 사용자의 코딩 결과를 모두 폐기할 필요는 없지만, 어떤 결과를 주 플랫폼에서 다시 확인할지 기록하고 승인받아야 합니다.
SECTION 06다섯 번째 단계: 정식 협업의 변경 입구를 하나로 줄이십시오
정식 단계에서는 프로젝트를 여러 개 만드는 것보다 변경 경로를 제한하는 것이 중요합니다. 팀 규칙에는 다음 내용을 포함하십시오.
- 프로젝트를 열기 전 복사본 이름을 정하는 방법
- 작업 시작과 제출 시점의 기록 방식
- 변환을 수행할 수 있는 담당자
- 병합 전 백업 위치와 복구 절차
- 동일한 원본에서 파생된 복사본의 동시 편집 금지
- 새 버전이나 새 분석 기능을 승인하는 방법
공식 협업 기능을 사용할 계획이라면 학교의 계정 정책, 데이터 저장 위치, 라이선스 조건과 함께 검토하십시오. 기능이 존재한다는 사실만으로 기관의 연구 데이터 규정을 충족한다고 볼 수는 없습니다. 협업 기능을 쓰지 않는 팀이라면 수동 변환을 매일 반복하는 대신, 정해진 인계 시점에만 교환 파일을 만들고 주 프로젝트에서 최종 반영하십시오.
버전 업그레이드나 새 분석 기능을 추가한 뒤에는 기준 프로젝트로 다시 시험하십시오. 통과 기록이 없는 기능은 논문 마감 직전에 도입하지 않는 것이 좋습니다.
SECTION 07최종 인계 전에는 무엇을 승인해야 하나요?
논문 제출이나 연구 종료 전에 주 플랫폼에서 실제 인용할 쿼리, 도표, 내보내기 작업을 다시 실행하십시오. 맥에서 보였다는 결과를 그대로 복사하지 말고, 최종 프로젝트에서 같은 결과가 재현되는지 확인해야 합니다.
다음 체크리스트를 프로젝트 책임자와 데이터 관리자에게 함께 전달하십시오.
- [ ] 주 프로젝트와 교환 복사본의 이름이 구분되어 있습니다.
- [ ] 읽기 전용 원본과 복구 위치가 남아 있습니다.
- [ ] 양쪽 구성원의 NVivo 주요 버전을 기록했습니다.
- [ ] 코드, 메모, 쿼리와 코딩 범위를 주 플랫폼에서 다시 확인했습니다.
- [ ] 외부 음성, 영상, 이미지와 표의 연결 상태를 확인했습니다.
- [ ] 논문에 인용할 쿼리와 내보내기 결과를 주 플랫폼에서 재실행했습니다.
- [ ]
.nvp및.nvpx파일의 역할과 보관 위치를 문서화했습니다. - [ ] 변환 제한 사항과 맥 사용자의 허용 작업 범위를 적었습니다.
- [ ] 교환 파일, 최종 결과, 버전 설명과 복구 절차를 함께 보관했습니다.
- [ ] 프로젝트 종료 뒤 원격 장비나 임시 저장소의 자료 삭제 절차를 확인했습니다.
실험실에 맥이 없다면 최종 보관 전에 독립된 원격 맥에서 탈감작 프로젝트를 열고, 첨부 자료 접근과 결과 내보내기를 확인할 수 있습니다. 다만 원격 환경을 연구 데이터의 영구 보관소로 사용하기보다, 기관 규정에 맞는 저장소와 분리된 검수 환경으로 운영하십시오. MACNOX의 원격 맥 환경을 검토할 때도 독립 계정, 접근 권한, 작업 종료 후 삭제 절차를 먼저 확인해야 합니다.
현재 실험실의 윈도우와 맥을 번갈아 쓰는 방식은 장비를 새로 사지 않아도 된다는 장점이 있지만, 프로젝트 복사본이 늘고 변환 책임과 링크 복구 책임이 불분명해지기 쉽습니다. 반면 원격 맥은 매일 쓰는 주 플랫폼을 바꾸지 않고도 맥 수신 환경을 시험할 수 있지만, 네트워크 접근과 기관의 데이터 정책을 별도로 검토해야 합니다. 맥 사용자가 한 명뿐이거나 한 번의 논문 인계만 필요하다면, MACNOX 요금과 이용 기간을 확인해 탈감작 프로젝트로 먼저 검수한 뒤 장기 구매나 이중 환경을 결정하는 편이 합리적입니다.
NVivo 15 윈도우 맥 협업의 승인 기준은 “양쪽에서 열리는가”가 아니라 “같은 결과를 다시 확인할 수 있는가”입니다. 주 프로젝트를 하나로 고정하고 시험 인계 기록을 남겨야 한다면, MACNOX 원격 맥 신청 안내에서 논문 일정에 맞는 임시 검수 환경을 확인해 보시기 바랍니다.