Lucy Park

지난 봄학기, 데이터 사이언스 입문 과목인 Data Mining과 한 학기 동안 실제로 데이터마이닝 프로젝트를 수행하는 Business Analytics 를 강의할 기회가 주어졌다.

강의한다는 소식을 듣고 몇 분은 학계에 남을거냐는 질문을 주셨고 커리어패스 측면에서 그것은 아주 자연스러운 질문이지만, 사실 나는 졸업 후 큰 회사든 작은 회사든 산업계로 가고 싶다는 생각을 하고 있다. 졸업 후 학계에 남고 싶은 마음이 컸다면 오히려 진행 중인 연구에 집중하기 위해 이 일은 고사했을 것 같다. 하지만 새로운 경험은 대체로 나를 크게 성장시켜주기 때문에 이 일도 내게 그런 기회일거라 생각했다.

그런데 박사 초년 시절 지도교수님의 조교 역할을 일 년간 하고, 한 두 시간에 걸친 짤막한 튜토리얼 해본게 전부인 나로서는 과목 하나를 통째를 맡는다는게 사실은 꽤 부담스럽고 긴장되는 일이기도 했다. 다만 내가 정말 좋아하고 존경하는 선배님의 제안이었고, 학생들의 눈높이에 맞는 수업을 할 수 있을거라는 자신감도 있었고, 나 또한 수업을 준비하면서 많이 배울 것 같다는 생각이 들어서 하게 되었다. 그리고 실제로도 많이 배웠다. 당초 예상했던대로 데이터 분석이라는 영역에 대한 이해도 어느 정도 깊어졌다고도 생각하지만, 사실은 그 외의 것들을 훨씬 다양하게 배운 것 같다.

시간이 더 지나기 전에 내가 얻은 크고 작은 배움들을 기록하는 것이 의미있을거라 생각해서 느낀 바를 정리해보았다.쓰다보니 제법 긴 글이 되어버렸다만 비슷한 경험을 할/하고 있는 다른 누군가에게도 도움이 될 수 있었으면 하는 마음과 그 분들이 가르칠 학생들이 더 나은 강의를 듣게 되었으면 좋겠다는 마음으로 내가 겪은 시행착오와 배움에 대한 글을 세상에 내놓는다.

1. 배움 1. Less is more.
2. 배움 2. Mutual motivation is important.
3. 배움 3. Getting feedback needs effort.
4. 배움 4. Encouraging class participation is difficult, even more than you expect.
5. 배움 5. 가르치는 법도 배워야 한다.
6. 배움 6. 데이터 사이언스 강의에서 프로그래밍이 필수적이지는 않다.
7. 배움 7+: 그 외의 것들

배움 1. Less is more.

아무래도 처음 수업을 맡은 학기였기 때문에 커리큘럼부터 시작해서 강의자료 준비까지, 엄청난 의욕에 불타올라서 열심히 준비했다. 게다가 학생들에게 전달해주고 싶은 내용이 한두가지가 아니었다. 내가 수업을 들을 때 배웠던 것은 물론이고, 그 때 배우지 못해서 아쉬웠던 것들까지 커리큘럼에 넣고 싶었다. 학생들이 나중에 어디가서 “입데마”하지 않기 위해서는 당연히 실습도 중요한 portion을 차지해야 했다.

하지만 (당연하게도) 내가 다루고 싶은만큼 많은 내용을 다루기에는 나에게 할당된 수업 시간이 부족했다. 가령 데이터마이닝 수업의 경우, 나는 내가 데이터마이닝 시간에 배웠던 것 중 multiple linear regression, logistic regression, decision trees, k-NN, k-means, hierarchical clustering, market basket analysis, neural networks을 넣고, 내가 중요하다고 생각하는 SVM, data visualization, distributed systems, 그리고 text mining 등을 추가해서 각 항목을 거의 동등한 비중으로 다루기로 했다. (물론 국내외의 많은 대학들의 데이터마이닝 수업도 대체로 비슷한 병렬적인 모양새여서, 내가 커리큘럼을 독창적으로 짰다기보다는 오히려 “내가 배웠던대로” 안전한 방식을 취하고 약간의 variation을 준 것에 가깝다.)

그런데 학기의 중반쯤 깨달았던 것은, 이 조차도 범위가 너무 넓다는 것이다. 이유는 다음과 같다:

1. 모든 것이 겉핥기가 된다.

   사실 linear regression (LR) 하나만 한다고 해도, 단순히 regressor과 regressand의 관계를 이해하는 것을 넘어서는 practical한 문제가 아주 많다. Normalization을 해야하는가? 계수로 변수의 중요도를 알 수 있는가? (또는 중요한 변수를 판별할 수 있는가?) 변수가 레코드 수보다 너무 많을 때는 어떻게 하는가? 불필요한 변수가 너무 많다면 regularization이 낫나 변수 선택이 낫나? L1, L2 regularization이란 무엇인가? LR을 분류 문제에 적용할 수 있는가? 실제로 학습은 어떻게 되는가? Stochastic gradient descent에 어떤 장단점이 있는가? 등등. 하지만 독립변수와 종속변수에 대해 이제 처음 들었고, 때로는 함수의 역할이나 정의도 아리송해하는 학생들에게 그런 내용을 한두시간 안에 전달하려는 것은 과욕이고, 결국엔 피상적인 내용의 전달과 이해에 그치게 된다.

2. 병렬적 나열은 정작 중요한 것을 놓치게 한다.

   서비스 개발을 할 때 사용자들이 중요한 기능을 놓치지 않도록 핵심을 강조하는 디자인을 하는 것이 중요하듯, 수업 역시 학생들이 학기가 끝난 후 다른 모든 것은 잊더라도 과목의 핵심적인 내용은 습득해갈 수 있도록 디자인하는 것이 좋다. 실제로 데이터 분석을 할 때는 data cleaning 등 전처리는 작업 시간 중 어마어마한 비중이 투자되고, data exploration은 좋은 분석 결과를 내기 위해 필수적인 단계이며, parameter selection은 가장 challenging하고 expertise가 필요한 부분인데, 커리큘럼에서 알고리즘을 주욱 나열하고 나면 아무리 그 부분들에 대한 중요성을 강조해도 그것이 충분히 전달되지 못할 수 있다.

3. 가르치는 사람의 마음을 급하게 한다.

   1번과도 이어지는 내용이지만, 시간이라는 자원은 한정적이기 때문에 전달할 수 있는 내용도 한정적이다. 제약조건을 초과하는 내용을 전달하려다보면 학생들이 얼마나 이해했는지 덜 확인하게 되고, 강사의 말은 빨라지고, 오히려 학생들의 지식 수용율은 떨어진다는 것을 깨달았다. 다음은 내가 linear regression 수업을 신나게 하고나서 받은 피드백이었다:

   • 내용설명을 해주실때 조금 빨라서 필기하거나 이해하는데 조금 어려움이 있었습니다.
   • 제가 컴퓨터를 잘못해서 개인적인 바람이지만 python하실 때 속도 조금만 더 느리게 해주셨으면 좋겠습니다ㅠㅠ! 감사합니다.

   커리큘럼 맞추겠다고, 혹은 알고리즘 하나를 더 가르치겠다고 서둘러 진도를 빼는 것은 가장 어리석은 방법인듯하다.

“조금이 더 많다(less is more)” 전략을 택하면 실력 편차가 있는 군집 내에서도 내용에 대한 이해의 깊이는 달라지더라도 같은 주제에 대한 문제의식의 공유가 가능해진다.

내가 들었던 수업 중 less is more 정신이 가장 뚜렷하게 반영된 수업은 문병로 교수님의 유전 알고리즘 수업이었는데, 그 수업은 한 학기 내내 알고리즘 하나만 공부하며 그것을 최적화해 나가는 방법을 배운다. 뭣도 모르던 시절에 들었던거라 성적은 형편 없었지만 가장 기억에 남는 명강의 중 하나이고,¹ 아무리 바보여도 “유전자 알고리즘이 아니라 유전 알고리즘이다!”라고 하는 교수님의 말씀만큼은 기억에 확실히 남았다.

아마 수업을 또 하게 된다면, 나는 같은 방식의 병렬적인 커리큘럼을 쓰지는 않을 것 같다. 수많은 알고리즘과 그들의 변종을 “다” 알려주는 것은 어차피 불가능하다. 시간도 부족하고 내가 그것들을 모두 제대로 알기도 어려울 것이다. 그렇다면 이제, 덜 가르친다면 무엇을 가르칠 것이냐의 문제가 남는다. 또 기회가 있다면 나는 내가 데이터 마이닝이라는 분야에서 더 잘 아는 분야, 즉 내 세부적인 전공 분야에 더 focus해서 가르칠 것 같다. 두 가지 이유에서인데, 내 스스로 보다 재미있게 얘기를 들려줄 수 있을 뿐더러 어차피 이 학생들이 훗날 연구자가 된다면 나와 협력자가 될 가능성이 많기 때문이다.

내가 종종 인용하는 글 Teach Yourself Programming in Ten Years에서 Peter Norvig은 “어떤 OS를 써야할까요?”라는 질문에 대해 “뭐든 상관없으니 친구들이 쓰는걸 쓰세요.”라고 한다.

When asked “what operating system should I use, Windows, Unix, or Mac?”, my answer is usually: “use whatever your friends use.” The advantage you get from learning from your friends will offset any intrinsic difference between OS, or between programming languages.

수업과 연구 분야도 마찬가지가 아닐까. 옆 친구와 옆 연구실, 선생과 학생은 서로 잠재적 동료이고, 가장 많은 것을 배우고 가르칠 수 있는 관계이다.

배움 2. Mutual motivation is important.

강의실에서의 motivation은 상당히 중요하다. 그렇지 않으면 선생, 학생 모두에게 시간 낭비가 되니까.

예시를 보여주거나, 동영상을 보여주는 등 학생들의 흥미를 돋구는 방법은 아주 많지만, 이번에 느낀 것은 단 5분이라도 문제에 대해 직접 생각해볼 수 있는 시간이 필요하다는 것이다. 그 과정이 없으면 “주입식 교육”이 되기 쉽다. 즉, 알고리즘의 목적과 방법론, 효과, 장단점을 일방적으로 전달하기보다는 (알고리즘이 해결하는) 문제를 하나 던져 주고, 먼저 그 문제가 왜 문제인지, 왜 풀어야하는 문제인지를 고민해본 후 그 문제를 어떻게 풀 수 있을까를 스스로 고민하는 과정이 있는 것이 좋은 것 같다. 만일 그 이후에 해당 알고리즘의 태동과 발전 과정을 보여준다면 한 수업이 마치 한 편의 드라마를 보듯 흥미진진하지 않을까.

내가 생각하는 좋은 알고리즘 수업 방식:

1. Teaser로 시작: 이런 문제가 있어. 이게 왜 문제일까? 너희들은 어떻게 풀어볼래?²
2. 이 수업이 커리큘럼 상에서 어디쯤에 위치해있는지 보여주기 (큰 그림 보여주기)
3. 문제를 해결할 수 있는 가장 간단한 방법 전달 (실제로 학생들이 생각한 접근과 비슷할 것임)
4. 하지만 거기에는 A와 같은 문제가 있어서, 많은 사람들이 연구하고 개선해서 2015년에는 B와 같은 수준이 되었다
5. 수업 끝에 오늘 다룬 내용 요약

이 중에서 4번 항목에 관해 한 마디를 덧붙이자면, 학생들은 문제에 “답” 내지는 “정해진 공식”이 정해져 있다고 생각하는 경우가 많았다. 예를 들어, 텍스트 분석을 할 때 “TF-IDF에 대한 공식이 뭔가요? 강의자료와 외부자료의 공식이 다른데 어떤걸로 공부하면 되나요?”라는 질문이 있었다.

실제로 TF-IDF는 처음 제안되었던 지표 외에도 수많은 variant가 있다. 그것에 대해 수업 중 긴 시간을 할애해서, 다음과 같은 얘기를 해줬다. 과학에 관한 한 “정답”은 존재하지 않는다. 흔히들 “기술은 발전한다”고 하는데, 기술이 발전한다는 것 자체가 여러분이 알고 있는 “어제의 최상의 해결법”이 개선되었다는 것을 의미한다. 그리고 그렇게 발전시키는 것은 여러분이다. 따라서 여러분도 여기서 알고리즘을 배울 때 그것의 정답(알고리즘의 현재)이 뭔지 알려고 하기보다는 그것의 단점이 무엇인지 찾고, 어떻게 개선할 수 있을지(알고리즘의 미래) 생각해봤으면 좋겠다.

한편, 반드시 선생만 학생을 motivate시켜야하는 것은 아니라는 것도 배웠다. 학생도 얼마든지 선생을 motivate 시킬 수 있다. 학생들의 열정은 선생에게 큰 힘이 되고, 하나라도 더 가르쳐주고 싶다는 원동력이 된다는 것을 배웠다. 이광근 교수님께서도 최근 저술하신 컴퓨터 과학이 여는 세계에서 이 같은 생각을 말씀하셨다:

강의실 학생들의 반짝이는 눈빛은 내겐 큰 은전이었다. 항상 그들의 시선을 북돋아주는 것으로 답하고 싶었다. 학생들이 던진 질문들이 나를 어떻게 공부시켰는지. 그들은 상상하지 못할 것이다.

간혹, 학생들로부터 선생들의 열정이 부족한 것 같다는 얘기를 들었다. 그런데 학생들도 선생이 열정이 가질 수 있게 할 수 있다. 좋은 강의를 듣고 싶다면, 선생들을 신나게 해주자.

배움 3. Getting feedback needs effort.

수업을 매학기 수개의 강의를 하시는 교수님들은 경험이 많아 문제가 없으시겠지만, 단 한 학기, 두 과목만 담당하게 된 내 입장에서 가장 먼저 만난 어려움은 콜드 스타트(cold start)였다. 강의든 세미나든 가장 중요한 것은 청중에 대한 지식을 가지고 그들에게 맞춤형으로 내용을 전달해야한다는 것인데, 나는 학생들에 대한 사전 지식이 거의 전무했다. 그래서 학생들에 대한 정보를 그 때 그 때 최대한 얻으려는 방식으로 문제를 극복하려 했다. 일단 수업과 별개로 첫 시간에 학생들에게 자기 소개서를 제출해달라고 부탁했고, 원래는 학기 말에 하는 강의평가를 매 수업이 끝날 때마다 진행했다.

매 수업이 끝난 후 두 가지 질문을 꾸준히 물었다:

1. 수업 수준이 어땠나요? (5점 스케일의 리커트 척도)
2. 이번 수업에서 좋았던 점, 안 좋았던 점, 그리고 추가적으로 수업에 대해 제안하고 싶은 것이 있는지 말씀해주세요. (서술형)

1번을 통해 학생들의 만족도를 파악할 수 있었고, 학생들에게 적정한 난이도를 찾으려고 했다. 예를 들자면 다음과 같은 피드백을 받을 수 있었다:

• 너무너무너무너무너무너무 좋았습니다. 프로그래밍에 대해 어렵게 생각하고 하기 싫다는 부정적인 견해가 많았습니다. 하지만 교수님께서 눈높이를 맞쳐주시고 쉽고 천천히 모두가 이해할 수 있도록 설명해주시는 모습이 인상적이었습니다. 감사합니다.
• 저 정말 너무 재밌습니다. 1학년 때 자바를 배웠지만 그땐 흥미가없어서 저에게 프로그래밍은 잘맞지 않는것 같아 구체적으로 생각하고 있지 않았는데 교수님께 배우면서 정말 흥미를 많이 느낍니다. 감사합니다!
• 사전 수업 준비가 철저하시고 천천히 쉽게 설명해 주시려는 점도 정말 좋았습니다. 학생 의견을 최대한 수렴하려는 점도 정말 좋습니다.^0^//
• 기존의 다른 다른 교수님들에게는 조금 부족했던 열정을 보여주셔서 일방적인 게 아니라 함께하는 수업이라고 느꼈습니다.

피드백이 항상 긍정적인 것은 아니었다. 때로는 다음과 같은 피드백도 받았고, 덕분에 많이 배웠다:

• 수업안에서의 흐름에 대한 당위성? 원인과 결과? 이런게 좀더 분명했으면 좋겠습니다. 이렇기 때문에 이런걸 배우고, 또 이런것이 결과적으로 필요하다. 이런식으로 수업이 진행되었으면 좋겠습니다.

이 방식을 적용한 데이터마이닝 수업은, 총 40명짜리 클래스였는데 학기 말까지 총 208건의 피드백을 받았다. 총 38명의 학생들이 설문에 참여했고, 학생 당 피드백 횟수는 평균적으로 4.58회였다.

여러 가지 차원에서 강의의 openness를 최대한 확장하려 했지만, 강의 평가에 관한 한 학생들의 confidentiality를 보장해주려 했다. 처음에는 평가 결과를 학생들과 공유할까 했지만, 혹시 비밀보장이 안될 것을 우려해 입을 못 여는 학생이 있을까 싶어 공개를 안하기로 결정했다.³

또, Business Analytics 수업은 학생 수가 7명으로 적어서 직접 물어보면 되겠다고 생각했는데, 오히려 잘못된 생각이었던 것 같다. 온라인 피드백 채널이 오프라인에서 직접 얘기하는 것보다 좋은 점은 1) 수업이 끝난 후 충분히 생각할 시간이 주어지고 2) “좋게” 얘기해야한다는 학생들의 부담도 줄여줄 수 있다는 것이다. 학생 수가 적어도, 온라인 피드백을 받는 것이 좋을 것 같다.

배움 4. Encouraging class participation is difficult, even more than you expect.

데이터마이닝 수업은 인원이 40명으로 조금 더 많아서 사실 강의실 내에서 학생들과의 interaction이 많을거라고 기대하지는 않았다. Business Analytics는 인원이 소수이기 때문에 조금 더 활발한 수업이 될 수 있을거라 생각했다. 그런데 한 가지 문제가 있었다. 그 수업은 영어 수업이었던 것이다. 한국어 수업이었어도 어려웠을텐데 영어 수업에서 학생들의 참여를 이끌어낸다는 것은 참 어려운 일이었다. 교육 사례를 찾아보니 토론을 활발하게 하기 위해서는 pairwise discussion을 시킨 후 발표하게 하면 낫다는 얘기도 있던데, 딱 한 번 해본 경험상 그게 분위기를 크게 바꾸지는 않았다. 학생들에게 이유를 물으니 언어 때문이라고 했다.

또, 수업을 하는 모든 사람이 같은 염원을 가지고 있겠지만, 나도 수업이 강의실에서만 이루어지지 않고 강의실 밖에서도 이루어지기를 원했다. 요즘 e-class 시스템(또는 온라인 강의실)은 참 잘 되어 있다. 각종 MOOC들만 봐도 그렇고, 온라인 포럼, 평가 시스템 등이 (발전의 여지는 아주 많지만) 제법 쓸만하다. 나도 이번에 e-class를 최대한 활용하려고 했다.

특히 Coursera의 클래스 포럼이나 Piazza 등을 보면 학생들이 교실 밖에서도 활발하게 토론하는 모습을 볼 수 있다. 그렇게 학생들 간 토론이 많이 이루어졌으면 좋겠다는 생각에 e-class와 구글그룹스 메일링 리스트를 열어두었다.

결과적으로는 잘 안됐다. 일단 학생들이 그런 공개 토론 문화에 익숙지도 않은데 그 의도를 충분히 학생들에게 전달하지 못했던 탓이 컸다고 생각한다. 언젠가 다시 강의를 할 기회가 생긴다면 다시 한 번 시도를 해보고 싶은 부분이다. 토론을 평가 지표에 넣는 것도 방법이겠지만, 그것보다는 토론 문화를 만드는 방법에 대해 고민을 해보는 것이 좋을 것 같다. 교육 관련 자료를 찾다보면 첫 강의가 한 학기의 분위기를 완전히 판가름한다는 얘기가 있다. 온라인이든, 오프라인이든, 좋은 토론 문화를 만들려면 첫 시간부터 토론을 활성화시키는 것이 중요한듯 하다. 그렇게 할 수 있는 방법은 아직 조금 더 고민을 해봐야겠지만.

또, e-class로는 시험 문제도 낼 수 있는데, 문제와 문항의 셔플 등까지도 가능해서 컨닝 등을 방지하기 좋았다. 자동채점까지 해주니 조교가 배정되지 않은 내 입장에서는 아주 매력적인 시스템이었다. 다만 주관식은 학생들이 수식 등을 입력할 수 없어서 시험 문항에서 제외했는데, 시험이 다 끝나고 나서야 든 생각이지만, 객관식은 e-class로 내고 주관식만 별도로 종이 시험으로 봤어도 좋았을 것 같다.

배움 5. 가르치는 법도 배워야 한다.

강의실에는 내가 예상치 못한 수많은 boundary cases가 있는데, 굳이 처음부터 시행착오를 겪어가며 하나하나 배울 필요는 없는 것 같다. 교수법에 대해 알려진 스터디는 무수하게 많다. 심지어 딱 나같은 사람을 위한 이런 글도 있다:

• Teaching as a Phd Student
• Tips for the First-Time Graduate Student Instructor

그런데 아직까지도 고민되는 것이 하나 있다. 내가 과제, 또는 강의실의 원칙을 잘못 정해서 수정하고 싶을 때는 어떻게 해야할까? 양해를 구하고 원칙을 수정해야할까, 한 번 정해진 원칙을 원칙이라고 고수해야할까? 나는 지난 학기에 전자를 택했지만 그 방법이 좋은 것인지는 아직도 모르겠다.

1. 원칙을 수정한 예: 올해 모 회사가 주최한 코딩 대회에서 하면 안되는 원칙을 미리 공지하지 않아서, 그런 “헛점”을 이용해 좋은 성능을 낸 참여자들이 있었다. 주최측은 “헛점”을 이용한 참가자들을 실격처리 했다.
2. 원칙을 고수한 예: 모 대학의 Information Retrieval 수업에서 query-answer set을 가지고 Okapi BM25를 측정하는 과제가 있었는데, 한 학생이 if-else 문 100개를 써서 좋은 성능을 얻었다고 한다. 그런데 처음부터 공지한 바가 없기 때문에 학생에게 애초에 공지한대로 높은 점수를 주었다.

애초에 설계를 잘하지 못했다면, 사후에 어떤 방식을 취하든 참가자들은 잘못된 설계 탓을 할 것이다. 그리고 나도 그런 문제는 100% 시스템의 설계자 탓이라고 생각한다. 게임에 fair player들만 있는 것은 물론 아니고, 시스템에 헛점이 있으면 그 구멍을 이용하는 사람은 얼마든지 있을 수 있다.

강의도 처음부터 잘 설계되어 운영되면 좋겠지만, “처음”이라는 것의 어려움은 만만치 않다. 그나마 다행인 것은, 항상 “다음”이라는 것이 존재한다는 것.

배움 6. 데이터 사이언스 강의에서 프로그래밍이 필수적이지는 않다.

보통은 박사과정 학생에게 수업의 커리큘럼을 맡기지는 않을텐데, 믿음을 가지고 커리큘럼에 대한 98%, 최대한의 자유를 주셨다.⁴ Drew Conway가 데이터 사이언스 벤 다이어그램을 통해서도 얘기했지만, 데이터는 전자적으로(electronically) 거래되는 재화(commodity)이기 때문에 이 시장에 참여하기 위해서는 좋은 싫든 프로그래밍을 좀 해야한다. 그런 차원에서 나도 학생들이 “입데마”를 하지 않게하기 위해 여느 데마 수업과 마찬가지로 프로그래밍을 중요한 일부분으로 포함을 시켰다.

그런데 여기서 내가 간과한 사실이 두 가지가 있는데, 첫째는 학생들의 프로그래밍 수준을 모른 채로 덤볐다는 것과 둘째는 이 수업이 데이터마이닝 심화도 아니고 입문 수업이라는 사실이었다.

먼저, 학생들 간의 수준 차가 크다. 다음은 프로그래밍 관련해서 학생들이 준 피드백이다:

• 파이썬 실습할 때, 갑자기 어려워져서 당황했습니다
• 스스로 파이썬에 대해 공부를 하는 방법밖에 없다고 생각합니다..ㅠ
• 파이썬 조금만 천천히 나가주셨으면 합니다 설명도 좀 더 자세히 부탁드리겠습니다
• 처음에 함께 차근차근 따라갈 수 있게 강의를 해주신 점이 정말 좋았습니다. 하지만 수업 마지막 쯔음엔 실습?비슷하게 나간 부분이 어려웠는데 처음 다루는 파이썬인 만큼 처음부터 끝까지 교수님과 함께 진행하는 것이 더 좋을 것 같다고 느꼈습니다! 혼자 해보려니 어려워서 잘 안되네요 ㅜㅜ
• 프로그래밍은 처음해볼때 항상 익숙하지 않은데 그때 차근차근 알려주셔서 따라가기 쉬웠습니다. 홈페이지에 모두 정리해주셔서 집에서 혼자 복습하기도 정말 편했습니다. 내용설명을 해주실때 조금 빨라서 필기하거나 이해하는데 조금 어려움이 있었습니다.
• 자바를 배웠다고 가정하고, 파이썬과 비교해서 설명했던 점이 좋았습니다. 아쉬웠던 점은 없었습니다 ㅎㅎ
• Python 을 처음 쓰는 사람이 많았기 때문에 처음 설명부분에서 자세하게 할 수 밖에 없는 부분은 이해하지만 이부분에서 너무 많은 시간을 쓴 것 같습니다 :D

특히 학부 수준의 데이터마이닝 수업에 참여하는 학생들이 모두 프로그래밍을 할 수 있는 것은 아니기 때문에 이들은 프로그래밍을 하기 위해 별도의 노력을 하거나, 어느 정도 소외가 될 수 밖에 없다. 파이썬 튜토리얼을 한 시간 가지기는 했지만 이런 식의 crash course는 가장 기본적인 문법을 다루는 것에 그칠 뿐 소프트웨어 버젼 확인하기나 디버깅 방법 등 pragmatical한 프로그래밍은 전혀 다룰 수 없다. (그러면 자연히 학생들의 고생이 많아지고, 흥미도 떨어진다. 이건 가장 지양해야 하는 것!)

이 수업은 데이터마이닝 수업이다. 그런데도 그 안에서 배워야할게 프로그래밍과 데이터 사이언스 두 가지라면 학생 입장에서는 벅찰 수밖에 없다. 그 중 한 가지라도 없으면 문제의 복잡도가 낮아져서 훨씬 수월해진다. 이상적인 경우에는 데이터마이닝을 두 학기로 나눠서 한 학기는 이론, 다른 한 학기는 (프로그래밍을 완비한 상태로) 실습을 해도 좋겠지만, 상황이 여의치 않아 한 학기밖에 없을 때는 아쉬운대로 이론만 다루는 것도 괜찮을 것 같다. 즉, 논란의 여지는 있겠지만, 목적이 데이터마이닝 알고리즘에 대한 감을 잡게 하는 것이라면 프로그래밍은 굳이 필요하지 않다.

그럼에도 만일 한 학기 내에 프로그래밍을 꼭 해야한다고 생각한다면, 미리 공개된 패키지를 이용해 알고리즘을 돌려보는 것보다는 linear regression 과 같이 단순한 알고리즘을 직접 짜서 돌려보게 하는게 나은 것 같다. 게다가 패키지를 쓰게 하면 카피 잡는 것이 무지 어렵다. 심증은 있으나 물증이 없기 때문에.

[숙제 예시] Linear regression을 직접 짜보고, 서로 다른 성질을 가진 세 가지의 주어진 데이터셋에 적용해서 좋은 예측 성능 내기 (점수는 예측 성능에 따라 부여)

1. 중고차 가격 예측 등과 같이 재미있으면서도 성능이 잘 나올 법한 일반적인 데이터셋
2. 변수의 개수가 월등히 많은 fat 한 데이터 (feature selection의 중요성, 차원의 저주를 알려주기 위한 초석)
3. Classification 문제 (다음 알고리즘인 logistic regression으로 넘어가기 위한 초석)

마지막으로, 프로그래밍 언어를 파이썬으로 할지 R로 할지도 고민을 많이 했다. 나는 파이썬을 택했지만, 학기가 끝난 후에는 파이썬 대신 자바스크립트를 선택했어도 괜찮았을 것 같다는 생각이 들었다. 여러 단점에도 불구하고, 자바스크립트는 결과물을 바로바로 시각적으로 볼 수 있어서 engage 되기 쉽고 OS의 영향을 적게 받기 때문에 프로그래밍을 처음 접하거나 익숙하지 않은 학생들에게도 “즐거움”을 좀 더 줄 수 있기 때문이다. (한편, 대부분의 학생들이 프로그래밍에 꽤 익숙하거나 앞으로 직업적으로 코딩을 할 친구들이었다면 다른 선택을 했을 것이다.) 요즘엔 자바스크립트 라이브러리와 튜토리얼도 많다:

• Clustering: Clustering in JavaScript
• Deep nets: ConvNetJS
• 그리고 여기에 훨씬 더 exhaustive 리스트가 있음

배움 7+: 그 외의 것들

그 외에 간간이 메모해 둔 것들을 무작위로 나열해보았다:

1. 좋은 수업(시스템)을 만드는데는 어마어마어마어마한 시간이 들어간다.
2. 수업 프로젝트로 Kaggle 문제를 써도 된다고 했는데, submission 가능한 것에 한정해서 실제로 submission까지 하게 했으면 좋았을 것 같다.
3. 수업 프로젝트 제안서를 제출하기 전에 학생들이 데이터마이닝의 개념에 어느 정도 익숙해지거나, 제안서 예시가 여러 개 주어져야 한다.
   • 실제로 전에 통계 수업을 들어본 학생들은 설문조사를 해서 그 데이터로 학습하려고 했음
   • 이미 산출된 통계량을 사용하려는 학생들도 있었음
   • 기본적으로 어떤 분석을 할 수 있는지 모르기 때문에 목적과 방법이 부합하지 않을 수 있음
4. 과제는 굳이 엄밀하게 채점하지 않아도 되는듯. 특히 수업 초반의 과제를 엄격하게 채점하면 채점하는 사람은 힘들면서 학생들의 의욕만 떨어진다.
5. 선생은 건강에 특별히 유의해야 한다. 4월 말 독감에 걸렸는데, 매주 말을 해야해서 엄청 고생했다. 기침이 오래 간게 반드시 수업 때문이라고는 할 수 없겠지만, 나을만하면 수업을 해야해서 다시 기침이 심해지는 것이 반복돼서 목이 좀처럼 낫지 못한 것 같다. 결국 6월 말에 다 나은건 우연만은 아니라고 생각함.
   • 특히 대학의 시간 강사에게 휴강은 있지만 휴가는 없다. 대체해줄 사람이 없으니 결석을 할 수도 없고, 학기 중에 사표를 낼 수도 없다.
   • 게다가 엄밀히 말하면, 휴강을 하는 것은 돈을 받고 서비스를 제공하지 않는 것이다. 정말 불가피한 경우 휴강을 할 수는 있지만, 말 그대로 정말 불가피한 경우에 해당된다.
6. 잘 말하는 연습은 그럼에도 필요하다.
7. 조교가 없으면 정말 정말 힘들다.
   • 수업 준비, 과제/시험 출제/채점, 이메일 답변까지 하려니 몸이 남아나질 않았다. 이 중 하나만 빠져도 할 만 할 것 같은데, 뺄 수 있는게 없다. (결국 이메일 답변에 소홀해지곤 했다.)
   • 이런 상황을 나도 예상하고, 학생들에게 양해를 구하고, 그렇기 때문에 너희가 서로 peer discussion을 많이 해야한다는 얘기도 했으면 좋았을듯.
   • 책임과 권한 분산, 즉 공정성을 위해서도 조교는 필요하다. 모든 권한이 한 곳에 집중되는 것은 언제나 위험하다.
   • 어쨌든 그런 의미에서 수백명 수업하고 답안지 채점하는 초중고등학교 선생님들 존경합니다..
8. 나는 openness advocate여서 강의자료도 최대한 open하려고 했다. 강의자료에 내 저작물이 아닌 것이 포함된 경우(ex: 선배님 강의록 발췌)에는 공개하지 않았다. 언젠가 완전히 나만의 자료로 만들게 될 기회가 생긴다면 전부 open할 생각이다.
9. 강의 자료를 만들 때 다른 사람의 자료를 인용할 일이 있으면 출처 표기에 각별히 신경썼는데, 빠르게 작업하는 자료에서 출처를 하나하나 명시하는 것이 힘들다는 것을 느꼈다. 내 스스로를 합리화하는 것이라기보다는, 간혹 의견/내용의 출처를 누락하는 사람들이 의도적으로 그런게 아닐 수 있겠다는 것을 이해하게 되었다.
10. 사실 선배님이 물려주신 훌륭한 강의 노트도 있었고 선배님은 자유롭게 쓰라고 하셨지만, 웬지 그대로 쓰기에는 내 자존심이 허락하지 않아서 나만의 강의자료를 만들기 시작했다.⁵
11. 지금은 강의자료에 영어와 한국어가 혼재되어 있는데, 이것도 어떤 학생들은 불편했다고 한다. 앞으로 한국어 강의는 최대한 한국어로 만들어야겠다는 생각.
12. 단 한 번도 가르치는 입장으로 자료 정리를 한 적이 없는데, 지난 학기를 기점으로, 다른 누군가에게 다시 티칭할 수 있는 가능성을 염두에 두고 자료를 모르기 시작했다.
13. 한 강의에 학생수가 너무 많다. 조금 슬펐던 피드백은, 열정이 없는 교수님들 중에 돋보엿다는 것이었다. 나도 학생들을 하나하나 충분히 챙겨주지 못해 미안한 마음이 많이 있었는데도, 그런 얘기를 들었다. Richard Socher가 지난 학기에 스탠포드에서 맡은 CS224d 수업은 조교 수가 무려 6명이었다. 160명 정도가 강의를 들었다고 하니 강사를 포함해서 1인당 20명 조금 넘는 인원을 맡은 것이다. 실제로 이번에 내가 e-class를 통해 시험을 본 이유는 내가 꼼꼼하게 채점을 할 자신이 없어서기도 했다. 즉, 조교의 유무, 뜨논 교수+조교 대 학생 비율이 evaluation의 방법이나 수준까지 결정을 할 수 있다는 것이다.
14. 가까워지려는 노력을 굳이 하지 않아도 나이 차가 적은 시간 강사니까 학생들이 나를 편하게 여길 줄 알았지만, evaluator과 evaluatee 간의 벽은 존재했다.
15. 학생들과 가까워지고 싶으면서도 우습게 보이지 않아야 한다는⁶, 그 종잇장만큼 얇은 차이 사이에서 줄 타기하는 것은 어렵다.
16. 발표 후 “질문이나 코멘트 있으시면 말씀해주시기 바랍니다.”를 말하는 것도 교육의 일부분이구나.
17. 데이터 마이닝이 problem definintion, data acquisition부터 presentation까지라면, 시각화도 중요한 요소라고 생각해서 포함.
18. 과제에 extra credit 문제를 포함시키는 것은 무의미한듯.
19. 첫번째 숙제로 MNIST 데이터셋 분류하기를 냈는데, 학생들이 무척 힘들어하면서도 재밌어했다. 괜찮았던듯.
20. 교습법 연구에 자주 등장하는 말이긴 한데, 나는 내가 평가할 자격이 되나 싶은데, 학생들은 나를 “절대자”로 믿는 것이 부담스러웠다.

나도 학부 때 백 수십 학점에 해당하는 수업을 들었지만, 기억에 남는 것은 손에 꼽힌다. 학생들이 삶을 살아가는데 필요한 철학, 또는 데이터 기반의 사고를 수업을 통해 조금이라도 얻어간다면 그것으로 족하지 않을까. 그리고 학생들이 종강을 빨리 하기를 원한다지만, 사실 그 강의실에 있던 그 누구보다도 내가 빨리 종강하고 싶었을 것 같다.ㅋㅋ

우여곡절 많은, 그럼에도 참 뜻깊은 시간이었다.