뼈대를 만든다는 것
ZF.js 개발기 #4
framework : 뼈대[골조]
소프트웨어 프레임워크(software framework)는 복잡한 문제를 해결하거나 서술하는 데 사용되는 기본 개념 구조이다. 간단히 뼈대, 골조(骨組), 프레임워크(framework)라고도 한다. — 위키백과
프레임워크라는 단어를 듣고 뱉은지도 꽤나 오랜 시간이 흐른 것 같다. 사실 영어단어로서는 IT 관련 실무를 접하면서부터이긴 하지만 순 한국말인 뼈대라는 말로 견주면 초등학교 3학년 시절부터이다.
나는 어릴 때부터 그림을 그리거나 무언가를 만드는 것을 좋아했다. 그중 으뜸으로 좋아했던 것은 찰흙놀이였다. 지점토 한두 개만 있으면 무엇이든 만들 수 있어서 너무 좋았다. 어느 날 만세를 하는 사람을 만들었는데 시간이 지날수록 팔이 아팠는지 점차 내려오다가 말라가는 점토는 그 힘을 못 버티고 떨어져 버렸다.. 어린 마음에 상처는 받았지만 그제야 철사를 꼬아서 만드는 뼈대의 중요성을 알게 되었다.
종종 개발자들과의 대화 속에서 프레임워크라는 단어는 심심치 않게 듣게 된다. “프런트엔드 환경에 프레임워크는 어떤 걸 사용하시나요?”, “요즘 힙한 프레임워크는 어떤 게 있어?”, “다음 프로젝트엔 어디서 만든 프레임워크를 써볼 거야” 사실 나도 주니어 시절에 저런 대화를 들으면 엄청 전문적으로 보였다. ‘개발언어 + 디자인 패턴 + 구조론 + 라이브러리 + 프레임워크’ 개발자가 되기 위해선 뭐 그렇게 알아야 하는 게 많은 건지..
내가 본격적으로 프레임워크를 사용하게 된 건 2007년쯤 대규모 프로젝트를 들어가면서 협업을 위해 선택한 PureMVC라는 프레임워크가 처음이었다. 그런데 돌이켜보면 처음이라는 의미는 업계에서 유명한 이름의 프레임워크를 쓴 것이 처음이지 프레임워크를 처음 사용한 게 아니었다. 왜냐하면 코딩 꼬꼬마 일 때부터 어떤 작업을 하는 데 있어서 필요한 기능을 수행해줄 작은 프레임워크 혹은 템플릿들을 만들어 써왔기 때문이다.
튜토리얼 페이지 모습과 소스코드위 이미지는 오늘 만우절 기념으로 베타 오픈한 ‘ZF.js 튜토리얼 페이지’의 모습과 소스코드들이다. 기술 스펙부터 나열하자면 jQuery + Bootstrap + Codeigniter + highlight.js+ ZF.js를 활용해서 작업되었다. 하지만 여기서 끝이 아니라 두 개의 프레임워크를 추가로 활용하고 있다.
추가된 첫 번째 프레임워크는 페이지 문단을 관리하기 위해서 만들었다. 위 이미지에서 오른쪽 소스코드 부분을 보면 또다시 두 개로 나뉜다. 그중 오른쪽은 최종 리소스가 되는 HTML 태그들이고 왼쪽은 PHP 코드들로 이루어진 콘텐츠 작업환경이다. 튜토리얼 페이지의 경우 H1, H2, H3, H4, P, Code 노드들을 기준으로 HTML, CSS, Bootstrap 코드들로 꾸미는 것을 반복하며 직접 작성하려면 콘텐츠보다 코드들이 많아 집중도 안된다. 그리고 복사&붙여 넣기를 반복하는 것도 귀찮았다. 그래서 HTML 템플릿을 만들고 PHP 코드로 함수형 프로그래밍하듯 연결 지어 문단(콘텐츠)을 자동으로 구성되도록 했다.
두 번째 프레임워크는 Javascript 예시 코드들을 관리하기 위해서 만들었다. (은근 자랑하자면) ZF.js 튜토리얼의 예시 코드들은 단순 텍스트들이 아니다. 각 코드들이 해당 페이지에서 실제 구동이 되면서 거기서 발생한 로그들이 예시 화면상에 출력되도록 해놨기 때문이다.
예시화면과 소스코드위 이미지는 튜토리얼 페이지 Expert.VariableDataType 예시 화면과 소스코드의 모습이다. 코드 영역들은 사실은 비어져있다가 페이지 로드가 다되면 지정된 아이디를 가진 <script> 영역을 찾아서 해당 코드를 코드 영역에 텍스트로 입력한 뒤 하이라이터 처리를 해준다. 그렇기 때문에 페이지가 가동됨과 동시에 해당 코드들도 실제로 구동되고 있는 코드들이다. 더불어 전역 함수인 console.log() 메서드 자체를 오버 라이딩하여 실제 콘솔 창에 뜨는 메시지들을 코드 예시 영역에도 순차적으로 표시되도록 처리되어있다. 데이터 타입 예시에서 아래 버튼들을 클릭하면 실제로 코드들이 실행되어 Output창에 결과가 갱신되는 것을 볼 수가 있다.
사실 이렇게 두 가지 환경을 만들면서까지 튜토리얼 페이지를 신경 써서 만든 이유는 단순 튜토리얼 페이지를 넘어서 ZF.js의 유닛 테스트 환경을 내포하게 만들고 싶기 때문이었다. 그리고 예시들이 시간이 지나 ZF.js가 업데이트되어도 실제 동작하고 있는 코드들 즉 살아있는 예시들로 확인할 수 있게 하고 싶었다. 어느 누구나 복사 붙여 넣기를 하면 튜토리얼 페이지에서 본 결과를 그대로 볼 수 있도록. (간혹 튜토리얼 사이트 혹은 책 등에서 예시 코드가 잘못되어서 학습자들에게 멘붕을 주는 경우가 더러 있다.)
이렇게 만들어진 두 가지의 기능들을 프레임워크라고 볼 수 있을까? 구글, 페이스북, 트위터에서 만들어낸 AngualarJS, ReactJS, Bootstrap에 비해선 너무나 간단한 루틴이고 심지어 멋있는 이름조차 없다. 나는 프레임워크를 확장팩이나 고급 기술이라던가 정형적인 모습보단 어떤 작업을 하는 데 있어서 중심을 잡아주는 추상적 개념을 정립해주는 주체라 생각한다.
잠시 프로그래밍을 떠나서 생각해보면 건축이나 자동차, 그리고 조형예술품들을 보면 보이는 모습 내부에는 고유의 뼈대들이 존재한다. 뼈대의 종류도 다양하다, 찰흙의 경우 쉽게 구부러지는 철사들로 하지만 고급 스포츠카의 경우 카본이나 복합재료들을 활용하는 경우를 볼 수 있다. 아무리 좋은 뼈대용 재료라고 해도 찰흙으로 소형 조형을 만들 때 카본을 사용할 수 있을까? 오히려 찰흙을 가공하는 기술보다 카본 성형 기술을 배우는데 많은 시간이 소모될 것이다.
하지만 반대로 일반적인 상식으로 활용하는 뼈대나 구조를 벗어난 구조를 구성하는 경우도 있다. 만들고자 하는 뼈대와 비슷한 모양에 나뭇가지가 보인다면 구태여 철사로 뼈대를 만들 필요 없이 작업에 집중할 수 있지만 그 모습의 변형이 쉽지는 않을 것이다 선택하는 순간 결과는 정해졌기에. 반면 BMW i3의 경우는 종례의 자동차의 기반 프레임이라는 구조를 버리고 새로운 공법으로 뼈대를 구축하기도 했다. 덕분에 기존의 방식과 다른 결과를 만들어 낼 수 있었다.
다시 소프트웨어의 프레임워크로 돌아와서 생각하면 개발자들이 접하게 되는 프레임워크라는 것들을 추상적 개념에 대한 정리를 도와주는 뼈대로 활용하느냐 내가 할 수 없는 일들을 위임하는 형식으로 활용하느냐에 따라 결과가 상이할 것이라 생각한다. 편하게 먹을 수 있는 인스턴스 음식들이 많다 해도 집에서 직접 요리해서 손님을 대접하는 마음처럼 정성을 가미한다면 그것을 준비하는 시간도 더욱 값질 것이다. 하지만 유명하다고 혹은 간편하다는 이유만으로 찰흙놀이를 위한 카본 성형법을 배우지는 않기를 바란다.
이렇듯 나는 프레임워크 또한 작업의 일환이라 생각한다. 그에 걸맞은 완성품이 있다면 사용하면 도움이 될 것이고 만약 그렇지 않으면 유사한 것을 구해서 가공을 해야 할 것이다. 그리고 간혹 맞는 것을 구하지 못할 경우 억지로 남은 것 중 선택하는 것보단 뼈대를 직접 만들어 보는 것도 나쁜 선택은 아니라고 생각한다.
다양한 언어마다 상용이나 오픈소스 등의 수많은 프레임워크들이 존재한다. 그리고 그것을 사용하는 것이 잘못되었다고 말하고 싶은 것 아니다. 도구를 도구로 사용하여야 되는데 그것을 신격화하여 맹신하고 다른 길을 차단해버리면 그길에 끝에선 다시 돌아올 수 없음을 인지하고 나에게 맡는 뼈대를 찾거나 만드는 방법도 한 번씩 생각해봤으면 좋겠다고 생각할 뿐이다.
현재 ZF.js는 차후에 추가 예정이었던 접근 제한자, 오버 로딩의 코어 기능들까지 구현을 마쳤다. 이제 남은 것은 MVC 및 SCM 패키지들을 정돈하고 테스트한 후에 프로젝트에 적용 및 오픈소스 배포를 준비하고 있다. 그것을 위해 튜토리얼 페이지 자체가 ZF.js의 데뷔 무대로 준비되고 있다. 조만간 Example 페이지를 추가하여 예제들이 완성이 되면 깃헙을 통해서 소스코드들을 공유할 예정이다.
