AI가 코드를 써도 중복은 빚으로 남아요

AI가 코드를 써도 중복은 빚으로 남아요

AI 뉴스 썸네일

AI 코딩 도구가 같은 조건문을 여러 파일에 만들어도 당장은 문제가 없어 보여요. 코드가 실행되고 테스트까지 통과하면 그대로 합치기 쉬워요. 하지만 저장소에 남은 중복은 다음 코드의 참고 사례가 되고, 고칠 곳도 그만큼 늘어나요. 1

핵심 요약

구분	핵심	왜 볼 만한가요
코드 품질	동작하는 중복 코드도 유지보수 비용을 만들어요	접근 규칙이 바뀌면 여러 위치를 함께 고쳐야 해요
AI 코딩	기존 저장소의 패턴이 다음 생성 결과에 영향을 줘요	나쁜 관행이 반복될 가능성을 줄이려면 기준 코드부터 정돈해야 해요
실무 대응	공통 규칙을 한곳에 모으고 리뷰와 테스트로 경계를 지켜요	코드 작성 속도와 장기 품질을 함께 관리할 수 있어요

1. AI가 만든 코드도 사람이 고칠 수 있어야 해요

원문 저자 Scott Robinson은 접근 권한 확인 조건을 라우트 처리, 백그라운드 작업, API 엔드포인트, 웹훅에 각각 넣었던 경험을 소개해요. 각 구현은 작동했고 테스트도 통과했어요. 문제는 거의 같은 조건이 네 군데에 남았다는 점이에요. 공유 함수 하나로 묶을 수 있는 규칙이 복사본 네 개로 퍼진 셈이에요. 2

이 상태에서 활성 사용자, 읽기 권한, 계정 상태 가운데 하나라도 정책이 바뀌면 수정 범위가 넓어져요. 한 군데를 빠뜨리면 경로마다 권한 판정이 달라질 수도 있어요. 테스트가 현재 동작을 확인해 줘도, 흩어진 규칙을 자동으로 하나의 설계로 바꿔 주지는 않아요.

728x90

저장소의 기존 관행이 다음 코드에 남아요

AI 코딩 도구는 작업 중인 파일과 주변 구현을 참고해 다음 코드를 만들어요. 같은 접근 조건이 여러 파일에 복사돼 있으면 새 엔드포인트에도 비슷한 조건문이 붙기 쉬워요. 저장소에 들어간 지름길이 일회성 코드로 끝나지 않고 반복 가능한 예시가 되는 거예요.

다만 모든 중복을 도구 탓으로 돌리면 원인을 놓쳐요. 일정 압박 때문에 사람이 복사해서 붙인 코드도 같은 문제를 만들어요. 차이는 생성 속도예요. 짧은 시간에 더 많은 코드를 만들 수 있으니, 잘못된 패턴도 더 빠르게 퍼질 수 있어요.

나중에 한꺼번에 고치기는 생각보다 어려워요

중복이 다섯 군데로 늘어난 뒤 리팩터링하면 각 구현의 차이를 먼저 확인해야 해요. 변수 이름만 다른지, 예외 조건이 섞였는지, 호출 시점이 다른지 살펴봐야 해요. 겉보기에는 같은 코드라도 일부 경로가 별도 정책을 가질 수 있어요. 무작정 공통 함수로 합치면 기존 동작을 깨뜨릴 위험도 생겨요.

그래서 "나중에 도구가 정리해 줄 것"이라는 가정은 안전하지 않아요. 도구가 모든 복사본을 찾았는지, 차이를 제대로 해석했는지, 변경 뒤 권한 경계가 유지되는지는 사람이 검토해야 해요. 늦게 정리할수록 확인할 코드와 테스트가 함께 늘어요.

병합 전에 확인할 기준은 단순해요

새 코드가 기존 규칙을 반복한다면 먼저 공통 경계를 찾는 편이 좋아요. 접근 제어라면 `canReadAccount()`처럼 의도가 드러나는 함수나 정책 객체에 규칙을 모을 수 있어요. 호출부에는 권한 판단의 세부 조건보다 업무 의미만 남겨요.

공통화가 늘 정답은 아니에요. 두 코드가 우연히 닮았을 뿐 변경 이유가 다르면 억지로 묶지 않는 편이 나아요. 반대로 같은 정책 때문에 함께 바뀌어야 한다면 한곳에 두는 편이 안전해요. 코드 모양보다 변경 이유를 기준으로 판단해야 해요.

테스트도 공통 규칙의 경계를 따라가야 해요. 활성 상태, 정지 상태, 권한 유무, 닫힌 계정처럼 정책 조합을 한곳에서 검증해요. 각 엔드포인트에서는 공통 판정 결과를 올바르게 사용하는지만 확인하면 중복 테스트를 줄일 수 있어요.

리뷰는 생성량보다 변경 비용을 봐야 해요

AI 코딩 도구를 쓰면 완성된 코드가 빠르게 늘어요. 리뷰할 때는 "작동하는가"에서 끝내지 말고 "같은 규칙이 이미 있는가", "정책 변경 시 몇 군데를 고쳐야 하는가", "새 추상화가 실제 변경 경계를 따르는가"를 함께 봐야 해요.

정적 분석기도 도움이 돼요. 중복 코드, 순환 복잡도, 지나치게 큰 함수를 자동으로 찾아내면 리뷰어가 설계 판단에 시간을 더 쓸 수 있어요. 검사 결과를 무조건 따르기보다 반복되는 경고를 저장소 품질의 추세로 보는 편이 실용적이에요.

왜 중요한가요

AI 코딩 도구의 생산성은 입력 속도보다 병합 뒤 비용으로 평가해야 해요. 오늘 10분을 아낀 구현이 정책 변경 때 네 파일을 고치게 만들면 절약한 시간이 그대로 남지 않아요. 특히 권한, 결제, 개인정보처럼 누락 비용이 큰 규칙은 중복 자체가 운영 위험이 될 수 있어요. 2

좋은 기준 코드는 사람에게만 필요한 문서가 아니에요. 새 코드를 만들 때 참고할 가장 가까운 예시이기도 해요. 공통 규칙이 명확하고 테스트 경계가 정돈된 저장소에서는 AI 코딩 도구도 그 구조를 따르기 쉬워요. 결국 빠르게 생성하는 능력보다 어떤 코드를 저장소에 남길지 결정하는 리뷰가 더 중요해져요.

참고 자료

1. 사람이 유지보수할 것처럼 코드를 작성하라 — GeekNews
2. Write code like a human will maintain it — Unstack, Scott Robinson