애자일에 작별을 고하며

• 소프트웨어 업계를 지배해 온 애자일(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년의 애자일 선언문이 새로운 통찰을 제공하지 못했음이 드러남
  • 애자일은 모호한 정의와 상업적 포장으로 기존의 공학적 접근을 대체했을 뿐, 실질적 진보를 이루지 못함
  • 그 엔지니어들의 논문이 훨씬 더 명확한 의미를 담고 있었음
• 소프트웨어 개발이 계속 변화하고 진화하는 지금, 애자일을 역사 속으로 보내고 새로운 관점으로 전환할 시점임
  • 과거의 진지한 엔지니어들이 남긴 명확한 원칙과 공학적 사고로 돌아가야 함

[galadbran]

어떤 기준에서는 모두가 애자일하죠. 지금처럼 빠르게 배포하고 피드백 받는 시대가 있었나 싶고요.

[develosopher]

코드를 읽을 일이 없진 않으니 이 관점에서 문서보다 코드라는 말은 유효한 것 같고, 지시문으로서의 문서는 구현주체인 LLM이 읽어야하니 이 관점에서는 동의가 되네요. 그러므로 결론은 둘다 동시에 중요한 것 아닌가 싶어요.
지금 LLM 생산 제품의 문제는 운영 단계에서 누적되는 부채입니다. 지속적인 운영을 위해서는 개발자가 코드에 관여해야하고 그러려면 아직까지는 코드는 문서를 대신 할 수 있어야 한다고 생각해요.

[nvkzrx]

워터폴 사이클이 하루만에 돈다면?

[osw0124]

끔찍하게도 가장 자주 보는 것 같네요...

[GN⁺]

Hacker News 의견들

• Agile을 통해 흥미로운 현상을 보게 되었음
  실패하면 “충분히 하지 않았다”는 식으로 해석되는 구조임
  클라우드, 마이크로서비스, 긴축정책 등에서도 같은 패턴을 봄 — 실패의 원인은 항상 실행 부족이지, 접근법 자체는 절대 틀리지 않는다는 믿음이 작동함

  • 내가 좋아하는 Agile-ism은 “팀에 맞는 프로세스가 Agile이다”라는 정의임
    팀이 Agile을 시도했는데 잘 안 되면, “그건 진짜 Agile이 아니었다”는 방어 논리가 등장함. 결국 Agile은 실패할 수 없는 개념이 되어버림
  • 혼란의 근본은 Agile을 프로세스로 오해하기 때문임
    Agile Manifesto는 가치와 원칙만을 다룸. 문제는 이를 억지로 프로세스로 끼워 맞추는 조직 문화임
  • 이 패턴은 종교나 영성에서도 보임
    실패 시 내면을 돌아보게 하는 구조가 꼭 나쁜 건 아님. 외부 탓보다 자기 성찰을 유도하는 면에서는 건강한 시스템일 수도 있음
  • 대부분의 회사는 Agile을 진심으로 원하지 않음
    고객에게 약속한 로드맵과 유연한 대응은 양립하기 어려움. 현실은 계획 중심의 조직이 Agile을 흉내 내는 수준임
  • 이 논의는 Agentic software development를 떠올리게 함
    실패하면 “에이전트를 더 써야 했다”는 식으로 귀결됨. 마치 “토큰은 절대 충분하지 않다”는 농담처럼 들림

• 나는 Agile의 형식화를 두려워하게 되었음
  40명 규모의 팀을 성공적으로 운영했지만, 진짜 Agile은 단 네 문장으로 요약됨 — 사람, 작동하는 소프트웨어, 고객 협업, 변화 대응
  문제는 ‘대문자 Agile’이 오히려 비유연한 프로세스로 변질된 것임

  • 이 네 문장은 훌륭하지만, 실제로는 작은 팀에서만 잘 작동함
    인원이 늘면 목표 정렬이 어려워지고, 결국 통제와 절차가 필요해짐
  • “Agile”이라 부르지만 실제로는 Waterfall인 프로젝트를 수도 없이 봤음
  • 대부분의 조직은 Scrum, SAFE 같은 프레임워크를 복음처럼 받아들임
    심지어 티켓 생성 권한조차 제한하는 등, 유연성과는 거리가 멀었음
  • “작동하는 소프트웨어가 문서보다 중요하다”는 말은 안전 필수 시스템에는 역효과임
    문서화가 부족하면 유지보수가 불가능해지고, 결국 YOLO 개발로 흐름
  • “우리는 Agile하게 일해요”라며 SAFE 다이어그램을 보여주는 조직을 보면 웃음이 나옴

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

  • 나도 그런 지표 중심 Agile을 봤음
    관리자들은 숫자 상승만 보고 만족하고, 제품은 통계의 부산물로 전락함
  • 그런데 그 동료는 어떻게 다음 스프린트의 일을 미리 예측했는지 의문이었음

• Agile Manifesto 원문을 다시 볼 가치가 있음
  그게 유일한 합의 지점임. Agile 이전의 워터폴이 얼마나 끔찍했는지를 기억해야 함

  • 30년 경력자에게 물어보면, 문제투성이여도 Agile은 결국 긍정적인 변화였다고 함
    고정된 일정과 산출물을 강요하던 시대를 끝내준 무기였음
  • 하지만 중간관리자들은 진짜 Agile을 이해하려 하지 않음
    팀이 자율적으로 일하면 자기 자리 위협이 되기 때문임
  • 다시 한 번, Agile Manifesto를 읽어볼 필요가 있음

• Kent Beck이 “Extreme Programming”에서 말했듯, Agile은 상상된 전지전능함의 폭정을 피하려는 시도였음
  과거의 워터폴은 설계 단계에서 모든 걸 예측하려 했고, 학습과 피드백을 무시했음
  하지만 시간이 지나며 Agile의 의식과 형식이 본질을 덮어버림
  나는 여전히 Agentic programming을 좋아하지만, 결국 중요한 건 맥락을 잇는 인간의 역할임

• 원문 기사는 혼란스러웠음
  Agile이 새로 만든 게 없다고 하더니, LLM이 코드를 쓰면 Agile이 죽었다고 주장함
  하지만 Agile의 핵심은 불완전한 명세를 인정하고 반복적으로 개선하는 것임
  이 원칙은 여전히 유효함

  • 반복적 개발은 인류 역사만큼 오래된 개념임
    Agile은 그중 하나의 변형일 뿐, 나쁜 구현이 많았을 뿐임
    좋은 제품은 결국 명세 → 학습 → 수정의 순환에서 나옴
  • 소문자 agile은 유연한 개발을 뜻하지만, 대문자 Agile은 Scrum 의식주의로 변질됨
    Backlog Grooming, Sprint Review 같은 절차가 오히려 변경을 억제함

• Spec 기반 개발은 오래가지 못할 것 같음
  여전히 작동하는 소프트웨어를 만들고 반복하는 게 더 빠름 — 결국 Agile의 귀환임

  • 하지만 요즘은 에이전트가 명세를 작성하고 사람이 검토하는 구조임
    명세 품질이 좋아지고, 코드보다 리뷰가 쉬워졌음
  • Compound Engineering처럼 명세와 반복의 중간 지점을 찾는 시도도 있음
    GitHub 링크 참고

• 매니페스토에는 Daily Standup이나 Agile Coach 같은 말이 없음
  본질은 “프로그래머를 마이크로매니징하지 말라”는 것임
  즉, 동기부여된 개인에게 환경과 신뢰를 제공하라는 메시지임

• Kent Beck, Martin Fowler 등 창시자들은 원래 유연한 가이드라인을 의도했음
  하지만 시간이 지나며 비즈니스화되고, 맹신적 추종자들이 생겨 혼란이 커졌음
  성공 여부는 결국 사람의 역량과 태도에 달려 있음
  스프린트 길이도 상황에 맞게 조정해야 하고, 명세가 없으면 팀이 직접 만들어야 함
  AI 시대에도, 현명하게 Agile을 사용하는 사람이 있다면 여전히 유효함

• “Spec을 쓴다”는 게 정확히 뭘 의미하는지 궁금했음
  내가 해온 모든 Agile 프로젝트에는 디자인 문서가 있었고, 티켓은 그 문서에서 파생됨
  문서 없는 티켓 기반 개발은 지옥 같을 것임

  • 맞음, 우리도 문서는 있지만 거짓으로 가득함
    모두가 자기 입맛대로 해석함
  • 하지만 “디자인 문서가 출발점”이라면 그건 진짜 Agile이 아님
    티켓 중심의 접근이 오히려 더 순수한 Agile에 가까움
  • 진짜 Agile에서는 사용자와의 대화가 진실의 원천임
    가짜 Agile은 PO나 PM이 만든 문서가 진실인 척함
  • 작성자 본인으로서 말하자면, 결국 “Agile”이라는 이름은 아무 데나 붙일 수 있음
    당신이 말한 방식이야말로 내가 의도한 ‘명세 작성’의 의미에 가장 가까움