같은 논문이 두 개 저장돼 있는데 한쪽에는 메모, 다른 쪽에는 초록이 있다고 해 볼게요. 제목만 보고 하나를 삭제하면 무엇을 남겼는지 확인하기 어려워져요. 공동 문헌조사에서는 ‘항목 수를 줄였다’보다 서지정보를 바로잡고 팀이 남긴 기록을 보존했는지가 중요해요.
첨부 링크는 이 글의 예제 ZIP으로 연결돼요. 압축을 푼 뒤 링크에 표시된 파일을 열면 입력·코드·완성 자료를 함께 사용할 수 있어요.
이번 예제는 Pautasso의 공개 논문 하나를 바탕으로, 날짜 오류와 서로 다른 메모를 의도적으로 넣은 테스트 항목 A·B예요. 실제 팀 라이브러리가 아니라 합성 실습 자료예요. 항목 JSON (ZIP: test-items.json), 필드 결정표 (ZIP: field-decisions.csv), 병합 후 기대 결과 (ZIP: expected-merged.json)를 제공해요. 이 입력을 Zotero 10.0.6 Linux의 격리 프로필에서 실제 앱 내부 API로 병합해 날짜·초록·메모·첨부 관계를 확인했어요. 메뉴를 클릭한 시험과는 구분해 결과를 설명할게요.
중복 후보와 같은 문헌을 구분해요
Zotero의 Duplicate Items는 후보를 찾는 출발점이에요. 공식 중복 탐지 안내는 제목·DOI·ISBN 등을 사용하고, 중복 탐지는 같은 라이브러리 안에서 이루어진다고 설명해요. 서로 다른 그룹 라이브러리의 자료가 하나의 중복 목록에 자동으로 모이는 방식은 아니에요.
후보를 찾으면 원출처의 제목·저자·식별자·판본을 대조해요. 같은 제목이어도 개정판이나 다른 자료일 수 있으므로 곧바로 병합하지 않아요. 이번 A·B는 DOI 10.1371/journal.pcbi.1003149, 저자 Marco Pautasso, 제목이 같은 하나의 논문으로 만들었어요. PLOS 원출처의 발행연도 2013과 대조하면 A의 2012가 잘못됐음을 확인할 수 있어요.
실무에서 제목은 같은데 식별자가 다르다면 우선 확인 대기로 남겨요. 자료별 원문과 발행 정보를 확인한 뒤 같은 문헌의 중복 항목인지, 서로 연결만 해야 할 다른 판본인지 결정해요. 후보를 줄이기 위해 서로 다른 자료를 합치면 인용과 메모의 맥락이 섞일 수 있어요.
대표 항목 하나를 고르는 일과 보존 목록을 분리해요
A에는 날짜 오류, 빈 초록, A팀 메모와 텍스트 첨부가 있어요. B에는 올바른 날짜, 합성 실습 요약, B팀 메모와 다른 첨부가 있어요. 태그와 컬렉션도 각각 team-a/review-a, team-b/review-b로 다르게 만들었어요. 초록 필드의 문장은 원논문의 초록을 복사한 것이 아니라 실습용임을 표시한 요약이에요.
대표 항목은 B로 선택하는 안을 정했어요. 하지만 B를 고른다는 것이 A의 기록은 불필요하다는 뜻은 아니에요. 날짜는 2013 한 값으로 확정하고, 초록은 B의 값을 남길 대상으로 지정해요. 메모 두 개·첨부 두 개·태그 두 개·컬렉션 관계 두 개는 각각 보존 확인 대상이에요. 필드 하나를 선택하는 일과 자식 자료를 보존하는 일을 한 문장으로 뭉뚱그리지 않는 편이 좋아요.
공식 안내는 중복을 삭제하기보다 병합하도록 권하고, 병합 시 컬렉션과 태그가 유지되며 충돌하는 필드를 선택할 수 있다고 설명해요. 다만 “어떤 필드의 모든 값이 항상 자동 보존된다”로 넓혀 읽으면 안 돼요. 서로 다른 초록 두 개를 모두 참고해야 한다면 각각의 내용을 출처를 붙인 메모로 보존할지 먼저 정하고, 최종 초록 필드에는 어떤 값을 둘지 명시하세요.
앱에서는 한 쌍을 먼저 처리하고 보존을 확인해요
실행할 때는 기존 팀 자료와 분리한 테스트 라이브러리에서 A·B를 먼저 만들어 보세요. JSON은 이 예제의 입력 명세이며 Zotero의 자동 가져오기 파일이라고 보장한 형식은 아니에요. 항목 유형을 journal article로 만들고 제공된 제목·저자·DOI·날짜를 입력한 뒤, 각 메모와 텍스트 첨부를 추가하면 돼요. 일반 자료를 실습에 쓰기 어렵다면 이 작은 입력만으로 충돌 처리를 확인할 수 있어요.
같은 라이브러리에서 중복 후보를 선택한 뒤 대표 항목과 필드별 값을 확인하고 Merge Items로 병합하는 순서는 공식 병합 안내에 나와 있어요. 병합 후에는 대표 항목 수만 보지 말고 체크 기록의 각 행을 확인해요. 날짜와 초록의 정확한 값, 두 메모 본문, 두 첨부가 실제로 열리는지, 각 컬렉션에서 같은 항목이 보이는지를 대조해야 해요.
특히 초록은 추측하지 않아야 해요. 2026년 5월의 공식 포럼 대화에서는 병합할 때 초록이 어떻게 보이는지와 보존되는지에 대한 잘못된 AI 답변이 정정됐어요. 그 대화는 당시 문제를 확인하는 근거이며 현재 사용 중인 판본에서도 같은 버그가 남았다는 증거는 아니에요. 사용 판본을 적고 이번 테스트의 실제 결과를 확인해야 해요.
기대값을 실제 API 관측과 대조했어요
merge-checks.csv (ZIP: merge-checks.csv)에는 기대값과 실제 관측값을 분리했어요. 격리 프로필에서 B를 대표로 선택해 A를 병합한 결과, 날짜2013과 B의 합성 초록이 유지됐어요. 두 메모 본문, 두 텍스트 첨부의 경로와 새 부모 관계, 두 태그와 두 컬렉션 관계도 남았고 A는 휴지통 상태가 됐어요. 실제 전후 값은 zotero-native-run.json (ZIP: zotero-native-run.json)에 있어요.
검증은 임시 앱의 시작 직후 스크립트를 호출해 Zotero의 병합 API를 실행하는 방식이었어요. 계측용 시작 훅을 추가했지만 병합 구현과 데이터 모형은 바꾸지 않았으며 원본·실행본의 병합 구현 해시가 같았어요. 사용자 라이브러리는 접근하지 않았어요. 첨부의 경로·부모 관계는 확인했지만 앱에서 파일을 여는 동작까지 시험하지는 않았어요. 재현용 JavaScript는 실행 기록으로 제공하며 일반 라이브러리에 바로 적용하는 도구가 아니에요.
설치 가능성은 공식 설치 문서에서 확인했어요. Linux는 공식 배포 압축파일을 풀어 실행하는 경로가 있고 Windows 설치 안내도 제공돼요. 이 작업에서는 공식 Linux 배포본을 별도 위치에서 실행해 위 한 쌍의 앱 내부 병합을 검증했어요. GUI 메뉴 순서, PDF 주석, 워드프로세서 인용 갱신, 동기화는 시험하지 않았어요. 따라서 이 결과를 기존 라이브러리의 모든 자료 유형이나 대량 병합에 대한 보장으로 넓히면 안 돼요.
필드가 예상대로 남지 않거나 판본 차이로 메뉴가 다르면 대량 처리를 멈추고 한 쌍의 입력·기대값·실제 결과부터 기록하세요. 당장 앱 검증이 어렵다면 문헌을 삭제하지 않고 식별자와 충돌 필드 결정표만 정리해도 다음 작업의 기준이 생겨요. 완성된 결정표는 판단의 기록이고, 실제로 정리된 라이브러리는 별도의 확인 대상이에요.
2026년 10월 13일에 공식 문서와 원출처를 확인했어요. 이 글은 병합 전 판단, 실제 격리 API 실행의 전후 값, 미검증 범위를 함께 제공해요. 앱의 판본이나 다루는 첨부 유형이 달라지면 작은 한 쌍으로 다시 확인하세요.
작성·확인: Codex가 공개 원문 또는 공식 문서를 확인하고 예제와 초안을 작성했어요. 사람을 대상으로 한 사용성 검증은 수행하지 않았어요.
설명 삽화 2장은 GPT로 생성한 개념 설명이에요. 실제 예제의 작업 화면과 실행 결과는 기존 그림·첨부 자료에서 따로 확인할 수 있어요.