어제 상정된 저작권법 개정안

어제는 작년에 한참 대치하던 이른바 "MB악법"들을 포함한 여러 법안이 직권상정되거나 소위를 통과했습니다.
미디어관련법개정안들과 FTA비준안이 진행되고 있는 데에 대해서 굉장히 유감이지만 다른 곳에도
글이 많기에 생략하고, 어제 직권상정된 저작권법 개정안들은 이번의 쟁점법안은 아니지만 오픈룩과는 관련이 많기에 정리해 봤습니다.

이번에 상정된 저작권법 개정안은 의안번호 1800400 진성호의원등 12인, 의안번호 1802291 강승규의원등 11인의안번호 1802888 변재일의원등 12인입니다.
앞의 둘은 지금 나뉘어 있는 컴퓨터프로그램보호법과 저작권법을 저작권법 하나로 통합해서
저작권법에서 컴퓨터 소프트웨어까지 관할하도록 하는 것이 주요 취지이고, 마지막 것은 FTA비준을 위해서 요구사항을 맞추는 것과 청소년 저작권 위반 처벌 완화에 대한 것입니다.

강승규의원외 개정안(강승규 정병국 진성호 백성운 안형환 김영우 배은희 조진래 김금래 조전혁 이달곤)에서
컴퓨터프로그램보호법이 통합되는 것은 특별한 변동사항은 없고 두 법이 통합되는 정도인데, 점점 콘텐츠 융합 추세로 컴퓨터프로그램과 일반저작권의 경계가 모호해지는 것에 대응하기 위한 것이라고 합니다.
실질적으로 바뀌는 것은 기존에 분리되어 있던 저작권위원회컴퓨터프로그램보호위원회가 통합된다고 하는군요.

그리고 통합 외에 온라인에서 불법적으로 전송하는 사람 또는 올라오는 게시판을 정지시킬 수 있는 법적 근거를 넣는다고 합니다. 그 부분은 저작권법 133-2에 신설되는데 불법복제물이 올라오면 삭제하고 이용자를 정지하도록 요청할 수 있다고 되어있습니다. 단, 여기서 서비스정지를 해야 하는 서비스 제공자 중에 기간통신사업자가 빠지는데, 인터넷 선만 제공하는 사업자가 불법복제를 하는지 관리를 해야하는 건 힘들어서 뺐다고는 하지만, 검토보고서를 보면 기간망사업자(KT, SK브로드밴드 등)만 인터넷 서비스를 제공하는 것도 아니고, 기간망사업자도 다른 것을 제공하는 경우가 많아서 좀 더 검토를 해 봐야 한다는군요.

이 내용은 진성호의원외 개정안(진성호 현경병 조전혁 강성천 황영철 박선영 김효재 강승규 윤석용 김동성 박준선 유정현)에서도 다룬 것인데, 그 개정안에서는 P2P같은 서비스도 온라인서비스사업자로 추가하는 내용과 위의 133-2를 같이 다루었고, 강승규의원외 개정안과는 다르게 기간망사업자도 대상에 포함되어 있습니다.

변재일의원외 개정안(변재일 양승조 강성종 이춘석 권영길 홍재형 강봉균 안규백 강기갑 이시종 김종률 백원우)은 한미FTA비준을 위해 나온 개정안 세트 중의 일부입니다.
한미FTA의 저작권부분에서도 인정하는 여러 공정한 사용(Fair Use)을 미리 도입하고, 청소년들이 저작권을 잘 모른채로 어겨서 심각하게 처벌되고 가정 문제나 성장 문제까지도 연결되는 것을 막기 위한 안입니다.

가장 눈에 띄는 것은, P2P 업자나 온라인서비스제공자들이 저작권보호를 위해 충분한 장치를
하고 노력한 경우에는 사용자들이 발생시키는 저작권문제에 대해 책임이 없다는 것인데요.
그동안은 사용자들이 저작권을 어기면 서비스제공자도 책임이 있었던 모양입니다.
그리고 "공정한 사용"이 폭넓게 정의가 되었는데요. "통상적인 이용 방법과 충돌하지 아니하고 저작자의 합법적인 이익을 불합리하게 해하지 아니하는 경우에는 저작물의 이용을 가능하게 함."이라고 정의되어서, 지금까지 저작권자에게 해가 없는 경우에도 엄밀하게는 불법적인 사용이 되어 버린 경우가 이제 어느 정도는 합법화가 되었습니다. 위키백과에서 도움이 되지 않을까 싶군요.

또한 청소년들이 자기도 모른채 저작권법을 어기고 5년 이하의 징역까지 받을 수 있었던
문제가 있고, 이걸 악용해서 일부 나쁜 변호사들이 저작권 어기는 사람들 골라다가 협박메일을
보내는 일이 심심찮게 있었는데요. 이제 침해 권리의 소매가가 100만원 이하이면 처벌하지 못하도록 단서가 붙었습니다. 그리고 인터넷 서비스 같은 곳에서 캐싱 목적으로 저작물을 저작권자 동의없이 임시 저장해 두는 것도 이번에 합법화가 되었습니다.

프로그래밍 과목 조교하기

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

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

동영상(?)으로 보는 파이썬의 역사

Michael Ogawa의 code_swarm이라는
프로젝트에서 오픈소스 프로젝트의 CVS나 SVN 등 소스 저장고를 분석해서 일어난 작업들을
시각적으로 보여주는 걸 만들었습니다. 요새 UbiGraph같은
도구도 나오고 하는 걸 보면 시각화가 정말 굉장히 유행이네요~


code_swarm – Python from Michael Ogawa on Vimeo.

저는 3분 50초 쯤에 약간 왼쪽 아래에서 나타나서 잠시 머물다가 사라집니다;;; -ㅇ-;;;;;

이 영상은 미디어아트와 데이터 시각화에서 많은 관심을 모았던
Processing으로 만들었다고 하는데.. 전에 봤을 때는 괜히 어렵기만 하고 별 쓸모 없어보니더니
이걸 보니 확 땡기는군요. ^^;;

— via Python Daily URL

플레임에서 승리하는 자의 선택 [우리말 도우미], 지뢰밭용 업데이트

우리말 도우미

예전에 올렸던 우리말 도우미
한동안 잊고 있었는데 불여우 3.0 지뢰밭 출시가 임박해서 많은 분이 요청해 주셔서 3.0 용으로 갱신했습니다.

우리말 도우미 1.0 (불여우 부가 기능) 설치

3.0 지원 외에는 아주 사소한 레이아웃 관련 변경이 몇 개 있었지만 별로 눈에 안 띌 것 같네요 -ㅇ-;

아직 모래통 안에 들어 있어서 쉽게 설치가 안 되고, 사이트에 로그인해야지만 됩니다. 므흐흐..
언젠가는 모래통을 탈출하여 쉽게 설치할 수 있는 날이 오겠죠. -ㅇ-;

이번 업데이트에 큰 도움을 주신 신종훈님께 감사드립니다.Watch Full Movie Online Streaming Online and Download

“내 이름 어때” 만든 이야기~

며칠 전에 올렸던 “내 이름 어때?”를 만들면서 썼던 여러 가지 기술적인 부분에 대해서
간단하게 정리해 봅니다. 물론 django로 만들었습니다! 이히히

Django 템플릿에서 한글 조사 처리

이름 뒤에 은/는 이/가 같은 것들을 제대로 붙이려면 아무래도 템플릿에서 처리를 해 줘야하는데,
django에서는 애플리케이션에서 직접 템플릿 태그나 필터를 정의하는 걸 매우 장려하는 분위기라서
“필터”를 따로 정의해서 처리했습니다.

템플릿에서 이렇게 쓰려고 하는 부분이 있다면:

필터 정의를 이렇게 해 줬습니다.

마지막 줄에서 1:로 굳이 잡아준 이유는 이름 뒤의 ~이 처럼 받침이 없으면 끝에 안 붙는 경우도
처리해 주려고요..

추세 해석

이름의 인기가 늘고 있는지 줄어드는지를 글자로 판단해서 표현해 주기 위해서, 간단한 계산식을
사용했습니다. 우선 원 데이터 자체는 샘플수가 적어서 노이즈가 많기 때문에 보통 많이 쓰이는
9개 윈도우 평균으로 했고, 이렇게 하면 18개 포인트가 나와서 세 부분으로 나눠서
앞 중간 뒤의 평균을 다시 구해서 3가지 값이 나왔습니다. 그래서 눈으로 딱 보면 값이 계속
증가하는지, 올라갔다 내려갔다 하는지를 볼 수 있는데요, 그냥 값으로 볼 수는 없으니
앞/중간 과 중간/뒤의 각각의 변동폭을 0에서 1사이로 정량화해서 봤습니다. 변동폭은 이름마다
절대량이 다르기 때문에 상대량으로 비교해야해서 아래와 같은 식으로 썼습니다.

\delta = {{\arctan {\log {N_B \over N_A}}} \over \pi} + 0.5

보기엔 약간 쓸데없이 복잡하긴 하지만, 그냥 상대비율을 (0, 1) 사이로 넣어주는 일 밖에 안 합니다;;;

이렇게 나온 값으로 앞 뒤가 모두 (0.4, 0.6) 구간에 들어오면 “꾸준한 추세입니다.”라고 하거나,
앞-중간은 (0.0, 0.3), 중간-뒤는 (0.0, 0.5) 구간에 들어가면 앞 반쪽에서 감소세가 강하고
뒷 반쪽에서 감소세가 둔하다는 의미이므로 “확 줄어들다가 잦아드는 추세입니다.”라고 보여주는 식으로
주된 패턴들을 “대충” 느낌으로 나열하는 방법으로 코딩했습니다. 크흐;

구글 차트

이름 전체의 성별 성향이나 이름의 시대적 경향, 이름 글자의 시대적 경향을 보이는 부분에서
구글 차트를 불러서 사용했습니다. 구글 차트는 직접 URL을 코딩하는 방법은 아니고,
pygooglechart를 사용했는데요,
이게 의외로 그런대로 잘 만들어서 웬만한 기능은 불편없이 쓸 수 있게 돼 있더군요. 🙂

다만, 하나 기술적인 문제가 있었던 부분은 이름 글자의 시대적 경향 같은 경우에는
글자마다 실수값 18개씩(경향)이 저장돼야 하기 때문에, 이걸 그냥 저장하는 건 여러모로
번거롭고 해서 구글 차트 API에서 쓰는 0~4095 사이 인코딩하는 방법으로 썼습니다.
(base64와 거의 같은 방법입니다.) 그래서, 저장은 바로 구글 차트 API URL에 쓰면 되는
형태가 돼서 다시 불러올 때 매우 빠르게 불러올 수 있긴 한데, 문제는 한 이름 안에
이름 앞자와 뒷자의 경향을 모두 보여줘야하기 때문에 둘의 그래프 크기를 제대로 조절해 주지
않으면 각 글자의 크기가 잘못 나온다는 점이었습니다.

그래서 결국 선택한 방법은 보여줄 때 앞자 뒷자 인코딩된 값을 다시 풀어서 큰 쪽의 스케일로
맞춘 다음에 다시 인코딩하는 -.,-; 약간 노가다성 방법을 썼습니다. 역시 이런 부분은
numpy의 array의 도움을 많이 받을 수 있었습니다.

확장코드 인코딩/디코딩 부분을 따로 떼서 쓸 일이 좀 있을 것 같아서..

통계치가 적은 이름의 성별 추정

역시 통계 샘플 크기가 작아서 주요 이름들을 빼고는 제대로 된 통계치를 낼 수 없어서
주요 이름들의 성별 경향으로 학습한 걸로 예측하는 부분이 필요했습니다.
이번에는 아예 사용된 적 없는 글자까지도 어떻게 좀 해 보려고
통계치에 전혀 의존하지 않고 그냥 자소별로 분해해서 이름만 피처로 사용하기로 했습니다.
그래서 보통 SVM
쓰는 것이 여러모로 대세이기는 하지만, 카테고리성(이산) 피처값에 매우 유리한
random forest을 썼습니다.
(물론 제가 수학을 워낙 못하는 것도 큰 요인으로;;;;)

Random forest는 아무래도 쓸 수 있는 구현이 적다는 게 큰 문제인데요.
파이썬에서 쓸 수 있는 orange를 쓰면 정말
좋겠지만, 아쉽게도 이 구현은 리그레션은 지원하지 않고요. Y.Y
R용 패키지인
party
randomForest
중에 선택해야하는데, party를 먼저 했으나 메모리 3기가를 먹더니 죽었고 (-_-)
randomForest는 안정적으로 대략 200메가 정도 먹고 그런대로 쓸 만한 결과를 줬습니다. 🙂

학습 기법 측면에서는 남자 샘플이 2배 정도 되기 때문에 편향 문제가 있어서 샘플링 조절을
좀 해야했는데요, 그냥 복잡한 것 쓰지 않고 대략 0.3 밑을 반 다운 샘플링하니까 전체적으로
분포가 윗쪽하고 아랫쪽이 그런대로 맞았습니다. 중성적인 이름이 수가 훨씬 적은 것도 또한
중성적 이름 쪽에서 오차를 많이 발생시킬 수 있는 요인이 될 수 있는데, 이쪽에서 오버샘플링을
하려고 하다가 “될 거 같으면 대충해도 돼야 하는거지” 하는 교수님 말씀이 귓가를 스치며
놀이인데 대충하자 하고 -ㅇ-;; 크흐; 그래서 결국 10-fold cross validation으로
평균 피어슨 연관성이 0.97 정도 나왔습니다. (만… 역시 사람 느낌하고 좀 다른
사례가 개별적으로는 제법 많이 발견되긴 하네요;)

페이지 내용 캐시

서비스를 공개한 다음 날 점심시간이 좀 지나고 나서는 접속이 폭주해서, 실시간 계산이 상당히
있었던 구현 특성상 앞으로 어떻게 될 지 참 고민이 있었는데요; 그래서 마침 전혀 필요없겠다
싶어서 꺼놨던 django의 캐시 프레임워크
살려서 해 봤습니다.
백엔드를 선택할 수 있는데, 역시 제일 잘 나가는 memcached를 썼습니다. 이거 소문대로 깔끔하고 잘 돌아가네요. ^_^;

Django는 다행히도 템플릿에서 일부만 특정 변수에 따라서 캐시하는 기능이 있어서
이름에 따라 바뀌는 부분, 성에 따라 바뀌는 부분을 따로 따로 캐시하도록 3조각으로
따로 캐시해서 생각보다 훨씬 간단하게 쉽게 캐시로 넣었고요, 지금은 CPU부하가 전보다
같은 요청에서 거의 1/10로 줄어들었습니다! 이히히.

다른 사소한 것들..

몇 분께서 물어보셨던 게 자료처리나 통계처리는 어떤 걸 썼느냐가 있는데, 특별히 쓴 것은 없구요, 파이썬 하나면 다 해결됩니다. -ㅇ-;
물론 numpy, matplotlib도 아주 큰 도움이 됐습니다.
collections.defaultdict를 전에는 그렇게 자주 쓰지는 않았는데, 이번에 좀 과격하게
3~4 단계 쑥쑥 defaultdict를 겹쳐서도 써 봤더니 pickle이 잘 안 되는 문제만 빼고는, 코드를 아주 많이 줄여준다는 점에서
아주 사랑스러웠습니다.

후속편으로는 이번에 들어온 로그를 한 번 분석해 보려고 하고 있습니다. ^^;

단백질 접기 게임 fold.it의 배경 이야기

요즘 인터넷에서 단백질을 접는 게임 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 구조,
단백질-단백질/라이간드 도킹 예측/디자인, 단백질 유도 진화 등 재미있는 게
많이 있을 것 같은데 게임으로 과연 만들 수 있을지는 모르겠네요. ㅎㅎ;

생활 속의 프로그래밍

예전에 블로그에서 알려드린 적 있는 생활 속의 프로그래밍 동영상이 얼마 전에 올라왔습니다. 이미 보신 분도 계시겠지만, 기록의 의미로 여기도 하나 링크해 둡니다. 🙂

생활 속의 프로그래밍은 프로그래밍으로 먹고 사는 분들이 일상 생활에서 프로그래밍을 활용해서 재미도 있고 편하기도 하고 배울 것도 있는 여러 놀이를 떠올리는 계기가 되게 제가 그동안 오픈룩에서 썼던 여러 사례들을 소개해 드리는 세션이었습니다. 오픈마루 WoC 스노우캠프와 NHN 네이버토크에서 따로 2번 진행했었는데, 둘 다 비디오 촬영은 되었지만 오픈마루 WoC 것은 아직 공개되지 않았고, NHN 것이 얼마 전에 공개되었습니다.

화면이 잘 안 보이는 편이니, 발표자료를 따로 받아서 보시면 잘 보일 것 같습니다~

사실 제가 말이 좀 느리고 중언부언하는 경향이 있어서 3배속으로 보면 딱 맞을 것 같긴 한데, 아쉽게도 속도 조절은 못 하는군요 -ㅇ-;

WoC 눈 야영지에 대해서 추가 사항

엊그제 올렸던 WoC snow camp 얘기는 행사를 주최하는 곳에서 WoC참가 학생을 위한 행사라 장소가 좁아서 일반인은 참가할 수 없다고 알려왔습니다.

제가 미처 확인을 못 하고 알려드려서 죄송하네요~ “생활 속의 프로그래밍” 주제는 앞으로 많은 분들이 참여하실 수 있는 좋은 행사에서 준비가 되면 그 때 다시 알려드리겠습니다. 🙂