AI로 만든 PR이나 버그 보고서를 받았을 때, 변경의 의미보다 사실 여부부터 확인해야 하는 경우가 있습니다. 생성한 사람이 아낀 시간이 받는 사람의 부담으로 넘어간 것입니다.
코딩도깨비 3편에서는 AI 슬롭을 이런 관점에서 살펴봤습니다. AI로 만든 코드라는 사실보다 생성 뒤에 남은 검증을 끝난 것처럼 넘겼는가가 중요한 질문입니다.
curl과 Godot이 보여준 검토의 병목
curl은 2026년 1월 버그 바운티 보상금 제도를 종료했습니다. 유지관리자 다니엘 스텐버그는 AI 슬롭 보안 제보 증가를 이유 중 하나로 설명했습니다. 과거 15% 이상이던 보안 제보의 실제 취약점 확인 비율은 2025년 5% 아래로 떨어졌다고 했습니다.
이 숫자는 모든 AI 코드의 실패율이 아니며, 나머지 제보가 모두 AI로 만들어졌다는 뜻도 아닙니다. curl에 들어온 제보의 품질과 이를 확인하는 부담에 관한 이야기입니다.
취약점 주장은 재현하고 코드를 살펴봐야 합니다. 틀린 주장에도 설명이 필요할 수 있습니다. 그럴듯한 보고서를 만드는 일이 쉬워졌다고 유지관리자의 검토 시간까지 늘어나는 것은 아닙니다.
결과를 보내는 단계와 검토하는 단계의 속도가 다르면, 처리하지 못한 일이 받는 쪽에 쌓일 수 있습니다.
curl은 신고 자체를 막은 것이 아닙니다. 2026년 3월에는 HackerOne으로 신고 플랫폼을 되돌렸고 보상금은 재도입하지 않았습니다. 4월에는 제보량이 늘었지만 예전 AI 슬롭 제보가 더 이상 큰 문제가 아니라고 설명했습니다. 종료 당시 상황을 현재의 모든 AI 제보에 일반화하지 않아야 합니다.
Godot도 AI 기여 증가와 리뷰 부담을 이야기했습니다. 리뷰는 버그를 찾는 일뿐 아니라 새 기여자가 프로젝트를 이해하고 성장하도록 돕는 과정이기도 합니다. 사람이 피드백을 이해하지 않은 채 AI에게 수정만 시키면, 리뷰에 쓴 시간이 기여자의 학습으로 이어지기 어렵습니다.
버그 보고서에서는 관찰과 가설부터 나눕니다
아르민 로나허는 Pi 유지관리 과정에서 AI가 덧붙인 잘못된 원인 진단을 문제로 지적했습니다. 이런 보고서를 읽는 Pi 에이전트 역시 해당 진단을 따라 잘못된 방향으로 추론할 수 있다는 설명입니다.
가상의 예로 “기간을 바꿨지만 화면의 합계가 그대로다”는 관찰입니다. “캐시 무효화 오류다”는 확인 전까지 가설입니다. 추측을 금지하는 것보다 그 상태를 분명히 표시하는 것이 중요합니다.
현상은 조사할 출발점이고, 원인 추측은 검증할 후보입니다. 둘을 같은 수준의 사실로 전달하지 않습니다.
받는 사람에게 도움이 되는 보고서에는 다음 정보가 우선합니다.
- 실행한 환경과 재현 순서
- 기대한 동작과 실제 결과
- 정확한 오류 메시지와 로그
- 확인한 사실, 아직 확인하지 못한 조건
테스트 성공보다 의도한 동작의 근거가 필요합니다
사이먼 윌리슨은 작동 여부를 확인하지 않은 큰 코드 변경을 보내고 리뷰가 나머지를 해결해주기를 기대하는 방식을 비판했습니다. PR을 보내는 사람은 코드를 만드는 것과 함께 의도한 동작의 확인 근거를 남겨야 합니다.
린트·타입 체크와 자동 테스트는 먼저 걸러낼 수 있는 문제를 확인합니다. 하지만 어떤 사용 조건을 검사했는지는 따로 설명해야 합니다. 테스트가 통과했다는 문장만으로 바뀐 기능을 확인했다고 볼 수는 없습니다.
예를 들어 날짜 선택과 합계 표시를 바꿨다면, 계산 함수 검사뿐 아니라 실제 화면에서 날짜를 바꿨을 때 합계가 갱신되는지도 살펴봐야 합니다. 다음은 이를 전달하는 형식의 예시입니다. 실제 프로젝트에서 실행한 결과가 아닙니다.
- 상황: 화면에서 9월 합계가 942,000원으로 표시됨
- 실행: 기간을 10월로 변경
- 결과: 합계가 1,284,000원으로 갱신되는지 확인
- 재현 자료: 실행한 확인 스크립트가 있다면 함께 첨부
- 미확인 범위: 검사하지 못한 환경과 예외 조건을 구분해 기록
이런 기록이 있으면 리뷰어는 제출자가 무엇을 확인했는지 알고, 같은 방법으로 다시 확인할 수 있습니다. 자동 검사 기록과 사람이 실제 동작을 확인한 기록도 구분해야 합니다.
설명할 수 있는 결과를 제출합니다
Ghostty는 AI 사용을 허용하지만 외부 기여자가 변경을 이해하고 AI 도움 없이 무엇을 바꿨고 왜 바꿨는지 설명할 수 있어야 한다는 기준을 둡니다. Godot과 AI 허용 범위는 다르지만, 결과를 제출할 때 사람의 이해와 책임이 남는다는 점을 함께 보여줍니다.
소피 알퍼트가 다룬 AI 글쓰기 문제도 연결됩니다. 문서 내용은 저자의 생각을 대표해야 합니다. 동료가 문장의 뜻을 물었을 때 “AI가 쓴 문장이라 모르겠다”는 답변은 설명의 일을 받는 사람에게 넘깁니다.
AI를 쓰지 말자는 결론은 아닙니다. 전달 전에 세 질문을 남겨두자는 것입니다.
- 내가 이 내용을 설명할 수 있는가?
- 실제로 확인한 근거가 있는가?
- 상대가 질문했을 때 답하고 고칠 수 있는가?
모든 버그가 없음을 증명할 수는 없습니다. 대신 알고 있는 것과 확인하지 못한 것을 구분하면 됩니다. AI가 만든 양만큼이나 받는 사람이 확인해야 할 양을 함께 보는 것이 필요합니다.
영상과 원문 출처
코딩도깨비 3편 — AI로 일 줄였는데 왜 더 바빠졌지?
- Chicago Sun-Times 공식 입장: 영상에서 다룬 가짜 추천 도서 사례
- curl 보상금 종료
- curl 신고 플랫폼 변경, 후속 제보 상황
- Godot 기여 정책
- Armin Ronacher — Pi 유지관리
- Sophie Alpert — 자연어 글쓰기
- Simon Willison — 작동을 확인한 코드
- Ghostty AI 정책
사건·발언은 원문을 요약하고 해석했습니다. 앱의 동작·금액 예시는 가상의 확인 시나리오입니다. 그림은 AI로 새로 생성한 설명 이미지입니다.
