개인 Mac 에 맡기는 한 줄, “답할 메일만 추려 줘”

퇴근길 지하철에서 폰으로 메일 정리를 부탁한다고 해 보자. 안 읽은 메일 중에 답해야 할 것만 골라 달라는 요청이다. 폰을 주머니에 다시 넣고 몇 정거장을 지나는 사이, 개인 Mac 이 메일을 읽고 골라서 다 됐다는 알림을 보낸다. 잠금 화면에는 결과의 앞부분이 짧게 떠 있다.

나는 이런 구성을 구독으로 로그인한 Claude Code 세션과 개인 Mac 한 대로 꾸려 쓰고 있다. 구성요소 대부분이 그 Mac 위에서 돈다. 구성요소는 여덟 개다. 이 글은 그 요청이 처리되는 순서대로 구성요소를 하나씩 설명한다.

구성요소가 놓이는 곳은 폰, 호스트, 저장소 세 군데다. 호스트는 그 개인 Mac 이다.

폰
  클라이언트
호스트
  브리지
  런타임
  스케줄러
  도구 계층
  하위 에이전트
  알림
저장소
  기억 저장소

세 곳 사이의 흐름은 다섯 가지다.

요청: 클라이언트 → 접근 제어 → 브리지 → 런타임 → 도구 계층
응답: 런타임 → 알림 → 클라이언트
루틴: 스케줄러 → 런타임 → 알림 → 클라이언트
위임: 런타임 → 하위 에이전트 → 결과 회수 → 런타임
기억: 런타임 → 기억 저장소

요청 흐름부터 본다.

접근 제어와 브리지

폰에서 보는 화면을 나는 클라이언트라고 부른다. 요청을 보내고, 답을 확인하고, 승인 선택을 누르고, 필요하면 호스트 Mac 의 브라우저 화면까지 만지는 곳이다. 실체는 브리지가 내려주는 웹 앱이다.

요청은 Mac 으로 바로 가지 않는다. 호스트 앞에는 사설망 또는 터널과 접근 제어 서비스가 있고 브리지는 이 접근 제어를 거친 요청만 받는다. 인증 없는 요청은 브리지가 거절한다.

브리지는 호스트에서 도는 HTTP 와 WebSocket 서버로, 클라이언트의 요청을 호스트 기능에 전달한다. 웹 앱 번들도 브리지가 직접 내려준다. 덕분에 클라이언트는 같은 오리진의 HTTP 로 앱을 열고 HTTPS 페이지에서 ws:// 를 막는 혼합 콘텐츠 제약에 걸릴 일이 생기지 않는다.

런타임과 도구 계층

브리지를 지난 입력은 상주 세션으로 들어간다. 이 세션이 런타임이다. tmux 세션 안에 떠 있는 Claude Code 이고 지시를 해석해서 도구를 부른다. 계정이 여럿이라 로그인은 계정 폴더로 나눠 둔다.

이 계정 폴더는 빠뜨리기 쉬운 곳이다. 실행 환경에 계정 폴더 변수가 없으면 실행이 다른 계정으로 되기 때문에 실행 명령에 계정 폴더를 꼭 지정해 둔다.

런타임이 부르는 도구 계층은 호스트와 외부 서비스를 실제로 조작하는 부분이다. CLI, 로컬 API, 브라우저 자동화, OS 자동화 네 가지가 있다. 메일 목록을 가져오는 일이라면 로컬 API 호출 하나로 끝나야 하는데, 여기에는 헷갈리기 쉬운 실패가 하나 있다. 제공자 파라미터를 빼고 부르면 지원하지 않는 메일 제공자라는 오류가 돌아오는데 실제 원인은 필수 파라미터 누락이다. 오류 문구만 보고는 짐작하기 어려운 종류의 실패라, 엔드포인트 목록에서 파라미터를 확인하고 전부 지정한다.

끝난 줄은 어떻게 아나

일이 끝났는지는 호스트가 본다. 4초마다 세션 화면을 읽어서 작업이 끝났는지 판정한다. 끝났다고 보면 마지막 응답의 앞부분을 알림 본문으로 보낸다. 알림은 호스트가 직접 보내는 웹 푸시이고 본문은 마크다운을 제거한 평문을 180자로 자른 것이다.

예외가 하나 있다. 같은 채팅을 6초 안에 열어 봤으면 알림을 보내지 않는다. 이미 화면을 보고 있는 사람의 폰을 한 번 더 울릴 이유는 없으니까.

완료 말고도 알림이 가는 순간이 있다. 입력을 기다릴 때, 루틴이 실패했을 때, 계정이 바뀌었을 때도 호스트는 곧바로 푸시를 보낸다. 푸시 구독은 시간이 지나면 만료되기도 해서 클라이언트를 열 때마다 구독을 확인하고 자동으로 다시 등록하게 해 두었다.

여기까지가 다섯 흐름 중 요청과 응답이다.

아무도 시키지 않은 요청

루틴 흐름은 사람이 아무것도 보내지 않아도 시작된다. 정해진 시각이나 간격에 저절로 실행되는 지시를 나는 루틴이라고 부른다. 루틴을 실행하는 건 스케줄러이고 호스트 안의 주기 타이머가 20초마다 실행할 때가 됐는지 판정한다.

일정을 적는 형식은 세 가지다.

간격은 5분보다 짧게 잡을 수 없다. 시각은 지정한 시간대의 벽시계로 계산한다.

실행 방식은 두 가지다. 사람과 대화하던 상주 세션에 지시를 입력하는 방식이 있고 Claude Code 를 한 번 띄워서 일을 시키고 끄는 단독 실행이 있다.

호스트 Mac 은 잠자기 상태에 들어가기도 한다. 잠자기 동안 지나간 회차는 깨어난 뒤 유예 안에서 한 번 실행한다. 원래 시각보다 15분 넘게 늦었으면 실행 기록에 "늦게 실행됨"을 붙여 둔다. 실행 기록은 루틴마다 20건까지 남는다.

단독 실행 지시에는 규칙을 하나 넣었다. 알릴 게 없으면 NONE 한 단어만 답하라는 지시다. 답이 NONE 이면 알림도 결과 파일도 만들지 않는다. 그렇게 해야 폰이 쓸데없이 울리지 않는다.

루틴에서 조심할 건 빈 결과다. 루틴이 돌긴 도는데 결과가 비어서 온다면 OS 자동화 권한 팝업이 떠서 응답을 막고 있을 가능성이 크다. 그래서 그런 호출에는 제한 시간을 두고 응답이 없으면 권한 상태부터 확인한다.

남에게 맡기는 일

요청이 크면 런타임 혼자 다 하지 않는다. 오래 걸리거나 계속 관리해야 하는 일은 하위 에이전트에게 넘긴다. 하위 에이전트는 역할별로 따로 띄운 세션이고 자기 작업 폴더와 자기 대화 기록을 따로 가진다.

맡기는 과정은 이렇다. 런타임이 하위 에이전트 세션을 시작하고 지시를 보낸다. 지시 앞에는 위임 표시가 붙고 보내는 명령은 기다리지 않고 바로 돌아온다. 그다음 런타임은 세션 상태를 조회하면서 done 이 될 때까지 기다리고 끝나면 하위 에이전트의 대화 기록을 읽어 결과를 받아 온다. 세션 상태는 네 가지다.

어떤 일을 넘길지는 규칙으로 정해 두었다. 계속 관리하거나 오래 걸리는 일은 하위 에이전트에게 간다. 한 번에 끝나는 짧은 일은 런타임이 직접 하거나 서브에이전트를 호출한다. 하위 에이전트는 보고할 때 첫 줄에 결과를 한 문장으로 요약하고 파일로 남길 결과물은 지정한 결과 폴더에 날짜와 주제를 붙인 이름으로 저장한다. 런타임은 대화 기록을 읽어 오므로 첫 줄만 보고 결과를 판단할 수 있다.

사람 손이 필요한 순간

에이전트가 혼자 처리할 수 없는 단계도 있다. 로그인, 2단계 인증, 캡차, 결제 단계에 오면 에이전트는 작업을 멈추고 사람에게 넘긴다. 이때 사람은 클라이언트에서 호스트 Mac 의 브라우저 화면을 보고 조작한다.

에이전트 → 작업 중단 → 알림(응답 대기) → 클라이언트
클라이언트 → 브라우저 화면 요청 → 브리지 → 브라우저 자동화 → 화면 프레임 → 클라이언트
클라이언트 → 탭, 입력, 스크롤 → 브리지 → 브라우저 자동화
사람 → 단계 완료 → 에이전트에 재개 지시

폰에서 호스트 브라우저 화면을 보며 탭하고, 입력하고, 스크롤한다. 브리지는 입력 길이와 좌표 범위를 검증한 다음에야 그 조작을 브라우저 자동화에 넘긴다.

승인 선택 창도 같은 경로로 사람에게 온다. 호스트가 알아서 승인하는 창은 딱 두 가지, 호스트가 만든 작업 폴더의 신뢰 확인 창과 지침 파일 가져오기 확인 창뿐이다. 나머지 선택 창은 전부 알림과 함께 클라이언트에 뜬다.

고치지 않고 덧붙이는 기억

다섯 흐름 중 마지막은 기억 저장소로 가는 흐름이다. 기억 저장소는 파일 기반 위키 저장소이고 출처가 붙은 사실만 보관한다. 새로 알게 된 사실은 다음 순서로 저장된다.

새 사실 → 받은함 → 큐레이터(원본 보관) → 기억 파일(사실 하나, 출처 하나 이상)
출처 충돌 → 충돌 기록 → 해당 주장 작업 중단 → 소유자 결정

저장소 안은 네 층으로 나뉜다.

규칙은 엄격하다. 모든 주장에는 출처가 있어야 하고 출처가 없는 주장은 아예 적지 않는다. 사실이 바뀌어도 기존 파일은 고치지 않는다. 새 기억 파일을 추가하고 그 파일의 출처에 이전 파일을 적는다. 두 출처가 다르면 날짜와 두 주장과 두 출처를 충돌 기록에 적고 그 주장에 걸린 작업은 멈춘다. 누가 맞는지는 소유자가 정한다. 에이전트는 어느 쪽이 맞는지 고르지 않는다.

이렇게 하는 이유는 하나다. 에이전트가 기억을 덮어쓰기 시작하면 어느 순간 무엇이 원래 사실이었는지 아무도 모르게 된다.

묻지 않고 일하는 대신

런타임은 도구를 부를 때마다 승인을 받지 않는다. 그래야 폰을 들여다보지 않는 동안에도 일이 끝나 있을 수 있다. 그 대신 안전 규칙을 지침 파일과 브리지에 적어 두었다.

지침 파일에는 주의할 점이 하나 있다. 지침 파일에 규칙을 손으로 고쳐 넣어도 호스트가 원본 설정에서 지침 파일을 다시 만들기 때문에 그 규칙은 얼마 뒤 사라진다. 그래서 규칙은 원본 설정의 규칙 목록에 넣는다.

사용 한도와 잠자기

구독으로 돌리는 구성이라 사용 한도가 따라온다. 계정마다 5시간 창과 7일 창의 한도가 있다. 단독 실행이 한도 소진 응답을 받으면 실패로 기록하고 알린다. 기본 계정의 5시간 사용률이 기준값 이상이거나 7일 사용률이 100%가 되면 한도가 남은 다음 계정으로 옮겨 가고 한도가 풀리면 기본 계정으로 돌아온다.

한도보다 단순한 제약도 있다. 호스트가 잠자기 상태이거나 꺼지면 클라이언트 접속도, 루틴 실행도 멈춘다. 모든 흐름이 그 Mac 한 대에서 돌기 때문이다.

비슷한 걸 만들어 보려는 사람을 위해, 이 글에 나온 숫자를 한곳에 모아 둔다.

아직 오지 않는 알림

이 구성에서 확인하기 가장 어려운 단계는 마지막 완료 알림이다. 완료 알림이 오지 않는 이유를 꼽아 보면 넷이다. 열람 중이라 알림을 생략했을 수도 있고, 호스트가 잠자기 상태일 수도 있고, 푸시 구독이 만료됐을 수도 있고, 화면 판정이 실패했을 수도 있다. 폰에서는 네 경우 모두 알림이 오지 않는다는 것만 보인다. 지금은 그럴 때마다 세션 상태와 대화 기록을 직접 조회한다.

즉시 푸시는 이미 붙어 있다. 그 위에 점검 루틴을 하나 더 두는 게 맞다고 본다. 주기 루틴이 세션 목록을 읽다가 완료나 대기 상태로 오래 남은 세션이 있으면 알려 주는 방식이다. 다만 이건 아직 권장 사항으로만 적어 둔 채 만들지 못했다. 그리고 만든다 해도 마음에 걸리는 게 있다. 점검 루틴도 같은 호스트에서 돌기 때문에 호스트가 잠자기 상태면 점검 루틴도 멈춘다.

알림이 없는 세션이 작업을 끝낸 상태인지 중간에 멈춘 상태인지 폰 하나로 구분할 방법이 있을까. 비슷한 구성을 돌려 본 사람이 있다면 어떻게 챙기고 있는지 알려 주면 좋겠다.