AI 코딩 에이전트의 코드 검토 공백, 깃허브 시니어 엔지니어가 퇴사하며 남긴 경고

핵심 메시지

• 발표자는 깃허브에서 4년 가까이 일하며 시니어 엔지니어까지 올라갔지만, AI 코딩 에이전트의 안전 문제를 다루기 위해 회사를 떠났다고 밝혔다.
• 문제는 코드 생성이 아니라, 코드 리뷰·테스트·배포 결정·아키텍처 선택까지 사람의 감독 없이 에이전트에 넘기는 흐름이라고 지적한다.
• AI는 종종 사람보다 나은 코드를 쓰지만 항상 그런 것은 아니며, 확실한 것은 사람보다 훨씬 많은 양을 쓴다는 점이다.
• 불완전한 시스템이 방대한 코드를 만들어내면 사람이 확인할 수 없는 버그가 남는 것은 감이 아니라 산술적 귀결이라는 것이 그의 주장이다.
• 에이전트의 실수를 다시 에이전트로 검증하는 현재의 해법은 불완전한 시스템 위에 불완전한 시스템을 쌓는 것일 뿐이라고 본다.

쉽게 이해하기

깃허브에서 4년 가까이 일하며 시니어 엔지니어가 된 개발자가 퇴사 소식을 전하며 그 이유를 설명했다. 회사가 싫어서가 아니라, 지금껏 겪은 일 가운데 가장 좋은 직장이었지만 업계 전반에서 감지한 위험한 흐름을 그냥 두고 볼 수 없었다는 것이다. 그는 자동완성 수준이던 AI가 클로드 코드나 깃허브 코파일럿 같은 에이전트로 진화하는 과정을 현장에서 지켜봤고, 그 생산성 향상 자체는 여전히 지지한다고 말한다.

그가 문제 삼는 것은 코드 생성이 아니라 그다음 단계다. 기업들이 코드 리뷰, 테스트, 배포 판단, 심지어 아키텍처 결정까지 점점 더 적은 사람의 감독 아래 에이전트에 넘기고 있다는 것이다. 위험을 감수할 여력이 있는 소규모 스타트업만의 이야기가 아니라, 수백만 명이 쓰는 서비스를 운영하는 회사들도 사람이 거의 손대지 않은 코드를 프로덕션에 올리고 있다고 그는 말한다.

특히 그는 일부 조직이 풀 리퀘스트를 'AI가 만든 코드의 속도를 늦추는 성가신 병목'으로 부르기 시작했다는 점을 강조한다. 사용자에게 코드가 도달하기 전 사람이 들여다보는 마지막 관문을 병목이라 규정하는 순간, 다음 수순은 인간 검토 자체를 없애는 방향이 된다는 것이다.

그가 드는 근거는 단순한 산수다. 예전에는 하루에 수백 줄을 쓰는 날이 있었다면 지금은 한 세션에 수천 줄을 쓰는 일이 쉽다. 개발자 한 명이 100배의 코드를 만들어낼 수 있다면, 그 사람은 결과물을 더 이상 의미 있게 검토할 수 없다. 가끔 환각을 일으키고 긴 작업에서는 불완전한 해법을 내놓는 시스템이 '거의 완벽한' 코드를 대량으로 쏟아내면, 사람이 잡아낼 여력이 없는 버그가 남는 것은 통계적으로 보장된 결과라는 이야기다.

그렇다고 그가 코딩 에이전트를 멈추자고 주장하는 것은 아니다. 스스로도 모든 코드를 손으로 쓰던 시절로 돌아가고 싶지 않다고 말하며, 지원 포털의 버튼이 예외 상황에서 깨지는 정도라면 감수할 만하다고 인정한다. 문제는 이 흐름이 모든 산업에 퍼지면서 의료 시스템, 금융 플랫폼, 수백만 명이 의존하는 인프라처럼 실패를 감당할 수 없는 곳까지 밀고 들어간다는 데 있다. 그래서 그는 AI 코딩 에이전트를 위한 모니터링 시스템을 만드는 연구소 자리로 옮겼다고 밝혔다.

주요 인사이트

• 생산성 향상과 품질 저하는 같은 원인에서 나온다. 코드 생산량이 사람의 검토 용량을 넘어서는 순간, 늘어난 속도만큼 확인되지 않은 코드도 함께 늘어난다.
• 'AI가 사람보다 코드를 잘 쓴다'는 명제와 '항상 잘 쓴다'는 명제는 다르다. 자동화 범위를 정할 때는 평균 품질이 아니라 실패했을 때의 비용을 기준으로 삼아야 한다.
• 에이전트 출력을 다른 에이전트로 검증하는 방식은 같은 종류의 오류를 공유하는 시스템에 감시를 맡기는 셈이라, 프롬프트를 조금씩 바꿔 겹겹이 쌓아도 완벽에 수렴하지 않는다.
• 모든 소프트웨어에 같은 기준을 적용할 필요는 없다. 사소한 버그가 용인되는 영역과 의료·금융·인프라처럼 용인되지 않는 영역을 구분해 감독 수준을 다르게 두는 편이 현실적이다.
• 풀 리퀘스트를 병목으로 볼 것인가 안전장치로 볼 것인가는 기술이 아니라 조직의 선택이며, 그 선택이 결과물의 품질을 결정한다.

자주 묻는 질문

관련 AI 소식