오늘 AI 코딩 에이전트가 내 코드를 "수정"했다. 상황은 더 악화되었다.

저는 학교 관리 시스템인 EduTrack을 구축하고 있으며, Gemini CLI에게 제 Django views의 오류를 확인하고 보고해달라고 요청했습니다.

그것은 아무것도 보고하지 않았습니다. 대신 파일을 새로 작성했습니다.

발생한 상황은 다음과 같습니다: 저에게는 academics와 students라는 두 개의 Django 앱이 있습니다. 에이전트는 일부 학생 관련 views가 academics 대신 students에 속해야 한다고 판단했습니다. 솔직히 나쁜 직관은 아니었습니다. 하지만 그 관찰 내용을 묻거나 보고하는 대신, 에이전트는 서로 다른 구현 방식을 가진 함수들을 두 앱 모두에 중복해서 만들어 버렸습니다.

결국 저는 두 가지 버전의 edit_student를 갖게 되었습니다. 하나는 redirect를 반환하는 academics/views.py에 있었고, 다른 하나는 JsonResponse를 반환하는 students/views.py에 있었습니다. delete_student도 마찬가지였습니다. 어떤 views에는 @login_required가 있었고, 어떤 것들은 조용히 없었습니다. 아무것도 충돌(crash)하지 않았습니다. 바로 그 점이 위험했습니다. 조용히 망가진 코드는 명백한 오류를 던지는 코드보다 더 나쁩니다. 왜냐하면 그대로 배포(ship)되기 때문입니다.

진정한 교훈:
"오류를 확인하고 보고하라"와 "오류를 수정하라"는 근본적으로 다른 지시사항입니다. 명시적으로 읽기 전용(read-only)이라고 말하지 않으면, 에이전트는 기본적으로 행동할 권한이 있다고 가정할 것입니다. 그리고 일단 행동을 시작하면, 수정 범위는 원래의 버그를 훨씬 넘어 에이전트가 "관련이 있다"고 판단하는 모든 것에 손을 대는 경향이 있습니다.

만약 AI 에이전트에게 업무를 위임한다면:

• 명확하게 지시하세요: "이슈를 나열하되 아무것도 수정하지 마세요" vs "이 특정 함수를 수정하세요"
• 결과를 신뢰하기 전에 diff를 검토하세요. 특히 여러 파일에 걸쳐 있을 때는 더욱 그렇습니다.
• 광범위한 지시사항("오류를 확인해줘", "이걸 정리해줘")을 에이전트가 당신이 승인하지 않은 아키텍처 결정을 내릴 수 있는 초대장으로 간주하세요.

저는 다음 한 시간 동안 새로운 코드를 작성하는 것보다 더 가치 있는 일을 하며 시간을 보냈습니다. 모든 변경 사항을 읽고, 어떤 앱이 실제로 어떤 views를 소유해야 하는지 결정하며, 단순한 패턴 매칭이 아닌 실제 아키텍처 의도가 필요한 부분들을 재구축했습니다.

AI 에이전트는 강력한 협업 도구입니다. 하지만 범위(scope)가 없는 권한은 결국 당신이 디버거를 디버깅하게 만드는 결과를 초래합니다.

#ai #django #python #softwareengineering #buildinpublic #webdev