얼마 전에 Naver Open API에 대한 글을 보긴 했었는데, 역시나 이런 게 나왔다. 푸하하;

속도도 상당히 빠르고, 구글과 거의 흡사한 인터페이스를 가지고 있다. (구글이 연한 하늘색을 주요 색상으로 쓴다면 여기는 연한 초록색을 쓴다. -_-) 이런 응용을 할 수 있는 API가 공개된 것은 정말 잘 된 일이지만, 블로그 검색을 보면 네이버 내부에 그 결과가 거의 한정되어 있다는 점을 볼 수 있고, 내가 네이버를 주로 이용하는 이유인 "TV 편성표", "단위 환산"과 같은 특수(?) 검색어에 대해 별도로 제공되는 정보들은 나타나지 않는다. (API이기 때문에 일관성을 유지해야 하기 때문일 수도 있겠다)

네이버의 Open API 공개 이후, 다음에서도 일련의 움직임을 보이고 있는 것 같다. 윤석찬 님이 쓰셨듯, 앞으로 공개될 다른 Open API들도 기본 조건을 잘 고려해서 만들어져야 할 것이다. 확장성과 범용성, 사용하기 쉬운 예제의 제공, 다양한 표준 프로토콜의 지원, 사후 커뮤니티 관리 등.. Daum의 경우는 윤석찬 님이 계시니 어떤 모습으로 공개될 지 궁금하다.

현재의 네이버 Open API는 2%가 아니라 30% 부족한 것 같다. 그래도 대형 포탈에서 스스로 트래픽을 감당하면서 그런 문을 열어주었다는 데에는 의미가 있다. 구글형 네이버 말고도, 앞으로 다양한 활용 예시가 등장했으면 좋겠다. (MetaBBS에도 넣어볼까나? -_-)

꼭 실내악 앙상블 때문은 아니었지만, 저번 실내악 앙상블 공연에서 나름대로(-.-) 아카펠라를 해본 경험이 있기도 하고, 또 일본인 여성 5인조 그룹이라는 특이한 구성 때문에 궁금하기도 해서 KAIST 문화행사로 하는 앙상블 플라네타의 공연을 보러갔다.

결론부터 말하자면 아주 멋있었다. 심지어 당타이손이 왔을 때도 이렇진 않았는데 앵콜로 캐논변주곡이 끝나고나자 전원 기립 박수를 쳤다. (당타이손 때는 온 사람 자체가 워낙 많았기 때문에 박수 소리가 작은 건 아니었다)

거의 완벽하게 들어맞는 음정과 박자는 내 스스로 그들과 동조하게끔 만들었다. 특히 마음에 들었던 건, 내가 들어본 적은 있으나 이름이나 연주자는 전혀 몰랐던 곡들을 불러주어서, 그 곡들을 알 수 있게 해주었다는 점이다. 민요("traditional"이라고 표기된 것들)인 Greensleeves, Scarborough Fair, Amazing Grace도 불렀고 O mio babbino caro, Smetana의 Vltava -Ma vlast- 등의 이름은 생소하나 들어보면 모두 아는 것임직한 곡들도 있었다. 맨 마지막에는 앵콜로 그 유명한 캐논 변주곡을 불렀는데, 박자도 거의 정확했고(교수님 얘기로는 이게 가장 사고가 많은 곡이라고 한다. 2박자-4박자-8박자-16박자로 이어지는 돌림 형식이라 사람마다 다르게 길이를 해석하는 경우가 있다는 것이다) 곡의 구성 또한 조지윈스턴의 캐논변주곡과 비슷하게 구성하여 익숙하게 다가왔다.

신기했던 건, 그 그룹이 일본인들이라서 중간중간 한국어로 멘트를 할 때는 발음이 매우 어색했으나, 한국곡인 '고향의 봄'을 불렀을 때는 그다지 어색하지 않았다는 점이다. 보통 말하는 것과 성악으로 부르는 것과 발음하는 영역이 뇌에서 분리되어 있기라도 한 건가? -_-;

외국 공연이 처음이라는 멘트에 많은 사람들이 격려의 갈채를 보냈고, 이것이 그들의 대강당 안을 꽉 채우는 천상의 목소리와 맞물려 전원 기립 박수를 이끌어낸 것이 아닌가 싶다. 하여튼, 간만에 멋진 공연을 보니 그동안 숙제에 찌들었던(?) 정신을 다시 잡을 수 있어서 좋다.

내가 있는 동아리 중 하나의 정모 시간이 금요일 저녁이다. 그런데 나는 수업이 월요일부터 목요일까지만 있어서, 특별히 바쁜 일이 있거나 시험 기간이 아닌 경우에는 웬만하면 금요일에 집에 가는 편이다. 그래서 정모를 목요일로 했으면 좋겠다는 댓글을 동아리 홈페이지에 올렸었는데, 나 말고도 목요일을 정모 시간으로 했으면 좋겠다는 사람들이 꽤 있었다. (물론 이유는 나와 다르겠지만..) 그러자 다른 사람들이 "동아리원들이 정모 끝나고 모여서 편하게 놀 수 있는 요일이 금요일이기 때문"이라는 이유를 말했다. 뭐 그렇다면 나도 그 이유에 반대할 생각은 없다.

하지만 어느 선배가 다신 댓글이 조금 마음에 안 들었다. "너희들 집은 학교이고 기숙사고 동방이지 않나? 집에 간다는 생각부터가 이상한 것 같은데. 이제 어른이라고 하기에는 미성년자도 많구나. 안습"이라는 것이다.

나는 왜 집이 학교나 동방이 되어야 하는지 전혀 이해할 수 없다. 다만 학교가 집에서 멀리 떨어져 있기 때문에 기숙사 생활을 하는 것뿐이지 그 이상도 이하도 아닌데 말이다. (물론 전원 기숙사제를 택해서 집이 가까운 사람들도 기숙사 생활을 하기는 하지만, 원하는 경우는 원룸을 얻어서 나가 살 수도 있고 집에서 다닐 수도 있다. 다만 학교 생활을 하는 데 있어 기숙사에 사는 것이 여러모로 편리하기 때문에 기숙사를 택하는 것이다.)

내가 집에 가는 이유는, 내가 마마보이라서가 아니다. 다만 가족끼리 주말에 모여 서로 얼굴도 보고 같이 밥도 먹으면서 유대 관계를 다지는 것, 그리고 자전거 타기나 피아노 치기 등의 취미 생활을 학교에서보다 훨씬 자유롭고 편하게 할 수 있기 때문이다. 또 한 가지 이유는 학교나 그 근처에서만 밥을 먹다보면 금방 질리고 질도 낮기 때문에 집에서 주는 밥과 다양한 과일 등을 먹어 영양 보충(-_-)을 하는 것이다. 친구와 친하게 지내면 친구 집에 자주 놀러갈 수 있듯이, 나는 부모님과 가족들과 친하게 지내기 때문에 집에 자주 가는 것이라고도 볼 수 있다. (이를 테면 내가 관심 있는 디자인이나 건축에 관한 이야기를 건축가이신 아버지와 하는 것이 좋다든가 말이다.)

그렇다고 내가 모든 걸 집에 의존하는 건 아니다. 빨래 같은 정도는 거의 다 학교에서 해결한다. (집에는 여기서 세탁이 곤란한 외투, 손상되기 쉬운 의류 등을 가져가서 빨아온다) 피아노가 학교에도 있는데 왜 집에 가서 치냐고 묻는다면, 일단 내가 사는 신축 기숙사 근처에 피아노를 칠 수 있는 장소가 없어서 수백m ~ 1km 이상 되는 거리를 가서야 피아노를 칠 수 있다는 점과 집에서 연습하는 것이 가장 편안하고 여유롭게 할 수 있다는 점, 집의 피아노 소리가 더 좋다는 점 등을 들 수 있겠다. 또한, 아버지를 통해 시작한 산악 자전거(MTB)도 집에서 타야 하는 것도 큰 이유다. 주중에는 맘먹고 운동할 시간을 내기가 쉽지 않아서 주로 주말에 집에서 운동하는 편이다. (겨울에 별로 못했기 때문에 이제 날씨가 풀리면 다시 시작할 것이다)

어쨌든, 이러한 내 개인적인 모든 이유를 제쳐놓고라도, 어른이라고 해서 집에서 떠나 생활하면 집에 가지 말아야 하는 것인가? 갈 수 있는 여건이 되면 얼마든지 갈 수 있는 것이고, 집이란 생활 재충전의 장소 아닌가? (물론 기숙사에서 자는 것도 재충전이지만, 집에 가는 건 취미 생활 등을 통한 또다른 의미의 재충전이다, 그렇다고 내가 기숙사에 정을 붙이지 못한다거나 그런 건 또 아니다. 기숙사는 집에서보다 보는 관점에 따라 오히려 더 privacy를 보장받을 수도 있는 등 다른 이점이 있다.)

마치 집에 가는 것이 이상한 사람인 것마냥 취급하는 것 같아서 주절거려봤다.

덧. 만약 나보고 동아리와 집 중에서 선택하라고 한다면 집을 선택할 것이다. 물론 그것이 100% 항상 그런 것은 아니고 어느 때는 동아리를 선택할 수도 있다. 하지만 궁극적으로 집에 두는 가치가 나에겐 더 우선순위다. 그렇다고 내가 '독립적인' 사람이 되지 못할 이유는 없다. 필요하다면 집을 떠나 오랫동안 떨어져 있을 수도 있는 것이고, 다만 여건이 된다면 집에 자주 가고 싶다는 것이다.

아까 저녁 먹다가 YTN 뉴스에서 보기도 했고, 최근 카이스트 신문사 등에서 설문 조사를 벌이기도 하는 등 안팎으로 많이 시끄러운 모양이다. 그렇지만 러플린이 관련된 일을 직접 해보지 않은 학생들은 거의 모를 것이다. 사실 나조차도 shell 짜기 숙제, 동아리 활동 등으로 정신 없는 생활을 하고 있었기 때문에 막연히 교수들하고 사이가 안 좋다는 소리만 들었을 뿐 이 정도까지인 줄은 몰랐으니까.

지난 월요일에 스팍스 정모가 있었는데, MBC 시사매거진 2580에서 동아리방에 취재를 하러 왔었다. (그쪽에서는 몰랐던 모양인데 정모 시간과 정확히 맞아서 많은 사람들이 얘기를 해줄 수 있었다) 그러면서 총장의 연임 문제에 대해 어떻게 생각하는지 일일이 물어보고 촬영까지 해갔다. (이번 일요일인 4월 2일날 방송이라고 하는데, 워낙 많이 찍어가서 편집되었을 가능성이 높긴 하지만 보긴 봐야지. -_-)

하여튼, 내 개인적인 생각을 정리하면 이렇다. 러플린이 제시했던 비전과 개혁의 방향은 바람직하나, 그가 일을 추진하는 방식이 교수진들의 분위기와 잘 맞지 않았고, 자기만의 의견을 지나치게 고집했다는 점(KAIST PR Website를 만들 때도, 신문사 홈페이지 개편할 때도 CSS를 쓰지 말라고 고집한 것같이 작은 일부터 시작해서 학교 정책까지 그렇게 관여했던 모양이다)이 문제다. 사실 나는 러플린 자체보다도, 러플린이 단지 노벨상을 받은 훌륭한 물리학자이며 스탠포드의 학과장을 했었기 때문에 그 '간판'에 눈이 멀어서 데려왔다는 사실이 마음에 들지 않는다. (물론 기타 다른 이유도 있겠지만, '노벨상'이라는 것과 학교 경영과는 그다지 관련이 없는데도 매우 적절한 사람을 데려온 것인양 그랬던 분위기가 싫다는 것이다)

그가 말했던 학교 예산을 늘리고 보다 자유롭게 경영할 수 있도록 하기 위한 사립화, 의학이나 법학 과정의 신설, 예술 등 교양 과목 확충, 영어 사용 확대 등은 전반적으로 찬성하는 편이다. 어쨌든 교수들의 반대로 연임을 할 수는 없게 되었으니, 이러한 비전을 잘 추진할 수 있는, 보다 리더십 있고 융통성 있는 사람이 총장이 되었으면 좋겠다.

결국 집에 와서 만들어야 할 shell은 안 만들고 mail box rotator나 만들고 앉아있다. orz

그래도, mutt로 스팍스 메일함 확인할 때마다 수천 통이 넘는 메일을 읽느라 느려지는 게 계속 신경쓰여서 결국 python으로 삽질해가며 만들어내고 말았다.

가장 삽질이었던 부분은, for line in file 형태로 파일을 읽어나가면, seek 등의 다른 파일 조작 함수를 혼용할 수 없다는 사실이었다. (저런 for-in 루프로 읽으면 자체적으로 버퍼링을 하기 때문에 seek 등이 오동작을 일으킨다) python documentation을 자세히 읽어본 뒤에야 그 사실을 알 수 있었다. orz

그것 말고 또 한참 삽질하게 만든 것은, string concatenation이 매우 비효율적이라는 점이었다. (python의 string도 java처럼 immutable string이니까, 매번 새로운 string 개체를 생성해서 복사하니 느릴 수밖에 없다) 그래서 가급적 불필요한 concatenation을 없애고 파일에 기록하는 것은 바로 파일에 쓰는 방식으로 했다. 그리고 ''.join(sequence)라는 구문이 있었으니... 오, 나의 구세주여. -_-; (구글에서 검색해본 결과 ''.join이 상당히 빠르다는 사실을 알 수 있었다.)

어쨌든, 그 결과물은 여기서 볼 수 있다. BSD License이니 쓰실 분은 맘대로 쓰셔도 좋으나 메일 분실, 데이터 손실 등에 대한 책임은 지지 않는다. 자, 이제 슬슬 shell을 짜야지...

전산학, 디자인, 건축. 이들의 공통점은 무엇일까. 요즘 듣는 수업들을 잘 정리해보니 결국 한 가지를 말하고 있었다. 잠시 시간을 내어 글로 기록하고자 한다.

송준화 교수님이 강의하시는 System Programming 수업을 들으면서, 정작 그 과목 내용보다는 전산학을 바라보는 자세에 대해서 더 많은 이야기를 듣고 있다. (프로젝트로 Linux Shell을 2주만에 짜라거나, 조그마한 cpu 아키텍처를 가지고 thread manager, application을 가지는 toy-os를 만들어오라고 했다거나 하는 빡센 숙제는 제외하고 말이다. -_-) 수업에서 누차 얘기하시는 그 교수님의 요점은 '전산학은 당구 배우듯 직접 부딪치면서 배워야 한다'는 것이다. 나도 점차 경험을 쌓아가면서 느끼는 것이지만, 교수님 말씀처럼 전산학은 한 마디로 컴퓨터 프로그램이나 서비스 등을 협동 창작하는 일이다. 물론 그 와중에 알고리즘, DB, 분산 처리, 인공지능 등 갖가지 기술과 학문적인 내용들이 들어가긴 하나, 넓은 시각에서 바라봤을 때는 결국 근현대 이후의 디자인이나 건축과 같이 여러 사람이 하나의 목표를 이루어내는 작업이 된 것이다. (특히 컴퓨터를 디자인·설계하는 입장에서 바라보는 관점을 원하시는 듯하다)

한편, 이건표 교수님이 강의하시는 디자인 문화와 기술이란 산디과 과목에서는, Design에 대해서 단순히 Fashion, Style, Drawing 등을 말하는 것이 아니라 기획자, 마케터, 디자이너, 기술자, 소비자, 사회의 관점에서 제품 디자인이 어떤 의미를 가지게 되는지, 궁극적으로 invent concept을 하려면 새로운 기술과 새로운 시각을 가져야 한다는 것을 이야기하고 있다. 또한 디자인의 역사를 다루면서, 과거에는 장인이 모든 것을 혼자 해결했지만, maker와 thinker(designer)가 분리되기 시작한 후로 cooperate design(소비자와의 협동이든 디자이너들 사이의 협동이든 제작자와의 협동이든..)의 역할이 점점 커지고 있음을 말하였다.

아버지가 건축가시기도 해서, 어렸을 때부터 관심을 많이 가졌던 것 중 하나는 단연 건축이다. 공학과 예술의 결합이라고 볼 수도 있고, '공간에 대한 디자인'이라는 개념으로 볼 수도 있다. 하지만 여기서 내가 말하고자 하는 것은 결국 협동 창작이라는 것이다. 작은 건물이나 기념물 등은 혼자 설계할 수도 있겠지만, 수주부터 시작하여 공법 선택, 구조역학적 설계, 전기·수도 배치, 인테리어, 외관 디자인, 적법성 검토, 안전 점검, 조경 등을 혼자 다 하는 건 거의 불가능에 가깝다.

전산학 또한 점점 복합적인 기능을 요구하기 시작하면서, 서버측 프로그래밍, 웹클라이언트 프로그래밍, Database 등의 backend, GUI 설계, 통신과 동기화, 대용량 서버 및 분산 처리 기술, 검색, cross-platform, XML 등 수많은 분야에 대한 지식을 요구하고 있다. 역시 이를 한 사람이 다 마스터하기도 힘들고, 설령 그렇다고 해도 주어진 시간 내에 혼자서 모든 작업을 다 완성하는 것은 거의 불가능하다.

게다가, 바이오정보전자개론에서도 강조하고 있는 이야기지만, 앞으로는 점점 학문 간 융합이 추진될 것이며, 어느 한 학문만 깊이 알고 있는 것보다는, 다양한 학문에 대한 소양을 가지고 이들을 잘 조합해 새로운 것을 찾아내는 능력이 더 중요해지고 있다.

위에서 말했던 것들을 대체로 내가 관심 있는 분야들이다. (추가하자면 로봇 공학 등이 더 있겠다. 역시 기계공학, 전자공학, 전산학 융합의 결과다.) 내가 앞으로 무엇을 하든, 가장 중요한 것은 다른 학문을 하는 사람들이 하는 이야기를 잘 이해하고 내가 원하는 바를 쉽게 전달할 수 있는 의사 소통이다.

헌데, 이 의사소통을 잘 하는 사람을 아직 찾지 못했다. 물론 나 자신도 잘 한다고 말할 수는 없다. 그런 문제를 특히 느꼈던 건 지난 겨울방학 때 진행했던 OCO 프로젝트와 경기과학고 홈페이지 프로젝트였다. 자기가 무엇을 모르는지, 어떻게 참여해야 하는지 등을 서로 보완해주어야 하는데, 각자가 잘 모르고 있었다. 그 결과는 경기과학고 홈페이지의 스파게티 코드와 실패였다. (OCO의 경우는 훨씬 낫지만, 초창기 개발 단계에서 다른 사람들이 컨셉을 잘 이해하지 못해 애를 먹었다.)

그나마 의사 소통 문제가 가장 적었던 경우는, 친구 준호와 진행했던 과학전람회 및 휴먼테크 논문 준비 과정이었다. 그 녀석은 물리와 말로 설명하기를 잘 했고, 나는 프로그래밍과 글로 설명하기를 잘 했다. 주제는 음향·물리 쪽이었지만, 그런 서로의 상보적인 능력과 잘 통하는 의사소통으로 큰 시너지 효과를 얻을 수 있었다. 이론적인 계산이나 고찰, 그리고 발표는 준호가 맡았고, 나는 실제 실험 데이터를 분석할 때 프로그래밍 실력을 발휘하고 논문을 작성했다. (준호가 발표를 조금 더 잘하긴 했지만 나도 발표를 잘 하는 편이었기 때문에 서로가 편한 것도 있었고, 발표력을 바탕으로 서로의 의사소통이 잘 이루어진 것 같다)

아마도, 앞으로 나와 같은 공학도·과학도들은 살면서 이러한 의사소통 문제가 더욱 중요해질 것이다. 사실 이런 이야기는 많이 들어왔겠지만, 진로를 심각하게 고민하고 있고 직간접적인 경험을 하고 있는 나로서는 매우 크게 다가오는 이야기다. 얼마 전 바이오시스템학과에 가기로 한 한 친구와 점심을 먹은 적이 있다. 이야기하면서 관심사가 상당히 비슷함을 알 수 있었는데, 그 아이도 결국 앞으로는 다양한 분야에 대한 지식을 가지고 의사소통을 잘 하는 것이 중요하다고 말했다. 생물 쪽으로 공부를 했던 친구인데, 내가 전산을 잘 하면서 생물 쪽도 잘 이해하는 게 한편으론 부러운 모양이었다. (이 점에 대해서는 고등학교 선생님들께 매우 감사한다. 생물을 너무 빡세게 배워놓아서, 어지간한 내용은 거의 다 바로 이해하고 받아들여지고 있다.)

이러한 생각들을 종합해보면, 다양성에 대한 이해, 통찰력에서 나오는 창의성, 그 모든 것을 받쳐주는 의사소통 능력—앞으로는 이것들이 과학도·공학도로서의 삶에 대한 키워드가 되지 않을까 싶다.

오늘부터 태터 센터가 조금 바뀌었다. 개발 블로그가 따로 분리되고 사용자 중심의 공간이 따로 분리되었다. 앞으로 소스가 공개되어 본격적인 개발자 커뮤니티가 생기면 이들은 좀더 분명하게 구분될 것이다. (내 생각엔 dev.tattertools.com, dev.tattertools.com/blog, tatterstory.net이 각각 개발자 커뮤니티, 개발 블로그, 사용자 중심 블로그의 역할을 맡았으면 하는데, 노정석 님이 주로 블로깅을 해왔다는 역사적인 이유로 인해 tatterstory.net이 개발 블로그가 되어 url 상에서 조금 혼동이 생길 것 같다. 개인적으로는 소스 코드 공개를 하면서 url들도 싹 정리했으면 한다.)

여하튼, "태터툴즈 가이드북"이 출판된다는 소식 자체는 참 고무적이다. 주변 사람들 중에도 설치형 블로그를 사용해보고 싶지만 어려움을 느끼는 사람들이 많은데, 책으로 잘 정리되어 나온다면 큰 도움이 될 것이다. (문제는 mysql, 웹호스팅 계정, ftp 업로드 등의 개념을 초보자에게 알기 쉽게 설명하는 것이 그리 쉽지만은 않을 거란 사실이다) 또한 나부터라도 기념 등의 이유로 그 책을 하나 둘 사서 보게 될 것 같으니, 적게나마 태터툴즈의 재정(?)에도 도움이 될 것 같다.

태터툴즈가 더 대중성을 띠고 사용자층을 폭넓게 확보하려면 설치의 장벽을 넘어야 하는데, 이렇게 가이드북을 낸다는 건 그쪽으로 크게 신경쓰겠다는 뜻도 된다. 앞으로 더 대중들에게 쉽게 다가설 수 있는 태터툴즈가 되길 바란다. (그래야만 수익 모델도 세워지고 장기적인 발전이 가능할 것이다)

일단 이사는 잘 되었습니다. 곧 permalink 처리를 한 후 기존 태터를 완전히 삭제할 예정입니다. (물론 제가 만든 스킨은 남겨두었다가 나중에 공개해버릴 생각입니다)

일단 스킨은 Hemingway white를 적용했습니다. 새로운 스킨을 제작하기 전까지는 아마 이 스킨을 살짝살짝 고쳐나가는 식으로 유지할 것 같군요. (불행히 xhtml validation까지는 안 되는군요..;;)

어쨌든 수식 플러그인도 깔고 본격적인 태터 1.0의 생활에 적응해야겠습니다.

수식 플러그인 테스트 : [tex]\int_{-\infty}^{\infty}\sqrt{\frac{x^2-4ac}{2x}}dx[/tex]

글 수정 테스트...

이제 기초 과목들은 응미나 확통을 빼고는 거의 다 들은 상태다. 슬슬 전공 과목들을 듣고 있는데, 수업은 마치 교양 같은 분위기였던 System Programming 과목의 첫 번째 과제가 무려 Linux/Unix Shell 짜기. 아직 리눅스를 써보지도 않은 수강생들이 꽤 되는데도 이걸 2주만에 짜라는 것이다.

비록 스페셜포스에 말려서 쉘을 짜지는 못했지만 나는 작년에 들었던 스팍스의 SP 세미나 덕분에 어떤 것들을 구현해야 할지, 대충 어떤 구조가 될 지 감이 오고 있지만, 역시 실제로 구현하는 건 시간이 상당히 걸릴 것이다.

역시 전공 과목의 포스인 건지... 시험 전날이 3번째 프로젝트의 듀로 되어 있으니 할 말 다했다. (첫 숙제가 쉘짜기이니 아마 어셈블리로 계산기 짜는 정도는 기본으로 나오지 않을까...-_- 참고로 친구 녀석 하나가 방학 때 하루 이틀 정도 밤을 새면서 2주 내내 짰다고 한다.)

어째 이번 학기가 예상보다 빡쎄질 것 같다. 그나마 바이오정보전자개론에서 다루고 있는 sequence alignment 문제는 예전에 R&E를 통해 비슷한 알고리즘을 만들어 본 적이 있어 쉽게 이해할 수 있었고, 고등학교 때 빡쎄게 배운 생물 덕(DNA에서 RNA로 전사되고 리보솜에서 단백질로 합쳐지는 과정을 효소 이름까지 다 외워서 서술형으로 시험을 봐야 했을 정도였으니 말이다)을 톡톡히 보고 있어서 다행이다. 아무튼 이번 학기도 빡쎄지만 흥미로운 학기가 될 것 갈다.

덧. 그리고 전산과 3학년 과목인 Programmign Language를 더 신청했는데, 수업을 들어보니 그럭저럭 들을 만 하다. (예전부터 배우고 싶었던 lisp을 다루고 있다)

안 그래도 몸살에 걸려서 추위를 많이 타는 상태인데 눈보라까지 치더니 하루종일 눈이 퍼부었다. 태어나서 눈이 이렇게 많이 쏟아지는 광경을 보기는 처음이다. (전체적으로 내린 양이 그리 많지는 않았으나, 절정일 때는 정말 한 치 앞을 보기 힘들 정도였다)

선배들은 2004년 3월에 내린 폭설로 학교가 거의 마비되다시피했던 기억을 떠올렸고, 세종대왕 동상과 까리용은 모두 하얀 가루로 장식되었다. 봄기운이 한창 올라야 할 3월 중순에 갑자기 설경이 펼쳐졌다.

3월에 눈발이 흩날리는 경우가 아주 드문 건 아니지만, 앞으로는 꽃샘 추위보다는 꽃샘 눈보라라고 불러야 할 것 같다. 점점 기후가 이상해지는 걸까? 내가 초등학교 때 느끼던 사계절의 변화와 지금 느끼는 사계절의 변화만 해도 상당히 다른 느낌이다. 봄과 가을은 아주 짧아져 거의 느끼지 못할 정도가 돼버렸고, 봄엔 추위가, 가을엔 더위가 기승을 부리는 것 같다. 그리고 여름과 겨울은 더 덥고 더 추운 것 같다. (사실 이번 겨울 전까지만 해도 겨울이 너무 따뜻해서 겨울답지 않다는 생각이 많이 들었으나 이번 겨울은 굉장히 추웠다)

내년 날씨는 또 어떤 모습을 보이게 될까?

어제 드디어 태터툴즈 오픈하우스 행사가 있었다. 전날 스팍스 개강파티에서 맥주와 소주를 짬뽕해서 마신 것이 집안 내력(12시간 가까이 자고 글을 쓰는 지금도 계속 머리가 아프고 정신이 없는데, 내가 어머니 체질을 닮아 술을 섞어마시면 안 된다고 한다.. -_-)으로 엄청난 후유증을 가져다주고 있었지만 KAIST에서 거의 불가능한(?) 7시 40분에 기상하여 4일째 술을 퍼마신(..) 친구(배터리)를 끌어내다시피하여 서울로 올라갔다.

깔끔하게 와이셔츠와 넥타이까지 딱 맞춰입은 태터&컴퍼니 분들을 보면서 즐겁게(그러나 후유증으로 힘들게..) 발표를 보았다. 이미 전에도 얼추 알고 있었던 거라 크게 새로운 내용은 없었다. 다만 GPL화를 한 이유에 대해서 권순선 님이 그리 하라 하셔서 했다는 것이 황당(^^)했고, 태터툴즈의 전반적인 프로그램 구조를 알 수 있었다.

블로그에서만 보았던 포항공대 물리학 석사과정에 계시는 신정규님(inureyes)도 만나 인사를 나누었고, 라이브블로그 때 이미 만났던 함장님도 다시 볼 수 있었다.

사실 세미나보다 더 많은 이야기가 오간 것은 저녁 식사였다. 저녁을 먹을 건지 말 건지 잘 모르는 가운데 배터리(끝나고 대전으로 다시 내려가야 했으므로)가 저녁 먹기가 애매해 보여서 끝까지 기다렸고, 가까운 음식점에서 태터&컴퍼니 분들, 함장님 등 몇몇 블로거들과 식사를 같이 할 수 있었다.

식사 때 내가 물어본 것은, 일반 사용자들의 참여를 이끌어낼 방법이 없겠는가 하는 점, 태터툴즈와 이올린의 다양한 변형을 통한 수익 모델 창출에 대해 더 구체적인 계획이 있는가 하는 점 등이었다. 어느 분이 글마다 키워드 사용 여부를 선택할 수 있게 해달라고 하길래, 기왕 하는 거 글마다 어떤 키워드를 쓸 건지 말 건지 설정할 수 있게 해달라고 했더니 노정석 님께서 "원래 우리 회사에서는 아이디어 낸 사람이 만드는 것"이라며 나보고 만들어달라고 하셨다. -,.-

집단 지성이라는 것은, 만들기 전에 집단 지성을 강조해서 되는 것이 아니라 철저한 개인화와 소통 채널의 확보가 있어야 자연스레 이루어진다는 점, 그리고 자기에게 이익이 된다는 점을 알아야 tag cloud의 제대로 된 가치가 발현된다는 점 등을 이야기했다.

또, 장기적인 수익 사업이라고 보기는 어렵지만 설치형 블로그라는 한계를 극복하기 위한 블로그 서비스를 해보는 게 어떻겠냐 하는 의견도 나왔다. (호스팅처럼 계정을 제공하는 건 아니고, 이글루스처럼 가입해서 바로 블로그를 쓸 수 있는 형태 말이다) 이 부분에 대해서는 노정석 님도 고려해보겠다는 눈치셨다.

Tiny Core, Rich Components를 목표로 소스 코드를 대폭 수정하고 있다는 이야기도 하셨는데, 역시 나도 그런 방향에 동의하는 입장이다. (개발은 잠시 중단했지만 내가 만들던 Java IRC Bot도 그걸 목표로 하고 있으며 현재 나온 대부분의 IRC Bot들도 그런 방식이다.) 특히 오픈소스화된다면 필수적인 부분이 될 것이다.

버그 트래킹 시스템으로는 어떤 걸 쓸까 하는 이야기도 나왔는데, 내 서버에서 토끼군이 쓰고 있는 trac 같은 것이 괜찮을 것 같다는 의견이 있었다.

다 기억나지는 않지만 대략 이런 이야기들이 오갔다. 집에 오자마자 거의 뻗다시피해서 12시간 가까지 잠을 잤는데도 아직도 머리가 지끈거리고 있다. orz 어쨌든 다음에도 이런 오픈하우스 행사를 계속 할 예정이라고 하니 태터툴즈에 관심 있는 사람들은 참가해도 좋을 것이다.

덧. tattertools.com에서 기술적인 부분과 사용자 중심적인 부분을 분리하게 될 거라고 하셨다. 확실히 아직 초보자가 다가서기에는 어려워보인다.

예전에도 한 번 글 쓴 적이 있는데, 다시 전공 선택에 관한 글이다. 이제는 상당히 생각이 정리되어서, 일단 전산과 하나는 확정이다. 그리고 산업디자인과는 과감히 버리기로 했다. 산업디자인 그 자체에 매력이 있긴 하지만, 뭔가 더 challenging한 것을 하기에는 이공계통 분야가 더 낫다는 생각이 들었기 때문이다.

문제는, 전산 하나만 해서는 아예 software developer 쪽으로 나가지 않는 이상 학문적으로 무언가 이루기는 어렵다는 것이다. (인공지능이나 검색엔진 쪽을 죽어라 파면 또 모를까.) 그래서 다양한 부전공들을 생각해보고 있다.

전산과 전공 + 수학과(응용수학과) 부전공

가장 일반적인 조합이다. 그래픽 엔진 제작 등을 할 사람이라면 추천한다. 하지만 난 그쪽에는 그다지 취미가 없다. -_- 또한 수학 자체를 파고드는 것도 별로 좋아하지는 않는다.

전산과 전공 + 물리과 부전공

이것도 나름대로 괜찮다. 통계물리학 쪽은 특히 프로그래밍을 많이 필요로 하기 때문이다. 하지만 이렇게 할 바에야 물리 전공 + 전산과 부전공이 나을 것 같다.

전산과 전공 + 바시과/생물과 부전공

최근까지 가장 많이 생각해본 조합이다. 하지만 현재 바이오가 대세이기 때문에 경쟁자가 많다는 점이 악조건으로 작용한다. 또한 바이오시스템학과가 다양한 분야에 대해서 가르치기는 하지만 무언가 엑기스가 빠진 것 같다는 평을 많이 듣고 있어 망설여진다.
이쪽으로 가려면 먼저 생화학부터 넘어야 한다. -_-;

전산과 전공 + 기계과 부전공

가장 드문 조합 중 하나인데, 스팍스 선배 중 전산과 전공 + 항공우주공학 부전공(이지만 거의 복수 전공에 가까울 정도로 수업을 들었다)을 하시고 이번에 스탠포드에 합격하신 분이 있다. 그 분이 추천하는 조합이기도 하고, 전에 기계과 설명회 갔을 때부터 급격하게 고려하기 시작한 조합이다.
구체적으로, 기계과 실험 과목 두 개와 4대 역학부터 시작해야 할 것이다.

마음에 끌리는 정도, 앞으로의 발전 가능성 등을 종합적으로 고려해봤을 때, 마지막 조합인 전산과 전공 + 기계과 부전공이 가장 나아 보인다. 기계과를 전공으로 할 수도 있으나 전산 쪽에 더 취미가 있기 때문에 이쪽을 전공으로 하는 것이 무리가 없을 것이다.

문제는, 2학년 과목들에 해당하는 4대 역학이 봄/가을에 2개씩 개설한다는 점인데, 고체역학과 열역학 모두 기계과 쪽 교수님 과목으로는 전부 이산구조와 System Programming과 겹쳐버린다는 점이다. 일단 맛보기(?)로 기계기초실습을 수강해볼까 한다. (이번 학기 시간표를 매우 널럴하게 짜놨기 때문에 큰 무리는 없을 것이다.)

그렇다면 남은 것은 그 넓디 넓은 기계공학 분야에서도 어느 쪽으로 갈 것인가 하는 점이다. 추후 교수님들을 만나 상담을 더 해봐야겠지만, 역시 로봇공학 쪽이 될 가능성이 높다. 전산과의 시너지를 활용하기에도 아주 딱이다. (사실 로봇에서도 하드웨어보다 소프트웨어가 중요해지고 있다는 얘기는 심심찮게 들린다)

가을 학기에는 동역학과 다른 역학 1개 혹은 기계공학실험 쪽을 듣고, 전산과 과목으로는 아키텍처와 PL 쪽을 듣는 게 어떨까 싶다. (시간이 겹칠 지는 아직 모르겠다) 앞으로 수강 계획을 잘 세워봐야겠다.

얼마 전에 KAIST에서 물리학 석사를 하시는 한 분의 블로그를 읽고 생각난 것이 있었다. 그 분이 자주 인용하시는 신해철 씨의 말 중에,

더 웃긴 건, 그렇게 후배들에게 술을 강요하는 선배들이 술자리에서 나중에 사회 정의가 어쩌고, 민주주의가 어쩌고 하며 떠드는데.. 술을 거부하는 사람에게는 강요하지 않는 생활 속의 작은 민주주의조차 실천하지 않는 사람들이 무슨 사회 정의고, 무슨 민주주의 타령이란 말입니까.

를 보고 떠오른 것이다.

그 글을 읽기 좀 더 전에, 동아리 선배인 미래 누나가 해준 이야기가 있다. 자기가 전에 다른 학교의 과 개강파티에 참석할 기회가 있었는데, 카이스트의 "술먹고 죽자"와는 완전히 다른, 정말 개인의 특성을 살린 장기 자랑(단순히 노래나 춤이 아닌 시 낭송부터 시작해서 음악 연주에 이르는..)을 하는 걸 보고 문화 충격을 받았다는 것이다. 작년부터 처음 시도하는 걸로 반응도 좋고 교수도 같이 참여한다고 한다. 과연 카이스트에서도 그런 게 가능할까?

이런 내 코멘트에 달린 그 석사분의 답변이 더 마음에 와닿는다. (역시 신해철 씨의 이야기라고 함-_-)

우리 나라에서는 고등학교 때까지 학생들에게 노는 법을 가르쳐 주지 않기 때문에, 대학 와서 사람들이 어떻게 놀아야 하는지 모르다보니.. 남에게 술 먹이는 것 외에는 분위기를 어떻게 띄우는지 전혀 모르는 찌질이들이 술자리를 장악하게 됩니다.

그렇다. 나도 여러 사람이 모였을 때 어떻게 노는 것이 가장 좋을지 모른다. 결국 술마시러 가거나, 노래방, 잘 해야 보드게임방 정도를 분위기 따라 따라갈 뿐이다. (물론, 저기서 말하는 찌질이가 술자리가 아닌 다른 상황에서는 찌질이가 아닌 경우가 더 많겠지만..)

또 전에 한 선배가 말하길 "요즘은 점점 갈수록 신입생들이 술 마시는 걸 싫어하는 것 같다"는 말도 하셨는데, 이렇게 되면 점점 문화 공백이 생기게 된다. 선배들은 술과 노래방으로 노는 문화를 만들어왔지만, 그것을 대체할 대안은 존재하지 않는 상태에서 술·노래를 강요하지 않는 분위기가 정착된다면?

사실 술을 마시면서 오손도손 얘기하는 것이 친해지는 데 도움이 되는 것은 사실이나, 선후배 관계에서 소위 "예절"이라는 것이 있기 때문에 술로부터 자유롭지 못하다. 노래방은 그래도 한결 낫긴 하지만, 노래에 소질이 없거나 음악 취향이 달라서(나처럼 instrumental 쪽을 좋아하는 경우) 부를 노래가 없거나 하는 경우도 놀이 문화에 적응할 수 없게 되는 것이다.

역시 신입생 환영회라는 자리에서 장기자랑이로 거의 무조건 노래나 춤을 요구하는 것도 마찬가지다. (못하면 술을 마시던가..) 뭔가 그 다음날을 생각하는 건 전혀 보이지 않고, "술먹고 죽자" 식의 분위기..

결국 근본적인 문제는 사람들끼리 쉽게 어울리고 즐길 수 있는, 그러면서 상대방을 존중하고 배려하는 놀이 문화의 부재다. 자연스럽게 어울릴 수 있는 문화가 정착되지 않는 한 신입생들의 술에 의한 고역은 매년 계속될 것이다.

저번 겨울 방학 후반부터 시작한 2006년 SPARCS 프로젝트인 OCO(Open Course-site Organizer)를 출품한 IT Festival이 그제와 어제 이틀 동안 열리고 끝났다. 아쉽게 상은 못 받았지만, 다른 학교의 IT 동아리들은 어떤 수준에서 어떤 아이디어로 개발을 하고 있는지 살펴볼 수 있는 기회였다. (아, 서울대 UPnL 작품도 나왔는데 거기서 stania 님도 볼 수 있었다;;)

초반 개발을 거의 내가 하고, 그 코드를 기반으로 다른 사람들이 작업을 시작하는 데 시간이 많이 걸린 게 아쉬웠다. (사람들이 프로그래밍을 잘 못하거나 그런 건 아니나 웹프로그래밍과 XML에 대해 익숙하지 않아 단시간에 그걸 응용할 수 없었던 것이다. 물론 나도 처음부터 아주 잘 하는 건 아니었고, 삽질하면서 배우고 있다. -_-) 아무래도 소프트웨어인데다 웹프로그래밍이라 겉으로 뭔가 만들었다고 보여주지 못하는 게 심사위원들에게 점수를 못 받은 부분이 된 것 같다. 그리고 OCO 프로젝트의 의도인 "과목 정보 공개" 자체에 대해 상당히 거부감을 보이시는 심사위원(교수)도 있었다. (물론 우리도 기획 과정에서 그런 이야기가 나왔었고 그에 대한 우리의 입장을 설명해주긴 했다)

최고상인 정보통신부장관상을 받은 인하대 로보트연구회의 Mementory 작품의 경우, 역시 기술적으로 아주 뛰어난 건 없었지만 일상의 모든 것을 기록한다는 그 아이디어와 취지가 좋았다. (그 작품을 봤을 때 딱 그런 생각을 했었는데 역시 최고상을 받더라.) 온도, 압력, GPS, 소형카메라, 맥박수 등을 재는 센서가 달린 작은 기기를 가지고 다니면서 USB 메모리에 그 정보를 일정 주기로 계속 기록하고 나중에 PC에서 읽어들여 personal memory 형태로 저장/관리할 수 있는 작품이었다.

그 외의 다른 동아리들은 주로 메신저, 보안 프로그램 등을 선보였는데 그다지 아이디어의 뛰어남 등은 보이지 않았고 기술적으로도 대동소이한 듯 싶었다. (개발 언어가 다르다거나 그런 차이랄까..) 내가 MR이기 때문에 더 유심히 지켜본 Mirage에서는 블루투스의 신호 강도를 이용해 전시장 등에서 특정 위치에 가까이 접근할 경우 그 부근에 대한 설명을 해준다거나 하는 장치를 만들었다. 기술적인 시도는 좋았지만 아이디어는 이미 상용화까지 이루어진 부분이라 점수를 못 받은 것 같다.

뭐, 전시 내용은 괜찮았는데 주최 측에게 몇 가지 이야기하고 싶은 게 있다.

먼저, 첫째 날 경품 추첨에서 내가 넣은 표가 무려 PMP에 당첨이 되었는데, 당첨자 발표 당시 최소 1명씩은 부스를 지키고 있으라고 하는 말에 나와 몇몇이 남아 있었던 것이 화근(?)이 되어 상품을 못 받았다. 그래서 동아리 선배들이 그쪽에 항의했으나 본인이 없었기 때문에 소용이 없다는 식이었던 것 같다. (나는 전혀 모르고 부스를 지키고 있다가 나중에 얘기해줘서 알았기 때문에 달리 대처할 수가 없었다. 이미 재추첨으로 다른 사람에게 상품이 넘어간 후였다.)

사전에 본인이 반드시 참석해야 한다거나, 아니면 부스를 지키는 인원에 대한 별도의 안내·조치가 있어야 했는데 그런 것이 전혀 없었기 때문에(추첨 카드에는 연락처만 적게 되어 있었다) 이는 주최측의 잘못이다.

두 번째로, 골든벨 이벤트에서 예선 문제가 작년 출품 동아리의 작품이나 참가 인원수 등을 묻는, 사실 상 random한 인원을 뽑는 문제였다는 점과, 일부 문제에서 보다 정확한 검증을 거치지 않아 오답이 있었다는 점이다. 도우미 자원봉사자들이 네이버 백과사전(..)을 뒤져서 문제를 냈는데, 바로 XML과 XHTML을 구분하는 부분에 문제가 있었다. 네이버 백과사전에는 XML에 대해서 "인터넷 웹을 구성하는 HTML을 획기적으로 개선한 차세대 인터넷 언어."라고 정의하고 있다. 하지만 엄밀하게 말하면 XML은 "인터넷 언어"가 아니다. W3C의 XML 표준문서 첫머리를 인용하면,

Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere.

라고 하고 있다. 원래는 대형 전자 출판용으로 설계된 언어였으나, 사용 용도가 다양해지면서 웹에서도 활용되고 있다는 것이다. 그리고 XML의 문법 구조를 지키면서 HTML을 개선한 "차세대 인터넷 언어"는 XHTML이다. 역시 W3C에서 이야기하는 바는 다음과 같다.

The Extensible HyperText Markup Language (XHTML™) is a family of current and future document types and modules that reproduce, subset, and extend HTML, reformulated in XML. XHTML Family document types are all XML-based, and ultimately are designed to work in conjunction with XML-based user agents. XHTML is the successor of HTML, and a series of specifications has been developed for XHTML.

이것은 명백히 네이버 백과사전의 오류이며, 이를 제대로 검증하지 못한 주최측에도 어느 정도 문제가 있다. (사실 도우미들이 XHTML에서 들어본 적이 있기라도 했다면 아마 쉽게 잘못을 파악할 수 있었겠지만 그랬는지 안 그랬는지는 확인할 방법이 없다)

그 문제가 지나간 다음 나와 배터리(친구 nick)는 사회자를 불러서 정정을 요구했지만 행사 진행 상 어쩔 수 없다고 했다. (나와 그 친구는 이 이벤트에 참가하지 않고 관전하고 있었다) 그때 떨어진 사람 중에 XHTML을 답으로 적은 사람이 있었는데 그 사람에게 1등상을 주든지, 나중에라도 원래 정답을 이야기해달라고 요구했으나 묵살(?)되었다.

그래도 "삼성"의 이름을 걸고 하는 것인데, 앞으로는 좀 더 진행을 잘 해주었으면 좋겠다. 이제 3회 정도 되었으면 슬슬 공신력도 어느 정도 생길 때가 되지 않았나 싶은데 말이다.

어쨌든, 대학교 IT 동아리들은 어떤 활동을 하고 있는지 알 수 있는 경험이 되었다는 점은 좋다. 다음 번 IT Festival은 좀더 발전된 모습으로 매끄러운 진행을 했으면 좋겠다.

학부생 연구 참여 프로그램 홈페이지 알바가 드디어 끝났다. (물론 앞으로 약간의 A/S를 해야 할지도 모르겠지만...) 사실 사이트 자체가 기술적으로 어려운 것은 없었으나, 포탈 사이트 로그인 연동 부분에서 좀 삽질했고 역시 CSS를 못알아먹는 IE 때문에 삽질한 게 작업 시간의 상당 부분을 차지했다. (그러나 그 중에서도 가장 황당했던 것은 서버가 별도로 준비되어 있지 않아서 연구처 직원분의 한 데스크탑을 계속 켜놓고—그것도 무선랜을 사용하는—알아서 서버 세팅을 해놓으라고 했던 것이다. 윈도우용 아파치, php, mysql 까느라 또 삽질..OTL 작업하다가 phpmyadmin 2.7 stable 버전의 어이없는 버그로 고생하기도...)

주문받아 만드는 게 어떤 건지 경험 삼아 시작한 것이었는데, 작업 기한이 당겨지면서 동아리 활동가 겹쳐 상당히 빡쎄게 하고 말았다. 어쨌든, 그 결과물은 여기에서 볼 수 있다.

나름대로 표준을 지키려 노력했고, 접근성도 고려하려고 했지만, 급하게 만드느라 완전한 validation은 안 될 수도 있다. 그리고 메뉴 부분은 javascript로 동작한다. orz (지금에서야 validation을 해보니 오타라든가 /를 빼먹었거나 &를 entity로 하지 않았거나 하는 것들이 대부분인 것 같다. 다행히 GR Board를 사용한 게시판 부분은 XHTML 1.0 Strict validation이 된다.)

어쨌든 나름대로의 경험이 될 것 같다. 하지만 앞으로 이 정도 해주려면(완전 백지상태에서 시작해서 디자인 + 코딩을 혼자 다...-_-) 더 많이(!) 받아야겠다. -_-;;