[Antigravity #5] 버그 사냥꾼: AI와 함께하는 디버깅
Editor’s Note
“코딩의 90%는 디버깅이다”라는 말이 있죠.
하지만 빨간 에러 메시지를 볼 때마다 가슴이 철렁하시나요?
이제 Antigravity에게 그 공포를 넘겨주세요. “이거 왜 안 돼?”가 아니라 “이거 고쳐놔”가 되는 마법을 보여드립니다.
1. 에러를 대하는 우리의 자세
기존의 디버깅 방식:
- 에러 로그를 본다. (Stack Trace 읽기 싫음)
- 구글링 한다. (Stack Overflow 검색)
- 비슷한 답변을 찾아서 복사 붙여넣기 한다.
- 안 되면 1번부터 반복.
Antigravity 방식:
- “에이전트야, 에러 났어. 확인해.” 라고 요청한다.
- 에이전트가 터미널 로그와 관련 파일을 함께 확인한다.
- 수정 후 다시 실행해 같은 에러가 사라졌는지 검증한다.
여기서 핵심은 “고쳐줘” 한마디가 아니라 재현 -> 원인 추정 -> 수정 -> 재검증의 루프입니다. 좋은 디버깅 요청은 에이전트가 이 루프를 빠뜨리지 않게 만듭니다.
1
2
3
방금 실패한 명령을 기준으로 원인을 분석해줘.
수정 전에는 어떤 파일을 바꿀지 먼저 요약하고,
수정 후 같은 명령을 다시 실행해서 결과를 알려줘.
2. 실전: 런타임 에러 잡기
파이썬 코드를 돌리는데 IndexError: list index out of range가 떴다고 칩시다. 보통은 몇 번째 줄인지 찾아서 눈을 부릅뜨고 쳐다봐야 하죠.
Antigravity 매니저 뷰에 이렇게 말하세요.
1
"방금 터미널에 뜬 에러 수정하고 재실행해."
에이전트는 터미널의 에러 로그를 읽고 -> 해당 소스 코드를 찾아서 -> ‘index 체크하는 if문’을 추가합니다. 그리고 스스로 다시 실행(Rerun)해서 에러가 사라진 것까지 확인하고 보고합니다.
Agent: “리스트 길이가 0일 때 예외 처리가 없어서 수정했습니다. 이제 정상 작동합니다.”
이때 보고가 “정상 작동합니다”로만 끝나면 부족합니다. 실무에서는 무엇을 확인했는지가 중요합니다.
좋은 보고 예시:
1
2
3
4
- 원인: 빈 배열에서 마지막 요소를 읽으려 했습니다.
- 수정: 배열 길이가 0일 때 기본값을 반환하도록 처리했습니다.
- 검증: `python main.py` 재실행, 동일한 IndexError 없음.
- 남은 위험: 빈 배열 외의 잘못된 입력 타입은 아직 테스트하지 않았습니다.
이 정도로 남겨야 나중에 사람이 diff를 리뷰할 때 판단하기 쉽습니다.
3. 심화: 논리적 버그 (Logical Bug)
에러 메시지도 안 뜨는데 결과가 이상한 경우가 제일 골치 아프죠? (예: 계산 결과가 틀림) 이럴 땐 “의도(Intent)”를 설명해야 합니다.
1
2
"이 쇼핑몰 장바구니 총액 계산 함수 말이야,
할인 쿠폰이 10% 적용되어야 하는데 지금 10원만 깎이고 있어. 로직 확인해줘."
그러면 에이전트는 코드를 분석하더니 이렇게 대답할 겁니다.
Agent: “아, 코드 보니까
price * 0.1을 해야 하는데price - 10으로 되어 있네요. 수정할까요?”
여러분은 코드를 한 줄도 안 읽고 버그를 잡았습니다.
논리적 버그는 에러 메시지가 없기 때문에 “정답”을 알려주는 테스트가 중요합니다. 가능하면 기대값을 함께 주세요.
1
2
상품 가격이 10,000원이고 할인율이 10%이면 최종 금액은 9,000원이어야 해.
현재 결과가 9,990원으로 나오니 계산 로직과 테스트를 같이 확인해줘.
기대값이 있으면 에이전트가 단순히 코드를 그럴듯하게 고치는 대신, 실패하는 테스트나 예제 입력을 기준으로 수정할 수 있습니다.
4. Self-Correction (자가 치유)
Antigravity의 가장 무서운 점은 “실패를 통해 배운다”는 것입니다.
에이전트가 코드를 고쳤는데 또 에러가 날 수 있겠죠? 그러면 에이전트는 “어? 아까 수정 방법이 틀렸네. 다른 방법으로 시도해볼게요.”라며 스스로 방향을 틉니다. 마치 노련한 개발자가 여러 가지 가설을 검증하며 답을 찾아가는 과정과 똑같습니다.
다만 자가 수정 루프에도 한계가 있습니다. 에이전트가 같은 파일을 계속 바꾸면서 문제를 키울 수 있으므로, 반복 횟수와 중단 조건을 정해두면 안전합니다.
1
2
3
최대 3번까지만 수정-검증을 반복해.
3번 안에 해결하지 못하면 변경을 멈추고,
시도한 방법과 다음 조사 후보를 정리해줘.
이렇게 하면 무한 삽질을 막고, 사람이 개입해야 할 시점을 명확히 만들 수 있습니다.
5. 디버깅 요청 템플릿
바로 복사해서 쓸 수 있는 형태입니다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
다음 실패를 디버깅해줘.
목표:
- 원인을 설명하고 최소 수정으로 해결
제약:
- 관련 없는 리팩터링 금지
- 수정 전 변경 예정 파일 요약
- 수정 후 실패한 명령 재실행
보고:
- 원인
- 수정 내용
- 실행한 검증
- 남은 위험
이 템플릿을 쓰면 에이전트가 “그냥 고치는 사람”이 아니라, 리뷰 가능한 디버깅 파트너처럼 움직입니다.
6. 오늘의 요약
- 빨간 줄(Error)이 뜨면 당황하지 말고 에이전트를 부른다.
- 좋은 요청은 재현, 원인 추정, 수정, 재검증을 포함한다.
- 반복 수정에는 횟수 제한과 중단 조건을 두면 안전하다.
버그를 잡았으니 이제 튼튼한 코드를 만들어야겠죠? 다음 편 [Antigravity #6] 에서는 개발자가 놓치기 쉬운 테스트 케이스를 에이전트와 함께 설계하는 방법을 알아봅니다.