우로보로스를 연속으로 돌렸더니, 클로드코드 컴팩트가 통째로 멈췄다

점심 무렵, 한 참여자가 클로드코드의 컴팩트 작업이 끝나지 않는다며 도움을 청했다.

"컴팩트가 시간이 너무 오래걸리는데요"

이어 그냥 끄고 다시 시작해야 할지 물었지만, 곧바로 답이 붙지 않아 10분 넘게 대화가 비었다. 다른 참여자가 뒤늦게 다른 세션에서 새로 시작해도 된다고 답하자, 당사자는 재시작 방법을 다시 물었다.

몇 분 뒤 세 번째 참여자가 상황을 보고 놀란 반응을 남겼다. 컴팩트가 그 정도로 걸린다는 게 사실이냐고 되물으며 도대체 처리할 양이 얼마나 되길래 그러냐고 물었다. 당사자는 그제야 원인으로 의심되는 지점을 밝혔다.

"우로보로스 써서 연속적으로 했는데요."

우로보로스를 연속으로 여러 차례 돌린 뒤 컴팩트가 걸렸다는 것이었다. 스스로도 이게 문제인 것 같다며, 괜히 했다는 후회 섞인 반응을 보였다. 다른 참여자들의 진단이 이어졌다. 우로보로스를 많이 돌리면 그만큼 문서가 늘어나고, 그게 MCP 툴콜링 오류로 이어질 수 있다는 추측이었다. 옆에서 지켜보던 참여자도 MCP 오류 같다며 거들었다.

원인을 좁혀가는 대화 중에 하드웨어 사양도 드러났다. 당사자는 컴퓨터 사양 자체가 좋지 않다며 8GB 메모리로는 무리라고 털어놓았고, 전날 밤에도 같은 현상 때문에 창을 강제로 닫고 그날 아침 다시 시작한 참이라고 덧붙였다. 우로보로스 내부의 컴팩트 구조가 클로드코드 기본 컴팩트와 다른 게 아니냐는 질문도 나왔지만, 정확한 구조까지는 아무도 확신하지 못했다. 경험 많은 참여자 한 명이 이 지점에서 자신의 경험을 보탰다.

"저도 잘은 모르겠지만 경험상 울보 mcp 콜링이 잘 안되면 계속 병목이 생기면서 오래걸렸던 기억이 있어요"

그러면서도 컴팩트가 이런 식으로 걸리는 건 처음 본다고 덧붙여, 이번 사례가 흔한 패턴을 벗어난 수준이라는 점도 짚었다. 대화 말미, 당사자는 이 현상을 더 깊이 파고들 연구 가치가 있는지 물었다. 돌아온 답은 짧고 단호했다.

"굳이요..?"

이유를 묻자 어차피 툴콜 오류가 아니면 기능 오류 수준일 뿐이라 유의미한 분석 결과가 나올 것 같지 않다는 설명이 붙었다.

이 디버깅 대화는 결론에 도달하지 못한 채 끝났지만, 그 자체로 우로보로스처럼 반복 실행형 MCP 도구를 저사양 환경에서 연속으로 돌릴 때 드러나는 위험을 보여준다. 원인으로 지목된 후보는 셋이었다 — 문서량 누적, MCP 툴콜링 오류, 그리고 8GB 메모리라는 하드웨어 한계. 어느 것 하나로 단정되지 않았다는 사실 자체가, 반복 실행형 에이전트 도구의 장애가 단일 원인보다 여러 조건이 겹쳐 나타나는 경우가 많다는 걸 시사한다.

원인을 끝까지 추적하기보다 짧은 한마디로 대화가 마무리된 점도 눈여겨볼 대목이다. 실무 커뮤니티에서는 재현이 어렵고 이득이 불확실한 버그는 근본 원인 규명보다 빠른 우회(세션 재시작)로 넘어가는 경우가 많다는 걸 이 대화가 보여준다.