애자일에 작별을 고하며

• 소프트웨어 업계를 지배해 온 애자일(Agile) 방법론이 실제로는 모호한 원칙과 이미 해결된 문제의 재포장에 불과했다는 비판적 재검토
• 워터폴과의 대립 구도는 허상에 가깝고, 반복적 개발과 고객 참여 같은 핵심 개념은 이미 1970년대 연구에서 제시되어 있었음
• 애자일은 항상 폭포수(Waterfall) 모델의 반대로만 정의되었으나, 폭포수 모델의 한계는 이미 1970년대에 널리 알려진 사실
• 최근 대규모 언어 모델(LLM) 의 등장으로, 스펙 기반 개발(Spec-Driven Development) 이 다시 중요해지며 문서 중심 개발이 부상 중임
• “포괄적 문서보다 작동하는 소프트웨어”라는 애자일의 구호는, 이제 “포괄적 문서가 작동하는 소프트웨어를 만든다”는 인식으로 전환되고 있음
• 애자일이 남긴 모호함을 넘어, 명확한 원칙과 공학적 접근으로 돌아가야 할 시점임

RIP Agile, we hardly knew ye.
And I mean that literally - because no one was ever clear on what it was.
애자일, 편히 잠들길. 우린 널 제대로 알지도 못했어.
말 그대로, 애자일이 정확히 뭔지 아무도 제대로 몰랐으니까.

애자일의 정체성 문제

• 애자일(Agile) 은 소프트웨어 업계 전반을 휩쓴 거대한 흐름이었지만, 실제로는 그 의미가 불분명한 채로 확산된 개념임
• 의문이 제기될 때마다 "그것은 진짜 애자일이 아니다"라는 답변이 반복되어 왔음
• 애자일 선언문(2001) 을 실제로 읽어보면 구체적 지침이 거의 없으며, "고객 협업이 계약 협상보다 중요하다"와 같은 모호한 격언 수준
• "개발 후반부에도 요구사항 변경을 환영하라"와 같은 원칙은 상업적으로 비현실적
• “진정한 애자일(True Agile)” 이라는 주장 아래, 실무의 문제점은 선언문과 무관하다는 식으로 회피되어 왔음
• 애자일 산업이 애자일을 제대로 실천하지 않고, 선언문 자체도 의미가 부족하다면 애자일의 실체가 무엇인지 의문

"소프트웨어에 폭포수의 유령이 떠돈다"

• 애자일은 항상 자신이 아닌 것(Waterfall, 워터폴) 으로만 정의되었으며, 애자일을 하지 않으면 워터폴을 하고 있고, 워터폴은 작동하지 않는다는 논리 구조
• 그러나 워터폴이 작동하지 않는다는 사실은 1970년부터 이미 알려져 있었으며, Winston W. Royce가 그 이유를 정확히 설명
• Royce는 대안으로 프로그램 설계로 시작할 것, 소프트웨어 프로토타입을 만들어 요구사항을 정제할 것, 고객을 공식적이고 심도 있게 지속적으로 참여시킬 것을 권장
• 이 모든 것이 나중에 애자일의 혁신이라 주장되었지만, 실제로는 달 착륙 다음 해(1970년) 에 이미 작성된 내용
• 각주1: 아폴로 유도 컴퓨터 프로그래머들이 스토리 포인트도 없이, "기술적 탁월성에 대한 지속적 관심이 민첩성을 향상시킨다"는 원칙도 모른 채 어떻게 그런 위업을 달성했을까?

1976년 Bell-Thayer 논문과 반복적 개발의 역사

• 1976년 Bell과 Thayer의 논문은 "Waterfall(워터폴,폭포수))"라는 용어를 최초로 사용한 문헌으로, 이 용어 자체가 하지 말아야 할 것의 예시로 쓰임
• 해당 논문의 실증 연구 결론: 요구사항의 결함은 소프트웨어 개발 과정에서 설계로 요구사항을 충족시키려 할 때 비로소 발견됨
• 반복적 개발은 새로운 것이 아니었으며, 애자일 이전 수십 년간 지속적으로 정제
• 선언문이 업계를 해방시키기 전에도 폭포수는 최신 기술이 아니었고, 요구사항과 명세서의 효과성을 진지하게 의심하는 사람은 없었음

스펙 기반 개발(Spec-Driven Development)의 부상과 애자일 이후

• 대규모 언어 모델(LLM) 의 확산으로, 프로그래머들이 다시 명세(specification) 를 작성하는 흐름이 강화되고 있음
  • LLM은 모호한 입력에 취약하기 때문에, 문제를 명확히 기술하는 것이 올바른 코드 생성을 돕는 방식으로 자리 잡음
  • 애자일이 “포괄적 문서보다 작동하는 소프트웨어”를 강조했다면, 스펙 기반 개발은 "포괄적 문서가 작동하는 소프트웨어를 만든다" 는 반대 명제를 제시
• Royce는 이미 1970년에 “문서화, 명세, 설계는 코드 작성 전까지 동일한 개념이며, 문서가 나쁘면 설계도 나쁘다”고 지적
  • 문서가 존재하지 않으면 설계도 존재하지 않는다는 점을 강조함
• 1970년과 1976년의 연구를 돌아보면, 2001년의 애자일 선언문이 새로운 통찰을 제공하지 못했음이 드러남
  • 애자일은 모호한 정의와 상업적 포장으로 기존의 공학적 접근을 대체했을 뿐, 실질적 진보를 이루지 못함
  • 그 엔지니어들의 논문이 훨씬 더 명확한 의미를 담고 있었음
• 소프트웨어 개발이 계속 변화하고 진화하는 지금, 애자일을 역사 속으로 보내고 새로운 관점으로 전환할 시점임
  • 과거의 진지한 엔지니어들이 남긴 명확한 원칙과 공학적 사고로 돌아가야 함