Joinc Wiki: 애자일이 정착되기 힘든 이유

Facebook Joinc 그룹 Joinc QA 사이트

현재위치 : 미니사이트>개발자>글모음>프로그래밍관련>division_of_labor

joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다.

애자일이 정착되기 힘든 이유

그냥 생각나는 데로..

노동력과 에너지를 집약시키는 2차산업사회에서, 분업은 나타날 수 밖에 없는 당연한 노동의 형태일 것이다. 노동력과 에너지를 집약시키는 이유는 효율을 극대화 하기 위함이다. 노동력과 에너지를 효율적으로 집약을 시킬려면, 좁은 공간에 몰아 넣은다음, 기계의 부품과 같이 째깍째깍 거리면서, 주어진 일만을 하도록 만들어 놓으면 된다.

해서 공장이 만들어지고, 컨테이너 벨트가 설치가 된다. 컨테이너 벨트는 결국, 주어진 일만을 잘 수행해네는 숙련공을 만들어내기 위한, 즉 톱니바퀴를 만들어내기 위해서 고안된 작업방식일 것이다. 기업은 기본적으로 전체주의적인 성격을 띠며 힘을 집중시키고자 하는데, 이러한 기업의 특징에 부합하면서, 최대한 이익을 뽑아낼 수 있도록 도와주는 시스템이기 때문이다.

반면 정보산업, 특히 소프트웨어산업에 있어서는 기존의 분업방식이 어울리지 않다고 생각하는게 개발자들의 상식이다. 아니 이러한 개발자들의 상식은 일반인들과 심지어는 기존 2차산업에 익숙했던 기성세대 - 소프트웨어 산업에서 관리자 역할을 하는 -들에게 까지도 상식이 되어있다. 컨테이너 벨트에 개발자를 몰아넣고 채근 하는식으로 개발을 해서는 원하는 프로그램이 만들어지지 않는다는 것은 (여러번의 실패의)경험으로 잘 알고 있다. - 소프트웨어와 기존산업과의 차이점은 여기에서는 자세히 설명하지 않을 생각이다. -

소프트웨어개발은 최초에는 체계화된 개발방식을 가지지 않은 상태에서, 개발자 각개인의 역량에 따라서 나름의 개발방식을 만들어서 사용했던 것으로 보인다. 그러나 소프트웨어산업의 규모가 커지게 되자, 효율적인 소프트웨어의 개발과 유지보수가 힘들어지게 되었다. 결국 소프트웨어산업의 특성에 맞는 체계화된 개발방법론들이 만들어지게 된다.
애자일이 나온 이유도 이 때문일 것이다.

많은 개발방법론 중에서, 특별히 애자일을 언급하는 이유는 기존의 개발방법론들이 2차 산업시대 제품을 생산하던 그 경험을 토대로 만들어진 측면이 강하기 때문이며, 그나마도 산업전반을 아우른다기 보다는 특정 영역만을 다루는 경우가 많아서, 소프트웨어가 가지는 구조와 철학을 포괄하는 방법론이 되기에는 부족한 면이 있다고 보았기 때문이다.

기존의 2차산업시대의 경험을 이용해서 만들어진 개발방법론 - 혹은 방식 - 이 문제가 될 수 있는 있는 이유는 2차 산업시대의 특징 자체가 중앙집중적이며, 피라미드적이고, 노동과 가치가 극도로 분리되는 탈가치화와 이에 따라 발생하는 노동의 소외가 증가되는 문제를 만들어 냈다는 점 때문이다. 이들 문제점은 노동과 자본의 한계점이 드러나게 했다. 이 상황에서 노동자는 그냥 노동하는 소외된 기계일 뿐이이고, 창조하는 힘은 극도로 빈약해질 수 밖에 없는데, 소프트웨어 개발에서 이는 심각한 문제이기 때문이다. - 비단 소프트웨어 쪽만 아니다 -

2차산업시대의 경험을 가지고 만든 개발방법론들이 지금의 소프트웨어개발에 맞지 않는 것은 당연한 일일 것이다. 새술을 헌부대에 담는 꼴이라고나 할까 !

애자일의 지향점을 보면, 기성기업의 수직적, 권력집중적 마인드와 분명한 차이가 있음을 알 수 있다. 예컨데, 애자일의 가장 중요한 핵심은 사람중심의 개발과 참여 그리고 협력 이다. 이것은 노동의 소외에 주목해서 이를 해소하기 위한 목적으로 만들어진 지향점인데, 프로그래머와 프로그래머 사이는 물론이고 프로그래머와 고객 사이까지도 수평적이고 평등한 위치에서 서로 도움을 주고 협력을 하는 것을 기본원칙으로 하고 있다.

내가 만들고자 하는 프로그램에 내가 좀더 주도권을 가지고 참여할 수 있도록 함으로써, 더욱 즐겁게 일할 수 있을 것이다. 즐겁게 일할 수 있느냐 하는건, 창의력이 중시되는 소프트웨어 개발에서는 매우 중요하다. 즐거우며, 또한 생각할 여유가 주어져야 창의적인 생각을 할 수 있고, 좋은 제품을 만드는 밑거름이 될 수 있기 때문이다.

애자일은 사실 단순한 방법론이라고 볼수가 없다. 그것은 노동과 소프트웨어에 대한 새로운 관점을 담고 있는 철학 혹은 운동으로까지 생각할 수 있다는게 내 생각이다. 그러므로 애자일을 단순히 방법론 수준에서 보고, 관련 책을 사서 보는 정도 혹은 컨설팅을 받는 정도로 해서, 애자일이 정착할 수 있을 거라고 생각하지 말아야한다.

애자일이 정착되기 위해서는 기업의 권력구조와 소프트웨어와 노동을 바라보는 근본적인 마인드의 변화가 이루어져야 한다. 갑을병정...의 수직적이고 폭력적인 하도급 기업관계가 관행인 SI기업에 애자일을 도입하는게 의미가 있을 것이라고 생각하는 사람은 아무도 없을 것이다. 마찬가지로 기업의 일부조직만을 눈요기 식으로 애자일틱한 구조로 만들었다고해서, 애자일이 정착할 수 있을런지 하는가에 대해서도 대단히 회의적이다.

애자일이 실패하는 또다른 이유로는 적절하지 않은 곳에 애자일을 무작정 도입하려고 하는데에도 있다고 본다. 컨테이너 벨트를 이용해서 분업화된 작업이 이루어지는 곳에 애자일을 도입할 수 없을 것이다. 예컨데, 비행기생산공정에 애자일을 도입할 수 있을지는 회의적일 수 밖에 없는데, 그 이유는 이들 산업은 에너지,기술,노동 집약적인 산업으로 애자일의 철학과는 전혀 성격이 들어 맞지를 않기 때문이다. 애자일은 만능이 아니다. 마찬가지로 기업의 인프라와 관련된 SI, 통합자원관리 솔류션의 개발등 자본과 에너지가 집중되는 소프트웨어의 개발에도 적당한거 같지는 않다. 인터넷기반에서의 서비스라든지 SE영역, 평등한 분산 개발구조를 가지는 오픈소스 개발영역에 적당한 방법이 아닐까 싶은 생각이 든다.

만약 이러한 제품을 만드는데, 고민없이 애자일을 억지로 적용했다가는 아래의 사태가 발생하지 않을까 ?

그래서 나름 결론은

애자일이 실패하는 가장 큰 이유는 pair 프로그래밍을 어떻게하고, 단위 테스트를 어떻게 하는 등의 기술적인 문제가 아닌 철학의 문제다

이글은 joinc 블로그로 발행되었습니다. 댓글은 블로그에서 입력할 수 있습니다.

뇌자극 QA 뇌자극 에러 및 수정목록 총 페이지 수 : 3224 전체 함수/용어사전 구글검색방법 구글 맞춤검색	Facebook Joinc 그룹 Joinc QA 사이트 현재위치 : 미니사이트>개발자>글모음>프로그래밍관련>division_of_labor Tweet joinc는 Firefox와 chrome에서 테스트 했습니다. IE에서는 테이블이 깨지거나 이미지가 보이지 않을 수 있습니다. 특히 구글 Docs이미지의 경우 엑박처리될 수 있습니다. 애자일이 정착되기 힘든 이유 그냥 생각나는 데로.. 노동력과 에너지를 집약시키는 2차산업사회에서, 분업은 나타날 수 밖에 없는 당연한 노동의 형태일 것이다. 노동력과 에너지를 집약시키는 이유는 효율을 극대화 하기 위함이다. 노동력과 에너지를 효율적으로 집약을 시킬려면, 좁은 공간에 몰아 넣은다음, 기계의 부품과 같이 째깍째깍 거리면서, 주어진 일만을 하도록 만들어 놓으면 된다. 해서 공장이 만들어지고, 컨테이너 벨트가 설치가 된다. 컨테이너 벨트는 결국, 주어진 일만을 잘 수행해네는 숙련공을 만들어내기 위한, 즉 톱니바퀴를 만들어내기 위해서 고안된 작업방식일 것이다. 기업은 기본적으로 전체주의적인 성격을 띠며 힘을 집중시키고자 하는데, 이러한 기업의 특징에 부합하면서, 최대한 이익을 뽑아낼 수 있도록 도와주는 시스템이기 때문이다. 반면 정보산업, 특히 소프트웨어산업에 있어서는 기존의 분업방식이 어울리지 않다고 생각하는게 개발자들의 상식이다. 아니 이러한 개발자들의 상식은 일반인들과 심지어는 기존 2차산업에 익숙했던 기성세대 - 소프트웨어 산업에서 관리자 역할을 하는 -들에게 까지도 상식이 되어있다. 컨테이너 벨트에 개발자를 몰아넣고 채근 하는식으로 개발을 해서는 원하는 프로그램이 만들어지지 않는다는 것은 (여러번의 실패의)경험으로 잘 알고 있다. - 소프트웨어와 기존산업과의 차이점은 여기에서는 자세히 설명하지 않을 생각이다. - 소프트웨어개발은 최초에는 체계화된 개발방식을 가지지 않은 상태에서, 개발자 각개인의 역량에 따라서 나름의 개발방식을 만들어서 사용했던 것으로 보인다. 그러나 소프트웨어산업의 규모가 커지게 되자, 효율적인 소프트웨어의 개발과 유지보수가 힘들어지게 되었다. 결국 소프트웨어산업의 특성에 맞는 체계화된 개발방법론들이 만들어지게 된다. 애자일이 나온 이유도 이 때문일 것이다. 많은 개발방법론 중에서, 특별히 애자일을 언급하는 이유는 기존의 개발방법론들이 2차 산업시대 제품을 생산하던 그 경험을 토대로 만들어진 측면이 강하기 때문이며, 그나마도 산업전반을 아우른다기 보다는 특정 영역만을 다루는 경우가 많아서, 소프트웨어가 가지는 구조와 철학을 포괄하는 방법론이 되기에는 부족한 면이 있다고 보았기 때문이다. 기존의 2차산업시대의 경험을 이용해서 만들어진 개발방법론 - 혹은 방식 - 이 문제가 될 수 있는 있는 이유는 2차 산업시대의 특징 자체가 중앙집중적이며, 피라미드적이고, 노동과 가치가 극도로 분리되는 탈가치화와 이에 따라 발생하는 노동의 소외가 증가되는 문제를 만들어 냈다는 점 때문이다. 이들 문제점은 노동과 자본의 한계점이 드러나게 했다. 이 상황에서 노동자는 그냥 노동하는 소외된 기계일 뿐이이고, 창조하는 힘은 극도로 빈약해질 수 밖에 없는데, 소프트웨어 개발에서 이는 심각한 문제이기 때문이다. - 비단 소프트웨어 쪽만 아니다 - 2차산업시대의 경험을 가지고 만든 개발방법론들이 지금의 소프트웨어개발에 맞지 않는 것은 당연한 일일 것이다. 새술을 헌부대에 담는 꼴이라고나 할까 ! 애자일의 지향점을 보면, 기성기업의 수직적, 권력집중적 마인드와 분명한 차이가 있음을 알 수 있다. 예컨데, 애자일의 가장 중요한 핵심은 사람중심의 개발과 참여 그리고 협력 이다. 이것은 노동의 소외에 주목해서 이를 해소하기 위한 목적으로 만들어진 지향점인데, 프로그래머와 프로그래머 사이는 물론이고 프로그래머와 고객 사이까지도 수평적이고 평등한 위치에서 서로 도움을 주고 협력을 하는 것을 기본원칙으로 하고 있다. 내가 만들고자 하는 프로그램에 내가 좀더 주도권을 가지고 참여할 수 있도록 함으로써, 더욱 즐겁게 일할 수 있을 것이다. 즐겁게 일할 수 있느냐 하는건, 창의력이 중시되는 소프트웨어 개발에서는 매우 중요하다. 즐거우며, 또한 생각할 여유가 주어져야 창의적인 생각을 할 수 있고, 좋은 제품을 만드는 밑거름이 될 수 있기 때문이다. 애자일은 사실 단순한 방법론이라고 볼수가 없다. 그것은 노동과 소프트웨어에 대한 새로운 관점을 담고 있는 철학 혹은 운동으로까지 생각할 수 있다는게 내 생각이다. 그러므로 애자일을 단순히 방법론 수준에서 보고, 관련 책을 사서 보는 정도 혹은 컨설팅을 받는 정도로 해서, 애자일이 정착할 수 있을 거라고 생각하지 말아야한다. 애자일이 정착되기 위해서는 기업의 권력구조와 소프트웨어와 노동을 바라보는 근본적인 마인드의 변화가 이루어져야 한다. 갑을병정...의 수직적이고 폭력적인 하도급 기업관계가 관행인 SI기업에 애자일을 도입하는게 의미가 있을 것이라고 생각하는 사람은 아무도 없을 것이다. 마찬가지로 기업의 일부조직만을 눈요기 식으로 애자일틱한 구조로 만들었다고해서, 애자일이 정착할 수 있을런지 하는가에 대해서도 대단히 회의적이다. 애자일이 실패하는 또다른 이유로는 적절하지 않은 곳에 애자일을 무작정 도입하려고 하는데에도 있다고 본다. 컨테이너 벨트를 이용해서 분업화된 작업이 이루어지는 곳에 애자일을 도입할 수 없을 것이다. 예컨데, 비행기생산공정에 애자일을 도입할 수 있을지는 회의적일 수 밖에 없는데, 그 이유는 이들 산업은 에너지,기술,노동 집약적인 산업으로 애자일의 철학과는 전혀 성격이 들어 맞지를 않기 때문이다. 애자일은 만능이 아니다. 마찬가지로 기업의 인프라와 관련된 SI, 통합자원관리 솔류션의 개발등 자본과 에너지가 집중되는 소프트웨어의 개발에도 적당한거 같지는 않다. 인터넷기반에서의 서비스라든지 SE영역, 평등한 분산 개발구조를 가지는 오픈소스 개발영역에 적당한 방법이 아닐까 싶은 생각이 든다. 만약 이러한 제품을 만드는데, 고민없이 애자일을 억지로 적용했다가는 아래의 사태가 발생하지 않을까 ? 그래서 나름 결론은 애자일이 실패하는 가장 큰 이유는 pair 프로그래밍을 어떻게하고, 단위 테스트를 어떻게 하는 등의 기술적인 문제가 아닌 철학의 문제다 이글은 joinc 블로그로 발행되었습니다. 댓글은 블로그에서 입력할 수 있습니다.