윈도우 PC의 OpenCodex는 맥과 다른 계정을 활성으로 들고 있었다.
9월 21일, 윈도우에서 SSH로 맥에 붙어 일하다가
붙여 둔 것과 다른 계정에서 사용량이 나가는 걸 보고 원인을 추적하다가 확인한 사실이다.
맥을 정본으로 정해도 계정·설정·연결 상태는 기계마다 따로 산다.
한쪽에서 맞춘 값은 다른 쪽으로 건너가지 않았고
두 기계를 잇는 길은 어느 한쪽의 사정 때문에 끊겼다.
문제
9월 8일, 윈도우 PC에서 맥에 붙어 일하다가 두 기계가 함께 쓸 폴더가 필요해졌다.
"현재 ssh로 윈도우에서 맥에 붙어 작업중인데, 공유폴더가 하나있었음 좋겠어."
다음 날에는 OpenCodex의 정본을 맥북으로 옮기는 작업을 했다.
OpenCodex는 Codex의 요청을 받아 여러 계정과 모델 공급자로 보내는 프록시다.
기억 서비스와 에이전트 지침의 정본도 맥에 있다.
SSH 창 안에서만 일한다면 윈도우 쪽 값은 상관없다고 볼 수도 있다.
그런데 사용량 대시보드를 띄우는 OpenCodex 앱, 브라우저 자동화 도구 Aside,
맥의 Orca가 의존하는 클라이언트는 전부 윈도우 PC에서 실행된다.
SSH가 넘겨주는 건 맥의 셸 하나뿐이다.
같은 이름의 값이 기계마다 따로 산다
같은 프로그램, 같은 라벨의 계정이라도 값은 기계마다 따로 있었다.
OpenCodex 계정
9월 21일 맥의 OpenCodex에서 활성 표시가 붙은 Anthropic 계정은 하나였고
인증 파일의 activeAccountId도 그 계정을 가리켰다.
윈도우 PC의 인증 파일에도 같은 계정들이 있었지만 id는 전부 달랐고
윈도우의 activeAccountId는 맥의 활성 계정과 다른 계정이었다.
에이전트는 대시보드에 찍힌 계정 식별 표시가
윈도우의 활성 계정과 같다는 점을 근거로 그 화면이 윈도우 앱이었다고 진단했다.
SSH로 맥에서 하는 작업은 맥 프록시를 지나 맥의 활성 계정으로 나간다.
반면 윈도우 앱은 윈도우의 인증 파일을 읽는다.
SSH로 붙었다는 건 맥의 상태를 빌려 쓴다는 뜻이지,
윈도우의 상태가 맥을 따라간다는 뜻은 아니었다.
Aside의 Anthropic 인증
10월 11일에는 윈도우 Aside에서 cct로 붙여 둔 Anthropic 모델이 동작하지 않았다.
cct는 Claude 구독 계정의 토큰을 골라 쓰는 셸 지갑이다(cct).
윈도우 Aside에 남은 Anthropic 인증은 claude-code 자격 하나였고,
만료된 상태였다.
모델 설정에는 anthropic provider가 없었고 cct 지갑 파일도 없었다.
맥 Aside에서는 그 provider가 cct 토큰을 받기 때문에,
활성 cct 계정을 바꾸면 새 세션부터 바뀐 계정을 따라간다.
맥에서 계정을 갈아 끼우던 장치가 윈도우에는 없었던 것이다.
그 밖에 따로 산 값
| 항목 | 맥 | 윈도우 PC | 윈도우를 잰 날 |
|---|---|---|---|
| Codex의 기억 서비스 연결 | memory-vault 항목 있음 | mcp_servers에 node_repl 하나 | 9월 9일 |
| Aside 지침 파일 | 공용 지침으로 가는 심볼릭 링크, 14,223바이트 | 제목과 주석 한 줄뿐인 77바이트 별개 파일 | 9월 10일 |
| Aside 기억 서비스 주소 | 맥 로컬 8888 포트 | 맥의 테일스케일 HTTPS 주소, 8443 포트 | 9월 10일 |
맥 쪽 두 값은 2026-10-19에 확인했다.
맥에서 지침 파일이 심볼릭 링크로 공용 지침 하나를 읽는 구조는
에이전트 운영 체계에 적었다.
맥이나 PC가 꺼지면 끊기는 길
윈도우가 맥의 값을 직접 쓰도록 이어 붙이면,
이번에는 그 길이 맥이나 PC의 전원 사정에 묶인다.
맥이 잠들 때
9월 10일 윈도우 Aside에 기억 서비스를 붙일 때는
하루 전 윈도우 로컬 8888 포트가 응답하지 않았기 때문에 맥의 테일스케일 주소를 넣었다.
맥의 기억 서비스는 Hindsight 앞에 게이트웨이를 세운
Hindsight-Crew다.
작업을 마친 에이전트는 조건을 이렇게 적었다.
"이 연결은 맥이 깨어 있고 colima와 게이트웨이가 떠 있을 때만 삽니다."
SMB 공유 폴더도 같은 조건에 묶여 있었다.
에이전트는 SMB를 제안하며 "맥북이 잠들면 테일스케일도 같이 끊깁니다"라고 경고했다.
이어진 설명을 듣고 내가 남긴 말은 "잠들면 깨진다.. 음.."이었다.
윈도우 오프라인 파일로 마지막 상태를 남기려던 시도는
고정 호출이 성공을 반환한 뒤에도 캐시 목록이 비어 있었고,
윈도우를 재부팅한 뒤 알려 달라는 답에서 멈췄다.
공유 폴더 하나로 시작한 일이 윈도우 재부팅 숙제로 남았다.
윈도우 PC가 꺼질 때
맥에서 작업 런을 띄우는 Orca는 반대로 윈도우 PC에 의존한다.
맥의 orca 명령은 릴레이 소켓을 거쳐 명령을 보내는 래퍼이고
run-create처럼 소유 클라이언트가 필요한 명령은
그 클라이언트가 릴레이에 붙어 있어야 실행된다.
10월 2일 23:19, 맥 세션의 orca orchestration run-create가
No owning Orca client is connected to the relay를 냈다.
윈도우 PC의 이벤트 로그에는 23:04:35의 예기치 않은 종료와
23:18:12의 시작이 기록되어 있다. 오류가 난 시각은 운영 체제가 올라온 지 1분 뒤였다.
같은 오류는 모두 네 날짜에 발생했다.
| 날짜 | 맥에서 본 오류 시각 | 같은 무렵 윈도우 PC |
|---|---|---|
| 10월 2일 | 23:19 | 23:18:12 운영 체제 시작 (23:04:35 예기치 않은 종료 뒤) |
| 10월 7일 | 07:23 | 07:26 맥에서 보낸 ping에 down |
| 10월 11일 | 02:21, 02:45 | 00:04:58부터 예기치 않은 종료 다섯 번, 02:05:19 Kernel-Power 41 (0x124) |
| 10월 14일 | 15:26 | 15:23 Tailscale에서 offline, last seen 1d ago |
종료와 재시작이 이벤트 로그로 확인된 건 2일과 11일이다.
7일에 에이전트는 윈도우 PC의 절전을 원인으로 추정했지만
9월 30일에 powercfg로 조회한 절전 진입 시간은 AC·DC 모두 0이었다
(에이전트는 이를 절전 없음으로 읽었다).
7일과 14일의 원인은 확인하지 못했다.
정본을 옮기는 중에 끊긴 세션
9월 9일 새벽, 윈도우 Codex 세션이 작업 도중 끊겼다.
"아마 프록시 주소옮기면서 끊어진걸로 보이는데 어디까지 완료됐나 파악해봐."
맥에서 확인하니 컷오버 여섯 단계 중 다섯 단계는 끝나 있었다.
남은 건 맥 서비스를 상시 가동으로 돌리는 마지막 단계였다.
맥에서 돌던 프록시는 끊긴 세션이 ocx start로 띄운 분리 프로세스였다.
마지막 단계를 끝내려면 그 프로세스를 죽여야 했는데,
맥 Codex 에이전트는 거기서 멈췄다.
자기 모델 라우팅이 "죽여야 할 그 프로세스를 통과합니다"라고 적었고
그대로 진행하면 "앞선 세션이 죽은 것과 똑같은 방식"으로 끊긴다고 했다.
분리 실행한 마무리 스크립트의 로그도 프록시 종료 단계에서 끝난다.
컷오버에서 윈도우 Codex의 요청 주소는 맥 프록시로 바뀌었다.
그런데 9월 21일에 본 그 설정의 openai_base_url은 윈도우 로컬 127.0.0.1:10100을 가리켰고
그 포트에는 윈도우 프록시가 떠 있었다.
맥으로 돌려 둔 값이 열이틀 뒤 윈도우 쪽으로 돌아와 있었다(경위는 모른다).
결론
정본을 한 기계에 정하는 일보다 기계마다 따로 사는 값을 적어 두는 일이 먼저였다.
윈도우에서 도는 앱은 계정도, 기억 서비스 연결도, 모델 인증도 윈도우 것을 읽는다.
그래서 맥에서 계정이나 연결을 바꾸면 윈도우에 있는 같은 이름의 값도 함께 열어 본다.
다른 기계에 기대는 연결에는 그 기계가 깨어 있어야 한다는 조건을 붙여 두고
경로를 옮기는 작업은 그 경로 밖에서 돌린다.
한계·재검토 트리거
2026-10 기준 / 재검토 트리거: 맥을 재운 채 윈도우에서 기억 서비스를 불러 본 결과
참고
- 에이전트 운영 체계 - 맥에서 다섯 런타임이 지침 파일 하나를 읽는 설정 정본
- cct - Claude 구독 계정 토큰을 골라 쓰는 셸 지갑과 사용량 대시보드
- Hindsight-Crew - Hindsight 앞에 게이트웨이를 세운 공유 메모리