끊기지 않는 유입.

1부의 끝에서, 2부는 자료가 끊기지 않고 흘러들게 만드는 이야기라고 적었다. 자동화 8개를 붙였고, 그중 몇 개는 이상한 방식으로 실패했다고도 적었다. 이제 그 여덟 개가 무엇이고, 왜 그 간격으로 도는지부터 본다.

 

1부에서 만든 것은, 정확히는 소화 기관이다. 문서를 읽어 위키로 합성하고, 임베딩으로 색인하고, 질문이 오면 거기서 답을 찾는. 그런데 그 어느 것도, 재료가 들어오지 않으면 시작되지 않는다. 합성할 소스가 없으면 합성할 게 없고, 색인할 파일이 없으면 색인할 게 없다. 이걸 만들고 며칠 만에, 일이 실제로 어디에 있는지가 보였다. 합성이 아니라, 끊기지 않는 유입이었다. 유입 경로는 네 갈래였다. 손으로 쓰는 노트, 회의에서 나는 소리, 포털에 오는 메일, 그리고 일정. 넷 다 손이 닿아야 하는 곳이고, 손이 닿는 대로 늦어지거나 빠뜨려지는 곳이었다. 그날 밤의 작업은 이 넷을 손에서 떼는 일이었다. 이 넷이 하루에 만들어내는 것도, 그걸 옮기고 합성하고 색인하는 것도, 전부 기계가 하게 됐다. 사람이 할 일은 자료를 쓰고 회의에 나가고, 나온 결과를 읽는 것뿐이다.

 

 

그래서 6월 4일 밤, 자동화를 붙이는 작업을 했다. 기록에는 '야간 완성 작업 — 전체 시스템'이라는 제목 아래 launchd 여덟 개와 cron 다섯 개가 나열되어 있다. 한 번에 끝났다. 결과만 있고, 실행해서 확인했다는 기록은 없다.

 

일은 두 대의 컴퓨터로 나눠졌다. 맥은 수집을 맡고, 서버는 가공을 맡는다. 필연이었는데, 그룹웨어의 로그인 세션도 마이크도 캘린더도 전부 맥에만 있기 때문이다. 서버가 아무리 빠르고 커도, 교직원 포털에 들어간 브라우저의 쿠키를 갖고 있지 않고 회의실의 소리를 들을 수 없다. 사람이 쓰는 기기의 로컬 자원에 닿는 일은, 맥에서만 실행 가능한 일이다. 이 사실은 나중에, 자동화를 다른 기계로 옮기려 할 때마다 발목을 잡는다. 여덟 개와 다섯 개를 한 번에 늘어놓고 보자.

맥의 여덟 개

맥 launchd — 여덟 개
brain-sync              5분마다        옵시디언 볼트 동기화
brain-transcribe        10분마다       녹음 → 전사
brain-meeting-minutes   15분마다       전사 → 회의록 정리
brain-notes-export      30분마다       애플노트 내보내기
brain-wiki-pull         매시간         서버의 위키를 맥으로
brain-calendar-export   06·07·13·19시  일정
brain-portal-groupware  08:30·13:30·18:30  그룹웨어 수집
brain-portal-digest     19:00          하루치 요약

 

 

동기화가 5분이다. 이름 그대로 동기화만 하는 작업인데, 옵시디언 볼트를 서버로 밀어 넣는다. 이게 파이프라인의 첫 관문이라 가장 자주 돌고, 저장한 노트는 늦어도 5분 안에 서버에 도착한다. 5분이면, 앉아서 일하는 동안 이미 반영되어 있는 간격이다. 동기화가 늦어지면 그 뒤의 모든 단계가 함께 늦어진다. 그래서 여덟 개 중에서 가장 짧은 주기가 여기에 붙었다.

 

전사는 10분, 정리는 15분이다. 회의 녹음 파일이 생기면 먼저 전사가 도는데, mlx-whisper 를 쓰는 작업이다. 정리는 그 전사를 LLM 으로 요약해 회의록 폴더에 넣는다. 두 작업이 주기를 달리하니, 새 파일은 10분 안에 글이 되고 15분 안에 정리본이 된다. 회의가 끝나면 녹음 파일이 볼트에 떨어지고, 그다음부터는 전부 기계가 한다. 마이크에 닿을 수 있는 건 맥뿐이라서, 가능한 일이었다.

 

노트 내보내기는 30분이다. 애플노트를 마크다운으로 꺼내는 작업인데, 하루에 마흔여덟 번 돈다. 캘린더는 하루 네 번, 오전 여섯 시와 일곱 시, 오후 한 시와 일곱 시다. 아침 두 번, 점심, 저녁. 하루가 시작하기 전과, 하루가 진행되는 사이에 일정을 다시 본다.

 

그룹웨어는 하루 세 번, 오전 여덟 시 반, 오후 한 시 반, 오후 여섯 시 반이다. 받은편지함을 스크랩해 첨부까지 긁어오는데, 받는이와 참조인을 읽어 개인 메일과 단체 메일을 나누고, 개인 메일에만 텔레그램 알림을 보낸다. 첨부 파일은 내려받아 텍스트를 뽑아 두는데, 스캔 문서는 OCR 을 돌린다. 제목만 남는 게 아니라, 안에 든 내용까지 브레인에 들어간다. 출근 전, 점심 후, 퇴근 전. 메일이 쌓이는 시간대를 세 번 덮는다.

 

다이제스트는 열아홉 시다. 포털에서 들어온 것의 하루치를 모아 요약하고, 위키풀은 매시간 서버에서 갱신된 위키를 맥으로 당겨온다. 동기화에서 뺀 폴더가 넷인데, 서버가 만드는 위키, 그룹웨어 첨부, 회의록 녹음, 처리 완료로 옮긴 원본이다. 위키는 위키풀이 따로 당기니 중복이고, 처리 완료는 다시 인제스트되는 걸 막으려는 것이다. 첨부와 녹음을 뺀 이유는 기록에 남겨두지 않았다.

 

여덟 개가 만드는 파일은 전부 볼트 안에 떨어진다. 내보낸 노트, 전사본, 정리본, 스크랩한 메일. 그걸 서버로 옮기는 일은 여덟 개 밖에 있는데, 5분짜리 동기화가 한다. 수집의 모든 결과물은 결국, 동기화 한 줄로 이어진다.

서버의 다섯 개

서버 cron — 다섯 개
ingest-curated.sh   매시 :00    정제된 소스만 위키로 합성
index --scan        매시 :30    새 파일 임베딩
gdrive-sync         03:00       구글 드라이브 수집
digest              08:05       하루치 요약
lint                일 09:00    위키 점검

 

 

합성은 정각, 색인은 30분이다. ingest-curated 는 매시 정각에 정제된 소스만 위키로 합성하는데, 긴 노트만 대상이고 짧은 노트는 검색에만 들어간다. 120자 미만은 위키로 만들 가치가 없다는 판단이었다. 그래도 짧은 노트는 검색에는 들어가니, 아예 사라지는 건 아니다. 여기에 flock 이라는 잠금이 걸려 있어서, 이전 회차가 아직 돌고 있으면 겹치지 않게 한다. 겹쳐서 돌면 같은 파일을 두 번 건드리게 되고, 그만큼 합성 비용도 두 번 든다. 문서당 70초짜리 LLM 합성이니, 정각마다 한 번씩 하루에 스물네 번 도는 셈이다. 색인은 그 30분 뒤에 새 파일을 임베딩한다. 매시간 두 작업이 번갈아 돈다.

 

구글 드라이브는 서버가 rclone 으로 직접 당겨왔다. 맥을 경유하지 않는다. 문서 2만 개짜리 저장소라 하루 한 번, 새벽 세 시로 잡았다. 밤새 쌓인 변경분을, 새벽에 한 번에 받는 셈이다. 최초의 2만 개를 밀어 넣은 뒤로는, 새로 생긴 것만 받는다. 다이제스트는 아침 여덟 시 오 분, 어제 들어온 것을 모아 요약하는 작업이다. lint 는 일요일 아홉 시에 위키의 모순과 고아 링크와 누락을 점검한다. 점검은 매일 돌아도 그날그날 변하는 게 아니니, 주 단위로 뒀다.

주기는 작업의 단가를 따라간다

여덟 개와 다섯 개를 전부 늘어놓고 나서, 주기를 다시 봤다. 5분, 10분, 15분, 30분, 매시간, 하루 네 번, 하루 세 번, 새벽 세 시, 일요일 아홉 시. 5분에서 일주일까지 자릿수가 다섯 개나 되니 처음엔 어지러워 보였는데, 5분짜리 동기화와 일주일짜리 점검 사이에 싸고 자주 필요한 일과 비싸고 드문 일이 차례로 늘어서 있다는 걸 알고 나니 패턴이 눈에 들어왔다. 다시 보니 여덟 개와 다섯 개는 결국 하나의 파이프라인이고, 열세 개가 각자 도는 것처럼 보여도 모두 한 줄의 동기화에 매달려 있다. 매달려 있는 만큼, 한 곳이 늦어지면 아래로 전부가 늦어진다.

 

자주 도는 것들은 하나같이 싸다. 동기화는 파일을 복사하는 일이고, 캘린더와 그룹웨어는 긁어오는 일이니, 몇 분에 한 번씩 돌려도 부담이 없다. 반대로 비싼 것들은 길게 뒀다. 동기화가 5분이고 드라이브가 새벽 세 시인 이유는, 그 작업이 하루에 몇 번 필요한지와 한 번에 얼마나 비싼지가 정하는 것이다. 문서당 70초짜리 합성은 정각마다, 문서 2만 개짜리 드라이브는 하루 한 번 새벽에, 점검은 일주일에 한 번. 캘린더와 그룹웨어의 주기는 사람이 일하는 시간표에서 나왔고, 합성과 색인의 주기는 문서 한 장을 만드는 비용에서 나왔다. 다이제스트가 저녁 일곱 시와 아침 여덟 시에 도는 것도, 그 시간에 읽는 사람이 있기 때문이다. 기계라면 새벽 두 시에 돌려도 아무 상관이 없다.

 

이걸 하나의 주기로 통일했다면 어땠을까. 싼 일은 필요 이상으로 늦어지고, 비싼 일은 필요 이상으로 자주 돌았을 것이다. 주기를 작업의 단가에 맞추는 것, 이게 이 파이프라인에서 가장 쓸모있던 판단이었다. 그리고 그날 밤, 나는 여덟 개면 충분하다고 생각했다. 그 생각이 틀렸다는 걸 알게 되는 데는, 몇 주가 걸리지 않았다.

그리고 이주 뒤

여덟 개가 끝이 아니었다. 6월 중반까지 세 개가 더 붙었다. 메뉴바 회의 녹음기는 버튼이 눌릴 때 도는 트리거 방식이고, 정리 작업은 매일 새벽 세 시, 논문 리캡은 매주 월요일 아홉 시다. 트리거와 일 단위와 주 단위로 세 개가 또 제각각이었는데, 늘어난 만큼 주기의 자릿수도 같이 늘어났다. 정리 작업은 처리된 원본을 보관함으로 옮기고 30일이 지나면 지우는데, 첫 실행에서 단체 메일 160건이 아카이브로 갔다. 789에서 629로.

 

그중 첫 번째, 메뉴바 회의 녹음기가 다음 편이다. 버튼 하나로 시작과 끝을 기록하고, 노트북 뚜껑을 닫으면 자동으로 저장하는 앱이다. 녹음을 받는 방식을 두고 이상한 실패를 겪었는데, ffmpeg 을 쓰면 안 되는 이유가 거기서 나온다. 여덟 개로 시작해 열한 개가 된 파이프라인, 이제 하나씩 들어가 보자.