사람이 유지보수할 것처럼 코드를 작성하라

• LLM이 코드를 계속 대신 써주더라도, 중복 조건문과 임시 구현을 그대로 병합하면 이후 생성 코드가 그 관행을 프로젝트 규칙처럼 따라갈 수 있음
• 접근 권한 확인 로직을 route handler, background job, API endpoint, webhook 등에 반복해 넣으면 테스트는 통과해도 유지보수 부담은 그대로 남음
• 모델은 열린 파일, 기존 패턴, 최근 변경사항을 보고 다음 코드를 만들기 때문에, 복사된 조건문 4개는 다섯 번째 복사본을 부르는 신호가 됨
• 나중에 리팩터링을 요청해도 LLM이 기존 복사본을 모두 제대로 정리한다고 보장하기 어렵고, 나쁜 패턴은 일회성 실수보다 코드베이스의 스타일에 가까워짐
• 중복 조건문, “god” 함수, “나중에 정리” 병합이 쌓이면 프롬프트만으로 되돌리기 어려워지고 결국 사람이 직접 고쳐야 함

LLM이 참고하는 것은 현재 코드베이스임

• LLM은 코드를 “진공 상태”에서 작성하지 않고, 사용자의 코드베이스를 읽음
  • 열린 파일
  • 이미 존재하는 패턴
  • 최근 변경사항
• 코드베이스에 병합된 지름길은 “여기서는 이렇게 한다”는 학습 신호가 됨
• 같은 접근 제어 조건이 여러 위치에 반복될 수 있음

• 이 조건문은 공유 헬퍼로 추출할 수 있지만, LLM이 만든 코드가 동작하고 테스트가 통과한다는 이유로 그대로 병합될 수 있음
• 같은 규칙을 가진 다섯 번째 엔드포인트를 요청하면, 모델은 처음부터 설계하기보다 저장소 안의 기존 복사본들을 따라갈 가능성이 커짐

유지보수를 LLM에 맡긴다는 착각

• “나중에 바꿀 때도 LLM이 해줄 것”이라는 생각은 중복과 코드 냄새를 방치하게 만듦
• 몇 개의 중복 조건문은 치명적이지 않을 수 있지만, 이런 코드 냄새는 계속 쌓임
  • 중복 조건문
  • “god” 함수
  • “나중에 정리”하기로 한 병합
• 나쁜 패턴이 늘어나면 다음 프롬프트의 결과에도 영향을 주고, 나중에 모든 인스턴스를 LLM이 빠짐없이 고칠 것이라고 믿기 어려워짐
• 유지보수를 LLM에 아웃소싱한다고 생각해도, 실제로는 점점 나빠지는 습관을 반복하도록 만드는 상황이 될 수 있음
• 사람이 유지보수할 것처럼 코드를 작성해야 하며, LLM이 흡수해 되돌려줄 코드 패턴은 좋은 상태로 유지해야 함