LLM 시대에도 코드는 사람이 유지보수한다고 생각하고 짜야 함

• LLM이 하루 종일 코드를 써주는 시대가 되면서, 은근히 위험한 유혹이 하나 생김

  • '중복 좀 있어도 되지 않나? 나중에 AI한테 고치라고 하면 되잖아'라는 생각임
  • 글쓴이도 AI로 만든 프로젝트에서 같은 접근 권한 체크를 여러 위치에 조금씩 다르게 복붙하고 있었다고 함

• 예시는 되게 현실적임. 라우트 핸들러, 백그라운드 잡, API 엔드포인트, 웹훅마다 거의 같은 조건문이 들어감

  • 예를 들면 user.isActive, user.hasPermission('read'), !user.isSuspended, account.status === 'open' 같은 조건 4개가 반복되는 식임
  • 사람이 직접 짰다면 보통 canReadAccount() 같은 공유 헬퍼로 빼냈을 코드인데, AI가 그때그때 잘 돌아가는 코드를 만들어주니 그냥 머지하게 됐다는 얘기임

• 문제는 '테스트 통과했으니 됐다'에서 끝나지 않음. LLM은 진공 상태에서 코드를 쓰지 않음

  • 모델은 현재 코드베이스, 열려 있는 파일, 이미 존재하는 패턴, 최근 변경사항을 보고 다음 코드를 만듦
  • 그러니까 중복 조건문 4개를 머지해두면, 다음에 다섯 번째 엔드포인트를 만들 때 모델은 그걸 프로젝트의 정상 패턴으로 받아들일 가능성이 큼

• 더 찝찝한 포인트는 리팩터링을 시켜도 LLM이 꼭 다 고쳐준다는 보장이 없다는 것임

  • 이미 5군데에 비슷하지만 살짝 다른 조건문이 퍼져 있으면, 모델이 그걸 '의도된 차이'로 보고 보존할 수도 있음
  • 중복이 몇 개일 때는 별일 아닌데, 시간이 지나면 god function, 임시 코드, 복붙 로직이 전부 다음 프롬프트의 컨텍스트가 됨

• 이 글의 핵심은 'AI 써도 클린 코드 해야 함' 같은 뻔한 훈계가 아님

  • 코드베이스 자체가 LLM에게 가장 강한 프롬프트라는 얘기에 가까움
  • 좋은 설계와 일관된 패턴을 넣어두면 모델도 그쪽으로 따라오고, 대충 머지한 패턴이 쌓이면 모델도 그걸 따라 함

• 그래서 결론은 단순하지만 꽤 세게 남음. 코드는 여전히 사람이 유지보수한다고 생각하고 짜야 함

  • LLM은 내가 반복해서 보여준 습관을 흡수해서 다시 내놓는 스펀지에 가깝다는 것
  • AI가 코드를 빨리 만들어줄수록, 머지 전에 '이 패턴을 다음 생성 결과의 기준으로 삼아도 괜찮나?'를 더 자주 물어봐야 함

---

기술 맥락

• 이 글에서 중요한 선택은 중복 조건문을 그냥 두느냐, 공유 헬퍼나 정책 함수로 빼느냐예요. 예전에도 유지보수성 때문에 중요했지만, LLM 코딩에서는 이 선택이 다음 생성 결과의 입력 신호가 되기 때문에 더 커져요.

• 왜 문제가 되냐면 LLM은 프로젝트의 기존 모양을 강하게 따라가거든요. 같은 접근 권한 로직이 라우트, 잡, API, 웹훅에 흩어져 있으면 모델은 '이 프로젝트는 이렇게 복붙해서 처리하는구나'라고 판단하기 쉬워요.

• 어떻게 대응하느냐도 거창하지 않아요. 권한 체크처럼 의미가 같은 로직은 이름 있는 함수로 모으고, 새 코드를 받을 때도 기존 추상화를 쓰게 만드는 게 핵심이에요. 그러면 다음 프롬프트에서 모델이 참고할 좋은 예제가 코드베이스 안에 남아요.

• 결국 AI 코딩의 품질 관리는 프롬프트만의 문제가 아니에요. repo 안에 어떤 패턴을 머지해두는지가 모델의 작업 환경을 만들고, 그 환경이 다시 다음 코드의 품질을 결정해요.