🎯 학습 목표
- 에러 메시지와 스택 트레이스를 효과적으로 공유하는 법을 배운다.
- Claude와 함께 원인을 추적하는 디버깅 절차를 익힌다.
- 반복 수정(수정 → 재현 → 확인) 사이클을 운영한다.
- 근본 원인을 고치는 것과 증상만 가리는 것의 차이를 이해한다.
📖 개념 설명
디버깅은 Vibe Coding이 가장 빛나는 영역 중 하나입니다. Claude는 에러 메시지와 스택 트레이스를 빠르게 해석하고, 관련 파일을 읽어 원인을 추정할 수 있습니다. 단, AI가 정확한 진단을 하려면 사람이 충분한 단서를 제공해야 합니다.
좋은 디버깅 요청은 (1) 무엇을 하려 했는지, (2) 어떤 결과를 기대했는지, (3) 실제로 어떤 에러가 났는지(전체 메시지), (4) 어떻게 재현하는지를 포함합니다. 특히 스택 트레이스는 잘라내지 말고 전체를 그대로 붙여넣는 것이 중요합니다. 에러의 첫 줄뿐 아니라 호출 경로 전체가 단서가 되기 때문입니다.
디버깅은 한 번에 끝나지 않을 수 있습니다. Claude가 가설을 세워 수정하면, 사람이 다시 실행해 결과를 확인하고, 그 결과를 다시 알려주는 반복 사이클을 돕습니다. 이때 “근본 원인을 고치자”는 원칙이 중요합니다. 단순히 에러를 try/catch로 숨기는 것은 문제를 미루는 것입니다.
스택 트레이스를 읽는 법을 알아 두면 협업이 훨씬 매끄러워집니다. 스택 트레이스는 에러가 발생한 시점에 어떤 함수들이 어떤 순서로 호출되고 있었는지를 보여주는 ‘호출 경로’입니다. 보통 맨 위가 에러가 직접 터진 위치이고, 아래로 내려갈수록 그 함수를 부른 상위 호출자입니다. Claude는 이 경로를 따라 거꾸로 추적해, 실제 문제의 출발점을 찾아냅니다. 그래서 트레이스의 일부만 잘라 주면 단서가 사라져 진단이 부정확해집니다.
또 하나 중요한 개념은 ‘재현 가능성’입니다. 가끔만 발생하는 버그는 가장 잡기 어렵습니다. 어떤 조건에서, 어떤 순서로 조작했을 때 에러가 나는지 정확히 기록해 전달하면, Claude가 그 조건을 직접 만들어 확인할 수 있습니다. “가끔 안 돼요”보다 “목록이 비어 있을 때 삭제 버튼을 누르면 매번 에러가 난다”가 훨씬 빠른 해결로 이어집니다.
디버깅을 반복하다 보면 같은 자리를 맴돌 때가 있습니다. 두세 번 시도해도 해결이 안 되면, 접근 자체를 바꿔야 한다는 신호입니다. 이럴 때는 “지금까지 시도한 것을 정리하고, 전혀 다른 가능성을 나열해줘”라고 요청해 사고의 방향을 틀어 주세요. 때로는 문제가 의심하던 곳이 아니라 전혀 다른 모듈에 있기도 합니다.
💻 실습
에러가 발생하면 PowerShell의 출력을 그대로 복사해 전달합니다.
# 예: Node 스크립트 실행 중 에러 발생
node app.js
# 출력된 에러 전체를 복사해 Claude에게 전달전체 스택 트레이스와 함께 맥락을 전달합니다.
> 사용자 목록을 불러오려고 node app.js 를 실행했더니 아래 에러가 났어.
> 기대 동작은 콘솔에 사용자 배열이 출력되는 거야.
>
> TypeError: Cannot read properties of undefined (reading 'map')
> at getUsers (C:devapiapp.js:14:25)
> at Object. (C:devapiapp.js:30:1)
>
> 원인을 찾아서 근본적으로 고쳐줘. 임시방편 말고.Claude의 수정 후 다시 실행해 결과를 확인하고 피드백합니다.
node app.js
# 결과가 여전히 이상하면 새 출력을 다시 전달
> 이제 에러는 사라졌는데 빈 배열만 나와. fetchUsers가 데이터를 못 받는 것 같아. 확인해줘.⚠️ Windows 환경 주의사항
- PowerShell에서 에러 색상이 입혀진 텍스트를 복사하면 보이지 않는 제어문자가 섞일 수 있습니다. 가능하면 일반 텍스트로 붙여넣으세요.
- 스택 트레이스의 경로가
C:dev...처럼 백슬래시인 것은 정상입니다. 그대로 전달하면 됩니다. - 출력이 길어 잘리면
node app.js > error.txt 2>&1로 파일에 저장한 뒤 Claude에게 그 파일을 읽게 하세요.
💡 팁
- “임시방편 말고 근본 원인을 고쳐줘”라고 명시하면 try/catch로 숨기는 수정을 줄일 수 있습니다.
- 재현 방법을 정확히 알려주면 Claude가 직접 실행해 확인할 수 있어 정확도가 올라갑니다.
- 같은 에러가 3번 이상 반복되면 접근을 바꿔 “다른 가능성도 나열해줘”라고 요청하세요.
- 고친 뒤에는 “이 버그가 다시 안 생기게 막을 방법이 있을까?”로 예방책도 물어보세요.
- 에러가 안 나는데 결과만 이상할 때는, 중간 값을 콘솔에 찍어 달라고 요청해 흐름을 눈으로 확인하세요.
- “이 코드가 정상일 때 어떤 출력이 나와야 하는지 먼저 말해줘”로 기대값을 명확히 하면 진단이 빨라집니다.
- 버그를 고친 뒤에는 같은 상황을 다시 만들어 재현되지 않는지 꼭 확인하세요. 사라진 듯 보여도 실제로는 숨은 경우가 있습니다.
- 여러 에러가 한꺼번에 쏟아질 때는 맨 처음(가장 위) 에러부터 해결하세요. 뒤따르는 에러는 첫 에러의 연쇄 반응인 경우가 많습니다.