Vibe Coding이 진짜 생산성을 올려줄까

토요일 오후, "대충 이런 느낌으로 짜줘"

Vibe Coding이라는 말이 돌기 시작한 게 2025년 초쯤이었다. AI한테 상세한 스펙 대신 분위기랑 방향만 전달하고, AI가 알아서 구현하게 하는 방식. "노션처럼 깔끔한 대시보드 만들어줘"라고 하면 뚝딱 나온다는 거다.

멋있는 컨셉이다. 진짜 되나 3주간 사이드 프로젝트에서 써봤다.

1주차: 와 이거 사기 아니야

첫 주는 놀라웠다. 개인 독서 관리 앱을 만들기로 했는데, "책 목록 카드 그리드, 클릭하면 상세, 독서 진행률 차트"라고만 했더니 30분 만에 뼈대가 나왔다. 예전 같았으면 컴포넌트 구조 잡고, 타입 정의하고, 스타일링하는 데만 반나절 걸렸을 거다. 일주일 동안 이런 식으로 페이지 6개를 만들었다.

생산성이 체감상 서너 배는 된 것 같았다. (이때가 가장 행복했다.)

2주차: 뭔가 계속 아쉽다

문제는 "거의 다 된 것 같은데 뭔가 아쉬운" 상태가 끝나지 않는다는 거다. AI가 만든 카드 레이아웃이 특정 화면 크기에서 살짝 깨지고, 차트 색상이 다크모드에서 안 보이고, 스크롤 위치가 페이지 이동 후 복원이 안 되고.

이런 사소한 문제 하나하나를 고치는 데 오히려 시간이 더 걸렸다. "이 부분 고쳐줘"라고 하면 고치면서 다른 걸 건드린다. 그걸 또 고치면 또 다른 게 깨진다. 끝이 없다.

Vibe Coding의 8할은 빠르게 나온다. 나머지 2할이 전체 시간의 8할을 잡아먹는다.

3주차: 내가 짠 게 아니라 모르겠다

가장 큰 문제는 여기서 터졌다. 2주 동안 AI가 만든 코드가 3,000줄쯤 쌓였는데, 버그가 생겼을 때 어디를 봐야 할지 감이 안 왔다. 내가 짠 게 아니니까. 상태 관리 로직이 여기저기 흩어져 있고, AI가 만든 커스텀 훅의 내부 동작을 이해하려면 한 줄 한 줄 읽어야 했다.

결국 AI한테 "이 코드 설명해줘"라고 물어보는 상황이 벌어졌다. AI가 짠 코드를 AI한테 설명해달라고 하는 나. 좀 웃겼다.

그래서 언제 좋냐면

프로토타입이나 해커톤처럼 완성도보다 속도가 중요한 상황에서는 Vibe Coding이 진짜 좋다. 하루 만에 MVP 뽑아낼 수 있다. 근데 프로덕션에서는 위험하다. 디테일 잡는 비용, 유지보수 비용, "내 코드를 모르겠다"는 리스크가 초기 속도 이득을 금방 까먹는다.

결국 반반으로 갔다

지금 내가 쓰는 방식은 이렇다. 아키텍처랑 핵심 로직은 내가 직접 짜고, 반복적인 UI 코드나 보일러플레이트를 AI한테 vibe로 맡긴다. 뼈대는 내가 세우고 살은 AI가 붙이는 방식. 이러면 코드 구조를 내가 이해하고 있으니까 디버깅이 가능하고, 반복 작업은 빠르게 처리되니까 속도도 챙길 수 있다.

Vibe Coding은 도구이지 방법론이 아니다. "AI한테 다 맡기자"가 아니라 "뭘 맡길지 잘 나누자"가 핵심인데, 나는 3주를 써보고 나서야 이걸 깨달았다. 좀 더 일찍 알았으면 2주차의 고통이 줄었을 텐데.