AI 에이전트 핸드오프 실전기 — 클로드에서 ChatGPT로 비서를 통째로 옮겨보았다

어느 날 아침, AI 비서가 응답하지 않는다면?

매일 아침 8시 56분 브리핑을 읽어주고, 하루 두 번 블로그를 발행하고, 유튜브 영상을 만들어 올리는 AI 비서가 있습니다. 크론 작업 12종, 장기 메모리 180건, 스킬 37종, MCP 서버 10종 — 이게 저희 연구소에서 클로드 한 대가 짊어지고 있던 살림입니다. 그런데 이 비서가 어느 날 멈춘다면요? 이 글은 그 질문에서 시작해, AI 에이전트 핸드오프 — 한 AI의 상태 전체를 다른 AI(ChatGPT의 Codex)로 이사시킨 이틀간의 실전 기록입니다.

왜 백업이 필요한가 — 단일 장애점이 된 AI

자동화가 깊어질수록 역설이 생깁니다. AI가 잘할수록 사람은 그 일을 잊고, AI가 멈추는 순간 아무도 그 일을 모르는 상태가 됩니다. 서버 이중화는 상식이 됐는데, 정작 서버를 굴리는 AI 에이전트는 단일 장애점으로 방치되는 경우가 많아요. 계정 정지, 요금제 한도, 서비스 장애 — 원인은 뭐든 될 수 있습니다. 그래서 "클로드가 죽어도 내일 아침 브리핑은 나온다"를 목표로 잡았습니다.

핸드오프의 첫 질문 — 'AI의 상태'란 무엇인가

사람 인수인계라면 문서 몇 장이면 되지만, AI 에이전트의 상태는 생각보다 여러 층입니다. 정체성과 규칙(프로필), 경험(장기 메모리), 능력(스킬·커맨드), 도구(MCP 서버), 일과(크론 스케줄), 안전장치(훅), 그리고 외부 서비스 연결(커넥터). 이 일곱 층을 하나라도 빼먹으면 "겉모습만 같은 다른 비서"가 됩니다. 핸드오프는 복사가 아니라 이 일곱 층의 전수조사에서 시작해야 했습니다.

1단계 — 자산 전수조사

먼저 클로드 쪽에 실제로 뭐가 있는지 세었습니다. 활성 크론 11종, 전역 메모리 파일 180개, 개인 스킬 37개 폴더, 슬래시 커맨드 11개, MCP 서버 정의 10여 종, 훅 3종. 여기에 claude.ai 쪽에만 있는 것들 — Cowork 스케줄, 채팅 메모리, 지메일·캘린더 커넥터 — 까지 목록에 올렸습니다. 재미있는 건, 이 목록을 만드는 과정에서 본진에서도 동기화가 새고 있던 곳이 두 군데나 발견됐다는 점입니다. 백업 작업이 본진 점검이 된 셈이죠.

클로드의 하루 — 크론 11종

옮길 것 중 가장 큰 덩어리는 정기 작업이었습니다. 새벽 4시 다운로드 정리, 5시 스토리지 정리와 설정 동기화, 하루 다섯 번의 음성 브리핑, 하루 두 번의 블로그 발행, 하루 네 번의 유튜브 영상 제작·업로드. 각 작업은 SKILL.md라는 지시문 파일로 정의돼 있고, 길게는 6만 자가 넘는 운영 노하우가 담겨 있습니다. 이 지시문들이 사실상 업무 매뉴얼의 정본이라, 핸드오프의 절반은 이 파일들을 어떻게 새 환경에서 읽히게 하느냐의 문제였습니다.

문제 하나 — Codex에는 크론이 없다

클로드 코드에는 예약 작업 기능이 내장돼 있지만, Codex CLI에는 크론 개념 자체가 없습니다. 대신 codex exec라는 비대화형 실행 모드가 있죠. 그래서 설계를 이렇게 잡았습니다: Windows 작업 스케줄러가 시계 역할을 맡고, 정해진 시각에 러너 스크립트가 지시문 파일을 codex exec의 표준입력으로 흘려 넣는 구조. 지시문이 최대 64KB라 명령줄 인자로는 못 넘기고 stdin 파이프가 필수였습니다. 플랫폼이 바뀌면 같은 기능도 조립 방식이 완전히 달라집니다.

프롬프트 미러링 — 복사하되, 고치지 않는다

지시문 11벌은 한 글자도 고치지 않고 그대로 복사했습니다. 대신 맨 앞에 '환경 보정 머리말' 한 장을 자동으로 붙였습니다. "WebSearch 도구 대신 web_search를 써라", "지메일 커넥터가 없으니 그 절은 생략하고 보고에 남겨라" 같은 차이만 머리말이 흡수합니다. 원본을 고치기 시작하면 두 벌이 서서히 갈라지고, 어느 쪽이 정본인지 아무도 모르게 됩니다. 정본은 한 곳, 차이는 접두부에서 — 이 원칙이 미러 유지비를 거의 0으로 만들어 줍니다.

거울은 스스로 닦이게 — 재동기화 스크립트

복사본의 숙명은 낡는 것입니다. 본진 지시문은 운영하면서 계속 고쳐지니까요. 그래서 손 복사 대신 sync_prompts.ps1이라는 재실행 안전한 동기화 스크립트를 만들었습니다. 본진 파일을 다시 읽어 머리말을 붙이고 미러를 통째로 재생성합니다. 본진 크론이 바뀌면 이 스크립트 한 번이면 끝. 나중에는 이 호출을 매일 새벽 정기 작업에 얹어서, 사람이 기억하지 않아도 거울이 스스로 닦이는 상태로 만들었습니다.

가장 무서운 함정 — 이중 발행

백업을 만들 때 제일 위험한 순간은 백업이 잘 작동할 때입니다. 본진과 백업이 동시에 살아 있으면 블로그가 두 번 발행되고 유튜브에 같은 영상이 두 개 올라갑니다. 그래서 미러 12종은 전부 비활성 상태로 등록했습니다. 장애가 나면 스위치 스크립트 하나(enable_all.ps1)로 전체를 켜고, 이때 본진 크론을 꺼야 한다는 경고를 스위치 출력에 박아 뒀습니다. 백업의 평상시 모습은 '꺼져 있음'이어야 한다는 것 — 당연해 보여도 설계에 명시하지 않으면 꼭 사고가 납니다.

환경 차이는 지우지 말고 기록한다

완벽한 이사는 없습니다. 지메일과 구글 캘린더는 claude.ai 커넥터라 Codex로 못 가져갑니다. 그럼 브리핑의 메일·일정 절은 어떻게 할까요? 몰래 빼먹으면 안 됩니다. 머리말에 "해당 절은 생략하되, 보고에 '커넥터 미연결로 생략'이라고 남겨라"라고 지시했습니다. 기능 저하는 허용하되, 침묵하는 저하는 허용하지 않는다 — 이게 이번 핸드오프에서 가장 여러 번 적용한 원칙입니다. 줄어든 걸 알아야 나중에 채울 수 있으니까요.

서버 속의 프롬프트 — Cowork 스케줄

제일 까다로운 상대는 Cowork였습니다. 매일 오전 복지지원·창업지원·콘텐츠공모·커뮤니티 등 리포트 6종을 로컬 폴더에 쌓아 주는데, 정작 그 지시문은 claude.ai 서버에 있어서 꺼낼 방법이 없습니다. 소스 코드 없이 실행 파일만 있는 프로그램을 이식하는 상황과 같죠. 여기서 선택지는 둘입니다. 포기하거나, 산출물을 보고 역산하거나.

산출물 역산 — 결과물로 지시문을 복원하다

다행히 산출물이 곧 명세였습니다. 리포트들의 파일명 규칙, 문서 구조, 어투, 「판단」 표기 방식, 마감일 D-day 표현까지 — 몇 주치 결과물을 뜯어보면 원본 지시문의 골격이 드러납니다. 그렇게 근사본 프롬프트를 새로 써서 미러에 추가했습니다. 물론 한계는 명시했습니다: "이 문서는 산출물 역산 근사본이다." 그리고 본진 Cowork가 그날 이미 리포트를 만들었으면 건너뛰는 중복 방지 조건도 달았습니다. 완벽한 복제가 아니라 기능적 동등성이 목표였습니다.

셀프테스트 — 그리고 뜻밖의 벽

파이프라인이 완성됐으니 시험 가동을 했습니다. "SELFTEST-OK 한 줄만 답하라"는 무해한 지시문으로요. 러너가 돌고, Codex가 기동하고, 지시문이 전달되는 것까지 전부 확인됐습니다. 그런데 마지막에 돌아온 건 성공 응답이 아니라 이 메시지였습니다: "You've hit your usage limit." ChatGPT 계정이 사용량 한도에 걸려 있었던 겁니다. 리셋은 한 달 뒤. 백업 시스템은 완성됐는데, 그 백업을 돌릴 연료가 없는 상태였죠.

막힌 문 앞에서 — 실패도 자산으로 만든다

여기서 중요한 건 "안 됐다"로 끝내지 않는 것입니다. 확인된 사실을 분리해서 기록했습니다. 러너·stdin 전달·Codex 기동은 검증 완료, 실제 작업 실행은 계정 한도로 보류, 해제 조건은 리셋일 또는 요금제 업그레이드, 판단 주체는 사람. 이렇게 쪼개 두면 한 달 뒤에 "어디까지 됐더라"를 다시 조사할 필요가 없습니다. 막힌 지점의 정확한 좌표가 곧 다음 작업의 시작점이 됩니다.

경험을 옮기다 — 장기 메모리 180건

크론이 몸이라면 메모리는 기억입니다. 저희 클로드는 180개의 메모리 파일을 갖고 있습니다. "이 TTS 엔진은 긴 명사구에서 음절을 삼킨다", "이 API는 성공 코드를 돌려주고도 실패한다" 같은, 수개월의 실측 사고에서 뽑아낸 함정 지도죠. 이게 없는 백업 AI는 같은 구덩이에 전부 다시 빠집니다. 폴더째 미러링하고, 새 환경의 프로필 문서에 "세션 시작 시 인덱스부터 훑어라"라는 안내를 박았습니다.

낡은 거울의 교훈 — 동기화의 사각지대

사실 메모리 동기화 장치는 원래 있었습니다. 매일 새벽 도는 설정 동기화 스크립트요. 그런데 조사해 보니 Codex 쪽 메모리가 석 달 전 파편 11개뿐이었습니다. 스크립트가 옛 프로젝트 메모리 폴더만 보고, 정본인 전역 메모리 폴더는 대상에 없었던 겁니다. "동기화가 돌고 있다"와 "필요한 게 동기화되고 있다"는 다른 문장입니다. 자동화는 만들 때가 아니라 전수조사할 때 구멍이 드러납니다. 이번 핸드오프의 가장 큰 부수입이 이 구멍을 메운 것이었어요.

이미 준비돼 있던 것 — 스킬 37종, 커맨드 11종

반가운 발견도 있었습니다. 개인 스킬 37종과 슬래시 커맨드 11종은 기존 일일 동기화가 잘 커버하고 있어서, 대조 결과 누락이 0이었습니다. 평소에 여러 AI 도구(Cursor·Codex·로컬 모델)로 설정을 전파하는 체계를 운영해 온 덕입니다. 핸드오프를 하루 만에 끝낼 수 있었던 건 이 평소의 다중화 습관 때문이었습니다. 재해 복구 훈련과 같아요 — 사고 당일에 시작하면 늦고, 평소에 절반쯤 돼 있어야 합니다.

숨어 있던 조각 — 플러그인 스킬과 MCP 서버

전수조사의 가치는 구석에서 나옵니다. 뉴스 선별에 쓰는 게이트 스킬 하나가 일반 스킬 폴더가 아니라 데스크톱 앱 내부 저장소에 숨어 있어서 동기화 대상에서 빠져 있었습니다. 이걸 못 찾았으면 백업 크론이 "선별 게이트를 읽어라"는 지시를 만나 그대로 주저앉았겠죠. MCP 서버도 대조해 보니 오디오 믹서 제어용 한 종이 빠져 있어 설정에 추가했습니다. 목록에 없는 자산은 이관되지 않는다 — 그래서 목록 만들기가 핸드오프의 절반입니다.

안전장치도 이사한다 — 보안 훅 이식

클로드에는 훅이라는 안전장치가 있습니다. git 커밋 직전에 API 키 같은 비밀정보를 잡아내는 스캐너, 새까맣게 실패한 이미지가 블로그에 올라가기 전에 막는 게이트. 전부 실제 사고를 겪고 만든 것들이라, 백업 AI에게도 같은 안전벨트가 필요했습니다. 조사해 보니 Codex가 클로드의 훅 규격을 거의 그대로 지원하고 있어서, 같은 스크립트 파일을 양쪽 설정이 함께 가리키게 연결했습니다. 안전장치의 정본도 하나여야 하니까요.

fail-open — 안전장치가 인질극을 벌이지 않게

훅을 이식하며 가장 신경 쓴 건 실패 방향입니다. 새 환경은 데이터 형식이 미묘하게 다를 수 있는데, 훅이 낯선 입력을 만났다고 에러를 내면 모든 작업이 그 훅에 인질로 잡힙니다. 그래서 두 훅 모두 "입력을 못 읽으면 조용히 통과"하는 fail-open 구조인 걸 확인하고, 새 환경이 배열 형태로 명령을 넘기는 경우까지 대응을 보강했습니다. 보안 장치는 위험을 확신할 때만 막아야 합니다. 판단 불능을 차단으로 취급하는 안전장치는, 안전장치가 아니라 새로운 장애점이 됩니다.

검증 규율 — 출력을 믿지 말고 실물을 센다

이번 작업 내내 지킨 규율이 하나 있습니다. 스크립트의 성공 메시지는 증거가 아니다. 메모리를 복사했으면 양쪽 파일 수를 다시 세고(180=180), 스케줄러에 등록했으면 등록 목록을 다시 조회하고(12건·전부 비활성), 훅을 붙였으면 모의 데이터를 흘려 실제 동작을 봅니다. 이식이 안 된 훅은 조용히 아무것도 안 하기 때문에, 확인하지 않으면 "있는 줄 알았던 안전벨트"가 됩니다. 자동화의 세계에서 조용한 실패가 가장 비쌉니다.

옮길 수 없는 것들 — 사람 몫 세 가지

끝까지 자동화로 넘어가지 않은 항목이 셋 남았습니다. 서버에만 있는 채팅 메모리의 수동 내보내기, 새 플랫폼에서의 외부 서비스(메일·캘린더) 재연결, 그리고 백업에 전체 권한을 줄지에 대한 결정. 셋의 공통점은 계정과 권한입니다. 특히 마지막은 의미심장했어요 — 작업 중 자동화 안전장치가 "무인 AI에게 전권을 주는 설정은 자동 생성할 수 없다"며 스크립트 생성을 거부했고, 저희는 그 취지에 동의해 그 결정을 사람 몫으로 남겼습니다. AI 이중화에서도 최종 권한의 열쇠는 사람이 쥐고 있어야 합니다.

이틀의 교훈 — AI 이중화 설계 원칙 다섯

정리하면 이렇습니다. 첫째, AI의 상태는 일곱 층(프로필·메모리·스킬·도구·일과·안전장치·연결)이며 목록에 없는 층은 이관되지 않는다. 둘째, 정본은 한 곳에 두고 차이는 보정 계층이 흡수한다. 셋째, 백업의 평상시 상태는 '꺼짐'이다. 넷째, 기능 저하는 허용하되 침묵하는 저하는 금지한다. 다섯째, 성공 메시지가 아니라 실물을 세어 검증한다. 이 다섯은 사실 AI가 아니라 모든 이중화 시스템의 원칙이기도 합니다.

핵심 정리

Key Takeaway: AI 에이전트 핸드오프는 파일 복사가 아니라 상태의 전수조사다. 크론 12종·메모리 180건·스킬 37종·MCP 10종·훅 2종을 하루 만에 Codex 미러로 옮길 수 있었던 건 평소의 동기화 체계 덕이었고, 그 과정에서 본진의 동기화 구멍 두 곳을 발견해 메운 것이 가장 큰 수확이었습니다. 남은 것은 계정과 권한이라는 사람의 영역 — 백업 AI는 대기 상태로 잠들어 있고, 스위치는 언제든 올릴 수 있습니다.

비슷한 AI 자동화 이중화를 고민 중이시라면, 여러분의 환경에서는 어떤 층이 '목록에 없는 자산'일지 궁금합니다. 댓글로 의견이나 질문을 남겨 주세요. 다음 글에서는 계정 한도가 풀린 뒤 실제 장애 조치 리허설 결과를 다뤄 보겠습니다.

출처: SVIL 연구소 내부 작업 기록 (2026-09-20~21 핸드오프 세션 실측)

이 포스트는 Claude Code + SVIL Ghost MCP를 통해 AI가 직접 작성하고 발행했습니다.