▲

바이브 코딩의 마법을 깨기

 (fast.ai)
1P by GN⁺ 10시간전 | ★ favorite | 댓글 1개
  • AI가 생성한 복잡한 코드 대량 생산이 확산되며, 인간이 읽지 않는 코드를 만드는 현상이 업계 전반에 퍼지고 있음
  • 경영진은 AI로 인한 인력 감축을 정당화하고, 개발자들은 AI가 만든 코드 비율을 채우라는 압박을 받는 상황
  • 이러한 ‘바이브 코딩’은 도박의 중독 메커니즘과 유사한 ‘다크 플로우(dark flow)’ 상태를 유발, 생산성 착각을 일으킴
  • 실제로 AI 코딩 도구 사용 시 생산성이 20% 향상된다고 느끼지만 실제로는 19% 느려지는 연구 결과가 있음
  • AI는 유용하지만, 사람의 사고·창의·소프트웨어 엔지니어링 능력은 대체되지 않으며, 이를 포기하면 오히려 퇴보 위험이 있음

바이브 코딩의 확산과 문제 인식

  • 바이브 코딩은 AI가 생성한 복잡한 코드를 대량 생산하는 행위로, 인간이 읽거나 유지보수하기 어렵게 만듦
    • 일부 기업은 AI가 인간의 일을 대신할 수 있다며 해고를 정당화
    • 개발자들은 AI 생성 코드 비율을 채우지 못하면 성과 평가에서 불이익을 받는 압박을 받음
    • 학생과 직장인 모두 “AI가 곧 내 일을 대체할 것”이라는 불안 속에 자기계발을 주저하는 현상 발생
  • AI는 실제로 유용하지만, 바이브 코딩에는 주의가 필요하며 잘못 사용될 경우 부정적 결과 초래

‘플로우’와 ‘다크 플로우’의 차이

  • 심리학자 Mihaly Csikszentmihalyi가 정의한 ‘플로우’는 도전과 기술이 균형을 이루는 몰입 상태
  • 반면 도박처럼 기술과 무관한 활동에서도 몰입감이 생길 수 있으며, 이는 ‘가짜 플로우’ 에 해당
    • 슬롯머신의 Loss Disguised as a Win (LDW) 사례처럼, 실제로는 손실이지만 승리한 듯한 착각을 유도
    • 연구에 따르면 LDW는 실제 승리와 유사한 생리적 반응을 일으켜 중독적 몰입을 강화
  • 이러한 현상은 ‘다크 플로우(dark flow)’ 또는 ‘정크 플로우(junk flow)’ 로 불리며, 성장 없는 중독적 몰입을 의미

바이브 코딩과 도박의 유사성

  • 개발자 Armin Ronacher는 AI 코딩 도구 사용 후 많은 코드를 만들었지만 실제로는 거의 사용하지 못함을 언급
    • 이는 도박의 ‘가짜 승리’ 와 유사한 착각 구조
  • 바이브 코딩은 다음과 같은 점에서 플로우의 조건을 위반
    • 성과에 대한 명확한 피드백 부재, 오히려 잘못된 성취감 제공
    • 도전 수준과 기술 수준의 불균형
    • 통제 illusion을 통해 사용자가 결과를 조종한다고 믿게 함
  • AI가 생성한 코드의 품질은 수주 후에야 문제를 인식하는 경우가 많으며, 버그와 유지보수 불가능한 복잡성이 뒤늦게 드러남
  • LLM과 슬롯머신 모두 사용자의 심리 반응을 극대화하도록 설계, 지속 사용을 유도

생산성 착각과 ‘신뢰할 수 없는 화자’

  • METR 연구에 따르면, AI 도구 사용 개발자는 20% 더 빠르다고 느꼈지만 실제로는 19% 느림
    • 이는 인지된 효율과 실제 효율 간 40% 차이를 의미
  • AI로 작성된 글 역시 겉보기에는 유사하지만 품질이 떨어지는 경우가 있음
    • 한 AI 연구자의 블로그 글이 AI로 작성된 후 이전보다 덜 읽기 쉬운 문체로 변함
  • 사람들은 자신의 생산성을 객관적으로 평가하기 어렵고, AI 사용 후 과대평가하는 경향

잘못된 예측과 경력 위험

  • AI가 코딩을 완전히 대체할 것이라는 예측은 반복적으로 빗나감
    • Geoffrey Hinton은 2021년까지 AI가 방사선 전문의를 대체할 것이라 예측했으나 실현되지 않음
    • Google의 Sundar Pichai와 Jeff Dean은 2023년까지 모든 데이터 과학자가 자동 신경망 설계 도구를 사용할 것이라 했으나 불발
    • Anthropic의 Dario Amodei는 2025년 말까지 AI가 전체 코드의 90%를 작성할 것이라 예측했으나 근거 없음
  • 이러한 과장된 전망에 따라 자기 기술 개발을 중단하는 것은 위험
    • AI 발전 속도는 실제보다 지속적으로 과대평가되어 왔음

인간의 사고와 창의성의 지속적 중요성

  • AI 코딩 에이전트는 문법적으로 올바른 코드를 생성하지만,
    • 유용한 추상화, 모듈화, 코드 구조 개선은 수행하지 못함
    • 즉, 코딩은 자동화되었지만 소프트웨어 엔지니어링은 자동화되지 않음
  • AI가 생성하는 텍스트도 문법적으로 자연스럽지만, 사고를 정교하게 다듬거나 핵심을 파악하지는 못함
  • Jeremy Howard는 “AI에 사고를 완전히 위임하면 학습과 성장 능력을 잃게 된다”고 경고
    • AI는 도구로서 유용하지만 인간의 핵심 역량을 대체하지는 못함
▲
GN⁺ 2시간전  [-]
Hacker News 의견들
  • AI를 너무 많이 쓰는 위험과 너무 적게 쓰는 위험 중 어느 쪽이 더 큰지 고민 중임
    지금은 전자가 훨씬 위험하다고 느낌. 헛소리 버그, 막다른 아키텍처, 보안 문제, 코드 소유감 저하, 학습 기회 상실 등이 있음
    반면 AI를 덜 쓰면 생산성은 떨어지지만, 코드베이스에 대한 깊은 이해와 훈련이 장기적으로 더 큰 자산이 될 수도 있음
    개인적으로는 코드 속에서 직접 부딪히며 얻는 창의적 아이디어가 가장 가치 있다고 생각함
    AI에게 너무 일찍 맡기면 이런 기회를 잃는다는 점이 아쉬움
    • AI 보조 코딩 중에도 기준을 낮추지 않으면, 오히려 더 깊이 몰입하게 됨
      반복 작업을 덜 하니 머리가 덜 피곤하고, 어려운 문제에 집중할 수 있어 더 좋은 아이디어가 떠오름
      핵심은 좋은 취향과 기준을 유지하는 것임
    • 에이전틱 코딩을 시도하다가 막다른 아키텍처로 유도된 적이 있음
      미리 설계와 문서를 세밀히 준비해두면 성공률이 높았음
      코드 생성 자체보다 계획과 설계 단계가 진짜 어려운 부분임
      대신 LLM으로 문서화나 보일러플레이트 작성은 큰 시간 절약이 됨
    • 사람마다 AI 코딩을 쓰는 방식이 천차만별임
      어떤 사람은 앱을 한 번에 완성하려 하고, 어떤 사람은 단순 자동완성 수준으로만 씀
      계속 새로운 방식이 등장하니 열린 마음으로 다양한 시도를 해보는 게 최선임
    • “AI를 너무 많이 vs 너무 적게”라는 프레임은 잘못된 접근이라고 생각함
      새로운 기술은 항상 작은 단위로 검증하고 점진적으로 확장하는 게 정석임
      AI 사용량은 ‘검증된 만큼’이 정답임
      이런 논의를 파스칼의 내기처럼 몰고 가는 건 슬픈 일이며, 대개는 뭔가 팔려는 사람들의 논리임
  • 회계 자동화 툴을 만드는 입장에서 Vibe 코딩은 재앙임
    AI가 코드를 잘 쓰더라도, 세금 계산의 미묘한 오류처럼 보이지 않는 실패 모드가 가장 위험함
    실제 회계 시스템에 잘못된 숫자가 조용히 반영될 수 있음
    그래서 AI는 고급 자동완성 도구로만 사용함 — 아키텍처와 도메인 로직은 직접 설계하고, 반복 코드나 테스트 스캐폴딩에만 씀
    결국 문제는 “AI가 쓴 코드”가 아니라, 내가 직접 이해하지 못한 코드임
    • 실패 모드가 안 보이는 건 사람 코드도 마찬가지임
      • 오히려 이런 위험이 리스크 관리 부재를 드러내는 계기가 될 수도 있음
    • 이런 문제는 결국 테스트 부족의 문제임
      • 사람이 쓴 코드든 AI 코드든, 테스트가 없다면 실패는 보이지 않음
    • 세금 계산 오류는 복식부기 시스템이 잡아내지 않느냐는 질문도 나옴
    • 어떤 사람은 “나는 복잡한 작업도 문제없이 AI로 처리한다”며, 결국 프롬프트 실력의 차이라고 주장함
    • 또 다른 사람은 “그런 문제는 아키텍처적으로 해결해야 한다”며, 감사 가능성과 롤백 구조가 핵심이라고 말함
  • “코딩은 자동화됐지만 소프트웨어 엔지니어링은 아니다”라는 말에 깊이 공감함
    LLM은 함수 작성은 잘하지만, 어떤 함수가 필요한지 결정은 못함
    실제 프로젝트의 아키텍처는 현실의 병목을 부딪히며 만들어진 것임
    AI가 도와준 건 구현 속도뿐, 구조적 판단은 전적으로 사람 몫임
    특히 도메인 버그는 LLM이 절대 잡지 못함
    결국 아키텍처와 도메인 지식은 사람이 책임져야 함
    • 누군가는 “LLM에게 아키텍처 설계 자체를 물어봤냐”고 반문함
      단순히 ‘코드 작성’만 시키면, 그건 목표가 아니니 당연히 못함
    • 또 다른 사람은 “AI 덕분에 손목 통증이 줄었다”며 현실적인 장점을 언급함
  • AI 연구자들의 예측 때문에 자기 성장 투자를 멈출 필요는 없다고 생각함
    나는 지난 1년간 소프트웨어 설계와 Vibe 코딩을 동시에 배웠음
    DDD, Clean Architecture, Agile 등 여러 책을 공부하며 훨씬 나은 엔지니어가 되었음
    AI를 쓰더라도 코드 책임은 여전히 내 몫임
    두 영역을 함께 성장시킬 수 있음
    • AI 코딩 보조를 잘 쓰는 것도 하나의 숙련된 기술임
      시간 투자와 연습이 필요하지만, 배울 가치가 크고 다른 기술을 대체하지 않음
    • 나도 비슷하게 소프트웨어 설계 철학과 데이터 중심 설계 같은 책을 골라 읽음
      LLM이 잘 못하는 건 고수준의 판단과 구조 설계이기 때문임
      잘 설계된 시스템은 AI의 효율을 극대화함
      또한 새로운 패러다임 학습은 LLM이 만든 코드를 더 잘 판단하고 개선하게 해줌
      BDD, PBT, 모델 검증 같은 기법은 AI 코딩을 더 안전하게 만드는 도구임
    • 한편, 20년 경력자는 “DDD는 쓸데없다”며 과감히 버리라고 조언함
    • 누군가는 “세 권의 DDD 책 중 어떤 게 제일 유용했냐”고 묻기도 함
  • Claude Code로 복잡한 프로젝트를 두 번 진행했는데, 처음엔 놀라운 속도였지만 결국 치명적 가정 오류로 모든 이득이 사라졌음
    겉보기엔 승리처럼 보여도, 실제로는 패배를 가장한 승리였음
    이에 누군가는 “그 묘사가 마치 약물의 고조와 추락 같다”며 비유함
  • 좋은 프로그래머라고 해서 좋은 아키텍트나 디자이너, PM은 아님
    LLM을 제대로 활용하려면 이 세 역할의 근육이 모두 필요함
    • 다른 사람은 “좋은 엔지니어라면 이미 좋은 PM과 아키텍트여야 한다”고 반박함
    • 또 어떤 이는 “UI 디자이너의 ‘좋은 디자인’이 실제 사용자와 어긋난다”며, 획일적 디자인 문화를 비판함
    • 누군가는 “결국 아키텍트·디자이너·매니저 일을 하면서도 개발자 대우만 받는다”고 꼬집음
  • 성공의 핵심은 성공 기준을 구체적으로 정의하는 능력임
    원하는 UI/UX를 명확히 그릴 수 있다면, 현재 모델로도 충분히 좋은 결과를 얻을 수 있음
    반대로 “대충 만들어줘”식의 프롬프트는 위험함
    AI는 고급 메카 슈트처럼 다뤄야 함 — 사람이 루프 안에 있어야 진짜 빠름
  • 2017년 GPT는 그럴듯한 가짜 텍스트를 만들었지만, 2023년에는 완전히 달라졌음
    기술 발전 속도가 너무 빨라서, 작년엔 어려웠던 일이 지금은 사소해짐
    내부에서 쓰던 AI 도구조차 오픈소스 모델로 대체되고 있음
    지금은 마치 “AI판 Don’t Look Up” 같은 시기라 느껴짐 — 모두가 늦기 전에 AI 시대에 맞게 자신을 재배치해야 함
  • 사람마다 AI 코딩 접근법이 다르지만, Armin의 말처럼 방향성 없는 Vibe 코딩은 위험함
    친구가 3개월 동안 Cursor로 제품을 만들었지만, 기능만 많고 쓸모는 없었음
    결국 코드를 이해하는 사람의 부재가 문제였음
    • 나는 AI를 반복 작업과 버그 브레인스토밍에만 씀
    • AI는 코너 케이스 처리엔 일관성이 좋아서, 나는 설계와 아키텍처에 집중함
  • 코드를 생성하고 검토조차 안 하는 개발자들이 있다는 게 놀라움
    기본적인 정신적 검증(sanity check) 조차 안 하는 건 이해하기 어려움
    • 어떤 사람은 “AI 코드가 대부분 맞으니 결국 검토 피로감이 생긴다”고 함
      • 문제는 코드보다 아키텍처적 패턴에 숨어 있음
    • 또 다른 사람은 “IBM 연구에 따르면 설계 단계에서 고치는 게 15배 싸다”며, 검증을 초기에 하라고 조언함
    • 누군가는 “그런 사람들은 진짜 개발자가 아니다”라고 단언함
    • 또 다른 사람은 “하위 계층이 너무 신뢰할 만해져서 그런 듯”이라며,
      • 마치 우리가 컴파일된 바이너리를 직접 확인하지 않듯, AI도 그럴 거라 착각한다고 분석함
답변달기