애자일이 실제로 무엇이었는지, 워터폴과의 대비 속에서 어떻게 과장되었는지, 그리고 명세 주도 개발의 재부상이 왜 중요한지를 되짚는 글.
2026년 4월 14일
애자일이여, 편히 잠들길. 우리는 너를 거의 알지도 못했다.
그리고 이건 문자 그대로의 뜻이다. 무엇이 애자일인지 누구도 분명하게 설명한 적이 없었기 때문이다.
애자일은 쓰나미처럼 우리 업계를 휩쓸었다. 하지만 그것에 의문이 제기될 때마다, 어떤 목소리(아마도 구름 사이의 틈에서 울려 퍼지는?)가 늘 이렇게 말하곤 했다. "아, 하지만 그건 진정한 애자일이 아닙니다 - 선언문에는 데일리 스탠드업도, 애자일 코치도 없다고 쓰여 있습니다." 그런데 Agile Manifesto (2001)를 읽어 보면, 소프트웨어의 계몽된 신시대를 열었다는 이 샘물 같은 문서는, 결국 실제로는 그다지 많은 것을 말해 주지 않는다는 사실을 발견하게 된다. 좋게 봐도 막연한 상투어의 나열일 뿐이었고("계약 협상보다 고객과의 협업"), 나쁘게 보면 상업적으로 실행 불가능한 내용이었다("개발 후반부일지라도 변화하는 요구사항을 환영하라").
그렇다면 애자일 산업이 애자일을 "제대로" 하고 있지 않았고, 선언문 자체도 거의 의미가 없었다면, 도대체 그것은 무엇이었을까?
애자일은 언제나 주로 그것이 아닌 것의 관점에서 정의되었고, 그 아닌 것은 워터폴이었다. 애자일을 하고 있지 않다면, 당신은 워터폴을 하고 있는 것이고, 워터폴은 작동하지 않았다.
하지만 우리는 워터폴이 작동하지 않는다는 사실을 1970년부터 이미 알고 있었다. 그리고 Winston W. Royce는 정확히 왜 그런지 설명하면서, 대신 다음을 권고했다.
이 모든 것들은 나중에 애자일의 혁신이라고 주장되었다. 하지만 실제로는 달 착륙 이듬해에 이미 쓰여 있었다.1
그리고 그 10년 동안에도 워터폴에서 벗어나려는 작업은 그것만이 아니었다. Bell과 Thayer의 1976년 논문 - "Waterfall"이라는 용어를 처음 만들어 낸 글인데2 - 는 실증 연구의 마지막에서 이렇게 말한다.
요구사항에서 발견되는 문제의 유형은 소프트웨어 개발 프로젝트의 생애 동안 변화했다. 시스템 개발자들은 종종 설계로 요구사항을 충족시키려 시도했을 때에야 비로소 요구사항의 결함을 파악했다.
따라서 반복적 개발이 새로운 것이 아니었다는 점은 분명하며, 애자일 이전 수십 년 동안 계속 더 정교하게 다듬어지고 있었다3. 선언문이 우리를 해방하기 전까지 워터폴이 최첨단이었던 것은 아니었다. 그리고 요구사항과 명세의 효과를 진지하게 의심하는 사람도 없었다.
좋든 싫든, 방대한 프로그래밍 데이터셋으로 훈련된 저렴한 LLM의 등장은 우리 중 많은 이들이 컴퓨터를 프로그래밍하는 방식을 바꾸어 놓았고, 어쩌면 소프트웨어의 시대정신 자체를 이동시켰다.
그 뒤를 따라온 변화 가운데 분명하게 긍정적인 점 하나는 소프트웨어 전문가들이 다시 명세를 쓰고 있다는 것이다. LLM은, 우리 중 많은 사람들처럼, 모호함에 잘 대처하지 못하며, 문제를 명확히 규정하는 일은 올바른 코드를 생성하는 효과적인 도구임이 드러나고 있다. 애자일은 우리에게 "포괄적인 문서보다 작동하는 소프트웨어"라고 말했다. 명세 주도 개발은 우리에게 "포괄적인 문서가 작동하는 소프트웨어를 만든다"고 말하고 있다. 그리고 정말로, LLM이 있든 없든, 새것은 없다. Royce의 말을 빌리자면:
코딩이 시작되기 전까지 이 세 명사(documentation, specification, design)는 하나의 동일한 것을 가리킨다. 문서가 나쁘면 설계도 나쁘다. 문서가 아직 존재하지 않는다면 아직 설계도 없다. 그저 사람들이 설계에 대해 생각하고 이야기하고 있을 뿐이며, 그것도 약간의 가치는 있겠지만 크지는 않다.
1970년과 1976년의 글을 읽고 있으면, 2001년이 우리에게 वास्तव로 무엇을 가져다주는지 묻게 된다. 애자일은 모호하게 정의되었고, 이미 반세기 전에 더 말이 되는 논문을 썼던 진지한 엔지니어들에 의해 해결된 문제를 해결하는 것처럼 마케팅되었다. 우리 분야가 계속 변하고, 또 바라건대 발전해 가는 지금, 이제는 새로운 관점으로 사물을 바라보고, 애자일을 그것이 마땅히 있어야 할 역사의 쓰레기통으로 보내야 할 때다.
Apollo Guidance Computer의 프로그래머들이 어떻게 그런 위업을 이뤘는지 궁금해진다. Story Points도 없이, 또 "Continuous attention to technical excellence and good design enhances agility"라는 사실도 모른 채 프로그래밍했으니 말이다. ↩
물론, 하지 말아야 할 것의 예로 사용되었다. ↩
여기에서 Freed Brook의 "No Silver Bullet"에 대한 언급을 꼭 끼워 넣고 싶었지만, 이 글은 짧게 유지하려고 한다. Boehm의 Spiral Model도 읽을 목록에 올려 두었다. ↩
회사에 제가 도움이 될 것 같으신가요? 연락하세요 또는 제 컨설팅 사이트를 방문해 보세요!© 2021 - 2026, Lewis Campbell
