AI결과물검수 1주차 정리

【핵심 요약】

AI에게 "다시 검토해줘"라고 하는 것은 검증이 아니다. 검증은 ① 입력 전단에서 소음을 막고 ② 기계가 결정론적으로 걸러낸 뒤 ③ 남은 것만 LLM이 심의하는 3층 구조여야 한다.

1주차에서 확인된 핵심 8가지입니다.

🎯 이번 주에 드러난 평가·리뷰 하네스의 작동 구조

세션 전체(스터디장 개괄 + 리토님 시연)에서 실제로 확인된 것만 이어 붙인 9단계입니다.

 ① 의도 정렬
    워크스페이스 지침(AGENTS.md / CLAUDE.md)으로 "무엇을·왜·어떻게"를 고정
    → 두세 줄 지시로 던지면 LLM이 확률 높은 쪽을 자기 판단으로 골라버린다
              │
              ▼
 ② 입력 전단 필터  ← 여기가 가장 중요
    원문만 상위 티어. 블로그·2차 해석은 낮은 티어 또는 컷
    → 도미노의 첫 장을 세우는 단계
              │
              ▼
 ③ 인제스트
    원본 자료를 LLM-Wiki 구조(sources / glossary / claims / decisions)로 편입
              │
              ▼
 ④ 용어 번역 + 검색
    자연어 질문 → 도메인 용어로 번역(glossary) → 검색(BM25) → 1-hop 관련 문서 확장
              │
              ▼
 ⑤ 생성
    근거 앵커를 달아서 산출물 생성
              │
              ▼
 ⑥ 클레임 분해
    산출물을 Yes/No 판정 가능한 문장 단위로 쪼갠다 (예: 8~9개)
              │
              ▼
 ⑦ 기계 게이트 (결정론적 · LLM 아님)
    · 근거(조문·인용)가 실제로 존재하나?
    · 수치가 원본으로부터 계산되나?
    → supported / insufficient 판정
              │
              ▼ 기계로 못 걸러낸 것만
 ⑧ LLM 심의 (멀티에이전트)
    공격(SKEPTIC) ↔ 방어(DEFENDER) → 판정(CHAIR)
    ※ 역할 지침은 프롬프트가 아니라 스크립트에 고정 → 실행마다 흔들리지 않게
              │
              ▼
 ⑨ 판정: 통과 / 수정 / 보류
              │
              ▼
 🔁 신선도 감시 루프
    주기적으로 원본 재수집 → SHA-256 지문 대조 → 바뀐 것만 ③으로 되돌림

여기서 ⑦과 ⑧의 순서가 이 스터디의 핵심 주장입니다. LLM이 최종 판정을 하지 않습니다. 코드가 먼저 걸러내고, 애매해서 남은 것만 LLM이 봅니다.

1부. 스터디 목표와 워크스페이스 개념

워크스페이스 = 에이전트

"이거는 일종의 에이전트의 개념과 좀 동치하는 개념입니다."

윈도우로 치면 폴더 구조 안에 AGENTS.md, CLAUDE.md, 기타 지침 MD가 들어간 것. Claude Code나 Codex는 그 워크스페이스에 진입하면 그 파일들을 읽고 어떤 방식으로 일할지, 어떤 워크플로우를 탈지를 결정합니다.

왜 지침이 필요한가 — LLM의 작동 원리에서 나온 이유

"LLM은 굉장히 많은 데이터를 바탕으로 학습해서 확률적으로 그다음에 나올 토큰들을 예측하는 모델로 학습이 되었다 보니까, 우리가 어떤 의도와 어떤 목적을 가지고 일을 수행할 것인지 명확하게 전달해 주는 것이 중요하기 때문입니다."

즉 의도를 명확히 전달하는 장치가 없으면 모델이 확률 높은 쪽을 자기 판단으로 골라버립니다. 그게 할루시네이션의 출발점입니다.

하네스 = 마구(馬具)

"막 여기저기 날뛰는 말을 우리가 원하는 방향과 원하는 속도로, 목적에 맞게 달리게 한다 — 그런 의미로 하네스라는 말을 씁니다."

인제스트

원본 데이터를 LLM-Wiki 체계 구조 안에 집어넣는 것 = 인제스트. 2주차에 knowledge-manager 또는 gbrain 기반으로 각자 도메인 레포를 만들 예정이고, 1주차는 그 전 단계로 "일단 뭔가를 서베이해서 가져와 집어넣는 것" 까지만 시도합니다.

이번 주 목표

1. Claude Code 또는 Codex로 개인 워크스페이스 세팅 (복잡할 수 있으니 Claude Code 추천)

2. 검수 대상으로 쓸 결과물·자료를 인제스트

3. 생성 결과와 검수 결과의 차이를 이해

세 번째가 개념적으로 중요했습니다. 스터디장 설명에 따르면 — "하네스 지침에 따라 내가 원하는 주제의 자료를 정확히 가져온다"는 것 자체가 이미 검수 과정의 일환입니다. 검수는 마지막에 붙는 검열이 아니라, 가져오는 단계에 이미 들어가 있습니다.

그리고 검수해야 할 오류가 두 종류로 갈립니다: 잘못 가져오는 것과 있어야 할 걸 안 가져오는 것(누락). 둘 다 지침으로 막습니다.

2부. 4주 뒤의 최종 그림 — 멀티에이전트 하네스

터미널에서 tmux / cmux / wmux ⚠️ 로 화면을 분할하고, 메타하네스 워크스페이스로 실제 시연했습니다.

• 마스터 에이전트가 하위 역할별 에이전트에게 지시 하달

• 에이전트 간 쌍방향 소켓 통신으로 결과물을 서로 주고받음 → 반자동/자동 진행

• 에이전트별로 다른 LLM 배정 가능 (멀티 LLM)

• 검수 루브릭 기준 + LLM 기반 지식베이스 + 팀 에이전트별 설정을 묶어서 돌림

3부. 좋은 평가 기준은 어디서 오는가

LG AI연구원이 낸 논문 소개 파트입니다. 생성된 전문 보고서의 품질과 근거를 전문가 평가 기준(루브릭)으로 평가하게 만든 연구입니다.

⚠️ 논문명·투입 비용·기준 개수는 자막 오인식 위험이 있어 수치는 옮기지 않습니다. (발언 중 논문명이 "디어"로 들리고, 억 단위 비용·전문가 표준 개수·도메인 개수가 언급되었으나 확인 불가) 다만 논지 3개는 자막상 명확했습니다.

논지 ① 좋은 평가 기준은 발명이 아니라 이식이다

학회 리뷰어가 논문을 통과시키는 기준을 예로 들었습니다 — 연구가 얼마나 타당한지 / 근거가 사실인지 / 참신성은 어느 정도인지 / 구현 가능성은 있는지.

"사람들이 결국에는 오랜 기간 쌓아왔던 어떤 전문 체계와 전문 지식을 바탕으로 평가하는 게 좀 더 타당하지 않냐"

여러 도메인(메디컬·수학 등) 전문가의 표준을 긁어모아 루브릭으로 정리한 방식입니다. 내 루브릭을 창작하려 하지 말고, 내 도메인에 이미 있는 심사 기준·체크리스트를 옮기는 게 먼저라는 뜻으로 읽었습니다.

논지 ② AI 평가는 인간 전문가와의 합치도(agreement)로 검증한다

AI에게 기준을 주고 평가시켰다면, 그 평가가 얼마나 사람과 유사하거나 더 나은지를 재야 합니다. 특정 보고서에 대해 인간 전문가는 어떻게 평가했고 AI는 어떻게 평가했는지 대조하는 과정이 필요합니다.

논지 ③ 인용 존재 여부가 아니라 주장-근거 관계 전체를 본다

"실제 생성된 결과가 실제 어떤 근거 자료와 얼마나 합치되는지를 봐야 된다는 거예요."

→ 그래서 LLM-Wiki에 사실을 콤팩트하게 구축해두면, 그 지식베이스를 기준으로 대조할 수 있어 검수 성공률이 올라갑니다. 이게 2주차 LLM-Wiki가 필요한 이유입니다.

할루시네이션 = 도미노

이번 주 가장 기억에 남은 비유입니다.

"할루시네이션이라는 것은 이제 도미노와 같아서, 처음에 한 번 잘못 쓰러뜨리면 도미노 한 1,000개쯤 쓰러뜨렸을 때는 너무 큰 차이가 벌어질 거잖아요. 그래서 초반에 발생할 때 애초에 처음부터 발생하지 않게끔 막는 게 중요하거든요."

함의: 검수를 마지막에 한 번 붙이는 게 아니라, ① 중간 산출물마다 루브릭으로 검토하고 ② 과정마다 멀티에이전트로 교차검수해서 처음부터 잘 쌓아야 합니다. "틀린 채로 만든 뒤 고치는" 도돌이표를 없애는 게 목적입니다.

4부. 리서치 서베이 워크스페이스 데모

채팅으로 리서치 서베이 워크스페이스 zip을 배포했습니다.

실제 활용 사례

ICML 2026 논문 약 6,200~6,300편을 전량 크롤링해두고, 리서치 토픽을 넣으면 매칭되는 논문을 도메인 4개로 나눠 정리 → 노션 업로드(별도 스킬 사용)까지 자동화. 실제로 수십 편이 노션에 정리돼 올라갑니다.

라이브 데모

질의: "ICML 2026 논문 중 evaluation harness 관련 논문 가져와줘"

결과로 수집된 것들: 평가 하네스 공개, 벤치마크 eval 공개, 데이터셋 eval 공개, "사용자가 말하지 않는 목표 충족 평가", 증명 라이브러리·증명 엔지니어링, 음성 function calling, 파이프라인 공개 등.

스터디장 본인 평가: "좀 너무 단순하긴 했는데." 위키를 연동하지 않고 워크스페이스만 열어서 돌린 상태라서 결과가 깔끔하지 않을 수 있다고 미리 밝혔습니다.

다음 단계가 이어집니다 — "요약하고 검증도 해주고 위키로 승격해줘". 발표 후반에 이 작업이 완료돼서 인제스트 → 위키 승격까지 실제로 성공한 것을 확인했습니다.

5부. 워크스페이스를 만드는 3가지 경로 + 추천 레포

경로 A — 남의 워크스페이스를 레퍼런스로 확장

기본 워크스페이스를 하나 가져온 뒤 "이걸 레퍼런스 삼아서 내 워크스페이스를 구성해줘" 로 요청.

경로 B — PRD로 명세를 먼저 못 박고 생성

PRD(Product Requirements Documents)로 요구사항을 정의 → 상세 명세로 변환 → /goal 등 슬래시 커맨드로 구현.

경로 C — 멀티 LLM 에이전트 팀에게 "조리돌림" (최상급)

"가장 좋은 거는 저희가 3주차·4주차 때 할 멀티 LLM 에이전트 팀을 구축한 다음에 걔한테 조리돌림을 시키면 좀 더 잘해 줍니다."

추천 레포·도구

반복 강조된 원칙:

"이거는 이제 사실 우리보다 앞서서 반년에서 1년 정도 미리 사용해서 잘 구축하신 분들의 것을 잘 쓰면 된다가 이제 핵심이긴 합니다."

즉 LLM-Wiki를 맨손으로 만들지 않습니다. 검증된 레포 위에 검수용 구조만 얹습니다.