AI 코딩 프로젝트는 처음부터 다시 만들 필요 없다

• 목록
• 답변
• 글쓰기
• 옵션
  • 수정
  • 삭제

AI가 만든 코드가 복잡해지면 가장 먼저 떠오르는 선택은 “전부 지우고 다시 만들자”입니다. 새 프로젝트는 깨끗해 보이고, 프롬프트도 더 잘 쓸 수 있을 것 같으며, 이전 실수를 반복하지 않을 자신도 생깁니다. 하지만 실제 개발에서는 전체 재작성보다 점진적 리팩터링이 더 빠르고 안전한 경우가 많습니다.

그렇다고 재작성이 언제나 틀린 선택이라는 뜻은 아닙니다. 핵심은 감정적으로 낡은 코드를 버리는 것이 아니라, 리팩터링과 재작성 중 어느 쪽이 검증 비용을 줄이는지 판단하는 데 있습니다. 두 선택지를 개발 속도, 품질, 비용, 운영 위험이라는 기준으로 맞붙여 보겠습니다.

깨끗한 재작성 vs 맥락을 보존하는 리팩터링

새 코드는 단순하지만 기존 기능은 생각보다 복잡합니다

전체 재작성의 가장 큰 매력은 구조를 처음부터 설계할 수 있다는 점입니다. 잘못 나뉜 모듈, 중복된 함수, 임시로 붙인 예외 처리를 걷어내고 최신 프레임워크나 일관된 코딩 규칙을 적용할 수 있습니다. AI 코딩 에이전트에도 새 명세만 제공하면 되므로 작업이 단순해 보입니다.

문제는 기존 코드 안에 문서로 남지 않은 업무 규칙이 숨어 있다는 사실입니다. 특정 고객만 사용하는 입력 형식, 월말에만 실행되는 정산 예외, 오래된 모바일 브라우저를 위한 우회 처리처럼 눈에 띄지 않는 코드도 실제 사용자에게는 기능입니다. 재작성 과정에서 이를 누락하면 코드는 깔끔해져도 제품은 이전보다 불편해집니다.

반대로 점진적 리팩터링은 현재 동작을 유지하면서 내부 구조를 조금씩 바꿉니다. 변화 속도는 답답해 보일 수 있지만, 기존 테스트와 운영 데이터, 사용자 피드백을 계속 활용할 수 있습니다. 특히 AI가 생성한 코드의 품질이 고르지 않을 때는 전체를 한 번에 교체하는 것보다 경계가 분명한 모듈부터 개선하는 편이 오류 원인을 추적하기 쉽습니다.

• 재작성 우세: 핵심 기술이 지원 종료됐거나 현재 구조로 필수 기능을 구현할 수 없을 때
• 리팩터링 우세: 서비스가 운영 중이고 숨은 업무 규칙이 많으며 자동화 테스트를 추가할 수 있을 때
• 판단 보류: 불편하다는 인상만 있고 장애 빈도나 변경 시간을 측정하지 않았을 때

코드가 지저분하다는 평가는 재작성 근거가 아닙니다. 현재 구조 때문에 기능 하나를 추가하는 데 실제로 얼마나 더 오래 걸리는지부터 측정해야 합니다.

개발 속도 대결은 첫 커밋이 아니라 운영 투입까지 봅니다

재작성은 초반에 빠르고 후반에 느려지기 쉽습니다

빈 저장소에서 AI 코딩을 시작하면 화면과 API가 놀라운 속도로 만들어집니다. 이 때문에 재작성 쪽이 압도적으로 빠르다고 느끼기 쉽습니다. 그러나 첫 화면이 실행되는 시점과 기존 서비스를 대체할 수 있는 시점은 전혀 다릅니다. 데이터 이전, 권한 검증, 외부 연동, 배포 설정, 장애 대응 절차까지 갖춰야 비로소 운영 가능한 결과가 됩니다.

예를 들어 주문 관리 서비스를 다시 만든다고 가정해 보겠습니다. 상품 조회와 주문 등록은 며칠 안에 구현할 수 있지만, 부분 취소 후 쿠폰 복원, 중복 결제 방지, 배송사 응답 지연 처리까지 재현하려면 오래 걸립니다. AI는 알려 준 요구사항을 빠르게 구현하지만, 명세에 없는 기존 동작까지 자동으로 발견하지는 못합니다.

리팩터링은 작은 승리를 운영에 바로 반영할 수 있습니다

리팩터링은 작업 범위를 작게 나눌 수 있다는 장점이 있습니다. 느린 조회 쿼리만 교체하거나, 결제 모듈의 중복 검증을 하나의 함수로 모으거나, 타입이 불분명한 영역부터 스키마를 추가할 수 있습니다. 각 변경을 배포한 뒤 오류율과 처리 시간을 확인하면 다음 작업의 우선순위도 명확해집니다.

속도를 비교할 때는 개발자가 코드를 입력한 시간만 계산하면 안 됩니다. 코드 리뷰, 테스트 보완, 데이터 마이그레이션, 사용자 문의 대응까지 포함한 운영 투입 소요 시간을 비교해야 합니다. 아래 순서로 두 선택지의 예상 일정을 적어 보면 막연한 낙관을 줄일 수 있습니다.

1. 현재 기능을 사용자 흐름 단위로 나누고 실제 사용 빈도를 기록합니다.
2. 각 기능의 구현 시간뿐 아니라 테스트와 데이터 이전 시간을 따로 추정합니다.
3. 외부 API, 인증, 결제처럼 실패 영향이 큰 연동 항목을 표시합니다.
4. 재작성과 리팩터링 각각에 장애 대응 및 되돌리기 시간을 더합니다.
5. 첫 배포가 아니라 기존 버전을 완전히 대체하는 날짜를 비교합니다.

코드 품질보다 먼저 겨뤄야 할 것은 검증 가능성입니다

새 구조의 아름다움과 동작의 신뢰성은 별개입니다

재작성된 코드는 파일 이름이 일관되고 의존성도 적어 품질이 좋아 보입니다. 하지만 읽기 좋은 코드와 검증된 코드는 같은 말이 아닙니다. 기존 시스템에는 수년간의 장애 수정과 사용자 요청이 축적되어 있는 반면, 새 코드는 아직 현실의 예외 상황을 충분히 만나지 않았습니다.

리팩터링은 기존 동작을 기준점으로 삼을 수 있습니다. 변경 전후에 같은 입력을 넣어 결과를 비교하는 특성 테스트를 만들고, 문제가 생기면 작은 커밋만 되돌릴 수 있습니다. AI 코딩 에이전트에는 “구조를 개선해 줘”라고 넓게 요청하기보다 “공개 함수의 입력과 출력은 유지하고 중복된 검증 로직만 추출하라”처럼 불변 조건을 제시하는 것이 효과적입니다.

보안은 재작성만으로 초기화되지 않습니다

낡은 코드에 취약점이 많다는 이유로 재작성을 선택하기도 합니다. 그러나 새 코드에서도 인증 누락, 과도한 권한, 비밀키 노출, 의존성 취약점은 다시 생길 수 있습니다. 먼저 코드 보안의 기본 개념을 확인하고, 취약점의 원인이 개별 구현인지 전체 아키텍처인지 구분해야 합니다.

보안 개선이 목적이라면 두 방식 모두 동일한 통과 기준을 적용해야 공정합니다. 정적 분석 결과만 비교하지 말고 접근 제어 테스트, 의존성 검사, 비밀정보 탐지, 감사 로그의 완전성을 함께 확인해야 합니다. 관련 개념을 짧게 훑을 때는 코드 보안 요약 자료도 판단 기준을 잡는 데 활용할 수 있습니다.

• 공개 API의 요청·응답 계약이 변경 전후 동일한지 검사합니다.
• 권한별 허용 및 거부 시나리오를 자동화 테스트로 고정합니다.
• AI가 추가한 패키지의 필요성과 유지관리 상태를 검토합니다.
• 로그에 토큰, 개인정보, 내부 프롬프트가 기록되지 않는지 확인합니다.
• 실패 시 이전 버전으로 되돌리는 절차를 실제 환경과 유사하게 연습합니다.

재작성은 기술 부채를 없애는 버튼이 아니라 기술 부채의 형태를 바꾸는 프로젝트입니다. 검증 장치가 없으면 오래된 위험 대신 발견되지 않은 새 위험을 갖게 됩니다.

비용 대결에서는 개발비 밖의 숫자까지 계산해야 합니다

재작성 비용은 두 시스템을 함께 운영할 때 커집니다

AI가 코드를 빠르게 생성하니 재작성 비용도 크게 낮아질 것이라고 기대할 수 있습니다. 실제로 반복적인 화면, 기본 API, 테스트 초안의 제작 시간은 줄어듭니다. 하지만 요구사항 조사와 데이터 검증, 사용자 교육, 병행 운영은 생성 속도만으로 단축하기 어렵습니다. 새 시스템이 안정될 때까지 구형 시스템도 유지해야 한다면 인프라와 모니터링, 당직 부담이 이중으로 발생합니다.

또한 재작성 중에도 기존 서비스에는 기능 요청과 버그 수정이 들어옵니다. 한 팀이 두 코드베이스를 동시에 수정하면 동일 기능을 두 번 구현하게 되고, 새 버전 출시일은 계속 밀릴 수 있습니다. 재작성 예산을 잡을 때 개발 인건비만 넣으면 이 병행 운영 비용이 빠져 의사결정이 왜곡됩니다.

리팩터링 비용은 범위를 통제할수록 예측하기 쉽습니다

리팩터링도 싸기만 한 방법은 아닙니다. 테스트가 거의 없는 거대한 함수, 강하게 결합된 데이터베이스, 담당자가 사라진 외부 연동을 건드리면 작은 변경에도 조사 시간이 길어집니다. 다만 한 번에 하나의 경계를 개선하고 예산 상한을 정하면, 효과가 낮은 작업을 중단하거나 다음 분기로 넘기기 쉽습니다.

가격을 비교할 때는 금액 대신 팀의 작업일을 기준으로 먼저 계산해 보세요. 예를 들어 월간 장애 대응 6일, 신규 기능 개발 12일, 코드 이해와 리뷰 5일이 든다면 리팩터링으로 어느 항목을 몇 일 줄일 수 있는지 적습니다. 재작성도 같은 방식으로 데이터 이전과 교육, 병행 운영에 필요한 작업일을 포함합니다.

숫자가 애매하다면 두 주짜리 실험을 먼저 진행할 수 있습니다. 장애가 잦은 모듈 하나를 골라 테스트를 만들고 AI와 함께 리팩터링한 뒤, 변경 시간과 결함 수를 기록합니다. 같은 기간에 해당 모듈의 재작성 견적도 산출하면 추측이 아니라 팀의 실제 생산성으로 두 전략을 비교할 수 있습니다.

• 반드시 포함할 비용: 요구사항 발굴, 테스트 데이터 제작, 교육, 문서화, 모니터링
• 자주 빠지는 비용: 이중 유지보수, 외부 파트너 검수, 이전 실패 후 복구
• 효과 측정 지표: 배포 빈도, 변경 리드타임, 장애 복구 시간, 회귀 결함 수

“그럼 언제는 정말 다시 만들어야 하나요?”에 답하는 법

세 가지 조건이 겹칠 때 재작성의 설득력이 생깁니다

독자가 가장 자주 묻는 질문은 결국 이것입니다. 리팩터링이 기본 선택이라면 전체 재작성은 언제 필요할까요? 단순히 코드가 오래됐거나 개발자가 싫어한다는 이유로는 부족합니다. 현재 구조가 사업 목표를 실제로 막고 있고, 필요한 동작을 명세와 테스트로 복원할 수 있으며, 전환 실패를 감당할 계획까지 있을 때 재작성의 설득력이 생깁니다.

첫 번째 조건은 구조적 한계입니다. 예를 들어 사용 중인 런타임이 더 이상 보안 업데이트를 받지 못하고 업그레이드 경로도 없거나, 단일 고객용으로 설계된 데이터 구조가 다중 조직 격리를 구현할 수 없는 상황입니다. 성능 문제도 쿼리 최적화나 캐시로 해결할 수 있는 수준이 아니라 핵심 처리 모델 자체를 바꿔야 한다면 재작성을 검토할 수 있습니다.

두 번째 조건은 복원 가능한 명세입니다. 화면 목록만 정리한 문서로는 부족하며, 입력 조건과 권한, 실패 처리, 데이터 보존 규칙까지 설명할 수 있어야 합니다. 운영 로그와 고객 문의를 분석하고 핵심 시나리오에 회귀 테스트를 만들지 못한다면, 새 시스템도 같은 혼란을 반복할 가능성이 큽니다.

전면 교체 대신 병렬 구축으로 위험을 잘라냅니다

재작성이 필요하다고 판단해도 어느 날 전체 시스템을 한꺼번에 바꿀 필요는 없습니다. 기존 시스템 앞에 안정적인 인터페이스를 두고, 기능 하나씩 새 구현으로 연결하는 방식이 현실적입니다. 먼저 조회처럼 되돌리기 쉬운 기능을 옮기고, 이후 쓰기 기능과 결제처럼 실패 영향이 큰 영역으로 확장합니다.

사용자 일부에게만 새 경로를 열어 오류율과 응답 시간을 비교하면 AI가 만든 구현의 장점과 결함을 운영 환경에서 확인할 수 있습니다. 데이터 쓰기는 일정 기간 양쪽 결과를 대조하되, 어느 시스템을 최종 원본으로 삼을지 명확히 정해야 합니다. 그렇지 않으면 동기화 오류가 발생했을 때 무엇이 맞는 데이터인지 판단하기 어렵습니다.

1. 재작성 사유를 “코드가 복잡함”이 아니라 측정 가능한 제약으로 작성합니다.
2. 기존 기능 중 반드시 보존할 동작과 과감히 폐기할 동작을 구분합니다.
3. 새 시스템이 통과해야 할 기능·성능·보안 기준을 먼저 자동화합니다.
4. 사용자와 데이터의 일부만 이동할 수 있는 전환 경계를 설계합니다.
5. 오류율이나 데이터 불일치가 기준을 넘으면 자동 또는 수동으로 복귀시킵니다.
6. 새 경로가 안정된 뒤에만 다음 기능을 옮기고, 마지막에 기존 코드를 종료합니다.

따라서 답은 “절대 다시 만들지 말라”가 아닙니다. 재작성만이 해결할 수 있는 제약을 증명하고, 기존 동작을 검증할 장치를 확보한 뒤, 되돌릴 수 있는 크기로 나누라는 것입니다. 이 조건을 충족하지 못했다면 전체 삭제 버튼보다 테스트 하나와 작은 리팩터링 커밋이 프로젝트를 더 멀리 전진시킵니다.