앞서 모종의 테스트 목적 및 개인 사용 목적으로 명함을 하나 만든다고 했었다. 지난 주 목요일에 주문, 드디어 도착했다. 드디어 공개한다.

명함 작업본

실제 인쇄 결과물

확실히 그라데이션 처리한 부분이 인쇄는 의도대로 잘 되었음에도 눈으로 보기에는 모니터보다 훨씬 연하다. (자세히 들여다보면 잉크 망점이 찍혀는 있으나 너무 작아서..-_-) 색깔은 RGB 빛으로 색을 내는 모니터에 비해 조금 덜 화사하게 나왔지만 어느 정도 예상했던 바였고, 룸메 말로는 오히려 인쇄한 게 낫다고(...) 하니 이 정도면 만족.

다만 살짝 아쉬운 것은 진한 검정 배경에 컬러 글자를 찍으면서 검정과 다른 색상들의 위치가 정확하게 맞지 않아 0.1mm 이하 정도로 어긋나는 바람에 자세히 보면 글자 획의 오른쪽 방향으로 흰줄들이 아주 가늘게 보인다는 것. 그래도 이 정도면 만족할 만한 품질이다.

뒷면의 비트맵 이미지는 아마 이 블로그를 계속 봐온 사람이라면 알 것이다. 새로 이사 간 집의 부엌에 달기 위해 그린 그림인데, 단면으로 만들자니 심심하고, 양면으로 만들자니 딱히 뒷면에 넣을 만한 것(개인 명함이다보니 회사 약도나 로고를 넣는다거나 할 것도 없고 하니까)이 없어서, 내 개성을 살리자는 뜻에서 내가 직접 그린 작품을 넣은 것이다.

비트맵의 해상도는 권장 300dpi보다 낮은 240dpi 정도인데, 잉크 망점들로 인쇄가 되어 있어서 계단 현상은 전혀 보이지 않는다. 어떻게 나올까 가장 걱정했던 부분인데 깔끔하게 잘 나왔다. 재단선 처리도 작업할 때 생각하고 했던 것하고 거의 똑같다.

자, 그럼 이제 다음 번 블로거 모임 등에 나갈 때부터 이 명함을 쓰면 되겠지. 우선 동아리 사람들한테 좀 돌려야겠다. :D

덧. 살짝 이름의 위치를 조금 더 왼쪽으로 했으면 좋았을 걸 하는 생각이 든다.;

참고: 디카로 찍은 사진을 다시 모니터로 보니 실제 종이를 눈으로 보는 것과는 또 다르다. 그래도 이 정도면 대충 차이를 알 수 있을 듯?;;

...무려 열흘이 넘도록 블로그에 글을 하나도 안 썼다. 이게 다 미투 때문이다(?). -_-;

1. 명함 만들기

몇 가지 실험(?)을 위한 모종의 테스트 목적을 포함, 개인 명함을 하나 제작했다. 직접 디자인해서 인쇄만 맡겼는데, CMYK 색상이 실제로 어떻게 나올지 몰라서 색상이 어떨지 조금 걱정되기는 한다. 오늘(4월 30일) 배송 예정이며 도착하면 사진 찍어서 블로그에 올릴 생각.

2. Tatter Network Foundation & Needlworks

지난 1년여 동안 활동해온 Tatter & Friends가 이제 슬슬 변화를 꾀하고 있다. 단순히 포럼을 통한 공개 커뮤니티로서의 TnF가 아닌, 보다 큰 스케일의 프로젝트를 강력하게 추진할 수 있도록 하기 위한 TNF 재단의 구체화, 그리고 그 핵심 task force라고 할 수 있는 Needlworks 팀의 탄생이다.

자체 메일링 리스트를 통해 한 쓰레드에 수십~백개에 이르는 메일 토론이 하루 건너 매일 이루어질 정도로 활발한 내부 커뮤니케이션과 함께, 태터툴즈와 관련하여 몇 가지 큰 사건(?)을 터뜨릴 준비를 하고 있다.

3. 중간고사

사실 블로그에 글이 뜸해진 가장 큰 원인은 이것. 아직 시험결과가 나온 과목이 응용미분방정식밖에 없어서 결과에 대해서는 뭐라고 말을 못 하겠고, 다만 느낌상 고전역학과 전산기조직은 그럭저럭 잘 본 것 같다. (알고리즘은 최악의 경우 반타작, 가장 좋은 경우도 80% 정도일 듯하고, SE는 시험이 별로 중요한 과목이 아닌데다 시험 자체도 정답이 딱 존재하는 류가 아니라서 그다지 할 얘기가 없다.)

응용미분방정식의 경우는 생각보다 계산 노가다에 대한 감점이 적어서 전반적인 학생들의 점수는 꽤 높게 나온 편인데, Cauchy-Euler 방법으로 풀어야 하는 2번 문제를 전혀 엉뚱한 방법으로 풀려고 시도하다가 gg치는 삽질을 한 게 화근이었다. (오히려 다른 사람이 어렵다고 하는 문제는 그럭저럭 방법을 잘 선택해서 푼 편이다) 물론 방법은 다 맞게 풀었으면서도 계산 실수로 인해 만점 받은 문제는 별로 없었고, 적분 상수 처리를 빼먹는다든가 계수를 살짝 틀리게 썼다든가 해서 대체로 1~2점 정도씩 감점. (근데 이게 모이니까 꽤 크다;;;) 문제는 평균이 생각보다 높다는 거. 그래도 기말 한큐라고 하니 기말을 노려볼 수밖에 없다. 선대개처럼 재수강할 일은 만들지 말아야지. orz

4. Supreme Commander

학기 중에 거의 하지 못했던 수프림 커맨더의 각 종족별 미션을 모두 클리어했다. 그러나 핵미사일이 떨어지는 몇몇 지점을 방어해야 하는 방어 미션에서 하드로는 타이밍을 맞추지 못해 중간 난이도로 하고 넘어가서 살짝 아쉽다. (사실 시간이 충분히 많다면 삽질해서 해결해보겠지만...-_-) 미션을 다 깼으니 멀티를 해볼까- 했더니 갑자기 GPGNet이 접속이 안 되는 불상사가 벌어졌다. ㅠ_ㅠ (재설치하고 패치 다시 해보고 방화벽 꺼보고 별짓 다 해봤는데 쥐쥐..)

한편, 프로그래머의 관점에서 Total Annihilation 때와 마찬가지로 매우 뛰어난 확장성을 보여주고 있는 게임 엔진은 감탄을 금치 못하게 만든다. 공식 개발 도구가 빨리 공개되었으면 좋겠다.

5. Command & Conquer 3

내가 처음 접한 컴퓨터 게임이 커맨드앤컨커 시리즈였고, 레드얼럿까지는 모든 미션을 클리어했을 정도니 상당히 정이 많은 게임이다. 타이베리안 선은 정품 구매를 했으나 당시 내 사양이 딸리는 바람에 제대로 못 즐기고 처박아두기도 했다. 어쨌든, Supreme Commander 다음으로 기대했던 전략시뮬레이션 게임이고, 또 한때 골수 팬이었던 만큼 꼭 해보고 싶은 게임 중 하나다. 그러나 학교 내에서는 IRC 포트가 막혀있는 관계로 멀티플레이가 안 된다는 캐안습한 사실. OTL

6. Springnote 위키 개설

OpenAPI 지원과 한국 사용자 입맛에 맞춘 편집 인터페이스로 사랑을 받고 있는 스프링노트. 기존에 설치해서 쓰던 moniwiki가 있긴 했으나, 활용도가 떨어져서 그만두게 되었다. 그러나 스프링노트의 경우 기본 인터페이스가 편집용이라서, 단지 글 보기만을 하는 경우는 산만한 감이 있다. API를 이용해 글을 긁어와서 최대한 심플한 인터페이스로 보여주고 댓글/트랙백을 달 수 있는 형태의 매시업을 만들어볼까 생각 중이다.

아까 고전역학, 전산기조직 시험을 연타로 보고 뻗었다가 한숨 자고 일어나보니 뉴스속보가 하나 올라와있었다. 버지니아텍 총기난사 사건. 덜덜덜하면서도 역대 최대 규모라길래 놀라긴 했는데, 조금 있으니까 그 범인이 한국인이란다. 당장 아침 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화하는 건지, 템플릿 하나를 클래스 하나로 보는지 등등...)