AI 에이전트 세션 자동 인계, 세 가지 방법 다 실패하고 되돌렸다

나는 텔레그램 /blog 명령으로 에이전트 하네스 omo의 장기 작업 세션에 블로그 작업을 넘긴다. 2026년 9월 15일, 긴 컨텍스트에서 GPT가 작업을 처리하지 못한다는 문제를 풀려고 대화 기록 없이 새로 실행하는 /blog --fresh를 만들었다. 실전 검증에서 세 방식이 모두 timeout으로 실패했고, 나는 이 기능을 통째로 되돌렸다.

대상은 긴 세션 문제를 "새 세션으로 자동 인계"로 풀려는 개발자다. 이 글은 성공 방법이 아니라 실패 기록이다. 모델을 바꾸는 것과 세션을 분리하는 것이 어떻게 다른지, 무엇을 시도했고 어디서 멈췄는지를 정리한다.

모델만 바꾸는 것은 답이 아니었다

먼저 떠오르는 방법은 모델 전환이다. 내 브리지에는 이미 모델 선택자가 있었다. /blog --model <선택자> …는 그 요청만 지정 모델로 처리하고 원래 모델로 돌아오며, --model-sticky는 바꾼 모델을 유지한다.

하지만 기록에 남긴 판단은 이렇다. 모델만 바꾸는 방식은 기존 85MB 세션을 그대로 넘기므로 해결책이 아니다. --model은 기존 장기 세션의 컨텍스트를 그대로 쓴다. 모델 전환은 "어떤 모델이 읽느냐"를 바꾸고, 세션 분리는 "무엇을 읽느냐"를 바꾼다. 컨텍스트 문제에는 후자가 필요했다.

만들었던 구조

/blog --fresh 모델별칭 작업내용을 OpenClaw 플러그인에 추가했다. 이 경로는 요청 폴더와 장기 세션 확장을 거치지 않고 worker 스크립트를 detached process로 띄운다. worker는 omo를 세션·확장·프롬프트 템플릿 없이 별도로 실행하고, 결과만 원래 텔레그램 메시지에 답장으로 보낸다. 기록된 실행 형태는 다음과 같다.

omo --no-session --no-extensions --no-prompt-templates --print

기존 세션, 파일, 예약은 지우지 않았다. fresh 실행 자체의 대화 기록만 저장하지 않았다.

새 실행은 빈 상태에서 시작하므로, 작업에 필요한 운영 맥락을 어떻게 넣을지가 남는다. 세 방식은 모두 그 넣는 방법을 바꾼 시도였다.

세 방식 모두 timeout

시도맥락을 넣은 방법설정결과
1전체 HANDOFF/DECISIONS 문서를 모델이 직접 읽게 함high thinking15분 timeout
2문서를 Node가 프롬프트에 inlinelow thinking, 표준 Astra5분 timeout
3범위를 제한한 참조용 스냅샷 + prompt-file + 자동 fallback표준 Astra / Astra-fast / gpt-5.6-sol45초 / 180초 / 180초, 모두 SIGTERM timeout, stderr 없음

1번 시도에 쓴 모델은 기록에 없다. 각 시도에 넣은 문서 크기도 남기지 않았다.

세 번째는 문서 전체 대신 범위를 제한한 스냅샷을 넣은 시도였지만 결과는 같았다. 모델을 바꿔 가며 fallback해도 모두 timeout이었고, stderr에는 아무것도 남지 않았다.

대조 실행: 작은 입력은 즉시 성공

반면 작은 prompt-file로 Astra-fast에 PROMPT_FILE_READY라는 응답만 요구하자 즉시 성공했다.

기록은 이 대조를 이렇게 해석했다. 인증, 모델, @file 입력은 정상이고, 운영 맥락을 넣은 omo 독립 실행 경로가 안정적이지 않다. 세 시도가 정확히 어느 단계에서 멈췄는지는 기록에 없다. 맥락의 크기가 원인이라고 단정할 근거도 없다.

기능을 되돌린 결정

세 접근이 실패한 뒤 /fresh 구현, worker, 문서, 실험 상태 파일을 모두 롤백했다. 기존 텔레그램 브리지만 남겼고, 전체 테스트 40개가 통과했으며 gateway 재시작 응답도 ok/restarted였다. 그 뒤로 /blog --fresh는 지원하지 않는다.

같은 기록에서 모델 선택자 동작도 정리했다. /blog --model 아스트라만 보내면 다음 요청부터 Astra를 쓰고, /blog --model 아스트라 상태보고처럼 작업 내용이 붙으면 그 요청만 Astra로 처리한 뒤 원래 모델로 돌아온다. 이 동작의 회귀 테스트 28개가 통과했다. 다시 말하지만 이것은 모델 전환이고 컨텍스트 문제의 해결책이 아니다.

당시 기록이 긴 컨텍스트 문제의 대안으로 적은 것은 수동 절차 하나다. 새 세션을 직접 만들고 HANDOFF 문서로 인계하는 방식이다. 기록은 이를 검증된 해결책이라고 적었지만, 몇 번 시도해 몇 번 성공했는지는 남기지 않았다. 그래서 여기서도 성공률을 말하지 않는다.

비슷한 기능을 만든다면

이 실패에서 내가 가져가는 순서는 이렇다. 일반 규칙이 아니라 이 한 번의 기록에서 나온 내 판단이다.

  • 컨텍스트 문제라면 모델 전환과 세션 분리를 먼저 구분한다. 같은 세션을 쓰는 한 모델을 바꿔도 읽는 양은 그대로다.
  • 맥락을 넣은 실제 작업을 돌리기 전에, PROMPT_FILE_READY 같은 작은 대조 실행으로 인증·모델·입력 경로를 먼저 통과시킨다. 그래야 실패했을 때 경로 문제와 맥락 문제를 나눠 볼 수 있다.
  • 세 방식이 모두 실패하면 네 번째를 붙이기보다, 지원하지 않는 기능으로 정리하고 코드와 상태 파일을 걷어낸다.

이 기록이 답하지 않는 것

  • 세 시도가 timeout에 이른 정확한 원인
  • 1번 시도의 모델, 각 시도에 넣은 문서 크기
  • 수동 HANDOFF 인계의 성공률

같이 보면 좋은 글

컨텍스트에 무엇을 남기고 무엇을 지울지는 컨텍스트 엔지니어링 새 규칙 — "지워라"가 통하는 규칙, 안 통하는 게이트에서 다뤘다. 측정 결과를 해석할 때 실제로 무엇을 재고 있었는지 의심해 본 사례는 Benchmark가 측정한 건 모델이 아니라 채점기였다 — Honcho/Hindsight 3 라운드 측정 후기에 있다. 긴 세션의 토큰 사용을 줄이는 방법은 Claude Code 토큰 낭비 줄이는 5가지 — 캐시 TTL 5분 단축 대응법을 보면 된다.

결론: 새 세션 자동 인계는 접고 수동 인계만 남겼다

모델만 바꾸면 기존 85MB 세션을 그대로 넘긴다는 판단에서, 긴 컨텍스트 문제를 풀려고 대화 기록 없는 독립 실행 /blog --fresh를 만들었다. 운영 맥락을 넣은 세 방식은 45초에서 15분 사이 timeout으로 모두 실패했고, 맥락 없이 PROMPT_FILE_READY만 요구한 대조 실행은 즉시 성공했다. 나는 기능과 상태 파일을 모두 롤백했고, 당시 기록이 남긴 대안은 새 세션을 직접 만들고 HANDOFF 문서로 넘기는 수동 절차뿐이다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

AI 코딩 스킬, 많을수록 좋을까 — 자산이 부채로 바뀌는 손익분기

이미지
AI 코딩 스킬은 자산이다. 처음 몇 개는 그렇다. 그런데 수가 늘면 세금이 붙는다. 어느 스킬이 뜰지 예측이 안 되고, 도구 출력이 컨텍스트를 먹고, 모델이 바뀌면 쌓은 걸 전부 다시 만진다. 스킬을 관리하는 앱이 시장에 나온 게 그 신호다. 만들지 말라는 게 아니다. 만든 만큼 쳐내야 자산으로 남는다. 스킬은 자산으로 시작한다, 그런데 요즘 개발자들이 자기 .claude 디렉터리를 통째로 공개한다. TypeScript 교육자 Matt Pocock도 스킬 묶음을 GitHub에 올렸다. 제목이 “Skills for Real Engineers”이고, 소개가 “내 .claude 디렉터리에서 바로”다. skills.sh 같은 스킬 레지스트리도 생겼다. 스킬이 자산인 건 맞다. 손으로 반복하던 작업을 트리거 한 줄로 줄인다. 결과도 매번 일정해진다. 그래서 다들 쌓는다. 그런데 같은 GitHub에 묘한 게 같이 뜬다. 스킬을 “관리하고 동기화하고 정리”하는 데스크톱 앱이다. skills-manager는 Cursor·Claude Code·Codex 등 15개 넘는 도구의 스킬을 한곳에서 관리한다고 소개한다. 자산을 관리하는 전용 앱이 필요해졌다는 건, 그 자산이 관리 대상이 됐다는 뜻이다. 관리 대상은 곧 부담이다. 여기서 질문이 갈린다. AI 코딩 스킬은 많을수록 좋은가. 다음 중 하나라도 있나 비슷한 일을 하는 스킬이 둘 이상이라, 어느 게 뜰지 헷갈린 적이 있다. 스킬 하나를 고쳤더니 엉뚱한 데서 다른 게 어긋난 적이 있다. 내가 무슨 스킬을 만들어뒀는지, 목록을 열어봐야 기억나는 적이 있다. 셋 중 하나라도 해당되면 이미 부채 구간에 발을 걸친 것이다. 세 신호를 하나씩 본다. 신호 1 — 어느 스킬이 뜰지 예측이 안 된다 스킬이 늘면 비슷한 트리거를 여럿이 주장한다. “리뷰”라는 말에 코드 리뷰 스킬도 반응하고, 글 리뷰 스킬도 반응한다. 그러면 매 요청마다 “어느 스킬을 부를지” 판별하는 비용이 붙는다. 자동 라우팅 점...
자세한 내용 보기

M4 Max 128GB 로컬 LLM 4종 속도 비교 — 실측 기록과 한계

이미지
M4 Max 128GB에서 로컬 LLM은 얼마나 빠를까? 이 글의 과거 표에서는 gemma4:latest가 88 tok/s로 가장 높고, gemma4:26b는 85 tok/s다. gpt-oss:120b 47 tok/s, qwen3.6:35b-a3b 25 tok/s가 뒤를 잇는다. 처리량 표이지 정답률이나 코딩 품질 순위가 아니다. 작성자: 닥터조지. 2026년 4월 게시 당시 측정 기록 / 편집 보완: 2026-09-23. 기존 수치는 그대로 보존했고 이번에 모델을 다시 실행하지 않았다. 초판 제목의 llama3.3 표기와 “26B가 가장 빠르다”는 도입은 표와 일치하지 않아 바로잡았다. 원문의 장비·런타임·모델 표기는 당시 기록이다. 표의 qwen3.6:35b-a3b 는 원문에서 사용한 축약 표기이며, Q8과 qwen3.6:35b-a3b-q8_0 표기는 당시 본문 기록에서 가져왔다. 모델 파일이나 digest를 이번에 확인한 것은 아니다. 원 프롬프트 전문, 모델 digest, 반복 횟수와 개별 원시 응답이 이 글에 없어 표의 숫자를 그대로 재현했다고 확인할 수는 없다. 특히 latest 는 고정 버전 식별자가 아니다. 아래는 M4 Max 128GB 한 대에서 기록한 네 모델의 처리량이다. 모델 구조, 양자화, 크기가 동시에 다르므로 어느 한 요인만의 효과를 분리한 실험으로 읽으면 안 된다. 모델 크기만으로 속도를 예측하기 어려운 이유 원문은 gpt-oss:120b 를 총 117B, 활성 약 5.1B의 MoE로 기록했다. 활성 파라미터 수만으로 실제 생성 속도를 계산할 수는 없다. 모델 구조에 따른 메모리 접근 차이는 가능한 설명이지만, 이 표는 메모리 대역폭이나 접근 패턴을 직접 계측한 자료가 아니다. 생성 속도 차이만으로 병목의 원인을 확정하지 않는다. 당시 표의 gemma4:26b 는 gpt-oss:120b 보다 높은 생성 처리량을 보였다. 다만 이 결과를 모든 Dense 모델과 MoE 모델의 우열로 일반화할 수는 없다. 같은 ...
자세한 내용 보기

Opus 5는 더 잘 쓰고, 더 AI답게 쓴다 — 세 모델 첫날 실측

이미지
Claude Opus 5가 나온 다음 날, 세 모델에게 같은 시험지를 줬다. 결과부터 적는다. 글 품질 점수는 신형일수록 올랐다. 그런데 문장 리듬은 신형일수록 고르게, 그러니까 더 AI답게 변했다. 여기서 “AI답게”는 말투가 기계 같다는 뜻이 아니다. 문장 길이와 어미가 균질해진다는 뜻이고, 그 균질함이 통계 탐지기가 AI 글을 잡아낼 때 쓰는 바로 그 지문이다. 발표는 두 가지를 팔았다 새 모델이 나오면 벤치마크 표부터 보게 된다. 그 표는 전부 만든 쪽이 자기 시험지로 채점한 결과다. 내 작업에서 뭐가 달라지는지는 표에 없다. 그래서 표를 덮고 시험지를 직접 만들었다. 7월 24일 발표에서 Anthropic은 크게 두 가지를 내세웠다. 하나, 자기 작업을 검증하며 성공할 때까지 반복하는 능력이 강해졌다. 둘, 응답이 더 명확하고 간결해졌다. 벤치 수치는 여기 옮기지 않는다. 이 글이 확인할 건 저 두 문장이 내 작업물에서 어떻게 나타나느냐다. 같은 시험지 두 장 시험지는 두 장이다. 첫째는 글쓰기다. 주제·허용 사실·문체 규칙을 고정한 한국어 블로그 초안 스펙을 만들어 세 모델에 원샷으로 줬다. 둘째는 코딩 진단이다. 내 수집기에서 한 달 넘게 죽어 있던 실제 버그(reddit 수집 429 연쇄 실패)를 읽기 전용으로 진단하게 했다. 모든 주장에 파일과 행 번호 인용을 의무로 걸었다. 대상은 Opus 4.8, Fable 5, Opus 5. 각 모델의 정체는 시스템 프롬프트 자기보고로 확인했다. 채점은 사람 감이 아니다. 글은 발행 글 29편에서 뽑은 결정론 밴드(파이썬 스크립트)와 10점 감점제 루브릭으로, 진단은 미리 고정해 둔 정답표와 인용 실물 대조로 매겼다. 실측 1 — 더 잘 쓸수록 더 고르다 숫자부터 본다. 지표 Opus 4.8 Fable 5 Opus 5 발행 글 기준 문장 길이 변주(변동계수) 0.316 0.220 0.274 0.417 이상 행 길이 변주 0.266 0.23...
자세한 내용 보기