개인 업무 비서 만들기 3. 창을 닫아도 이어지는 기억 만들기

웹 UI가 생긴 뒤에도 질문은 끝나지 않았습니다. 화면을 닫았다 열면 세션이 없어지는지, 내부 웹서버를 껐다 켜면 어떻게 되는지, 컴퓨터를 꺼도 유지되는지 연이어 물었습니다. 비서를 계속 쓰려면 편한 입력창만큼이나 하던 일이 남는지가 중요했습니다.

이 질문들은 비슷해 보이지만 서로 다른 부분을 가리킵니다. 화면, 실행 중인 서비스, 컴퓨터의 전원, 파일에 저장한 기록을 나누어 보니 무엇을 확인해야 하는지 정리할 수 있었습니다.

닫는 대상에 따라 달라지는 것

브라우저는 비서에게 말을 거는 화면입니다. 실제 요청을 처리하는 Gateway가 별도 서비스로 떠 있다면 브라우저 탭을 닫는 일이 곧 그 서비스를 종료하는 일은 아닙니다.

터미널도 마찬가지입니다. 터미널에서 프로그램을 직접 실행해둔 상태와 운영체제의 서비스로 등록한 상태는 다릅니다. 제 맥에서는 OpenClaw를 개인용 LaunchAgent로 구성해 CLI 창의 실행과 분리했습니다. 터미널을 계속 열어두는 방식에서 벗어나려는 선택이었습니다.

현재 구성을 기준으로 구별하면 이렇습니다.

멈추거나 닫는 대상	다시 사용할 때 필요한 것	따로 확인해야 할 점
브라우저 탭	실행 중인 서비스에 다시 접속	인증과 기존 세션 선택 상태
CLI 창	별도 서비스가 살아 있으면 UI 접속	직접 실행한 프로세스와 서비스 실행의 구별
Gateway 서비스	같은 프로필과 저장 위치로 재시작	중단된 작업의 성공 여부와 기록 복구
맥 전원 또는 잠자기	장비가 돌아오고 서비스가 실행되어야 함	재로그인 후 시작과 작업 재개 정책

컴퓨터가 꺼진 동안 로컬 비서가 새 요청을 처리할 수는 없습니다. 디스크에 저장한 파일이 남는 문제와, 그 시간에도 계속 일하는 문제는 분리해야 합니다. 진행 중이던 요청이 중단됐다면 마지막 답변만 보고 성공했다고 판단하지 않고 실제 산출물을 확인해야 합니다.

다시 읽을 수 있다는 것을 시험했습니다

설치 후에는 실제 개인 자료 대신 시험용으로 만든 메모로 저장과 복구를 확인했습니다. 개인 위키에 그 내용을 쓰고 다시 읽은 뒤, Gateway를 재시작하고 별도의 새 세션에서 같은 내용을 찾도록 했습니다. 새 세션에서 저장한 메모를 다시 읽을 수 있었습니다.

이 시험에서 확인한 것은 파일에 남긴 기록을 서비스 재시작 뒤에도 활용할 수 있다는 점입니다. 맥 전원을 실제로 껐다 켜는 전체 시험이나, 처리 중인 모든 작업의 자동 복구까지 확인한 것은 아닙니다. 그 범위를 나누어 기록했습니다.

저에게 중요한 부분은 새 대화가 이전 대화의 모든 문장을 기억했는지가 아니었습니다. 확인해두어야 할 내용이 파일에 남았고, 새로운 대화가 그 파일을 근거로 다시 이어갈 수 있는지가 더 중요했습니다.

대화 기록과 위키의 역할

OpenClaw의 공식 메모리 문서는 워크스페이스의 Markdown 파일에 내용을 기록해 기억을 유지하는 방식을 설명합니다. 파일로 보존하는 구조를 모델이 모든 과거 대화를 무제한으로 알고 있다는 뜻으로 받아들이면 안 됩니다.

저는 비서에 남길 기록도 성격에 따라 나눠 생각했습니다. 대화는 왜 그 이야기가 나왔는지 보여주고, 작업 이력은 무엇을 했는지 남기고, 위키는 다음에 따를 방법을 정리합니다.

블로그 글 하나를 예로 들면 차이가 보입니다. 대화 중에는 제목을 여러 개 제안하고 방향도 바꿀 수 있습니다. 작업 이력에는 어떤 원본을 읽고 초안을 어디에 만들었는지 남길 수 있습니다. 위키의 작성 기준에는 그중 다음 글에서도 적용할 검토 방법을 정리합니다. 모든 제목 후보를 영구 규칙으로 저장할 필요는 없습니다.

세션이 길어질수록 같은 정보가 모두 똑같이 중요하지는 않습니다. 앞으로 다시 읽을 판단과 잠깐 검토한 아이디어를 구별해야 기록이 쌓여도 쓸 수 있을 것 같습니다.

같은 사실을 두 군데서 고치지 않기

개인 비서가 기존 블로그 위키를 읽기 시작하면 또 다른 문제가 생깁니다. 비서가 ‘이 글은 검토 중’이라고 따로 저장했는데 원본 쪽에서는 수정이 끝날 수 있습니다. 두 기록이 다를 때 무엇을 믿을지 정해야 합니다.

그래서 글의 내용과 작성 상태는 기존 글 원본을 우선하도록 설계했습니다. 개인 비서는 그 문서의 위치를 연결하고, 상태를 요약해 남길 때는 언제 확인한 정보인지 표시합니다. 블로그 본문 전체를 비서 폴더에 복제해 두고 양쪽에서 고치는 방식은 피하려 합니다.

반면 ‘이번 주에 이 글을 다시 검토하기’ 같은 개인 할 일은 비서의 일정 기록에 둡니다. 글의 내용과 제가 그 글에 들일 시간은 다른 정보이기 때문입니다. 글이 수정됐다고 제 일정이 자동으로 끝나는 것도 아니고, 개인 할 일을 완료했다고 글이 공개되는 것도 아닙니다.

이 구분 덕분에 비서가 무엇을 기억해야 하는지 더 구체적으로 적을 수 있었습니다. 원본을 대신하는 복사본이 아니라, 원본의 위치와 제가 결정한 다음 행동을 남기려는 것입니다.

꺼진 컴퓨터에 보낼 메모는 어디에서 기다릴까

아이폰에서 음성이나 메모를 남기고 맥이 켜진 뒤 위키에 반영하는 방식도 원했습니다. 이 요구는 세션 유지에서 한 단계 더 나아갑니다. 맥이 응답하지 않는 동안에도 입력을 잃지 않고 보관할 장소가 필요합니다.

휴대폰이나 별도 서비스가 입력을 저장했다면 ‘접수됨’과 ‘위키에 반영됨’을 구분해야 합니다. 나중에 다시 보낼 때 같은 메모가 두 번 반영되지 않는지도 확인해야 합니다. 브라우저에 입력 중인 글이 보인다는 사실만으로 이런 저장과 재전송을 보장할 수는 없습니다.

현재 제 구성에는 이 모바일 수신함이 없습니다. 휴대폰 녹음, 전사, 재전송, 위키 반영은 별도 구현 대상으로 남겨두었습니다. 처음부터 24시간 서버를 빌리는 대신, 어떤 입력을 어디에서 기다리게 할지부터 정하려 합니다.

저장할 기억을 정하는 일

비서를 껐다 켜도 이어서 쓰고 싶다는 질문은 결국 어떤 상태를 보존할 것인지의 질문으로 바뀌었습니다. 대화창이 다시 보이는 것만으로는 부족하고, 중요한 결정이 파일에 남았는지도 확인해야 합니다.

지금까지는 시험용 메모를 저장하고 새 세션에서 다시 읽는 데 성공했습니다. 다음에는 실제 콘텐츠와 할 일을 등록한 뒤 같은 기준으로 확인해야 합니다. 백업에서 복원하는 절차도 저장 기능과는 별도로 점검할 예정입니다.

제가 원하는 기억은 이전 대화를 끝없이 늘어놓는 능력보다, 오늘의 비서가 어제 확인한 기록을 찾아 읽을 수 있는 상태에 가깝습니다.

참고자료

• OpenClaw Memory overview