vibe slop이 뭔데??
바이브 코딩 한참 하다 보면, 내 코드인데 내가 모르겠는 순간이 온다. 찾아보니까 이름까지 있더라. vibe slop.
요즘 진짜 바이브 코딩만 한다.
새 기능 하나 만들 때, 예전 같으면 파일 열어서 한 줄 한 줄 짰겠지만 — 이제는 그냥 AI 한테 “이 기능 추가해줘” 하고 던지면 알아서 짜준다. 빠르다. 진짜 빠르다.
근데 최근에 좀 이상한 감각이 들기 시작했다.
내 코드인데… 내 코드 같지가 않다.
예전이랑 뭐가 달라졌나
손으로 한 줄 한 줄 짤 때랑, 바이브 코딩 할 때랑 — 정확히 뭐가 달라졌나 한 번 생각해봤다.
달라진 것
예전:
- 모든 코드 구조가 머리에 들어있었다. 어떤 함수가 어디서 호출되는지, 어떤 모듈이 어떤 모듈에 의존하는지.
- 새 기능 추가하려면? 어느 파일에 손대야 할지 1초 만에 떠올랐다.
- 버그 잡으려면? 보통 그 자리에서 원인 가설 두세 개가 머리에 떠올랐다.
지금:
- 코드 구조? AI 한테 “이 시스템 전체 구조 정리해줘” 시키고, 그 정리본을 한 번 읽어야 안다.
- 새 기능 추가? 마찬가지로 분석 한 번 요청한 다음 시작.
- 버그? 더 심하다. “이 함수 어디서 호출돼?” 부터 AI 한테 물어봐야 한다.
이게… 좀 충격이었다.
내가 짠 코드인데, 분석본을 끼고 봐야 알 수 있다는 거.
그래도 안 변한 것
뭐 다 잃어버린 건 아니다. 안 변한 것도 있다.
- 기획 문서랑 ERD 는 여전히 의존한다. 이게 진짜 살아남는다. AI 가 아무리 코드를 자기 멋대로 짜도, 기획 문서랑 ERD 가 머리에 있으면 “아, 이 도메인은 이렇게 작동해야 하지” 가 안 흔들린다.
- 클래스 다이어그램 정도의 큰 그림은 머리에 있다. 어떤 도메인이 어떤 도메인이랑 관계가 있는지, 그 수준은 안 잃었다.
그러니까 큰 그림은 살아있는데 — 그 안의 구체적인 코드 흐름은 점점 멀어진다. 그런 감각이다.
문제는 시간이 지나면서 생긴다
처음 짤 때는 그래도 괜찮다. 기획서 그대로다. ERD 그대로다. 깔끔하다.
근데 출시하고 한 달이 지나면, 새 기능이 두세 개 끼어든다. 베타 피드백으로 데이터 모델이 한두 군데 바뀐다. 버그 픽스가 누적된다.
이때부터 진짜 시작된다.
처음 기획서에는 없던 필드가 DB 에 생긴다. 클래스 다이어그램에 없던 새 클래스가 슬그머니 추가된다. 새 엔드포인트가 한두 개 더 박힌다.
근데 — 기획 문서랑 ERD 는 안 갱신된다.
왜냐? 1인 개발자니까. 코드 짜기 바쁘니까. “나중에 한 번에 정리하지 뭐” 하고 미룬다.
그리고 그 “나중” 은 영원히 안 온다.
그렇게 한 달, 두 달 흘러간다.
어느 날 보면 — 내가 머리에 들고 있는 그림이랑, 실제 코드가 다른 시스템이다.
분석 없이는 본인도 디버깅이 안 되는 코드가 된다.
이 감각, 진짜 이상하다. 본인이 만든 게 본인한테 낯설어지는 거.
집을 직접 지었는데, 어느 날 들어가보니까 방 배치가 바뀌어 있는 느낌이랄까.
이거 요즘 문제더라 — vibe slop
좀 답답해서 찾아봤는데, 이미 이름까지 있더라.
vibe slop.
vibe coding + slop. 바이브로 짜다가 결국 쌓여서 알아볼 수 없게 된 덩어리를 가리키는 단어다.
그리고 이게 SNS 농담이 아니라, 진짜로 측정되고 있더라.
- Veracode 라는 회사가 낸 보고서에 따르면, AI 코드의 45% 가 보안 구멍을 갖고 있다고 한다. 자바는 더 심해서 72%.
- Apiiro 라는 곳에서는, AI 코드 채택 6개월 만에 보안 발견이 10배 증가했다는 추적 결과를 냈다고.
- arXiv 에 “Vibe Coding in Practice” 라는 학술 논문도 올라와있다. vibe coding 의 속도와 기술 부채의 트레이드오프 를 정식으로 측정하는 연구다.
- 그리고 여러 글이 공통적으로 짚는 결론은 — 6~12개월이면 초반 속도 이득이 다 상쇄된다는 거다.
빠르게 짜는 만큼, 정확히 그만큼의 부채가 같이 쌓이고 있다는 거다.
심지어 더 웃긴 건 — vibe coding 이라는 단어 만든 Karpathy 본인이, 작년에 새 프로젝트는 “거의 전부 손으로 짰다” 고 발표했다는 거다. AI agent 가 “그냥 충분히 잘 작동하지 않았다” 면서.
본인이 만든 단어인데 본인이 떠난 거.
좀 의미심장하다.
그래서 어떻게 회피하냐고?
솔직히 — 답 없다.
매번 코드 한 줄 한 줄 읽으면 회피할 수 있겠지만, 그러면 바이브 코딩 하는 의미가 없잖아. 손코딩이랑 다를 게 없다.
근데 그렇다고 손 놓고 있을 수도 없으니까, 내가 나름대로 하고 있는 건 있다.
내 머릿속에 — “지금 작업할 때 생길 만한 잠재 문제” 와 — “AI 가 짠 코드의 흔한 함정” 정도는 항상 들고 있으려고 한다.
예를 들면:
- 새 API 만들 때: 인증 빠질 수 있다. 권한 체크 빠질 수 있다. 입력 검증 빠질 수 있다.
- 새 DB 컬럼 추가할 때: 옛 클라이언트가 깨질 수 있다. 마이그레이션 순서 꼬일 수 있다.
- 새 비즈니스 로직 짤 때: 이미 비슷한 로직이 어딘가에 있을 수 있다. 중복 코드 생긴다.
- AI 가 알고리즘 짤 때: 5개짜리 리스트인데 메모이제이션 박는다거나, 분산 캐시 도입하자고 한다거나. 오버엔지니어링.
이런 잠재 함정 카탈로그 정도는 항상 머리에 깔아두고, AI 한테 분석 요청할 때 그냥 “분석해줘” 가 아니라 — “이런 관점에서 한 번 봐줘” 라고 시킨다.
이 분석 한 번에 모든 게 잡히는 건 아니지만, 이 정도라도 안 하면 진짜 한 달 뒤에 손도 못 댄다.
vibe coding 의 진짜 비용은, 본인이 본인 코드를 모르는 상태를 견디는 비용이다.
빠르게 짠다는 건 좋지만, 그 빠름 만큼 본인이 잃어버리는 게 있다는 사실은 — 받아들여야 한다.
암튼 쉽지 않다
뭐… 결국 결론은 그거다.
바이브 코딩, 진짜 빠르다. 한 달 만에 베타 끝내고 출시까지 한 거, 이거 손코딩으로는 진짜 불가능했다.
근데 그 댓가가 정확히 — 내 코드에서 내가 점점 멀어지는 감각이라는 거.
이걸 완전히 회피할 방법은 없다. 그냥 최대한 늦추는 수밖에.
문서 자주 갱신하고, 잠재 함정 카탈로그를 머리에 들고 있고, 작업 끝낼 때 한 번 분석 돌려서 점검하고.
근데 솔직히 — 이것도 하기 싫은 날이 매일이다. 그냥 빠르게 코드 짜고 빠르게 자고 싶다.
암튼 쉽지 않다.
마침.
다른 글 보기
암튼 정리해보는 깃 브런치 전략
항상 브런치를 따도록 하자.
바이브 코딩을 배운다 는 무슨 말일까?
요즘 개발자들 다 AI 딸깍이잖아!! 를 반박할 수 없는 사람 여기 있습니다.
아, 문 열면 줄 서서 들어올 줄 알았지...
사람 귀한 줄... 잘 알았습니다.
냉장고에 맥주가 있으니까 맥주를 마시는거다. 난 죄가 없다.
StockPile Effect(비축 효과)의 아주 바람직한 예시 인간