Needlworks/TNF 블로그

도움닫기

(inureyes) — Sat, 04 Apr 2009 01:35:49 +0900

놀고 있는 블로그마냥 요새 저희가 좀 뜸합니다. 텍스트큐브 1.8도, 2.0도 로드맵 안에서만 돌고 있고, 1.7.7도 한참 늦게 등장했습니다. IIS 지원이니 구글맵 지원이니 등등 뭔가 하기는 하는데, 티가 좀 안 납니다. 뜸한 이유가 여러가지 있겠지만 주된 이유는 사람입니다. 니들웍스가 살짝 뜸하게 움직이는 중입니다.

저를 예로 들면, 포럼 죽돌이였던 예전과 다르게 요새는 포럼에서는 드문드문 보일 정도로 뜸합니다. 결혼을 했기 때문이라고 생각하시는 분들도 계시겠지만 주말부부이기 때문에 결혼해서 바쁘다는 그런 이유는 아닙니다. 물론 신혼여행 다녀와서 3주동안의 코드 변화를 따라잡느라 고생은 좀 했습니다. (제가 없어야 전체 커밋 수가 늘어난다는 놀라운 사실을 배웠습니다...) 각설하고, 요새 제가 뜸한 이유는 박사과정 대학원생이라, 저 노는 사이에 컴퓨터 시뮬레이션이 지금까지 했던 연구들 중에서 결론이 난 것들이 있어 정리를 하는 중이기 때문입니다. 사실 이건 핑계고, 항상 때가 되면 하는 일이라 주된 이유는 아닙니다.

요새 잡다한 공부를 하고 있습니다. 원래 관심사나 공부하는 내용들은 주로 물리학이나 사회학같은 이론적인 주제들 이었습니다만, 요새 하는 공부는 컴퓨터 프로그래밍입니다. 원래 코딩을 잘 하는 편이 아니라 그냥 필요할 때 필요한 것만 겨우 만들어 쓰는 수준입니다. 그게 한계가 온거죠. 올해부터 해 보려고 하는 연구들이 굉장히 큰 계산들을 필요로 하기 때문에 오래간만에 좀 고생을 해 가면서 컴퓨터 프로그래밍 공부를 하고 있습니다. 약간 만질 줄 아는게 C++ 정도라 자바 언어등의 요새 언어들도 한 번 공부해 보고, 멀티 쓰레드 프로그래밍이나 CUDA 를 사용한 GPU 연산을 공부하고 있습니다. 직렬식 프로그래밍만 하다 보니 가끔은 병렬적으로 사고하기가 어렵습니다. 머리가 복잡해질 때면 그저 ㅁㄴㅇㄹ!@#

한 달 남짓 공부를 하고 나니, 그 전에 비하여 조금은 나아지지 않았나 싶습니다. 불명확하게 알고 있던 점들을 조금 더 명확하게 알게 된 것들도 있고, '요새 경향이 이렇구나' 하는 점들도 새로이 배우게 되었습니다. 그렇다고 코드를 조금 더 잘짜게 된 것은 아닌것 같지만, '요새 컴퓨터'를 어떻게 보아야 하는지를 익힌 듯 합니다. 예전이나 지금이나 프로그램이 CPU와 RAM이라는 한정된 생태계 안에서 사용자라는 신의 선택을 받기 위하여 고군분투해야 하는 것은 같습니다만 (8년전에는 이러한 생각 을 했었습니다.), 지금의 프로그램과 컴퓨터는 훨씬 복잡한 구조를 바탕으로 예전과는 비교할 수 없는 복잡함 속에 모든 것이 돌아가고 있는 듯 합니다.

어떤 발전이든 외부에서 보면 어느 순간 임계점을 넘는 식으로 보입니다. 하지만 그렇게 임계점을 넘기 위해서는 굉장히 느리지만 지속적인 변화가 쌓여야 합니다. 니들웍스나 TNF도 그런 단계를 밟고 있는 것이 아닌가 싶습니다. 3년 전의 생각대로 도구가 일상화되고, 변화가 받아 들여지는 세상이 왔습니다. 그 너머 해야 할 일은 무엇일까? 같은 질문에 대한 답은 질문을 들고 고민을 해서 나오는 답이 아닌 것 같습니다. 그래서 여러가지를 공부하고 있습니다. 피라미드도 밑둥부터 쌓아야 꼭대기를 올릴테니까요. 무엇을 하고 싶은지와 크게 상관 없어 보이는 것들도 꾸준히 배우는 중입니다.

삶 자체는 공부 거리로 가득 차 있습니다. 전혀 연관없을 것 같은 배움과 깨달음들이 다시 텍스트큐브에 집중되는 시간이 곧 오리라 생각합니다. 요리는 어느정도 됐다 싶어서 슬슬 PHP에 다시 눈을 돌리고 있는 inureyes였습니다. 곧 니들웍스와 TNF의 모든 공헌자 분들과 함께 이 다음에 할 일에 대해서 이야기 해 볼 시간을 가져보기를 고대하고 있습니다.

덧) 진짜 텍스트큐브 1.8이 늦어지는 이유는 개발하던 텍스트큐브의 새 프레임웍이, 이론상으로 논의되던 것과는 다르게 구현을 해 본 결과 성능 문제가 너무 커서 제주도에서 한 번 뒤집은 후 좌절의 텀이 길어지고 있어서라는 농담같은 이야기가 있긴 합니다. ㅎㅎ

컴퓨터 길들이기

(daybreaker) — Sat, 24 Jan 2009 03:18:31 +0900

텍스트큐브 개발을 해오면서 수많은 사용자들의 건의와 질문을 받습니다. 설치 과정에서 DB 정보를 입력해야 하는데 그게 뭔말인지 몰라서 질문하는 경우부터, 스킨을 수정하는데 특정 브라우저에서 깨지니까 소스 주면서 어떻게 고쳐야 되냐고 물어본다거나, 굉장히 세세한 동작에 대한 옵션을 추가해달라는 경우까지 정말 다양하지요.

문제는 오픈소스 커뮤니티의 특성상, 사용자들의 모든 요구에 일일이 응대해주기도 어려울 뿐더러--사실 전문대응팀을 가진 큰 기업도 쉽지 않은 일입니다만--각 요구를 우리가 추구하는 목표에 맞게 자를 건 자르고 받아들인 건 받아들인다면 그 기준을 어떻게 세울 것인가도 큰 문제입니다. 100% 사용자의 요구에 맞출 수도 없는 일이고(사공이 많으면 배가 산으로 간다고 했습니다), 우리의 목표에 맞추자니 당장의 버전 로드맵부터 개발자의 취향(!)에 이르기까지 다양한 변수의 영향을 받습니다.

개발 프로세스를 좀더 세분화해서 알파 단계까지 새 버전에서 지원할 기능 목록을 확정하고 베타에서 테스트하고 발표후보 단계에서 다국어 번역 및 최종 디버깅하는 식으로 가면 가장 이상적이겠습니다만, 그럼 그 지원할 기능 목록을 정하기까지 어떤 기준으로 잘라내야 하는지는 사실 정답이 없는 문제라는 겁니다. 기술적으로 봤을 때 구현난이도를 포함, 현재 프로그램의 구조에 잘 끼워맞출 수 있는 것인지 볼 수도 있고, 무조건 이건 사용자가 원하는대로 가야 한다는 식이 있을 수도 있고 그 둘의 절충안이 있을 수도 있겠죠.

어떤 분들은 자신이 처한 상황을 매우 잘 분석해서 정말 도움을 드리고싶게끔 하시는 경우도 있지만, 어떤 분들은 무조건 자기가 필요로 하는 것을 해결해달라고 하는 경우도 많습니다. 물론 저 또한 제가 사용하는 다른 제품이나 소프트웨어에 대해서 그런 태도를 보일 때도 있을 것입니다. 어쨌든, 이런 사용자 지원 요청들을 중간에서 적절하게 잘라서 영양가 있는 것만 골라내야 하는데 그게 참 어렵습니다. 누가 그 일을 할 것인가도 문제고, 누가 그 기준을 세울 것인가도 문제고...

* * *

한편 얼마 전 이런 글을 읽었습니다. 컴퓨터가 일상에서 너무나 자주 사용되는 물건이 되었기 때문에, 이제는 마치 펜과 종이를 다루듯 컴퓨터 교육도 변해야 한다는 내용이었습니다.

예를 들면, 국어 시간에 글쓰기 방법을 가르치면서 문단 개념과 함께 HTML의 p 태그와 br 태그의 차이점을 알려준다든지, 수학 시간에 함수를 배우면 이 개념을 그대로 구현한 함수형 프로그래밍 언어 실습을 한다든지, 가사에 관해 다루는 가정 시간에는 컴퓨터 운영체제 설치하는 방법을 가르친다든지 말이죠.; 미술 시간엔 문서 디자인 정의하는 방법을 실습해보고, 음악 시간엔 MIDI 소프트웨어로 써보며, 도덕 시간에는 네티켓에 대해 배우는 겁니다.

컴퓨터는 현대의 학생들에겐 마치 연필과 같은 존재입니다. 더이상 '컴퓨터'라는 별도의 과목에 가두어두기보단 생활과 모든 분야에 자연스럽게 녹아들어갈 수 있도록 해야 한다는 것이 그 주장의 요지입니다.

한 가지 질문을 해보겠습니다. 이 글을 보시는 여러분들 중 워드프로세서의 구조적 서식 기능을 얼마나 사용하시나요? 구조적 서식이란 미리 제목, 부제목, 문단, 캡션 등의 속성을 글에 적용해놓고 각각에 대한 서식을 정의함으로써 문서 전체에 일관성있는 디자인을 적용하는 걸 말합니다. 웹에 비유하자면 h1, h2, h3, p 태그 등으로 잘 작성해놓은 문서에 CSS로 서식을 입히는 것과 같죠.

이런 기능이 있다는 것을 모르거나, 있는 걸 알고 있어도 그냥 당장 눈에 잘 보이면 되니까-하고 안 쓰는 경우도 있을 것입니다. 혹은, 어딜가나(다른 프로그램으로 옮겨서 보거나 다른 문서에 붙여넣었을 때) 내가 편집한 건 무조건 똑같이 보여야 한다는 생각 때문일 수도 있겠죠. 가끔은 그런 구조화 기능이 실제 사용자가 필요로 하는 구조화를 미처 다 지원하지 못하여 어쩔 수 없는 경우도 있습니다.

특히 마지막과 같은 경우로 얼마 전 아버지가 쓰실 파워포인트 슬라이드 정리를 했었는데, 파워포인트가 제공하는 '제목 - 항목 나열'의 구조로는 '제목 - 현재 섹션 - 1개 이상의 페이지 부제목 - 부제목 별 항목 나열'이라는 구조를 도저히 흡수시킬 수 없었기 때문에 결국 일일이 서식 노가다를 해야 했었습니다.

* * *

사람들이 컴퓨터를 컴퓨터로 보지 않고 일상에서의 도구로 보게 되는 날이 오면, 아마도 지금은 기술자들이나 다루는 추상화라고 생각하는 것들이 자연스런 상식으로 받아들여지거나 아니면 애초에 기술이 존재하는지 모를만큼 자연스러워지거나 하게 될 것입니다.

그렇지만 언제나 그렇듯 추상화의 구멍이 생기는 순간 어쩔 수 없는 부분들이 생깁니다. 바로 위의 파워포인트 서식 사례가 바로 그렇습니다. 그러면 여기서 제가 마이크로소프트에 저런 서식 구조도 지원해달라고 건의해야 할까요? 만약 건의를 해서 받아들여진다면, 결과가 사용자가 직접 파워포인트의 템플릿을 정의하고 각각에 대한 디자인 요소 이름을 정의할 수 있게 만든다면 디자인 서식들이 이를 '일반적으로 잘' 지원할 수 있게 하기 위한 오버엔지니어링이 엄청날 겁니다. 그리고 그게 저한테는 편하다손 치더라도 다른 사람들한테도 편할 것인지는 절대 장담할 수 없습니다.

제가 보기엔 텍스트큐브 포럼에 올라오는 많은 건의와 질문들 중 이런 경우도 종종 있는 것 같습니다. 물론 그렇다고 사용자분들께 건의하지 말라는 건 아닙니다. 언제나 그렇듯(^^) 모든 분들의 의견은 어떤 식으로든 소중하니까요. 다만 그러한 건의들의 우선순위를 결정하고 그 기준을 세우고 거기에 적절한 인력을 할당하는 일은 정말 어렵다는 이야기를 하고 싶은 것입니다. 기준이 구체화될수록 결정은 쉬워지겠지만 그만큼 놓치는 것도 많을 겁니다.

* * *

위지윅 에디터는 무조건 사용자가 눈에 보이는 문서를 편집하기 쉽게 만들어져야 할까요 아니면 문서의 구조화를 통해 서식 기능을 활용하도록 만들어져야 할까요?

개발자가 아닌 분들은 이런 문제에 대해 어떻게 생각하시나요? 정말 궁금합니다.

새해인사 올려요

(LonnieNa) — Sat, 03 Jan 2009 23:34:49 +0900

'텍스트큐브' 니들과 웍스들?

안녕하세요. LonnieNa(윤식) 입니다.

2008년은 벌써 저 뒤에 있네요.
아직 3일 밖에 안지났는데 말이죠.
벌써! 작심삼일에 넘어가신 분은 계시련지요? 헤헤
Needlworks(니들웍스)에서도 신년인사를 올려야 하는데 맴버들이 다들 바쁘신지라,
(내부적으로 오는 10일 이제 유부남의 세계로 가시는 inureyes(신정규)님 많이 축하해주세요~)
매번 놀고 있는 제가 ㅠ.~ 먼저 인사올립니다.

길면 길고 짧으면 짧다던 1년동안 2008에 익숙해져버렸는지 2009라는 숫자가 너무나도 어색하기만 합니다.
벌써부터 신년계획 주루룩 세워놓고 스케쥴 빡빡히 채워두신 분도 계실테구요.
아직 미처 망설이고 계신분들도 계실거구..
저처럼 응, 아직 2008년에 미련을 못버려 애태우고 있는 분은 안계시겠지요?
지나간건 이제 다 잊어버리고 그 중 좋았던 기억들만 가지고 가자구요.
봄날의 싱그러운 아침 햇살, 여름날의 시원한 바다소리, 가을날의 여유로운 바람의 느낌, 그리고 겨울날 즐겁기만 했던 눈오던 그 날..
앤하고 영화보며 웃었던 기억 들.. 뭐 그런것들이요.

지난 2008년 니들웍스에서는 무슨 즐겁고 재미난 일들이 있었을까요?
P2, S2, TNC, DAUM, Tistory, Google.. 아는 사람만 아는 그런 이야기들..
사실 저도 이런 어려운말 잘 모르거든요;;
이런 것들보다 더 중요한건 앞으로의 2009년 이랍니다아.

'니들웍스는 모두가 서로 아끼고 아껴서, 그래서 그 맘가득 담아 한해동안 더욱더 한발짝 나아가는 우리가 될거에요오~'

2009년엔 더욱 더 많이 지켜봐 주시구요, 응원해 주세요.
2008년의 그 커다란 사랑이 있어 오늘의 2009년을 더 힘차게 내 딛을 수 있었습니다.
수많은 덕담, 바라는 말, 그 무엇을 다 이루면 그 끝엔 행복이 있답니다.
마지막으로..
더도 덜도 말고 여러분들에게 행복만, 사랑만 가득하길 빌겠습니다.

'여러분들이 있어 오늘도 저희는 삽질을 합니다.'

오랜만에 광고글 하나

(daybreaker) — Wed, 03 Dec 2008 23:52:36 +0900

아아, 눈물이 앞을 가리는군요.

Save The Developer! - IE6는 제발 더이상 쓰지 말아 주세요.

온갖 웹서버와 웹브라우저에 대응해야 하는 텍스트큐브 개발진으로서 매우매우 공감가네요. 제발, 제 머리털 좀 덜 빠지고 제가 제 명에 죽을 수 있도록 IE6 쓰시는 분들은 업그레이드해주세요. ㅠ_ㅠ

이제 국내의 어지간한 사이트들도 IE7에서 문제 없이 돌아갑니다. 인터넷 뱅킹, 쇼핑, 결제 등등 문제 생기는 곳은 더이상 안 보이는 것 같습니다. 그러니 제발 개발자들이 더 나은 인터넷·웹 서비스를 제공할 수 있도록 다같이 도와줍시다~

시간의 흐름, 그리고 오픈소스

(daybreaker) — Mon, 13 Oct 2008 01:55:11 +0900

최근 모종의 일(?) 때문에 우분투를 본격적으로 써야 할 일이 생겼습니다. 뭐, 그동안 데비안이나 우분투를 서버용으로 오랫동안 사용해왔기 때문에 새삼스런 일은 아니지만, 이번에는 데스크탑 운영체제로 사용해야 했기 때문에 실제 작업 환경을 구축하는 일이라 좀더 다른 의미가 있지요.

제가 데스크탑 버전을 마지막으로 써본 것이 우분투 6.x 시절입니다. 노트북에 멀티부팅으로 깔아서 잠깐 써봤던 정도이고, 아직 본격적으로 이용해야겠다는 생각은 들지 않았었습니다. 절전 모드 동작이 불안하다든지, 당시만 해도 소리가 나오게 하기 위해 설치 후 잡다한 삽질을 해야 했다든지, 특히 설치 직후 한글 입력과 미려한 한글 글꼴 사용을 위해 이것저것 해야 할 일이 너무나 많았습니다. 관련 지식이 있는 사람이라면 그래도 한두 시간의 삽질로 해결할 수 있겠지만 전혀 경험이 없는 사람들이나 일반 사용자들의 경우엔 접근하기 어려웠고, 우분투를 주 운영체제로 사용한다는 건 일종의 모험 같은 것이었습니다.

시간이 흘러흘러 2년여가 지났습니다. 약 2년 전부터 듀얼코어급 데스크탑을 사용하기 시작했고, 학교에서 라이센스를 나눠준 Windows Vista를 써오고 있었습니다. 그러다가 얼마 전 새 하드디스크를 구입하게 되었고, 그동안 가상머신에서 깨작깨작(...) 가지고 놀던 우분투를 멀티부팅으로 제대로 깔아볼 수 있었습니다.

우선 놀라운 것은 별다른 설정 없이, 설치 과정에서 한글 키보드 레이아웃을 선택한 것만으로 한영 전환이 기본으로 동작했다는 점입니다. 한글 윈도우를 쓴다면 지극히 당연한 일이지만, 리눅스에서는 아직까지 당연한 게 아니었습니다. 제가 할 일은 두벌식 대신 세벌식을 쓰도록 바꾸는 정도 뿐이었습니다. 글꼴 또한, 최근 배포되기 시작한 NHN의 나눔 시리즈나 아리따체 등 기본 은글꼴 시리즈 외에도 선택의 폭이 커져 보다 미려한 화면을 볼 수 있게 되었지요. (특히 나눔고딕의 경우 우분투에서 웹페이지 기본 글꼴로 아주 잘 어울립니다.)

우분투 듀얼모니터 적용 스크린샷

게다가, Windows Vista도 한 번에 잡지 못했던 8800GTS 그래픽카드 드라이버도 독점드라이버 사용 클릭 한 번으로 해결했고, 고급 사용자들만이 성공할 수 있었던 무한한 삽질(-_-)의 듀얼모니터 설정 또한 nvidia-settings라는 프로그램을 이용해 아주 간단하게 끝마칠 수 있었습니다. 거기에 절전·최대절전모드까지 완벽하게 동작하고 있습니다. ㅠ_ㅠ

이제 윈도보다 설치가 간단해진 것 같습니다. 웹브라우저, 오피스, 통합 메신저 등이 기본으로 깔려 있기 때문에 개발자처럼 특별한 소프트웨어를 필요로 하는 경우가 아니라면 설치 후 기본 UI 글꼴, 바탕화면 그림 등 몇 가지 손보는 것 외에는 별로 할 일이 없습니다. 다만, 오픈소스 운영체제의 특성상 처음부터 독점 소프트웨어를 설치할 수 없기 때문에 mp3를 처음 재생할 때 코덱 설치 안내가 뜬다든지 그래픽카드 드라이버도 한 번 더 클릭해서 활성화해줘야 하는 단점은 있지만 어차피 윈도우 깔고 나서도 칩셋 드라이버며 온갖 드라이버를 깔아야 하는 수고스러움을 생각한다면 오히려 더 간단합니다. 그래픽 드라이버 쪽에서 아직 독점소프트웨어에 의존해야 하는 부분은 있지만, ATI도 오픈소스 드라이버 발표를 확정했고(아직까지 ATI보다는 nVidia 쪽이 리눅스에서 쓰기 편합니다), nVidia의 리눅스 드라이버 지원도 잘 이루어지고 있어 사용자 입장에서는 전혀 문제될 것이 없습니다.
사실 아주 초창기 때는 리눅스의 그래픽 환경을 사용하기 위해 자기가 가진 모니터와 그래픽카드가 지원하는 수직·수평 주파수 값을 알고 있어야 했을 정도니 사용자들이 쓰기엔 요원해보이는 적도 있었습니다.

저는 놀랐습니다. 하나의 철학으로 시작한 오픈소스 운동이 수많은 사람들의 손을 거치며 리눅스를 탄생시키고 그것이 점점 발전하여 이제는 정말로 사용자 입장에서 쓸 만한 그 무엇이 되었다는 것에 말이죠. 물론 우분투 뒤에는 엄청난 재력가인 마크 셔틀워스의 든든한 후원이 있었기는 합니다만 기본적으로 오픈소스 철학 하에 만들어지고 있고 그의 지원이 없었어서 시간이 더 걸렸더라도 결국엔 이렇게 발전했으리라 생각합니다. 아무튼, 이제 슈프림 커맨더와 같은 윈도우 전용 게임을 하거나 비주얼 스튜디오 개발을 하지 않는 이상 우분투를 메인으로 써도 되겠다는 생각이 들었습니다.

인터넷 뱅킹과 전자상거래를 이미 모든 웹브라우저에서 이용할 수 있는 유럽에서는 실제로 우분투를 메인 운영체제로도 많이 사용하고 있습니다. 스웨덴 교환학생할 때 기숙사 같은 층 친구도 우분투를 데스크탑 운영체제로 사용하고 있었지요. (아, 한국의 IT 현실이 이럴 때 특히 안타깝습니다.) 자신의 용도에 맞추어, 굳이 상용 제품 없이도 컴퓨터 생활을 할 수 있는 세상을 리눅스와 우분투가 열어주었습니다.

상용 소프트웨어들도 그 나름대로의 장점이 있습니다. 문제가 발생했을 때 따질 수 있는 창구가 존재한다는 점이 대표적이겠죠. 하지만 이제 오픈소스 소프트웨어들도 상용 소프트웨어만큼의 기능·성능을 가지기 시작했고 그로 인해 기업들이 독과점할 수 있는 여지를 줄여버렸습니다. 따라서 오픈소스의 존재로 인해 상용 제품을 파는 기업들은 계속해서 부단히 노력해야 할 수밖에 없고, 이는 소비자 입장에서 보다 다양한 선택권을 주는 효과를 가져옵니다.

니들웍스의 모토 또한 그러한 웹의 다양성 유지·확보가 중요한 부분을 차지하고 있죠. 텍스트큐브 또한 마찬가지입니다. 누구나 생소한 개념이었던 블로그를 비교적 손쉽게 설치하고 사용해볼 수 있는 토양을 마련하였고, 이는 우분투와 같이 독점 서비스들에 대한 훌륭안 대안재가 되었습니다. 한편으로는 그만큼 더 분발해야겠다는 책임감도 생깁니다.

저는 가끔 생각합니다. 단순히 지식정보화시대라는 낱말로 표현되지 않는 오픈소스가 세상을 어떻게 변화시켰는지, 어떻게 변화시키게 될지에 대해 후대의 역사학자들이 어떻게 평가할지 말이죠. 인류가 수백, 수천년 후에도 계속 번영한다면 아마도 굉장히 특이한, 굉장히 중요한 사건으로 기록되지 않을까 싶습니다.

이상 갑자기 쓸데없는 감상(...)에 젖어본 우분투 사용자(...)였습니다;;;

ps. 여기서 '독점'이란 단어는 단순히 시장을 장악한다는 의미뿐만 아니라, 폐쇄적인 라이선스·약관을 가진 경우도 포함합니다.

실종아동찾기 캠페인 (findingNemo 프로젝트) 관련 서버 장애 및 오류 복구 안내

(inureyes) — Wed, 08 Oct 2008 17:37:57 +0900

실종아동 찾기 캠페인 프로젝트 및 플러그인 동작 오류에 대한 안내를 드립니다.

10월 1일부터 TNF/Needlworks 의 메인 서버인 TNF1에 오류가 생겨 이후 서버 이전 및 복구 작업을 진행하였습니다. 그 과정에서 실종 아동 찾기 플러그인 파일의 마지막 백업일이 2008년 2월이라 당시의 파일을 복원하며 임시파일인 RSS 캐시 데이터가 10월 8일 새벽 4시경부터 오전 10시 30분까지 노출되었습니다. 이로 인하여 과거의 정보가 출력되는 문제와 함께, 해당 데이터를 12시간 단위로 캐싱해서 사용하는 티스토리의 플러그인도 과거 정보를 보여주는 문제가 있었습니다.

현재는 서버 복구 작업및 과거 캐시 파일들에 대한 삭제 작업이 이루어진 상태입니다.

이번 데이터 장애는 서버 복구 과정에서 과거 파일을 사용하면서 해당 서비스와 같이 백업 되었던 임시파일이 출력된 경우이므로, 실종 아동의 데이터 보관과는 아무런 연관이 없음을 알려 드립니다. 또한 TNF/니들웍스의 서버 복구 과정에서 일어난 사고이므로, 캠페인에 관련해서 도움을 주시는 어린이 재단과는 관련이 없음도 함께 알려 드립니다.

예상치 않은 긴급 복구 작업으로 인하여 과거의 임시 저장 데이터가 출력된 부분에 대하여 관계자 분들께 죄송하다는 말씀을 드립니다. 또한 관련하여 문제를 해결하기 위해 도움을 주신 어린이 재단 및 다음 커뮤니케이션 측에 감사의 말씀을 드립니다.

PHP5와 텍스트큐브

(inureyes) — Fri, 29 Aug 2008 01:14:12 +0900

오랜만에 글을 적습니다. 핑계라면 핑계이겠습니다만, 살아가면서 가끔 여러 일들을 겪으며 정리가 필요한 시기가 니옵다. 비단 한 사람만이 아니라 사람들의 모임에도 그런 시가기 오지요. 그 시기를 어떻게 지나가는지가 참 중요하다는 생각이 듭니다.

간만의 글 치고는 고른 내용이 좀 딱딱하겠습니다. 텍스트큐브 1.8 이후부터 실행을 위해 PHP5.2 와 MySQL 4.1 이상을 기본 사양으로 요구하는데, 오늘은 그에 대한 설명이나 변화점을 이야기 하려고 합니다.

국내의 대부분의 PHP 어플리케이션들은 PHP4를 기준으로 제작되고 있습니다. 여러 이유가 있지만, 가장 큰 이유는 프로그램을 설치할 수 있는 환경을 주로 제공하는 호스팅 업체들이 PHP5 를 지원하는 경우가 적기 때문입니다. PHP4 와 PHP5 는 숫자 하나 차이가 나지만, 굉장히 다른 특성을 보이는 언어입니다. 그래서 PHP4를 기준으로 만들어진 응용 프로그램들은 PHP5에서 동작하지 않는 경우들이 간혹 있습니다.

그렇다고 PHP5 가 굉장히 새로운 언어는 아닙니다. 물론 PHP4 보다는 최근에 나왔지만, 어디까지나 상대적으로 보았을 때 입니다. 올해는 PHP5가 나온지 5년이 된 해입니다. PHP 5.3과 PHP6 이 개발 중에 있으며, 멀지 않아 사용할 수 있게 될 것입니다.

지금까지 PHP 4.3을 기준으로 제작되던 텍스트큐브가 PHP 5.2를 기본 환경으로 선택하게 된 근본적인 이유는, 더이상 PHP 4 가 개발되지 않는다는 점 때문입니다. PHP 4의 공식적인 지원은 얼마전 종료 되었습니다. PHP.net에서는 보안을 포함한 여러 문제로 사용자들이 PHP 5.2 이상으로 이주할 것을 권고하고 있습니다. 웹을 둘러싼 환경은 빠른 속도로 변하게 될 것입니다. 이러한 과정에서 니들웍스와 텍스트큐브 개발 그룹도 결정을 해야 했습니다.

텍스트큐브 1.7의 과거 환경 지원은 굉장히 폭넓습니다. PHP 4.3 과 MySQL 3.23 이상의 환경을 지원합니다. 이러한 지원은 사용자에게는 환경에 대한 고민을 하지 않아도 되는 이점이 있지만, 코드의 효율성 입장에서는 문제가 있습니다. 더 상위의 환경에서 텍스트큐브를 돌려도 속도의 이점을 볼 수 없기 떄문입니다. 예를 들면, 윈도우 비스타가 지원되는 환경에서도 도스 시절의 프로그램을 돌릴 수는 있지만 그 프로그램이 윈도우 비스타의 성능을 모두 끌어낼 수는 없는 것과 마찬가지입니다. 텍스트큐브가 하위 호환 모드로 동작할 때, 유니코드 환경 지원과 MySQL 3 데이터 베이스 지원을 위해 들어가는 서버 리소스는 텍스트큐브 전체 동작시 사용하는 리소스의 1/3 이상입니다.

개발 패러다임의 변화도 PHP 5.2를 택한 이유입니다. 텍스트큐브의 일부 컴포넌트는 객체 지향 패러다임을 기반으로 작성 되었지만, PHP 4 의 객체 지원은 굉장히 부족합니다. 또한 속도 부분에서 큰 손해가 있기 때문에 텍스트큐브 1.7까지는 일부의 객체 기반 코드 일부의 순차 처리 코드로 이루어져 있습니다. 그러나 텍스트큐브 2.0에서 사용될 TCF (텍스트큐브 코어 프레임웍 – 가칭입니다.)를 개발하는 과정에서 개발에 참여하는 분들은 현재 코드의 혼란을 최소화 하기 위해서 코드의 패러다임을 변경하기를 원했습니다.

위에서 설명 드린 것과 같이 PHP.net 에서의 PHP 4의 지원 중단, 과거 환경 지원으로 인하여 발생하는 성능 감소, 새 프레임웍을 둘러싼 개발 패러다임의 변화를 이유로 텍스트큐브 1.8 이후부터는 PHP 5.2와 MySQL 4.1 이상을 요구합니다. 새로운 프레임웍은 텍스트큐브 2.0부터 본격적으로 도입될 예정이며, 텍스트큐브 1.8은 텍스트큐브 1.x 코드를 새로운 환경의 특징을 살려 최적화하는, 다리 역할을 하는 주춧돌이 될 예정입니다. 텍스트큐브 1.8은 그 전까지 막혀 있던 병목들을 제거하여, 단위 시간당 더 많은 트래픽을 더 적은 CPU와 서버 로드를 사용해서 처리할 수 있는 가능성을 시험하게 됩니다.

간단하게 결졍된 내용은 아니었습니다. 기본 요구 환경의 변화와 관련하여 내부적으로 많은 토론이 있었습니다. 한국 호스팅 업체의 환경이 과련 이러한 요구 사항을 받아 줄 것인지부터, 새로운 환경의 어떤 특징을 살려서 코드를 써 나갈 것인지에 대한 이야기도 있었습니다.

그 논의에 참여하며 한가지 확신한 것이 있습니다. 정체는 무기력을 낳습니다. 텍스트큐브를 현재 한국 웹 호스팅의 현실에 맞게 개발하는 것도 중요합니다. 그렇지만 조금 눈을 밖으로 돌리고 조금 앞을 내다보려고 합니다. 지금이 현실에 대한 안주가 아닌 변화를 위한 적기입니다. 언젠가는 시작해야 하는 일입니다. 그래서 시작하려고 합니다.

덧) PHP 4.3 사용자 분들이 많고, 당장 쉽게 새로운 환경으로 이전하기 힘든 부분을 어떻게 지원할 것인지에 대한 논의도 있었습니다. 텍스트큐브 1.8을 개발하는 중, 성능 향상이나 기존 버전에서 구현이 불가능한 부분들을 제외한 기능이나 인터페이스 추가와 같은 부분들은 기존의 텍스트큐브 1.7 에도 계속 반영하고 발표할 예정입니다.

Needlworks.org i18n 적용!

(daybreaker) — Fri, 20 Jun 2008 08:25:33 +0900

안녕하세요. 오랜만입니다.
이번 토요일에 스웨덴을 떠나 일요일이면 드디어 기나긴(그러나 한편으론 짧디 짧은) 반년 동안의 교환학생 생활을 마치고 한국에 돌아가는 daybreaker입니다. (어디서 '날뷁~~'하고 부르는 소리가 들리지만 무시하시고-_-)

이번에 알려드릴 소식은 needlworks.org 업데이트 내용입니다. 겉보기에는 전혀(...) 별 차이가 없겠지만 내부적으로는 약간의 변화가 있었습니다. 우선 기반 프레임웍으로 사용되는 Django의 버전업에 맞추어 새로 업데이트한 후 호환성 문제들을 수정하였고, 특히 중요한 것은 이제 외국에서 needlworks.org에 접속할 경우 영문으로 소개 내용이 표시되도록 했다는 것입니다. (사실 뜬금없이 i18n 지원을 넣게 된 건 제가 그동안 외국 친구들에게 needlworks 명함을 나눠주면서 홈페이지에 들어왔을 때 영문 지원이 없으면 좀 황당해하겠다 싶어서 그랬다고 말 못합니다..-_-..) 한편 Mac 환경에서 글꼴이 좀더 예쁘게 보이도록 CSS를 일부 변경하였습니다.

이것은 Django의 i18n 프레임웍을 이용한 것으로, 제가 추가로 코드를 짠 것은 전혀 없고 단지 설정 파일과 템플릿 파일 및 python 코드 파일에 번역할 문자열을 표시해주고 번역한 데이터를 넣어준 것 뿐입니다. 역시 python을 사랑할수밖에 없군요..=3=3==3

웹브라우저 언어 설정을 영어 우선으로 놓고 들어가본 모습.

물론 번역을 급조했기 때문에 번역의 질은 장담 못합니다만 그래도 없는 것보다는 낫겠지요.;; 번역 내용은 앞으로 차차 개선할 생각이며, (이렇게 쉽게 가능할지는 모르겠지만) textcube.org도 i18n을 할 예정입니다. :D

혹시, 일본어·중국어 등 다른 언어로 needlworks.org 번역을 도와주실 분은 이곳에 비밀댓글로 메일 주소를 달아주시면 번역 분량 파일을 보내드리도록 하겠습니다.

마지막 순간

(inureyes) — Mon, 09 Jun 2008 04:23:15 +0900

이미 몇번째이지만 그 순간의 느낌은 정말 특별하다.

저 막대기를 끌어 올리기 위해서는 정말... 많은 사람들이 고생을 해야 한다

15분을 남겨두고 드는 이 감정을 삭히려 오늘 새벽에도 한바퀴 산책을 해야 할 듯 하다. 시간이 적어져 글을 쓰는 것도 확연히 줄었지만, 요새처럼 풍부하게 읽고 보고 생각하는 적도 최근에는 그리 없었다.

덧) 1.7의 버전 이름은 Risoluto이다. 항상 그 버전의 기능적 특징이나 목표를 의미한 이름이 붙어 왔지만, 이번만큼은 텍스트큐브를 통하여 제작자들이 세상에 하고 싶은 말을 담았다. 한국의 민주주의에 축복을.

예외 처리는 언제나 확실하게!

(daybreaker) — Wed, 14 May 2008 10:06:11 +0900

정말로 오랜만의 글이로군요. 간만에 재미있는, 그러나 슬픈(...) 삽질기를 하나 들려드릴까 합니다. ㅠ_ㅠ

지금 스웨덴 교환학생의 가장 마지막 관문(?)으로 Musical Communication and Music Technology라는 매우 긴 이름을 가진 과목의 기말 프로젝트를 하는 중입니다. 발표는 오늘(!)이지만 프로젝트 기간 자체가 워낙 짧았던 데다 같이 하는 애들이 지난 주에 시험이 계속 겹치는 등의 이유로 실제 진행은 거의 3일 벼락치기로 하는 중이지요;;;

과목 이름에서 유추할 수 있듯 프로젝트 내용은 상당히 '미디어 아트'적인 내용입니다. 과제로 했던 Lab에서 마지막에 했던 것이 실시간 비디오프로세싱 프로그램인 EyesWeb을 이용하여 사람의 동작을 웹캠으로 찍어 음악을 컨트롤하는 내용이었는데, 그것을 좀더 확장하기로 한 것이지요. 처음엔 막연히 뭘 더 넣을 수 있을까 고민하다가 요즘 한창 유명해진 니코니코조곡 오토마리오 버전 동영상을 보고 실제 몸의 움직임을 추적하여 실제 사람이 연기하는 마리오를 만들면 재밌겠다 싶어서 그쪽으로 방향을 잡았습니다. (그게 어젭니다-_-)

수업 때 소리를 컨트롤하는 프로그램으로 실시간 소리 합성이 가능한 오픈소스 사운드 프로그래밍 툴인 Pure Data를 이용했는데, 이게 사운드 생성은 쉬워도(?) 기존에 녹음된 사운드를 재생하는 것이 난감하더군요.; 그래서 EyesWeb에서 Open Sound Control(이하 OSC)이라는 프로토콜을 이용해 UDP로 쏴주는 메시지들을 직접 받아 소리 재생을 하는 프로그램을 짜면 어떨까 싶었습니다.

자, 서론이 길었습니다.
제가 요즘 유용하게 이곳저곳 잘 써먹는 Python을 이용하기로 했고, 크로스플랫폼 소리 재생을 위해 pygame 라이브러리를 써서 쉽게 소리 재생을 할 수 있었습니다. 또한 OSC 프로토콜을 파싱해주는 것도 이미 Python으로 구현되어 있었기 때문에 그 라이브러리를 가져다 쓰니 통신도 금방 구현할 수 있었지요. 근데 갑자기 어느 순간부터, EyesWeb에서 계속 쏴주고 있는 UDP 데이터를 못 받고 block되어버리는 겁니다.

EyesWeb 문제인가 싶어서 데이터 전송 속도를 줄여보기도 하고, 파일을 새로 만들어보기도 했고 윈도우 문제인가 싶어서 방화벽에 UDP 포트 추가도 해보고 심지어 패킷스니핑 프로그램까지 썼습니다.;; 또 OSC 라이브러리 문제인가 싶어서 멀티쓰레드로 된 구현을 싱글쓰레드로 바꿔보기도 하고 별의별 짓을 다 해봤지요. 일단 혐의(?)는 소켓 쪽에 문제가 있을 것으로 생각하고 있었습니다.

근데 여기가 스웨덴이다보니, 저보다 Python을 잘 하시는 퍼키군님과 같은 다른 사람들의 도움을 요청하자니 다들 자고 있을 시간이더군요. -_-; 혼자 힘들게 구글링하며 온갖 삽질을 다 하다가, 결국 가장 원시적인 디버깅 방법, 즉 print 찍어보기를 해봤습니다. 그리고 1분만에 좌절했습니다. (........)

원인은 세 가지였습니다.

pygame.mixer.get_busy()를 이용해 현재 재생 상태를 알아내는 부분이 있는데, is_busy()라는 잘못된 이름의 함수를 썼습니다. (이건 전적으로 제 잘못입니다..orz) 근데 이 부분이 항상 실행되는 게 아니고, 받아온 모션캡처 데이터에 따라 반랜덤하게 실행되는 곳이었죠.
OSC 라이브러리가 멀티쓰레드로 돌며 제가 지정한 핸들러 함수를 호출해주는 방식이었습니다. 따라서 그 안에서 뭔 일이 발생하여 죽더라도 프로그램은 죽지 않았습니다.
OSC 라이브러리 내부 코드에서 핸들러를 호출하는 부분을 try-except 구문이 둘러싸고 있었는데, 그 except 구문에 어떤 예외를 받을지 지정이 되어 있지 않았습니다. 즉, 모든 예외를 다 받겠다는 것이었죠.

자, 이쯤에서 무슨 일이 벌어졌을까요?

잘못된 이름의 함수를 썼으니 당연히 예외가 발생하여 프로그램이 죽어야 할 것입니다. 하지만 그 예외를 라이브러리 코드 내에서 먹어버렸고, 불행히도 그 try-except가 소켓 데이터를 읽는 while 루프 바로 바깥이라서 루프가 종료되고 결과적으로 해당 쓰레드는 아무 일 없었다는 듯 '정상 종료'를 했습니다. 하지만 메인 프로그램은 계속 돌고 있었죠. 화면에는 아무것도 나오지 않습니다. 게다가 그 잘못된 함수를 호출하는 순간은 제가 카메라 앞에서 어떤 동작을 하느냐에 따라 달라지니 에러가 랜덤하게 발생하는 것처럼 보였던 겁니다. (위에서, 싱글스레드로 바꿔보기도 했다고 썼는데, 이 경우에도 랜덤 발생으로 보였던 겁니다. 게다가 프로젝트 듀가 급하니 마음도 급했던지 차분하게 생각하지 못했던 것도 문제였죠.)

그래서......인생이란 삽질인 것입니다. OTL

여러분, 저같이 애꿎은 사람 희생시키지 마시고 예외 처리할 땐 어느 예외를 받을 것인지 항상 확실하게 지정하는 습관을 들입시다~ ㅠ_ㅠ