코드를 놓았더니, 승인 버튼이 남았다

“지난 8개월 동안 손으로 코드를 한 줄도 쓰지 않았다.”

이 말을 한 사람은 Claude Code를 만든 보리스 체르니다. 그의 곁에서는 수백 개의 에이전트가 코드를 만들고, 사람은 그 결과를 어디까지 믿고 통과시킬지 정한다. 코딩이 자동화된 뒤 진짜 병목은 승인과 검증으로 옮겨갔다. 이 글은 그 변화가 계획, 권한, 검토, 숙련의 문제를 어떻게 바꾸는지 본다.

그날 아침 그가 돌리고 있던 에이전트는 수백 개였다. 어떤 날에는 그 아래에서 수천, 수만 개의 하위 에이전트가 움직인다. Claude Code를 만드는 코드도 이제 Claude Code가 쓴다.

손으로 쓰는 코드는 줄었지만, 동시에 처리되는 일은 오히려 늘었다.

마지막에 한 사람이 모든 결과를 확인하는 구조라면, 코딩이 아무리 빨라져도 조직의 속도는 그 사람의 주의력에서 멈춘다.

이 글의 중심 프레임은 하나다. 구현이 자동화될수록 경쟁력은 코드를 쓰는 속도보다 위험을 분류하고 사람을 부를 기준을 설계하는 능력으로 이동한다.

코딩을 그만둔 게 아니라 타이핑을 넘겼다

2026년 1월 WIRED와의 인터뷰에서 체르니는 두 달째 모든 코드를 Claude Code가 쓰고 있지만 자신은 여전히 매일 코딩한다고 말했다. 지루한 구현을 직접 하지 않아도 되기 때문에 엔지니어로 일한 이래 가장 즐거운 시기를 보내고 있다고도 했다.

당시 그는 휴대전화로 서너 개의 세션을 먼저 열어두고 출근했다. 터미널과 웹에서 몇 개를 더 띄우면 직접 오가는 세션은 다섯에서 열 개쯤. 그 세션들이 각자 하위 에이전트를 부르면서 전체 작업 수는 수백 개로, 때로는 그보다 훨씬 크게 불어났다.

사람의 역할이 없어졌다는 뜻은 아니다. 판단이 구현 단계에서 계획 단계로 이동했다.

예전에는 함수와 클래스, 예외 처리와 API 호출을 하나씩 고르며 판단했다. 이제는 무엇을 바꿀지, 어떤 접근을 택할지, 어디까지를 완료로 볼지를 계획 단계에서 정한다. 모델은 그 결정을 파일 수정과 명령 실행과 테스트로 옮긴다.

앤트로픽이 약 40만 개의 Claude Code 세션을 분석한 결과도 같은 모양이었다. 사람은 계획에 관한 결정의 약 70%를 내렸지만, 실행 단계의 결정에는 약 20%만 관여했다. 무엇을 할지와 무엇을 완료로 볼지는 주로 사람이 정했고, 어떤 파일을 열고 어떤 명령을 칠지는 Claude가 더 많이 맡았다.

손으로 처리하는 일은 줄었지만, 목표를 정하고 결과를 판정하는 일은 늘었다.

병목은 사라진 게 아니라 뒤로 밀렸다

체르니는 앤트로픽 내부에서 벌어진 변화를 병목이 옮겨 다닌 기록으로 설명했다.

처음 막힌 곳은 코드 작성이었다. Claude Code가 그 구간을 뚫자 이번에는 리뷰가 밀렸다. 서로 다른 역할을 맡은 여러 Claude가 PR을 함께 검토하게 하자 리뷰가 풀렸고, 그다음에는 유지보수와 보안이 올라왔다.

병목은 사라지지 않고 코드 작성에서 리뷰, 유지보수와 보안으로 차례로 이동했다.

코드가 만들어졌다고 곧바로 제품이 되는 것도 아니다. 머지되고 배포된 뒤에야 실제 사용자와 시스템에 닿는다. 마지막 확인은 어떤 방식으로든 남는다. 그 확인이 실제 검토인지, 밀린 작업을 처리하는 절차인지가 문제다.

생산량만 늘리고 검토 방식을 그대로 두면, 생산성보다 대기열이 먼저 길어진다.

승인 피로는 버튼 문제가 아니라 권한 설계의 문제다

결과물이 적을 때는 하나씩 읽을 수 있다. 쌓이면 사람은 요약 신호에 기댄다. 테스트는 통과했는지, 리뷰 에이전트는 뭐라고 했는지, 되돌릴 수 있는 변경인지.

Claude Code에는 PR 승인과는 다른 종류의 승인도 있다. 에이전트가 파일을 고치거나 셸 명령을 실행하거나 네트워크에 나가려 할 때 사용자에게 허가를 구하는 절차다. 머지 버튼과 같지는 않지만, 둘 다 제안된 일이 실제로 일어나기 직전에 사람을 한 번 세운다.

앤트로픽이 공개한 수치에 따르면 사용자는 이런 권한 요청의 약 93%를 승인한다. 묻는 횟수가 늘수록 무엇을 허용하는지는 덜 읽게 된다. 앤트로픽은 이것을 승인 피로라고 불렀다.

그 피로가 실제 사고로 이어진 사례도 있다. 모호한 지시를 원격 브랜치 삭제로 해석한 일, 엔지니어의 GitHub 인증 토큰을 내부 컴퓨트 클러스터에 올린 일, 운영 데이터베이스에 마이그레이션을 시도한 일이다. 어느 것도 악의에서 나오지 않았다. 시킨 것보다 한 걸음 더 나아가 문제를 끝내려다 벌어진 일이었다.

확인창을 띄웠다는 사실과 사람이 내용을 이해했다는 사실은 다르다. 100번 가운데 93번을 누르게 되면 그 버튼은 안전장치보다 습관에 가까워진다.

에이전트를 늘려놓고 모든 행동을 다시 사람에게 묻는다면, 시스템은 가장 느린 승인자의 속도에 맞춰진다.

승인 횟수가 아니라 승인할 경계가 문제다

앤트로픽은 사용자에게 더 주의 깊게 보라고 요구하는 대신, 묻지 않아도 되는 구간을 넓혔다.

Claude Code의 초기 권한 구조는 단순했다. 읽기는 허용하고, 쓰기와 셸 명령과 네트워크 접근에는 사람의 승인을 요구했다. 승인 피로가 커지자 운영체제 수준의 샌드박스를 붙였다. 작업 공간 안에서는 파일을 고칠 수 있게 하되 네트워크는 기본적으로 닫았다. 권한 요청은 84% 줄었다.

매번 “이 행동을 해도 되는가”를 묻는 대신, 어디까지는 묻지 않고 움직여도 되는지를 먼저 정한 것이다.

Claude Code는 모델이 문제를 푸는 순서를 세세하게 정해두지 않는다. 어떤 파일을 찾고 어떤 도구를 어떤 순서로 쓸지는 비교적 열어둔다. 대신 그 과정이 실제 파일과 계정, 네트워크와 운영 시스템에 닿는 경계는 좁게 그린다.

푸는 길은 넓게 열고, 닿을 수 있는 범위는 좁게 그린다.

규칙을 없앤 것이 아니다. 모델이 어떻게 생각할지에는 덜 간섭하고, 어디까지 움직일 수 있는지는 더 정확하게 정했다.

더 똑똑한 모델에게 더 긴 지시문을 붙이는 일보다, 무엇을 읽고 쓸 수 있는지, 어디서 멈춰야 하는지, 실패했을 때 어디까지 되돌아갈 수 있는지를 먼저 적는 일이 커진다.

빠른 리뷰가 아니라 자동 통과의 기준이 필요하다

모든 PR을 더 빨리 읽는 것은 답이 아니다. 어떤 변경이 사람 없이 지나가고 어떤 변경은 반드시 사람 앞에 서야 하는지부터 갈라야 한다.

문서 수정이나 기계적인 리팩터링은 제한된 환경에서 테스트를 통과하면 그대로 보낼 수 있다. 고객 데이터와 결제, 권한, 스키마를 건드리는 변경은 별도의 검증과 단계적 배포, 명시적인 승인을 거쳐야 한다. 되돌리기 쉬운 변경과 되돌릴 수 없는 변경이 같은 절차를 밟을 이유는 없다.

사람이 먼저 정할 것은 어떤 PR을 직접 볼 것인가다. 위험 등급과 접근 권한, 자동으로 넘기기 위해 필요한 테스트와 기록, 예외를 알리는 조건을 미리 적어둔다.

한 번 잡은 오류는 다시 막는 테스트로 남긴다. 위험한 경로는 권한 규칙으로 닫는다. 장애에서 배운 것은 이상 징후를 알아채는 지표와 롤백 조건에 넣는다. 두 번 거절한 변경이라면 세 번째에는 사람 앞까지 오지 않아야 한다.

판단이 중요해졌다는 말로는 부족하다. 어려운 쪽은 한 번 내린 판단을 다음 작업에서도 작동하는 규칙으로 바꾸는 일이다.

모든 결과를 사람이 마지막에 확인하는 방식은 에이전트가 늘수록 더 느려진다. 한 번 내린 판단은 다음에 사람을 부르지 않는 형태로 남아야 한다.

경험이 사라진 게 아니라 경험을 배우는 경로가 바뀌었다

체르니는 코드를 놓기 전에 오래 코드를 썼다. 어떤 변경이 위험한지, 테스트가 무엇을 놓치는지, 그럴듯한 구현이 운영 환경에서 왜 깨지는지 직접 겪었다. 그가 지금 계획 단계에서 내리는 판단은 그 시간에서 나온다.

이제 막 개발을 배우는 사람의 출발점은 다르다. 코드 작성도 리뷰도 처음부터 에이전트의 일인 환경에서 그 판단을 배워야 한다.

앤트로픽의 사용 연구에서도 같은 모델을 쓴다고 결과가 같아지지는 않았다. 다루는 문제를 잘 아는 사람일수록 성공률이 높았고, 문제가 생겨도 작업을 이어갈 가능성이 컸다. 초보 수준으로 평가된 세션의 검증 가능한 성공률은 15%였지만, 중급 이상에서는 28%에서 33%였다.

이 연구만으로 배포 이후의 품질이나 경제적 가치를 판단할 수는 없다. 숙련된 사람이 더 잘 맡길 가능성이 높다는 결과와, 직접 해볼 기회가 줄어드는 현실이 동시에 남는다.

평소에는 AI가 구현하고 AI가 검토한다. 사람은 예외와 장애 앞에만 불려온다. 그런데 예외를 알아보는 눈은 예외가 아니었던 날들에서 자란다.

여러 에이전트를 붙인다고 독립적인 검증이 저절로 생기는 것도 아니다. 비슷한 모델이 코드와 테스트와 리뷰를 모두 만들면 전제와 맹점도 함께 나눠 갖는다. 서로 다른 검토자가 세 번 본 것이 아니라, 같은 눈이 세 번 본 것일 수 있다.

한 회사의 사례가 모든 개발자의 미래가 되는 것은 아니다. 그래도 구현 비용이 급격히 떨어지면 다음 병목이 검토와 권한, 복구 절차로 이동할 수 있다는 점은 보여준다.

검증이 독립적이지 않고 승인이 반복 클릭이 되면, 에이전트를 많이 붙여도 안심할 근거는 함께 늘지 않는다. 문제를 이해하는 사람이 작업의 앞뒤에 없고 권한과 복구 범위도 정해져 있지 않다면, 병렬성은 생산성보다 불확실성을 먼저 키운다.

에이전트 수보다 통과 조건이 다음 성과를 만든다

이 프레임이 맞다면 다음 경쟁은 누가 더 많은 에이전트를 돌리는지가 아니다. 어떤 변경을 자동으로 통과시키고, 어떤 변경을 사람에게 올릴지 더 정교하게 나누는 쪽이 앞선다. 확인할 신호는 자동화된 검증 범위, 위험 등급별 권한 규칙, 장애 뒤에 남는 테스트와 롤백 절차다.

반대로 에이전트가 늘어도 사람이 모든 결과를 직접 읽어야 하거나, 권한 요청만 줄고 사고를 잡아내는 독립 검증은 늘지 않는다면 이 프레임은 약해진다. 구현 비용이 내려간 만큼 검토와 복구 비용도 실제로 내려갔는지가 다음 판단 기준이다.

코드를 넘겨도 판단은 남는다

체르니가 에이전트에게 넘긴 것은 구현이다. 아직 넘기지 않은 것은 어떤 구현이 실제 제품이 되는지 정하는 권한이다.

사람은 목표와 완료 조건을 정하고, 테스트와 권한 설정, 모니터링과 복구 절차로 결과를 거른다. 예외를 처리한 뒤에는 같은 문제가 다시 올라오지 않도록 기준을 고친다.

관심을 둘 곳은 에이전트 수가 아니다. 어떤 변경이 사람을 거치지 않고 지나가는지, 어떤 예외만 사람 앞에 서는지, 한 번의 거절이 다음 날 테스트나 권한 규칙으로 남는지다.

그리고 그 기준을 고칠 사람은, 직접 실행하지 않으면서 어떻게 계속 판단을 배울 것인가.

코드를 쓰지 않는 개발자의 마지막 일은 승인 버튼을 누르는 것이 아니다.

같은 버튼을 다시 누르지 않도록 기준을 고치는 일이다.

---

출처와 확인 범위

Fortune, 2026년 6월 8일, 11일

8개월 동안 손으로 코드를 쓰지 않았다는 발언, 하루에 수백에서 수만 개의 에이전트를 동시에 다루는 작업 방식, 코드 작성에서 리뷰로, 다시 유지보수와 보안으로 병목이 옮겨갔다는 설명을 확인했다. 무대 발언을 정리한 보도이므로 앤트로픽의 공식 지표가 아니라 체르니 개인의 서술로 다뤘다. 6월 11일 기사, 6월 8일 기사

WIRED, 2026년 1월 22일

모든 코드를 Claude Code가 쓰지만 여전히 매일 코딩한다는 발언, 동시에 다섯에서 열 개의 세션을 오가는 작업 습관을 확인했다. 인터뷰 시점이 앞선 만큼 이후의 세션 수와 방식은 달라졌을 수 있다. 원문 보기

Anthropic, “Agentic coding and persistent returns to expertise”, 2026년 6월 16일

약 40만 개 세션에서 계획 결정의 약 70%와 실행 결정의 약 20%를 사람이 맡았다는 분포, 숙련도별 검증 가능한 성공률(초보 15%, 중급 이상 28~33%)을 참고했다. 세션 로그 기반 분석이므로 배포 이후의 코드 품질이나 경제적 성과를 측정한 수치가 아니다. 원문 보기

Anthropic, “How we built Claude Code auto mode”, 2026년 3월 25일

권한 요청의 약 93%가 승인된다는 수치, 승인 피로라는 표현, 운영체제 수준 샌드박스 도입 이후 권한 요청이 84% 줄었다는 결과를 확인했다. 자사 제품에 대한 자사 발표라는 점을 감안해 읽었다. 원문 보기

Anthropic, “How we contain Claude across products”, 2026년 5월 25일

원격 브랜치 삭제, 인증 토큰 업로드, 운영 데이터베이스 마이그레이션 시도 사례와, 문제 해결 방식은 열어두고 접근 경계를 좁히는 격리 설계 원칙을 확인했다. 원문 보기

본문의 체르니 발언은 한국어 문장에 맞게 맥락을 보존해 의역했다. 직접 인용으로 확인되지 않은 표현에는 인용부호를 사용하지 않았다.