AI결과물검수 - 스터디장님 강의 내용 정리 (AI 결과물 검수를 위한 워크스페이스 세팅)

AI결과물 검수 스터디장, 에이전트H 님의 강의 내용 정리입니다.

ALT

일체 포함

-----------------------------------------------
【핵심 요약 】

한 문장 핵심

AI 결과물을 잘 검수하려면 마지막 답변만 평가하는 것이 아니라, 워크스페이스·원본 자료·전문가 루브릭·역할별 에이전트·중간 검증을 하나의 하네스로 묶어 생성 과정 자체를 통제해야 한다.

• 워크스페이스는 AGENTS.md, CLAUDE.md, 스킬, 런북, 튜토리얼, 자료 경로처럼 에이전트가 따라야 할 맥락과 절차를 담는 작업 환경이다.

• 하네스는 확률적으로 움직이는 LLM을 목적·방향·속도에 맞게 달리도록 잡아주는 ‘마구’다. 단순 프롬프트보다 지속 가능한 지침·자료·검수 절차의 묶음에 가깝다.

• 첫 실습 흐름은 워크스페이스 확인 → 검수 대상 자료 인제스트 → 일반 분석과 하네스 기반 검수 비교다.

• 강의가 제안하는 평가 기반은 오랫동안 축적된 도메인 전문가의 평가 표준이다. 보고서의 품질과 주장–근거 무결성을 분리해서 보고, 필요 개념·근거·비교 조건·대안·한계·레퍼런스를 확인한다.

• 환각은 초기에 생긴 작은 오류가 뒤 단계에서 증폭되는 도미노와 같다. 마지막에 한 번 검사하기보다 중간 산출물을 여러 역할과 루브릭으로 반복 검토해야 한다.

• 리서치 서베이 데모에서는 학회 논문 풀을 먼저 모은 뒤 관심 주제로 좁히고, 여러 에이전트가 분류·요약·검증하며, 결과를 Notion이나 LLM Wiki 같은 지식베이스로 승격하는 흐름을 보여 준다.

• 워크스페이스 구축 방법은 목적·도메인을 MD로 직접 지정하는 방법, 검증된 기존 저장소를 레퍼런스로 개조하는 방법, PRD·명세를 먼저 작성한 뒤 단계별로 생성하는 방법의 세 갈래로 제시된다.

• 기존 글로벌 스킬·설정과 새 워크스페이스가 섞이면 일부 규칙이 사라지거나 충돌할 수 있다. 강의에서는 깨끗한 Docker 환경이나 프로젝트 단위 설정으로 격리하는 방안을 제안한다.

🎯 핵심 강의 — 평가·리뷰 하네스의 작동 구조

1. 검수할 업무·도메인·결과물 정의
        ↓
2. WORKSPACE에 목적·절차·역할·경로·스킬 고정
        ↓
3. 원본 자료 / 평가 대상 / 전문가 기준 INGEST
        ↓
4. LLM Wiki·지식베이스로 주장과 근거의 기준점 마련
        ↓
5. 도메인별 RUBRIC으로 품질·근거·누락·한계 평가
        ↓
6. Master Agent가 역할별 Agent에 작업 분배
        ↓
7. 중간 산출물마다 교차검토·수정·재평가
        ↓
8. 최종 결과와 원본 근거를 비교하고 지식베이스로 승격

왜 이 구조가 필요한가

1. 의도 손실 방지 — LLM은 다음 토큰을 확률적으로 선택하므로 사용자의 목적과 평가 기준을 스스로 완벽히 보존하지 않는다.

2. 누락·오선택 방지 — 중요한 자료를 빼거나 관련성이 낮은 자료를 가져오는 문제를 검색 단계부터 줄인다.

3. 전문가 관점의 재사용 — 사람 전문가가 실제로 사용해 온 리뷰 기준을 루브릭으로 구조화한다.

4. 초기 오류 차단 — 환각이 뒤 단계까지 전파되기 전에 각 과정에서 검증한다.

5. 반복 가능한 업무화 — 한 번의 좋은 프롬프트가 아니라 파일·스킬·런북·에이전트 역할로 재현 가능한 시스템을 만든다.

📌 Highlight Timestamps

• 00:01:50 — 오늘 만들 것: 워크스페이스, 인제스트, 일반 분석과 하네스 검수 비교

• 00:02:40 — 확률적 LLM에 목적과 의도를 명확히 전달해야 하는 이유

• 00:03:06 — 하네스라는 표현의 의미

• 00:05:03 — 이번 주 목표: 개인 워크스페이스와 검수 자료 구성

• 00:08:26 — 마스터·역할 에이전트·소켓 통신 기반 미래 구조

• 00:12:42 — LG AI Research의 DEER 평가 연구 소개

• 00:14:00 — 도메인 전문가의 평가 표준을 루브릭으로 만드는 관점

• 00:17:36 — 환각의 도미노와 중간 검수의 필요성

• 00:28:10 — 리서치 서베이 예시 워크스페이스 배포

• 00:35:00 — 워크스페이스가 지침·런북·튜토리얼을 읽는 방식

• 00:37:45 — ICML 논문 풀에서 관심 주제를 선별하는 데모

• 00:42:33 — 워크스페이스를 만드는 두 가지 접근

• 00:44:24 — 검색 결과를 요약·검증하고 위키로 승격

• 00:50:43 — GSD·PRD·멀티에이전트로 워크스페이스 고도화

• 00:53:03 — 원하는 도메인 자료로 소스 코퍼스를 교체하는 법

• 00:55:50 — 글로벌 설정·스킬과 새 저장소의 충돌 문제

• 00:57:29 — Docker 격리 또는 프로젝트 단위 설정 제안

• 01:03:20 — 대규모 논문 처리 작업이 계속 실행되는 상태에서 구간 종료

ALT

한국어 단어가 적힌 포스터

【상세 정리 】

1부. 스터디의 목표와 하네스의 기본 개념

00:00–01:50 스터디 운영과 전체 구성

강의는 ‘검수 AI 스터디’의 개괄 설명으로 시작한다. 첫 발표에서는 검수 AI의 전체 그림과 예시 워크스페이스를 소개하고, 뒤 세션에서는 세법 조문을 LLM Wiki에 넣어 검색·활용하는 시연을 진행할 예정이라고 안내한다. 매주 과제를 제출하고 우수 사례를 공유하면서 4주 동안 각자의 도메인에 맞는 하네스를 만드는 방식이다.

이 운영 설명은 단순 공지가 아니라 이후 강의의 전제를 보여 준다. 참가자는 완성된 서비스를 소비하는 사람이 아니라, 자신의 업무를 글·도식·규칙으로 표현하고 그것을 에이전트가 수행할 수 있는 워크스페이스로 바꾸는 실습자다.

01:50–02:40 오늘 만들 것: 워크스페이스 → 인제스트 → 비교

화면의 오리엔테이션 슬라이드는 세 단계로 정리되어 있다.

1. 워크스페이스: 내 작업 위치와 자료 경로 확인

2. 인제스트: 검수 대상 결과물 또는 자료 한 종류 넣기

3. 비교: 일반 분석과 하네스 기반 검수 비교

슬라이드가 남기려는 질문은 “내 업무에서는 무엇을 검수해야 하는가?”다. 검수 시스템을 만들기 전에 업무의 대상과 성공 기준을 한 문장으로 정의해야 한다.

02:06–03:06 워크스페이스는 에이전트가 일하는 맥락의 묶음

강의에서 워크스페이스는 폴더 이상의 개념이다. Windows 폴더 구조 안에 AGENTS.md, CLAUDE.md 같은 지침 파일과 스킬·가이드·자료가 들어가고, Claude Code나 Codex는 이를 읽어 어떤 순서와 방식으로 일해야 하는지를 결정한다.

LLM은 대규모 데이터에서 다음 토큰을 확률적으로 예측한다. 따라서 사용자가 무엇을 왜 시키는지, 어떤 자료를 기준으로 어떤 품질을 원하는지를 명확하게 전달하지 않으면 모델 자체의 높은 확률 선택이 사용자의 의도와 어긋날 수 있다. 워크스페이스는 이 의도와 맥락을 반복 가능하게 전달하는 장치다.

03:06–03:21 하네스는 날뛰는 말을 목적에 맞게 달리게 하는 마구

강사는 ‘하네스’를 말의 방향과 속도를 제어하는 마구에 비유한다. LLM을 억누르는 단일 규칙이 아니라, 원하는 방향으로 달리도록 목적·자료·절차·평가 기준을 묶어 주는 시스템이라는 뜻이다.

하네스의 목적

모델에게 더 많은 말을 시키는 것이 아니라, 의도한 업무를 의도한 방식으로 수행하고 스스로 검수하도록 만드는 것이다.

03:21–04:13 인제스트와 LLM Wiki

2주차에는 도메인별 LLM Wiki 저장소를 만들고 원본 데이터를 체계 안에 넣는 인제스트를 다룬다. 첫 주에는 완전한 위키 구축보다 조사한 자료나 검수 대상 결과물을 워크스페이스로 가져오는 연습부터 시작한다. 강사는 메타하네스와 리서치 서베이 워크스페이스를 예시로 소개한다.

04:13–05:03 단순 요청과 하네스 기반 요청의 차이

그냥 Claude Code를 열어 “논문을 조사해 줘”라고 하는 방식과, 관심 주제·검색 범위·선별 기준·검증 절차가 들어 있는 하네스를 사용한 방식은 결과가 달라진다. 참가자는 집에서 두 접근을 직접 비교해 보도록 안내받는다.

이 비교는 이후 평가 루브릭 학습으로 이어진다. 3주차에는 무엇을 기준으로 AI 결과물이 잘되었는지 판단할지, 다양한 평가 기준을 워크스페이스 안에서 어떻게 적용할지를 다룰 예정이다.

05:03–06:03 이번 주 목표: 생성과 검수의 차이를 이해하기

이번 주의 실습 목표는 다음과 같다.

• 개인 워크스페이스에서 Claude Code 또는 Codex 실행

• 검수할 결과물이나 자료를 가져오거나 인제스트하도록 요청

• 일반 생성 결과와 검수 절차를 거친 결과의 차이 확인

• 중요한 자료가 누락되지 않았는지, 잘못된 자료가 선택되지 않았는지 검토

논문 주제를 정확히 가져오는 행위 자체도 검수의 일부다. 검색이 틀리거나 중요한 자료가 빠지면, 이후의 요약과 보고서가 아무리 매끄러워도 전체 결과는 잘못된다.

06:03–07:10 과제: 내 업무의 절차를 먼저 표현한다

과제는 각자의 개인 워크스페이스를 만드는 것이다. 기존 오픈소스 워크스페이스를 참고하되, 자신의 도메인과 태스크에 필요한 업무 절차를 상세한 글·키워드·워크플로·도식으로 먼저 표현하고 Claude Code나 Codex에게 그 절차에 맞는 워크스페이스를 구성하도록 요청한다.

즉, “좋은 에이전트를 만들어 줘”가 아니라 다음을 먼저 정해야 한다.

• 어떤 위치에서 작업하는가

• 어떤 결과물과 원본 자료를 검수하는가

• 어떤 순서로 조사·생성·평가하는가

• 무엇이 누락되면 실패인가

• 어떤 결과를 다음 단계로 넘기는가

2부. 멀티에이전트 검수 구조와 전문가 루브릭

08:26–11:14 마스터 에이전트와 역할별 에이전트

강사는 터미널에서 여러 에이전트가 동시에 동작하는 미래 형태를 보여 준다. 마스터 역할의 에이전트가 하위 역할 에이전트들에게 지시하고, 에이전트들이 소켓 통신으로 결과물을 주고받으면서 반자동 또는 자동으로 일을 진행한다.

이 구조에 다음 요소를 결합하면 검수 시스템이 된다.

• 검수 루브릭

• LLM 기반 지식베이스

• 역할별 에이전트 설정

• 에이전트 간 결과 전달

• 중간 결과의 반복 검토

각 에이전트는 서로 다른 LLM으로 설정할 수도 있다. 목표는 사용자가 다소 거칠게 요청하더라도 저장된 맥락과 역할 분담을 바탕으로 의도를 복원하고, 수행 결과를 꼼꼼히 검토하는 시스템이다.

11:36–12:20 4주 동안 만들 하네스의 모습

4주간 참가자는 자신의 컨텍스트, 메시지 방식, 자료를 에이전트 시스템에 지속적으로 공급한다. 하네스가 “알아듣고 실행하는 능력”뿐 아니라 “실행한 결과를 검수하는 능력”까지 갖도록 다듬는 것이 목표다.

12:42–13:44 DEER: 보고서 품질과 근거 무결성을 분리 평가

강사는 LG AI Research의 DEER 연구를 예로 든다. 화면에서는 Deep Research Report를 두 축으로 나눠 평가한다.

• Report Quality: 문서 전체 품질 판단

• Information Verification: 주장 단위의 근거 검증

슬라이드에는 Report Quality 측에 5 Dimensions / 46 Criteria / 101 Rubric Items, Information Verification 측에 2 Dimensions / 10 Metrics / Claim ↔ Evidence가 표시된다. 핵심 메시지는 문서의 총괄 품질 판단과 사실·근거 검증은 서로 다른 방식으로 수행해야 한다는 것이다.

14:00–15:47 좋은 평가 기준은 전문가가 축적한 실제 표준에서 온다

강의는 좋은 평가 기준을 새로 상상하는 대신, 도메인 전문가들이 오랜 기간 사용해 온 심사 기준을 모으는 접근을 소개한다. 논문 리뷰에서는 연구의 타당성, 근거의 사실성, 참신성, 구현 가능성 같은 관점이 사용된다. 의료·수학 등 여러 도메인의 공개된 평가 기준과 전문가 피드백을 모아 루브릭으로 구성했다는 설명이다.

여기서 중요한 것은 ‘보편적인 좋은 글’만 평가하지 않는다는 점이다. 과제와 도메인에 따라 필요한 전문 표준이 다르므로, 하네스도 자신의 업무에 맞는 루브릭을 갖춰야 한다.

15:49–16:52 루브릭이 확인해야 할 요소

보고서나 논문을 검수할 때 다음을 확인하도록 기준을 줄 수 있다.

• 필수 개념과 빠진 요소

• 필요한 증명과 근거

• 비교해야 할 조건

• 대안과 한계

• 제언을 뒷받침할 예시·레퍼런스

• 내용이 충분히 좋은지와 무엇이 누락됐는지

AI의 평가는 사람 전문가의 평가와 얼마나 합치되는지도 확인해야 한다. 같은 보고서를 전문가가 어떻게 평가했고 AI가 어떻게 평가했는지를 비교해야 루브릭과 평가 에이전트의 신뢰도를 알 수 있다.

16:58–17:36 주장–근거 관계와 지식베이스

보고서 전체의 인용 유무만 확인해서는 부족하다. 생성된 주장과 실제 근거 자료가 얼마나 합치되는지를 비교해야 한다. LLM Wiki처럼 압축·정리된 지식베이스가 있다면 결과물과 원본 지식의 비교 기준점으로 사용할 수 있다.

17:36–18:29 환각의 도미노를 초기에 막는다

강사는 환각을 도미노에 비유한다. 초반에 작은 오류 하나가 발생한 채로 여러 단계를 지나면 최종 결과에서는 훨씬 큰 차이가 된다. 따라서 마지막 결과만 한 번 평가하는 구조로는 부족하다.

• 각 과정에서 역할별 에이전트가 검수

• 중간 결과에 루브릭 적용

• 원본 자료와 결과를 반복 비교

• 잘못된 선택을 초반에 수정

핵심 위험

초기 검색·선별·해석이 틀리면 뒤 단계의 요약·분석·보고서가 모두 그 오류를 확대한다. 검수는 최종 단계가 아니라 생성 파이프라인 전체에 들어가야 한다.

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

18:34–28:10 시스템 지연과 휴식

시연 직전 컴퓨터가 버벅이면서 자료 공유를 위해 휴식 시간을 갖는다. 20:31~28:10은 사실상 휴식·음악 구간이며 강의 내용이 없다. 이 지연은 이후 데모에서도 환경과 설정의 차이가 실행 안정성에 영향을 준다는 맥락으로 이어진다.

28:10–30:06 리서치 서베이 예시 워크스페이스

강사는 공유한 ZIP 파일을 내려받아 사용할 수 있는 리서치 서베이 워크스페이스를 소개한다. 이전에 공개된 Claude Code 플러그인·워크스페이스 사례에서는 PRD(Product Requirements Document)를 작성하고 상세 명세를 준 뒤 slash command 등을 이용해 원하는 결과물을 구현한다.

워크스페이스는 여러 스킬과 지침·가이드라인을 담아 특정 목적에 맞게 동작하게 만드는 환경이다.

30:06–31:23 서베이 파이프라인의 목적

예시 워크스페이스는 관심 주제에 맞는 논문을 고르고, 요약하고, 여러 에이전트에게 검증시키며, 인사이트·가설·서베이 결과를 정리하는 튜토리얼을 목표로 한다. 강사는 ICML 2026 자료를 예시로 구성했다고 설명한다.

31:23–34:25 ZIP을 풀고 터미널에서 워크스페이스 열기

사용자는 ZIP 압축을 풀고 해당 디렉터리로 이동한 뒤 Claude Code를 실행한다. Windows에서는 PowerShell 사용을 권하지만 데모는 시스템 지연 때문에 CMD로 진행한다. cd로 다운로드·압축 해제 위치에 이동하며, 압축 해제가 어렵다면 에이전트에게 요청하는 방법도 소개한다.

강의 중 사용자 확인을 최대한 생략하는 고권한 실행 옵션이 언급되지만, 이는 편의 기능에 대한 짧은 설명일 뿐 안전한 기본값으로 제시되지는 않는다. 실제 적용에서는 권한 범위를 별도로 검토해야 한다.

34:56–35:56 지침·런북·튜토리얼을 자동으로 읽는 환경

워크스페이스를 열면 Claude Code와 Codex는 내부의 AGENTS.md 및 여러 지침 파일을 읽고 목적과 태스크에 필요한 맥락을 얻는다. 예시 저장소에는 런북과 튜토리얼 문서가 들어 있다. 이 자료들도 멀티 LLM 에이전트에게 작성하도록 요청해 만든 것이라고 설명한다.

35:56–36:39 참고할 하네스: GSD Core와 기존 공개 저장소

장기간 여러 단계로 구현하는 작업에는 GSD Core 같은 구조를 참고할 수 있다. 강사는 직접 써 본 경험을 바탕으로 GSD Core와 기존 Claude Code 워크스페이스·PRD 저장소를 추천한다. 핵심은 처음부터 모든 구조를 새로 만들기보다, 이미 잘 작동하는 공개 하네스를 레퍼런스로 삼는 것이다.

36:41–37:45 리서치 서베이의 검수 기준

튜토리얼 문서에는 리서치 서베이에서 무엇을 확인하고 요약할지에 대한 기준이 들어 있다. 단순히 LLM이 확률적으로 고른 논문을 받는 것이 아니라, 사용자의 의도·목적을 반영해 선별하도록 지침을 제공한다. 여기에 지식베이스와 루브릭을 붙이면 환각과 오선택을 더 줄일 수 있다.

37:45–38:55 대규모 논문 풀 → 관심 주제 → 도메인별 정리

강사는 ICML 2026의 수천 편 논문을 먼저 수집한 뒤, 원하는 리서치 토픽을 입력해 관련 주제를 여러 도메인으로 나누고 정리하도록 한 사례를 설명한다. 결과를 Notion에 올리는 과정에는 별도 스킬을 사용했다.

이 흐름의 핵심은 다음과 같다.

대규모 후보 수집 → 관심 주제로 필터링 → 분류 → 요약 → 검증 → 외부 지식도구로 전달

38:55–40:27 Evaluation Harness 관련 논문 검색 데모와 한계

데모 요청은 ICML 2026 논문 중 evaluation harness 관련 자료를 가져오는 것이다. 강사는 이 데모가 충분히 검증된 상태는 아니며, 자신의 환경에서는 LLM Wiki를 연동해 사용하지만 공유된 새 워크스페이스만으로는 결과가 얼마나 깔끔할지 확신하기 어렵다고 밝힌다. 스킬이 참가자 환경에서도 정상 발동하는지 확인하는 장면도 나온다.

이 caveat는 중요하다. 좋은 워크스페이스 파일을 복사하는 것만으로 동일한 결과가 보장되지는 않으며, 지식베이스·스킬·환경 설정을 함께 검증해야 한다.

40:30–41:10 데모의 핵심: 의도에 맞는 정보를 더 잘 가져오기

워크스페이스의 본질은 원하는 도메인과 연구 주제에 맞는 정보를 더 잘 가져오도록 의도를 구조화하는 것이다. 저장소는 각자의 목적에 맞게 커스터마이징할 수 있다.

4부. 워크스페이스 구축법과 지식베이스 승격

41:34–42:33 예시 저장소를 목적별 워크스페이스로 바꾸기

이날 직접 기능을 구현하는 것이 주목적은 아니다. 제공된 리서치 서베이 저장소의 하네스·전체 구성·세부 기능을 참고해, 자신의 도메인과 태스크를 정의한 MD 파일을 만들고 “이 목적에 맞는 워크스페이스를 구축해 줘”라고 요청하는 방식이 소개된다.

연구 외에도 맛집·서울 빵집 지도처럼 깊게 조사하고 정리할 주제라면 같은 구조를 적용할 수 있다.

42:05–43:40 워크스페이스를 만드는 세 접근

1. Purpose-first — 원하는 도메인과 태스크를 MD에 직접 정의하고 “이 목적에 맞는 워크스페이스를 만들어 줘”라고 요청한다.

2. Reference-first — 공개된 기본 워크스페이스를 하나 가져와 구조와 파일을 참고하고, 자신의 업무에 맞게 개조한다.

3. Spec-first — PRD와 상세 명세를 먼저 작성하고, GSD Core나 slash goal 같은 단계적 생성 방식을 통해 새 워크스페이스를 만든다.

세 접근은 배타적이지 않다. 목적을 먼저 고정한 뒤 검증된 저장소를 참고하고, 필요한 부분은 상세 명세로 보강할 수 있다.

44:14–45:25 검색 결과 확인 → 요약·검증 → 위키 승격

데모 결과에는 evaluation harness·benchmark·dataset과 관련된 여러 논문 후보가 표 형태로 나온다. 강사는 결과가 다소 단순하다고 평가하면서도, 다음 단계로 요약과 검증을 시키고 위키로 승격할 수 있다고 설명한다.

2주차에는 지식베이스 관리 도구를 활용해 이런 결과를 더 체계적으로 축적할 예정이다. 이미 수개월 이상 사용하며 잘 구축한 사람들의 도구와 구조를 적극 재사용하는 것이 효율적이라는 조언도 덧붙인다.

45:31–46:08 이번 주의 실제 목표는 워크스페이스와 인제스트

현재는 완전한 LLM Wiki를 만드는 주차가 아니다. 먼저 워크스페이스를 구축하고 자료를 가져오는 경험을 한다. 이미 위키가 있는 경우에는 경로를 알려 주고 해당 위치에 인제스트하도록 요청할 수 있다.

46:28–48:12 리서치 서베이 데모 스킬

워크스페이스에는 짧은 자동 체험용 리서치 서베이 데모가 포함되어 있다. 강사는 별도 스킬을 명시하지 않고도 논문 검색을 요청한 장면과, 토큰이 충분할 경우 리서치 서베이 스킬을 사용해 더 구체적으로 제한하는 방법을 함께 보여 준다.

5부. 커스터마이징과 멀티에이전트 고도화

48:12–50:43 위키 경로·스키마·에이전트 지침도 다듬을 수 있다

사용자는 결과를 저장할 위키 위치를 지정할 수 있다. 위키의 AGENTS.md, 지침, 스키마도 자신의 도메인에 맞게 다듬을 수 있으며, 이후 주차에는 지식관리 도구와 결합해 시너지를 내는 방향을 다룬다.

강사는 공유 워크스페이스가 여러 모델을 오가며 멀티 LLM 에이전트로 다듬어진 것이라고 설명하지만, 개인적으로는 자신의 리서치 토픽에 맞게 더 세밀하게 수정해 사용한다고 밝힌다.

50:43–51:18 더 나은 워크스페이스를 만드는 검토 방식

GSD Core, PRD, slash goal 같은 도구로 워크스페이스를 만들 수 있고, 이후에는 멀티 LLM 에이전트 팀을 구성해 결과를 여러 번 돌려보며 검토시키면 품질을 높일 수 있다.

51:23–52:02 연구에 한정되지 않는 하네스

하네스는 연구 논문만을 위한 것이 아니다. 원하는 지역의 맛집이나 빵집을 조사해 지도로 만들거나, 특정 관심 주제를 깊게 조사하는 튜토리얼·워크스페이스로도 바꿀 수 있다. 공유 저장소의 목적은 정답을 제공하는 것이 아니라 “이런 방식으로 만들 수 있다”는 구조적 레퍼런스를 주는 것이다.

6부. Q&A — 소스 교체, 설정 충돌, 환경 격리

53:03–53:55 도메인 자료를 직접 가져와야 하는가

질문에 대해 강사는 데모 워크스페이스에는 이미 ICML 논문 풀이 들어 있다고 설명한다. 사용자는 ICML 대신 원하는 학회·주제·커뮤니티 자료를 넣고 같은 방식으로 질문할 수 있다. 또는 기존 저장소를 레퍼런스로 삼아 자신만의 워크스페이스를 새로 생성할 수 있다.

54:05–56:45 전주기 저장소를 이식할 때 기존 규칙이 깨지는 문제

참가자는 개별 스킬은 옮길 수 있지만, 전주기를 다루는 큰 저장소에서는 일부를 빼면 목적이 사라지고, 그대로 가져오면 기존 CLAUDE.md·규칙·스킬과 섞여 동작이 깨지는 문제를 제기한다. 에이전트에게 자신의 설정에 맞게 바꾸라고 하면 구현 목적에 필요한 요소를 삭제하기도 하고, 원본 그대로 쓰면 글로벌 규칙과 충돌한다.

이 질문은 하네스의 중요한 현실적 한계를 드러낸다. 하네스는 파일을 복사하는 것만으로 끝나지 않고, 설정 범위·참조 경로·우선순위를 함께 설계해야 한다.

56:45–58:01 해결책 1: 깨끗한 환경 또는 프로젝트 단위 설정

강사는 다음 두 가지 방향을 제안한다.

• 환경 격리: Docker 등으로 깨끗한 환경을 만들고 새 저장소를 별도로 실행

• 프로젝트 로컬 설정: 글로벌 설정 대신 프로젝트 내부에서만 스킬과 지침이 적용되게 구성

자주 쓰는 스킬만 글로벌에 남기고 나머지를 정리하는 개인 운영 방식도 공유한다.

58:17–59:52 본질은 경로와 참조 범위의 문제

설정 충돌은 결국 어떤 경로의 어떤 설정·스킬 파일을 참조할지에 대한 문제다. 연구 프로젝트와 강의 준비 환경을 Docker 단위로 나누거나, Claude Code의 프로젝트 단위 경로 설정을 세밀하게 구성할 수 있다. 강사는 자신이 모든 방법을 직접 쓰는 것은 아니므로 즉석에서 상세 설정을 확정하지 않고, Claude Code나 Codex에게 현재 문제를 그대로 설명해 경로 설정 대안을 요청해 보라고 권한다.

59:59–01:03:33 휴식과 실행 중인 데모

01:00 이후에는 휴식·음악 구간이 이어진다. 01:03:20에 다시 진행하려 하지만, 논문 수가 많아 데모 작업이 아직 실행 중이라고 말한다. 따라서 이 문서의 분석 범위는 검색 작업이 완료되기 전, 다음 발표로 넘어가기 직전에 끝난다. 이후 강의의 결과나 결론을 이 구간의 내용으로 간주하면 안 된다.

🧩 강의에서 확인되는 하네스 구성요소

✅ 강의 기준 실습 체크리스트

• 내 업무에서 검수해야 할 결과물을 한 문장으로 정의한다.

• 원본 자료와 결과물의 위치를 정한다.

• 업무 절차를 글·키워드·도식으로 표현한다.

• 목적 직접 지정 / 기존 워크스페이스 참조 / PRD·GSD 명세 중 구축 경로를 고른다.

• AGENTS.md·CLAUDE.md·스킬·런북의 역할을 구분한다.

• 검수 대상 자료 한 종류를 인제스트한다.

• 일반 요청 결과와 하네스 기반 결과를 비교한다.

• 도메인 전문가 기준을 루브릭으로 추가한다.

• 주장과 근거가 실제 원본과 일치하는지 확인한다.

• 중간 단계마다 누락·오선택·환각을 검토한다.

• 글로벌 설정과 프로젝트 설정이 충돌하지 않는지 확인한다.

• 필요하면 Docker 또는 프로젝트 로컬 설정으로 환경을 격리한다.

🔚 이 구간의 결론

강의의 핵심 원리

좋은 검수 AI는 마지막 답을 채점하는 모델이 아니라, 올바른 자료를 고르고 전문가 기준으로 중간 결과를 반복 검토하며 주장과 근거를 끝까지 연결하는 워크스페이스형 하네스다.

이 구간은 완성된 하네스 구현을 끝내는 수업이 아니다. 개인 워크스페이스를 만들고 자료를 인제스트해, 일반 생성과 하네스 기반 검수의 차이를 직접 확인하는 첫 단계다. 이후 주차에서 지식베이스·루브릭·멀티에이전트 구조를 더해 검수 시스템을 고도화하는 로드맵을 제시한다.