같은 코드가 10곳에 복사돼 있었다 — 바이브 코딩, 언제 한 번 멈춰서 정리해야 할까

📝 한줄 요약

AI랑 만든 사이트가 잘 굴러가고 있었다. 기능을 더 붙이기 전에 한 번 열어봤더니 같은 코드가 10곳에 복사돼 있고, 색깔을 손으로 477번 지정해뒀더라. 하루 날 잡아 청소했고, 그 김에 몰랐던 버그 2개도 잡았다.

바쁘시면 이것만:

• "클린 아키텍처로 짜줘"는 그때 한 번만 먹힌다.** 기능을 추가할 때마다 **"기존 구조에 맞춰서"를 말해줘야 하는데, 나는 한 번도 안 했다
• 그래도 어긋나니까 한 번씩 열어봐야 한다. 제일 중요한 신호 = "앞으로 붙일 게 눈에 보일 때"
• 정리하다가 원래 있던 버그 2개가 튀어나왔다. 잘 굴러간 게 아니라 몰랐던 것
• 청소 전에 자로 재는 게 먼저. "지저분한 것 같아" 말고 "같은 게 10곳에 있다"로
• 잘 만들어진 데는 안 건드리는 게 실력

🎯 이런 분들께 도움돼요

• AI로 뭔가 만들었는데 기능이 붙을수록 슬슬 불안해지는 분
• "코드 정리"를 언제 해야 하는지 감이 안 오는 분
• 만든 걸 남들이 쓰고 있어서 함부로 못 고치는 분

😫 왜 정리하게 됐나

사실 이번이 두 번째 개편이다.

처음엔 되는 대로 만들었다. 틀이 잡히고 나서 한 번 갈아엎었는데, 그때는 정적 사이트(글만 보여주는 형태)라 결제나 기능 확장이 어려울 것 같아서였다. 기획은 이미 있으니 그대로 두고, 도구만 확장 가능한 걸로 바꿔 구조부터 새로 짰다. 그때 이렇게 요청했다.

완전 클린 아키텍처로,
앞으로 기능을 덧붙여도 무너지지 않게 처음부터 구조를 짜서 만들어줘

그리고 그 부분은 지금도 멀쩡하다. 오늘 열어보고 손 안 댔다.

문제는 그 뒤였다. 레이아웃을 조금씩 바꾸고 기능을 하나씩 추가하면서, "기존 구조에 맞춰서 해줘"라는 말을 한 번도 안 했다. 생각해보니 정말 한 번도.

AI 입장에선 당연하다. "이 버튼 색 바꿔줘" 하면 색을 바꿔준다. "이 색을 어디 모아둬야 나중에 안 흩어질까"까지는 안 따진다. 내가 안 물었으니까.

그게 열 번 쌓이면 같은 게 열 군데에 흩어진다. 한 번에 무너지는 게 아니라 조금씩 어긋나서 눈치채기 어렵다.

결정적인 건 "앞으로 붙일 것"이었다. 결제 기능도 붙여야 하고, 얼마 전엔 강의 자료를 슬라이드로 보는 기능이 생겼다. 앞으로 사업계획서 화면, 상세 페이지 화면도 붙일 생각이다. 화면이 늘면 디자인이 흩어진다. 색깔이 477군데 흩어진 채로 화면을 셋 더 붙이면 1,000군데가 된다.

그래서 하루를 비웠다.

⏰ 언제 정리해야 할까

내가 겪은 걸로 정리하면, 하나라도 해당하면 볼 때가 된 거다.

1. 같은 걸 두 번째로 복붙할 때 — 두 번은 우연, 세 번부터 습관
2. 고치려는데 어디를 고쳐야 할지 못 찾을 때 — 내가 만든 건데 못 찾으면 흩어진 거다
3. 한 곳 고쳤는데 다른 데가 안 따라올 때 — 같은 내용이 여러 곳에 있다는 증거
4. 기능 붙이는 게 무서워질 때 — 불안하다는 건 구조가 말해주는 거다
5. ★ 앞으로 붙일 게 눈에 보일 때 — 지금 안 불편해도, 붙이기 전이 제일 싸다

앞의 넷은 "지금 불편해서"인데, 이번에 내가 멈춘 진짜 이유는 5번이었다. 이렇게 물어보면 된다.

"앞으로 3개월 안에 뭘 더 붙일 예정이지? 그걸 지금 구조 위에 올려도 괜찮을까?"

시점으로 보면 — 첫 번째는 만들고 싶던 게 일단 굴러갈 때(제일 쌈), 그다음은 위 신호가 뜰 때와 큰 기능 붙이기 직전. 아직 뭘 만들지 모를 때는 하지 말자 — 방향이 바뀌면 정리한 게 버려진다.

🔧 하루 동안 한 것

도구: Claude Code (Opus 5) · 시간: 하루

1. "지저분한 것 같아"를 숫자로 바꿨다

바로 고치지 말고 세는 것부터 시켰다. 몇 분 뒤 나온 답:

• 같은 코드가 10곳에 복사됨
• 색깔을 손으로 지정한 곳 477군데
• 관리 화면 파일 하나가 3,884줄 (전체의 33%)

그런데 전부 엉망은 아니었다. 처음에 신경 쓴 부분은 깨끗했고, AI가 이걸 짚으며 말했다.

"여긴 안 건드립니다. 잘 된 것을 리팩터링하는 게 이런 작업이 실패하는 제일 흔한 방식이에요."

이 한마디가 하루의 방향을 잡았다.

✅ 확인법: "10곳·477군데·3,884줄"이라는 숫자가 손에 잡혔을 때. 숫자가 안 나오면 진단이 안 끝난 거다

2. 정리하다 원래 있던 버그 2개가 나왔다

흩어진 코드를 한 곳으로 모으는 단순 이사라고 생각했는데, AI가 이러더라.

"파일에 뭘 쓰는 코드는 화면으로 확인이 안 됩니다. 테스트를 따로 돌려볼게요."

저장 방식을 8가지 경우로 나눠 실제로 써봤더니 두 개가 걸렸다. 지워진 자리에 빈 줄이 남는 것, 그리고 파일마다 다른 줄바꿈 방식을 무시하고 한 가지로만 붙이던 것(우리 파일 208개 중 94개가 위험에 걸려 있었다).

둘 다 오늘 이전부터 있던 버그다. 화면에선 멀쩡해 보였으니 아무도 몰랐다.

그러니까 "잘 굴러가는데 왜 고쳐요?"의 답은 이거다. 잘 굴러간 게 아니라, 안 굴러가는 걸 몰랐던 것.

✅ 확인법: 빌드(조립 검사) 통과 = 안전이 아니다. 파일을 다루는 코드는 실제로 써보는 테스트가 따로 필요

3. "지금 저장하면 수업 중인 사이트가 갈립니다"

작업 도중에 확인차 물었다. 마침 주말이라 사람들이 이 사이트로 수업 중이었다.

지금 이걸 내 컴퓨터에서만 작업하고 있는 거니?
실제 운영되는 사이트에서 바로 작업하는 거면,
지금 수업 중이라 문제가 생기면 아예 안 될 것 같거든.

답은 "지금은 안전"이었다. 그때까지 작업은 전부 내 컴퓨터 안에만 있었으니까.

문제는 그다음이었다. 나는 하루에 몇 번씩 /save라는 명령을 쓴다. AI한테 시킬 마무리 절차를 내가 직접 만들어둔 건데 — 오늘 뭘 했는지 기록하고, 계획 문서를 갱신하고, 코드를 저장하고, 점검을 돌리고, 사례글 소재까지 뽑아준다. 한 단어로 열 가지 일이 한 번에 도는 거다.

편한데, 그 안에 "사이트에 올리기"가 들어 있다. 그러니까 이 상황에선 세이브를 누르는 순간 수업 중인 사이트가 갈린다. 배포되는 구조인 건 알고 있었지만, 작업하다 습관적으로 세이브를 눌렀으면 그대로 나갔을 거다.

해결은 작업용 갈래(브랜치)였다. 프로젝트를 잠깐 복사본처럼 하나 더 만들어서 거기에 저장하는 거다. 저장은 되니까 컴퓨터가 꺼져도 안 날아가고, 원래 것은 안 건드리니 사이트도 그대로다. 나중에 합치는 순간이 곧 배포다. 그건 수업 없는 새벽에 하기로 했다.

남들이 쓰는 걸 만들었다면, 내가 만든 편한 명령이 어디까지 하는지 한 번 훑어보시길. 편할수록 많은 일을 한 번에 한다.

✅ 확인법: 실제 사이트 주소를 열어서 예전 상태 그대로인지 눈으로. "아직 안 올라간 변경이 몇 개인지" 세는 것도 같이

✅ 결과

• 색 바꾸려면 이제 한 파일만 연다
• 다크모드가 가능해졌다 — 예전 구조면 수백 곳을 손으로 뒤집어야 했다
• 화면은 하나도 안 바뀌었다. 이게 성공 조건이었다

제일 큰 덩어리는 절반에서 멈췄다.** 지금 옮겨봐야 파일만 쪼개지고 얽힘은 그대로일 상태여서, 그 화면을 실제로 고칠 때 같이 하기로 했다. 이게 가능했던 건 **"각 단계가 끝나면 언제든 멈춰도 되는 상태"를 미리 규칙으로 정해뒀기 때문이다.

💬 배운 것

됐던 것

1. 고치기 전에 잰다. "지저분한 것 같아"로는 어디까지 할지 못 정한다
2. 잘 된 곳은 안 건드린다. 멀쩡한 걸 손대다 새 버그를 넣는 게 제일 흔한 실패
3. 값은 그대로 두고 이름만 바꾼다. 색 477개를 정리할 때 색 값은 하나도 안 바꿨다. 그래서 "화면이 안 바뀐다"가 저절로 보장됐다

안 되는 것

1. "클린 아키텍처로 짜줘" 한 번으로 끝났다고 믿기. 그건 그때 한 번만 먹힌다
2. 검사 통과했으니 됐다고 믿기. 조립 검사는 모양만 본다
3. 편한 명령을 습관적으로 누르기. 여러 일을 한 번에 하는 명령일수록, 위험한 시간대엔 그중 뭐가 나가는지 봐야 한다

📋 재사용 가능한 프롬프트

1. 기능 추가할 때마다 붙이는 한 줄 (제일 중요)

[원하는 기능]을 추가해줘. 단, 이미 있는 구조에 맞춰서 해줘. 새로 만들기 전에 비슷한 게 있는지 먼저 확인하고, 있으면 재사용해. 색깔·간격 같은 값도 이미 정해둔 곳이 있으면 거기서 가져다 쓰고, 없으면 흩뿌리지 말고 한 곳에 모아줘.

이 한 줄을 매번 붙였으면 오늘 하루가 통째로 필요 없었을 거다.

2. 정리할 때가 됐는지 진단

앞으로 기능을 더 붙여도 구조가 안 무너지게 하고 싶어. 바로 고치지 말고 먼저 실측해줘: 같은 코드가 여러 곳에 복사된 것과 개수 / 지나치게 큰 파일 / 하드코딩된 값이 흩어진 곳과 개수. 그리고 잘 되어 있어서 안 건드려야 할 곳도 알려줘. 전부 뒤집는 게 목적이 아니야.

3. 안전하게 진행하기

정리를 단계로 나눠줘. 각 단계가 끝나면 화면이 전과 똑같아야 하고, 그 상태로 멈춰도 문제없어야 해. 그리고 [내 사이트]는 지금 사람들이 쓰고 있어. 지금 작업 중인 내용이 실제 서비스에 언제 반영되는지 먼저 확인해줘. 위험한 시간대엔 저장은 하되 서비스엔 안 나가게 하는 방법(작업용 갈래 만들기)도 같이 알려줘.

아루나의 다른 프로젝트가 궁금하다면 → aluna-site.vercel.app