AI가 작성한 코드, 누가 검토할까요?

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

Google CTO실에서는 인간과 AI 에이전트가 실제 운영 업무에 협업하는 하이브리드 모델로 팀을 운영하고 있습니다. 소프트웨어 개발 속도가 빨라졌습니다. 믿을 수 없을 정도로 빨라졌죠. 하지만 이러한 속도는 예상하지 못했던 문제를 드러냈습니다. 소프트웨어 출시의 병목 현상이 코드 작성에서 코드 검토 및 통합 단계로 옮겨간 것입니다.

대규모 pull 요청을 통해 배운 점

대시보드 재작성을 포함하여 에이전트의 대규모 기능을 개발하는 데 며칠이 걸렸습니다. pull 요청(PR)은 엄청난 규모였습니다. 변경사항이 화면을 가득 채우며 스크롤되었고, 어떤 검토자도 혼자서 전체 내용을 파악할 수 없었습니다. 관리 가능한 묶음으로 분할하려고 시도했지만, 기존 워크플로는 AI로 생성된 커밋의 양을 처리할 수 있도록 설계되지 않았다는 것을 알게 되었습니다.

개발자들이 같은 파일에 병합을 시도하면서 병합 충돌이 급증했습니다. 우리는 자꾸만 풀 수 없는 종속 항목 체인을 만들었습니다. PR #1은 PR #2 없이는 병합할 수 없었고, PR #2는 PR #3이 필요했지만, PR #3은 다른 시간대의 검토자 때문에 막혀 있었습니다. PR #4는 간단한 부분이라 이미 승인되었습니다. 일부 변경사항은 승인되었지만, 그와 관련된 다른 변경사항은 검토를 기다리는 동안 더 많은 충돌을 낳았습니다.

주말이 다가오자, 전체적으로 테스트할 수 있는 것이 아무것도 없었습니다. 메인 브랜치는 망가졌고, 스테이징 환경은 주황색 경고에 멈춰 있었으며, 팀 채팅은 서로를 위로하는 모임으로 변해 있었습니다.

이러한 문제는 매일 세 가지 방식으로 나타났습니다.

• 병합 충돌: 여러 개발자가 한 시간 내에 동일한 파일에 커밋을 적용하는 경우

• 검토 정체: 방대한 PR이 마트료시카 인형처럼 하위 PR로 분해

• 컨텍스트 단편화: 한 팀원이 커피를 마시러 간 사이에 다른 팀원이 공유 파일에서 변수 이름을 변경합니다. 그리고 에이전트가 어제의 스냅샷을 인용하여 더 이상 존재하지 않는 함수를 호출하는 코드를 열심히 생성합니다.

개발 속도가 빨라져도 버그 대 코드 비율은 일정하게 유지됩니다. 실제 오류율은 변하지 않으며, 단지 누가 비난받고 얼마나 빨리 비난받는지가 달라질 뿐입니다. 이러한 상황을 극복하기 위해 우리는 세 가지 중요한 교훈을 얻었습니다.

• 기술적 가드레일: 빠른 개발을 위한 안전망을 만들기 위해 구문 린터, 규칙, 스킬, 필수적인 AI 생성 테스트 범위를 구현했습니다.

• 소유권 재정의: 에이전트가 작성한 일회성 코드의 스타일에 대한 사소한 지적을 중단하고 아키텍처 청사진에 집중했습니다. 여러 시간대에 걸쳐 팀이 운영되는 경우, 테스트 통과를 조건으로 PR을 승인하는 '조건부 LGTM(Looks Good To Me)'을 도입하여 12시간의 지연 시간을 없앴습니다.

• AI 검토자 가이드: 이제 모든 PR에는 변경사항, 잠재적인 중단점, 위험 평가에 대한 AI 생성 스냅샷이 포함됩니다. 이를 통해 인간 검토자는 코드에 파묻히는 대신 정말 중요한 부분에 집중할 수 있습니다.

번아웃 및 '승인 피로' 방지

우리는 '승인 피로'라는 새로운 현상을 목격하고 있습니다. CNBC가 보도한 Quantum Workplace의 연구에 따르면, AI를 자주 사용하는 사람은 AI를 사용하지 않는 사람보다 번아웃을 경험할 가능성이 45% 더 높습니다. 우리 팀에서도 그 이유를 정확히 확인할 수 있습니다. 코드 한 줄을 수정하거나 도구 호출을 조정하는 등 끊임없이 이어지는 사소한 승인 요청을 처리하다 보면 개발자들은 반사적으로 '승인'을 클릭하기 시작합니다. 이는 팀이 AI의 속도를 따라잡기 위해 AI의 작업 결과 확인을 포기하는 약한 수준의 피로감입니다.

팀을 보호하기 위해 우리는 지속적인 감독에서 구조화된 경계로 방식을 전환했습니다. 승인 요청이 저녁이나 주말로 넘어가지 않도록 디지털 휴식 시간을 정했습니다. 또한 매주 에이전트 인사이트 세션을 개최하여 개발자들이 AI 파트너가 식별한 패턴을 공유하고 개별적인 발견을 조직 전체의 공유된 지식으로 전환하도록 합니다.

가드레일이 없는 상태에서 에이전트가 작동하면 어떻게 될까요?

지금까지는 검토 및 통합 측면에 초점을 맞췄습니다. 하지만 에이전트가 충분한 가드레일 없이 작동할 때 어떤 일이 발생하는지에 대해 뼈아픈 교훈을 얻은 적이 있습니다.

하루는 정기적인 코드 업데이트 중에 Antigravity의 기본 제공 UI 브라우저의 기능과 한계를 동시에 발견했습니다. 이 기능을 사용하면 AI 에이전트가 로그인 사용자 인증 정보 없이도 개발 중인 애플리케이션과 상호작용할 수 있어 UX 테스트에 매우 유용합니다. 그러나 YOLO(자동 승인) 모드에서는 이 작동이 생각보다 훨씬 빠를 수 있습니다.

버튼을 만들라는 제 간단한 프롬프트가 예상치 못한 연쇄 반응을 일으켰습니다. 브라우저 에이전트가 이메일 에이전트용으로 만들어진 새 버튼을 자율적으로 클릭한 것입니다. 지정된 URL이 없었기 때문에 에이전트는 이메일 보호 장치가 전혀 없는, 지원이 중단된 레거시 에이전트에 연결하여 할루시네이션을 일으켰습니다. 그 결과, 동료 50명이 할루시네이션 콘텐츠로 가득 찬 잘못된 이메일을 받게 되었습니다.

이 사고를 통해 저는 이제 컨텍스트 할루시네이션 위험이라고 부르는 문제를 처음 알게 되었습니다. AI에 충분한 데이터가 없으면 하드코딩된 이메일 주소나 URL과 같은 민감한 정보를 포함하여 컨텍스트에 존재하는 어떤 문자열이든 사용하여 빈 맥락을 채울 수 있다는 것입니다.

별일 아니라고 생각하시는 분도 있을 것입니다. '고작 이메일 한 통 더 받은 게 뭐 어때?'라고 생각하실 수도 있습니다. 그럴 수도 있겠죠. 하지만 에이전트가 실제로 어떤 일을 했는지 생각해 보세요. 에이전트가 해당 작업을 해야 하는지 여부에 대한 어떤 검증도 없이 사용 가능한 데이터만으로 지시를 이행한 것입니다. 이것이 바로 자율 시스템의 핵심 위험입니다. 인간 참여형 패턴 또는 정책 엔진이 없다면 에이전트는 찾을 수 있는 모든 것을 사용하여 목표를 달성하기 위해 최적화를 시도합니다. 가드레일은 선택사항이 아닙니다. 가드레일이 있어야만 유용한 도구가 예측 불가능한 도구로 변하는 것을 막을 수 있습니다.

문제 해결을 위해서는 몇 가지 즉각적인 변화가 필요했습니다.

• 도구를 실행하기 전에 권한 확인을 요구하는 정책 엔진을 통해 제로 트러스트 모델을 구현했습니다.

• 템플릿에서 이름, 이메일 주소와 같은 모든 개인 식별 정보(PII)를 {{placeholders}}로 대체하여 엄격한 컨텍스트 정제를 실천했습니다.

에이전트가 볼 수 없는 것을 오용할 수는 없으니까요. 아, 그리고 결국 기존 에이전트를 삭제하기로 결정했습니다.

병목 현상 이동

1년도 채 되지 않아 소프트웨어 개발 주기가 획기적으로 빨라졌습니다. 점심시간 전, 때로는 첫 Red Bull 캔의 효과가 나타나기도 전에 에이전트가 1,000줄의 잘 문서화된 코드를 생성하는 것을 보면 아직도 짜릿합니다.

하지만 이 속도에는 중요한 사실이 숨어 있습니다. AI가 코드 작성의 병목 현상을 제거하자 제약 조건은 하류로 이동했고, 모든 출력을 검토, 테스트, 통합해야 하는 인간에게 부담이 가중되었습니다. 더 나은 프롬프트나 더 빠른 모델로는 이 문제를 해결할 수 없습니다. 이 문제를 해결하려면 팀이 협업하는 방식, 코드를 검토하는 방식, 휴식 없이 작동하는 도구들과의 업무 경계를 설정하는 방식을 발전시켜야 합니다.

병목 현상은 사라지지 않았습니다. 코드에서 코드를 검토하는 사람으로 옮겨갔을 뿐입니다.