이득:
- 오류 메시지, 스택 추적 및 최소 재현 인스턴스를 통해 AI에 버그를 효과적으로 설명하는 기능
- AI로 체계적인 디버깅 흐름을 실행하여 단계별로 가설을 세우고 범위를 좁혀 근본 원인을 찾아내는 능력
- AI가 제안한 수정 사항이 실제로 문제를 해결했는지 재현 및 회귀 테스트를 통해 검증하는 기능
디버깅은 프로그램이 예상과 다르게 동작하는 이유를 찾아 수정하는 작업으로, 대부분의 엔지니어의 시간을 많이 소모합니다. 좋은 디버깅은 추측 게임에 기반을 두는 것이 아니라 체계적으로 범위를 좁혀 나가는 것입니다. 즉, 증상을 명확히 하고, 가설을 세우고, 가설을 테스트하고, 근본 원인을 찾아냅니다. AI는 이 주기에서 매우 강력한 파트너입니다. 하지만 그에게 올바른 정보를 제공하는 경우에만 가능합니다. “코드가 작동하지 않습니다. 고쳐주세요”라고 말하면 AI가 추측하고 포괄적인 제안을 하게 됩니다. 전체 오류 메시지, 스택 추적 및 가장 작은 재현 샘플을 제공하면 함께 근본 원인을 찾을 수 있습니다.
이 단원에서는 AI에 대한 버그를 효과적으로 설명하고, 가설의 범위를 단계별로 좁히고, 회귀 테스트를 통해 제안된 수정 사항이 실제로 문제를 해결하는지 확인하는 방법을 살펴보겠습니다. 기억하세요: 버그를 "수정"하는 것과 "버그 증상을 억제하는 것"은 서로 다른 것입니다. 근본 원인을 찾지 못한 채 수정하면 오류가 다른 곳으로 이동됩니다.
개념: 스택 추적: 오류 발생 시 어떤 함수가 어떤 순서로 호출되었는지 보여주는 덤프입니다. 최소 재현: 오류를 유발하는 가장 간단하고 짧은 코드/입력입니다. 근본 원인: 증상이 아닌 문제의 실제 원인입니다. 회귀 테스트: 동일한 오류가 반복되지 않는지 확인하는 테스트입니다.
AI에게 버그 설명하기
AI가 근본 원인을 찾을 가능성은 제공하는 정보의 품질에 정비례합니다. 좋은 오류 설명에는 수행하려고 한 작업, 예상했던 작업, 발생한 내용, 정확한 오류 텍스트 및 스택 추적, 관련 코드, 환경(언어/버전/OS) 및 오류를 생성한 가장 작은 샘플이 포함됩니다.
- 증상을 명확히 하세요. "예상 X, 실현된 Y" 형식입니다.
- 전체 오류 텍스트와 스택 추적을 붙여넣습니다. 단축하지 말고 검열하되 구조를 깨뜨리지 마십시오.
- 가장 작은 재생산을 제공하십시오. 오류를 유발하는 최소 입력 및 코드입니다.
- 환경을 지정합니다. 언어 버전, 라이브러리 버전, 런타임 환경.
효과적인 오류 설명 프롬프트: "버그를 디버깅하고 있습니다. 정보:- 수행하려는 작업: [X]- 예상 동작: [Y]- 실제 동작: [Z]- 전체 오류 메시지 및 스택 추적: [붙여넣기]- 환경: [언어/버전, 라이브러리/버전]- 관련 최소 코드: [코드] 직접적인 수정을 제공하지 마십시오. 먼저 가능성이 가장 높은 근본 원인 3개를 확률 순으로 나열하고 각각에 대해 확인할 확인 사항을 알려주십시오."
가설을 통한 흐름 축소
체계적인 디버깅은 가능성을 하나씩 제거하는 기술입니다. AI를 사용하여 가설을 생성하고 각 가설을 테스트하기 위한 실험을 설계합니다. 그런 다음 실험을 실행하고 결과를 반환합니다. 이 주기는 "샷건 디버깅"이라고 불리는 무작위 변경 및 중지 습관보다 훨씬 빠릅니다.
이진 검색(이분할) 도우미 프롬프트: "이 오류는 어제는 없었는데 오늘 있습니다. 지난 20개의 변경 사항 중 어느 것이 이분할로 인해 오류를 발생시켰는지 알고 싶습니다. 단계별 계획을 알려주세요. 테스트해야 할 지점은 어디인지, 결과에 따라 어느 절반으로 가야 하는지도 알려주세요. 또한 각 단계에서 확인할 사항을 정확히 알려주세요."
로그 삽입 전략 프롬프트: "이 함수의 중간 값을 볼 수 없기 때문에 오류를 찾을 수 없습니다. 어떤 변수를 인쇄하는 로그 줄을 어느 지점에 추가해야 하는지 알려주세요. 각 로그에 '이 로그에서 무엇을 배울 것인가' 설명을 추가하세요. 또한 기밀 데이터를 기록하지 못하게 하는 경고도 지정하세요."
팁: 오류를 해결할 수 없다면 대부분의 경우 잘못 가정한 부분에서 문제가 발생하는 것입니다. AI에게 “내 가정이 틀릴 수도 있나요?”라고 물어보세요. 묻는 것은 당신의 실명을 깨뜨릴 것입니다. 가장 어려운 실수는 "이것이 제대로 작동하고 있다고 확신합니다"라고 말하는 곳에 숨어 있습니다.
약한 프롬프트 / 강한 프롬프트
WEAK:"내 코드에서 오류가 발생했습니다. 수정합니다: [200줄의 코드]"(결과: AI는 오류가 무엇인지, 예상되는 내용이 무엇인지 모릅니다. 추측을 기반으로 일반적인 제안을 제공하지만 대부분은 쓸모가 없습니다.)STRONG:"NullPointerException이 발생합니다. 예상: 사용자 목록이 반환되어야 합니다. 실제: getUsers() 호출 시 폭발합니다. 스택 추적: [붙여넣기].환경: Java 17. 최소 반복: 다음과 같은 경우에 발생합니다. 사용자 목록이 비어 있지만 가득 차면 그렇지 않습니다. 관련 15줄: [코드]. 근본 원인과 빈 목록이 트리거되는 이유를 설명하고 수정 사항을 제안합니다."
강력한 프롬프트는 오류를 상황에 맞게 표시합니다. 어떤 경우에는 오류가 발생하고(빈 목록), 어떤 경우에는 발생하지 않습니다(전체 목록). 이 단서("비어 있을 때 발생")는 근본 원인을 거의 직접적으로 가리킵니다. 약한 프롬프트에서는 이 정보를 사용할 수 없기 때문에 AI는 맹목적인 추측을 합니다.
수정 사항 확인
수정 사항은 다음 세 가지 작업을 수행하는 경우에만 실제 수정 사항입니다.
제어
질문
확인 방법
오류가 사라졌나요?
이제 동일한 항목이 작동합니까?
최소 재현을 다시 실행하세요.
새로운 오류는 없나요?
또 깨진 건 없나요?
전체 테스트 스위트 실행
반복되지 않습니까?
같은 오류가 또 발생할까요?
이 시나리오에 대한 회귀 테스트 추가
근본 원인을 찾지 못한 채 교정을 하면 증상이 억제되는 경우가 많습니다. 예를 들어, "null인 경우 건너뛰기"로 null 오류를 얼버무리면 "왜 데이터가 null이 되는가?"라는 실제 이유가 됩니다. 보이지 않으며 다른 곳에서도 오류가 다시 발생합니다.
미니 케이스
사례 1 - 증상 억제 함정. 팀은 try-catch를 사용하여 간헐적으로 발생하는 null 오류를 침묵시킵니다. 오류는 사라지지만 2주 후에는 데이터가 누락된 것으로 나타납니다. 실제 이유는 서비스가 시간 초과 시 null을 반환하기 때문입니다. AI에게 "왜 null이 발생합니까?"라고 물으면 근본 원인이 드러납니다. 실제 수정은 1시간이 걸리지만 영구적입니다.
사례 2 - 최소한의 재현력. 개발자는 "가끔 충돌이 발생합니다"라는 버그를 수정할 수 없습니다. AI의 제안에 따라 오류를 가장 작은 입력으로 줄입니다. 문제는 터키어 문자가 포함된 파일 이름에서만 발생합니다(인코딩 오류). 300줄의 불확실성이 5줄의 확정 재현으로 줄어들면 해결책이 분명해집니다.
사례 3 - 회귀 방지 테스트. AI가 날짜 계산 오류를 수정합니다. 엔지니어는 이에 만족하지 않습니다. 잘못된 시나리오(월말, 1월 31일 + 1개월)에 대한 회귀 테스트를 추가합니다. 4개월 후 동일한 영역에 또 다른 변경 사항이 적용되면 테스트가 빨간색으로 바뀌고 버그가 프로덕션에 도달하기 전에 포착됩니다.
일반적인 실수
- "작동하지 않아요, 고치세요"라는 뜻이에요. 오류 텍스트, 예상 및 재현 없이 AI가 추측합니다.
- 스택 추적을 제공하지 않습니다. 스택 추적은 근본 원인을 직접적으로 나타내는 경우가 많습니다.
- 계속 무작위로 변경하세요. 가설을 세우지 않은 실험은 시간낭비입니다.
- 증상을 억제하고 근본 원인을 놓치는 것입니다. 오류는 다른 곳에서 다시 발생합니다.
- 회귀 테스트로 수정 사항을 확보하지 못했습니다. 앞으로도 같은 오류가 자동으로 다시 발생합니다.
요약하면
효과적인 디버깅은 추측이 아니라 체계적으로 범위를 좁히는 것입니다. AI에 전체 오류 텍스트, 스택 추적, 최소한의 재현 및 환경 정보를 제공하면 근본 원인을 찾을 가능성이 기하급수적으로 높아집니다. AI를 사용하여 가설을 생성하고 각 가설을 테스트하기 위한 실험을 설계합니다. 실험을 진행합니다. 버그가 사라졌고, 새로운 버그가 발생하지 않았으며, 회귀 테스트를 통해 보호되는 경우에만 수정 "완료"를 고려하세요.
응용과제
실제 오류나 인위적인 오류를 고려해보세요. 먼저 오류를 가장 작은 재현(입력이 발생하는 경우와 발생하지 않는 경우)으로 줄입니다. 효과적인 버그 레시피 프롬프트를 사용하여 AI에게 3가지 근본 원인 가설과 각각에 대한 검증 단계를 요청하세요. 가설을 하나씩 테스트하여 근본 원인을 찾고 수정한 다음 이 시나리오에 대한 회귀 테스트를 작성하고 실행하여 버그가 사라졌고 테스트가 보호를 제공한다는 것을 보여줍니다.
체크리스트
- [ ] 증상을 "예상 vs 실현"으로 명확히 했습니다.
- [ ] 전체 오류 텍스트와 스택 추적을 AI에 제공했습니다.
- [ ] 오차를 최소화하여 재현하였습니다.
- [ ] 가설을 하나씩 테스트해 보니 근본 원인을 찾았습니다.
- [ ] 증상을 억제하는 대신 근본 원인을 해결했습니다.
- [ ] 동일한 오류에 대해 회귀 테스트를 추가하고 실행했습니다.