3  담론의 진화

바이브 코딩이라는 말이 자리 잡자마자 그것을 다듬거나 넘어서려는 개념들이 쏟아졌다. CHOP, 컨텍스트 엔지니어링, 스펙 주도 개발, 루프 엔지니어링, 바이브 엔지니어링. 이 장은 이 개념들의 계보를 그리고, 개념이 바뀔 때마다 무엇이 병목이었는지를 추적한다. 마지막 절은 이 개념 시장 자체를 분석 대상으로 삼는다.

3.1 CHOP과 에이전틱 코딩: 자율성의 스펙트럼

경고집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. 이 꼭지는 Steve Yegge가 바이브 코딩이라는 말이 퍼지기 전부터 쓰던 CHOP(chat-oriented programming)이라는 개념에서 출발해, 이후 정리된 에이전트 자율성 스펙트럼(어디까지 사람이 관여하고 어디부터 에이전트가 자율적으로 움직이는가)까지를 다룬다. CHOP과 바이브 코딩, 에이전틱 코딩이 서로 어떻게 구분되고 겹치는지가 핵심 질문이다. 3장은 바이브 코딩이라는 용어가 자리 잡은 뒤 쏟아진 후속 개념들을 다루는데, 이 꼭지는 그중 가장 먼저 나온 축을 맡는다.

시드 질문

  • Steve Yegge는 CHOP을 언제, 어떤 맥락에서 처음 제안했나, 바이브 코딩과의 선후 관계는 어떠한가?
  • CHOP과 바이브 코딩은 정의상 어떻게 다른가, 실무자들은 두 말을 구분해서 쓰는가 섞어 쓰는가?
  • “에이전틱 코딩”이라는 말은 CHOP, 바이브 코딩과 각각 어떤 관계에 있나?
  • 에이전트 자율성을 단계로 나누는 시도(자동완성에서 자율 실행, 자율 검증까지)는 누가, 어떤 기준으로 정리했나?
  • Gene Kim과 Steve Yegge가 함께 쓴 단행본은 이 개념들을 어떻게 종합했나?

조사 포인터

  • Steve Yegge, O’Reilly 팟캐스트 인터뷰에서 CHOP 관련 발언을 확인할 것
  • Gene Kim·Steve Yegge 공저 단행본 “Vibe Coding”의 정확한 출간 시점과 핵심 주장을 확인할 것
  • 에이전트 자율성 단계론을 다룬 실무 블로그 글(레벨 표를 제시한 사례)을 찾아 비교할 것

3.2 컨텍스트 엔지니어링

경고집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. 이 꼭지는 컨텍스트 엔지니어링이라는 개념의 명명과 정식화를 다룬다. Shopify CEO Tobi Lütke가 2025년 6월 트윗으로 이 말을 붙였고 Karpathy가 이를 승인하며 정식화에 힘을 실었다. 핵심 주장은 프롬프트 하나를 잘 쓰는 기술에서, 에이전트가 매 턴 무엇을 보고 무엇을 못 보는지, 즉 컨텍스트 창 구성 전체를 설계하는 기술로 병목이 옮겨갔다는 것이다. 3장에서 이 꼭지는 프롬프트 엔지니어링(1부)의 직접적 후계 개념을 다룬다.

시드 질문

  • Tobi Lütke는 정확히 어떤 트윗에서 이 말을 제안했고, 어떤 문제의식에서 나왔나?
  • Karpathy는 어떤 방식으로 이 명명에 동의했나, 그의 승인이 용어 확산에 어떤 역할을 했나?
  • “프롬프트 엔지니어링”과 “컨텍스트 엔지니어링”의 실질적 차이는 무엇인가, 겹치는 부분은 어디인가?
  • Simon Willison과 Phil Schmid는 각각 이 개념을 어떻게 정리했나, 두 정리 사이에 강조점의 차이가 있는가?
  • 컨텍스트 엔지니어링이라는 개념이 실제로 바꾼 개발 관행(CLAUDE.md·AGENTS.md류 문서, 컨텍스트 창 예산 관리 등)은 무엇인가?

조사 포인터

3.3 스펙 주도 개발

경고집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. 이 꼭지는 스펙 주도 개발을 바이브 코딩에 대한 반작용으로 다룬다. GitHub이 2025년 9월 공개한 Spec Kit은 Spec, Plan, Tasks, Implement 네 단계를 명시적으로 밟게 하는 도구다. 핵심 질문은 “코드가 존재한다는 사실조차 잊어버리라”는 바이브 코딩의 태도와, 명세를 먼저 쓰고 그것을 코드보다 우선시하는 스펙 주도 개발의 태도가 어떤 긴장 관계에 있는가이다. 이 대립이 폭포수와 애자일 논쟁의 재상연인지(4부 §10.1에서 다시 다룸)도 짚어야 한다. 3장에서 이 꼭지는 바이브 코딩에 대한 최초의 체계적 반작용을 맡는다.

시드 질문

  • GitHub Spec Kit이 명시한 네 단계(Spec, Plan, Tasks, Implement) 각각은 어떤 문제를 겨냥해 설계되었나?
  • 스펙 주도 개발을 표방하는 다른 도구·워크플로가 있는가, 있다면 접근 방식이 어떻게 다른가?
  • 스펙 주도 개발은 바이브 코딩을 대체하려는 시도인가 보완하려는 시도인가, 실무자들의 실제 사용 패턴은 어느 쪽에 가까운가?
  • 이 대립을 폭포수 대 애자일 논쟁(Royce 1970, Agile Manifesto 2001)과 겹쳐 보면 어떤 유사점과 차이점이 드러나는가?
  • 스펙 우선 접근이 실제로 코드 품질이나 검증 가능성을 높였다는 증거가 있는가?

조사 포인터

  • GitHub, “Spec-driven development with AI” (2025-09) 공식 발표문을 읽을 것
  • Winston Royce, “Managing the Development of Large Software Systems” (1970)과 Agile Manifesto (2001)를 원전으로 대조할 것
  • Spec Kit 외 유사 워크플로(다른 벤더의 plan-mode류 기능)를 조사해 비교할 것

3.4 루프 엔지니어링과 하네스 엔지니어링

경고집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. 이 꼭지는 2026년에 정리된 두 후계 개념, 루프 엔지니어링과 하네스 엔지니어링을 다룬다. 루프 엔지니어링은 Addy Osmani가 2026년 6월 무렵 정리하며 확산시킨 개념으로, 에이전트를 반복시켜 스스로 일을 찾고 검증하게 만드는 설계를 다룬다. 하네스 엔지니어링은 “에이전트는 모델과 하네스의 합”이라는 정식화에서 나온 개념으로, 모델 자체보다 그것을 둘러싼 도구·프롬프트·검증 장치의 설계를 강조한다. 두 개념이 프롬프트 엔지니어링, 컨텍스트 엔지니어링과 함께 병목 이동의 연속선 어디에 놓이는지가 핵심 질문이다.

시드 질문

  • Addy Osmani가 정리한 루프 엔지니어링의 핵심 주장은 무엇인가, 그가 인용한 실무 사례는 어떤 것들인가?
  • “루프”라는 단위(에이전트가 스스로 일을 찾고, 하고, 검증하고, 기억하는 순환)는 이전의 대화 턴 단위 상호작용과 무엇이 다른가?
  • “Agent = Model + Harness”라는 정식화는 누가, 언제 처음 제안했나, 이 정식화가 강조하는 것은 무엇인가?
  • 하네스 엔지니어링이라는 말은 실무에서 컨텍스트 엔지니어링과 어떻게 구분되어 쓰이는가, 겹쳐 쓰이는가?
  • 루프 엔지니어링과 하네스 엔지니어링 중 어느 쪽이 더 넓은 개념을 가리키는가, 아니면 서로 다른 축인가?

조사 포인터

3.5 바이브 엔지니어링과 그 반작용들

경고집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. 이 꼭지는 Simon Willison이 제안한 바이브 엔지니어링 개념과 그 주변의 재정의 시도들을 다룬다. 바이브 코딩이 “코드를 읽지 않고 전적으로 맡기는” 태도로 널리 이해되자, 이에 대한 반작용으로 빠른 속도를 유지하되 결과에 책임을 지는 태도를 가리키는 말들이 나왔다. 이 꼭지는 바이브 엔지니어링이 바이브 코딩과 정확히 무엇이 다른지, 이런 재정의 시도들이 실무에서 실제로 구분되어 쓰이는지 검증해야 한다. 3장에서 이 꼭지는 §3.3(스펙 주도 개발)과 함께 바이브 코딩에 대한 반작용 축을 이룬다.

시드 질문

  • Simon Willison은 바이브 엔지니어링을 어떤 문제의식에서, 정확히 언제 제안했나?
  • 바이브 엔지니어링과 바이브 코딩의 경계는 구체적으로 어디에 그어지나?
  • “책임지는 가속”류의 재정의를 시도한 다른 필자나 개념이 있는가, 있다면 Willison의 정의와 비교하면 어떤가?
  • 이런 재정의 시도들은 실무 현장에서 실제로 구분되어 쓰이는가, 아니면 바이브 코딩이라는 말로 뭉뚱그려지는가?
  • 바이브 엔지니어링이라는 말 자체는 이후 얼마나 확산되었나, 아니면 소수 담론에 머물렀나?

조사 포인터

3.6 개념 시장의 관찰: 다음 유행어는 어떻게 만들어지는가

경고집필 상태

초안 전. 담당·상태는 저장소 루트의 TOPICS.md에서 확인.

브리프. 이 꼭지는 3장 전체를 메타 분석하는 자리다. 프롬프트 엔지니어링에서 시작해 바이브 코딩, 에이전틱 코딩, 컨텍스트 엔지니어링, 스펙 주도 개발, 루프 엔지니어링, 하네스 엔지니어링, 바이브 엔지니어링까지 이어진 용어들의 탄생, 확산, 소멸(또는 정착) 패턴 자체를 분석 대상으로 삼는다. 핵심 가설은 각 개념의 교체가 실제 병목의 이동(모델 능력 부족에서 컨텍스트 관리 부족, 검증 부족, 루프·시스템 설계 부족으로)을 반영한다는 것이다. 이 가설이 맞다면 다음 유행어가 가리킬 병목도 예측해볼 수 있다. 1부의 마지막 꼭지로서 2부(기술)로 넘어가기 전 개념사 전체를 정리하는 역할을 한다.

시드 질문

  • 이 장에서 다룬 개념들을 시간순으로 배열하면 각 개념의 수명(등장부터 다음 개념에 자리를 내주기까지)은 얼마나 되나?
  • 각 개념 교체 시점마다 실제로 이동한 병목은 무엇이었다고 주장할 수 있는가, 그 주장의 근거는 무엇인가?
  • 이 담론들은 실제 개발 관행을 바꿨는가, 아니면 기존 관행에 새 이름을 붙인 것에 가까운가?
  • 개념이 확산되는 경로(트윗 하나, 유력 인사의 승인, 언론 보도, 사전 등재)에 공통 패턴이 있는가?
  • 이 분석이 맞다면, 다음 병목과 다음 유행어는 어느 방향일 것으로 예측할 수 있는가?

조사 포인터

  • 이 장의 다른 꼭지(§3.1~§3.5)에서 확정한 각 개념의 정확한 등장 시점을 표로 정리해 시간순으로 비교할 것
  • 용어 확산 메커니즘 자체를 다룬 언어학·밈 확산 연구가 있는지 검색할 것
  • Meir Lehman의 소프트웨어 진화 법칙(1970년대)이 개념 자체의 진화에도 유비될 수 있는지 검토할 것