바이브코딩 용어를 22개에서 9개로 줄인 기준
바이브코딩 용어집은 많은데 왜 봐도 안 늘까. 22개 중 13개를 버리고 9개만 남긴 기준과, 그 기준을 실제 화면으로 검증한 과정을 정리했습니다.
방구석컴퍼니
혼자 일하는 사람 · 작업 기록
용어집을 세 번 읽었는데도 자기 화면 앞에서는 여전히 손이 멈춘다면, 문제는 기억력이 아닙니다. 목록이 잘못 짜여 있어서 그렇습니다.
바이브코딩 용어라고 돌아다니는 걸 모아보니 대략 스물두 개였습니다. 여기서 열세 개를 버리고 아홉 개만 남겼는데, 이 글은 무엇을 남겼는지가 아니라 무슨 기준으로 잘랐는지에 대한 기록입니다.
기존 용어집이 실패하는 구조적 이유
시중 용어집은 대부분 개념 사전입니다. IDE, CLI, 모델, 프롬프트, 컨텍스트 윈도우, 토큰, 할루시네이션… 항목마다 정의 한 줄과 비유 하나가 붙어 있습니다.
문제는 이 구조가 조회 시점을 가정하지 않는다는 데 있습니다. 사전은 모르는 단어를 만났을 때 찾는 물건인데, 초보자는 그 단어를 만난 줄도 모릅니다. 화면에 뜬 영어 한 줄과 용어집의 한글 항목이 머릿속에서 연결되지 않기 때문입니다.
실제로 경쟁 영상 34편을 훑어보니, 용어를 20개 다룬 편이 5개 다룬 편보다 성과가 낮았습니다. 정보량이 아니라 연결 실패가 병목이라는 신호로 읽었습니다.
배제 기준 한 문장: 화면에 그 글자가 뜨는가
그래서 기준을 하나로 고정했습니다. 그 용어가 내 화면에 글자로 실제로 등장하는가.
뜨면 남기고, 안 뜨면 버렸습니다. 중요도나 난이도가 아니라 조우 여부가 기준입니다. 이 기준은 검증이 가능하다는 게 장점입니다. 실행해 보면 뜨거나 안 뜨거나 둘 중 하나니까요.
이 기준을 적용하면 결과가 직관과 어긋납니다. 하네스, 서브에이전트, 오케스트레이션처럼 최근 자주 언급되는 용어가 전부 탈락합니다. 화면에 안 뜨니까요. 반대로 용어집에 거의 없던 EADDRINUSE나 CORS가 살아남습니다.
남은 아홉 개와 버린 열세 개의 성격 차이
| 구분 | 남긴 9개 | 버린 13개 |
|---|---|---|
| 등장 방식 | 에러 메시지·상태 표시로 화면에 출력 | 문서·영상·커뮤니티 대화에서 언급 |
| 모를 때 결과 | 그 자리에서 진행 불가 | 대화를 못 알아들음 |
| 예시 | 포트 충돌, 의존성, 404·500·CORS, 컴팩션, 룰 파일, 커밋·롤백, 환경변수 | 하네스, 서브에이전트, 스킬, 훅, MCP, 오케스트레이션, 샌드박스 등 |
| 학습 시점 | 첫 실행 전 | 뭔가 하나 만들어본 뒤 |
핵심은 오른쪽 열이 틀린 게 아니라 순서가 뒤라는 점입니다. 버린 열세 개도 결국 필요해집니다. 다만 아직 화면에 안 뜨는 시점에 외우면, 외운 채로 못 쓰는 상태가 됩니다.
기준을 실제 화면으로 검증한 과정
기준을 세웠으면 검증이 따라와야 합니다. 아홉 개 전부를 실제로 재현해 봤습니다.
Node 24와 Express로 최소 프로젝트를 만들고, 설치 없이 실행해서 Cannot find module을 받았습니다. 이어서 서버를 띄운 채로 한 번 더 실행해 EADDRINUSE를 냈고요. 이 두 번째는 의도한 게 아니었습니다. 3000번 포트를 다른 프로세스가 이미 쓰고 있어서 저절로 터졌습니다.
404는 없는 주소로, 500은 일부러 예외를 내는 라우트로, CORS는 3002번에 별도 출처를 띄워 3001번으로 요청을 보내 재현했습니다. 브라우저 콘솔에 실제로 찍힌 문장은 이겁니다.
Access to fetch at 'http://localhost:3001/' from origin 'http://localhost:3002'
has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is
present on the requested resource.
검증 과정에서 기준이 스스로 수정된 지점
여기서 기준의 약점이 하나 드러났습니다.
CORS는 화면에 안 뜹니다. 페이지에는 "불러오지 못했습니다" 같은 문구만 나오고, 진짜 메시지는 개발자 콘솔에만 있습니다. 500도 비슷합니다. 브라우저에는 세 글자만 나오고 원인은 서버를 띄운 창에 찍힙니다.
그래서 기준을 한 번 다듬었습니다. "화면에 뜨는가"가 아니라 **"어딘가에 글자로 남는가, 그리고 그 어딘가가 어디인지 아는가"**로요. 이게 오히려 더 쓸모 있는 기준이 됐습니다. 500 에러에서 브라우저만 들여다보는 게 초보자의 전형적인 시간 낭비이기 때문입니다.
아홉 개를 세 칸으로 다시 묶은 이유
아홉 개를 나열하면 그것도 목록입니다. 목록은 또 안 외워집니다.
그래서 실행 순서대로 묶었습니다. 안 켜지는 자리 두 개, 켜진 뒤 빨간 글씨 네 개, 에러 없이 이상해지는 자리 세 개. 이 순서는 임의가 아니라 실제로 마주치는 시간 순서입니다.
이렇게 묶으면 조회 방식이 바뀝니다. "이 단어가 뭐지"가 아니라 "지금 몇 번째 단계에서 막혔지"로 접근하게 되고, 후자가 훨씬 답하기 쉽습니다.
이 접근의 한계
기준이 깔끔하다고 결과까지 완벽한 건 아닙니다.
- 아홉 개는 제 재현 환경 기준입니다. Node·Express 조합에서 나온 것이라, 파이썬이나 다른 스택이면 목록이 달라집니다.
- 에러 메시지가 항상 원인을 정직하게 말하지 않습니다. 원인이 A인데 B에서 터지는 경우엔 세 칸 분류가 안 먹힙니다.
- 아홉 개를 다 알아도 만드는 건 장난감 수준입니다. 실제 서비스에는 부하·보안·데이터 설계가 따로 필요하고 그건 이 목록 밖입니다.
- 경쟁 영상 34편이라는 표본은 검색어 5종으로 모은 것이라 전수가 아닙니다.
정리
용어 학습에서 바꾼 건 목록의 내용이 아니라 선별 기준의 성격입니다. "중요한가"라는 주관적 기준을 "화면에 글자로 남는가"라는 검증 가능한 기준으로 바꿨더니, 목록이 절반 이하로 줄고 순서가 저절로 잡혔습니다.
혹시 다른 스택에서 이 기준을 적용해 보신 분이 있다면, 어떤 항목이 추가로 살아남았는지 궁금합니다.
전체 스물두 개를 등급까지 매긴 정리집은 오픈톡 방구석모각코에 있고, 아홉 개를 화면으로 하나씩 재현한 과정은 유튜브 방구석컴퍼니에 올려뒀습니다.