"채팅앱 만들어줘." 이 한 문장이면 앱이 뚝딱 나오는 세상입니다. AI에게 말만 하면 코드가 쏟아지고, 화면이 구현되고, 심지어 배포까지 된다고 합니다. 2025년 콜린스 사전이 '올해의 단어'로 선정할 만큼 바이브코딩은 이제 개발 문화 그 자체가 되어가고 있죠.
그런데 최근 커뮤니티를 돌아다니다 흥미로운 장면을 목격했습니다. 프론트엔드, 백엔드, 데이터베이스가 뭔지도 모르는 상태에서 AI에게 "인스타그램 같은 거 만들어줘"라고 요청하는 분들이 꽤 있더라고요. 정적(static) 웹페이지와 서버에서 데이터를 가져와 보여주는 동적 웹의 차이조차 구분하지 못한 채 말이죠.
결과는 어땠을까요? 처음엔 신기하게 화면이 나옵니다. 그런데 거기서 한 발짝만 더 나아가면, 벽에 부딪힙니다. 그리고 그 벽은 AI가 넘어줄 수 있는 벽이 아닙니다.
바이브코딩, 왜 이렇게 뜨거운가
바이브코딩(Vibe Coding)은 2025년 2월, OpenAI 공동 창립자 안드레이 카파시(Andrej Karpathy)가 처음 제안한 개념입니다. 핵심은 간단합니다. 코드를 직접 쓰지 않고, 자연어로 원하는 것을 설명하면 AI가 코드를 생성해준다는 거죠.
실제로 이 흐름은 놀라울 정도입니다. Y Combinator가 2025년 초 선발한 스타트업 중 25%는 전체 코드베이스의 95%가 AI로 생성되었다고 보고했고, Vercel의 'State of Vibe Coding 2025' 보고서에 따르면 v0 플랫폼 사용자의 63%가 비개발자였습니다. 미국 개발자의 92%가 AI 코딩 도구를 매일 사용한다는 조사도 있고요.
Cursor, Claude Code, Lovable, Replit 같은 도구들이 쏟아져 나오면서, "국어만 잘하면 개발할 수 있다"는 말까지 나올 정도입니다.
그런데 여기서 한 가지 질문이 생깁니다. 정말 원리를 몰라도 괜찮은 걸까요?
"만들어줘"와 "이런 아키텍처로 만들어줘"의 차이
제가 실제로 관찰한 두 가지 사례를 비교해보겠습니다.
사례 A: "할 일 관리 앱 만들어줘."
AI는 아마 HTML과 JavaScript로 브라우저에 투두 리스트를 만들어줄 겁니다. localStorage에 데이터를 저장하는 간단한 정적 페이지요. 새로고침하면 데이터가 유지되니 "오, 잘 되네!" 싶을 수 있습니다.
사례 B: "React 프론트엔드와 Supabase 백엔드로 할 일 관리 앱을 만들어줘. 사용자 인증은 OAuth로 처리하고, 할 일 데이터는 PostgreSQL에 저장해서 기기 간 동기화가 되게 해줘."
같은 "할 일 관리 앱"이지만, 결과물의 수준이 완전히 다릅니다.
사례 A의 결과물은 본인 브라우저에서만 쓸 수 있는 간단한 메모장입니다. 사례 B의 결과물은 실제 서비스로 확장할 수 있는 기반을 갖춘 앱이죠.
더 중요한 건, A를 만든 사람은 "이걸 다른 사람도 쓸 수 있게 하려면 어떻게 하지?"라는 질문에 답할 수 없다는 점입니다. 반면 B를 요청한 사람은 이미 그 답을 알고 있기 때문에 제대로 된 질문을 던질 수 있었던 거예요.
원리를 모르면 생기는 현실적인 문제들
요즘IT에 실린 한 개발자의 경험담이 이 상황을 잘 보여줍니다. 비개발자 두 사람의 바이브코딩을 도와주면서 발견한 공통적인 막힘 포인트가 있었는데, 이런 것들이었습니다.
개발 환경 자체를 모릅니다. VS Code가 뭔지, npm이 뭔지, package.json을 어떻게 읽는지. AI가 코드를 줬는데, 그걸 어디에 붙여야 하는지를 모르는 거예요. 개발자에겐 숨 쉬듯 자연스러운 것들이 완전한 벽이 됩니다.
데이터 구조 개념이 없습니다. JSON이 뭔지, DB가 뭔지, 데이터를 어떻게 저장하고 불러오는지. AI가 JSON을 출력했는데, 중괄호와 대괄호가 뒤섞인 "외계어"로 보이는 거죠. 더 문제인 건, AI도 데이터 구조 변경에는 약한 편이라서 한번 꼬이면 맥락을 놓치기 쉽다는 겁니다.
배포와 보안은 아예 다른 차원입니다. 화면은 잘 만들어졌는데 로그인이 필요하고, 개인정보를 다뤄야 하고, 서버에 올려야 하는 순간? 그때부터 진짜 개발이 시작됩니다.
실제로 Vercel은 2025년 7월 한 달간 보안 키 노출 문제로 17,000건의 배포를 차단했다고 밝혔습니다. Google Maps 키, OpenAI API 키, Supabase 데이터베이스 키 같은 것들이 코드에 그대로 노출된 거예요. 원리를 아는 사람이라면 절대 하지 않을 실수입니다.
정적 웹과 동적 웹, 이 차이를 아는 것부터 시작입니다
바이브코딩으로 무언가를 만들기 전에, 적어도 이 정도는 이해하고 있어야 합니다.
정적 웹(Static Web) 은 미리 만들어진 HTML 파일을 그대로 보여주는 방식입니다. 블로그 글이나 회사 소개 페이지처럼 내용이 바뀌지 않는 사이트에 적합하죠. 서버가 특별한 처리를 하지 않아도 되니 빠르고 단순합니다.
동적 웹(Dynamic Web) 은 사용자의 요청에 따라 서버가 데이터를 처리하고, 그 결과를 보여주는 방식입니다. 로그인 후 "내 주문 내역"을 보여주는 쇼핑몰, 실시간으로 댓글이 업데이트되는 SNS 같은 것들이죠.
이 차이를 모르는 상태에서 "쇼핑몰 만들어줘"라고 하면 어떻게 될까요? AI는 아마 멋진 상품 목록 화면을 만들어줄 겁니다. 하지만 실제로 결제가 되거나, 재고가 관리되거나, 사용자별 장바구니가 유지되는 서비스와는 거리가 멀겠죠.
이건 AI의 능력 문제가 아닙니다. 질문하는 사람이 무엇을 원하는지 정확히 모르니까, AI도 정확한 답을 줄 수 없는 거예요.
프론트엔드, 백엔드, 데이터베이스 — 삼위일체를 이해해야 하는 이유
복잡한 앱을 만들려면 결국 이 세 가지 영역이 어떻게 맞물리는지 이해해야 합니다.
프론트엔드는 사용자가 직접 보고 만지는 화면입니다. 버튼, 입력창, 애니메이션 같은 것들이죠. AI가 가장 잘하는 영역이기도 합니다. "예쁜 로그인 화면 만들어줘"라고 하면 꽤 그럴듯한 결과가 나옵니다.
백엔드는 화면 뒤에서 돌아가는 로직입니다. 사용자가 로그인 버튼을 눌렀을 때 비밀번호를 확인하고, 권한을 부여하고, 세션을 관리하는 일을 합니다. 눈에 보이지 않지만, 이게 없으면 서비스가 아니라 그냥 그림일 뿐이에요.
데이터베이스는 모든 정보가 저장되는 곳입니다. 사용자 정보, 게시글, 주문 내역, 설정값 등. 어떤 데이터를 어떤 구조로 저장할지 설계하는 것 자체가 서비스의 뼈대를 세우는 일입니다.
이 세 영역의 관계를 이해하는 사람은 AI에게 이렇게 지시할 수 있습니다.
"Next.js로 프론트엔드를 만들고, API Route에서 Supabase에 연결해서 사용자 데이터를 가져와줘. 인증은 Supabase Auth를 쓰고, Row Level Security를 적용해서 본인 데이터만 접근할 수 있게 해줘."
반면, 이 관계를 모르는 사람의 지시는 이렇습니다.
"회원가입이랑 게시판 있는 사이트 만들어줘."
AI는 두 경우 모두 코드를 생성해줍니다. 하지만 전자는 실제로 동작하는 서비스가 되고, 후자는 높은 확률로 보안 취약점 투성이의 프로토타입에 머물게 됩니다.
지시의 품질이 결과의 품질을 결정합니다
바이브코딩의 본질은 결국 "AI와의 대화"입니다. 그리고 대화의 품질은 말하는 사람의 지식에 비례합니다.
비유하자면 이렇습니다. 건축을 전혀 모르는 사람이 건축가에게 "좋은 집 지어주세요"라고 하는 것과, 건축에 대한 기본 이해가 있는 사람이 "남향으로 3룸 구조, 거실은 오픈형, 단열은 패시브하우스 기준으로 해주세요"라고 하는 것. 결과물이 같을 리가 없겠죠.
소프트웨어 개발도 마찬가지입니다. AI가 아무리 똑똑해져도, 큰 그림을 그리는 건 사람의 몫입니다. 어떤 아키텍처를 쓸지, 데이터를 어떻게 흘려보낼지, 보안은 어떤 수준으로 가져갈지. 이런 의사결정 없이 AI에게 모든 걸 맡기면, 결국 AI가 임의로 결정한 구조 위에서 작업하게 되고, 조금만 복잡해지면 전체가 무너집니다.
삼성SDS 인사이트 리포트에서도 이런 상황을 잘 정리하고 있습니다. 경력 있는 개발자가 AI를 활용하는 방식은 마치 시니어 개발자가 주니어에게 작업을 위임하는 것과 비슷합니다. 핵심 설계는 직접 하고, 반복적인 작업만 AI에게 맡기는 거죠. 이게 바이브코딩의 올바른 활용법입니다.
C++을 만든 사람도 경고합니다
C++ 언어를 개발한 비야네 스트로스트룹(Bjarne Stroustrup)은 바이브코딩에 대해 이런 우려를 표했습니다. 잘못된 코드들이 학습 데이터로 다시 활용될 수 있고, 개발자가 생각 없이 코드를 받아들이는 습관이 만들어질 수 있다는 거죠.
실제로 이런 일이 벌어지고 있습니다. 2025년 7월에는 코딩 AI가 "라이브 배포 전에 허가를 받을 것"이라는 명령을 무시하고 데이터베이스를 직접 수정해서 데이터가 통째로 날아간 사례도 보고되었습니다.
AI가 생성한 코드가 전자상거래 사이트에서 가짜 리뷰를 조작한 사례, AI의 맥락 창 한계로 인해 코드가 점점 더 꼬여가는 문제, 같은 LLM을 써도 개발자마다 다른 결과가 나와서 코드 일관성이 무너지는 현상까지. 원리를 모르고 AI를 사용한 결과는 점점 심각한 수준으로 드러나고 있습니다.
그러면 뭘 알아야 하나요?
바이브코딩 시대에 개발 원리를 "전부" 알 필요는 없습니다. 하지만 최소한 이 정도는 이해하고 있어야, AI와 제대로 된 협업이 가능합니다.
클라이언트와 서버의 차이. 브라우저에서 실행되는 코드와 서버에서 실행되는 코드는 역할이 다릅니다. 이걸 모르면 API 키를 프론트엔드 코드에 그대로 노출하는 실수를 하게 됩니다.
데이터가 어떻게 흘러가는지. 사용자가 버튼을 누르면 → 프론트엔드가 서버에 요청을 보내고 → 서버가 DB에서 데이터를 꺼내서 → 응답을 돌려주는 이 흐름. HTTP, REST API, 데이터베이스 쿼리의 기본 개념만 잡아도 AI에게 훨씬 정확한 지시를 내릴 수 있습니다.
인증과 보안의 기초. 비밀번호를 평문으로 저장하면 안 된다는 것, 환경변수로 민감한 정보를 관리해야 한다는 것, HTTPS가 왜 필요한지. 이런 기본적인 보안 감각은 AI가 대신해줄 수 없는 영역입니다.
버전 관리와 배포. Git으로 코드를 관리하고, 스테이징 환경에서 테스트한 후 프로덕션에 배포하는 기본 워크플로우. 이걸 모르면 AI가 만들어준 코드를 실제 서비스로 만드는 것 자체가 불가능합니다.
이런 원리들을 이해하고 있다면, AI는 정말로 강력한 가속기가 됩니다. 예전에는 한 팀이 몇 주에 걸쳐 할 일을 이제는 혼자서 며칠 만에 해낼 수 있으니까요. 요즘 개발 도구들의 발전 속도를 보면, 1인 개발자가 이전에는 불가능했던 규모의 서비스를 만들 수 있는 시대가 정말 온 것 같습니다.
원리를 아는 바이브코딩이 진짜 바이브코딩입니다
카파시가 바이브코딩을 처음 제안했을 때, 그는 수십 년간 AI와 소프트웨어 엔지니어링을 깊이 연구한 전문가였습니다. 그가 "코드가 존재한다는 사실조차 잊어버린다"고 말할 수 있었던 건, 코드의 원리를 너무나 잘 알기 때문이었습니다.
오케스트라 지휘자가 모든 악기의 운지법을 일일이 지시하지 않듯이, 전체적인 분위기와 방향을 이끌 수 있는 건 그 사람이 음악의 원리를 깊이 이해하고 있기 때문이죠. 바이브코딩에서 개발자의 역할도 이와 같습니다.
DB가 뭔지, 프론트엔드와 백엔드가 어떻게 통신하는지, 정적 웹과 동적 웹의 차이가 뭔지. 이런 기본 원리를 아는 사람이 AI를 쓰면 날개를 다는 겁니다. 모르는 사람이 AI를 쓰면 날개 없이 절벽에서 뛰어내리는 것과 같고요.
바이브코딩의 시대는 코딩을 몰라도 되는 시대가 아닙니다. 코딩의 "원리"를 아는 사람이 훨씬 더 빛나는 시대입니다. AI가 코드를 대신 써주는 만큼, 이제 진짜 가치는 무엇을 만들지 결정하고, 어떤 구조로 만들지 설계하는 능력에 있습니다.
오늘부터 복잡한 문법을 외우는 대신, 소프트웨어가 어떻게 돌아가는지 그 흐름을 이해하는 데 시간을 투자해보세요. 그게 바이브코딩 시대의 진짜 경쟁력입니다.
'IT일반' 카테고리의 다른 글
| 로티(Lottie) 애니메이션, 상업적으로 써도 될까? — Lottie Simple License 완전 정리 (0) | 2026.02.13 |
|---|---|
| 알림일까? 알람일까? 정확한? 사용법 (0) | 2025.11.06 |
| 느낌이 이끄는 코드 – 바이브 코딩이란? (4) | 2025.07.10 |
| 다빈치 리졸브 20의 새로운 기능 (0) | 2025.05.08 |
| 버려지는 디자인 vs 통과되는 디자인, 그 차이는 무엇일까? (0) | 2025.04.08 |
