스터디에서 "Knowledge Manager"가 요약기가 아니라 지식 운영 하네스(Extract → Retrieve → Verify → Store → Propagate)라는 개념을 접했습니다. 평소 퀀트 투자 전략 연구에 관심이 있었는데, 마침 수백 편의 논문을 리서치해서 관심 분야를 체계적으로 추려내고 싶다는 목표가 있었습니다. 단순히 논문을 요약해서 쌓아두는 게 아니라, "통계적으로 유의미한 결과"와 "경제적으로 납득 가능한 논리를 가진 결과"를 구분해내는 지식베이스(퀀트 Research Wiki)를 만들어보고 싶어서 시도했습니다.
진행 방법
사용 도구: Claude (Cowork)를 에이전트로 활용해 대화형으로 구조를 설계하고, 실제 폴더·문서·JSON Schema 파일까 지 생성했습니다.
진행 순서:
스터디에서 공유받은 개념(하네스 = Extract/Retrieve/Verify/Store/Propagate 파이프라인, Control Plane vs Execution/Verification Plane 분리)을 제 연구 목적에 맞게 재해석해달라고 요청했습니다.
스터디장님께서 권장한 "Self Discovery" 방식(질문에 답하며 시스템을 점진적으로 설계)을 따라, 제가 정보를 처리하는 습관(한 편을 깊게 파고듦 → 노트 앱에 요약 → 폴더 계층 탐색 → 과부하 시 세분화 대신 재범주화)을 먼저 진단받았습니다.
이후 실제 폴더 구조·스키마 초안을 만들어달라고 요청했고, 관심 도메인(팩터 투자, 포트폴리오 구성·리스크관리)을 정했습니다.
강의자가 권장한 정석 순서(PRD.md → data_model.md → 폴더/스키마)와 제가 진행한 순서가 반대라는 걸 뒤늦게 인지해서, 기존 산출물을 지우지 않고 PRD.md·data_model.md를 역산해서 보완했습니다.
사용한 프롬프트 예시:
내가 llm-wiki, personal knowledge-manager 관련된 연구 논문 서베이를
체계적으로 저장하는 지식 베이스를 구축하고 싶어. 수백개의 논문을
리서치 하고, abstract와 discussion 내용을 기반으로 관심 분야의
논문을 전부 추려낸다. 그리고 내가 원하는 연구 주제에 맞는 것을
전부 선별해(공유해주신 자료 프롬프트)그럼 오늘 초안에서 다룰 퀀트 논문 리서치의 구체적인 관심 주제는
무엇인가요? → 1(팩터 투자), 5(포트폴리오 구성·리스크관리)로 시작.
최종 목표는 10개 도메인 다 해보고 싶음. 여러 방면으로 하려면
자료 정리를 잘 해둬야 하는지 확인 요청.결과와 배운 점
결과물: research-wiki/ 아래에 아래 구조를 완성했습니다 (논문은 아직 한 편도 안 넣은 초안 상태).
research-wiki/
├─ PRD.md # 목표: 통계적 유의성 vs 경제적 근거 구분
├─ data_model.md # 개체(Paper/Domain/EconomicRationale 등) 관계 정의
├─ raw/ # 원문 PDF (읽기 전용)
├─ database/ # SQLite 등 판정 결과 저장 예정
├─ wiki/
│ ├─ research-question.md # 최종 10개 도메인 + 현재 활성(D01,D05)
│ ├─ inclusion-criteria.md # 공통기준(G1~G4) + 도메인별 기준
│ ├─ exclusion-criteria.md
│ ├─ concepts/ methods/ findings/ debates/ gaps/ syntheses/
├─ review/ # included / excluded / uncertain / audit-samples
├─ schema/
│ ├─ paper-schema.json # JSON Schema (draft-07)
│ ├─ AGENTS.md # 저장소 규칙 (Always/Ask/Never)
│ └─ screening-rubric.md # 3단계 선별 + 6단계 검수 게이트
└─ log.md배운 점 / 나만의 꿀팁:
"하네스"는 1회성 요약이 아니라, 새 정보가 기존 지식과 교차검증되고 기존 문서까지 갱신되는 폐루프 파이프라인이라는 개념이 핵심이었습니다.
LLM 검증(Verify 단계)을 같은 모델이 프롬프트만 바꿔서 수행하면 "검수자 독립성" 문제가 생긴다는 지적이 인상 깊었습니다. → 스키마에
verifier_independent필드를 넣어서, 실제로 다른 모델/결정론적 스크립트가 검증했을 때만 true로 기록하도록 강제했습니다.퀀트 논문 특성상 "통계적으로 유의미함"과 "경제적으로 왜 그런지 설명됨"을 분리하지 않으면 나중에 팩터 주(factor zoo) 문제를 걸러내기 어렵다는 걸 깨닫고,
economic_rationale_type(risk_based/behavioral/institutional_friction/data_mining_risk/unclear) 필드를 별도로 설계했습니다.UNCERTAIN 판정을 강제로 포함/제외시키지 않고 보존하는 것, 제외 논문 5~10%를 무작위 감사하는 것 등 재현율 손실을 막는 장치를 처음부터 스키마·규칙 문서에 못박아뒀습니다.
시행착오:
처음에 스터디장님께서 권장한 순서(PRD → data_model → 구조)를 모르고 거꾸로(구조 → 스키마 → 뒤늦게 PRD) 진행했습니다. 다행히 기존 산출물을 지우지 않고 역산해서 보완할 수 있었지만, 처음부터 순서를 알았다면 더 매끄러웠을 것 같습니다.
"초안 범위에서 안 할 일"을 스스로 정의하는 게 생각보다 어려웠습니다. 처음엔 막막해서 기본값을 제안받아 확정하는 방식으로 진행했습니다.
도움이 필요한 부분:
스터디에서 실제로 사용하는 PRD 질문 세트(정확한 문항)를 모른 채 임의로 질문을 구성해서 진행했습니다. 강의자의 원래 질문 흐름과 비교해보고 싶습니다.
검증자 독립성(동일 모델계열 한계)을 실제로 어떻게 구현하는지 — 예를 들어 다른 LLM API를 교차검증에 쓰는 구체적 방법 — 에 대한 안내가 필요합니다.
지금까지 설계한 방향(raw/database/wiki/review/schema 5분할 구조, 논문 1편당 JSON Schema로 통계적 결과와 경제적 근거(economic_rationale_type)를 분리해서 기록, 10개 퀀트 도메인을 태그로 확장 가능하게 설계, PRD.md·data_model.md를 뒤늦게 역산해서 보완한 점)이 실제로 맞는 방향인지 봐주실 수 있을까요? 혹시 이 설계가 방향이 잘못됐거나 비효율적이라면 어떤 부분을 어떻게 바꿔서 다시 설계해나가면 좋을지 구체적으로 조언 부탁드립니다.
앞으로의 계획:
실제 관심 논문 2~3편을 스키마에 손으로 채워 파이프라인이 실제로 작동하는지 검증.
database/에 SQLite 초기 스키마 생성.
논문이 쌓이면 concepts/, findings/, debates/ 페이지 작성 시작.
이후 도메인을 D01·D05 외로 점진적으로 확장.
