TechToast

[세컨드브레인 개발기] 11. OpenClaw 를 버리고 Hermes 로 간 이유브레인에 MCP를 달고, 에이전트가 창고에 쓰는 손을 얻었습니다. 그런데 그 이야기에는 전제가 하나 숨어 있어요. 창고를 쓰는 쪽, 즉 에이전트가 제대로 서 있어야 한다는 전제입니다. 3부가 묻는 것은 창고를 쓰는 쪽이 누구인가인데, 그 쪽을 통째로 갈아탄 일이 이 편의 중심입니다. MCP가 붙은 뒤로 얼마 지나지 않아, 에이전트 플랫폼을 OpenClaw에서 Hermes로 바꿨습니다. 이유는 하나, 남의 버그였어요. 지난 편에서 예고한 그 도구들의 이야기는 다음 편에서 풀기로 하고, 이 편은 그 도구들이 달려 있던 플랫폼의 이야기입니다. 하나씩 보겠습니다.게이트웨이와 페어링 그때까지 에이전트 플랫폼으로 쓰던 것은 OpenCl..

[세컨드브레인 개발기] 10. 브레인에 MCP 를 달다 (읽기 → 쓰기)지난 편 끝에서, 입력은 이제 들어올 만큼 들어온다, 다음 문제는 채우는 것이 아니라 쓰는 것이라고 했습니다. 그 말이 이 편이 하는 일의 예고였어요. 이 편부터 시리즈의 부가 바뀝니다. 2부가 입력을 만드는 일이었다면, 3부는 그 입력을 쓰는 쪽이 누구인가의 이야기입니다. 파이프라인은 정해진 시간에 정해진 일을 하지만, 에이전트는 대화 속에서 무엇이 중요한지를 스스로 가릅니다. 그 차이가, 창고에 들어오는 것의 성격까지 바꿔요. 지금까지 브레인에 무언가 들어오는 길은 하나같이 기계였습니다. 파이프라인이 걷고, 회의록이 쌓이고, 논문 리뷰가 떨어졌죠. 사람이 직접 넣는 일도 있었지만, 그건 언제나 손이 필요했습니다. 그런데 이번에는 ..

[세컨드브레인 개발기] 9. 매주 월요일 아침, 논문이 온다.지난 편 끝에서, 논문은 매주 월요일 아침에 모여 한국어 요약으로 만들어져 텔레그램으로 온다고 했습니다. 그 이야기예요. 메일이 지금 일어나는 일을 남긴다면, 논문은 앞으로 할 일을 정하는 재료인데, 그 재료는 들어오는 것만으로는 부족하고 읽혀야 합니다. 하루에 읽을 수 있는 논문은 한정되어 있고, 쏟아지는 논문은 그보다 많으니, 이 자동화는 읽기를 대신하지 않기로 했습니다. 대신 고르는 일을 맡기로 했어요. 메일 편에서는 받는이를 기준으로 갈랐는데, 논문은 어떤 기준으로 갈랐는지가 이 편의 중심입니다. 무엇을 골랐는지, 하나씩 보겠습니다.매주 월요일 아침에 온다 첫 버전은 맥의 launchd가 매주 월요일 아홉 시에 깨우는 작업이었습니다. 논..

[세컨드브레인 개발기] 8. 단체 메일은 조용히.이번 편은 메일입니다. 교직원 포털의 그룹웨어는 대학 생활의 온갖 것이 지나가는 길인데, 회의 안내와 행정 공지가 오고, 동료의 메일이 오고, 학생의 질문이 옵니다. 이 흐름을 브레인에 넣어 두면, 브레인이 내가 하는 일의 적지 않은 부분을 저절로 알게 되는데, 그게 이 자동화를 시작한 이유였습니다. 메일 하나가 곧 업무 기록 하나라, 긁어 두면 기록이 되고 놓치면 흔적도 없어요. 회의록은 지나간 일을 남기는데, 메일은 지금 일어나는 일을 남깁니다. 그런데 막상 만들어 보니 메일을 긁어오는 일 자체는 어렵지 않았습니다. 어려웠던 것은 쌓인 메일을 어떻게 나누느냐였고, 그 나눔이 이 편의 전부예요. 수집은 도구의 일이고, 나눔은 사람의 일입니다. 어떤 기준..

[세컨드브레인 개발기] 7. 전사가 깨진 이유.지난 편의 마지막에서, 전사가 전사대로 싸움을 준비하고 있다고 했는데, 그 싸움의 상대는 소리가 아니었습니다. 회의 녹음을 글로 바꾸는 brain-transcribe라는 작업이, 죽어 있었어요. 녹음기는 소리를 받는 법을 고쳤는데, 정작 그 소리를 받아야 할 다음 관문이 넘어져 있었습니다. 그달 중반의 기록에는, numpy와 numba의 충돌이라는 진단 한 줄이 남아 있습니다. 버전 두 개가 싸운 흔적을, 하나씩 보겠습니다. 전사가 하는 일은 단순한데, 16k 모노 wav를 받아서 텍스트로 바꾸는 것 하나입니다. 그 일을 하는 도구는 mlx-whisper인데, large-v3-turbo라는 모델을 맥의 통합 메모리 위에서 도는 애플 실리콘 전용 음성 인식이에..

[세컨드브레인 개발기] 6. 소리가 줄어드는 녹음.메뉴바 회의 녹음기부터 봅니다. 여덟 개로 시작해 열한 개가 된 파이프라인에, 첫 번째로 붙은 것이 이 녹음기예요. 회의가 시작되면 클릭하고, 끝나면 또 클릭하는, 그게 전부인 앱입니다. 5분마다 도는 동기화나 10분마다 도는 전사와 달리, 이건 손가락이 눌러야 시작되는 트리거 방식입니다. 트리거로 산다는 점은 끝까지 그대로였는데, 소리를 받는 방식만 이상하게 무너졌습니다. 열 초를 녹음했는데 2.73초짜리 파일이 나오는, 소리가 줄어드는 실패였어요. 무엇이 줄었는지, 하나씩 보겠습니다. 그달 중반에 붙은 세 개는 성격이 저마다 달랐습니다. 매일 새벽 세 시에 도는 정리 작업, 매주 월요일 아홉 시의 논문 리캡, 그리고 버튼이 눌릴 때 도는 녹음기. 셋 ..

[세컨드브레인 개발기] 5. 끊기지 않는 유입.1부의 끝에서, 2부는 자료가 끊기지 않고 흘러들게 만드는 이야기라고 적었습니다. 자동화 8개를 붙였고, 그중 몇 개는 이상한 방식으로 실패했다고도 적었어요. 이제 그 여덟 개가 무엇이고, 왜 그 간격으로 도는지부터 보겠습니다. 1부에서 만든 것은, 정확히는 소화 기관입니다. 문서를 읽어 위키로 합성하고, 임베딩으로 색인하고, 질문이 오면 거기서 답을 찾는. 그런데 그 어느 것도, 재료가 들어오지 않으면 시작되지 않습니다. 합성할 소스가 없으면 합성할 게 없고, 색인할 파일이 없으면 색인할 게 없어요. 이걸 만들고 며칠 만에, 일이 실제로 어디에 있는지가 보였습니다. 합성이 아니라, 끊기지 않는 유입이었어요. 유입 경로는 네 갈래였습니다. 손으로 쓰는 노트..

[세컨드브레인 개발기] 4. 위키가 영어로 쓰여 있었다 — 4,382개 중 482개1부의 마지막 편입니다. 앞 세 편에서 세컨드브레인을 LLM-Wiki 패턴으로 시작하고, 문서 2만 개를 만나 벡터 검색 계층을 얹고, 온갖 파일 포맷에서 텍스트를 꺼내는 이야기를 썼습니다. 이 편은, 그렇게 만든 위키를 열어봤을 때 생긴 일입니다. 2주쯤 지나 브라우징 화면을 붙였고, 페이지를 넘겨보다가 이상한 걸 발견했습니다. 일부 페이지가 영어로 쓰여 있었습니다. 내 자료는 거의 전부 한국어인데, 합성된 페이지가 영어라니. 아무도 부탁하지 않은 번역이었죠. 왜 그랬는지부터 보겠습니다. 원인은 금방 찾았는데, ingest 시 LLM에 주는 시스템 프롬프트에 한국어로 작성 지시가 이미 있었습니다. 어라, 지금 규칙은 맞..

[세컨드브레인 개발기] 3. 20k 문서를 실제로 읽어들이기 — 로더 지옥앞 편에서 문서 2만 개를 만나 설계를 고친 이야기를 썼습니다. 벡터 검색 계층을 얹고, 청크로 쪼개서 임베딩하면 된다고 적었는데, 그 문장에는 앞 단계가 하나 빠져 있습니다. 파일에서 텍스트를 꺼내는 일. 이게 이 프로젝트에서 제일 지루하고, 제일 오래 걸리고, 블로그에서 아무도 안 쓰는 부분입니다. RAG 튜토리얼은 대부분 PyPDFLoader 한 줄로 끝나요. 실제 자료는 그렇게 생기지 않았습니다. 공문 하나만 열어봐도 한글 파일이 나오고, 구형 오피스 파일이 나오고, 스캔 이미지가 나옵니다. 이 글이 그 삽질을 반복하지 않게 해주면 좋겠습니다.처리해야 했던 포맷 드라이브에서 당겨온 파일의 확장자를 세어보고 정리한 목록입니다...

[세컨드브레인 개발기] 2. 20,000개 문서 앞에서 설계가 무너진 날앞 편에서, 개인 연구용 세컨드브레인을 벡터 RAG 없이 시작한 이야기를 썼습니다. 소스가 들어올 때 LLM이 한 번 읽고 링크 걸린 마크다운으로 다시 쓰는 방식(Karpathy의 LLM-Wiki 패턴)이고, 근거 중 하나가 "개인 규모에서는 사전합성이 RAG를 이긴다"였습니다. 2026년 6월 2일에 그게 엔드투엔드로 돌아가는 걸 확인했습니다. 같은 날 설계가 깨졌습니다. 이 편은 그 이야기고, 시리즈에서 제일 중요한 편이라고 생각합니다.산수 한 줄로 끝났다 구글드라이브에는 대학 두 곳에서 일하며 만든 자료가 예전부터 쌓여 있었습니다. 브레인에 넣을 대상으로 그 폴더를 지정하고, 규모를 세어봤어요. 폴더 두 개를 합쳐 문서 20,..