소개
시도하고자 했던 것과 그 이유를 알려주세요.
GPTers 스터디 1주차 과제로 deck6ix님의 AKM(Agent Knowledge Management) 시스템을 로컬에 설치하고, Claude(Cowork)를 에이전트로 붙여 실제 지식관리 루프를 돌려봤습니다. AKM은 Karpathy의 LLM Wiki 패턴(지식을 LLM이 읽는 마크다운 위키로 컴파일)을 지식 레이어로 채택하고, 거기에 실행→검증→Learn Back(실패를 시스템 개선으로 환류) 루프를 얹은 구조입니다.
단순히 구조만 구경하는 게 아니라, 세 가지를 직접 시험했습니다:
웹 리서치를 AKM 규칙(인박스 우선)대로 저장하기
저장된 정보의 오류를 일부러 파고들어 Learn Back 루프가 실제로 작동하는지 보기(이럴 의도는 없었으나 하다보니 눈에 보이는 오류가 있어 하게됨)
유튜브 영상(1시간짜리)을 자막 기반으로 정리·분석해서 지식 노트로 만들기
진행 방법
어떤 도구를 사용했고, 어떻게 활용하셨나요?
도구: Claude Cowork(로컬 폴더 연결) + AKM 저장소 + 웹 검색 + Chrome 브라우저 제어(유튜브 자막 추출)
① AKM 구조 파악
먼저 시스템이 뭘 요구하는지 물어봤습니다.
AKM을 제대로 작동되도록 만드려면 앞으로 어떤 명령을 내려야 하나요?AKM 규칙에 맞게 정리하려면 어떤 과정으로 명령해야 해?Claude가 저장소의 99-system/LOOP.md, ROUTER.md를 읽고 7단계 루프(Ingest→Classify→Compile→Contextualize→Execute→Verify→Learn Back)와 "인박스 우선, ROUTER 분류, INDEX/LOG 갱신, lint 검사" 파이프라인을 정리해줬습니다. (캡처 1: 루프 설명 답변 화면)
② 웹 리서치 인테이크
인박스에 아래 자료를 검색하여 넣어줘.
---
분당에서 지하 고속도로 계획이 있다고 한다.
이와 관련된 내용을 자세하게 검색하여 저장해줘.Claude가 웹 검색으로 "의왕~광주 고속도로(제2영동연결고속도로)" 관련 기사를 모아 frontmatter(SCHEMA 준수)를 갖춘 노트를 00-inbox/에 만들고 LOG.md에 한 줄을 남겼습니다. (캡처 2: 인박스 노트 파일)
③ 사실 검증 + Learn Back — 오늘의 하이라이트
저장된 노트에 "당골공원은 구미동 소재"라고 적혀 있었는데, 실제로는 분당동 소재입니다. 일부러 이렇게 지적했습니다.
이 정보가 실제 사실에 근거한 것인지 자세히 살펴보자.
당골공원은 분당동 소재이며 구미동이 아니다.
다른 부분들도 거짓인지 자세히 살펴보자.Claude가 검색 요약이 아닌 원 기사 2건(경인일보, 뉴스브레인)을 직접 열어 대조했고, 결과는:
당골공원 소재지 오류 확인·정정 (검색 요약문만 믿고 쓴 게 원인)
출처 간 상충 발견: 착공 일정(2026→2032 vs 2029→2036), 의견서 인원(4,260명 vs 4,371명) — 단정 대신 병기로 수정
70-evaluation/audits/에 감사 노트 생성: "지명·수치는 1차 출처 대조 전에 단정 기재 금지, 사용자 요청문의 전제도 검증 대상" 같은 재발 방지 규칙까지 기록
즉 실수가 그냥 수정으로 끝나지 않고 시스템 규칙으로 남는 것, 이게 AKM이 일반 노트앱과 다른 지점이었습니다. (캡처 3: 감사 노트)
④ 유튜브 영상 분석
https://www.youtube.com/watch?v=h_sI7zIdZLI 유튜브 동영상 내용을 정리하여
정말로 돈을 버는 투자 방법론이 있는지 분석하여 정리해주세요.일반 웹 fetch로는 유튜브 내용이 안 잡혀서, Claude가 Chrome 브라우저 제어로 영상 페이지를 열고 스크립트(자막) 패널을 켠 뒤 자막 전문(약 2만 9천 자)을 추출했습니다. 이를 기반으로 언더스탠딩 '독하게 돈 공부' 편(켈리 공식, 섀넌의 도깨비, 에드 소프)을 요약하고, "켈리 공식은 엣지를 만들어주는 공식이 아니라 엣지가 있을 때 파산하지 않는 베팅 크기 공식"이라는 비판적 분석까지 붙여 인박스에 저장했습니다. (캡처 4: 분석 노트)
결과와 배운 점
배운 점과 나만의 꿀팁:
"인박스 우선" 규칙이 생각보다 강력합니다. 모든 신규 자료가
00-inbox/에 착지하고 7일 안에 ROUTER로 분류되니, 에이전트가 아무 데나 파일을 흩뿌리는 문제가 구조적으로 막힙니다.묶음 명령 꿀팁: "이 자료 를 AKM 규칙대로 정리해줘 — 인박스에 넣고, ROUTER로 분류하고, 템플릿 맞춰 노트화한 뒤 INDEX/LOG 갱신하고 lint까지 돌려줘" 한 줄이면 파이프라인 전체가 돕니다.
에이전트의 답을 한 번 의심하는 게 곧 시스템 훈련입니다. 오류를 지적하면 정정에서 끝나지 않고
70-evaluation/에 재발 방지 규칙이 쌓여서, 다음 인테이크의 품질이 올라갑니다.
시행착오:
검색 도구의 요약문만 믿으면 사실 오류가 섞입니다 (당골공원 소재지 오류가 정확히 이 케이스). 지명·수치·날짜는 반드시 원문 기사를 열어 대조해야 합니다.
유튜브는 일반 fetch로는 빈 페이지가 나옵니다. 브라우저 제어로 자막 패널을 직접 열어야 했고, 자막이 ASR(자동생성)이라 고유명사 오류(존 켈리→"존리")가 있어 그 한계도 노트에 명시했습니다.
도움이 필요한 부분:
인박스 주간 트리아지를 스케줄 작업으로 자동화한 사례가 있다면 듣고 싶습니다.
검증 단계(VERIFICATION Tier 선택)를 어느 수준까지 습관화할지 기준을 잡는 중입니다.
앞으로의 계획:
쌓인 인박스 노트를 ROUTER로 분류해
10-sources/,20-knowledge/로 승격30-context/에 내 프로젝트·선호 정보를 채워 Contextualize 단계 가동반복되는 "유튜브 자막 추출→분석" 작업을
50-procedures/프로시저로 승격
도움 받은 글 (옵션)
deck6ix, AKM 저장소 (README, 99-system 문서 일체)
Karpathy의 LLM Wiki 패턴 — https://karpathy.bearblog.dev/
Zoom 강의와 스터디 단톡방에서 받은 피드백이 큰 도움이 되었습니다. 감사합니다!
