2025년 9월 15일·7분
AI가 생성한 코드베이스가 재작성하기 더 쉬운 이유
AI가 생성한 코드베이스는 반복 가능한 패턴을 따르는 경우가 많아, 수작업으로 만든 맞춤형 시스템보다 재작성·교체가 더 쉬울 수 있습니다. 이유와 안전하게 활용하는 방법을 설명합니다.
AI가 생성한 코드베이스는 반복 가능한 패턴을 따르는 경우가 많아, 수작업으로 만든 맞춤형 시스템보다 재작성·교체가 더 쉬울 수 있습니다. 이유와 안전하게 활용하는 방법을 설명합니다.
“교체하기 더 쉽다”는 말은 전체 애플리케이션을 삭제하고 처음부터 다시 만든다는 뜻인 경우는 드뭅니다. 실제 팀에서는 교체가 여러 규모로 일어나며, “재작성(rewrite)”의 의미는 무엇을 교체하느냐에 따라 달라집니다.
교체 대상은 다음과 같을 수 있습니다:
사람들이 코드베이스가 “재작성하기 더 쉽다”고 말할 때는 보통 한 조각을 다시 시작해도 다른 부분을 뒤흔들지 않을 수 있다는 의미입니다. 비즈니스는 계속 운영하고 점진적으로 마이그레이션할 수 있습니다.
여기서의 논지는 “AI 코드가 더 낫다”가 아닙니다. 관찰되는 전형적인 경향에 관한 이야기입니다.
재작성 시에는 이런 차이가 중요합니다. 널리 이해되는 관례를 따르면 또 다른 관습적 구현으로 상대적으로 적은 토론과 적은 놀라움으로 교체할 수 있습니다.
AI가 생성한 코드는 일관성이 없거나 반복적이거나 테스트가 부족할 수 있습니다. “교체하기 더 쉽다”는 주장은 더 깔끔하다는 뜻이 아니라, 덜 ‘특별하다’는 주장입니다. 서브시스템이 공통 재료로 만들어졌다면, 그것을 교체하는 것은 맞춤형 기계를 역공학하는 것보다 표준 부품을 교체하는 것과 비슷할 수 있습니다.
핵심 아이디어는 단순합니다: 표준화는 전환 비용을 낮춘다. 코드가 인식 가능한 패턴과 명확한 경계를 갖추면, 숨겨진 의존성을 깨뜨릴 두려움 없이 부분을 재생성하거나 리팩터링하거나 재작성할 수 있습니다. 아래 섹션들은 구조, 소유권, 테스트, 일상적 엔지니어링 속도에서 이 원리가 어떻게 적용되는지 보여줍니다.
AI가 생성한 코드의 실용적 장점 중 하나는 친숙한 패턴(폴더 구조, 예측 가능한 네이밍, 주류 프레임워크 관례, 라우팅/검증/오류 처리/데이터 접근에 대한 교과서적 접근)을 기본값으로 택하는 경향입니다. 코드가 완벽하지 않더라도 많은 튜토리얼이나 스타터 프로젝트처럼 읽기 쉬운 경우가 많습니다.
재작성은 주로 기존 것을 먼저 이해해야 하므로 비용이 많이 듭니다. 잘 알려진 관례를 따르는 코드는 그 “해독” 시간을 줄여줍니다. 새로운 엔지니어는 구성 파일이 어디에 있는지, 요청이 어떻게 흐르는지, 의존성이 어떻게 연결되는지, 테스트가 어디에 있어야 하는지를 이미 가진 정신 모델에 매핑할 수 있습니다.
이로 인해 더 빠르게 할 수 있는 것들:
반대로, 고도로 수작업화된 코드베이스는 종종 깊게 개인화된 스타일을 반영합니다: 고유한 추상화, 커스텀 미니 프레임워크, 과거 맥락 없이는 이해하기 힘든 도메인 특화 패턴 등. 이런 선택은 우아할 수 있지만, 재시작 비용을 올립니다.
이건 AI에만 국한된 마법이 아닙니다. 팀은 템플릿, 린터, 포매터, 스캐폴딩 도구를 통해 구조와 스타일을 강제할 수 있고 그래야 합니다. 차이점은 AI는 기본적으로 “일반적(generic)인 기본값”을 출력하는 경향이 있고, 사람이 쓴 시스템은 관례를 적극적으로 유지하지 않으면 맞춤화로 흘러가기 쉽다는 점입니다.
재작성 고통의 많은 부분은 핵심 비즈니스 로직 때문이 아닙니다. 맞춤형 글루—커스텀 헬퍼, 자체 제작 마이크로 프레임워크, 메타프로그래밍 트릭, 일회성 관례—이 모든 것을 조용히 연결해 놓은 것이 문제입니다.
맞춤형 글루는 제품의 일부는 아니지만 제품이 그것 없이는 동작하지 않는 요소들입니다. 예를 들어: 커스텀 의존성 주입 컨테이너, 직접 만든 라우팅 레이어, 모델을 자동 등록하는 마법 같은 베이스 클래스, 편의를 위해 전역 상태를 변경하는 헬퍼 등. 처음에는 시간 절약용으로 시작하지만 결국 변경 시 필수 지식이 됩니다.
문제는 글루가 존재하는 것이 아니라 보이지 않는 결합이 되는 것입니다. 팀 전용 글루는 흔히:
재작성 중 이 글루를 정확히 재현하기는 어렵습니다. 규칙이 문서화되어 있지 않은 경우 깨뜨려보며 알아내는 수밖에 없습니다.
AI 출력은 종종 표준 라이브러리, 공통 패턴, 명시적 배선을 선호합니다. 모델은 복잡한 마이크로 프레임워크를 발명하기보다 간단한 모듈이나 서비스 객체를 선택할 가능성이 큽니다. 이런 절제는 장점이 될 수 있습니다: 마법 같은 훅이 적으면 숨겨진 의존성도 적어지고, 서브시스템을 떼어내 교체하기 쉬워집니다.
단점은 ‘평범한’ 코드가 더 장황할 수 있다는 점입니다—더 많은 매개변수를 전달하고 더 많은 배관 코드가 생기며 근사치를 택하는 대신 명시적으로 처리합니다. 그러나 장황함은 미스터리보다 보통 더 저렴합니다. 재작성할 때는 이해하기 쉽고 삭제하기 쉬우며 오해하기 어려운 코드를 원합니다.
“예측 가능한 구조”는 아름다움보다 일관성에 관한 것입니다: 같은 폴더, 네이밍 규칙, 요청 흐름이 모든 곳에서 반복되는 것. AI 생성 프로젝트는 종종 controllers/, services/, repositories/, models/ 같은 친숙한 기본값과 반복적인 CRUD 엔드포인트, 유사한 검증 패턴을 따릅니다.
그런 일관성은 재작업을 절벽이 아닌 계단으로 바꿉니다.
기능 전반에서 패턴이 반복됩니다:
UserService, UserRepository, UserController)모든 기능이 같은 방식으로 구성되면, 매번 시스템을 다시 배우지 않고도 한 조각씩 교체할 수 있습니다.
점진적 재작성은 경계를 격리하고 그 뒤를 재구축할 수 있을 때 가장 잘 작동합니다. 예측 가능한 구조는 자연스럽게 그 봉합부(Seam)를 만듭니다: 각 레이어는 좁은 역할을 가지며 대부분의 호출은 소수 인터페이스를 통해 이뤄집니다.
실용적인 접근법은 “스트랭글러(strangler)” 스타일입니다: 공개 API를 안정적으로 유지하고 내부를 점진적으로 대체합니다.
컨트롤러가 서비스를 호출하고 서비스가 리포지토리를 호출하는 앱을 가정해보면:
OrdersController → OrdersService → OrdersRepository직접 SQL에서 ORM으로, 또는 한 DB에서 다른 DB로 이동하고 싶다면 예측 가능한 코드베이스에서는 변경을 한곳에 국한시킬 수 있습니다:
OrdersRepositoryV2(새 구현)를 만든다getOrder(id), listOrders(filters))컨트롤러와 서비스 코드는 대부분 그대로 남아 있습니다.
고도로 수작업으로 만든 시스템은 훌륭할 수 있지만 종종 고유한 아이디어를 코드에 새깁니다: 커스텀 추상화, 영리한 메타프로그래밍, 베이스 클래스에 숨은 횡단 관심사. 이런 곳에서는 각 변경이 깊은 역사적 맥락을 요구합니다. 반면 예측 가능한 구조에서는 "어디를 바꿔야 하나?" 질문이 보통 명확해서 작은 재작성 작업을 주간 단위로 수행할 수 있습니다.
많은 재작성의 조용한 장애물은 기술적이기보다 사회적입니다. 팀은 종종 소유권 위험을 떠안고 있는데, 한 사람만 시스템을 진정으로 이해하는 경우가 있습니다. 그 사람이 큰 부분을 수작업으로 작성했다면 코드는 개인적 유물처럼 느껴지기 시작합니다: “내 설계”, “내 영리한 해결책”, “릴리즈를 구해준 내 워크어라운드”. 이런 애착은 삭제를 감정적으로 부담스럽게 만들고 이는 경제적으로 합리적일 때조차 재작업을 어렵게 합니다.
AI가 생성한 코드는 이 효과를 줄일 수 있습니다. 초기 초안이 도구에 의해 생성되었고 친숙한 패턴을 따르는 경우, 코드는 서명(signiture)처럼 느껴지기보다 교체 가능한 구현처럼 느껴집니다. 사람들은 누군가의 공예품을 지우는 것 같지 않을 때 모듈을 교체하자는 데 더 편하게 동의합니다.
작성자 애착이 낮을 때 팀은:
재작성 결정은 여전히 비용과 결과(전달 일정, 리스크, 유지보수성, 사용자 영향)를 기반으로 내려야 합니다. “삭제하기 쉽다”는 유용한 특성이지만 그것만으로 전략이 될 수는 없습니다.
과소평가되는 장점 중 하나는 AI가 생성한 코드의 입력값이 살아있는 명세(living specification)로 기능할 수 있다는 점입니다. 프롬프트, 템플릿, 생성 구성은 자연어로 의도를 설명할 수 있습니다: 기능이 무엇을 해야 하는지, 어떤 제약(보안, 성능, 스타일)이 중요한지, “완료”의 기준이 무엇인지 등.
반복 가능한 프롬프트(또는 프롬프트 라이브러리)와 안정적인 템플릿을 사용하면 의사결정의 감사 추적이 만들어집니다. 좋은 프롬프트는 미래의 유지보수자가 추측해야 할 내용을 명시할 수 있습니다:
이것은 많은 수작업 코드베이스에서 핵심 설계 선택이 커밋 메시지, 부족 지식, 작은 암묵적 관례에 흩어져 있는 것과 의미 있게 다릅니다.
생성 추적(프롬프트 + 모델/버전 + 입력 + 후처리 단계)을 보관하면 재작성은 백지에서 시작하지 않습니다. 같은 체크리스트를 재사용해 동일한 동작을 더 깔끔한 구조 아래 재생성하고 출력물을 비교할 수 있습니다.
실무적으로, 이는 재작성 과정을 “새 규칙 아래에서 기능 X를 재생성하고 동등성을 검증한다”로 바꿀 수 있습니다. 반대로 수작업에서는 “기능 X가 무엇을 해야 했는지 역추적한다”가 됩니다.
이 방식이 작동하려면 프롬프트와 설정을 소스 코드처럼 관리해야 합니다:
그렇지 않으면 프롬프트는 또 다른 문서화되지 않은 의존성이 됩니다. 잘 관리하면, 수작업 시스템들이 종종 갖지 못한 문서가 될 수 있습니다.
“교체하기 쉽다”는 사실상 사람이 썼는지 툴이 썼는지의 문제가 아니라, 자신 있게 변경할 수 있는지의 문제입니다. 테스트가 변경 후에도 동작이 동일하다는 것을 빠르고 신뢰성 있게 알려주면 재작성은 일상적 엔지니어링이 됩니다.
AI 생성 코드는 요청 시 이것을 도와줄 수 있습니다. 많은 팀이 기능과 함께 보일러플레이트 테스트(기본 단위 테스트, 해피패스 통합 테스트, 간단한 모킹)를 프롬프트로 생성하도록 합니다. 이 테스트들이 완벽하진 않더라도, 테스트가 미뤄진 수작업 시스템에 비해 초기 안전망을 제공합니다.
교체 가능성을 원하면 파트들이 만나는 봉합부에 테스트 에너지를 집중하세요:
계약 테스트는 내부를 교체해도 변하지 말아야 할 것을 고정합니다. 따라서 모듈을 API 뒤에서 재작성하거나 어댑터 구현을 바꿔도 비즈니스 동작을 재논의할 필요가 줄어듭니다.
커버리지 수치는 위험 구역을 안내할 수 있지만, 100%를 쫓는 것은 리팩터를 막는 깨지기 쉬운 테스트를 만들기 쉽습니다. 대신:
강한 테스트가 있으면 재작업은 영웅적 프로젝트가 아니라 안전하고 되돌릴 수 있는 단계의 연속이 됩니다.
AI 생성 코드는 예측 가능한 방식으로 실패하는 경향이 있습니다. 같은 헬퍼가 세 번씩 재구현되거나, 거의 같은 분기가 엣지 케이스를 다르게 처리하거나, 모델이 수정을 계속 덧붙이면서 함수가 비대해지는 모습을 자주 봅니다. 이것들은 이상적이지 않지만 한 가지 장점이 있습니다: 보통 가시적입니다.
수작업 시스템은 영리한 추상화나 미세 최적화 뒤에 복잡성을 숨길 수 있습니다. 그런 버그는 올바른 것처럼 보이고 가벼운 리뷰를 통과하기 때문에 고통스럽습니다.
AI 코드는 대신 명백히 일관성이 없는 경우가 많습니다: 한 경로에서는 매개변수를 무시하고 다른 파일에서는 검증이 빠져 있거나, 오류 처리 스타일이 함수마다 바뀝니다. 이런 불일치는 리뷰와 정적 분석에서 드러나기 쉽고, 깊은 의도적 불변식에 의존하지 않기 때문에 격리하기도 쉽습니다.
반복은 신호입니다. 같은 단계(입력 파싱 → 정규화 → 검증 → 매핑 → 반환)가 여러 엔드포인트나 서비스에 반복되면 자연스러운 추출/교체 지점입니다. AI는 종종 이전 솔루션을 약간 수정해 재생산하기 때문에 거의 동일한 복제본 클러스터를 만듭니다.
실무적 접근법은 다음과 같습니다:
반복되는 동작을 한 문장으로 설명할 수 있다면, 그건 아마 하나의 모듈이어야 합니다.
반복 조각들을 하나의 유틸리티, 공유 서비스 또는 라이브러리 함수로 교체하고 기대 엣지 케이스를 고정하는 테스트를 작성한 다음 중복을 삭제하세요. 여러 취약한 복사본을 개선할 한 곳으로 만들면 나중에 다시 교체하기도 쉬워집니다.
AI 생성 코드는 명확성을 우선하라고 요구하면 친숙한 제어 흐름, 관습적 네이밍, ‘지루한’ 모듈을 선택하는 경향이 있습니다. 이는 약간의 속도 향상보다 장기적으로 더 큰 이득이 될 수 있습니다.
새로운 사람이 시스템의 정확한 정신 모델을 빠르게 만들 수 있으면 재작성은 성공합니다. 가독성 있고 일관된 코드는 “요청은 어디로 들어오나?” “여기서 데이터 형태는 무엇인가?” 같은 기본 질문에 답하는 시간을 줄입니다. 모든 서비스가 유사한 패턴(레이아웃, 오류 처리, 로깅, 설정)을 따르면 새로운 팀이 한 조각씩 교체하면서 지역 관례를 계속 배우지 않아도 됩니다.
일관성은 또한 두려움을 줄입니다. 코드가 예측 가능하면 엔지니어는 표면적 이해가 쉬워지므로 일부를 삭제하고 다시 빌드하는 데 자신감을 가집니다.
고도로 최적화된 수작업 코드는 재작성하기 어려울 수 있습니다. 성능 기법은 종종 곳곳에 스며들기 때문입니다: 커스텀 캐싱 레이어, 미세 최적화, 자체 동시성 패턴, 특정 데이터 구조에 대한 강한 결합 등. 이런 선택은 유효할 수 있지만, 문제가 생기기 전까지는 미묘한 제약을 만들기 쉽습니다.
가독성이 느려도 괜찮다는 면죄부는 아닙니다. 재작성 전후로 성능 지표(지연 시간 백분위, CPU, 메모리, 비용)를 측정하세요. 교체 후 성능이 악화되면 특정 핫스팟을 최적화하되 전체 코드를 퍼즐로 만들지 마세요.
AI 보조 코드베이스가 '이상하다'고 느껴질 때 항상 전체 재작성으로 가야 하는 것은 아닙니다. 어떤 리셋이 적절한지는 시스템의 어느 부분이 잘못됐는지(wrong), 단순히 *지저분한지(messy)*에 달려 있습니다.
**재생성(Regenerate)**은 스펙이나 프롬프트에서 부분을 다시 만드는 것을 의미합니다—종종 템플릿이나 알려진 패턴에서 시작해 통합 지점(라우트, 계약, 테스트)을 다시 연결합니다. “모두 삭제”가 아니라 “이 조각을 더 명확한 설명으로 다시 만든다”는 접근입니다.
**리팩터(Refactor)**는 동작은 유지한 채 내부 구조만 바꿉니다: 이름 변경, 모듈 분리, 조건부 단순화, 중복 제거, 테스트 개선 등.
**재작성(Rewrite)**은 현재 설계를 유지할 수 없고 경계, 데이터 흐름, 동작을 바꿔야 할 때 새로운 구현으로 교체하는 것입니다.
재생성은 가치가 인터페이스에 있고 내부가 대부분 보일러플레이트인 경우에 빛을 발합니다:
스펙이 명확하고 모듈 경계가 깔끔하면 재생성은 얽힌 코드를 풀어내는 것보다 빠른 경우가 많습니다.
코드가 고된 도메인 지식을 담고 있거나 미묘한 정확성 제약을 가진 경우 주의하세요:
이 영역에서는 “거의 같은”이 비싸게 틀릴 수 있습니다—재생성이 도움이 되더라도 강력한 테스트와 리뷰로 동등성을 증명할 수 있을 때만 사용하세요.
재생성된 코드는 새 의존성처럼 다루세요: 인간 리뷰를 요구하고 전체 테스트 스위트를 돌리고 이전에 본 실패 사례를 대상으로 한 테스트를 추가하세요. 기능 플래그나 점진적 배포를 활용해 한 엔드포인트, 한 화면, 한 어댑터 단위로 롤아웃하세요.
유용한 기본 원칙은: 쉘을 재생성하고, 경계를 리팩터링하며, 가정이 계속 깨진다면 그 부분만 재작성하라입니다.
“교체하기 쉽다”는 이점은 팀이 교체를 설계된 활동으로 다루는 한 계속 유지됩니다. AI가 생성한 모듈은 더 빠르게 교체될 수 있지만, 검증보다 신뢰하면 더 빠르게 실패할 수도 있습니다.
AI가 생성한 코드는 완성된 것처럼 보이는 경우가 많아 **거짓된 자신감(false confidence)**을 초래할 수 있습니다.
또 다른 리스크는 빠진 엣지 케이스입니다: 드문 입력, 타임아웃, 동시성 문제, 프롬프트나 샘플 데이터에 포함되지 않은 오류 처리 등.
마지막으로 라이선스/IP 불확실성이 있습니다. 많은 상황에서 위험이 낮을 수 있지만, 팀은 어떤 소스와 도구를 허용할지, 출처를 어떻게 추적할지 정책을 가져야 합니다.
교체 작업을 다른 변경과 동일한 게이트 뒤에 두세요:
모듈을 교체하기 전에 그 경계와 불변 조건을 적어두세요: 어떤 입력을 받는지, 어떤 것을 보장하는지, 절대 해서는 안 될 것(예: “고객 데이터를 삭제하지 않는다”), 성능/지연 기대치 등. 이 "계약"이 바로 구현이 무엇이든 테스트해야 할 대상입니다.
AI가 생성한 코드는 친숙한 패턴을 따르고 깊은 ‘공예적’ 개인화를 피하며 요구가 바뀔 때 조각을 빠르게 재생성할 수 있기 때문에 재작성하기 더 쉬운 경우가 많습니다. 그 예측 가능성은 코드 일부를 삭제·교체하는 데 드는 사회적·기술적 비용을 낮춥니다.
목표는 “코드를 버려라”가 아니라 계약과 테스트로 뒷받침된 상태에서 코드를 교체하는 것을 정상적이고 마찰이 적은 옵션으로 만드는 것입니다.
먼저 관례를 표준화해 재생성되거나 재작성된 코드가 같은 틀에 맞게 하세요:
vibe-coding 워크플로우를 사용한다면, 계획 모드 스펙을 리포와 함께 저장하고 생성 추적을 캡처하며 안전한 롤백을 지원하는 툴을 찾아보세요. 예를 들어 Koder.ai는 채팅 기반 생성과 스냅샷/롤백을 지원하도록 설계되어 있어 “교체 가능하게 설계”하는 접근과 잘 맞습니다—조각을 재생성하고 계약을 유지하며 동등성 테스트 실패 시 빠르게 되돌릴 수 있습니다.
중요하지만 안전하게 격리할 수 있는 모듈(예: 보고서 생성, 알림 전송, 단일 CRUD 영역)을 하나 골라서 공용 인터페이스를 정의하고 계약 테스트를 추가한 다음 내부를 재생성/리팩터/재작성해 볼 것을 권합니다. 사이클 타임, 결함률, 리뷰 노력을 측정해 팀 전체 규칙을 정하세요.
이를 운영화하려면 내부 플레이북에 체크리스트를 두고(또는 /blog로 공유) “계약 + 관례 + 추적” 트리오를 새 작업의 요구사항으로 만드세요. 툴링을 평가 중이라면 /pricing을 보기 전에 어떤 지원이 필요한지 문서화하세요.
"교체"는 보통 시스템의 *일부분(slice)*을 다른 것으로 바꾸고 나머지는 계속 운영하는 것을 의미합니다. 일반적인 대상은:
전체 앱을 통째로 지우고 다시 쓰는 일은 드물며, 성공적인 재작성은 대부분 점진적입니다.
주장은 전형적인 경향에 관한 것이지 품질 우열을 단정하는 것은 아닙니다. AI가 생성한 코드는 종종:
그런 “덜 특이한” 형태는 이해와 교체를 더 빠르게 만듭니다.
표준 패턴은 재작성 시 ‘해독 비용’을 낮춥니다. 엔지니어가 빠르게 인식할 수 있다면:
…새 구현에서 동작을 재현하기 위해 개인적 아키텍처를 먼저 배우지 않아도 됩니다.
맞춤형 글루(홈브루 DI 컨테이너, 마법 같은 베이스 클래스, 암시적 전역 상태 등)는 코드에서 명확히 드러나지 않는 결합을 만듭니다. 교체 과정에서는:
더 명시적이고 관습적인 결합 방식은 이러한 놀라움을 줄여줍니다.
경계(boundary)를 안정화하고 내부를 교체하는 방식이 실용적입니다:
이 접근법은 "절벽"이 아니라 "계단(strangler)" 스타일입니다.
AI가 생성한 초안은 도구에 의해 생산되었다는 느낌 때문에 다음과 같은 행동 변화를 촉진합니다:
엔지니어링 판단이 사라지는 것은 아니지만, 변화에 대한 사회적 마찰이 줄어듭니다.
프롬프트, 템플릿, 생성 설정을 리포지토리에 보관하면 가벼운 스펙이 됩니다:
이것들을 코드처럼 버전 관리하고 어떤 프롬프트/설정이 어떤 모듈을 만들었는지 기록하지 않으면, 프롬프트는 또 다른 문서화되지 않은 의존성이 됩니다.
교체 가능성을 원하면 경계(seam)에 테스트를 집중하세요:
이런 계약 테스트가 통과하면 내부를 교체할 때 훨씬 더 안전합니다.
AI가 생성한 코드는 보통 눈에 띄는 방식으로 실패합니다:
반복이 보이면 추출 후보로 삼으세요: 반복되는 조각을 하나의 테스트된 모듈로 통합하고 복제본을 제거하면 교체가 쉬워집니다.
생산성보다 가독성과 일관성을 우선하면 장기적으로 재작성에 더 유리합니다. 다만 성능은 측정으로 관리하세요:
재설정 옵션은 세 가지입니다:
재생성은 보일러플레이트 중심의 모듈에 특히 적합하지만, 도메인 지식이나 동시성/컴플라이언스처럼 민감한 부분에서는 강력한 검증이 필요합니다. 항상 리뷰 게이트와 소규모 롤아웃을 둡니다.