공개 노트

애자일 비판과 스펙 주도 개발의 재조명

2026-04-17Views 28약 4분

Summary

이 노트는 아래 출처를 AI 도구 클립을 활용하여 재구성한 것입니다. 상세한 정보는 원문 방문을 권장합니다.

핵심 요약

이 글은 애자일이 실제로는 모호한 구호에 가까웠고, 반복 개발·고객 참여·프로토타이핑 같은 핵심 아이디어는 이미 1970년대에 정리되어 있었다고 주장한다.

또한 최근 LLM의 확산으로 명확한 명세의 가치가 다시 커지면서, "문서보다 동작하는 소프트웨어"라는 애자일 구호가 재평가되고 있다고 본다.

글의 핵심 문제의식은 단순하다. 애자일은 업계를 휩쓴 거대한 흐름이었지만, 정작 누구도 그것을 또렷하게 설명하지 못했다는 것이다.

비판이 나오면 늘 "그건 진짜 애자일이 아니다"라는 식의 반응이 따라붙는다. 그런데 정작 근거로 제시되는 애자일 선언문은 매우 짧고 추상적이다. 방향을 제시하는 문장들은 있지만, 실제 현장에서 무엇을 어떻게 해야 하는지까지는 거의 알려주지 않는다.

즉, 현장에서는 해석이 제각각이었고, 선언문은 지나치게 넓게 읽힐 수 있었다. 그래서 애자일은 방법론이라기보다, 모두가 자기 방식으로 의미를 덧씌운 상징에 가까웠다는 비판이 가능하다.

글은 애자일이 스스로를 설명하기보다 "우리는 워터폴이 아니다"라는 방식으로 정체성을 만들었다고 본다.

이 구도에서는 논리가 아주 단순해진다. 애자일이 아니면 곧 워터폴이고, 워터폴은 실패한다는 식이다. 하지만 이런 이분법은 실제 소프트웨어 개발의 역사를 지나치게 납작하게 만든다.

마치 음식 세계를 "패스트푸드가 아니면 전부 구식 요리"라고 말하는 것과 비슷하다. 현실에는 다양한 조리법이 있듯, 소프트웨어 개발에도 워터폴과 애자일 사이의 넓은 스펙트럼이 존재했다.

글은 1970년 윈스턴 로이스의 논의를 꺼내며, 애자일이 혁신처럼 포장한 요소들이 사실 훨씬 이전부터 알려져 있었다고 지적한다.

로이스는 프로그램 설계부터 시작하고, 프로토타입을 만들어 요구사항을 다듬고, 고객을 지속적으로 깊이 있게 참여시켜야 한다고 봤다. 오늘날 많은 사람이 애자일의 특징이라고 떠올리는 내용과 크게 다르지 않다.

즉, 반복 개발, 실험적 구현, 사용자와의 상호작용은 2001년에 갑자기 하늘에서 떨어진 아이디어가 아니다. 이미 수십 년 전부터 진지한 엔지니어들이 고민하고 정리해 온 실천이었다.

흥미로운 점은 워터폴의 한계 역시 애자일 이전부터 이미 잘 알려져 있었다는 사실이다.

글은 1976년 Bell과 Thayer의 연구를 예로 들어, 요구사항의 문제는 프로젝트가 진행되면서 새롭게 드러나고, 설계를 시도하는 과정에서야 결함이 발견되곤 한다고 설명한다. 이는 요구사항을 처음부터 완벽하게 고정하기 어렵다는 뜻이다.

중요한 점은 이런 통찰이 애자일의 독점 자산이 아니라는 것이다. 다시 말해, "워터폴의 실패를 애자일이 처음 발견했다"는 서사는 역사적으로 과장되어 있다.

글은 최근 LLM의 확산을 계기로 개발 문화가 바뀌고 있다고 본다. 그중 가장 긍정적인 변화로, 개발자들이 다시 명세를 쓰기 시작한 점을 든다.

LLM은 모호한 지시를 잘 처리하지 못한다. 사람도 마찬가지다. 무엇을 만들어야 하는지 분명하지 않으면 결과물의 품질은 흔들린다. 그래서 문제를 명확히 정의하고, 기대 동작을 문서로 정리하는 일이 다시 핵심 역량이 되고 있다.

이 관점에서는 "문서보다 동작하는 소프트웨어"보다, "좋은 문서가 좋은 소프트웨어를 만든다"가 더 설득력 있게 들린다. 설계도 없이 집을 짓기 어렵듯, 명세 없이 복잡한 소프트웨어를 안정적으로 만드는 일도 어렵다.

글은 로이스의 생각을 빌려, 문서·명세·설계는 코딩 전에는 사실상 같은 것이라고 강조한다.

이 말의 뜻은 단순하다. 문서가 없으면 아직 설계가 없는 것이고, 머릿속 아이디어가 흩어져 있는 상태에 가깝다는 것이다. 말로만 합의한 설계는 쉽게 왜곡되고, 각자 다른 그림을 품게 된다.

문서화는 관료주의의 상징이 아니라, 생각을 검증 가능한 형태로 바꾸는 과정이다. 특히 여러 사람이 함께 일하거나, AI에게 작업을 위임하거나, 시간이 지나 다시 유지보수해야 할 때 이 차이는 매우 커진다.

글쓴이는 2001년의 애자일이 실제로 새롭게 가져온 것이 많지 않다고 본다. 이미 알려진 원칙을 더 모호한 언어로 포장했고, 마치 과거의 문제를 처음 해결한 것처럼 마케팅했다는 시각이다.

그래서 결론도 단호하다. 이제는 애자일이라는 깃발 자체에 집착하기보다, 무엇이 실제로 개발을 더 낫게 만드는지 다시 봐야 한다는 것이다.

핵심은 이름이 아니라 작동 원리다. 반복이 필요하면 반복하고, 문서가 필요하면 문서화하고, 고객 참여가 중요하면 깊이 협업하면 된다. 특정 구호를 믿는 것보다, 문제에 맞는 공학적 판단이 더 중요하다는 메시지다.

이 글을 곧이곧대로 받아들이면 "애자일은 틀렸고 문서가 전부다"라는 결론으로 흐를 수 있다. 하지만 더 유용한 읽기는, 유행어보다 기본기를 보라는 경고로 이해하는 것이다.

실무에서는 애자일이냐 아니냐를 따지기보다 세 가지를 점검하면 좋다. 무엇을 만들지 명확히 적고, 작게 검증하며, 이해관계자를 계속 참여시키는 것이다.

결국 좋은 개발은 간판이 아니라 명확성에서 나온다. 방법론의 이름보다, 팀이 얼마나 분명하게 생각하고 소통하는지가 더 큰 차이를 만든다.