부록 A — 개념 사전
바이브 코딩 주변에서 태어나고 진화하는 개념들의 사전이다. 항목마다 정의, 유래, 현재 상태를 적는다. 개념은 계속 나타나고 뜻이 바뀌므로 이 부록은 영원히 미완성이며, 그래서 이 책에서 가장 자주 갱신되는 부분이다. 항목 하나가 곧 기여 단위다. 새 항목 추가와 담당은 저장소의 TOPICS.md에서 한다.
정의 두어 문장, 유래(누가 언제), 현재 상태. 유래의 날짜와 인물은 1차 출처를 확인하고 링크를 단다. 확인하지 못한 것은 “유래 확인 필요”로 표시한다.
A.1 바이브 코딩 (vibe coding)
자연어로 AI 코딩 에이전트에게 지시해 소프트웨어를 만드는 방식이다. 좁은 뜻으로는 생성된 코드를 직접 읽지 않고 실행 결과만 보며 반복하는 작업 태도를 가리키고, 넓은 뜻으로는 AI 보조 개발 전반을 가리킨다.
Andrej Karpathy가 2025년 2월 트윗에서 만든 말이다. 원문에는 “fully give in to the vibes, embrace exponentials, and forget that the code even exists”라는 표현이 들어 있다 (원 트윗). Karpathy는 2026년 2월 1주년 회고 트윗에서 이 말을 “shower of thoughts throwaway tweet”이라고 돌아봤다 (회고 트윗).
2025년 11월 Collins 사전 올해의 단어로 선정되며 일반어가 됐다 (발표, 보도). Simon Willison은 “코드를 읽지 않는 방식”과 “AI 보조 개발 전반”을 구분하자고 제안했지만 (글), 실제 사용에서는 두 뜻이 섞여 쓰인다.
- Willison 글 전문을 읽고 그가 구분한 스펙트럼을 정리할 것
- Karpathy 1주년 회고 트윗 전문에서 원 트윗 당시 맥락(어떤 모델·도구를 쓰고 있었는지) 확인할 것
- 위키피디아 개관 문서(링크)와 대조해 뜻의 표류 사례를 추가로 모을 것
A.2 프롬프트 엔지니어링 (prompt engineering)
원하는 출력을 얻기 위해 모델에 주는 입력, 즉 프롬프트를 설계하는 기술이다. few-shot 예시 구성, chain-of-thought 유도 등 특정 기법을 발견하고 체계화하는 작업을 포함한다.
GPT-3 공개(2020) 이후 한동안 하나의 직무처럼 다뤄졌다. 정확히 누가 언제 이 말을 직무 명칭으로 굳혔는지는 확인이 필요하다.
모델 성능이 좋아지고 상호작용이 대화형, 에이전트형으로 바뀌면서 독립 기술로서의 위상은 흐려졌다. 이 책의 관점에서는 바이브 코딩의 전사(前史)에 해당한다.
- “프롬프트 엔지니어”라는 직무명이 언제 등장하고 채용 공고에서 언제 사라졌는지 시계열 확인
- few-shot, chain-of-thought 등 대표 기법의 원 논문 확인
- 직무 소멸을 보도한 기사 수집 (§1.3 섹션과 연계)
A.3 컨텍스트 엔지니어링 (context engineering)
프롬프트 한 줄이 아니라 모델이 보는 컨텍스트 전체, 즉 파일, 문서, 대화 이력, 도구 출력을 설계하는 기술이다. 프롬프트 엔지니어링의 병목이 “말을 어떻게 하나”에서 “무엇을 보여주나”로 이동했음을 반영한다.
Tobi Lütke(Shopify CEO)가 2025년 6월 19일 트윗으로 이름을 붙였고 Karpathy가 이를 승인하는 트윗을 남겼다 (Karpathy 트윗). Simon Willison과 Phil Schmid가 각각 개념을 정리하는 글을 썼다 (Willison, Schmid).
2025년 하반기부터 널리 쓰이기 시작했고, 현재는 CLAUDE.md, AGENTS.md 같은 컨텍스트 파일 설계 관행을 가리키는 실무 용어로 자리 잡았다.
- Lütke 원 트윗 전문과 스레드 반응 확인
- Willison·Schmid 두 정리 글의 정의 차이 비교
- §3.2, §5.3 섹션에서 다루는 실무 사례와 교차 확인
A.4 에이전틱 코딩 (agentic coding)
AI가 한 번 답하고 끝나는 것이 아니라 도구를 호출하고 코드를 실행하고 결과를 확인한 뒤 다음 행동을 정하는 루프를 돌며 작업하는 방식이다. 바이브 코딩을 실제로 가능하게 만든 기술 형태다.
“에이전틱 코딩”이라는 표현을 누가 언제 처음 썼는지는 확인이 필요하다. 다만 이 루프 구조 자체를 정리한 참고 문헌으로 Anthropic의 “Building Effective Agents”(2024년 12월)가 있다 (링크).
CLI형 코딩 에이전트(Claude Code 등)와 IDE 통합형 에이전트가 이 방식을 구현하는 대표 도구로 꼽힌다. §2.3, §8.2 섹션에서 도구 계보와 루프 구조를 각각 다룬다.
- “agentic coding” 용어의 최초 사용례 확인
- Anthropic “Building Effective Agents”의 워크플로/에이전트 구분과 이 책의 용법 대조
- §8.2(코딩 에이전트의 해부학)와 정의 정합성 확인
A.5 CHOP (chat-oriented programming)
채팅 인터페이스로 대화하듯 AI에게 지시해 코드를 만드는 방식을 가리키는 말이다. 바이브 코딩과 인접한 개념으로, 코드를 직접 다루기보다 대화로 작업을 진행한다는 점을 강조한다.
Steve Yegge가 바이브 코딩이라는 말이 나오기 전에 만든 용어다 (O’Reilly 팟캐스트). 정확한 최초 사용 시점은 확인이 필요하다. Yegge는 Gene Kim과 함께 “Vibe Coding”이라는 단행본을 공저했는데, 정확한 출간 정보는 확인이 필요하다.
바이브 코딩이라는 말이 대중화된 뒤로는 CHOP이 더 이전 세대 용어, 또는 바이브 코딩의 동의어에 가깝게 쓰이는 경우가 많다.
- CHOP 최초 사용 시점과 맥락(어떤 글, 어떤 발표)을 원 출처에서 확인
- Kim·Yegge 공저 “Vibe Coding” 출간일, 출판사 확인
- CHOP과 바이브 코딩을 같은 말로 쓰는 사례와 구분해 쓰는 사례를 각각 수집 (§3.1과 연계)
A.6 바이브 엔지니어링 (vibe engineering)
바이브 코딩의 속도를 유지하면서도 결과물의 책임을 지는 작업 방식을 가리키는 말이다. 검증, 테스트, 리뷰 같은 공학적 절차를 바이브 코딩 워크플로에 다시 결합하자는 제안에 가깝다.
Simon Willison이 제안한 개념이다 (글). 2025년 가을로 알려져 있으나 정확한 발행일은 확인이 필요하다.
바이브 코딩의 “검증 문제”에 대한 반작용 개념 중 하나로, §3.5에서 이런 반작용 개념들을 함께 다룬다.
- Willison 글의 정확한 발행일과 정의 원문 확인
- vibe engineering과 spec-driven development, TDD 부활론(§10.4) 등 인접 반작용 개념과의 관계 정리
- Willison 이후 이 용어를 쓴 다른 저자·기사 존재 여부 확인
A.7 루프 엔지니어링 (loop engineering)
프롬프트를 사람이 매번 치는 대신, 에이전트가 일을 찾고 수행하고 검증하고 기록하는 루프 자체를 설계하는 기술이다. 프롬프트 엔지니어링의 후계 개념으로 이야기된다.
2026년 6월 Addy Osmani의 정리 글을 계기로 널리 퍼졌다 (보도).
이 책의 관점에서는 바이브 코딩의 다음 장에 해당하는 개념이다. §3.4에서 하네스 엔지니어링과 함께 다룬다.
- Osmani 원문 글(정리 글의 원 출처) 찾아 인용 확인
- loop engineering과 agent harness 개념이 어디서 겹치고 어디서 갈리는지 정리
- 이 용어를 쓰는 실제 도구·워크플로 사례 수집 (§3.4와 연계)
A.8 에이전트 하네스 (agent harness / harness engineering)
에이전트를 실제로 작동하게 만드는 실행 환경, 즉 도구 접근, 권한, 루프 제어, 컨텍스트 관리 장치 전체를 가리키는 말이다. “Agent = Model + Harness”라는 정식화에서, 모델의 성능과 별개로 하네스 설계가 에이전트 품질을 좌우한다는 관점을 담는다.
프롬프트 엔지니어링에서 컨텍스트 엔지니어링을 거쳐 하네스 엔지니어링으로 이어지는 3단계론으로 정리된 바 있다 (Faros AI 블로그). 이 정리 글 이전에 누가 “하네스”라는 말을 에이전트 실행 환경에 처음 썼는지는 확인이 필요하다.
Claude Code 같은 CLI형 코딩 에이전트 도구가 하네스의 대표 사례로 꼽힌다. §3.4, §8.2 섹션과 겹친다.
- “harness”라는 말이 에이전트 문맥에서 쓰이기 시작한 최초 시점 확인
- Faros AI 정리 글의 3단계론(프롬프트→컨텍스트→하네스)을 원문에서 확인하고 이 책 §3.4와 대조
- 오픈소스 에이전트 하네스 사례(§8.2에서 다루는 소스 읽기 대상)와 연결
A.9 스펙 주도 개발 (spec-driven development)
AI에게 바로 코드를 시키지 않고 먼저 명세, 즉 스펙을 함께 작성한 뒤 그 명세를 기준으로 생성과 검증을 진행하는 방식이다. “코드를 읽지 않는” 바이브 코딩의 검증 문제에 대한 대표적 대응으로 이야기된다.
GitHub이 2025년 9월 Spec Kit을 공개하며 Spec, Plan, Tasks, Implement 4단계 흐름을 제시했다 (GitHub 블로그).
폭포수 개발의 명세 우선 원칙이 AI 시대에 재발견된 사례로 볼 수 있다. §3.3, §10.1에서 각각 개념 확산과 폭포수 논쟁 재상연을 다룬다.
- Spec Kit 이전에 유사한 “스펙 먼저” 도구·제안이 있었는지 확인
- Spec Kit의 4단계 흐름과 §10.1이 다루는 폭포수 모델의 단계 구분을 비교
- Spec Kit 채택 사례나 비판 글 수집
A.10 서브에이전트 (subagent / 멀티에이전트)
메인 에이전트가 특정 작업을 별도의 독립된 에이전트 인스턴스에 위임하는 구조, 또는 그렇게 위임받아 실행되는 개별 에이전트를 가리키는 말이다. 위임받은 서브에이전트는 자신의 컨텍스트 창과 도구 접근 범위를 따로 가지며, 작업을 마치면 결과만 메인 에이전트에 반환하는 방식이 일반적이다. 여러 서브에이전트를 동시에 또는 순차로 조율하는 구조를 멀티에이전트 시스템이라 부른다.
용어의 정확한 유래는 확인이 필요하다.
컨텍스트 창을 아끼면서 작업을 병렬화하는 수단으로 여러 코딩 에이전트 도구가 이 구조를 채택하고 있다. §8.2에서 다루는 에이전트 해부학의 구성 요소 중 하나다.
- 서브에이전트 개념을 처음 제품화한 도구와 시점 확인
- 서브에이전트 간 컨텍스트 격리 방식이 도구마다 어떻게 다른지 비교
- §8.2(코딩 에이전트의 해부학)와 정의 정합성 확인
A.11 휴먼 인 더 루프 (human-in-the-loop)
자동화된 시스템의 실행 과정에 사람의 확인이나 개입 지점을 명시적으로 두는 설계를 가리키는 말이다. AI 코딩 에이전트 맥락에서는 파일 수정, 명령 실행, 배포처럼 되돌리기 어려운 행동 전에 사람의 승인을 받도록 하는 장치를 뜻한다.
AI 코딩 이전부터 자동화·제어 시스템 분야에서 쓰이던 일반 용어이며, 정확한 최초 유래는 확인이 필요하다.
코딩 에이전트 도구에서는 권한 프롬프트, 계획 모드(plan mode), 변경 사항 승인 UI 등의 형태로 구현된다. §5.6에서 다루는 위임의 한계선 논의와 직결된다.
- 자동화·제어 분야에서 이 용어가 쓰인 최초 문헌 확인
- 코딩 에이전트별 human-in-the-loop 구현 방식(승인 UI, plan mode 등) 비교
- §5.6(언제 멈추고 직접 읽어야 하는가)과의 관계 정리
A.12 환각 (hallucination)
언어 모델이 사실이 아니거나 존재하지 않는 내용을 그럴듯하게 생성하는 현상을 가리키는 말이다. 코딩 맥락에서는 존재하지 않는 함수, 라이브러리, API를 실재하는 것처럼 생성하는 경우가 대표적이다.
머신러닝 분야에서 먼저 쓰이던 말이 대형 언어 모델로 옮겨온 것으로 알려져 있으나, 정확한 최초 용례와 시점은 확인이 필요하다.
코딩 에이전트가 존재하지 않는 패키지명을 생성하는 경우가 공급망 공격으로 이어질 수 있다는 점에서 슬롭스쿼팅(G14)과 직결된다. §9.2에서 보안 맥락으로 다룬다.
- “hallucination”이 언어 모델 오류를 가리키는 말로 쓰이기 시작한 최초 논문·글 확인
- 코드 생성 맥락에서의 환각 실증 연구(존재하지 않는 패키지 생성 비율 등) 수집
- §9.2(보안: 새로운 공격면)와 슬롭스쿼팅 항목을 교차 확인
A.13 슬롭 (slop / workslop)
품질 검토 없이 대량으로 생성된, 낮은 품질의 AI 산출물을 가리키는 말이다. workslop은 그중에서도 업무 맥락, 즉 보고서나 문서, 코드처럼 동료나 조직이 소비해야 하는 산출물에 한정해 쓰이는 표현이다.
유래 확인 필요. 누가 언제 이 말을 만들었는지, workslop이라는 변형어가 별도로 언제 등장했는지 모두 원 출처를 찾아 검증해야 한다.
생성 속도가 검토 속도를 앞지르면서 나타난 현상을 가리키는 말로 통용되고 있으며, §9.3(품질 부채와 유지보수)에서 다루는 문제와 연결된다.
- “slop”과 “workslop” 각각의 최초 용례와 유래를 원 출처에서 확인
- workslop을 다룬 실증 연구(생산성 손실 추정치 등)가 있는지 확인
- §9.3과 사실관계 대조
A.14 슬롭스쿼팅 (slopsquatting)
AI 코딩 에이전트가 환각으로 만들어낸, 실재하지 않는 패키지명을 공격자가 미리 등록해 두는 공급망 공격 기법을 가리키는 말이다. 개발자가 에이전트의 제안을 그대로 설치 명령에 넣으면 공격자가 등록한 악성 패키지가 설치된다.
유래 확인 필요. 누가 언제 이 용어를 만들었는지 원 출처를 찾아 검증해야 한다. typosquatting(오타를 노린 패키지명 선점)에서 파생된 조어로 보이나 이 계보 역시 확인이 필요하다.
생성 코드의 신뢰 문제를 보여주는 대표 사례로 보안 논의에서 자주 언급된다. §9.2(보안: 새로운 공격면)에서 다루는 핵심 사례다.
- slopsquatting 용어의 최초 사용례(보안 연구, 블로그, 논문 등) 확인
- 실제 관측된 slopsquatting 공격 사례와 피해 규모 수집
- §9.2와 사실관계 대조
A.15 MCP (Model Context Protocol)
AI 모델이 외부 도구, 데이터 소스, 서비스와 통신하는 방식을 표준화한 프로토콜이다. 이 표준을 따르는 서버를 구현하면 서로 다른 AI 애플리케이션이 같은 도구 연동 코드를 재사용할 수 있다.
Anthropic이 공개한 프로토콜이다. 정확한 공개 시점은 확인이 필요하다.
코딩 에이전트가 파일 시스템 바깥의 도구(브라우저, 데이터베이스, 사내 시스템 등)에 접근하는 표준 경로로 자리 잡았다. 실무에서는 MCP 서버 대신 직접 API 호출로 전환하는 사례도 나타나고 있다.
- MCP 공개 정확한 날짜와 최초 발표 자료(Anthropic 공식 블로그·문서) 확인
- MCP 이전에 존재하던 도구 연동 방식(함수 호출, 플러그인 등)과의 차이 정리
- MCP 채택 현황(어떤 회사·도구가 지원하는지) 수집
A.16 RAG (retrieval-augmented generation)
모델이 답을 생성하기 전에 외부 문서나 데이터베이스에서 관련 내용을 검색해 프롬프트에 포함시키는 기법이다. 모델의 학습 데이터에 없는 최신 정보나 비공개 문서를 답변에 반영할 수 있게 한다.
유래 확인 필요. 최초 제안 논문과 저자, 발표 시점을 원 출처에서 확인해야 한다.
코딩 에이전트에서는 사내 코드베이스나 문서를 검색해 컨텍스트에 넣는 용도로 쓰이며, 컨텍스트 엔지니어링(G3)의 구체적 구현 기법 중 하나로 다뤄진다.
- RAG를 처음 제안한 논문의 저자·발표 시점을 원 출처에서 확인
- 코딩 에이전트 맥락에서의 RAG 활용 사례(코드 검색, 문서 검색) 수집
- 컨텍스트 엔지니어링 항목과의 관계 정리
A.17 토큰과 컨텍스트 윈도 (tokens / context window)
토큰은 언어 모델이 텍스트를 처리하는 최소 단위로, 단어보다 작을 수도 여러 단어를 묶을 수도 있다. 컨텍스트 윈도는 모델이 한 번에 참조할 수 있는 토큰의 최대 개수를 가리킨다.
일반 기술 용어로, 특정 인물이나 시점에 귀속되는 유래는 없다.
코딩 에이전트가 다룰 수 있는 코드베이스의 크기, 대화의 길이, 컨텍스트에 넣을 수 있는 파일 수를 모두 이 한계가 좌우한다. 컨텍스트 윈도가 커질수록 컨텍스트 엔지니어링(G3)의 중요성이 오히려 부각된다는 관찰이 있다. §5.3에서 실무적 관리 기술을 다룬다.
- 주요 모델별 컨텍스트 윈도 크기 변화 추이(수치는 반드시 공식 문서로 확인)
- 토큰화 방식(BPE 등)이 코드에 어떻게 특히 적용되는지
- §5.3(컨텍스트 관리의 기술)과 사실관계 대조
A.18 evals (평가)
AI 모델이나 에이전트의 출력을 정해진 기준에 따라 채점하는 절차, 또는 그 채점에 쓰이는 테스트 집합을 가리키는 말이다. 소프트웨어의 유닛 테스트에 대응하는 개념으로, 모델 성능이나 회귀 여부를 정량적으로 확인하는 데 쓰인다.
일반 기술 용어로, 특정 인물이나 시점에 귀속되는 유래는 없다.
코딩 에이전트 평가에서는 벤치마크 점수뿐 아니라 실제 저장소에서의 작업 성공률을 재는 evals가 함께 쓰인다. §5.4(검증 가능한 단위 만들기)와 맞닿아 있다.
- 코딩 에이전트용 대표 벤치마크(예: 저장소 기반 작업 성공률 측정)의 방법론 확인
- evals와 전통적 소프트웨어 테스트의 차이점(비결정성 처리 등) 정리
- §5.4와 사실관계 대조
A.19 가드레일 (guardrails)
AI 시스템의 입력과 출력에 제약을 걸어 의도하지 않은 행동이나 위험한 결과를 막는 장치를 가리키는 말이다. 프롬프트 필터링, 출력 검증, 실행 권한 제한 등 여러 층위에서 구현된다.
일반 기술 용어로, 특정 인물이나 시점에 귀속되는 유래는 없다.
코딩 에이전트에서는 파일 접근 범위 제한, 위험 명령 차단, 실행 전 승인 요구 같은 형태로 구현되며 휴먼 인 더 루프(G11)와 겹치는 부분이 많다. §9.2, §9.5에서 각각 보안과 책임 소재 맥락으로 다룬다.
- 코딩 에이전트 도구별 가드레일 구현 방식(권한 시스템, 샌드박스 등) 비교
- 가드레일 우회 사례(프롬프트 인젝션 등)와의 관계 정리
- §9.2, §9.5와 사실관계 대조
A.20 소프트웨어 2.0 / 3.0 (Software 2.0 / 3.0)
소프트웨어 2.0은 사람이 직접 규칙을 코드로 짜는 대신 데이터로 신경망 가중치를 학습시켜 프로그램을 만드는 패러다임을 가리키는 말이다. 소프트웨어 3.0은 이 계보를 이어, 자연어 프롬프트로 모델의 행동을 프로그래밍하는 단계를 가리키는 말로 쓰인다.
소프트웨어 2.0은 Andrej Karpathy가 2017년에 쓴 글에서 만든 개념이다 (링크). 소프트웨어 3.0이라는 후속 개념을 누가 언제 정식화했는지는 확인이 필요하다.
소프트웨어 2.0은 딥러닝 전반을 가리키는 말로 정착했고, 소프트웨어 3.0은 바이브 코딩 담론에서 자연어를 프로그램으로 보는 관점을 뒷받침하는 개념으로 쓰이고 있다.
- “Software 3.0” 개념을 누가 언제 처음 정식화했는지 원 출처 확인 (Karpathy의 이후 발표·글 포함)
- 소프트웨어 1.0/2.0/3.0 3단계 구분이 처음 어디서 나왔는지, 3.0이 2.0 글에 이미 있었는지 원문 확인
- §8.1(다음 토큰 예측에서 코드까지)과 개념적으로 어떻게 연결되는지 정리