📝 한줄 요약
gpters 스터디 과제로 AI 지식관리 체계 **AKM(Agent Knowledge Management)**을 처음 클론해서, 폴더 구조·규칙·워크플로우를 하나씩 파고들며 실제 노트 9개까지 직접 쌓아본 학습 기록입니다.
바쁘시면 이것만 읽어도 돼요:
AKM은 "많이 저장"이 아니라 "역할별로 나눠 제자리에 두기" 가 핵심 — 저장 시점의 분류가 나중 검색 품질을 결정한다
같은 '정보의 저장'인데도 내용 성격에 따라 knowledge·context·memory 3계층으로 분산되는 걸 직접 보고 개념이 잡혔다
AKM은 기존 LLM Wiki를 부정하는 게 아니라 knowledge 레이어로 흡수하고, 실행·검증·학습(Learn Back)을 더한 '운영체제'였다
결정적 배움: 이론 설명만 듣지 말고, 개념을 잘게 쪼개 계속 되물으며 실제 노트를 직접 쌓아보는 것이 가장 빠른 학습법
🎯 이런 분들께 도움돼요
LLM Wiki는 써봤는데 "학습용 지식"과 "실제 프로젝트 실행"이 따로 놀아서 답답했던 분
AI에게 매번 처음부터 설명하는 게 비효율적이라, 지식을 체계적으로 쌓고 싶은 분
AKM/지식관리 시스템을 처음 접해서 폴더 구조부터 막막한 분
😫 문제 상황 (Before)
저는 그동안 LLM Wiki를 성공적이지는 않지만 사용은 해봤습니다. 이와는 별도로 실제 프로젝트(제안서, 앱, 영상 등)를 진행할 때는 워크스페이스를 만들어 작업했죠. 고민은 "아는 곳(Wiki)"과 "일하는 곳(프로젝트)"이 완전히 단절돼 있었다는 겁니다. Wiki에 정리한 지식이 실제 작업으로 자동으로 이어지지 않았고, 작업하며 얻은 교훈도 다시 Wiki로 돌아오지 않았습니다.
그러던 중 **gpters 23기 스터디 과제로 AKM(Agent Knowledge Management)**을 다루게 됐습니다. "이 둘을 하나로 합칠 수 있다는데, 도대체 어떻게?"라는 궁금증으로 시작했습니다.
🛠️ 사용한 도구
도구명: Claude Code
모델: Claude Opus
특이사항: AKM은 DB도 서버도 없이 폴더 + 마크다운 파일 + Git으로만 굴러가는 순수 텍스트 지식 체계
🔧 작업 과정
첫 실습 — 웹 글 하나를 규칙대로 정리해보기
개념만 듣는 것보다 실제로 해보는 게 빠를 것 같아서, 웹 글 하나를 AKM 규칙에 맞춰 정리해달라고 했습니다.
이 URL을 방금 설치한 AKM 규칙에 맞춰 정리해줘
Claude는 ROUTER(분류 규칙)를 따라 판단했습니다. 외부 원문이니 **10-sources(원본 보존, 수정 금지)**에 먼저 저장하고, 그걸 읽고 소화한 정제 지식은 **20-knowledge**에 따로 만들더군요. 원본과 해석을 분리하는 이 흐름이 AKM의 뼈대라는 걸 첫 실습에서 바로 느꼈습니다.
이어서 방금 한 이 정리 과정 자체를 재사용 절차로 저장해달라고 했고, 50-procedures에 "웹 자료를 AKM에 정리하는 7단계 절차"가 생겼습니다. 나중에 하네스 엔지니어링을 조사할 때 이 절차가 그대로 재사용되는 걸 보고 "아, 이게 절차화의 힘이구나" 싶었습니다.
계속 파고들며 잡은 감 — source와 knowledge의 경계
본격적으로 구조를 파고들면서, source와 knowledge를 어떻게 구분하는지 계속 물었습니다. 한 번에 이해하려 하지 않고 "이건 어디 넣어?" → "그럼 누가 만들어?"처럼 꼬리를 물었더니 경계가 또렷해졌습니다.
핵심 기준은 "손 안 댄 원본이냐(→source)" vs "읽고 소화해 새로 쓴 재사용 지식이냐(→knowledge)" 였습니다. 원본은 박제하듯 그대로 두고, 거기서 내가 정리·종합한 것만 knowledge로 올리는 거죠. 헷갈릴 때 "이 파일을 나중에 내가 고칠 일이 있나?"를 자문하면 대부분 갈렸습니다.
같은 '가이드 저장'이 3계층으로 쪼개지다
학습 가이드를 저장하는 실습에서 정말 "오!" 했습니다. 그냥 한 파일에 저장될 줄 알았는데, Claude는 같은 가이드를 내용 성격에 따라 세 곳으로 나눴습니다.
7계층·루프·명령어 같은 보편 지식 →
20-knowledge"이건 gpters 학습 클론이다 / 이 사용자는 초심자다" 같은 이 프로젝트·사람만의 것 →
30-context매 세션 먼저 읽을 요약 포인터(링크만) →
40-memory
"저장 = 한 곳에 넣기"라고 생각했던 제 머릿속 그림이 이때 완전히 바뀌었습니다. 같은 내용도 성격에 따라 흩어 담는 게 AKM의 핵심이었습니다.
"그럼 실제 작업은 AKM에서 하는 거야?"
가장 실질적인 걱정이 하나 있었습니다. 제안서 같은 실제 작업은 전용 커맨드·에이전트가 있는 별도 워크스페이스에서 하는데, AKM 세션을 열면 그 도구들을 못 쓰는 거 아닌가?
akm에서 세션을 열게 되면 해당 커맨드나 에이전트를 사용할 수없고,
akm세션 자체에서 제안서 작성 작업을 하게 되는거 아냐?
정답은 **"방향을 뒤집으면 된다"**였습니다. AKM에서 작업하는 게 아니라, 외부 작업 워크스페이스에 어댑터를 심어서 그 세션이 AKM의 지식을 읽고 쓰게 만드는 구조더군요. AKM은 두뇌, 실제 작업은 손. 그리고 작업하며 얻은 교훈은 "배울 게 생기는 순간마다" AKM으로 되돌리는(Learn Back) 양방향 순환이 이 시스템의 진짜 가치였습니다.
✅ 결과 (After)
Before vs After
항목
Before
After
저장 위치 판단
"이걸 어디 넣지?" 매번 막막
source/knowledge/context를 스스로 구분 가능
지식 ↔ 실행
Wiki(학습)와 프로젝트(실행)가 단절
어댑터 + Learn Back으로 연결되는 그림이 잡힘
이해 방식
이론 설명만 들음
실제 노트 9개를 직접 쌓으며 검증
결과물
이번 학습으로 워크스페이스에 실제로 쌓인 노트들:
원본(source) 2개: gpters 원문, 하네스 엔지니어링 조사 자료
정제 지식(knowledge) 3개: AKM 7계층 구조, 하네스 엔지니어링, 워크스페이스 가이드
맥락(context) 2개: 프로젝트 맥락, 사용자 맥락
메모리 1개 + 절차 1개: 세션 시작 포인터, 웹 자료 정리 절차
💬 이 과정에서 배운 AI 활용 팁
효과적이었던 것
개념을 잘게 쪼개 계속 되물었다 — "source vs knowledge?" → "그럼 누가 만들어?"처럼 한 번에 이해하려 하지 않고 꼬리를 물었더니, 헷갈리는 지점이 정확히 어디인지 짚어낼 수 있었습니다.
이론만 듣지 않고 직접 노트를 쌓았다 — 실제 웹 글 하나를 규칙대로 정리해보니, 표로 설명들을 때보다 개념이 훨씬 빨리 잡혔습니다.
이렇게 하면 안 돼요
설명을 한 번에 다 이해하려 하지 마세요 — 한꺼번에 삼키면 어디서 막혔는지도 모른 채 넘어갑니다. 걸리는 지점을 구체적으로 되물어야 개념이 제대로 잡힙니다.
실습 없이 설명만 듣고 끝내지 마세요 — 머리로는 이해한 것 같아도, 실제 자료 하나를 규칙대로 정리해보기 전까지는 감이 잡히지 않습니다.
🌍 다른 업무에 적용한다면?
AKM의 "역할별 분리 저장" 원리는 꼭 AI가 아니어도 통합니다. 받은 원본 자료와 내가 소화해 정리한 내용을 섞지 않고 따로 두는 것만으로도, 나중에 "이게 사실인지 내 해석인지" 헷갈리는 일이 크게 줄어듭니다. 개인 노트 정리, 팀 위키, 프로젝트 자료 관리 어디에나 적용해볼 수 있는 습관입니다.
🚀 앞으로의 계획
워크플로우별로 실행되는 md 파일과 템플릿 파일은 아직 학습이 더 필요합니다. 어떤 상황에서 어떤 템플릿이 발현되는지 구체적으로 파고들 예정입니다.
이번에 잡은 개념을 바탕으로, 실제 제안서 프로젝트에 어댑터를 심어 AKM ↔ 작업 워크스페이스 양방향 순환을 직접 돌려볼 계획입니다.