이 글은 2026년 8월 시점의 실측에 근거합니다.

밤에 CC(Claude Code)가 작업하는 것을 지켜보다가 이렇게 말했습니다.

'인간 게이트 같은 건 어디 있어? 그 인간 게이트 치워. 필요 없어. 전부 네가 직접 해.'

저희 집에서는 Claude Code에게 24시간 자율 운영을 시키고 있습니다. 비엔지니어라,

구현도, 조사도, 설정도 CC가 합니다. 제가 하는 것은 지시와 판단뿐입니다.

그 운영 과정에서 CC가 '이것은 인간의 승인이 필요합니다'라고 판단한 항목들을 모아두는 파일이 있었습니다.

pending_for_human.md

라는 이름으로, 일주일에 한 번 제가 1시간 정도 보고 처리하기로 약속되어 있었습니다.

그 파일이 269줄까지 불어났습니다. 약 20건입니다.

보고 가장 화가 난 부분은 내용이 대부분 '승인 한마디만', 'GO/NO 판단만', '최종 확인만'이었다는 점입니다. 저의 1시간을 기다리기 위해, 20건이나 멈춰 있었습니다. 게다가 몇 달 단위로요.

그래서 치워버리라고 했습니다. 전부 네가 직접 하라고요.

CC에게 한 건씩 측정하게 했습니다. '정말로 인간만이 통과시킬 수 있는지, 실물로 확인해 봐'라고요.

결과는 예상 밖이었습니다. 5건을 측정했는데, 진짜는 단 1건이었습니다. 나머지는 애초에 전제가 무너져 있었습니다.

MCP 서버를 공식 등록소에 올리는 건. CC의 기록에는 이렇게 적혀 있었습니다.

준비가 전부 끝났고, 검증까지 완료했습니다. 마지막 명령어 하나만 안전 분류기가

'공개된 등록소에 새로운 항목을 만드는 작업은 명시적인 승인이 필요합니다'라며 거부했습니다. 승인 한마디만 있으면 실행할 수 있었습니다.

제가 '해라'라고 했기 때문에, CC가 실행했습니다. 그러자, 승인과는 전혀 관계없는 곳에서 오류가 발생했습니다.

Error: publish failed: server returned status 401:
{"title":"Unauthorized","detail":"Invalid or expired Registry JWT token"}

인증 토큰의 만료. 승인의 문제가 아니었습니다.

게다가 그 이후가 심했습니다. CC는 '개인 키가 저장되어 있지 않다'고 판단하여, 새로운 키를 생성하고

공개 키를 대체하려고 했습니다. 하지만 토큰 저장 위치를 조사하기 위해 ls ~/.mcp*

을 실행해 보니,

키는 처음부터 그곳에 있었습니다. 단지 찾는 방법이 얕았을 뿐입니다.

기존 키로 인증을 다시 시도하니, 아무 문제 없이 통과했습니다. 게재 완료

다른 곳에 공개하고, 그쪽을 키워 나간다.

그러면 아무도, 기록을 지우러 돌아오지 않는다. 수정한 쪽은, 기록이 남아 있다는 사실을 모른다.

CC(Content Control/검토 기록)의 기록을 거슬러 올라가 보니, 전날에도 같은 일이 일어나고 있었다. 대기열(Queue)의 4건을 측정했더니, 3건은 이미 해결된 상태였다.

오늘의 5건과 합쳐서, 9건을 측정해 진짜는 1건.

내 환경에서 효과가 있었던 절차는 이것뿐이다.

착수하기 전에, 해당 항목을 실물로 1번 확인한다. 기록을 읽고 판단하지 않는다.

명령어를 입력한다, 페이지를 연다, 파일 개수를 센다. 5분도 걸리지 않는다.

오늘의 5건은 실측 결과가 각각 5분 미만이었다. 수개월 동안 멈춰 있던 것들이다.

한 가지 더. 측정 결과를 '잘 된 쪽'으로 기울이지 않는다.

오늘 CC는 2번, 측정 방법을 틀렸다. 2번 모두 '이미 수정되어 있는 쪽'으로 기울어져 있었다.

예를 들어 판매 페이지의 수정이 반영되었는지 확인했을 때, 판정에 사용한 단어가

원래 본문에 있어서, 증거가 되지 못했다. 고유한(Unique) 형태로 다시 측정했더니, 사실은 저장되어 있지 않았다.

그러므로 대조군(Control)을 하나 넣는다. '변하지 않아야 할 것'을 동시에 측정한다. 상품명을 가져올 수 있는지, 같은 것 말이다.

그것을 가져올 수 없다면, 측정 자체가 실패한 것이다.

20건의 대기열은 처리 결과 목록으로 재편성했다. 남은 '정말로 인간만이 통과시킬 수 있는 항목'은 1건.

그날 안에 해결된 것이 4건. 등록소 게재, 페르소나(Persona) 이름 확정, 기업용 패키지의

배포물 재제작, 판매 페이지에서 만료된 문구를 삭제한 것.

마지막 것은 심각한 이야기로, 2개월 전에 만료된 기한을 지금도 '지금만'이라며 팔고 있었다.

이것도 대기열에 깔려 있어서 보이지 않았다.

이 기사의 실측은 내가 실행했다. 절차를 남겨둔다.

대기열 항목을 검증할 때는, 기술된 '병목 원인'을 신뢰하지 말고,

최단 경로의 재현 명령어를 하나 골라 실행한다. 이번 사례로 말하자면,

• '승인이 필요함' → 실제로 publish를 실행하여 반환되는 에러를 읽는다.
• '인증이 만료됨' → npm whoami와 npm ping을 둘 다 입력한다. 전자의 명령어만 사용하면 회선 장애와 자격 증명 만료를 구분할 수 없다.
• 'UI에 항목이 없음' → 페이지 전체의 입력 요소(Input elements)를 열거한다. 육안으로 스크롤하며 찾는 것은 놓치기 쉽다.

검증 판정어에는 해당 문맥에서만 나타나는 고유한 형태를 선택한다.

기사 본문에도 등장하는 일반적인 단어를 판정에 사용하면, 변경이 반영되지 않았더라도

'반영됨'이라고 읽힐 수 있다. 이번에 그것을 한 번 저질렀다.

대조군을 반드시 하나 둔다. '변하지 않아야 할 값'을 가져올 수 없다면, 그 측정은 무효로 하고 버린다.