04. DRY 리팩터링
바이브 코딩의 절반은 리팩터링입니다 — 중복된 코드를 공용 컴포넌트로 모아 정돈하는 흐름을 익혀봅니다.
왜 "바이브 리팩터링"인가
새 기능을 빠르게 만들다 보면 AI는 기존 예시를 참고하면서 비슷한 코드를 여러 파일에 복제하는 경향이 있습니다. 그래서 전체 프롬프트 중 절반 정도가 리팩터링에 쓰이지 않는다면, 코드베이스가 점점 어지러워지고 있을 가능성이 큽니다. 이번 단계에서는 게임 안에 흩어져 있는 "E 키로 상호작용" 표시를 하나의 컴포넌트로 모아보면서, AI와 함께 정리하는 감각을 길러봅니다.
이전 단계 복습: 홈 화면을 HTML/CSS로 다듬고, 물리 엔진 버그를 잡고, 여러 파일에 걸친 상호작용 버그까지 손봤다면 이번 모듈을 진행할 준비가 끝난 상태입니다.
1단계 — 현재 구조 파악하기
리팩터링은 "지금 어디에 무엇이 있는지" 아는 것에서 출발합니다. Kiro에게 다음과 같이 물어보세요.
Where is the interact prompt implemented in the components?Kiro는 Computer.vue, Workbench.vue, Chest.vue, Garbage, GameItem, PullLever, Dispenser 등 여러 컴포넌트에 동일한 의도의 코드가 살짝씩 다른 모양으로 흩뿌려져 있음을 알려줍니다. 예를 들어 레버의 프롬프트 크기와 작업대의 프롬프트 크기가 미묘하게 다르다는 식입니다. 이런 차이가 바로 통합의 후보입니다.
2단계 — DRY 리팩터링 요청
"E" 표시가 들어 있는 파일 중 하나(예: Chest.vue)를 에디터에서 열어둔 상태로 다음 프롬프트를 실행합니다.
I want to DRY the "interact-prompt" into a separate component with standardized styles, reused across my components
열려 있는 파일이 곧 컨텍스트: Kiro는 현재 열려 있는 파일들을 우선적으로 참고합니다. 리팩터링 대상이 명확하다면, 관련 파일을 먼저 열어두는 것만으로도 결과 품질이 달라집니다.
3단계 — 결과 검증
Kiro는 "interact-prompt" 마크업을 가진 컴포넌트들을 찾아 한 곳에서 관리되는 공용 컴포넌트로 옮겨줍니다. 결과가 나오면 다음 항목을 직접 눈으로 확인합니다.
- 각 오브젝트별로 위/좌/우 등 위치 지정이 그대로 유지되었는가
- 두 가지 텍스트 크기 표현 중 어떤 방식이 표준으로 채택되었는가
- 게임을 실제로 플레이했을 때 모든 상호작용 표시가 동일한 모양으로 떠오르는가
Trust, but verify. AI가 만든 결과는 그럴듯해 보여도 위치, 사이즈, prop 이름 같은 세부가 어긋나 있을 수 있습니다. 자동으로 신뢰하지 말고 한 번 더 확인하세요.
4단계 — 더 정리할 거리 찾기
리팩터링이 한 번에 끝나는 일은 드뭅니다. AI를 코드 리뷰어처럼 활용해 추가 개선 포인트를 캐내봅니다.
Look through my components. Do you see any things that should be refactored or opportunities to implement best practices?
명시적으로 비판을 요청하기: 모델은 기본적으로 사용자의 요청에 우호적으로 답하도록 학습되어 있어 먼저 문제를 지적하지 않습니다. "리뷰해줘", "문제점을 짚어줘"처럼 명확하게 요구해야 비판적인 시각을 끌어낼 수 있습니다.
핵심 정리
- 일반적인 코딩과 마찬가지로 바이브 코딩에도 정기적인 리팩터링이 필요합니다. 기능 추가만큼 "vibe refactoring"의 비중을 챙기세요.
- AI는 알아서 반대 의견을 내지 않습니다. 리뷰어 역할을 명시적으로 부여해야 비로소 숨어 있던 개선점을 끄집어냅니다.