바이브코딩의 시대, AI가 코드를 짜는 세상에서 인간은 무엇을 할까?

바야흐로, 바이브 코딩의 시대

1. 바이브 코딩(Vibe Coding)이란?

요즘 AI와 개발 분야에서 가장 핫한 용어라고 한다면 단연 바이브 코딩일 것이다.

최초로 바이브코딩이란 용어를 사용한 사람은 OpenAI 창업멤버인 안드레 카파시다. (사진 속 저 분이다)

바이브코딩은 Vive+Coding의 합성어다.
AI의 도움을 받아 코딩을 할 때 논리나 설계가 아닌, 직관과 느낌에 의존하여 코딩한다는 취지로 만들어진 용어인데 요즘에는 그냥 LLM에게 자연어로 '해줘'하면서 코딩하는 것을 총체적으로 바이브코딩이라고 부르는 분위기이다.

머리 아픈 코딩을 그저 '해줘' 한 마디로 할 수 있다니, 이게 얼마나 놀라운 일인가.
그렇기에 바이브코딩은 그 개념이 나온지 1년도 안되서, 개발자와 비개발자 모두에게 엄청난 센세이션을 일으키게 된다.

2. 요즘 개발자들

바이브코딩이 대두되면서 가장 많이 이득 본 부류는 개발자들이다.
과장하자면 예전에는 일주일 걸렸을 개발이 요즘에는 하루나 길어도 이틀이면 되는 수준이다.
당연히 생산성이 올라가니 워라밸이 좋아지고(혹시 일이 더 늘어서 워라밸은 똑같다면 애도한다...) 업무에서 받는 스트레스도 많이 줄었을 것이다.
특히, 직접 코드를 짜는 일은 과거 대비 10% 수준으로 줄었다고 해도 과언이 아닐 것이다.

몇몇 개발자들은 이러한 상황에 현타를 느끼기도 한다.

"내가 직접 코딩하는게 없는데 나 개발자가 맞긴 한가...?"

이런 현타 말이다.
물론 그렇다고 개발자가 AI에게 시키기만 하고 아무것도 안하는 것은 아니다.
예전에는 기능 구현에 할애하던 시간을 아키텍처와 트래픽처리와 같은 AI가 하기 힘들어하는 부분을 고민하는데 할애하게 되었다.
즉, '단순 구현을 위한 코드는 AI가 하고 거시적 관점의 의사결정은 개발자가'
이런 느낌이 요즘 개발 업무의 표준이 되었다. 물론, 폐쇄망이나 보안 이슈로 AI를 제대로 못 쓰는 개발자들도 있을 것이지만, 대체적으로는 저렇다는 얘기다.

3. 기술적 해자의 붕괴, 바이브코더의 양산

"개발 그냥 AI한테 시키면 다 할 수 있는거 아니야?"

개발자라면 요즘 하도 들어서 PTSD가 오는 대사일 것이다.
그리고 실제로 많은 사람들이 저런 얘기를 하기도 한다. 과연 맞는 얘기일까?
내 생각엔 '경우에 따라 다르다'라고 볼 수 있다.
어떤 경우에는 정말 누구나 개발을 할 수 있어 개발자가 필요 없을 수 있고, 어떤 경우에는 그럼에도 개발자가 있어야 하는 경우도 있다.

하지만 확실한 건 비개발자들(디자이너, 기획자, 아니면 정말 업계외 사람)이 바이브코딩을 통해서 실제로 앱을 출시하고 있고, 이를 통해 수익화까지 성공하고 있다는 사실이다.
그 말은 바이브코딩이 '개발'이라는 업무를 수행하는데 있어서 적합한 패러다임이란 것을 증명한다.

결국 바이브코딩의 등장으로 '프로그래밍 언어'라는 기술적 해자가 무너진 것이 현실인 것을 개발자들은 인정할 수 밖에 없는 상황이다.
과거 개발자의 전유물이었던 '프로그래밍 언어'가 '자연어'로 대체되는 길목에 우리는 서있는 것이다.

이제 개발자는 진짜 끝난걸까?

1. 개발자 채용 시장 현황

경제적 상황과 맞물린 것도 있겠지만, 실제로 요즘 개발자 시장은 좋지 않다. 특히, 신입 채용은 거의 빙하기 수준으로 취업이 힘든 상황이다.

하지만 단순히 “불황이라서”만은 아니다.
개발의 패러다임 자체가 달라지고 있기 때문이다.

예전에는 기능 하나를 구현하기 위해 2~3명의 개발자가 투입됐다면,
이제는 AI가 1명의 개발자를 보조하면서 훨씬 빠른 속도로 동일한 결과물을 만들어낸다.
기업 입장에서는 생산성이 두 배 이상 높아졌으니, 굳이 인력을 예전만큼 많이 뽑을 이유가 없다.

또한 최근 몇 년간 바이브코딩 애플리케이션들의 등장으로 ‘기능 구현’ 자체의 기술적 진입장벽이 크게 낮아졌다.
이전에는 단순 CRUD조차 개발자 몫이었지만, 이제는 비개발자도 “해줘” 한마디로 어느 정도 완성된 프로토타입을 만들 수 있는 시대다.

결국 기업이 필요로 하는 개발자는 ‘코드를 많이 치는 사람’이 아니라 AI를 활용해 더 큰 구조를 설계하고, 문제의 본질을 파악할 수 있는 사람으로 바뀌고 있다.

즉, 개발자 시장의 위축은 기술이 발전한 결과이지, 개발자의 가치가 사라졌기 때문이 아니다.
개발자라는 직업의 정의가 단순히 ‘코드를 짜는 사람’에서
‘AI를 포함한 시스템 전체를 이해하고 설계하는 사람’으로 재정의되고 있는 것이다.

경력개발자 채용시장은 아직 비교적 활발한 것이 그에 대한 반증이라 볼 수 있다.
그리고, 신입 취준생은 이런 패러다임 변화에 대해서 고민하여 취업 전략을 다시 생각해볼 필요가 있다.

2. 개발자가 가지는 차별점

바이브코딩 시대의 개발자는 비개발자와 어떤 차별점이 있을까?

예를 들어 렌딩페이지를 만든다고 치자. 이 경우는 위에 언급했던 누구나 개발할 수 있는 케이스다. 어떤 내용으로 만들고 싶은지만 명확히 기획되어 있으면 누구나 바이브코딩을 통해 짧으면 10분 내외로 배포까지 할 수 있다.
예전에는 개발자의 영역이었던 분야가 바이브코딩으로 인해 비개발자 영역으로 확대된 것이다.
이 경우에는 개발자가 비교우위에 있다고 보기 어렵다. 오히려 디자이너들, 혹은 번뜩이는 아이디어가 있는 기획자들이 더욱 완성도 높은 홈페이지를 완성시킬 가능성이 높다.

그럼 반대로 그럼에도 개발자가 있어야 되는(그래서 채용을 계속 하는) 경우는 어떤 것일까?
내 생각엔 '맥락'이 있어야 하는 애플리케이션의 경우가 바로 개발자가 차별점을 가질 수 있는 케이스다.
단적으로 표현하면 '엔터프라이즈급' 애플리케이션을 만드려면 아직 개발자의 손길이 필요하다.

엔터프라이즈급 애플리케이션에는 고려해야 될 것들이 무수히 많다.
그 중 간단하게 하나의 사례만 떠올려봐도

"데이터는 어떤 정책으로 관리되어야 하지"

이런 사례는 AI가 하기 힘든 분야다. 왜냐하면 애플리케이션의 '맥락'을 알아야 하기 때문이다.
이 맥락이란 것은 아주 애매모호하다.
실무적인 이슈로 정통적 이론과 다른 방향으로 적용되어야 하는 경우도 있고, 다소 비효율적이더라도 비즈니스상 불가피하게 기술적으로 안 좋은 것을 선택해야 하는 경우도 있다.
또한, 복잡한 도메인의 경우 트래픽에 대한 이슈처리를 하려면 인프라부터 시작한 대규모 프로세스 플로우 상에서 병목지점을 찝어내야 하는데, 이런 것들은 AI가 알 수가 없다.
이건 업무 프로세스를 이해하고, 실제 사용되는 케이스를 분석하여 시스템의 구성과 흐름에 대한 '맥락'을 알아야만 합리적 판단이 가능한 영역이기 때문이다.

3. 바이브코딩의 한계

바이브코딩의 한계는 위에서 본 것처럼 '맥락'을 읽기 힘들다는 점 뿐만은 아니다.
바이브코딩도 결국 LLM기반의 애플리케이션인데, 이 LLM이 가지는 태생적 한계는 더 큰 문제다.

쉽게 이해하기 위해 chatGPT를 생각해보자. chatGPT는 GPT라는 LLM모델을 활용하여 만든 대화형 애플리케이션이다. 여기서 중요한게 바로 GPT가 가지는 근본적인 특성이다.

GPT - Generative Pre-trained Transformer

GPT의 약자처럼 GPT의 근본적 기능은 '텍스트를 생성하는 것'이다.
chatGPT는 '텍스트를 생성하는 것'을 채팅형식의 애플리케이션으로 구현한 것이다.
즉, '채팅형식으로 사용자의 대화 뒤에 답변으로 올만한 텍스트를 생성하는 것'이 chatGPT의 본질인 것이다.
이를 바이브코딩 애플리케이션에 대입해보면 '채팅형식으로 사용자의 대화 뒤에 올 확률적으로 높은 텍스트(코드)를 생성하는 것'이 된다.

이게 문제가 되는 것은 '어떻게든' 텍스트를 생성해야 하는 것이 LLM의 근본원리라는 것이다.
즉, 사용자가 개떡같은 요청을 해도 AI는 일단 무언가 생성해내야 한다.
예를 들어, 모든 코드가 참조하고 있는 테이블(혹은 엔티티)이 있다고 가정하자. 근데 이 테이블의 데이터 형식이 무언가 마음에 안 들어서 데이터 형식을 바꿔달라고 요청한다고 해보자.
이때, 개발자라면 그 테이블은 참조되고 있는 프로그램이 많아서 수정하면 안 돼요 라고 말할 것이다.
그리고 애플리케이션의 안정성은 유지된다. (물론 변화도 없다)

하지만 클로드코드에게 똑같은 요청을 하면 클로드코드는 거절하지 않는다. 왜냐면 뭐라도 생성해내야하는게 본질이자 존재이유이기 때문에.
테이블 컬럼(혹은 속성)을 바꾸고, 그에 맞춰 참조되는 프로그램들을 수정해버리고, 기존 데이터들의 참조사항들을 변경하고... 이런 일련의 작업을 수행해버릴 것이다.

물론, 최신 버전의 AI의 경우 요청을 거절하거나 경고하는 케이스도 있긴 하다.
하지만 이 조차도 AI가 '거절'을 한다는 의미는 인간처럼 판단해서 위험하다고 인식한다는 뜻은 아니다.
LLM이 요청을 거절하거나 경고하는 것은, 실제로는 '안정성 필터'나 'Instruction tuning'을 통해 사전 학습된 문장 패턴에 반응하는 결과일 뿐이다.
즉, AI가 "이건 하면 안 돼요"라고 답한다고 해서, 진짜로 내부 시스템 구조를 이해하거나 참조 관계를 판단해서 막는 것은 아니란 것이다.
이런 경고는 단지 '사용자 요청의 문맥'을 확률적으로 해석한 결과로, 같은 요청이라도 표현만 조금 바꾸면 AI는 다시 수행하려 들기도 한다.

그리고 무엇보다 AI는 저 일련의 복잡한 작업을 완벽히 수행할 정도로 고도화되지 않았다.
결국, 잘 돌아가던 시스템은 엉망진창이 되고 형상관리가 제대로 안 되어있는 최악의 경우엔 새로 만드는게 더 빠른 상황이 발생할 여지도 있는 것이다.

4. 아직은 개발자

위와 같은 이유로 바이브코딩은 물론 비개발자들에게 '프로그래밍 언어'라는 기술적 해자를 없애주는 역할을 하지만 근본적인 '개발'을 완벽히 해주진 못 한다.
아직은 '맥락'을 읽을 수 있는 판단력, '맥락'에 맞는 결정을 내릴 수 있는 지식과 경험이 있어야 하는 것이다.
그리고 이것들은 개발자들이 학습과 경험을 통해 쌓아온 것으로 단기간에 익히기란 쉽지 않다.
그래서 비개발자가 단순 바이브코딩만으로 볼륨있는 실서비스 수준의 앱을 개발하는 것은 다소 현실성이 떨어지고(물론 볼륨이 크지 않는 서비스라면 충분히 현실성 있다) 아직은 개발자의 몫이 있는 것이다.

다만 바이브코딩은 개발자에게 비약적인 생산성 향상을 이끌어내므로, 기존보다 개발자 수요가 줄어들 것은 분명해보인다. 이미 위에 취업시장 현황에서 봤듯이 신입개발자 채용에서부터 시작은 이미 되었다.

바이브 코딩의 미래

1. 필연적 CS

그럼 바이브코더들은 어떤 것을 해야될까?
어떻게 하면 볼륨있는 앱을 안정적인 퀄리티로 개발할 수 있을까?
이것의 답은 필연적으로 CS다. 안정적으로 일정한 퀄리티의 앱을 개발하려면 CS지식을 축적하는 것으로 귀결될 것이다.

"이 프로세스는 신뢰도 있게 처리되어야 하니까 메시지큐를 써야겠다"
"이 데이터들은 정합성이 중요하니까 스키마구조는 반드시 PK와 FK로 묶어야겠어"
"다중 데이터를 처리하는 로직 속도가 너무 느린데... 멀티쓰레딩 병렬처리로 구현해야겠다"

위와 같은 지식을 알고 AI에게 저런 조건들과 함께 개발을 요청하는 것과 그저 AI에게 '해줘'하는 것의 결과물의 퀄리티가 천지차이란 것은 대강 생각해봐도 자명한 일이다.
그렇기에 내 생각에는 앞으로 바이브코딩을 배운다는 것에는 'CS지식'을 배운다는 의미가 내포될 것이라고 확신한다.

그럼 우리는 어떤 것들을 배워야 할까?
사실 이건 개발자들도 배워야 될 내용이 많을 것이다. 개발자 중에는 더러 '코딩'만 하는 개발자들도 생각보다 많기 때문이다.
하지만 바이브코딩을 위한 CS는 '코딩'을 배운다는 의미가 아니다. 오히려 '코딩'은 가장 덜 배워도 되는 항목이다. 왜냐면 바이브코딩 자체가 '코딩'을 대신해주는 도구이기 때문이다.
우리는 이 도구를 잘 쓰기 위한 배경지식을 배워야 하는 것이다.

포괄적인 분야를 제시하자면

1. 데이터베이스
2. 네트워크
3. 알고리즘
4. 자료구조
5. 라이브러리와 프레임워크
6. 프론트엔드
7. 백엔드
8. 인프라
9. 보안

이 정도가 생각난다. 이렇게 나열한 것을 보면 "결국 모든 것을 다 하라는거야 뭐야?"라는 생각이 들 것이다.
근데 그게 맞다. 바이브코딩을 잘 하려면 결국 전부 다 어느정도 알아야 한다.

위에서 말한 '맥락'이란 것은 어느 특정 지점에서만 발생하는 것이 아니기 때문이다.
개발 공부의 패러다임이 바뀐 것이다. 예전에는 백엔드 개발자라면 일단 개발언어를 잘 알아야 하고, 쿼리를 잘 짜야하고, 쿼리옵티마이저도 할 줄 알면 좋고, 현대에 와서는 데브옵스도 어느정도 겸한다면 훌륭했다.

하지만 바이브코딩 시대에는 특정 분야만 잘 해선 의미가 없다. 왜냐하면 AI코딩하는 범위에는 한계가 없기 때문이다.
AI는 프론트를 개발해달라고 하면 프론트를 개발해주고, 백엔드를 개발해달라고 하면 백엔드를 개발해준다.
데이터처리를 위한 파이썬 프로그램을 짜달라고 하면 아주 잘 짜주기도 한다.

결국 언어의 장벽은 사라지고, 중요한 것은 언어와 관계없이 전체적인 시스템 구조 상에서의 '맥락'을 읽을 수 있는 능력이 중요해질 것이다.
서비스 병목이 발생했다면 네트워크에서 발생한 것인지, 백엔드 로직 처리에서 발생한 것인지, 프론트엔드 렌더링에서 문제가 발생한 것인지, 인프라 구성 자체가 문제인 것인지... 전체적인 숲을 보며 '맥락'을 판단할 수 있어야 하는 것이다.

그렇기에 우리는 앞으로 CS라고 칭할 수 있는 범용적인 지식을 익혀나가야 한다. 비개발자에겐 이것이 기회가 될 수 있다. 개발자들고 CS전체적으로 아는 경우는 드물기 때문이다.

2. CS와 결합한 바이브코딩의 미래

위에 말했듯 바이브코딩은 단순히 자연어로 코딩을 '해줘'하는 것에서 그치면 한계가 명확하다.
CS지식과 함께 그 상황에 적절한 '맥락'을 찾아서 알맞는 기술을 조건으로 걸고 AI에게 요청해야 진정으로 내가 원하는 수준의 결과물을 얻을 수 있을 것이다.

물론 종종 그냥 '해줘해줘'하면서 원하는 결과물을 뽑아내는 경우도 있을 것이다.
하지만 그건 어디까지나 요행이고, 어쩌다 얻어걸린 것일 뿐이다.
똑같은 퀄리티의 결과물을 다시 한번 재현하고 싶어도 100% 재현을 보장할 수 없기 때문이다.

결국 바이브코딩은 CS지식과 결합하여 안정적이고 결과가 보장되는 방향으로 발전할 것이다.

결론 : 바이브코딩을 잘 하기 위한 방법론이 필요

예전에는 새로운 언어나 프레임워크가 나오면 '헤드퍼스트'와 같은 교재로 해당 언어에 대해서 공부했다.
바이브코딩 시대에서는 바이브코딩 앱 별로 어떻게 하면 최적화 된 개발을 할 수 있을지에 대한 방법론이 교재로 나오지 않을까 생각한다. (안 나오면 나라도 쓸 생각이다)
그 중심에는 단연코 CS가 있을 것이고, 교재는 이 CS를 활용하여 어떻게 안정적으로 바이브코딩을 잘 할 수 있을지에 대한 내용을 중점적으로 다루지 않을까 생각한다.

바이브코딩 시대에 대비하기 위해서 현재 나에게 부족한 것이 무엇인지, 어떤 것들이 필요한지 발 빠르게 준비하는 사람들이 바이브코딩 시대의 진정한 바이브코더가 될 것이다.
다음에는 바이브코딩을 제대로 하기 위한 실전 방법론에 대한 포스팅 예정이다.