[HRD Trend] Learning Design Agile

오늘 모임에서 이야기 나눈 주제 중 하나가 ATD에 참석해봤나는 것이였다. 일반적으로 기업이나 공공기관에서는 해마다 ATD를 할때 우수 인재들 혹은 기관과 연계되어 있는 인력들으 ATD에 보내곤 한다. 하지만 실상 영어가 완벽하게 구사되지 않는 이상에야 ATD에 간들 무엇을 배울 수 있을까? 내가 생각하기에 국내에서 진행하는 수많은 HRD 포럼 같은 곳을 다녀와도 비슷한 인사이트는 얻을 수 있을 것 같은데 말이다.

각설하고 지금까지 다루고 있는 것은 ATD에서 발표했던 디브리핑 주제들을 기반으로 이야기 하고 있는 것이다. 확실히 2016년과 비교해 봤을때 상당히 많은 부분이 바뀌었다는 것을 인지할 수 있다. 다만 그것이 새로운 학습 형태이기 보다 형태나 도구의 활용도를 좀 더 중점적으로 다루고 있다는 것이 다른 부분이라고 생각한다.

오늘은 어제에 이어 학습전이와 관련된 이론이 아닌 실질적으로 교육담당자가 가장 많이 사용해야 하는 과정개발의 영역을 함께 이야기 하고자 한다. 물혼 나는 실제 ATD현장을 살펴보지 않았기 때문에 디브리핑에 참석한 수많은 저명한 교수들이나 전문가들이 이야기하는 것을 되새김 할 뿐이지만 나 나름대로의 인사이트를 이야기 하고자 하니 맞지 않고나 의미가 불분명한 사항이 있어도 너그러이 용서해 주길 바랄 뿐이다.

흔히 기존의 과정개발의 형태를 살펴보면 조사분석과 과정설계에 엄청난 시간을 투여하는 것이 사실이다. 그 이유는 실질적으로 학습자들이 필요로 하는 궁금증과 이슈가 무엇인지를 파악하기 위함이다. 나 또한 수박 겉 핧기 보다는 궁극적으로 사업이슈와 현장에서의 어려움을 극복하기 위한 방법론으로 구체적인 ADDIE 모형을 이용할 것을 주장해 왔다. 헌데 앞에서도 이야기 했지만 아무리 앞단에서 학습의 목표와 궁극적으로 바라는 산출물을 위해 과정을 기획하고 설계한다는 것은 많은 어려움이 있는 것도 사실이다. 실질적으로 잘 운영이 되지 않을 뿐더러 산출물 또한 기대치에 미치지 못하는 것이 현실이다.

그래서 2017 ATD에서는 기존의 ADDIE모형을 대신한 Agile 모형을 제시했다. 간단히 이야기 하자만 방법론적으로 서두의 다양한 조사 방법론 대신 수시로 이슈를 발굴하고 이를 반영하여 과정을 개발하라는 의미이다. 다만 이는 HRD 고유의 영역이기 보단 소프트웨어를 개발하기 위한 방법론에 조금더 가깝다.

기존의 ADDIE 모형은 여하튼 오래 걸린다. 이유를 찾아야 되기 때문이다. 생각해보면 당연한 것이 아닌가? 비싼 비용을 들여서 과정을 개발하는데 단기간에 개발을 한다는 것은 "대충하겠습니다"와 일맥상통하는 의미이다. 그러니 기본적으로 본질은 무엇이고 이를 해결하기 위해서는 이런 교육 프로그램을 만들어야 합니다. 라고 이야기 하는 것이 일반적이다. 하지만 앞서 이야기 했던 것과 같이 마이크로 러닝과 개인학습화와 관련된 이슈들이 나오는 이유들은 기존의 학습 방법론이 잘못되어 있다고 지적하는 부분인 것이다. 사실 그것이 맞기도 하지만 틀리기도 하다. 그래서 지금부터 제대로 이야기를 해보려 한다.

ADDIE 모형이 과연 잘못된 이론일까?

 

Waterfall 방법론

폭포수 방법은 1950년대에 처음 언급된 소프트웨어 개발의 표준 방법론이다. 미리 정해진 몇 개의 단계에 따라 엄격한 순서대로 이루어지는 일직선의 과정인것이다. 이는 제조업과 건설업에서 이러한 구조화 된 방식에 따라 효과적으로 일을 해왔기 때문에, 소프트웨어와 웹 개발에도 적용될 수 있다고 여겨져 왔다.

 

 

폭포수 방법은 확실하고 명확한 계획으로 시작되어, 각각의 엄격하게 기록된 단계를 통해서 매우 밀접하게 진행이 된다. 단계는 겹치지 않고, 다음 단계로 넘어가기 전에 완벽하게 완료되어야 하고, 또한, 프로젝트가 제대로 진행되는지 매 단계 후에 검토해야 한다. 결국 제품 테스트는 모든 개발이 완료된 후에 이루어져야 한다는 말이다. 하지만 시간과 돈을 더 투자하지 않는 이상 중간에 바꿀 수 없기 때문에 이 방법을 이용한다면 대담하게 비용을 투자해야 한다. 폭포수 방법론은 자신이 원하는 것을 정확히 알고 있으며, 개발 과정 중에 사소한 것을 바꾸지 않을 고객들에게 좋은 선택인 것이다. 상세한 문서와 엄중한 계획 때문에 프로젝트 관리는 명확하고, 최종 제품은 미리 정해진 계획표와 예산액에 맞추어져 있는 것이다. 이게 기존의 ADDIE 모형을 설명하는 기본적인 바탕이다. 결국 시간과 비용이 많이 들어간다는 것을 의미한다.

폭포수 방법론의 장점

1. 프로젝트를 시작하기 전에 프로젝트의 범위, 비용, 타임라인에 대해 자세하게 알 수 있다. 또한 예상하는 것과 비슷하게 만들 수 있습다. 까다로운 계획 때문에 각각의 개발자들이 다른 부분에서 일을 하기 때문에 더 쉽게 프로젝트 관리를 할 수 있다. 단계별 개발은 규율을 시행하고, 중요한 단계들은 확인되고 관찰이 되고, 빠듯한 기한이 없거나 필수 조건들이 적은 작은 프로젝트에 적합하다고 할 수 있다.

 

 

애자일 방법론

애자일 방법론은 1970년 대에 발표되었다. 소프트웨어 개발은 제조업의 조립라인 처럼이 아닌, 점진적인 방법으로 진행해야 한다고 주장되었고, 소프트웨어를 길고 연속된 단계로 개발하는 방법 대신에, 애자일은 스프린트라는 단계로 이루어졌다. 이러한 반복적인 일의 흐름은 개발 팀이 프로젝트의 방향을 몇 주마다 검토할 수 있게 해주며, 동시에 버그를 고치고, 필요한 것을 바꾸며, 그에 따라 개발을 다시 진행할 수 있게 해주었다.

애자일 방법론은 2001년에 Manifesto for Agile Software Development에 정의되었다. 12개의 원칙 선언은 가벼운 개발 방법을 통한 고객과의 협력을 강조하고, 과정과 도구 보다는 개인과 상호작용을 더 중요시하며, 계획을 따르는 것보다 변화에 대처하는 것을 보여주었다. 애자일 선언문은 고객 개입과 넓은 개발자 팀워크를 강조하며 인간적인 요소를 더해 소프트웨어 개발 방법의 전환점이 되었다. 폭포수 방법론은 필수 요소에 의해 진행이 되기 때문에 내향성을 띠고 있는 반면, 애자일 방법은 외향적인 방법이라는 것을 알 수 있다. 당연히 이러한 독특한 특징들은 많은 개발자들과 그 고객들에게 개발 결과나 흐름을 바꿔놓을 수 있었다.

 

애자일 방법론의 장점

1. 물론 프로젝트 진행 중간 중간에 필요한 요소들을 바꿀 수 있다. 또한 시작할 때 프로젝트를 정확하게 규정하지 않아도 된다. 이는 작은 요소들을 출시 할 때 빠르게 만들 수 있기 때문이다. 게다가 점진적으로 테스트되기 때문에 초기에 버그를 발견할 수 있다

자 여기서 질문이다. 그렇다면 우리는 Agile 방법론으로 과정을 개발하면 될까? 내가 기껏 Ctrl + C 하여 긁어온 글을 보면서 이상한 생각이 들지 않는가?

 

결론부터 이야기 하자면 Agile 방법론은 마이크로 러닝과 비슷하다고 생각한다. 실질적으로 학습이 유기적으로 연계 될 수 있도록 과정 과정마다 실제 도입하고 개선점을 도출해서 아웃풋을 내자는 이야기인데 이게 실제 잘 적용되지 않는다. 그 이유는 우리 대한민국의 기업들은 단기간의 성과를 도출해 내길 원하지 현장에서 바빠서 허우적 거리는 사람들을 중간중간 끊어서 교육시키는 걸 극도로 혐오하기 때문이다. 게다가 이렇게 교육을 하기 위해서는 시스템이 갖추어져야 하는데 이것 또한 쉽지 않다.

 

다만 Waterfall 방법론 즉, 기존의 ADDIE 모형이 맞다는 이야기를 하려는 것도 아니다. 누가 조사분석에 2~3개월을 쏟아 가면서 과정을 개발하기 원하겠는가? 비용도 그렇고 당장에 해결해야하는 이슈인데 말이다. 결국 중요한 것은 학습자들이 스스로 학습을 한다면 쉽게 해결된 문제인데 이게 쉽지 않기 때문에 자꾸 문제가 생기는 것이고 다양한 이론들이 발생되는게 아닌가 싶다.

기존의 Waterfall 방법론이 아닌 Agile 방법론을 제기한 것은 매우 훌륭한 발상이라고 할 수 있다. 왜냐하면 문제시 되는 것을 어떻게 하면 풀어갈것인지에 대한 고민이기 때문이다. 다만 무작정 ATD 디브리핑에서 발표했다고 해서 그것을 맹신하고 따라 하는 것이 문제인것이다. 실제 우리 환경과 상황에 맞는지 고민한 후에 적절한 해결점을 반영해 나가는 것이 중요한데 그게 아니라 무작적 이론이고 트렌드이기 때문에 반영하는 것은 교육받은 형태를 그대로 적용하는 것 밖에는 되지 않는다. 우리는 배움을 통해 성장 하는 HRDer인데도 말이다.  

Agile 모델적용사례