KCI 투고 전 사전 검증 자동화 사례

소개

KCI 등재 학술지에 투고하기 전, 심사위원이 지적할 만한 약점을 미리 찾고 싶었습니다.


진행 방법

Claude Code(AI)로 직접 검증 자동화를 시도했습니다.

1. 인용 문헌을 실제 웹 DB와 직접 대조해서 서지오류 찾기

2. 논문 초록·본문·표·결론을 교차 비교해서 내부 불일치 찾기

3. 발견 내용을 체계적인 검토보고서(.docx)로 자동 생성하기

사용한 도구

- Claude Code (AI 에이전트) — 논문 분석, 웹 검증, 코드 생성

- Node.js + docx 라이브러리 — 검토보고서 자동 생성

- Python (xml.etree) — 논문 원본 docx에 수정 내용 직접 반영

전체 흐름

논문 원본 업로드

[1단계] Claude Code가 논문 전문 분석

[2단계] 인용 문헌 7건을 Cambridge Core / Tandfonline / Sagepub / MDPI 등에서 직접 웹 대조

[3단계] 초록↔본문↔표↔결론 교차 비교 (수치·지명·연도·방법 개수 등)

[4단계] Node.js로 검토보고서(.docx) 자동 생성

[5단계] Python으로 논문 원본 XML에 수정 내용 직접 주입 → 수정안 완성

---

사용한 주요 프롬프트

[프롬프트 1 — 검증 기준 설정]

이 논문은 내가 직접 운영한 사업을 연구한 실천가 연구(practitioner research)야.

KCI 등재 학술지 투고 전에, 심사위원이 지적할 만한 약점을 미리 전부 찾아줘.

검증 우선순위:

1. 인용 문헌의 서지정보가 실제와 일치하는지 (허위 인용 여부 포함)

2. 초록·본문·표·결론 사이의 수치·지명·연도 불일치

3. 선언한 연구방법이 결과에 실제로 구현되었는지

각 오류를 중대/보통/경미로 등급 분류하고,

발견 근거(논문의 어느 위치 vs 실제 확인값)를 표로 정리해줘.

[프롬프트 2 — 인용 웹 대조]

아래 인용 문헌들을 Cambridge Core, Tandfonline, Sagepub, MDPI, ResearchGate에서

직접 검색해서 실제 서지정보(권·호·페이지·학술지명)와 논문 표기를 비교해줘.

불일치가 있으면 실제 확인값을 명시하고, 검증에 사용한 URL도 함께 알려줘.

[프롬프트 3 — 보고서 자동 생성]

지금까지 찾은 모든 오류를 정리해서 학술지 투고용 검토보고서 docx를 만들어줘.

형식:

- 표지(논문명, 저자, 검토일, 목적)

- 검증 기준 (3가지 우선순위 표)

- 종합 판정 요약 (영역별 오류 건수, 중대/보통/경미)

- 기준별 상세 검증 결과 (표 형식, 등급별 색상 구분)

- 우선순위순 수정 권고 8개 항목

- 검증에 사용한 출처 URL 목록

Node.js + docx 라이브러리로 코드 작성해줘.

[프롬프트 4 — 수정안 자동 반영]

검토보고서의 '중대' 등급 오류를 논문 원본 docx에 직접 반영하고 싶어.

docx를 unzip해서 document.xml을 파이썬으로 수정하는 방식으로 해줘.

수정 방법:

- 확실히 맞는 수정(서지정보 오류 등): 파란색 텍스트로 교체

- 저자가 판단해야 할 항목: 빨간색 【검토 노트】 삽입

18개 수정 항목을 XML replace 방식으로 처리하고,

완료 후 XML well-formedness 검증까지 실행해줘.

---

검증 스크린샷 (웹 대조)

아래는 Claude Code가 각 인용 문헌을 직접 웹에서 확인한 캡처입니다.

▎ check1.jpg — Darcy 외(2021) Cambridge Core 확인 / 실제 28권 308-328쪽 확인

▎ check3.jpg — Leahy & Ferri(2023) Tandfonline 확인 / Disability & Society 게재 확인

▎ chk_refs.jpg — 참고문헌 orphan 문헌 대조

(파일 위치: 같은 폴더의 check1.jpg, check1b.jpg, check3.jpg, check4b.jpg, chk_refs.jpg)

결과와 배운 점

등급 분류가 핵심입니다. 중대/보통/경미로 나누니 수정 우선순위가 명확해졌습니다. 모든 걸 다 고치려 하면 오히려 시간이 더 걸립니다.

- 파란색(확정) vs 빨간색(검토 필요) 구분이 실용적이었습니다. 저자가 바로 Accept/Reject 결정을 내릴 수 있어서 효율적입니다.

- XML 직접 수정 방식은 강력하지만 위험합니다. 반드시 xml.etree.ElementTree로 well-formedness 검증을 마지막에 실행하세요. 파일이 깨지면 복구가 어렵습니다.

도움 받은 글

ai논문 수업 시간에 도움받은 것들로 시도해봤어요~

감사합니다.

1
밀어주고 끌어주는

온·오프라인 AI 스터디

AI로 어디까지 할 수 있는지
직접 확인하실 분만 신청하세요.