바이브 코딩 리팩터링 완전 정리

리팩터링의 정의는 외부 동작을 바꾸지 않고 내부 구조만 바꾸는 것입니다. 그런데 모델에게는 '바꾸지 않았다'를 확인할 수단이 없습니다. 요청을 받으면 읽기 좋은 코드를 새로 써낼 뿐이고, 그 과정에서 널 처리 하나, 예외를 삼키던 catch 한 줄이 조용히 사라져도 결과물은 오히려 더 깔끔해 보입니다. 초보자의 모델이 깨지는 지점이 여기입니다. 출력이 단정하다는 사실과 동작이 같다는 사실 사이에는 아무 관계가 없습니다. 게다가 범위가 넓을수록 이해하지 못한 부분을 일반적인 상식으로 채우기 때문에, 규약이 독특한 코드일수록 그 보정이 그대로 버그가 됩니다.

그래서 순서를 뒤집어 읽는 편이 낫습니다. 레거시 코드 이해에 AI 활용으로 현재 코드가 무엇을 하는지 먼저 말로 복원하고, 코드 냄새(Code Smell)를 AI가 찾아주도록 요청하라로 손댈 후보를 모은 다음, 점진적 리팩터링 계획을 AI와 함께 수립하라에서 그 후보들을 커밋 단위로 쪼갭니다. 긴 메서드 분리 리팩터링을 단계별로 요청하라와 전략 패턴으로 분기문을 리팩터링 요청하라는 그 계획의 개별 단계를 어떻게 주문하는지 보여주는 실행편입니다. 이 순서를 지키면 되돌릴 지점이 언제나 한두 커밋 안쪽에 남습니다.

가장 조용히 터지는 것은 동기 코드를 비동기로 옮길 때입니다. 함수 시그니처에 suspend나 async를 붙이는 기계적인 변환은 잘 해내지만, 안쪽에 남은 블로킹 호출 하나가 스레드 풀을 그대로 잡아먹습니다. 트랜잭션 경계와 ThreadLocal에 얹혀 있던 컨텍스트도 함께 무너지고, 취소와 예외가 전파되는 경로도 달라집니다. 이런 결함은 단위 테스트에서는 거의 보이지 않고 동시 요청이 몰리는 운영 환경에서만 드러난다는 점이 특히 고약합니다.