개인 업무 비서 만들기 6. 실제 글 몇 개로 시작해 비서를 키우려 합니다

다음 단계에서 비서에게 맡길 대상은 전체 작업 폴더가 아니라 제가 고른 콘텐츠 3~5개입니다. 아직 등록하지는 않았습니다. 블로그와 총괄 역할의 골격을 만든 뒤, 실제 글 몇 개에서 근거를 찾고 다음 행동을 제안하는지부터 확인하려 합니다.

자료가 많이 연결된 모습보다 같은 자료를 보고 제가 납득할 만한 답을 하는지가 먼저입니다. 이 글은 그 작은 시험에서 시작해 분야별 위키와 모바일 입력까지 넓혀갈 계획입니다.

무엇을 읽을지 아는 작은 목록

첫 등록 목록에는 글의 이름만 넣지 않으려 합니다. 실제로 고칠 원본의 위치, 관련 계획 문서, 주제와 별칭, 읽어도 되는 범위, 마지막 확인일을 함께 적도록 설계했습니다.

이 목록은 블로그 전체를 대신하는 새 데이터베이스가 아닙니다. 비서가 우선 찾아볼 입구입니다. 글의 진행 상태를 말할 때는 목록의 오래된 요약만 믿지 않고 실제 원본을 다시 읽어야 합니다.

등록할 때는 서로 비교할 이유가 있는 글을 고르는 편이 좋겠습니다. 예를 들면 초안과 관련된 기존 글, 근거 보완이 필요한 계획을 함께 놓고 볼 수 있습니다. 어떤 글을 실제 대상으로 삼을지는 별도로 선택할 예정입니다.

비슷한 제목보다 같은 질문을 찾기

앞으로 시험할 요청은 ‘이 메모가 어느 글과 비슷한지 알려달라’는 종류입니다. 여기서 비슷함을 제목의 단어가 겹치는 것으로만 판단하면 곤란합니다.

가령 위키를 다룬 두 글이 있다고 해보겠습니다. 하나는 블로그 원본을 관리하는 방법이고 다른 하나는 비서가 지난 결정을 이어 읽는 방법일 수 있습니다. 같은 ‘위키’라는 단어를 쓰지만 독자가 해결하려는 질문은 다릅니다. 이는 조회 기준을 설명하기 위한 예시입니다.

설계한 조회 순서는 요청의 주제와 하려는 행동을 먼저 읽고, 등록 목록에서 후보를 찾고, 실제 원본의 관련 절을 확인하는 방식입니다. 초기 조회는 원본 최대 5개부터 시작하고 충분하지 않으면 더 읽거나 질문하도록 했습니다. 현재는 파일과 목차를 읽는 방식이며 자동 전체 색인이나 벡터 검색이 붙어 있지는 않습니다.

답변에는 관련 문서뿐 아니라 겹치는 결론과 새로 다룰 질문이 나와야 합니다. 등록한 범위에서 찾지 못했으면 그 범위에서 확인하지 못했다고 말해야 합니다. 저장소 전체에 없다고 단정해서는 안 됩니다.

정확성을 확인할 질문

비서가 자신 있게 말하는 정도를 정확성 기준으로 삼지는 않으려 합니다. 제가 원본을 보고 답변을 대조할 수 있어야 합니다. 첫 파일럿에서는 다음과 같은 차이를 확인할 계획입니다.

• 같은 주제이지만 목적이 다른 글을 구별하는지.
• 필요한 근거가 없을 때 새 사실을 만들어 채우지 않는지.
• 날짜 없는 할 일에 임의 마감을 붙이지 않는지.
• 같은 요청을 다시 받아도 기록을 중복 생성하지 않는지.
• 저장한 기록을 새 세션에서 다시 읽고 실제 상태를 설명하는지.

특히 답변과 파일 저장을 따로 봐야 합니다. ‘등록했습니다’라는 말이 나왔어도 실제 파일이 없거나 일부 기록만 만들어졌다면 완료가 아닙니다. 여러 파일을 함께 바꾸다가 중단됐을 때 무엇이 저장됐고 무엇이 남았는지도 알려줘야 합니다.

초기 시험용 요청에서는 조회만으로 기록을 만들지 않는 모습을 확인했습니다. 이제 필요한 것은 실제로 저장하는 요청, 실패하는 요청, 다시 보내는 요청까지 넓힌 시험입니다. 이 결과를 보기 전에는 일상 업무를 안정적으로 관리한다고 판단하지 않으려 합니다.

예외를 위키에 반영하는 순서

1편에서 정한 예외 반영 원칙은 실제 기록 양식으로 시험하려 합니다. 아래는 글의 최신성을 검토하는 절차에 개선안을 남기는 가상 예시입니다. 아직 적용하거나 검증한 이력이 아닙니다.

상태: 제안
대상: 기존 글의 최신성 검토
문제 후보: 작성일이 오래됐다는 이유만으로 수정 대상으로 분류할 수 있음
개선안: 제품 기능 설명과 개념 설명을 구분해 확인할 근거를 고르기
확인할 것: 선정한 실제 글에서 수정할 주장과 유지할 주장을 원본과 대조
채택 조건: 적용 결과를 검토하고 내가 재사용할 기준으로 확정
반영 위치: 기존 글 검토 절차의 관련 항목

제안이 나왔다는 이유로 기존 절차를 곧바로 덮어쓰지는 않습니다. 실제 적용 결과와 남은 한계를 사례에 기록하고, 채택한 조건만 원래 위키의 관련 항목에 반영하려 합니다. 나중에 기준을 바꿀 때도 어느 사례에서 나온 판단인지 되짚을 수 있게 하려는 것입니다.

예외 기록이 쌓인다는 것은 AI의 모델 자체가 다시 학습된다는 뜻이 아닙니다. 다음 요청에서 다시 읽을 근거와 처리 기준이 더 나아지는 것을 목표로 합니다. 나중에 검색을 고도화하더라도 사람이 고칠 위키 원본은 유지하려 합니다.

CLI 작업의 끝을 비서가 이어받게 하기

실제 집필과 개발은 계속 Codex CLI에서 진행할 계획입니다. 비서는 목표와 원본 위치, 지켜야 할 규칙, 완료 조건을 정리한 요청서를 만들고, CLI 작업이 끝나면 결과를 확인해 다음 행동을 갱신하도록 연결하려 합니다.

블로그라면 초안을 만든 경로, 어떤 검토를 했는지, 남은 사실 확인이 무엇인지가 필요합니다. 프로그램이라면 변경한 범위와 테스트 결과, 아직 못 확인한 조건이 있어야 합니다. ‘완료’ 한 줄만 넘기면 비서가 공개나 배포까지 끝난 것으로 오해할 수 있습니다.

기존 글쓰기 규칙을 비서용으로 다시 복제할 생각은 없습니다. CLI가 해당 저장소의 지침과 집필·검수 스킬을 읽고 작업하고, 비서는 그 결과를 이어받게 하려 합니다. 저장소에 스킬 파일이 있다고 OpenClaw 대화에 자동 설치되는 것으로 가정하지 않습니다.

보고서와 대시보드도 같은 원칙입니다. 생성 기능은 별도의 개발 작업으로 만들고 검증한 뒤 비서에 연결하려 합니다. 월별 HTML 보고서에는 해당 기간에 확인한 기록과 아직 미완료인 일을 구분해 담고, 집계 기준과 조회 시점을 남길 계획입니다. 현재 보고서 자동 생성이 돌아가는 상태는 아닙니다.

휴대폰과 외부 도구는 그다음 단계

아이폰에서는 메모와 음성을 간단히 남기고 싶습니다. 녹음한 내용을 정리해 위키에 활용하고, 확정한 약속만 총괄 일정에 연결하는 흐름입니다. 이때 맥이 꺼져 있어도 입력을 보관할 영속 수신함이 필요하다는 조건은 그대로입니다.

연결 순서를 현재 계획으로 정리하면 다음과 같습니다.

순서	추가할 기능	그전에 확인할 것
먼저	실제 콘텐츠 조회와 개인 할 일 파일럿	원본 근거, 날짜 해석, 저장·중복·재시작 복구
이어서	요청할 때 보는 오늘·주간 요약	확정 일정과 추천의 구분, 없는 기록을 꾸미지 않기
별도 승인 후	예약 브리핑과 리마인더	실행 시각, 잠자기 중 누락, 재시도와 알림 중복
입력 확장	아이폰 메모·음성·회의록	안전한 접속, 녹음 허용 범위, 전사 조건, 재전송과 반영 상태
연결 확장	개인 메일·캘린더·메신저와 허용된 자료 수집	계정별 최소 권한, 읽기와 쓰기 승인, 수집 가능한 자료 범위
결과 연결	월별 HTML 보고서·분석 대시보드	별도 개발·검증, 집계 원본, 공개 범위와 접근 제한

24시간 실행도 이 단계에서 다시 판단하려 합니다. 꺼진 동안 메모를 접수하는 것과 그 시간에 실제 분석·알림까지 수행하는 것은 비용과 운영 조건이 다릅니다. 새벽에도 일을 처리해야 한다면 상시 실행 장비가 필요하지만, 입력을 보관하고 다음에 처리해도 된다면 구조를 더 작게 잡을 수 있습니다.

다른 사람이 함께 쓰는 확장은 별도 문제로 남깁니다. 역할 이름을 나누는 것만으로 사용자별 자료 접근이 분리되지는 않습니다. 그때는 개인 기록을 누가 볼 수 있는지부터 다시 설계해야 합니다.

다음 완료 기준은 작은 실제 요청입니다

최종적으로는 블로그, 개발, AI 프로젝트와 개인 일정을 연결한 비서를 원합니다. 하지만 다음 구현의 완료 기준은 그 전체 그림이 아닙니다. 선택한 글에서 근거를 찾고, 제가 확정한 다음 행동을 정확히 남기고, 새 세션에서 다시 이어갈 수 있는지입니다.

이 작은 흐름이 맞으면 같은 원칙으로 위키를 하나씩 추가하려 합니다. 자비스라는 목표는 유지하되, 그 방향으로 잘 가고 있는지는 실제 글 몇 개와 할 일 몇 건으로 확인해볼 생각입니다.