3년간 방치됐던 오픈소스 라이브러리를 6주 만에 v2로 재작성했다는 기록이 있다. react-modern-audio-player의 메인테이너는 146개의 커밋, 약 20개의 PR을 거쳐 번들 크기를 ~380KB에서 ~79KB로 줄이고, 테스트 파일을 0개에서 32개로 끌어올렸다. 접근성 점수는 1/10에서 VoiceOver 검증 수준으로 올라갔다. 그 모든 과정의 기폭제는 Claude Code였다. 하지만 이 경험담이 흥미로운 이유는 'AI가 얼마나 잘 짜줬냐'가 아니다. 개발자가 AI를 어떻게 불신하면서 활용했냐에 있다.
신뢰의 붕괴에서 시작된 검증 스택
dev.to에 공개된 이 경험담에서 가장 인상적인 장면은 하나의 실험이다. 같은 PR 리뷰 태스크를 Claude Sonnet, Gemini 3 Flash, GPT 5.3, CodeRabbit에 동시에 맡겼더니, 4개 모델이 모두 다른 지점에서 틀렸다. 그리고 각자 나중에 그 실수를 인정했다. Claude는 "파일 내용을 검증 없이 유효한 것처럼 설명했다"고 했고, CodeRabbit은 "내 블로커 판단이 틀렸다"고 했다.
흥미로운 건 정답을 맞힌 모델이 '돌아가며 바뀌었다'는 점이다. Claude가 상태 관리 질문은 정확히 짚었지만 Vite 설정에서는 환각을 일으켰다. 그 결과 메인테이너가 채택한 규칙은 단순했다. "Claude와 CodeRabbit이 동의하고, 공식 문서가 확인해주면 진행. 아니면 코드를 직접 실행한다." 검증 스택이 오버헤드가 아니라 개발 결과물 자체가 됐다는 표현이 정확하다.
Claude Code가 파일을 읽기 전엔 편집하지 못하는 이유
이 불신의 구조적 근거는 Claude Code 내부 설계에서도 드러난다. dev.to에 공개된 소스 분석(v2.1.88 기준)에 따르면 Claude Code는 읽지 않은 파일을 편집할 수 없도록 코드 레벨에서 강제한다. FileEditTool이 호출되면 가장 먼저 readFileState 캐시를 확인한다. 이전 Read 기록이 없으면 편집 자체가 거부된다.
이유는 명확하다. LLM은 파일 내용을 기억하지만, 그 기억이 틀릴 수 있다. 42번째 줄에 const x = 1이 있다고 '기억'하지만, 실제로는 다른 프로세스가 그 줄을 이미 바꿨을 수 있다. 환각에 기반한 편집은 파일을 조용히 망가뜨린다. 또한 LLM이 곱슬 따옴표(")를 생성하면 직선 따옴표(")와 매칭에 실패하는데, Claude Code는 이를 따옴표 정규화 단계로 자동 처리한다. /dev/zero처럼 무한 스트림을 반환하는 디바이스 파일 접근 차단, 동시 편집 경쟁 조건(TOCTOU) 방어까지—이 모든 설계는 하나의 전제에서 출발한다. AI의 출력을 그대로 신뢰하면 안 된다.
'타이핑하는 나'가 사라지는 것과 '직업이 사라지는 것'은 다른 문제다
Anthropix CEO 다리오 아모데이의 "코딩이 먼저 사라질 것"이라는 발언 이후 브런치에 올라온 한 글은 이 불안의 실체를 정확히 짚는다. 미국 노동통계국의 2033년 전망을 보면, '컴퓨터 프로그래머(순수 코딩 직군)'는 -3% 감소하지만 '소프트웨어 개발자(시스템 설계 직군)'는 +17.9%, 신규 일자리 32만 7천 개가 늘어난다. 두 줄 안에 두 개의 다른 미래가 공존한다.
글의 핵심 통찰은 이 문장이다. "두렵다. 하지만 내가 두려워한 건 '직업이 사라지는 것'이 아니었다. '타이핑하는 나'가 사라지는 것이었다." 타이핑은 도구였고, 생각이 본질이었다. 컴파일러, 프레임워크, 클라우드가 등장할 때마다 같은 공포가 반복됐고, 결과는 매번 엔지니어 수 증가였다. 이른바 제번스의 역설—자원이 효율화될수록 총 소비량이 늘어나는 역설이 소프트웨어 개발에도 작동하고 있다.
AI와 협업할 때 개발자가 실제로 판단해야 하는 것
세 가지 소스가 수렴하는 지점은 결국 하나다. AI는 코드를 생성하는 속도를 높이지만, 무엇을 만들어야 하는지, 어떤 출력을 믿어야 하는지, 어디서 멈춰야 하는지는 여전히 개발자의 판단 영역이다.
오픈소스 재작성 경험에서 AI가 실제로 한 일은 무엇이었나. 3년간 알고 있었지만 쓰지 않았던 기술 부채를 '전체 코드베이스를 수 초 만에 스캔'하며 정리해줬다. 접근성이 1/10이라는 점, 테스트가 0개라는 점은 메인테이너가 이미 알고 있었다. AI는 그것을 빠르게 수면 위로 올리고, 시작의 활성화 에너지를 낮춰준 것이다. '두 시간 걸리던 코드 파악'을 '15분의 대화'로 줄였다는 표현이 핵심이다.
반대로 AI가 하지 못한 일도 명확하다. "비독립적인 vibe-code 플레이어를 AI로 오후에 뚝딱 만들면 되지 않냐"는 질문에 대한 메인테이너의 답이 인상적이다. Safari와 Chrome의 canplaythrough 차이, wavesurfer.js의 메모리 누수, Next.js App Router에서의 브라우저 환경 가정 충돌—각각은 어렵지 않지만 복합되면 몇 주를 잡아먹는 문제들이다. 라이브러리 6주의 가치는 코드가 아니라 그 문제들이 이미 해결되어 있다는 '축적된 흉터 조직(scar tissue)'에 있다.
개발자의 역할이 이동하는 방향
Claude Code의 내부 설계, 오픈소스 v2 경험담, 그리고 직업 변화 분석이 함께 가리키는 방향은 같다. AI 에이전트가 코드를 더 잘 짜게 될수록, 개발자의 핵심 역량은 점점 더 "AI가 틀렸을 때를 포착하는 능력" 쪽으로 이동한다.
이는 단순한 검토자 역할이 아니다. 어떤 질문을 어떤 모델에 맡길지 결정하는 것, 다중 모델 출력을 교차 검증하는 기준을 세우는 것, 품질 게이트를 어디에 심을지 설계하는 것—이 모든 것이 아키텍처 수준의 판단이다. Anthropic 내부 엔지니어들이 "우리는 더 이상 코드를 직접 쓰지 않는다. 우리는 편집하고, 검토하고, 아키텍처를 설계한다"고 말하는 것은 퇴보가 아니라 추상화 레이어가 한 단계 더 올라간 것이다.
빠르게 만들 수 있다는 것과 무엇을 만들어야 하는지, 무엇을 믿어야 하는지는 여전히 전혀 다른 문제다. AI와의 협업에서 개발자가 진짜 판단해야 할 것들은 코드 바깥에 있다.