▲

바이브 코딩 숭배는 미쳐있다

 (bramcohen.com)
15P by GN⁺ 8시간전 | ★ favorite | 댓글 5개
  • Claude의 소스코드 유출 사건을 계기로, "바이브 코딩(vibe coding)"의 맹신이 실제 프로젝트 품질에 어떤 해를 끼치는지가 드러남
  • 바이브 코딩은 코드 내부를 전혀 들여다보지 않는 것을 원칙으로 삼지만, 이는 순수한 미신에 불과하며 실제로는 계획 파일, 스킬, 규칙 등 인간의 구조 설계가 반드시 수반됨
  • AI는 코드 중복·기술 부채 정리 같은 작업에 실제로 매우 뛰어나지만, 이를 활용하려면 인간이 직접 코드를 살피고 문제를 파악해 AI에게 설명해야 함
  • AI가 자발적으로 "스파게티 코드가 있으니 정리해야겠다"고 인식하는 경우는 드물며, 인간이 방향과 맥락을 먼저 제공할 때 높은 품질의 결과물이 나옴
  • “나쁜 소프트웨어는 개발자의 선택” 이라는 문구처럼, 품질 저하는 AI가 아닌 의사결정의 결과임
  • 즉, 소프트웨어 품질 저하는 AI 탓이 아니라 개발자가 스스로 내리는 선택

Claude 소스코드 유출과 바이브 코딩의 문제

  • Claude의 소스코드가 유출되었고, 코드 품질이 낮다는 이유로 많은 이들의 조롱을 받음
  • 이 문제의 원인으로 도그푸딩(dogfooding)의 과잉, 즉 자사 제품을 지나치게 맹목적으로 사용하는 문화가 지목됨
  • 독식 자체는 좋은 아이디어이지만, 어떤 합리적 한계도 넘어서는 컬트적 활동으로 변질될 수 있음

바이브 코딩의 실체

  • 바이브 코딩은 코드 내부에 어떤 기여도 하지 않고, 심지어 들여다보지도 않는 것을 원칙으로 삼는 방식
  • 그러나 순수한 바이브 코딩은 미신(Myth) 임 — 실제로는 계획 파일(할 일 목록), 스킬, 규칙 등 인간이 만든 프레임워크가 반드시 존재하며, 이 구조 없이 AI는 매우 낮은 성능을 발휘함
  • 코드는 영어로 작성되어 있어 누구나 읽을 수 있음에도, "내부를 보는 것은 반칙"이라는 논리로 개발자들이 직접 확인을 거부함
  • 실제로 인간 한 명이 코드를 살펴본 결과 에이전트와 툴 사이에 대규모 중복이 존재한다는 사실이 발견되었으며, 이는 누군가가 잠깐만 살펴봤다면 쉽게 인지할 수 있는 문제였음

AI와 기술 부채 정리

  • 소프트웨어 프로젝트는 흔히 기술 부채를 안고 출발하며, 과거에는 이를 정리하는 데만 1년이 걸리는 경우도 있었음
  • AI를 활용하면 이 정리 작업을 수 주 만에 완료하거나, 새 기능 개발과 병행하면서 점진적으로 해소할 수 있음
  • AI는 코드 정리에 매우 뛰어나지만, 스스로 문제를 감지하는 능력은 부족함 — 인간이 "여기 스파게티 코드가 있다"고 알려주고 가이드를 제공할 때 좋은 결과가 나옴

올바른 AI 활용 방식 — 대화 기반 접근

  • 중복 문제를 해결하는 올바른 방법으로, 다음과 같은 단계를 제시:
    • 에이전트와 툴 양쪽에 해당하는 항목 목록 작성
    • 예시 검토 후 각 항목이 에이전트인지 툴인지 판단
    • 전체 기준 논의 및 일반 가이드라인 수립
    • 전체 항목 감사 후 잘못 분류된 항목 수정
    • 양쪽에 모두 존재하는 항목은 두 버전을 검토해 하나로 통합
  • Ask 모드가 이 과정을 위한 것으로, 예시를 함께 검토하고 AI가 지나치게 동의하려 할 때 잘못된 부분을 바로잡는 과정이 핵심
  • 충분한 대화 후에는 AI가 원샷(one-shot)처럼 보이는 결과를 냈다고 느낄 수 있지만, 실제로는 사전에 인간과의 많은 상호작용이 전제된 결과임
  • Claude 팀은 이 과정 없이 독식을 극단적으로 적용해, 코드 내부를 잠깐 살피고 문제를 설명하는 최소한의 노력도 거부하고 있음

실제 활용 사례

  • 본인의 워크플로우 예시: 대화 시작 시 "이 코드베이스에서 도달 불가능한 코드를 감사하자" 또는 "이 함수는 눈이 아프다"고 말하며 대화를 시작함
  • 실행 가능한 방향이 나올 때까지 대화를 계속하고, 해야 할 일을 설명한 뒤 AI가 어리석은 말을 멈출 때까지 계속 논의함
  • 이후 계획을 세우고 빌드를 실행하는 것이 일상적인 방식

소프트웨어 품질은 선택의 문제

  • AI를 사용한다고 해서 낮은 품질의 소프트웨어를 감수해야 하는 것은 아님
  • AI 도움 없이 과도한 보수를 받는 개발자들이 만든 라이브러리도 나쁜 품질일 수 있음
  • 나쁜 소프트웨어는 스스로 내리는 결정이며, 이에 대한 책임을 져야 하고 더 나은 품질을 추구해야 함

함께 보면 좋은 글 β

▲
koreacglee 1시간전  [-]

AI AGENT 로 FULL AUTO MATION 하면서 코드 생성, 머지, 리뷰, 검증까지 완전 자율화 시켜 코드구성 되고 신경 1도 안써도 가끔씩 에이전트 끼리 꼬였을때나 개발자가 개입하는 수준이면 다된다고 그렇게 하지 못하는 개발자들을 트렌드 못따라가는 비정상 취급하는 분위기가 남발되더니...평소에 얼마나 보일러플레이트한 코드를 남발하고 단순 패턴 연속의 코드를 짜면서 고연봉 쳐받고 있다가, AI 로 더이상 코드 안짜도 된다고 입터는것 들 보면 한심 그자체

답변달기
▲
summerpicnic 14분전  [-]

바이브 코딩이 곧 코드 리뷰 안함 으로 결론 내리고 이유 같다붙이는식의 비난 같음

거기다 claude code를 갖다붙이는것도 말이 안됨 그정도의 퀄리티 따지는 이를테면 리눅스 유지보수급의 엔지니어링 원칙을 따진다면 코드 품질 문제를 이런식으로 단편적으로 접근하지 않음 거의 대부분이 프로파간다적 접근 직접 테스트해본게 아닌 그렇더라식

마치 삼성 건물 디자인이 별로라고 아직 소니 따라잡으려면 멀었다라고 말하는것과 비슷

답변달기
▲
qwertypotter 6시간전  [-]

dogfooding은 독식이 아니라 도그푸딩으로 보는게 낫겠습니다.

답변달기
▲
GN⁺ 8시간전  [-]
Hacker News 의견들

  • 사람들이 Claude Code의 유출된 소스 품질을 예로 들며 ‘vibe coding’이 실패했다고 말하는 게 이상함
    오히려 그 반대임. 전통적인 “좋은 코드” 규칙을 어기면서도 인기 있고 성공적인 제품을 만들 수 있다는 증거라고 생각함

    • 내가 본 대부분의 제품 코드도 처음 보면 충격적이었음. BigCo에서도 스타트업에서도 마찬가지였음
      마감기한 때문에 임시방편으로 만든 코드가 그대로 프로덕션에 남는 경우가 많음
      개인 프로젝트에서도 첫 커밋들은 엉망이고, 나중에야 정리 브랜치를 만들어 다듬음
      하지만 회사에서는 두 번째, 세 번째 초안을 만들 시간이 거의 없어서 결국 첫 초안이 배포됨
      솔직히 내 이름이 붙은 코드가 유출될까봐 걱정되기도 함. 하지만 이게 현실임
    • 나쁜 코드는 짧은 기간엔 잘 돌아가지만, 장기적으로는 반드시 문제를 일으킴
      코드 변경 시 “이건 좀 억지 같다”는 느낌이 들면 그때 바로 고치는 게 결국 시간을 아끼는 길임
      LLM에 대해서는 아직 경험이 많지 않아서 확신은 없음
    • “좋은 코드 규칙을 어겨도 성공할 수 있다”는 건 사실 예전부터 늘 그랬음
    • “Vibe coding”은 인간의 개입 정도에 따라 스펙트럼이 있음
      Claude Code는 본질적으로 단순한 제품이고, 진짜 가치는 모델 자체에 있음
      즉, 코드 품질이 낮아도 큰 문제가 되지 않는 저위험 제품이라서 이런 사례가 가능했음

  • “Vibe coding” 개념을 위반한 것도 아님. 고수준의 추상적 아이디어만 주고 실제 코드는 AI가 작성하는 구조임
    Claude Code는 AI Level 7 (인간이 스펙, 봇이 코드) 수준이고, 작성자는 Level 6이 더 낫다고 주장함
    사람마다 이상적인 수준이 다름. 어떤 이는 Level 5 이하가 한계라고 보고, 어떤 이는 Level 2 이상은 위험하다고 생각함

    • 내가 하는 컴퓨터 비전 분야에서는 UI나 앱은 Level 6~7 정도지만, 렌더링 파이프라인이나 알고리즘은 오히려 AI 개입이 방해됨
      분야의 복잡도와 새로움에 따라 적절한 수준이 달라짐
    • AI를 잘 활용하는 핵심은 부분별로 다른 수준을 적용하는 것임
      예를 들어, 내가 만드는 앱은 알고리즘 부분은 Level 0, UI는 Level 7, 미들웨어는 그 중간쯤임
      각 코드 영역에 맞는 수준을 찾는 게 진짜 기술임
    • 나는 Level 5 정도에서 작업 중임. TDD, 타입 안정성, 스펙 작성 등으로 안전장치를 많이 둠
      동적 언어에서는 이 이상은 불안함. 만약 Level 7 이상으로 간다면 정적 타입 언어로 완전히 전환하는 게 낫다고 생각함
    • 앞으로 가장 발전할 사람들은 이 스케일의 최고 수준까지 밀어붙이는 개발자들일 것임
      코딩은 이제 대장장이처럼 일부만 남고 대부분은 자동화될 것임
      하지만 그 덕분에 한 명이 예전 팀 전체가 하던 일을 할 수 있게 될 것임
    • 회사에서는 Level 4지만, 개인 프로젝트는 슬그머니 Level 6까지 올라감
      작동 원리를 완전히 이해하지 못한 채 기능을 받아들이는 유혹이 큼

  • 이 글의 작성자는 BitTorrent 창시자임. 단순한 블로거가 아님

    • Bram이 다시 이런 논의에 참여하는 걸 보니 반가움
    • 대부분은 BitTorrent가 뭔지도 모르지만, 그래도 ‘vibe’는 느끼는 듯함
    • 그의 경력을 생각하면, 주장에 대한 근거 제시는 좀 더 있었어야 한다고 생각함

  • 내가 Claude Code를 가장 좋아하는 용도는 코드 품질 개선임
    사람이 하면 시간 낭비로 보일 일도 AI가 거의 무료로 해주니까 괜찮음
    반복적인 테스트 패턴 정리, JSON 직렬화 일관성 유지, 중복 코드 제거 등
    결과적으로 코드베이스가 작아지고 유지보수가 쉬워짐. 일종의 대규모 린팅 같음

    • 나도 비슷하게 여러 모델(Opus, GPT5.4, Gemini)을 병렬로 돌려 버그 탐지와 코드 개선을 시킴
      각 모델이 만든 결과를 교차 검증하고, 마지막엔 Opus가 최종 리스트를 만들어 수정함
      불필요한 변경이 많긴 하지만, 잡아내는 문제들이 실제로 유용함

  • “Dogfooding” 관점이 흥미로움
    논점은 코드 품질이 아니라, 사용자가 AI 결과를 비판적으로 평가할 수 있느냐임
    경험 많은 엔지니어가 판단력을 유지하며 AI를 쓰는 것과, 판단을 AI에 맡기는 건 완전히 다름
    문제는 도구가 이 둘을 구분하지 못하고, 마케팅은 후자에게 맞춰져 있다는 점임

  • ‘Vibe coding’을 지지하는 사람들은 LLM이 인간보다 훨씬 빠르게 반복(iteration) 할 수 있으니 코드 품질은 중요하지 않다고 주장함
    인간은 각 단계(작성–검증–수정)의 비용이 높지만, LLM은 토큰 비용만으로 빠르게 반복 가능함
    하지만 나는 이런 접근에 회의적임. 실제로 깨지는 사례를 너무 많이 봤음
    그래도 LLM이 더 발전하면 그들의 말이 맞을 수도 있음

  • “Vibe coding” 스펙트럼에는 두 부류가 있음
    하나는 기술적 배경이 없지만 신기해서 좋아하는 사람들, 다른 하나는 AI 혐오자들임
    그 사이에는 조용하지만 생산성 높은 중간층이 있음. 이들은 낙관적이면서도 경험이 풍부함
    나도 지난 6개월간 Claude Code 크레딧을 약 $2500어치 썼는데, 대부분은 실제 배포되지 않음에도 엄청난 가치를 얻었음

    • “생산성 향상”을 어떻게 측정하냐는 질문이 있음. 정량화가 어렵지만 체감은 분명함

  • “Claude Code는 쓸모없다”는 주장에 동의하지 않음
    대부분의 웹앱은 단순한 CRUD 수준임. 99%의 회사는 5만 명의 사용자를 갖지도 못함

    • 기업용 앱은 사용자 수는 적지만, CPU나 DB 부하가 훨씬 큼
      내가 일했던 회사는 비효율적인 코드 때문에 하루 22시간씩 프로그램을 돌려야 했음
    • “사용자”와 “유료 사용자”는 구분해야 함. 의미가 다름
    • 사실 100명에게 배포하는 것도 이미 지옥 같은 일임. ‘시민 개발자’ 시대는 오지 않을 것 같음

  • 이 현상은 Clayton Christensen의 혁신 이론을 떠올리게 함
    기존 기업은 수익성이 높은 현재 제품에 안주해 새로운 저품질 기술을 무시하지만, 결국 그 기술이 충분히 발전해 시장을 뒤집음
    Claude Code도 이미 “충분히 괜찮은” 수준이고, AI가 계속 발전한다면 결국 수작업 코드를 능가할 것임

    • 설령 AI 발전이 멈춰도, 우리는 현재 모델을 중심으로 한 새로운 툴링과 패턴을 만들어낼 것임
    • 하지만 지금 분위기는 너무 낙관적임. 경영진이 테스트와 코드 리뷰를 없애려는 얘기까지 나옴. 위험을 과소평가하는 듯함

  • ‘Vibe coding’을 둘러싼 사람들은 몇 부류로 나뉨
    ① 금전적 이해관계자, ② 코딩에 지친 개발자, ③ 처음으로 무언가를 만들어보는 신입
    ②는 새로운 걸 배우기 싫어하고, ③은 진심으로 창작의 즐거움을 느끼는 중임
    AI 코딩은 이들에게 좋은 입문 경로가 될 수 있음

    • 여기에 또 다른 그룹이 있음. 코딩을 사랑하지만 더 많은 걸 만들고 싶은 고성과자들임
      나도 그런 부류임. 30년 동안 코딩을 사랑했지만, 상상한 걸 구현하는 데 걸리는 시간이 너무 길었음
      이제는 그 격차가 사라져서 해방감을 느낌. 품질을 유지하면서 속도를 높이는 법을 배우는 게 목표임
    • 나도 뛰어난 엔지니어들이 AI를 적극적으로 활용하면서도 기준을 낮추지 않고 더 많은 결과를 내는 걸 봤음
    • 사실 지난 10년간의 소프트웨어 산업은 불필요한 복잡성의 시대였음
      대기업의 문제를 그대로 따라 하느라 생산성은 떨어지고 피로감만 늘었음
      이제는 AI 덕분에 이런 복잡성을 무시하고 바로 결과를 얻을 수 있음
      새로운 프레임워크나 배포 방식이 나와도 신경 쓸 필요 없음. AI가 다 처리함
    • 하지만 혹시 당신이 말하는 “배우기 싫은 사람들”이 아니라, 오히려 새로운 걸 배우는 사람일 수도 있음
      기술 세대 교체가 일어날 때마다 이런 갈등이 반복됨
    • 개인적으로는 요즘의 품질 저하(sloppiness) 가 오히려 흥미를 잃게 만듦
답변달기