[Neurain 개발일지] #5. Neurain 해독법

여기까지 읽고 "그래서 정확히 뭐가 어떻게 생겼는데?"가 궁금해진 사람을 위한 사용 설명서다. 저장해 두고 필요할 때 꺼내 보면 된다.

시스템에는 Neurain이라는 이름도 붙였는데, 내부에서는 그냥 '뇌'라고 부른다.

TL;DR

1) Neurain = 지식(LLM Wiki) + 운영 규칙 + 갈아끼우는 AI 호스트.
2) 폴더만 있으면 세컨드 브레인이 아니다. 차이는 운영 층에 있다.
3) 비슷한 제품 열아홉 개를 뜯어 봤다. 베낀 것과 일부러 안 베낀 것을 공개한다.
4) 남는 해자는 하나로 압축된다. 모델에 구애받지 않고 지식이 내 파일에 남는다.

1. 세 부품으로 보는 전체 그림

자동차에 비유하면 지식은 차체와 짐칸, 운영 규칙은 교통법규, AI 호스트는 엔진이다. 엔진은 더 좋은 게 나오면 갈아끼우지만, 그래도 차는 내 차고 짐은 내 짐이고 법규는 그대로다.

구조와 운영을 나누는 게 이 그림의 핵심인데, 폴더를 잘 짜 두는 것(구조)과 그 지식이 시간이 지나도 틀리지 않게 유지되는 것(운영)은 다른 문제다. 폴더만 있으면 어디에 쓸지는 알 수 있지만, 누가 언제 바꿔도 되는지 비공개가 새지 않는지, 사실이 충돌하면 어느 쪽이 정본인지는 폴더가 답해 주지 않는다. 그 답이 운영 규칙이고, Neurain은 사실 이 운영 층에 붙인 이름이다.

만들고 나서 알게 된 건데, 내가 두 달 동안 만든 것의 본질은 소프트웨어가 아니었다. 나와 AI 사이의 취업규칙에 가깝다. 뭘 해도 되고 뭘 물어봐야 하고 사고가 나면 어떻게 복구하는지를 정한 규칙집. 코드는 그 규칙을 강제하는 장치일 뿐이라, 그래서 비개발자가 만들 수 있었다고 본다. 규칙을 정하는 일은 원래 개발이 아니라 운영의 영역이니까.

2. 폴더의 신분 제도

4화의 평면도를 신분으로 다시 보면 이런데, 핵심은 무엇이 정본이고 무엇이 보조인지 가르는 일이다.

정보는 한 방향으로만 흘러서, 들어온 것은 raw에 쌓이고 AI가 wiki와 영역 문서로 정리하고 필요할 때 output이 된다. 질문이 들어오면 반대 방향으로 검색이 도는데, 그 검색이 어떤 길을 거치는지는 4화의 흐름도 한 장에 정리해 뒀다.

이 신분 제도 덕에 무엇이 소중하고 무엇이 소모품인지가 명확해진다. 백업할 것은 증거와 정본이고 캐시는 버려도 되니, 사고가 나도 어디까지 복구하면 되는지 답이 정해져 있다. 실제로 AI가 정리를 잘못해 둔 걸 발견했을 때도 raw에 원본이 그대로 있으니 정리만 다시 시키면 끝이라 당황할 일이 없었다.

3. 명령어 다섯 개

하루 루틴은 단순한데, 아침에 _status로 어제를 이어받고 낮에는 그냥 대화하며 일하다가 잊으면 안 될 게 나오면 _save 한 번씩, 저녁에 _wrap으로 닫는다. 매일 쓰는 건 이 세 개고 나머지 둘은 시스템이 알아서 부른다.

_wrap 하나만 뜯어 보면 이 시스템의 성격이 보인다. 마감 한 번에 네 가지가 순서대로 도는데, 오늘 나온 것들을 저장하고 지식 문서로 정리하고 내일 세션에 넘길 인수인계를 갱신하고 마지막으로 검증한다. 저장한 것이 검색에 실제로 걸리는지, 비밀번호 같은 민감 정보가 실수로 섞이지 않았는지까지 훑은 뒤에 결과 영수증을 내민다. 퇴근 전에 책상을 정리하고 서랍을 잠그고 내일 할 일을 포스트잇으로 붙여 두는 일을 명령 하나가 대신하는 셈이다.

명령이 밑줄(_)로 시작하는 건 일상 대화와 명령을 구분하기 위해서다. "정리해줘"라는 말에 시스템이 멋대로 움직이는 사고를 겪고 나서 만든 규칙이다.

4. 자동과 수동의 경계

안전한 작업은 전부 자동이라, 저장과 정리와 인덱스 갱신과 동기화는 묻지 않고 돌아간다. 매번 허락을 구하는 비서는 비서가 아니다.

반대로 의미가 바뀌는 결정은 반드시 사람에게 물어온다. 목록으로 못 박아 뒀다. 비공개를 공개나 다른 영역으로 옮길 때, 기존 사실을 뒤집을 때, 충돌하는 자료 중 정본을 고를 때, 새 영역을 만들 때, 지우거나 크게 옮길 때, 가장 깊은 곳의 공식 기억을 바꿀 때. 물을 때도 "진행할까요?"가 아니라 어떤 문서의 어떤 내용이 문제인지, 선택지가 무엇인지를 구체적으로 들고 온다.

그리고 사고에 대비한 장치가 밑에 깔려 있는데, 변경 전 자동 저장점과 삭제 시 30일 휴지통 경유와 잘못됐을 때 되돌리기다. 비밀번호나 계좌번호 같은 게 저장물에 섞이면 저장 자체를 거부한다(막히면 통과가 아니라 정지다). AI에게 정리를 맡긴다는 건 AI를 믿는다는 뜻이 아니다. 믿을 수 있는 울타리를 먼저 치고 그 안에서만 맡긴다는 뜻이다.

이 경계선을 어디에 긋느냐가 사실 이 시스템 운영의 전부다. 전부 물어보게 하면 비서가 아니라 결재 기계가 된다. 전부 맡기면 어느 날 내 지식이 내가 모르는 사이에 바뀌어 있다. 두 달 동안 이 선을 몇 번이나 옮겼고, 지금 답은 위의 목록이다. 안전은 자동, 의미는 수동.

5. 열아홉 개를 뜯어 봤다

혼자 만들다 보면 바퀴를 다시 발명하고 있는 건 아닌지 불안해진다. 그래서 비슷한 걸 만든 사람들이 뭘 했는지 전수조사를 했다. 정리하고 보니 제품이 열아홉 개였다.

읽는 방식은 이랬다. 각 제품마다 세 가지만 물었다. 이건 무엇을 잘하려고 만들어졌나. 우리가 배울 게 있나. 우리가 일부러 다르게 갈 부분은 어디인가.

가장 깊게 해부한 상대

가장 오래 붙잡은 건 agentmemory라는 오픈소스였다. 별 2만 개 가까이 받은 물건이고 기능만 보면 화려하다. 키워드 검색과 벡터 검색과 그래프 검색을 한꺼번에 돌려 결과를 합친다. 사람의 망각 곡선을 흉내 내서 오래된 기억을 단계적으로 식혀 준다. 통합되는 AI 도구가 서른 개가 넘는다.

솔직히 처음엔 비교가 안 되겠다고 생각했다. 그래서 내부 구조까지 파고들었는데, 거기서 발견한 걸 보고 이 프로젝트의 방향을 굳혔다. 이 물건은 "외부 데이터베이스가 필요 없다"고 소개하는데, 실제로는 자기네 엔진의 상태 저장소에 강하게 묶여 있었다. 즉 그 엔진이 없으면 기억도 없다.

그 순간 내가 가진 것의 값어치를 알았다. 내 지식은 그냥 마크다운 파일이다. 데이터베이스도 없고 상주 프로그램도 없다. 폴더를 복사해서 나가면 그게 전부다.

그렇다고 무시한 건 아니다. 여덟 가지를 그대로 배워 왔다. 설치와 진단 명령을 갖추라는 것, AI에게 밀어 넣는 참고 자료의 분량에 상한을 두라는 것(그러지 않으면 비용과 속도가 무너진다), 문서마다 신뢰도와 출처와 대체 관계를 라벨로 달아 두라는 것, 한국어 검색을 위해 단어 쪼개기를 손보라는 것. 이런 것들이다.

반대로 여섯 가지는 명시적으로 "안 베낀다"고 적어 뒀다. 상시 켜져 있는 프로그램, 도구 쉰 개짜리 인터페이스, 오래된 기억 자동 삭제, 그리고 그쪽 성능 수치를 내 것처럼 인용하는 일. 마지막 건 특히 중요하다고 봤다. 남의 벤치마크 숫자를 빌려 쓰면 그건 내 성능이 아니다.

나머지에서 배운 것

이 표를 만들고 나서 내 위치가 선명해졌다. Khoj라는 제품을 검토하면서 적어 둔 한 줄이 결론이었다.

"저쪽은 노트와 대화하는 제품이고, 여기는 지식 체계를 최신으로 유지하는 제품이다."

그리고 대기업의 기본 기능

가장 무서운 경쟁자는 사실 오픈소스가 아니라 대형 AI 회사들의 기본 메모리 기능이다. 이것도 다섯 개를 놓고 열 개 항목으로 비교했다. 정직하게 인정할 게 하나 있다.

셋업이 없고 공짜고 기본으로 켜져 있다는 그쪽의 장점은 진짜로 크다. "나는 pnpm을 쓴다" 정도의 가벼운 취향을 기억시키는 용도라면 그걸 쓰는 게 맞다. 굳이 이런 시스템을 만들 이유가 없다.

내 비교표에서 Neurain이 유일하게 지는 항목도 명확했다. 셋업 부담이다. 다섯 개 중 가장 무겁다. 이건 내가 표에 직접 적어 놓은 문장이고 지금도 그렇게 생각한다.

6. 그래서 왜 필요한가

그럼에도 이걸 만든 이유, 그러니까 남는 차별점은 다섯 가지로 좁혀진다.

첫째, 모델에 구애받지 않는다. 이게 제일 크다. 같은 명령이 클로드에서도 코덱스에서도 돌고 결과 화면까지 같게 나오도록 출력을 한 군데서 만든다. 실제로 서로 다른 회사의 모델 세 개에 같은 근거 묶음을 주고 답하게 하는 실험도 통과했다. 앞단이 무엇이든 뒤의 뇌는 하나다.

둘째, 지식이 내 파일에 있다. 데이터베이스도, 상주 프로그램도, 서버 전송도 없다. 서비스를 떠날 때 협상할 게 없다. 폴더를 복사하면 끝이다.

셋째, 숨은 기억이 아니라 보이는 문서다. 대기업 메모리는 무엇을 왜 기억했는지 열어볼 수 없다. 여기서는 전부 파일이라 열어 보고 고치고 지울 수 있다. 무엇이 정본이고 무엇이 캐시인지도 문서로 정해져 있다.

넷째, 기록이 남는다. 무엇이 언제 바뀌었는지는 추가만 되는 로그와 커밋 기록에 쌓인다. 비교한 다섯 제품 중 감사 기록이 있는 건 여기뿐이었다.

다섯째, 저장한 것을 다시 찾아 증명한다. 마감 명령이 오늘 저장한 문서를 실제로 검색해 보고 안 걸리면 알려 준다. 저장했다고 말만 하고 정작 못 찾는 사고를 막기 위한 장치인데, 이것도 비교 대상 중에는 없었다.

대기업 메모리는 편의를 판다. 이 시스템은 소유권과 이식성을 산다. 둘은 다른 물건이고 후자가 필요해지는 건 쌓인 맥락이 커졌을 때다.

7. 흔한 세컨드 브레인과 뭐가 다른가

카파시의 메모 이후 비슷한 세컨드 브레인 구축기가 많이 나왔다. 대부분 폴더 구조에 프롬프트를 얹은 형태에서 멈춘다. 구조는 있는데 운영이 없는 상태다.

폴더는 하루면 만들고, 두 달이 걸린 건 아랫줄 네 개였다. 아랫줄이 없으면 시간이 지날수록 낡은 정보가 최신 정보를 덮고 비공개가 새고 검색이 미덥지 않아져서 결국 시스템을 안 쓰게 된다. 세컨드 브레인이 한 달 만에 버려지는 전형적인 경로가 이것이다.

8. 구글이 답을 맞혀 줬다

한창 만들던 2026년 7월, 구글이 Open Knowledge Format(OKF)이라는 것을 발표했다. AI가 읽기 좋은 지식 저장 포맷의 표준안인데, 발표를 열어 본 순간이 아직 기억난다. 마크다운에 라벨을 얹고 index와 log 파일을 두는 구조에 심지어 문서에서 카파시를 인용하고 있었으니, 내가 두 달째 쓰고 있는 구조와 같은 방향이었다.

혼자 만든 사람의 불안이라는 게 있는데, 이 방식이 맞는 건지 확인해 줄 사람이 없다는 불안이다. 업계 표준이 뭔지 남들은 어떻게 하는지 물어볼 동료가 없으니 비개발자라 더했다. 그 불안이 빅테크의 표준안 문서 하나로 상당 부분 걷혔다.

바로 클로드와 코덱스에게 OKF 스펙 원문을 주고 내 시스템과 비교시켰다. 판정은 이랬다. 내 문서 라벨 체계가 OKF 필수 필드의 상위호환이라 고칠 것 없이 이미 적합. 콘텐츠 구조는 오히려 내 쪽이 더 세분화되어 있다는 평이었다.

물론 다 이긴 건 아니라 배운 것과 진 것도 적어 둔다. 구글 표준은 파일 이름 규칙을 일부러 정하지 않았는데, 그건 내 규칙이 채운 빈칸이었다. 반대로 스펙을 문서로 정리해 배포하는 솜씨는 비교가 안 되게 저쪽이 낫다. 배울 점들은 표준 형식으로 내보내는 변환기나 라벨 대응표처럼 그대로 가져와 반영했다. 언젠가 내 뇌를 통째로 표준 형식으로 내보낼 수도 있다. 덤으로 '구글 표준 호환'이라는 공짜 명함도 생겼다.

9. 나도 만들어 보고 싶다면

거창하게 시작할 필요 없고, 최소 버전은 세 단계다.

1. 폴더 하나를 만들고 그 안에 수집함(raw), 지식(wiki), 산출물(output) 폴더를 판다.
2. 규칙 문서 한 장을 쓴다. "raw는 안 고친다, wiki는 AI가 정리한다" 두 줄이면 시작으로 충분하다.
3. 오늘부터 들은 것, 본 것을 수집함에 넣고 AI에게 정리를 시켜 본다.

주의할 것은 하나인데, 처음부터 도구를 만들려 하지 말라는 것이다. 폴더와 규칙 문서만으로 한 달을 살아 보고 반복해서 불편한 지점이 생기면 그때 그 지점만 자동화하면 된다. 내 명령어 다섯 개도 그렇게 나왔으니, 구조는 단순하게 시작해서 필요할 때 키우면 되고 나머지는 습관이 만든다.