ChatGPT에 스택 트레이스(Stack Traces)를 그대로 붙여넣는 것을 멈추세요: 더 나은 AI 디버깅 워크플로우

여러분은 그 과정을 잘 알고 있을 것입니다. 테스트가 실패합니다. 에러 메시지를 복사해서 ChatGPT에 붙여넣고, 여러분의 코드베이스와 맞지 않는 일반적인 답변을 받으며 20분을 허비합니다. 그러다 결국 2분 만에 스스로 버그를 찾아냅니다.

디버깅을 위해 AI를 사용하는 더 나은 방법이 있습니다. AI를 사용해야만 할 것 같은 기분이 들지만 실제로는 도움이 되지 않는 기묘한 의존성을 만드는 대신, 실제로 시간을 절약할 수 있는 방법 말입니다.

무작위 프롬프팅(Random Prompting)의 문제점

대부분의 개발자들은 AI를 디버깅 자판기처럼 취급합니다. 에러를 집어넣고 해결책이 나오기를 바라는 것이죠. 그 결과는 무엇일까요? 다음과 같은 사항들을 무시한 일반적인 조언뿐입니다:

• 여러분의 특정 기술 스택 (tech stack)
• 코드가 실제로 흐르는 방식
• 실제 근본 원인 (보통 에러 메시지보다 3단계 더 깊은 곳에 있음)

ChatGPT는 독심술사가 아닙니다. ChatGPT에게는 _컨텍스트 (context)_가 필요합니다. 좋은 컨텍스트 말이죠.

실제 디버깅 워크플로우

무언가 고장 났을 때 제가 실제로 하는 방식은 다음과 같습니다:

1. 먼저 멈추고 에러를 읽으세요 (네, 정말입니다)

에러가 실제로 무엇을 말하고 있는지 살펴보는 데 60초를 투자하세요. 에러 메시지 자체가 아니라 _컨텍스트 (context)_를 보라는 뜻입니다. 어떤 함수가 실행 중이었나요? 최근에 무엇이 바뀌었나요?

대부분의 버그는 다음 다섯 가지 중 하나입니다:

• Off-by-one 에러
• 예상치 못한 Null/undefined 값
• 타입 불일치 (Type mismatch)
• 레이스 컨디션 (Race condition)/타이밍 문제
• 더 이상 유효하지 않은 가정

AI를 건드리기 전에 어떤 것인지 추측해 보세요.

2. 실패를 격리하세요

격리된 환경에서 재현하세요. 최소한의 테스트 케이스를 작성하세요. 이것은 AI를 위한 것이 아니라, 무엇이 실제로 실패하고 있는지 여러분이 이해하기 위한 것입니다.

// 나쁜 예: "왜 내 API가 작동하지 않죠?"
// 좋은 예: 실패하는 격리된 테스트
const testCase = () => {
...

범위가 작을수록 = 사고가 명확해지고 = 더 빠르게 수정할 수 있습니다.

3. AI를 해결사가 아닌 러버 덕 (Rubber Duck)으로 사용하세요

이것이 핵심적인 사고방식의 전환입니다. "이것을 고쳐줘"라고 말하는 대신, AI에게 소리 내어 다음과 같은 질문을 던지세요:

"result가 .name 속성을 가진 객체이기를 기대하고 있습니다. 그런데 대신 undefined가 나옵니다. 제 fetch 호출은 useEffect 안에 있고, DevTools에서 확인할 수 있기 때문에 데이터는 올바르게 로드됩니다. 하지만 첫 번째 렌더링(render) 시점에 접근하면 undefined가 됩니다. 제가 무엇을 놓치고 있는 걸까요?"

일반적인 에러가 아니라 _구체적인 시나리오(specific scenario)_로 구성하세요. 관련 있는 코드(fetch, 상태(state), 오류가 발생하는 지점)만 붙여넣으세요.

4. 일반적인 답변에 반박하기 (Push Back on Generic Answers)

만약 AI가 "에러 핸들링(error handling)을 추가해야 합니다"라고 말하는데 이미 구현되어 있다면, 그렇게 말하세요. 반박하세요. 더 구체적으로 만드세요:

"이미 에러 핸들링을 하고 있습니다. fetch는 성공하고, 데이터는 콘솔에 올바르게 찍히지만, 첫 번째 렌더링 시점에 접근하면 undefined를 반환합니다. 왜 데이터가 한 곳에서는 사용 가능하고 다른 곳에서는 그렇지 않은 걸까요?"

이렇게 하면 양측 모두 더 깊게 생각하게 됩니다. 종종 답변은 타이핑을 하는 동안 스스로 깨닫게 되는 내용일 것이며, 이것이 바로 이 방식의 핵심입니다.

5. 배포 전 로컬에서 검증하기

AI는 75%의 확률로 정답을 맞힙니다. 나머지 25%는 프로덕션(production) 환경에 배포되어 새벽 3시에 문제를 일으킬 것입니다. 제안된 수정 사항은 항상 실제 환경에서 먼저 테스트하세요.

실제 사례: 레이스 컨디션 (Race Condition)

지난주에 실제로 겪었던 버그입니다:

내가 본 현상: 폼(form) 제출이 첫 번째 시도가 아닌 두 번째 시도에서 작동함.

AI에게 물어본 방식: 일반적인 에러 + 스택 트레이스 (10분 낭비).

물어봤어야 했던 방식:

"사용자가 폼을 제출한 직후에 바로 resetForm()을 호출합니다. 폼은 초기화되지만, 사용자가 즉시(500ms 이내) 다시 제출하려고 하면 제출이 작동하지 않습니다. 함수가 호출된 직후에 바로 사용할 수 없게 되는 원인은 무엇일까요?"

정답: 제가 필요했던 참조(reference)를 null로 만들고 있었습니다. 명확하게 설명하고 나니 간단한 문제였습니다.

실제로 도움이 되는 도구들

진정한 AI의 도움을 받고 싶다면, 문맥(context) 안에서 사용하세요:

• IDE 내의 GitHub Copilot: 코드베이스를 파악하여 타겟팅된 제안을 제공합니다.
• Perplexity 또는 Claude: 특정 사항이 왜(why) 작동하는지에 대한 상세한 설명을 제공합니다.
• 자신만의 테스트 스위트 (test suite): 테스트를 실행하고, 실패하는 것을 관찰한 뒤, AI를 사용하여 귀하의 특정 코드에서 발생한 실패 원인을 설명하도록 하세요.

진정한 기술

AI의 유무와 상관없이 디버깅을 잘하는 능력은 다음과 관련이 있습니다:

1. 관찰하고 있는 내용에 대해 정확하게 기술하기
2. 도움을 요청하기 전에 가설을 세우기
3. 무엇이 잘못되었는지 알 수 있을 정도로 자신의 코드를 충분히 이해하기
4. 언제 기계를 믿고, 언제 자신의 직관을 믿어야 하는지 알기

AI는 사고를 대체하는 것이 아니라, 당신이 더 명확하게 생각할 수 있도록 도울 때 가장 효과적입니다.

다음번에는

다음에 무언가 고장 난다면:

• 즉시 붙여넣지 마세요.
• 60초 동안 에러를 가만히 살펴보세요.
• 스스로에게 질문을 소리 내어 던져보세요.
• 그다음에 충분한 문맥 (context)과 함께 AI에게 물어보세요.
• 배포하기 전에 검증하세요.

그러면 더 빠르게 디버깅하고, 더 많이 이해하며, AI의 도움을 덜 필요로 하는 자신을 발견하게 될 것입니다. 이것이 아마도 이 모든 과정의 궁극적인 목적일 것입니다.