바이브 코딩에서는 언제 갈아엎고 언제 유지보수할까: 내가 정한 의사결정 기준

바이브 코딩을 하다 보면 한 번은 반드시 이 질문이 온다. “고쳐서 갈까, 그냥 새로 만들까?”

나도 초반에는 무조건 고치려고 했다. 하지만 요구사항이 크게 변하는 초기 단계에서는 수정이 누적될수록 구조가 무너지고 판단 속도도 느려졌다.

내 경험: 유지보수가 더 비싼 순간이 분명히 있다

특히 아래 조건이 겹치면 유지보수보다 리라이트가 더 싸게 끝났다.

• 도메인 규칙이 바뀌어 핵심 상태 모델 자체가 달라진 경우
• 기존 코드의 의도/경계 문서가 거의 없는 경우
• 에이전트가 여러 차례 패치하며 계층 규칙이 깨진 경우

이때 부분 수정을 계속하면 “어제 붙인 패치가 오늘 버그의 원인"이 되는 루프가 생겼다.

참고: Martin Fowler는 AI 코딩에서 생성 속도와 유지보수 비용을 분리해서 보지 않으면 후반에 크게 지불하게 된다고 지적한다. Spec-Driven Development: Tools

내가 쓰는 판단 프레임

지금은 감으로 결정하지 않고, 아래 5개 질문으로 결정한다.

1. 핵심 상태 모델이 그대로 유지되는가
2. 기존 테스트가 변경 이후에도 의미가 있는가
3. 모듈 경계를 지키면서 수정 가능한가
4. 수정 범위가 전체의 30%를 넘는가
5. 2주 내 재수정 확률이 높은가

결정 규칙은 단순하다.

• 1~3이 모두 예면 유지보수
• 4 또는 5가 예면 리라이트 우선 검토

참고: Fred Brooks의 관점처럼 본질적 복잡성은 단일 기법으로 사라지지 않기 때문에, “조금만 더 고치면 된다"는 낙관은 자주 틀린다. No Silver Bullet (1986)

리라이트를 선택할 때 지키는 원칙

• 이전 실패 원인을 문서로 고정한 뒤 시작한다.
• 데이터/권한/결제 같은 핵심 경계는 먼저 테스트로 잠근다.
• 새 코드는 “더 깔끔하게"가 아니라 “더 설명 가능하게"를 목표로 한다.

리라이트는 새 출발이 아니라 실패의 원인을 코드화하는 과정이어야 했다.

참고: Google SRE 관점에서도 운영 경계(SLI/SLO)를 유지하지 못하는 변경은 기능 확장이 아니라 신뢰 훼손으로 귀결된다. Implementing SLOs

정리

초기 스타트업에서 리라이트는 실패가 아니라 전략일 수 있다. 다만 “기분 전환용 재개발"과 “구조적 리셋"은 다르다.

나는 이제 이렇게 정의한다.

• 유지보수: 기존 의도를 보존하며 개선하는 일
• 리라이트: 의도 자체가 바뀌었을 때 새 경계를 세우는 일

바이브 코딩 시대일수록, 코드를 얼마나 빨리 쓰는지보다 언제 버리고 다시 설계할지 결정하는 능력이 더 중요했다.