Younghoe.Info (final edition)

1. 참 대단한 일입니다. 국내 환경에서 오픈 소스 활용이 아닌 오픈 소스 개발은 흔한 일이 아닌데 계기나 배경을 여쭤보겠습니다.

우선, 저를 간단하게 소개하겠습니다. 직장 9년, 소프트웨어 개발회사 대표 11년, 프리랜서 10년으로 모두 전산 경력이 30년입니다. 소프트웨어 회사를 할 때에도 1~2개 프로젝트는 제가 직접 수행을 했으니 소프트웨어 개발자로서 30년을 살았군요. 주변에 손자/손녀 재롱을 보면서 살아가는 친구도 있는데, 머리 싸매가면서 자판을 두드리고 있으니 무엇 하고 있는 건지 모르겠네요. :)

개발 배경, 계기

이것, 이야기하자고 하면 말이 길어집니다만, 한마디로 말하면 자존심이 상한다는 것입니다.
세계적으로 알려진 Ajax 관련 라이브러리가 미국에서 발표되고 있는데요, 자칭 소프트웨어 강국이라고 하는 대한민국에는 없다는 것입니다. 그들이 만든 것이 좋은 소프트웨어이기는 하지만 우리가 못 만들 정도는 아니라는 것에 더욱 화가 났습니다.

어쩌면 오기심의 발동이라고도 볼 수 있습니다만, 이는 제가 개발하는 것을 좋아하기 때문에 생긴 것인지도 모르겠습니다. 자기 자신이 좋아하는 일에 매진할 수 있다는 것, 행복한 인생이 아닐까요… 그런데요, 처음 개발을 준비할 때에는 이런 마음이었습니다만, 지금은 “하지 않으면 안되기 때문에 반드시 해야 한다.”라는 생각을 하고 있습니다.

제가 아니라도 누군가가 반드시 이 일을 해야 합니다. 바다 건너에서 새로운 기술이 나왔다고 하면 이를 도입/발표하는 사람이 선구자로 대접받았던 것이 지난 30년의 모습입니다. 정제도 없이 검증도 없이 마구잡이로 도입되었습니다. 여기까지는 그래도 좋습니다. 여기에 상업적인 면이 가미되면 시간 주고 돈 주는 아주 우스꽝스런 모습이 연출됩니다. 개발자는 광대이자 마루타일 뿐 실속은 딴 사람이 챙겼다는 것입니다.

그렇다고, 이렇게 비싼 대가를 치른 소프트웨어를 제대로 사용하지도 못했습니다. 이는 원천 기술을 확보하지 못하고 껍데기로 사용법만 익혔기 때문입니다. 버전이 올라갈 때마다 돈과 시간으로 해결해야 했습니다. 이젠 이런 어리석은 모습에서 하나씩 벗어나야 합니다. 적어도 대가를 치른 소프트웨어를 제대로 사용할 수는 있어야 합니다.

어떻게 보면 제가 지금 미친 짓을 하고 있는지도 모릅니다. 시쳇말로 돈도 안 되는데 만사 제쳐놓고 이 일에 몰두하고 있으니 한심하다고 할지도 모르겠습니다. 그런데요, 세계적으로 유명한 소프트웨어는 처음엔 저 같이 미친 사람이 만들었다는 것입니다. 하기야 미치지 않고서는 세계적으로 유명한 소프트웨어가 탄생할 수도 없습니다. 개발자의 혼이 담겨 있는 소프트웨어야말로 사랑을 받을 자격이 있으며, 혼이 담겨야만 아름다운 소프트웨어가 되기 때문입니다.


2. Method Chain이라는 이름이 생소한 분들이 많을 텐데 간단히 소개를 부탁합니다.

시나리오가 중요해!

저는 시스템을 개발할 때 시나리오를 매우 중요하게 생각합니다. 요구분석 단계에서 적어도 메서드 단위까지 시나리오를 정립하지 않으면 절대로 더는 진척을 하지 않습니다. 너무 자세한 것이 아니냐, 그것이 가능하냐라는? 반문도 나올 수 있습니다만, 이를 철저하게 지킵니다. 이렇게 하지 않으면, 보나 마나 중반 이후부터 우왕좌왕하게 될 것이며 이로 말미암아 여러 사람 고생하게 되고, 저 또한 마음에 상처를 받게 될 것이기 때문입니다.

가보지도 않은 먼 길을 전부 종이 위에, 머릿속에 그린다는 것이 만만치 않습니다만 이 점을 염두에 두고 경험을 쌓아가면 그리 어려운 것도 아닙니다. 이런 것이 습관화되면 사용자의 요구 사항을 들음과 동시에 머릿속에 아키텍처가 연상되고 클래스와 코드가 그려지기도 합니다.

다른 관점에서 보면 시나리오가 없다는 것은 목적지를 향해 무작정 걸어가는 모습이 될 수도 있습니다. 그 길엔 강도 있고 산도 있을 것입니다. 이에 대한 대책도 없이 걸어간다는 것은 홀가분하게 떠나는 여행이나 가능하지 않을까요?

한편, 이런 모습을 하는 저에게 사용자는 물론이고 개발자로부터도 곱지 않은 시선을 받는 적도 있었습니다. 하지만, 분명한 것은 요구분석 단계에서 갖은 고생을 하더라도 시나리오를 확고하게 수립하면, 프로젝트가 종료될 때 고객으로부터 박수를 받는다는 것입니다.

시나리오가 있다는 것은 전체를 보고 있다는 것을 의미하며, 앞으로 발생할 것을 예측하고 있다는 것을 의미합니다. 또한, 길목을 지키고 있다는 것을 의미합니다. 이를 기준으로 열심히 걸어가기만 하면 프로젝트에 성공할 수 있다는 확신을 할 수 있습니다.

기술적인 관점에서 보면 시나리오상의 각 요소는 서로 유기적으로 연결되어 연동하고 있다는 것을 의미합니다. 이것이 MathodChain의 기본 사상입니다. 기술적으로 유명한 세계적인 소프트웨어는 사상과 철학을 가지고 있습니다. 이를 이해하지 않고 기능적으로 접근하는 개발자가 있는데요, 이는 겉모습을 보고 접근하는 것과 같습니다. 물론, 처음부터 이를 이해할 수 없겠지만, 되도록 빨리 이를 간파해야 알맹이를 사용할 수 있습니다.

사상과 철학을 갖지 않는 소프트웨어는 코드의 나열에 불과하므로 발전에 한계가 있습니다. 즉 일회성이라는 것입니다. 유명 예술가가 독창적인 작품을 지속적으로 제시할 수 있는 것은 그 나름대로 사상과 철학이 있기 때문이며, 우린 그런 사람의 작품을 높게 평가합니다.

MethodChain은 코드가 유기적으로 연동하기 위한 메커니즘을 갖고 있으며 앞으로 발전 시나리오도 갖고 있습니다. 하나의 완성된 도자기를 만들려고 수없이 많은 도자기를 부수듯이 이를 정립하려고 몇백 줄 아니 1,000 줄 이상을 부수고 다시 짠 적이 한두 번이 아닙니다.

3. 'Ajax prototype.js : 프로토타입 완전분석'이라는 prototype.js에 대한 심층 분석 서적을 출간하신 바 있는데, 그때 경험이 Method Chain을 시작하는데 어떤 영향을 미쳤나요?

한마디로 음과 양으로 지대한 영향을 미쳤다고 할 수 있습니다. 앞서 사상과 철학에 대해 언급했습니다만, prototype.js는 정통파라고 할 수 있습니다. 기술자로서 원론적으로 접근하려고 애써 고민한 흔적이 여기저기에 있습니다. 하지만, 너무 코드 측면에서 정통을 지키려다 보니 다른 것을 놓쳤다고 할까요, 그런 점이 있습니다. 자바스크립트의 장점을 살리는 것에는 충실했지만, 단점을 보완한 구조를 만들었으면 하는 아쉬움도 남습니다. 그러다 보니 확장성에 조금 어려움이 있다고 할 수 있습니다.

처음 prototype.js를 접했을 때 코드가 그리 크지 않았고 일부 코드는 쉽게 눈에 들어왔으므로 스쳐 지나갔지만, 조금 시간이 흐르고 다시 접했을 때 풍기는 냄새가 달랐다고 할까요. 하여튼 분석을 하겠다고 결심하는 데까지 몇 번씩 생각을 바꾸었지만 지금 생각하면 분석한 것을 잘했다고 생각합니다. 여담입니다만, 코드를 분석할 때 잠자리에 누었는데 코드가 천장에 그려지기도 했습니다. 이런 미친 나날을 보내면서 어느 정도 개발자의 사상과 철학을 이해하게 되었고 아울러 비판력도 생겼습니다. 그랬더니 코드 분석이 더욱 재미있어지고 조금 더 근본적으로 접근하고 싶다는 생각도 들었습니다.

위로 거론된 책이 절판되어 이런 글을 쓸 수 있습니다만, 책이라는 한계 탓에 분석하면서 메모로 남겼던 더욱 근본적인 사항들을 쓸 수 없었으며 이는 결국 2008년 5월에 출판된 ‘웹 표준 Ajax DOM 스크립팅’이라는 책을 쓰게 된 동기가 되었습니다.

이런 일련의 홍역을 치르면서 우리나라는 왜 이런 것을 만들지 못할까? 라고 생각하게 되었으며, 그로부터 한 달 정도 시간이 지나고 개발해야겠다고 결심하고 이에 대해 준비를 했습니다. 그리고 지난여름 본격적으로 개발을 시작했습니다. 그때부터 집중력을 높이려고 낮과 밤을 바꾸었고 처참하리만큼 전체 시나리오를 수립하는데 몰입을 했습니다. MethodChain은 앞으로 1년 이내에 약 25,000줄 규모가 될 것입니다. 이는 아직 개발을 하지는 않았지만 25,000줄에 대한 시나리오를 수립했다는 뜻이 되기도 합니다. 안영회님을 만났던 때가 촛불 집회가 한창이던 시기였는데, 그때는 시나리오가 어느 정도 정립되어 가는 시점이었다고 생각됩니다.


4. 요즘 한창 인기를 구가하는 jQuery에도 Chain 개념(http://ejohn.org/blog/ultra-chaining-with-jquery/ )이 등장하는데 Method Chain과 연관이 있는가? 둘을 비교해주실 수 있나요?

자신이 만든 것과 다른 사람이 만든 것을 비교한다는 것이 조심스럽습니다만, 지금으로서는 비교할 사람이 없으므로 제가 조금만 비교를 해보겠습니다. 비교를 하기 위한 전제조건은 두 가지 모두를 거의 완전하게 숙지해야 한다는 것입니다. 즉, 개발자의 사상과 철학을 이해해야 한다는 것이 되는데요, 그 정도까지는 지면 관계도 있고 하여 아키텍처 측면에서 조금만 비교를 해보겠습니다.

jQuery는 메서드를 연결해서 사용할 수 있는 Method Chain 개념을 갖고 있습니다. 이는 유연성과 편리성을 갖고 있다는 것을 내포합니다. 그런데 이런 것을 인위적으로 만들어서 제공하고 있다는 것입니다. jQuery의 유연성과 편리성은 Selector를 근간으로 하고 있습니다. 여기서 Selector를 근간으로 한다는 점에 주목할 필요가 있습니다.

세계적으로 유명한 Ajax 라이브러리의 Selector 관련 클래스를 보면 400에서 700라인 정도가 하나의 묶음입니다. 이는 하나의 조건을 select 하려고, 이 많은 코드를 실행해야 한다는 것을 의미합니다. 특히 IE는 XPath를 지원하지 않기 때문에 XPath 기능을 날로 실행해야 합니다. 즉, 내부에서 이를 위한 메서드를 만들어서 실행하는 형태입니다. MethodChain의 경우 Selector 클래스 규모가 560라인 정도 됩니다만, 아무리 간단한 조건이라고 할지라도 for 루프를 한 번으로 간주하더라도 200라인 이상을 실행해야 합니다. 조건에 따른 메서드를 만들고, 이를 실행하고, 정제하는 과정을 거쳐야 합니다. 물론, 근간의 클라이언트 환경이 좋아 이 정도의 속도가 애플리케이션 실행에 영향을 미치는 것은 아닙니다. 하지만, 이미지 몇십 개를 처리하거나 텍스트 형태의 콘텐츠를 처리하기에는 편리하지만, 대량의 데이터를 처리해야 하는 기업의 비즈니스 환경에는 다소 어려움이 있을 것으로 예상합니다. 예를 들어 10개의 칼럼을 가진 1,000건의 판매 데이터를 웹 페이지에 뿌린다고 할 때 10,000항목이 됩니다. 여기에 Select 처리를 위해 200줄을 수행해야 한다면 2,000,000이 됩니다. 또 항목마다 click 이벤트가 발생할 수 있으며 이를 위한 처리가 50줄 정도가 된다고 한다면 100,000,000줄을 실행해야 한다는 수치를 도출할 수 있습니다. 데이터를 처리하려면 이것만 필요한 것이 아닐 것입니다. 사용자 인터페이스 관련 처리, 데이터 입력에 따른 에러 체크 등 다수 기능이 항목마다 발생한다면 이는 매우 많은 실행을 요구받게 될 것입니다. 어쩌면 저의 기우인지도 모르겠으며 훌륭한 개발자이므로 이에 대처할 것으로 생각됩니다만, 다소 확장성에 어려움이 있지 않을까라는 생각은 하고 있습니다.

Method Chain은 기본적인 아키텍처가 메서드 체인을 위한 구조로 되어 있기 때문에 Selector를 사용하지 않습니다. 또 인위적으로 연결한 형태가 아니므로 확장성도 높습니다. 이는 결국 실행속도에 영향을 미치게 될 것으로 생각됩니다.

그간 4GL로 개발되었던 애플리케이션이 웹 환경으로 전환하지 못했던 이유 중의 하나가 대량의 데이터를 처리함에 어려움이 있었기 때문입니다. 지금 정확하게 자료를 제시하는 것이 좀 그렇습니다만, 그간의 테스트 결과와 Method Chain의 아키텍처를 볼 때 UI가 포함된 10,000항목을 3초 이내에 뿌릴 수 있을 것으로 생각하고 있습니다.


5. 사이트를 우리말 외에 영어와 일어로 서비스하던데 직접 작업하시나요? 도와주시는 분이 있다면 어떤 분들인가요?

일본어는 제가 번역을 하고 있고요, 영어는 두 사람이 도와주고 있습니다. 그런데 공교롭게도 한 사람이 갑자기 영장을 받아 1월 6일 늦둥이로 군에 입대했습니다. 또 한 사람은 직장이 바빠 저도 미안하게 생각할 정도입니다. 이 자리를 빌려 영작 가능하신 분, 참여를 부탁합니다.
메일 주소는 다음과 같습니다:



조선족이 한국말을 잘하더라도 때로는 어색하며, 한국 사람이 쓴 글도 사람에 따라 차이가 있습니다. 한편, Ajax 라이브러리 사이트라는 경계도 있고 소스 코드, 샘플이 있으므로 너무 정교한 번역은 필요하지 않다고 생각됩니다. 그냥 번역기로 돌려서 체크, 수정하는 정도면 될 것 같습니다. 참, 몇 개월 후에는 중국어 버전을 공개할 것 같습니다. 중국에서 대학을 다녔고 지금은 통역 대학원 졸업을 앞둔 딸의 친구가 다음 주부터 도와주겠다고 했습니다.


6. 끝으로 Method Chain 프로젝트 종국의 목적이나 앞으로의 비전에 대해 한 말씀 해주시죠.

제가 생각하는 앞으로 전체 시나리오는 5단계입니다만, 전체를 제시하기에는 어려움이 있으므로 두 단계만 제시하려고 합니다.

Framework 개발이 1단계이고 widget 버전 개발이 2단계입니다. 1단계는 현재 진행 중이며 2월에 약 1,000줄 정도를 발표할 예정입니다. 이것으로 Framework 개발을 일단 완료할 것입니다. 소소하게 기능 추가는 발생하겠지만, 클래스 규모의 개발은 당분간 없을 것입니다.

2단계인 위젯 버전은 3월에 첫 버전을 발표할 예정입니다. 위젯 버전을 발표하고 전 세계 개발자들에게 평가를 받으려고 생각하고 있습니다. 지금은 Framework 상태이고 이미 세계적으로 알려진 라이브러리들이 있어서 위젯 버전 개발에 전념하고 있습니다만, 위젯 버전이 나오면 세계적인 라이브러리들과 자웅을 겨루어 볼 만 하다고 생각하고 있습니다.

소스 라인으로 소프트웨어의 규모와 기능을 판단하는 것이 마음에 들지 않지만, 발표할 위젯 버전의 소스 라인을 기준으로 세계적으로 유명한 라이브러리와 비교한다면 3위 정도가 될 것으로 생각합니다. 웹 환경에서 실행되는 라이브러리이므로 규모가 너무 커도 문제가 될 수 있고, 규모가 크다고 좋은 소프트웨어라고도 할 수 없습니다만, 그래도 어느 정도 규모가 되어야 할 것으로 생각합니다.

비영어권이라는 점, 미국으로부터 일본, 인도를 거쳐 유럽까지 펼쳐져 있는 보이지 않는 장벽이 있습니다만, 이를 헤치고 나갈 방법을 찾아보겠습니다.

라이브러리를 선정할 때 고려 사항 중의 하나가 미래의 확장성과 발전성을 들 수 있습니다. 그런데 이를 판가름하기 어렵다는 것입니다. 또 개발자의 말만 듣고서 판단할 수도 없습니다. 이때 참조할 수 있는 것이 라이브러리가 가진 아키텍처라고 생각합니다. 즉, 얼마나 구조적으로 튼튼한가를 점검해야 하며, 이를 통해 앞으로 개발될 기능을 예측할 수 있습니다.

아무리 좋은 소프트웨어라고 할지라도 유용하게 사용하지 않으면 그 효과는 반감될 것입니다. 이는 교육을 통해 달성할 수 있다고 생각합니다. 끝으로 제가 지금 한국 말을 하고 있다는 것입니다.

후기: 한국어 맞춤법/문법 검사기 쓰기 선언에 따라 보내주신 인터뷰 내용을 맞춤법, 스팸 방지, 가독성 향상 등을 위해 일부 수정했다. 교정을 위해 읽으면서 5번 항목 답변을 읽을 즈음에는 감동했다. :)