레딧에서 바이브 코딩에 대해서 찾아보던중 흥미로운 토론 발견..
요즘 **“vibe coding”**이라는 용어가 자주 보이는데, 이게 정말 새로운 개념인지 아니면 단순히 AI 코드 생성을 새롭게 포장한 말인지 궁금합니다.
이 개념은 코드를 한 줄 한 줄 직접 작성하는 것보다는, 만들고 싶은 것을 설명하면 AI가 설정과 구조 대부분을 처리해주는 방식에 더 초점을 두는 것처럼 보입니다. Vitara 같은 도구들은 프롬프트가 개발의 대부분을 이끄는 방식에 강하게 기울어 있고요.
한편으로는 자연스러운 진화처럼 느껴집니다. 우리는 이미 자동 완성, 스캐폴딩, 보일러플레이트 생성 같은 것들을 쓰고 있으니까요. 반면에 “vibe coding”이라는 이름은 실제보다 더 추상적인 무언가처럼 들리기도 합니다.
제가 진짜로 궁금한 건, 이 접근 방식이 장기적으로 사람들이 소프트웨어를 만드는 방식을 바꿀 정도인지, 아니면 프로토타이핑이나 빠른 실험용으로만 유용한지입니다.
속도와 명확성을 실제로 높여주는지, 아니면 복잡성을 숨겼다가 나중에 문제가 되는 구조인지도 궁금합니다.
주말 프로젝트 수준을 넘어서, 이런 방식으로 실제로 작업해본 분들의 의견을 듣고 싶습니다.
기본 개념은 머릿속에 확실히 알고 있어야 합니다.
코드를 “이해하고”, 데이터 설계 개념과 입력·출력을 어떻게 다뤄야 하는지를 알고 있다면, 바이브 코딩은 시간을 절약해주는 도구가 됩니다.하지만 단순히 “XYZ를 만들어줘”라고 지시하는 방식은 결국 어느 순간 한계에 부딪히게 됩니다.
이 의견에 전적으로 동의합니다. 바이브 코딩은 코드를 빠르게 작성하는 데는 매우 유용하지만, 그 코드가 무엇을 해야 하는지에 대한 충분한 이해는 여전히 필수입니다. 그렇지 않으면 원하는 결과를 얻는 데 어려움을 겪게 됩니다.
기본기를 먼저 배우고, 그다음에 바이브 코딩을 활용하세요. 그리고 그 이후에도 결과물은 반드시 오류가 없는지 확인해야 합니다.완전히 공감합니다. 기본 개념을 아는 것이 핵심입니다. AI는 초기 설정이나 보일러플레이트 작업에서 엄청난 시간을 절약해주지만, 데이터 설계, 입력과 출력 같은 근본적인 로직을 이해하지 못하면 결국 문제에 부딪히게 됩니다. 프로토타입을 만들거나 기본 작업을 빠르게 진행하는 데는 훌륭하지만, 복잡한 기능은 여전히 사람의 손길이 필요합니다.
동의합니다. 제가 처음 모바일 앱 개발을 시작했을 때는, 제 코드를 제대로 이해하고 있는지 확인하려고 Mozy에게 정말 기본적인 질문들을 많이 했어요.
“X, Y, Z 기능이 있는 앱에는 어떤 폴더 구조가 적절할까?”
“각 폴더에는 어떤 파일들이 필요하지?”
“각 폴더마다 주석을 달아서 어떤 코드가 들어가야 하는지 설명해줄 수 있을까?”
“코드를 작성하면서 단계별로 자세한 주석도 함께 달아줄 수 있을까?”정말 기초적인 수준이었지만, 덕분에 전체 흐름을 이해하는 데 큰 도움이 됐습니다. 지금은 그냥 유튜브 영상을 보면서 Mozy가 백그라운드에서 코딩하게 두고 있긴 하지만(lol), 모든 AI 도구들이 점점 더 좋아지고 있고, 실수도 훨씬 줄어들고 있는 건 분명합니다.
제가 보기에는, 이것은 새로운 범주라기보다는 사고가 이루어지는 지점이 이동한 것에 더 가깝습니다.
바이브 코딩은 제약 조건을 이미 이해하고 있고, 그것을 명확하게 설명할 수 있을 때 잘 작동합니다. AI는 그저 명백한 부분들을 더 빠르게 처리해줄 뿐입니다.문제는 시스템에 숨겨진 복잡성이 있을 때 발생합니다. 그 복잡성은 사라진 게 아니라, 그저 뒤로 미뤄졌을 뿐이기 때문입니다.
장기적으로 보면, 사람들의 프로토타이핑 방식이나 아이디어를 탐색하는 방식은 바뀔 가능성이 있지만, 실제 프로덕션 작업에서는 여전히 아키텍처와 장애(실패) 시나리오를 논리적으로 고려할 수 있는 사람이 필요합니다. 단순한 “바이브”만으로는 충분하지 않습니다.아직도 더닝–크루거 효과 문제는 그대로 남아 있다고 생각합니다.
저는 기술 분야에서 20년간 PM으로 일했고, 2000년대 초반에 약 4년 정도 개발자 경험도 있습니다. 시스템 설계에는 강한 편이지만, Claude를 제대로 관리하기에는 제가 충분히 알지 못하는 세부 사항들이 정말 많습니다.
제가 기본적으로 당연하다고 여기는 관행들조차도 Claude에게 명시적으로 하나하나 지시해야 한다는 점을 보면, 제가 바이브 코딩으로 만든 것들 안에는 드러나지 않은 문제들이 많이 숨어 있을 거라는 의심이 듭니다.제가 만든 것들은 제 개인적인 필요에 맞춘 문제를 해결하는 개인용 소프트웨어로서는 충분히 좋습니다.
하지만 나무 위 오두막에 전기를 끌어왔다고 해서 그게 콘도가 되는 건 아니죠.즉, 판매를 목적으로 무언가를 설계한다면 고객에 대한 책임이 따릅니다.
AI의 등장으로 인해, 소프트웨어도 언젠가는 다른 공학 분야들처럼 규제를 받게 되지 않을까 하는 생각이 듭니다.
원문
'daily check' 카테고리의 다른 글
| [IT생각] 고객지원용 RAG: 프로덕션에서 깨져보기 전엔 아무도 안 알려주는 기술 이야기 (0) | 2026.01.07 |
|---|---|
| [IT생각] Zapier Sensay CrewAI n8n RAG이 뭘까? 워크플로우 자동화용 AI 스택 탐구 (0) | 2026.01.06 |
| [IT생각] opencode란 무엇일까 (0) | 2026.01.05 |
| [IT생각] Reddit 유저들이 꼽은 2025년 최고의 자동화 (0) | 2026.01.05 |