2016년 5월 6일 금요일

분석 #5 Coursera에서 소프트웨어 공학 최고의 스승을 만나보자


요즈음 교육 방법으로 매우 편리한 MOOC(Massive Open Online Course) 라는 방식이 있다. 언제 어디서나 원하는 강의를 들을 수 있는 온라인 강좌서비스인데 강좌 자료만 올려 놓는 가장 원시적인 것부터 실제 전세계 최고의 대학 강좌와 거의 비슷하게 체험할 수 있는 것까지 다양한 수준이 있다.

전세계 MOOC중에서 가장 유명한 사이트가 Coursera (https://www.coursera.org) 이다. Coursera 에서 가장 많이 듣는 강좌가 Stanford 교수인 Andrew Ng의 기계학습(Machine Learning) 코스이다. Andrew Ng 교수는 Coursera의 창시자이기도 하고 인공지능 분야의 대가 중의 한 명인데 얼마 전에 구글에서 바이두로 옮겨 인공지능의 책임자인 Chief Scientist로 있다. 이 강좌는 Stanford 대학원의 정규 코스이기도 하다.

필자가 수년 전에 Market Segmentation으로 Machine Learning을 했었는데 알파고의 홍보효과로 한국에서는 갑자기 대중에게 유행이 되었지만 이미 전세계에서 미래의 핵심 기술로 자리 잡은지 오래이다. 구글, 페이스북, 마이크로소프트, 애플, 바이두 등 전세계 모든 기업들이 사운을 걸고 엄청나게 투자를 하는 분야이다. 필자가 Stanford에 입학할 당시에는 인공지능의 실현 가능성에 문제가 제기되던 시절이라 전공으로 선택하지는 않았는데 그 후 30년이 흐르면서 많은 변화가 있었다. 특히 Geoffrey Hinton 교수의 획기적인 발견과 GPU 연산능력의 발전으로 과거의 문제들이 해결되면서 이제는 의심의 여지없이 미래 모든 산업의 핵심기술이 되었다.

필자도 이 기회에 여러가지 목적으로 Andrew Ng 교수의 Machine Learning 강좌를 들었다. 가장 큰 목적은 한국의 개발자들이 이 코스를 들을 때 직면할 문제점을 발견하고 조언을 하기 위해서 였다. 이전에 학생이었을 때 듣던 거의 유사한 교육 방식의 코스이기 때문에 필자는 전혀 거부감이나 당황감 없이 들을 수 있었다. 주중에는 시간이 없으므로 주말에 밤새우다시피 하면서 11주 코스를 6주만에 빨리 끝냈다. 하지만 쉽게 통과하기 쉽지 않은 코스라는 것을 밝혀둔다.

이 강좌의 가치는  Machine Learning을 배우는 것 이외에도 다음과 같은 3가지 혜택이 있다.

첫째, 대학 교육방법의 Role Model을 보여준다.
둘째, 실리콘밸리 회사에서 어떻게 일하는 지를 가르쳐 준다.
셋째, 분석이 무엇인지를 몸에서 느끼게 저절로 가르쳐 준다.

이 강좌를 듣는 방법에는 3가지가 있는데 첫째로 그냥 동영상 강의만 듣는 것이다. 즉 청강이다. Class당 1시간 20분 정도의 동영상 11개 이니까 동영상만 듣는다면 대충 15시간이면 끝난다. 둘째 방식은 가끔 나오는 Quiz를 이해하고 풀면서 듣는 것인데 강좌을 다시 듣고 잘 이해해야 하는 부분이 있으므로 조금 시간이 더 걸린다. 20시간으로 잡자. 거의 모든 개발자가 기초만 있으면 통과할 수 있는 수준이다. 마지막 셋째는 프로그래밍 숙제를 해야 하는 방식이다. 숙제를 모두 끝내야 Course Certificate을 발행해 준다. Certificate만 받지 않으면 모두 무료 강좌이다. 개발자의 수준에 따라 다르겠지만 필자의 경우에는 약 100시간 걸렸다. 시간으로 보면 Quiz까지 푸는 방식과 숙제까지 하는 방식에서 5배의 차이가 난다. 하지만 배우는 역량은 5배가 아니라 10배, 100배의 가치가 있다. 청강이나 Quiz를 푸는 방식으로는 진정으로 개발자가 배워야 하는 것은 전혀 배울 수 없다. 그냥 얉은 표면적인 지식만 임시적으로 쌓일 뿐이다. 즉 골프는 쳐보지도 않고 골프 동영상 강좌만 들은 것과 같다.

그럼 이 강좌의 Certificate을 받기 위한 과정에서 개발자들에게 어떤 중요한 가르침을 줄 수 있는지 보자. 핵심은 프로그래밍 숙제이다. 프로그래밍 숙제를 모두 통과하지 못한다면 이 코스를 완성했다고 인정할 수 없다. 훈수나 두는 잡다한 지식 수준이다. 그럼 프로그래밍 숙제가 어떻게 나오는 지를 살펴보자. 한국의 대학교수들이 꼭 배워야 할 점이기도 하다.

첫째, 모든 숙제의 설명이 양적으로 작은 책자처럼 나온다. 그것을 다 읽고 완전히 이해해야 한다. 한 부분이라도 이해하지 못한 상태에서 대충 어떻게 되겠지하고 숙제를 하려고 시작하면 고생은 고생대로 하고 시간이 더 든다. 여기서 개발자가 배워야 할 기본 원칙이 나온다. "무엇을 할 지를 모르면서는 코딩을 시작하지 말라"는 것이다. 백가지 이유를 들면서 일찌감치 코딩에 뛰어드는 한국의 통상적인 개발자는 아무리 얘기해도 실감하기 어려운 것인데 강좌를 들어보고 경험해 보면 백문이 불여일견이라고 이해가 갈 것이다. 즉 "코딩을 일찍 시작하면 개발시간이 더 걸린다" 는 소프트웨어 공학의 #1 원칙을 배울 기회이다. 폭포수모델이니 애자일 방법론과는 전혀 상관이 없는 기본 원칙이니 방법론과 착각하지 말기 바란다.

숙제가 정의되어 있는 상세함을 보면 무엇을 프로그램해야 하는 지 정확하게 정의되어 있다. 숙제 설명 중에 쓸데 없는 단어도 없고 모든 단어가 필요한 만큼 잘 사용되어 있다. 바로 "완벽한 SRS"인 것이다. SRS의 형식이 중요한 것이 아니라 문제를 정확히 정의하는 것을 확실히 볼 수 있다. 이 숙제 설명 중에 한 부분이라도 이해 없이 넘어가면 꼭 문제가 되고 결국 다시 와서 이해하기 전에는 숙제를 완성할 수 없다. 이런 식으로 매 과목마다 완벽한 SRS를 기반으로 숙제를 하고 교육을 받다 보면 SRS를 어떻게 작성해야 하는 것을 저절로 배우게 된다. 자신이 다른 사람에게 어떤 일을 부탁할 때나 개발 프로젝트 발주를 할 때도 그렇게 적어야 한다는 것이 몸에 배게 되는 것이다. 자신도 모르는 사이에 문제를 정의하는 방법, 즉 "분석" 능력을 배우게 된다.

문제를 정확히 정의하는 것과 창의성과는 전혀 별개의 문제이고 둘 다 모두 가장 중요한 개발자의 역량이지만 여기서는 창의성을 설명하지는 않는다. 정확히 정의된 문제 안에서 창의성을 발휘하는 것 정도로 알아 두자.. 불행히도 한국에는 이런 수준의 숙제를 디자인하고 만들수 있는 교수가 거의 없다. 학교에서 잘 가르쳐야 한다고 요구해야 정치교수, 관리교수들 처럼 실무 역량을 상실한 교수들에게는 이런 코스 디자인 역량이 있을 수 없고 공허한 메아리만 될 뿐이다.

또 중요한 것이 숙제를 채점하는 방식이다. 온라인 사이트로 숙제를 프로그램 채점기에 제출하면 즉시 자동으로 채점이 되어 나온다. 채점은 항목별로 Pass/Fail (통과/실패)로 나온다. 모든 항목을 100% Pass 해야만 숙제가 통과된다. 여기서 소프트웨어 개발 프로세스에서 나오는 Acceptance Test Plan(ATP, 인수테스트) 라고 하는 핵심 개념이 나온다. ATP만 통과하면 개발이 완료되고 계약은 종료된다. 발주시 미리 약속한 ATP만 통과하면 발주자가 어떤 트집도 잡을 수 없다. 이런 정교한 ATP가 없는 한국에서는 절대 경험해 볼 수 없는 것이다. 대학의 과목에서도 따라하는 소프트웨어 개발의 기본을 한국의 소프트웨어 업계에서는 한 번도 경험해 본 적이 없다는 것은 슬픈 현실이다. 그러면서 소프트웨어 공학을 논할 자격이 있는지도 의문이다.

프로그래밍 숙제의 내용에 대해 정확히 정의되어 있고, 채점도 Pass와 Fail이 자동으로 나온다. 무슨 편법을 사용하더라도 채점 프로그램만 통과하면 통과한 것이다. 하지만 하드코딩을 한다거나 편법으로 채점기를 속이는 것은 불가능하게 디자인 되어 있다. 프로그램을 제대로 하지 않는 이상은 절대 채점기를 통과할 수 없게 만들어져 있으니 시간 낭비 하지 말고 처음부터 제대로 하는 것이 현명하다. 여기서 주지할 것은 채점기가 얼마나 정교하게 잘 되어있는지도 중요하지만 더 중요한 것은 숙제 설명과 함께 동시에 채점기가 나온다는 것이다. 이것을 소프트웨어 산업에서 비교하자면 숙제의 정의는 SRS이고 채점기는 ATP (인수테스트)인 것이다. 소프트웨어 공학에서 당연하게 SRS와 ATP(인수 테스트)가 동시에 나오는 기본 원칙을 보여주는 것이다. SRS와 ATP 있어야만 합리적이고 정상적인 개발 계약이 가능하다. 이런 기본적인 프로세스를 한 번도 해 본 적이 없다는 것은 한국 소프트웨어 업계의 실체와 수준을 적나라하게 보여준다.

한국에서의 프로젝트 발주와 수주의 기본 프로세스인 "RFP (제안 요청서) -> Proposal(제안서) -> 우선협상대상자 계약 -> 개발범위 논의 -> 등등" 의 어디에서 과연 내가 돈을 주고 발주를 하든 돈을 받고 수주계약을 하던 계약 전에 무엇을 개발하는 지와 인수테스트를 정확히 알 수 있는 시점이 없다는 점이다. 무슨 근거로 애초에 이런 개발방식이 생겨났는지는 안타까운 과거의 행위이지만 앞으로 한국 소프트웨어 업계가 넘어가야할 가장 큰 장애물이다. 하여튼 이 잘못된 관행은 프로젝트 규모의 문제가 아니라 기본이 안 되어 있기 때문인 것이다. 규모가 크기 때문에 학교의 과목보다도 더 정확히 하지 않으면 재앙은 더 커진다.

마지막으로 말하고 싶은 것은 이 과목에서는 Matlab 이라는 프로그래밍 언어를 사용한다. 필자는 이 전에 한 번도 Matlab을 사용해 본 적이 없다. 하지만 배워서 이 숙제를 해야 한다. 강좌에서도 한 30분 정도 가르쳐 준다. 다른 과목에서는 Python으로 숙제를 해야 한다. 이 역시 학생들이 알아서 배워야 한다. 이런 프로그래밍 언어는 학원에서는 가르칠지 모르지만 학교에서 귀중한 학점을 낭비하면서 따로 가르치지는 않는다. 중요한 것은 문제해결 능력이지 프로그래밍 언어의 Syntax가 아니기 때문이다. 이런 Syntax를 가르칠 만큼 한가한 학교라면 그 학교에서는 많은 것을 배우지 못할 것이다. 한국 개발자의 이력서에 빼곡히 적힌 프로그래밍 언어 목록에 대해 필자는 그렇게 가치를 두지 않는다. 실리콘밸리에서 개발자를 뽑을 때도 그랬고 지금도 그렇다. 이런 모든 상황 때문에 한 학기에 프로그래밍이 숙제로 있는 코스를 1개 이상 수강한다는 것은 거의 사생활을 포기한 것이나 다름 없다. 그래서 전산학을 하면서 Full-time 학점인 학기당 12학점 이상을 듣는다는 것도 거의 불가능하다.


이 강좌 하나에 한국의 정부, 학교, 회사, 개발자등 소프트웨어 업계가 배워야 하는 Role Model이 모두 들어 있다. 과연 이런 강좌를 한국에서 언제 보게 될 수 있을 지가 궁금하다. 그 때가 아마 한국의 소프트웨어 업계가 진정으로 소프트웨어를 이해하는 시점이고 글로벌 소프트웨어를 위해 나갈 수 있는 시작점이라고 본다. 그 때까지는 한국의 갈라파고스 섬에서 자화자찬하며 살아갈 것이다.

미래의 핵심 역량인 Machine Learning을 배우면서 추가로 소프트웨어 공학의 핵심을 저절로 배우는 기회를 위해 필자가 개발자들에게 꼭 추천하는 강좌이다.