소개
시도하고자 했던 것과 그 이유를 알려주세요.
시도한 것: 현재 클로드 채팅 프로젝트 (Claude Project)에서 수작업으로 하고 있는 (리서치) 리포트 작성과 트렌드 정리를, 클로드코드 기반의 "리서치 에이전트 팀"으로 자동화하는 것. 향후 리서치 결과가 쌓이는 지식베이스 (LLM WIKI)는 옵시디언 (Obsidian)으로 연결하면 깔끔할 것으로 생각했다.
선정 이유: 지금까지 클로드 프로젝트로 "(2026) IP 토큰화 발표"(최종 발표까지 완료), "(2026) K-Strategy"(상당 부분 진행) 등 여러 리서치성 프로젝트를 돌려왔는데, 매번 같은 흐름, 가령, 질문 정의 → 자료 수집 → 검증 → 구조화 → 리포트/발표자료 등을 수작업으로 반복하고 있었다. 게다가 리서치 결과가 각 프로젝트의 채팅 안에 갇혀 있는 경우가 많아서, 다음 프로젝트에서 재사용이 안 된다는 것이 가장 큰 비효율이었다.
이번 자동화의 구조: 완료/진행된 두 프로젝트 (IP 토큰화 발표, K-Strategy)의 산출물을 "학습 (패턴 추출) 대상"으로 삼아 리서치 하네스를 설계하고, 새로 시작하는 "(2026) IP RWA project (개인)"에 이 하네스를 실전 적용해 본다. 리서치 에이전트 팀을 한 번 잘 만들어두면, 이후 다른 프로젝트에도 그대로 재사용할 수 있다는 것이 나의 가설이다.
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
Tip: 사용한 프롬프트 전문을 꼭 포함하고, 내용을 짧게 소개해 주세요.
Tip: 활용 이미지나 캡처 화면을 꼭 남겨주세요.
Tip: 코드 전문은 코드블록에 감싸서 작성해주세요. ( / 을 눌러 '코드 블록'을 선택)
클로드코드 (Claude Code)
STEP 1. 자동화 후보 업무 나열과 선정
먼저 내가 클로드와 해 온 업무를 후보로 나열하고,
①반복성 ②표준화 가능성 ③자동화 효과 세 가지 기준으로 비교했다.
자동화 후보 업무
반복성
표준화 가능성
자동화 효과
① 리서치 리포트 작성
(자료수집→분석→리포트)
높음
(프로젝트마다 반복)
높음
(패턴이 명확)
매우 큼
② 트렌드/뉴스 모니터링 및 요약
매우 높음
(주간 단위)
높음
큼
③ 발표자료 (스토리라인) 초안 작성
중간
중간
(주제별 편차)
중간
④ 리서치 결과의
지식베이스 (위키) 축적
높음
높음
(포맷 통일 가능)
큼
(재사용 가치)
선정 결과: ①번 "리서치 리포트 자동 작성"을 메인 자동화 대상으로 선정하고,
②트렌드 모니터링과 ④위키 축적을 같은 하네스 안의 서브 기능으로 함께 설계하기로 했다.
세 가지가 사실상 하나의 파이프라인 (수집→분석→리포트→위키 축적)으로 묶이기 때문이다.
STEP 2. 기존 프로젝트에서 나의 리서치 패턴 추출
에이전트 팀 설계의 재료는 "내가 실제로 일해 온 방식"이다.
두 프로젝트에서 공통 패턴을 뽑아 보았다.
• (2026) IP 토큰화 발표: 주제/청중 정의 → 개념·용어 정리 → 해외/국내 사례 수집 → 규제·법률 이슈 검토 → 시사점 도출 → 발표 스토리라인 구성 → 발표자료 완성
• (2026) K-Strategy: 정책·시장 동향 수집 → 국가/기업별 비교 분석 → 전략 프레임워크 적용 → 전략 리포트 작성
공통 패턴 (= 하네스의 뼈대): ① 리서치 질문 정의 → ② 소스 수집 (뉴스/보고서/논문/규제)
→ ③ 출처 검증 및 교차확인 → ④ 프레임에 맞춘 구조화 분석
→ ⑤ 산출물 변환 (리포트 또는 발표 스토리라인) → ⑥ 핵심 지식의 위키 축적
참고: 채팅 프로젝트의 대화는 프로젝트별로 분리되어 있어 클로드코드가 직접 읽을 수 없다고 한다. 그래서 두 프로젝트의 최종 산출물 (발표자료, 리포트, 핵심 정리 문서)을 파일로 export해서 클로드코드 작업 폴더의 seed/ 디렉토리에 넣고, 에이전트에게 "이 산출물에서 나의 리서치 패턴과 품질 기준을 추출하라"고 시키는 방식으로 학습시킨다. 이것이, 채팅의 프로젝트와 클로드코드를 연결하는 첫 번째 다리라고 할 수 있다.
STEP 3. 하네스(Harness) 설계 — 디렉토리 구조와 CLAUDE.md
하네스 엔지니어링의 핵심은 "에이전트가 일할 작업장 (구조)과 규칙 (CLAUDE.md)을 먼저 만들어 주는 것"으로 이해했다. 설계한 작업 폴더 구조는 다음과 같다.
ip-research-harness/
├── CLAUDE.md # 전체 규칙: 리서치 원칙, 출처 표기, 산출물 포맷
├── seed/ # 기존 프로젝트 산출물 (패턴 학습용)
│ ├── 2026-ip-tokenization/ # IP 토큰화 발표 자료 export
│ └── 2026-k-strategy/ # K-Strategy 리포트 export
├── .claude/agents/ # 서브에이전트 정의
│ ├── research-lead.md # 오케스트레이터 (계획 수립·업무 분배)
│ ├── source-scout.md # 소스 수집 (뉴스·보고서·규제)
│ ├── analyst.md # 구조화 분석 (프레임워크 적용)
│ ├── fact-checker.md # 출처 검증 및 교차확인
│ ├── report-writer.md # 리포트/발표 스토리라인 작성
│ └── wiki-librarian.md # 핵심 지식 위키 반영
├── projects/
│ └── 2026-ip-rwa/ # 이번 실전 적용 대상 프로젝트
│ ├── 00_question.md # 리서치 질문 정의
│ ├── 10_sources/ # 수집 자료 (출처 메타데이터 포함)
│ ├── 20_analysis/ # 분석 노트
│ └── 30_output/ # 최종 리포트·발표 초안
└── wiki/ # LLM WIKI (옵시디언 vault로 사용)
├── concepts/ # 개념 노트 (IP 토큰화, RWA, ...)
├── cases/ # 사례 노트
├── regulations/ # 규제 노트
└── trends/ # 주간 트렌드 노트
CLAUDE.md에는 모든 에이전트가 공통으로 지켜야 할 규칙을 담는다. 다음은 초안 전문이다.
초안 전문:
# CLAUDE.md — IP 리서치 하네스 공통 규칙
## 목적
IP/RWA 도메인 리서치를 수집→검증→분석→리포트→위키 축적 순서로 수행한다.
## 리서치 원칙
1. 모든 주장에는 출처 (제목, 기관, 날짜, URL)를 남긴다.
2. 단일 출처 주장은 '미검증'으로 표시하고 fact-checker의 교차 확인을 거친다.
3. 2차 자료보다 원문(규제 원문, 백서, 공시)을 우선한다.
4. 분석은 seed/에서 추출한 나의 기존 프레임(사례→규제→시사점)을 따른다.
## 산출물 포맷
- 리포트: 30_output/report.md (개요/핵심발견/사례/규제/시사점/출처)
- 발표 초안: 30_output/storyline.md (슬라이드 단위 스토리라인)
## 위키 규칙
- 재사용 가치가 있는 지식은 wiki/에 노트로 축적한다.
- 노트는 옵시디언 호환: YAML frontmatter + [[위키링크]] 사용.
- 파일명은 한글 개념명, frontmatter에 tags/updated/출처를 기록한다.
STEP 4. 리서치 에이전트 팀 설계
클로드코드의 서브에이전트 기능을 사용해 6개 역할로 팀을 구성한다.
대표로 오케스트레이터인 research-lead의 정의 전문은 다음과 같다:
name: research-lead
description: 리서치 프로젝트 총괄. 질문을 작업으로 분해하고 서브에이전트에 분배한다.
---
너는 IP/RWA 도메인 리서치 팀의 리드다.
1. projects/{프로젝트}/00_question.md 의 리서치 질문을 읽는다.
2. seed/ 의 기존 산출물에서 사용자의 리서치 패턴 (구성, 깊이, 프레임)을 파악한다.
3. 질문을 소스수집/분석/검증 작업으로 분해해 계획을 10_sources/plan.md 에 쓴다.
4. source-scout → fact-checker → analyst → report-writer 순으로 작업을 지시한다.
5. 각 단계 산출물이 CLAUDE.md 포맷을 지키는지 검수하고, 미흡하면 재작업시킨다.
6. 완료 후 wiki-librarian 에게 위키 반영 대상 목록을 전달한다.
실제 실행 시 클로드코드에 입력할 프롬프트 전문 예시:
seed/ 폴더에 있는 두 프로젝트 산출물 (2026-ip-tokenization, 2026-k-strategy)을 읽고,
나의 리서치 패턴을 다음 관점에서 추출해서 seed/pattern.md 로 정리해줘:
1) 리서치 질문을 어떻게 정의하는가
2) 어떤 종류의 소스를 어떤 순서로 수집하는가
3) 분석 프레임(사례/규제/시사점 등)의 구조
4) 최종 산출물(리포트/발표)의 목차와 톤
이 pattern.md 는 이후 모든 에이전트가 참조하는 품질 기준이 된다.
STEP 5. LLM WIKI 설계 (옵시디언 연결)
리서치가 끝날 때마다 휘발되지 않도록, 재사용 가치가 있는 지식을 wiki/에 축적한다.
wiki/ 폴더 자체를 옵시디언 vault로 열면 별도 연동 작업 없이, 바로 그래프 뷰와 위키링크를 쓸 수 있다는 점이 마음에 들었다. 노트 포맷 예시는 다음과 같다:
tags: [RWA, 토큰화, 규제]
updated: 2026-07-27
source: 프로젝트 2026-ip-rwa
---
# IP 토큰화 (IP Tokenization)
지식재산권을 블록체인 토큰으로 표현해 유동화하는 것.
[[RWA]]의 하위 개념이며, [[저작권 신탁]] 구조와 결합할 때 [[STO 규제]] 이슈가 발생한다.
## 핵심 사례
- ... (cases/ 노트로 링크)
STEP 6. 클로드 채팅 프로젝트 ↔ 클로드코드 연결 방안
두 도구를 잇는 방법으로 아래 3단계를 계획해 보았다.
• (지금) 파일 브리지: 채팅 프로젝트의 산출물을 md/pdf로 export → 하네스의 seed/에 투입.
반대로 클로드코드가 만든 리포트 md를 채팅 프로젝트의 "프로젝 트 지식"에 업로드해서,
채팅에서는 결과를 놓고 토론 및 수정하는 용도로 사용.
• (다음) 위키를 단일 소스로: wiki/를 옵시디언 vault이자 프로젝트 지식의 원천으로 승격.
채팅 프로젝트에는 위키의 핵심 노트만 동기화.
(향후) MCP 연동: 옵시디언 MCP 서버를 붙여서 채팅/클로드코드 양쪽에서 같은 vault를 직접 읽고 쓰게 하는 것. 스터디에서 사례를 찾아보며 검토 예정.
결과와 배운 점
배운 점과 나만의 꿀팁을 알려주세요.
• 배운 점 1 — 자동화 대상은 "업무"가 아니라 "패턴":
"리서치를 자동화한다"는 막연했지만, 과거 프로젝트 2개를 나란히 놓고 보니 6단계 공통 패턴이 보였고, 그 패턴이 그대로 에이전트 팀 구조가 되었다.
자동화 대상 선정 = 내 반복 패턴 발견이라는 게 이번 주 가장 큰 수확.
• 배운 점 2 — 하네스가 먼저, 에이전트는 나중:
에이전트 프롬프트보다 폴더 구조와 CLAUDE.md 규칙 (출처 표기, 산출물 포맷)을 먼저 고정하는 것이 품질을 좌우한다고 이해했다.
• 꿀팁 — seed 폴더 전략: 완료된 프로젝트 산출물을 seed/로 넣고 "내 패턴을 추출해 pattern.md로 만들어라"고 시키면, 그 파일이 팀 전체의 품질 기준서가 된다.
잘된 과거 결과물이 곧 최고의 프롬프트가 되는 구조이다.
과정 중에 어떤 시행착오를 겪었나요?
• 클로드 채팅의 대화 기록은 프로젝트 별로 분리되어 있어,
다른 프로젝트의 대화를 클로드코드가 (그리고 채팅 클로드조차) 직접 읽을 수 없다는 것을 확인. → 산출물을 파일로 export하는 "파일 브리지" 방식으로 우회하기로 했다.
• 처음에는 에이전트를 많이 만들수록 좋다고 생각했는데, 역할이 겹치면 오히려 관리가 어려워 보였다. 수집/검증/분석/작성/축적이라는 패턴의 단계 수 만큼만 두는 것을 현재 버전으로 정리. 사실 더 줄여야 하나 아직 살짝 고민이기도 한데, 하면서 최종 판단을 내리려 한다.
도움이 필요한 부분이 있나요?
• 클로드코드 서브에이전트 정의 (.claude/agents/)의 베스트 프랙티스: 특히 에이전트 간 산출물을 주고받는 패턴을 어떻게 잡는 게 좋은지 사례가 궁금.
• 옵시디언 MCP 연동을 실제로 해 보신 분의 세팅 방법과 주의점.
앞으로의 계획이 있다면 들려주세요.
• 2주차: seed/ 투입 → pattern.md 추출 → 에이전트 6종 정의 완성 (하네스 구축).
• 3주차: "(2026) IP RWA project (개인)"의 리서치 질문을 00_question.md로 정의하고 파이프라인 첫 실전 가동.
4주차~: 트렌드 모니터링(주간)을 하네스에 추가하고, wiki/를 옵시디언 vault로 운영 시작.
잘 되면 다른 프로젝트에도 같은 하네스를 복제 적용.
도움 받은 글 (옵션)
참고한 지피터스 글이나 외부 사례를 알려주세요.
(내용 입력)
