개인 업무 비서 만들기 5. 블로그와 총괄 비서의 첫 골격을 만들었습니다

첫 구현 뒤 새 세션에서 오늘 할 일을 조회하는 시험을 했습니다. 비서는 등록된 기록이 0개라는 결과를 말했고, 새 할 일이나 약속 파일을 만들지 않았습니다. 아직 맡긴 일이 없는 상태에서 그럴듯한 하루 계획을 만들어내지 않는지부터 확인한 것입니다.

2026년 9월 11일 기준으로 맥의 OpenClaw에는 블로그·콘텐츠 역할과 일정·우선순위 총괄 역할의 골격이 들어갔습니다. 실제 등록한 콘텐츠와 할 일, 약속은 모두 0개입니다. 기존 블로그가 비어 있다는 뜻이 아니라 비서의 관리 대상을 아직 넣지 않았다는 뜻입니다. 이번 첫 구현에서는 이 기본 구조와 새 세션의 역할 이해까지를 완료 기준으로 잡았습니다.

설계를 실행 순서로 바꿨습니다

전체 비서 설계에서 제가 먼저 선택한 것은 블로그와 총괄 역할이었습니다. 개발 프로젝트 전문 비서와 외부 도구 연결까지 함께 구현하지 않고, 이 두 역할의 상세 설계서를 작성한 뒤 Codex와 구현을 진행했습니다.

상세 설계에서 기존 환경 확인과 공통 구조 추가를 첫 단계로 잡았습니다. 그다음에 실제 콘텐츠 연결, 일정 운영, CLI 인수인계, 파일럿 검증을 이어가도록 순서를 정했습니다.

이미 동작하던 로컬 UI와 인증을 다시 만드는 일은 하지 않았습니다. 기존 설정, 모델 선택, 서비스와 파일 접근 범위를 유지하면서 역할 문서와 개인용 기록 양식을 추가했습니다. 새 기능의 영향 범위를 작게 두고 무엇이 달라졌는지 확인하려는 선택이었습니다.

먼저 만든 것은 역할과 기록의 자리입니다

단일 main 안에서 총괄 역할은 전체 일정과 우선순위를 보고, 블로그 역할은 콘텐츠 문서와 다음 집필 행동을 보도록 지침을 나눴습니다. 역할 문서가 있다는 사실만으로 자동 실행되는 것으로 가정하지 않고, 시작 지침에서 필요한 문서를 읽도록 연결했습니다.

기록도 종류별로 자리를 마련했습니다. 아래는 처음 추가한 구조를 설명한 것이며 실제 자료가 채워진 목록은 아닙니다.

기록	여기에 남기려는 내용
콘텐츠 등록 목록	비서가 살필 글과 계획의 원본 위치, 주제, 열람 범위
할 일·약속	개인 작업의 상태와 마감, 확정된 시간 약속
수신함·브리핑	아직 정리할 입력과 특정 시점에 확인한 요약
인수인계	CLI에 넘길 요청과 완료 후 돌려받을 결과
사례·개선 제안	확인한 예외와 아직 채택하지 않은 처리 방법

글 본문을 여기에 복사하지는 않았습니다. 실제 집필과 수정은 기존 위키에서 진행하고, 비서 쪽에는 원본을 가리키는 위치와 개인 행동 기록을 둡니다. 그 원칙을 지키기 위한 양식부터 만든 것입니다.

빈 구조를 검사할 때도 그 단계에 맞는 조건을 사용했습니다. 초기 검사에서는 실제 기록이 없는지 확인하지만, 나중에 콘텐츠를 등록한 뒤에도 계속 0개를 요구하면 정상 상태를 오류로 볼 수 있습니다. 그래서 빈 상태 확인은 첫 골격 단계에만 적용하도록 구별했습니다.

파일이 있는지와 실제로 읽는지는 달랐습니다

새 세션에서도 제가 정한 역할과 조회 기준을 찾는지 물었습니다. 총괄이 상위이고 블로그가 하위라는 답만으로 끝내지 않고 실제 역할 파일 조회 기록도 확인했습니다.

비서는 두 역할 문서를 읽고, 우선순위 규칙의 마지막 항목인 ‘장기 방치’와 첫 콘텐츠 조회에서 원본을 최대 5개부터 살피는 기준을 답했습니다. 현재 등록이 0개이고 외부 캘린더나 자동 의미 색인이 연결되지 않았다는 점도 구분했습니다.

이와 별도로 필수 문서와 항목, 기존 양식의 유지 여부를 검사하고 설정과 서비스 상태도 확인했습니다. 파일 배치 검사는 문서가 마련됐는지 보여주고, 새 세션의 조회 시험은 비서가 실제로 그 문서를 읽는지 보여줍니다. 두 확인을 구별해 진행했습니다.

이를 통해 새 세션에서도 역할 문서를 읽고 필요한 규칙을 찾는다는 초기 근거를 얻었습니다. 다만 규칙을 설명하는 능력과 실제 자료가 복잡할 때 일관되게 적용하는 능력은 다릅니다. 후자는 다음 콘텐츠 시험에서 봐야 합니다.

읽기만 하는 요청으로 확인한 것

첫 일정 시험에는 실제 약속 대신 시험용 요청을 사용했습니다. 실제 기록이 만들어지지 않는 조건에서 요청을 어떻게 이해하는지 확인했습니다.

‘2026-09-12까지’처럼 날짜만 있는 마감은 시각이 정해진 약속이 아니라 날짜 마감의 할 일로 구분했습니다. ‘오늘 할 일’을 조회했을 때는 기록이 0개라는 결과를 말했고 새 할 일이나 약속 파일을 만들지 않았습니다.

‘다음 주 중’이라는 모호한 표현에는 날짜와 시간을 확인하는 응답이 나왔고 파일을 쓰지 않았습니다. 여기에는 추가 시험이 필요합니다. 단순히 언젠가 검토하고 싶다는 말을 처음부터 시간 약속으로 해석하지 않는지도 봐야 하기 때문입니다. 확인 질문이 나왔다는 사실만으로 모든 일정 의도 분류가 정확하다고 볼 수는 없습니다.

이 단계에서 확인한 것은 빈 기록을 꾸며내지 않는지, 읽기 요청으로 저장을 하지 않는지, 날짜만 있는 마감에 임의 시각을 붙이지 않는지입니다. 일정 충돌 해결이나 반복 일정, 중복 저장까지 검증한 상태는 아닙니다.

완료라고 적을 수 있는 범위

현재 구현 상태는 아래처럼 나눠 기록했습니다.

구분	2026년 9월 11일 상태
로컬 비서 기반	웹 UI·인증·서비스 구성과 시험용 메모 재시작 복구 확인
블로그·총괄 역할	역할 문서, 빈 기록 구조와 양식, 새 세션의 문서 조회 확인
실제 콘텐츠 이해	등록 전이므로 유사 글 추천 정확성 미검증
실제 일정 관리	시험용 요청의 조회 시험만 수행, 실제 저장·복구 종합 시험은 후속
외부 연결·자동 실행	메일·캘린더·모바일·예약 브리핑 미연결

블로그·총괄 역할의 첫 골격은 만들었지만, 아직 제 하루를 맡기지는 않았습니다. 현재 완료 기록은 이 표의 범위까지입니다.

다시 구축할 수 있도록 남긴 설계

지금까지의 대화가 길어지면서 설계 자체도 다음 작업에 전달할 필요가 생겼습니다. 어떤 기능을 원했는지뿐 아니라 왜 현재 범위를 좁혔는지, 무엇은 구현했고 무엇은 남았는지 정리했습니다. 전체 구조를 읽을 수 있는 문서와 HTML 설명, 다시 시작할 때 참고할 절차와 빈 양식도 마련했습니다.

실행 환경의 설정이나 인증을 그대로 복제하는 것과 설계를 전달하는 일은 구별했습니다. 재사용할 수 있는 역할 원칙과 검증 기준을 문서화한 것이지, 다른 개인 장비에 설치까지 완료한 것은 아닙니다.

첫 구현에서 얻은 것은 많은 일을 처리한 실적보다 다음 시험을 시작할 수 있는 기준선입니다. 이제는 실제로 챙길 글 몇 개를 넣고, 비서가 읽은 근거와 제안한 다음 행동이 맞는지 확인할 차례입니다.