애자일에 작별을 고하며

게시 2026/04/18

By BLUEBUG

37 분읽는 시간

애자일에 작별을 고하며

원문: Lewis Campbell (lewiscampbell.tech, 2026년 4월 14일)
한국어 커뮤니티 토론: GeekNews (news.hada.io)
분석 작성일: 2026-04-18

개요 및 배경
애자일의 역사적 계보
애자일 선언문의 정체성 문제
워터폴이라는 허수아비
Royce(1970)와 Bell-Thayer(1976): 애자일보다 앞선 통찰
LLM 시대의 등장과 스펙 기반 개발
한국 개발자 커뮤니티의 반응 분석
Hacker News 글로벌 커뮤니티 시각
비판적 종합 평가
결론: 애자일 이후의 세계는 어디로

1. 개요 및 배경

2026년 4월, 영국의 소프트웨어 컨설턴트 Lewis Campbell은 자신의 블로그에 “Saying Goodbye to Agile(애자일에 작별을 고하며)”라는 제목의 글을 게재했다. 이 글은 2001년 탄생한 ‘애자일 소프트웨어 개발 선언(Agile Manifesto)’을 정면으로 비판하는 내용을 담고 있으며, 한국의 개발자 커뮤니티 GeekNews와 글로벌 커뮤니티 Hacker News에서 활발한 논쟁을 불러일으켰다.

Campbell의 핵심 주장은 단순하면서도 도발적이다. “애자일이 해결했다고 주장하는 문제들은 이미 1970년대에 해결되어 있었으며, 애자일 선언문 자체는 의미 있는 지침을 거의 담고 있지 않다” 는 것이다. 더불어 LLM(대규모 언어 모델)의 확산으로 인해 소프트웨어 개발 패러다임이 다시 ‘스펙 기반 개발(Spec-Driven Development)’로 전환되고 있다고 주장한다.

이 글은 단순한 방법론 비판을 넘어, 25년간 소프트웨어 업계를 지배해 온 하나의 이념적 운동 전체를 재평가하는 시도라는 점에서 주목할 만하다.

2. 애자일의 역사적 계보

애자일이 어떤 역사적 흐름 속에서 탄생했는지 이해하기 위해서는 소프트웨어 공학의 역사를 되짚어볼 필요가 있다.

timeline
    title 소프트웨어 개발 방법론의 역사적 흐름
    1969 : 아폴로 11호 달 착륙
           아폴로 유도 컴퓨터(AGC) 소프트웨어 개발 성공
    1970 : Winston W. Royce 논문 발표
           반복적 개발·프로토타이핑·고객 참여 제안
           현재의 '워터폴 비판'이 이미 담겨 있음
    1976 : Bell & Thayer 논문
           '워터폴(Waterfall)'이라는 용어 최초 등장
           하지 말아야 할 방식의 예시로 제시
    1986 : Fred Brooks - No Silver Bullet
           소프트웨어 복잡성 본질에 대한 고전적 통찰
    1988 : Barry Boehm - Spiral Model
           리스크 기반 반복 개발 모델 제안
    1996 : Kent Beck - Extreme Programming(XP) 태동
    2001 : 애자일 선언문(Agile Manifesto) 발표
           17명의 개발자가 유타주 스노버드에서 합의
    2010s : SAFe, LeSS 등 스케일드 애자일 프레임워크 확산
            애자일 코치·스크럼 마스터 직군 폭발적 성장
    2023~: LLM 기반 개발 도구 확산
            Spec-Driven Development 부상
            Claude Code·Cursor 등 AI 코딩 에이전트 등장

이 타임라인에서 눈여겨볼 점은, 애자일 선언문(2001) 이전에 이미 반복적 개발, 고객 참여, 요구사항의 점진적 정제 등 모든 핵심 개념이 학문적으로 정립되어 있었다는 사실이다. Campbell의 비판은 바로 이 지점을 겨냥한다.

3. 애자일 선언문의 정체성 문제

3.1 선언문의 내용

2001년 발표된 애자일 선언문은 네 가지 핵심 가치와 열두 가지 원칙으로 구성된다. 네 가지 핵심 가치는 다음과 같다.

---
config:
  quadrantChart:
    chartWidth: 800
    chartHeight: 800
  themeVariables:
    quadrant1TextFill: "ff0000"
---
quadrantChart
    title 애자일 선언문의 4가지 핵심 가치 대립 구도
    x-axis "덜 중시 --> 더 중시"
    y-axis "전통적 접근 --> 애자일 접근"
    quadrant-1 "애자일이 선호"
    quadrant-2 "애자일이 수용"
    quadrant-3 "전통이 선호"
    quadrant-4 "균형 영역"
    "개인과 상호작용": [0.85, 0.90]
    "프로세스와 도구": [0.20, 0.20]
    "작동하는 소프트웨어": [0.80, 0.80]
    "포괄적 문서화": [0.25, 0.30]
    "고객 협업": [0.75, 0.85]
    "계약 협상": [0.30, 0.20]
    "변화에 대응": [0.85, 0.75]
    "계획 준수": [0.20, 0.35]

Campbell이 문제로 삼는 것은 이 가치들 자체가 아니다. 문제는 이 가치들이 지나치게 추상적이고 모호하여, 어떤 실천 방식도 “애자일”이라고 주장할 수 있다는 점이다.

3.2 “진짜 애자일” 방어 메커니즘

소프트웨어 업계에는 오랫동안 흥미로운 방어 논리가 존재해 왔다. 어떤 팀이나 조직이 애자일을 실천했다가 실패하면, 관찰자들은 이렇게 말한다: “그것은 진짜 애자일이 아니었어.”

이 방어 논리는 철학적으로 ‘노 트루 스코트맨(No True Scotsman)’ 오류와 동일한 구조를 가진다. 즉, 반증이 불가능한 방식으로 개념이 정의되는 것이다.

flowchart TD
    A[팀이 애자일을 도입함] --> B{결과는?}
    B -->|성공| C[✅ 애자일이 효과적이라는 증거]
    B -->|실패| D{원인 분석}
    D --> E[충분히 하지 않아서]
    D --> F[잘못 구현해서]
    D --> G[진짜 애자일이 아니었어서]
    E --> H[🔄 결론: 애자일 자체는 문제없음]
    F --> H
    G --> H
    H --> I[📌 애자일은 실패할 수 없는 개념이 됨]

    style C fill:#4CAF50,color:#fff
    style H fill:#FF9800,color:#fff
    style I fill:#F44336,color:#fff

이 구조는 Campbell뿐만 아니라 Hacker News 커뮤니티에서도 강하게 지적되었다. 한 댓글에서는 이를 클라우드 컴퓨팅, 마이크로서비스, 긴축 재정 등 다른 유행어에서도 동일하게 발견되는 패턴이라고 꼬집었다.

3.3 상업적 변질: 대문자 Agile의 탄생

선언문의 창시자들인 Kent Beck, Martin Fowler 등이 의도한 것은 유연한 가이드라인이었다. 그러나 시간이 흐르면서 ‘소문자 agile(유연한 개발 철학)’은 ‘대문자 Agile(스크럼 의식주의)’로 변질되었다.

스크럼 마스터(Scrum Master): 새로운 직군의 등장
애자일 코치(Agile Coach): 고액 컨설팅 산업화
SAFe(Scaled Agile Framework): 수백 페이지 분량의 규범화된 프레임워크
스토리 포인트, 번다운 차트, 벨로시티: 측정 지표의 목적화

이에 대해 Campbell은 냉소적으로 지적한다. “선언문 어디에도 데일리 스탠드업(Daily Standup)이나 애자일 코치에 대한 언급은 없다.”

4. 워터폴이라는 허수아비

4.1 애자일의 정체성 공식

Campbell의 분석에서 가장 날카로운 통찰 중 하나는 애자일이 본질적으로 워터폴의 반대 개념으로만 정의되어 왔다는 점이다.

flowchart LR
    subgraph AGILE["🔵 애자일 진영의 논리"]
        A1[당신이 애자일을 하지 않으면]
        A2[워터폴을 하고 있는 것]
        A3[워터폴은 실패한다]
        A4[∴ 애자일을 해야 한다]
        A1 --> A2 --> A3 --> A4
    end

    subgraph REALITY["🔴 현실"]
        R1[워터폴의 한계는 1970년부터 이미 알려짐]
        R2[반복적 개발은 새로운 개념이 아님]
        R3[Royce 1970 · Bell-Thayer 1976이 이미 답을 제시]
    end

    AGILE -.->|Campbell의 비판| REALITY

더 중요한 것은, “워터폴”이라는 용어 자체가 1976년 Bell과 Thayer의 논문에서 “하지 말아야 할 것의 예시”로 처음 등장했다는 사실이다. 즉, 워터폴은 당시에도 권장되는 방법론이 아니었다. 그럼에도 애자일은 수십 년 전에 이미 버려진 허수아비를 내세워 자신의 존재 이유를 정당화해 온 것이다.

4.2 전형적인 워터폴 vs 반복 개발의 비교

flowchart TD
    subgraph WF["전통적 워터폴 모델 (비판받는 방식)"]
        direction TB
        W1[요구사항 정의] --> W2[시스템 설계]
        W2 --> W3[구현·코딩]
        W3 --> W4[통합·테스트]
        W4 --> W5[운영·유지보수]
        W5 -.->|"문제 발견 시 처음으로 복귀<br/>(매우 비용이 큼)"| W1
    end

    subgraph IT["반복적 개발 (1970년 Royce가 이미 제안)"]
        direction TB
        I1[초기 요구사항 파악] --> I2[프로토타입 제작]
        I2 --> I3[고객 피드백]
        I3 --> I4[요구사항 정제]
        I4 --> I5[설계·구현]
        I5 --> I6[테스트·검증]
        I6 -->|"다음 이터레이션"| I2
    end

    WF -.->|"1970년 이미 비판됨<br/>→ Agile의 독창성이 아님"| IT

    style WF fill:#ffebee
    style IT fill:#e8f5e9

5. Royce(1970)와 Bell-Thayer(1976): 애자일보다 앞선 통찰

Campbell 주장의 핵심 역사적 근거는 두 편의 논문이다.

5.1 Winston W. Royce (1970)

달 착륙 다음 해인 1970년, Royce는 소프트웨어 개발에 관한 논문을 발표하며 워터폴 모델의 한계를 지적하고 다음의 대안을 제시했다.

Royce(1970) 제안	나중에 “애자일의 혁신”이라 불린 것
프로그램 설계로 시작	스프린트 계획·백로그 정제
소프트웨어 프로토타입으로 요구사항 정제	MVP(최소 기능 제품)·반복 개발
고객의 공식적·심층적·지속적 참여	고객 협업·스프린트 리뷰

Royce는 또한 문서화에 대해 이렇게 썼다: “코딩이 시작되기 전까지는 문서화·명세·설계는 동일한 것을 지칭한다. 문서가 나쁘면 설계도 나쁘다. 문서가 존재하지 않으면 설계도 아직 존재하지 않는 것이며, 오직 생각하고 이야기하는 수준에 불과하다.”

이 문장은 56년이 지난 오늘날, LLM 시대의 Spec-Driven Development 논의와 완벽하게 맞닿아 있다.

5.2 Bell & Thayer (1976)

Bell과 Thayer의 논문은 두 가지 이유로 역사적으로 중요하다.

‘Waterfall’이라는 용어를 최초로 사용한 문헌이다 — 단, 하지 말아야 할 방식의 예시로.
실증 연구를 통해 다음을 발견했다: “요구사항의 결함은 설계로 요구사항을 충족시키려 할 때 비로소 발견된다.” 이는 반복적 개발의 필요성을 경험적으로 증명한 것이다.

Campbell은 여기서 결정적인 질문을 던진다: “1970년과 1976년의 연구를 돌아보면, 2001년의 애자일 선언문이 도대체 어떤 새로운 통찰을 제공했단 말인가?”

6. LLM 시대의 등장과 스펙 기반 개발

6.1 패러다임의 역전

Campbell이 애자일의 ‘사망’을 선언하는 계기는 단순히 역사적 재검토에 그치지 않는다. 그는 현재 진행 중인 AI 혁명이 소프트웨어 개발의 철학적 기반을 뒤흔들고 있다고 주장한다.

flowchart LR
    subgraph AGILE_ERA["🔵 애자일 시대의 패러다임"]
        direction TB
        AE1["작동하는 소프트웨어 > 포괄적 문서화"]
        AE2["변화에 대응 > 계획 준수"]
        AE3["빠른 배포 → 피드백 → 반복"]
        AE4["명세보다 코드가 먼저"]
    end

    subgraph LLM_ERA["🟢 LLM/AI 시대의 패러다임"]
        direction TB
        LE1["포괄적 문서화 → 작동하는 소프트웨어"]
        LE2["명확한 명세 → 올바른 코드 생성"]
        LE3["LLM은 모호성에 취약 → 정밀한 스펙 필수"]
        LE4["Spec-Driven Development 부상"]
    end

    AGILE_ERA -->|"LLM 등장으로 역전"| LLM_ERA
    
    style AGILE_ERA fill:#e3f2fd
    style LLM_ERA fill:#e8f5e9

6.2 왜 LLM은 스펙을 요구하는가

LLM 기반 코딩 도구(Claude Code, Cursor, GitHub Copilot 등)가 보급되면서 실무 개발자들은 흥미로운 경험을 하고 있다. 모호한 지시를 주면 LLM은 모호한 코드를 생성한다. 반면 정확하고 구체적인 명세를 제공하면 품질 높은 코드가 나온다.

이는 소프트웨어 공학의 오래된 진리를 AI라는 매개체를 통해 다시 한번 증명하는 것이다: “입력의 품질이 출력의 품질을 결정한다.”

graph TD
    A[개발 요청] --> B{명세의 수준}
    
    B -->|"모호한 요청<br/>예: '로그인 기능 만들어줘'"| C[LLM 처리]
    B -->|"명확한 스펙<br/>예: 'JWT·OAuth 2.0·2FA 포함<br/>세션 타임아웃 30분 명세'"| D[LLM 처리]
    
    C --> E["❌ 불완전하거나<br/>수정이 많이 필요한 코드"]
    D --> F["✅ 요구사항을 충족하는<br/>고품질 코드"]
    
    E --> G[반복적 수정 사이클]
    F --> H[최소한의 수정으로 완성]
    
    G -->|"결국 더 많은 시간 소요"| I[비효율]
    H --> J[생산성 향상]

    style E fill:#ffcdd2
    style F fill:#c8e6c9
    style I fill:#ffcdd2
    style J fill:#c8e6c9

6.3 에이전트 시대의 스펙 작성

2025~2026년 현재, 흥미로운 역설이 등장하고 있다. AI 에이전트가 스펙을 작성하고, 인간이 그것을 검토하는 구조가 형성되고 있는 것이다.

이 구조에서는 다음의 흐름이 만들어진다:

sequenceDiagram
    participant Human as 👤 인간 개발자
    participant Agent as 🤖 AI 에이전트
    participant Codebase as 📁 코드베이스

    Human->>Agent: 비즈니스 요구사항 전달 (자연어)
    Agent->>Agent: 요구사항 분석 및 명세(Spec) 초안 작성
    Agent->>Human: Spec 초안 제시
    Human->>Agent: 검토·수정·승인
    Agent->>Agent: 승인된 Spec 기반으로 코드 생성
    Agent->>Codebase: 코드 커밋
    Agent->>Human: 결과 보고 및 테스트 결과 제시
    Human->>Agent: 피드백 제공
    Agent->>Agent: 다음 이터레이션 Spec 업데이트
    
    Note over Human,Codebase: 스펙의 품질 = 소프트웨어의 품질

이 과정에서 Campbell의 주장처럼 명세서(스펙)의 중요성이 극대화된다. 코드보다 스펙을 먼저, 그리고 더 신중하게 작성해야 하는 시대가 온 것이다.

7. 한국 개발자 커뮤니티의 반응 분석

GeekNews와 제공된 문서에 담긴 한국 개발자 커뮤니티의 반응은 크게 세 가지 입장으로 분류된다.

7.1 비판적 수용 (Campbell에 동조)

myc0058의 댓글은 한국적 맥락에서 가장 강렬한 공감을 얻었다:

“국내에서 애자일은 개발자들 일정 압박용 그 이상도 이하도 아님”

이 짧은 문장은 한국 IT 업계의 현실을 적나라하게 드러낸다. 애자일의 ‘스프린트’와 ‘빠른 출시’라는 개념이 실제로는 개발자에게 더 많은 업무를 더 빠르게 강요하는 도구로 악용되어 왔다는 것이다.

savvykang은 더 본질적인 문제를 지적했다:

“왜 이렇게 방법론을 경전처럼 여기는지 모르겠습니다. 원 저자도 방향만 달랐지 교조주의적인건 마찬가지라고 생각합니다.”

이는 Campbell의 글 역시 기존 애자일 옹호론과 같은 구조적 오류를 범할 수 있다는 날카로운 메타 비판이다.

7.2 반론: 여전히 애자일은 유효하다

tekart는 가장 균형 잡힌 반론을 제시했다:

“결론이 좀 과한 거 같네요. 상업화나 형식화가 문제일 수 있지만 스프린트나 백로그 같은 도구가 쓸모없어진 건 아니죠. SDD가 중요해졌다는 건 맞지만 그 스펙 자체를 AI와 협력적으로 신속하게 작성할 수 있으니 여전히 애자일하죠. 2주짜리 스프린트가 몇 시간 정도로 단축된 것일 뿐, 반복적으로 깎는다는 본질은 그대로인 거 같습니다.”

이 시각은 매우 중요하다. 애자일의 철학(반복·적응·피드백)은 살아있으며, LLM으로 인해 반복 주기가 단축될 뿐 본질은 유지된다는 관점이다.

dopeflamingo는 더 직접적으로 비판했다:

“바보같은 글이네요. spec 자체를 애자일하게 써야하는게 핵심인데…애자일은 고객 요구사항에 빠르게 변화해서 적응하는 겁니다.”

7.3 코드 vs 문서 논쟁

특히 주목할 만한 것은 develosopher와 snisper, willom2c 사이의 코드-문서 논쟁이다.

develosopher: “가독성 높은 코드는 문서를 생산할 필요가 없도록 만든다. 코드와 문서를 번갈아 보는 작업을 줄이는 것이 핵심이다.”

snisper: “코드는 문서를 대신할 수 없다. 프로그래밍 언어는 자연어의 풍부한 표현력을 갖지 못한다. 오르지 못할 바벨탑이다.”

willom2c: “반대로 자연어가 코드를 대체하기도 힘들다. 컴퓨팅을 위해서는 결국 디테일을 채워 넣어야 한다.”

graph LR
    subgraph DEBATE["코드 vs 문서 논쟁"]
        C["코드<br/>(실행 가능·구체·엄밀)"]
        D["문서<br/>(가독성·맥락·의도)"]
        N["자연어/스펙<br/>(표현력·추상성)"]
        
        C <-->|"표현력의 한계 ↔ 정밀성의 한계"| D
        D <-->|"추상성 ↔ 구체성"| N
        N <-->|"모호성 ↔ 실행 불가"| C
    end
    
    LLM["🤖 LLM의 역할<br/>세 요소를 중재·변환"]
    DEBATE --> LLM
    LLM -->|"자연어 스펙 → 코드"| DEBATE

이 논쟁의 핵심은 LLM이 자연어(스펙)와 코드 사이의 변환을 담당함으로써, 세 요소의 관계가 근본적으로 변하고 있다는 것이다.

8. Hacker News 글로벌 커뮤니티 시각

Hacker News의 논의는 한국 커뮤니티보다 더 심층적이고 다양한 관점을 제시했다.

8.1 애자일은 실패할 수 없는 개념이다

가장 많은 공감을 받은 논지는 애자일의 반증 불가능성이다.

“Agile을 통해 흥미로운 현상을 보게 되었음. 실패하면 ‘충분히 하지 않았다’는 식으로 해석되는 구조임. 클라우드, 마이크로서비스, 긴축정책 등에서도 같은 패턴을 봄.”

이는 철학적으로 중요한 지적이다. 어떤 이론이나 방법론이 반증 불가능하다면, 그것은 과학적 지식이 아니라 신앙에 가깝다.

8.2 대기업 애자일의 민낯

“내가 다닌 대기업들의 Agile은 거짓말이었음. 한 동료는 ‘다음 스프린트 일을 미리 해두면 항상 제때 끝난다’고 말했음. 즉, Agile은 실제 일보다 지표 생산 시스템으로 작동했음.”

이 증언은 한국의 “일정 압박용 애자일” 비판과 완벽하게 일치한다. 벨로시티, 번다운 차트, 스토리 포인트 등의 측정 지표가 실제 생산성이 아닌 지표 관리를 위해 조작되는 현실이 글로벌 공통 현상임을 보여준다.

8.3 규모 확장의 한계

“이 네 문장(애자일의 핵심 가치)은 훌륭하지만, 실제로는 작은 팀에서만 잘 작동함. 인원이 늘면 목표 정렬이 어려워지고, 결국 통제와 절차가 필요해짐.”

이 통찰은 중요하다. 애자일은 소규모 자율 팀을 전제로 한 방법론이다. SAFe, LeSS 같은 스케일드 애자일 프레임워크는 이 모순을 해결하려다 오히려 애자일의 본질을 훼손했다는 비판이 타당하다.

8.4 Kent Beck의 원래 의도

“Kent Beck이 ‘Extreme Programming’에서 말했듯, Agile은 상상된 전지전능함의 폭정을 피하려는 시도였음. 과거의 워터폴은 설계 단계에서 모든 걸 예측하려 했고, 학습과 피드백을 무시했음.”

이는 Campbell의 주장과 절충점을 찾는 시각이다. 애자일의 탄생 동기 자체는 유효했다. 다만 그것이 상업화되고 의식화되는 과정에서 본질이 왜곡되었다는 것이다.

9. 비판적 종합 평가

Campbell의 주장은 도발적이고 날카롭지만, 몇 가지 중요한 약점도 가지고 있다.

9.1 Campbell 주장의 강점

mindmap
  root((Campbell 주장의 강점))
    역사적 근거
      Royce 1970
      Bell-Thayer 1976
      실증적 선행 연구 존재
    애자일 상업화 비판
      애자일 코치 산업
      SAFe의 아이러니
      지표 조작 현실
    LLM 시대 통찰
      명세의 중요성 부활
      Royce의 재발견
      실용적 미래 방향
    선언문 분석
      모호성 지적
      No True Scotsman 구조 해체

9.2 Campbell 주장의 한계

mindmap
  root((Campbell 주장의 한계))
    과잉 일반화
      좋은 애자일 실천도 존재
      스프린트·백로그는 여전히 유용
      수평적 문화 기여 무시
    인과관계 혼동
      LLM 등장이 애자일을 죽인 것인가
      단순한 도구 변화 vs 철학 폐기
    대안의 불명확성
      Spec-Driven Development의 구체적 방법론은?
      문서화의 실용적 한계 미언급
    역사적 선택 편향
      불리한 반례 무시 가능성
      성공한 애자일 사례 외면

9.3 본질적 논점 정리

flowchart TD
    Q["핵심 질문: 애자일은 죽었는가?"]
    
    Q --> A["Campbell의 주장<br/>☠️ 사망 선고"]
    Q --> B["반론 진영<br/>🔄 진화 중"]
    Q --> C["절충 시각<br/>🔄 본질 vs 형식의 분리 필요"]
    
    A --> A1["이유: LLM이 Spec-DD를 부활시킴"]
    A --> A2["이유: 선언문이 원래부터 공허했음"]
    
    B --> B1["이유: 반복·적응 철학은 여전히 유효"]
    B --> B2["이유: 스프린트 주기만 단축될 뿐"]
    
    C --> C1["소문자 agile = 살아있음"]
    C --> C2["대문자 Agile = 상업적 껍데기는 사망"]
    C --> C3["LLM 시대의 애자일 = 재발명 중"]
    
    style A fill:#ffcdd2
    style B fill:#c8e6c9
    style C fill:#fff9c4

가장 균형 잡힌 관점은 아마도 이것일 것이다: 소문자 ‘agile’이 표현하는 반복·적응·학습의 철학은 소프트웨어 개발의 본질과 맞닿아 있어 결코 사라지지 않을 것이다. 반면 대문자 ‘Agile’이 상징하는 스크럼 의식주의, 인증 산업, 지표 관리 문화는 이미 그 실효성을 의심받고 있으며, LLM 시대에 더욱 빠르게 재편될 것이다.

10. 결론: 애자일 이후의 세계는 어디로

Campbell의 글이 제기하는 가장 근본적인 질문은 이것이다: 소프트웨어 개발에서 “방법론”이란 무엇이어야 하는가?

역사는 보여준다. 워터폴→애자일→? 로 이어지는 패러다임 전환은 결코 이전 것을 완전히 폐기하지 않는다. 각 시대는 그 시대의 기술적 제약과 조직적 현실 속에서 최선의 답을 모색해 왔다.

graph LR
    subgraph ERA1["🕰 1970년대"]
        E1A[요구사항 정밀화]
        E1B[프로토타이핑]
        E1C[고객 참여]
    end
    
    subgraph ERA2["🕰 2001년대 애자일"]
        E2A[스프린트·반복]
        E2B[자기조직화 팀]
        E2C[빠른 피드백]
    end
    
    subgraph ERA3["🕰 2025년+ AI 시대"]
        E3A[AI 지원 스펙 작성]
        E3B[에이전트 기반 개발]
        E3C[인간: 검토·판단·방향]
    end
    
    ERA1 -->|"애자일이 재포장"| ERA2
    ERA2 -->|"AI가 재발명"| ERA3
    
    CORE["⚙️ 변하지 않는 핵심<br/>반복 · 학습 · 피드백 · 명세의 중요성"]
    
    ERA1 --- CORE
    ERA2 --- CORE
    ERA3 --- CORE

    style CORE fill:#FFD700,color:#333

앞으로 소프트웨어 개발은 다음과 같은 방향으로 진화할 것으로 보인다.

① 스펙 작성의 재부상: LLM을 효과적으로 활용하려면 정밀한 명세가 필수다. 이는 Royce(1970)가 강조한 문서화의 가치를 반세기 만에 재확인하는 것이다.

② 반복 주기의 극단적 단축: tekart가 지적했듯이, 2주 스프린트는 몇 시간 또는 몇 분으로 단축될 수 있다. 반복의 철학은 살아있지만 그 속도가 달라진다.

③ 인간 역할의 재정의: 코드를 작성하는 것에서 스펙을 작성하고 AI가 생성한 코드를 검토·판단·방향 설정하는 것으로 개발자의 역할이 이동한다.

④ 방법론 교조주의의 쇠퇴: Campbell의 글이 옳든 그르든, 어떤 방법론도 은총알(silver bullet)이 아님을 우리는 이미 알고 있다. 도구와 기술이 빠르게 변하는 AI 시대에 방법론 경전주의는 더욱 설 자리가 없어질 것이다.

마지막으로, Campbell 자신이 인용한 Royce의 1970년 문장으로 이 분석을 마무리한다:

“문서화, 명세, 설계는 코딩이 시작되기 전까지 동일한 것을 지칭한다. 문서가 나쁘면 설계도 나쁘다. 문서가 존재하지 않으면 설계도 아직 존재하지 않는 것이다.”

56년 전 달 착륙 직후에 쓰인 이 문장이 ChatGPT, Claude, Gemini의 시대에 다시 소환되고 있다는 것은, 소프트웨어 공학의 근본 진리가 얼마나 시대를 초월하는지를 역설적으로 보여준다.

참고 자료

자료	출처
원문 블로그 포스트	lewiscampbell.tech/blog/260414.html
GeekNews 한국어 토론	news.hada.io/topic?id=28583
Hacker News 토론	news.ycombinator.com/item?id=47774781
Agile Manifesto 원문	agilemanifesto.org
Royce 1970 논문	Managing the Development of Large Software Systems
Bell & Thayer 1976	Software Requirements: Are They Really a Problem?

작성일: 2026-04-18

AI, Material

AI Agile spec-driven-development Claude.write

애자일에 작별을 고하며

목차

1. 개요 및 배경

2. 애자일의 역사적 계보

3. 애자일 선언문의 정체성 문제

3.1 선언문의 내용

3.2 “진짜 애자일” 방어 메커니즘

3.3 상업적 변질: 대문자 Agile의 탄생

4. 워터폴이라는 허수아비

4.1 애자일의 정체성 공식

4.2 전형적인 워터폴 vs 반복 개발의 비교

5. Royce(1970)와 Bell-Thayer(1976): 애자일보다 앞선 통찰

5.1 Winston W. Royce (1970)

5.2 Bell & Thayer (1976)

6. LLM 시대의 등장과 스펙 기반 개발

6.1 패러다임의 역전

6.2 왜 LLM은 스펙을 요구하는가

6.3 에이전트 시대의 스펙 작성

7. 한국 개발자 커뮤니티의 반응 분석

7.1 비판적 수용 (Campbell에 동조)

7.2 반론: 여전히 애자일은 유효하다

7.3 코드 vs 문서 논쟁

8. Hacker News 글로벌 커뮤니티 시각

8.1 애자일은 실패할 수 없는 개념이다

8.2 대기업 애자일의 민낯

8.3 규모 확장의 한계

8.4 Kent Beck의 원래 의도

9. 비판적 종합 평가

9.1 Campbell 주장의 강점

9.2 Campbell 주장의 한계

9.3 본질적 논점 정리

10. 결론: 애자일 이후의 세계는 어디로

참고 자료

인기 태그