바이브 코딩은 남이 유지보수해야 할 때 문제가 된다

요즘 이 문제 때문에 골머리 좀 앓고 있다. 일단 빠르게 뭘 하나 만든다. 잘 돌아가고 데모도 그럴싸하다. 몇 군데 고치고 기능 좀 더 얹으면서 계속 달린다.

그러다 일주일 뒤에 다시 코드 열어보면… 뭔가 이상하다. 완전히 망가진 건 아닌데, 뭐라 설명하기 힘든 찝찝함이 있다. 헬퍼 함수는 여기저기 중복돼 있고, 컴포넌트 하나가 너무 많은 일을 한다. 건드리기 무서워서 방치하는 파일들도 생긴다.

데이터 모델도 얼추 맞는 것 같긴 한데, 기능을 추가했던 순서를 기억해야만 이해가 된다. 이틀 전에 했던 '임시방편'이 어느새 다른 기능 세 개의 기반이 되어버렸다. 그러다 보면 이제는 만드는 것보다 내가 뭘 만들었는지 파악하는 게 더 힘들어지는 상황이 온다.

이런 부분에 대해서는 다들 얘기가 별로 없더라. '바이브 코딩(vibe coding)' 할 때는 흐름 타서 기분 좋지. 근데 그 바이브 다 빠지고 나서 누군가 유지보수해야 할 때는 어쩔 건데?

이걸 까려는 건 아니다. 나도 이런 식으로 자주 짜고, 덕분에 속도도 많이 냈다. 근데 나중에 치러야 할 대가가 점점 크게 느껴진다. 재미로 만드는 프로토타입 단계를 넘어서 프로젝트를 키워본 형들은, 코드베이스가 아무도 건드리기 싫은 쓰레기장으로 변하는 걸 어떻게 막고 있어?

스펙부터 먼저 짜나? 아니면 주기적으로 리팩토링을 하나? 파일 경계를 엄격하게 지키나? 테스트 코드를 일찍부터 넣나? 변경 사항 하나하나 꼼꼼히 리뷰하나? 아니면 아이디어 검증 끝나면 지저분한 부분 싹 다 갈아엎나?

그냥 뻔한 소리 말고, 진짜 도움 되는 실전 팁 좀 알려줘라. 뭐가 진짜 효과 있냐?