내 AI 코딩 에이전트가 계속 고장 났던 이유 — 내가 바꾼 것들
6주 전, 내 AI 코딩 에이전트는 쓰레기 같은 결과물만 내놓았다.
컴파일은 되지만 아무 일도 하지 않는 함수를 작성했다. 잘못된 이유로 테스트를 통과했다. 버그 하나를 고치면 세 개의 새로운 버그를 만들어냈다.
나는 에이전트가 문제라고 생각했다. 틀렸다. 문제는 나의 규율(discipline) 부족이었다.
나는 엔지니어링 업무의 40%를 AI 에이전트에게 맡긴다. 리팩터링, 테스트 생성, 버그 조사를 처리한다. 내 코드베이스가 엉망이었을 때, AI는 그 난장판을 3배 더 악화시켰다.
AI는 규율을 대체하지 않는다. AI는 당신이 이미 가지고 있는 것을 증폭시킬 뿐이다.
결과물을 개선하기 위해 내가 워크플로우를 바꾼 방법은 다음과 같다:
테스트는 상태(state)가 아닌 동작(behavior)을 검증해야 한다. "assert user is not None"과 같은 테스트는 작성하지 마라. 그것은 거짓이다. 테스트는 "assert user.email == expected_email"처럼 구체적인 데이터를 확인해야 한다. 테스트가 부실하면 AI는 그 허점을 파고들 것이다.
모든 diff를 하나하나 읽어라. 예전에는 코드를 보지도 않고 리팩터링을 수락하곤 했다. 이는 순환 의존성(circular dependencies)과 지저분한 아키텍처로 이어졌다. 왜 이 변경 사항이 더 나은지 설명할 수 없다면, 거절하라.
상태를 명시적으로 만들어라. AI가 캐시나 세션을 어떻게 처리할지 스스로 "알아내게" 두지 마라. 프롬프트나 스키마에 이를 정의하라. 추론된 상태(inferred state)는 운영 환경을 망가뜨리는 조용한 버그를 유발한다.
에이전트의 변경 사항에 대해 직접 테스트를 작성하라. 에이전트가 코드를 변경할 때마다, 나는 먼저 사람이 작성한 테스트를 만든다. 15분이 더 걸리지만, 몇 시간의 디버깅 시간을 아껴준다.
확실한 실패(loud failures)를 요구하라. 변경 사항이 테스트는 통과하지만 로직을 깨뜨린다면, 시스템이 이를 반드시 감지해야 한다. "테스트 통과했으니 배포하자"를 유효한 지표로 받아들이지 마라.
결과:
- 주당 버그 발생 건수가 5건에서 1건 미만으로 감소했다.
- 주당 디버깅 시간이 6시간에서 1시간으로 감소했다.
에이전트는 변하지 않았다. 내가 변했다.
AI 에이전트를 사용한다면, 먼저 코드베이스부터 바로잡아라. 테스트를 개선하고, 상태를 명확히 하며, 리뷰를 강화하라.
에이전트는 거울이다. 증폭할 가치가 있는 무언가를 갖추고 있는지 확인하라.
출처: https://dev.to/susiloharjo/my-ai-coding-agent-kept-breaking-what-i-changed-4l5f
선택 사항 학습 커뮤니티: https://t.me/GyaanSetuAi