바이브 코딩이라는 표현, 어디서 어떻게 생겨난걸까?
최근 전세계적으로 많이 쓰이는 표현 중 하나인 바이브 코딩 유래를 찾아보신적 있으신가요?
생성형 AI 를 활용한 코딩을 바이브 코딩이라고 표현 합니다.
왜 AI 코딩, 생성형 코딩이 아니라
바이브 코딩이지? 라는 생각에서 찾아봤습니다.
1) Vibe Coding은 공식적인 개발 방법론이 아니다.
2025년 2월, OpenAI 공동창립자 Andrej Karpathy가 X(구 트위터)에 올린 한 포스트에서 시작됐습니다.
완전히 분위기(vibe)에 몸을 맡기고, 코드가 존재한다는 것 자체를 잊어라 이것이 그의 원래 표현이었습니다.
즉, "AI 코딩"이나 "생성형 코딩"이 아니라 바이브 코딩인 이유는,
코드를 이해하거나 검토하지 않고 느낌대로 AI에게 맡긴다는 뉘앙스를 담고 있기 때문입니다.
2) 바이브 코딩을 활용 하는 것 과, 바이브 코딩만 할 줄 아는것의 차이
바이브 코딩의 가장 큰 장점은 속도입니다.
그동안 아이디어는 있지만 개발이라는 영역의 허들 때문에 진입하지 못 했던 사람들이
바이브 코딩을 통해 개발에 입문 하고 있습니다.
하지만 여기서 중요하게 느끼는게 있습니다.
바이브 코딩을 활용 하는 것 과, 바이브 코딩만 할 줄 아는것의 차이 입니다.
최근 AI 생성 페이지들의 보안 문제가 자주 발생합니다.
예를 들어 AI에게 로그인 기능을 만들어줘 라고 하면 바이브 코딩만 할 줄 아는 사람들은 생성된 로그인 기능이 어떤 방식으로 구현된 기능인지를 생각하지 않습니다.
대부분의 사람들은 이해하고, 개선하려고 하지 않습니다.
이러한 지점에서 활용하는 사람과 사용하는 사람의 특별성이 강조된다고 생각합니다.
그렇다면 바이브 코딩을 제대로 활용한다는 것은 무엇 일까요?
3) 바이브 코딩을 활용하는 의미
바이브 코딩을 잘 활용 하려면 어떤게 중요 할까요?
- 기본적인 CS/아키텍쳐 지식
- AI 결과물을 검토하는 습관
- 좋은 프롬프트 작성법
- 직접 코딩도 할 줄 아는 기본기
모두 중요하지만 제가 생각하는 하나의 핵심은
내가 주도권을 갖는것 입니다.
내가 뭘 만들고 있는지 목표 결과물을 확실하게 이해하고,
목표물에 대한 이해를 바탕으로 AI에게 정확한 지시를 내리고 결과물을 항상 검토 하는 것.
이 요소들을 지킨다면 내가 주도권을 갖고 바이브 코딩을 잘 활용하고 있다고 생각합니다.
4) 바이브 코딩을 활용하기 위한 '방향성' 설계
바이브 코딩을 실패하는 주된 이유는 '방향성'이 명확하지 않기 때문입니다.
무엇을 만들지 정확하게 알지 못하고 AI에게 요청을 하면 AI도 모호한 결과물을 생성합니다.
바이브 코딩을 시작하기 전 누가, 어떤 문제를, 어떻게 해결하는 서비스인가? 를 명확하게 정의 합니다.
5-1 ) 직접 제작 해보기
제가 바이브 코딩으로 사이드 프로젝트를 설계하고 진행 해본 경험으로는
메모리 관리, 데이터베이스 접근 권한 등 보안 관련 이슈를 발견한 경험이 있습니다.
그런 와중 Deepwiki 라는 오픈 소스를 발견 했고. 보안 점검 + 자동 생성 wiki + 자동 생성 API 문서 에 흥미가 가서
SecureScanWiki 프로젝트를 진행 했습니다.
나는 깃허브 레포지토리 프로젝트를 스캔하여 보안 취약점과 프로젝트의 wiki, api 문서를 생성하는 프로젝트를 만들거야.
1. 사용 유저는 오픈 소스로 공개할 예정이고
2. 핵심 기능은 프로젝트 취약점 문석, wiki 생성, api 문서 생성이야.
3. wiki는 Deepwiki 프로젝트의 베이스를 카피하고 싶어.
4. 깃허브 레포지토리 url을 넣으면 분석을 시작하고 비공개 레포지토리를 분석하고 싶을 경우 github 로그인을 해야해.이라는 프롬프트로 프로젝트 설계를 했습니다.
프로젝트를 진행하기 전 Deepwiki 에서 불편점은 한국어를 지원하지 않고,
wiki generator의 역할만 한다는게 아쉬웠습니다.
을 바탕으로 향 후 서버와의 통신과 확장성, 트렌드를 고려하여 next.js로 프로젝트를 구축 했습니다.
첫번째 결과물 및 문제
- Github 의 fetch API 를 활용하여 프로젝트의 15개 파일만 불러와서 wiki를 생성함.
생각했던 결과물은 레포지토리 내 모든 파일을 읽고 분석하여 wiki와 api 문서를 생성하는 것이었습니다.
보통의 프로젝트가 15개의 파일을 초과한다는 점을 생각하면 의미가 없는 결과물이였습니다.
해당 부분을 지적하자 AI는 다음과 같은 방법을 제시 했습니다.
- Github 프로젝트를 Zip 으로 다운.
- 서버에서 압축 해제
- 전체 파일 트리 분석
- Claude에게 청크 단위로 나눠서 전달
이러한 방식은 Claude context window 를 초과하고 비용마저 많이 소모가 됩니다.
이렇게 많은 비용이 소모되는 wiki 생성기는 어디에도 없을 것 이였습니다.
Search Code API 를 사용하여 레포지토리 다운로드 없이 취약점 패턴을 '검색' 해서
관련 코드만 가져오는 로직을 생성해달라고 했습니다.
코드에서 위험 패턴을 정규식/키워드로 빠르게 스캔
SQL Injection, XSS, 하드코딩 시크릿, eval, 취약 함수 등
수백 개 파일도 서버에서 순식간에 처리와 같은 방식으로 구현을 시작했고 최소한의 토큰 소모로 제가 목표로 했던 결과물을 생성해낼 수 있었습니다.
AI를 활용한 결과물 생성, 확인, 검증 해봄으로써
실 사용자가 생긴다면 어떤식의 불편함이 있을지
설계와 생성 과정에서 누락되거나 결함은 없는지
직접 제작해보고 확인 해봄으로써 생성형 AI를 더 잘 활용하는 방법에 대해 알게 되었습니다.