"AI한테 코딩 맡겼더니 4줄짜리가 천 줄 괴물 코드가 되는 이유"

요약 소프트웨어 설계에서 흔히 간과되지만 핵심적인 원칙 중 하나는 '필요하지 않은 요구사항을 쳐내는 것'입니다. 속도가 조금 느려도 되는 부분, 데이터가 즉시 갱신되지 않고 약간 오래되어도(stale) 무방한 부분, 유연성을 포기해도 되는 부분을 찾아내는 것이 오히려 시스템을 우아하고 단순하게 만드는 열쇠입니다. 실제로 뛰어난 시스템들은 일부 요구사항을 의도적으로 버려 강력함을 얻었습니다. 유니콘(Unicorn) 웹 서버는 인스턴스 간 가변 상태 공유를 포기해 완벽한 프로세스 격리를 얻었고, 느린 클라이언트 처리를 무시하여 유닉스 소켓 기반의 초단순 설계를 완성했습니다. AWS S3는 다중 키 원자적 업데이트 지원을 포기함으로써 파티션을 넘나드는 오버헤드 없이 블롭 단위의 압도적인 확장성과 속도를 확보했습니다. SQLite는 동시 쓰기를 포기해 '단일 파일 실행'이라는 극강의 운영 편의성을 얻었고, Cursor는 테일 레이턴시를 일부 감수함으로써 분산 깃 백엔드를 쉽게 확장했습니다. 이처럼 잘 설계된 시스템은 약점을 강점으로 전환합니다. 하지만 실무에서 요구사항을 덜어내는 일은 극도로 어렵습니다. 이는 기술적 판단과 비즈니스 판단이 동시에 필요하기 때문입니다. 특정 타협이 시스템에 미치는 영향을 기술적으로 파악해야 하고, 동시에 그 타협(예: 데이터 갱신 지연)을 사용자가 용납할 수 있는지 비즈니스적으로 결정해야 합니다. 대기업에서는 엔지니어와 기획자(PM) 간의 동기와 평가 기준이 다르고 상호 검증이 어려워 불신이 생기기 쉽고, 결국 아무도 타협하지 않으려는 '요구사항 과열' 상태에 빠집니다. 반면 1인 개발자나 스타트업은 한 사람이 기술과 비즈니스를 모두 쥐고 있어 과감한 타협을 내릴 수 있습니다. 최근 이 문제는 코딩 AI(LLM)와 협업할 때 더욱 두드러집니다. AI 모델들은 강화학습(RLVR) 과정을 거치며 채점자를 만족시키려는 성향이 극대화되어 있습니다. 반면 실제 비즈니스 맥락은 거의 알지 못합니다. 이 때문에 AI는 필요하지도 않은 극단적인 엣지 케이스나 일관성 가설을 세우고, 코드 곳곳에 불필요한 뮤텍스(락)나 상태 검증 로직을 마구잡이로 집어넣습니다. '요청 처리 도중 관리자 권한이 박탈되면 어쩌지?' 같은 가상의 문제를 해결하려다 4줄짜리 수정을 수천 줄짜리 괴물 코드로 부풀려 놓는 것입니다. 결국 AI 코딩 시대에도 코드 리뷰는 필수적입니다. AI가 멋대로 추가한 과도한 요구사항이나 불필요한 락, 과도한 계층을 쳐내지 않으면 시스템은 점점 경직되어 확장 불가능한 상태로 굳어버리게 됩니다. 우아한 시스템을 지키려면 '우리가 만족시키지 않아도 되는 요구사항이 무엇인가'를 끊임없이 의심하고 덜어내는 결단력이 필요합니다.