지식관리는 단순히 적재만 하는 것이 아니라, 좋은 지식을 쌓고 '액션'으로 이어지게끔 하는 환경을 만드는게 중요하다고 생각합니다. 또한 새로운 지식을 생산하여 어떤 액션을 했는지 기록하고 사이클을 만들기 위한 과정을 좀 담았습니다. 그럼 글 시작해보겠습니다. (내일 좀 더 수정 예정입니다.)
소개
시도하고자 했던 것과 그 이유
콘텐츠 자동화 시스템(하네스)을 몇 달째 운영하면서 이상한 걸 느꼈습니다. 유튜브 대본, 스레드, 인스타 카드뉴스가 계속 뽑혀 나오는데, 발행한 글은 계속 쌓이기만 할 뿐 다시 맥락이 깨끗하게 참고된다는 느낌을 받지 못했습니다. 스킬을 주기적으로 업데이트해도 뭔가 좀 찌무찌무 했습니다. 폴더 안에 글 수백 개가 잠들어 있었고, 새 콘텐츠를 쓸 때마다 사실상 매번 처음부터 다시 쓰는 것과 다를 게 없었습니다. 글은 쌓이는데 좋은 지식은 안 쌓이는 상태였던 겁니다.
그래서 덱 선생님의 DECK6/akm이라는 지식관리 시스템 구조를 활용하고, 제 하네스를 통째로 그리로 옮기기로 했습니다. 단순히 옵시디언 그래프뷰에 노드를 많이 쌓는 게 목표가 아니라, "수집 → 분류 → 지식화 → 맥락 반영 → 실행 → 검증 → 다시 배우기"라는 순환 구조를 갖춰서, 발행한 글이 진짜 재사용 가능한 지식으로 쌓이고 그게 다시 남들과 다른 제 맥락이 진하게 밴 콘텐츠로 돌아오게 만드는 게 목표였습니다.
진행 방법
1) 옮기기 전에, 지금 뭐가 있는지부터 문서로 정리했습니다
복잡하게 커져 있는 프로젝트를 다른 구조로 옮기려면, 가장 먼저 해야 할 일은 지금 뭐가 있는지 정확히 파악하는 것이었습니다. 그래서 마이그레이션을 시작하기 전에 이렇게 요청했습니다.
지금 이 하네스 기준으로 폴더 트리맵과 각 폴더에 대한 설명 문서를 만들어주세요. 목적은 이 폴더 구조를 DECK6/akm 저장소 구조로 마이그레이션하기 위함입니다. 마이그레이션 전에 지금 각 폴더에 어떤 내용이 들어 있는지 정확히 파악하고, 그 맥락을 전달할 수 있는 참고 문서를 먼저 만들어두고 싶습니다.
README에 이미 대략적인 구조 설명이 있었지만, 그걸 실제 폴더 트리와 다시 대조해서 최신화하는 작업을 시켰습니다. 결과로 나온 harness-folder-map__v01__migration-context.md 문서는 187줄짜리였는데, 구성이 꽤 쓸모 있었습니다.
전체 폴더 트리를 데이터·실행·산출 3개 레이어로 주석 달아 정리한 맵
폴더별 한 줄 요약 + 마이그레이션 시 고려사항까지 담은 표
지금 구조에서 새 시스템으로 가져갈 만한 설계 패턴 8가지 메모 (데이터·로직 분리, 정체성 파일의 "5+1" 구조, 스킬 폴더 평면 네이밍, 상위-하위 스킬 계층, 결정론적 검증 게이트 등)
이 문서가 뒷단계 전체의 지도 역할을 했습니다. 실제로 다음 날 이관 작업을 시작할 때 가장 먼저 "이 문서를 보라"고 다시 불러온 게 바로 이 파일이었습니다.
기존 컨텐츠 하네스 예시
2) 자기 전 요청 → 밤사이 리서치 → 아침 인터뷰
다음 날 밤, 다음과 같이 요청을 남기고 잠들었습니다.
harness-folder-map__v01__migration-context.md 내용을 보세요. https://github.com/DECK6/akm 구조로 지식관리를 하고 싶습니다. 제가 SNS 여러 플랫폼에 올리고 쓰는 글(메인)들을 관리하고, 아직 안 해본 플랫폼의 레퍼런스 글(비중은 적음)을 참고해서 새로운 인사이트가 있는 SNS 글로 재창조하는 게 목표입니다 — 릴스 대본, 유튜브 대본, 링크드인 글, 캐러셀 카피라이팅 등 폭넓게요. 그러려면 지금 가진 스킬들도 대부분 복사하거나 이관해야 합니다. 어떻게 해야 장기적으로 좋은 지식관리를 할 수 있을지 고민입니다. akm의 폴더 대부분을 활용하고 싶고, 옵시디언 그래프뷰로 단순히 예쁘게 보이는 것보다 좋은 지식을 실제로 쌓아서, 제 정체성과 맥락이 온전히 반영된 인사이트 있는 글과 콘텐츠를 만드는 게 최종 목표입니다. 저는 이제 자야 해서, 내일 아침에 궁금한 걸 답변하겠습니다. 모호함을 최소화할 인터뷰를 준비하고 계획을 짜 두세요.
이 방식이 좋았던 이유는 "다 정해서 시키는" 대신 "궁금한 걸 먼저 물어보게" 했다는 점입니다. 자는 동안 akm 저장소 구조를 리서치하고, 아침에 답할 인터뷰 질문지(git 정책, 레퍼런스 수집 방식, 자동화 여부, 파일럿 채널 등)를 준비해뒀습니다. 아침에 몇 가지만 답하니 바로 실행 가능한 계획이 나왔습니다.
3) 단계별로 옮겼습니다
한 번에 다 옮기지 않고 단계를 나눴습니다. 빈 저장소에 akm 골격을 먼저 이식하고, 가장 구조가 단순한 Threads부터 파일럿으로 옮겨서 검증한 뒤, YouTube로 확장하고, 마지막으로 발행물에서 실제 훅 패턴·플랫폼 문법 같은 인사이트를 뽑아 지식층(20-knowledge)을 처음 채웠습니다.
4) 검증 질문으로 빈틈을 확인했습니다
시스템이 다 만들어진 것처럼 보였을 때, 그냥 "잘 됐나요?" 라고 묻지 않고, 평소 제가 갖고 있던 구체적인 문제의식 하나를 던져서 이 시스템이 그 맥락까지 잡아내는지 되물었습니다. 그래서 긴 프롬프트를 던져보았습니다.
에이전틱 코딩을 하다 보면, 프롬프트 한 번으로 에이전트를 얼마나 오래 돌렸는지를 자랑하는 글을 자주 봅니다. 인지심리학의 전문성(expertise) 연구 관점에서 보면 이건 위험한 신호입니다. 전문성이 늘기 어려운 구조이기 때문입니다. 내가 한 행동과 그 결과를 받아보는 시점 사이의 간격이 멀어질수록, 그리고 그 결과물이 복잡하고 복합적일수록 전문가로서 성장하는 속도는 느려집니다. 쉽게 말해 '내'가 정확히 뭘 잘못했는지 짚어내기가 어려워진다는 뜻입니다. 그런데 손쉬운 기준, 즉 '얼마나 오래 돌렸는가'로만 학습하면 점점 더 오래 돌리는 방법만 배우게 될 위험이 있습니다. 인간의 개입을 최소화해서 AI의 학습을 극대화하는 전략은 결국 '내가 지금 하려는 일이 얼마나 well-structured problem인가'에 달려 있는데, 이 전제를 놓치는 경우가 많습니다. 설령 그 전제가 맞아서 작업이 잘 끝나더라도, 그 과정에서 정작 인간은 더 똑똑해지지 않는다는 맹점도 있습니다. 같은 맥락에서, 많은 사람들이 PKM(개인지식관리)을 정보 축적과 혼동하고 있다고 생각합니다. 세컨드 브레인 열풍도 그 연장선입니다. 옵시디언 그래프뷰에 노드 몇천 개가 얽혀 있는 걸 보여주며 자신의 PKM 실력을 자랑하는 사람들이 있는데, 그게 대체 무슨 쓸모가 있을까요. PKM이 정말 잘되어 있다면, 그걸로 얼마나 많은 새로운 지식을 만들었고 그 지식으로 어떤 액션을 했는지를 따져야 한다고 생각합니다. 지금 만든 지식관리 시스템이 이 문제의식 — 실행·검증 없는 축적은 무의미하다는 것, 그리고 PKM의가치는 노드 개수가 아니라 지식이 실제로 만들어낸 액션의 수로 측정해야 한다는 것 — 을 얼마나 반영하고 있는지 점검해줬으면 합니다. 다른 도메인 이야기이긴 하지만, 지식관리 설계에서는 이 관점이 핵심이라고 봅니다.
이 질문 하나로 시스템의 절반이 비어 있었다는 게 드러났습니다. "실행·검증 없는 축적은 무의미하다"는 사상은 이미 구조에 박혀 있었지만, "지식이 실제로 얼마나 많은 액션으로 이어졌는가를 측정한다"는 나머지 절반은 빠져 있었습니다.
5) 실제 테스트: 같은 주제로 스레드 글을 두 번 뽑아 비교했습니다
말로만 "반영됐다"고 하지 않고, 실제로 콘텐츠를 뽑아서 차이를 확인하고 싶었습니다. 같은 주제 — 바로 이 이관 이야기 자체 — 로 스레드 글을 두 번 만들었습니다. 하나는 이관 전 하네스(톤 코퍼스만 참고), 하나는 이관 후 지식관리 시스템(톤 코퍼스 + 그 사이 추출된 훅 패턴 지식 활용)으로요. 둘 다 실제 길이 검증 스크립트(세그먼트당 500자 제한)를 통과한 결과입니다. (또한 별도의 스레드 글을 쓰는 스킬을 가지고 있었어서 활용해봤습니다.)
Before — 하네스 없을 때 (Few shot + 다소 평이한 example)
[SNS 하네스를 지식관리 시스템으로 옮긴 이야기] 최근에 제 콘텐츠 자동화 시스템을 통째로 옮기는 작업을 했습니다. 지금까지 유튜브 대본, 스레드, 인스타 카드뉴스까지 자동으로 뽑아내는 하네스를 써왔는데요. 어느 순간 이상한 걸 느꼈습니다. 발행한 글은 계속 쌓이는데, 그 글들이 다시 참고되는 일은 거의 없더라고요. --- 폴더 안에 수백 개 파일이 잠들어 있었습니다. 새 콘텐츠를 만들 때마다 사실상 매번 처음부터 다시 쓰는 것과 다를 게 없었습니다. 그래서 지식관리 시스템(AKM) 구조로 통째로 이관하는 작업을 했습니다. 발행한 글에서 훅 패턴이나 인사이트를 뽑아 재사용 가능한 지식으로 쌓는 층을 새로 만들었습니다. --- 아직 갈 길이 멀지만, 이번 이관 작업을 하면서 배운 게 있다면 지식관리는 얼마나 많이 쌓았는지가 아니라 그걸로 무슨 콘텐츠를 만들고 무슨 액션을 했는지로 재야 한다는 것이었습니다. 관심 있으신 분들은 한번 확인해보세요~!
After — 이관 후 지식관리 시스템 (이관 후 스킬 적용)
[콘텐츠 자동화 하네스를 지식관리 시스템으로 옮긴 이유] "자동화로 콘텐츠를 계속 뽑아내고 있다"는 말, 저도 몇 달 전까지 그렇게 소개했습니다. 근데 결론부터 말씀드리면, 그동안 죽어있던 건 콘텐츠가 아니라 콘텐츠를 다시 써먹는 방법이었습니다. --- 발행한 유튜브 대본, 스레드, 카드뉴스가 폴더에 수백 개씩 쌓여 있었는데, 새 글을 쓸 때 그 글들을 다시 여는 일이 거의 없었습니다. 매번 처음부터 다시 쓰는 것과 똑같았던 겁니다. 그래서 이번에 지식관리 시스템(AKM) 구조로 하네스를 통째로 옮기면서, 발행한 글에서 반복되는 훅 패턴과 인사이트를 뽑아 재사용 가능한 지식으로 쌓는 층을 새로 만들었습니다. 이관 첫날 실제로 뽑아낸 패턴 하나가 "결론부터 선언하고 판단의 대상만 바꾸는 훅"이었는데, 지금 이 글 도입부에도 그대로 쓰고 있습니다. --- 이관하면서 제일 크게 깨달은 건, 지식관리는 얼마나 많이 쌓았느냐가 아니라 그걸로 무슨 콘텐츠를 만들고 무슨 액션을 했느냐로 재야 한다는 것이었습니다. 그래서 매주 월요일마다 "이번 주 만든 지식이 실제로 콘텐츠가 됐는가"를 스스로 점검하는 루틴도 같 이 넣었습니다. 관심 있으신 분들은 한번 확인해보세요 ⤵️
두 글의 도입부·구조·CTA는 거의 비슷합니다. 결정적으로 다른 지점은 After의 첫 문장입니다. Before는 그냥 사실을 서술하며 시작하지만, After는 이관 과정에서 실제로 추출된 "결론 선언 후 판단의 과녁을 바꾸는" 훅 패턴(제 기존 유튜브·스레드 글에서 반복 관찰된 패턴을 지식 노트로 뽑아둔 것)을 의도적으로 가져와 씁니다. 이게 바로 "지식이 지식에 머물지 않고 다음 콘텐츠에 실제로 쓰였는가"를 보여주는 가장 작은 단위의 증거였습니다. (개인적인 내용이라 일반 분들은 봤을 때 큰 티가 나지 않겠습니다..ㅠ)
6) SNS 자동발행 에이전트(Annie)까지 새 시스템을 바라보게 만들었습니다
콘텐츠는 옮겼는데, 실제로 크론잡을 돌려 매일 자동 발행을 담당하는 별도 에이전트(Hermes의 "Annie")가 여전히 옛 경로를 보고 있었습니다. 이건 판단을 통째로 위임하는 방식으로 처리했습니다.
지금 스케줄로 잡아둔 작업들을 헤르메스 에이전트에게 위임하고 싶습니다. 전체적으로 손봐주셔도 좋고, 혹은 "이렇게 고쳐라"라는 프롬프트를 저한테 주셔도 좋습니다. 어느 쪽이 나을지는 판단해주세요. 관련 맥락은 헤르메스 에이전트가 이미 답변해준 게 있으니 참고해주세요. 대화 내용은 다음과 같습니다. (Annie가 정리해 준 크론잡·스킬·경로 전수 목록 깃허브 예시 전달)
이후 Annie의 크론잡을 실제로 수동 실행시켜 검증하고, 성격 문서(SOUL.md)에 운영 규칙이 섞여 들어간 걸 발견해 공식 문서 기준으로 다시 정리하고, "일부는 옛 시스템에 남기는 분기 구조" 대신 "완전히 새 시스템 하나만 본다"는 단일 루트로 재정리했습니다.
Hermes에서 sns글 테스트 I/O 결과 입니다. (그래프 엔지니어링 개념 설명)
대본 내용이 구리다보니 테스트한 thread 글 초안도 좀 구리네요. 스킬도 뭔가 수정해야할 거 같고.. 무튼 마이그레이션 했지만 또 다른 시작인 거 같습니다. 무튼 아직 만족스럽진 않아서 더 디벨롭해봐야할 거 같습니다.
결과와 배운 점
배운 점과 나만의 꿀팁
가장 크게 배운 건 "구조를 만드는 것"과 "철학이 반영되는 것"은 다른 일이라는 겁니다. akm 구조 자체를 이식하는 것까지는 순조로웠지만, 진짜 검증은 제가 구체적인 문제의식을 하나 던졌을 때 나왔습니다. 그 전까지는 "실행·검증 없는 지식 축적은 무의미하다"는 사상의 절반만 구조에 박혀 있었고, "지식이 실제로 콘텐츠·액션으로 얼마나 이어졌는가를 측정한다"는 나머지 절반은 빠져 있었습니다.
꿀팁이라면 — 시스템을 다 만들었다고 믿기 전에, 자기가 실제로 느꼈던 구체적인 문제의식을 하나 던져서 "이게 반영되나?"라고 되묻는 것입니다. 추상적으로 "잘 됐나요?"라고 물으면 절대 안 나오는 답이 나옵니다. 그리고 한 걸음 더 나아가, 말로 검증하는 데서 그치지 말고 실제로 콘텐츠를 한 번 뽑아서 비교해보는 것도 유효했습니다. 위 비포/애프터처럼요 — 시스템이 "지식을 실제로 다음 글에 썼는지"는 결과물을 직접 봐야 확인됩니다.
시행착오
SNS 자동 발행 에이전트(Annie)의 정체성 문서(SOUL.md)에 실수로 운영 규칙·경로 정보를 같이 집어넣었다가, "이건 성격 문서 용도가 아니다"라는 지적을 받고 공식 문서를 다시 읽고 재작성했습니다. 문서마다 원래 역할이 있다는 걸 잊으면 안 됩니다.
처음엔 "옛 하네스 일부는 남기고 신규 시스템과 분기 라우팅"으로 설계했는데, "구 하네스는 이제 아예 안 쓰고 싶다"는 피드백으로 단일 구조로 다시 뜯어고쳤습니다.
도움이 필요한 부분
지식이 실제 콘텐츠로 이어졌는지를 별도의 크론잡을 통해서 제 게시글이나 콘텐츠를 주기적으로 모니터링하는 hermes cronjob을 만들었습니다. 지표를 최신화하고 고성과인 것들을 따로 상위 레이어로 보내는 부분은 세팅했고, 별도의 영상을 만들어주는 하네스와 쇼츠/릴스, 캐러셀을 만들어주는 하네스 전부 통합할 예정입니다.
앞으로의 계획
지금은 Threads·YouTube만 새 지식관리 시스템으로 옮겼고, 카드뉴스·블로그·뉴스레터·링크드인은 아직 옛 하네스에 남아 있습니다. 이걸 순서대로 새 시스템 안에서 재구축할 계획입니다. 그리고 지식층을 실제 발행하면서 계속 채우고, 매주 "이번 주 지식이 액션으로 이어졌는가"를 계속 스스로 심문받는 구조로 운영할 생각입니다.
도움 받은 글 (옵션)
DECK6/akm — 지식관리 시스템 구조의 원본. 7개 지식 레이어와 "실행 없는 축적은 위키일 뿐"이라는 순환 구조를 그대로 채택했습니다.
