애자일에 작별을 고하다

Source: Hacker News

RIP Agile, 우리는 그 존재를 거의 알지 못했습니다.

그리고 나는 그것을 문자 그대로 의미한다 – 왜냐하면 아무도 그것이 무엇인지 명확히 알지 못했기 때문이다.

Agile은 우리 산업을 쓰나미처럼 휩쓸었다. 하지만 그것이 의문시될 때마다, 구름 사이 틈새에서 나오는 목소리(아마도)라면 언제나 “아, 그건 진정한 Agile이 아니다 – 선언문에는 Daily Standup도, Agile Coach도 언급되지 않았다”고 말한다. 그럼에도 불구하고 Agile Manifesto (2001)을 읽어보면, 우리를 깨우는 새로운 소프트웨어 시대의 원천이라 할 수 있는 이 선언문이 실제로는 별다른 것을 말해주지 않는다는 것을 알 수 있다. 최선일 때는 모호한 격언들의 연속일 뿐이다(예: “고객 협업을 계약 협상보다 중시한다”), 최악일 때는 상업적으로 실행 불가능한 내용이다(예: “개발이 늦어도 변경 요구를 환영한다”).

그렇다면 Agile 산업이 Agile을 제대로 수행하지 않았고, 선언문 자체가 거의 의미가 없었다면, 그것은 정확히 무엇이었을까?

“소프트웨어를 괴롭히는 유령, 워터폴의 유령”

Agile은 언제나 그것이 아니었던 것을 기준으로 정의되었습니다 – 그리고 그것이 아니었던 것은 Waterfall이었습니다. Agile을 하지 않는다면 Waterfall을 하고 있는 것이고, Waterfall은 제대로 작동하지 않았습니다.

하지만 우리는 1970년대부터 Waterfall이 제대로 작동하지 않는다는 것을 알고 있었으며, Winston W. Royce가 정확히 그 이유를 제시했습니다. 그는 대신 다음을 권고했습니다:

• 프로그램 설계부터 시작한다.
• 요구사항을 다듬기 위해 소프트웨어 프로토타입을 만든다.
• 고객을 참여시킨다 (“참여는 공식적이고, 깊이 있으며, 지속적이어야 한다”).

이 모든 것이 나중에 Agile 혁신으로 주장되었습니다. 실제로는 달 착륙 다음 해에 쓰여진 것이었습니다.¹

그 시기에도 Waterfall에서 벗어나려는 작업은 하나뿐이 아니었습니다. 1976년 Bell과 Thayer가 발표한 논문—여기서 처음으로 “Waterfall”이라는 용어가 등장했습니다²—은 실증 연구의 결론에서 다음과 같이 말합니다:

요구사항에 대한 문제 유형은 소프트웨어 개발 프로젝트의 진행 과정에서 변합니다. 시스템 개발자는 설계로 요구사항을 충족하려고 시도할 때 비로소 요구사항 결함을 발견하는 경우가 많습니다.

따라서 반복적 개발이 새로운 것이 아니었으며, Agile 이전 수십 년 동안 계속해서 다듬어졌다는 것이 명백합니다³. Manifesto가 우리를 해방시키기 전까지 Waterfall이 최첨단이었던 것은 아니었습니다. 그리고 요구사항과 사양의 효과에 대해 진지하게 의심하는 사람은 거의 없었습니다.

Spec‑Driven Development

좋든 나쁘든, 대규모 프로그래밍 데이터셋으로 학습된 저렴한 LLM의 등장으로 많은 사람들이 컴퓨터를 프로그래밍하는 방식이 바뀌었으며, 이는 소프트웨어의 시대 정신을 바꿨다고 할 수 있습니다.

분명히 긍정적인 변화 중 하나는 소프트웨어 전문가들이 다시 사양을 작성하기 시작했다는 점입니다. LLM도 우리와 마찬가지로 모호함에 약하고, 문제를 명확히 규정하는 것이 올바른 코드를 생성하는 효과적인 도구가 되고 있습니다. 애자일은 “포괄적인 문서보다 작동하는 소프트웨어”를 강조했지만, Spec‑Driven Development은 “포괄적인 문서가 작동하는 소프트웨어를 만든다”고 말합니다. 그리고 실제로 LLM이 있든 없든, 햇빛 아래 새로운 것은 없습니다. 로이스는 이렇게 말했습니다:

코딩이 시작되기 전까지 이 세 명사의(문서, 사양, 설계) 의미는 하나였습니다. 문서가 나쁘면 설계도 나쁩니다. 문서가 아직 존재하지 않으면 설계도 없으며, 사람들은 설계에 대해 생각하고 이야기할 뿐입니다. 그 생각이 어느 정도 가치를 가질 수는 있지만, 크게는 아닙니다.

1970년대와 1976년을 읽어보면 2001년이 우리에게 정말 무엇을 가져다 주는지 물어볼 수밖에 없습니다. 애자일은 모호하게 정의되고, 반세기 전 진지한 엔지니어들이 논문으로 해결한 문제를 해결한다는 식으로 마케팅되었습니다. 우리의 분야가 계속 변화하고—그리고 우리는 진화하기를 바라며—새로운 관점으로 사물을 바라보고, 애자일을 역사의 쓰레기통에 넣을 때가 왔습니다.

Footnotes

Footnotes

1. 아폴로 유도 컴퓨터의 프로그래머들이 어떻게 그런 위업을 해냈는지 궁금해진다. 그들은 스토리 포인트도 없었고, “Continuous attention to technical excellence and good design enhances agility”라는 사실도 몰랐다. ↩

2. 물론, 하지 말아야 할 예시로 사용된 것이다. ↩

3. 여기서 Freed Brook의 “No Silver Bullet”에 대한 몇몇 참고문헌을 꼭 넣고 싶었지만, 글을 짧게 유지하려고 한다. 또한 Boehm의 Spiral Model도 읽을 목록에 있다. ↩