TNF Needlworks

도움닫기

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

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

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

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

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

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

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

(0) (0)

필자

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

미래, 삶, 생각, 코딩, 텍스트큐브

(0)(3)

컴퓨터 길들이기

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

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

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

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

* * *

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

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

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

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

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

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

* * *

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

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

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

* * *

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

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

(0) (0)

필자

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

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

건의, 구조화, 사용자, 서식, 질문, 추상화, 컴퓨터, 포럼

(0)(3)

새해인사 올려요

필자

LonnieNa 입니다. Needlworks에서 Painter에 있습니다.
http://blog.2pink.net
Painter로,
여러분과 나의 세상을 바라보는 시선을 달리합니다.

2009년, 눈떠보니, 벌써

(0)(2)