10  방법론의 재발견

지난 50년의 소프트웨어 엔지니어링은 AI 시대에 하나씩 다시 발견되고 있다. 이 부(部)의 각 꼭지는 고전 개념 하나를 잡고 원전을 읽은 뒤, AI 시대의 재등장과 대조한다. 이 장은 일하는 방식의 방법론들이다. 폭포수와 애자일, 페어 프로그래밍, 코드 리뷰, TDD.

10.1 폭포수와 애자일, 다시

경고집필 상태

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

브리프. 스펙 주도 개발과 바이브 코딩의 대립이 폭포수와 애자일 논쟁의 재상연인지 묻는 꼭지다. 3단 구조로 쓴다. 먼저 Royce(1970)의 원논문이 실제로 무엇을 주장했는지, Agile Manifesto(2001)의 4가치와 12원칙이 원문으로 무엇을 말하는지 정확히 읽는다. 다음으로 GitHub Spec Kit류 스펙 주도 개발과 프롬프트로 시작해 반복 확인하는 바이브 코딩 실무가 각각 어느 쪽에 가까운지 최근 사례를 모은다. 마지막으로 반복 주기의 길이, 명세의 위치처럼 정말 같은 지점과 에이전트라는 새 행위자가 양쪽 모델의 전제를 바꾸는 지점을 가려 논증한다.

시드 질문

  • Royce(1970) 원논문을 실제로 읽으면 그가 정말 폭포수를 순수 순차 모델로 옹호했는가, 아니면 이미 반복의 필요성을 경고하고 있었는가? (원전 확인)
  • Agile Manifesto의 4가지 가치와 12원칙 중 어떤 조항이 오늘날 바이브 코딩의 정당화 논리로 가장 자주 인용되는가? (원전 확인)
  • 스펙 주도 개발(Spec Kit 등) 지지자들은 자신의 워크플로를 폭포수의 부활로 규정하는가, 아니면 애자일 내부의 한 변형으로 규정하는가? (재발견 사례 수집)
  • 프롬프트로 시작해서 반복 확인하는 바이브 코딩 실무는 애자일의 반복 주기와 어떤 점에서 같고 다른가, 특히 반복 단위 시간이 초 단위로 줄었을 때도 이론이 성립하는가?
  • 폭포수와 애자일 논쟁 당시의 비판(문서 과잉, 계획의 허구성)이 오늘날 스펙 주도 개발에 대한 비판과 얼마나 겹치는가?
  • 실무자들이 두 워크플로를 섞어 쓰는 사례가 있다면 어떤 기준으로 나누는가? (재발견 사례 수집)

조사 포인터

  • Royce 1970 원논문(저자명·연도로 검색해 원문 확인)
  • agilemanifesto.org 원문(4가치, 12원칙)
  • GitHub Spec Kit 발표 글과 실무자들의 채택·비판 블로그
  • 이 책 §3.3(스펙 주도 개발), §2.2(용어의 확산)과의 접점, 중복 서술 피할 것

10.2 페어 프로그래밍: 짝이 사람이 아니게 될 때

경고집필 상태

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

브리프. Beck의 XP(1999)가 페어 프로그래밍을 정당화한 논거를 AI를 짝으로 삼는 오늘날의 실무와 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 XP 원문에서 상시 리뷰, 지식 전파, 역할 교대 같은 페어링 논거를 정확히 읽는다. 다음으로 도구가 스스로를 “AI 페어 프로그래머”로 소개하는 방식과 실무자들의 워크플로 묘사를 사례로 모은다. 마지막으로 대등한 두 행위자, 상호 학습, 사회적 압력이라는 사람 페어링의 전제가 사람과 AI 관계에서 성립하는지 성립하지 않는지 논증한다.

시드 질문

  • Beck이 “Extreme Programming Explained”(1999)에서 페어 프로그래밍을 옹호한 핵심 논거는 정확히 무엇이었나, 단순한 결함 감소를 넘어선 부분까지 확인할 것 (원전 확인)
  • XP의 페어링은 운전자와 관찰자 역할 교대를 전제하는데, AI와의 협업에서 이 역할 교대가 실제로 일어나는가, 아니면 사람이 항상 관찰자 역할에 고정되는가?
  • AI 페어 프로그래밍이라는 표현을 처음 쓴 제품이나 문서는 무엇인가, 그 표현이 XP의 원래 의미를 어디까지 계승하고 어디서부터 은유로 미끄러지는가? (재발견 사례 수집)
  • 사람과 사람의 페어링 연구가 보고한 효과(결함 감소, 학습 효과) 중 사람과 AI 페어링에서도 재현된다고 주장하는 최근 연구나 사례가 있는가? (재발견 사례 수집)
  • 페어 프로그래밍의 사회적 메커니즘, 즉 부끄러움과 동료 압력과 즉각적 설명 요구는 AI 상대에게는 작동하지 않는데, 이 차이가 실제 작업 품질에 어떤 영향을 주는가?
  • XP 실천가들 사이에서도 있었던 페어 프로그래밍 반론(피로도, 비용)이 AI 페어 시대에는 어떻게 다르게 제기되는가?

조사 포인터

  • Beck, “Extreme Programming Explained”(1999) 원문 중 페어 프로그래밍을 다룬 장
  • 페어 프로그래밍 실증 연구(결함율, 소요 시간을 측정한 논문류)
  • GitHub Copilot, Cursor 등 도구의 페어 프로그래머 자기 소개 문구와 발표 자료
  • 실무자 블로그의 AI와 페어하는 워크플로 묘사

10.3 코드 리뷰: Fagan 인스펙션에서 AI 리뷰어까지

경고집필 상태

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

브리프. Fagan의 인스펙션(1976)이 세운 코드 리뷰의 원래 목적을 LLM 기반 자동 리뷰 도구와 대조하는 꼭지다. 3단 구조로 쓴다. 먼저 Fagan 인스펙션의 형식적 절차, 즉 사전 준비와 역할별 참가자와 결함 분류와 재작업 확인을 원전에서 정확히 읽는다. 다음으로 AI 리뷰어 도구가 실제로 무엇을 검사하고 무엇을 놓치는지 사례를 모은다. 마지막으로 결함 발견, 지식 전파, 조직 규범 확립이라는 리뷰의 세 기능 중 AI 시대에 무엇이 남고 무엇이 빠지는지 논증한다.

시드 질문

  • Fagan(1976)의 인스펙션 절차에서 참가자 역할(모더레이터, 저자, 리뷰어, 기록자)과 결함 분류 체계는 정확히 어떻게 정의되어 있었나? (원전 확인)
  • Fagan 인스펙션이 명시적으로 방지하려 한 것, 즉 저자가 스스로를 방어하는 상황이나 형식 없는 즉흥 리뷰는 오늘날 AI 리뷰 도구에서 어떤 형태로 재현되거나 사라지는가? (원전 확인)
  • 코드 리뷰의 전통적인 세 목적, 즉 결함 발견과 신참에 대한 지식 전파와 팀 코딩 규범 확립 중 AI 리뷰어는 무엇을 대체하고 무엇을 대체하지 못하는가? (재발견 사례 수집)
  • AI가 작성한 코드를 AI가 리뷰하는 구조는 Fagan이 전제한 저자와 리뷰어의 독립성 원칙과 어떻게 충돌하는가?
  • 실무에서 AI 리뷰 도구가 지적한 내용을 사람이 실제로 반영하는 비율에 대한 데이터가 존재하는가? (재발견 사례 수집)
  • Fagan 인스펙션 이후 경량 코드 리뷰로 넘어가면서 이미 한 번 형식성이 후퇴했는데, AI 리뷰어의 등장은 형식성을 다시 높이는 방향인가 낮추는 방향인가?

조사 포인터

  • Fagan, “Design and Code Inspections to Reduce Errors in Program Development”, IBM Systems Journal(1976) 원문
  • GitHub Copilot code review, Claude Code /code-review 등 도구 공식 문서
  • 코드 리뷰 실증 연구(대형 기술 기업의 코드 리뷰 관행을 다룬 논문류)
  • 이 책 §9.3(품질 부채)과 겹치지 않도록 리뷰 절차와 목적 자체에 집중할 것

10.4 TDD의 부활: 테스트가 스펙이 될 때

경고집필 상태

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

브리프. Beck의 TDD(2002)가 제시한 red-green-refactor 사이클과 테스트가 곧 명세라는 논거를 에이전트 코딩에서 테스트를 먼저 작성해 가드레일이자 검증 신호로 쓰는 최근 관행과 대조하는 꼭지다. 검증이 병목이라는 이 책의 관찰(§8.3)과 직결된다. 3단 구조로 쓴다. 먼저 TDD 원전의 사이클과 논거를 정확히 읽는다. 다음으로 에이전트 워크플로에서 테스트 우선 프롬프팅이 실무 관행으로 자리잡은 과정을 사례로 모은다. 마지막으로 Beck이 강조한 설계 도구로서의 TDD와 AI 출력 검증 도구로서의 테스트가 같은 것인지 다른 것인지 논증한다.

시드 질문

  • Beck이 “Test-Driven Development: By Example”(2002)에서 제시한 red-green-refactor 사이클의 정확한 순서와, 테스트를 설계 도구라고 부른 맥락은 무엇인가? (원전 확인)
  • Beck의 TDD 논거는 결함 감소보다 설계 압력, 즉 작은 단위로 나누고 인터페이스를 먼저 생각하는 데 방점이 있었는데, 이 설계 압력 논거가 AI가 코드를 쓰는 상황에서도 똑같이 성립하는가, 아니면 사람이 코드를 쓸 때만 유효했던 논거인가?
  • 테스트를 먼저 작성하게 하고 에이전트가 통과시키게 하는 워크플로가 도구 문서나 실무 관행에서 언제부터 명시적으로 등장했는가? (재발견 사례 수집)
  • TDD가 원래 전제한, 테스트를 쓰는 사람과 코드를 쓰는 사람이 같다는 조건이 에이전트가 테스트와 구현을 모두 작성하는 상황에서는 어떻게 깨지는가, 이것이 검증 신호로서의 유효성을 훼손하는가?
  • TDD 부활론자들이 인용하는 성공 사례와, AI가 테스트를 통과시키기 위해 테스트 자체를 조작하는 실패 사례가 둘 다 보고되는가? (재발견 사례 수집)
  • Kent Beck 본인이 최근 AI 코딩과 TDD의 관계에 대해 공개적으로 언급한 적이 있는가, 있다면 무엇이라 했는가?

조사 포인터

  • Beck, “Test-Driven Development: By Example”(2002) 원문(서문, 초반 예제 장)
  • 에이전트 코딩 도구의 테스트 우선 권장 문서, 실무자 블로그
  • 이 책 §8.3(검증 비대칭)과의 접점, 중복 서술 피할 것
  • Kent Beck 최근 인터뷰나 블로그에서 AI 코딩 관련 언급이 있는지 확인