3P by GN⁺ 2025-02-04 | ★ favorite | 댓글 1개
  • LLM 기반 개발 환경에서 사용자가 직접 코드를 작성하지 않고, 대화와 명령으로 결과를 만들어내는 새로운 방식의 ‘바이브 코딩’ 개념 제시
  • Cursor ComposerSuperWhisper를 이용해 음성 명령으로 코드를 수정하며, “사이드바 패딩을 절반으로 줄여줘” 같은 단순 요청만으로 작업 수행
  • 코드 변경 내역(diff)을 읽지 않고 ‘Accept All’ 로 일괄 승인하며, 오류 메시지는 그대로 복사해 넣어 해결하는 자동 수정 흐름 사용
  • 코드가 점점 복잡해져 이해하기 어려워지지만, 주말용 실험 프로젝트 수준에서는 충분히 작동
  • 두 개의 LLM이 실시간으로 대결하는 Battleship 게임도 같은 방식으로 제작, “4o가 4o-mini보다 강하다”는 관찰 언급

바이브 코딩 개념

  • “바이브 코딩(Vibe Coding)”은 코드 작성 행위보다 흐름과 감각에 집중하는 개발 방식
    • 사용자는 코드의 세부 구조를 신경 쓰지 않고, LLM이 제안하는 결과를 그대로 수용
    • “코드가 존재한다는 사실조차 잊는다”는 표현으로, AI 중심의 개발 경험을 강조

사용 도구와 작업 방식

  • Cursor ComposerSonnet 모델을 활용해 코드 생성을 수행
    • SuperWhisper를 통해 음성으로 Composer와 대화하며, 키보드 입력을 거의 사용하지 않음
  • “사이드바 패딩을 절반으로 줄여줘” 같은 단순 명령으로 수정 요청
    • 코드 변경 내역(diff)을 검토하지 않고 ‘Accept All’ 로 승인
    • 오류 메시지는 별도 설명 없이 복사해 넣으면 대부분 해결됨

코드 관리와 한계

  • 코드가 커질수록 이해하기 어려운 수준으로 복잡해짐
    • 버그가 해결되지 않을 경우, 우회하거나 임의의 수정 요청을 반복해 문제를 제거
  • 이러한 접근은 단기·실험적 프로젝트에는 적합하지만, 복잡한 시스템에는 한계 존재

실험 프로젝트: Battleship 게임

  • 약 한 시간의 “바이브 코딩”으로 Battleship 게임을 제작
    • 두 개의 LLM 모델이 실시간으로 서로 대결하는 구조
    • “4o가 4o-mini보다 강하다”는 비공식적 관찰 결과 언급
  • 구체적인 통계나 성능 비교 수치는 아직 확보되지 않음

전체 맥락

  • LLM의 발전으로 인해 개발자가 세부 코드를 직접 다루지 않고도 작동 가능한 애플리케이션을 빠르게 생성할 수 있음을 보여줌
  • “바이브 코딩”은 AI 중심의 새로운 프로그래밍 패러다임을 실험적으로 드러내는 사례로 평가 가능
Hacker News 의견들
  • 매년 소프트웨어 품질 기준이 더 낮아질 수 없다고 생각하지만, 매번 그 생각이 틀림을 깨닫게 됨

    • 왜 제대로 하지도 않을 일을 굳이 하는지 이해가 안 됨
    • 마치 아무렇게나 못 자른 나무를 못질해 의자 비슷하게 만든 뒤 앉는 것과 같음
    • “그냥 앉을 자리만 필요할 때도 있음” 이라는 말도 있지만, 그래도 최소한의 완성도는 있어야 한다고 느낌
    • 어떤 사람들은 영어에 자신이 없어 LLM에 완전히 의존하게 되었는데, 그 결과 자기 표현력과 자신감을 잃는 걸 봄
    • 소프트웨어에서는 처음부터 ‘의자’를 만든다는 걸 아는 경우가 드묾
      • 결국 탐색적 프로그래밍이나 프로토타이핑의 다른 이름일 뿐임
    • 때로는 목적지가 중요하지 않고, 그냥 빨리 어딘가 도달하고 싶은 마음일 뿐임
      • 피곤해서 잠깐 바닥에 앉는 사람을 꾸짖는 것과 같음
    • 요즘은 코드가 실제 하드웨어에서 실행된다는 현실감이 사라진 것 같아 걱정임
      • 젊은 개발자들이 코드의 물리적 결과를 이해하지 못하는 경우가 많음
      • AI와 그 하이프가 언젠가 무너질 거라 생각하지만, 품질을 지키는 싸움은 계속해야 함
  • 나도 이런 식으로 가벼운 프로젝트를 할 때 즐거움을 느낌

    • 하지만 보안만큼은 절대 대충할 수 없음
    • AI 코딩 어시스턴트가 인증 없는 API를 만들거나, XSS 위험이 있는 템플릿을 생성한 적이 많았음
    • LLM을 매일 쓰지만, 보안 엔지니어의 역할은 앞으로도 충분히 남아 있을 것이라 확신함
  • 이런 접근을 보면, 마치 ‘먹고 코딩하는 사람’ 이 결과물을 제출하는 느낌임

  • 이런 방식으로 코딩을 시작하면 어려운 문제 해결 능력이 퇴화할까 걱정됨

    • 하지만 다른 사람은 여전히 필요한 부분은 수동으로 꼼꼼히 할 수 있다고 말함
    • 대신 새로운 걸 시도하는 진입 장벽이 낮아져서 훨씬 자유롭게 탐색할 수 있음
  • 요즘은 처음부터 이런 방식으로 배우는 AI 네이티브 개발자들이 많아지고 있음

    • 이제는 코딩이라기보다 AI 코더 관리에 가까운 시대가 된 것 같음
  • “자연어 명령으로 수정 가능한 WYSIWYG” 같은 도구는 RAD 툴의 한계처럼 급격한 난이도 절벽이 있을 것 같음

  • 어떤 사람들은 “이런 식으로 배우면 안 된다”고 하지만, 나는 노력 대비 완성도를 맞추는 게 중요하다고 생각함

    • Vibe Coding은 학습과 탐색에 좋은 방법임
    • 새로운 노력–완성도 스펙트럼을 열어줄 수 있음
    • 다만 Fred Brooks의 말처럼, 첫 시도가 부족하면 과감히 버릴 수 있어야 함
      • LLM이 만든 첫 구현에 매달리면 문제를 제대로 이해하지 못한 채 잘못된 기준점에 묶일 수 있음
  • CSS 정도는 Vibe Coding으로 충분하다고 생각함

    • 하지만 다른 사람은 접근성이나 반응형 디자인을 고려하면 그렇게 단순하지 않다고 반박함
    • 잘 만든 CSS는 오히려 간결하고 유지보수하기 쉬움
    • AI를 끼워 넣는 게 오히려 방해가 될 수 있음
    • 또 다른 사람은 Claude로 작은 웹 유틸리티를 완전히 구현해본 경험이 있다고 함
    • 어떤 사람은 React 기반의 검색 DSL이나 GUI 파이프라인 에디터를 같은 방식으로 만들었다며, 이 접근이 단순한 CSS 수준을 넘어선다고 설명함