애자일
애자일 연합 홈페이지
보다시피 "왼쪽에 있는 것들도 가치가 있지만"을 간과해서는 안 된다. "애자일을 사용하니까 그 어떤 공정도 도구도 문서도 계획도 만들지 않겠다"라고 딱 잘라 말할 수는 없다는 것. 애자일 프레임워크를 설명하고 있는 각 단체의 자료를 살펴보면 거기서도 각종 공정과 도구와 문서를 심심찮게 다루고 있다. (...) 물론 그것들을 우측에 언급된 것들에 대해 가중치를 두려는 목적으로 사용하기는 하지만.
정식 명칭은 애자일 소프트웨어 개발(Agile[2] software development). 한국에서는 주로 '''애자일 방법론''' 이라고 부르는 소프트웨어 개발 방법론의 하나이다. 처음부터 끝까지 계획을 수립하고 개발하는 폭포수(Waterfall) 방법론과는 달리 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이다. 켄트 벡이 주창한 익스트림 프로그래밍(XP,Extreme Programming)과 테스트 주도 개발이 대표적이다.
애자일 방식의 소프트웨어 개발에 대한 방법론들이 처음 등장하기 시작한 것은 90년대 중반으로 기존의 무겁고 규범적인 방법론에서 탈피하여 가벼운 방법론을 지향하며 등장하였다. 처음부터 애자일(Agile)이라고 불렸던 것은 아니고 경량방법론 등으로 불리다 애자일 선언문(Agile Manifesto)을 만들면서 비로소 Agile로 불리게 되었다. 이후부터 애자일은 소프트웨어 개발의 한가지 특징적인 개발 방식으로 의미를 갖기 시작하였다.
빠르고 기민한, 이라는 이름 덕인지 수많은 기업들이 나서서 애자일로 개발한다고 떠들고 있지만, 정작 실상은 애자일이 뭔지도 모르면서 기획서를 통과시키기 위해 붙이는 전문용어중 하나의 취급일 뿐이다. 애자일을 제대로 하려면 QA 인력도 필요한데, 애초에 애자일 방법론은 하나의 개발 모델이 아니라, 여러 개의 개발 방법론이 있는 개발 방법론 집합체의 원칙에 가깝다. 만약 회의실에서 사업이나 기획자가 애자일 방법론을 언급 한다면 이렇게 물어보길 바란다. '''애자일 방법론중 어떤 방법론 말인가요?''' 만약 그 질문에 답변이 없거나 어물쩍 거리면 그건 그냥 야근 하자는 소리일 뿐이다. 잘 알지도 못하면서 하는 말이라는 것이다.
이렇게 된 배경에는 다음과 같은 설이 가장 유력하다.
원래 컴퓨팅서비스는 1990년 대 후반까지만 해도 IBM등의 공룡사업자가 만드는 메인프레임 판이었고, 이 메인프레임에 더미터미널 콘솔을 붙여 서비스를 했다. 그 때는 검은 화면에 초록 또는 회색 글씨만 가득찬 화면 구성이라, 키보드 입력 편의성 개선이 제일 중요했다. 그런데, 이후 PC가 보급되면서, 메인프레임이 독점했던 상당량의 컴퓨팅 자원을 굳이 메인프레임이 사용하지 않고, 최종 사용자 단의 PC가 나눠져도 되는 환경이 되었으며, 이에 따라, 클라이언트/서버 환경으로 변화(라고 쓰고, 업계에서는 다운사이징이라 불렀다)했다. 이러한 컴퓨팅 환경이 재차 웹시대로 진화하고, 모바일 시대로 흘러가지만, 지금까지도 개발/관리 방법론은 폭포수 모형[3]일 때의 그것을 그대로 쓰고 있었다. 기술의 변화에 따라, 개발 환경이 변했지만, 25년 동안 방법론의 변화가 없었던 것이다.
30년 동안 대규모 금융권 SI사업을 전문적으로 수행해 온 동양네트웍스에 따르면, “지금까지의 Waterfall Model 방식으로 프로젝트를 진행 할 경우 개발이 완료되기 전 까지 사용자가 실제 구동하는 화면을 볼 수 없다. UI/UX 정의 단계에서 사용자와 설계자 간의 합의를 이루는 과정의 매개체로 파워포인트와 같은 정적 문서를 주로 활용하는 실정이다. 이러한 정적 문서는 UI 구성요소의 배치 위치 등을 표현하기에는 적절하나 실제 동작 방법을 텍스트와 그림으로만 표현하기에는 한계가 있다. 이러한 한계로 인하여 사용자와 설계자는 같은 문서를 보고 다른 UI/UX를 상상하게 되고 결국 오해를 한 상태로 개발까지 진행되게 된다.
Waterfall 방식에서 사용자와 설계자는 이러한 오해를 개발이 완료된 후 테스트 단계에 와서야 실제 구동하는 화면을 보고 난 후 인지할 수 있다. 뒤늦게 발견한 요구정의 오류에 따라 개발된 내용에 수정이 필요하게 되고, 오류 내용에 따라 DB 모델링 등 설계가 변경되는 경우 수정해야 할 분량은 가늠할 수 없는 수준이 되어 프로젝트 납기 준수에 큰 차질을 빚는다.”라는 분석을 내놓았다.
따라서, 스타트업의 소규모 앱 개발이 아닌 대규모 개발에서 실제적으로 성공하려면, 몇 가지 장치가 필요하다. 애자일 그 자체 만으로 고객을 설득할 수 없다는 한계(고객이 대금 줄 때, 책임 회피할 만한 증빙자료)에 기반하여 고객 과금(대금 지급 주기), 고객이 초반에 문서 상에서 대충 승인한 후 떼쓰기하여 관철시키는 문제 방지(나중에 개발 변경 물량 폭탄으로 이어짐) 등을 위해 동양네트웍스는 대규모 금융권 시스템에 적용해 성공한 방법론(TY*agile), 실제적인 프레임워크(TY*eXtreame)와 코딩이 필요 없는 테스트/업무 자동화 툴를 갖추고 고객을 대상으로 임상 실험까지 완료했다. 대부분의 대기업들이 자기 방법론과 프레임워크가 적절하다고 하지만, 결국 프로젝트 들어가면, 다 폭포수로 바뀌고, 소송에서도 제안했던 방법론이 폭포수에 기반한 애자일이었다고 주장한다. 프리랜서 개발자 업계에서 그 중, 그나마 쓸만 하다라고 평가 받는 것은 동양 것이 낫다. SI업계 빅3인 삼성SDS,LG CNS,SK는 애자일로 개발할 프로젝트 자체를 안한다. 그룹 물량으로도 먹고 살만 하기 때문이다.
한국개발 시장, 특히 SI 에서의 애자일은 정식적인 설명과는 전혀 다른 모습을 드러내곤 한다. 실제로 애자일 형태로 개발할 능력도 없고, 있다 해도 시간적, 금액적 한계 때문에 애자일을 쓰면 안되지만, 큰 규모의 사업 / 대기업에서 사용되었다는 미명으로 소형 개발 업무에서도 사용하겠다는 기괴한 포부와 함께 사용되곤 한다. 실제 개발 시작전에는 애자일을 응용한 엄청난 개발을 해줄게! 로 시작하지만 막상 개발을 시작하면 한국 특유의 노예관리 형태로 변질된다.[4] 여전히 대한민국 대부분의 기술개발자들은 애자일은 커녕 타임어택 형식의 개발 지옥에서 살아가고 있다.
애자일이 제대로 돌아가기 어려운 것은, 말만 애자일이지 결국 워터폴 방식으로 운영을 하게 되기 때문이다. 애자일의 장점은 예측이 어려운 부분을 대응하는 데에 있어서 어느정도의 해답을 준다는 부분인데, 대다수의 한국 업체들은 모든 것을 다 짜둔 상태에서 프로젝트를 시작하며, 설사 준비가 제대로 안 된 상태에서 일을 시작하더라도 이를 애자일 방법론대로 나중에 결정하게 놔두는 경우가 없고 불확실한 부분을 최대한 빨리 확정부터 하려고 한다. 갑을 관계가 희박한 분야에서도 이러한데, SI의 경우는 말할 것도 없다. 일을 주는 쪽에서는 내부적으로 개발 과정이 어떻게 돌아가는지 전혀 관심이 없고, 현재 개발자측 가용자원이 어떻게 되든지도 당연히 아웃 오브 안중이고, 돈을 틀어쥐고 "시간 내로 끝내지 않으면 끝장이야!" 하는 엄포를 놓는다. 이런 역학구조는 활발한 의사소통, 끊임없는 프로세스 개선, 단순한 사이클의 반복을 통해 실제로 동작하는 기능을 조금씩 늘려나가는 것이 핵심인 애자일 방법론과 영 맞지가 않는다. 계약서대로 정해진 시간 내에 정해진 스펙대로 물건을 만들면 되는 상황에 애자일을 끼워넣을 이유가 도대체 뭐가 있단 말인가. 결국 앞뒤 다 자르고 "중간에 요구사항 추가가 있겠지만 추가 금전 보상이나 가용 자원 조정은 없음."을 애자일이란 이름하에 에둘러 표현하는 것이나 다름 없다. 상술한대로 이는 야근을 의미할 뿐이다.
메시지 전달방향이 고정되어 있다면 시간낭비 자원낭비하지 말고 애자일의 A도 꺼내지 말고 그냥 기존대로(워터폴) 하는 게 낫다. 도구에는 죄가 없고, 모든 것은 사용하는 사람에게 달렸을 뿐이다. 이 글을 읽는 사람이 의사 결정권자라서 이 부분을 조절할 수 있는 상황이라면, "요구사항을 추가하고자 할 때, 새 리소스를 얻어다주거나 대신 다른 기능을 기꺼이 포기할 준비가 되어 있는가?", "개발 진행이 예측대로 잘 되지 않은 상태에서 릴리즈 날짜가 다가올 때, 야근을 요구하지 않고 완성된 기능만 가지고 릴리즈를 하거나 출시일을 미룰 수 있는가?" 이 두 가지 질문에 대해 스스로 답변을 내어 보길 바란다. 둘 중 하나라도 No가 나온다면, 애자일을 할 이유가 전혀 없고 해봤자 역효과만 날 것이다.
혹여 일본 IT 업체에 취직하거나, 혹은 파견을 나갈 일이 있다면 프로젝트 진행을 설명할 때 높은 확률로 '''애자일 방법론으로 진행 할 건데, 할 수 있겠습니까?''' 라는 말을 들을 수 있다. 그리고 매우 안타깝지만, 일본은 한국과는 전혀 다른 의미로 애자일 개발을 할 형편이 안된다. 관료주의적 성향이 엄청나게 강한 일본 대기업은 한국과는 달리 IT라고 해도 엄청난 양의 문서를 남기는 경향이 있는데, 이것은 위에 말한 애자일 방법론의 기본 원칙중 '''포괄적인 문서보다 작동하는 소프트웨어를'''에 정면으로 위배된다. 기본 틀이 되는 기업 문화 부터가 이러하니 애자일 방법론이 먹힐 가능성 자체가 없다.[5] 결국 일본 IT 업체에서 '''애자일로 할 건데 할 수 있습니까?''' 라는 질문을 받으면 이렇게 해석하면 된다. '''우리는 네가 개발할때 수시로 아무때나 설계와 스펙 변경을 끝도 없이 요구 할 작정인데 거기에 불평불만 없이 응해 줄 수 있습니까?'''
인간관계 및 업무 협력이 동양권 회사들보다 훨씬 수평적이고, 소프트웨어 공급 면에서도 갑과 을이 칼같이 정해져있는 경우가 많지 않은 서구권 회사들은 애자일을 도입하기가 훨씬 수월한 상황. 그래서 애자일이 요구하는 직급을 회사에 신설까지 해가며 최적화된 조직을 만들기 위해 여념이 없는 회사들이 많다. 그래서 "필요없는 것은 모두 쳐내고" "고객이 원하는 기능 위주로" "빠른 사이클로 릴리즈를 내놓는다"는 장점이 비교적 잘 드러나는 것을 볼 수 있다. 또한 소프트웨어 개발의 최대 난점들인 "직접 해보기 전엔 모르기 때문에 계획이 전혀 들어맞지 않는다"[6], "다 만들어놨더니 세상이 변했다"(...) 등등에 대한 해답을 어느정도 제시하는 데에 성공했고, 기존 워터폴 방식에 비해 릴리즈당 개발 기간을 눈에 띄게 단축시키거나 업계 트렌드를 제품에 빠르게 반영하는 등 제법 효과를 보고 있다. 애초에 애자일 자체가 서구권에서 만들어진 것이기 때문에 서양 업무문화에 더 적합할 수밖에 없다.
1. 애자일 선언문 (Manifesto for Agile Software Development)
애자일 선언문 전문We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
'''Individuals and interactions''' over processes and tools
'''Working software''' over comprehensive documentation
'''Customer collaboration''' over contract negotiation
'''Responding to change''' over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
© 2001, the Agile Manifesto authors
This declaration may be freely copied in any form, but only in its entirety through this notice.
한국어판 애자일 선언문 [1]애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다.
이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 '''개인과 상호작용'''을
포괄적인 문서보다 '''작동하는 소프트웨어'''를
계약 협상보다 '''고객과의 협력'''을
계획을 따르기보다 '''변화에 대응하기'''를
가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만, 우리는 '''오른쪽에 있는 것들에 더 높은 가치를 둔다'''는 것이다.
Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler,
James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin
Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
© 2001, 상기 저자들
이 선언문은 어떤 형태로든 자유로이 복사할 수 있지만, 본 고지와 함께 전문으로서만 가능하다.
보다시피 "왼쪽에 있는 것들도 가치가 있지만"을 간과해서는 안 된다. "애자일을 사용하니까 그 어떤 공정도 도구도 문서도 계획도 만들지 않겠다"라고 딱 잘라 말할 수는 없다는 것. 애자일 프레임워크를 설명하고 있는 각 단체의 자료를 살펴보면 거기서도 각종 공정과 도구와 문서를 심심찮게 다루고 있다. (...) 물론 그것들을 우측에 언급된 것들에 대해 가중치를 두려는 목적으로 사용하기는 하지만.
2. 개요
정식 명칭은 애자일 소프트웨어 개발(Agile[2] software development). 한국에서는 주로 '''애자일 방법론''' 이라고 부르는 소프트웨어 개발 방법론의 하나이다. 처음부터 끝까지 계획을 수립하고 개발하는 폭포수(Waterfall) 방법론과는 달리 개발과 함께 즉시 피드백을 받아서 유동적으로 개발하는 방법이다. 켄트 벡이 주창한 익스트림 프로그래밍(XP,Extreme Programming)과 테스트 주도 개발이 대표적이다.
3. 기원
애자일 방식의 소프트웨어 개발에 대한 방법론들이 처음 등장하기 시작한 것은 90년대 중반으로 기존의 무겁고 규범적인 방법론에서 탈피하여 가벼운 방법론을 지향하며 등장하였다. 처음부터 애자일(Agile)이라고 불렸던 것은 아니고 경량방법론 등으로 불리다 애자일 선언문(Agile Manifesto)을 만들면서 비로소 Agile로 불리게 되었다. 이후부터 애자일은 소프트웨어 개발의 한가지 특징적인 개발 방식으로 의미를 갖기 시작하였다.
4. 현장에서의 애자일 개발의 현실
빠르고 기민한, 이라는 이름 덕인지 수많은 기업들이 나서서 애자일로 개발한다고 떠들고 있지만, 정작 실상은 애자일이 뭔지도 모르면서 기획서를 통과시키기 위해 붙이는 전문용어중 하나의 취급일 뿐이다. 애자일을 제대로 하려면 QA 인력도 필요한데, 애초에 애자일 방법론은 하나의 개발 모델이 아니라, 여러 개의 개발 방법론이 있는 개발 방법론 집합체의 원칙에 가깝다. 만약 회의실에서 사업이나 기획자가 애자일 방법론을 언급 한다면 이렇게 물어보길 바란다. '''애자일 방법론중 어떤 방법론 말인가요?''' 만약 그 질문에 답변이 없거나 어물쩍 거리면 그건 그냥 야근 하자는 소리일 뿐이다. 잘 알지도 못하면서 하는 말이라는 것이다.
이렇게 된 배경에는 다음과 같은 설이 가장 유력하다.
원래 컴퓨팅서비스는 1990년 대 후반까지만 해도 IBM등의 공룡사업자가 만드는 메인프레임 판이었고, 이 메인프레임에 더미터미널 콘솔을 붙여 서비스를 했다. 그 때는 검은 화면에 초록 또는 회색 글씨만 가득찬 화면 구성이라, 키보드 입력 편의성 개선이 제일 중요했다. 그런데, 이후 PC가 보급되면서, 메인프레임이 독점했던 상당량의 컴퓨팅 자원을 굳이 메인프레임이 사용하지 않고, 최종 사용자 단의 PC가 나눠져도 되는 환경이 되었으며, 이에 따라, 클라이언트/서버 환경으로 변화(라고 쓰고, 업계에서는 다운사이징이라 불렀다)했다. 이러한 컴퓨팅 환경이 재차 웹시대로 진화하고, 모바일 시대로 흘러가지만, 지금까지도 개발/관리 방법론은 폭포수 모형[3]일 때의 그것을 그대로 쓰고 있었다. 기술의 변화에 따라, 개발 환경이 변했지만, 25년 동안 방법론의 변화가 없었던 것이다.
30년 동안 대규모 금융권 SI사업을 전문적으로 수행해 온 동양네트웍스에 따르면, “지금까지의 Waterfall Model 방식으로 프로젝트를 진행 할 경우 개발이 완료되기 전 까지 사용자가 실제 구동하는 화면을 볼 수 없다. UI/UX 정의 단계에서 사용자와 설계자 간의 합의를 이루는 과정의 매개체로 파워포인트와 같은 정적 문서를 주로 활용하는 실정이다. 이러한 정적 문서는 UI 구성요소의 배치 위치 등을 표현하기에는 적절하나 실제 동작 방법을 텍스트와 그림으로만 표현하기에는 한계가 있다. 이러한 한계로 인하여 사용자와 설계자는 같은 문서를 보고 다른 UI/UX를 상상하게 되고 결국 오해를 한 상태로 개발까지 진행되게 된다.
Waterfall 방식에서 사용자와 설계자는 이러한 오해를 개발이 완료된 후 테스트 단계에 와서야 실제 구동하는 화면을 보고 난 후 인지할 수 있다. 뒤늦게 발견한 요구정의 오류에 따라 개발된 내용에 수정이 필요하게 되고, 오류 내용에 따라 DB 모델링 등 설계가 변경되는 경우 수정해야 할 분량은 가늠할 수 없는 수준이 되어 프로젝트 납기 준수에 큰 차질을 빚는다.”라는 분석을 내놓았다.
따라서, 스타트업의 소규모 앱 개발이 아닌 대규모 개발에서 실제적으로 성공하려면, 몇 가지 장치가 필요하다. 애자일 그 자체 만으로 고객을 설득할 수 없다는 한계(고객이 대금 줄 때, 책임 회피할 만한 증빙자료)에 기반하여 고객 과금(대금 지급 주기), 고객이 초반에 문서 상에서 대충 승인한 후 떼쓰기하여 관철시키는 문제 방지(나중에 개발 변경 물량 폭탄으로 이어짐) 등을 위해 동양네트웍스는 대규모 금융권 시스템에 적용해 성공한 방법론(TY*agile), 실제적인 프레임워크(TY*eXtreame)와 코딩이 필요 없는 테스트/업무 자동화 툴를 갖추고 고객을 대상으로 임상 실험까지 완료했다. 대부분의 대기업들이 자기 방법론과 프레임워크가 적절하다고 하지만, 결국 프로젝트 들어가면, 다 폭포수로 바뀌고, 소송에서도 제안했던 방법론이 폭포수에 기반한 애자일이었다고 주장한다. 프리랜서 개발자 업계에서 그 중, 그나마 쓸만 하다라고 평가 받는 것은 동양 것이 낫다. SI업계 빅3인 삼성SDS,LG CNS,SK는 애자일로 개발할 프로젝트 자체를 안한다. 그룹 물량으로도 먹고 살만 하기 때문이다.
4.1. 한국
한국개발 시장, 특히 SI 에서의 애자일은 정식적인 설명과는 전혀 다른 모습을 드러내곤 한다. 실제로 애자일 형태로 개발할 능력도 없고, 있다 해도 시간적, 금액적 한계 때문에 애자일을 쓰면 안되지만, 큰 규모의 사업 / 대기업에서 사용되었다는 미명으로 소형 개발 업무에서도 사용하겠다는 기괴한 포부와 함께 사용되곤 한다. 실제 개발 시작전에는 애자일을 응용한 엄청난 개발을 해줄게! 로 시작하지만 막상 개발을 시작하면 한국 특유의 노예관리 형태로 변질된다.[4] 여전히 대한민국 대부분의 기술개발자들은 애자일은 커녕 타임어택 형식의 개발 지옥에서 살아가고 있다.
애자일이 제대로 돌아가기 어려운 것은, 말만 애자일이지 결국 워터폴 방식으로 운영을 하게 되기 때문이다. 애자일의 장점은 예측이 어려운 부분을 대응하는 데에 있어서 어느정도의 해답을 준다는 부분인데, 대다수의 한국 업체들은 모든 것을 다 짜둔 상태에서 프로젝트를 시작하며, 설사 준비가 제대로 안 된 상태에서 일을 시작하더라도 이를 애자일 방법론대로 나중에 결정하게 놔두는 경우가 없고 불확실한 부분을 최대한 빨리 확정부터 하려고 한다. 갑을 관계가 희박한 분야에서도 이러한데, SI의 경우는 말할 것도 없다. 일을 주는 쪽에서는 내부적으로 개발 과정이 어떻게 돌아가는지 전혀 관심이 없고, 현재 개발자측 가용자원이 어떻게 되든지도 당연히 아웃 오브 안중이고, 돈을 틀어쥐고 "시간 내로 끝내지 않으면 끝장이야!" 하는 엄포를 놓는다. 이런 역학구조는 활발한 의사소통, 끊임없는 프로세스 개선, 단순한 사이클의 반복을 통해 실제로 동작하는 기능을 조금씩 늘려나가는 것이 핵심인 애자일 방법론과 영 맞지가 않는다. 계약서대로 정해진 시간 내에 정해진 스펙대로 물건을 만들면 되는 상황에 애자일을 끼워넣을 이유가 도대체 뭐가 있단 말인가. 결국 앞뒤 다 자르고 "중간에 요구사항 추가가 있겠지만 추가 금전 보상이나 가용 자원 조정은 없음."을 애자일이란 이름하에 에둘러 표현하는 것이나 다름 없다. 상술한대로 이는 야근을 의미할 뿐이다.
메시지 전달방향이 고정되어 있다면 시간낭비 자원낭비하지 말고 애자일의 A도 꺼내지 말고 그냥 기존대로(워터폴) 하는 게 낫다. 도구에는 죄가 없고, 모든 것은 사용하는 사람에게 달렸을 뿐이다. 이 글을 읽는 사람이 의사 결정권자라서 이 부분을 조절할 수 있는 상황이라면, "요구사항을 추가하고자 할 때, 새 리소스를 얻어다주거나 대신 다른 기능을 기꺼이 포기할 준비가 되어 있는가?", "개발 진행이 예측대로 잘 되지 않은 상태에서 릴리즈 날짜가 다가올 때, 야근을 요구하지 않고 완성된 기능만 가지고 릴리즈를 하거나 출시일을 미룰 수 있는가?" 이 두 가지 질문에 대해 스스로 답변을 내어 보길 바란다. 둘 중 하나라도 No가 나온다면, 애자일을 할 이유가 전혀 없고 해봤자 역효과만 날 것이다.
4.2. 일본
혹여 일본 IT 업체에 취직하거나, 혹은 파견을 나갈 일이 있다면 프로젝트 진행을 설명할 때 높은 확률로 '''애자일 방법론으로 진행 할 건데, 할 수 있겠습니까?''' 라는 말을 들을 수 있다. 그리고 매우 안타깝지만, 일본은 한국과는 전혀 다른 의미로 애자일 개발을 할 형편이 안된다. 관료주의적 성향이 엄청나게 강한 일본 대기업은 한국과는 달리 IT라고 해도 엄청난 양의 문서를 남기는 경향이 있는데, 이것은 위에 말한 애자일 방법론의 기본 원칙중 '''포괄적인 문서보다 작동하는 소프트웨어를'''에 정면으로 위배된다. 기본 틀이 되는 기업 문화 부터가 이러하니 애자일 방법론이 먹힐 가능성 자체가 없다.[5] 결국 일본 IT 업체에서 '''애자일로 할 건데 할 수 있습니까?''' 라는 질문을 받으면 이렇게 해석하면 된다. '''우리는 네가 개발할때 수시로 아무때나 설계와 스펙 변경을 끝도 없이 요구 할 작정인데 거기에 불평불만 없이 응해 줄 수 있습니까?'''
4.3. 서구권
인간관계 및 업무 협력이 동양권 회사들보다 훨씬 수평적이고, 소프트웨어 공급 면에서도 갑과 을이 칼같이 정해져있는 경우가 많지 않은 서구권 회사들은 애자일을 도입하기가 훨씬 수월한 상황. 그래서 애자일이 요구하는 직급을 회사에 신설까지 해가며 최적화된 조직을 만들기 위해 여념이 없는 회사들이 많다. 그래서 "필요없는 것은 모두 쳐내고" "고객이 원하는 기능 위주로" "빠른 사이클로 릴리즈를 내놓는다"는 장점이 비교적 잘 드러나는 것을 볼 수 있다. 또한 소프트웨어 개발의 최대 난점들인 "직접 해보기 전엔 모르기 때문에 계획이 전혀 들어맞지 않는다"[6], "다 만들어놨더니 세상이 변했다"(...) 등등에 대한 해답을 어느정도 제시하는 데에 성공했고, 기존 워터폴 방식에 비해 릴리즈당 개발 기간을 눈에 띄게 단축시키거나 업계 트렌드를 제품에 빠르게 반영하는 등 제법 효과를 보고 있다. 애초에 애자일 자체가 서구권에서 만들어진 것이기 때문에 서양 업무문화에 더 적합할 수밖에 없다.
[1] 번역 상태가 그리 썩 좋지는 않다. 번역 과정에서의 의미 변질 논란을 피하기 위해 자연스러움을 희생하고 최대한 직역에 가까운 표현을 의도적으로 사용한 것일 수 있다.[2] 기민한 내지는 민첩한 등으로 번역된다.[3] https://ko.wikipedia.org/wiki/%ED%8F%AD%ED%8F%AC%EC%88%98_%EB%AA%A8%EB%8D%B8[4] 애자일에서 중시하는것은 개발시작단계부터 이해당사자의 적극적 참여를 요구한다. 외주환경에 차이는 있겠지만, 대부분의 경우 개발을 요청한 쪽은 명세서 만들어 던져놓고 결과물만 받기를 원하므로 정상적인 애자일 프로세스가 돌아가기 힘들다.[5] 단, 소규모 사업장이나 게임 회사는 예외인 경우도 많다[6] 물론 애자일이 아니라 애자일 할아버지라도 아예 모르는 걸 알아낼 방법은 없다. 단지 변화하는 상황에 좀 더 유연하게 대처할 수 있을 뿐이다.