이제 제 코드의 대부분은 AI가 작성합니다. 저는 이에 대해 불만은 없습니다. 더 빠르고, 대부분의 경우 정확하기 때문입니다.

하지만 이 에이전트들이 하루 종일 만들어내는 결과물들을 몇 달간 검토한 결과, 매우 구체적이고 매우 일관된 방식으로 실패한다는 점을 발견했습니다. 무작위적인 쓰레기가 아닙니다. 그럴듯하고, 형식이 잘 갖춰져 있으며, 테스트를 통과하지만 테스트 스위트(test suite)가 절대 알아차리지 못하는 방식으로 틀린 코드입니다.

다음은 제가 이제 모든 AI 보조 PR(Pull Request)에서 찾아내는 7가지 유형과, 각 버그가 프로덕션(production)에 도달하기 전에 잡아내는 방법입니다.

1. 자체 API에 대한 파괴적 변경 (Breaking change)

에이전트가 응답 DTO를 "정리"합니다. 필드 이름을 바꾸거나, 사용하지 않는 것처럼 보이는 필드를 삭제하거나, 무언가를 선택 사항(optional)으로 만듭니다. Diff(차이)는 깔끔하고, CI는 통과(green)합니다.

하지만 그 필드는 다른 팀, 모바일 앱, 또는 파트너 연동(integration)이 의존하고 있는 계약(contract)에 포함되어 있었습니다. 변경 사항은 이 레포지토리(repo) 내에 있지 않으므로 여기서 무엇도 이를 감지할 수 없으며, 에이전트가 동일한 커밋에서 테스트 코드까지 업데이트했기 때문에 테스트는 통과합니다.

잡는 법: CI에서 현재 배포된 버전과 OpenAPI/스키마(schema)를 비교(diff)하고, 삭제/이름 변경/범위 축소된 필드가 있으면 실패하도록 설정하세요. 사람은 600줄짜리 diff에서 이름이 바뀐 키를 놓칠 수 있지만, diff 도구는 절대 놓치지 않습니다.

2. 모든 테스트를 통과하는 N+1 쿼리

에이전트는 매우 관용적(idiomatic)으로 보이는 ORM 루프를 작성하여 행(row)당 하나의 쿼리를 실행합니다. 3개의 행만 있는 테스트 피스처(fixture)에서는 즉각적으로 실행됩니다. 하지만 50,000개의 프로덕션 데이터 행에서는 데이터베이스를 녹여버립니다.

테스트는 아주 작은 피스처에서 실행되므로, 실제 데이터를 가진 고객이 이를 마주하기 전까지는 보이지 않습니다.

잡는 법: 테스트에서 쿼리 횟수를 단언(assert)하고(assertNumQueries(2) 등), 핫 패스(hot paths)에 대해 부하 테스트(load-test)를 수행하며, 스테이징(staging) 환경에서 슬로우 쿼리 로깅(slow-query logging)을 활성화하세요.

3. 해피 패스(Happy-path) 전용 코드

에이전트는 프롬프트에 제공된 예시에 최적화합니다. 성공 사례를 보여주었기 때문에, 성공 사례를 작성한 것입니다. Null 입력, 빈 리스트, 타임아웃, 다운스트림 서비스(downstream service)로부터의 500 에러 등은 조용히 처리되지 않은 채 남겨집니다.

잡는 법: 속성 기반 테스트(property-based testing, 수천 개의 이상한 입력을 던져보는 방식)를 수행하고, 언해피 패스(unhappy path)를 명시적으로 검토하세요. "이것이 null/빈 값/느림/다운 상태가 되면 어떻게 되는가?"를 확인하는 것은 여전히 당신의 업무입니다.

4. 동시성 버그 (The concurrency bug)

코드는 싱글 스레드(single-threaded) 환경에서는 정확합니다. 공유 리소스에 대한 '확인 후 동작 (Check-then-act)', 보호되지 않은 카운터, 누락된 트랜잭션 등이 이에 해당합니다. 당신의 테스트 스위트(test suite)는 직렬(serially)로 실행되기 때문에, 레이스 컨디션(race condition)을 결코 재현하지 못합니다.

해결 방법: 실제로 병렬(parallel)로 실행되는 동시성 테스트를 수행하고, 멱등성 (idempotency)을 고려하여 설계하며, 애플리케이션 로직이 놓친 최후의 보루로서 데이터베이스 제약 조건 (database constraints)에 의존하세요.

5. 자신만만하게 오래된 API (The confidently outdated API)

모델의 학습 데이터에는 반감기가 있습니다. 모델은 지원 중단된 (deprecated) 메서드, 두 버전 전에 제거된 플래그, 또는 거의 맞지만 틀린 함수 시그니처 (function signature)를 호출할 것입니다. 컴파일도 되고 실행도 되지만, 조용히 부패해 갑니다.

해결 방법: 의존성 (dependencies) 버전을 고정하고, 지원 중단 (deprecation) 사항에 대해 린트 (lint)를 수행하며, 모델의 확신보다 공식 문서를 더 신뢰하세요. "작동했다"는 것이 "최신이다"라는 뜻은 아닙니다.

6. 보안적 실수 (The security footgun)

문자열 보간 (String-interpolated) SQL, 누락된 권한 확인 (authorization check), 로그 라인에 포함되어 버린 비밀 값 (secret), 에러를 없애기 위해 *로 설정된 CORS 등이 있습니다. 당신의 테스트는 _안전성 (safety)_이 아니라 _동작 (behavior)_을 검증하기 때문에, 이 모든 것들이 통과됩니다.

해결 방법: CI 단계에서 정적 애플리케이션 보안 테스트 (SAST)를 수행하고, 보안에 특화된 전용 리뷰 단계를 거치며, 에이전트의 "작동한다"는 말이 인증(auth)이나 입력 처리 (input-handling) 코드의 기준이 될 수 없다는 규칙을 세우세요.

7. 예스맨 테스트 (The yes-man test)

이것은 미묘하면서도 가장 위험한 버그입니다.

동일한 에이전트가 코드와 테스트를 한 번에 작성하면, 테스트는 더 이상 독립적인 검증 수단이 되지 못합니다. 테스트는 버그를 포함하여 코드가 실제로 수행하는 동작이 무엇이든 간에 그것을 검증해 버립니다. 테스트와 코드가 서로 일치하도록 작성되었기 때문에, 당신은 초록색 체크 표시를 받지만 보호는 전혀 받지 못하게 됩니다.

- assertThat(json).contains("\"currency\":\"USD\"");
+ assertThat(json).doesNotContainKey("currency");   // 변경 사항에 맞춰 테스트를 "수정"함

해당 테스트는 파괴적인 변경 사항을 잡아낸 것이 아니라, 오히려 그것을 _승인 (ratified)_해 버린 것입니다.

해결 방법: 에이전트가 구현 (implementation)에 손을 대기 전에 명세서 (spec)를 바탕으로 테스트를 작성하세요. 그리고 코드와 동일한 커밋에서 수정된 모든 테스트는 해당 코드를 검증하는 대상으로서 깊은 의구심을 가지고 다루어야 합니다.

일곱 가지 버그에 흐르는 공통 패턴

이 모든 버그에는 동일한 근본 원인이 있습니다. AI는 코드를 작성하는 (writing) 비용을 거의 제로로 만들었지만, 자신이 편집 중인 함수 외부에 존재하는 요소들—즉, 다른 서비스, 프로덕션 데이터 볼륨, 동시성 (concurrency), 소비자 (consumers), 위협 모델 (threat model)—은 인지하지 못합니다.

병목 현상은 타이핑 (typing) 단계에서 검증 (verifying) 단계로 이동했습니다. 그리고 에이전트가 자신의 코드를 위해 직접 작성한 테스트는 검증이 아닙니다. 그것은 에이전트가 자기 자신에게 동의하는 것에 불과합니다.

따라서 이제 중요한 레버리지(leverage)는 더 똑똑한 프롬프트가 아닙니다. 에이전트가 속일 수 없는 가드레일(guardrails)입니다. 즉, 계약 검사 (contract checks), 쿼리 예산 (query budgets), 보안 스캔 (security scans), 그리고 보호 대상 코드와 독립적으로 작성된 테스트가 필요합니다.

AI 에이전트가 당신을 대신해 확신에 차서 배포(ship)했던 가장 어처구니없는 일은 무엇이었나요? 저는 이런 사례들을 수집하고 있습니다. 👇