사람이 유지보수할 것처럼 코드를 작성하라 — LLM이 흡수해 되돌려줄 코드 패턴은 좋은 상태로 유지해야 한다

핵심 요약

LLM은 진공 상태에서 코드를 쓰지 않는다. 모델은 열린 파일, 이미 존재하는 패턴, 최근 변경사항을 보고 다음 코드를 만든다. 코드베이스에 병합된 지름길은 "여기서는 이렇게 한다"는 학습 신호가 된다. 같은 접근 제어 조건이 여러 위치에 반복되면, 다섯 번째 엔드포인트 요청시 LLM은 처음부터 설계하기보다 기존 복사본들을 따라간다.

> "다음에 같은 접근 규칙을 가진 엔드포인트를 LLM에 요청하면, 모델은 처음부터 생각하지 않고 저장소에 이미 있는 네 개의 복사본에서 시작한다."

원문 핵심 — GeekNews 31307번 요약

unstack.io의 글 "Write code for humans to maintain"은 LLM 시대의 코드 품질 문제에 대해 다음과 같이 진단한다.

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

• 중복 조건문이 4곳에 박혀 있으면, 5번째 복사본이 자연스럽게 따라옴
• LLM은 "복사된 조건문 4개"를 다섯 번째 복사본을 부르는 신호로 읽음
• 나중에 리팩터링을 요청해도 LLM이 기존 복사본을 모두 제대로 정리한다고 보장하기 어려움

if (
  user.isActive &&
  user.hasPermission('read') &&
  !user.isSuspended &&
  account.status === 'open'
) {
  // do a thing
}

이런 조건은 공유 헬퍼로 추출할 수 있지만, LLM이 만든 코드가 동작하고 테스트가 통과한다는 이유로 그대로 병합되는 경우가 많다.

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

"나중에 바꿀 때도 LLM이 해줄 것"이라는 생각은 중복과 코드 냄새를 방치하게 만든다.

• 중복 조건문
• "god" 함수
• "나중에 정리"하기로 한 병합

이런 코드 냄새는 계속 쌓인다. 나쁜 패턴이 늘어나면 다음 프롬프트의 결과에도 영향을 주고, 나중에 모든 인스턴스를 LLM이 빠짐없이 고칠 것이라고 믿기 어렵다.

3. 사람이 유지보수할 것처럼 코드를 작성해야 한다

LLM이 흡수해 되돌려줄 코드 패턴은 좋은 상태로 유지해야 한다. 즉, LLM의 입력이 되는 코드베이스 자체의 품질이 곧 미래의 LLM 출력 품질이다.

• --

한국 개발자 관점 — 우리가 얻을 교훈

a. 프롬프트보다 코드베이스가 더 큰 영향

LLM 코딩 어시스턴트의 성능을 좌우하는 건 모델 버전이나 프롬프트 엔지니어링보다 현재 저장소 상태다. "잘못된 패턴 100개"가 저장소에 있으면, 어떤 프롬프트를 주더라도 모델은 그 패턴을 따라간다.

b. 기술 부채의 새로운 정의

전통적 기술 부채는 "나중에 인간이 정리할 것"이라는 약속이었다. 이제는 "나중에 LLM이 정리해줄 것"이라는 더 위험한 약속이 등장했다. LLM은 코드를 작성한 사람만큼 컨텍스트를 이해하지 못하며, 저장소의 노이즈를 스스로 걸러내는 능력이 제한적이다.

c. 코드 리뷰의 무게가 더 커진다

LLM이 생성한 코드를 그대로 머지하면, 그 코드가 다음 LLM 호출의 학습 데이터가 된다. 머지 시점의 작은 타협이 수 개월 뒤의 시스템 품질을 좌우한다.

d. 정적 분석 도구의 재조명

순환 복잡도나 코드 중복을 결정적으로 잡아내는 AST 기반 정적 분석기(SonarQube, Rubocop 등)는 토큰을 전혀 쓰지 않으면서도 LLM보다 빠르고 결정적인 품질 가드를 제공한다. 빌드 파이프라인에 넣으면 LLM의 부주의를 보완할 수 있다.

• --

실천 가능한 5가지 규칙

1. 머지 전 동일 조건문이 3개 이상 중복되지 않았는지 확인 — 4번째 중복은 거의 확실히 머지 안 됨
2. "god" 함수 경보 — 100줄을 넘는 함수는 LLM에게 그대로 보여주지 말고 먼저 분해
3. 테스트는 실제로 코드를 검증하는가? — LLM이 만든 빈 테스트를 그대로 두면 다음 LLM도 빈 테스트를 학습
4. PR 리뷰에서 캡슐화를 깨는 주석을 제거 — 함수 호출자 동작을 함수 정의 위에 설명하는 주석은 LLM 과잉 정보
5. 주석은 사과다 — 코드가 명확하지 않을 때만 주석을 쓰고, 주석이 없으면서 부정확한 코드보다 낫다

• --

함께 보면 좋은 글

• LLM 번아웃이 온 것 같아요 — 같은 문체·같은 환각의 반복이 만든 피로
• LLM 시대의 엔지니어링 이해 부채 — LLM이 만든 코드가 남기는 시한폭탄
• AI를 사용해 더 나은 코드를 더 천천히 작성하기

• --

한 줄 결론

> 코드는 LLM이 잘 쓸 수 있도록 작성하는 게 아니라, 사람이 유지보수하기 좋게 작성해야 한다 — 그러면 LLM도 그 품질을 흡수해 따라간다.

원문 보기

---

📰 원본 출처 · https://news.hada.io/topic?id=31307 (#N=31307)

이 글은 GeekNews(긱뉴스)에 게제된 글을 기반으로 작성되었습니다. 원본의 라이선스와 저작권은 원작자에게 있습니다.