공부 20

[세컨드브레인 개발기] 1. 개인 세컨드브레인을 RAG 없이 시작한 이유

의료영상 AI 연구를 하다 보니, 논문이며 회의록, 연구계획서, 강의자료, 과제 문서가 몇 년치 쌓였는데, 어느 순간부터는 어디에 뭐가 있는지 내 머리로 감당이 안 되기 시작했다. 검색을 해도 파일명이 기억나야 찾아지고, 파일명은 당연히 기억나지 않고. 그래서 개인 연구용 세컨드브레인을 만들기로 했다. 2026년 6월 2일이었다. 이 글은 그 첫날에 내린 설계 결정 하나에 관한 이야기다. 요즘 이런 걸 만든다고 하면 거의 자동으로 나오는 답이 있는데, 문서를 청크로 쪼개 임베딩하고 벡터DB에 넣어두고, 질문이 들어오면 비슷한 조각을 꺼내 LLM에 물리는 방식, 그러니까 RAG다. 나는 그걸 안 하기로 시작했다. 두 달 뒤에 이 시스템은 "아무짝에도 쓸모없다"는 말을 듣게 되는데, 미리 밝혀두면 그 원인은..

[세컨드브레인 개발기] 14. GB10 에서 배운 것 — 속도는 대역폭을 활성 파라미터로 나눈 값이다

이 시리즈의 3부는 에이전트가 창고를 쓰는 이야기였다. 그리고 그 마지막 편에서, 나는 하나의 빚을 남기고 3부를 닫았다. 그 무렵 Hermes 의 브레인은 27B 였고, 그 27B 가 왜 그렇게 느렸는지는 다음 부에서 풀겠다고 했다. 그보다 더 일찍, 12편에서도 같은 질문을 접어둔 적이 있다. 모델이 느리다는 것 자체는 확인했는데, 왜 하필 그 모델이 그렇게 느린지는, 모델의 문제라기보다 그것을 올린 기계가 초당 얼마를 읽어낼 수 있느냐의 문제라며, 그 자리에서는 접어두었다. 이제 4부가 시작됐으니 그 빚을 갚는다. 이 편의 주제는 하드웨어다. 창고도, 에이전트도, 도구도 아닌, 그 모든 것이 올라가 있는 박스 하나의 물리적 특성이, 왜 모델 선택을 지배했는지에 대한 이야기다. 결론을 먼저 말하면, ..

[세컨드브레인 개발기] 13. Hermes 에게 자율성을 얼마나 줄 수 있나 — 실측

지난 편에서 남은 질문이 하나 있었다. 브리지가 살아나고, 대답이 3분에서 15초로 내려오고 나니, 이제는 그 에이전트에게 일을 얼마나 맡길 수 있을까였다. 여태까지는 에이전트가 질문을 받고 답하는 쪽만 보고 있었는데, 슬랙 저편에서 스스로 판단해서 뭔가를 만들어 내는 모습은 한 번도 본 적이 없었다. 감으로 답하지 않으려고, 일을 실제로 던져봤다. kanban 보드에 다섯 개의 태스크를 올리고, 세 명의 워커에게 나눠 주고, 밤 열 시 반부터 새벽 한 시까지 지켜봤다. 그 실측이 이 편의 전부다. 결론부터 말하면, 일을 끝까지 해내는 경우와 중간에 죽는 경우가 갈리는 지점이 꽤 선명하게 보였고, 그 경계는 내가 처음에 그었던 것과는 조금 다른 곳에 있었다.무슨 일을 던졌나그 무렵 Hermes 의 브레인..

[세컨드브레인 개발기] 12. Slack 봇이 3분 걸린 이유 — 원인이 3겹이었다

지난 편에서, 플랫폼을 Hermes 로 갈아타고 브리지가 다시 살아났다고 했다. 살아나기는 했는데, 그다음 문제가 바로 그 자리에서 기다리고 있었다. 대답이 오는 데 걸리는 시간이었다. 슬랙에 질문을 던지면, 입력 표시는 뜨는데 대답이 오기까지 꼬박 3분이 걸렸다. 죽어 있는 것도 아니고, 살아 있는 것도 아니고, 그 중간 어딘가에서 하염없이 기다리는 상태였다. 지난 편에서도 썼지만, 플랫폼을 바꾸는 일은 그 자체로 끝이 아니라 그 위에서 문제가 어디서 나는지가 달라지는 일이다. 이번에는 그 문제가 통로가 아니라 시간이었다. 이 편은 그 3분을 세 번에 걸쳐 고친 이야기다. 같은 증상을, 세 번, 서로 다른 이유로. 하나씩 겹을 벗겨보자.첫 번째 겹 — 모델이 느리다그 무렵 Hermes 의 브레인은 ed..

[세컨드브레인 개발기] 11. OpenClaw 를 버리고 Hermes 로 간 이유

지난 편에서, 브레인에 MCP 를 달고, 에이전트가 창고에 쓰는 손을 얻었다고 했다. 그런데 그 이야기에는 전제가 하나 숨어 있다. 창고를 쓰는 쪽, 즉 에이전트가 제대로 서 있어야 한다는 전제다. 3부가 묻는 것은 창고를 쓰는 쪽이 누구인가인데, 그 쪽을 통째로 갈아탄 일이 이 편의 중심이다. MCP 가 붙은 뒤로 얼마 지나지 않아, 에이전트 플랫폼을 OpenClaw 에서 Hermes 로 바꿨다. 이유는 하나, 남의 버그였다. 지난 편 끝에서 예고한, 겉으로는 읽는 일을 하는 것처럼 보이면서 뒤에서 사람의 몫을 하던 도구들의 이야기는 그다음 편에서 풀기로 하고, 이 편은 그 도구들이 달려 있던 플랫폼의 이야기다. 하나씩 보자.게이트웨이와 페어링그때까지 에이전트 플랫폼으로 쓰던 것은 OpenClaw 였다..

[세컨드브레인 개발기] 10. 브레인에 MCP 를 달다 (읽기 → 쓰기)

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

[세컨드브레인 개발기] 9. 매주 월요일 아침, 논문이 온다.

지난 편 끝에서, 논문은 매주 월요일 아침에 모여 한국어 요약으로 만들어져 텔레그램으로 온다고 했다. 그 이야기다. 메일이 지금 일어나는 일을 남긴다면, 논문은 앞으로 할 일을 정하는 재료인데, 그 재료는 들어오는 것만으로는 부족하고 읽혀야 했다. 하루에 읽을 수 있는 논문은 한정되어 있고, 쏟아지는 논문은 그보다 많으니, 이 자동화는 읽기를 대신하지 않기로 했고, 대신 고르는 일을 맡기로 했다. 메일 편에서는 받는이를 기준으로 갈랐는데, 논문은 어떤 기준으로 갈랐는지가 이 편의 중심이다. 무엇을 골랐는지, 하나씩 보자.매주 월요일 아침에 온다첫 버전은 맥의 launchd 가 매주 월요일 아홉 시에 깨우는 작업이었다. 논문은 세 곳에서 걷는데, arXiv 에서는 영상처리와 컴퓨터비전 두 카테고리를, Pu..

[세컨드브레인 개발기] 8. 단체 메일은 조용히.

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

[세컨드브레인 개발기] 7. 전사가 깨진 이유.

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

[세컨드브레인 개발기] 6. 소리가 줄어드는 녹음.

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