나만의 AI 업무 시스템 만들기 1. 맥에서 시작한 비서를 서버로 옮긴 이유

블로그를 쓰거나 프로그램을 만들 때, AI에게 다음 일을 맡기려면 먼저 지금까지의 작업을 설명해야 했습니다. 어떤 문서를 읽었고 무엇을 결정했는지, 어디까지 구현했고 다음에는 무엇을 확인할지 다시 정리했습니다. 답변을 잘 만드는 도구에 더해, 제가 하던 일을 이어서 맡길 환경이 필요했습니다.

처음에는 맥에 비서를 띄우는 일부터 시작했습니다. 이후에는 비서의 실행 위치를 서버로 옮기고 일정 조회와 회의록 기능을 붙였습니다. 이 글은 그 과정에서 달라진 요구를 정리한 기록입니다. 2026년 9월 28일 현재 전체 구조는 다시 검토하고 있으며, 모든 업무가 하나로 이어지는 시스템을 완성한 상태는 아닙니다.

다시 설명하는 일을 줄이고 싶었습니다

제가 원하는 사용 장면은 복잡한 명령에서 시작하지 않았습니다. 글감이나 메모를 건네면 전에 쓴 내용과 비교하고, 지금 하려는 일에 필요한 자료를 찾아주는 정도였습니다. 아래는 그 요구를 설명하기 위한 예시입니다.

이 메모로 글을 쓰고 싶습니다. 전에 다룬 내용과 겹치는지 보고, 이번 글에서 더 확인할 부분을 정리해주세요.

이 요청에 새 초안만 길게 돌아오면 충분하지 않습니다. 무엇을 이미 썼고 어떤 근거가 부족한지 알아야 다음 일을 고를 수 있습니다. 개발에서도 새 기능을 만드는 것과 지난 작업의 결과를 읽고 다음 과제를 정하는 것은 서로 이어져 있어야 했습니다.

처음부터 블로그만을 위한 도구를 만들려던 것은 아닙니다. 개발, 개인 프로젝트, 일정에도 같은 요구가 있었습니다. 다만 모두 한꺼번에 연결하기보다 블로그와 할 일처럼 제가 결과를 확인하기 쉬운 대상에서 시작하려 했습니다.

맥에서 만든 첫 골격

2026년 9월 11일에는 OpenClaw를 맥의 대화 창구로 두고, 이미 쓰던 Codex CLI는 문서와 코드를 실제로 고치는 도구로 남겼습니다. 이것은 두 제품의 성능 순위를 매긴 결과가 아니라 당시 정한 역할 분담이었습니다.

비서가 글감과 관련 문서를 찾아 요청을 정리하면, 작업 도구가 그 요청을 받아 초안을 고치고 검사하는 흐름을 생각했습니다. 결과를 다시 비서가 읽으려면 어느 문서를 바꿨고 무엇을 확인했는지도 남아야 했습니다. 이 인수인계까지 자동으로 연결한 상태는 아니었습니다.

당시에 확인한 것은 로컬 화면, 비서 역할의 기본 구조, 시험용 기록을 읽는 동작이었습니다. 다음에는 실제 글 몇 개를 연결해보려 했습니다. 큰 작업 폴더를 한꺼번에 맡기는 것보다 제가 원본과 답을 대조할 수 있는 작은 시험이 필요했습니다.

그 뒤에는 실행 위치와 기기 사용에 대한 요구가 구체화되면서, 처음 계획했던 작업 순서가 달라졌습니다.

맥이 켜져 있는 조건을 벗어나기

맥에서만 쓰는 비서는 그 컴퓨터가 실행 중이라는 조건에 묶입니다. 브라우저 창을 닫는 일과 컴퓨터를 끄는 일도 다릅니다. 별도 서비스가 떠 있으면 창을 닫아도 요청을 처리할 수 있지만, 장비가 꺼져 있으면 그 장비의 프로그램은 일할 수 없습니다.

9월 14일에는 여러 컴퓨터와 아이폰에서 같은 기록을 이용하고, 폰에서 작업을 요청하는 방향으로 요구를 구체화했습니다. 맥에서 시작한 일을 다른 기기에서 확인하고 싶었습니다. 어느 기기를 손에 들었는지에 따라 작업 기록의 위치가 달라지는 방식은 피하고 싶었습니다.

큰 작업을 함께 진행할 때 맥이 꺼지거나 재부팅되는 경험도 있었습니다. 발열을 의심했지만 원인을 확정한 진단은 아니었습니다. 이 경험을 계기로 큰 작업의 실행 위치까지 서버로 옮기는 방안을 검토했습니다. 서버를 쓰면 그 문제가 모두 해결된다고 확인한 것은 아닙니다.

서버는 실행을 맡길 장소입니다. 그곳에 프로그램을 설치했다고 모든 기기에서 같은 작업이 이어지는 것은 아닙니다. 접속 권한, 기록을 저장할 위치, 중단된 작업을 확인하는 방법은 따로 정해야 했습니다.

서버에 기능을 하나씩 붙였습니다

이후 서버의 두 비서에서 일정과 할 일을 조회하는 흐름을 시험했습니다. 회의록은 음성을 받아 문서를 만드는 경로부터 시작해, 외부 도구가 만든 녹취록을 가져와 검토하는 화면으로 바뀌었습니다. 할 일을 보관할 서비스도 별도로 구현하고 시험했습니다.

이 작업들은 같은 단계에 있지 않습니다. 일정 조회와 회의록 화면에는 실제 서버에서 확인한 결과가 있습니다. 업무 상태를 보관할 서비스의 구현·시험과 실제 업무의 기준 저장소를 옮기는 일은 구분해야 합니다. 기능이 있다는 사실만으로 서로 연결됐다고 말할 수는 없었습니다.

예를 들어 회의록에 할 일이 적혀 있어도, 그 일의 현재 상태를 어디서 바꿀지는 별도 문제입니다. 대화에서 “그 일 끝났어”라고 말했을 때 어느 기록을 고쳐야 하는지도 정해야 합니다. 기능을 늘릴수록 그 사이의 기록을 어떻게 연결할지가 더 구체적인 과제로 드러났습니다.

하나의 창구와 여러 업무 화면

처음에는 개인 비서와 업무 비서를 나눠 구성했습니다. 지금은 일을 맡기는 창구를 하나로 두고 필요한 업무 화면을 연결하는 방향을 검토하고 있습니다. 자료를 구분하는 일과 대화창을 몇 개 둘지는 별개의 선택이라고 보기 시작했습니다.

긴 회의록을 고칠 때는 문서를 읽고 수정하는 화면이 편합니다. 해야 할 일을 볼 때는 목록이나 대시보드가 필요할 수 있습니다. 이런 화면을 모두 대화창으로 바꾸기보다, 어디서 시작하든 같은 요청과 기록을 찾을 수 있기를 바랍니다.

창구를 합치더라도 개인 자료와 업무 자료를 섞어 보관하겠다는 뜻은 아닙니다. 자료별 저장 위치와 읽고 고칠 수 있는 범위는 유지해야 합니다. 화면에서 한 번에 요청할 수 있는 것과 모든 자료에 같은 권한을 주는 것은 다릅니다.

9월 28일에는 전체 구조를 다시 검토하기 위해 새 구현과 운영 전환을 멈췄습니다. 이미 동작하는 기능은 유지하면서 어떤 접속 방식과 실행 구조가 요구에 맞는지 비교하려 합니다. 특정 도구를 더 붙이는 일보다, 지금 만든 것 중 무엇을 이어 쓸 수 있고 무엇을 바꿔야 하는지 먼저 판단할 단계입니다.

처음의 질문은 지금도 같습니다. 다른 기기에서 다시 말을 걸었을 때 제가 하던 일을 어디서부터 이어갈 수 있는가. 로컬 비서에서 서버로 옮긴 것은 그 질문을 풀기 위한 한 단계였고, 다음 판단에는 요청과 결과가 남는 방식까지 들어가야 합니다.