소개
과학 학술 논문에서 통계 오류는 곧 결론의 오류로 이어질 수 있습니다. 그런데 실제 논문 심사 과정에서는 통계 검토가 충분히 이뤄지지 않는 경우가 많고, 통계에 익숙하지 않은 Reviewer가 검토를 맡는 일도 드물지 않습니다.
저는 이 지점이 늘 아쉬웠습니다. 논문의 실험 설계와 결과 해석이 아무리 흥미로워도, 통계 적용과 보고가 잘못되면 연구의 신뢰도 자체가 흔들릴 수 있기 때문입니다. 실제로 여러 문헌에서는 출판된 연구들에서 통계 보고 오류나 분석상의 문제가 반복적으로 발견된다고 지적하고 있고, 일부는 정정이나 논문철회(Retract)로 이어지기도 합니다.
이 문제를 조금이라도 줄이기 위해, 저는 학술 논문의 통계 오류를 Screening하는 AI 앱을 만들어 보기로 했습니다.
처음부터 거창하게 시작한 것은 아니었습니다. 시작은 단순했습니다.
논문을 업로드하면
통계적으로 위험한 지점을 먼저 찾아주고
Reviewer가 빠르게 확인하고 수정할 수 있게 만들자
그렇게 저는 Manus 하나만 사용해서 이 아이디어를 실제 동작하는 형태로 발전시켰습니다. 가장 흥미로웠던 점은, 중간에 다른 AI 툴로 옮겨 가지 않고도 SKILL 설계 → 기능 통합 → 웹앱 구현까지 이어갈 수 있었다는 점입니다.
진행 방법
1. 일반 통계 Review용 SKILL부터 시작
가장 먼저 만든 것은 논문의 일반적인 통계 Review를 수행하는 SKILL이었습니다.
초기 목표는 아래와 같았습니다.
논문에서 사용된 통계 기법이 문맥에 맞는지 확인하기
결과 해석이 과장되거나 비약되지 않았는지 점검하기
보고 형식에서 빠진 요소가 없는지 체크하기
Reviewer가 빠르게 훑어볼 수 있는 형태로 정리하기
처음에는 이 SKILL 하나로도 어느 정도는 동작했습니다. 하지만 실제 논문을 테스트해 보니, 복잡한 분석 유형까지 안정적으로 다루기에는 한계가 있었습니다.
2. 생존분석 특화 SKILL 추가
특히 한계가 뚜렷했던 부분은 생존분석(survival analysis) 이었습니다.
생존분석은 일반적인 평균 비교나 회귀 분석과는 다르게,
절단(censoring)
추적 기간
Kaplan-Meier curve
log-rank test
Cox proportional hazards model
같은 요소를 함께 봐야 하고, 보고의 적절성도 따로 확인해야 합니다.
그래서 두 번째로는 생존분석에 특화된 SKILL을 별도로 만들었습니다.
이 단계에서 느낀 점은, 하나의 거대한 프롬프트로 모든 것을 해결하려 하기보다 분석 유형별로 역할을 분리하는 것이 훨씬 안정적이라는 점이었습니다.
3. 여러 SKILL을 묶는 오케스트라 SKILL 설계
문제는 여기서 끝나지 않았습니다.
일반 통계 Review SKILL과 생존분석 SKILL을 각각 만들어도, 실제 사용 단계에서는 두 SKILL의 결과를 어떻게 조합해서 일관된 리뷰 결과로 보여줄지가 중요했습니다.
이 문제를 해결하기 위해 저는 Manus에게 방향을 물었 고, 그 결과 여러 개의 SKILL을 통합하는 오케스트라 역할의 SKILL을 추가로 만들었습니다.
이 오케스트라 SKILL의 역할은 아래와 같았습니다.
논문의 분석 유형을 먼저 파악하기
일반 통계 Review SKILL과 생존분석 SKILL 중 필요한 흐름을 선택하거나 함께 호출하기
결과를 하나의 리뷰 포맷으로 통합하기
심각도를 기준으로 Reviewer가 먼저 봐야 할 항목을 정리하기
이 구조를 적용한 뒤에는 실제 논문을 업로드했을 때 훨씬 만족스러운 결과를 얻을 수 있었습니다.
4. SKILL만으로는 부족했던 UI 문제
여기까지 오면서 기능 자체는 꽤 만족스러웠지만, 또 다른 문제가 보였습니다.
SKILL 형태의 출력은 Reviewer가 실제 업무에 쓰기엔 UI/입력 방식/출력 형식이 불편했습니다.
예를 들어,
논문 업로드 흐름이 직관적이지 않고
결과를 한눈에 우선순위로 보기 어렵고
사람이 수정/보완하기에 인터페이스가 부족했습니다.
즉, 성능의 문제가 아니라 사용 경험의 문제였습니다.
그래서 이 시점에서 저는 “검토 기능”이 아니라 “검토 앱” 으로 바꿔야겠다고 판단했습니다.
5. Manus의 웹앱 생성 기능으로 전환
이 과정에서 Manus에 웹앱 생성 기능이 있다는 점을 발견했고, 여기서 흐름이 크게 달라졌습니다.
저는 다른 AI 툴을 추가로 사용하지 않고, Manus만으로 웹앱을 구현해 보기로 했습니다.
구현한 웹앱의 주요 기능은 다음과 같습니다.
로그인 기능
대시보드
논문 업로드 기능
업로드된 논문에 대한 자동 통계 Review
결과를 High / Medium / Low severity 기준으로 분류
Reviewer가 결과를 추가 수정할 수 있는 구조
결과를 Markdown 형식으로 저장
High severity 항목의 경우 Editor에게 보낼 letter 초안 작성 지원
이 단계부터는 단순히 “AI가 통계 오류를 찾아주는 실험”이 아니라, 실제 리뷰 워크플로우 안에 들어갈 수 있는 업무형 도구에 가까워졌습니다.
예시 프롬프트 1. 일반 통계 Review SKILL
업로드된 학술 논문을 통계 Reviewer의 관점에서 검토하라.
목표:
1. 연구 설계와 통계 방법의 적절성을 평가한다.
2. 통계 검정 선택이 데이터 구조와 연구 질문에 맞는지 확인한다.
3. 결과 해석이 통계 결과를 과장하거나 잘못 일반화하지 않았는지 점검한다.
4. 보고 누락, 불명확한 표현, 재현성을 떨어뜨리는 요소를 식별한다.
5. Reviewer가 바로 활용할 수 있도록 항목별로 정리한다.
출력 형식:
- Summary
- Major concerns
- Minor concerns
- Suggested questions to authors
- Severity label (High / Medium / Low)
예시 프롬프트 2. Survival Analysis 특화 SKILL
이 논문에서 survival analysis가 사용되었는지 확인하고, 사용되었다면 아래 항목을 집중 검토하라.
검토 항목:
- Kaplan-Meier 분석의 적절성
- log-rank test 사용 맥락
- Cox proportional hazards model 사용 여부와 해석 적절성
- censoring, follow-up time, event definition 보고의 명확성
- hazard ratio, confidence interval, p-value 보고의 일관성
- 결과 해석이 인과 추론으로 과장되지 않았는지 확인
출력 형식:
- Survival-analysis-specific issues
- Missing reporting items
- Potential interpretation risks
- Severity label
예시 프롬프트 3. 오케스트라 SKILL
논문의 통계 분석 유형을 먼저 분류하고,
일반 통계 Review SKILL과 survival analysis SKILL을 적절히 호출하여
최종 Reviewer-friendly report를 작성하라.
규칙:
- 분석 유형이 혼합되어 있으면 두 SKILL의 결과를 통합한다.
- 중복 이슈는 병합한다.
- Reviewer가 먼저 확인해야 할 항목부터 우선순위를 매긴다.
- 각 이슈에 Severity를 부여한다.
- 최종 결과는 Markdown으로 정리한다.
웹앱 구성 메모
[화면 1] 로그인 페이지
[화면 2] 대시보드
[화면 3] 논문 업로드 및 분석 시작 화면
[화면 4] Severity별 리뷰 결과 화면
[화면 5] Editor letter 생성 화면
결과와 배운 점
이번 작업에서 가장 크게 배운 점은 세 가지였습니다.
1. 하나의 큰 프롬프트보다, 역할이 분리된 SKILL 구조가 강했다
처음에는 일반 통계 Review SKILL 하나로 대부분 해결할 수 있을 거라고 생각했습니다. 하지만 실제 논문을 다뤄 보니, 특정 분석 유형까지 일관되게 처리하려면 역할을 나눠야 한다는 사실이 분명해졌습니다.
특히,
일반 통계 검토
생존분석 특화 검토
결과 통합 및 우선순위 정리
이 세 역할을 분리하자 결과의 안정감이 훨씬 좋아졌습니다.
2. 좋은 분석 결과만으로는 부족하고, 좋은 UI가 필요했 다
SKILL 단계에서 이미 의미 있는 결과가 나왔지만, 실제 Reviewer가 사용하기에는 여전히 불편했습니다.
이 경험을 통해 다시 확인한 것은,
좋은 AI 결과와 좋은 제품은 다르다.
Reviewer가 반복적으로 사용하려면,
파일 업로드가 쉬워야 하고
결과가 우선순위별로 보여야 하며
사람이 수정할 수 있어야 하고
저장과 전달까지 자연스럽게 이어져야 합니다.
그래서 결국 웹앱으로 확장한 결정이 매우 중요했습니다.
3. Manus 하나만으로도 실전 수준의 워크플로우를 만들 수 있었다
이번 사례에서 개인적으로 가장 인상 깊었던 부분은 다른 AI 툴 없이 Manus 하나만으로 끝까지 밀어붙일 수 있었다는 점입니다.
SKILL 설계
특화 기능 확장
오케스트라 구조 설계
웹앱 구현
리뷰 결과 저장 포맷 설계
이 흐름이 하나의 환경 안에서 이어지니, 작업 맥락이 끊기지 않았고 수정도 훨씬 수월했습니다.
시행착오 정리
일반 통계 Review SKILL 하나만으로는 성능이 부족했다.
survival analysis처럼 특수 분석은 별도 SKILL이 필요했다.
여러 SKILL을 통합하는 조정자 역할이 없으면 결과가 분산됐다.
SKILL 출력만으로는 Reviewer 친화적인 사용 경험을 만들기 어려웠다.
그래서 최종적으로 웹앱이 필요했다.
앞으로의 계획
앞으로는 아래 방향으로 더 발전시켜 보고 싶습니다.
통계 분석 유형을 더 세분화한 특화 SKILL 추가
Reviewer 피드백을 반영한 severity 기준 정교화
Editor letter 자동화 품질 향상
실제 저널 리뷰 워크플로우에 가까운 협업 기능 보완
이번 작업을 하며 내린 결론은 분명했습니다.
완벽한 자동 판정보다, Reviewer가 놓치기 쉬운 통계 오류를 먼저 드러내는 Screening 도구가 더 현실적이고 강력하다.
그리고 그런 도구는 생각보다 빠르게, 그리고 생각보다 실용적인 수준으로 만들 수 있었습니다.
도움 받은 글 (옵션)
Manus 공식 문서: Skills
Manus 공식 문서: Website Builder / Web App
AI를 활용한 통계 오류 탐지 관련 리뷰 논문
출판 논문에서 반복적으로 나타나는 통계 오류 관련 리뷰 논문
Survival analysis 보고에서 자주 발생하는 오류를 다룬 리뷰 논문
