AI가 프로그래밍을 더 어렵게 만들고 있나요? 왜 'Test Only, Zero Code Review'가 절대적인 재앙인가?
I’m happy to translate the article for you, but I’ll need the full text you’d like translated. Could you please paste the content (or the portion you want translated) here? I’ll keep the source line exactly as you provided it and preserve all formatting, markdown, and code blocks.
Introduction
최근 **“AI Fatigue is Real”**이라는 제목의 기사에서 많은 개발자들이 현재 느끼고 있는 감정을 정확히 대변했습니다: AI 시대의 프로그래밍이 실제로 더 피곤해졌다는 것입니다.
우리는 **Creators (Builders)**에서 Reviewers로 전환되었습니다. AI가 코드를 너무 빠르고 일관성 없이 생성하기 때문에 리뷰 부담이 압도적으로 커졌습니다:
- 흐름 상태에 들어가는 것이 불가능합니다.
- 끊임없이 컨텍스트를 전환해야 합니다.
- 이 고밀도 마이크로 리뷰는 엄청나게 소모적이며 빠르게 결정 피로를 유발합니다.
커뮤니티에서의 관찰
다양한 커뮤니티에서 제 오픈소스 프로젝트인 **fastfilelink CLI (ffl)**를 홍보하면서, 저는 뒤에서 지켜보며 주류 개발자 토론을 관찰해 왔습니다. 제가 본 것은 끝없는 불안, 무한한 과대광고, 그리고 “AI가 개발자를 대체할 것이다”라는 방법론이 넘쳐나는 것이었으며, 그와 함께 형편없이 작성된 코드가 대량으로 쏟아졌습니다.
그 중 일부는 일리가 있지만, 솔직히 말해서 대부분은 완전한 헛소리입니다.
“테스트‑전용, 코드 리뷰 제로” 제안
커뮤니티(특히 현재 OpenClaw‑지배 파벌에 의해)에서 새로운, 달콤하게 들리는 제안이 등장했습니다:
“코드를 리뷰하지 말고, 출력 / 통과된 테스트만 리뷰하라.”
일부 사람들은 컴파일러를 비유로 사용하면서, 오늘날 우리는 컴파일러가 만든 어셈블리 코드를 리뷰하지 않는다고 주장합니다. 저는 이 주장이 근본적으로 잘못됐다고 생각합니다.
비유가 깨지는 이유
- 컴파일러는 결정론적 번역을 위해 엄격한 구문을 사용합니다.
- LLM은 확률적 모델입니다. LLM에게 테스트 케이스 생성을 요청하면, 그 테스트 자체가 가짜이거나 품질이 매우 나쁠 수 있습니다.
- 모든 테스트가 초록색이라고 해서 시스템이 정상이라는 뜻은 아닙니다. 결국 이 테스트 케이스들을 검토해야 하므로, “전혀 리뷰하지 않는다”는 전제는 신뢰할 수 없습니다.
현재 LLM의 한계
- Context windows and RAG capabilities는 제한적이며, LLM은 프로젝트의 일부분만 볼 수 있어 시스템 전체를 이해하지 못합니다.
- 생성된 코드는 종종 과도한 중복을 포함하여 DRY (Don’t Repeat Yourself) 원칙을 위반합니다.
- 요구사항이 변경될 때, 코드는 대규모이며 일관성 없는 버그가 발생하기 쉽습니다.
아키텍처 붕괴는 곧 해결되지 않음
- 학습 데이터와 어텐션 메커니즘의 물리적 한계 때문에 컨텍스트 윈도우는 항상 상한을 가집니다.
- 프로젝트는 계속해서 규모가 커져 컨텍스트 크기의 증가를 앞질러 나갑니다.
- 따라서 앞서 언급한 아키텍처 붕괴는 가까운 미래에 실질적으로 해결될 수 없습니다.
테스트 커버리지는 만병통치약이 아니다
이상하고, 패치되지 않았으며, 일관성 없는 엣지 케이스 버그를 방지하려면, 여러분의 테스트 커버리지는 100 %에 가깝게 유지해야 하며, 테스트는 극도의 엄격함으로 설계되어야 합니다. 이는 앞서 언급한 점으로 돌아갑니다: 테스트 케이스 자체가 코드이며, LLM에 의해 많이 복사‑붙여넣기됩니다.
프로덕션 코드를 검토하는 수고를 절약하고 싶다면, 방대한 테스트 코드 더미를 검토하는 데 동등한(또는 그보다 더 많은) 노력을 들여야 합니다. 결국 한 지옥을 다른 지옥으로 바꾸는 것에 불과합니다.
“테스트 통과만 신경 쓰기”가 결함이 있는 이유
- 근본적인 결함: 코드를 무시하고 테스트 결과만 신경 쓰는 것은 AI 과대광고다. 멋져 보이지만 실제로는 문제투성이이다.
- “작동한다”는 주장: 충분한 시간과 토큰을 투자하면 LLM이 결국 테스트를 통과하더라도, 프로젝트는 반복적인 로직으로 가득 차게 되고 이를 고치기 위해 점점 더 많은 자원이 필요하게 된다.
핵심 포인트
- 리뷰를 하지 않는 것은 불가능 – 리뷰 대상이 생산 코드에서 테스트 케이스로 옮겨졌을 뿐이다. 그것도 여전히 코드이며, 여전히 뇌력을 소모한다.
- 유지보수 비용이 기하급수적으로 증가 – 기술 부채가 쌓이면 사소한 버그를 고치는 데에도 점점 더 많은 토큰과 시간이 필요하게 된다.
- 경제적 인센티브 – 궁극적인 수혜자는 AI 개발 도구 공급업체이다. 코드가 비대해지고 디버깅이 많이 필요할수록 그들은 더 많은 수익을 얻는다.
결론
가장 오래된 소프트웨어‑엔지니어링 격언은 여전히 유효합니다:
“은탄환은 없다.”
AI‑생성 테스트에만 의존하고 코드 리뷰를 무시하는 것은 은탄환이 아니며; 단지 한 세트의 문제를 다른 문제로 바꾸는 것에 불과합니다.