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

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

[GN⁺]

Lobste.rs 의견들

• 최근 불안하게 지켜보던 소프트웨어 엔지니어링 업계의 변화를 다룬 글 중 단연 잘 쓴 편임

• 1년 전만 해도 에이전트형 엔지니어링이 바람직한 방향처럼 여겨졌지만, 실제 도구 사용자 대부분은 인정하기를 주저할 뿐 바이브 코딩으로 기우는 듯함. LLM이 내 기술과 애정을 무용하게 만들지 모른다는 공포는 두 가지 원칙을 세우고 크게 줄었음
  첫째, 여가에는 LLM이나 코딩 에이전트를 쓰지 않고 검색의 AI 기능도 거부함. 스스로 해결할 수 없을 만큼 절박할 때만 환각 가능성을 감수하고 활용함. 기술을 외면한다고 세상이 해결되지는 않지만, 개인 개발자를 공격하거나 대기업을 바꿀 수도 없는 상황에서 여가까지 관여하지 않는 것이 현실적으로 가능한 선택임
  둘째, AI 사용을 강하게 권장하는 직장에서도 코드 리뷰와 심부름에만 활용함. 코드베이스에서 직접 찾을 수 있지만 번거로운 내용을 묻는 정도이며, 코드는 모두 직접 작성함. 그래야 작동 원리를 직관적으로 이해하고 자신과 동료가 기대하는 수준으로 일할 수 있음
  LLM은 결정론적 린터가 찾지 못하는 패턴 기반 오류를 발견해 주는 보조 수단으로 괜찮음. 엉뚱한 답도 내놓지만 코드를 직접 작성하고 이해하므로 맹신하지 않음. 사람의 리뷰 전에 명백한 논리 오류와 잘못된 가정을 걸러내면 동료는 더 복잡한 부분에 집중할 수 있고, 공개 채널에서 사람 대신 기계끼리 대화하게 만드는 무례도 피할 수 있음
  최근 회사가 토큰 사용량을 엄격히 제한했지만 하루 비용이 1~2유로에 불과한 작업 흐름이라 걱정되지 않음. 직감에 전적으로 의존하던 이들은 다시 인간의 추론을 써야 한다는 사실에 불안할 수 있지만, 나머지는 동료들과 직접 해내면 됨

  • “모래에 머리를 박는다고 해결되겠느냐”는 비판은 실제 제삼자가 아니라 상상 속 비판자를 대신해 스스로 하는 말임. 그런 비판을 의식해 선택할수록 삶이 나빠져서 나도 이를 경계하려고 함
    고통스러울수록 진실을 직시해야 한다는 자학적 인식론도 깔려 있음. 괴로운 정보를 피하면 덕이 없는 것처럼 느껴질 수 있지만 주의력은 유한하므로, 더 행복하고 충만해져 내일도 계속할 힘을 주는 일에 쓰는 편이 나음
  • 이는 모래에 머리를 박는 것보다 “사무실 근무가 싫어서 여가에는 사무실을 피한다”에 가까움. 즐겁지 않은 일을 피할 수 있다면 피하는 것이 합리적임
    삶의 모든 것을 최적화하고 최고가 되어야 할 업무처럼 대하는 이들이 오히려 손해를 봄. 코딩이 좋으면 여가에도 하면 되고, 싫다면 직업으로만 남겨도 됨. 여가에는 때때로 비효율적이어도 괜찮으며, 그렇지 않으면 자유 시간이 두 번째 직장이 되어 전혀 쉬지 못함

• 여기서 Fawlty의 철자를 틀린 것이 지나치게 거슬림

  • “말썽을 부리는” 바벨탑이라는 말장난이라 일부러 그렇게 쓴 듯함

• 글은 늘 그렇듯 훌륭하지만, LLM 생성물인지 물으면 무례할지 고민할 필요는 없어 보임. 제작 과정에서 LLM을 썼는지와 무관하게 형편없는 결과물을 받았다면 품질이 나쁘고 마음에 들지 않는다고 말할 수 있음

  • 모르는 신규 기여자라면 PR의 품질 문제를 짚고 수정 책임을 돌려주는 것이 합리적임. 다만 Zig 프로젝트는 신규 기여자를 장기 기여자로 성장시키기 위해 LLM이 아닌 사람을 직접 지도하고자 AI 반대 정책을 채택했던 것으로 기억함
    반면 동료나 온라인에서 오랫동안 교류한 사람과는 관계를 유지하기 위해 가능한 한 무례를 피하고 싶을 수 있음. 기여물이 어떻게 만들어졌는지 알아야 논의할 수 있고, 그 결과가 관계에 의도적으로 큰 영향을 줄 수도 있음. 무례할 위험을 감수할지, 기본적으로 갈등을 피하며 관계를 보존할지는 성향에 따른 선택임
    원래 갈등을 피하는 편이라 그 문장이 나온 배경은 이해되며, 본래 주장에도 크게 반대하지 않음

• 봅슬레이 비유가 마음에 듦. LLM 사용자가 반드시 끝까지 내려가게 된다는 주장에는 동의하지 않지만, 업계에서 관찰되는 행동을 지금까지 본 어떤 비유보다 잘 묘사함

• “봅슬레이 비유”는 논리적 오류인 미끄러운 경사면으로 더 잘 알려져 있음. 1년 전에는 바이브 코딩 비중이 0%였고, Simon Willison은 코딩 에이전트를 신중하게 도입하며 점차 신뢰를 높여 가는 과정을 여러 글로 공개했음
  그런데 이를 근거로 “갈 곳은 하나뿐”이라고 단정함. Willison과 다른 사용자들에게도 취향과 판단력이 있다고 보는 편이 타당함