공식 안내는 프로젝트 클라우드를 아직 베타로 표시하고, 두 기기에서 같은 프로젝트를 동시에 편집하는 용도로 쓰지 말라고 설명합니다. 프로젝트 클라우드 공식 안내에 근거하면, ATLAS.ti 26 프로젝트 클라우드는 개인의 기기 간 이어하기와 비동기 공유에는 적합하지만, 여러 사람이 같은 프로젝트를 동시에 편집하는 협업 공간으로 보면 안 됩니다.
실시간 코딩이 필요하면 ATLAS.ti 웹을 우선 검토해야 합니다. 데스크톱 분석, 프로젝트 병합, 코더 일치도 검사를 해야 한다면 하나의 주 프로젝트를 정하고 데스크톱 분배와 병합 절차를 사용해야 합니다.
이 글은 다음 독자를 위한 검수 기준입니다.
- 질적 연구 책임자: 여러 코더의 주 프로젝트, 권한, 전달 규칙을 정해야 하는 경우
- 연구생과 코더: 맥과 윈도우 사이에서 프로젝트를 안전하게 이어서 작업해야 하는 경우
- 대학 기술 지원 담당자: 원격 맥, 계정 사용 허가, 자료 보관과 데스크톱 배포 범위를 판단해야 하는 경우
마지막 확인: 2026년 9월 7일. 자료는 ATLAS.ti 26 맥 공식 안내와 팀 작업 문서를 기준으로 확인했습니다.
[ SECTION_01 ] 먼저 정하는 네 가지 협업 경로
아래 표는 기능을 나열한 표가 아닙니다. 연구팀이 어떤 작업을 할 때 어느 경로를 먼저 검수할지 정하는 표입니다.
| 경로 | 맞는 장면 | 먼저 확인할 것 | 승인 기준 |
|---|---|---|---|
| 프로젝트 클라우드 | 한 사람이 맥과 윈도우에서 이어서 작업 | 최신 버전과 업로드 상태 | 한 번에 한 기기만 수정 |
| ATLAS.ti 웹 | 여러 사람이 같은 자료를 온라인에서 다룸 | 웹 기능과 데스크톱 기능의 차이 | 웹 중심 흐름으로 운영 |
| 프로젝트 병합 | 코더별 독립 작업을 하나로 결합 | 사용자 정체성, 문서 식별자, 충돌 | 중복 문서와 충돌이 설명됨 |
| 원격 맥 데스크톱 | 맥 전용 작업을 원격으로 검수 | 실행, 사용 허가, 내려받기, 내보내기 | 비식별화 표본으로 전체 왕복 성공 |
프로젝트 클라우드와 ATLAS.ti 웹의 관계는 특히 주의해야 합니다. 공식 안내에 따르면 데스크톱 프로젝트 클라우드 프로젝트와 ATLAS.ti 웹 프로젝트는 현재 서로 바로 보이지 않습니다. 웹에서 만든 프로젝트가 데스크톱 프로젝트 클라우드 목록에 자동으로 나타난다고 가정하면 안 됩니다. 프로젝트 전송 공식 문서에서 가져오기와 내보내기 범위를 먼저 확인해야 합니다.
[ SECTION_02 ] 장면별 검수 기준
첫 번째 단계: 맥과 윈도우에서 한 사람이 이어서 작업하기
이 장면에서는 협업보다 버전 보존이 핵심입니다. 프로젝트 클라우드가 작업자의 두 기기를 하나의 실시간 편집 화면으로 합쳐 주는 것은 아닙니다. 프로젝트의 로컬 복사본과 동기화 상태를 확인하면서 한 기기씩 사용해야 합니다.
검수 순서는 다음과 같습니다.
- 주로 사용할 기기에서 프로젝트를 업로드합니다.
- 다른 기기에서 최신 버전 표시를 확인한 뒤 내려받습니다.
- 내려받은 프로젝트의 문서와 코드 수를 확인합니다.
- 한 기기에서만 코딩을 진행합니다.
- 작업 종료 뒤 업로드가 끝났는지 확인합니다.
- 다음 기기에서 새 버전을 다시 내려받습니다.
두 기기에 모두 업로드되지 않은 변경 사항이 있다면 계속 코딩하지 않아야 합니다. 어느 복사본이 기준인지 먼저 정하고, 필요한 경우 읽기 전용 원본과 작업본을 분리해야 합니다. 프로젝트 클라우드 동기화 제한은 이 판단의 공식 근거가 됩니다.
통과 기준: 시작 전에 최신 버전을 확보하고, 종료 뒤 업로드 상태를 기록하며, 동시에 편집한 사실이 없어야 합니다.
중단 기준: 두 기기에서 서로 다른 변경 사항이 발견되거나, 어느 버전이 최신인지 설명할 수 없을 때입니다.
두 번째 단계: 작은 연구팀의 비동기 분업
작은 팀에서는 자료를 나누어 코딩한 뒤 다시 회수하는 방식이 현실적입니다. 다만 각 구성원이 받는 것은 공동으로 잠긴 하나의 인스턴스가 아니라, 독립적으로 작업할 수 있는 프로젝트 복사본입니다.
분배 전에 다음 항목을 기록해야 합니다.
- 주 프로젝트의 책임자와 보관 위치
- 코더별 이름과 작업 범위
- 자료의 비식별화 여부
- 작업 시작일과 회수일
- 파일 이름 규칙과 회수 방식
- 병합 전 백업 위치
한 차례의 비식별화 자료를 표본으로 사용해 보십시오. 주 프로젝트에서 복사본을 만들고, 코더가 작업한 뒤 회수하고, 시험 병합 결과를 저장합니다. 이 과정을 통과하지 못했다면 실제 인터뷰 자료를 배포하지 않는 편이 좋습니다.
팀 작업 공식 안내는 구성원별 작업과 프로젝트 결합을 분리해 설명합니다. 이름만 다른 파일을 자동으로 합쳐 주는 기능으로 이해해서는 안 됩니다.
세 번째 단계: 실시간 코딩이 필요한 경우
여러 사람이 같은 자료를 보면서 즉시 코드 결과를 공유해야 한다면 프로젝트 클라우드를 선택하지 않는 것이 안전합니다. 현재 공식 안내는 두 기기에서 같은 프로젝트를 동시에 편집하는 사용을 제한합니다.
이 장면에서는 ATLAS.ti 웹을 별도 경로로 검토합니다. 다만 웹 프로젝트와 데스크톱 프로젝트 클라우드 프로젝트가 현재 서로 바로 보이지 않으므로, 한쪽에서 작업한 결과를 다른 쪽에서 즉시 이어서 편집할 수 있다고 약속해서는 안 됩니다.
| 연구 요구 | 우선 검토할 경로 | 피해야 할 운영 |
|---|---|---|
| 온라인에서 함께 코딩 | ATLAS.ti 웹 | 웹과 데스크톱을 임의로 섞기 |
| 데스크톱 전용 분석 | 데스크톱 주 프로젝트 | 여러 사람이 주 프로젝트를 동시 수정 |
| 코더별 결과 비교 | 독립 복사본과 병합 | 각자가 문서와 코드를 새로 만들기 |
| 맥 전용 환경 확인 | 원격 맥 데스크톱 | 실제 민감 자료로 첫 테스트 진행 |
데스크톱 버전에 의존하는 분석 기능이 있다면 웹과 데스크톱을 혼합한 실시간 흐름보다 단계별 전달이 낫습니다. 웹에서 코딩을 끝낸 뒤 어떤 자료와 결과를 데스크톱으로 넘길지 문서로 정해야 합니다.
네 번째 단계: 코더 일치도 검사와 정식 병합
코더 일치도 검사는 단순히 여러 파일을 한 폴더에 넣는 작업이 아닙니다. 같은 주 프로젝트에서 독립 복사본을 만들고, 코더의 작업을 식별할 수 있어야 합니다.
코더 일치도 공식 설명에 따르면 공통 프로젝트와 독립 코딩 결과가 분석의 기반이 됩니다. 맥용 병합 및 일치도 안내도 시험 병합을 먼저 검토해야 하는 이유를 보여 줍니다.
검수 항목은 다음과 같습니다.
- 각 코더가 같은 주 프로젝트에서 출발했는가
- 코더별 사용자 정체성이 남아 있는가
- 문서 식별자가 유지되는가
- 병합 뒤 중복 문서가 생기지 않았는가
- 충돌 보고서를 설명할 수 있는가
- 코드 이름과 코드 체계가 임의로 달라지지 않았는가
- 일치도 분석에 필요한 원본과 결과가 모두 남아 있는가
프로젝트 병합 공식 문서는 병합 시 충돌과 중복 위험을 다룹니다. 코더가 각자 새 문서와 새 코드 체계를 만든 경우에는 결과를 합치기 전에 구조를 정리해야 합니다.
[ SECTION_03 ] 민감 자료와 대용량 음성 자료의 보관 판단
인터뷰 자료가 프로젝트 클라우드에 들어가도 되는지는 학교 윤리 승인, 자료 분류, 기관의 외부 저장 정책과 국외 이전 조건을 함께 확인해야 합니다. 이 글은 법적 허용 여부를 단정하지 않습니다.
먼저 자료를 세 종류로 나누는 편이 좋습니다.
| 자료 유형 | 확인할 위험 | 최소 검수 |
|---|---|---|
| 비식별화 문서 | 재식별 가능성 | 표본 프로젝트로 내려받기와 업로드 |
| 프로젝트 내부 음성·영상 | 저장 용량과 접근 권한 | 다른 기기에서 재생과 경로 확인 |
| 외부 링크 자료 | 링크 만료와 권한 변경 | 새 기기에서 링크 접근 확인 |
음성이나 영상이 프로젝트 안에 들어 있는지, 외부 저장 위치를 가리키는 링크인지도 구분해야 합니다. 외부 링크라면 기기를 바꾼 뒤에도 같은 권한으로 열리는지 확인해야 합니다.
학교 정책이 클라우드 보관을 허용하지 않거나, 대용량 자료 링크가 안정적으로 복구되지 않는다면 로컬 데스크톱 프로젝트와 통제된 전송 경로를 유지해야 합니다. 원본 인터뷰 자료는 읽기 전용으로 따로 보관하고, 원격 환경에는 비식별화 표본만 올리는 방식이 안전합니다.
주의: 연구 자료의 비식별화는 파일 이름만 바꾸는 작업이 아닙니다. 문서 본문, 음성, 영상, 메모, 링크 권한에 남은 식별 정보까지 확인한 뒤 원격 검수를 시작해야 합니다.
[ SECTION_04 ] 실험실에 맥이 없을 때 원격 데스크톱을 검수하는 방법
원격 맥은 정식 자료를 바로 옮기는 수단이 아니라, 데스크톱 버전의 작업 가능성을 확인하는 시험 환경으로 접근해야 합니다. ATLAS.ti 26 맥 시스템 요구 사항과 사용 허가 활성화 안내를 먼저 확인합니다.
검수 순서는 다음과 같습니다.
- 비식별화 문서와 소량의 표본 자료로 시험 프로젝트를 만듭니다.
- 원격 맥에서 ATLAS.ti 26이 실행되는지 확인합니다.
- 연구 계정과 사용 허가가 정상적으로 활성화되는지 확인합니다.
- 프로젝트 클라우드 또는 프로젝트 전달 경로로 표본을 내려받습니다.
- 문서 열기, 코드 작성, 메모와 분석 기능을 차례로 확인합니다.
- 프로젝트를 다시 내보내 기존 윈도우 또는 리눅스 환경에서 열어 봅니다.
- 결과 파일과 로그아웃 상태를 확인하고 원격 환경의 표본을 정리합니다.
원격 화면이 조작된다는 사실만으로 승인해서는 안 됩니다. 분석 결과가 기존 연구 환경으로 돌아오는지, 계정 사용 허가가 연구팀 정책에 맞는지, 종료 뒤 표본이 남지 않는지가 더 중요합니다.
아래 항목을 모두 확인할 수 있을 때만 정식 흐름을 승인합니다.
- [ ] 비식별화 표본만 원격 환경에 업로드했습니다.
- [ ] ATLAS.ti 26 실행과 계정 사용 허가를 확인했습니다.
- [ ] 프로젝트 내려받기와 열기를 확인했습니다.
- [ ] 문서, 코드, 메모 작업을 확인했습니다.
- [ ] 결과를 기존 플랫폼으로 내보냈습니다.
- [ ] 내보낸 결과의 문서와 코드가 원본과 일치합니다.
- [ ] 원격 환경에서 표본과 로그인 흔적을 정리했습니다.
- [ ] 공식 사용 허가와 학교 자료 정책을 담당자가 확인했습니다.
현재 단계에서 실제 원격 조작 시간이나 처리 속도를 일반적인 성능으로 해석해서는 안 됩니다. 그런 수치는 노드, 네트워크, 프로젝트 크기와 자료 유형에 따라 달라지므로, 본문에서는 별도 실측 자료가 없는 한 제시하지 않습니다.
[ SECTION_05 ] 네 경로의 최종 점수와 방출 조건
연구팀이 선택지를 빠르게 좁힐 수 있도록 기능 점수가 아니라 장면 적합도로 평가합니다. 점수는 5점 만점이며, 모든 상황에서 우수하다는 뜻이 아니라 해당 장면에서의 출발점입니다.
| 경로 | 개인 이어하기 | 비동기 분업 | 실시간 협업 | 데스크톱 병합 |
|---|---|---|---|---|
| 프로젝트 클라우드 | 5점 | 4점 | 1점 | 2점 |
| ATLAS.ti 웹 | 3점 | 4점 | 4점 | 2점 |
| 프로젝트 패키지 병합 | 3점 | 5점 | 1점 | 5점 |
| 원격 맥 데스크톱 | 4점 | 3점 | 2점 | 5점 |
이 점수는 공식 기능의 우열이 아니라 검수 목적에 따른 운영 판단입니다. 프로젝트 클라우드는 개인의 맥과 윈도우 전환에 강하지만, 실시간 공동 편집에는 맞지 않습니다. 프로젝트 병합은 코더 일치도와 데스크톱 분석에 적합하지만, 작업 규칙과 주 프로젝트 관리가 필요합니다.
연구팀의 결정은 다음처럼 정리할 수 있습니다.
- 한 사람이 기기를 바꾸며 작업하면 프로젝트 클라우드를 검수합니다.
- 여러 사람이 온라인에서 동시에 코딩하면 ATLAS.ti 웹을 검토합니다.
- 코더별 독립 결과를 분석하면 하나의 주 프로젝트와 병합 절차를 사용합니다.
- 맥 전용 기능이 필요한데 실험실에 맥이 없으면 비식별화 표본으로 원격 맥을 먼저 검수합니다.
- 민감 자료의 클라우드 보관이 승인되지 않으면 로컬 프로젝트와 통제된 전송을 유지합니다.
[ SECTION_06 ] 자주 확인하는 질문
질문과 답변은 메타데이터에도 정리했습니다. 특히 프로젝트 클라우드의 동시 편집 제한, 맥과 윈도우의 이어하기, ATLAS.ti 웹과 데스크톱 사이의 가시성, 코더 결과 병합, 맥이 없는 실험실의 원격 검수 범위를 구분해서 확인해야 합니다.
현재 방식이 윈도우 또는 리눅스만으로 구성되어 있다면, 맥 전용 데스크톱 분석을 위해 별도 장비를 구매하는 선택에는 초기 비용, 관리 책임, 사용하지 않는 기간의 유휴 비용이 따릅니다. 반대로 원격 맥은 네트워크 지연, 계정 사용 허가, 자료 반출 정책, 기관 보안 검토를 해결해야 합니다. 장기간 매일 대용량 자료를 처리하거나 물리 포트와 로컬 저장 장치가 필요하다면 구매가 더 적합할 수 있습니다.
아직 정식 배포를 결정하지 못한 연구팀이라면, 맥 대여 비용과 선택 기준을 먼저 비교하고, 연구용 원격 맥 검수 기준과 같은 운영 조건도 함께 확인하는 편이 좋습니다. NOVAKVM의 원격 맥은 실제 연구 자료를 바로 옮기는 대안이 아니라, 비식별화 프로젝트로 업로드, 코딩, 병합, 내보내기를 한 번 검수해 보는 임시 환경으로 접근하는 것이 적절합니다. 이를 통해 장기 배포가 필요한지, ATLAS.ti 웹 중심으로 전환할지, 기존 윈도우·리눅스 장비를 유지할지 판단할 수 있습니다.