검증을 마쳤다고 생각했습니다. 하지만 6일 후, 저는 제가 전부 다 확인하지 못했다는 사실을 알게 되었습니다.

한 AI 기업의 엔지니어 중 매우 높은 비율이 자기 개선 에이전트 루프 (self-improving agent loops)를 운영하고 있다는 게시물이 제 피드에 올라왔습니다. 저는 출처를 확인하지 않은 숫자는 반복하지 않기에, 반응하기 전에 그것이 어디에서 왔는지 찾아보았습니다. 이는 단순히 조심성이 많아서가 아니었습니다. 만약 그 주장이 사실이라면, 저는 저만의 에이전트 플릿 (agent fleet)을 운영하는 방식을 재구축해야 했기 때문입니다.

공개된 기록에서는 그 문장을 찾을 수 없었습니다.

내가 실제로 발견한 것

세 가지의 별개이며 실제적인 사실들이 있었지만, 그 중 어느 것도 해당 주장과는 일치하지 않았습니다.

그곳의 한 엔지니어가 더 이상 코드를 수동으로 작성하지 않는다고 말하며, 하루 최대 약 150개의 풀 리퀘스트 (pull requests)를 기록했다는 보고가 있습니다. 저는 이에 대해 간접적인 이야기만 접했기에, 이를 측정값이 아닌 보고로서 전달합니다.

Anthropic의 리더십은 스크립트와 실험용 코드를 포함하여 그들 코드의 90% 이상이 Claude에 의해 작성된다고 공개적으로 추정했습니다. 그것은 추정치이며, 출처에서도 그렇게 명시하고 있습니다.

그리고 발표된 측정치가 있습니다. 2026년 5월 기준으로, 그들의 코드베이스에 병합된 코드의 80% 이상이 Claude에 의해 작성되었습니다.

모든 출처는 모델이 얼마나 많은 코드를 작성하는지를 설명했습니다. 얼마나 많은 인간이 루프 (loop)를 운영하는지에 대해서는 아무도 설명하지 않았습니다.

바이럴된 버전은 주어를 바꾸어 놓았습니다. 코드가 엔지니어가 되었고, 다른 내용에 관한 다른 문장에서 "90%"라는 숫자를 빌려왔습니다. 이런 일이 일어나기 위해 누군가 거짓말을 할 필요는 없었습니다. 단지 숫자가 명사 하나만큼 왼쪽으로 밀려났을 뿐입니다.

부재(Absence)는 어려운 부분이다

제가 주장하는 바에 대해 신중하고 싶습니다. 왜냐하면 바로 이 지점에서 팩트 체크 (fact-checks)가 보통 과잉 대응하기 때문입니다.

저는 여러 각도에서 검색하고, 주요 출처들을 뽑아냈으며, 확인하는 것이 아니라 오히려 그것을 '반박'하는 것이 임무인 검증가들에게 각 주장에 대해 이의를 제기하도록 했습니다. 결과는 만장일치였습니다. 하지만 무엇에 대한 만장일치였을까요? 그 문장이 존재하지 않는다는 것이 아니었습니다. 단지 제가 그 문장에 도달할 수 없었다는 것뿐이었습니다.

저는 이 정확한 간극 때문에 이전에 데인 적이 있습니다. 한 번은 grep 결과가 0건인 것을 무언가가 존재하지 않는다는 증거로 읽은 적이 있는데, 실제로 그랬습니다. 제 패턴(pattern)이 틀렸던 것이죠. 또한 검색 API의 "결과 없음"이 빈 집합(empty set)이 아니라 표시 제한(display cutoff) 때문이었던 적도 있었습니다. 검색 결과가 0건이라는 것은 당신의 검색이 멈췄다는 뜻이지, 세상이 비어 있다는 뜻이 아닙니다.

따라서 제가 옹호할 문장은 "공공 기록에서 그것을 찾을 수 없었다"이지, "그것은 존재하지 않는다"가 아닙니다. 이 둘은 서로 다른 주장이며, 그중 하나만이 제가 실제로 뒷받침할 수 있는 내용입니다.

하지만 검색을 통해 유용한 정보를 얻기는 했습니다. 2025년 10월부터 2026년 4월 사이에 약 235,000명의 사용자가 생성한 약 400,000개의 Claude Code 세션을 분석하여 발표된 연구에 따르면, 사람들은 계획 결정(planning decisions)의 약 70%를 내리지만 실행 결정(execution decisions)은 약 20%만 내린다는 사실이 밝혀졌습니다. 저는 제 설정에서 모든 실행 여부(go/no-go) 결정에 인간의 승인 단계(human gate)를 유지하고 있으며, 이 때문에 자동화가 느려진 것이라고 막연히 추측해 왔습니다. 알고 보니 그것은 이미 측정된 분업(division of labour)의 비율과 거의 일치했습니다.

그러고 나서 내 메모도 똑같은 검증에서 실패했다

6일 후, 저는 이 모든 내용의 요약본을 게시하려 했습니다. 저의 규칙은 숫자가 포함된 내용이 나갈 때는 연구가 이미 검증되었더라도 1차 자료(primary sources)를 다시 가져오는 것입니다. 며칠이 지나는 것은 데이터의 표류(drift)로 간주하기 때문입니다.

초안에는 네 가지 주장이 있었습니다. 세 가지는 유지되었지만, 하나는 그렇지 않았습니다.

제 연구 메모에는 "작업의 020%만이 완전히 위임될 수 있다"와 같은 내용이 기록되어 있었습니다. 하지만 해당 문구는 연구 어디에도 나타나지 않습니다. 연구 어디에도 "위임 가능한(delegable)"이라는 단어는 없으며, 020%라는 범위도 없습니다. 가장 가능성 높은 설명은 제가 "인간이 실행 결정의 약 20%를 내린다"라는 문장을 읽고, 이를 조용히 "작업의 0~20%가 위임될 수 있다"라고 다시 썼다는 것입니다. 이는 서로 다른 대상에 대한 다른 진술입니다.

즉, 타인의 수치에서 방금 잡아냈던 바로 그 교체(swap)를, 6일 후 제 자신의 요약본에서 똑같이 저지른 것입니다.

타인의 수치를 위해 구축했던 검증 시스템은 정작 저 자신에게는 실행되지 않았습니다.

그것을 잡아낸 것은 정교한 과정이 아니었습니다. 다각도 검색도, 적대적 검증기 (adversarial verifiers)도 아니었습니다. 단지 규칙에 따라 마지막 순간에 원본 문서를 다시 한 번 단순하게 재조회 (re-fetch)했을 뿐이었습니다.

간극은 검증에 있었던 것이 아니라, 회귀 경로 (return path)에 있었습니다.

이 부분이 실제로 제 작업 방식을 바꾼 지점입니다.

그 문장을 수정했을 때, 저는 발행될 게시물(outgoing post) 내에서 수정했습니다. 하지만 그 게시물을 만들어낸 연구 노트는 틀린 상태로 남았습니다. 그 노트는 작성된 날 이후로 수정 작업이 할당되지 않은 채 6일 동안 그대로 방치되어 있었고, 저는 이 글을 쓰기 위해 다시 돌아가 확인했을 때야 비로소 그 사실을 알아차렸습니다.

제 발행물에는 게이트(gate)가 있었지만, 그것을 뒷받침하는 노트에는 게이트가 없었습니다. 수정 사항은 결과물(artifact)을 향해 외부로 전달되다가 멈춰버렸습니다. 정작 수정이 필요했던 것은 그 결과물이 될 모든 것들의 상류(upstream)에 있었음에도 말입니다.

이제 그 문제는 해결되었으며, 저는 이를 단순히 주장하기보다 직접 보여드리고 싶습니다. 이제 노트에는 잘못된 수치에 취소선이 그어져 있고, 올바른 수치와 함께 날짜가 기입된 수정 표시가 있으며, 어떻게 발견되었는지에 대한 설명이 한 줄 적혀 있습니다. 노트를 조용히 편집해 버리면 무엇이 잘못되었었는지에 대한 어떠한 증거도 남지 않기 때문입니다. 다른 한 사람이 독립적으로 원본을 재조회 (re-fetch)하여, 원문에는 해당 단어나 범위가 전혀 포함되어 있지 않음을 확인했습니다. 그리고 누락되었던 단계는 하나의 규칙으로 기록되었습니다: 숫자를 수정할 때는 즉시 워크스페이스 전체를 grep하여 동일한 주장이 있는지 찾고, 모든 복사본을 제거(kill)할 것.

교훈 (Takeaways)

숫자로 된 어떤 주장이라도, 그것이 당신의 로드맵을 움직이게 하기 전에 반드시 1차 자료 (primary source)에서 **주어와 분모 (the subject and the denominator)**를 확인하십시오. 대부분의 바이럴 통계는 조작된 것이 아니라, 무언가 인접한 것을 설명하는 실제 숫자일 뿐입니다.

"찾을 수 없었습니다"와 "존재하지 않습니다"는 서로 다른 문장이며, 그중 하나만이 검증 가능합니다. 당신이 뒷받침할 수 있는 문장만을 말하십시오.

검증을 타인의 주장뿐만 아니라 당신 자신의 노트에도 실행하십시오. 그리고 수정 사항이 단순히 당신이 발행한 결과물에만 머무는 것이 아니라, 노트가 존재하는 곳까지 거슬러 올라가도록 만드십시오.

당신의 수정 사항은 어디로 향합니까: 게시물 속입니까, 아니면 다시 노트 속입니까?

출처 (Sources): When AI builds itself (>80% 측정값 및 90% 이상의 리더십 추정치) · How Claude Code is used in practice (~400,000 세션 분석 및 70%/20% 분할)

── Hideyuki Mori (Ayane International) 🔗 hideyuki-mori.com

[

hideyukimori image

](/hideyukimori)

HideyukiMORI팔로우

자체 호스팅 비즈니스 워크플로우를 위한 API 우선 (API-first) PHP 도구 구축. NENE2 및 NeNe OSS 시리즈 제작자.