Claude 코드 80%, Anthropic이 요구한 검증 가능한 일시정지

Anthropic Institute가 2026년 6월 10일 공개한 When AI builds itself는 제품 출시 글이 아닙니다. 글의 첫 번째 숫자는 내부 개발 공정입니다. Anthropic은 2026년 5월 기준 자사 production codebase에 merge되는 코드의 80% 이상이 Claude가 작성한 것으로 attribution된다고 밝혔습니다. Claude Code가 2025년 2월 research preview로 나오기 전에는 이 비율이 한 자릿수였다는 설명도 붙었습니다.

이 수치 하나만 보면 Claude Code가 잘 팔린다는 제품 홍보처럼 읽힐 수 있습니다. Anthropic이 글 끝에서 꺼낸 결론은 더 무겁습니다. 회사는 AI가 AI 개발 cycle을 점점 더 많이 맡는 방향이 full recursive self-improvement로 이어질 수 있다고 보고, frontier AI 개발을 늦추거나 일시정지할 수 있는 검증 가능한 글로벌 mechanism을 논의해야 한다고 썼습니다. 한 회사만 멈추는 선언이 아니라, 여러 frontier lab과 국가가 같은 조건으로 멈췄는지 확인할 수 있는 장치가 필요하다는 주장입니다.

이번 글의 독해 포인트는 과장된 singularity headline이 아니라 두 숫자의 충돌입니다. 하나는 내부 코드의 80% 이상을 Claude가 작성했다는 생산성 수치입니다. 다른 하나는 2026년 2분기 Anthropic의 typical engineer가 2024년 대비 하루 merge code를 8배로 늘렸다는 operational 수치입니다. Anthropic은 lines of code가 품질 생산성 지표로 불완전하다고 caveat를 달았지만, frontier lab 내부에서 code authoring, experiment loop, review unit이 이미 바뀌었다는 증거로 제시했습니다.

Anthropic의 footnote는 80% 수치가 내부 leadership이 공개적으로 말한 90% 이상보다 보수적이라고 설명합니다. 이유는 두 가지입니다. 첫째, attribution pipeline에는 gap이 있습니다. 둘째, Claude로 attribution되지 않은 줄에는 사람이 직접 쓴 코드뿐 아니라 autogenerated artifact도 섞입니다. 이 대목은 개발팀이 바로 가져갈 수 있는 체크리스트입니다. AI 작성 코드 비율을 말하려면 editor plugin 사용량이나 prompt 수가 아니라 merge된 artifact의 provenance를 어떻게 잡을지부터 정해야 합니다.

제품팀 입장에서 더 직접적인 변화는 engineer 역할의 이동입니다. Anthropic 글은 엔지니어가 직접 typing하는 시간을 줄이고, Claude가 작성한 코드를 directing, reviewing, redirecting하는 시간이 늘었다고 설명합니다. 이 구조에서는 코드를 얼마나 빨리 쓰는가보다 어떤 task를 맡길 수 있는가, 중간에 takeover가 얼마나 자주 필요한가, reviewer가 어디까지 이해했는가가 품질 지표가 됩니다. Claude가 만든 diff가 많아질수록 human reviewer는 더 넓은 surface를 짧은 시간에 판단해야 합니다.

Anthropic은 모델의 독립 작업 길이도 함께 꺼냈습니다. 글은 METR time horizon 자료를 인용해 AI가 스스로 안정적으로 완료할 수 있는 task length가 최근에는 약 4개월마다 2배로 늘고 있다고 설명합니다. 2024년 3월 Claude Opus 3가 사람 기준 약 4분짜리 software task를 수행했다면, 2025년 Claude Sonnet 3.7은 약 1시간 30분 task, 2026년 Claude Opus 4.6은 12시간 task를 다뤘다는 식입니다. Anthropic이 말하는 recursive self-improvement의 전 단계는 바로 이 long-horizon work입니다.

여기서 recursive self-improvement를 엄밀히 나눠야 합니다. Claude가 회사 backend 코드를 고치거나 test harness를 작성하는 것은 AI 개발을 돕는 일입니다. Claude가 다음 모델의 training recipe, architecture, evaluation, data mix를 스스로 설계하고 검증하는 것은 다른 단계입니다. Anthropic도 full recursive self-improvement에 아직 도달하지 않았고, 필연적이지 않다고 적었습니다. 다만 frontier AI 연구에서 상당수 work unit이 scaling, experiment, debugging, result interpretation으로 이루어져 있고, 이 부분이 자동화될수록 연구 속도는 compounding될 수 있다고 봅니다.

Anthropic은 research taste를 남은 human bottleneck으로 둡니다. 어떤 문제를 풀어야 하는지 고르는 판단, 가짜 개선과 진짜 개선을 구분하는 감각, 좋은 benchmark와 나쁜 benchmark를 가르는 감각은 아직 사람 쪽에 남아 있다는 반론입니다. 글은 이 반론을 인정하면서도, 연구의 많은 부분이 한 번의 천재적 발상보다 반복 실험과 수정에 가깝다고 답합니다. 이 답변이 설득력을 가지려면 자동화된 실험이 benchmark 점수만 올리는지, production reliability와 safety case까지 개선하는지 별도 증거가 필요합니다.

개발자에게 이 논쟁은 멀리 있는 AI safety 문제가 아닙니다. 코드 작성자 attribution이 자동화되면 who wrote this?가 which model, which prompt, which tool, which approval path produced this?로 바뀝니다. 보안팀은 dependency provenance처럼 AI-generated diff provenance를 물어야 합니다. 플랫폼팀은 CI가 감당해야 할 PR 수, test shard, review queue를 다시 계산해야 합니다. Anthropic 글의 footnote는 GitHub가 2025년 전체 약 10억 commit을 처리했고, 2026년 중반에는 주당 2억7500만 commit pace를 보였다고 인용합니다. AI coding adoption이 증가하면 shared developer infrastructure가 먼저 압박을 받습니다.

Hacker News 반응은 이 간격을 잘 드러냅니다. 원문 스레드는 5일 전 기준 531 points와 702 comments를 모았습니다. 찬성 쪽은 frontier lab이 내부 수치를 공개했다는 점을 높게 봤습니다. 비판 쪽은 제목이 AI builds itself인데 본문 증거는 대부분 coding agent와 lines of code라고 지적했습니다. 한 댓글은 recursive self-improvement라면 모델 research program 자체를 자동화해야 한다고 구분했습니다. 다른 댓글은 Anthropic이 안전을 말하면서 동시에 그 방향으로 전력 질주하는 모순을 문제 삼았습니다.

이 반응은 글의 약점을 정확히 찌릅니다. AI가 AI를 만든다는 문장은 강하지만, 공개 증거는 production code, 설문, benchmark, internal quote의 조합입니다. Anthropic은 이를 숨기지 않습니다. 글 중간에 lines of code가 quantity를 재는 지표이며 true productivity gain을 과장할 수 있다고 적었습니다. 또 오늘의 training method와 architecture가 full recursive self-improvement capacity를 열 수 있는지는 불분명하다고 했습니다.

그럼에도 이번 글은 단순 marketing copy로 치우기 어렵습니다. Anthropic은 "좋은 코드"를 작동 여부와 다른 engineer가 이해하고 확장할 수 있는지로 나눕니다. 또한 Claude 작업 중 사람이 correction, redirection, takeover하는 비율이 1년간 낮아졌다고 말합니다. 이 부분은 일반 기업이 코딩 에이전트 rollout을 평가할 때도 쓸 수 있습니다. AI 작성 코드 비율보다 중간 takeover rate, review defect rate, rollback rate, incident contribution을 보는 편이 더 안전합니다.

일시정지 논의도 같은 방식으로 읽어야 합니다. Anthropic은 가능하다면 기술 발전을 늦춰 society structure와 alignment research가 따라잡을 시간을 버는 것이 좋겠다고 씁니다. 하지만 한 lab만 멈추면 덜 조심스러운 actor가 따라잡을 수 있어 모두가 덜 안전해질 수 있다고 덧붙입니다. 그래서 필요한 것은 선언이 아니라 verification입니다. 누가 멈췄는지, 어떤 training run이 pause 대상인지, 어떤 compute 사용이 허용되는지, 누가 판정하는지, 몰래 진행하는 actor를 어떻게 탐지하는지가 논점입니다.

이 부분은 핵무기 조약 비유와 다르면서도 닮았습니다. Anthropic은 Intermediate-Range Nuclear Forces Treaty 같은 verification regime을 언급하지만, AI training run은 missile silo보다 숨기기 쉽다고 적습니다. GPU cluster, data, algorithmic efficiency 연구는 모두 dual-use입니다. 기업이 "우리는 멈췄다"고 말해도 fine-tuning, synthetic data generation, evaluation automation, inference optimization 중 어디까지가 frontier development인지 합의하기 어렵습니다.

개발 조직은 이 governance 논의를 기다릴 필요가 없습니다. 당장 정할 수 있는 것은 내부 AI coding policy입니다. 첫째, AI-generated code attribution을 commit metadata, PR template, tool log 중 어디에 남길지 정해야 합니다. 둘째, model output이 만든 test와 사람이 만든 test를 구분해야 합니다. 셋째, reviewer는 diff를 읽는 사람인지, agent trace를 감사하는 사람인지 역할을 명확히 해야 합니다. 넷째, security-sensitive path에는 AI-written code 비율이 아니라 independent human validation 기준을 붙여야 합니다.

Anthropic 사례가 던지는 불편한 질문은 개발자가 필요 없어지는가가 아닙니다. 더 정확한 질문은 개발자가 검증하지 못하는 양의 코드를 책임지게 되는가입니다. AI가 8배 많은 code를 만들면 review capacity도 8배 늘어야 한다는 뜻은 아닙니다. 하지만 review 방법은 달라져야 합니다. 작은 diff 단위의 line review만으로는 agent가 만든 넓은 변경 surface를 따라가기 어렵습니다. architecture decision record, test coverage delta, runtime telemetry, rollback plan이 PR review 안으로 들어와야 합니다.

Anthropic이 공개한 80%는 frontier lab만의 특수한 숫자일 수 있습니다. Anthropic 직원은 Claude 내부 도구, 높은 model access, 강한 review culture, AI-native workflow를 가진 사용자입니다. 일반 기업이 같은 비율을 곧바로 기대하면 실패합니다. 특히 legacy codebase, 규제 산업, low-test repo, 느린 CI, 약한 observability에서는 agent output이 늘수록 병목이 작성에서 검증으로 이동합니다. 이 점에서 Anthropic 글은 생산성 광고보다 capacity planning 문서에 가깝게 읽어야 합니다.

이번 글의 가장 현실적인 결론은 recursive self-improvement가 내일 온다는 예언이 아닙니다. AI 개발의 앞단에서 사람이 쓰던 노동이 agent loop로 이동했고, 그 변화가 frontier lab 내부에서 이미 수치로 잡히기 시작했다는 보고입니다. 그 다음 병목은 model capability만이 아닙니다. provenance, review, evaluation, compute governance, 국제 검증이 한꺼번에 따라와야 합니다. Claude가 Anthropic 코드의 80% 이상을 쓴다는 숫자는 그래서 개발자에게도 정책 담당자에게도 같은 질문을 던집니다. 누가 썼는지보다, 누가 검증했는지를 어떻게 증명할 것인가.