애자일에 작별을 고하며
(lewiscampbell.tech)- 소프트웨어 업계를 지배해 온 애자일(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년의 애자일 선언문이 새로운 통찰을 제공하지 못했음이 드러남
- 애자일은 모호한 정의와 상업적 포장으로 기존의 공학적 접근을 대체했을 뿐, 실질적 진보를 이루지 못함
- 그 엔지니어들의 논문이 훨씬 더 명확한 의미를 담고 있었음
- 소프트웨어 개발이 계속 변화하고 진화하는 지금, 애자일을 역사 속으로 보내고 새로운 관점으로 전환할 시점임
- 과거의 진지한 엔지니어들이 남긴 명확한 원칙과 공학적 사고로 돌아가야 함
결론이 좀 과한 거 같네요. 상업화나 형식화가 문제일 수 있지만 스프린트나 백로그 같은 도구가 쓸모없어진 건 아니죠. 수평적이고 목표 중심적인 회의 문화가 자리 잡는 데 도움이 되기도 했고요. SDD가 중요해졌다는 건 맞지만 그 스펙 자체를 AI와 협력적으로 신속하게 작성할 수 있으니 여전히 애자일하죠. 2주짜리 스프린트가 몇 시간 정도로 단축된 것일 뿐, 반복적으로 깎는다는 본질은 그대로인 거 같습니다.
동감입니다
수직적 의사결정타파, 짧은 사이클의 반복개선만 쳐도 우리에게 남기는 메시지가 크죠 (당연히 프로젝트 매니징 기법/도구들도 마찬가지고요)
'애자일 자체가 새로운 통찰을 제공하지 못했으며 애자일을 옹호하는 사람 전체를 맹목적 애자일 빠돌이로 호도'하는 결론은 과격한 것 같습니다
바보같은 글이네요. spec.자체를 애자일하게 써야하는게 핵심인데...애자일은 고객 요구사항에 빠르게 변화해서 적응하는 겁니다.
이런 애자일에 대한 잘못된 오해와 어설픈 상상을 갖는 사람들 때문에 애자일이건 개발 문화건 잘못 되어 가는거죠.
spec 자체를 애자일하게 쓴다는게 뭔가요?
- spec을 대충 쓴다.
- spec을 고객이 불러주는데로 쓴다.
- 고객 요구사항이 바뀌면 spec을 빠르게 바꿀수 있도록 도구의 힘을 빌려서 유지관리한다.
- spec을 애자일하게 쓴다.
애초에 애자일이 뭔지 모르겠다는게 저글의 핵심입니다. 애자일은 이런 특성이 있고, 이러저러하게 해야한다고만 떠들어댔지 정작 이게 애자일 방법론으로 만들어진 제품이다라고 제시해주는 글은 지금까지 보지못했습니다. 선언문을 봐도 아리송하더군요. 한번 보여주시면 어떨까요.
켄트백의 익스트림 프로그래밍, 제프 서덜랜드의 스크럼 등등 대부분의 애자일 기법 책에 기본적으로 나오는 내용입니다. 유저 스토리를 보셔도 됩니다. 대부분의 사람들이 애자일의 근간이 고객 요구사항에 대한 빠른 적응을 위한 짧은 스프린트와 데모 라는 것을 잘 모르더군요.
코드를 읽을 일이 없진 않으니 이 관점에서 문서보다 코드라는 말은 유효한 것 같고, 지시문으로서의 문서는 구현주체인 LLM이 읽어야하니 이 관점에서는 동의가 되네요. 그러므로 결론은 둘다 동시에 중요한 것 아닌가 싶어요.
지금 LLM 생산 제품의 문제는 운영 단계에서 누적되는 부채입니다. 지속적인 운영을 위해서는 개발자가 코드에 관여해야하고 그러려면 아직까지는 코드는 문서를 대신 할 수 있어야 한다고 생각해요.
반론을 조심스럽게 전달하자면, 저는 코드는 문서를 대신할 수 없다고 봅니다. 아직 programming language는 자연어의 풍부한 표현력과 전달력을 가지지 못했고, 현실적으로는 그 많은 코드를 언제 다 읽습니까?
문서를 대신할 수 있는 코드를 가져보는 것은 희망이고 바램이지만, 오르지 못할 바벨탑이지요.
차라리 OOAD를 열심히 하는게 더 나아보입니다.
네 말씀하신 의견이 공감됩니다.
코드로 대체할 수 없는 부분이 분명히 있습니다.
그런 의미에서 좀 다르게 설명해보자면, 가독성 높은 코드는 문서를 생산할 필요가 없도록 만든다는 얘기를 하고 싶었습니다.
소프트웨어가 장기화 되며 쌓이는 문서 또한 개발자에게 인지 부하를 주니까요. 코드와 문서를 번갈아 보는 작업을 줄이자는데 핵심이 있습니다.
온전히 코드만 남길 수는 없다고 생각합니다.
맥락과 처한 상황에 따라 다를 수 있다고 생각드네요.
댓글 주셔서 감사합니다.
Hacker News 의견들
-
Agile을 통해 흥미로운 현상을 보게 되었음
실패하면 “충분히 하지 않았다”는 식으로 해석되는 구조임
클라우드, 마이크로서비스, 긴축정책 등에서도 같은 패턴을 봄 — 실패의 원인은 항상 실행 부족이지, 접근법 자체는 절대 틀리지 않는다는 믿음이 작동함- 내가 좋아하는 Agile-ism은 “팀에 맞는 프로세스가 Agile이다”라는 정의임
팀이 Agile을 시도했는데 잘 안 되면, “그건 진짜 Agile이 아니었다”는 방어 논리가 등장함. 결국 Agile은 실패할 수 없는 개념이 되어버림 - 혼란의 근본은 Agile을 프로세스로 오해하기 때문임
Agile Manifesto는 가치와 원칙만을 다룸. 문제는 이를 억지로 프로세스로 끼워 맞추는 조직 문화임 - 이 패턴은 종교나 영성에서도 보임
실패 시 내면을 돌아보게 하는 구조가 꼭 나쁜 건 아님. 외부 탓보다 자기 성찰을 유도하는 면에서는 건강한 시스템일 수도 있음 - 대부분의 회사는 Agile을 진심으로 원하지 않음
고객에게 약속한 로드맵과 유연한 대응은 양립하기 어려움. 현실은 계획 중심의 조직이 Agile을 흉내 내는 수준임 - 이 논의는 Agentic software development를 떠올리게 함
실패하면 “에이전트를 더 써야 했다”는 식으로 귀결됨. 마치 “토큰은 절대 충분하지 않다”는 농담처럼 들림
- 내가 좋아하는 Agile-ism은 “팀에 맞는 프로세스가 Agile이다”라는 정의임
-
나는 Agile의 형식화를 두려워하게 되었음
40명 규모의 팀을 성공적으로 운영했지만, 진짜 Agile은 단 네 문장으로 요약됨 — 사람, 작동하는 소프트웨어, 고객 협업, 변화 대응
문제는 ‘대문자 Agile’이 오히려 비유연한 프로세스로 변질된 것임- 이 네 문장은 훌륭하지만, 실제로는 작은 팀에서만 잘 작동함
인원이 늘면 목표 정렬이 어려워지고, 결국 통제와 절차가 필요해짐 - “Agile”이라 부르지만 실제로는 Waterfall인 프로젝트를 수도 없이 봤음
- 대부분의 조직은 Scrum, SAFE 같은 프레임워크를 복음처럼 받아들임
심지어 티켓 생성 권한조차 제한하는 등, 유연성과는 거리가 멀었음 - “작동하는 소프트웨어가 문서보다 중요하다”는 말은 안전 필수 시스템에는 역효과임
문서화가 부족하면 유지보수가 불가능해지고, 결국 YOLO 개발로 흐름 - “우리는 Agile하게 일해요”라며 SAFE 다이어그램을 보여주는 조직을 보면 웃음이 나옴
- 이 네 문장은 훌륭하지만, 실제로는 작은 팀에서만 잘 작동함
-
내가 다닌 대기업들의 Agile은 거짓말이었음
한 동료는 “다음 스프린트 일을 미리 해두면 항상 제때 끝난다”고 말했음.
즉, Agile은 실제 일보다 지표 생산 시스템으로 작동했음- 나도 그런 지표 중심 Agile을 봤음
관리자들은 숫자 상승만 보고 만족하고, 제품은 통계의 부산물로 전락함 - 그런데 그 동료는 어떻게 다음 스프린트의 일을 미리 예측했는지 의문이었음
- 나도 그런 지표 중심 Agile을 봤음
-
Agile Manifesto 원문을 다시 볼 가치가 있음
그게 유일한 합의 지점임. Agile 이전의 워터폴이 얼마나 끔찍했는지를 기억해야 함- 30년 경력자에게 물어보면, 문제투성이여도 Agile은 결국 긍정적인 변화였다고 함
고정된 일정과 산출물을 강요하던 시대를 끝내준 무기였음 - 하지만 중간관리자들은 진짜 Agile을 이해하려 하지 않음
팀이 자율적으로 일하면 자기 자리 위협이 되기 때문임 - 다시 한 번, Agile Manifesto를 읽어볼 필요가 있음
- 30년 경력자에게 물어보면, 문제투성이여도 Agile은 결국 긍정적인 변화였다고 함
-
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”이라는 이름은 아무 데나 붙일 수 있음
당신이 말한 방식이야말로 내가 의도한 ‘명세 작성’의 의미에 가장 가까움
- 맞음, 우리도 문서는 있지만 거짓으로 가득함