Nate Herk | AI AutomationMORNING DIGEST · 2026-07-26 · Nate Herk | AI Automation🎬 영상

AI OS 즉시 업그레이드하는 5가지 방법 (Nate Herk)

인포그래픽 요약

01핵심 개요

항목내용
채널Nate Herk \AI Automation
제목5 Hacks to Instantly Level Up Your AI OS
길이약 25분 3초(1503초)
핵심결론 1AI 운영체제(AIOS, 세컨드 브레인)가 틀린 답을 주는 이유는 크게 4가지(오염·과적재·혼동·충돌)로 정리되며, 이를 이해하면 정리 방법이 명확해진다
핵심결론 2저장하는 정보를 "항상 필요한 전문지식"과 "그때그때 불러올 상황정보"로 구분하는 것이 정리의 핵심 원칙이다
핵심결론 3저장소를 스스로 점검하는 "OS 감사(audit)" 스킬을 무료로 공개하며, 이를 포함한 5가지 실전 노하우를 제시한다

02핵심 내용 구조

1) 문제의식 — 정리 안 된 AI OS는 환각의 원인

진행자는 최근 가장 많이 받는 질문이 "AI 운영체제(AIOS)를 어떻게 정리하느냐"라는 점을 언급하며 영상을 시작합니다. 파일을 어떻게 라우팅할지, 위키를 어떻게 구성할지, 폴더를 어떻게 나눌지, 클라이언트 프로젝트는 어디에 둘지 등 정리 방식에 대한 질문이 많다고 설명합니다. 정리가 안 되어 있으면 에이전트(AI 비서)가 사용자에게 잘못된 정보를 줄 뿐 아니라, 그 잘못된 정보를 바탕으로 스킬을 만들거나 자동화를 구축할 때 문제가 더 커질 수 있다고 경고합니다. 이를 막기 위해 자신이 실제로 쓰는 5가지 방법을 공유하겠다고 소개합니다.

2) OS 감사(Audit) 스킬 시연

영상 초반, 자신의 실제 프로젝트(Herk 2)에서 무료로 공개할 "OS Audit" 스킬을 직접 실행하는 장면을 보여줍니다. 이 스킬은 프로젝트 전체를 읽고 모든 라우팅 규칙을 점검해 취약한 부분, 개선이 필요한 부분, 갱신이 필요한 데이터를 찾아냅니다. 결과물은 실행이 아니라 "이런 문제 10가지를 발견했고 수정안은 이렇다, 진행할지 여부를 알려달라"는 형태의 보고서이며, 프로젝트 루트에 audits라는 폴더를 만들어 마크다운 보고서를 저장합니다. 이 스킬은 무료 스쿨 커뮤니티(링크는 영상 설명란)에서 받을 수 있다고 안내합니다.

3) 컨텍스트 실패의 4가지 유형

감사 결과를 이해하려면 먼저 컨텍스트(맥락 정보)가 실패하는 4가지 방식을 알아야 한다고 설명합니다.

  • 오염(Poisoning): 저장된 정보 안에 틀린 사실이 하나 섞여 있는 경우입니다. 에이전트는 일부러 거짓말을 하는 게 아니라, 오염된 데이터셋에서 그 틀린 사실을 그대로 가져다 쓰는 것입니다. 웹 검색으로 교차 검증하거나 확신이 없으면 사람에게 확인을 요청하도록 하면 비교적 쉽게 고칠 수 있는 유형이라고 설명합니다.
  • 과적재(Bloat): 데이터가 너무 많아서 생기는 문제입니다. 저장 규모가 커질수록 흔히 겪는 문제이며, 관련 없는 내용이 섞여 들어가기 쉬워 고치기가 더 어렵다고 말합니다. 뒤에 나올 "전문지식 대 상황정보" 구분이 해결의 실마리가 됩니다.
  • 혼동(Confusion): 필요한 정보가 아예 빠져 있거나 관련 없는 사실이 섞여 있어서, 에이전트가 빈 부분을 스스로 지어내며 답하는 경우입니다. 오염과 비슷해 보이지만, 오염은 "틀린 사실을 자신 있게 가져다 쓰는 것"이고 혼동은 "누락과 잡음 때문에 스스로 지어내는 것"이라는 차이가 있습니다.
  • 충돌(Clash): 오래된 데이터와 새 데이터, 혹은 서로 다른 두 출처가 상충하는 정보를 담고 있는 경우입니다. 예시로 "3월에는 환불 정책이 항상 가능이었는데 6월에는 환불 불가로 바뀐 경우, 환불 문의가 들어오면 에이전트가 어느 쪽을 믿어야 할지 몰라 오래된 정책을 말하거나 아예 다른 답을 지어낼 수 있다"는 사례를 듭니다.

4) 전문지식 컨텍스트 vs 상황 컨텍스트

진행자가 이전에 제시한 "4C 프레임워크(컨텍스트·연결·역량·주기)" 중 컨텍스트와 연결 부분을 다시 "전문지식(expertise)"과 "상황(situational)"으로 구분해 설명합니다.

  • 전문지식 컨텍스트: 항상 필요한 정보, 즉 "당신이 누구인지, 목표가 무엇인지, 사업이 무엇을 하는지" 같은 정책·기본 규칙에 해당하며, 시스템 프롬프트처럼 모든 대화에 항상 로드되어야 하는 정보입니다.
  • 상황 컨텍스트: 필요한 순간에만 불러오는 정보입니다. 예를 들어 어제 들어온 고객 문의 티켓을 항상 컨텍스트에 담아둘 이유는 없으며, 목요일 오후 2시에 그 고객 관련 질문이 나올 때만 실시간으로 조회해 불러오면 된다고 설명합니다.
  • 이를 학교 비유로 설명하는데, "교장은 교실 운영 방식(화이트보드 위치, 문 위치 등 규칙)을 아는 전문지식형 존재이고, 담임교사는 어떤 학생이 시력이 나빠 앞자리가 필요한지, 어떤 두 학생을 붙여 앉히면 안 되는지 같은 상황정보를 그때그때 아는 존재"라는 비유를 듭니다. 상황 컨텍스트를 항상 담아두면 과적재·혼동·충돌이 늘어나므로, 필요할 때만 불러오는 것이 핵심입니다.

5) [하나] CloudMD를 라우터로 사용하기

많은 사람이 최상위 설정 파일(예: CLAUDE.md류)을 하나의 프로젝트에 대한 시스템 프롬프트처럼 쓰지만, 진행자는 자신의 전체 AIOS("Herk 2")를 하나의 큰 루트 폴더 아래 여러 하위 폴더로 구성하고, 최상위 설정 파일은 순수하게 "라우팅 표(어디에 무엇이 있는지 안내하는 목차)"로만 사용한다고 설명합니다. 하위 폴더마다 각자의 설정 파일을 둬서 프로젝트별 세부 규칙을 따로 관리할 수 있습니다. 루트 폴더를 통째로 깃허브에 백업하는 방식이 편해서 이렇게 구성했다고 밝히며, 폴더 구조는 브레인스톰, 위키, 다른 프로젝트들(각각 별도 깃허브 저장소를 가진 대형 프로젝트), 프로젝트(가장 많은 산출물이 쌓이는 폴더, 그 안에 유튜브 영상별 자료 등), 브랜드 자산 등으로 나뉘어 있다고 소개합니다. 폴더를 완전히 평평하게(flat) 두든, 하나의 폴더 아래 깊게 파고들든 상관없으며, 핵심은 사람과 에이전트가 모두 찾아갈 수 있는 올바른 라우팅 규칙이 있는지라고 강조합니다.

6) [둘] AI가 스스로 감사하게 하기

앞서 시연한 감사(Audit) 스킬을 만들기 전에는, 매주 말 또는 매달 말에 "모든 파일을 열어서 라우팅 규칙이 여전히 맞는지 확인하고, 개선할 부분이 있으면 제안해달라"고 직접 요청했다고 합니다. 실제로 이런 대화 과정에서 Claude Code가 먼저 "유튜브 대본과 회의록이라는 두 가지 데이터를 매주 특정 주기로 넣고 있으니, 하나의 마스터 위키로 합치지 말고 둘로 나누는 게 검색하기 쉽겠다"고 제안한 사례를 들며, 실제로 분리한 뒤 과적재와 혼동이 줄고 더 빠르고 정확하며 저렴하게(토큰을 덜 써서) 답할 수 있게 됐다고 말합니다. 정답은 하나가 아니며, "계속 틀린 답을 받으면서 아무 조치도 하지 않는 것"만이 잘못된 방식이라고 강조합니다. 자신의 세컨드 브레인을 직접 탐색기로 열어 검색 없이 원하는 파일을 찾아갈 수 있는지 스스로 테스트해보라는 팁도 제시합니다.

7) [셋] 데이터 자동 갱신 자동화 구축하기

감사 결과에서 "내구성(durability)" 항목으로 지적된 것처럼, 매주 반복되는 데이터 입력(예: 매주 월요일 Q&A 세션, 매주 화요일 리더십팀 회의)은 사람이 깜빡 잊어도 자동으로 채워지도록 크론(cron, 정기 자동 실행) 작업으로 만들어두라고 권합니다. API 키만 있으면 자연어로 "이 스크립트를 정기 실행하도록 설정해줘"라고 요청하는 것만으로 쉽게 구축할 수 있다고 설명합니다.

8) [넷] 지식을 세그먼트(구획)로 나누기

자신의 경우 유튜브 대본용 위키와 회의록용 위키를 처음부터 분리해 각각 계속 성장하도록 관리하고 있다고 말합니다. 서로 뚜렷이 구분되는 지식 뭉치가 계속 커질 것 같으면 미리 나누는 것이 좋으며, 그러면 에이전트가 "Apify 관련 내용을 찾으려면 유튜브 위키만 보면 된다"는 식으로 검색 범위를 좁힐 수 있어 효율적이라고 설명합니다. 클라이언트 프로젝트를 어디에 둘지에 대한 질문에는, 클라이언트별 폴더(클라이언트 A, B, C)를 만들어 계약일·프로젝트 금액·디스커버리콜·업무범위 같은 내부 지식은 AIOS 안에 두되, 실제 클라이언트에게 전달할 산출물(외부용 저장소)은 별도로 분리해 관리한다고 밝힙니다. 다만 내부 AIOS에는 이 계약 관계에 대한 맥락은 반드시 알려주되, 산출물 전체를 소유할 필요는 없다는 점을 구분합니다.

9) [다섯] 되짚어보기(Backtrack)

에이전트가 뭔가를 5분 동안 헤매다 찾거나, "그 정보에 접근할 수 없다"고 잘못 답했는데 실제로는 접근 권한이 있었던 경우, 단순히 "다시는 그러지 마"라고 지적하는 데 그치지 않고 "왜 그때 바로 찾지 못했는지 네가 어디를 검색했는지 되짚어보라"고 요청하는 방법을 제시합니다. 이렇게 하면 에이전트가 "제가 실수했습니다, 이렇게 검색했어야 훨씬 빨리 찾았을 것입니다"라고 스스로 원인을 설명하고, 그 다음에 라우팅을 갱신하거나 파일을 재배치하도록 시키면 단순히 "실수하지 마"라고 말하는 것보다 훨씬 효과적이라고 강조합니다.

10) 팀 단위 확장에 대한 고민

영상 말미에는, 개인 세컨드 브레인을 넘어 팀·부서 단위로 데이터를 동기화하는 문제를 활발히 고민 중이라고 밝힙니다. 구글 드라이브, 노션, 깃허브 등 어떤 도구로도 가능하다고 보지만, 진짜 어려움은 기술이 아니라 "사람들이 데이터를 동기화하는 습관을 들이고, 무엇을 가져와야 하는지 알고, 권한을 관리하는" 습관의 문제라고 진단합니다. 지금은 이 부분에 대한 명확한 정답이 없다고 인정하며, 팀 단위로 확장하기 전에 개인 시스템부터 제대로 마스터하는 것이 먼저라고 조언하며 영상을 마무리합니다.

03기술적 맥락

  • 이 영상은 특정 신제품 발표가 아니라, Claude Code 기반 개인 지식관리 체계(AIOS/세컨드 브레인)를 오래 운영해온 경험에서 나온 컨텍스트 엔지니어링(맥락 정보 설계) 노하우 공유 영상입니다.
  • 핵심 기술 개념은 "컨텍스트 윈도우 안에 무엇을, 언제 넣을 것인가"를 다루는 컨텍스트 엔지니어링이며, 오염·과적재·혼동·충돌이라는 4가지 실패 유형과 전문지식/상황 정보 구분이 뼈대를 이룹니다.
  • "OS Audit" 스킬은 읽기 전용(read-only)으로 설계되어 있어, 프로젝트 상태를 점검만 하고 스스로 파일을 고치거나 삭제하지 않으며, 대규모 프로젝트(폴더 100개 이상)에서는 하위 에이전트(sub-agent)를 점검 항목별로 나눠 병렬로 조사한 뒤 결과를 합치는 방식으로 동작한다고 설명됩니다.

04전략적 의미

  • 개인이나 소규모 팀이 AI 에이전트에게 점점 더 많은 업무 맥락(회의록, 고객 데이터, 프로젝트 이력 등)을 맡기게 되면서, "저장은 했지만 정리가 안 된 데이터"가 오히려 에이전트의 신뢰도를 갉아먹는 역설이 부각되는 사례로 볼 수 있습니다.
  • "항상 필요한 정보"와 "그때그때 불러올 정보"를 구분해 설계하는 방식은, 향후 개인 AI 비서나 사내 지식관리 자동화를 설계할 때 참고할 수 있는 실무적 원칙으로 제시됩니다.
  • 스스로 자신의 상태를 점검하는 "감사 스킬"이라는 패턴은, 단발성 챗봇 사용을 넘어 에이전트가 자신의 운영 환경 자체를 유지보수하는 방향으로 활용이 확장되고 있음을 보여줍니다.

05핵심 워크플로우·방법론

  1. OS 감사 실행: Claude Code 등에서 감사 스킬을 실행하면, 프로젝트 전체를 읽고 라우팅 무결성·인덱스 정합성·데이터 최신성·중복/과적재·정리정돈 상태를 항목별로 점검해 적신호/황신호/청신호로 보고합니다. 대규모 프로젝트는 점검 항목별로 하위 에이전트를 나눠 병렬 조사 후 결과를 병합합니다.
  2. 문제 진단: 보고서는 "왜 문제인지"와 "지금 상태로 질문하면 어떤 틀린 답이 나올지"를 함께 제시하고, "수정할지 여부"를 사용자에게 먼저 확인한 뒤 실행합니다(읽기 전용 원칙).
  3. 정리 원칙 적용: 전문지식 정보는 시스템 프롬프트급으로 상시 로드하고, 상황 정보는 필요한 시점에만 실시간 조회로 불러오도록 구조를 나눕니다.
  4. 자동 갱신 체계 구축: 반복되는 데이터 입력(주간 회의록, 정기 Q&A 등)은 자연어 요청만으로 크론 작업으로 자동화해 사람이 잊어도 최신 상태가 유지되게 합니다.
  5. 지식 세그먼트 분리: 서로 다른 성격의 지식(예: 영상 대본 vs 회의록, 클라이언트별 내부/외부 자료)은 각각 독립된 폴더·위키로 나눠 검색 범위를 좁히고 정확도를 높입니다.
  6. 되짚어보기(Backtrack) 피드백 루프: 에이전트가 실수했을 때 단순 지적 대신, 실수 원인을 스스로 추적·설명하게 한 뒤 그 원인에 따라 라우팅이나 구조를 실제로 개선하도록 요청합니다.

06활용 시나리오

  • 개인이 Claude Code, Notion, Obsidian 등으로 자기만의 세컨드 브레인을 운영 중인데 최근 들어 엉뚱한 답이나 오래된 정보가 자주 나올 때, 오염·과적재·혼동·충돌 중 어느 유형인지 진단하는 틀로 활용할 수 있습니다.
  • 여러 클라이언트 프로젝트를 병행하는 프리랜서나 에이전시가, 클라이언트별 내부 관리 정보와 외부 전달용 산출물을 어떻게 분리 보관할지 구조를 설계할 때 참고할 수 있습니다.
  • 매주 반복되는 회의록·리포트 정리를 수작업으로 계속 잊어버리는 사람이, 이를 자동화(크론)로 전환하는 아이디어를 얻을 때 활용할 수 있습니다.
  • 팀 단위로 AI 지식관리 체계를 확장하려는 조직이, 기술보다 "습관과 권한 관리"가 병목이라는 관점에서 도입 전략을 재검토할 때 참고할 수 있습니다.

07현황 및 전망

  • 영상 시점(2026년 7월) 기준, 진행자 본인의 감사 스킬은 아직 다듬는 중이며(그날 세 번째 테스트 실행이라고 언급), 무료로 공개된 상태입니다.
  • 개인 세컨드 브레인/AIOS 운영 노하우는 활발히 논의되는 주제이지만, 팀·부서 단위로 데이터를 동기화하는 문제는 아직 뚜렷한 정답이 없는 상태이며, 진행자는 이를 "기술 문제가 아니라 사람·습관의 문제"로 규정하고 후속 콘텐츠로 다룰 계획을 시사합니다.

08용어 사전

용어한줄 설명비유·예시
AIOS(AI 운영체제)개인이 AI 에이전트와 함께 쓰는 지식·파일 관리 체계 전체사람의 책상 서랍 정리 시스템
세컨드 브레인자신의 지식과 기록을 외부(주로 디지털)에 체계적으로 저장해두는 개인 지식관리 체계머릿속 대신 노트에 모든 걸 적어두는 습관
컨텍스트(context)AI 에이전트가 답변할 때 참고하는 배경 정보 전체시험 볼 때 참고하는 요약노트
컨텍스트 윈도우AI가 한 번에 참고할 수 있는 정보의 최대 용량책상 위에 한 번에 펼쳐놓을 수 있는 책의 양
오염(Poisoning)저장된 정보에 틀린 사실이 섞여 있는 문제정답지에 오탈자 하나가 섞여 있는 것
과적재(Bloat)정보량이 너무 많아 필요한 것을 찾기 어려운 문제창고에 물건이 넘쳐 필요한 걸 못 찾는 상황
혼동(Confusion)정보 누락·잡음 때문에 AI가 빈 부분을 지어내 답하는 문제퍼즐 조각이 없어서 대충 그려 넣는 것
충돌(Clash)서로 다른 시점·출처의 정보가 상충하는 문제오래된 지도와 새 지도가 서로 다른 길을 알려주는 상황
전문지식 컨텍스트항상 로드되어야 하는 기본 규칙·정책 정보학교 교장이 아는 교실 운영 규칙
상황 컨텍스트필요한 순간에만 불러오는 정보담임교사가 아는 특정 학생의 사정
라우팅(routing)에이전트가 필요한 정보를 어디서 찾을지 안내하는 규칙건물 안내판의 층별 안내
크론(cron)정해진 시간에 자동으로 실행되는 반복 작업매일 아침 알람처럼 자동 실행되는 작업
하위 에이전트(sub-agent)큰 작업을 나눠 병렬로 처리하는 보조 AI 인스턴스큰 프로젝트를 나눠 맡는 팀원들
되짚어보기(Backtrack)AI가 실수한 과정을 스스로 되짚어 원인을 설명하게 하는 방법실수한 이유를 스스로 복기해 다음엔 안 틀리게 하는 것
Nate Herk | AI Automation · 2026-07-26
← 목록으로