---
title: '[Neurain 개발일지] #2. 코딩 도구에 코드 대신 뇌를 넣었다'
category: ai
tags:
  - ai
  - second brain
published: true
date: 2026-06-19 22:10:00
series: 'Neurain 개발일지'
seriesOrder: 2
description: '카파시의 LLM Wiki 메모에서 위키를 AI가 유지보수한다는 역할 역전을 발견했고, 폴더를 지정해 일하는 코딩 도구가 그 그릇이 될 수 있다는 결론에 닿았다. 원안을 그대로 쓰지 않고 내 삶에 맞게 고쳐 쓴 지점들이 지금의 Neurain이 됐다.'
---

1화에서 말한 그 '이상한 문장'의 주인은 안드레 카파시(Andrej Karpathy)였다.

AI 판에서 이 이름은 무게가 다른데, 테슬라의 자율주행 AI를 이끌었고 오픈AI 창립 멤버였고 지금은 유튜브에서 AI를 가장 잘 가르치는 사람으로 통한다. 유행어를 따라가는 사람이 아니라, 이 사람이 무심코 던진 말이 몇 달 뒤 업계 유행어가 되는 쪽에 가깝다.

그런 사람이 개인 지식 관리를 두고 남긴 메모가 하필 그 시기의 나에게 걸렸다.

## TL;DR

> *1) 카파시의 LLM Wiki 메모: 위키를 사람이 아니라 LLM이 유지보수하게 하라.\
> 2) 그릇은 옵시디언, 재료는 마크다운. 사람에게는 문서, LLM에게는 가장 잘 읽히는 데이터다.\
> 3) 챗 앱으로는 안 된다. 파일을 소유하는 도구, 그러니까 코딩 도구가 답이었다.\
> 4) 원안을 그대로 쓰지 않았다. 내 삶에 맞게 고친 지점이 지금의 시스템이 됐다.*

## 1. 이상한 메모

[그 메모](https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f)는 논문도 제품 발표도 아니고 아이디어를 끄적인 글에 가깝다. 그런데 요지가 심상치 않아서 세 줄로 줄여 보면 이렇다.

| 원칙 | 뜻 |
|---|---|
| raw는 불변 | 수집한 원본은 손대지 않고 증거로 보존한다 |
| wiki는 LLM이 유지보수 | 정리된 지식 문서는 사람이 아니라 AI가 쓰고 고친다 |
| 스키마가 지배 | 규칙 문서 하나가 전체 구조를 다스린다 |

두 번째 줄에서 멈췄다. 위키를 AI가 유지보수한다고?

위키피디아를 떠올려 보면 이 말의 이상함이 보인다. 위키피디아는 수많은 사람 편집자가 문서를 쓰고 고치며 유지되는데, 카파시의 메모는 그 편집자 자리를 통째로 AI에게 주라는 이야기다. 나는 자료를 던져 넣기만 하고 문서를 최신으로 유지하는 편집장은 AI가 맡는다. 사람은 편집장이 일을 제대로 했는지 검수만 한다.

그전까지 내 상식은 반대였다. 지식은 내가 정리하고 AI는 그걸 잘 찾아 주는 검색 담당. 그런데 이 메모는 역할을 뒤집어서, 수집만 사람이 하고 정리는 AI가 한다.

읽고 나서 며칠을 머릿속에서 굴리며 1화의 배신들을 하나씩 대입해 보니 아귀가 맞았다. 문제는 늘 정리였고 저장 자체는 쉬웠다. 저장한 것을 최신 상태로 유지하고 꺼내 쓰기 좋게 다듬는 노동이 사람 몫인 한, 지식 관리는 어느 시점에 반드시 멈춘다. 나도 노션 페이지 수십 개를 만들다 말았고 폴더 정리를 몇 번이나 갈아엎다 말았다. 부지런함의 문제가 아니라 구조의 문제라, 정리 노동이 사람에게 있는 구조는 사람이 지치는 순간 끝난다. 카파시의 메모는 그 노동을 통째로 AI에게 넘기라는 이야기였다.

그리고 1화 마지막의 가설과 정확히 이어졌다. 병목이 모델의 지능이 아니라 구조라면, 필요한 건 AI가 스스로 유지보수하는 지식 구조다. 방향은 잡혔으니 이제 어디에 무엇으로 만들지가 남았다.

## 2. 그릇은 옵시디언, 재료는 마크다운

답부터 말하면 재료는 마크다운(Markdown)이었다. 확장자 .md로 끝나는, 텍스트에 최소한의 기호만 얹은 파일 형식이다. 이런 식이다.

```
# 제목은 샵 하나
**강조는 별표 두 개**
| 표는 | 막대기로 |
```

이게 전부라, 워드나 한글 파일처럼 복잡한 서식 정보가 없고 메모장으로 열어도 읽힌다. 지금 읽고 있는 이 글도 마크다운으로 썼다.

마크다운이 핵심인 이유는 이중성에 있다. **사람에게는 읽기 편한 문서인데, LLM에게는 가장 잘 읽히는 데이터다.** LLM은 애초에 인터넷의 텍스트로 학습된 물건이라 마크다운을 모국어처럼 다룬다. 전용 앱의 포맷이나 데이터베이스와 달리, 어떤 AI에게 던져도 변환 없이 바로 읽는다. 그리고 마크다운으로 쌓아 두면 그다음이 무궁무진하다. 글이 되고 보고서가 되고 발표자료가 되고 웹사이트가 된다. 텍스트는 모든 산출물의 원료라서 그렇다.

그릇은 마크다운 파일 뭉치를 폴더째 열어 보고 문서끼리 연결해 주는 앱인 옵시디언(Obsidian)으로 정했다. 처음 열어 봤을 때 인상이 아직 남아 있는데, 화려한 기능이 아니라 열어 보니 그냥 내 폴더여서 그게 마음에 들었다.

1화에서 노션 같은 문서 앱을 검토하다 접었다고 했는데, 옵시디언은 결정적인 차이가 하나 있다. **파일을 소유하지 않는다.** 노션의 내 글은 노션 서버에 노션의 형식으로 살지만, 옵시디언의 내 글은 그냥 내 폴더 안의 .md 파일이고 옵시디언은 그걸 보여 주는 창일 뿐이라 앱을 지워도 파일은 남는다. 1화에서 세운 첫 번째 조건, '내 소유의 기억'과 정확히 맞는 그릇이다.

여기서 고백 하나. 나는 원래 정리하는 인간이라, 회의가 끝나면 들은 것을 표로 만들어야 직성이 풀리고 투자를 하면 판단 근거를 문서로 남기고 무엇이든 목록으로 줄 세우는 버릇이 있다. 남들에게는 노동인 이 작업이 나에게는 재미였고 이게 이 프로젝트가 두 달 넘게 이어져도 지치지 않은 진짜 이유라고 본다. 시스템을 만들 때 기술보다 중요한 게 있다면 자기 성향과의 궁합이다. 정리가 고통인 사람에게는 이 방식 자체가 맞지 않을 수 있고 그 경우에도 AI에게 더 많이 맡기는 쪽으로 조절하면 된다.

## 3. 옵시디언에서 그래프 뷰를 껐다

옵시디언을 쓰기 시작하면 누구나 그래프 뷰를 켜 본다. 문서들이 점으로 뜨고 서로 선으로 연결된 별자리 같은 화면이다. 처음에는 지식이 연결되어 있다는 걸 눈으로 확인시켜 주니 이게 세컨드 브레인의 상징처럼 보인다.

두 달 쓰고 나서 세어 보니, 그래프 뷰를 실제로 열어 본 건 손에 꼽았다. 예쁘긴 한데 그걸 보고 내가 할 수 있는 일이 없었다. 그래프는 "연결이 있다"만 보여 주지 "지금 뭘 해야 하는지"는 알려 주지 않는다. 문서가 4,000개를 넘어가면 화면은 그냥 털뭉치가 된다.

그래서 시각화를 다시 생각했고, 결론이 이거였다.

**사람이 보기 좋은 화면과 AI가 읽기 좋은 구조는 다르다. 하나로 만들려니까 둘 다 망가진다.**

그래서 지도를 두 벌 만들었다.

| | 사람이 보는 지도 | AI가 읽는 지도 |
|---|---|---|
| 무엇 | 폴더별 안내 문서, 영역 요약, 운영 대시보드 한 장 | 문서 머리에 붙는 라벨, 방마다 놓인 규칙 문서, 검색 인덱스 |
| 언제 | 내가 뭘 어디에 뒀는지 찾을 때 | AI가 어느 문서부터 봐야 할지 판단할 때 |
| 형태 | 읽는 문장과 링크 | 기계가 파싱하는 필드 |

같은 마크다운 파일 하나가 이 둘을 동시에 해낸다. 본문은 사람이 읽고, 파일 맨 위에 붙은 몇 줄짜리 라벨(어떤 영역인지, 언제 갱신됐는지, 공개해도 되는지)은 AI가 읽는다. 사람은 라벨을 볼 일이 거의 없고, AI는 라벨부터 본다. 한 파일에 두 독자가 산다.

여기에 하나 더 얹은 게 운영 대시보드인데, 볼트 상태를 한 장짜리 HTML로 뽑아 주는 물건인데, 문서가 몇 개고 최근에 뭐가 들어왔고 정리가 밀린 게 뭔지가 뜬다. 그래프 뷰가 못 해 준 "지금 뭘 해야 하는지"를 이게 답해 준다. 예쁜 별자리 대신 계기판을 택한 셈이다.

나중에 알게 된 건데, 나와 비슷한 방식을 쓰는 해외 실무자도 "옵시디언 그래프 뷰는 필요 없다"고 잘라 말하고 있었다. 같은 결론에 각자 도달한 셈인데, 이유도 같았다. 지식 관리에서 중요한 건 연결의 그림이 아니라 판단의 순서다.

## 4. 챗 앱으로는 안 되는 이유

처음에는 챗지피티나 클로드 앱 안에서 해결해 보려 했다. 안 된다. 이유는 단순한데, **챗 앱은 내 파일을 소유하지 못한다.**

대화창에 파일을 첨부할 수는 있어도, AI가 내 폴더를 직접 열고 읽고 수정하고 새 파일을 만드는 건 불가능하다. 위키를 AI가 유지보수하려면 AI에게 파일을 다루는 손발이 있어야 한다. 편집장에게 편집실 열쇠를 줘야 하는데, 챗 앱의 AI는 면회실에서만 만날 수 있는 상태였다.

그 손발을 가진 도구가 개발자용 코딩 도구인 클로드 코드(Claude Code)와 코덱스(Codex)였다.

이 도구들의 원래 용도는 이렇다. 개발자가 프로젝트 폴더를 지정하면 AI가 그 폴더 안의 코드를 읽고 고치고 새 파일을 만들며 개발을 돕는다. 모든 변경은 커밋(commit)이라는 단위로 기록되어 언제 무엇이 왜 바뀌었는지 역사가 남는다.

여기서 발상의 전환이 나왔다. 저 폴더에 코드가 아니라 내 지식을 넣으면?

하나씩 대응시켜 보니 빠짐없이 맞아떨어졌다.

| 코딩 도구의 기능 | 지식 관리로 옮기면 |
|---|---|
| 폴더 안의 파일을 읽고 고침 | 위키를 AI가 유지보수 |
| 규칙 문서(설정)를 먼저 읽고 따름 | 카파시가 말한 '스키마의 지배' |
| 모든 변경이 커밋으로 기록됨 | 지식의 변경 이력, 언제든 되돌리기 |
| 여러 파일을 한 번에 훑고 고침 | 새 정보가 여러 문서에 동시 반영 |

코딩 도구가 가진 능력 전부가, 사실은 지식 관리에 필요한 능력과 하나하나 일치했다. 개발자들이 코드를 커밋하는 자리에 나는 회의록과 결정과 생각을 커밋하면 된다.

1화에서 심긴 씨앗이 여기서 발아했는데, 오픈클로가 로컬에서 내 파일을 읽고 쓰는 걸 보며 신기해했는데, 코딩 도구는 그 능력을 훨씬 정교하게 갖추고 있었다. 다만 아무도 이걸 지식 관리용으로 쓰지 않을 뿐이었다.

지금이야 몇 문단으로 깔끔하게 정리하지만, 당시에는 이게 맞는 방향인지 확인해 줄 사람이 없었다. 코딩 도구를 코딩에 안 쓰겠다는 이야기라 개발자 친구에게 물어볼 성격의 질문도 아니었고, 결국 확인은 실험으로 할 수밖에 없었다.

## 5. 원안을 그대로 쓰지 않았다

2026년 5월 하순의 어느 밤. 클로드 코드를 폴더 구조로 운영하는 방법을 다룬 자료를 발견하고 스크린샷 여덟 장을 연달아 찍었다. 지금 보면 그 밤이 착공식이었다.

다음 날 저녁에 첫 설계 문서를 썼는데, 사실 회사 업무 폴더 하나에서 몇 달째 비슷한 실험을 하며 확신을 쌓아 온 터라, 결정 자체는 빨랐다.

여기서 중요한 이야기를 하나 해야겠다. 나는 카파시의 원안을 그대로 베끼지 않았는데, 원안은 개인 연구자가 자기 자료를 다루는 그림이었고, 내가 다뤄야 하는 건 회사 전략과 가족 문서와 투자 기록이 한 컴퓨터에 섞여 있는 삶이었다. 그래서 네 군데를 고쳤다.

| 항목 | 카파시의 원안 | 내가 고친 것 |
|---|---|---|
| 층 구조 | raw + wiki + 스키마 | 여기에 output(산출물)을 더하고, 삶의 영역별로 방을 나눔 |
| 유지보수 | LLM이 위키를 관리 | LLM이 관리하되, 의미가 바뀌는 변경은 사람에게 물어봄 |
| 규칙 | 스키마 파일 하나가 지배 | 공통 규칙 + 방마다 놓인 안내문 + 명령어 다섯 개 |
| 품질 확인 | 언급 없음 | 검색 품질을 채점표로 실측하고 나빠지면 되돌림 |

왜 고쳤는지가 이 시리즈의 나머지 내용이다. 짧게 말하면 원안은 "지식을 어디에 둘 것인가"까지만 답하는데, 내가 부딪힌 문제는 그다음이었다. 누가 언제 고쳐도 되는지, 비공개가 새지 않는지, 사실이 충돌하면 어느 쪽이 정본인지. 구조가 아니라 운영의 문제다.

그리고 원안에 없던 조건을 하나 얹었는데, 1화에서 정의한 그 목표대로 앞단의 AI는 어떤 모델이든 갈아끼울 수 있어야 한다는 것이다. 그래서 규칙 문서도 특정 AI 전용이 아니라, 어떤 AI가 들어와도 같은 규칙을 읽고 같은 방식으로 일하도록 썼다.

정리하면 구조는 이렇게 3층이 됐다.

![Neurain 3층 구조](neurain-layers.svg)

아래 두 층은 내 폴더에 있고 위층만 교체되니, 이 그림 한 장이 두 달치 설계의 결론이다.

당시 설계 문서에는 이런 문장이 적혀 있다.

**"사람은 계속 파일을 소유하고, AI는 그 파일 구조를 읽고, 저장하고, 정리하고, 검증하고, 이어받는다."**

지금 다시 읽어도 이 한 문장이 전부이고, 남은 건 이걸 실제로 굴러가게 만드는 일이었다.

문제가 하나 있었다. 나는 코드를 한 줄도 쓸 줄 모른다.