[KT 특강] 1014_Agile론 특강

오늘은 교육이 진행되는 과정에서 Agile에 대한 특강을 듣게 되었다.

평소 Agile은 학교에서 강의를 들었을 때, 취업 준비하면서 정보를 얻을 때 몇 번 듣기만 했지, 정확한 Agile에 대한 이해는 하지 못 했었는데 좋은 경험이 될 것 같다.

우선 Agile의 공 패스 게임으로 방법론에 있어 효율성을 실감해보았다.

여러 명의 조원이서, 8개의 공을 3가지 방법으로 전달하는 방법이었다. 1명이 8개를 전달하는 것이 끝나면 그 다음 사람이 또 8개를 전달하고.. 그런 방식으로 8개씩 / 4개씩 / 2개씩 전달하는 게임을 해보았다.

아무 생각 없이 게임에 임했다면, 그저 지루하다고 생각했을수도 있지만 내가 이후에 취업을 하고 사회에서 팀원이라는 생각으로 임했을 땐 한 번에 전달하는 공의 개수가 적어짐에 따라 효율성을 절감할 수 있었다.

Agile이 추구하는 바가 그만큼 빠른 시도와 실패를 통한 개선이라는 점을 잠깐이나마 느낄 수 있었다. 

정확히 의미를 알고 싶어서 구글에 Agile의 정의에 대해서 찾아봤더니,

 

 

정해진 계획만 따르기 보다 개발 주기 혹은 소프트웨어 개발 환경에 따라 유연하게 대처하는 방식

 

 

이런 정의를 도출해낼 수 있었다.

 

과거 라이트 형제와 더불어 사무엘 랭글리라는 박사도 유인 동력기를 만들기 위해서 노력했다고 한다. 

하지만 우리가 라이트 형제만 아는 이유는, 그들은 빠른 실패를 경험하고 다양하고 반복적인 시도를 통해서 4년만에 성공을 했기 때문이다.

사무엘 랭글리 박사는 정부 지원도 받고, 실패를 하지 않으려 엄격하게 연구를 해온 결과 17년동안 연구를 하고도 결국 어떠한 결과도 얻어내지 못했다고 한다.

그만큼 Agile이 결과를 얻어낼 때는 기존의 Waterfall 방식보다 효과적이라는 것이다.

이러한 Agile은 소프트웨어 개발 방식에서 처음 나왔다고 한다.

여러 프로젝트를 진행하고 산출물을 뽑아내는 IT 조직에게 Agile화는 중요했고, 이러한 방식이 이제는 IT에 국한되지 않고 여러 기업들에 녹아들어 효율적인 조직 체계와 의사결정 권리를 분배해서 수평적인 소통을 통한 협업으로 만족할 만한 결과물을 얻어내는 것이 트렌드이다.

Agile 조직 모델을 적용한 기업 사례로 현대 카드 / 캐피탈에 관한 영상을 보았다. 하루만에 팀을 옮기고, 기존 조직 체계를 변경해서 유기적으로 프로젝트 단위로 팀을 만들고 일을 한다. 

 

조직이 일을 만드는 것이 아니라, 일이 조직을 만든다.

 

영상 중에 이 문장이 가장 와닿았다. 단순히 조직이 시키는 업무, Waterfall 형식으로 업무를 진행하는 것이 아니라 유기적으로 조직을 구성해 필요한 프로젝트에 필요한 인원을 구성하고 효율적으로 업무를 진행하는 점이  논리적으로 설득할 만한 점이었다.

이외에도 Netflix의 분기별 계획 수립 및 피드백 관리, Spotify의 Agile 조직 문화에서 음악 추천 서비스를 만들어 결국 스트리밍 점유율 1위를 달성할 수 있었던 배경.

 

결국 상호작용, 포괄적인 문서보다는 동적인 결과물, 고객과의 협력, 변화에 민첩하고 유연하게 대응하는 것. 이것이 가장 중요한 Agile의 핵심가치 4가지이다.

 

Agile에는 여러 조직 형태가 있는데, 오늘은 Scrum에 대해 배웠다.

Scrum은 럭비에서 개개인이 팀이 되어 밀집하여 뭉치는 형태를 의미하는데, 정확히 해당 용어가 왜 여기에 쓰였는지는 알 수 없다고 한다.

Scurm의 5대 가치관에는,

 

1. 팀의 모든 일과 상황에 대해 공유

2. 팀원 간 서로 존중하는 것

3. 옳은 일을 위해 어려운 것에도 도전할 수 있는 용기

4. 팀의 목표와 작업에 집중

5. 약속한 것을 확실히 실현하는 것

 

 

이렇게 5가지가 있다. 

물론 기본적으로 해당 5가지의 가치관이 중요하지만, 몇몇 항목들은 기존의 상황에서 실제로 구현되기는 어려운 부분이 있을 것이다.

그렇다 하더라도, 더 나은 결과물을 만들어 내고 효율적으로 기업 문화를 만들어가는데 있어 이러한 부분이 적용이 되는 것이 중요할 것이라고 생각한다. 

 

이를 기업에 적용시켜 실제로 생각을 해보자.

예를 들어, 기업이 자동차를 만든다고 했을 때 최종 소비자는 자동차를 구매할 고객이다.

해당 고객이 원하는 것은 SUV였지만, 고객과의 피드백 없이 제품을 만든다면 해당 제품은 고객에게 선택받지 못 할 것이고 기업의 수명 가치는 줄어들 것이다.

많은 경쟁 속에서 살고 있는 우리들로서, 고객의 피드백을 단계별로 받아 개선해나가면서 제품을 만든다면 소비자도 만족하고, 소비자가 해당 제품을 선택함으로서 기업도 행복할 것이다.

여기서 단계마다 피드백을 받는다고 했는데, 크게는 이 단계를 Sprint라고 표현을 한다고 이해를 했다.

스크럼을 짜서 프로덕트 백로그를 진행하고, 스프린트를 계획하고 스프린트 백로그를 진행한다. 이 스프린트를 실행하면서 매일 스크럼을 진행하고 프로덕트 인크리먼트를 거쳐 리뷰를 하고 회고를 하는 방식이다. 이러한 사이클이 모여서 개발이 완성이 된다.

이러한 과정을 직접 조를 짜서 'Mural'이라는 툴을 이용해 함께 도시 계획을 세워보는 시간을 가졌다.

직접 내가 시뮬레이션을 해보고, 조원이 되어 직접 함께 참여를 해보니까 좋은 점, 아쉬운 점을 조금이나마 느낄 수 있었던 것 같다. 다만 아쉬운 점은 온라인이라서 그 효과가 조금 덜 하지 않았나 싶다.

 

그래도 매일 코딩, 머신러닝에 쫓기는 교육을 듣다가 이런 교육을 들으면 조금 마음도 편하고 쉬어가는 느낌이라 좋은 것 같다.