AI 코딩으로 가장 힘든 순간은 처음 만드는 때가 아니라 수정을 반복한 뒤입니다. 처음에는 단순했던 코드가 여러 차례 “이 오류 고쳐줘”, “이 기능도 추가해줘”를 거치면서 같은 기능이 두 번 구현되고, API 주소가 여러 파일에 흩어지고, 한 부분을 고치면 다른 기능이 깨지기 시작합니다.
이 상태가 되면 극단적인 선택을 하게 됩니다. “전부 새로 만들자.” 하지만 실제로는 전부 버릴 필요도 없고, 반대로 억지로 살려야 하는 것도 아닙니다. 중요한 것은 코드를 파일 기준이 아니라 기능과 책임 기준으로 진단하는 것입니다.
먼저 해야 할 일: 수정 금지
코드가 꼬였다고 느껴질 때 가장 먼저 해야 할 일은 AI에게 계속 고치게 하는 것이 아닙니다. 현재 상태를 고정해야 합니다.
- 지금 실행되는 코드를 Git에 커밋합니다.
- 별도
rescue브랜치를 만듭니다. - 실행 방법을 기록합니다.
- 현재 되는 기능과 안 되는 기능을 표로 만듭니다.
이 상태를 만들지 않으면 진단하는 동안에도 코드가 계속 변합니다.
1단계. 파일이 아니라 사용자 흐름을 기준으로 목록화
예를 들어 예약 서비스라면 이렇게 적습니다.
- 회원가입
- 로그인
- 클래스 목록 보기
- 날짜 선택
- 예약 생성
- 결제
- 내 예약 보기
- 관리자 예약 확인
- 환불
각 기능을 정상 / 불안정 / 미구현으로 분류합니다.
이 표가 코드 분석보다 먼저입니다. 이유는 목적이 “예쁜 아키텍처”가 아니라 “런칭 가능한 서비스”이기 때문입니다.
2단계. 살릴 가능성이 높은 영역
대체로 다음은 재사용 가치가 높습니다.
화면 UI
이미 사용자 흐름이 잡혀 있고 컴포넌트 구조가 크게 깨지지 않았다면 살릴 수 있습니다. 화면은 재작성 비용이 높고, 비즈니스 로직과 분리되어 있다면 구조 개선도 쉽습니다.
콘텐츠와 디자인 자산
이미지, 카피, 아이콘, 디자인 토큰은 코드 품질과 무관하게 재사용 가능합니다.
독립적인 API 래퍼
외부 API 호출이 한 파일에 잘 모여 있다면 재사용할 수 있습니다.
데이터 모델 중 실제 업무와 맞는 부분
테이블 설계가 완벽하지 않아도 사용자, 주문, 예약처럼 핵심 개념이 맞으면 migration으로 개선할 수 있습니다.
3단계. 다시 만드는 편이 나은 신호
다음 신호가 여러 개 겹치면 특정 영역은 재작성하는 것이 빠를 수 있습니다.
- 같은 기능을 하는 함수가 여러 개 존재
- 파일 하나에 UI, DB, API 호출이 모두 섞임
- 데이터가 LocalStorage와 DB에 동시에 저장
- API 호출 URL이 화면 컴포넌트 곳곳에 하드코딩
- 인증 상태가 여러 방식으로 관리됨
- 테스트용 코드가 운영 흐름에 남아 있음
- 한 파일을 고치면 관련 없는 화면이 깨짐
- AI가 만든 주석과 임시 코드가 계속 누적
중요한 것은 “프로젝트 전체 재작성”이 아니라 문제가 집중된 레이어만 다시 만드는 것입니다.
4단계. 가장 먼저 정상화할 경계 4개
Auth 경계
누가 로그인되어 있는지 판단하는 방식을 하나로 통일합니다.
Data 경계
데이터를 읽고 쓰는 코드를 한 계층으로 모읍니다. 화면이 DB에 직접 접근하는 구조는 변경에 취약합니다.
API 경계
외부 AI, 결제, 이메일 API 호출을 별도 모듈로 분리합니다.
Environment 경계
개발/운영 설정과 Secret을 코드에서 분리합니다.
이 네 경계만 정리해도 “AI가 한 파일을 고쳤는데 서비스 전체가 흔들리는” 문제가 크게 줄어듭니다.
5단계. 기능마다 ‘완료 조건’을 만든다
“로그인 완료”는 버튼이 눌리는 것이 아닙니다.
완료 조건 예:
- 신규 사용자 가입 성공
- 잘못된 비밀번호 오류 표시
- 로그인 후 새로고침해도 상태 유지
- 로그아웃 후 보호 페이지 접근 차단
- 탈퇴 계정 로그인 차단
이렇게 테스트 가능한 문장으로 완료를 정의해야 AI에게도 정확한 작업을 요청할 수 있습니다.
6단계. AI에게 리팩터링을 맡길 때 프롬프트 구조
나쁜 요청:
코드가 너무 꼬였어. 전체 정리해줘.
좋은 요청:
현재 기능은 최대한 유지한다. 이번 작업에서는 인증 구조만 정리한다. UI와 DB schema는 변경하지 않는다. 먼저 현재 인증 관련 파일과 흐름을 목록화하고 중복 구현을 찾아라. 변경 계획을 제안한 뒤 내가 승인하기 전에는 코드를 수정하지 마. 수정 후에는 로그인, 로그아웃, 보호 페이지 접근 테스트 결과를 보고해라.
핵심은 분석 → 계획 → 승인 → 수정 → 테스트 순서를 강제하는 것입니다.
7단계. 새로 만들지 말아야 할 때
코드가 마음에 들지 않는다는 이유만으로 새로 만들면 안 됩니다.
다음 조건이면 기존 것을 살리는 편이 낫습니다.
- 실제 사용자 데이터가 이미 있음
- 핵심 기능의 70% 이상 정상 동작
- UI 자산과 비즈니스 로직이 상당 부분 검증됨
- 문제 영역이 특정 기능에 집중됨
- 일정이 촉박함
반대로 전체 재설계를 고려할 때
- 데이터 모델이 실제 서비스 개념과 완전히 다름
- 인증/권한이 보안상 위험한 방식
- 기술 스택이 유지보수 불가능한 수준으로 혼합됨
- 핵심 기능조차 테스트 가능한 단위가 없음
- 운영 데이터 migration보다 재구축이 더 단순함
그래도 UI와 콘텐츠, 요구사항까지 버리는 것은 아닙니다. 제품 지식은 그대로 살리고 구현만 바꾸는 것이 재설계입니다.
Rescue Sprint 예시
Day 1 — 동결과 진단
- Git snapshot
- 기능 목록
- 정상/불안정/미구현 분류
- 운영에 꼭 필요한 1차 범위 결정
Day 2~3 — 경계 정리
- Auth 통합
- API/DB 접근 정리
- 환경변수 분리
Day 4~5 — 핵심 흐름 복구
- 회원 → 핵심 기능 → 결과 저장
- 관리자 확인
Week 2 — 운영화
- 배포
- 로그
- 백업
- 결제/외부 연동
- 회귀 테스트
정리
AI 코드가 꼬였을 때 중요한 것은 “코드 품질을 완벽하게 만드는 것”이 아닙니다. 사용자가 돈을 내고 써도 되는 핵심 경로를 안정화하는 것입니다.
버릴지 살릴지 결정할 때는 코드가 예쁜지가 아니라 다음 세 가지를 보세요.
- 핵심 기능이 동작하는가
- 변경 영향 범위를 통제할 수 있는가
- 운영과 복구가 가능한가
완주 관점의 핵심: 모든 것을 고치는 것이 아니라 런칭에 필요한 것만 정상화합니다.