결함투성이 탑, 바이브 멀미, 그리고 바이브 봅슬레이

• LLM이 만든 코드를 사람이 이해하지 못해도 다시 LLM에 해석을 맡기며 개발하는 방식이 확산되면서, 한때 구분되던 에이전트 엔지니어링과 바이브 코딩의 경계가 빠르게 흐려지고 있음
• 바이브 봅슬레이는 자동완성에서 코드 생성, 검토 포기, 프롬프트 포기로 이어지는 정해진 경로를 뜻하며, 생성 속도를 활용할수록 프로그래머의 핵심 역할인 이론 구축과 검토에서 멀어짐
• Pvote 실험에서는 보안 전문가들이 위치를 미리 알고 100줄의 코드를 약 20시간 검토하고도 세 버그 중 어려운 버그를 찾지 못해, 사람이 대량의 LLM 출력을 온전히 검토한다는 전제가 비현실적임을 보여줌
• 이해되지 않은 코드와 생성물이 음식점 포스터, 고객지원 챗봇, 연령 확인 코드, 오픈소스 이슈·PR까지 침투하는 바이브 멀미가 퍼지고 있으며, 도구를 쓰지 않는 사람도 타인의 생성물을 검토하느라 영향을 받음
• 생성형 AI는 문제 발견에는 유용할 수 있지만 생성에는 특히 취약하며, 이해할 수 없는 시스템이 세계를 대체하는 흐름 속에서도 인간이 더 나은 환경을 직접 만드는 능력까지 포기해서는 안 됨

이해할 수 없는 코드의 탑

• The Tower Keeps Rising은 과거라면 팀원끼리 대화해야 풀었을 상황에서도 에이전트를 이용해 계속 진척을 낼 수 있게 된 상태를 관찰함
  • Armin은 이를 좋거나 나쁜 일로 판단하지 않았으며, 지속 가능한 상태라고 옹호하지도 않음
  • 다만 바이브 코딩 회사를 운영하며 이러한 흐름을 진전시키는 위치에 있음
• 바이브 코딩 시스템은 코드와 추상화를 계속 쌓다가 결국 어떤 인간도 코드베이스를 이해하지 못하는 상태에 도달할 수 있음
  • 사람이 이해할 수 없는 부분도 LLM이 다시 해석해 주므로 개발을 계속할 수 있다는 새로운 운영 방식이 생김
• 이를 옹호하는 쪽에서도 인간이 시스템을 이해하지 못하는 종착점을 인정하고, 그 상태를 앞으로의 개발 방식으로 받아들이는 변화가 나타남

에이전트 엔지니어링과 바이브 코딩의 경계 붕괴

• Simon Willison은 처음 에이전트 엔지니어링(agentic engineering)을 바이브 코딩과 명확히 구분함
  • 2025년 3월 글에서 프로덕션 품질의 AI 보조 프로그래밍이라면 저장소에 커밋하는 모든 코드를 읽고 다른 사람에게 정확히 설명할 수 있어야 한다는 원칙을 세움
  • LLM이 작성한 코드라도 사람이 검토하고 철저히 테스트하며 작동 방식을 설명할 수 있다면 바이브 코딩이 아니라 소프트웨어 개발이라고 구분함
• 약 1년 뒤 Vibe coding and agentic engineering are getting closer than I’d like에서는 코딩 에이전트의 신뢰성이 높아지면서 프로덕션 코드조차 모든 줄을 검토하지 않게 됐다고 밝힘
  • Claude Code가 SQL 쿼리를 실행해 JSON을 반환하는 API 엔드포인트를 올바르게 만들고 테스트와 문서까지 추가할 것이라고 신뢰함
  • 동시에 검토하지 않은 코드를 프로덕션에 사용하는 일이 책임 있는지 죄책감과 의문을 느낌
• 두 입장 사이의 간격은 1년을 조금 넘는 정도에 불과함
• 에이전트 엔지니어링이 바람직한 사용법이라는 인식이 널리 퍼졌지만, 실제 사용자는 Simon 자신을 포함해 바이브 코딩 쪽으로 끌려가는 경향을 보임

바이브 봅슬레이

• 봅슬레이는 얼음 트랙을 빠르게 내려가지만 이동할 방향은 사실상 하나뿐인 스포츠임
  • 선수끼리 숙련도를 겨루고 짜릿함을 느낄 수 있지만, 탑승자가 여정 자체를 선택할 여지는 크지 않음
• 바이브 봅슬레이에서는 LLM이 탈것이고 사용자는 승객임
  • 사용자가 느끼는 것보다 실제 주도권은 훨씬 적으며, 단순히 미끄러운 경사라기보다 미리 만들어진 여정에 가까움
• 개발자는 다음 단계를 거치며 코드 생산 과정에서 자신을 제거함
  • 처음에는 고급 자동완성으로만 사용한다고 생각함
  • 이후 아이디어 탐색용 에이전트를 실행하되 코드는 직접 작성하겠다고 함
  • 다음에는 에이전트가 코드를 생성하지만 모든 결과를 검토하겠다고 다짐함
  • 곧 코드를 거의 검토하지 않으면서 에이전트가 자신보다 더 나은 개발자일 수 있다고 믿게 됨
  • 마지막에는 “더는 코딩하지 않는다”를 넘어 “더는 프롬프트도 작성하지 않는다”는 단계로 향할 수 있음
• 각 단계는 LLM이 자신의 작업을 이해하고 잘 처리한다는 신뢰 기반 코드 생산으로 이동하는 과정임

생성 속도와 검토의 충돌

• 코딩에서 느린 부분은 생성이 아니라 이론 구축과 검토이며, 그럴듯하지만 잘못된 결과는 디버깅하고 이해하기 매우 어려움
• LLM의 가장 강력한 속성은 생성 속도이므로 사람이 결과를 모두 검토하면 그 속도를 충분히 활용하기 어려움
• 반면 이론 구축과 검토는 프로그래머의 가장 중요한 역할이어서, LLM의 장점을 극대화할수록 핵심 역할에서 멀어지는 충돌이 생김
• Ka-Ping Yee의 논문 Building Reliable Voting Machine Software는 소프트웨어 검증을 어렵게 만드는 요인으로 다음 네 가지를 꼽음
  • 구성 요소의 수
  • 복잡한 상호작용
  • 광범위한 영향
  • 비선형성
• 이 네 가지 문제는 LLM의 코드 생성 방식으로 더 심해질 수 있음

Pvote 버그 검토 실험

• Ka-Ping Yee와 David Wagner는 모델 투표기 Pvote에 선거 결과를 바꾸는 데 악용할 수 있는 쉬운·중간·어려운 버그를 하나씩 삽입함
• 세 버그는 모두 Navigator.py의 11~109행에 해당하는 100줄 영역에 배치됨
  • 프로그램 로직상 흥미로운 부분이면서 검토자의 제한된 시간을 고려한 선택이었음
  • 검토자들에게 살펴볼 영역은 알려줬지만 버그가 몇 개인지는 알리지 않음
• 세 번째 날의 검토 결과는 다음과 같음
  • Python에 매우 익숙한 Dan Sandler는 약 70분 안에 쉬운 버그와 중간 버그를 찾음
  • Yoshi Kohno와 Mark Miller는 약 4시간 뒤 쉬운 버그를 발견함
  • 어려운 버그는 아무도 찾지 못함
• 네 번째 날에는 Ian Goldberg가 약 2시간 안에 쉬운 버그를 찾았지만 다른 버그는 발견하지 못함
• 숙련된 보안 전문가들은 위치까지 알고 있었지만 총 약 20 검토자-시간을 투입하고도 세 버그를 모두 찾지 못함
• Mark S. Miller는 나중에 버그를 확인한 뒤 모두가 명백한 버그이며 자신들이 찾아냈어야 했다고 동의한 점에 놀라움을 느낌
• 최고 수준의 프로그래머도 100줄 안에 반드시 존재하는 버그를 놓친다면, 인간이 LLM의 방대한 출력을 검토하는 방식은 감당하기 어려움
  • 결국 사용자는 검토를 포기하고 코드 생산 과정에서 자신을 단계적으로 제거하게 됨

AI 정신증과 바이브 멀미

• “AI psychosis”는 생성형 AI로 발생한 나쁜 행동이나 결과 전반을 가리키는 말로 넓게 쓰이지만, 원래는 사용자를 지나치게 긍정하는 챗봇과 상호작용하며 실제 정신증과 망상적 현실 이탈을 겪는 상태에 가까웠음
• 임상적 정신증이 아닌 생성형 AI로 인한 광범위한 불쾌감에는 바이브 멀미(vibe sickness) 가 더 적합함
• Glyph의 PyCon US 2026 후기에는 다음 상황이 동시에 나타남
  • 광범위한 바이브 멀미
  • 오픈소스의 대규모 지속 가능성 위기
  • 저품질 보안 PR의 범람
  • 상호 이해를 위한 희망·에너지·노력과 작업에 대한 감사

일상과 오픈소스에 번지는 생성물

• 사람들은 저품질 생성물인 슬롭(slop) 을 불평하지만, 생성형 AI 사용자는 자신의 결과물을 슬롭이라고 부르지 않음
• 그럴듯하면서도 이해할 수 없는 생성물은 일상 곳곳에 나타남
  • 이해하기 어려운 디자인의 지역 음식점 포스터
  • 이용자를 좌절시키는 고객지원 챗봇
  • 연령 확인 코드
  • 오픈소스 프로젝트에 제출되는 저품질 이슈와 PR
• 이러한 도구는 일부 작업에 유용하며 문제 발견에는 다르게 평가할 여지가 있음
• 그러나 “genAI”라는 이름이 강조하는 생성은 오히려 도구가 가장 못하는 부분임
  • 생성물의 품질뿐 아니라 시스템의 구축·구조·유지보수 방식을 아무도 이해하지 못하는 문제까지 생김

생성형 AI에서 벗어날 수 없는 환경

• 생성형 AI를 직접 사용하지 않아도 동료나 오픈소스 기여자가 자신도 이해하지 못한 생성물을 “기여”로 보내올 수 있음
  • 검토자는 LLM 생성 여부를 물으면 무례한지 고민해야 함
  • 이슈나 PR에 답하는 동안 에이전트와 간접적으로 상호작용하며 의도치 않게 바이브 코딩 작업 흐름에 참여하게 됨
• Glyph는 LLM이 들어간 모든 소프트웨어를 거부하는 일을, 자동차의 유연 휘발유 도입에 항의하려고 모두가 사용을 멈출 때까지 숨을 참는 것에 비유함
  • 현실적으로 어느 정도 받아들일 수밖에 없어 개인적인 윤리선을 정하더라도, 그것이 생성형 AI 환경에 대한 기대나 흥분을 뜻하지는 않음
• 불쾌한 골짜기(uncanny valley) 가 현실 세계를 점유하면서 아무도 이해하지 못하는 시스템이 기존 세계를 대체하고 있음
• 이 상태에서 회복할 때 치러야 할 대가는 아직 파악되지 않았으며, 현재의 생성형 AI에 참여하지 않기로 선택한 프로젝트는 존중할 가치가 있음

더 나은 지형을 만드는 선택

• 업무나 환경 때문에 생성형 AI 문제에 기여하는 일을 완전히 거부하지 못할 수도 있음
• 자동차 운전자가 도로의 자전거 이용자에게 화를 내더라도, 자전거 인프라가 부족하면 이용자는 주차 차량의 문이나 조급한 운전자 때문에 위험해짐
• 운전 중 앞에 자전거가 있다면 그 존재에 감사하고, 자전거가 더 안전하게 참여할 수 있도록 지형과 인프라를 바꾸는 방법을 생각할 수 있음
  • 이런 변화는 자동차 운전을 쉽게 만들고, 상황에 따라 자전거를 선택하기도 쉽게 함
• 기술이 정한 경로에 자신을 맡기기보다 인간이 직접 참여해 더 나은 세계를 만들 수 있다는 믿음을 포기하지 않아야 함