디버깅 및 근본 원인 분석

이득:

• 버그를 재현 가능한 가장 작은 인스턴스로 줄이고 완전한 증거를 갖춘 AI로 옮기는 기능
• 가장 저렴한 컨트롤로 증거 기반 가설을 테스트하고 근본 원인을 찾는 능력
• 증상 패치가 아닌 회귀 테스트로 근본 원인 해결 및 확보 능력

디버깅은 소프트웨어가 예기치 않게 작동하는 이유를 찾아 수정하는 프로세스입니다. 개발자가 가장 많은 시간을 보내고 가장 피곤해지는 일입니다. 대부분의 경우 실수는 나타나는 곳에 있는 것이 아니라 몇 단계 뒤에 숨겨져 있기 때문입니다. AI는 이 연구를 가속화하는 강력한 사고 파트너입니다. 단, 올바른 증거를 제공하는 경우에만 가능합니다. 증거 없는 디버깅은 AI가 가장 많은 환각을 일으키는 영역입니다.

이 단원에서는 오류 생성부터 근본 원인 파악까지, 즉 증상 명확화, 증거 수집(오류 메시지, 스택 추적, 로그, 항목), 가설 생성, 가설 테스트, 수정 사항 검증까지 체계적인 흐름을 설정합니다. AI는 모든 단계에서 도움을 줍니다. 그러나 "수정된" 결정은 버그가 실제로 사라졌음을 확인함으로써 내려집니다.

왜 증거가 전부인가?

LLM은 여러분이 보는 것처럼 오류를 보지 않습니다. 그는 당신이 그에게 말하는 것만 알고 있습니다. "애플리케이션이 충돌합니다"와 같은 문장은 모델에 거의 정보를 제공하지 않으며 모델은 예측, 즉 환각으로 그 공백을 채웁니다. 결과적으로, 전체 오류 메시지, 스택 추적 — 오류가 발생한 함수 호출에 대한 분석, 오류를 유발한 입력, 예상된 내용 등. 관찰된 동작이 주어지면 모델은 실제 확률의 순위를 매길 수 있습니다.

디버깅할 때 AI를 탐정의 조수로 생각하십시오. 더 많은 증거를 제시할수록 AI가 생성하는 가설이 더 정확해집니다. 증거가 없으면 보조자는 추측만 하고 잘못된 길로 안내할 수 있습니다.

팁: 버그를 AI로 포팅하기 전에 버그를 재현 가능한 가장 작은 예로 줄이세요. 오류를 유발하는 가장 작은 코드와 입력은 귀하와 모델 모두에게 일을 근본적으로 더 쉽게 만듭니다. 대부분의 경우 이러한 감소 과정에서 원인을 스스로 찾아냅니다.

단계별: 근본 원인 분석 흐름

1. 증상을 명확히 하세요. "무슨 일이에요, 무슨 일이 일어날 거라고 예상하셨나요?" 두 가지를 한 문장으로 쓰세요.
2. 증거를 수집하세요. 전체 오류 메시지, 스택 추적, 관련 로그 라인, 트리거 항목, 버전 정보.
3. 가설을 세워보세요. AI에서 "이 증상을 설명하는 3가지 가능한 원인과 각 원인을 어떻게 테스트합니까?" 묻다.
4. 가장 저렴한 가설을 먼저 테스트해 보세요. 로그를 추가하고, 값을 인쇄하고, 테스트를 실행하세요. 증거가 가설을 확증하는가?
5. 증상이 아닌 근본 원인을 해결하세요. 패치로 증상을 침묵시키는 대신 근본 원인을 해결하십시오.
6. 회귀 테스트를 검증하고 추가합니다. 오류가 사라지는 것을 확인하세요. 그런 다음 오류가 다시 발생하지 않도록 해당 오류를 포착하는 테스트를 작성하세요.

미니 케이스 3개

사례 1 — 스택 추적이 올바른 파일로 이어졌습니다. 애플리케이션이 특정 요청에 대해 500 오류를 반환했습니다. 개발자는 AI에 전체 스택 추적 및 트리거 요청을 제공했습니다. 모델은 날짜 구문 분석 레이어의 없음 값으로 인해 오류가 발생했다고 가정했습니다. 개발자는 해당 줄에 로그를 추가하고 이를 확인한 후 15분 만에 해결했습니다. 전날 검증되지 않은 실험으로 2시간을 낭비했다.

사례 2 - 환각으로 인해 잘못된 길로 인도되었습니다. 다른 개발자는 단순히 "데이터베이스 연결이 끊어지고 있습니다"라고 썼습니다. AI는 아무런 증거도 없이 연결 풀 설정을 비난했다. 개발자는 이 설정을 수정하는 데 40분을 소비했습니다. 실제 원인은 네트워크 측의 시간 초과였으며 로그를 통해서만 알 수 있었습니다. 교훈: 증거 없이 취한 가설은 가능성이 있을 뿐 신뢰할 수는 없습니다.

사례 3 - 불안정한 오류가 발견되었습니다. 가끔 실패하는 테스트가 있었습니다. AI에는 테스트 코드, 실패 메시지, "때때로 통과하고 때로 실패"라는 정보가 제공되었습니다. 모델은 테스트의 공유 시간/순서 종속성을 나타냈습니다. 검토 결과 테스트는 시스템의 현지 시간을 기준으로 한 것으로 확인되었습니다. 시계가 고정(모의)되면 테스트가 안정되었습니다.

복사 가능한 템플릿 4개

증거 기반 가설 생성:

버그를 디버깅하고 있습니다. 아래에 증거가 있습니다.- 예상 동작: {{예상}}- 관찰된 동작: {{관찰}}- 오류 메시지/스택 추적: {{trace}}- 트리거 입력: {{input}}- 환경/버전: {{version}}이 증상을 설명하는 가장 유사한 근본 원인 3개를 나열하세요. 각각에 대해 테스트하는 방법(가장 저렴한 검사)과 그것이 사실인 경우 수정하는 방법입니다. 증거가 불충분할 경우 어떤 추가 정보가 필요한지 알려주세요.

스택 추적 해석:

이 스택 추적을 읽으십시오. 오류가 아마도 루트에서 시작되는 줄과 체인의 연속인 줄을 구별하세요. 먼저 살펴볼 곳을 1~2곳 추천해주세요. 관련 코드:{{code}}추적:{{trace}}

최소 재현 빼기:

아래 코드에서는 오류가 발생합니다. 여전히 오류를 유발하지만 불필요한 것은 모두 삭제하는 가장 작은 인스턴스로 줄입니다. 제거한 모든 부분이 오류에 영향을 미치지 않는다고 가정하지 말고 "이 부분을 제거할 때 오류가 사라지면 이것이 이유입니다"라는 메모를 추가하세요.{{code}}

수정 후 검증 및 회귀 테스트:

근본 원인이 {{원인}}이라고 가정하고 다음과 같이 수정합니다. {{수정}}.1) 이 수정으로 증상이 실제로 수정됩니까, 부작용이 있습니까? 2) 향후 이 버그를 잡을 회귀 테스트를 작성합니다.

약한 프롬프트 / 강한 프롬프트

약함: "코드가 작동하지 않습니다. 왜죠?"

Strong: "노드 20 / Express. POST /orders는 항목이 본문에서 빈 문자열인 경우 500을 반환합니다. 400을 반환해야 합니다. 스택 추적: TypeError: 정의되지 않은 속성을 읽을 수 없습니다('0'으로 읽음). 첨부된 것은 전체 추적 및 관련 처리기입니다. 이 증상을 설명하는 가장 가능성 있는 3가지 원인과 각각을 테스트하는 방법을 알려주세요. [추적 + 코드]"

강력한 버전; 환경, 끝점, 트리거 입력, 정확한 오류 유형 및 예상 동작을 제공합니다. 모델은 더 이상 예측을 할 수 없고 분석을 할 수 있습니다.

단계

AI의 기여

당신의 통제

증거 수집

어떤 증거가 필요한지 상기시켜줍니다.

실제로 증거를 수집합니다.

가설 생성

가능한 이유 나열

상황에 따라 우선순위를 정함

가설 검정

테스트 방법을 권장합니다

직접 운영하고 관찰함

교정

패치 권장

근본 원인을 해결하는가? 사실이에요.

회귀

테스트를 작성합니다

테스트가 중단되었는지 확인합니다.

증상이 아닌 근본 원인 해결

대부분의 경우 AI는 증상을 신속하게 해결하는 패치를 제안합니다. 즉, try/catch를 추가하고, null 검사를 수행하고, 오류를 무시합니다. 이것은 때때로 사실이고 종종 위험합니다. 원래의 원인은 그대로 남아 있다가 다른 곳에서 다시 분출되기 때문입니다. 각 수정 작업을 수행할 때마다 스스로에게 물어보세요. "이렇게 하면 오류의 원인이 해결됩니까, 아니면 오류가 보이지 않게 되나요?" 근본 원인을 찾으면 일반적으로 수정 사항이 더 작고, 더 강력하며 영구적입니다.

주의: 예외(빈 catch)를 자동으로 삼키면 오류가 해결되지 않습니다. 그것은 단지 은폐하고 향후 진단을 불가능하게 만들 뿐입니다. AI가 그런 '해결책'을 제안한다면 근본 원인을 묻지 않고 받아들이지 마세요.

일반적인 실수

• 증거도 없이 질문을 합니다. 모호한 문장은 모델을 환각에 빠지게 만듭니다. 전체 오류, 추적 및 입력을 제공합니다.
• 첫 번째 가설을 고수합니다. AI의 첫 번째 제안은 가능성이 가장 높지 않을 수 있습니다. 가장 저렴하고 통제 가능한 가설부터 시작하세요.
• 증상을 패치하고 근본 원인이 누락되었습니다. 침묵 오류가 반환됩니다.
• 확인하지 않고 수정사항을 닫습니다. 실제 생산과 유사한 조건에서 오류가 실제로 사라지는지 확인하세요.
• 회귀 테스트를 작성하지 않습니다. 테스트가 추가되지 않으면 이후 버전에서도 동일한 오류가 자동으로 반환됩니다.

요약하면

디버깅에서 AI의 성능은 제공한 증거에 정비례합니다. 전체 오류 메시지, 스택 추적, 입력 트리거 및 예상 동작이 없으면 모델은 단지 추측만 할 뿐입니다. 증상을 명확하게 하고, 증거를 수집하고, 가설을 생성하고, 가장 저렴한 제어로 테스트하고, 근본 원인을 수정하고, 회귀 테스트를 확인하고, 회귀 테스트를 추가하는 체계적인 흐름을 통해 버그를 빠르고 영구적으로 닫습니다. AI는 가설 생성기입니다. 버그가 실제로 해결되었는지 결정하는 사람은 바로 당신입니다.

응용과제

최근에 발생한 실제 버그를 선택하십시오(또는 테스트 버그를 재현하십시오). "최소 재생산" 단계를 먼저 수행하십시오. 오류를 유발하는 가장 작은 코드와 입력을 제거합니다. 그런 다음 “증거 기반 가설 생성” 템플릿을 사용하여 AI로부터 3가지 가능한 원인과 테스트 방법을 얻으세요. 가장 저렴한 가설을 직접 테스트하고 근본 원인을 찾아 수정한 후 마지막으로 향후 이 버그를 잡아내고 테스트가 실제로 손상되었는지 확인하는 회귀 테스트를 작성합니다.

체크리스트

• [ ] AI로 옮기기 전에 재현 가능한 가장 작은 샘플로 오류를 줄입니다.
• [ ] 전체 오류 메시지, 스택 추적, 입력 및 예상 동작을 프롬프트에 추가하고 있습니다.
• [ ] 나는 하나의 가설에 얽매이지 않고 가장 저렴하게 제어할 수 있는 것부터 시작합니다.
• [ ] 증상을 패치한 것이 아니라 근본 원인을 해결했음을 확인합니다.
• [ ] 수정 사항이 실제로 버그를 수정하는 것으로 확인되었습니다.
• [ ] 해결된 각 버그에 대해 회귀 테스트를 추가합니다.