팀의 AI 코드를 감사했습니다. 그 결과는 다음과 같습니다.
저희 팀은 AI를 사용하여 기록적인 속도로 코드를 작성했습니다. 기능 배포 시간을 3분의 1로 단축했습니다. 개발 속도는 훌륭해 보였고, 테스트 커버리지는 91%에 달했습니다.
하지만 곧 한계에 부딪혔습니다.
해결하기 어려운 프로덕션 버그들이 발생했습니다. 간단한 리팩토링에 4일이 아닌 4주가 걸렸습니다. 새로 합류한 팀원은 코드가 깔끔하긴 하지만 이해하는 것이 불가능하다고 말했습니다.
저희는 3주 동안 코드베이스를 감사했습니다. 그 결과 어떤 스캐너로도 잡아낼 수 없는 기술 부채를 발견했습니다. 그 부채는 아키텍처적인 문제였고, 동작(behavioral)적인 문제였습니다.
AI 도구는 프롬프트에 담긴 즉각적인 문제를 해결합니다. 로컬 작업에 최적화되어 있습니다. 전체 시스템을 이해하지 못합니다. 곧 삭제할 예정인 서비스가 무엇인지 알지 못합니다. 장기적인 데이터 모델에 대해서도 알지 못합니다.
그 결과, 국소적으로는 정확하지만 전체적으로는 취약한 코드가 만들어집니다.
저희는 네 가지 구체적인 패턴을 발견했습니다:
- 숨겨진 엣지 케이스 (Hidden Edge Cases) AI는 사용자가 제공한 테스트를 통과하는 코드를 작성합니다. 자신의 실수에 대한 테스트를 작성하는 데는 서툽니다.
- 해결책: 엔지니어는 코드를 보지 않고 동료에게 코드를 설명할 수 있어야 합니다. 설명할 수 없다면 머지(merge)할 수 없습니다.
- 보여주기식 테스트 커버리지 (Test Coverage Theater) AI는 존재하는 코드를 커버하는 테스트를 생성합니다. 시스템이 실제로 어떻게 동작해야 하는지에 대한 테스트는 작성하지 않습니다.
- 해결책: 모든 AI 테스트 스위트는 적대적 검토(adversarial review)를 통과해야 합니다. 두 번째 엔지니어가 코드를 망가뜨리려고 시도해야 합니다.
- 보이지 않는 결합 (Invisible Coupling) AI는 프롬프트를 빠르게 해결하기 위해 의존성을 추가합니다. 알림 로직을 결제나 사용자 모듈에 엮어버릴 수도 있습니다. 이렇게 되면 나중에 서비스를 분리하는 것이 불가능해집니다.
- 해결책: AI가 도입한 모든 새로운 의존성은 시니어 엔지니어의 승인을 받아야 합니다.
- 얕은 에러 핸들링 (Shallow Error Handling) AI는 종종 완벽해 보이지만 실제 시스템 장애를 처리하지 못하는 에러 블록을 작성합니다.
- 해결책: 저희는 변경 테스트(change test)를 사용합니다. 작은 변경 하나를 했을 때 얼마나 많은 파일이 깨지는지 측정합니다. 영향도가 높다는 것은 결합도가 높다는 것을 의미합니다.
AI는 적이 아닙니다. AI를 주니어 엔지니어처럼 대해야 합니다. 가이드를 제공하고, 기대치를 설정하며, 판단력을 발휘하여 AI의 결과물을 바로잡아야 합니다.
도구는 작업(tasks)에는 뛰어나지만, 직무(job)에는 뛰어나지 않습니다.
Optional learning community: https://t.me/GyaanSetuAi