Synthesia AI 코드 리뷰가 더 빠른 생성의 대가를 드러내다

Synthesia AI 코드 리뷰는 풀 리퀘스트가 120% 증가했음에도 뚜렷한 충돌을 보여준다. 코드를 더 빠르게 생성한다고 해서 엔지니어링 업무가 사라지는 것은 아니다. 그 업무는 후속 단계로 이동할 뿐이다.

Synthesia에 따르면 현재 풀 리퀘스트의 95%에는 AI 생성 코드가 포함되어 있다. 그러나 사람의 검토를 거치지 않는 변경은 5% 미만이다. 이 수치는 코딩 에이전트를 대규모로 도입하는 엔지니어링 조직이 직면한 새로운 문제를 포착한다.

새로운 병목은 더 이상 코드를 타이핑하는 일이 아니다. 생성된 코드가 의도한 설계를 반영하는지, 기존 시스템에 맞는지, 예외적인 상황을 처리하는지, 배포 후에도 안전한지를 판단하는 일이다.

이 변화는 엔지니어링 리더들에게 전체 리뷰 프로세스의 재설계를 요구한다. Amazon, AWS, Bonterra, IBM, Making Sense, Temporal은 같은 아이디어의 다양한 형태를 시험하고 있다. 자동화가 일상적인 검사를 맡되, 중요한 결정에 대한 권한은 사람이 유지해야 한다는 것이다.

이러한 분업은 효율적으로 들린다. 그러나 어려운 질문도 만들어낸다. AI 시스템이 코드를 작성하고 또 다른 AI 시스템이 이를 검토한다면, 책임 있는 엔지니어는 어떤 근거로 둘 중 어느 쪽도 신뢰할 수 있을까?

Synthesia AI 코드 리뷰가 드러내는 새로운 병목

AI 생성 코드는 기업이 이를 검증할 역량을 늘리는 속도보다 더 빠르게 생산 능력을 높였다.

Synthesia의 엔지니어 118명은 2025년 11월부터 워크플로 전반에 AI 코딩 도구를 도입했다. CTO Peter Hill에 따르면 2026년 8월까지 풀 리퀘스트는 전년 대비 120% 증가했다.

풀 리퀘스트는 메인 코드베이스에 병합되기 전에 다른 엔지니어 또는 자동화 시스템이 검토하는 제안된 변경 사항이다. 풀 리퀘스트 증가는 산출량 증가를 의미할 수 있지만, 각 요청은 테스트, 리뷰, 조율, 유지보수 업무도 함께 만든다.

Synthesia에서의 변화는 자동완성 도구가 완성한 작은 제안에 그치지 않았다. Hill은 원문 보도에서 회사 풀 리퀘스트의 95%에 AI 생성 코드가 포함됐다고 말했다.

이러한 물량은 반복되는 약점을 드러냈다. 코딩 에이전트는 동일한 기능이 이미 저장소의 다른 위치에 존재한다는 사실을 인식하지 못한 채 함수를 만들 수 있다. 제한된 맥락은 하나의 구현을 여러 경쟁 버전으로 바꾼다.

Synthesia는 같은 함수의 버전을 최대 10개까지 발견한 것으로 전해진다. 엔지니어는 중복을 찾아내고, 어떤 구현이 제품에 남아야 하는지 결정하며, 나머지를 제거하고, 에이전트가 같은 실수를 반복하지 않도록 해야 한다.

생성된 함수 하나하나는 따로 보면 그럴듯해 보일 수 있다. 결함은 누군가가 더 넓은 시스템을 이해할 때에만 분명해진다. 이 차이는 피상적인 검사를 통과한 코드도 기술 부채를 늘릴 수 있는 이유를 설명한다.

기술 부채란 현재 소프트웨어의 지름길, 불필요한 복잡성, 취약한 설계 선택으로 인해 미래에 발생하는 엔지니어링 업무를 뜻한다. AI가 이를 만들기 위해 문법이 깨진 코드를 생성할 필요는 없다. 모델이 더 큰 아키텍처와 충돌하는, 국지적으로만 그럴듯한 코드를 만들면 충분하다.

Hill은 회사 규모에서 의도한 결과물을 얻는 일이 엄청난 양의 작업이라고 설명했다. 그는 팀이 에이전트 생성 코드를 완전히 신뢰하게 될 수 있을지에도 의문을 제기했다.

이러한 회의론이 Synthesia의 코딩 에이전트 사용을 막지는 않았다. 대신 회사는 위험도에 따라 사람의 주의를 배분한다. 오류 메시지 변경은 고객 데이터나 핵심 비즈니스 규칙과 관련된 변경보다 덜 면밀한 검토를 받는다.

이러한 분류 작업에도 95%가 넘는 변경은 여전히 사람의 리뷰를 받는다. 회사는 생성 역량을 키우면서도 대부분의 배포에 인간의 관문을 유지하고 있다.

업계 전반에서도 같은 긴장이 나타난다. Sonar는 전문 개발자 1,100명 이상을 조사했고, 응답자들은 커밋된 코드의 42%가 AI에서 비롯됐다고 답했다.

그러나 96%는 AI 생성 코드가 올바르게 작동할 것이라고 완전히 신뢰하지 않았다. 개발자 설문조사에 따르면, AI 지원 코드를 커밋하기 전에 항상 검증한다고 답한 비율은 48%에 불과했다.

불신과 일관된 검증 사이의 격차는 단순한 도입 수치보다 더 중요하다. 이는 일부 조직이 통제 체계가 평가할 수 있는 속도보다 더 빠르게 생성 코드를 생산하고 있음을 시사한다.

응답자의 38%는 AI 생성 코드가 동료가 작성한 코드보다 더 많은 리뷰 노력을 요구한다고 답했다. 61%는 생성 코드가 종종 올바르게 보이지만 신뢰할 수 없다고 답했다.

이러한 결과가 모든 AI 생성 변경이 더 나쁘다는 점을 입증하는 것은 아니다. Sonar는 코드 검증 제품을 판매하며, 이 설문은 통제된 프로덕션 측정이 아니라 보고된 경험을 반영한다.

그럼에도 이 수치는 Synthesia 및 다른 기업들의 운영 사례와 일치한다. 코드 생성은 빨라졌지만, 신뢰도는 같은 속도로 높아지지 않았다.

더 빠른 코딩은 업무를 후속 단계로 이동시킨다

조직이 사용자에게 도달하는 신뢰할 수 있는 소프트웨어가 아니라 생성된 코드를 측정할 때 생산성 약속은 약해진다.

코딩 에이전트는 몇 분 안에 수천 줄의 코드를 만들 수 있다. 그러나 줄 수는 그 변경이 존재해야 하는지, 올바르게 통합되는지, 요청된 문제를 해결하는지에 대해 거의 말해주지 않는다.

Amazon은 모바일 쇼핑 애플리케이션 뒤에 있는 17년 된 코드를 현대화하면서 이 차이를 경험했다. 수석 프린시펄 엔지니어 McLaren Stanley는 1,000명 이상의 개발자를 지원하는 70명 규모 팀과 일하고 있다.

Stanley는 에이전트가 Apple의 프로그래밍 언어인 Swift의 잘못된 버전으로 25,000줄을 생성한 사례를 설명했다. 결과물을 변환하는 과정에서 에이전트가 한꺼번에 해결하지 못한 오류 600개가 발생했다.

팀은 생성 코드를 한 줄씩 고치는 대신 폐기했다. Stanley는 에이전트가 무엇을 만들고 어떻게 동작해야 하는지를 정의하는 상세 계획인 명세를 수정했다.

이 수정 후 에이전트는 15분 안에 코드를 올바르게 다시 생성한 것으로 전해진다. 이 사례는 생산성 논쟁의 양면을 모두 보여준다.

에이전트는 사람이 25,000줄을 다시 작성하는 것보다 빠르게 복구했다. 그러나 중요한 제약 하나가 빠져 있었기 때문에, 처음에는 대규모의 사용할 수 없는 변경을 만들어냈다.

생성 속도는 계획의 품질을 증폭시켰다. 불완전한 명세는 이례적인 규모의 실패를 낳았다. 수정된 명세는 빠르게 사용할 수 있는 결과를 만들었다.

이 관계는 수석 엔지니어가 시간을 쓰는 위치를 바꾼다. 에이전트가 구현을 시작하기 전에 아키텍처, 제약 조건, 인터페이스, 승인 기준, 금지된 동작을 정의해야 한다.

업무는 프로그래밍 문법으로 모든 지시를 표현하는 일에서 실행 가능한 계획을 구성하고 방어하는 일로 옮겨간다. 편집기에 입력되는 키 입력이 줄더라도 이는 여전히 소프트웨어 엔지니어링이다.

전반적인 생산성에 대한 독립적 증거는 여전히 엇갈린다. 2025년 METR 무작위 대조 시험은 자신이 잘 아는 저장소에서 246개 작업을 수행하는 숙련된 오픈소스 개발자 16명을 연구했다.

생산성 시험에 따르면, 초기 2025년 AI 도구를 사용할 수 있었을 때 이 개발자들은 19% 더 오래 걸렸다. 참여 전에는 AI가 자신들을 24% 더 빠르게 만들 것이라고 예상했다.

이후에도 이들은 AI가 업무를 약 20% 가속했다고 믿었다. 측정 결과는 정반대를 가리켰다.

이 연구는 규모가 작았고, 익숙하고 성숙한 저장소에서 작업하는 숙련 개발자에게 초점을 맞췄다. METR은 이 결과를 모든 개발자, 도구, 프로그래밍 환경에 적용해서는 안 된다고 명시적으로 경고했다.

익숙하지 않은 시스템에서 일하는 개발자는 AI 설명과 저장소 탐색에서 더 큰 가치를 얻을 수 있다. 더 새로운 모델과 개선된 에이전트 워크플로도 결과를 바꿀 수 있다.

METR은 후속 도구가 더 큰 이점을 제공할 가능성이 높다고 인정했다. 이 연구는 체감 속도와 측정된 완료 시간을 구분한다는 점에서 여전히 가치가 있다.

개발자는 에이전트가 눈에 보이는 결과물을 만드는 모습을 보며 더 빨라졌다고 느낄 수 있다. 프롬프트 작성과 리뷰는 동일한 변경을 직접 구현하는 것보다 덜 피곤하게 느껴질 수도 있다.

그러나 어느 감각도 올바른 변경이 더 빨리 프로덕션에 도달한다는 보장은 아니다. 대기, 오해 수정, 생성 결과물 읽기, 불필요한 코드 정리에 드는 시간도 모두 포함된다.

더 최근의 기업 현장 연구는 중요한 단서를 전제로 더 낙관적인 결과를 제시한다. 연구진은 2024년 1월부터 2026년 4월까지 개발자 802명과 풀 리퀘스트 196,212건을 조사했다.

연구 대상 기업에서 개발자당 처리량은 결국 도입 전 기준선의 2.09배에 도달했다. 연구진은 도입이 무작위로 배정되지 않았기 때문에, 증가분 전체를 AI에 직접 귀속할 수는 없다고 경고했다.

더 중요한 점은 조직의 리뷰 시스템도 생산량에 맞춰 변화했다는 것이다. 리뷰어당 부담은 대략 두 배로 늘었고, 자동화된 리뷰가 사람의 리뷰를 넘어섰다. 병합 및 되돌리기 비율은 안정적으로 유지됐다.

이 증거는 “AI가 엔지니어링 생산성을 두 배로 높인다”보다 더 제한적인 결론을 뒷받침한다. 조직이 리뷰를 재설계하고 도구 사용 경험을 축적할 때 높은 산출량이 지속 가능해질 수 있음을 시사한다.

가치의 핵심 단위는 생성된 코드가 아니다. 리뷰를 통과하고, 사용자에게 도달하며, 사고를 피하고, 유지보수가 가능한 변경이다.

계획과 리뷰 에이전트가 통제 계층이 된다

AI 코드 슬롭에 대한 가장 강력한 대응은 생성 이전에 시작해 계층적이고 위험 기반의 리뷰를 거쳐 이어진다.

기업들은 코딩 에이전트 주변에 통제 계층을 구축하고 있다. 이 계층은 명세, 자동화 테스트, 보안 검사, 정책 집행, 신뢰도 신호, 사람에 의한 에스컬레이션을 결합한다.

리뷰만으로는 잘못 정의된 작업을 효율적으로 구제할 수 없기 때문에 계획이 먼저다. 정밀한 명세는 에이전트가 대규모 변경을 생성하기 전에 선택지를 좁힌다.

명세는 의도된 동작, 관련 구성 요소, 아키텍처 한계, 데이터 제약, 승인 테스트를 식별해야 한다. 또한 실패 조건과 예외적인 입력도 설명해야 한다.

이 접근법은 프롬프트를 개선하는 데 그치지 않는다. 자동화 리뷰어와 사람이 모두 결과를 평가하는 데 사용할 수 있는 기준을 만든다.

승인된 계획이 없다면 리뷰어는 구현을 읽으면서 작성자의 의도를 추론해야 한다. 명목상 작성자가 현재 맥락 밖에서는 안정적인 이해를 갖지 못하는 에이전트라면 이 작업은 더 어려워진다.

계획이 있다면 리뷰 질문은 더 구체적이 된다. 구현이 합의된 설계와 일치하는가, 아니면 에이전트가 다른 해결책을 만들어냈는가?

수석 프린시펄 엔지니어 David Yanacek에 따르면 AWS는 초기 검사를 위해 특화된 에이전트를 사용한다. 이 에이전트들은 코드가 작동하는지 테스트하고, 원래 계획과 비교하며, 사람이 리뷰하기 전에 보안 문제를 찾는다.

이 계층형 워크플로는 AI 리뷰를 최종 권한이 아니라 필터링으로 취급한다. 기계는 반복적인 읽기와 구조화된 비교를 처리한다. 사람은 모호한 트레이드오프를 판단하고 책임을 수용한다.

Bonterra는 리뷰 업무량이 급증한 뒤 유사한 모델을 도입했다. 이 비영리 소프트웨어 제공업체에는 약 290명의 엔지니어가 있다.

CTO Tanuja Korlepra에 따르면 AI 도입 3개월 안에 제안된 변경은 세 배로 늘었다. 리뷰에 들어오는 코드 양은 열 배 증가했고, 리뷰 시간은 세 배가 됐다.

그 수치는 전통적인 줄 단위 검토만으로는 무제한으로 생성되는 결과물을 감당할 수 없는 이유를 보여준다. 코딩 에이전트 한 명을 추가하는 것만으로도 기업이 숙련된 검토자를 채용하는 속도보다 더 빠르게 생산량이 늘어날 수 있다.

Bonterra의 검토 에이전트는 제안된 코드를 승인된 설계, 보안 요구사항, 코딩 표준, 접근성 규칙과 비교한다. 또한 신뢰도 평가도 생성한다.

신뢰도 점수가 낮거나 문제가 표시되면 해당 변경 사항은 사람에게 전달된다. 결제, 개인정보 또는 기타 민감한 시스템에 영향을 미치는 코드는 항상 사람의 검토를 받는다.

이 접근 방식은 위험을 희소한 주의력을 배분하는 기준으로 활용한다. 자동화된 검토가 모든 저위험 변경 사항을 정확하게 만든다고 주장하지는 않는다.

위험 기반 분류는 대신 어떤 실패가 가장 큰 피해를 초래할지를 묻는다. 그러면 팀은 맥락과 책임이 가장 중요한 곳에 제한된 인적 주의를 투입할 수 있다.

에이전트가 작성한 풀 리퀘스트에 관한 연구는 구조적 신호가 도움이 될 수 있음을 시사한다. 2026년 검토 노력 연구는 2,807개 리포지토리에서 생성된 33,707건의 에이전트 생성 풀 리퀘스트를 분석했다.

연구진은 28.3%가 1분 이내에 병합됐으며, 이는 상호작용이 거의 필요하지 않은 범위가 좁은 변경 사항을 반영한다고 밝혔다. 다른 요청들은 더 긴 검토 주기에 들어갔고, 이 과정에서 에이전트가 피드백에 멈추거나 응답하지 않는 경우도 있었다.

연구진은 생성 시점에 검토 노력이 가장 많이 필요한 상위 20%의 풀 리퀘스트를 식별하는 모델을 구축했다. 구조적 신호를 활용해 해당 검토 예산 내에서 전체 검토 노력의 69%를 포착했다.

이 모델은 시간 기반 평가 분할에서 0.957의 AUC 점수를 기록했다. 이 점수는 분류기가 더 많은 노력이 필요한 변경 사항과 더 적은 노력이 필요한 변경 사항을 얼마나 잘 구분하는지 측정한다.

텍스트 설명은 예측 가치에 거의 추가적인 기여를 하지 못했다. 에이전트가 무엇을 변경했는지가 작업을 어떻게 설명했는지보다 더 중요했다.

이 발견은 변경 구조를 조기에 검토해야 한다는 근거를 강화한다. 파일 수, 코드 규모, 구성 변경, 의존성 범위, 아키텍처 확산 정도는 누군가 코드 스타일을 논의하기 전에 위험을 드러낼 수 있다.

그러나 효과적인 통제 계층에는 생성과 평가 사이의 독립성이 필요하다. 같은 모델에게 자신이 도입한 가정을 승인하게 하면 원래의 사각지대가 재현될 수 있다.

팀에는 모델 기반 검토와 함께 결정론적 테스트, 정적 분석, 보안 스캐너, 리포지토리 정책, 그리고 사람의 도메인 지식이 필요하다. 각 통제 수단은 서로 다른 실패 모드를 포착한다.

문서화 역시 운영 인프라가 된다. 코딩 에이전트는 회의와 개인 기억 속에 흩어져 있는 아키텍처 결정, 소유권 규칙, 과거 사고의 교훈을 따를 수 없다.

엔지니어링 지식 베이스는 팀이 이러한 맥락을 보존하는 데 도움을 줄 수 있다. 이는 권위 있는 테스트나 리포지토리 통제를 대체하지 않고 검토 과정을 지원해야 한다.

사람의 승인이 형식적인 절차가 되어서는 안 된다

엔지니어가 그 아래에 있는 생성된 설계를 이해하지 못한 채 작동하는 동작만 승인할 때 검토는 실패한다.

소프트웨어 컨설팅 기업 Making Sense의 최고 AI 아키텍트 JD Raimondi는 이런 결과를 “형식적 승인(theater approval)”이라고 부른다. 검토자는 기능이 작동하는 듯 보이는지 확인하고 구현을 훑어본 뒤, 그 근본적인 선택을 이해하지 못한 채 승인한다.

이 문제는 생성형 AI 이전에도 존재했다. 대규모 풀 리퀘스트, 마감 압박, 불명확한 소유권, 피상적인 테스트는 언제나 검토를 약화시켰다.

코딩 에이전트는 이들이 이례적인 속도로 설득력 있는 구현을 만들어낼 수 있기 때문에 위험을 높인다. 깔끔한 형식과 자신감 있는 설명은 취약한 가정을 더 알아차리기 어렵게 만들 수 있다.

에이전트는 드문 입력을 잘못 처리하면서도 눈에 보이는 테스트는 통과할 수 있다. 또한 회사 정책과 충돌하는 의존성을 도입하거나 대규모 리포지토리의 다른 곳에 숨겨진 로직을 중복할 수 있다.

명백한 기능 장애 없이 보안을 약화시킬 수도 있다. 권한 부여 경계, 데이터 보존 규칙, 경쟁 조건, 안전하지 않은 기본값은 짧은 시연 이상의 검토를 요구한다.

Temporal은 제출 엔지니어가 에이전트 생성 작업을 직접 설명하도록 함으로써 대응한다. “Send Back” 정책에 따라 엔지니어는 설계 선택을 자신의 말로 설명해야 한다.

또한 코드가 비정상적인 조건을 어떻게 처리하는지도 설명해야 한다. 이를 하지 못하면 검토자는 제출을 거절한다.

CEO Samar Abbas는 이 정책을 직접 요약했다. “우리는 코드 검토가 검증되지 않은 모델 출력물을 버리는 장소가 되는 것을 거부합니다.”

이 규칙은 에이전트를 호출하는 사람의 인센티브를 바꾼다. 더 큰 패치를 생성한다고 해서 이해에 드는 모든 비용을 다른 사람에게 넘길 수는 없다.

제출자는 질문에 답하고 결과에 책임질 만큼 충분히 이해해야 한다. 이 요구사항은 추측성 코드 물량을 억제하고, 더 작고 방어 가능한 변경을 장려한다.

이는 책임성도 보존한다. AI 에이전트는 사고 대응 회의에 참여하거나, 규제 위반을 설명하거나, 위험한 배포를 계속할지 결정할 수 없다.

기계가 대부분의 읽기 작업을 수행하더라도 사람의 책임은 필수적이다. 문제는 조직이 검토자에게 그 책임을 행사할 충분한 시간, 맥락, 권한을 제공하는지다.

Google의 배포 연구는 AI 도입이 더 높은 소프트웨어 처리량과 더 큰 배포 불안정성 모두와 연관돼 있음을 발견했다. 이 보고서는 AI를 주변 시스템을 증폭하는 요소로 설명했다.

강력한 테스트, 명확한 플랫폼, 빠른 피드백, 건전한 문서화는 증가한 생성을 유용한 결과물로 전환할 수 있다. 취약한 통제는 같은 증가한 물량이 결함과 혼란을 증폭하도록 만들 수 있다.

이 관점은 두 가지 흔한 과장을 피한다. AI 생성 코드는 자동으로 안전하지 않은 것이 아니며, 자동화된 검토도 자동으로 충분한 것은 아니다.

결과는 두 시스템을 둘러싼 워크플로에 달려 있다. 승인된 제안 수나 생성된 코드 줄 수를 측정하는 팀은 이후의 재작업을 놓칠 수 있다.

더 강력한 측정 시스템은 병합 이후까지 변경 사항을 추적한다. 유용한 지표에는 유출된 결함, 실패한 배포, 보안 발견 사항, 롤백 빈도, 검토 시간, 유지보수 노력이 포함된다.

팀은 또한 저위험 자동화와 결과가 중대한 제품 로직을 구분해야 한다. 생성된 문서를 업데이트하는 것은 결제 권한 부여를 변경하는 것과 같은 노출을 수반하지 않는다.

위험 분류 역시 실패할 수 있다. 공유 인증 헬퍼에 대한 작은 변경이 격리된 도구의 대규모 업데이트보다 더 광범위한 결과를 낳을 수 있다.

이 때문에 줄 수만으로 검토 강도를 결정할 수 없다. 검토 시스템에는 소유권 맵, 의존성 정보, 과거 사고 데이터, 민감한 경계에 대한 이해가 필요하다.

자동화된 검토자는 자체적인 잡음도 만든다. 에이전트가 개발자에게 가치가 낮은 경고를 쏟아내면, 사람들은 경고를 무시하도록 길들여질 수 있다.

그 결과 경고 피로는 기술적 통제를 또 다른 형태의 형식으로 바꾼다. 검토 시스템은 철저해 보이지만, 중요한 발견은 일상적인 의견 속에 묻힌다.

따라서 기업은 자동화된 발견 사항의 정확성과 유용성을 측정해야 한다. 검토 에이전트는 사람의 탐색 비용을 줄여야 하며, 누구도 책임 있게 처리할 수 없는 또 다른 대기열을 만들어서는 안 된다.

회의적인 결론은 분명하다. AI 지원 검토는 AI 생성 물량을 관리하는 데 도움이 될 수 있지만, 증거는 고위험 변경에서 사람의 책임성을 제거하는 것을 뒷받침하지 않는다.

주니어 엔지니어 파이프라인은 다른 위험에 직면한다

에이전트가 주니어 엔지니어를 훈련시키던 업무를 흡수한다면, 기업은 초보자에서 신뢰받는 검토자로 가는 경로를 의도적으로 다시 구축해야 한다.

신입 개발자는 전통적으로 구현을 통해 판단력을 얻는다. 기존 코드를 추적하고, 범위가 제한된 변경을 만들며, 상세한 피드백을 받고, 실패를 디버깅한 뒤, 점차 더 큰 시스템을 다룬다.

이러한 업무 중 다수는 코딩 에이전트에 잘 맞는다. 범위가 정해져 있고, 반복적이며, 시니어 엔지니어가 쉽게 설명할 수 있다.

이를 자동화하면 단기 산출량을 개선할 수 있다. 동시에 초보자에게 추상화가 어떻게 실패하는지, 관례가 왜 존재하는지, 프로덕션 시스템이 복잡성을 어디에 숨기는지 가르치는 연습 기회를 없앨 수도 있다.

주니어 엔지니어는 아직 이해하지 못하는 코드를 승인한다고 해서 신뢰할 수 있는 검토자가 될 수 없다. 생성된 결과물을 읽는 것은 도움이 되지만, 수동적인 검토가 소프트웨어를 만들고, 망가뜨리고, 고치는 일을 완전히 대체하지는 못한다.

Making Sense는 주니어 엔지니어들 사이에서 가장 큰 AI 생산성 향상 중 일부를 경험한 것으로 알려졌다. 이 컨설팅 기업은 에이전트가 구현을 처리할 때 이 직원들이 무엇을 배우지 못하게 되는지도 우려한다.

이에 대한 대응으로 주니어들이 고객이 기능을 왜 필요로 하는지, 해당 기능이 어떻게 동작해야 하는지 결정하는 과정에 계속 참여하도록 한다. 이들은 확인할 AI 생성 결과만 받는 대신 문제 정의에 참여한다.

IBM은 또 다른 접근을 시도하고 있다. 회사의 자동화 및 AI 총괄 매니저 Neel Sundaresan에 따르면, 신입 엔지니어들은 더 이른 시기에 더 까다로운 과제를 받는다.

AI는 구현과 테스트를 지원한다. 시스템이 실패하면 주니어 엔지니어는 시니어 승인을 받기 전에 문제를 진단하고 수정해야 한다.

Sundaresan은 AI가 주니어 엔지니어가 이전에는 시니어 개발자와 연관됐던 일부 업무의 70~80%를 수행하도록 도울 수 있다고 추정한다. 이 수치는 독립적인 생산성 측정이 아닌 경영진의 추정치다.

중요한 부분은 그에 수반되는 책임이다. 주니어들은 에이전트를 의심 없는 정보원으로 취급하는 대신 여전히 실패를 조사한다.

Synthesia는 주로 중급 및 시니어 엔지니어를 채용한다. 경험이 적은 직원들은 프로젝트의 정의된 부분을 맡으면서 시니어 동료와 AI 에이전트 모두와 함께 일한다.

Bonterra 역시 주니어 개발 방식을 바꿨다. 이제 에이전트는 한때 훈련 과제 역할을 했던 잘 정의된 업무 다수를 수행한다.

대신 회사는 주니어 엔지니어에게 경험 많은 동료와 함께 결과를 책임지도록 요구한다. 이들은 에이전트를 지시하고, 결과에 의문을 제기하며, 제공된 동작에 계속 책임을 진다.

Korlepra는 장기적 우려를 명확히 표현했다. “업계가 주니어 채용을 중단하면, 업계는 시니어 배출도 중단하게 됩니다.”

이 파이프라인 문제는 배포 대시보드에 즉시 나타나지 않는다. 기업은 신입 채용을 줄이고도 여러 분기 동안 산출량을 늘릴 수 있다.

비용은 나중에 레거시 시스템, 프로덕션 사고, 고객 제약, 아키텍처 이력을 이해하는 엔지니어가 필요할 때 발생한다. 이러한 역량은 축적된 경험을 통해 발전한다.

따라서 조직에는 처리량 지표와 함께 교육 신호가 필요하다. 주니어 엔지니어가 변경 사항을 설명하고, 실패를 진단하고, 테스트를 작성하며, 점점 더 모호한 과제를 처리할 수 있는지 추적해야 한다.

검토 참여에도 구조가 필요하다. 주니어 엔지니어에게 맥락 없이 거대한 에이전트 생성 패치를 주는 것은 판단력이 아니라 지구력만 가르친다.

더 작은 변경은 더 나은 학습 순환을 만든다. 명확한 명세, 제한된 범위, 관찰 가능한 테스트, 직접적인 시니어 피드백은 초보자가 의도와 구현을 연결하도록 돕는다.

사고 검토는 또 하나의 중요한 교실을 제공한다. 엔지니어는 겉보기에 무해한 결정이 왜 운영 장애를 만들었는지, 보호 장치를 어떻게 바꿔야 하는지 배운다.

기업은 이러한 교훈을 교육과 에이전트 맥락 모두에 반영할 수 있다. 그러나 사람의 학습 목표는 도구 배포의 부수 효과가 아니라 명시적으로 유지돼야 한다.

미래의 시니어 엔지니어는 에이전트를 지시하고 평가하는 데 더 많은 시간을 쓸 가능성이 크다. 이는 기초 지식의 중요성을 줄이는 것이 아니라 높인다.

판단에는 시스템에 대한 정신적 모델이 필요하다. 그 모델을 구축한 경험이 없다면, 검토자는 생성된 코드가 익숙해 보이는지만 평가할 수 있다.

따라서 주니어 파이프라인은 AI 코드 검토 문제의 일부다. 기업은 신뢰할 수 있는 소프트웨어와 자동화가 잘못됐을 때 이를 알아볼 수 있는 사람 모두를 길러야 한다.

새 워크플로가 작동하는지 보여줄 세 가지 신호

다음 단계는 프로덕션 안정성, 리뷰 비용 구조, 그리고 인간 전문성의 발전으로 평가받게 될 것이다.

첫 번째 신호는 pull request 물량 증가가 장애를 늘리지 않으면서 배포 성과를 개선하는지 여부다. 기업은 배포 빈도와 함께 롤백, 유출 결함, 인시던트, 보안 발견 사항을 공개하거나 내부적으로 추적해야 한다.

안정적인 되돌리기 비율은 고무적이지만, 모든 유지보수 비용을 포착하지는 못한다. 중복 로직과 아키텍처 드리프트는 눈에 보이는 인시던트를 일으키기 훨씬 전부터 프로덕션에 남아 있을 수 있다.

처리량이 늘어나는 동안 신뢰성과 유지보수 수준이 안정적으로 유지된다면, 재설계된 워크플로우의 신뢰도는 높아진다. 리뷰 대기열과 재작업이 계속 증가한다면, 생성은 제약 요인만 옮겨 놓은 셈이다.

두 번째 신호는 위험 기반 리뷰가 책임성을 약화시키지 않으면서 사람의 투입을 줄이는지 여부다. Bonterra와 Synthesia는 민감도에 따라 변경 사항을 라우팅하고 있으며, AWS는 초기 검증에 에이전트를 활용하고 있다.

유용한 근거는 엔지니어가 어떤 자동화 발견 사항을 수용하는지, 어떤 결함이 빠져나가는지, 그리고 저위험으로 분류된 변경 사항이 나중에 수리를 필요로 하는 빈도가 얼마나 되는지를 보여줘야 한다.

리뷰 지연 시간은 사람들이 내용을 이해하지 못한 채 더 많은 코드를 승인해서가 아니라, 자동화가 반복 업무를 제거하기 때문에 줄어들어야 한다. Temporal의 설명 요구 사항은 실제 이해도를 검증하는 한 가지 기준이 된다.

엔지니어가 기계적인 검토에는 더 적은 시간을 쓰면서도 생성된 설계를 설명하고 방어할 수 있다면, AI 코드 리뷰는 유용한 역할을 하고 있는 것이다. 승인이 형식적인 절차가 된다면, 워크플로우는 실패하고 있는 것이다.

세 번째 신호는 주니어 엔지니어가 독립적인 기술 책임자로 계속 성장하는지 여부다. 기업은 승진 준비도, 디버깅 성과, 인시던트 참여도, 그리고 주니어가 책임감 있게 완수할 수 있는 과제의 복잡도를 살펴봐야 한다.

단기적인 산출량 증가는 숙련된 리뷰어 공급이 줄어드는 문제를 보완하지 못한다. 자동화된 모든 훈련 과제에는 실제 결과와 피드백을 갖춘 대체 학습 루프가 필요하다.

Synthesia AI code review는 코딩 에이전트 자체가 하나의 구성 요소일 뿐임을 보여준다. 명세, 리포지터리 맥락, 자동화 검증, 에스컬레이션 정책, 인간의 설명, 경력 개발이 최종 결과를 결정한다.

이제 엔지니어링 리더는 AI가 얼마나 많은 코드를 생성했는지보다 더 어려운 질문을 던져야 한다. 검증 가능하고 유지보수 가능한 소프트웨어가 얼마나 많이 사용자에게 도달했는가, 그리고 팀은 다음 변경 사항을 판단할 능력을 강화했는가?

두 질문 모두에 답할 수 있는 조직은 생산성의 증거를 갖게 될 것이다. 그렇지 못한 조직은 불확실성을 하류에 축적하면서 더 빠르게 코드를 계속 생산하게 될 것이다.