🧑🏻💻 Ep.17 | A와 함께 버그를 잡는다는 것
그 주는 화요일 아침부터 꼬였습니다. 결제 서비스에서 간헐적으로
NullPointerException이 뜬다는 제보가 들어왔거든요. 에러 메시지를 통째로 복사해서 AI에게 던졌습니다. 1초 만에 답이 왔어요. "여기 null 체크가 빠졌네요. if문 하나 넣으면 됩니다." 넣었더니 에러가 사라졌습니다. 그런데 잠시 뒤, 같은 자리에서 이번엔 다른 증상으로 또 튀어나왔어요. 반창고만 붙였던 거죠. 돌아보면 그 화요일이, 한 주 내내 이어질 소동의 시작이었습니다.AI는 증상을 빠르게 가라앉힙니다. 다만 원인을 짚는 건 좀 다른 일입니다.
1. AI는 보이는 것에만 답한다.
AI에게 에러를 주면, AI는 그 에러 메시지 안에서만 답을 찾습니다.
NullPointerException이 떴다면 "null을 막으세요"라고 하죠. 틀린 말은 아닙니다.
문제는 진짜 질문이 따로 있다는 겁니다. 왜 그 값이 null이 됐는지, 어디서부터 null이 흘러 들어왔는지, 이 null이 가리키는 더 큰 문제는 없는지. 던져준 조각만 보는 AI는 여기까지 못 따라옵니다. 그 반창고 밑에서 곪고 있는 진짜 원인은 사람이 따라가야 합니다.2. 좋은 디버깅은 좋은 질문에서 시작한다
코드 리뷰가 그렇듯, 디버깅도 AI에게 무엇을 묻느냐가 결과를 가릅니다. "이 에러 고쳐줘"는 반창고를 부릅니다. 저는 요즘 이렇게 묻습니다.
"이 값이 null이 될 수 있는 경로를 전부 찾아줘. 가능성이 높은 순으로."
"이 함수에 들어오기 전에 이 값은 어디서 만들어져?", "이 증상이 나오는 다른 시나리오는 뭐가 있어?", "지금 가설은 A인데, 이 가설을 반증할 근거를 찾아줘" 같은 식이죠. AI를 답을 뱉는 기계가 아니라, 가설을 같이 세우는 동료로 두는 겁니다.
3. 맥락을 주는 만큼 답이 좋아진다
같은 버그라도, 에러 한 줄만 주는 것과 전체 흐름을 주는 건 답의 질이 하늘과 땅입니다. AI에게 줄수록 좋은 것들이 있어요.
✔️ 에러가 난 코드뿐 아니라, 그 값을 만든 상류 코드
✔️ 재현 조건 ("이 사용자만, 이 시간대에, 두 번째 요청부터")
✔️ 최근 변경 내역 ("3일 전에 이 부분을 바꿨다")
✔️ 이미 시도해본 것 ("캐시는 꺼봤는데 그대로다")
마지막 항목이 특히 중요합니다. 안 알려주면 AI는 당신이 이미 30분 동안 해본 걸 천연덕스럽게 다시 제안하거든요. 맥락이 없으면 일반론을 말하고, 맥락을 주면 우리 코드를 말합니다.
4. 재현이 절반이다
디버깅의 8할은 "어떻게 재현하느냐"라고 생각합니다. 재현만 되면 고치는 건 대체로 금방이에요. 여기서 AI가 의외로 큰 도움이 됩니다. 흩어진 단서를 모아 재현 시나리오를 가설로 세워주고, 그 시나리오를 검증할 최소 재현 코드를 빠르게 짜줍니다. 로그를 어디에 더 찍어야 단서가 나올지도 곧잘 짚어주고요.
"이 버그를 재현하는 가장 작은 테스트를 짜줘." 디버깅에서 가성비가 가장 좋은 요청 중 하나입니다.
재현이 되는 순간, 모호하던 버그가 손에 잡히는 문제로 바뀝니다.
5. AI의 답을 의심하는 습관
AI는 자신 있게 틀립니다. 디버깅에서는 이게 특히 위험해요. "이게 원인입니다"라고 단정하면, 우리는 그 방향으로만 파게 됩니다. 정작 원인은 옆에 있는데도요. 첫 가설에 생각이 묶이는 이 현상을 앵커링이라고 하죠. 앞의 그 결제 버그도, 사실 저는 AI 말만 믿고 엉뚱한 자리만 30분을 봤습니다. 그래서 한 가지를 더 시킵니다.
"이 가설 말고, 같은 증상을 만들 수 있는 다른 원인 세 개를 더 대줘."
가설을 하나가 아니라 여러 개 받아두고, 로그와 데이터로 하나씩 지워나가는 겁니다. 가설을 빠르게 늘리는 건 AI가 잘하고, 그중 진짜를 고르는 건 사람이 합니다.
6. 고친 뒤에 남겨야 하는 것
버그를 잡았습니다. 여기서 끝내면 절반만 한 거예요. 왜 이런 버그가 생겼는지, 어떻게 찾았는지, 같은 류를 막으려면 뭘 바꿔야 하는지. 이걸 커밋 메시지에, PR 설명에, 혹은 회귀 테스트로 남겨야 합니다. 다행히 이 정리는 AI가 잘 도와줍니다. 사람이 "무엇을 깨달았는지"를 말하면, AI가 그걸 구조화된 기록으로 만들어줍니다. 설계 문서를 쓸 때와 똑같은 분업이죠. 같은 버그를 두 번 잡는 것만큼 아까운 시간도 없으니까요.
7. 디버깅 감각은 여전히 사람의 것
AI는 단서를 빠르게 모으고, 가설을 넓게 펼치고, 재현 코드를 순식간에 짭니다. 그런데 "뭔가 이상한데" 하는 직감, 로그 한 줄에서 위화감을 느끼는 감각. 그건 장애를 직접 겪어본 사람한테서 나옵니다.
AI는 디버깅의 속도를 올려줍니다. 하지만 어디를 의심할지 정하는 건 운영해본 사람의 감각입니다. 그 감각은 AI가 대신 쌓아줄 수 없지만, AI 덕분에 더 빨리 쌓을 수는 있습니다.
새벽 3시 장애 콜에서 끝내 차이를 만드는 건, 여전히 그 감각입니다.
🌱 장애와 디버깅을 실전으로 나누는 곳, 루퍼스
교과서의 디버깅과 새벽 3시의 디버깅은 다릅니다. 루퍼스에서는 현업에서 부딪힌 장애와 트러블슈팅 경험을 서로 나누며, AI를 어떻게 동료로 쓸지 함께 고민합니다 🙌
AI 시대에도 결국 중요한 건 생각하는 힘과 성장하는 환경이라고 믿습니다.
루퍼스에는 성장에 진심인 800+명의 크루가 함께하고 있습니다. 현업에서 부딪히는 고민과 경험을 나누며 함께 성장하는 크루들의 이야기. 전액 기부 강의 그리고 다양한 오프라인 네트워킹까지! 루퍼스는 개발자를 위한 지속 가능한 성장을 만들어 갑니다.
📢 LOOPERS의 소식이 궁금하다면?
Share article