바이브코딩이 무너지는 건 '첫 프롬프트'가 아니라 세 번째 이슈부터입니다

핵심 요약 (TL;DR)

• 요구사항을 한 번에 주지 않고 하나씩 붙여가며 개발시키는 SlopCodeBench에서, 세 모델의 '엄격 통과율'은 Opus 5 = 24%(4/17), Opus 4.8·Sonnet 5 = 각 6%(1/17)에 그쳤습니다.
• Opus 5는 함수를 5배 더 많이 짰지만 코드 라인의 93%가 정적 분석 품질 경고를 유발했습니다(버그율이 아니라 유지보수성 신호입니다).
• 결론은 분명합니다. 오늘의 모델도 '조종(steering)' 없이 반복 개발을 통째로 맡기기엔 이릅니다.

첫 화면은 늘 그럴듯합니다, 문제는 그다음이죠

바이브코딩을 해본 분이라면 익숙한 장면이 있습니다. 처음 프롬프트 하나로 뚝딱 나온 결과물은 놀랍도록 멀쩡한데, 기능 두세 개를 더 붙이는 순간 코드가 걷잡을 수 없이 엉키기 시작하는 거죠. 이걸 처음으로 숫자로 답한 리포트가 나왔습니다. humanlayer 팀이 SlopCodeBench 벤치마크에 Claude Opus 5·Opus 4.8·Sonnet 5를 돌린 결과입니다. 참고로 SlopCodeBench 자체는 위스콘신-매디슨대 Gabe Orlanski 랩이 2026년 3월 공개한 기존 벤치마크로, 새로 나온 건 여기에 최신 모델을 적용한 이 리포트입니다. 이 벤치마크의 방식이 핵심인데, 요구사항을 한꺼번에 주지 않고 실제 프로젝트처럼 '하나씩 점진적으로' 공개하며 시킵니다. 그리고 반복 개발 과정에서 코드 품질이 얼마나 무너지는지, 이른바 '슬롭(slop)'을 회귀 테스트·복잡도·중복·유지보수성 신호로 측정하죠.

숫자가 말하는 것

결과는 냉정했습니다. 3개 문제(쉬움·보통·어려움)의 17개 체크포인트에서, 신규 기능과 회귀 테스트를 '전부' 통과해야 인정하는 엄격 기준으로 봤을 때 통과율은 Opus 5가 24%(4/17), Opus 4.8과 Sonnet 5가 각각 6%(1/17)였습니다. 표본이 문제 3개·체크포인트 17개로 작다는 점은 감안해야 합니다. 그런데 더 눈여겨볼 대목은 품질 신호입니다. Opus 5는 다른 모델보다 함수를 5배 더 많이 짰지만, 장황함과 복잡도도 모든 문제에서 함께 늘었고, 결국 작성된 코드 라인의 93%가 품질 경고를 유발했습니다. 오해하기 쉬운데, 이 93%는 정적 분석이 붙인 '경고'이지 곧바로 버그라는 뜻은 아닙니다. 다만 '더 많이, 더 복잡하게' 짜는 방향이 반복 개발에선 유지보수성 적신호로 쌓인다는 걸 보여주죠.

그래서 'steering'이 실력입니다

왜 이런 일이 벌어질까요. 반복 개발은 맥락이 계속 쌓이는 작업입니다. 요구가 하나씩 추가될 때마다 모델은 이전 결정을 잊거나, 그 위에 급하게 덧칠을 합니다. 벽돌을 쌓는 게 아니라 페인트를 덧바르는 셈이죠. 리포트의 결론도 여기 있습니다. 오늘의 모델도 '조종(steering)' 없이 불 끄고 맡기는 lights-off 방식으로는 실제 소프트웨어를 만들 수 없다는 것. 바꿔 말하면, 무엇을 언제 어떤 맥락으로 건네주느냐를 설계하는 컨텍스트 엔지니어링이 곧 실력이라는 얘기입니다. 바이브코딩은 '사람이 빠지는 자동화'가 아니라 '사람이 방향을 잡는 협업'에 가깝습니다.

자주 묻는 질문 (FAQ)

Q. 그럼 바이브코딩은 아직 못 쓸 물건인가요?
아닙니다. 한 번에 만드는 작업이나 프로토타입에선 여전히 강력합니다. 무너지는 건 '유지·확장' 국면이니, 그 구간에서 사람의 개입 밀도를 높이면 됩니다.

Q. 통과율 24%는 실망스러운 숫자 아닌가요?
엄격 기준(신규+회귀 전부 통과)이라 낮게 나온 겁니다. 모델 성능의 전부가 아니라, '반복 개발 관리'라는 특정 난이도를 보여주는 지표로 읽는 게 맞습니다.

Q. steering은 구체적으로 뭘 하라는 건가요?
큰 요구를 작은 단위로 쪼개 주고, 매 단계 기존 구조를 다시 상기시키며, 중복·복잡도가 늘면 리팩터링을 명시적으로 요청하는 것. 방향키를 계속 쥐고 있는 겁니다.

첫 프롬프트의 마법에 취하기는 쉽습니다. 진짜 실력은 세 번째 이슈, 다섯 번째 이슈에서 갈리죠. 여러분의 프로젝트는 지금 몇 번째 이슈에서 흔들리기 시작하나요?