N잡러의 it템

Claude한테 버그 잡으라고 시킬 때, 코드 모르는 사람이 자주 빠지는 함정 5가지

코셔의 일상 2026. 5. 6. 11:11

코드 모르는 채로 Claude 데리고 앱 만들고 있다. 잘 굴러가는 날도 있지만, 가장 진을 빼는 건 버그 잡기다.

처음에는 "여기 안 돼요" 한 마디만 던지고 답답해했는데,

이제는 어느 정도 패턴이 보인다. 코드 모르는 사람이 디버깅 시킬 때 자주 빠지는 함정 다섯 가지를 적어둔다.

 

1. 에러 메시지를 통째로 안 주고 요약해서 던지기

가장 큰 함정이다. "앱이 안 켜져요"라거나 "빨간 글씨 떠요"라고 말하면, AI는 가능한 원인 50가지 중 하나를 찍어서 답한다.

그러면 같은 자리를 한 시간 동안 빙글빙글 돈다. 콘솔에 뜬 에러 메시지를 빨간 줄 한 줄도 빼지 말고 통째로 복사해서 붙여넣는다.

스택트레이스도 같이 붙인다. AI는 "빨간 글씨"를 못 보지만, 텍스트는 정확히 읽는다.

 

2. 재현 절차를 안 적어주기

버그가 어떤 조건에서 나는지 알려주지 않으면, AI가 추측만 한다. "앱 켜고 → 로그인 화면에서 → 카카오 버튼 누르면 → 흰 화면" 이런 식으로 한 줄 한 줄 적어준다.

재현이 100% 되는 절차인지, 가끔 되는 건지도 명시한다. 가끔 나는 버그는 따로 물어봐야 하는 영역이다.

처음부터 "이 절차로 100% 재현됨"이라고 적으면 AI가 곧장 원인을 좁힌다.

 

3. 한 번에 여러 버그 같이 던지기

"이거랑 저거랑 그것까지 다 안 돼요" 하고 다 적어버리면, AI가 한 줄짜리 수정으로 세 버그를 동시에 고치려다 새 버그를 만든다.

버그는 한 건씩 처리한다. 첫 번째 버그 잡고 → 빌드 한번 돌려서 → 멀쩡한지 확인 → 그다음 버그로 넘어간다.

시간이 더 걸리는 것 같지만, 결과적으로 훨씬 빠르다.

 

4. 결과를 검증 안 하고 다음으로 넘어가기

AI가 "이렇게 고치면 됩니다" 하고 코드를 줘도, 그게 진짜 고쳐졌는지 확인 안 하고 다음 작업으로 넘어가는 게 함정이다.

며칠 뒤에 보면 그 버그가 그대로 있고, 그 위에 다른 코드가 더 쌓여서 더 어려워진다.

수정 받으면 즉시 빌드 돌리고, 같은 절차로 재현이 안 되는지 직접 눌러보고 확인한다.

"수정됐다고 하니 됐겠지" 하고 넘기는 순간 부채가 쌓인다.

 

5. 맥락 안 주고 코드 조각만 던지기

"이 함수 어디가 문제예요?" 하면서 함수 본문 10줄만 붙여넣으면, AI가 그 함수가 어디서 호출되는지, 어떤 데이터가 들어오는지 모른다. 가능하면 파일 전체를 주거나, 적어도 함수가 호출되는 부분과 입력 데이터 예시까지 같이 준다.

토큰이 좀 많이 들어도 한 번에 정답에 가까워지는 게 결과적으로 절약이다.

Claude의 긴 컨텍스트는 이럴 때 쓰라고 있는 거다.

 

+α. 추측을 사실처럼 단정하지 말기

"이거 분명히 카카오 SDK 문제예요"라고 단정해서 던지면, AI는 그 가정 위에서 답을 맞춘다.

결국 진짜 원인은 다른 곳에 있는데, 두세 시간을 카카오 SDK만 뜯어보고 있게 된다.

 

단정 대신 "카카오 로그인 직후에 흰 화면이 뜬다, 원인은 잘 모르겠다"라고 사실만 적는다.

추측이 있으면 "의심되는 건 A인데 확실하진 않다"라고 명시한다. 그래야 AI가 더 넓게 후보를 살펴본다.

 

마무리 — 디버깅은 정보전이다

코드 못 짜는 사람이라도, 정보 정리는 누구나 할 수 있다. 에러 메시지 통째로, 재현 절차, 환경(OS/브라우저/버전), 시도해본 것까지 한 번에 정리해서 던지면, AI는 정말 깜짝 놀랄 정도로 정확히 짚어낸다.

 

디버깅이 안 풀리는 건 AI 능력 문제가 아니라 내가 정보를 부족하게 줘서인 경우가 대부분이었다. 다음 버그 만나면, 위 다섯 가지를 체크리스트처럼 점검하고 한 번에 깔끔히 던져보길 권한다.