나는 단 3주 만에 3년 치의 경험을 했다. 애자일은 단순한 개발 프로세스가 아니라, 개발 방식과 협업 문화를 혁신하는 철학이자 실천 방식이었다.

나는 2024년 12월 30일부터 2025년 1월 17일까지 스크럼 팀에 속해 있었다. 그 시간은 마치 폭풍과 같았다. 회사에서 차세대 시스템 구축을 위해 IBM의 컨설팅을 받았고, PI(Process Innovation) 단계가 끝난 후 공통 플랫폼(프레임워크) 구축을 위한 스크럼 팀이 구성되었다. 나는 운 좋게도 그 팀에 합류할 수 있었다.

팀원들은 모두 경험이 풍부한 개발자들이었지만, 스크럼은 처음이었다. XP, Lean, Kanban에 대해서도 제대로 알고 있는 사람이 없었다. 프로젝트 오너이자 스크럼 마스터 역할을 IBM 실장님이 겸임하셨고, 우리는 3주간 스크럼 팀으로 활동했다. 당시에는 몰랐지만, 그 시간이야말로 베스트 프랙티스 Agile을 경험하는 순간이었다.

3주 후, 회사의 사정으로 인해 프로젝트가 중단되었다. 하지만 그 경험은 나의 인식을 완전히 바꾸어 놓았다. 그동안 내가 알고 있던 애자일은 단지 이름뿐인 경우가 많았다. 진정한 애자일은 강력한 효율과 효과를 갖고 있었다. 나는 3년 동안 쌓아온 경험보다 더 많은 것을 3주 동안 배웠다. 하지만 전혀 힘들지 않았고, 즐거웠다.

바로 회고를 하고 싶었지만, 애자일에 대해 제대로 알지 못하고 있었다는 사실을 깨달았다. 그래서 한 달 동안 애자일 관련 서적을 읽으며 이해를 넓혔다.

• 스텔만, 앤드류, & 그린, 제니퍼. (2019). Head First Agile: 개념부터 시험 대비까지, 가장 애자일다운 안내서 (박현철, 역). 한빛미디어. (원저는 2017년에 출판)
• 슈와버, 켄, & 비들, 마이크. (2008). 스크럼 (박일 & 김기웅, 역). 인사이트. (원저는 2002년에 출판)
• 벡, 켄트. (2006). 익스트림 프로그래밍: 변화에 대응하는 개발 방법론 (신시아 안드레스 공저, 김창준 & 정지호, 역). 인사이트. (원저는 2004년에 출판)
• 앤더슨, 데이비드 J. (2014). 칸반: 지속적 개선을 추구하는 소프트웨어 개발 (조승빈, 역). 인사이트. (원저는 2010년에 출판)

이제야 조금은 애자일을 이해할 수 있게 되었고, 본격적인 회고를 시작하고자 한다.

애자일 선언문(Agile Manifesto)

2001년, 미국 유타 스노우버드 스키 리조트에서 17명의 소프트웨어 개발 전문가들이 모여 새로운 소프트웨어 개발 방법론을 논의했다. 그리고 애자일 소프트웨어 개발 선언(Agile Manifesto) 을 발표했다.

• https://agilemanifesto.org/iso/ko/manifesto.html

애자일(Agile)은 14세기 프랑스어에서 유래했으며, 라틴어 agilis에서 파생되었다. 이는 '행동하다(act)'라는 의미를 포함하며, 단순한 속도가 아닌 적응력과 유연성을 강조하는, 이상적인 소프트웨어 개발의 본질과 맞닿아 있는 단어인 것이다.

2000년대 초반, 대부분의 소프트웨어 개발은 워터폴(Waterfall) 방식을 따랐다. 하지만 워터폴 방식은 변화하는 요구사항을 반영하기 어려운 한계를 지니고 있었다. 소프트웨어 개발은 현실이고, 현실은 불확실성과 혼돈이 가득한 영역이다. 소프트웨어 개발은 불확실성으로 가득차있고, 요구사항은 매순간 변경된다.

애자일은 이러한 불확실성과 요구사항의 변화에 대응하기 위해 탄생한 것이다. 요구사항을 모두 수집하고, 모든 기능을 평가하기전에 소프트웨어를 개발을 시작한다. 소프트웨어를 개발하면서 요구사항이 변경된다면, 그것을 환영한다. 그것은 소프트웨어가 사용자에게 가치를 주기 위한 것이기 때문이다.

경영진들은 초기에 이를 받아들이지 않았다. 하지만 소프트웨어의 기능이 점점 복잡해지고, 생산성이 저하되자, 미친척 반영해보았고 그게 잘 동작하는 것을 보고 깜짝 놀랐다. 애자일의 성공은 이후 십년 동안 소프트웨어 개발 방식을 바꿔놓았다.

문제는 그 후 일어났다.

애자일(Agile)에 대한 오해

Agile 은 죽었다. (Agility여 영원하라) - 'Agile' 이라는 단어는 사실상 의미가 없는 지경까지 전복(subvert) 되었고, 애자일 커뮤니티의 경우 대체로 컨설턴트와 벤더들이 서비스와 제품을 판매하는 장소가 되어버렸습니다. Manifest가 대중화 되면서 Agile 이라는 단어는 지지할 것이 있거나, 청구할 시간 이나 판매할 제품이 있는 모든 것들을 끌어들이는 자석이 되어버려서, 마케팅 용어가 되었습니다. 그래서 'Agile' 이라는 말은 이제 은퇴시켜야할 때라고 생각합니다. - Dave Thomas(애자일 선언문 서명자, 실용주의 프로그래밍 공동 창시자), 2014년 8월 7일

개발자는 Agile을 포기해야 합니다. - 'Agile' 아이디어가 제대로 적용되지 않으면, 개발자에게 더 많은 간섭을 하고, 작업시간을 더 적게 주고, 높은 압력을 주고, '더 빠르게 진행' 하는 것을 요구하게 됩니다. 이건 개발자들에게 좋지 않으며, 궁극적으로는 회사에도 좋지 않습니다. 'Agile'을 제대로 수행하지 않으면 실제 달성할 수 있는 것보다 훨씬 더 많은 결함과 더 느린 진행이 자주 발생하기 때문입니다. 종종 우수한 개발자가 그런 회사를 떠나게 되면서, 결과적으로는 "Agile"을 도입하기 전보다 효율성이 떨어지는 기업이 됩니다. - Ron Jeffries(애자일 선언문 서명자, XP 공동 창시자), 2018년 1월 15일

많은 경영진은 애자일을 '더 빨리, 더 많이' 개발하기 위한 도구로 오해한다. 반면, 개발자들은 애자일이 '끝없는 간섭과 일정 압박을 위한 통제 수단'이라고 착각한다. 자율성과 협업이 사라지고, 속도만 강조된 비효율적인 관리 도구로 전락해버린다. 그 결과, 팀은 단기 목표에 쫓기며 과부하에 시달리고, 장기적인 품질과 생산성은 오히려 악화되는 것이다.

애자일은 본질적으로 구성원의 행복을 위한 것이다.

애자일(Agile)에 대한 이해

❌ 잘못된 애자일

• "더 빨리, 더 많이"를 강요
• 불필요한 회의 증가
• 구성원의 통제 도구로 변질

✅ 진짜 애자일

• 구성원의 자율성과 책임 강화
• 가치 중심의 피드백 루프
• 지속 가능한 개발 환경 조성

애자일을 이해하기 위해서는 애자일의 가치와 원칙을 이해해야 한다. 애자일은 개인과 상호작용, 작동하는 소프트웨어, 고객과의 협력, 변화에 대한 대응을 가치로 하는 방법론이다.

나는 실리콘 밸리에서 자라났다. '그것이 필요하다는 것을 당신이 모른다고 해도, 우리가 당신에게 필요한 것을 주리라'가 흔히 명시적으로 표현되기까지 했던 좌우명이었다. 이런 식으로 작성한 소프트웨어는 기술 면에서는 뛰어나도 효용 면에서는 부족하곤 했다. 경험을 더 쌓으면서 나는 반대 상황의 불균형도 보게 되었는데, 비즈니스의 관심사가 개발을 지배하는 상황이 그것이다. 비즈니스 이유에 따라서만 설정된 마감일과 기능의 범위는 팀의 성실성integrity을 유지하지 못한다. 사용자와 발주자의 관심사도 중요하지만, 개발자들의 욕구 또한 정당한 것이다. 셋 모두 균형을 맞춰야 한다. ...(중략)... 그 과업이란 소프트웨어로 돈을 벌기 위해 한데 모인 다양한 사람들 사이에 튼튼한 관계를 길러내는 것이다. 마음의 변화 없이는, 세상의 모든 실천방법과 원칙들도 단지 작고 단기적인 이익만 만들 뿐이다. (23) - Extreme programming (Beck, 2004)

요구사항 변경을 적극적으로 받아들이고, 짧은 주기마다 작동하는 제품을 제공하는 것이 목표이다.

점진적 상세화(progressive elaboration)를 통해 이전 단계를 개선하면서 얻은 지식을 바탕으로 다음 단계 산출물(계획 등)을 만드는 일이다.

소프트웨어 개발은 과잉 생산의 낭비로 가득 차 있다. 금새 쓸모없어지는 두꺼운 요구사항 문서, 절대 쓰지 않는 정교한 아키텍처, 통합하지도 테스트하지도 않고 실제 출시될 환경에서 실행해 보지도 않은 채 몇달이나 개발하는 코드, 아무도 읽지 않은 채 시간이 지나 부적절해지거나 혹은 잘못된 정보를 주는 문서가 그것이다. 물론 이런 모든 활동은 소프트웨어 개발에서 중요한 활동들이지만, 낭비를 제거하기 위해 필요한 피드백을 받으려면 우리는 이런 활동들의 결과물들을 즉시 사용해야 한다. 예를 들어 요구사항 수집은 요구사항 수집 절차를 더 정교하게 만들 때 개선되는 것이 아니라, 요구사항 세부내용을 만드는 일과 명세된 소프트웨어를 배포하는 일 사이의 경로를 짧게 만들 때 개선된다. (19) - Extreme programming (Beck, 2004)

애자일은 마지막 순간까지 요구사항 변경을 수용하며, 이것이 고객의 경쟁력을 높이고 제품의 가치를 최대화하는 것임을 안다.

애자일은 크게 세 가지 대표적인 프레임워크가 있다.

• 스크럼(Scrum)
• 익스트림 프로그래밍(XP)
• 칸반(Kanban)

이 세가지 구현체는 모두 애자일의 핵심 원칙을 따르지만, 적용 방식과 특징이 다르다. 스크럼은 프로젝트 관리 방법론이며, 익스트림 프로그래밍은 개발 방법론이며, 칸반은 작업 관리 방법론이다. 각각의 방법론을 들여다보자.

1. 스크럼(Scrum)

스크럼은 가장 널리 사용되는 애자일 프레임워크로, 일정한 주기(스프린트) 동안 목표를 설정하고 팀이 협업하여 실행하는 방식이다.

• 고정된 반복 주기(Sprint, 일반적으로 1~4주)
• 역할(Role)
  • 이 역할은 직무와는 별개이다. 직무와 관계없이 가장 적합한 사람에게 역할이 주어져야 한다.
  • 스크럼 마스터: 프로세스 조율 및 장애물 제거
    • 스크럼 마스터는 팀이 스크럼을 올바르게 수행하도록 도와주는 역할을 한다. 팀의 코치 역할인 것이다.
    • 외부 요인으로 인해 스크럼이 방해받을 때, 스크럼 마스터는 이를 해결할 수 있어야 한다. 심지어 상사와 회사의 방해로부터 스크럼을 보호해야 한다. 만약 스크럼 마스터가 이를 지켜내지 못하면, 스크럼은 결국 회사의 요구에 맞춤화되며 본래의 목적을 잃어버리게 된다. 맞춤화된 스크럼(Customized Scrum)은 창의성과 자율성을 상실하게 되며, 결국 더 이상 스크럼이 아닌 형식적인 프로세스로 전락하고 만다. 이런 방식으로 운영된 프로젝트는 대부분 실패하거나, 애자일이 의도한 효과를 발휘하지 못한다.
  • 프로덕트 오너(PO): 요구사항 정의 및 우선순위 관리
    • 프로덕트 오너는 제품의 비전을 이해하고, 제품 백로그를 관리하며, 제품의 가치를 최대화하는 역할을 한다.
    • 고객, 이해 관계자들과 가장 친밀하며, 소통 가능해야 한다.
    • 회사는 도출될 제품에 대해 완전히 신뢰 가능한 사람을 지정해야 한다. PO는 제품에 대해 누구보다 잘 알며 그 가치를 최대화 할 방법을 알아야 한다. 때문에 제품에 대한 최종 결정권을 가지고 있으며, 회사는 이런 사람을 지정했기 때문에, 스크럼의 결과물을 수용하면 된다.
  • 개발팀(Development Team): 자율적으로 일하는 크로스펑셔널 팀
    • 제품을 개발하는 팀으로, 프로젝트에 필요한 모든 역할을 수행한다.
    • 각각 스스로 조직하고, 스스로 관리하며, 스스로 일할 수 있어야 한다.
    • 팀은 서로를 비판하되 비난해선 안되며, 모든 정보와 업무를 공유한다. 서로를 존중하고 신뢰하고 협력해야 한다.
• 미팅
  • 스프린트 계획 회의: 목표 설정 및 백로그 선택
  • 데일리 스탠드 업(DSU) 미팅: 매일 짧은 회의(15분)로 진행 상황 공유
  • 스프린트 리뷰: 결과물 데모 및 피드백 반영
  • 스프린트 회고: 프로세스 개선 논의
• 백로그(Product Backlog & Sprint Backlog)
  • 우선순위가 높은 작업부터 수행
• 번다운 차트(Burn-down Chart)
  • 스프린트 진행 상황을 시각적으로 확인

2. 익스트림 프로그래밍(XP, eXtreme Programming)

극한, 개발!

소프트웨어 품질과 개발 속도 향상에 중점을 둔 방법론으로, 개발 프로세스의 실천 방식을 강조한다. (다만, 모든 개발자가 페어 프로그래밍이나 TDD를 원활하게 수행할 수 있어야 한다.)

스크럼과 중복되는 애자일 개념들(가치, 원칙)과 XP 구성원에 대한 이야기는 생략하고, XP의 주요 실천법들을 추려봤다.

• 테스트 중심 개발(TDD, Test-Driven Development)
  • 테스트 코드를 먼저 작성하고 이를 통과하도록 개발
  • 결함 비용 증가(Defect Cost Increase, DCI)를 방지
• 가차 없는 리팩토링(Refactor Mercilessly)
  • 지속적인 코드 개선을 통해 유지보수성을 높임
  • 매 주간 주기에 기술적 부채(technical debt)를 갚고, 리팩토링 할 시간을 가짐
• 페어 프로그래밍(Pair Programming)
  • 두 명이 한 컴퓨터에서 코드를 함께 작성하며 품질 향상
• 단순 설계(Simple Design)와 점진적 설계(Incremental Design)
  • 필요 이상으로 복잡한 설계를 피하고 단순함 유지
  • 팀이 책임을 따르는 마지막 순간에 설계에 관한 의사결정을 내린다.
    • '아무것도 설계하지 말라'가 아닌, '언제나 설계하라'
• 고객과의 긴밀한 협업(Continuous Feedback)
  • 고객과 지속적인 대화를 통해 요구사항을 반영
• 짧은 배포 주기(Small Releases)
  • 빠르게 배포하고 자주 업데이트하여 고객 피드백 반영
• 지속적 통합(Continuous Integration, CI)
  • 코드 변경 사항을 자주 병합하여 충돌을 최소화
• 그리고...

여기 슬프지만 자주 반복되는 이야기가 있다. 개발 팀이 XP를 적용하기 시작해서, 품질과 생산성이 극적으로 개선된다. 그런데 팀이 해체되고 팀장은 해고되고 나머지 팀원은 흩어진다. 왜 이런 일이 생길까? 제약 이론의 관점에서 보면, 팀의 성과가 개선되면 제약 지점이 조직의 다른 곳으로 옮겨간다. 새로운 제약 지점(예를 들어, 자기들이 무엇을 원하는지 충분히 빠르게 결정할 수 없는 마케팅부)은 자기들에게 시선이 쏠리는 것을 좋아하지 않는다. 사실 조직 전체의 처리능력을 걱정하는 직원은 아무도 없다. 결국 소란의 '근원'인 XP가 비난의 표적이 되어 제거된다. XP를 적용할 때에는 임원의 후원을 받고 팀 바깥 사람들과 튼튼한 관계를 맺는 것이 핵심적인데, 그 까닭은 바로 XP를 적용하여 소프트웨어 개발이 자기들의 행동을 개선하는 순간 조직 나머지 부분의 업무 구조도 바뀌기 때문이다. 만약 임원의 후원을 받지 않는다면, 인정이나 보호 없이 혼자서라도 일을 더 잘하겠다고 각오하라. (11) - Extreme programming (Beck, 2004)

정리

꼭 XP를 사용하세요. 기능 단위로 계획을 짜세요. 고객들이 관심을 가지는 기능들을 계획의 항목으로 삼아야 합니다. 릴리즈는 분기에 한번 계획하시고, 반복iteration은 더 자주 계획하세요. 우리는 두 주짜리 반복을 사용합니다. 반복이 절대로 고정된 것이 되도록 만드세요. 고객을 팀과 한 자리에 앉도록 하세요. 팀을 개방된 공간에 두세요. 폭포수 방식 개발 안에 XP를 끼워 넣어야만 하는 경우에도, XP를 사용한다면 여전히 많은 이익을 얻을 것입니다. (16) - Extreme programming (Beck, 2004)

3. 칸반(Kanban)

Lean 철학을 기반으로 한, 소프트웨어 개발뿐만 아니라 다양한 업무 관리에 적용되는 방법론으로, 작업 흐름을 시각화하고 WIP(Work In Progress, 진행 중인 작업)의 제한을 통해 효율성을 극대화하는 방식이다.

Q: 린 철학과 애자일 철학은 어떤 연관이 있나요?
A: 린은 완벽을 추구하는 반면에 애자일은 불완전한 정보로 진행해가면서 나중에 더 많이 알게되면 진로를 변경한다는 아이디어가 바탕으로 있지요. ...(중략)... 린과 애자일의 또 한 가지 차이점은 사람을 바라보는 관점입니다. 린에서는 시스템 사고를 통해 모든 것을 바라봅니다. 사람도 시스템의 일부이기 때문에 사람이 이루는 성과는 시스템으로부터 큰 영향을 받는다고 여기고, 그래서 사람들이 효율적으로 일할 수 있는 시스템을 설계하는 것이 사람을 존중하는 방법이라고 생각합니다. (부록2. 2012 인터뷰) - Kanban (Anderson, 2014)

칸반 시스템은 어떤 특징들을 갖고 있을까?

• 작업 흐름(Workflow) 시각화
  • 칸반 보드를 활용해 진행 중인 작업을 한눈에 볼 수 있도록 함
• WIP 제한(Work In Progress Limit)
  • 한 번에 수행할 수 있는 작업 개수를 제한하여 과부하 방지
• 리드 타임(Lead Time) 단축
  • 작업이 시작된 후 완료되기까지 걸리는 시간을 줄임
• 지속적인 개선(Continuous Improvement)
  • 병목 현상을 분석하고 프로세스를 최적화함

비즈니스 쪽 사람들은 요구량을 수용량에 맞게 제한하는 것이 어떤 의미인지 이해할 수 있어야 합니다. 그것은 지원 가능한 수용량에 맞게 요구량을 제공한다는 뜻입니다. 항상 지원할 수 있는 것보다 발생하는 요구가 더 많기 때문입니다. 인간의 창의성에는 제한이 없습니다. 정말로 중요한 것은, 사람들이 접하게 될 새로운 소프트웨어가 갖는 위험, 보상, 이익 등을 정확히 평가하는 일입니다. ...(중략)... 제공할 수 있는 수용량을 개선하려고 노력하는 동안, 그들 또한 가능한 아이디어들 중에서 최고를 선택하는 방법을 배워야 합니다. ...(중략)... 점점 더 요구가 많아지는 이유 중 하나는, 미래가 불확실하고 그래서 비즈니스 쪽 사람들이 "그냥 다 만들어 주세요"라고 이야기하며 양쪽 모두에 베팅하기 때문입니다. 분명히 이런 상황은 너무나 비합리적이기 때문에, 그들이 위험을 제대로 평가하고 직면한 불확실성을 더 잘 이해할 수 있도록 도와주어야 합니다. (부록2) - Kanban (Anderson, 2014)

칸반은 다른 애자일 프레임워크와 차별되는 특징을 갖는다. 위로부터 하향식 변화도, 아래로부터 위로 향하는 다른 애자일과 같은 상향식 변화도 아니다. 중간 계층에서 일으키는 조직 차원의 변화에 가깝다. 이것이 팀 단위 적용 방식인 스크럼의 발전 방향이라 여겨지는 이유일 것이다.

칸반은 결코 팀 차원의 프로세스만이 아닙니다. 칸반 시스템은 여러 부서 사이의 업무 흐름을 다루는 프로세스였습니다. 칸반은 조직 차원의 업무 흐름 프로세스입니다. 칸반은 중간 계층이 변화를 이끌어갈 수 있도록 설계되어 있습니다. 많은 린 컨설턴트 들은 최고 경영진을 설득할 수만 있다면 반드시 성공할 수 있다고 이야기합니다. 그런 변화는 하향식 변화입니다. 대부분의 애자일 변화는 밑에서 시작하는 경향이 있습니다. 왜냐하면 애자일은 팀을 지향하며 개발자를 지향하기 때문입니다. 칸반은 중간 계층에서 변화를 시작할 수 있도록 만들어졌습니다. (부록3. 2013 컨퍼런스 인터뷰) - Kanban (Anderson, 2014)

비교

• 스크럼: 프로젝트 관리와 협업 강화 (프로젝트 관리에 유리)
• XP: 개발자의 기술 역량 향상과 품질 중심 개발 목표 (기술적으로 복잡한 프로젝트에 유리)
• 칸반: 지속적인 흐름을 유지하고 유연한 업무 관리 (운영에 유리)

실제 진행

공통 차세대 플랫폼 프로젝트는 스크럼 방식을 주로 활용했다.

Back Log를 Story Board로 관리했다. 모두가 볼 수 있도록, 스크럼 보드를 사용했다. 이를 통해, 모두가 현재 진행 상황을 파악할 수 있었다.

DSU(Daily Stand Up Meeting)는 매일 아침 9시에 진행했으며, 30초씩만 발언할 수 있었고, 이 시간을 넘어가면 스크럼 마스터(IBM 실장님)가 중단시켰다. 때문에 전체 회의는 5분이 넘어가지 않았다. 이 과정을 통해 모든 업무가 투명하게 공유되었다. 이 방식은 처음에는 낯설었지만, 결과적으로 팀의 생산성과 협업을 극대화했다.

초기 백로그는 PO가 작성했지만, 매일 DSU에서 팀원들과 논의하며 우선순위를 조정하고, 불필요한 항목을 정리하는 과정을 반복했다. 처음 계획했던 기능도 개발 도중 필요성이 낮아지면 과감히 제외했고, 반대로 중요한 요구사항이 새롭게 등장하면 빠르게 반영했다. 이렇게 유연한 백로그 관리를 통해, 가장 가치있고 진짜 필요한 기능에 집중할 수 있었다.

매주 스프린트 리뷰를 통해, 다른 개발팀들과 DBA들(이해관계자)에게 공통 플랫폼을 소개하고, 피드백을 받았다.

매주 Pizza Day를 가졌다. 말 그대로 피자를 시켜 먹는 날이다. 이 날은 팀원들과 편하게 대화를 나눌 수 있는 시간이다. 또한 이 시간에 스프린트 회고를 같이 했다.

프로젝트의 개발은 XP 방식으로 진행되었다. 깃랩 이슈 보드를 통해 작업을 관리했고, 기능 개발이 완료될 때마다 MR을 생성하고 코드 리뷰를 수행했다. CI/CD를 통해, 코드를 자동으로 빌드하고, 테스트를 수행했다. 하루 이틀 단위로 기능을 완성하고, DSU에서 Do, Done, Block을 공유하고, 백로그가 점진적으로 추가됐다. 팀원은 매일 서로가 무엇을 하고 있는지 투명하게 공유했고, 서로 간의 피드백이 자유로웠다.

비록 3주간의 짧은 프로젝트였지만, 많은 것을 배웠다. 애자일은 무엇인가? 무엇을 위한 것인가? 어떻게 적용해야 하는가? 이 모든 것을 베스트프렉티스로 배웠다. 앞으로 나는 단순히 '애자일을 한다'는 것이 아니라, 애자일의 본질을 이해하고 팀과 조직이 함께 성장할 수 있는 환경을 만드는 개발자가 되고 싶다. 애자일은 그저 방법론이 아니라, 지속적인 개선과 협업을 통해 더 나은 개발 문화를 구축하는 철학이자 실천 방식이다."

애자일은 마음가짐이다!

실버 불렛은 없다. 하지만 무엇이 소프트웨어 방법론에 더 알맞을지는 생각해볼 필요가 있다. 끝으로 켄트 벡의 Extreme Programming(kent, beck, 2004)에서의 일화를 가져왔다.

나는 처음으로 운전하는 법을 배운 날을 생생하게 기억한다. 어머니와 나는 캘리포니아 치코 근처의 5번 고속도로를 달리고 있었는데, 이 도로는 평탄한 땅에 직선 도로가 지평선까지 쭉 곧게 뻗어나간다. 어머니는 조수석에 앉은 내게 손을 뻗어 운전대를 잡아 보도록 하셨다. 그리고 운전대를 돌리는 것이 자동차의 방향에 어떻게 영향을 미치는지 내가 느끼게 해주셨다. 그런 다음 내게 "이렇게 해보렴. 차가 길의 정중앙에 놓이도록 해서 그 방향으로 쭉 뻗어나가면 저 지평선에 바로 맞닿을 수 있게 해라."라고 말씀하셨다.
나는 도로를 흘끗흘끗 내다보며 조심스럽게 방향을 잡았다. 나는 차가 정확히 길 한가운데에서 차선 중앙으로만 가도록 했다. 꽤 잘 하고 있었다. 그러다가 아주 잠깐 정신을 딴 데 팔았더니...
차가 길 옆 자갈을 스치는 소리에 나는 번쩍 제정신이 들었다. 어머니는 부드럽게 차를 다시 길에 돌려놓으셨다 (지금 생각해 보니 그때 당신의 용기는 정말 놀랍다.) 내 심장은 두근거렸다. 어머니는 이런 경험을 하게 만든 다음에야 진짜 운전법을 가르쳐 주셨다. "운전은 차를 똑바른 방향으로 가도록 맞추어 놓고 그대로 두는 게 아니야. 운전은 계속 신경을 쓰면서 이번에는 이쪽으로 조금, 다음에는 저쪽으로 조금씩 방향을 고치면서 가능거지." (2)