멀티머신 에이전트 하네스, 스킬이 조용히 꺼져도 아무도 모른다

여러 대의 머신에서 같은 에이전트 하네스를 돌리고 있고, 그중 한 대에서 스킬이나 룰이 슬그머니 꺼진 채로 작업이 계속 진행되는 상황을 겪어본 엔지니어라면 이 글이 바로 그 문제를 다룹니다. 스킬과 룰을 심링크로 켜고 끄는 멀티머신 하네스에서, 세션이 시작될 때마다 상태를 점검하는 방식과 일정 주기로 전체를 훑는 방식 중 어느 쪽이 드리프트를 더 빨리 잡아내는지를 20회의 장애 주입 시뮬레이션으로 답한 논문입니다. 결론부터 말하면 평균 체크 간격이 완전히 같아도 주기적 스윕이 세션 트리거 방식보다 탐지 시간을 절반으로 줄입니다. 그 이유는 우연이 아니라 renewal theory에 나오는 검사역설(inspection paradox)입니다.

침묵하는 기능 손실이라는 문제

요즘 LLM 에이전트 하네스는 능력을 프롬프트 안에 다 밀어넣지 않고 버전 관리되는 파일로 빼내는 구조를 씁니다. 재사용 가능한 스킬과 상시 적용되는 행동 룰이 저장소에 파일로 존재하고, 하네스는 실행 시점에 그중 무엇을 에이전트에게 보여줄지 결정합니다. 머신이 한 대뿐이면 이 결정은 간단합니다. 저장소에 있는 건 전부 쓰면 됩니다. 머신이 여러 대면 이야기가 달라집니다. 같은 저장소가 개인 워크스테이션과 조직 워크스테이션에 각각 클론되고, 두 환경의 요구사항은 서로 다릅니다. 한쪽에서는 적절한 스킬이 다른 쪽에서는 부적절하거나 정책 위반일 수 있습니다.

그래서 자연스럽게 두 겹짜리 설계가 나옵니다. 버전 관리되는 작은 매니페스트인 머신 스코프 레지스트리가 어느 머신 부류에서 무엇이 활성화돼야 하는지를 선언합니다. 그리고 머신별 토글 레이어가 실제로 무엇이 켜져 있는지를 기록합니다. 이때 콘텐츠를 지워버리는 대신 가벼운 파일시스템 간접 참조, 즉 심볼릭 링크의 유무로 토글을 구현하는 게 핵심입니다. 콘텐츠를 지우면 감사 추적이 사라지고 되돌리기도 비싸지기 때문입니다.

이 설계는 싸고 되돌릴 수 있고 들여다보기 쉬워서 매력적이지만 구조적 약점이 하나 있습니다. 두 레이어가 서로 어긋날 수 있다는 점입니다. 레지스트리는 git으로 동기화되니 빠르게 수렴하지만, 토글 레이어는 머신 로컬이고 의도적으로 버전 관리에서 빠져 있습니다. 한쪽에서 무언가를 끈 행동이 다른 쪽에 삭제로 그대로 전파되는 걸 막기 위해서입니다. 그 대신 이 레이어는 수동 개입, 부분 동기화, 호스트명 변경, 같은 머신에서 벌어지는 동시 세션 간 경합으로 흐트러질 수 있습니다. 어긋남이 벌어져도 아무것도 죽지 않습니다. 에이전트는 여전히 실행되고 여전히 답을 내고 여전히 그럴듯한 결과물을 만듭니다. 다만 원래 가졌어야 할 능력 없이, 혹은 없었어야 할 능력을 가진 채로 그렇게 합니다. 이 논문은 이 현상을 침묵하는 기능 손실(silent capability loss)이라 부릅니다. 특별히 그것을 잡으려고 계측해두지 않는 한 눈에 보이지 않는다는 게 이 실패 양상의 정의적 특징입니다.

실험을 어떻게 설계했나

논문이 다루는 저장소의 복구 메커니즘은 자기치유(self-healing) 점검입니다. 로컬 토글 상태를 레지스트리와 비교해 불일치를 전부 고치는 방식이고, 관례적으로는 세션 시작 시점에 발동합니다. 어차피 에이전트가 부팅되는 시점이니 비용이 이미 벌어지는 이벤트에 자연스럽게 얹히고, 매 세션이 검증된 상태에서 시작한다는 직관이 있습니다. 저자들은 이 직관이 흥미롭게 틀렸다는 것을 보여줍니다.

이를 검증하기 위해 저자들은 통제된 장애 주입 시뮬레이션을 만들었습니다. 머신 5대, 머신당 스킬·룰 50개, 총 250개 상태 셀을 두고 2000 스텝 동안 각 셀이 독립적으로 확률 0.0002로 드리프트하도록 만듭니다. 그리고 두 가지 탐지 전략을 정확히 공정한 조건에서 경쟁시킵니다. 첫째는 세션이 시작될 때마다 그 머신의 셀만 스캔하는 이거(Eager) 전략이고, 세션은 머신당 스텝마다 확률 0.05로 시작합니다. 둘째는 20스텝마다 전체 5대 머신, 250개 셀을 한꺼번에 스캔하는 스윕(Sweep) 전략입니다.

여기서 핵심 설계 선택이 있습니다. 세션 확률 0.05는 평균 대기시간이 정확히 20스텝이 되도록 고른 값이고, 이는 스윕의 고정 주기 20스텝과 정확히 같습니다. 즉 두 전략의 머신당 평균 체크 간격을 완전히 동일하게 맞춘 뒤에 비교합니다. 이렇게 해야 어느 한쪽이 더 자주 체크해서 이긴다는 반론이 애초에 성립하지 않습니다. 시뮬레이션은 시드 10개씩, 전략당 총 20회 실행됐고 순수 파이썬으로 약 100줄, GPU 없이 CPU 단일 코어에서 돌아갑니다. 이건 모델 추론 실험이 아니라 상태 관리 실험이기 때문입니다.

결과: 같은 평균 간격인데 스윕이 두 배 빠르다

측정 결과는 명확합니다. 스윕의 평균 탐지 지연은 9.41스텝, 이거의 평균 탐지 지연은 19.23스텝으로 51% 차이가 납니다. 두 전략의 머신당 평균 체크 간격이 똑같이 20스텝인데도 이 정도 격차가 벌어집니다. 꼬리 지연은 격차가 더 큽니다. 이거의 95번째 백분위 지연은 시드에 따라 41스텝에서 78스텝까지 흔들리는 반면, 스윕은 모든 시드에서 일관되게 17에서 19스텝 사이에 머뭅니다. 이유는 구조적입니다. 이거의 최악의 경우는 원리적으로 무한합니다. 세션을 거의 시작하지 않는 머신은 체크를 촉발할 이벤트 자체가 없으니 임의로 오랫동안 방치될 수 있습니다. 반대로 스윕의 최악의 경우는 W=20스텝으로 구조적으로 상한이 걸려 있고, 실측된 p95 17~19스텝은 정확히 그 상한 바로 안쪽에 위치합니다.

CPU 전용 컨테이너에서 시드 10개, T=2000스텝, 상태 셀 250개를 집계한 실측 결과입니다. 이거의 p95는 시드별로 41~78스텝, 스윕의 p95는 모든 시드에서 17~19스텝으로 일관됩니다.

솔직하게 짚어야 할 부분도 있습니다. 스윕이 모든 축에서 이기는 건 아닙니다. 거짓 음성률은 이거 1.30%, 스윕 1.40%이고 실행 종료 시점의 잔여 드리프트는 250개 셀 중 각각 0.8개, 0.9개입니다. 시드 10개 수준에서 이 차이는 통계적으로 구분되지 않고, 그나마 방향도 스윕에 유리하지 않습니다. 두 전략 모두 실행 구간 안에서 드리프트 이벤트의 약 98.6~98.7%를 결국 잡아내며, 남는 잔여는 실행이 끝나기 직전에 주입돼 애초에 잡힐 기회가 없었던 이벤트가 대부분입니다. 스윕이 이기는 건 지연과 지연의 편차이지, 탐지 완결성이 아닙니다.

스윕이 이기는 이유: 검사역설

똑같은 평균 간격에서 왜 이런 차이가 나는지를 설명하려면 분산을 봐야 합니다. 스윕의 체크 간격은 결정론적입니다. 매 사이클 정확히 20스텝, 분산은 0입니다. 이거의 체크 간격은 성공 확률 0.05인 독립 베르누이 시행 사이의 대기시간, 즉 기하분포를 따릅니다. 기댓값은 1/0.05 = 20으로 스윕과 정확히 같지만 분산은 (1-p)/p² = 380이나 됩니다. 이 분산이 이차모멘트에 반영되면 이거는 E[T²] = 380 + 400 = 780, 스윕은 E[T²] = 400으로 벌어집니다.

여기서 중요한 건 드리프트 이벤트가 체크 경계에서 정확히 발생하지 않는다는 사실입니다. 진행 중인 어떤 체크 간격 안의 임의의 지점에서 주입되고, 우리가 측정하는 건 그 지점부터 다음 체크까지 남은 대기시간, 즉 전진잔여시간(forward recurrence time)입니다. renewal theory는 임의로 삽입된 지점에서 본 기대 잔여수명을 E[R] = E[T²] / (2E[T])로 줍니다. 이는 결정론적인 경우를 빼면 평균 간격의 절반과 다릅니다. 스윕에 대입하면 400/40 = 10, 이거에 대입하면 780/40 = 19.5가 나오고, 실측값 9.41과 19.23은 이 예측과 거의 일치합니다. 두 값의 비율 780/400 = 1.95는 실측된 격차 약 2배와 사실상 같은 숫자입니다.

renewal theory의 잔여수명 공식 E[R] = E[T²] / (2E[T])을 그대로 적용한 계산입니다. 결정론적 스윕은 20²/(220) = 10, 기하분포 이거는 780/(220) = 19.5로, 실측 격차(9.41 대 19.23)와 정확히 맞아떨어집니다.

이 현상은 버스 대기시간 역설로도 불리는 고전적인 검사역설입니다. 불규칙하고 메모리 없는 도착 과정은 임의의 관찰자 입장에서 크기 편향됩니다. 짧은 간격보다 긴 간격 안에 들어갈 확률이 높은데, 긴 간격이 타임라인에서 더 많은 시간을 차지하기 때문입니다. 그래서 기대 대기시간은 결정론적 스케줄과 평균이 같아도 그 절반보다 부풀려집니다. 이거가 매 세션 하는 일은 사실 스윕과 총 비교 작업량 면에서 거의 같기도 합니다. 이거는 실행당 약 495.8회 체크하며 매번 머신 하나의 셀 50개를 스캔해 총 24,790번의 셀 비교를 합니다. 스윕은 실행당 약 99.0회 체크하며 매번 250개 셀 전체를 스캔해 총 24,750번을 비교합니다. 두 값의 차이는 0.2% 미만입니다. 다만 스윕은 그 작업을 5분의 1의 체크 이벤트에 압축해 담습니다.

총 비교 작업량은 이거 24,790회, 스윕 24,750회로 사실상 동일하지만, 체크 이벤트 수는 이거 495.8회, 스윕 99.0회로 스윕이 5분의 1입니다. 프로세스 기동, 세션 시작 훅 지연, 그 결과를 보고하는 토큰 비용처럼 이벤트마다 붙는 고정비를 스윕이 5분의 1로 줄인다는 뜻입니다.

여기서 나오는 실무 규칙은 값싸고 일반적입니다. 배포, 요청, 로그인처럼 변동성이 큰 이벤트에 상태 점검을 얹어 쓰고 있다면, 그 이벤트와 동일한 평균 발생률의 고정 주기 타이머로 바꾸는 것만으로 탐지 지연이 대략 절반으로 줄어듭니다. 총 점검 작업량은 그대로 두고 분산에서 오는 검사역설 페널티만 제거하는 방식입니다. 다만 저자들은 두 전략이 상호 배타적이지 않다고 강조합니다. 세션 체크는 사실상 거의 공짜로 얹을 수 있는 기회주의적 보조층으로 남겨두고, 실제로 최악의 노출 시간을 상한 짓는 건 고정 주기 스윕에 맡기는 하이브리드가 실제 배포에서는 합리적입니다.

ThakiCloud와 그 너머의 의미

이 연구는 저희 자신의 멀티머신 하네스, 즉 집과 회사 두 대의 머신과 launchd 러너로 굴러가는 운영 환경을 실제로 겪은 실패 양상에서 출발했습니다. machine-scoped-jobs와 skill-worktime-gate 룰에 이미 기록된 사고들이 바로 이 침묵하는 기능 손실의 사례이고, 이번 연구는 그걸 정량화해 재사용 가능한 드리프트 감사와 자기치유 프로토콜로 만들어 다른 내부 하네스에도 적용할 수 있게 합니다. 더 넓게 보면 여러 조직이 노트북과 클라우드, 개발과 프로덕션처럼 여러 머신·환경에 걸쳐 에이전트 하네스를 굴리는 일이 늘어날수록 설정 드리프트는 측정 방법론 자체가 없는 구조적 신뢰성 위험이 됩니다. 이 논문이 제안하는 방식은 특정 인프라에 묶이지 않아서 LLM 에이전트를 넘어 어떤 분산 기능 플래그나 설정 시스템에도 그대로 적용됩니다.

과학적으로도 이 연구는 에이전트 능력 하네스에 특화된 상태 일관성 실패와 자기치유 수렴 시간을 정량적으로 처음 특성화했다는 의미가 있습니다. 관련 연구 중 에이전트의 행동 일관성, 즉 같은 태스크를 반복 실행했을 때 같은 도구 호출을 내는지를 측정하는 연구는 있었지만, 그건 모델의 확률적 정책이 갖는 속성입니다. 이 논문이 재는 상태 일관성은 그와 직교하는 축으로, 모델이 완전히 결정론적이더라도 존재할 수 있는 문제입니다. 고전적인 분산시스템의 자기치유·최종적 일관성 문헌은 에이전트 세션 자체를 치유 트리거로 모델링하지 않는데, 바로 그 지점이 이 논문이 새롭게 짚는 부분이기도 합니다.

한계

저자들은 이 연구가 증명하지 않는 것도 분명히 밝힙니다. 드리프트는 각 셀이 서로 독립적인 i.i.d. 베르누이 과정으로 모델링됐지만, 실제 드리프트는 뭉쳐서 발생할 가능성이 큽니다. 잘못된 병합 하나, 중단된 동기화, 머신 클래스 해석을 무효화하는 호스트명 변경 같은 사건은 한 머신의 여러 능력을 동시에 어긋나게 만들 수 있고, 이런 상관관계가 있으면 두 전략의 상대적 우위가 어느 방향으로든 바뀔 수 있습니다. 또한 시뮬레이션은 모든 머신이 공유하는 단일 정책 벡터만 다뤄서, 실제 프로덕션에서 벌어지는 머신 클래스별 레지스트리 충돌은 다루지 않습니다.

파라미터도 평균 간격을 정확히 맞추기 위해 세션 확률 0.05, 스윕 주기 20이라는 한 점만 시험했고, 이 비율을 그리드로 넓혀 교차점이 있는지 보는 건 앞으로의 과제로 남았습니다. 무엇보다 이 결과는 통제된 시뮬레이션에서 나온 것이지 실제 프로덕션 사고 데이터가 아닙니다. 절대적인 지연 수치는 비율과 형태로 읽어야지 프로덕션에서 그대로 재현될 예측값으로 읽으면 안 됩니다. 마지막으로 비교 대상은 이거와 스윕 두 전략뿐이고, 하이브리드 스케줄이나 적응형 주기, 드리프트 심각도에 따른 에스컬레이션 같은 대안은 이번 실험에서 다루지 않았습니다.

논문 상세 정보는 다음에서 확인할 수 있습니다: https://huggingface.co/datasets/thaki-AI/daily-paper-2026-08-13-skill-state-drift-self-healing