요즘은 바이브 코딩이 처음 이야기 되었을 때와는 달리 너무 다양한 개념으로 용어가 사용되는 것 같다는 생각이 듭니다. 바이브 코딩을 Andrej Karpathy가 언급 했을 때는 제가 기억하기로는 아이디어가 떠오르는 대로 에디터에 지시해서 개발자가 감독자로서 결과물의 방향을 잡아 나간다는 내용이었습니다. 그러나 어느 순간 AI를 활용한 모든 개발 방식에 사람들이 바이브 코딩이라는 용어를 붙이게 되었고 지금은 각자가 사용하는 바이브코딩의 의미가 너무 상이한 것 같다는 생각이 듭니다. 약간의 재미 삼아서 제가 들여다 보는 커뮤니티들에서 느낄 수 있는 관점을 정리해보고자 합니다.
엔지니어의 관점:
바이브 코딩 자체에 대해서 회의적인 시선을 가지신 분들이 꽤 있습니다. 실제로 바이브 코딩만으로 완성도 있는 프로덕트를 만드는 것에는 한계가 있는 것도 사실입니다. 그렇다고 AI를 활용하는 것에 게으르지는 않습니다. Agentic AI 를 활용한 코딩 방법론들을 많이들 시도하고 계시고 최근에는 Kiro나 Github Spec Kit 등을 활용한 SDD(Spec Driven Development)가 뜨고 있습니다.개발자 커뮤니티에서는 대체로 이러한 방법들과 바이브 코딩이라는 용어를 구분하려는 경향이 느껴집니다. 저도 엔지니어로서 이러한 구분에 꽤 동의를 하고 있습니다. 아무리 인공지능을 활용하여 70~80%의 완성도로까지 끌어올린다고 하여도 나머지 20~30%는 결국 엔지니어가 개입하여 마무리를 해야하기 때문에 바이브 코딩이 만능처럼 여겨지는 분위기에는 회의적인 경향이 있습니다.
디자이너의 관점:
디자이너분들의 경우는 해당 용어를 폭넓게 활용하시는 것으로 보입니다. 바이브 코딩이 아니더라도 AI를 활용해서 프로덕트와 관련된 작업을 하는 경우 "바이브" 라는 용어를 수식어 처럼 붙여서 사용하시는 경우가 많이 관찰됩니다. (브랜딩적인 측면도 있어 보입니다)기존의 엔지니어를 통하지 않으면 실제로 해보기 어려웠던 영역들이 바이브 코딩으로 인해 진입장벽이 많이 낮아진 것이 사실이며 이를 적극 활용하고 계신것으로 보입니다.다만 이와 동시에 Look&Feel 이나 UI의 영역 또한 비디자이너의 직군에게도 진입장벽이 다소 낮아져 실존적인 위기의식도 많이 가지고 계신것으로 보입니다.그리고 여전히 바이브 코딩으로 채우기 어려운 20~30% 이상의 영역에 대해서 고민이 많은 것으로 보이고 이를 위해서 예전보다 좀 더 AI툴에 대한 다양한 시도나 엔지니어적인 접근이 이루어지고 있는 것으로 보입니다.
시간이 흐르면 바이브 코딩이라는 용어가 어느정도 서로의 합의에 의해 좀 더 명확해 질 것이라 생각이 됩니다.
저는 개인적으로 엔지니어들에게는 UX에 대한 이해를 강조해왔고 디자이너 분들에게 엔지니어 영역으로 과거보다는 훨씬 많이 넘어오셔야한다고 강조해 왔었던지라 이 바이브 코딩이 가져다준 효과는 각자의 해석과는 상관없이 매우 긍정적으로 느껴집니다.
Agentic Design Pattern들이 많이 정리 되고 있는 요즘,프로덕트 빌딩의 골든룰이 어떻게 만들어져 갈지 참 흥미롭습니다.