본문으로 건너뛰기

© 2026 Molayo

Dev.to헤드라인2026. 06. 03. 17:35

리팩터링에는 3일이 걸렸지만, AI는 단 한 세션 만에 이를 되돌려 놓았다

요약

AI를 활용한 개발 환경에서 리팩터링의 효과가 지속되지 않는 이유를 분석합니다. 리팩터링으로 개선된 코드 패턴이 AI의 다음 작업에 반영되지 않는 문제를 해결하기 위해, 명시적인 규칙(Rules) 설정의 중요성을 강조합니다.

핵심 포인트

  • 리팩터링만으로는 AI가 생성하는 코드의 품질을 유지할 수 없음
  • AI는 명시적인 제약 조건이 없으면 이전의 잘못된 패턴을 반복함
  • 리팩터링 후 확립된 표준을 AI를 위한 규칙으로 문서화해야 함
  • 규칙 기반의 개발은 코드베이스의 기술 부채 축적을 방지함

그 기분을 잘 아실 겁니다.

3일 동안의 세심한 작업. 로직을 적절한 위치로 이동시키기. 너무 커져 버린 컴포넌트(Components) 분할하기. 실제로 의미가 통하는 명명 규칙(Naming) 확립하기. 너무 많은 세션에 걸쳐 축적된 상태 관리(State management) 정리하기.

코드베이스(Codebase)는 마침내 처음부터 그랬어야 했던 모습처럼 보였습니다.

그때 새로운 기능 요청이 들어왔습니다. 당신은 세션을 열었습니다. AI가 첫 번째 컴포넌트를 생성했습니다.

그리고 그것은 리팩터링(Refactor) 전의 코드베이스와 정확히 똑같아 보였습니다.

규칙 없는 리팩터링이 유지되지 않는 이유

리팩터링은 존재하는 것을 바꿉니다. 하지만 새로운 것이 만들어지는 방식까지 바꾸지는 않습니다.

React 프로젝트를 리팩터링할 때, 당신은 이전의 모든 세션에서 축적된 결정들을 바로잡고 있는 것입니다. 당신은 표준(Standard)이 없었던 코드베이스에 표준을 부여하고 있는 것입니다.

하지만 다음 기능을 구축하는 AI는 그 리팩터링에 대해 알지 못합니다. 당신이 패턴(Pattern)을 확립하기 위해 3일을 보냈다는 사실을 모릅니다. 컴포넌트가 이제는 다르게 분할되어야 한다는 것, 상태(State)가 이제는 특정 위치에 있어야 한다는 것, 임포트(Imports)가 이제는 특정 컨벤션(Convention)을 따라야 한다는 것을 알지 못합니다.

AI는 자신이 볼 수 있는 것과 존재하는 제약 조건(Constraints)을 바탕으로 생성합니다. 만약 제약 조건이 리팩터링 전과 같다면, 결과물도 리팩터링 전과 같을 것입니다.

리팩터링은 과거를 청소했습니다. 하지만 미래를 보호하기 위한 규칙은 작성되지 않았습니다.

대부분의 개발자가 인지하지 못하는 순환 고리

리팩터링. AI로 구축하기. 표준이 침식되는 것을 지켜보기. 다시 리팩터링하기.

각 리팩터링이 진정으로 상황을 개선하기 때문에 이는 진전처럼 느껴집니다. 하지만 그 개선은 복리로 쌓이지 않습니다. 초기화될 뿐입니다. 왜냐하면 근본적인 원인인 '규칙 없이 스스로 결정을 내리는 AI'는 전혀 변하지 않았기 때문입니다.

리팩터링에 쓴 3일은 낭비된 것이 아닙니다. 하지만 투자된 것도 아닙니다. 그것은 소모되었습니다. 그리고 다음 세션은 반대편에서 그것들을 다시 소모해 버렸습니다.

규칙 없는 리팩터링 (Refactor)은 유효 기간이 정해진 수정일 뿐입니다. AI는 준수해야 할 제약 조건 없이 새로운 것을 생성하는 순간, 당신이 정리해 놓은 것을 다시 무너뜨릴 것입니다.

리팩터링을 영구적으로 만드는 법

리팩터링이 영구적이 되는 시점은, 그 리팩터링이 세운 표준이 앞으로 AI가 따라야 할 규칙 (Rules)으로 기록될 때입니다.

문서화 (Documentation)가 아닙니다. 코드 내의 주석 (Comments)도 아닙니다. 세션이 시작되기 전에 존재하며, 모든 새로운 출력물이 어떤 모습이어야 하는지를 정의하는 규칙입니다.

리팩터링을 마쳤을 때, 질문은 단지 "코드베이스 (Codebase)가 더 좋아졌는가?"에 그쳐서는 안 됩니다. "AI에게 이것을 되돌리지 않기 위해 필요한 규칙을 주었는가?"라고 물어야 합니다.

실제 사례는 다음과 같습니다:

마지막 리팩터링 이후 작성된 규칙:
1. 200라인이 넘는 컴포넌트 (Components)는 세션이 계속되기 전에 분리한다. 예외는 없다.
2. 모든 새로운 기능은 UI 컴포넌트가 구축되기 전에 전용 훅 (Hook)을 가져야 한다.
...

이것들은 리팩터링을 통해 확립된 패턴들이었습니다. 이를 기록하는 데는 20분이 걸렸습니다. 그리고 그 이후의 모든 세션에서 이 규칙들은 유지되었습니다.

다시는 할 필요가 없는 리팩터링

대부분의 개발자는 반응적으로 리팩터링을 합니다. 코드베이스가 표류하고, 고통이 너무 커지면, 그제야 리팩터링을 수행합니다.

규칙이 마련되면 표류는 멈춥니다. AI가 추측을 더 잘하게 되었기 때문이 아닙니다. AI가 추측을 멈추고 규칙을 따르기 시작했기 때문입니다.

다음 기능은 리팩터링된 코드베이스와 같은 모습을 갖추게 됩니다. 규칙이 반드시 그래야 한다고 정의하기 때문입니다. 대략적으로가 아니라, 정확하게 말입니다.

그것이 바로 당신이 다시는 할 필요가 없는 리팩터링입니다. 코드베이스가 절대 변하지 않기 때문이 아니라, 리팩터링이 세운 표준이 이후의 모든 세션과 함께 이동하기 때문입니다.

프롬프트 (Prompt)는 중요하지 않습니다. 규칙이 중요합니다.

3일간의 리팩터링이 단 한 번의 세션으로 무너질 만큼 가벼운 것은 아닙니다.

표준을 기록하십시오. 다음 세션이 시작되기 전에 AI에게 전달하십시오. 그리고 그것을 보호할 규칙을 단 한 번도 기록하지 않았다는 이유로, 똑같은 코드베이스를 반복해서 리팩터링하는 일을 멈추십시오.

당신의 React 프로젝트 중 어느 부분이 단 한 번의 AI 세션만으로 또 다른 리팩터링(Refactor)이 필요하게 될지 알고 싶습니까?

저는 바로 그 부분을 정확히 찾아낼 수 있도록 도와주는 24가지 항목의 무료 체크리스트를 만들었습니다. AI에게 새로운 빌드 작업을 맡기는 순간, AI가 스스로의 결정으로 채워버릴 구조적 공백(Structural gaps)들을 찾아낼 수 있습니다.

React AI 클린 코드 체크리스트 받기 — 무료

Avery Code React AI 엔지니어링 시스템

AI 자동 생성 콘텐츠

본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.

원문 바로가기
0

댓글

0