computer

저희 학교는 등록금이 상당 부분 세금에서 지원되는 대신, 모든 학기에 뭐든 조교를 하도록 돼 있습니다. 학과 사무실 조교 같은 자잘한 일 도와주는 조교부터 시작해서, 슈퍼컴 관리 조교, 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명 씩 짝을 만들어서
공략합니다! 이제 그 뒤 부터는 예전에 코드레이스같은 곳에서 했던 형식이나 재미있게 할 수 있는 형식을 여러 가지 만들 수 있을 것 같네요. 채점은 아마도 각 문제를 출제한 사람이 뽑게? ^^;

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

요즘 인터넷에서 단백질을 접는 게임 fold.it이 아주 인기입니다.
단백질 접기(protein folding)는 구조생물정보학의 가장 큰 문제이기도 하지만, 제가 있는 연구실의
주요 주제이기도 해서, 단백질 접기에 관한 몇 가지 얘기를 해 볼까 합니다. 🙂

단백질 구조가 뭔가?

단백질은 생물을 구성하는 주요 분자구조 중의 하나인데, 20가지 아미노산이 일렬로
실처럼 쭉 연결되는 것이 기본 구조입니다. (현재 22번째 자연계 아미노산까지 발견되긴
했지만 사람은 20개만 사용하고 있습니다.) 20가지면 컴쟁이가 생각하기에 바로 생각할
수 있는게 알파벳으로 커버하고 남는다 그거죠. 그래서 실제로 아미노산은 알파벳으로
표시하고 있는데 각각의 이름을 따서 BJOUXZ 여섯개를 빼고 나머지로 표현하는 문자열로
많이 씁니다.

그런데, 각 아미노산은 성질이 있어서 자기들끼리 모이려고 하는 것도 있고, 서로 떨어지려고
하는 것도 있고 크기가 커서 부딪히지 않으려고 하는 것도 있고, 기타 등등 여러 성질이 있어서
안정적인 몇 가지 기본적인 구조(나선형, 판형 등..)을 지역적으로 이루는데, 이걸 2차구조라고 부릅니다.

역시 인간관계도 상당히 복잡하듯, 2차구조를 이룬 다음에도 자기들끼리 꼬이면 그나마 남은
관계까지도 복잡하게 얽여서 굉장히 안정적인 구조를 만들 수 있는데요, 이렇게 모인 것을
3차구조라고 부릅니다. 그리고 여러 단백질 가닥이 모여서 큰 단백질을 만들면 4차구조라고
부릅니다.

구조는 뭐에 쓰는가?

단백질은 생화학적 작용의 가장 기본적이고 유용한 분자이기 때문에, 생화학 작용에서
단백질을 빼면 거의 남는게 없습니다. 물론 핵산이나 탄수화물 등도 매우 중요하긴 하지만,
생화학 회로를 그린다 하면 거의 대부분 단백질이 주인공이죠. 그런데, 단백질이 상대를
만나서 반응을 하는 기준이 대부분 단백질에 있는 구멍의 특정 모양이나 아미노산들이 배치된
패턴과 상대의 특징들 같이 단백질과 생분자간의 모든 관계가 구조를 빼면 설명하기 힘듭니다.

그래서 단백질의 구조를 밝히는 것이 분자생물학, 세포생물학의 기본 원리를 밝히는 데 뿐만
아니라, 새로운 단백질을 디자인하고 약을 만드는 데 매우 중요한 도구입니다. 90년대 말의
히트작 항암제인 글리벡도 구조를 연구해서 기막히게 구멍을 메우는 약이죠.

구조를 그냥 보면 안 되나?

웬만하면 구조는 그냥 현미경으로 보면 가장 좋겠죠. 그런데, 단백질은 빛의 파장보다
짧은 구조를 하고 있기 때문에, 가시광선으로는 볼 수 없어서 현미경으로 볼 수 없고,
전자현미경이나 다른 원리를 쓰는 현미경들도 (적어도 아직은) 단백질 구조까지 보기에는
한참 힘듭니다. 그래서 사용하는 것이 일반인들에게 MRI로 유명한 NMR과
X레이 구조결정 두 가지 방법이 쓰이는데요, 보통 X레이가 여러 이유로 더 많이 쓰입니다.

X레이로 그냥 다 찍으면 보이면 좋은데, 이게 결정을 만들어야하다보니, 같은 분자를 다량
정제하는 것도 힘들고 결정으로 만들기도 힘든 고분자를 결정으로 만드는 것도 상당히
경우에 따라 다른 기술이 필요합니다. 그래서, 대량으로 찍고 싶다고 다 나온다기 보다는
관심이 많은 단백질들의 구조에 집중되어 있는 편입니다. 또한, 단백질 구조가 항상 같은게
아니라 꿈틀꿈틀 움직이기도 하고 아예 훽훽 움직이기도 하는데 그 움직임이 중요한 경우도 있어서 원하는 걸 다 얻기도 힘들고,
막 사이에 끼여있는 단백질 같은 경우엔
아예 원래 구조로 결정으로 만드는게 너무너무너무 힘들어서 지금까지 찍힌 것이
손으로 꼽을 정도가 되기도 합니다.

계산적 구조 예측

그래서 하는 것이 컴퓨터를 이용한 구조 예측입니다. 기본적으로 원자의 움직임은 물리역학적
특성을 따르기 때문에, 움직임이나 안정적 구조를 컴퓨터로 당연히 이론적으로 예측할 수
있습니다. 대표적으로 사용되는 방법은 분자동역학 시뮬레이션이나 몬테카를로 같은 것들을
쓰는데, 전자의 경우에는 계산량이 엄청나게 많아서 수십나노초(ns)가 넘으면
예측이 거의 불가능해집니다. 그리고 몬테카를로법이나 다른 변종들도
한계가 있습니다. (시작점을 잡기 위한 방법이나 지속적인 움직임을 보기 위한 다른 방법을 도입할 필요가 있죠.)

그 결과 결국 구조 예측의 주축은, 유사성 모델링이 되었는데, 기존의 비슷한 단백질의 구조를 가져다가
여기 저기 비슷한 부분을 잘라 붙인 다음에, 그걸 기존 방법으로 에너지 안정화 시뮬레이션을
좀 거치는 방법입니다. 기존 단백질 구조를 이용해서 완전 바닥이 아니라 벌써 한참 진행된
것을 가지고 하기 때문에 아주 효율적이고 비교적 정확한 결과를 얻을 수 있지만, 기존의
비슷한 단백질이 없으면 구조를 예측하지 못하는 한계가 있습니다. 그렇지만, 데이터베이스가
점점 커져서, 최근에는 단백질 예측에서 유사성을 이용하지 않는 것은 상상할 수 없을 정도가
되었고 데이터베이스 크기가 예측의 품질과 매우 밀접한 관계를 가지게 되었습니다.

구조 예측 대회 CASP!

이렇게 단백질 구조 예측이란게 아주 정의가 잘 된 계산 문제가 되다보니, 그 다음에 당연히
나올 수 있는 것은 초밥만들기 대회처럼 세계대회가 생기는 것이겠죠. 그 중 가장 큰 것은
단연 CASP입니다. 1994년부터 격년으로 하고 있는데
올해 대회는 얼마 전에 참가접수가 끝나고, 지금 한참 대회가 진행 중입니다.

요즘 유행하는 fold.it도 이 구조 예측 대회를 타겟으로 나온 것인데, fold.it을 만든
워싱턴대학(시애틀) 생화학과의 David Baker 연구실은 한동안 CASP을 휩쓸었던
먼치킨 그룹입니다. 여기는 애플과 비슷한 점이 많은데, 남들이 다 뻔히 될 것 같다고 생각하고는
있지만 실제로는 여러 이유로 안 해보는 것들을 아주 기발하고 멋진 해결책을 들고서
짠! 하고 만들어서 그걸로 굉장한 결과물을 만들어냅니다. 유사성 모델링에서 에너지 계산방법도
그렇고, 구조 데이터베이스 탐색법, 분산계산(Rosetta@Home)등 여러 가지가 그런데요,
이번에 fold.it도 종종 컨퍼런스에서 구조는 역시 사람이 보고 끼워맞추는게 최고다 그런
농담이 자주 나오는 걸 진짜로 게임으로 만들어서 수만명이 달려들게 만들어버렸습니다.

-ㅇ-; 그 결과 지금 fold.it에 슬슬 CASP문제가 나오기 시작했고, 올해 CASP 문제를
게임에서 수만명 플레이어가 여러가지를 아직 알고리즘으로 나오지도 않은 여러 직관을
써서 풀어놓으면 거기서 나온 구조로 CASP 답안으로 제출한다고 합니다. 물론 컴퓨터로
찾는 것 보다 완전 샅샅히 뒤지는 것은 안 되겠지만, 그래도 사람의 직관이 수만명이
모이면 그 힘이 어떻게 될 지는 상상도 안 가네요. 아마도 상당히 상위권에 들어갈
수 있지 않을까 싶습니다.

실제로 게임 안에 나오는 구조는 진짜 단백질 구조인가?

많은 분들이 물어보셔서 덧붙이자면, 게임 안에서 쓰이는 용어는 모두 실제
생물학에서 사용하는 용어이고, 구조에 큰 영향을 주는 요소들은 상당 부분이
게임 안에서 자세히 표현되어 있습니다.

앞으로 이런 게임이 어떤 것이?

직관으로 풀면 훨씬 간단한 NP-hard 문제들을 재미있는 퍼즐로만 만들 수 있다면
이렇게 잘 표현한 게임으로 만드는게 수천개 CPU 동원한 클러스터보다 효율적일 수도
있을 것 같습니다. 단백질 구조 외에도 계통 분류 최적화나 RNA 구조,
단백질-단백질/라이간드 도킹 예측/디자인, 단백질 유도 진화 등 재미있는 게
많이 있을 것 같은데 게임으로 과연 만들 수 있을지는 모르겠네요. ㅎㅎ;