「이 버그 좀 고쳐줘」라고 AI에게 부탁해서 해결되었다고 생각했던 버그가 있었습니다.

3주 후에 다른 증상으로 재발했습니다. 원인을 추적해 보니, 첫 번째 "수정"은 증상을 없앴을 뿐, 근본 원인을 **한 단계 더 깊은 레이어 (Layer)**로 밀어 넣은 것이었습니다.

이때 저는 AI에게 전적으로 맡기는 디버깅에는 코드와는 별개의 부작용이 있다는 것을 깨달았습니다. 그로부터 3개월 동안, 저는 저 자신과 사내 팀이 AI에게 던진 디버깅 100건을 계속해서 기록했습니다. 분류를 마친 후 나타난 것은, AI에 의존할수록 버그가 깊어지는 5가지 패턴이었습니다.

이것은 AI 리뷰의 간과에 대한 이야기가 아닙니다. 디버깅 100건의 실측 분류입니다. 인지 편향이나 심리적인 측면의 이야기도 아닙니다. AI 개입 디버깅의 결과 로그를 실측 분류한 기록입니다.

역설적인 중심 명제

3개월간의 관측을 통해 제가 이끌어낸 명제는 다음의 한 문장이었습니다.

AI에게 전적으로 맡길수록, 증상은 사라지지만 근본 원인은 깊게 숨겨진다.

개입도 50-75% 구간이 최악이다.

개입도 100% (전부 AI에게 맡김)에서는 AI 스스로가 이상하다는 것을 깨닫는 케이스도 있었습니다. 개입도 0% (인간만 수행)에서는 시간은 걸리지만 근본 원인까지 도달할 수 있었습니다. 하지만 개입도 50-75%에서는 AI가 증상을 없애고, 인간이 "고쳐졌다"라고 오인하는 조합이 발생하여, 근본 원인이 보이지 않은 채 매몰되었습니다.

저는 이전에 「코드 리뷰를 6단계로 나누었더니 AI와 인간의 분업이 보였다」라는 기사에서, 코드 리뷰에서는 중간(60%)이 최악의 구간이라고 썼습니다. 디버깅에서도 동일한 구조가 나타난 것은 저에게도 놀라운 일이었습니다.

AI 개입도별 실측 매트릭스 (Matrix)

먼저 데이터를 보여드리겠습니다. 100건을 AI 개입도에 따라 5단계로 나눈 결과입니다.

AI 介入度別の根本原因発見率と再発率

그래프에서 읽을 수 있는 점은 다음 3가지입니다.

• 100% (전부 AI)와 0% (인간만)는 재발률이 낮은 양극단
• 50-75% 구간은 근본 원인 발견율이 최저이며, 재발률이 최고
• 25% 구간은 근본 원인 발견율이 가장 높음 (AI가 로그 정리와 1차 가설을 담당하고, 인간이 판단을 담당함)

즉 "AI를 어디까지 사용할 것인가"가 아니라, "AI에게 어느 페이즈 (Phase)를 맡길 것인가"에 따라 결과가 달라집니다.

패턴 1: 증상 제거 ── try-catch로 매몰되는 근본 원인

100건 중 28건에서 관측된, 가장 빈도가 높은 패턴입니다.

제가 처음에 겪었던 예시입니다. 「API가 500 에러를 반환한다」라고 AI에게 전달했더니, AI는 try-catch를 추가하고 null 체크를 늘렸습니다. 에러는 사라졌습니다. 저는 "고쳐졌다"라고 판단했습니다.

3주 후, 완전히 다른 엔드포인트에서 동일한 500 에러가 발생했습니다. 원인은 커넥션 풀 (Connection Pool)의 고갈이었습니다. 첫 번째 try-catch는 풀 고갈의 증상을 억누르고 있었을 뿐입니다.

대규모 언어 모델 (LLM)은 "다음에 올 가장 확률 높은 토큰 (Token)"을 예측하는 구조입니다. 학습 데이터에 대량으로 존재하는 "에러 핸들링 (Error Handling) 패턴"을 근본 원인 조사보다 먼저 내놓습니다. 인간이 "그 핸들링이 올바른가"를 검증하지 않는 한, 증상 제거 방식은 그대로 채택됩니다.

이 패턴의 재발률은 제 관측 결과 78%였습니다. 10건 중 8건 가까이가 3주 이내에 다른 증상으로 재발하고 있습니다.

패턴 2: 조기 완료 보고 ── 아직 조사 중인데 "완료했습니다"

100건 중 23건에서 관측된 패턴입니다.

Anthropic의 연구 팀은 AI 에이전트가 장시간 태스크에서 빠지기 쉬운 3가지 드리프트 (Drift) 중, Premature Exit (조기 이탈)을 첫 번째로 꼽고 있습니다. 태스크가 완료되지 않았음에도 "완료했습니다"라고 보고하는 거동입니다.

디버깅 문맥에서는 다음과 같이 나타났습니다. 표면적인 증상이 사라진 시점에 AI가 "수정 완료입니다"라고 선언합니다. 인간은 "AI가 완료라고 하니까"라며 받아들이고, 근본 원인 조사가 중단됩니다.

제가 관측한 전형적인 예시는 테스트 실패 수정이었습니다. 테스트가 하나 통과됨으로써 AI는 "수정 완료"라고 보고했지만, 실제로는 테스트의 어서션 (Assertion)이 느슨하여 버그를 재현하지 못하고 있었습니다. 테스트가 통과된 것은 로직이 옳았기 때문이 아닙니다. 테스트의 검증 조건이 느슨했기 때문입니다.

이 드리프트를 방지하려면 성공 판정의 외부화가 필요합니다. "AI가 자신의 작업을 스스로 평가하는" 구조에서는 Premature Exit가 자동으로 발생합니다.

패턴 3: 리트라이 (Retry) 양산 ── 장애를 "증폭"시키는 수정

100건 중 17건에서 관측된 패턴입니다.

「타임아웃이 많으니 고쳐달라」고 AI에게 요청하면, AI는 3회 재시도 (Retry) 로직을 추가합니다. 로컬 환경에서는 에러가 줄어듭니다. 하지만 운영 환경에서 트래픽이 증가하는 순간, 재시도는 증폭 장치가 됩니다.

의존 관계가 클라이언트 → API Gateway → Backend의 3단계로 구성되어 있을 경우, 각 단계에서 3회 재시도를 하면 1개의 요청이 최종적으로 27개의 요청으로 증폭됩니다. 장애 중인 서버에는 평소보다 27배의 부하가 몰려듭니다. 로드 밸런서 (Load Balancer)가 장애 서버를 제외하지 않는 한, 이 증폭은 멈추지 않습니다.

제가 관측한 실례에서는 AI가 추가한 재시도로 인해 운영 환경의 장애 복구 시간이 40분 늘어났습니다. 재시도를 제거하는 것이 복구의 크리티컬 패스 (Critical Path)에 포함되어 있었기 때문입니다.

패턴 4: 가설 고착 ── 잘못된 가설에서 파생된 조사가 모두 헛수고

100건 중 19건에서 관측된 패턴입니다.

Anthropic의 3가지 드리프트 (Drift) 중, 누적 편차 (Cumulative Deviation)가 이에 해당합니다. 작은 판단 실수가 쌓여 결국 크게 방향을 잘못 잡게 됩니다.

구체적인 예입니다. AI에게 "왜 응답이 느린가"라고 물었을 때, AI는 "N+1 쿼리가 원인일 가능성이 높습니다"라고 첫 번째 가설을 세웁니다. 저는 그 가설을 믿고 AI와 함께 40분을 들여 SQL 로그를 분석했습니다. 하지만 진짜 원인은 프론트엔드의 JavaScript 번들 (Bundle)이 12MB까지 불어나 있었던 것이었습니다.

40분간의 SQL 분석은 모두 헛수고였습니다. 게다가 AI는 "N+1 쿼리 가설"을 계속 유지하며, SQL 로그 속에서 억지로 N+1의 흔적을 찾으려 했습니다. 맞지 않는 증거는 무시하고, 맞는 증거만 골라내는 동작입니다.

이 패턴의 무서운 점은 AI가 가설 유지를 우선시한다는 데 있습니다. 사람이 "다른 가설은 없는가"라고 개입하지 않는 한, AI는 첫 번째 가설의 주변만을 계속 파고듭니다.

패턴 5: 테스트 사기 ── 통과된 테스트가 버그를 재현하지 못함

100건 중 13건에서 관측된 패턴입니다.

3가지 드리프트 중, 품질 과신 (Quality Overconfidence)이 이에 해당합니다. 테스트를 작성했지만, 그 테스트 자체가 버그의 재현 조건을 올바르게 커버하지 못하는 패턴입니다.

AI에게 "이 버그의 재현 테스트를 작성해줘"라고 부탁하면, AI는 재현 테스트를 작성합니다. 테스트는 통과합니다. AI는 "수정이 올바르다는 증거입니다"라고 보고합니다. 하지만 테스트의 어설션 (Assertion)은 "에러가 발생하지 않는 것"만을 검증하고 있으며, 실제 버그 (레이스 컨디션 (Race Condition), 병행 액세스, 경계값)는 재현하지 못하고 있습니다.

제가 관측한 예에서는 AI가 작성한 테스트가 "500 에러가 반환되지 않는 것"만을 보고 있었습니다. 하지만 진짜 버그는 "특정 순서로 두 개의 요청이 들어오면 한쪽의 데이터가 깨지는" 레이스 컨디션이었습니다. 테스트는 계속 통과했지만, 버그는 그대로 남아 있었습니다.

5가지 패턴의 분포와 재발률

3개월간 100건을 분류한 결과를 하나의 매트릭스 (Matrix)로 남깁니다.

분포를 통해 알 수 있는 것은 패턴 5 (테스트 사기)가 가장 재발률이 높다는 점입니다. 테스트가 통과된 이상, 다음 버그가 현상화될 때까지 아무도 눈치채지 못합니다. 시차를 두고 폭발할 지뢰를 AI가 테스트를 통과시키는 방식으로 매설해 나가는 것입니다.

AI가 잘하는 단계와 맡겨서는 안 되는 단계

100건을 분류하며 얻은 부산물로, AI에게 맡겨도 좋은 단계와 나쁜 단계의 분기점이 보였습니다.

AI에게 맡겨도 좋은 단계:

• 로그 패턴 인식: 수 시간 분량의 로그를 수 초 만에 처리하여 이상 지점을 추출할 수 있습니다.
• 빠른 가설 생성: 증상으로부터 생각할 수 있는 원인을 망라하여 10개 정도 나열할 수 있습니다.
• 코드 추적: 함수 호출 체인 (Call Chain)을 여러 파일에 걸쳐 정확하게 따라갈 수 있습니다.
• 테스트 자동 생성: 버그의 재현 테스트를 구조로부터 생성할 수 있습니다.

AI에게 맡겨서는 안 되는 단계:

• 가설의 채택: 어떤 가설로 조사를 진행할지는 사람이 결정해야 합니다.
• 수정 방침의 판단: 시스템 전체에 미치는 영향은 AI가 가지지 못한 맥락에서 판단이 필요합니다.
• 완료 판정: "버그가 고쳐졌다"는 것을 AI가 스스로 말해서는 안 됩니다.

방향 설정과 검증은 사람, 실행은 AI. 이것이 100건을 분류하며 남은 분업 라인이었습니다.

5가지 패턴 자기 진단 체크리스트

자신의 최근 디버깅을 5가지 패턴으로 되돌아보기 위한 체크리스트를 제시합니다.

패턴 1 (증상 억제)

• 추가한 것이 try-catch / null 체크 / 에러 무시(Error swallowing)뿐은 아닌가
• 그 에러가 "왜 발생했는지"를 한 문장으로 설명할 수 있는가
• 3주 후에 다른 증상이 나타나지 않을 것이라고 확신할 수 있는가

패턴 2 (조기 완료 보고)

• "완료했습니다"라는 판단을 AI가 아닌 인간이 했는가
• 테스트가 통과했다는 것 외에, 근본 원인(Root cause)의 특정을 나타내는 증거가 있는가
• 수정 후에 다른 곳에서 영향이 나타나지 않았는가

패턴 3 (재시도 양산)

• 추가한 재시도(Retry)는 몇 단계인가 (의존 그래프를 그렸는가)
• 타임아웃(Timeout) 연장이나 캐시 TTL 연장을 안이하게 채택하고 있지는 않은가
• 운영 트래픽(Production traffic)에서 재시도가 증폭 장치가 되지 않을 것인가

패턴 4 (가설 집착)

• 첫 번째 가설 이외의 후보를 3가지 제시했는가
• 40분 이상 같은 가설을 계속 파고들고 있지는 않은가
• AI가 가설을 유지하기 위해 증거를 선별(Cherry-picking)하고 있지는 않은가

패턴 5 (테스트 사기)

• 테스트의 어설션(Assertion)이 실제 버그 조건을 재현하고 있는가
• 레이스 컨디션(Race condition)・병행 액세스(Concurrent access)・경계값(Boundary value)을 포함했는가
• 테스트를 인간이 읽고 "이것으로 버그를 재현할 수 있다"라고 납득할 수 있는가

AI 전담 비중을 50% 이하로 좁히는 디버깅 프로토콜

제가 100건의 사례 이후에 채택한, AI 개입도를 50% 이하로 고정하는 3단계 프로토콜입니다.

Stage 1: 가설과 검증은 인간이 주도한다

"왜 이 버그가 발생했는가"에 대한 가설과 "그 가설을 검증하는 방법"은 인간이 결정합니다. AI에게는 "그 방법을 실행하는 데 필요한 로그 추출이나 코드 추적"만을 맡깁니다.

Stage 2: 수정은 "근본 원인이 언어화된 후에" 작성한다

수정 코드를 작성하기 전에, 저는 자신의 언어로 3줄의 근본 원인을 작성합니다. 작성할 수 없다면 아직 수정 단계로 진입하지 않습니다. AI에게 "이 근본 원인을 수정하는 코드를 작성해줘"라고, 원인을 문자로 만든 뒤에 전달합니다.

Stage 3: 완료 판정은 테스트 통과만으로 수행하지 않는다

테스트가 통과한 후, 저는 자신에게 3가지 질문을 던집니다. "이 테스트는 정말로 버그를 재현하고 있는가", "같은 근본 원인으로 인한 다른 증상은 없는가", "3주 후에 재발할 가능성은 있는가". 3가지 모두에 '예'라고 답할 수 없다면 완료라고 하지 않습니다.

요약

3개월간 100건을 분류하며 제가 얻은 것은 다음 3가지입니다.

• AI 개입 디버깅의 부작용은 5가지 패턴으로 분류할 수 있으며, 재발률이 58%에서 85%로 매우 높다는 것을 알게 되었습니다.
• 최악의 개입도 구간은 50-75%로, AI가 증상을 지우고 인간이 오인하는 조합이 발생했습니다.
• 가설과 검증 및 완료 판정은 인간이 맡고, 실행만을 AI에게 넘기면 5가지 패턴의 발생률이 크게 낮아졌습니다.

"이 버그 고쳐줘"라는 한마디로 AI에게 던지기 전에, 근본 원인을 3줄 먼저 작성하십시오. 이 한 번의 수고가 3주 뒤의 자신을 돕습니다.

관련 나의 기사

Discussion