나만의 AI 업무 시스템 만들기 2. 대화가 끝난 뒤에도 남아야 할 기록

비서 화면을 닫았다 다시 열면 하던 일이 남아 있을까요. 처음에는 세션이 유지되는지를 물었습니다. 비서를 만들면서는 질문을 조금 나누게 됐습니다. 대화가 다시 보이는지, 저장한 문서를 읽을 수 있는지, 중단된 요청의 결과를 알 수 있는지는 각각 확인할 일이었습니다.

그 출발점은 작은 메모 시험이었습니다. 이 글에서는 당시 확인한 결과와 2026년 9월 28일 현재 검토 중인 기록 구조를 구분해 정리합니다. 목표는 대화를 끝없이 보존하는 데 있지 않습니다. 다음 요청이 무엇을 읽고 어디를 고칠지 알 수 있게 하는 것입니다.

메모를 다시 읽는 시험부터

9월 11일 맥의 로컬 비서에서 시험용 메모를 비서 전용 위키에 저장했습니다. 그 내용을 읽은 뒤, 요청을 처리하는 Gateway 서비스를 재시작하고 새 대화에서 같은 메모를 찾도록 했습니다. 새로운 대화에서도 파일에 남긴 내용을 다시 읽을 수 있었습니다.

확인한 것은 저장된 파일의 재조회였습니다. 백업 파일을 복원한 시험도, 맥 전원을 껐다 켠 시험도 아니었습니다. 처리 중이던 작업이 모두 자동으로 재개된다는 결과로 넓힐 수는 없습니다.

그래도 이 시험은 다음 질문을 정하는 데 도움이 됐습니다. 이전 대화의 모든 문장을 알고 있어야만 일을 이어갈 수 있는 것은 아니었습니다. 다음 판단에 필요한 내용이 파일에 있고, 비서가 실제로 그 파일을 찾아 읽는다면 새 대화에서도 참고할 수 있었습니다.

여기서 말하는 위키는 제가 근거와 절차를 정리해 둔 문서입니다. 제품이 보관하는 대화 기록이나 메모리 파일과 위키를 같은 것으로 부르지는 않으려 합니다. 파일이 남아 있는지와 이번 답변이 그 파일을 읽고 만들어졌는지도 따로 봐야 합니다.

소개 글 하나를 고칠 때 생기는 기록

어떤 정보를 남겨야 할지 생각할 때는 작업 하나를 놓고 보는 편이 분명했습니다. 개인 프로젝트 회의에서 “금요일까지 소개 글을 고친다”고 정했다고 가정해보겠습니다. 아래는 실제 운영 결과가 아닌 설계 설명용 예시입니다.

정보	기준으로 삼으려는 기록	다시 확인할 질문
왜 소개 글을 고치기로 했는지	위키의 회의록과 결정 문서	어떤 논의와 근거가 있었나
고칠 소개 글의 내용	해당 글 원본	지금 수정할 문서는 어느 것인가
누가 언제까지 하고 현재 어디까지 했는지	할 일을 관리하는 업무 DB	아직 해야 하는 일인가
AI에게 어떤 수정을 맡겼고 결과가 무엇인지	요청·진행·결과를 잇는 작업 기록	어느 결과에서 이어서 작업할 것인가

회의록에는 당시의 결정이 남습니다. 그 뒤 소개 글의 수정이 끝났다면 현재 할 일 상태가 달라집니다. 회의록의 과거 문장을 고쳐 완료 상태를 관리할 필요는 없습니다. 현재 상태를 관리할 기록과 당시 논의를 보존할 문서가 서로 연결되면 됩니다.

소개 글 본문도 비서 폴더에 복제해 양쪽에서 고치지 않으려 합니다. 원본 위치를 연결하고, 상태를 요약했다면 언제 확인했는지를 함께 남겨야 합니다. 원본이 수정됐는데 예전 요약만 읽고 답하면 잘못된 다음 일을 제안할 수 있습니다.

이때 기준으로 읽고 고칠 기록을 정본이라고 부를 수 있습니다. 모든 것을 파일 하나에 넣겠다는 뜻은 아닙니다. 글의 내용은 글 원본, 진행 상태는 할 일 기록처럼 정보의 성격에 따라 기준 위치를 정하는 것입니다.

할 일과 시간 약속도 다릅니다

“금요일까지 소개 글 수정”은 마감이 있는 할 일입니다. “금요일 오후 3시 회의”는 특정 시간을 차지하는 약속입니다. 날짜가 들어 있다고 같은 종류의 기록으로 다루면, 아직 끝내지 않은 일과 이미 시간이 지난 약속을 구별하기 어려워집니다.

할 일을 완료했다고 그 결과물이 공개되는 것도 아닙니다. 초안 수정은 끝났지만 검토나 발행이 남을 수 있습니다. 비서가 한 상태를 바꿀 때 어느 업무의 어떤 단계가 끝났는지를 알아야 합니다.

분야별로 위키를 나누는 것만으로 이 문제가 풀리지는 않았습니다. 자료를 찾는 위치와 현재 진행 상태를 바꾸는 위치가 함께 정해져야 했습니다. 그래서 문서 지식과 할 일 상태, AI에게 맡긴 요청을 각각 남기는 구조를 검토하고 있습니다.

업무 DB는 도메인별로 있는 것을 먼저 활용하고 물리적인 통합은 사용 뒤에 판단하기로 했습니다. 다만 9월 28일에는 전체 구조 재검토로 도입 작업도 대기 중입니다. DB가 구현돼 있다는 사실과 실제 업무의 기준 기록이 그곳으로 옮겨졌다는 사실은 구분합니다.

다른 도구에 넘길 때 필요한 것

기록을 나누는 이유는 여러 AI 도구를 쓰려는 요구와도 이어집니다. 블로그 초안 작성을 한 도구에 맡기고 다른 도구에 검토를 요청한다면, 앞선 답변만 복사해서는 부족합니다. 원래 요청과 검토할 문서, 어떤 기준으로 확인할지 함께 전달해야 합니다.

가령 검토자가 읽은 뒤 초안이 수정됐다면 그 검토 결과는 이전 버전에 대한 것입니다. “검토 완료”라는 말만 최신 문서에 붙이면 무엇을 확인했는지 알 수 없습니다. 대상 문서와 결과를 연결해두어야 다음 작업에서 다시 판단할 수 있습니다.

다음 그림은 기록의 역할을 연결하려는 목표입니다. 원본을 고칠 때는 권한과 버전을 확인하는 경로를 거치도록 검토하고 있으며, 실제 운영에 적용하기 전의 설계입니다.

모델이 바뀌어도 같은 생각이나 문장을 재현하려는 것은 아닙니다. 무엇을 요청했고 어떤 결과가 나왔으며 어디서부터 이어서 고칠지를 보존하려는 것입니다. 이를 모으는 공통 작업 기록과 실행 도구의 연결은 아직 구현·검증할 과제입니다.

화면이나 공급사를 고르는 일도 이 요구와 함께 봐야 합니다. 대화가 편리하더라도 결과를 다시 찾기 어렵다면 제 작업에는 부족할 수 있습니다. 반대로 기록을 잘 남긴다고 매 요청에 여러 모델을 동원할 필요는 없습니다.

접수와 반영을 같은 상태로 쓰지 않기

휴대폰에서 메모를 보냈다는 응답을 받았다고 해보겠습니다. 그것이 입력을 받았다는 뜻인지, 위키에 저장을 마쳤다는 뜻인지 구분할 수 있어야 합니다. 나중에 다시 보낼 때 같은 메모가 중복 반영되는지도 확인해야 합니다.

회의록의 내용을 고친 경우도 비슷합니다. 화면에서 저장된 문서와 다른 기기에서 읽는 위키가 같은 상태인지, 전송 중에 문제가 생겼다면 어디에 머물러 있는지 보여야 합니다. 이 연결을 위한 구현 브랜치는 있지만 전체 동기화가 운영에서 이어지는 상태로 확인되지는 않았습니다.

현재는 구조를 재검토하고 있어 특정 동기화 방식이 최종안이라고 쓰기도 이릅니다. 다만 방식이 바뀌어도 확인할 질문은 남습니다. 요청을 받았는가, 기준 기록에 반영했는가, 다른 곳에서 그 결과를 다시 읽었는가입니다.

처음의 메모 시험은 저장한 기록을 다시 읽을 수 있다는 작은 확인이었습니다. 지금은 거기에 무엇을 기준으로 고치고, 어떤 요청의 결과인지 식별할 수 있어야 한다는 조건이 더해졌습니다. 비서의 기억을 평가할 때는 대화가 얼마나 길게 남는지와 함께 이 기록들을 살펴보려 합니다.