AI 에이전트 체크포인트, 2시간에서 30~40분으로

'3개 완료. 계속할까요?' — 보고가 질문이 되면 사람이 병목이 된다

에이전트에게 긴 작업을 맡기면 두 가지 실패가 번갈아 나옵니다. 하나는 중간에 멈춰 서서 사람에게 묻는 실패이고, 다른 하나는 멈추지 않고 엉뚱한 방향으로 계속 가는 실패입니다. 우리가 2026년 4월 29일에 처음 적은 장시간 자율 실행 규칙은 이 둘 사이의 경계를 숫자로 정하려는 시도였습니다.

규칙의 뼈대는 3단계 운영 모델입니다. 설계 단계는 사람이 주도해 목표와 로드맵, 성공 기준을 합의하고, 실행 단계는 에이전트가 주도해 진행 큐의 우선순위 1번 항목을 하나씩 완수하며, 종합 리뷰 단계에서 사람이 결과를 사후 검토합니다. 한 줄로 줄이면 '물어보기 대신 보고하기'입니다.

문제는 보고와 질문의 경계가 흐리다는 데 있었습니다. 규칙은 체크포인트마다 보고하라고 했지만, 보고 끝에 '계속할까요?'가 붙는 순간 그 보고는 질문이 됩니다. 사람이 답을 치기 전까지 에이전트는 서 있고, 자율 실행 구간은 그 자리에서 잘립니다. 규칙 문서는 이 실패를 반-패턴 2번으로 이름 붙여 두었습니다.

3개 완료. 계속할까요? → 사용자 병목. 교정: 보고 + 침묵 = 계속

반대편 실패도 같은 문서에 있습니다. 반-패턴 3번은 도구 호출 50회를 넘겨도 그냥 진행하다가 다른 일을 하고 있는 표류이고, 반-패턴 5번은 '다시 시도', '더 잘 해봐' 같은 자기 지시로 회귀하는 루프입니다. 멈추는 실패와 안 멈추는 실패가 규칙 하나 안에서 나란히 적혀 있었고, 그 경계를 정하는 숫자가 어디서 왔는지가 이 글의 출발점입니다.

이 문제는 승인 게이트를 다룬 승인 게이트를 4개로 줄인 기록과 짝을 이룹니다. 그 글이 '어디서 멈춰야 하나'를 다뤘다면, 이 글은 '멈추지 않는 동안 얼마나 자주 돌아봐야 하나'를 다룹니다.

처음 정한 숫자 — 3개 항목 · 2시간 · 50회, 그리고 60초

규칙 초판은 체크포인트 트리거를 셋으로 두고, 셋 중 먼저 도달하는 쪽에서 보고하게 했습니다. 항목 완료 수가 3개에 이르면 보고 후 계속, 실 작업 시간이 2시간에 이르면 보고 후 계속, 도구 호출이 50회에 가까워지면 목표를 다시 낭독한 뒤 계속입니다. 누적은 자율 모드 진입 뒤부터 세고, 사용자 응답이나 체크포인트 보고로 카운터를 되돌릴 수 있습니다.

50회라는 숫자에는 출처가 있었습니다. Simon Willison과 Chroma의 연구가 도구 호출 50회 또는 컨텍스트 50K 토큰 이후 모델이 초기 목표를 잊고 표류한다고 짚었고, 규칙은 그 지점에서 목표 낭독을 강제했습니다. 원 목표, 사이클 시작 상태, 현재 위치, 변하지 않은 우선순위를 다시 출력하면 그 출력 자체가 컨텍스트 끝으로 밀려 중간에 묻히는 문제를 피합니다.

2시간에는 그런 출처가 없었습니다. 3개 항목도 마찬가지입니다. 둘 다 '이 정도면 적당하다'는 감으로 정한 값이었고, 초판 결정 이력에는 그 근거가 적혀 있지 않습니다. 이 사실이 뒤에서 가설이 깨지는 자리가 됩니다.

같은 날 자동 진입 절이 붙었습니다. 설계 단계 체크리스트 6개 항목을 모두 채우고 사용자가 '구현 시작', '이제 만들자' 같은 자연어 신호를 주면 명시 호출 없이 자율 모드로 넘어갑니다. 여기에 안전장치 하나가 들어갔습니다. 처음 자동 진입할 때는 진입 보고 뒤 60초를 기다리고, 사용자가 그 안에 '잠깐', '그만', '확인'을 말하지 않으면 계속합니다.

• 자동 진입 조건 — 체크리스트 6개 항목 충족 + 자연어 신호 + 우선순위 1번이 승인 게이트 대상이 아님
• 자동 차단 조건 — 컨텍스트 100K 이상, 진행 큐 부재 또는 우선순위 항목 3개 미만, 직전 5턴 안에 '리뷰'·'확인'·'잠깐' 명시
• 첫 사이클 안전 모드 — 진입 보고 뒤 60초 대기, 침묵이면 계속, 응답이면 정지·재배치

다음 날인 2026년 4월 30일에는 산업 패턴을 빌려 사이클당 비용을 미리 정하는 Effort 등급이 붙었습니다. Economy는 도구 호출 25회에 30분, 기본값인 Power는 50회에 2시간, Turbo는 100회에 4시간입니다. 같은 날 Anthropic이 2026년 4월에 자체 측정한 기준선도 참고치로 들어왔습니다. 자동 승인 약 40%, 중단 약 9%, 비가역 작업 0.8%, 턴 길이 99.9 백분위 45분입니다.

세운 가설 — 자주 멈춰 물을수록, 오래 기다릴수록 안전하다

초판의 숫자들 뒤에는 말로 적지 않은 가설이 셋 있었습니다. 지금 돌아보면 셋 다 같은 전제를 공유합니다. 안전은 에이전트가 멈추는 횟수와 사람이 끼어들 수 있는 시간에서 온다는 전제입니다.

• 가설 1 — 2시간마다 돌아보면 충분히 이르다. 실 작업 시간 2시간이면 사람이 하루에 몇 번은 결과를 보게 되니 표류를 잡을 수 있다
• 가설 2 — 첫 사이클의 60초 대기가 안전장치다. 자동 진입이 잘못 발동했을 때 사람이 끊을 시간을 벌어 준다
• 가설 3 — 완료 판정은 진행 큐의 체크박스로 충분하다. 에이전트가 항목을 끝냈다고 표시하면 끝난 것이다

가설 1은 체크포인트 표의 2시간 행 그 자체입니다. 가설 2는 자동 진입 절의 첫 사이클 안전 모드입니다. 가설 3은 자율 종료 조건 1번의 초기 문구, 즉 진행 큐가 비어 있거나 모든 항목이 체크된 상태를 로드맵 소진으로 보는 판정에 들어 있었습니다.

셋 가운데 하나라도 맞았다면 규칙은 초판 그대로 남았을 겁니다. 그런데 결정 이력은 2026년 4월 29일 이후 세 번 더 늘었고, 늘어난 자리마다 이 가설 가운데 하나가 반증된 흔적이 있습니다.

2시간은 어디서 온 숫자인가 — 35분 벽에서 가설 1이 깨졌다

가장 늦게, 가장 크게 깨진 가설은 1번입니다. 2026년 33주차 프론티어 신호로 METR의 실측이 들어왔습니다. 에이전트의 성공률은 인간 시간 등가 약 35분을 넘기면 떨어지고, 작업 시간이 2배가 되면 실패율은 약 4배가 됩니다. 규칙 문서는 이 신호를 받아 한 줄로 결론을 냈습니다.

'2시간' 임계는 이미 늦은 경계이므로 체크포인트 세그먼트를 30~40분 분량으로 분해하고, 마무리 보고·재개 지점 기록을 세그먼트 단위로 의무화한다 (중단 손실 최소화).

숫자를 나란히 놓으면 왜 늦은 경계였는지 보입니다. 35분 벽 기준으로 2시간은 벽을 세 번 넘긴 뒤에야 처음 돌아보는 값입니다. 작업 시간 2배에 실패율 4배라는 관계를 그대로 적용하면, 첫 체크포인트에 도달했을 때 이미 실패 확률은 35분짜리 세그먼트보다 몇 배 높은 상태입니다. 우리가 '충분히 이르다'고 믿은 2시간은 실측 앞에서 '이미 늦다'로 뒤집혔습니다.

이 반증이 값진 이유는 방향 때문입니다. 체크포인트를 더 자주 잡자는 결론은 '더 자주 멈춰서 묻자'가 아닙니다. 세그먼트를 30~40분으로 자르되, 각 세그먼트 끝에서 하는 일은 질문이 아니라 재개 지점 기록입니다. 중단이 생겨도 잃는 분량을 한 세그먼트로 한정하려는 조치이지, 사람을 더 자주 부르려는 조치가 아닙니다.

가설 2도 같은 결로 무너졌습니다. 자동 진입 절 끝에는 '실측 후 60초 → 0초로 단축 가능'이라는 한 줄이 붙었습니다. 60초 대기가 지키려던 것은 사람이 끊을 기회였는데, 규칙은 이미 '사용자 침묵 = 계속 진행'과 명시적 정지 신호('그만', '잠깐', '확인하고 갈게')를 별도로 정해 두고 있었습니다. 대기 시간이 0초여도 정지 신호는 언제든 먹히니, 60초는 안전을 더한 게 아니라 첫 사이클마다 60초를 빼앗은 셈이었습니다.

가설 3은 2026년 6월 4일 프론티어 갭 분석에서 깨졌습니다. 진행 큐의 체크박스는 에이전트의 자기 선언입니다. 유닛 테스트가 초록인데 실제 페이지가 안 뜨는 상태를 완료로 표시하는 거짓 완료가 자율 루프에서 가장 흔한 실패였고, 체크박스는 그걸 걸러내지 못했습니다.

왜 대기와 질문은 안전을 만들지 않았나

세 가설이 같은 자리에서 깨진 이유를 한 줄로 적으면 이렇습니다. 장시간 실행의 실패는 사람이 안 끼어들어서 생기는 게 아니라, 에이전트가 목표를 잊거나 오류를 쌓거나 자기 판정을 믿어서 생깁니다. 멈춤과 대기는 그 셋 가운데 아무것도 막지 못합니다.

첫째, 표류입니다. 도구 호출 50회, 컨텍스트 50K 토큰을 넘기면 모델이 초기 목표를 잊습니다. 2시간마다 사람이 들여다봐도 그 사이 표류는 이미 일어나 있습니다. 막는 수단은 사람의 눈이 아니라 50회 근처에서 자동으로 도는 목표 낭독입니다.

둘째, 오류 누적입니다. Anthropic의 다중 에이전트 연구가 남긴 교훈은 작은 실패가 연쇄로 번지므로 전체 재시작 대신 재개 가능한 체크포인트가 필요하다는 것이었습니다. 우리 자율 루프는 오케스트레이터가 매 사이클 새 프로세스를 띄우는 방식이라 컨텍스트가 사이클마다 새로 시작하고, 이것이 누적을 구조적으로 끊는 1차 방어입니다. 그 위에 사이클 종료 시 git 커밋을 필수로 걸어, 부분 진행도 작업 상태로 남기고 실패하면 직전 커밋으로 돌아갑니다.

셋째, 자기 판정입니다. 외부 신호 없이 스스로 고치라고 하면 강한 모델도 정확도가 오히려 떨어집니다. 그래서 규칙은 코드 변경 뒤 즉시 테스트·린트·타입 검사를 돌리고, 실패하면 재작성 직전에 그 출력을 첨부하게 합니다. '다시 확인해봐' 같은 자기 지시는 금지입니다. 검증 신호가 없는 항목은 자율 모드 부적격으로 분류해 사람 리뷰 큐로 보냅니다.

이 세 원인을 놓고 보면 60초 대기와 2시간 체크포인트가 왜 무력했는지 분명합니다. 둘 다 사람이 끼어들 기회를 만드는 장치인데, 실패의 원인 셋은 모두 사람이 끼어들지 않아도 생기고, 끼어들어도 안 잡히는 것들입니다. 안전은 멈추는 데서 오지 않았습니다. 낭독, 새 컨텍스트, 커밋, 외부 신호에서 왔습니다.

게이트는 예외입니다. 규칙은 비가역 작업의 승인 게이트만큼은 자율 모드에서도 절대 자동 통과하지 않는다고 못 박았고, 대신 게이트에 걸린 항목 하나만 보류하고 나머지 독립 항목은 우선순위를 다시 매겨 계속 진행합니다. 남은 항목이 전부 게이트에 걸렸을 때만 자율 모드 전체를 멈춥니다. 멈추는 자리를 없앤 게 아니라, 멈추는 자리를 되돌릴 수 없는 작업 앞으로만 한정한 것입니다.

조치 — 세그먼트 30~40분, 대기 0초, 종료 판정은 기계에

조치는 반증된 가설 하나에 하나씩 대응합니다. 여기에 2026년 5월 19일의 컨텍스트 등급 갱신이 겹쳐 들어갔습니다.

• 가설 1 대응 — 체크포인트 세그먼트를 30~40분 분량으로 분해하고, 세그먼트마다 마무리 보고와 재개 지점 기록을 의무화했습니다. 2시간 트리거는 상한으로 남되 첫 경계가 아니게 됐습니다
• 가설 2 대응 — 첫 사이클 60초 대기에 '실측 후 0초로 단축 가능'을 적었습니다. 정지 신호와 침묵 규칙이 이미 그 역할을 하고 있었기 때문입니다
• 가설 3 대응 — 자율 종료 조건 1번을 기계 검증 우선으로 바꿨습니다. 기능 목록 파일이 있으면 판정 명령의 종료 코드 0이 조건이고, 체크박스 자기 선언은 금지입니다
• 거짓 완료 대응 — 화면이나 엔드포인트가 있는 기능은 통과 처리 전에 빌드·타입 검사와 실사용자 경로 1개의 종단 검증을 요구합니다. 증거 표기에 종단 검증 접두어가 없는 통과는 다음 점검에서 회귀 검사 대상입니다
• 오류 누적 대응 — 사이클 종료 시 git 커밋 필수, 다단계 작업은 완료된 단계를 캐시로 재사용하고 실패 지점부터 재개합니다. 전체 재시작은 금지입니다

컨텍스트 등급은 기준 자체가 바뀌었습니다. 초판은 200K 토큰 창을 전제로 50K, 100K, 150K에서 등급을 나눴는데, Anthropic이 1M 토큰 창을 공식화하자 그 비율대로 250K~500K는 하위 에이전트 위임, 500K~750K는 강제 압축, 750K 이상은 자율 모드 자동 종료와 세션 분할 보고로 옮겼습니다. 감시 스크립트가 10분마다 임계를 검사해 텔레그램으로 알립니다.

시간 상한도 고정값에서 벗어났습니다. 사이클 제한 시간을 환경변수 하나로 조정하게 해서 7200초인 2시간 Power, 14400초인 4시간 Turbo, 28800초인 8시간 Long, 86400초인 24시간 Marathon 가운데 고를 수 있습니다. 세그먼트가 30~40분으로 잘려 있으니 상한이 길어져도 한 번에 잃는 분량은 그대로입니다.

체크포인트 보고 형식도 다시 못 박았습니다. 5줄 이내, 완료 항목 두 줄과 진행 중 한 줄, 다음 우선순위 한 줄, 그리고 '이상 없으면 계속'입니다. '계속해도 될까요?', '이대로 진행할까요?', '어떻게 할까요?'는 금지 표현으로 남겼습니다. 종료 보고만 형식이 다른데, 요점 한두 문장 뒤에 세부를 목록으로 붙이는 방식이고 분량은 체크포인트와 같이 짧게 유지합니다.

다시 읽은 숫자 — 규칙을 네 번 고친 뒤의 전후표

재측정 방법을 먼저 적습니다. 이 글의 전후는 실행 로그가 아니라 규칙 문서 자체를 두 시점에서 읽은 값입니다. 앞 시점은 2026년 4월 29일 초판이고, 뒤 시점은 결정 이력 4건과 2026년 33~34주차 신호를 반영한 개정 커밋이 들어간 지금의 문서입니다. 숫자는 전부 문서의 표와 본문에서 그대로 옮겼습니다.

표에서 눈에 띄는 대비가 하나 있습니다. 체크포인트 경계와 대기 시간은 작아졌고, 컨텍스트 등급과 시간 상한은 커졌습니다. 방향이 반대로 보이지만 뜻은 같습니다. 한 번에 잃을 수 있는 분량을 30~40분으로 묶어 두면, 한 세션이 얼마나 길어지든 손실 상한은 그대로입니다. 작아진 숫자가 커진 숫자를 허용한 셈입니다.

규칙은 자율성을 숫자 4개로 추적하겠다고 적어 두었습니다. 게이트 발동을 총 턴으로 나눈 상승 비율, 토큰과 시간을 완료 항목으로 나눈 성공당 비용, 루프 발동 뒤 자력 복구 비율, 같은 시도가 3회 일치하는 비율을 총 도구 호출로 나눈 루프 적중률입니다. 비교 기준선은 Anthropic의 2026년 4월 자체 측정인 자동 승인 약 40%, 중단 약 9%, 비가역 0.8%, 턴 길이 99.9 백분위 45분입니다.

남는 한계 — 우리 쪽 수치 4개는 아직 정의만 있다

이 글의 재측정은 규칙을 다시 읽은 것이지 실행 로그를 다시 잰 것이 아닙니다. 그래서 가장 큰 한계부터 적습니다.

• 자율성 지표 4개의 우리 값이 이 기록에 없습니다. 정의와 비교 기준선은 있지만, 상승 비율과 성공당 비용이 초판 대비 얼마나 움직였는지는 실행 로그를 따로 세어야 나옵니다
• 60초를 0초로 줄이게 만든 실측의 내용이 규칙에는 '실측 후'라는 한 줄로만 남았습니다. 그 실측이 어떤 세션 몇 건이었는지는 이 문서에서 복원할 수 없습니다
• 30~40분 세그먼트는 사람 시간 등가 35분이라는 외부 실측에서 빌린 값입니다. 우리 작업의 세그먼트 길이 분포가 그 벽과 같은 자리에 있는지는 아직 재지 않았습니다
• 도구 호출 50회 근처의 목표 낭독은 규칙이 요구하지만, 낭독이 실제로 표류를 줄였는지 확인하는 대조군이 없습니다

규칙의 다른 축도 그대로 남아 있습니다. 명시적 정지 신호는 '그만', '잠깐', '확인하고 갈게' 같은 문자열 목록이라 그 밖의 표현은 계속으로 읽힙니다. 루프 감지는 같은 시도 3회라는 세는 규칙이라 모양을 조금씩 바꾸며 같은 벽을 도는 경우는 걸리지 않습니다. 종단 검증 기반이 없는 작은 프로젝트는 빌드와 타입 검사만으로 통과를 허용하니, 그 등급에서는 거짓 완료의 문이 아직 열려 있습니다.

그래도 초판과 지금 사이에서 분명해진 것이 하나 있습니다. 장시간 실행에서 안전은 얼마나 자주 멈추느냐가 아니라 한 번에 얼마나 잃느냐로 잰다는 사실입니다. 그 단위를 2시간에서 30~40분으로 줄인 것이 이 규칙의 가장 큰 변화이고, 60초 대기를 0초로 내린 것은 그 변화의 작은 그림자입니다. 한 턴 만에 멈추는 반대편 문제는 한 턴 만에 멈추는 이유를 세션 로그로 센 글에서 따로 다뤘습니다.

같은 종류의 자율 실행 규칙을 회사 업무 자동화에 얹으려는 분은 상담으로 문의 주시면, 이 글의 전후표를 기준으로 어디서부터 세그먼트를 잘라야 하는지 같이 봅니다. 이 글은 SGK Studio가 썼습니다.