리팩터링

리팩터링은 집을 예로 들면 이해가 쉬워요. 가족이 쓰는 방 배치나 현관문 위치(앱이 하는 일)는 하나도 안 바꾸고, 어질러진 창고와 뒤엉킨 전선만 깔끔하게 정리하는 거예요. 겉에서 보는 사람은 아무 변화도 못 느끼지만, 안에서 뭔가를 고치거나 새로 지어야 할 때는 훨씬 수월해지죠.

AI가 코드를 대신 짜주는 도구를 쓰다 보면 처음엔 잘 되다가 어느 순간부터 작은 수정 하나에도 다른 기능이 깨지고, 답이 늦게 나오는 경험을 하게 돼요. 이건 AI의 실력이 떨어진 게 아니라, 코드가 쌓이면서 창고처럼 어질러진 신호일 수 있어요. 정리되지 않은 코드 안에서는 AI도 어디에 뭐가 있는지 파악하느라 더 많은 시간과 자원을 쓰고, 실수할 확률도 올라가거든요. 그래서 기능을 하나 완성할 때마다 창고 정리하듯 코드를 다듬어두는 습관이 중요해요.

코딩 에이전트 Bolt는 앱이 자꾸 오작동하거나 느려지는 원인이 에이전트 탓이 아니라 코드베이스가 지저분해진 데 있다고 짚으며, 코드를 고치기 전 먼저 문제를 진단하고 계획부터 받는 리팩터링 프롬프트를 공개했어요. 흔히 오해하듯 리팩터링은 기능을 추가하거나 버그를 고치는 작업이 아니에요 — 화면과 동작은 그대로 두고 내부 구조만 정리하는 게 핵심이에요.

쓰고 있는 코딩 에이전트에게 이렇게 요청해보세요.

"이 프로젝트를 더 깔끔하고 유지보수하기 쉽게 리팩터링하고 싶어. 코드를 고치기 전에 먼저 코드베이스를 점검하고 계획부터 알려줘. 너무 길거나 여러 일을 한꺼번에 하는 파일, 여러 곳에 중복된 로직, 이름이 헷갈리는 부분, 아무도 쓰지 않는 죽은 코드를 찾아서 각각 어떻게 바꿀지와 위험도를 알려줘. 아직 코드는 건드리지 말고, 기능 추가나 다른 버그 수정도 하지 마. 우선순위가 매겨진 계획만 줘서 내가 승인한 뒤에 진행하자."

계획을 받은 뒤 위험도가 낮은 항목부터 하나씩 승인하며 진행하면 앱이 갑자기 망가질 걱정을 줄일 수 있어요.