🚀 연구의 패러다임을 바꾸는 'LLM 위키(Wiki)'와 'AI 다중 에이전트' 구축 가이드

🚀 연구의 패러다임을 바꾸는 'LLM 위키(Wiki)'와 'AI 다중 에이전트' 구축 가이드

안녕하세요! 오늘은 연구자분들의 끝없는 골칫거리인 자료 관리와 학회 제출 전 논문 심사(Peer Review) 프로세스를 AI로 완전히 자동화하는 방법을 공유해 드리려고 합니다. [cite: 1]

이 글은 카이스트 학·석사를 거쳐 독일 하이델베르크 대학과 보쉬에서 박사를 마치고 연구 자동화 도구를 개발하고 계신 이해봄 박사님의 세미나 내용을 바탕으로 작성되었습니다. [cite: 1]

연구 데이터를 단순한 '검색용 기록'에서 '누적되는 평생의 연구 자산'으로 전환하는 혁신적인 워크플로우를 지금 바로 만나보세요! [cite: 1]

---

📌 전체 핵심 요약 한눈에 보기

세미나의 핵심은 지식의 자산화(1부)와 검증의 자동화(2부), 그리고 이 둘을 묶어 시너지를 내는 순환 루프 구축(3부)으로 요약할 수 있습니다. [cite: 1]

graph TD
    A[1부: LLM Wiki 구축] -->|연구 자산 구조화| B[2부: AI 에이전트 다중 리뷰]
    B -->|심사 결과 피드백| C[3부: Wiki 자동 축적 및 연동]
    C -->|지속적 지식 확장| A
    style A fill:#e3f2fd,stroke:#1e88e5,stroke-width:2px
    style B fill:#f1f8e9,stroke:#7cb342,stroke-width:2px
    style C fill:#fff3e0,stroke:#fb8c00,stroke-width:2px

---

1️⃣ [1부] 왜 꼭 '위키(Wiki)'여야 할까? (구글 OKF 규격 구축법)

다들 조테로(Zotero), 멘델레이(Mendeley) 혹은 로컬 폴더에 읽을 논문을 가득 쌓아두고 계실 겁니다. [cite: 1] 하지만 특정 수식이나 실험 결과를 찾으려면 매번 검색창을 두드려야 하죠. [cite: 1]

💡 핵심은 "연결과 누적"

논문 요약과 실험 결과를 서로 링크로 연결해 LLM 위키 형태로 관리하면, 사람뿐만 아니라 AI 에이전트가 정보를 탐색하는 속도가 비약적으로 빨라집니다. [cite: 1] 한 번 정리한 지식이 다음 연구의 즉각적인 입력값(Input)이 되는 것이죠. [cite: 1]

📏 구글의 표준 포맷: OKF (Open Knowledge Format)

얼마 전 구글이 AI가 파싱하기 쉽도록 위키 규칙을 규격화해 발표했습니다. [cite: 1] 옵시디언(Obsidian)과 같은 시각화 툴에서 깔끔하게 보려면 아래 4가지 기본 규칙만 지키면 됩니다. [cite: 1]

1. 개념 하나 = 파일 하나 + YAML 프론트매터: 논문 한 편, 저자, 학회명, 특정 개념(자율주행 등)을 각각 독립적인 .md 파일로 쪼갭니다. [cite: 1]
2. 필수 필드 구성: 프론트매터에 최소한 type 필드는 필수로 넣어주고, title, tags, timestamp는 권장 사항으로 채웁니다. [cite: 1]
3. 표준 마크다운 링크: 페이지 간 연결 시 상대경로 대신 번들 기준 절대경로 형태의 표준 링크를 씁니다. [cite: 1]
4. 예약 파일 활용: 폴더마다 목차를 담당하는 index.md를 두고, 루트 폴더에는 전체 변경 이력을 기록하는 log.md를 유지합니다. [cite: 1]

🛠️ 내 서지 데이터를 위키로 바꾸는 흐름

flowchart TD
    subgraph Zotero [문헌 관리 툴]
        A[논문 컬렉션 수집] --> B[BibTeX .bib 파일 추출]
    end

    subgraph LLM_Engine [Claude Code / GPT]
        B -->|references.bib 입력| C[OKF 변환 프롬프트 실행]
        C --> D[마크다운 파일 트리 생성]
    end

    subgraph Wiki_Output [LLM Wiki]
        D --> E[Papers/ 저자/ 학회/ 연도별 MD 생성]
        E --> F[Obsidian 그래픽 뷰 시각화]
    end

    style Zotero fill:#fafafa,stroke:#ccc
    style LLM_Engine fill:#fffde7,stroke:#fbc02d
    style Wiki_Output fill:#f3e5f5,stroke:#8e24aa

---

2️⃣ [2부] 학회 제출 전에 미리 맞는 매집집, "AI 다중 에이전트 리뷰"

논문을 제출하고 결과를 받기까지 보통 수개월이 걸립니다. [cite: 1] 실제 제출 전, 각기 다른 시각을 가진 5명의 AI 전문 리뷰어에게 미리 혹독한 피드백을 받아 구멍을 메울 수 있다면 어떨까요? [cite: 1]

🎭 5인의 AI 리뷰어 페르소나 설정

에이전트가 독립적인 관점으로 심사하도록 정교하게 설계된 페르소나 명단입니다. [cite: 1]

• 🔬 Reviewer A (방법론·통계): 재현 가능성 검증, 데이터 누수(Data Leakage) 감지. [cite: 1]
• ⚖️ Reviewer B (비교 공정성): SOTA 모델과 정말 공정하게 비교했는지, 내 편향된 매트릭만 쓴 것은 아닌지 감시. [cite: 1]
• 🎓 Reviewer C (도메인 전문가): 기술적인 정확성 및 누락된 필수 관련 연구(Related Work) 지적. [cite: 1]
• 🔍 Reviewer D (회의적 독자): "그래서 독창성(Novelty)이 뭔데?"라며 기여도와 한계점을 파고듦. [cite: 1]
• ✍️ Reviewer E (글쓰기·표현): 문법 오류, 스토리라인의 매끄러움, 그림과 표의 통일성 검수. [cite: 1]

🔄 다중 에이전트 협업 메커니즘

다섯 명의 리뷰어는 상호 간의 심사 내용을 전혀 보지 못하는 상태(독립적 병렬 실행)로 심사를 거치며, 최종적으로 편집장(Editor-in-Chief) 에이전트가 이들의 보고서를 취합해 최종 의견을 도출합니다. [cite: 1]

sequenceDiagram
    autonumber
    actor Researcher as 연구자 (Human)
    participant ClaudeCode as Claude Code (에이전트 실행기)
    participant Reviewers as 5인의 독립 리뷰어 (A~E)
    participant Editor as Editor-in-Chief (에디터)
    participant Wiki as LLM Wiki (OKF 저장소)

    Researcher->>ClaudeCode: 논문 초안 (Manuscript.md) 입력 & 리뷰 요청
    Note over ClaudeCode, Reviewers: 각 리뷰어는 독립된 페르소나 파일 기반 작동 (상호 의견 참조 불가)
    par Reviewer A 심사
        ClaudeCode->>Reviewers: 방법론/통계 검증
    and Reviewer B 심사
        ClaudeCode->>Reviewers: 비교 공정성/SOTA 검증
    and Reviewer C 심사
        ClaudeCode->>Reviewers: 도메인 기술성/레퍼런스 검증
    and Reviewer D 심사
        ClaudeCode->>Reviewers: Novelty/회의적 검증
    and Reviewer E 심사
        ClaudeCode->>Reviewers: 글쓰기/표현/스토리 검증
    end
    Reviewers-->>ClaudeCode: 개별 심사 보고서 (5건) 반환
    ClaudeCode->>Editor: 개별 보고서 전달 및 취합 요청
    Editor->>Editor: 종합 분석 및 최종 판정 (e.g., Major Revision) 도출
    Editor-->>Researcher: 에디터 총평 및 필수 수정 리스트 제안
    Editor->>Wiki: 리뷰 결과 문서 자동 저장 및 링크 연결 (log.md 자동 갱신)

---

3️⃣ [3부] 지식이 저절로 자라나는 "연동 루프" 설계법

리뷰 에이전트가 만든 결과물은 1회성 답변으로 사라지지 않습니다. [cite: 1] OKF 형식에 맞춰 내 LLM 위키 저장소에 히스토리로 기록되게 설정해 두었기 때문입니다. [cite: 1]

flowchart LR
    A[연구 아이디어 및 가설] -->|실험 및 분석| B[논문 초안 작성]
    B -->|다중 에이전트 리뷰| C[심사 보고서 및 수정 가이드]
    C -->|OKF 마크다운 형태로 저장| D[(LLM Wiki 지식 저장소)]
    D -->|자동 인덱싱 및 이력 갱신| E[log.md / index.md]
    E -->|다음 단계 자산으로 활용| A

    style D fill:#e8f5e9,stroke:#4caf50,stroke-width:2px

🚶‍♂️ 지금 당장 시작하는 실전 3단계

거창한 파이썬 코딩이나 개발 지식은 필요 없습니다. [cite: 1] 오늘 밤 바로 시작해 볼 수 있는 미니멀 가이드입니다. [cite: 1]

1. 반복 업무 하나 정하기: 매주 반복해서 직접 작성하고 있는 논문 요약정리, 실험 로그 정리, 혹은 체크리스트 작성 중 딱 한 가지만 고릅니다. [cite: 1]
2. 위임 지침 문서 만들기: 신입 팀원에게 첫 업무를 지시하듯, 원하는 포맷, 지켜야 할 기준, 잘 된 예시를 적은 간단한 프롬프트 마크다운 문서를 작성합니다. [cite: 1]
3. 위키 폴더로 자동 수집되게 연결하기: AI 에이전트가 결과물을 위키 저장소의 특정 폴더로 밀어 넣게 설정하면 매번 손쓸 필요 없이 자동으로 나의 소중한 연구 자산이 차곡차곡 쌓이기 시작합니다. [cite: 1]

---

💬 연구자들의 궁금증 해결 (Q&A)

• Q. AI 모델이 가짜 논문을 인용하는 '할루시네이션' 문제는 어떻게 처리하나요? [cite: 1]
  • A. 에이전트가 단순히 스스로의 기억에 의존해 출처를 만들어내지 못하도록, CrossRef API 등의 외부 데이터베이스 조회 툴을 함께 연동해 실존하는 논문인지를 실시간으로 필터링하는 파이프라인 안전장치를 설계해야 합니다. [cite: 1]
• Q. 옵시디언(Obsidian)을 무조건 깊게 배워야 하나요? [cite: 1]
  • A. 아닙니다. 옵시디언은 단순히 쌓인 정보의 연결 고리를 가끔 확인하기 위한 시각화 뷰어일 뿐입니다. [cite: 1] 가장 본질적인 가치는 배경에 깔려 있는 구조화된 마크다운 파일들의 집합(Wiki 그 자체)에 있습니다. [cite: 1]
• Q. 인문학이나 사회과학 도메인에서도 사용할 수 있나요? [cite: 1]
  • A. 당연히 가능합니다. 통계 검증 기준이나 도메인별 페르소나 설정만 본인의 전공에 맞춰 수정해 주면, 가설 설정 및 선행 연구 검증 단계에서 동일하게 놀라운 효율 개선 효과를 볼 수 있습니다. [cite: 1]

---

💡 마무리하며
에이전트는 복잡하고 지루한 반복 작업을 대신 맡아줄 뿐, 연구에 대한 핵심적인 통찰과 최종적인 의사결정의 책임은 여전히 우리 연구자들에게 열려 있습니다. [cite: 1] 지루한 노가다는 에이전트에게 완벽히 위임하고, 우리는 더 가치 있고 창조적인 아이디어에 집중해야 할 때입니다. [cite: 1]

---

태그: #연구자동화 #LLMWiki #ClaudeCode #AI에이전트 #논문리뷰 #옵시디언 #OKF