어제 드디어 스웨덴 KTH로부터 최종 입학허가 메일이 날라왔다. 아직 우편으로 온 것은 아니고 그쪽에서 먼저 메일로 스캔본을 보내준 것이다.

그래서... 사전 조사에 들어갔다. -_-;

위의 빨간색 동그라미가 기숙사가 있는 지역이고, 아래의 빨간색 사각형이 강의실과 도서관 등이 있는 학교다. 거리는 직선으로 약 2.5 ~ 3km 정도 되는데, 잘 포장된 오솔길들이 중간에 있어서 자전거로 통학하면 딱일 듯. (한겨울엔 좀 춥겠다-_-)

전원마을 같은 분위기다. 나는 저기서 Amanuensvagen이라는 곳의 어느 한 건물에 묵게 된다. (길 이름으로 주소를 만드는 것 같다) 사진 오른쪽 위 구석을 보면 작은 선착장과 모래사장이 있다. 이 위는 내륙으로 깊숙히 굽어들어온 바다다. (우리나라의 남해안처럼 해안선이 굉장히 복잡하게 되어 있다.) 사진의 왼쪽 아래에 있는 건물은 스웨덴 자연사 박물관.

위키백과를 찾아보면 잘 나온 사진들은 몇 장 구할 수 있을 것이고, 구글어스를 이용해 각 장소에서 찍은 사진 등의 부가 정보를 표시하면 더 많은 모습을 볼 수 있다. 위성사진이 여름에 찍은 거라 저렇게 아름다운 초록빛을 띠고 있지만 겨울엔 무척이나 황량하고 눈이 많이 올 것 같다.

학교 내에 도서관이 세 군데 정도 있는 것 같다. 아직 강의나 이런 것은 어디서 이루어지는지 잘 모르겠다. 특이한 건 학교 왼쪽으로 기찻길이 지나간다는 것. 구글어스를 잘 들여다보니 철도망이 상당히 발달해 있는 것 같다.

아무튼 재밌는 교환학생 생활이 되었으면 좋겠다. 이번에 우리학교에서 나 혼자만 지원한 줄 알았는데 06학번으로 추정되는 사람이 한 명 더 있었다. Physical Engineering School로 가는 거 보니 기계공학과인 듯? 외국인들하고도 많이 사귀어야 할 텐데.

이번 학기 듣는 수업 중에 전산물리학개론이라는 과목이 있다. 물리과에서도 아주 괴짜로 소문난(?) 모 교수님의 수업인데, 보통 전산물리학이라고 하면 수치해석적 기법들에 대해 다루지만 이 수업은 자기가 모델링한 것이나 기존 이론들을 컴퓨터로 '재빠르게' visualize함으로써 어떤 insight를 빨리 얻는 것을 목표로 하고 있다.

이 과목에서는 각자 개인별로 주제 발표를 하나씩 해야 하는데, 전산물리학 수업 시간에 배운 기법들을 동원하여 어떤 물리적 현상에 대한 것을 다루는 것이다. 수업 시간에 지금까지 배운 것들은 Excel, Excel+VBA, Visual Basic 6.0, VC++ MFC를 모두 약간씩 맛보았으니(교수님의 모토가 '필요한 것만 그때그때 배워서 쓰면 된다'라서 그냥 닥치고 따라해보기 식의 수업이다-.-) 그 중에서 무엇을 고를 것인가가 문제다.

나는 초등학교 6학년때부터 중학교, 고등학교때까지도 많이 썼던 Visual Basic 6.0을 골랐다. Java나 Python 같은 OOP 언어로 짜다가 오랜만에 VB6으로 프로그램을 짜보니 갑자기 왤케 안 되는 것이 많던지.. (VB도 OOP 언어이지만 언어적 기능이 다소 딸리는 편이다.) 연산자 재정의라든가 오브젝트 생성시 인자 넘기는 것이라든가 안 되는 것이 좀 있었지만 어쨌든 프로그램은 금방 짤 수 있었다.

내가 잡은 주제는 그 유명한 만델브로트 집합. 워낙 유명한 거라서 카오스의 '카' 자라도 들어봤다면 다들 한번쯤 본 적이 있을 바로 그 그림이다.; 프로그램 짜놓고 혼자 감상하면서, 정말이지 어떻게 그런 간단한 식으로부터 그런 복잡하고 아름다운 그림이 나오는지 신기했다.

사실 이 프로그램을 중학교 때 한 번 짜려고 시도했던 적이 있는데, 그때는 Picture Box와 복소 평면 사이의 좌표변환 개념을 제대로 이해하지 못해서 중도에 그만두었던 기억이 있다.

요즘 수리물리 시간에 Complex Analysis에 대해 배우고 있는데, 복소수의 세계는 정말 오묘하다. 특히 conjugate를 취한 z*를 z와 서로 다른 변수로 취급할 수 있다는 사실과, 복소함수의 singularity들을 보면서 추상화와 일반화의 힘이 어떤 것인가 체험하고 있다.

아무튼 결론은 잡담이었다는 것과 전산물리 발표 잘 끝났으면 좋겠다는 거.

그림 추가 : 결국 말려서... 색깔 기능까지 업그레이드! -_-

와, 얼마만의 정식(?) 블로그 포스팅인지 모르겠다.

요 근래 OS 프로젝트를 하느라 거의 밤샘하다시피하면서 폐인 생활을 계속했었는데, 딱 하나 잘못 생각했던 것 때문에 거의 2일 이상을 날려먹었음을 깨닫고 그동안 짰던 priority donation 코드를 싹다 버리고 새로 짰다. -_- 2일 동안 밤새서 만든 코드보다 양도 더 적고 버그도 적었다.

그렇다면 그동안 했던 삽질이 헛수고냐라고 묻기 쉬운데 잘 생각해보면 꼭 그런 것 같지만은 않다. 그렇게 삽질을 하면서 어떤 버그나 문제가 발생했을 때 잠재적인 원인을 유추하는 스킬이 생기고 특히 이번 프로젝트를 통해 gdb 사용법을 좀더 자세히 알게 되었다.

OS 커널 코딩은 SP 때와 상당히 다른 느낌이다. SP 때는 코딩량 자체가 많았지만, OS는 코딩량은 얼마 안 되어도(Pintos 처음 코드와 현재 내가 고친 코드를 diff 뜬다면 아마 100줄 정도밖에 안 바뀌었을 것이다) 한줄 한줄의 의미와 영향력이 엄청나게 중요해서 정말로 생각을 많이 해야 한다. 모니터를 보며, vi의 ctags로 이리저리 돌아다니며 계속 생각하고 모델링해야 하는 것이다. 또한 내가 처음부터 만드는 프로그램이 아니고 이미 Pintos라는 주어진 OS 골격 안에서 프로그램을 짜야 하기 때문에 다른 사람이 만들어둔 소스를 읽는 스킬도 중요한 것 같다.

SP를 들으며 "Segmentation Fault"에 익숙해졌다면 OS를 진행하면서 "Kernel Panic"에 익숙해졌다. -_- 이제 블루스크린이나 커널패닉이 떠도 개발자가 얼마나 고생했을까 하는-_- 동병상련(?)의 마음이 들 것 같다; 물론 데이터 날려먹으면 화는 나겠지만..;;

SP와 OS를 들으며 느끼는 거지만, 큰 규모의 디버깅이 힘든 프로그램을 짤 때는 다음을 꼭 지켜야 하는 것 같다.

• 하다가 막히면 일단 쉬자. 게임을 한판 하든 산책을 하고 오든 잠을 자든 다른 짓을 하고 다시 보면 새로운 아이디어가 떠오르는 경우가 많다.
• 오랫동안 짠 코드라고 버리기를 아쉬워하지 말자. 보다 나은 설계가 있다면 최대한 빨리 적용하고 테스트해보자. (물론 만일에 대비하여 버전관리 시스템을 사용하는 것을 권장한다)
• 잘 이해가 안 되는 부분이 있다면 다른 사람에게 물어보거나 같이 토론하는 것이 큰 도움이 된다. 직접적으로 답을 제시받지 못하더라도 남에게 설명하기 위해 스스로 문제를 정리하게 되기 때문이다.

이제 오늘 중으로 18개의 test-case 중 남은 2개에 해당하는 nested donation 구현만 끝낸다면 1번 프로젝트는 끝난다. 그러나 2번 프로젝트는 훨씬 더 많은 test-case가 기다리고 있다는 소문이..... OTL