코드 수정 판단: 고칠까 새로 만들까

코드 수정 판단은 새 코드가 더 깔끔해 보이는지가 아니라 기존 동작과 데이터를 안전하게 지킬 수 있는지로 내려야 합니다.

연재 안내: 27편 전체 순서와 현재 공개된 글은 비개발자 바이브코딩 로드맵에서 확인할 수 있습니다.

현재 오류의 위치부터 좁혀야 한다면 코딩 오류 확인 순서를 먼저 적용하세요.

한 줄 답변

기존 코드가 지저분해 보여도 실제 사용 규칙과 예외 처리가 남아 있다면 작은 리팩토링이 대체로 안전합니다. 전면 재작성은 요구사항이 크게 바뀌었거나 현재 기술로 운영·보안 요구를 충족하기 어렵고, 기존 동작을 비교할 테스트와 전환 계획이 있을 때 선택해야 합니다.

새로 만들기가 매력적으로 보이는 이유

오래 수정한 코드는 이름이 어색하고 중복이 많아 보입니다. AI에게 “처음부터 깔끔하게 다시 만들어줘”라고 하면 몇 분 안에 정돈된 코드가 나옵니다. 눈에 보이는 오래된 버그도 사라질 수 있습니다.

하지만 기존 코드에는 문서에 적지 않은 업무 규칙이 숨어 있습니다. 특정 사용자 예외, 날짜 계산, 실패 복구, 실제 고객이 발견한 경계 상황이 전면 재작성과 함께 사라질 수 있습니다. 오래된 코드는 더럽기만 한 것이 아니라 운영 지식이 쌓인 기록이기도 합니다.

먼저 고쳐 쓰는 편이 좋은 경우

• 핵심 사용자 흐름이 현재 정상 동작한다.
• 문제 위치를 파일이나 함수 수준으로 좁힐 수 있다.
• 요구사항은 그대로이고 내부 구조만 불편하다.
• 수동 테스트나 실제 사용 기록이 남아 있다.
• 작은 변경을 커밋하고 되돌릴 수 있다.

이 경우에는 의미 없는 이름 바꾸기, 긴 함수 분리, 중복 규칙 통합처럼 작은 리팩토링부터 진행합니다. 한 번에 한 종류만 바꾸고 결과가 같다는 것을 확인합니다.

전면 재작성을 검토할 수 있는 경우

반대로 다음 조건이 여러 개 겹치면 새 구현을 검토할 수 있습니다.

• 사용자와 핵심 요구사항이 이전과 크게 달라졌다.
• 지원이 끝난 기술 때문에 중요한 보안 업데이트가 불가능하다.
• 데이터 구조가 새 요구를 수용하지 못하고 모든 기능이 우회 코드를 쓴다.
• 현재 시스템을 실행하거나 테스트할 방법이 사실상 없다.
• 작은 수정 비용이 반복적으로 새 구현 비용을 넘어선다.

그래도 기존 시스템을 즉시 삭제하지 않습니다. 새 버전을 별도 공간에서 만들고 같은 입력에 같은 결과가 나오는지 비교한 뒤, 데이터 이전과 롤백 계획을 준비합니다.

리팩토링과 기능 추가를 섞지 않는다

리팩토링은 외부 동작을 유지한 채 내부 구조를 정리하는 작업입니다. 구조를 고치면서 새 로그인 방식과 알림 기능까지 추가하면 실패 원인을 구분할 수 없습니다.

먼저 현재 동작을 테스트로 고정하고 구조만 정리합니다. 커밋과 검증이 끝난 다음 새 기능을 별도 작업으로 시작합니다. 버그 수정, 성능 개선, 기능 추가도 가능한 범위에서 구분합니다.

30분 판단표

마지막 두 질문에 답하지 못하면 전면 재작성을 시작하기 이릅니다.

안전한 점진 수정 순서

1. 핵심 사용자 흐름과 현재 결과를 기록한다.
2. 정상 상태를 Git 커밋으로 남긴다.
3. 가장 위험한 함수나 중복 한 곳만 고른다.
4. 구조만 수정하고 같은 테스트를 실행한다.
5. 변경 이유와 결과를 기록한 뒤 다음 위치로 이동한다.

작은 성공을 쌓으면 전체를 갈아엎지 않고도 구조를 개선할 수 있습니다.

AI에게 판단을 요청하는 방법

새 코드를 작성하기 전에 기존 시스템의 정상 기능, 숨은 업무 규칙, 문제 위치, 테스트 유무를 표로 정리해줘. 점진 수정과 전면 재작성의 비용·위험·데이터 이전·롤백 조건을 비교하고, 가장 작은 안전한 첫 작업을 제안해줘.

AI의 평가는 코드 정보가 충분할 때만 의미가 있습니다. 사업 일정, 고객 영향, 법적 책임은 작업자가 결정합니다. 어떤 선택을 하든 안전망은 테스트입니다.

작은 병행 실험으로 판단한다

논쟁만으로 결론이 나지 않으면 가장 위험한 기능 하나를 골라 두 가지 접근을 짧게 시험하세요. 기존 코드에서는 문제 함수를 작은 단계로 정리하고, 별도 브랜치에서는 같은 입력과 결과를 가진 최소 새 구현을 만듭니다. 정해진 시간 안에 구현 속도, 누락된 규칙, 테스트 통과, 데이터 이전 난이도를 비교합니다.

새 구현이 보기 좋다는 이유만으로 선택하지 않습니다. 기존 예외를 얼마나 재현했고 운영 중 전환과 롤백이 가능한지 봅니다. 반대로 기존 수정이 매번 예상 밖의 기능을 깨뜨린다면 의존성과 테스트 부족을 비용에 포함합니다. 작은 실험의 결과를 기록하면 감정이 아니라 증거로 결정할 수 있습니다.

코드 수정 판단 최종 점검

코드 수정 판단을 내리기 전 현재 기능의 정상 기준, 자동·수동 테스트, 데이터 이전 필요성, 외부 연동, 보안 제약을 표로 비교하세요. 코드 수정 판단에서 전면 재작성은 기존 규칙을 모두 다시 발견해야 하므로 코드가 낡았다는 이유만으로 선택하면 위험합니다.

작은 수정으로 문제를 고립할 수 있다면 먼저 그 경로를 택하고, 구조 개선은 동작을 유지한 채 단계적으로 진행하세요. 재작성이 필요하다면 기존 버전을 유지하면서 핵심 흐름 하나씩 결과를 대조하고 전환·복구 조건을 미리 정합니다.

수정이나 재작성 방향을 정했다면 다음 글 비개발자 앱 테스트: 시작 순서 5단계에서 핵심 흐름·완료 기준·정상 및 실패 데이터를 검증하는 순서를 확인하세요.

관련된 글:

바이브코딩, AI에게 맡길수록 왜 더 꼬일까 AI 코드 꼬임: 기능이 깨지는 이유 긴 함수 나누기: 초보자 3단계 기능 의존성: 수정하면 깨지는 이유