스크립트
00:00:00세컨드 브레인(Second Brain)과 Claude OS에 대한 수많은 이야기를 들어보셨을 겁니다.
00:00:03사람들이 Claude Code를 사용하여 전체 시스템을 구축하고,
00:00:07단순한 코딩 에이전트가 아닌 운영 체제처럼 실행하고 있죠.
00:00:10하지만 이런 시스템에는 고유한 문제들이 따릅니다.
00:00:12사람들이 세컨드 브레인을 구축할 때는 자신들이 사용하기 위해 만들며,
00:00:16각자 생각하기에 가장 좋다고 느끼는 방식으로 구조화합니다.
00:00:18표준적인 방법이 존재하지 않기 때문에,
00:00:20이런 시스템은 탐색하기 어렵고 공유하기도 어렵습니다.
00:00:23이 문제를 해결하기 위해 구글이 Open Knowledge format을 출시했습니다.
00:00:26구글이 AI를 활용하여 이런 운영 체제를 구축하는 자신들만의 방식을 제시한 것이죠.
00:00:31처음 오신 분들을 위해 소개하자면, 저희는 소프트웨어 회사이고 이곳은 AI Labs 채널입니다.
00:00:36저희가 프로세스를 최적화한 것과 동일한 방식으로 여러분의 프로세스를 AI로 최적화하는 방법을 보여드립니다.
00:00:41이번 영상에서는 이 형식이 무엇인지,
00:00:44어떻게 문제를 해결하는지, 그리고 왜 여러분의 워크플로에 중요한지 말씀드리겠습니다.
00:00:48하지만 구글의 발표 내용을 다루기 전에 먼저 실제 문제를 이해해 보죠.
00:00:52지난 영상에서 저희는 세컨드 브레인을 유지하는 것에 대해 이야기했고,
00:00:55저희 또한 전략, 연구, 지침 등을 보관하는 세컨드 브레인을 관리하고 있습니다.
00:01:00Git으로 버전 제어하고 GitHub에 푸시하며 팀원 모두가 접근할 수 있게 했죠.
00:01:05그래서 신규 입사자가 오면 바로 풀(pull)해서 저희 업무 방식에 대한 맥락을 파악할 수 있습니다.
00:01:09앞서 말씀드렸듯이, 이 세컨드 브레인은 Claude.md 파일로 제어됩니다.
00:01:13그 파일은 기본적으로 에이전트에게 브레인 내에서 어떻게 탐색할지 안내하죠.
00:01:17각 폴더마다 별도의 Claude.md 파일도 가지고 있어서,
00:01:20에이전트가 해당 디렉터리에서 작업할 때 구체적인 지침을 따르게 합니다.
00:01:24하지만 Claude가 파일에서 맥락을 파악하는 데 상당히 능숙함에도 불구하고, 여전히 실수가 잦습니다.
00:01:28파일을 엉뚱한 곳에 넣어버리는 일이 너무나 자주 발생했고,
00:01:31그럴 때마다 원래 위치가 어디인지 다시 알려줘야 했습니다.
00:01:34그러고 나면 단순히 새로운 폴더를 만들어버리곤 하는데,
00:01:37다른 이름으로 된 폴더에 이미 유사한 정보가 존재한다는 사실을 모르기 때문입니다.
00:01:41진짜 문제는 Claude가 지식 베이스에 필요한 정보가 이미 존재한다는 사실을 모른다는 점입니다.
00:01:47능동적으로 검색을 수행할 때만 정보를 찾습니다.
00:01:49따라서 특정 파일을 보라고 말하지 않는 한, 그 파일이 존재하는지도 모릅니다.
00:01:53작은 지식 베이스에서는 크게 티가 나지 않지만,
00:01:56큰 지식 베이스로 작업하게 되면 이 문제가 훨씬 더 뚜렷하게 드러납니다.
00:01:59Claude가 검색하는 방식은 파일 내용과 키워드를 일치시키는 것이며,
00:02:03파일 이름도 안내서로 활용합니다.
00:02:05그래서 매우 깊게 중첩된 폴더 구조를 검색하라고 시키면,
00:02:08올바른 파일을 찾을 때까지 여러 번 시도해야 합니다.
00:02:12이는 시간을 낭비할 뿐만 아니라 토큰도 많이 소비하게 하죠.
00:02:15그래서 구글이 Open Knowledge format을 출시했고, 이 형식이 해결하는 문제는 바로 표준화입니다.
00:02:20이는 에이전트 업계에서 이미 여러 번 봐왔던 현상입니다.
00:02:24에이전트가 터미널에 있는 것 이상의 외부 자원과 소통해야 할 필요가 있을 때,
00:02:29그들은 MCP(Model Context Protocol)를 도입했고 모든 에이전트가 채택하는 프로토콜이 되었습니다.
00:02:33이와 마찬가지로, 재사용 가능한 지침을 패키징하는 것은 '스킬(skills)'의 형태로 나타났고,
00:02:36MCP처럼 모든 에이전트로 퍼져 나갔습니다.
00:02:40그리고 디자인 의도를 전달하는 방법을 표준화할 필요가 생겼을 때,
00:02:43구글은 design.md 표준도 출시했습니다.
00:02:46즉, 표준화에 대한 요구는 항상 존재했고,
00:02:49지식 또한 표준화할 필요가 있었던 것입니다.
00:02:51그것이 바로 Open Knowledge format이 하는 역할입니다.
00:02:53이 아이디어는 사실 새로운 것이 아닙니다.
00:02:55안드레아 카파시(Andre Karpathy)가 제시하여 한동안 큰 인기를 끌었던 LLM wiki 패턴에 기반합니다.
00:02:58그 아이디어가 나오기 전에는 RAG 접근 방식에 의존했었는데,
00:03:00방대한 문서를 모두 벡터 형식으로 변환하는 방식이었죠.
00:03:03벡터는 모든 것을 모델이 이해할 수 있는 형태로 바꿔주기 때문에 확실히 도움이 됩니다.
00:03:07거기서 시스템은 쿼리의 의미와 기존 데이터를 일치시켜,
00:03:12가장 관련성 높은 결과를 반환합니다.
00:03:15하지만 카파시는 이 방식에 문제가 있다고 지적했습니다.
00:03:18질문을 할 때마다 에이전트가 기본적으로 처음부터 정보를 재구성한다는 점이죠.
00:03:20답변은 주지만 시간이 지나도 지식이 쌓이지는 않습니다.
00:03:25그래서 그는 대신 마크다운 파일을 사용하여 지식 베이스를 구축할 것을 제안했습니다.
00:03:28그렇게 하면 에이전트가 작업을 수행하면서 실제로 맥락을 쌓아갈 수 있기 때문이죠.
00:03:31그의 접근 방식은 모델이 파일 시스템을 탐색하는 능력을 활용한 것이었습니다.
00:03:35아이디어를 공유한 후, 많은 사람들이 각자의 세컨드 브레인을 만들기 시작했습니다.
00:03:38하지만 각 시스템이 창작자의 개인적인 워크플로에 맞춰 설계되었다는 것이 문제였습니다.
00:03:43구조를 만든 사람은 각 폴더에 무엇이 있는지 알고 에이전트로 쉽게 탐색할 수 있었죠.
00:03:47하지만 새로운 사람은 그 폴더가 무엇을 담고 있는지,
00:03:50에이전트가 폴더를 탐색하게 하는 데 시간을 쓰느라 고생해야 했습니다.
00:03:52OKF는 파일을 구성하는 표준적인 방법을 만들어,
00:03:54에이전트뿐만 아니라 사람도 지식 베이스에 무엇이 있는지 이해할 수 있게 합니다.
00:03:57지식을 번들로 패키징하여 공유할 수 있게 만드는 거죠.
00:04:01이 번들에는 지식 베이스를 구축하는 모든 정보를 담은 마크다운 파일들이 포함될 수 있습니다.
00:04:04각 파일에는 파일 상단에 YAML 프론트매터(frontmatter)라는 작은 블록이 포함되어 있는데,
00:04:09파일 안에 무엇이 들어있는지 설명하여 에이전트가 내용을 알 수 있게 합니다.
00:04:12OKF가 특별히 새로운 것을 도입하는 것은 아닙니다.
00:04:14대신 누구나 생성하고 읽을 수 있는 표준 형식을 제공하여,
00:04:18다양한 시스템 간에 지식을 이동 가능하게 만듭니다.
00:04:23처음 이 소식을 듣고 살펴봤을 때, 한 가지 생각이 들었습니다.
00:04:27구글이 웹 검색을 에이전트 기반 검색으로 바꾸려 하고 있으니,
00:04:29이것 또한 그 변화를 지원하려는 시도일 수 있겠다는 것이죠.
00:04:32현재 웹사이트들은 LLMs.txt 파일을 추가하고 있는데,
00:04:35거기에는 모델을 위해 특별히 맞춤화된 웹사이트 정보가 들어있어서,
00:04:39에이전트 시스템에 사이트에 대한 맥락을 제공합니다.
00:04:42그러니 LLMs.txt에만 의존하는 대신,
00:04:44웹사이트들이 결국 OKF 번들도 추가하기 시작할지도 모릅니다.
00:04:48그러면 에이전트들이 콘텐츠를 더 효율적으로 쿼리하고,
00:04:52구조화된 정보를 바탕으로 더 나은 검색 결과를 제공할 수 있겠죠.
00:04:55지금 당장은 내부용으로만 의도된 것이지만,
00:04:58충분히 일어날 수 있는 일입니다.
00:05:01도움이 되는 원리를 이해하기 위해 OKF가 내부적으로 어떻게 작동하는지 보겠습니다.
00:05:04이 시스템은 지식 베이스의 일부인 모든 것을,
00:05:07'개념(concepts)'이라고 불리는 객체로 나타냅니다.
00:05:09데이터, 마크다운 문서, YAML 파일,
00:05:12혹은 그 안에 들어가는 무엇이든 될 수 있습니다.
00:05:16구조는 다음과 같이 작동합니다.
00:05:18정리하고 싶은 모든 정보는 주제별로 이름이 붙은 폴더에 배치되고,
00:05:21각 폴더는 오직 그 주제에 대한 콘텐츠만 담습니다.
00:05:24그리고 모든 폴더 안에는 index.md 파일이 있죠.
00:05:26이 파일이 가장 중요한데, 에이전트가 가장 먼저 읽는 파일이기 때문입니다.
00:05:28해당 폴더 안에 무엇이 있는지에 대한 맥락을 에이전트에게 제공합니다.
00:05:31각 개념 문서에는 작은 YAML 블록이 포함되어 있는데,
00:05:32이름과 설명이 담겨 있어서 에이전트가 문서가 무엇인지,
00:05:35무엇이 들어있는지 정확히 알 수 있게 합니다.
00:05:38스킬(skills)에도 비슷한 YAML 블록이 있는 것처럼,
00:05:41이것은 정확히 같은 목적을 수행합니다.
00:05:44에이전트에게 맥락을 조금씩 제공하여,
00:05:46이 설명을 먼저 읽고 나서 관련 콘텐츠를 불러오는 식으로,
00:05:48필요한 정보만 로드하게 만듭니다.
00:05:50OKF가 구축된 기본 원칙은 미니멀리즘입니다.
00:05:52각 개념은 오직 한 가지만 나타내야 하며,
00:05:54문서 안의 'type' 필드가 그것이 무엇인지 알려줍니다.
00:05:56서로 관련 없는 것들을 한 문서에 담아서는 안 되는데,
00:05:58개념이 여러 주제를 섞기 시작하는 순간,
00:06:00에이전트는 필요한 정확한 정보를 불러올 능력을 잃어버리기 때문입니다.
00:06:02OKF의 또 다른 원칙은,
00:06:04지식 베이스를 소비하는 주체와 분리하는 것입니다.
00:06:07에이전트든, 사람이든, 팀원이든 그 무엇이든,
00:06:09지식 그 자체는 독립적으로 유지됩니다.
00:06:13어떤 특정 플랫폼에 종속되지 않기 때문에,
00:06:15거의 모든 것과 함께 사용할 수 있게 됩니다.
00:06:17이 시스템을 실제로 보기 전에,
00:06:21스폰서인 Mobbin의 이야기를 들어보죠.
00:06:22Cursor, Lovable, Claude Code 같은 도구로 UI를 구축해 본 적 있다면,
00:06:25모두가 같은 것을 내뱉는다는 것을 눈치채셨을 겁니다.
00:06:29똑같은 히어로 섹션, 카드 레이아웃, 그리고 똑같은 일반적인 온보딩이죠.
00:06:31AI 쓰레기(AI slop)처럼 보이는데 이유는 간단합니다.
00:06:33이 도구들은 좋은 디자인이 무엇인지 실제로 본 적이 없기 때문입니다.
00:06:36하지만 Mobbin은 다릅니다.
00:06:38Mobbin은 방금 MCP 서버를 출시했습니다.
00:06:40Cursor, Lovable 또는 Claude Code 같은 툴로 UI를 만들어 보셨다면,
00:06:44Revolut, Uber, Wise처럼 실제로 출시된 제품들의 14만 2천 개가 넘는 플로우 라이브러리를,
00:06:47AI 도구들에 직접 연결해 주는 서버입니다.
00:06:50제가 어떻게 사용했는지 보여드리죠.
00:06:53체크아웃 플로우를 만드는 중이었는데 에이전트에게,
00:06:56최고의 앱들이 어떻게 처리하는지 참조하라고 했습니다.
00:06:57핵심은 스크린을 복사하는 게 아닙니다.
00:06:59Mobbin은 에이전트에게 실제 플로우를 제공합니다.
00:07:02코드를 작성하기 전에 디자인 뒤에 숨겨진 상태(states)와 계층 구조를 제공하여,
00:07:05추측하는 대신 검증된 패턴을 기반으로 구축하게 합니다.
00:07:11설정은 1분도 안 걸리고, Claude, Cursor, V0 등에서 작동합니다.
00:07:12고정 댓글의 링크를 통해 Mobbin MCP를 사용해 보세요.
00:07:13그래서 저희는 이 시스템이 실제 설정에서 실제로 어떻게 수행되는지 보고 싶었고,
00:07:16이미 GitHub를 통해 팀 전체와 공유되는 세컨드 브레인을 유지하고 있었기에,
00:07:18OKF를 그 브레인에 테스트했습니다.
00:07:21하지만 제대로 작동하지 않을 경우를 대비해 메인 브랜치는 건드리고 싶지 않았죠.
00:07:24그래서 프로젝트의 별도 복사본인 새 브랜치를 만들고 거기서 모든 변경 작업을 수행했습니다.
00:07:27OKF는 기본적으로 세 가지 요소와 함께 제공됩니다.
00:07:31첫 번째는 인리치먼트 에이전트(Enrichment agent)입니다.
00:07:34구글의 데이터 저장용 대형 데이터베이스인 BigQuery에 있는 데이터를 가져와,
00:07:38OKF 개념 문서로 변환한 다음 LLM 패스를 실행하여 확인합니다.
00:07:41GitHub을 통해 팀원들과 공유하는 데이터베이스인데,
00:07:43OKF 번들을 탐색하기 더 쉬운 대화형 그래프 뷰로 바꿉니다.
00:07:44그리고 에이전트가 참조로 사용할 수 있는, 제대로 포맷팅된 OKF 데이터 예시와 함께 제공되죠.
00:07:47저희는 BigQuery로 작업하고 있지 않았기 때문에,
00:07:51첫 번째 부분은 필요 없었습니다.
00:07:52Google Cloud에 전체 프로젝트를 설정해야 했을 텐데,
00:07:55이미 프로젝트가 Git으로 추적되고 있었기 때문에 불필요했죠.
00:07:57하지만 데이터를 OKF 형식으로 바꾸는 도구는,
00:07:59오직 BigQuery용으로만 설계되어 있었습니다.
00:08:03그래서 우회 방법으로 'Markdown to OKF'라는 스킬을 만들었습니다.
00:08:05이 스킬이 하는 일은 마크다운 파일 폴더를,
00:08:07사양(spec)에 맞춰 Open Knowledge format 번들로 변환하는 것입니다.
00:08:09설계상 코드가 대부분의 작업을 수행합니다.
00:08:13판단이 필요한 부분만 에이전트가 처리하죠.
00:08:14스크립트 우선 접근 방식을 따릅니다.
00:08:18코드를 통해 작업하면 에이전트의 부하가 줄고 토큰도 적게 들기 때문입니다.
00:08:20BigQuery를 사용하지 않았기 때문에,
00:08:22첫 번째 부분은 필요 없었습니다.
00:08:24그랬다면 Google Cloud에 전체 프로젝트를
00:08:27설정해야 했을 텐데, 이미 Git으로 프로젝트를 관리 중이라 필요가 없었죠.
00:08:31하지만 데이터를 OKF 형식으로 변환하기 위해 제공되는 도구는
00:08:34BigQuery 전용으로 설계되었습니다.
00:08:36그러자 모든 하위 폴더에 대한 참조 링크가 포함된 index.md 파일이 생성되었습니다.
00:08:39Obsidian을 사용해 보셨다면, 서로 다른 페이지를 연결하는 방식과 정말 유사하다는 걸 아실 겁니다.
00:08:42Obsidian이 그래프 뷰를 구축하는 데 사용하는 것과도 같은 방식이죠.
00:08:45그리고 index.md는 루트 레벨에만 존재하는 것이 아닙니다.
00:08:47각 하위 폴더 내부에도 존재합니다.
00:08:51각 파일은 해당 폴더 안의 모든 것을 나열합니다.
00:08:53그래서 에이전트는 그곳에서 어떤 콘텐츠를 사용할 수 있는지 알게 되죠.
00:08:55이제 앞서 언급했듯이 OKF는 시각화 도구와 함께 제공됩니다.
00:08:58그래서 터미널에서 visualize 명령어를 사용하여 번들에 실행해 봤습니다.
00:09:02전체 지식 베이스를 나타내는 HTML 문서가 생성되었습니다.
00:09:06그저 브라우저에서 열기만 하면 됩니다.
00:09:09모든 노드와 파일 간의 연결을 배치해 줍니다.
00:09:12전체 시스템과 모든 것이 어떻게 연결되는지 이해할 수 있는 대화형 방식을 제공하는 거죠.
00:09:15모든 문서를 OKF 구조로 변환한 상태에서, 검색 시 어떻게 작동하는지 테스트했습니다.
00:09:19하지만 처음 파일 검색을 요청했을 때, 그냥 평소처럼 패턴을 일치시켜 검색하는 기본 방식으로 돌아갔습니다.
00:09:24OKF가 아직 널리 채택된 표준이 아니기도 하고 최근에 나온 것이라 Claude가 존재 자체를 몰랐던 탓이죠.
00:09:29이를 해결하기 위해, 시스템 탐색 방법, 각 파일의 역할, 그리고 구조를 어떻게 사용해야 하는지 설명하는 섹션을 Claude.md 파일에 추가했습니다.
00:09:32준비가 된 후 다시 특정 파일로 이동하라고 요청하자,
00:09:35이번에는 저희가 만든 index.md 파일들을 하나하나 훑기 시작했고,
00:09:37Claude가 일반적으로 하는 방식처럼 전체 지식 베이스를 다 뒤지는 것보다 훨씬 더 빠르게 결과를 도출할 수 있었습니다.
00:09:40또한 YAML 메타데이터를 먼저 로드했기 때문에,
00:09:42각 파일에 무엇이 있는지 먼저 이해하고 나서 실제로 열어볼지 결정했기에 토큰도 적게 사용했습니다.
00:09:45얻을 수 있는 주요 이점은 토큰 사용량 감소와 빠른 검색 시간이라는 두 가지입니다.
00:09:49앞서 언급한 오류 발생 확률을 낮추면서 정보를 더 빨리 가져올 수 있는 방법이 확실합니다.
00:09:53게다가 Claude.md 파일에 구조가 문서화되어 있으므로 파일을 어디에 두어야 할지 잊어버리지도 않습니다.
00:09:55더불어 index.md 파일들에 각각 명시되어 있으니 각 파일이 무엇을 하는지도 알죠.
00:09:58현재 모델들은 패턴 매칭과 자체 터미널 명령 실행만으로도 이미 충분히 유능합니다.
00:10:03따라서 에이전트들이 기본적으로 지원하는 공개 표준이 되기 전까지는, 이 작업은 꼭 해야만 하는 것이라기보다 최적화에 가깝습니다.
00:10:07저희가 만든 스킬들은 저희 커뮤니티인 AI Labs Pro에서 찾으실 수 있습니다.
00:10:13OKF는 아직 널리 채택된 표준이 아니고 최근에 나온 것이라 Claude는 그 존재를 잘 몰랐거든요.
00:10:20이를 해결하기 위해 Claude.md 파일에 시스템 탐색 방법, 각 파일의 역할, 구조 활용법을 설명하는 섹션을 추가했습니다.
00:10:28그 내용을 반영한 뒤 특정 파일로 이동하라고 요청했더니, 이번에는 저희가 만든 index.md 파일을 따라 탐색하기 시작했고, Claude가 평소에 전체 지식 베이스를 검색하던 것보다 훨씬 빠르게 결과를 내놓았습니다.
00:10:42또한 YAML 메타데이터를 먼저 로드해서 각 파일에 무엇이 담겨 있는지 파악한 후 실제로 열어볼 필요가 있는지 판단했기 때문에 토큰 사용량도 줄었습니다.
00:10:50결과적으로 토큰 사용량 감소와 검색 시간 단축, 이 두 가지 주요 이점을 얻게 된 셈입니다.
00:10:56정보를 더 빠르게 가져올 수 있으면서 앞서 언급한 오류 발생 가능성도 줄어들고, 구조가 Claude.md에 문서화되어 있어 파일 위치를 잊어버릴 일도 없습니다.
00:11:05아래의 Super Thanks 버튼을 이용해 주세요.
00:11:10현재 모델들은 패턴 매칭을 하거나 직접 터미널 명령어를 실행하는 등 이미 꽤 뛰어난 능력을 갖추고 있습니다.
00:11:16따라서 에이전트들이 기본적으로 이를 지원하는 오픈 표준이 되기 전까지는, 이건 꼭 필요한 기술이라기보다는 하나의 최적화 방법이라고 볼 수 있습니다.
00:11:23방금 말씀드린 기술들은 저희 커뮤니티인 'AI Labs Pro'에서 확인하실 수 있습니다.
00:11:27그곳에서 리소스와 스타터 팩 등을 얻으실 수 있고, 저희 팀을 포함한 수많은 열정적인 분들과 교류하실 수도 있습니다.
00:11:34저희 활동이 도움이 되셨고 채널을 후원하고 싶으시다면, 이 방법이 가장 좋은 길입니다.
00:11:39링크는 설명란에 있습니다.
00:11:40이제 이번 영상도 마칠 시간이네요.
00:11:42채널을 후원해주시고 이런 영상을 계속 만들 수 있도록 도와주고 싶으시다면, 아래 'Super Thanks' 버튼을 이용해주시면 됩니다.
00:11:49언제나처럼 시청해주셔서 감사드리고, 다음 영상에서 뵙겠습니다.