1  전사(前史): 사람이 기계에게 말 걸어온 역사

바이브 코딩은 어느 날 갑자기 나타나지 않았다. “사람의 말로 프로그래밍한다”는 꿈은 컴퓨팅의 역사만큼 오래됐고, 그때마다 다른 이름을 달고 돌아왔다. 이 장은 그 반복의 역사에서 시작해, 바이브 코딩의 직접적 전사인 프롬프트 엔지니어링까지 온다.

1.1 자연어 프로그래밍이라는 오래된 꿈

경고집필 상태

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

브리프. “코드를 자연어로 쓰면 프로그래밍 진입 장벽이 사라진다”는 발상은 바이브 코딩이 처음이 아니다. COBOL이 내걸었던 “영어에 가까운 문법”부터 4세대 언어(4GL), CASE(Computer-Aided Software Engineering) 도구까지, 비슷한 약속이 수십 년에 걸쳐 반복되어 왔고 매번 완전히는 실현되지 못했다. 이 꼭지는 그 반복의 역사를 추적하고, 각 시도가 구체적으로 무엇을 약속했고 어디서 좌절했는지를 정리해야 한다. 바이브 코딩을 이 역사의 최신 반복으로 볼지, 질적으로 다른 단절로 볼지 판단할 근거를 마련하는 것이 이 꼭지의 목표다. 1부 전체에서 가장 먼 기원을 다루는 자리다.

시드 질문

  • COBOL 설계자들은 “영어처럼 읽히는 코드”로 실제 무엇을 노렸나, 그 목표는 어느 정도 달성되었나?
  • 4GL은 어떤 문제를 풀겠다고 등장했고, 실제 채택은 어떤 궤적을 그렸나?
  • CASE 도구의 약속과 1990년대의 실패 사례는 구체적으로 무엇이었나?
  • 자연어 프로그래밍의 반복된 좌절에는 공통 원인이 있는가, 아니면 시도마다 다른 원인이었는가?
  • 바이브 코딩이 “이번엔 다르다”고 주장할 근거가 있다면 무엇인가, 아니면 같은 패턴의 반복인가?

조사 포인터

  • COBOL 원 설계 문서(CODASYL 관련 자료)와 Grace Hopper의 관련 발언 기록을 1차 출처에서 확인할 것
  • 4GL과 CASE 도구의 역사를 다룬 소프트웨어공학 교과서(예: Pressman, Sommerville)의 서술을 대조할 것
  • 자연어 프로그래밍의 반복된 실패를 다룬 학술 리뷰나 회고 글이 있는지 검색할 것

1.2 엔드유저 프로그래밍: 스프레드시트라는 선례

경고집필 상태

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

브리프. 비프로그래머가 프로그래밍을 하는 시대는 이미 있었다. 스프레드시트에서 셀 수식을 쓰는 행위는 형식상 프로그래밍이고, 수십 년간 가장 널리 채택된 엔드유저 프로그래밍 사례다. 이 꼭지는 무엇이 스프레드시트를 성공시켰는지(즉시 피드백, 시각적 표현, 낮은 진입 장벽 등 후보들을 검증할 것)를 분석하고, 이것이 바이브 코딩에 주는 시사점을 도출해야 한다. 동시에 스프레드시트 오류가 실무에서 반복적으로 큰 사고를 낸 반례도 다뤄야 한다. 1부에서 이 꼭지는 “비전문가의 프로그래밍”이라는 주제를 프로그래밍 언어가 아니라 도구 형태의 관점에서 접근하는 대응축이다.

시드 질문

  • 엔드유저 프로그래밍이라는 용어는 학계(HCI, 프로그래밍 언어 연구)에서 어떻게 정의되어 왔나?
  • 스프레드시트가 다른 자연어·저코드 시도보다 훨씬 널리 채택된 이유는 무엇인가?
  • 스프레드시트 오류로 인한 실제 사고 사례(재무, 학술 등)는 어떤 것이 있고 무엇을 시사하는가?
  • 스프레드시트의 즉시 실행 피드백 구조는 바이브 코딩의 실행 확인 루프와 어떤 점에서 유사하고 다른가?
  • 로우코드·노코드 플랫폼은 스프레드시트의 어떤 성공 요인을 계승했고 어떤 요인을 놓쳤나?

조사 포인터

  • 엔드유저 프로그래밍 연구 문헌(HCI/PL 교차 분야, 예: Burnett 등의 연구)을 검색할 것
  • 스프레드시트 오류 사례 모음(European Spreadsheet Risks Interest Group의 사고 아카이브 등)을 확인할 것
  • VisiCalc, Lotus 1-2-3, Excel의 채택사를 다룬 컴퓨팅사 자료에서 정확한 연도와 수치를 확인할 것

1.3 프롬프트 엔지니어링의 짧은 전성기

경고집필 상태

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

브리프. 바이브 코딩 직전 단계에는 프롬프트 엔지니어링이라는, 지금 보면 짧았던 전성기가 있었다. 거대언어모델에게 “무엇을 어떻게 말할 것인가”가 하나의 독립된 기술로 취급되던 시기, few-shot·chain-of-thought 같은 기법이 발견되고 정리되는 과정, 그리고 “프롬프트 엔지니어”라는 직함이 채용 시장에 등장했다가 빠르게 흐려지는 과정을 다뤄야 한다. 이 기법 중심 시대의 어떤 한계가 반복 대화와 실행 확인 중심인 바이브 코딩이라는 다음 단계를 불렀는지가 핵심 질문이다. 1부에서 이 꼭지는 2장(탄생)으로 넘어가기 직전의 마지막 전사를 맡는다.

시드 질문

  • “프롬프트 엔지니어링”이라는 말은 언제, 어느 커뮤니티에서 처음 쓰이기 시작했나?
  • few-shot, chain-of-thought, 역할 부여 같은 대표 기법은 각각 어떤 문제를 풀려고 나왔나?
  • “좋은 프롬프트를 쓰는 기술”과 “모델과 반복 대화하며 만드는 기술”의 경계는 어디서, 왜 무너지기 시작했나?
  • 프롬프트 엔지니어 채용 공고는 언제 정점을 찍었고 언제부터 줄었나?
  • Karpathy의 Software 2.0(2017) 논의는 프롬프트 엔지니어링 시대를 예견한 것으로 읽을 수 있는가?

조사 포인터

  • Anthropic과 OpenAI의 공식 프롬프트 엔지니어링 가이드 문서를 원전으로 확인할 것
  • chain-of-thought 관련 초기 학술 논문(Wei et al. 등)의 발표 시점과 핵심 주장을 확인할 것
  • 프롬프트 엔지니어 채용 공고의 등장과 소멸을 다룬 언론 기사를 수집할 것
  • Karpathy, “Software 2.0” (2017)이 이 시기 담론과 어떻게 연결되는지 재독할 것