아까 고전역학, 전산기조직 시험을 연타로 보고 뻗었다가 한숨 자고 일어나보니 뉴스속보가 하나 올라와있었다. 버지니아텍 총기난사 사건. 덜덜덜하면서도 역대 최대 규모라길래 놀라긴 했는데, 조금 있으니까 그 범인이 한국인이란다. 당장 아침 9시에 시험 하나 있는데도 놀란 가슴이 진정이 안 되고 있다.

고등학교 동기나 선배들 중에도 미국쪽 유학 간 사람들이 있고, 또 대학 와서 알게된 사람들 중에도 한다리만 건너면 미국 유학 간 사람들이 꽤 된다. 버지니아텍에 직접 아는 사람은 없지만 한인교포사회와 외교관들 초비상사태가 걸렸다고 하니 이건 뭐... 많은 사람들이 우려하듯 멀쩡한 한국사람들한테 보복하는 일이나 일어나지 않길 바랄 뿐.

이 와중에도 Wikipedia는 너무나 성실한 업데이트로 사건 경위가 자세히 올라오고 있고, 조승희씨 페이지도 만들어졌을 정도다. 블로거과 네티즌들이 올린 글과 사진, 동영상들이 주류 언론의 보도 대상이 되고 있기도 하다. 사건 자체는 참으로 안타까운 일이지만 한편으로 점점 변해가는 Web을 보는 건 흥미롭다.

12세 때 미국으로 건너갔다..는 얘기가 주로 들리는데, 내가 초등학교 다닐 때 친한 친구 한 녀석이 딱 12살때 북미 쪽으로 이민을 갔었다. 그 뒤로 연락이 안 돼서 지금은 어떻게 살고 있는지 모르겠고, 잘 살고 있기를 바라는 것 외엔 도리가 없다.

언제나 그랬듯 이번에도 미국내 총기소지에 대한 논란이 불거질 것으로 생각된다. 총기는 한 번 잘못 사용하기 시작하면 대량 살상이 일어나기 딱 좋기 때문에(물론 폭탄테러가 더 하겠지만 상대적으로 칼 등 다른 일반 휴대용 무기류에 비해서) 총기소지를 허용한다고 해도 그 사용에 엄격한 규제가 필요하다. 물론 원천금지를 하는 것이 더 좋겠지만...

나름 공대와 기숙사라는 공통점이 있어서인지, 뭔가 섬짓한 느낌이 들기도 한다. 우리학교에서 저런 일이 벌어지는 건 상상도 하기 싫다. 내년에 교환학생 가려고 했던 건, 비록 미국은 아니지만서도, 토플 대란 때문에 어쩌구 하는 것보다도 치안이 어떤지 먼저 걱정이 된다. 어쨌든 고인의 명복을 빌며 시험공부하러...

지난 월요일에는 SE 프로젝트와 중간고사라는 빠듯한 일정에도 불구하고 음악회를 하나 보러갔었다. 다름 아닌 실내악 앙상블을 강의하시는 김정진 교수님이 연주하시는 것. 학교에서 가장 가까운 성당인 궁동 성당에서 바로크 음악을, 그것도 명동 성당 오르가니스트와 함께 오르간 연주도 곁들여서 한다는데 안 갈 수가 없었다. (게다가 무료 입장!)

성당이나 교회들은 보통 신부/목사의 목소리가 잘 전달되게 하기 위해 한 번 방사된 소리가 일정 시간 잔향으로 남게 만든다. (이건 공연장들도 마찬가지다. 용도에 따라 다른 것은 당연하고.) 그래서인지, 내가 가본 그 어떤 음악회보다도 음향이 훌륭했다. 첼로는 마이크를 써서 음을 크게 했고, 고급 전자오르간이 반주를 해주었는데, 성당 안이 정말 소리로 꽉꽉 들어차는 느낌이었다. 일전에 어느 블로그에서 바티칸 성당의 주교 회의 사진에 '살아있는 공간'이라는 설명을 단 것을 본 적이 있는데, 딱 그런 느낌이었다.

감미로운 첼로 연주도 좋았지만, 실제 오르간으로 바흐의 그 유명한 Toccata and Fugue in D minor를 연주하는 것을 본 건 처음이었다. 그 엄청난 음량으로 머리부터 발끝까지 온 몸의 털이 쭈뼛쭈뼛 서는 것 같았다. 다른 사람들도 그 곡은 아주 심취했던 것 같다. 주로 바흐의 곡들이 많았는데, 자기 아들을 연습시키려고 만든 평균율에 멜로디를 붙여 만들어진 곡인 Ave Maria나, Squire의 빠른 2박자 곡인 Bouree도 인상 깊었다.

간만에 정말 집중할 수 있는 음악회였고, 바쁜 일정 중에 힘들게 짬내서 간 만큼 희열을 느낄 수 있는 시간이었다. 끝나고 교수님한테 인사도 드리고, 또 전날 부활절 미사에서 만났던 노영해 교수님도 다시 보고. 옛날에 실내악 앙상블 같이 들었던 같은 학번 사람도 만나서 인사하고. 여튼 정말 가뭄 속의 오아시스, 그리고 그동안 미사만 해왔던 곳에서 꽉 찬 살아있는 음악소리를 들은 경험으로 새로운 에너지를 충전할 수 있었다.

오늘 밤 12시 듀를 앞두고 어제 SE 프로젝트 조모임을 무려 12시간 가까이—그것도 새벽 5시까지—했다. 물론 그 시간 동안 순수하게 SE만 한 것은 아니지만(밥도 같이 먹고 음료수 마시면서 잠시 쉬기도 하고, 잠시 내게 배정된 일이 없는 사이 TNF 홈페이지 코딩도 하고..), 그래도 에너지 소모는 엄청났다. 계속 바닥에 앉거나 누워있다보니(GON 동방이었음) 온몸이 쑤시기도 하고 정신적인 에너지 소모도 장난 아니다. 결국 오늘 아침 수업 2개는 다 째고 말았다. -_-

우리가 듀 직전이라서 이렇게 달리는가 하면 그것은 또 아니다. 우리 조는 다른 조들에 비해서 상당히 빨리 시작한 편이어서, 이미 지난 주 월요일부터 보고서 작성에 들어갔던 것이기 때문이다. (다른 조에 아는 사람을 만났더니 거의 일주일이나 늦게 일요일에 처음 시작했다고도...-_-) Web으로 할 것이냐 말 것이냐 하는 문제도 어떻게든 결론을 지어야했기 때문에 더욱 빨리 착수했던 것이기도 한데, 결국 사용하지 않는 쪽으로 결론이 났다.

뭐, 조원들과 함께 많은(-_-) 시간을 보내다보니 서로 친해진다는 점은 좋지만, 그래도 이건 좀 너무한다 싶은 생각이 들었다. 조원들이 시간을 잡아먹는다거나 하는 것이 아니라—원래 여럿이서 모여서 하다보면 서로 동기화를 해야 하기 때문에 발생하는 오버헤드가 있기 마련이므로—프로그램 설계 자체가 이렇게 시간을 많이 잡아먹을 만한 가치가 있는 일인가 하는 것이다. 뭐 교수님이 수업시간에 말씀하신 바로는 프로젝트 개발 기간의 80%가 설계고 20%가 구현이라는 얘기도 있지만, 지금 우리가 하는 방식의 설계는 너무 사람을 지치게 만든다.

매번 거의 똑같은 이야기를 쓰고, 하나의 기능을 작성하는 데 있어서 수많은 diagram들과 씨름해야 하는 것이 과연 효용성이 있는 것일까? 물론 documentation이 얼마나 중요한 것인지는 나도 잘 알고 있다. (사용자 입장의 것이든 개발자 입장의 것이든 간에.) 하지만 지금은 documentation이 모든 궁극적인 목표가 된 것 같다는 느낌이다. 문서를 위한 문서를 만든달까. 어떤 제품을 만든다는 것은 사용자의 욕구를 충족시키고 그것을 통해 profit을 창출하는 것이 목표일 텐데, 만약 지금과 같이 개발한다면 문서 만들고 나면 지쳐서 정작 개발은 전혀 하지 못할 것 같다.

심지어는, 약간 주제넘은 생각일지도 모르겠지만, UML이 과연 복잡한 프로그램 구조를 설명하는 데 적합한 것인지조차 하는 의심마저 들 정도다. 2~3시간에 걸친 UML 강의도 들어보고 담당 조교님과의 면담도 해보고 예제 문서도 들여다보고 꽤 많은 시간 동안 공을 들였지만, 뭐랄까, 오히려 UML이 우리가 설명하고자 하는 온전한 의도를 왜곡시켜버리는 것 같다. (뭐, 이건 우리가 그만큼 UML을 잘 못 다루기 때문일 수도 있겠지만.) 개발 문서라는 것은 개발자 자신뿐만 아니라 다른 개발자들에게도 설계도처럼 쓰일 수 있어야 하는 것이라면, UML이 과연 그 역할을 다 할 수 있을까 하는 생각이 드는 것이다. 아직 덜 배워서 그런 거라면 모르겠지만 동적으로 scaling되는 thread pool이라든가 하는 것들은 어떤 식으로 표현할까? 또 Web이 왜 이런 설계 문서 작성에 적합하지 않아야 하는 것일까? 등등 수많은 의문들이 존재한다. 사실 Class design 자체가 scale을 어느 수준까지 자세하게 할 것인가에 따라서 많이 달라지기도 하기 때문에 더욱 애매하다.

한 마디로 말해서, 지금 우리가 배우는 기법과 도구들이 우리가 들이는 시간과 노력만큼 절대적인 가치를 지니는가 하는 것이다. 이번 수강생들을 위해 30개의 라이센스를 샀다는, 매우 비싼 모델링 툴인 것 같은(?) TAU도 특정 상황에서 마우스 오른쪽 클릭에 꺼져버린다든가, diagram 인쇄 미리보기를 하면 프로그램 오류난다든가 등등 아주 버그 투성이인 것을 보면 (몇몇) 조교님들이 이 프로그램에 정말 감동먹었다고 하는 것이 도저히 상상이 가지 않을 정도다. Code generation이 된다고는 하지만 과연 그 모호한 UML를 통해 generation된 프로그램이 얼마나 효용가치가 있을까 하는 회의도 든다. (몇가지 예제를 보면 오히려 쓸데없는 부수적인 코드만 더 많아지는 것 같기도 하다.)

Object-oriented가 분명 현재의 대세가 되고 있고, abstraction과 encapsulation을 통해 매우 깔끔한 코드를 제공한다는 것은 동의한다. 하지만 OOP가 모든 것을 해결해 줄 수 있는 만능 솔루션이라고 생각하지는 않는다. 또, 끊임없이 발전하고 프로그래밍 기술과 끊임없이 변하는 요구사항들을 생각했을 때 지금의 설계 방법이 잘 통할 것 같지도 않다. 실전에서는 다르다는 것을 알면서도 이만한 시간과 노력을 들이는 게 무가치하게 느껴진다는 것이다.

다른 조 이야기를 들어보면, 조교들끼리도 class design 방법에 대해 의견차가 있는 것 같고, 게다가 예제 문서 또한 다 맞는 것이 아니라고 하고... 너무나 혼란스럽고 모호한 것이 많다. 이런 상황에서 우리는 엄청난 로드로 설계를 위한 설계를 하고 있다. 힘들더라도 제대로 하는 것이 맞다는 확신이 있으면 견뎌낼 만 할텐데 그렇지 않으니 문제다. 실전에서 이런 식으로 기력을 빨아먹어버린다면 그건 문서화 기계일 뿐이지 사람이 아니다. (프로그래밍하고 문서 만들고 하는 것도 궁극적으로는 자신의 행복을 위해서가 아닌가. 뭔가를 희생 혹은 투자했다면 그만한 가치를 찾아 합리화가 가능해야 한다.) 지금 제대로 하는 게 맞는 건지 심히 의심스럽다.

몇가지 잡설.
1. 혹시 이것은 이러한 방법론 말고 다른 방법론을 택해야 한다는 것을 몸으로 느끼고 깨닫게 하기 위한 고도의 전략?
2. 이러한 문서화가 오히려 순간순간 나타날 수 있는 개발자들의 창의성을 엮어내는 데 방해가 되는 것은 아닐까. 물론 지나치게 창의적이어서 배가 산으로 가면 안 되지만 말이다.

예전 글에서 썼던 바로 그 화면깨짐 현상의 원인을 드디어 찾았다.

원격데스크탑을 쓰다가 화면 깨짐이 발생했을 때, 속도가 느린 것 같아 Windows 고전테마로 바꿨더니 화면 깨짐이 발생하지 않는 것이었다. 다시 XP 테마로 바꿨더니 잠시 후 또 깨짐 현상이 나타났다. 그러기를 몇 번 반복해서 내린 결론은 XP 테마 처리 버그. 옛날에 StyleXP 등을 써봤던 경험도 있고 Visual Basic 6.0에서 custom control을 만든답시고 uxtheme.dll API를 써서 프로그램을 짜봤던 적도 있었기에 바로 uxtheme.dll에 관해서 검색해봤다.

아니나 다를까. MS에 이런 버그 보고가 올라와 있었다. 근데 MS에서는 '특정 문제만 해결하기 때문에 다음 서비스팩을 기다리는 것이 좋습니다. 즉시 해결하려면 기술지원을 받으세요'라고 해서 gg. 좀더 검색해보니 StyleXP 없이 custom theme를 쓰기 위한 uxtheme 패치들이 있었고 그것을 통해 최신 버전으로 올릴 수 있었다. (끝자리 2180에서 2845로 올렸다)

사실 그 후에 XP 듀얼코어 패치를 하면서 이 문제가 고쳐진 줄 알았으나, 최근에 다시 발생하기 시작해서 신경쓰이던 차였다.

어쨌든 이 문제를 해결해서 기쁘다. 앞으로 좀더 두고봐야지. 이런 걸 두고 십년 묵은 체증이 내려간다는 표현을 쓰는 것 같다.

덤. 근데 생각해보니, VGA 카드 교환한답시고 서울까지 갔던 건 삽질이었다. 내 교통비 ㅠㅠ

요즘도 계속 SE를 하고 있다. 나 혼자 하는 거면 모를까, 그래도 팀원들과 같이 하는 것이다보니 다수의 의견을 따라 웹을 버리기로 했다. 사용자 편의를 위해서 뭔가 자세하게 하려고 하면 할수록 sequence diagram, class diagram이 오히려 복잡해져서, '문서와 코드의 consistency'를 중요시하는 분위기 상 오히려 감점 요인만 늘어난다는 생각 때문이었다.

지금 우리가 이 수업에서 하고 있는 프로젝트는 CADIT(Conceptualization - Analysis - Design - Implementation - Test)의 과정 중 T를 제외한 나머지를 다룬다. 상당히 전통적인 개발 방법론이라고 볼 수 있는데, 문제는 이 방식이 처음에 모든 것을 완벽하게 설계해놓고 거기에 맞춰 코드를 만들어 결과물을 짠~ 내놓는 것이라는 점이다.

이는 몇 년 전부터 뜨기 시작한 XP(Extreme Programming)에 정면으로 대치된다. XP에서는 아주 작은 스케일(초, 분)부터 아주 큰 스케일(달, 년)까지의 시간 단위마다 지속적으로 가치 점검과 방향 수정을 하며, 모든 것을 다 설계한 다음 한 번에 구현하는 것이 아니라 중요한 기능들부터 먼저 구현하면서 주변 기능들을 덧붙여 나가는 방식을 사용한다. 어떻게 보면 자전거 타기에 비유할 수 있을 것이다. 자전거를 타면 우리는 원하는 경로를 따라가기 위해 무의식 중에 연속적으로 미세하게 경로 변경을 하는데, CADIT은 모든 준비를 마친 다음 목표 지점에 도달하기 위해 포탄 발사하듯 내던지는 격이다. 그 둘의 차이점(장단점)은 굳이 말하지 않아도 알 수 있으리라 생각한다.

사실, 수업 프로젝트로 하는 것이기 때문에 우리가 처음 원했던 수준만큼 프로젝트를 진행하는 것은 여러모로 무리가 있을 수도 있다. 다른 수업과의 로드 분산도 고려해야 하고, 조교와의 의견 조율도 필요하기 때문이다. 또 학부 수업에서는 아무래도 '고전'에 해당하는 것을 다루다보니 더 그런 것이라는 얘기도 들린다. 결국 우리는 설계 문서 작성법을 익히는 데 의의를 두고 코드는 C#을 이용해서 간단하게 짜기로 했다. (물론 완전히 확정됐다고 보기는 조금 그렇다) 실제 서비스하는 것을 목적으로 하지 않고 prototyping을 목적으로 한달까(라고 자기합리화하는 듯한 느낌이 들지만).

하아, 세상을 너무 복잡하게 살 필요는 없는 것 같다. 가끔은 맘에 안 드는 것을 다른 방식으로 받아들이는 것도 괜찮겠지.

덧. 실제 현업 프로젝트에서는 HTML이나 Javascript 혹은 CSS 같은 건 설계 문서에 어떻게 표현하는지 알고 싶습니다. 아시는 분은 답글 부탁드립니다. (파일 단위로 단순히 entity화하는 건지, 템플릿 하나를 클래스 하나로 보는지 등등...)

어제부터 시작해서 대략 6시간 동안 계산했는데, 오랜만에 미적분을 하려니 자꾸 실수하는 것도 있고 해서 정말 고생했다.

고전역학 숙제 풀이 중 일부 (참고로 저거 틀려서 한 페이지 다시 썼다. orz)

외부 힘이 주어진 경우에 대한 진동의 2차 미분방정식을 푸는 문제였는데, 문제 자체는 매우 간단했으나 계산을 하면 할수록 항이 늘어나면서 저렇게 되었다. -_- 이것을 Green's method라는 것으로 다시 푸는 게 있는데 그것은 부분적분 n번을 하니까 같은 답이 나왔다. (사실 미분방정식을 풀다가 꼬여서 결국 얼버무리고 말았다. -_- 원래는 똑같은 답이 나와야 한다.)

하아, 이제 알고리즘 숙제와 URP 논문 읽기 및 matlab 코드 리뷰, 그리고 SE 분석 프로젝트 예시 문서 스터디까지 해야 한다. 그냥 밤 샐까. ㄱ-

이번 학기에 듣는 소프트웨어공학개론 프로젝트가 아주 골치아파지고 있다. 5명이서 한 학기 동안 하나의 프로젝트를 기획, 분석, 설계, 구현까지 모두 하는 방식으로 이루어지는데, 우리팀은 학내 BBS 서비스인 Ara의 Buy&Sell이 불편한 점이 많다는 것에 착안하여 KAIST인들을 대상으로 하는 Auction을 기획하였고, Python Django 기반으로 구현하려고 생각 중이었다..

지난 주에, 첫 번째 단계인 conceptualization이 잘 마무리되어가던 찰나, 교수님과의 면담에서 OK를 받았음에도 불구하고 청천벽력 같은 소식이 들려왔다. 그것도 듀 바로 전날에. '언어는 C++, Java로 제한합니다. 웹은 하지 마세요.' -_-

우리의 반응은 '지금 장난해? 시작할 때부터 제한하든가, 웹을 쓰려고 하는 이유가 무엇인데?'...

과목 게시판에서 토론이 벌어지기도 했고, 우리팀 담당 조교님과 면담을 하기도 하면서 일단 현재 상황을 정리해봤다.

우리가 하고 싶어하는 것과 근거

• 웹도 충분히 Object-oriented 모델링이 가능하다. (오늘 Django에서 controller 부분을 순수 클래스로 짜봤는데 바로 테스트 성공, 이대로라면 class diagram을 그대로 옮기는 것도 가능하다.)
• 우리는 이 프로젝트로 만들어진 결과물을 실제 서비스할 계획을 가지고 있다. (교수님한테 얘기했을 때도 좋다고 하셨다) 그렇기 때문에 서버 관리가 용이한 Linux 기반의 오픈소스 플랫폼을 쓰고자 한다.
• Python이 대부분의 팀원에게 생소한 언어긴 하지만 다들 배우고 싶은 의지가 있고, 언어 자체가 그리 어렵지 않은 편이다. (정 어렵다면 ASP.NET 등을 쓸 수도 있으나 서버 관리 등의 문제로 인해 실제 서비스와는 멀어지게 된다)
• 옥션 서비스를 만드는데 전용 클라이언트를 만들면 누가 쓰겠나? 웹을 쓰는 이유는 접근성과 UI 커스터마이징의 편리함 때문이다. 결국 전용 클라이언트를 만들어도 view만 다를 뿐..

조교님(들)의 견해

• C++, Java가 UML 모델링한 것들을 코드로 그대로 옮기기 편하다.
• 웹은 Object-oriented와 잘 맞지 않는다. 따라서 consistency를 유지하기 힘들어 점수가 깎일 가능성이 높을 것이다.
• 굳이 하지 말라는데, 감점의 위험을 감수하고서라도 하는 이유가 뭐지?
• 서비스는 나중에 알아서 하든 말든 중요치 않고, 일단 scoping을 적절한 크기로 유지하는 것이 필요하다.
• Class diagram에 프로그램의 모든 요소가 나타나야 하고, 그것들은 반드시 실제의 class로 만들어져야 한다. 웹에서 이런 것을 하기 힘들지 않나?

조교님들의 견해에 대한 우리 나름의 추측으로는, C++/Java로 코드를 제출할 경우 자체적인 모델링 도구를 이용해 역으로 diagram을 뽑아낼 수 있어 편하거나 혹은 Python이 채점하기에 익숙하지 않은 언어라서 꺼리는 것 같다는 것, 그리고 담당 조교님과의 대화를 통해 추측컨대 웹 프로젝트 경험이 거의 없어 웹을 단순 노가다로 보는 경향이 있다는 것이다.

사실 우리 프로젝트에서 HTML/CSS는 그다지 큰 비중을 차지하지 않는다. Django로 짜게 될 경우 template 데이터로 존재는 하겠지만 그 자체가 프로그램의 로직을 구성하는 것은 아니고 단지 데이터 파일 역할만 하는 것이다. (물론 간단한 for/if 문 등이 들어가서 UI 구성을 편하게 할 수는 있지만, 그것을 로직이라고 보기는 어렵고 flexible한 스킨이라고 보는 게 맞다.) Django의 template 각각을 하나의 클래스처럼 볼 것인지 단순한 스킨 데이터 정도로 취급할 것인지 좀더 명확히 해야 할 것 같긴 하다.

또 한가지 문제는, conceptualization 제출 직전부터 조교님들이 웹 프로젝트 하는 것을 강력히 반대해왔기 때문에 우리가 이제와서 설득한다고 해도 쉽게 받아들여주겠냐 하는 것이다. 우리는 단지 학점을 위해서 프로젝트를 하는 것이 아니라, 이러한 프로그램 설계 과정을 적용하면서 직접 실제 서비스를 만드는 데 목표가 있는 것인데, 단지 웹이라는 이유로 너무 심한 반대를 하는 것 같다.

사실 내가 생각하기에는 실제로 사용할 것을 생각하고 프로젝트를 진행하는 것이 SE 수업의 진정한 방향이 되는 것이 맞다고 본다. 웹이 UML 모델링을 적용하기 어려울 것 같다면, 왜 어려운지 분석하고 어떻게 하면 잘 적용할 수 있을지 고민하는 것이 맞는 것 아닐까? 한 번 짜고 버릴 코드라면 왜 굳이 복잡한 명세서와 diagram들을 그려가며 만들어야 하는가? 그럴 거면 이 수업을 안 들었을 것이다. 저번 전산학 세미나 시간에 외국의 좋은 대학들은 실제 사용할 서비스를 개발하는 프로젝트를 한다지 않았던가.

무엇보다 결정적으로, 웹프로그램을 OOP로 모델링하는 게 아주 처음 시도되는 것이 아니라 이미 웹프레임워크 등으로 계속 이루어져 오던 일이고, 내가 간단하게 샘플 코드를 짰을 때도 아무런 문제가 없었다는 점이다. 그러니 그렇게 뜯어말릴 이유도 없다.

한 가지 내가 생각하는 Python 사용의 단점이라면, 클래스 멤버변수나 메소드에 대해 private/public 등의 한정자나 data type을 명시할 수 없어서 UML이 그대로 변환되지는 않고 중간에 손실되는 정보가 생길 수 있다는 것 정도다. 그렇지만 이것이 전체 프로젝트의 OOP 모델링에 그렇게 큰 영향을 끼치는가? 이 문제는 앞으로 조교님하고 좀더 상의를 해볼 생각이다.

어쨌거나 오늘 조교님과의 면담 끝나고 내린 결론은, 다음번 면담 때 일단 간단한 sample 코드를 Django 기반으로 짜서 class diagram을 그리고 실제로 어떻게 매칭되는지 보여드리자는 것과 우선 analysis 문서 작성법을 잘 익혀두자는 것이었다. 하아, 아주 하지 말라는 말은 안 하고 '해보겠다면 해보세요'라고 말하고 있는데, 왜 학점이 불안하게 느껴질까.

드디어 봄이 오고 있다. 어제만 해도 목련이 1/4도 안 피었었는데, MT 갔다가 돌아오면서 보니 학교 곳곳에 개나리와 목련, 산수유가 만발했다. 학부기숙사의 벚꽃들도 막 물이 올라 꽃봉오리들이 붉은 빛깔을 띠기 시작했다.

비가 왔음에도 날씨가 추워지지 않고 따뜻한 걸 보니 이제 완연한 봄이다. 내일부터는 학복위에서 딸기 판매도 한다고 하고, 딸기파티와 함께 중간고사 시즌이.... orz

어쨌든 간만에 기운나는 날씨다.

갑자기 무슨 바람이 들었는지(봄바람? -_-), 오래 전에 가입해두고 쓰지 않던 서비스인 플리커를 써보고 있다. 플리커는 대부분 알다시피 대표적인 Web 2.0 사이트로 각광받았던 taggingw 위주의 사진 공유 서비스다.

예전에는 그냥 가입에 사진 몇 장 올려두고 말았었는데, 다시 찬찬히 뜯어보니 꽤나 잘 만들었다. (완전 뒷북이다. -_-) 사진 업로드를 편하게 해주는 별도의 데스크탑 어플리케이션 제공이라든가, 업로드 후 여러 장의 사진의 속성을 한 꺼번에 바꾸는 batch organize 기능 등 꽤나 원하는 기능들이 잘 배치되어 있었다.

하지만 가장 큰 단점이라면 해외 서버기 때문에 속도가 좀 느리다는 것. 국내에 서버가 있다면 엄청 편할 거라는 생각이 든다.

그래서 플리커에 올린 사진 하나. 봄도 되었고 하니 한껏 물오른 나뭇잎들 사진이다. 아마 눈치챈 사람도 있겠지만 저건 고등학교 기숙사 올라오는 계단에서 찍은 것이다.

ps. 다른 것보다 맘에 들었던 건, Creative Commons 라이센스를 채택할 수 있도록 옵션을 제공하고 그러한 사진들을 검색할 수 있도록 해준다는 것이다. 블로그 스킨 등을 만들 때 참고하면 큰 도움이 될 것 같다.

요즘 일정

하아, 왜 꼭 일이 몰릴 때는 꼭 이런 식으로 몰리는 건지.. 저기 비어있는 칸들은 잠 or 숙제 or 밥먹기다.

그래도 방학 때보다는 좀 바쁜 게 낫다. 하지만 이런 상황에서 느릿느릿한 영어강의는 GG -_ㅠ (알고리즘 시간에 완전 자버렸다 orz)

※ 이 글은 CS496 전산학 세미나의 에세이 과제로 썼습니다.

나는 이공계에 있는 사람들이 다른 분야—특히 의학이나 법률 분야—로 간다고 해서, 궁극적인 의미로 그것을 이공계의 위기라고 볼 수는 없다고 생각한다.

얼마 전, 포항공대를 수석 졸업한 생명과학과 학생이 의대로 진학하여 화제가 되고 있다. 블로고스피어에서도 꽤 회자되었던 일이고, 내가 이공계에 있는 까닭에 주변 사람들의 다양한 의견을 볼 수 있었다. 어떤 사람들은 그런 식으로 실험실 식구들을 비판한 것이 사람된 도리가 아니라는 얘기를 하면서도 선택은 개인의 자유라고 말하기도 했다. 또 다른 사람들은 의대가 오히려 더 권위적이면 권위적이었지 왜 진로를 바꾸었느냐 하는 충고를 하기도 했다.

과학고등학교를 다닐 때, 교장선생님의 애국조회 연설 등에서 가장 많이 들은 얘기가 바로 '애국'에 관한 것이었다. 우리는 커서 나라의 일꾼이 되어야 하고, 나라에서 이렇게 좋은 교육 환경을 지원받고 있으니 보답을 해야 한다 등등. 그러나 내가 볼 때 나도 그렇고 우리 세대의 아이들에게 그런 소리가 씨알이 먹히는 경우는 거의 없다. 어떻게 보면 개인주의나 이기주의로 보일 수도 있지만, 분명히 자기가 잘 되어야 국가에 이바지들 하든 말든 할 것이다. 그런 면에서 요즘의 학생들은 개인적인 목표를 수립하고 그것을 위해 정진할 수 있는 환경과 역할 모델들을 요구하고 있다.

그러나 이공계 바깥에서 보는 인식은 아직 그렇지 못하다. 머리 좋은 사람들 잘 가져다 써서 돈을 벌든지 국가 발전을 시킨다고 생각한다. 나는 '가져다 사용되는' 입장이 되길 거부한다. 보다 주체적으로 인정받는 삶을 원하고 있는 것이다. 내가 돈을 벌고, 내가 과학기술을 공부·연구함으로써 간접적으로 국가를 발전시키는 것일 뿐이다.

그렇기 때문에, 비록 실험실 식구들에 대한 비판은 다소 무리가 있었다고 생각하면서도—뭐랄까, 그 사람이 제시했던 이유라면 굳이 그런 선택을 해야 했을까 하는 개인적인 느낌—그 사람의 선택은 충분히 존중되어야 한다고 생각한다. 자기 삶의 방향을 결정하는데 단지 이공계였다고, 수석졸업이었다고 해서 그 선택권을 박탈당할 수는 없는 것이다. 이공계인들은 계약을 하고 공부를 하는 것이 아니라, 단지 자기가 원했던 방향이기에 공부를 하는 것이다.

이공계 위기라는 것은 사실 본질은 간단하다. 인재가 부족하다는 등의 위기라는 건 결국 기피로부터 나온 것인데, 기피를 막으려면 당장의 장학금 같은 것보다는 사회 구성원으로서의 정체성을 살리고 삶의 질을 보장받을 수 있는 무언가가 필요하다. 요즘은 근무 시간에 노동의 질을 높이고 근무 시간을 줄이는 방향으로 가자는 의견들이 나오고 있다. 돈을 많이 벌거나 연구 성과를 많이 낸다거나 해도 자기 시간이 없다면 삶의 질이 높다고 할 수는 없기 때문이다. 또한, 다소 매니악한 특징을 가지는 이공계 사람들에 대한 사회적 수용력도 뒷받침되어야 한다.

현재의 위기는 내가 보기에 정말로 위기라기보다는 일종의 과도기다. 과거에 비해 과학기술자, 혹은 지식노동자가 가지는 삶에 대한 패러다임이 변하고 있지만 사회적으로 받아들여지지 못한 상태라고나 할까. 그래서 대우가 안 좋다느니 하는 얘기도 나오는 것 같다. 하지만 분명한 건 점점 가속되는 과학기술의 발전은 더욱 많은 기회를 만들어낼 것이고 결국 사회를 변화시킬 것이다. 차별화된 능력과 다양한 분야를 수용할 수 있는 능력이 있다면 소위 말하는 '성공'의 스펙트럼에서 높은 위치를 차지할 수 있을 것이다.

꿈.

룸메인 승범이에게 내 컴퓨터를 몇 시간 동안 쓰라고 빌려주었다. 그런데 돌아와보니 갑자기 생전 못 보던 화면이 떠 있는 거다. 무엇인지 봤더니 갑자기 웬 윈도우 비스타?! 어찌된 거냐고 물었더니 그냥 생각나서 깔아봤댄다. -_-

대체 무슨 소리냐며 파티션과 데이터를 확인해보니 기존 윈도우를 덮어씌워놨다. 게다가 내 문서 파일들은 다들 어디로? .... 현실에서는 절대 못 할 것 같은(?) 욕을 승범이에게 하다가 기왕 이렇게 된 거 비스타라도 잘 쓰자는 생각이 들어서 그래픽 드라이버가 제대로 안 잡혀있길래 잡아주었다. 오, 이쁘긴 이쁘네.

.
.
.
.

화들짝 잠에서 깼다. 바깥이 어두컴컴하다. 어라, 지금 몇 시지?

생각해보니 오늘은 응미 연습이 7시에 있는 날이고 첫번째 퀴즈를 본다. 갑자기 밀려오는 불안감과 함께 핸드폰을 열자 7시 49분. -_-

아놔, 망했구나 하면서 아까 승범이가 응미 초수강할 때 적분 틀려서 퀴즈 빵점 받았었다는 얘길 한 게 떠올랐다. 우어, 차라리 틀려서 망했으면 낫지 자다가 못 간 건 최악이잖아!! 버럭버럭;

아무도 없는 불꺼진 방에서 혼자 침대를 잡고 흔들고 TV 리모콘을 던지며 화풀이를 했다.

.
.
.
.
.
.

위이이이잉. 위이이이잉. 위이이이이잉.

전화가 온다. 하아, 알람 대신 타이밍 맞춰 잘도 전화한 준호였다. 22인치쯤 되는 모니터를 새로 살까 하는데 노트북에서 잘 인식이 될까 어쩌구 하는 얘기였다. 최근에 산 거니까 별 문제 없을꺼라고 안심시키고 시간을 확인하니 1시 28분.

휴우. 응미 연습이 5시라는 게 떠올랐다. 첫 퀴즈인데 망할 순 없지, 공부를 하기 위해 책을 펼쳤다.

비로소 현실이었다.

SPARCS 개강 파티를 하면서 작년 한 해 동안 학교를 비우셨던 미래 누나를 만날 수 있었다. (SPARCS 05년도 회장이었다) 06년 초에는 첫눈, NHN에서 일하시다가 가을학기에 스웨덴으로 교환학생을 갔고, 거기서 Google 면접을 통과하여 내년 3월부터 스위스 취리히에서 정식 직원(Software Engineer)으로 근무하게 될 거라고 하였다.

동아리 사람들은 드디어 우리 동아리가 구글에도 진출했다며 좋아했다. (사실 나는 꽤 전부터 알고 있었는데 다른 사람들은 잘 몰랐던 것 같다-_-) 사실 스웨덴에서 구글이 누나를 석사생으로 알고 면접을 진행하고 job offer를 줬는데 나중에 학사과정이라고 얘기했더니 본사와 한참 뭔가 왔다갔다 하더니 다시 job offer를 줬다고 한다. 면접에 대해서 물어봤더니 거의 기술면접 위주였으며 문제들 자체는 그다지 어려운 편은 아니었지만, 문제를 풀 때 혼자 골똘히 생각해서 답을 주루룩 표현하는 것보다는 풀어가는 과정을 말로 말하면서 하는 것이 중요하다고 했다. (이건 애자일이야기 블로그에서 본 오픈마루의 면접과 비슷한 방식인 것 같다) 그리고 처음 주어진 문제는 쉽지만 계속 이어서 물어보는 질문들이 중요하며, 주로 그러한 문제에 대해 고민해본 적이 있는지 알아보는 것 같았다고 한다.

구글에 대한 이야기는 이 정도로 해두고, 교환학생에 대해서 물어봤다. 우선 내 학점 정도면 학점을 특별히 더 관리하기보다는 토플 성적을 올리는 것이 중요하고(원하는 대학을 선택할 폭을 넓히기 위해서), 자기의 경우는 미국 쪽과 스웨덴을 알아봤었는데 미국 쪽은 좋은 곳을 가려면 TO가 많이 빡세다고 한다. Iowa 쪽 대학과 스웨덴을 두고 지도교수님께 찾아갔더니 Iowa 쪽은 우리학교보다 구리고 스웨덴을 추천해주셨다면서 그리로 가게 된 것이라고. 스웨덴은 외국인들이 굉장히 많은 국가이고, 여러 문화들이 공존하고 있어서 스웨덴어가 있어도 영어만 할 줄 알면 전혀 불편 없이 지낼 수 있단다. 그래도 교환학생 가기 전에 하는 각종 문화 프로그램 등에 참여하는 것이 좋다고 하였다.

누나 얘기를 듣고 대충 정리를 해본 결과, 크게 두 가지 방향이 있다. 일단 이번 가을학기까지는 전공을 어느 정도 마무리해야 하기 때문에 학교에 계속 있어야 할 것 같다.

첫번째는, 병역 문제 해결을 먼저 하는 것이다. 우선 올해 안으로 병특 취직에 필요한 정보처리산업기사 자격증을 딸 계획(5월과 9월에 시험이 있는데, URP 등의 경과 상황에 따라 9월에 하게 될 가능성이 높아 보인다)이다. 병특을 하게 된다면 08년도 TO를 알아봐서 적당히 신청해야 할 것이다. 이렇게 되면 교환학생 계획은 3년 후로 미뤄진다. (토플 성적 또한 유효기간 때문에 시험 보는 것도 연기할 것이다) 카추사를 지원할까 하는 생각도 있으나 떨어지면 얄짤없이 현역으로 간다는 이야기도 있어서 조금 불안하다.

두번째는, 여름방학 때 TOEFL에 올인한 후 시험을 다시 봐서(1학년 때 본 건 점수도 낮을뿐더러 유효기간이 지났다) 가을학기 때 신청받는 08년도 봄학기 교환학생에 지원하는 것이다. 물론 이 경우에도 자격증은 따둘 것이다. 곧 있으면 가을학기 교환학생 신청을 받겠지만 현재 영어 성적이 유효기간이 애매하게 지나버린 상태인데다 점수도 높지 않아서 조금 곤란하단다. 그리고 가을학기 때 OS와 같은 중요한 전공필수 과목을 들어야 하기 때문에 그다지 내키지도 않았다. 교환학생은 누나를 따라 스웨덴 쪽이 어떨까 하는 생각을 하고 있다. (알고보니 동아리 선배 중에 스웨덴으로 다녀온 분이 한 명 더 있었다)

미래 누나에게 그럼 구글에서 일한 다음 무엇을 할 계획인지 물어보았다. 현재 GRE 공부를 하고 있고, 그 성적이 5년 동안 유효하기 때문에 구글에서 몇 년 일하다가 미국 쪽 유학을 생각하고 있다고 한다. 아무래도 구글에서 일한 경력이면 유리하지 않을까라는 것이다.

어쨌든, 가까운 선배가 멋진 진로의 예제를 잘 보여주고 계셔서 좋았다. 나뿐만 아니라 동아리 후배들한테도 좋은 본보기가 될 수 있을 것이다. 한 가지 문제라면 나는 남자기 때문에 유학을 위해서는 병역 문제를 어떻게든 해결해야 한다는 것. 확실히 미래 누나는 병역 걱정이 없어서 자기 마음대로 죽 계획을 세울 수 있어서 부러웠다. 한창 배우고 머리 돌아갈 나이에 2년 정도를 뚝 잘라내는 것이 여간 아까운 게 아니지만, 그나마 병특 제도라도 있어서 다행이랄까. (물론 그것도 제대로 된 회사가 아니라면 거의 도움이 되지 않는다고 하고, 더군다나 2012년까지인가 점차 줄여서 완전히 없애버린다고 하니..-_-)

하아, 그나저나 이놈의 URP는 점점 빡세지는데 논문 주제는 뭘로 잡을지 고민이다. 조교님과 얘기하다가 나온 주제가 하나 있긴 하나 결국 지능제어 + Matlab + 동역학... 다 배워야 할 것 같다. 과연 URP를 내가 몇 학점짜리로 평가하게 될 지....-_- 아무튼 이것도 좋은 결과를 낼 수 있도록 노력해야지.

연세대학교의 술과 주조공장 견학 수업. Syllabus를 보면 정말 기상천외하다. 2002년부터 개설되어 꽤 유명해진 과목이라고 하며, 신입생들만 들을 수 있다고도 한다.;

• 절주 보신기간 = 중간고사기간
• 생맥주 무한정 마시기, 안주 한없이 먹기
• 주량 테스트 = 학기말 고사기간

다른 건 그러려니 했는데 기말고사에서 완전히 뒤로 넘어가지 않을 수 없었다. 주량 테스트라니. -_-;;;;;

우리학교에도 저런 수업 하나 생기면 술에 대한 거부감이나 지나친 걱정 등을 없애고 정말 올바른(?) 술 문화를 만들어내는 데 일조할 수 있을 것이다. 정말 개설된다면 어떤 반응이 나올까...;

지난 주에 C&C3 데모를 받아서 해볼 기회가 있었다. 아직 데모 버전이라 그런지는 몰라도 게임 속도가 트레일러 영상에 비해 느리다는 점만 빼면 꽤 잘 만든 것 같다. 일단 그래픽 효과는 상당히 화려해졌고, 특히 오르카 헬기의 엔진 아래로 나오는 열로 인해 아지랑이가 보이는 것을 표현했다든가, 폭발할 때 잔해가 퍼지는 것도 잘 표현했고, 건물이나 유닛의 텍스처 디테일도 상당했다.

인터페이스는 기존의 C&C와 비슷한 형태로 가지만, 보다 확장성 있게 바뀌었다. 건물이나 유닛 종류별로 건설 예약 queue가 따로 존재하고, 팩토리나 배럭을 클릭하면 해당 건물의 queue를 보여주거나(생산 건물을 지을수록 그 개수만큼 queue가 생긴다) 생산이 완료된 queue 탭을 하이라이트시켜주는 등의 기능이 추가되었다.

그 외에 이전작에서는 없었던, 유닛의 행동 상태를 지정할 수 있는 기능이 추가되었다. Hold position이나 Return fire와 같은 것들이 생겨났다. (그럼에도 불구하고 10년 전에 나온 Total Annihilation보다는 못했다.. -_-) 하지만 TA/Supcom 시리즈에 익숙해진 탓인지 Shift 키를 이용한 무한 예약 명령이 안 되는 것은 상당히 불편했다.

마우스로 줌인/줌아웃을 할 수 있게 되었지만, Supreme Commander에 비해서는 한참 못 미쳤다. 조정 가능한 범위도 너무 작을뿐더러 그나마 스크롤하는 양에 비해 시점 변화가 너무 적어서 답답했다. 대신 시점을 자유자재로 돌릴 수 있고 건물을 마음대로 돌려서 짓는다든가 하는 게 가능해진 것은 재밌었다.

게임 진행 속도를 빠르게 하고 최적화를 좀더 해서 나온다면 멀티로 재미있게 즐길 수 있을 것 같다. 물론 Supreme Commander처럼 전략적인 맛은 별로 없을 듯하고, 화려한 눈요깃거리와 유닛 상성 맞추기 등에서 재미를 찾을 수 있을 것이다. 다만 한 가지 바라는 점은 제대로 된 시나리오/맵 에디터가 나왔으면 한다는 것. Supreme Commander는 게임 엔진에서 다루는 데이터 포맷이 워낙 공개적이어서 벌써 사용자들이 만든 3rd party 맵에디터가 존재할 정도다. 개인적으로 별로 좋아하지는 않지만 스타크래프트와 워크래프트의 캠페인 에디터는 정말 높이 평가하는 부분으로, C&C3도 그런 점을 잘 이어갔으면 좋겠다.