Anthropic의 하루 30,000건 코드 변경: AI 기반 소프트웨어 공장과 검증의 중요성

설문에서 청중 대부분이 지난 한 주 안에 자신의 코딩 에이전트가 풀 리퀘스트를 열었다고 답했습니다. 그러나 병합된 코드를 한 줄 한 줄 검토한 사람은 소수에 그쳤습니다.

Manish Kapur는 이 차이를 짚으며, 자동 병합 속도와 사람이 검토할 수 있는 역량 사이의 격차가 커지고 있다고 말했습니다.

CircleCI가 2,800만 건의 CI 워크플로를 분석한 결과, 올해 처리량이 59% 늘었습니다. 그럼에도 프로덕션에 코드를 병합하려는 시도 열 번 중 세 번꼴로 실패하고 있습니다.

Manish Kapur는 이 추세가 Sonar 고객 대부분에게서 보는 흐름과 같다고 말했습니다.

Addy Osmani는 소프트웨어 공장을 두 가지로 나누어 설명했습니다. ‘조명이 켜진’ 공장에서는 에이전트가 계획, 구현, 점검, 배포를 돕지만 최종 판단과 감각은 사람이 맡습니다.

반면 ‘어두운 소프트웨어 공장’은 로봇 자동차 공장에 가깝습니다. 에이전트가 범위 설정부터 배포까지 전 과정을 자율적으로 처리하고, 사람은 가장 큰 예외 상황에만 개입합니다. 대부분의 팀은 이 스펙트럼 어딘가에 있으며, 신뢰를 유지하면서 자동화를 늘리는 것을 목표로 합니다.

Manish Kapur는 AI 코딩이 이미 보편화되었다고 말했습니다. 조직의 85%가 코딩 에이전트를 쓰고 있고, 곧 100%에 이를 것으로 예상됩니다. 하지만 개발자의 76%는 AI가 코드를 검증할 수 있는 속도보다 빠르게 만든다고 답했고, 그 결과 코드 리뷰에 쓰는 시간이 늘고 있습니다.

엔지니어링 리더들은 코드 품질에 대한 확신을 유지하면서 배포 속도를 높이는 데 집중하고 있습니다. Addy Osmani는 AI가 이제 테스트, 벤치마크, 명세를 만드는 데 쓰이면서 코드 검증의 비용이 낮아지고 있다고 설명했습니다.

AI 에이전트가 높은 품질의 결과물을 내려면, 자기 작업의 정확성과 완결성을 검증할 방법을 함께 주어야 합니다. Manish Kapur는 이런 검증을 도입하면 결과물 품질이 두세 배 좋아질 수 있다고 말했습니다.

코드에 대한 확신은 희소한 자원으로 보고 적극적으로 키워야 할 대상입니다. 핵심 코딩 문제가 대체로 해결된 지금은 더욱 그렇습니다.

Anthropic은 일일 병합 코드 변경량을 5월의 약 2,500건에서 30,000건으로 크게 늘렸습니다. 최근 Claude.ai를 새로 단장한 프로젝트는 짧은 기간에 약 3,000건의 풀 리퀘스트를 병합하며 성능을 세 배 끌어올렸고, 이런 규모 확대가 결정적이었습니다.

이 작업에는 엔지니어와 프로덕트 디자이너 등 여러 직군이 참여했습니다. 워크플로와 검증을 전반적으로 다루는 접근이었다는 뜻입니다.

Anthropic의 검증 워크플로는 Claude가 코드를 1차로 검토하는 것에서 시작합니다. 핵심은 Claude가 실제 사용자 경험을 시뮬레이션할 수 있어야 한다는 점입니다. 여기에는 end-to-end 작업, 브라우저 점검, 도구 실행, 린트 검사가 포함되어 코드에 대한 확신을 쌓습니다.

Addy Osmani는 버그나 기능 공백이 발견되면 편집 시점에 자동 훅이 돌아가 diff를 분석하고 풀 리퀘스트를 빠르게 고친다고 설명했습니다. 팀은 모범 사례를 Claude.md나 agents.md 같은 공유 문서에 정리해, 검토 중 에이전트가 참고하도록 하고 있습니다.

최종적으로 개발자는 에이전트가 제시한 스크린샷이나 영상 같은 검증 근거를 검토해야 합니다. 모바일과 데스크톱 등 여러 환경에서 코드가 의도대로 작동하는지 직접 확인하는 것입니다.

Manish Kapur는 Sonar가 곧 발표할 ‘State of Code’ 설문의 결과를 인용했습니다. 1,000명이 넘는 개발자가 응답했고, 84%는 AI 기능이 기능과 수정 사항의 프로덕션 배포를 앞당긴다고 믿고 있습니다. 그러나 풀 리퀘스트는 점점 커지고 복잡해지고 있습니다.

설문에서 우려스러운 수치는 수동 검토 없이 프로덕션에 도달하는 코드가 31% 늘었다는 점입니다. 완벽한 검증과 배포 코드에 대한 확신이 필수인 규제 산업과 미션 크리티컬 애플리케이션에는 특히 위험한 신호입니다.

Manish Kapur는 1,000명 이상의 개발자를 대상으로 한 Sonar의 곧 발표될 설문 결과를 공유했습니다. 응답자의 84%가 AI 기능이 기능과 수정 사항의 프로덕션 배포를 앞당긴다고 믿는 것으로 나타났습니다.

속도는 빨라졌지만 풀 리퀘스트는 더 크고 복잡해지고 있습니다. 게다가 검토 없이 프로덕션에 도달하는 코드가 31% 늘었는데, 배포 코드에 절대적인 확신이 필요한 규제 산업과 미션 크리티컬 애플리케이션에서는 특히 우려되는 수치입니다.

Addy Osmani는 앞으로 소프트웨어 개발의 발전이 검증 과정을 다듬는 일과 높은 모델 품질을 확보하는 일의 결합에서 나올 것이라고 강조했습니다. 그는 Opus 55 같은 모델이 이미 높은 수준의 품질에 도달했다고 말했습니다.

다음 단계는 일반적인 조언을 넘어, 유용한 테스트 유형을 구체적으로 명시하는 검증 모범 사례를 공유하는 것입니다. Addy는 자동 병합에 필요한 확신을 쌓기 위해 end-to-end 테스트, 속성 테스트, 시각적 검증에 의존하라고 제안했습니다.

Manish Kapur는 현재 소프트웨어 공장, 즉 대규모 자동화 루프를 쓰는 기업이 5%에 불과하다고 짚었습니다. 그러나 전체적으로 34%까지 늘어날 것으로 전망되며, 금융 서비스 분야는 39%로 더 높아질 것으로 예상됩니다.

Addy Osmani는 소프트웨어 공장이 사람이 깊이 개입하는 ‘밝은’ 공장에서 완전 자율의 ‘어두운’ 공장까지 스펙트럼을 이룬다고 다시 강조했습니다. 목표는 에이전트가 검증을 만들고 확신을 쌓게 해서 더 높은 자동화로 나아가는 것입니다.

Manish Kapur는 Sonar가 모든 기업이 제로 트러스트 기반의 다층 검증 방식을 채택해야 한다고 확신한다고 말했습니다. 검증은 소프트웨어 개발의 모든 루프, 즉 에이전트 루프, CI 검증 루프, 코드 유지보수에 통합되어야 합니다.

Sonar의 접근은 결함 유형별로 층을 나눕니다. 첫 번째 층은 SQL 인젝션과 버퍼 오버플로처럼 결정적으로 잡아내는 검사입니다. 두 번째 층은 에이전트 기반 검토로, 결정적 검사가 놓칠 수 있는 로직과 의도의 문제를 찾습니다. 세 번째 층은 소프트웨어 공급망 보안으로, CVE, 악성코드, 악성 패키지를 탐지합니다.

Addy Osmani는 많은 기업이 에이전트가 늘어나는 상황을 걱정한다고 전했습니다. 수백에서 수천 개의 에이전트가 무엇을 하는지 제대로 파악되지 않은 채 돌아가는 경우가 많습니다. 이 에이전트들은 모든 시스템에 접근하고, 데이터를 읽고, 프로덕션에 배포까지 할 수 있어 우려가 큽니다.

기업이 짚는 핵심 문제는 에이전트 신원, 활동 추적을 위한 텔레메트리, 통제 수단, 권한, 그리고 에이전트가 허가되지 않은 행동을 하지 않도록 샌드박스 무결성을 지키는 일입니다. Manish Kapur는 Sonar가 이를 ‘가드레일’로 다룬다고 덧붙였습니다. 에이전트가 벗어나지 않도록 막는 데 그치지 않고, 정해진 경로를 따라가도록 능동적으로 이끄는 방식입니다.

패널은 완전 자동화된 환경인 ‘어두운’ 소프트웨어 공장을 도입하는 시기를 논의했습니다. Addy Osmani는 2027년 말까지는 완전 자동화보다는 일부 ‘어두운 구석’이 있는 ‘밝은’ 공장으로의 전환이 이뤄질 것으로 예측했습니다.

Manish Kapur는 Anthropic이 올해나 내년에 이르면 어두운 공장 쪽으로 움직일 수 있다고 봤습니다. 합의된 견해는 완전 자동화가 당장의 업계 표준이 아니라 점진적으로 진행되는 과정이라는 것이었습니다.

Addy Osmani는 풀 리퀘스트에서 AI가 생성한 코드에 라벨을 붙이는 것이 유익하다고 봅니다. 에이전트가 만든 코드에 필요한 제약과 추가 점검이 무엇인지 파악하는 데 도움이 된다는 것입니다. 그는 Anthropic이 결과에 더 초점을 맞추며, Claude가 작성자로 표기되는 것도 괜찮다고 여긴다고 말했습니다.

Manish Kapur는 단기적으로, 특히 향후 6~9개월 동안 라벨링을 의무화하는 데 찬성했습니다. 금융 서비스처럼 감사 가능성이 중요한 분야에서 특히 그렇다는 것입니다. 두 사람은 누가 또는 무엇이 코드를 쓰든 결과에 대한 사람의 책임은 협상할 수 없다는 데 동의했습니다.

Addy는 작업을 에이전트가 시작하더라도, 그것을 시작한 사람이 생기는 문제를 고칠 책임을 여전히 진다고 강조했습니다.

Addy Osmani는 리더들에게 팀이 검증이 실제로 무엇을 뜻하는지 깊이 생각하도록 독려하라고 조언했습니다. 기존 테스트 방식을 살피고, 에이전트가 코드 품질을 독자적으로 승인하지 못하게 하는 공백을 찾으라는 것입니다.

주니어 개발자에게는 end-to-end 테스트, 속성 테스트 등 다양한 테스트 방법론을 폭넓게 경험하라고 권했습니다. 궁극적인 목표는 병합 전에 에이전트가 코드 품질을 독립적으로 검증해도 편안하게 받아들일 수 있는 수준에 이르는 것입니다.

패널은 안전을 해치지 않으면서 개발 속도를 유지하기 위한 세 가지 핵심 원칙으로 마무리했습니다. 첫째, 코드 생성은 이제 개발 과정의 주된 병목이 아닙니다. 대체로 해결된 문제이기 때문입니다.

둘째, 품질을 보장하려면 강력한 검토와 독립적인 자동 검증을 소프트웨어 공장의 모든 루프에 통합해야 합니다. Manish Kapur는 “쓰기 빠른 것이 배포하기 빠른 것은 아니다”라고 말했습니다.

셋째, 소프트웨어 공장의 자율성은 신뢰를 통해 얻어집니다. 팀은 코드가 샌드박스를 잘못 빠져나가 프로덕션에 도달하지 않도록 모든 것을 엄격하게 검증해야 합니다.