그래서 애자일(Agile)이 뭔가요?
문과라서 문과스럽게 문과스러운 애자일을 끄적여봅니다
요즘에도 어떤 회사는 수십 여명을 거느린 부장 아래 지극히 수직적 문화를 이끌어 나가는 것을 볼 수 있다. 전례 없는 코로나 사태와 언택트를 동시에 겪었지만 그 흔한 재택 따위 없이 대면하고 회의하고 보고서로 작성된 A4용지가 이면지가 되어 곳곳에 난무하며 구시대적이고 구태의연한 모습을 보이기도 한다. (재택근무 없이 대면하고 회의한다는 것을 부정적으로 보는 것은 아니니 오해가 없길 바란다. A4용지 역시 필요하면 쓰는 것인데 이를 문제 삼으려는 것도 아니다. 구시대적인 발상과 발언은 물론이고 현실에 안주하려는 무능의 애티튜드는 겪어본 사람들이 더 잘 알 것이다)
군대보다 더한 수직적 직장 문화가 자리한 어느 곳에서는 특정 프로젝트를 실행할 때에도 영혼 없는 기획을 하고 유명무실한 시장조사를 거치며 껍데기에 불과한 보고서를 수차례나 작성한다. '초안'부터 시작한 보고서 파일 뒷자리에는 '수정', '진짜 최최종', '파이널' 등 끝날 때까지 끝나지 않는 꼬리표를 덕지덕지 붙이고 진짜로 마무리가 되면 그제야 결재를 받아 실행에 옮긴다. 기획 단계에서도 그러하지만 보고가 이뤄지는 단계나 프로젝트 실행에서도 시행착오를 겪으며 에너지를 쏟아낸다. 전통적이지만 노후된 조직 속에 노련함은 없고 나태함만 존재하는 듯 수많은 부서원들의 의견이 부서장 하나에 묻히는 경우도 다반사다. 씁쓸하지만 이것도 첨단 테크놀로지가 세상을 변화시키고 있는 작금의 현실이고 누군가의 거울이다. '돌다리도 두드려가며 건너라'라고 했지만 언제 건너갈 수 있을까? 이러한 조직 문화에서도 알게 모르게 어떠한 메리트가 있을지도 모르겠다만 일단 경험했던 것들을 이렇게 (지극히 개인적인 입장에서, 아주 부정적으로) 적어봤다.
출처 : pixabay<애자일(Agile)>
'애자일(Agile)'이라는 키워드는 위에서 말한 이야기와 굉장히 상반된다. 영단어 '애자일'의 의미는 '기민한', '재빠른'이라는 뜻을 담고 있다. 이를 경영방식의 키워드로서 회사 조직에 그대로 대입하면, 수평적이고 유연한 조직 문화를 의미한다. 대놓고 '애자일한 조직'이라 말하기도 한다. 한때 경영 트렌드를 이끄는 대표적 키워드가 되기도 했고 글로벌 IT 기업인 구글, 애플, 마이크로소프트 등이 애자일 조직 문화의 사례가 되기도 했다. 특별한 직급 체계 없이 팀원 개개인에게 의사 권한을 주고 거기서 나오는 이야기들을 귀담아듣고 수용한다. 일부 기업에서는 '셀(Cell)' 조직이라는 말을 쓰기도 하는데 이는 소규모의 팀 단위를 의미한다. 아주 기초적이고 기본적인 기획 단계를 거쳐 실행에 바로 옮긴다. 사실 그리 오래 걸리지 않는다. 애초에 소규모 조직에서 결정된 사안이므로 프로젝트 하나도 쉽게 테스트가 가능하다. 외부로부터 피드백을 듣고 시행착오를 거쳐 최종 결과물을 손에 쥔다. 당연하지만 유연하게 대처할 수도 있고 때문에 기민하게 움직일 수도 있다.
기민하고 민첩하고 유연하게 그리고 수평적으로, 애자일. 출처 : soflab.pl<애자일의 의미>
애자일은 사실 프로그래밍에 집중한 '유연한 개발방식'으로 소프트웨어 개발 방법론 중 대표되는 하나다.
"소프트웨어 개발 어렵지? 애자일 쓰면 바로 해결돼!"
난 이게 무슨 말인지 잘 모르겠다. 그래서 나무위키의 힘을 빌렸다. 나무위키에서는 애자일 개발 방법론 자체가 90년대 중반을 기점으로 한다고도 했지만 혹자는 2천년대라고도 한다. 기원의 시기가 언제가 되었든 그간에 어렵고 복잡했던 소프트웨어 개발 매뉴얼을 아주 가볍게 만들고자 했던 개발자들의 오랜 노하우들을 녹인 결과물이라고 봐야겠다. 심지어 '애자일 선언문'이라는 것도 존재하고 있었다.
※ '애자일 선언문'의 경우 내용이 길어지는 관계로 본문 하단에 따로 붙인다. 참고하시길!
애자일 방식에 대한 다른 예시로 자동차 제조사를 들어보자. 자동차 부품은 셀 수도 없을 만큼 다양하다. 최근에는 반도체 이슈까지 존재하고 있고 '반자율주행'을 가능하게 할 만큼 고사양의 부품이 들어가기도 한다. 어쨌든 다양한 2차, 3차 업체들로부터 부품을 제공받아 완성차가 나오기까지 공정 임무를 수행한다. 발주가 시작되면 완벽하게 굴러가는 완성차로 납품하는데 이러한 프로세스를 워터폴(Waterfall) 방식이라 한다. 여느 제조산업에서 볼법한 보편적 공정 프로세스라 하겠다. 생각해보면 기계적이고 단순하다. 정해진 틀 안에서 이뤄지니 생산속도 또한 빠를 것이다. 그러나 즉흥적 대응은 어려운 편에 속한다. 더구나 누군가의 참여 자체가 어렵다. 물론 개입할 순 있다. 그리고 그간의 프로세스를 뒤바꿀 수도 있겠지만 오랜 시간 정해진 틀이 한순간에 바뀌게 되면 상당한 것들이 소비되고 말 것이다. 그럼 이를 플렉시블(flexible) 하게 대응할 순 없을까? 그래서 생겨난 것이 바로 애자일이다. 누군가의 적극적인 참여에 따른 필요한 요구사항들을 유연하게 수용하고 효과적으로 대처할 수 있도록 만든 일종의 '맞춤형 프로세스'로 개발이 진행된다. 개발기간 자체가 워터폴 방식보다 오래 걸리더라도 생겨날 수 있는 리스크를 미연에 방지할 수 있게 된다. 그런데 애자일이라는 업무 방식에서 팀원들의 의견을 개입할 수 없도록 한다거나 충분히 존재해야 할 권한 자체를 앗아가는 순간 애자일이라는 개념 자체가 망가진다. 애자일은 프로세스의 방식이지만 어쨌든 사람이 하는 일이다.
유연한 개발방식, 애자일! 출처 : elvenite.se애자일이라는 어원의 의미와 소프트웨어 개발에 따른 개념을 넘어 '사무 환경 속에서 부서 간 혹은 팀 간의 경계는 물론 직급 체계 자체를 없애 팀원들에게 의사 권한을 부여하는 형태'의 업무 방식을 말하는데 위에서도 언급했듯, 셀 조직과 같이 소규모로 구성된 팀이 보다 빠른 커뮤니케이션과 효과적 결론 도출 나아가 기민하게 움직여 바로 실행에 옮기고 프로젝트를 완성하는 프로세스의 개념을 애자일 경영방식이라고 말한다. 국내외 IT 기업들이 이러한 애자일 경영방식을 채택해 실제 업무 환경에 도입하기도 했다. 디지털 혁신이라는 것 자체가 비즈니스와 기업 경영의 중심이 되어버린 것이다. 그도 그럴 것이 생산성을 높이고 상황에 따라 유연하게 대처할 수 있을 뿐 아니라 신속하게 결과물을 얻을 수 있으니 거부할 이유가 없지 않은가.
<어쨌든, 수평적인 애자일의 세계>
어떤 회사의 '경영'이라는 측면은 지극히 수직적인 빌딩 구조 같은 느낌이다. 저 아래 존재하는 직원들은 승진이나 보상을 위해 보이지 않는 경쟁을 하며 윗 단계로 오른다. 관리자는 직원들의 퍼포먼스를 평가하고 그 내용들을 또다시 자신들의 관리자인 C레벨에 보고한다. 꼭대기 층에 존재하는 C레벨의 커뮤니케이션은 하향식으로 이뤄진다. 높지만 결코 넓지 않은 고층빌딩의 경영 방식에서는 일방향 커뮤니케이션과 엄격한 통제 그리고 경쟁이 난무한다.
애자일의 세계는 위에서 언급했듯 수평적인 구조를 이룬다. 기본적으로 쌍방향 커뮤니케이션이 원활하게 이루어지는 모양새다. 보이지 않는 제한적 요소야 어느 정도 존재할 수 있겠지만 사원들의 퍼포먼스를 제대로 발휘할 수 있도록 '해방'시켜주는 것 역시 애자일이 추구하는 기본적 조직 문화다. '부장', '팀장'이라 적어두고 '님' 혹은 '프로' 혹은 애칭 따위로 부르며 직급을 무너뜨리는 것도 수평적인 문화를 지향하기에 가능한 것이다.
올바른 혁신을 이루기 위해서라면 시행착오는 반드시 필요하다. 작금의 시대에 존재하는 굵직한 플랫폼들 역시 작은 스타트업에서 하나의 브랜드로 거듭나기 위해 실험과 실패를 꾸준하게 학습해왔다고 볼 수 있다. 처음부터 완벽한 서비스는 없다. 애자일이 지향하는 지점 역시 새로운 것에 대한 다양한 실험과 도전이고 그 실험이 가능할 수 있도록 창조적인 환경을 만들어주는 것, 뿐만 아니라 상호 소통하고 독려할 수 있는 문화라는 것에 있다. 애자일이라는 것을 도입하고 적용한다고 해서 반드시 놀라운 퍼포먼스를 기록하는 것은 아니다. 기업이 발전하고 성장한다고 개런티 할 수도 없지만 쓸데없는 겉치레는 버리고 누군가의 역량을 가릴 수 있는 장막은 거둬내야 하지 않을까. 변화가 필요하다고 말하면서, 그리고 그것이 전통적인 것이라며 깨부수지 않으면 결국은 제자리에 머물거나 퇴보하게 될지도 모른다.
<덧붙임>
어느 일간지에서 다룬 '조직문화 세대교체'라는 기사가 눈에 띄어 잠시 읽어본 적이 있다. 90년대 조직은 폭력적 상사와 명령에 수긍하고 굴복하는 부하 결국 상명하복 조직 문화 속에서 생존하듯 살아남아야 했다고 하면서 '야생적인 맹수 문화'라고 언급했다. 2천년대에 이르면서 모두 일하는 기계가 된 듯 이른 시간에 출근하고 늦은 저녁 퇴근하는 루틴이 반복되면서 모든 결과물을 과정이 아닌 숫자로 증명하던 '(쉬지 않고 일하는) 벌꿀 문화'라고 전했다. <90년생이 온다>라는 책의 타이틀처럼 이제 직장에는 MZ세대가 다수 자리하고 있다. 시대가 흐르고 세대가 바뀌면서 피라미드형 수직적 문화도 점차 깨지고 있는 듯하다. 젊은 직원들의 목소리가 커져가고 있고 윗자리를 차지하고 계신 분들은 그들의 눈치를 본다고 적었다. 불만이 있으면 그대로 말하고 부당한 것에 목소리를 높이며 개선을 요구하는 행위들이 MZ세대라 가능하다고 했지만 그만큼 조직문화 또한 크게 바뀌었다고 볼 수 있다. 90년대의 조직문화와 비교하면 정말이지 확연하게 다른 모습이다.
※ 애자일 조직 문화를 너무 긍정적 요소만 부각한 듯 작성한 것 같아 한편으로는 우려스럽네요. 언젠가 '애자일을 너무 믿지 마세요'라고 쓸 수도 있습니다. 어쨌든 변화가 필요하다면 정말 필요하다고 생각하는 요소들은 지금 우리 환경에 적용해야 하지 않을까 싶어 너무 깊지 않은 수준으로 작성하였습니다.
※ 아래 사이트를 참고했습니다. 사실과 다르거나 잘못 이해하여 작성된 부분이 있다면 언제든지 조언 부탁드립니다.
- <Why do Managers hate Agile?>(2015.1.26), forbes.com
- 애자일선언문 : https://agilemanifesto.org/
<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.
여기서 Bold 처리한 것의 의미(선언문 원문상 폰트 크기가 크게 처리된 키워드)는 왼쪽 편에 언급한 '공정과 도구, 포괄적 문서, 계약 협상, 계획' 자체로도 가치가 있고 의미가 있지만 그보다 오른쪽에 존재하는 '개인과 상호작용, 소프트웨어, 고객과의 협력, 변화에 대응'이라는 것에 더욱 높은 가치를 둔다는 것이다. 애초에 영단어들을 직역에 가까울 정도로 해석한 내용이라 와닿지 않을 수 있겠다. 위 선언문 그리고 그에 따른 애자일 SW 개발 원칙은 아래와 같다. 아무래도 이 내용이 지금까지 언급한 애자일 조직이라던가 애자일 업무 방식에 대해 쉽게 이해할 수 있도록 도움을 줄 것 같다.
※ 애자일 소프트웨어 개발 원칙(일부 요약)
- 최우선 목표는 고객을 만족시키기 위해 가치 있는 소프트웨어를 신속하고 지속적으로 제공하는 것.
- 개발 후반에 새롭게 추가되는 니즈도 수용한다. 애자일 프로세스는 고객의 경쟁력을 위해 요구사항의 변경도 수용할 수 있어야 한다.
- 동작 가능한 소프트웨어를 짧으면 2주, 길면 2개월 간격으로 고객에게 전달하며 이 간격을 짧을수록 좋다.
- 프로젝트 진행 과정 동안 업무 담당자와 개발자 간 의견 공유가 매일 같이 이뤄져야 한다.
- 정보 전달을 위한 가장 효과적인 의사소통 방법은 직접 대면하고 대화하는 것이다.
- 진척 사항의 척도를 나타내는 가장 좋은 방법은 실행 가능한 소프트웨어를 보여주는 것.
- 최고의 아키텍처, 요구사항, 설계가 나올 수 있으려면 자율적 사고와 자유로운 분위기가 형성되어야 한다.
- 프로젝트의 효율성을 향상시키기 위해 개발팀 스스로 정기적인 미팅을 진행하여 자신들의 행동을 되돌아보고 조율하고 수정한다.
출처 : <쉽게 배우는 소프트웨어 공학>(2021.6.30), 한빛아카데미(김치수 교수)
