긴장과 이완

따뜻한 이야기 2007/12/28 03:38 by daybreaker

정말 폭풍과도 같은 전공 3학년 시기를 끝내고 나니 홀가분한 기분입니다. (사실 아직 프로젝트가 하나 남아 있습니다..ㅜㅜ)

대학 들어오고 나서 매 학기마다 '아, 이번 학기가 정말 제일 힘들었어'라는 얘기를 6학기째 해오고 있군요; 그래도 이번 가을학기는 지난 봄학기보다는 조금 덜(?) 힘들었던 것 같습니다. 봄학기 때 들었던 소프트웨어 공학 개론이라는 원래는 꽤 널널한 편에 속했던 과목이 갑자기 교수님이 바뀌고 대학원 프로젝트를 학부로 끌고내려오면서 엄청나게 빡쎄지는 바람에, 매일 10시간씩 조모임하고 한 자리에 앉아서 해지는 거 보고 해뜨는 거 보고 하기를 수십번... 다른 과목들은 그냥 다 안드로메다로 가버린 슬픈 기억이 있었죠. (응용미분방정식이라는 과목에서 첫 한 달 동안 쪽지시험 만점을 받다가 나중에는 공부할 시간이 없어서 백지를 냈을 정도니까... 게다가 그나마 열심히 했던 소프트웨어공학개론마저 프로젝트 점수를 사실상 평준화시키고 얼마 비중이 안 되는 시험으로 점수가 다 갈렸죠. 결국 자체 기준으로 재수강 2개 만들고 A를 하나도 못 받은 안습의 학기가 되었습니다.. orz―원래 학기 시작하기 전에는 올A가 목표였는데 말이죠 -_-)

그러고나서는 여름학기 때 운동 + textcube.org 제작 + 동아리 System Programming 세미나 조교를 한답시고 이것저것 펼쳐놓다가 별로 쉬지도 못하고 계속 말리고, 가을학기에는 OS 프로젝트 한답시고 계속 바빴습니다. (그래도 OS 프로젝트는 2명이서 하는 거였고 팀메가 룸메였기 때문에 시간 조절이 편해서 체감 로드는 소공개에 비해서 낮았죠.)

하여간 이래저래 지친 상태에서 프로젝트 듀와 함께 이런저런 일이 겹칠 때마다 일종의 패닉 상태 같은 게 찾아오더군요. 봄학기때는 그냥 멋모르고(?) 살았던 것 같은데, 가을학기 때는 OS 2번, 3번 프로젝트 끝날 때 한 번씩 고비가 왔었습니다. 굉장히 할 일은 많은데, 아무것도 할 의욕이 나지 않고 괜히 심심하고 말리고 싶고 뭐 그런 상태 말이죠. 2번 프로젝트 끝나자마자 동아리에서 야심차게 준비한 Workshop 발표도 당일 새벽 1시부터 준비를 시작하여 밤 꼴딱 새고 유체이탈 상태로 발표하고 게다가 그날 밤에 동아리 홈커밍데이랍시고 선배들과 새벽 5시까지 술마시고 달렸으니...-_-;;

아, 정말 어떻게 살아남았나 싶군요. OS 2번 프로젝트와 워크샵이 끝나고 한동안 휴식 기간을 가졌습니다. 약 2주 정도 정말 그때그때 해야 하는 숙제 말고는 전혀 공부하지 않았죠. (그래도 그런 숙제들을 처리하는 데만도 2~3일씩은 꼬박 걸립니다.) 그래서 그나마 OS 3번 프로젝트와 겹친 기말고사를 버텨낼 수 있었지 않나 싶습니다. 마지막 수리물리 오픈북 오픈타임 14시간짜리 시험이 아주 제대로 피날레를 장식해줬다는...-_-; (그런 시험은 어차피 컨닝 같은 게 의미가 없기 때문에 정말 끈기 싸움이죠.)

2학년 때까지만 해도 어떻게 조금만 노력하면 거의 퍼펙트한 결과를 얻을 수 있었지만, 3학년부터는 80~90%까지는 금방 되어도 99%, 100%를 달성한다는 게 몇 배의 노력이 필요해졌습니다. 미리 선행학습하고 뭐 이런 거 다 필요 없고 정말 각자의 능력과 노력이 드러나게 되는 것 같습니다. 그리고 많은 선배들, 부모님이 '인생은 장기 레이스이다'라고 말했던 것을 느끼게 됩니다. 한 순간 달리고 끝내는 것이 아니고 계속 해야 할 일들이 물밀듯 밀려오기 때문에 우선순위를 정해서 어떤 것은 완벽하게 성에 차지 않더라도 적당 선에서 포기하고 더 중요한 것에 집중할 줄 알아야 하는 것 같습니다. (뭐 능력이 좋아서 모든 걸 완벽하게 할 수 있다면 또 모르겠지만...ㅠㅠ)

또 하나 느꼈던 건, 오토마타 과목을 듣는데 고등학교 동기 친구하고 정말 똑같이 숙제하고 똑같이 시험공부하고 했음에도 시험 결과를 보면 완전 천지 차이가 날 수도 있다는 겁니다.. ㅠ_ㅠ; 시험 문제가 주로 증명 스타일로 나오는데(그렇다고 책에 나온 증명을 달달 외운다고 풀 수 있는 문제는 안 나옵니다. 시간 제한은 있지만 오픈북이거든요. -_-), 나중에 그 친구와 함께 얘기해보니 문제를 푸는 스타일이 저랑 완전히 다르더군요.

저는 주로 배운 지식을 체계적으로 정리해서 나만의 언어로 변환·이해하여 그걸 가지고 뭔가 해보는 스타일인 반면, 그 친구는 일단 문제를 어떻게 풀어야겠다는 아이디어가 생각나면 그걸 맞게 유도하기 위해서 레퍼런스를 뒤지는 스타일입니다. 평상시에 숙제를 하거나 이럴 땐 크게 차이나지 않지만, 어려운 증명 문제를 풀어야 할 경우는 친구의 스타일이 더 맞는 것 같습니다. 저는 배우지 않았다면 증명 쪽으로는 일단 아이디어가 생각나지 않으니까 시작을 못합니다;; -_-; 친구한테 어떻게 풀었냐고 물어보면 중간에 감으로 건너뛰고 '그냥 이렇게 하면 될 것 같아서'라는 게 대부분입니다. 저는 그 풀이를 보고 빠진 부분을 세세하게 채워넣어주는 편이고, 친구는 거꾸로 그걸 보고 '아하~' 이러죠.;; (하지만 오픈북 증명 스타일의 시험이라면 친구처럼 되는 것이 아이디어만으로 일단 문제 답을 구해놓고 세세한 부분은 책을 보며 채워나갈 수 있으니 더 좋겠죠.)

대신에 제가 유리한 경우는 바로 OS(....)와 같은 큰 규모의 체계적인 프로그램을 만들어야 하는 경우입니다. 번뜩이는(?) 아이디어로 일단 코딩은 빨리빨리 진행시킬 수 있지만, 저는 시스템이 어떻게 이루어져 있는지 먼저 파악하고 거기에서 하나하나 쌓아가기 때문에 전체 진행속도가 아주 빠르지는 않지만 꾸준하게 계속 나아갈 수 있고 중간중간 리팩토링·코드 정리를 자주 하기 때문에 다른 사람이 코드를 보기 편해하는 편입니다. 저는 OS처럼 한 줄 한 줄 고민하며 짜는 경우, 제가 어디를 어떻게 고쳐서 어떤 문제가 왜 고쳐졌는지 거의 다 파악을 하면서 진행하지만, 그 친구의 경우는 진행이 굉장히 빨라서 물어보니 일단 어쩌다보니까-_- 고쳐졌는데 왜 고쳐졌는지는 모르는 경우가 많았습니다.

어쨌든 전공이 빡세지면서 그러한 개개인의 특징이 더욱 극명하게 드러나고 대비되는 것 같습니다. 얼마 전에 지도교수님과 면담했을 때 교수님이 절 보고 '실무적 개발 능력은 학부생 수준에서는 이미 충분하고도 남는(?) 수준에 도달해 있지만 이론적 기초를 좀더 닦으면 좋겠다'고 하신 것도 비슷한 맥락이겠지요. 사실 그래서 수리물리를 듣고 수학적 intuition을 키우고자 한 것이긴 합니다만... (.....)

죽죽 생각나는 대로 쓰다보니 제목하고는 먼 글이 되어버렸군요;; 아무튼 과제하다가 더이상 말리지 않기 위해 이만 접습니다. 결론은 한 학기 동안의 푸념. (...)

ps. 이 글을 쓰기 위해 기나긴 여정을 거쳤습니다. (...) 바로 이 글과 동일한 버그 때문인 것 같군요. OTL;;; 그야말로 딱 걸렸...

필자
author image
Daybreaker(아침놀)입니다. 현재 KAIST 전산학과에 재학 중이며 전산 외에도 물리, 음악, 건축 등에 관심이 많습니다. Needlworks 내에서는 각종 홈페이지 제작 및 서버 관리 등과 함께 Textcube 개발에 참여하고 있습니다.

홈페이지 : http://daybreaker.info

2007/12/28 03:38 2007/12/28 03:38

아이디어

머리아픈 이야기 2007/12/25 23:34 by inureyes

가끔 엄청나게 오래된 일을 한참을 돌아와서 해결하게 된다.

텍스트큐브가 태터툴즈였던 시절, 작년 중순즈음엔가 fastCGI 환경 지원에 대한 요청이 들어온 적이 있었다. 당시에는 서버에 fastCGI 환경을 쉽게 구축하지 못하였고, 그래서 자연히 뒤로 밀리게 되었다. 이후 조금씩 workaround들을 통하여 구현을 해 놓았지만 역시 제대로 돌아가지는 못하고 있었다.

작년 말에는 '외국계 호스팅에서 태터툴즈가 잘 안돌아간다' 는 문의를 받았다. 직접 서버의 권한을 받아 들어가 본 결과 서버측에서 mod_rewrite에 대하여 선처리를 미리 해 둔 상태였다. 이 경우를 처리하기 위해서는 rewrite 모듈[footnote]아파치 웹서버 등에 들어있는, 주소를 처리해서 미리 정해놓은 인터페이스로 연결해주는 모듈이다. 텍스트큐브의 글들의 주소가 괴상한 숫자등이 아니라 읽을 수 있는 문자가 되도록 도와주는 모듈.[/footnote] 에 대한 의존도를 확 줄여야 했다. 이런 경우에 주로 사용하는 방법은 rewrite 모듈의 모든 결과를 하나의 파일로 보내고, 그 파일이 요청을 모두 해석해서 처리하는 방식이다. 그러나 당시 간단하게 테스트 해 본 결과 그림파일이나 음악파일 등등등 까지도 모두 php 엔진을 거쳐서 내보내기 때문에 서버에 무리가 있었다. 소스도 엄청나게 고쳐야 했다. 기존의 방식을 고수하기가 힘들어 보였다. 소스를 대대적으로 개수하기에는 언제나 시점의 무리가 있어서 계속 그 일은 뒤로뒤로 밀려왔다.

그러면서 1년이 넘는 시간이 지났고, 잘은 모르지만 머릿속 어딘가에서 그 생각이 계속 돌아가고 있었나보다. rewrite 모듈이 없는 상황에서 돌아가는 예외 처리를 추가한다거나, fastCGI를 지원하는 예외 처리를 추가한다거나 하는 식으로 대응해 가다가 사흘쯤 전 샤워하다가 아이디어가 떠올랐다. define으로 상수를 정의하는데, 그 상수를 두 번 정의할 경우 어느쪽이 무시되는가? 에 대한 생각이었다. 실험해 보니 처음 define만이 유지되었다. 그 때부터는 문제가 연속적으로 죽 풀렸다.

텍스트큐브는 /lib/suri.php 를 통하여 현재 주소 체계를 해석하고, 어떤 부분이 주소이고 어떤 부분이 파라미터인지 파악해 낸다. 그리고 각 인터페이스 (blog 하위의 디렉토리들은 사실 인터페이스라고 부르는 것이 더 적당하다.) 에서 필요한 라이브러리를 통째로 불러낸다. 과거에는 불가능했지만, 두달 사이에 이루어졌던 컴포넌트 및 라이브러리의 독립화로 인하여 라이브러리를 불러오는 시점의 의존성이 사라졌다. 따라서 suri가 실제로 동작하기 이전이라면 주소 처리 부분을 기존의 suri가 이해하기 좋게 만들어서 suri에 코드 한 줄을 추가하여 호환성을 유지할 수도 있을 것이다. 또한 각 인터페이스에서는 모든 포함관계의 기준이 되는 ROOT를 미리 정의하는데, 인터페이스 파일이 불려지기 이전에 ROOT를 일률적으로 정의해 버리면 이후의 모든 파일 포함관계들도 전부 수정 없이 이식할 수 있지 않을까.

그래서 크리스마스 이브 전날부터 크리스마스 기간 내내 그 부분을 구현하였다. 일단 (못 고치면 블로그 못쓴다-는 자신에게로의 압박을 위해서) 개인 서버의 아파치 웹서버를 fastCGI 기반으로 변경하였다. rewrite 모듈이 보내주는 값을 해석하는 부분은 최소한의 크기로, 또한 앞에서 처리해야 유리한 루틴은 최대한 앞에서 처리하는 식으로 작성하였다. 덕분에 기존 코드는 거의 손을 대지 않은채로, fastCGI나 다양한 rewrite module들에 대한 대응이 가능해졌다.

말이 길었다. 결론은 간단하다. 아이디어는 하늘에서 떨어지지는 않는다. 그렇다고 아이디어를 낼려고 머리 싸매고 있다고 튀어 나오는 것도 아니다. 문제를 완벽히 이해할 때 까지 생각하고 곱씹는 과정에서 문제의 한계라고 스스로 생각하고 있는 무엇인가를 넘기위한 뇌의 싸이코 댄스가 시작된다. 그 댄스 중 일부가 실제로 먹히면 그 댄스에 아이디어라는 이름이 붙게 된다.

아이디어는 사고의 형태에 붙는 명칭이 아니라 이미 일어난 사고에 붙이는 자격이다.

필자
author image
inureyes 입니다. 하고 싶은 일과 해야 할 일의 균형 맞추기를 하며 즐겁게 살고 있습니다. N/W에서는 구성을, TC에서는 교리 전파? 및 사회자?를 맡고 있습니다. 오전과 오후에는 물리학을, 저녁 시간에는 코딩을 하며 삽니다.
http://forest.nubimaru.com

2007/12/25 23:34 2007/12/25 23:34

준비

차가운 이야기 2007/12/11 14:23 by inureyes

겨울입니다.

산골짝의 다람쥐 아기다람쥐가 도토리 점심가지고 소풍을 가던 가을은 지나갔습니다. 곧 겨울이 올테고, 소풍 다니느라 나무에 도토리를 가득 채워놓지 않았다면 곧 배고파 죽을겁니다. 가마솥에 쌀밥이 가득 들어 있다고 하여 밥을 퍼먹는 것에 정신이 팔리면, 쌀이 떨어지는 것을 알아챘을 때는 이미 눈이 한마당 쌓여 밖으로 나갈 수가 없게 된 후일겁니다.

뜬금없지만 텍스트큐브 1.6 트리를 잠시 놓고 텍스트큐브 2의 기반 설계와 구성요소 드래프트를 손대고 있습니다. 1.6을 내놓고 나면 바로 2.0을 만들 수 있을 것 같지만, 지난 1년을 교훈삼아 보면 그렇게 되지는 않을겁니다. 1.6.1도 나가야 할테고, 1.6.2도 나가야 하겠습니다. 유지보수에 신경을 쓰다가 보면 또다시 목표는 살짝 멀어질 것이 분명했습니다. 그렇다면 누군가 유지 보수를 맡는 동안 새로운 프로그램을 만드는 과정이 동시에 이루어져야 할 겁니다. 하지만 새로운 프로그램을 만들 때, 설계와 재료가 준비되어 있지 않으면 결국 기반이 준비될 동안 많은 사람들은 할 일이 없어지게 됩니다. 그렇게 되지는 않아야겠죠.

위의 상황이 올해 9월 이후의 문서화 과정에서 일어 났었습니다. 문서화 전용 프로그램인 파피루스가 준비되지 않아서 대부분의 문서화 작업과 국제화 작업은 멈춰 있는 상태입니다. 멈춘 상태가 1주일이라면 사람들이 견딜 수 있지만, 3개월 가까이가 되면 열정이 식어버립니다. 파피루스는 아직도 제작 중이고, 문서화는 아직도 요원합니다. 그 사이에 생긴 차이점이 있습니다. 처음에 문서화 및 번역에 나서겠다고 하신 분들의 이야기가 아직까지도 유효할 지 전혀 장담할 수 없다는 점입니다. 이후 텍스트큐브 2.0의 코드에 있어서 그렇게 되는 것을 막으려면, 기반 부분의 준비가 더 늦으면 안되겠다는 생각을 했습니다.

설계는 올해 봄부터였지만, 항상 지식에 있어서 부족한 부분이 있었습니다. 코드를 잘 짜는 부분의 문제는 아닙니다. 코드는 지금도 그다지 잘 짜지 못합니다. 사람은 아는 만큼 생각의 폭을 넓혀 갈 수 있습니다. 그런데 '데이터'에 대해서 단순히 데이터베이스와 테이블 이런것 말고 무엇을 더 알고 있나 생각해보니 많이 아는 것이 없었습니다. 그래서 좀 더 많이 알려고 대학원 데이터베이스 과목을 들었습니다. (과목에서 필요한 것 보다 훨씬 더 근본적인 부분들을 다루었기에 힘들었습니다......) 모르면 배워야 합니다. 알고 있는 말이지만 참 힘들었습니다.

배운 것들과 함께 여러가지 공부를 하고, 엉성하게나마 데이터 모델을 만들었습니다. 가능하면 텍스트큐브 1.6과 병행해서 개선시키고, 이후 텍스트큐브 2.0의 개발을 이 데이터 프레임웍 위에서 할 수 있었으면 합니다. 겨울이 오고 있고, 연구, 논문 작성, 텍스트큐브, 여행 등등 할 일의 리스트도 쌓여가고 있습니다. 그리고 나름의 방법으로 겨울을 준비하는 중입니다.

'무엇이 세상을 움직이는가' 보다 훨씬 어려운 질문은 '무엇이 사람을 움직이는가' 라는 생각을 하는 요즘입니다.

필자
author image
inureyes 입니다. 하고 싶은 일과 해야 할 일의 균형 맞추기를 하며 즐겁게 살고 있습니다. N/W에서는 구성을, TC에서는 교리 전파? 및 사회자?를 맡고 있습니다. 오전과 오후에는 물리학을, 저녁 시간에는 코딩을 하며 삽니다.
http://forest.nubimaru.com

2007/12/11 14:23 2007/12/11 14:23