안드레 카파시 바이브 코딩, 에이전틱 엔지니어링, 운영 배포 | 주말에 만든 걸 그대로 올려도 되나?
안드레 카파시 바이브 코딩으로 만든 화면을 운영에 그대로 올리면 지금 단계에선 중요한 서비스에 맞지 않는다. 남는 코드는 에이전틱 엔지니어링으로 바꾸고, 메뉴젠처럼 로그인과 결제와 키는 diff로 본다. 커서, 클로드 코드, 버셀, 카카오 로그인, 토스 웹훅, 1인 개발자 기준. 2026년 9월 카파시 후기, 뉴스택, 윌리슨.
안드레 카파시 바이브 코딩으로 만든 화면을 운영에 그대로 올리면, 본인이 메뉴젠에서 적은 대로 중요한 서비스에는 지금 단계가 맞지 않습니다. 남는 코드는 에이전틱 엔지니어링으로 바꿉니다.
로컬에서 예쁜 화면이 뜨면 끝난 줄 알고 버셀에 밀어 넣는 순간, 환경 변수와 로그인, 결제가 따로 남죠. 같은 커서와 클로드로 둘 다 하니 헷갈립니다.
원문 다섯 행동과 툴 고르기는 이미 나눠 둔 글이 있어요. 주말 프로토와 배포 브랜치를 가르는 자리만 표로 봅니다. 근거는 카파시 메뉴젠 후기와 뉴스택이 옮긴 2026년 2월 게시, 사이먼 윌리슨에 있습니다. 저는 사이트를 프리빌트로 올릴 때 로컬은 되고 배포만 깨지는 칸을 따로 보죠. 코드를 안 읽은 채로 올리면 그 칸을 나중에 못 찾습니다.
바이브 코딩과 에이전틱 엔지니어링은 같은 말이 아니다
가르는 선은 코드를 읽느냐이고, 안 읽으면 바이브, 읽고 감독하면 에이전틱입니다. 안드레 카파시 바이브 코딩은 흐름에 맡기고 diff를 안 읽는 상태고, 에이전틱 엔지니어링은 에이전트가 줄을 쓰더라도 사람이 감독하고 품질을 지키는 상태입니다.
2025년 2월 2일 원문은 코드가 존재한다는 사실조차 잊는다고 했습니다. 사이먼 윌리슨은 그 정의를 더 좁혔죠. LLM이 짠 코드를 검토하지 않고 만드는 것만 바이브 코딩이고, 읽고 테스트하고 설명할 수 있으면 AI 보조 코딩입니다. 마틴 파울러도 코드를 안 보기 때문에 유지보수와 정확성, 보안이 남는다고 적었습니다. 원문 다섯 행동과 그 한계선은 정의와 원문 글에 있습니다. 여기는 그 다음 칸만 봅니다.
칸
바이브 코딩
에이전틱 엔지니어링
사람 역할
말하고 실행하고 붙여넣기
일을 쪼개고 에이전트를 감독
diff
대체로 전체 수락
읽고 고치고 다시 맡김
맞는 자리
주말 프로토, 데모, 버릴 코드
남을 서비스, 협업 브랜치
실패 때
우회하거나 다른 요청
테스트와 로그로 원인을 고정
책임
흐릿함
사람이 최종 확인
도구 이름이 같다고 방식이 같지는 않습니다. 커서 컴포저로 주말 앱을 통째로 받아도 바이브고, 같은 창에서 결제 줄만 읽고 테스트를 돌리면 에이전틱입니다. 툴 목록은 바이브코딩 툴 가이드에 있고, 클로드 코드로 설계부터 배포까지 읽는 흐름은 실전 워크플로우에 있습니다.
먼저 기억할 것 | AI로 짰다고 전부 바이브 코딩이 아닙니다. diff를 안 읽으면 바이브, 읽고 감독하면 에이전틱입니다.
같은 도구라도 diff를 읽는지가 두 방식을 가른다
카파시가 1년 뒤에 바꾼 한 줄
2026년 2월 무렵 그는 전문가 기본을 에이전틱 엔지니어링이라고 불렀습니다. 코드를 직접 안 써도 에이전트를 조율하고 감독하는 쪽이 기본이고, 품질은 타협하지 말라는 뜻이었습니다.
뉴스택은 그 게시를 이렇게 옮겼습니다. 1년 뒤에는 LLM 에이전트로 프로그래밍하는 일이 전문가의 기본 흐름이 되어 가고, 다만 감독과 검토가 더 붙는다는 내용이죠. 그는 에이전틱이라고 부른 이유를 직접 안 쓰는 시간이 대부분이라서, 엔지니어링이라고 부른 이유를 기술과 숙련이 있어서라고 적었습니다. 배울 수 있고 더 잘할 수 있다는 말도 같이 있습니다.
The goal is to claim the leverage from the use of agents but without any compromise on the quality of the software.
에이전트가 주는 속도는 가져가되, 소프트웨어 품질은 타협하지 않는 것이 목표다. 뉴스택이 옮긴 카파시 2026년 2월 게시.
같은 사람입니다. 2025년 2월에는 버려도 되는 주말 프로젝트에 나쁘지 않다고 선을 그었고, 2025년 6월 YC 강연에서는 바이브 코딩이 토요일이면 맞춤 앱을 날로 만들어 보는 재미라고 했습니다. 1년 뒤 말은 그 재미를 부정한 게 아니라, 남을 코드에 그 재미를 그대로 옮기지 말라는 쪽에 가깝습니다. 역량 다섯 가지는 에이전틱 엔지니어링 역량 글이 따로 있으니, 여기는 카파시가 바이브와 이름을 나눈 자리만 봅니다.
이름을 바꾼 이유 | 바이브는 코드를 잊는 상태의 이름입니다. 에이전틱은 코드를 에이전트가 쓰더라도 사람이 품질을 지키는 상태의 이름입니다.
메뉴젠을 끝까지 올리면 어디가 막히나
로컬 화면은 빨리 나오고, 회원가입과 결제와 배포에서 시간이 갑니다. 카파시는 2025년 4월 27일 메뉴젠 후기에서 코드를 한 줄도 직접 안 썼고, 커서와 클로드가 전부 짰다고 적었습니다.
첫 프로토는 금방이었고, 새 사이트가 뜨는 맛에 80퍼센트 끝난 느낌이 들었지만 실제로는 20퍼센트에 가까웠다고 했습니다. 막힌 칸은 에디터가 아니었습니다. 오픈AI와 리플리케이트 API 키, 폐기된 호출을 환각하는 모델, 요청 한도, 버셀 빌드만 실패하는 린트, .env.local이 깃에 안 올라가서 대시보드에 키를 따로 넣는 일, 비공개 저장소인데도 추측하기 쉬운 공개 URL이 열리는 일, 클러크 로그인과 구글 클라우드 콘솔, 스트라이프에서 자바스크립트 예제를 타입스크립트 앱에 붙이는 일, 결제 이메일과 구글 로그인 이메일을 같게 보려다 크레딧이 안 붙는 설계까지였습니다.
메뉴젠에서 막힌 칸
로컬 데모
운영에 남기면
화면, CSS
금방 됨
읽지 않아도 당장 안 죽음
API 키, 한도
로컬 파일에 있음
호스트 환경 변수에 따로 넣음
로그인
개발 모드로 통과
커스텀 도메인, 오오스 콘솔
결제
테스트 키
사용자 아이디로 매칭해야 함
DB, 큐
없어도 됨
새로고침하면 결과가 사라짐
마지막 문장이 여기 운영 기준입니다. 풀 웹앱을 바이브로 끝까지 만드는 일은 지금으로선 지저분하고, 진짜 중요한 일에는 좋은 생각이 아니라고 본인이 적었습니다. 한국에서 카카오 로그인과 토스 웹훅을 붙이면 같은 종류의 칸이 더 붙습니다. 리다이렉트 URI, 웹훅 서명, 테스트와 라이브 키를 대시보드에서 손으로 맞추는 일은 에디터 전체 수락으로 안 끝납니다.
메뉴젠에서 시간이 간 칸은 에디터가 아니라 배포와 키와 결제였다
주말 프로토를 배포 브랜치에 넣으면
반응이 좋다고 그 저장소를 운영 브랜치에 합치면, 읽지 않은 줄이 그대로 남습니다. 카파시가 스트라이프에서 잡은 설계 실수가 그 전형입니다.
모델은 결제 이메일과 구글 계정 이메일을 같다고 보고 크레딧을 붙이려 했습니다. 테스트 결제는 통과할 수 있고, 실제 사용자는 크레딧을 못 받습니다. 그가 사용자 아이디를 메타데이터로 넘기라고 지적한 뒤에야 고쳤습니다. 전체 수락만 반복하면 이런 줄을 배포 후에야 만납니다.
윌리슨도 같은 자리를 짚었습니다. 실험과 지분이 작은 프로토에는 바이브가 맞고, 운영 코드베이스로 바이브하는 일은 분명히 나쁜 생각이라고 했습니다. 이미 있는 시스템을 고치는 일이 엔지니어 일의 대부분이라, 코드의 질과 이해 가능성이 중요하다고 적었죠. 파울러는 버리는 소프트웨어와 한정된 청중에는 쓸 수 있다고 보면서도, 유지보수와 보안 문제가 남는다고 했습니다.
제가 쓰는 사이트도 로컬 프리뷰는 되고 버셀 환경 변수만 비어 있으면 배포만 깨집니다. 그 칸을 보려면 설정 화면을 열어야 하고, 에이전트가 짠 결제 매칭을 보려면 diff를 열어야 합니다. 하드 리프레시로 화면만 살리는 것과 비슷합니다. 그 탭만 고치고 원인은 남죠.
합치지 말 것 | 로그인, 결제, 웹훅, 개인정보가 들어간 줄을 전체 수락한 채 메인에 넣지 마세요. 테스트가 초록이어도 이메일 매칭 같은 설계는 테스트가 못 잡습니다.
한국 1인 개발자가 자리를 나누는 법
감을 잡는 저장소와 남을 저장소를 나눕니다. 주말 앱은 바이브로 빠르게 보고, 카카오와 토스와 카드가 붙는 줄부터는 diff와 테스트를 의무로 둡니다.
혼자 만들면 나중에 물어볼 동료가 없습니다. 안 읽은 코드는 나만 모르는 코드가 됩니다. 저는 새 기능을 붙여 볼 때는 흐름에 맡기고, 화면에 남기기로 하면 그때부터 읽습니다. 배포 브랜치에 올라가는 커밋은 통계라도 한 번 보고, 인증과 웹훅은 줄 단위로 봅니다.
[ ] 지금 저장소가 버릴 코드인지 남을 코드인지 정했다
[ ] 남을 코드면 로그인, 결제, 웹훅 경로를 diff에서 걸렀다
[ ] 버셀과 카카오, 토스 콘솔의 키와 리다이렉트가 로컬과 같은지 봤다
[ ] 에이전트가 이메일만으로 사용자를 붙이려 하지 않는지 봤다
[ ] 프로토가 반응이 좋아도 운영 브랜치에 그대로 머지하지 않기로 했다
에이전틱 쪽으로 옮길 때는 일을 작게 쪼개고, 통과 조건을 말로 박고, 실패한 테스트를 다시 맡깁니다. 클로드 코드라면 프로젝트 규칙 파일에 결제와 인증은 전체 수락 금지라고 적어 두는 식이면 충분했습니다. 전체 수락을 반복하면 큰 파일을 통째로 다시 쓰면서 사용량도 빨리 찹니다. 그 비용 칸은 여기서 다룰 자리가 아니고, 읽지 않는 대가가 배포 뒤에 나온다는 점만 기억하면 됩니다.
프로젝트 규칙에 감독 칸을 박아 둔다
# CLAUDE.md 또는 커서 규칙 파일 예시
결제, 로그인, 웹훅, 개인정보 경로는 전체 수락 금지.
해당 파일은 git diff를 읽고 테스트를 통과한 뒤에만 커밋.
이메일을 사용자 식별자로 쓰지 말 것. 내부 사용자 아이디를 쓴다.
버셀 환경 변수는 .env.local과 키가 같은지 배포 전에 확인.
