100% AI 코딩 의무화 1년 후, 아무도 코드를 이해하지 못한다
한 바이럴 레딧 게시글이 AI 생성 코드를 의무화한 팀이 이제 자체 코드베이스를 설명하지 못한다고 주장한다. LLM API로 개발하는 개발자들이 얻어야 할 교훈.
게시글이 실제로 주장하는 것
제목은 직설적이다. 100% AI 의무화 1년 후, 아무도 코드를 이해하지 못한다는 것이다. 레딧 스레드에서 보도되고 Hacker News에서 확산된 주장에 따르면, 한 팀이 AI 생성 코드를 기본으로 밀어붙였고 이제 이해와 유지보수 측면에서 그 대가를 치르고 있다.
여기서는 신중할 필요가 있다. 이는 통제된 연구가 아닌 온라인 포럼의 단일 일화다. 코드베이스의 규모, 리뷰 프로세스, 팀의 연차 구성도 알 수 없다. 이를 보편적 결과의 증거가 아니라 그럴듯한 실패 모드에 대한 신호로 받아들여야 한다.
이해 부채가 누적되는 이유
팀 내 누구도 설명할 수 없는 코드는 누가 또는 무엇이 작성했든 부채다. 아무도 논리적으로 검토하지 않은 모듈에서 버그가 발생하면 디버깅 속도가 급격히 느려지고, 모든 변경에 추가 위험이 따른다. 이것이 이 스레드가 제기하는 핵심 우려다.
AI 생성은 리뷰가 약할 경우 이를 가속할 수 있다. 테스트가 통과한다는 이유로 출력이 병합되고, 테스트 역시 생성된 것이라면 팀은 동작에 대한 독립적 이해를 거의 갖지 못할 수 있다. 이 부채는 프로덕션에서 무언가 깨지기 전까지 보이지 않는다.
LLM API로 개발하는 팀에게 의미하는 것
LLM API 위에 제품을 출시한다면 동일한 역학이 자체 통합 코드에도 적용된다. 프롬프트 템플릿, 재시도 로직, 스키마 검증, 폴백 경로가 그렇다. 바로 이 영역에서 생성된 코드가 올바르게 보이면서도 예상 밖으로 동작할 수 있다.
실용적인 패턴은 최소한 한 명의 엔지니어가 각 핵심 모듈을 한 줄씩 읽지 않고도 설명할 수 있도록 요구하고, 가장 중요한 경로에 대해서는 사람이 작성하거나 리뷰한 테스트를 유지하는 것이다. 작은 diff, 명시적 소유권, 문서화된 설계 의도 같은 벤더 중립적 습관은 공급자를 넘어 잘 통용된다.
모델 변경에도 살아남는 가드레일
모델 동작은 시간이 지나면서 변하므로, 프롬프트가 안정적으로 유지되리라 믿기보다 가정을 코드와 테스트에 고정하는 것이 더 안전하다. 구조화된 출력을 검증하고, 디버깅을 위해 원시 응답을 로깅하며, 모델 호출과 비즈니스 로직 사이에 명확한 경계를 유지해 공급자 교체가 재작성을 요구하지 않도록 하라.
이 중 어느 것도 AI 지원 개발에 반대하는 주장이 아니다. 이 스레드의 교훈은 생성 금지가 아니라 소유권과 리뷰 규율에 관한 것이다. 가장 큰 이점을 얻는 팀은 생성된 코드를 여전히 사람이 최종 작성자로서 책임져야 하는 초안으로 취급하는 경향이 있다.
