OpenLook

저희 학교는 등록금이 상당 부분 세금에서 지원되는 대신, 모든 학기에 뭐든 조교를 하도록 돼 있습니다. 학과 사무실 조교 같은 자잘한 일 도와주는 조교부터 시작해서, 슈퍼컴 관리 조교, BK21 서류 관리 조교도 있지만 대부분은 수업을 돕는 학과목 조교를 합니다. 저도 지금까지 쭉 운도 없이 계속 학과목 조교를 해왔습니다. 지난 학기까지는 쭉 과학 기초과목을 해서 별로 특별한 것은 없었는데, 이번 학기에는 전산, 전자과에서 누구나 듣는 기초과목에다가 바이오를 짬뽕한 "바이오데이터구조"라는 과목을 맡았는데요. 과에서 2학년 필수과목이다보니 보통 저희 과 과목은 수강생이 많아도 10명 정도인데, 이 과목은 처음엔 수강생이 60명이 넘었습니다. (물론 이 안에는 학점을 쉽게 따려고 오는 전산과, 전자과 고학년들도 있긴 하죠. 🙂

처음 맡는 프로그래밍 관련 과목이라, 제가 학부 때 느꼈던 "조교가 이런 걸 하면 무척 좋지 않을까!"를 한 번 실행에 옮겨 보기로 했습니다. 사실 중간고사증후군보다 졸업논문증후군이 훨씬 심하죠 –;;

제가 맡은 부분은 학기 프로젝트 관리/채점 부분이라서, 이런 것들을 한 번 생각해 봤는데요.

• 괜히 코드에 a = 1; 같은 것까지 주석 달아야 점수 잘 나온다는 생각은 안 갖게
• 코드의 실행 결과가 제대로 안 나오거나 만들다 말았어도, 코드의 세세 부분을 보고 겪었을 만한 세부 경험을 기준으로 채점해서 프로그래밍을 잘 못해도 포기하지 않도록
• 코딩 결과 자체보다, 코드를 돌려본 결과를 성능/속도/알고리즘 등 여러 측면에서 시험해 보는 과정과 원인 분석 과정, 개선 방안, 도메인 문맥에서의 의미 등을 살펴보게
• 결과 보고서와 코드가 결국 조교 혼자 보라고 쓰는 것이라고 생각하면 영 지루하니, 어떻게든 피드백을 많이 줘서 누군가 읽긴 읽었구나 하는 느낌을 확실히 받도록
• 프로젝트 진행 중에 학생들의 질문에는 스펙 설명같은 것 자체에 곁들여서, 진행과 관련된 현실적인 조언이나 관련 학문에서의 정보를 전달하게
• 질문에 대한 답변이나 채점 결과는 가급적이면 빠를 수록 공부에 효과가 좋으므로 가급적 빠르게

그래서 프로젝트를 시작할 무렵에는 우선 가이드라인을 제시했습니다. 원래 내용은 꽤 길지만 요약하면

• 주석 너무 많이 달지 마라, 주석이 적어도 잘 이해되는 코드가 좋은 거다.
• 사소한 문제 때문에 진행하기가 힘든 상황이면, 그런 것들은 보고서와 코드에 표시하고 우선 상황을 대충 억지로 넘긴 다음에 시간이 날 때 다시 봐라.
• 보고서에는 이런이런~~ 것들에 대한 토론이 있으면 좋다. (예시 10가지)

이렇게 시작하고 나중에 오는 질문에는 가급적이면 질문 자체에 대한 직접적인 답보다는, 왜 그렇게 되는지, 실제 프로젝트의 상황에서 어떤 경우가 있어서 그런 결정을 해야하는지 같은 것들을 가급적이면 같이 썼는데, 사실 처음 배우는 프로그래밍 과목에서 하기로는 좀 어려운 프로젝트다보니 제대로 전달이 잘 안 된 것 같아서 좀 아쉽기는 했습니다.

드디어 제출이 다가왔을 때는, 직접 내면 좀 번거로우니까 전자메일로 받기로 했는데요. 아무래도 전자메일에 큰 첨부파일을 보내다보면 사고도 많이 생기고 해서, 별도의 2가지 경로로 보낼 수 있게 메일 주소를 따로 2개를 마련해서 둘 다 보내도록 했습니다. 그리고, 그래도 혹시 또 메일은 알 수 없으니, 과목 홈페이지 게시판에 MD5 체크섬을 올리면 MD5 체크섬이 맞으면 나중에 제출해도 게시판에 올린 시간으로 인정하기로 했습니다. 그런데 정말로 한 학생이 5일 뒤에 메일이 안 갔냐고 자기 성적이 안 올라왔다고 그러는데, 메일이 유실됐는지 전혀 로그에서도 찾을 수 없는 일이 발생했습니다. 마침 게시판에 MD5 체크섬이 올라와 있어서 구원해 줄 수 있었죠.

결국 약간 늦은 학생도 있었지만 대부분 제출이 끝나고 채점을 했는데요. 역시 채점은 하다보면, 점수로만 표현하기는 좀 아쉬운 뭔가 그런 것이 있습니다. 그래서, 아예 성적표 사이트를 하나 만들어서, 각각의 개인의 제출물에 대한 피드백과 학생들의 부분별 상대적 위치를 알 수 있는 도표를 볼 수 있도록 했습니다. (실제 인물이 아니라 이 글에서 인용하려고 가상의 학번을 만들었습니다.)

피드백은 직접 일일이 쓰기는 좀 많아서, 세부항목별로 따로 Z-score를 계산해서 낮은 순서로 몇 개, 높은 순서로 몇 개를 추려서 "좀 더 열심히", "참 잘했어요" 아래에 코멘트를 자동으로 쓰게 했습니다. 뭐 그런대로 괜찮게 나오더군요. 🙂 하나 재미있는 것은, 웹서버 로그를 보니까, 자기 성적만 보고 가는 학생은 30% 정도 밖에 안 되고, 나머지는 친구 학번을 다 넣어보고 가더군요.;; (친구 관계 네트워크라도 그릴 수 있을 정도!)

이제 프로젝트가 끝나긴 했는데, 제가 맡은 부분이 기말고사가 또 남아있어서.. ㅡㅡ; 또 하려니 막막하네요 -ㅇ-; 그래도, 학생들이 그냥 조교라서 하는 아부도 많이 섞여있겠지만 제출하는 메일이나 게시판 댓글에서 도움이 많이 됐다, 좋은 경험을 할 수 있었다, 많은 것을 배울 수 있었다. 라고 해 줘서 무척 힘이 났습니다. 이제 졸업 준비를 해야하는데.. -ㅇ-;;

서울에 있을 때는 이런 저런 행사를 많이 했는데 요즘 대전에 있다보니
영 근질근질해서, 가끔 이런 행사 하면 정말 재미있겠다 상상하며 졸곤(;;) 합니다.
어디 적어두는 습관이 없다보니 생각을 아무리 해 봐야 늘 남는 게 없는데요. 흐흐;;
그래서 최근에 생각났던 걸 함께 생각해 보기도 하고 스스로 안 까먹으려고
적어 놓아 봅니다.

개발자 구보씨의 3일

제가 가장 좋아하는 TV 프로그램은 단연 KBS1 다큐멘터리 3일 입니다.
이 프로그램에선 어떤 장소나 사건을 주제로 3일 동안 같은 곳을 지키며 오가는 사람을 취재합니다.
강남역, 구로역 같은 사람 많이 다니는 지하철 역이 되기도 하고, 강남고속터미널이나 통도사, 동해의 어촌, 추석 특송 기간 동안의 택배 직원들 등등
생활을 밀접하게 다루다보니, 역에서 지나가는 사람들을 보며 저 사람들이
어디서 어디로 가고 어떤 일을 하고 어떤 생각을 하고 가족들과는 어떻게 지내고
어떤 게 행복한지 등이 늘 궁금해 했던 것을 조금이나마 엿볼 수 있게 해 줍니다.
특히 같은 자리에 3일을 쭉 있다보니, 면접보러 서울에 왔다가 다시 며칠 있다가 내려가는 사람, 자전거 여행하러 갔다가 2박 3일 여행하고 돌아오는 사람들의 전과 후를 모두 볼 수 있다보니 정말 재미있습니다. 한 편을 보면 마치 100명하고 술 마시면서 인생 사는 얘기를 하고 온 것 같은 기분이죠.

그래서 개발자도 이런 것들을 할 수 있지 않을까 생각해 봤는데요. 개발자라고 묶으면 왠지 뻔히 하루 종일 컴퓨터 보고 키보드만 칠 것 같지만, 알고보면 회의도 하고, 아이디어 만들기도 하고, 제안서도 쓰고, 싸우기도 하고, 몰래 만화도 보고, 여자친구와 메신저도 하고… 하는 일이나 회사 환경, 개인적인 환경에 따라 적지 않은 차이가 있습니다. 그냥 보면 다 똑같은 개발자의 실제 일하는 환경을 엿보면 고년차 개발자들끼리, 또는 갓 IT업계에 들어온 신입, 대학생, 고등학생 등등.. 추상적인 "이 쪽 전망이 어떻더라…" 보다 도움이 될 것 같아서요.

72시간 VJ들이 쫓아다니는 건 현실적으로 어려우니, 대충 타협해서 72시간 중에 종종 자기 모습이나 하는 일, 주변 환경을 사진으로 찍어서, 그 중 24장을 꼽아서 자기 생활에 대해 페차쿠차 형식으로 발표하는 것입니다! +_+ 자기 자리 자랑도 있을 것이고.. 몰래 회의 장면 같은 데서 이상한 동료 욕도 할 수 있고.. 어려웠던 문제 해결하는 과정을 무용담처럼 얘기할 수도 있고… 단편적인 생활 스케줄을 쫙 훑기보다는, 살아있는 진짜 3일처럼 당시의 생생한 연결된 이야기를 들으면 더욱 좋겠죠!

서울에 사는 세계 개발자 페차쿠차

한국 IT게에서 비전통적 컨퍼런스를 상당히 일찍 시도했던 "KLDP CodeFest"에서는 초기에 계속 꾸준히 서울 인근에 사는 외국인 개발자들이 몇 명씩 참여했습니다. 지난 번 파이썬 페차쿠차는 진행 언어가 한국어였지만 한국어를 잘 하는 프랑스인 개발자가 한 분 참여해서 자리를 빛내주었습니다. 그 때 생각이 떠올랐는데요. 서울에 사는 외국인 개발자들과 또한 그들과 교류하고 싶은 한국인 개발자들이 소통하는 계기가 있으면 좋겠네요.

그래서 역시 지난 번 파이썬 페차쿠차와 마찬가지로 자기가 하는 일이나 한국에서 일하는 개발자로의 경험, 어려움, 팁 같은 것을 페차쿠차로 발표하는 자리가 있으면 촉진할 수 있는 좋은 기회가 되지 않을까 합니다. 아무래도 한국어에 서투른 개발자들도 많이 참가할 수 있도록 공식 언어도 영어로 지정해서 행사장에 누가 있어도 서로 말을 거는 데 주저하지 않을 수 있도록 하면 더욱 좋을 것 같습니다. (한국어를 너무 사랑하는 분들은 이 부분에서 거부감이 있을 수도 있겠지만, 현실적으로 취지를 살려서 한국어를 못하는 개발자를 배제하지 않으려면 이 방법이 최선인 듯 하네요.)

장난감 문제 축제

예전에 언젠가 한 번 제 블로그에 올린 적 있는 생각이기도 한데요.
앞의 "구보씨"와 마찬가지로 다양한 분야에서 일하는 개발자들이 모여서
경험을 나누고 이해를 넓히는 방법으로 장난감 문제를 쓰는 방법을
생각해 봤습니다. 우선 자기 개발 분야에서 아주 간단해서 잘 모르는 사람도
10분 안에 풀 수 있는 장난감 문제를 1개 준비해 옵니다. 예를 들어 게임
프로그래머라면 2D 좌표계에서 충돌 검사를 하는 문제를 가져온다거나,
자판기에 들어가는 펌웨어를 만드는 프로그래머라면 자판기에서 돈 넣으면
잔돈 계산하는 문제, 이미지 처리를 주로 하는 프로그래머라면 간단한 껍데기를 채워넣어서 간단한 알고리즘으로 그림파일 외곽선을 보여주는 문제를 가져오는 등 최대한 자기 분야 특성은 살리지만 장난감 문제인 것을 가져
오면 되겠죠.

그래서 이 문제를 이제 잘 모르는 사람들끼리 무작위로 2명 씩 짝을 만들어서
공략합니다! 이제 그 뒤 부터는 예전에 코드레이스같은 곳에서 했던 형식이나 재미있게 할 수 있는 형식을 여러 가지 만들 수 있을 것 같네요. 채점은 아마도 각 문제를 출제한 사람이 뽑게? ^^;

그냥 최근 떠올랐던 생각 세 가지를 적어 봤는데요. 좀 다듬어서 해 볼 만한 것도 있을 것 같네요. 언제 기회가 되면 한 번 추진을!