수천 줄의 통합 테스트 로그를 띄워놓고 16개의 로그 파일 중 대체 어디에 버그가 숨어 있는지 찾아 헤매는 상황은 개발자라면 누구나 겪는 고통이다. 이번 주 해외 매체를 통해 공개된 구글의 사례는 이 지독한 로그 찾기 전쟁에 종지부를 찍으려는 시도를 보여준다.

Gemini 2.5 Flash 기반 Auto-Diagnose의 90.14% 정확도

구글 연구팀이 공개한 Auto-Diagnose(자동 진단 도구)는 통합 테스트(여러 컴포넌트가 서로 올바르게 통신하는지 확인하는 테스트) 실패 로그를 읽어 원인을 찾고 코드 리뷰에 직접 진단 결과를 게시한다. 39개 팀의 실제 실패 사례 71건을 대상으로 한 수동 평가에서 90.14%의 정확도로 근본 원인을 찾아냈다. 실제 운영 환경에서는 22,962명의 개발자가 작성한 91,130건의 코드 변경분과 224,782회의 실행, 52,635건의 실패 테스트에 적용되었다. 사용자 피드백 결과 도움이 되지 않았다는 응답률은 5.8%에 불과했다.

이 시스템은 Gemini 2.5 Flash 모델을 사용하며 설정값은 temperature = 0.1, topp = 0.8이다. 구글의 통합 테스트 데이터로 별도의 미세 조정을 거치지 않고 오직 프롬프트 엔지니어링(AI 모델이 더 좋은 답을 내도록 입력문을 설계하는 기술)만으로 구현했다. 실행당 평균 110,617개의 입력 토큰과 5,962개의 출력 토큰을 사용하며, 응답 속도는 p50(전체 데이터 중 하위 50% 지점의 속도) 기준 56초, p90(하위 90% 지점의 속도) 기준 346초다. 결과물은 마크다운(텍스트 기반의 가벼운 문서 양식) 형태로 작성되어 Critique(구글 내부의 코드 리뷰 시스템)에 게시된다.

단순 증상 나열을 넘어 근본 원인을 짚어내는 추론 구조

왜 개발자들은 통합 테스트 진단에 그토록 많은 시간을 쓰는가. 구글의 6,059명 개발자 대상 설문 조사 결과, 통합 테스트 실패 진단은 가장 큰 불만 사항 중 하나였다. 특히 116명의 개발자를 대상으로 한 심층 조사에서 통합 테스트 실패의 38.4%는 진단에 1시간 이상이 걸렸고, 8.9%는 하루 이상이 소요되었다. 이는 유닛 테스트(개별 함수나 클래스 단위를 검증하는 테스트)의 진단 시간보다 압도적으로 길다.

문제는 구조에 있다. 테스트 드라이버 로그는 타임아웃이나 어설션 오류 같은 일반적인 증상만 보여줄 뿐이다. 실제 에러는 SUT(System Under Test, 테스트 대상 시스템) 구성 요소 로그 속에 파묻혀 있으며, 복구 가능한 경고나 무관한 에러 메시지들 사이에 숨어 있다. Auto-Diagnose는 pub/sub(발행-구독: 메시지를 보내는 쪽과 받는 쪽을 분리해 비동기적으로 통신하는 방식) 이벤트를 통해 작동하며, 데이터 센터와 프로세스, 스레드 전체에서 INFO 레벨 이상의 로그를 수집해 타임스탬프 순으로 정렬한 단일 스트림을 모델에 입력한다.

여기서 핵심은 모델이 무작정 답을 내지 않게 만드는 단계별 프로토콜이다. 로그 섹션 스캔, 컴포넌트 문맥 읽기, 실패 지점 위치 파악, 에러 요약 순으로 사고하게 하며, 실패한 컴포넌트의 로그가 없으면 결론을 내지 말라는 강한 부정 제약 조건을 걸었다. 이를 통해 AI 특유의 환각을 줄이고 실제 인프라 버그까지 찾아내는 부수적 효과를 거뒀다. 실제로 로그가 제대로 저장되지 않아 진단에 실패한 사례 7건 중 4건은 실제 인프라 버그로 판명되어 수정되었다.

AI가 코드를 짜는 시대를 넘어, 이제는 개발자가 가장 싫어하는 로그 분석이라는 단순 노동을 완전히 대체하는 단계로 진입했다.