다 읽어야 '세컨드 브레인'이 된다는 착각: 주간 리뷰 루틴과 슬랙 알림까지

인제스트 대기열에 새 글 열 편이 들어와 있었습니다. 그중 하나가 개인 블로그에 올라온 짧은 글이었는데, 제목부터 눈에 걸렸습니다. PKM을 사용할 때 AI에게 요약과 링크를 맡기면 ‘본유적 부하’(germane load), 즉 스키마를 만드는 데 필요한 좋은 인지 부하까지 같이 사라진다는 내용이었습니다. 노트를 연결하는 과정 자체가 장기기억을 인출하고 다시 부호화하는 과정인데, AI가 대신 연결해 주면 그래프 뷰는 예뻐져도 제 머릿속에는 아무것도 남지 않는다는 지적이었습니다.

요약을 쓰다 말고 잠깐 멈췄습니다. 이건 남 얘기가 아니었습니다.

이 프로젝트를 시작한 뒤로 제가 직접 읽어본 위키 페이지가 몇 개나 될지 세어봤습니다. 블로그 포스트 아이디어와 synthesis 문서 몇 개를 빼면 거의 없었습니다. 128개 페이지 대부분은 제가 링크를 걸어본 적도, 다시 열어본 적도 없는 페이지였습니다.

이 글에서는 그 순간부터 시작된 대화가 어떻게 ’주간 리뷰’라는 새 워크플로우로, 그리고 그걸 제가 잊어버릴 경우를 대비한 슬랙 알림 루틴으로 이어졌는지 정리해보겠습니다.

걱정은 근거가 있었다

멈춰서 생각해보니 걱정할 만한 이유가 있었습니다. 지금 이 위키는 인제스트 파이프라인이 소스를 읽고, 등급을 매기고, 요약을 쓰고, 필요하면 위키 페이지까지 만듭니다. 저는 그 결과를 승인하는 역할이었습니다. 승인은 했지만 내재화는 하지 않은 셈입니다.

PKM이 ’세컨드 브레인’으로 기능하려면 실제 제 뇌의 확장이 되어야 하는데, 링크도 요약도 전부 AI가 만든 것이라면 그건 제 뇌가 아니라 인터넷 어딘가에 있는 자료와 다를 게 없어집니다. 노트는 제 이름으로 되어 있지만 실제로는 제 것이 아니게 되는 셈입니다.

그런데 시간이 없다는 것도 사실이다

문제는 이 걱정을 해결하겠다고 128개 페이지를 전부 다시 읽을 시간이 없다는 점입니다. 하루에 낼 수 있는 시간은 한 시간 남짓입니다. 완벽하게 내재화하겠다고 덤비면 결국 아무 페이지도 다시 열어보지 못한 채 이 워크플로우 자체를 그만두게 될 가능성이 큽니다.

그래서 대화의 방향을 “AI 개입을 줄이는 법”에서 “어디에만 제 시간을 쓸지 정하는 법”으로 옮겼습니다.

매주 3~5개로 범위를 좁히다

전체 위키를 대상으로 하지 않기로 했습니다. 대신 다음 조건을 모두 만족하는 페이지만 매주 3~5개 골라 보여주는 새 워크플로우를 만들었습니다.

조건	기준
레버리지가 높은 페이지	근거 소스가 T1/T2 등급이거나, type: synthesis 페이지이거나, 요약 파일에 resonance: high가 달린 경우
아직 제가 관여하지 않은 페이지	새로 추가한 daniel_reviewed 필드가 no이거나 비어 있는 경우

T3/T4 등급의 대량 레퍼런스성 소스는 이 대상에서 아예 뺐습니다. 이런 소스까지 언젠가 제가 직접 내재화할 것처럼 취급하는 게 오히려 정직하지 않다고 판단했습니다. 그런 자료는 AI가 관리하는 참고 자료로 남겨두고, 제 시간은 실제로 제 판단이 들어가야 하는 소스와 synthesis 문서에 쓰기로 했습니다.

결과물은 meta/weekly-review-queue.md에 매주 날짜별로 쌓입니다. 지운 적 없는 append-only 로그라 특정 페이지가 몇 주째 계속 밀리고 있는지도 나중에 눈에 보입니다.

잊어버릴 걸 각오하고 안전장치를 만들다

여기까지 정리하고 나니 다른 질문이 생겼습니다. 이 주간 리뷰도, 이미 있던 월간 린트도, 결국 제가 먼저 요청해야 실행되는 구조입니다. 제가 깜빡하면 그걸로 끝입니다.

세션 안에서 도는 예약 작업(cron)을 먼저 떠올렸지만 두 가지 한계가 있었습니다. 세션이 꺼지면 같이 사라지고, 그렇지 않더라도 7일이 지나면 자동으로 만료됩니다. 일주일에 한 번 저에게 알려주는 용도로는 애초에 맞지 않는 도구였습니다.

대신 claude.ai에 등록하는 예약 클라우드 루틴을 썼습니다. 이쪽은 세션과 무관하게 독립적으로 돌아갑니다. 다만 이 루틴이 저에게 실제로 말을 걸려면 채널이 있어야 했는데, 이 프로젝트에는 연결된 MCP 커넥터가 하나도 없었습니다. 슬랙을 이 프로젝트용으로 새로 연결한 뒤에야 루틴이 제 슬랙 DM으로 메시지를 보낼 방법이 생겼습니다.

루틴이 하는 일은 단순합니다. 매주 월요일 오전 9시, meta/weekly-review-queue.md에서 가장 최근 날짜를 확인하고, 그 날짜가 7일 이상 지났거나 아예 기록이 없으면 슬랙 DM 한 통을 보냅니다. 아직 7일이 안 지났으면 아무것도 보내지 않습니다. 매주 알림이 오는 게 아니라, 정말 밀렸을 때만 옵니다.

처음 실행했더니 바로 막혔다

루틴을 만들어놓고 바로 실행해봤습니다. 만들어만 두고 월요일까지 기다렸다가 안 되는 걸 확인하는 것보다는 지금 확인하는 게 낫다고 판단했습니다.

첫 실행은 곧바로 실패했습니다. 깃허브 저장소 접근 권한 확인에서 막혔습니다. 재인증을 하고 다시 돌렸는데 똑같은 오류가 그대로 나왔습니다. 재인증 자체는 됐지만, 그 앱이 이 저장소에 접근할 수 있는 저장소 목록에는 여전히 포함되어 있지 않았던 것입니다. 저장소 단위 권한을 별도로 추가하고 나서야 세 번째 시도에서 정상적으로 실행됐고, 슬랙 DM도 실제로 도착했습니다.

지금 이 큐 파일에는 아직 ‘## Week of’ 항목이 하나도 없는 상태라, 이번 실행은 알림이 뜨는 조건에 정확히 해당했습니다. 우연히 딱 맞는 조건에서 처음 실행해본 덕분에, 알림이 실제로 오는 경로까지 한 번에 확인할 수 있었습니다.

결론: 경계는 한 번 정하고 끝낼 문제가 아니다

이번 작업으로 걱정이 사라진 건 아닙니다. 128개 페이지 대부분은 여전히 제가 직접 내재화하지 않은 AI의 요약으로 남아 있습니다. 다만 그 사실을 숨기지 않고, 어디까지가 제 몫이고 어디부터는 AI에게 맡겨도 되는지 경계를 분명히 그은 것에 의미가 있다고 생각합니다.

이 경계가 제대로 작동하는지는 이번 한 번의 성공적인 실행이 아니라, 몇 주 뒤에도 이 알림을 실제로 열어보고 있는지로 판단해야 할 것 같습니다. 다음 월요일에 알림이 다시 울릴 때, 그걸 클릭해서 실제로 페이지 서너 개를 읽고 있을지 지켜볼 필요가 있습니다.