바퀴를 재발명 해버렸다.
ZF.js 개발기 #3
바퀴를 재발명하지 말아라.
십수 년간 개발일을 해오면서 ‘바퀴를 재발명하지 말아라.’라는 이야기를 많이 접할 수 있었다. 물론 나도 동의하는 바이다. 심지어 나는 신기술에 크게 관심 없고 누군가들이 터전을 닦아놓으면 뒤늦게 쫒아가는 거북이 같은 개발자이다. 활용하고 있는 언어들마다 나의 코딩 스타일에 맞는 각각의 프레임웤을 숙지하고 활용하는 편이었다.
그런데 이상하게도 Javascript만은 마음에 드는 프레임웍을 찾을 수가 없었다. 그래서 개인적 필요로 인해 만들기 시작했던 ZF.js가 어제부로 기반 작업이 완성되었다. 지난 수개월간 몇 번의 리팩터링과 적용을 반복하면서 문제점을 수정하여 이제는 누군가에게 나 이런 프레임워크 만들었어 라고 자랑할 수 있을 것 같다!
하지만 아직 공개적으로 자랑할 수 없다. ㅠㅠ 실제 프로젝트에 도입해서 원활한 작업이 가능한지까지 검증하고 나서 오픈소스 배포를 목표하기 때문에 그저 오랜만에 일기처럼 개발기를 적는 것으로 위안 삼으려고 한다. 그래서 오늘은 그동안 구현된 내용들과 관점을 글로 정리하려 한다.
ZF.core.js# ZF.core.js
[ ZObject, ZEvent, ZEventDispatcher ]
ZF의 기반이 되는 처리를 담당하는 파일이다. $ZF 참조를 통해서 CORE를 활용하는 구조로 되어있다. Javascript와 유사한 ActionScript3.0을 기반으로 OOP 처리에 필요한 상속, 인터페이스, 오버라이드, 읽기/쓰기 전용 속성, 캡슐화, 이벤트 모델(bubble-model)등을 구현하였다. 이벤트 모델의 경우 기능은 Javascript의 이벤트 모델과 동일하지만 별개의 구조에서 작동된다. 이유는 Scope문제를 일부 우회하기 위함이다. 아래의 예시 이미지의 코드처럼 조금은 우회적인 문법이지만 기존 OOP언어와 구조는 최대한 유사하도록 고려했다. (혹은 간결하게)
ZF.js를 활용한 클래스생성 예시# ZF.mvc.js
[ ZFacade, ZProxy, ZMediator, ZCommand, ZNotify ]
MVC패턴으로 작업이 필요할 때 사용할 수 있는 확장팩이다. AS3 작업할 때 PureMVC를 주로 활용했기 때문에 거의 흡사한 구조로 구현하였다. CORE (facade, model, view, control)들과 AGENT (proxy, mediator, command)로 분기되어있으며 notification을 통한 이벤트를 처리를 한다.
# ZF.scm.js
[ ZDirector, ZStorage, ZComponent, ZMacro, ZAction ]
웹앱을 개발하면서 컴포넌트 기반의 심플한 처리방식이 필요할 때 사용할 수 있는 확장팩이다. MVC패턴과 다르게 결합성 없이 이벤트와 콜백의 중간쯤 개념으로 처리할 수 있도록 설계하였다. HTML-DOM을 관리하는 Component와 데이터를 관리하는 Storage 객체를 기준으로 다중 그룹관리가 가능한 Director객체와 Action객체를 통해 명령 처리를 한다. 이 과정을 Macro객체를 통해서 진행, 수집, 대기, 처리 등 프로세스의 루틴을 독립적으로 컨트롤할 수 있다.
이외에도 ZF.bootstrap.js / ZF.net.js / ZF.graphic.js 등 유틸리티 확장팩도 각각 만들고 있다. ZF 문법으로 OOP를 처리할 때 필요한 기능들도 앞으로 하나씩 만들어 나갈 예정이다, 왜냐하면 내가 필요하기 때문이다.
바퀴를 재발명 해버렸다.
나는 이쯤 돼서 한번 생각해본다. 진짜 바퀴를 재발명하는 일이 잘못된 일일까? 내가 시대의 흐름(Angular, React, Node)을 쫒아가지 못하면서 안위적 사고를 하고 있는 건 아닌가?라는 질의를 스스로에게 던지면서 말이다.
현재의 웹 시장에서 힙한 바퀴들이 나에겐 맞지 않는다. 함수형, NoSQL 등 그것이 진리인양 다들 말하고 있지만 그렇다고 C, JAVA 등 기존 OOP와 SQL들이 없어질 것도 아니라고 생각한다.(PHP가 아직까지 건재하듯) 사실 어느 쪽이 먼저 없어질 가능성이 높은 지를 굳이 점수를 매기자면 변태적으로 발전되면서 변형되고 있는 Javascript시장이 아닐까 싶다.(나는 JS프레임웤들을 프레임웤이 아닌 별도의 언어로 보고 있다.)
사실 나는 길다면 길고 짧다면 짧은 개발 경력을 가지고 있지만, 현재 자바스크립트의 발전 경향과 비슷한 상황을 경험한 적이 있다. 내가 아직까지 사랑하고 있는 ActionScript의 태동과 발전의 모습이 그러했다. 선대의 지혜인 양 떠들 생각은 없지만 적어도 나는 그 길을 쫒아가다가 어떤 엄한 꼴을 볼지 직감적으로 느낀듯하다.
Firebase을 찬양하면서 원리 기술에 대해서 전혀 알 생각도 안 하고 있는 개발자들을 더러 만날 수 있다. 그들은 마치 3D 프린트를 통해서 제품을 만들면서 수공예로 조각해서 작품을 만드는 사람들을 괄시하는 느낌 같다. 그들은 무엇이든 만들 수 있는 사람일 수 있지만 장비가 없으면 무엇도 만들 수 없는 사람이기도 하다. 그저 신기술이 적용된 장비를 다룰 수 있을 뿐이다.
그렇기 때문에 나는 현재 자바스크립트 프레임웤들에 관심이 없다. 그저 언어의 장벽 없이 내 스타일대로 개발을 하고 싶을 뿐. 그리고 언제 없어질지 모르는 환경에서 작업하다가 또다시 벼랑 끝에 몰리고 싶지 않다. (한번 당해봤다;;) 그렇기 때문에 내가 필요한 것을 만들어서 쓰는 게 나의 발전과 안녕을 위한 길이라고 생각이 들었다. 그리고 다음에 만날 환경(웹 어셈블리)이 단단해지기 전까지만 버틸 수 있으면 충분하다.
변종 사이즈의 휠이 아무리 유행한다 해도 결국 타이어 제조업체에서 생산을 중단하면 선택의 폭이 없어진다. 바퀴를 만들 줄 알면서 바퀴를 재창조하지 않는 것과, 만들 줄 모르면서 말만 그렇게 전하는 것은 다르다. 결국 그들이 사용하고 있는 환경 자체가 새로운 바퀴를 만들려고 시도 한 사람들의 결과이듯이.
그래서 나는 무모한 과정에 도전을 즐기고 있다.
깃헙은 앞으로 를 위해서 만들었고요. 샘플로 minify 버전만 올려놨습니다만 아직 설명이나 이런 것들은 없어요;; 조만간 정리되면 정식으로 설명과 함께 커밋할 예정이에요. ^^
