개인 업무 비서 만들기 4. 일정 비서를 가장 위에 두었습니다

회의 내용을 정리하는 기능과 일정 관리가 같은 기능처럼 묶일 때, 저는 둘을 나누고 싶었습니다. 회의가 없어도 개인 일정은 있고, 블로그와 개발 프로젝트의 우선순위도 함께 봐야 하기 때문입니다. 일정 관리는 각 기능 위에서 전체 일을 정리하는 역할에 더 가깝다고 생각했습니다.

그래서 회장 비서와 분야별 사장 비서가 따로 있는 모습을 떠올렸습니다. 분야별 비서는 자기 일을 자세히 알고, 총괄 비서는 그 보고를 받아 제가 오늘 무엇부터 할지 정리하는 방식입니다. 이 비유를 실제 개인 비서의 역할과 기록 구조로 풀어보기로 했습니다.

분야별로 잘 아는 것과 하루를 정하는 것

블로그 비서는 기존 글의 근거, 초안의 진행 상태, 비슷한 주제를 알아야 합니다. 개발 비서는 기능 구현이 어디까지 됐는지, 테스트가 남았는지, 무엇 때문에 다음 작업을 못 하는지 알아야 할 것입니다.

그렇다고 각 비서가 따로 제 하루를 정하면 곤란합니다. 모두 자기 분야에서 중요한 일을 추천할 테니까요. 개인 약속이 있는 날에도 블로그와 개발 양쪽에서 긴 작업을 올리면 제가 다시 조정해야 합니다.

총괄 비서에는 그 조정에 필요한 정보만 모으려 합니다. 무엇을 해야 하는지, 언제까지인지, 다른 작업을 기다리는지, 제가 알려준 가용 시간에 할 수 있는 다음 행동은 무엇인지입니다. 글 원문이나 코드 전체를 총괄 기록에 복사할 필요는 없습니다.

목표 구조를 줄이면 아래와 같습니다. 현재 역할 골격을 만든 것은 총괄과 블로그 부분이며, 나머지는 확장 계획입니다.

나의 요청과 확인
└─ 일정·우선순위 총괄 비서
   ├─ 블로그·콘텐츠 역할 → 기존 글과 집필 계획
   ├─ 개발 프로젝트 역할 → 기능·검증·남은 작업       [추후]
   ├─ AI 프로젝트 역할  → 실험·학습·판단 기록        [추후]
   └─ 개인 생활 영역    → 내가 확정한 약속과 할 일    [등록 후]

회의·음성·메모 입력 → 검토할 기록 → 관련 분야와 총괄에 반영 [추후]

총괄은 모든 분야의 원문을 소유하는 역할이 아니라, 필요한 원본을 찾아보고 서로 충돌하는 일을 설명하는 역할로 두려 합니다.

할 일과 시간 약속을 다른 기록으로

일정 비서를 설계하며 먼저 구분한 것은 할 일과 약속입니다. 둘을 한 목록에 모을 수는 있지만 같은 정보로 저장하면 안 되는 경우가 있습니다.

예를 들어 ‘금요일까지 초안을 검토하기’는 마감이 있는 할 일입니다. 어느 시각에 시작해서 끝낼지는 아직 정해지지 않았습니다. ‘금요일 오후 3시부터 30분간 초안 검토 회의’는 시간대를 차지하는 약속입니다. 이는 설계를 설명하기 위한 예시입니다.

제가 날짜만 말했는데 비서가 임의로 오후 6시 마감이나 오후 3시 약속으로 바꾸지 않도록 규칙을 두었습니다. 할 일에는 마감 날짜 또는 시각을 구별해 적고, 약속에는 시작·종료 시각과 시간대를 확인하도록 설계했습니다.

‘다음 주 중에 살펴보고 싶다’는 말도 바로 확정 일정이 되면 안 됩니다. 검토할 후보로 남기려는 것인지, 실제 시간 약속을 잡으려는 것인지부터 확인해야 합니다. 정확한 날짜를 묻는 것만으로 부족할 수도 있습니다. 처음부터 약속이라고 잘못 해석하지 않는지도 시험해야 합니다.

이 구분이 있어야 비서가 빈 시간을 그럴듯하게 채우는 대신 제가 실제로 확정한 약속을 기준으로 말할 수 있습니다.

우선순위의 이유를 설명하게 하기

처음부터 복잡한 점수 계산식을 만들지는 않았습니다. ‘중요도 87점’이라는 숫자보다 오늘 이 일을 먼저 추천한 이유를 알고 싶었습니다.

설계에서는 이미 끝났거나 선행 작업을 기다리는 일을 먼저 걸러냅니다. 확정 약속과 가까운 마감을 살피고, 제가 정한 중요도와 다른 일을 풀어주는 효과를 봅니다. 시간이 알려져 있다면 그 안에 가능한 다음 행동을 고르고, 오래 미뤄진 일은 정기 검토 후보로 보여주는 순서입니다.

예를 들어 공개할 글의 근거 확인이 끝나지 않았다면 제목 다듬기보다 근거 확인을 먼저 추천할 수 있습니다. 반대로 확인에 필요한 자료를 기다리고 있다면 당장 실행할 수 있는 다른 일을 보여줘야 합니다. ‘급한 일’과 ‘지금 할 수 있는 일’이 같지 않을 수 있기 때문입니다.

가용 시간을 말하지 않았는데 하루 시간표를 만들어주는 것도 원하지 않습니다. 이때는 순서와 추천 이유를 제시하고, 필요한 경우 시간을 물어보는 편이 맞습니다. 비서의 추천이 저장된 마감이나 약속을 바꾸는 행위가 되지 않도록 따로 구분했습니다.

회의록은 총괄 비서에게 들어오는 자료

아이폰으로 녹음한 내용을 회의록으로 정리하고 위키에 활용하는 기능은 여전히 만들고 싶습니다. 다만 회의록을 잘 쓴다고 일정 관리가 저절로 완성되지는 않습니다.

회의에는 확정된 약속도 있지만 제안, 질문, 검토 중인 날짜도 섞입니다. 음성을 문자로 옮기는 과정에서 잘못 인식한 말도 있을 수 있습니다. 이런 내용을 모두 일정으로 만들면 기록이 많아지는 만큼 잘못된 약속도 늘 수 있습니다.

앞으로는 회의 기록에서 결정사항과 미결사항, 할 일 후보와 일정 후보를 나눈 뒤 확인받는 흐름을 붙이려 합니다. 확정한 내용만 개인 일정에 연결하고, 회의 기록은 별도 근거로 남기는 것입니다. 이 기능은 아직 구현하지 않았습니다.

녹음과 전사는 입력 과정이고, 총괄 비서는 그 자료를 다른 개인 업무와 함께 보는 역할입니다. 이렇게 두면 회의뿐 아니라 메일이나 짧은 메모도 같은 확인 절차로 받아들일 수 있습니다.

역할을 나눈다고 프로그램이 여러 개가 되는 것은 아닙니다

회장 비서와 분야별 비서라는 표현만 들으면 여러 AI가 각자 돌아가며 협의하는 구성을 떠올릴 수 있습니다. 현재는 그렇게 만들지 않았습니다. OpenClaw의 단일 main 안에 총괄과 블로그의 역할 지침을 나누어 둔 상태입니다.

요청에 따라 어떤 자료를 읽고 어떤 관점으로 답할지 구분하는 시작점입니다. 별도 프로세스나 계정, 기술적 접근 권한을 분리한 것은 아닙니다. 같은 파일 도구 권한 위에서 지침을 나눈 것이므로, 역할 이름만으로 서로의 자료 접근이 차단된다고 설명할 수는 없습니다.

나중에 독립 에이전트가 필요해지면 이 구분을 바탕으로 데이터와 권한까지 나눌 수 있을 것입니다. 지금은 먼저 같은 질문에 역할을 혼동하지 않는지, 원본을 제대로 찾는지 확인하려 합니다.

전체를 본다는 것은 원문을 모두 모으는 일이 아닙니다

블로그 비서가 새 글의 근거를 정리했다면 총괄 비서는 제가 판단할 부분과 남은 행동을 받아야 합니다. 개발 도구가 테스트를 끝냈다면 무엇을 확인했고 무엇이 남았는지 알아야 합니다. 분야별 원본은 그 분야에 둡니다.

이것이 제가 일정 비서를 가장 위에 둔 이유입니다. 위키가 늘어나도 오늘의 약속과 해야 할 일은 함께 보고 싶었습니다. 분야별로 더 많은 것을 기억하게 만드는 동시에, 제게 올라오는 다음 행동은 서로 맞물리게 정리하려 합니다.