내가 쓴 논문 리뷰하는 위키 만들기 실험

왜 이 실험을 시작했나

논문을 쓰다 보면 가장 답답한 질문이 있다.

“리뷰어가 이 논문을 보면 어디를 찌를까?”

AI에게 논문을 읽히면 지적은 많이 받을 수 있다. 문장이 어색하다, 초록이 과장됐다, 방법 설명이 부족하다, 한계가 약하다 같은 말은 금방 나온다.하지만 지적이 많다고 좋은 평가자는 아니다. AI가 전문가처럼 말해도, 실제 사람 리뷰어가 중요하게 볼 문제를 잡았는지는 알 수 없다.

나는 리뷰어의 시선을 완전히 알고 있는 사람이 아니다. 그래서 AI가 만든 평가 기준을 내 감으로만 고르면 위험했다. 비교할 실제 기준이 필요했다.

이번 작업의 질문은 이렇게 바뀌었다.

“리뷰어가 실제로 무엇을 지적했는지 공개된 논문을 모아, AI 평가 기준이 그 시선과 얼마나 맞는지 확인해보자.”

즉, 목표는 “AI 논문 리뷰어 완성”이 아니었다. 먼저 AI가 들고 있는 평가 기준 자체를 검증하는 것이었다.

(참고로 이 작업을 시작하기전에 22기 리서치하네스 스티디원 생강님의 칼날위키를 벤치마킹을 밝힌다 ㅎㅎ)

먼저 이 글에 나오는 용어를 쉽게 풀면

어떤 도구로 작업했나

이 작업은 한 번에 끝난 “AI에게 논문 리뷰를 시킨 실험”이 아니었다. 여러 도구를 역할별로 나눠 썼다.

가장 중심이 된 작업 환경은 Claude Code 계열의 코딩 에이전트 세션이었다. 여기서 폴더 구조를 만들고, 평가 기준 파일을 정리하고, 원고와 리뷰 문서를 비교하고, 결과를 기록했다. 다만 한 모델에게 모든 일을 한꺼번에 맡기지는 않았다.

역할은 대략 이렇게 나눴다.

이렇게 나눈 이유는 단순했다. 같은 AI가 기준을 만들고, 같은 자료를 보고, 다시 “내 기준이 맞다”고 판정하면 결과가 쉽게 부풀려진다. 그래서 구조를 짜는 일, 원고를 읽는 일, 정답지와 대조하는 일을 가능한 한 분리했다.

특히 중요한 원칙은 이것이었다.

AI 평가자(서브에이전트)는 사람 리뷰어의 지적을 먼저 보면 안 된다.

그래서 원고 평가를 맡은 AI 평가자(서브에이전트)에게는 사람 리뷰어의 지적을 넣지 않았다. 먼저 원고만 보고 “어디가 문제일지” 예측하게 한 뒤, 나중에 사람 리뷰어의 실제 지적과 대조했다. 도구를 많이 쓴 이유도 멋져 보이기 위해서가 아니라, 이 오염을 줄이기 위해서였다.

이 과정에서 중요했던 것은 거대한 코드가 아니었다. 오히려 작은 파일 계약과 변환 절차가 핵심이었다.

리뷰 전 원고 PDF
→ 텍스트 추출
→ manuscript.txt
→ AI 평가자(서브에이전트)에게 이것만 전달

사람 리뷰어의 실제 지적
→ reviews.md
→ AI 평가 전에는 숨김
→ AI 평가 후 대조 단계에서만 사용

영어 표현 예시쌍
→ pairs.yaml        # 정답지
→ eval-input.md     # 라벨을 가린 평가자 투입본
→ 평가 결과와 정답지 대조

예를 들어 첫 공개 리뷰 논문은 리뷰 전 원고 PDF를 텍스트로 바꿔 manuscript.txt를 만들었다. 두 번째 논문은 출판사 쪽 변환이 잘 맞지 않아, 공개 논문 저장소의 구조화된 원문에서 전문을 뽑는 경로를 썼다. 영어 표현 평가는 더 엄격하게 나눴다. 정답이 들어 있는 pairs.yaml과 평가자에게 보여줄 eval-input.md를 분리해, 평가자가 답을 미리 보지 못하게 했다.

이 작은 파일 구조 덕분에 “AI가 그럴듯하게 평가했다”가 아니라 “AI가 무엇을 보고 판단했고, 무엇은 보지 못했는지”를 추적할 수 있었다.

0단계: 첫 평가 기준은 어디서 왔나

비교할 논문을 찾기 전에 먼저 1차 평가 기준이 필요했다. 아무 기준 없이 AI에게 “논문을 평가해줘”라고 하면, 결과는 그럴듯한 조언 모음이 되기 쉽다.

초기 기준은 내가 갖고 있던 논문 작성 강의록에서 출발했다. 특히 다음 세 가지 자료가 뼈대가 됐다.

1. 한국인 저자가 영어 원고에서 자주 하는 오류
   문장 구조, 주어-동사 일치, 장황한 표현, 단어 선택, 수식어 위치처럼 영어 원고에서 반복되는 문제를 뽑았다.

2. 리뷰어 코멘트에 대응하는 법
   리뷰어가 실제로 무엇을 문제 삼는지 거꾸로 읽었다. 예를 들어 “결과가 결론을 뒷받침하기에 충분한가”, “연구 범위가 명확한가”, “방법 선택에 근거가 있는가” 같은 질문이 여기서 나왔다.

3. 좋은 초록과 커버레터를 쓰는 법
   초록이 본문 없이도 이해되는지, 본문에 없는 내용을 넣지 않았는지, 핵심 결과를 숨기지 않았는지 같은 기준을 만들었다.

처음에는 이 자료들에서 리뷰어 관점, 초록, 영어 표현, 커버레터 기준을 함께 뽑았다. 하지만 곧 정리가 필요했다. 커버레터는 에디터에게 원고를 소개하고 설득하는 글이라, 원고 본문 자체를 평가하는 기준과 성격이 달랐다. 그래서 이번 원고 평가 기준에서는 빼고, 별도 작업으로 분리했다.

또 모든 자료를 다 넣지는 않았다. AI 윤리, 표절, 패러프레이징, 그래픽 초록처럼 중요한 주제라도 이번 “원고 평가 기준”과 직접 맞지 않는 자료는 제외하거나 보류했다. 기준을 많이 넣는 것보다, 지금 검증하려는 목적에 맞게 좁히는 것이 먼저였다.

그래서 이 단계에서 원고 평가 기준으로 남긴 1차 구조는 이랬다.

커버레터는 중요하지만, 이 표에는 넣지 않았다. 이번 실험의 비교 대상은 “원고 본문을 AI가 어떻게 평가하느냐”였기 때문이다.

이 기준은 아직 완성된 도구가 아니었다. 강의록에서 뽑은 “후보 기준”에 가까웠다. 그래서 다음 단계가 필요했다. 실제 사람 리뷰어의 지적과 비교해, 이 후보 기준이 어디까지 맞고 어디서 비는지 확인해야 했다.

1단계: 비교할 수 있는 논문부터 찾았다

AI 평가를 검증하려면 비교할 기준이 있어야 한다. 이번 작업에서는 실제 사람 리뷰어의 지적을 기준으로 삼고 싶었다.

그러려면 세 가지가 필요했다.

1. 리뷰어가 보기 전의 논문 원고

2. 리뷰어가 남긴 지적

3. 지적을 반영한 뒤의 논문이나 공개 기록

이 세 가지가 있어야 AI가 원고만 보고 먼저 지적한 내용과, 실제 사람 리뷰어가 지적한 내용을 비교할 수 있다.

문제는 이런 자료가 흔하지 않다는 점이다. 유명 저널이라고 해서 사람 리뷰어의 지적이 모두 공개되는 것은 아니다. 많은 저널은 리뷰 내용을 공개하지 않는다.

그래서 자료를 찾을 때 기준을 세웠다.

• 사람 리뷰어의 지적이 공개되어 있는 출판사나 저널인가?

• 리뷰 전 원고와 리뷰 후 논문의 흐름을 확인할 수 있는가?

• 너무 주변적인 사례가 아니라, 어느 정도 저명하거나 신뢰할 만한 논문인가?

• 논문 버전이 꼬여 있지 않은가?

쉽게 말하면, AI를 채점할 수 있는 “답안지와 채점표가 같이 남아 있는 논문”을 찾은 것이다.

2단계: 출판된 논문만 보면 불공정할 수 있었다

처음에는 공개된 논문과 리뷰어 코멘트를 비교하면 될 것처럼 보였다. 하지만 곧 문제가 드러났다.

출판된 논문은 이미 사람 리뷰어의 지적을 반영해 고쳐진 결과물일 수 있다. 그렇다면 AI가 출판본을 읽고 어떤 문제를 못 찾았다고 해서, 바로 AI가 부족하다고 말할 수 없다. 그 문제는 이미 고쳐져서 사라졌을 수 있기 때문이다.

예를 들어 리뷰어가 “통계 방법 설명이 부족하다”고 지적했고, 저자가 그 설명을 출판본에 추가했다고 하자. 그러면 출판본만 읽은 AI는 그 문제를 지적하지 않는 것이 자연스럽다.

그래서 비교할 때는 반드시 버전을 맞춰야 했다.

• AI가 읽은 문서가 리뷰어가 본 문서와 같은가?

• 이미 고쳐진 논문을 기준으로 삼고 있지는 않은가?

• 사라진 문제를 AI에게 다시 맞히라고 요구하는 것은 아닌가?

여기서 첫 번째 원칙이 나왔다.

AI 평가를 검증하려면, AI가 읽는 문서와 리뷰어가 읽은 문서가 같거나, 최소한 차이를 알고 있어야 한다.

만약 리뷰 후 논문만 쓸 수 있다면, 사람 리뷰어의 지적을 두 종류로 나눠야 했다.

• 지금 논문에도 남아 있어서 AI가 볼 수 있는 지적

• 리뷰 과정에서 이미 고쳐졌을 가능성이 큰 지적

이 구분을 하지 않으면 숫자는 나와도 의미가 흐려진다.

3단계: 첫 점수는 낮았지만, 그래서 더 중요했다

초기 평가 기준으로 첫 논문을 평가했을 때, 실제 사람 리뷰어의 지적을 많이 잡지는 못했다. 회수율은 대략 21–36% 수준이었다. 겉으로 보면 실패다. 하지만 자세히 보니 이 낮은 점수가 오히려 다음 길을 알려줬다.

AI가 놓친 지적 중 상당수는 단순한 글쓰기 문제가 아니었다. 연구 설계와 통계, 분석 방식에 가까운 문제였다.

예를 들면 이런 질문이다.

• 비교해야 할 위험을 제대로 나눠 봤는가?

• 결과에 영향을 주는 다른 변수를 충분히 고려했는가?

• 분석을 시작하는 시점을 올바르게 잡았는가?

• 특정 집단에서 나온 결과를 너무 넓게 일반화한 것은 아닌가?

• 분석 방법이 연구 질문과 맞는가?

초기 평가 기준은 주로 글의 구조와 표현을 보는 쪽에 가까웠다. 그러니 이런 연구 설계 문제를 놓치는 것은 이상한 일이 아니었다.

이 결과는 “AI가 못한다”가 아니라 “평가 기준에 연구 설계와 통계 축이 빠져 있다”는 신호였다.

여기서 중요한 선택을 했다. 빠진 지적을 그대로 베껴 새 기준으로 넣지 않았다. 그렇게 하면 첫 논문에는 잘 맞을 수 있지만, 다른 논문에도 통할지는 알 수 없다.

대신 관찰연구 보고 기준(e.g. STROBE checklist)처럼 널리 쓰이는 정식 기준을 참고해 연구설계 평가 축을 만들었다. 답안지를 보고 외운 것이 아니라, 빠진 분야를 발견하고 그 분야의 표준 기준에서 새 평가 축을 만든 것이다.

4단계: 하나의 AI가 다 보는 구조를 버렸다

이때 중요한 구조 전환이 있었다.

처음에는 하나의 AI가 모든 기준을 들고 논문 전체를 평가하는 그림에 가까웠다. 하지만 실제 논문 평가는 한 덩어리가 아니었다. 여기서 말하는 평가자는 실제로는 역할별로 나눈 서브에이전트에 가깝다.

• 문장과 표현을 보는 AI 평가자(서브에이전트)

• 초록이 본문과 맞는지 보는 AI 평가자(서브에이전트)

• 연구 설계와 통계를 보는 AI 평가자(서브에이전트)

• 주장 범위와 한계를 보는 AI 평가자(서브에이전트)

각 AI 평가자(서브에이전트)는 보는 지점이 다르다. 어떤 문제는 한 문장만 보면 된다. 어떤 문제는 방법 섹션 전체를 봐야 한다. 어떤 문제는 논문 전체의 주장과 결과를 함께 봐야 한다.

그래서 구조를 바꿨다.

하나의 거대한 AI 평가자가 아니라, 평가 축마다 다른 AI 평가자(서브에이전트)를 두자.

5단계: 두 번째 논문으로 “외운 기준”인지 확인했다

새로 만든 연구설계 평가 축이 첫 논문에만 맞춘 기준일 수도 있었다. 그래서 두 번째 논문이 필요했다.

연구설계 평가 축은 두 번째 논문에서도 꽤 잘 작동했다. 기록상 현재 논문에서도 확인 가능한 지적 기준으로 94–100% 수준을 잡았다. 중요한 것은 첫 번째 논문에 없던 쟁점도 잡았다는 점이다. 이것은 첫 논문 답지를 외운 기준이 아니라, 어느 정도 다른 논문에도 통하는 기준이라는 신호였다.

물론 논문 두 편은 아직 작다. 그래서 이 결과를 “완성”이라고 부르면 안 된다. 더 정확히는 이렇게 말하는 편이 맞다.

첫 논문에만 맞춘 기준은 아닌 것으로 보인다. 다만 더 많은 논문으로 검증해야 한다.

6단계: 영어 문장 평가는 다른 정답지가 필요했다

다음 문제는 영어 표현 평가였다. 문장이 장황한지, 표현이 부정확한지, 구두점이 맞는지 같은 항목이다.

처음에는 이것도 사람 리뷰어의 지적으로 검증하면 될 것 같았다. 하지만 실제로는 잘 맞지 않았다.

사람 리뷰어는 보통 문장 표현을 하나하나 다 지적하지 않는다. 의학·과학 논문 리뷰에서는 연구 설계, 분석, 결과 해석, 한계 같은 내용을 더 많이 본다. 이미 영어 퀄리티가 낮은 경우 리뷰 전 단계에서 지적받기도 한다. 그러니 사람 리뷰어의 지적을 정답지로 삼으면 영어 표현 기준은 검증하기 어렵다.

그래서 영어 표현 평가는 별도 정답지를 만들었다.

이번에는 권위 있는 작법 자료에서 “나쁜 문장 → 고친 문장” 예시쌍을 모았다. 예를 들어 대학 글쓰기 센터, 저널 출판사 자료, 의학 작문 매뉴얼처럼 실제로 문장 수정 예시가 있는 자료를 썼다.

(특히 많이 인용한 작법 자료는 "Grammar | AMA Manual of Style: A Guide for Authors and Editors 11판" 이다).

여기서도 안전장치를 뒀다.

• 기준을 뽑은 자료와 검증 자료가 서로 겹치지 않게 한다.

• AI 평가자는 고친 답을 보지 않고 문장만 본다.

• 애매한 문항은 억지로 통과시키지 않는다.

• 한 자료에만 기대지 않고 여러 출처에서 예시를 나눠 가져온다.

첫 평가에서는 나쁜 문장을 모두 잡았지만, 좋은 문장을 문제라고 잘못 잡은 경우가 일부 있었다. 흥미롭게도 그 오탐 중 일부는 AI의 실수만이 아니었다. 정답지 예시 자체가 애매하거나, 설명이 부족한 경우도 있었다.

즉, 평가는 AI만 검사한 것이 아니라 정답지의 품질도 같이 검사했다.

그 뒤 예시를 고치고, 비어 있던 문항을 보강하고, 다시 평가했다. 두 번째 평가에서는 좋은 문장을 잘못 잡는 문제가 0%로 줄었고, 영어 표현 기준은 독립 평가 축으로 승격됐다.

단, 한 문항은 보류했다. 표현 판단이 미국식/영국식, 격식 수준, 문맥에 따라 갈리는 경우였다. 이런 문항은 억지로 정답지를 만들면 오히려 기준이 흔들린다.

여기서 나온 원칙은 이것이다.

정답이 갈리는 문항은 억지로 채택하지 않는 것이 더 정직하다.

계속 지킨 원칙: 평가자가 정답을 보면 안 된다

이번 실험에서 계속 지킨 원칙이 하나 있다.

AI 평가자는 정답지를 보면 안 된다.

AI에게 원고와 사람 리뷰어의 지적을 같이 보여준 뒤 “무엇을 맞혔는지 말해봐”라고 하면, 그것은 평가가 아니다. 이미 답을 보고 해설하는 것이다.

그래서 평가 과정을 분리했다.

1. AI 평가자는 원고만 보고 먼저 문제를 찾는다.

2. 다른 쪽에서 실제 사람 리뷰어의 지적과 비교한다.

3. 영어 표현 평가는 문장과 평가 기준만 주고, 정답 예시는 보여주지 않는다.

4. “정답 파일 읽지 마”라고 말로만 막지 않고, 아예 평가 프롬프트에 필요한 것만 넣는다.

이 방식은 번거롭다. 하지만 공정한 평가에는 필요하다.

모델이 똑똑한지보다 먼저 봐야 할 것이 있다. 평가자가 답을 미리 보지 않았는가. 이 조건이 무너지면 결과 숫자는 믿기 어렵다.

결과: 체크리스트가 아니라 검증 루프가 생겼다

이번 실험으로 만들어진 것은 “논문 평가 체크리스트” 하나가 아니다. 더 정확히는 평가 기준을 검증하고 키우는 작은 시스템이다.

실제 위키 골격은 이런 식으로 나뉘었다. 내부 관리 폴더는 빼고, 독자가 이해할 수 있는 핵심 구조만 적으면 다음과 같다.

PaperEval/
├── lenses/          # 검증을 통과했거나 검증 중인 평가 기준
│   ├── README.md
│   ├── draft-v0.md
│   └── lang.md
├── theory/          # 기준을 만들 때 참고한 이론·작법 노트
│   ├── k-author-common-errors.md
│   ├── reviewer-comments-response.md
│   ├── abstract-cover-letter.md
│   └── strobe-observational-methods.md
├── gold/            # AI 평가와 비교할 정답지 역할의 자료
│   ├── case-01/
│   │   ├── manuscript.txt
│   │   ├── reviews.md
│   │   └── meta.md
│   ├── case-02/
│   │   ├── manuscript.txt
│   │   ├── reviews.md
│   │   └── meta.md
│   └── lang-case-01/
│       ├── pairs.yaml
│       └── eval-input.md
├── cases/           # 실제 평가 결과와 해석
│   ├── case-01-eval.md
│   ├── case-02-eval.md
│   └── lang-case-01-eval.md
├── writing/         # 영어 표현 평가용 외부 작법 자료 큐레이션
│   └── sources.md
└── feedback-style/  # 이후 피드백·문체 관련 자료를 둘 공간

이 구조에서 중요한 점은 “기준”, “정답지”, “평가 결과”를 같은 폴더에 섞지 않았다는 것이다. 기준은 lenses/, 비교 자료는 gold/, 실제 평가 결과는 cases/에 둔다. 그래야 나중에 기준을 고칠 때도 어떤 자료를 보고 만든 기준인지, 어떤 자료로 검증했는지 추적할 수 있다.

가장 큰 변화는 질문이 바뀐 것이다.

처음 질문은 이것이었다.

“AI가 논문을 리뷰어처럼 봐줄 수 있을까?”

작업 후 질문은 이렇게 바뀌었다.

“어떤 기준으로, 어떤 정답지와 비교하며, 어떤 평가자는 무엇만 보게 할 것인가?”

이 질문에 답하지 않으면 AI 평가는 쉽게 그럴듯한 조언 모음이 된다.

이 사례에서 배운 AI 활용법

1. AI에게 판단을 맡기기 전에 정답지를 먼저 의심해야 한다

평가 자동화에서 가장 위험한 것은 숫자가 빨리 나온다는 점이다. 회수율, 오탐률, 일치율 같은 숫자는 그럴듯하다. 하지만 정답지가 틀렸거나 불공정하면 숫자는 오히려 착시가 된다.

이번에는 다음을 먼저 따졌다.

• AI가 본 문서와 리뷰어가 본 문서가 같은가?

• 이미 고쳐진 논문을 기준으로 삼고 있지는 않은가?

• 정답지가 한쪽 입장에 치우쳐 있지는 않은가?

• 평가자가 정답을 미리 본 것은 아닌가?

• 애매한 문항을 억지로 정답 처리하고 있지는 않은가?

숫자는 그 다음이었다.

2. 낮은 점수는 실패가 아니라 빠진 기준을 알려준다

첫 평가 점수가 낮았을 때 바로 버릴 수도 있었다. 하지만 낮은 점수를 분해해보니 빠진 축이 보였다. 글쓰기 기준은 있었지만 연구설계 기준이 부족했다.

좋은 평가는 성공 점수만 주는 것이 아니다. 어디가 비어 있는지도 알려준다.

3. 사람의 개입은 방해가 아니라 구조를 바꾸는 신호였다

이번 작업에서 사람의 개입은 중요했다.

• 리뷰 전후 논문이 있는 출판사와 저명한 논문 위주로 찾자는 방향이 비교 기준을 잡았다.

• 문법/통계/디자인 요소를 나눠 평가하자는 아이디어가 축별 평가자 구조로 이어졌다.

• 작법 자료에서 추가 기준도 뽑아야 하지 않나 하는 지적이 영어 표현 기준의 후보 확장으로 이어졌다.

AI는 빠르게 찾고 정리하고 비교했다. 하지만 무엇을 공정한 비교로 볼지, 어떤 구조가 맞는지는 사람이 계속 조정했다.

그래서 이 사례는 “AI가 혼자 논문 평가 시스템을 만들었다”가 아니다.

사람은 방향과 판단 기준을 잡고, AI는 탐색·정리·평가·대조를 빠르게 반복한 사례다.

솔직한 한계

이 글에서 가장 조심해야 할 부분도 있다. 나는 논문을 직접 쓰고 읽는 사람이지만, 전문 리뷰어의 시선을 완전히 아는 사람은 아니다. 내가 직접 모든 평가 기준을 만들고 “이게 맞다”고 말할 수 있었다면 가장 좋았겠지만, 현실적으로는 그럴 수 없었다.

특히 영어 표현 평가는 더 그렇다. 나는 비영어권 연구자다. 영어 원고에서 어떤 표현이 자연스럽고, 어떤 표현이 학술적으로 어색한지 판단할 때 내 감만으로는 부족하다. 그래서 논문 작성 강의록, 대학 글쓰기 자료, 출판사 작법 자료, 의학 작문 매뉴얼처럼 외부 자료에 의존할 수밖에 없었다.

이 의존 자체가 나쁜 것은 아니라고 본다. 오히려 내 감으로 기준을 만드는 것보다 낫다. 다만 그 기준 역시 절대적인 정답은 아니다. 어떤 자료에서 가져왔는지, 어떤 문항은 보류했는지, 어떤 기준은 실제 사람 리뷰어의 지적과 맞지 않았는지를 계속 표시해야 한다.

또 하나의 한계는 아직 이 구조를 내가 실제로 쓰는 논문에 적용하지 못했다는 점이다. 지금까지 한 일은 공개 리뷰 논문과 외부 작법 자료를 이용해 평가 기준을 검증하는 초기 실험에 가깝다. 실제 내 원고에 적용했을 때 어느 정도 도움이 되는지, 어느 부분에서 과하게 지적하는지, 연구자 입장에서 받아들일 만한 피드백인지까지는 아직 확인하지 못했다.

그래서 이 글의 결론은 “논문 평가 AI를 완성했다”가 아니다.

내가 직접 다 판단할 수 없는 영역에서, 외부 기준과 공개 자료를 이용해 AI 평가 기준을 검증하는 방법을 만들기 시작했다.