Bolt, AI 코딩 에이전트용 리팩터링 프롬프트 공개

리팩터링은 앱이 하는 일을 그대로 둔 채 그 밑에 깔린 코드만 정리하는 작업이에요. 버튼도 그대로고 동작도 그대로인데, 코드 구조만 깔끔해지는 거죠. Bolt는 영상에서 에이전트가 느려지거나 실수를 늘리는 가장 큰 원인 중 하나가 에이전트 탓이 아니라 코드가 지저분해졌다는 신호라고 설명했어요. 정리되지 않은 코드베이스에서는 에이전트가 맥락을 파악하는 데 더 많은 토큰을 쓰고, 그만큼 오답 확률도 올라간다는 논리예요.

영상에는 OpenClaw 창업자 Peter Steinberger의 습관도 소개됐어요. 그는 기능 하나를 병합할 때마다 다음엔 뭘 리팩터링할 수 있을지 스스로 묻는다고 말했는데, 영상에서 공개된 발언에 따르면 이 습관을 건너뛰면 결국 "you'll slop yourself into a corner(스스로 코드를 구석으로 몰아넣게 된다)"고 경고했어요.

1단계: 코드를 건드리기 전에 먼저 감사하고 계획을 받는다

Bolt가 공개한 첫 번째 프롬프트는 코드를 고치기 전에 먼저 에이전트에게 진단부터 시키는 용도예요. 원문은 이래요.

"I want to refactor this project to make it cleaner and easier to maintain. Before changing any code, audit the code base and give me a plan. Look for the things that most hurt maintainability: files that are too long or doing too many unrelated things, the same logic duplicated in more than one place, components that mix data fetching, business logic, and UI, unclear or misleading names, dead code that nothing uses. For each, say what you would do to change it and how risky that change is. Do not change any code yet, do not add any features, fix unrelated bugs, or change how the app behaves. Just give me a prioritized plan so I can approve it before we touch anything."

한국어로 옮기면 이런 내용이에요 — 프로젝트를 더 깔끔하고 유지보수하기 쉽게 리팩터링하고 싶으니, 코드를 고치기 전에 코드베이스부터 감사하고 계획을 달라는 요청이에요. 너무 길거나 여러 일을 한꺼번에 하는 파일, 여러 곳에 중복된 로직, 데이터 조회와 비즈니스 로직과 화면(UI)이 뒤섞인 컴포넌트, 이름이 헷갈리는 부분, 아무도 쓰지 않는 죽은 코드를 찾아 각각 어떻게 바꿀지와 위험도를 알려달라고 지시해요. 그리고 코드는 아직 건드리지 말고, 기능 추가나 무관한 버그 수정, 동작 변경도 하지 말라고 못박아요. 승인할 수 있게 우선순위가 매겨진 계획만 먼저 달라는 거예요.

2단계: 계획을 한 걸음씩만 실행한다

에이전트가 개선점 목록을 내놓으면, 그걸 한꺼번에 실행하지 말라는 게 이 튜토리얼의 핵심 조언이에요. 코드베이스가 클수록 여러 리팩터링을 동시에 진행하면 위험이 커지기 때문에, Bolt는 계획의 첫 항목만 골라 다음 프롬프트로 실행하라고 안내해요.

"Refactor the first step from the plan. Rules: do not change any behavior. The app must look and work the exact same afterwards. Do not add features or fix unrelated bugs while you're in here. Only touch the files needed for this change. Keep the existing interface the same so nothing else breaks. When you're done, give me a short summary of what changed and confirm the app still behaves identically."

번역하면 — 계획의 첫 단계만 리팩터링하고, 동작은 하나도 바꾸지 말고, 앱은 이후에도 똑같이 보이고 똑같이 작동해야 하며, 이 변경에 필요한 파일만 건드리고, 기존 인터페이스를 그대로 유지하라는 규칙이에요. 끝나면 무엇이 바뀌었는지 짧게 요약하고 앱이 여전히 동일하게 작동하는지 확인해달라고 요청해요.

실제 적용해 보니: 두 프로젝트에서 나온 결과

프로젝트	가장 문제였던 컴포넌트	에이전트가 짚은 문제	첫 실행 대상
내부 리크루팅 파이프라인 툴	App 컴포넌트	앱 전체 상태·CRUD·필터링·레이아웃 렌더링을 한 파일이 전부 처리	데이터베이스 접근 로직을 별도 파일로 분리
회의 요약·후속조치 툴	Customer Call Card	1,200줄이 넘는 파일에 하위 컴포넌트 7개, API 호출과 화면 로직이 혼재, 중복 함수·중복 토글 존재	Customer Call Card부터 우선 리팩터링

두 사례 모두 감사 프롬프트가 문제 부위를 구체적으로 짚어낸 뒤, 실행 프롬프트가 그중 딱 한 항목만 손댔어요. 리크루팅 툴에서는 데이터베이스 쿼리 5개를 별도 파일의 비동기 함수로 옮기는 작업이 저위험으로 분류돼 곧바로 실행됐고, 회의 요약 툴에서는 1,200줄짜리 컴포넌트 하나를 쪼개는 작업이 중간 위험으로 분류됐어요.

두 프롬프트를 관통하는 공통 뼈대

공통 요소	프롬프트에 담긴 표현
코드 변경보다 진단이 먼저	"코드를 고치기 전에 먼저 감사하고 계획을 달라"
동작은 절대 바뀌지 않는다	"동작을 하나도 바꾸지 말라", "앱은 이전과 똑같이 작동해야 한다"
한 번에 한 단계만	"계획의 첫 단계만 리팩터링하라"
완료 후 자가 확인	"무엇이 바뀌었는지 요약하고 동일하게 작동하는지 확인하라"

네 요소를 빼면 프롬프트가 흔들려요. 진단 단계를 생략하면 에이전트가 어디를 고쳐야 할지 스스로 정하게 되고, 동작 불변 원칙을 빼면 리팩터링 도중 기능이 슬쩍 바뀔 위험이 생기죠. 한 단계씩 진행하라는 지시를 지우면 이 튜토리얼이 애초에 경고했던 '한꺼번에 여러 곳을 고치다 생기는 위험'이 그대로 재현돼요.

그대로 따라 해보는 법

1. 새로운 대화를 시작해 컨텍스트를 비워요. 튜토리얼은 이 과정을 활주로 시작점에서 이륙하는 것에 비유했어요 — 리팩터링처럼 큰 작업을 시작할 때는 컨텍스트 창을 최대한 남겨둬야 한다는 뜻이에요.
2. plan 모드(실행 전 검토 모드)로 전환하고 1단계 감사 프롬프트를 그대로 붙여넣어요.
3. 에이전트가 내놓은 우선순위 목록을 확인해요. 위험도가 낮다고 표시된 항목은 바로 진행해도 되지만, 위험도가 높은 항목은 에이전트에게 로직을 더 설명해달라고 되묻는 편이 안전해요.
4. 모드를 실행 모드로 바꾸고, 2단계 프롬프트로 계획의 첫 번째 항목을 지정해 리팩터링을 맡겨요.
5. 결과가 어긋나면 — 빌드가 깨지거나 동작이 달라지면 — 가장 먼저 확인할 곳은 프롬프트가 건드려도 된다고 허락한 파일 범위예요. 그 범위를 벗어난 파일이 바뀌었는지부터 봐요.
6. 다른 프로젝트에 옮길 때는 프롬프트 문구를 그대로 두고 "이 프로젝트"라는 표현만 실제 프로젝트로 바꾸면 돼요. 동작 불변·한 단계씩·완료 후 요약이라는 규칙 문장은 그대로 유지하는 편이 안전해요.

에디터의 시선

바이브 코딩 도구가 늘어나면서 '에이전트가 점점 멍청해진다'는 불만도 함께 늘고 있어요. 그런데 이번 튜토리얼이 짚은 지점은 방향이 달라요. 에이전트가 느려지는 원인을 모델 성능이 아니라 코드베이스에 쌓인 부채에서 찾은 거예요. 사람이 짠 코드에서도 오래전부터 통하던 원칙인데, AI 에이전트 시대라고 예외가 아니라는 걸 Bolt가 다시 확인해준 셈이에요.

실무에 붙여 보면 이 순서가 왜 중요한지 체감이 와요. 감사 프롬프트 없이 곧바로 코드를 정리해달라고만 시키면, 에이전트는 눈에 보이는 대로 손을 대다가 기능까지 슬쩍 바꿔버리는 경우가 생겨요. 반대로 감사→승인→한 단계 실행이라는 순서를 지키면, 리뷰할 사람이 이 변경이 정말 안전한지 판단할 지점이 매 단계마다 생겨요. 사람 개발자에게 받던 코드 리뷰 습관을 에이전트에게도 그대로 옮긴 셈이죠.

국내에서 바이브 코딩 도구로 사이드 프로젝트나 사내 도구를 만드는 팀이라면, 기능을 다 얹은 다음에야 코드가 느려졌다고 느끼는 시점이 반드시 와요. 그 시점에 새 기능부터 더 얹기보다, 이번에 공개된 두 프롬프트로 감사 한 번을 먼저 돌려보는 편이 비용이 적게 들어요. 특히 파일 하나가 500줄을 넘거나 같은 로직이 두 곳 이상에 복사돼 있다면 리팩터링 우선순위 후보로 봐도 될 정도예요.

앞으로 몇 주 안에 다른 코딩 에이전트 업체들도 비슷한 '진단 우선' 프롬프트 가이드를 자체 튜토리얼로 내놓을 가능성이 높아요. 에이전트 성능 경쟁이 벤치마크 점수 다음 단계로 넘어가면서, 에이전트를 어떻게 잘 부리는가를 알려주는 사용법 콘텐츠 자체가 하나의 경쟁 포인트가 되고 있어요.