4일차 글의 마지막 문장은 이거였다. "남은 3일 동안 확인하고 싶은 건, 이 작은 연결이 계속해서 내 하루를 다음 하루로 이어주는지다." 그 3일이 마저 지나갔고, 오늘로 1주일 실사용 검증이 끝난다.
그런데 정작 이 글을 쓰려고 앉은 오늘 아침, TouchMemory 알림이 안 왔다. 순간 "일주일 다 채우고 마지막 날 사고냐"는 생각이 먼저 들었는데, 확인해보니 원인은 어이없을 만큼 단순했다. 어젯밤 내가 직접 갤럭시(Termux)의 화면 잠금 방지(wakelock)를 꺼버려서 백그라운드 프로세스가 죽어 있었던 거다. ./run.sh 한 번 다시 실행하니 바로 살아났고, 지연된 알림도 곧이어 도착했다. 이건 설계나 코드의 결함이 아니라 내가 환경 설정을 잘못 건드린 사고였다. 그래서 이 구간은 이번 회고의 "정상 사용 패턴"에서 따로 떼어 놓고, 뒤에서 별도로 짚는다.
7월 5일부터 오늘까지 갤럭시 DB에 쌓인 usage_events는 165건, 등록된 기억(memory_items)은 26건이다.
채널별로는 Discord 90건, Claude Code CLI 55건, system(자동, 주로 알림) 20건이었다. 행위별로는 조회(view) 94건, 등록(register) 37건, 완료(complete) 25건, 알림(notify) 9건. 하루 단위 활동량은 60 → 31 → 9 → 18 → 20 → 11 → 11 → 5로, 극적인 반등 없이 완만하게 줄어드는 모양이었다(마지막 5는 오늘 아침 사고 구간을 포함한 부분 집계다).
완료율은 76.9%(20/26)였다. 미완료로 남은 6건은 전부 "다음 버전에 반영해볼 만한 힌트"성으로 일부러 완료 처리하지 않고 남겨둔 것들이라, 미완료율을 곧바로 관리 실패로 읽을 수 없다.
시간대로 보면 저녁 17시와 20시에 뚜렷한 피크가 있었고, 00~02시 새벽대에도 활동이 이어졌으며, 08시는 매일 확인하는 시간대로 별도 피크를 이뤘다.
이 숫자들을 그냥 나열하는 것보다 흥미로웠던 건, 4일차 때 이미 느꼈던 패턴이 숫자로 그대로 찍혀 있었다는 점이다.
17시 피크는 그날 계획한 일이 끝나는 시점에 완료 처리가 몰리는 시간이었고, 20~21시는 그날 마무리 못한 잔업을 정리하면서 동시에 내일 할 일을 새로 등록하는 시간이었다. 이건 예상하고 설계한 사용 방식이 그대로 숫자로 확인된 경우라, 굳이 확인하지 않아도 될 걸 확인한 느낌이었지만 그만큼 편안했다 — 예상한 대로 쓰게 됐다는 뜻이니까.
00~02시 새벽대 활동도 마찬가지였다. 늦게까지 작업하다 완료 처리를 남기고 잠드는 패턴은 4일차 글에서 이미 적었던 그대로였고, 이번 7일 전체에서도 똑같이 반복됐다.
7월 7일이 유독 활동량이 적었던 날(9건)은 처음엔 시스템 문제인가 싶었는데, 그날 일정을 다시 보니 이유는 단순했다. 그날은 채용 면접이 있던 날이었다. 하루 종일 다른 일에 시간과 신경을 쓴 날이라 TouchMemory를 건드릴 시간 자체가 없었던 거다. 데이터가 시스템 결함 없이 내 삶에 그대로 반응하고 있다는 걸 보여주는 사례라고 생각한다.
Claude Code에게 "오늘 뭐 있어?" 류의 질문을 던진 게 이번 주 세션 로그에 4번 있었는데, 전부 CLAUDE.md 라우팅을 거쳐 TouchMemory CLI로 정확히 연결됐다. 다만 이걸 "TouchMemory에 의존하게 됐다"는 뜻으로만 읽으면 정확하지 않다. 이 4번의 질문은 사실 지난 글에서 다룬 라우팅 실패(공방 루트에서 세션을 열면 엉뚱한 기록을 뒤지던 사고) 이후, 그 수정이 실제로 계속 잘 작동하는지 내가 직접 확인해본 질문들이었다. 편의를 누린 흔적이라기보다 검증을 위해 내가 일부러 던진 질문에 가깝다.
Discord 채널 사용량(90건)이 Claude Code(55건)보다 많은 것도 체감과 맞았다. 그런데 이걸 "폰으로는 Discord, 맥북에서는 Claude Code"로 단순 도식화하면 틀린다. 실제로는 맥북 앞에 앉아 있으면서도 Discord 앱으로 완료 처리를 한 경우가 꽤 있었다. 채널 선택은 기기가 아니라 그 순간 뭘 열어두고 있었는지에 더 가까웠다.
4일차 글에서 "카르테" 설계 재개 알림 얘기를 적으면서, 끊길 뻔한 사고의 흐름이 다시 이어진 경험이라고 썼다. 7일을 다 채우고 다시 돌아보니, 그때 표현이 실제 체감보다 약했다는 걸 인정해야겠다.
그건 "맥락을 찾는 데 도움이 됐다" 정도가 아니었다. 알림에 뜬 한 줄을 보고 나서야, 내가 전날 그런 생각을 했었다는 사실 자체를 몰랐다는 걸 깨달았다. "내가 이런 기록을 남겼던가?" 하고 되묻는 순간이 있었고, 그 한 줄을 따라가면서 전날 하루 전체가 통째로 다시 떠올랐다. 부분적으로 기억을 되찾은 게 아니라, 잊었다는 사실 자체를 몰랐던 하루가 통으로 재발견되는 경험에 더 가까웠다. 이번 주를 통틀어 가장 예상하지 못했던 지점이 여기였다.
오늘 아침 알림 미발송은 앞서 적었듯 설계 결함이 아니라 운영 실수였다. 어젯밤 wakelock을 직접 꺼서 백그라운드 프로세스가 죽었고, ./run.sh 재기동으로 즉시 복구됐으며, 지연된 알림도 뒤늦게 도착하는 걸 확인했다. 이 구간은 "정상 사용 패턴"이 아니라 "장애 구간"으로 따로 분리해서 본다 — 그렇지 않으면 마지막 날의 우연한 사고 하나가 7일 전체의 안정성 판단을 왜곡할 수 있다.
이번 주를 마치면서 코드를 다시 살펴보니, CLI에는 완료 처리 명령 자체가 없다는 걸 확인했다. cli/main.py에 주석으로 남겨둔 확장 지점이 있는데, "완료 처리(--done)는 이번 MVP 범위 아님(구현 안 함)"이라고 아예 적혀 있었다. 아쉬운 지점이긴 했지만, 완료 처리가 필요할 때는 맥북에서도 Discord로 넘어가면 됐기 때문에 실사용에 치명적이지는 않았다.
이번 주 중에 새로 든 생각도 하나 있다. 당일 처리할 기억과 오래 붙잡고 있어야 할 기억을 공간적으로 분리하고 싶다는 아이디어다. 다만 이건 이번 주에 처음 떠오른 1회성 생각이라, 아직 반복해서 검증된 요구는 아니다. 다른 백로그 항목들과 같은 무게로 다루지 않으려 한다.
이 판단들을 종합해서, V2는 지금 바로 착수하지 않기로 했다. 재개 시점도 날짜가 아니라 조건으로 정했다 — 같은 불편함(완료 처리 명령 부재, 기억 공간 분리 필요성)을 몇 번 더 반복해서 느끼거나, 회사 인스턴스 운영이 안정된 이후로 미뤘다. 이건 요즘 따로 설계하고 있는 "카르테"에서 세운 Core/Instance 승격 원칙 — 아직 검증되지 않은 아이디어를 공식 구조로 성급히 승격하지 않는다는 원칙 — 을 V2 착수 판단에 그대로 가져다 쓴 결정이다.
설계할 때 세운 문장은 "기억은 저장하는 것만으로 부족하다. 다시 건드려야 한다"였다. 7일치 데이터와 체감을 나란히 놓고 보니, 이 가설은 극적인 반전 없이 그대로 유지됐다. 저녁 완료 처리, 등록 패턴, 새벽 마무리 습관 — 4일차 때 예상한 만큼의 효과가 7일 내내 반복됐다. 유일하게 예상을 넘어선 지점은 카르테 재발견 사례였고, 유일하게 걸린 지점은 마지막 날 아침의 환경 설정 실수였다.
지금은 기능을 더 늘리기보다, 이 정도로 확인된 걸로 충분하다고 판단했다. V2는 트리거가 생기면 그때 다시 연다.
이번 7일은 TouchMemory를 검증한 기간이었다. 다음 검증은 기능이 아니라, 다른 환경에서도 같은 패턴이 반복되는지를 확인하는 과정이 될 것 같다.
