구조화된 프론트엔드 개발로 빠른 결과를 얻는 법
들어가며
지난 몇 년 동안 서버 사이드 개발자는 모듈 방식과 코드 재사용 같은 고급 기술을 활용하고 있었지만, 프론트엔드 개발자는 체계 없는 스크립팅, 아무렇게나 뒤섞인 플러그인과 라이브러리에 의존해 작업을 해왔다. 본 보고서에서는 센차 기술을 이용한 컴포넌트 기반의 개발을 통해, 서버 측 개발의 생산성과 체계성을 프론트엔드와 모바일 개발에 적용하는 방법을 소개하고자 한다.
최근 다수의 자바스크립트 “마이크로 프레임워크”의 수가 급증하며 웹에 풍부한 콘텐츠와 미디어를 빠르게 전송하려는 수요에 단순성을 추가하려 하고 있다. 하지만 마이크로 프레임워크 스택(예: 제이쿼리 JQuery, 프로토타입 Prototype, 앵귤러JS AngularJS, 백본 Backbone 등)의 디자인 패턴과 일반적인 유틸리티가 정말로 대기업의 웹 개발 생산 가치를 높였을까?
과거를 돌이켜 보면 성공 사례가 여럿 있다고 할 수 있다. 특히 UX 디자인/개발 팀의 규모가 작고 체계가 잘 잡혀 있을 경우에는 더욱 그렇다. 하지만 CRM, ERP, 데이터 마이닝/분석 등 임무 수행에 필수적인 사업 애플리케이션에 대규모로 배포해야 하는 기업이 질서가 없는 기술 스택에서 쓸 만한 가치를 골라 전달하기는 여간 까다로운 일이 아니었다. 기업은 디자인, 구현, 장기 유지의 규모만으로 예전의 소비자 대면 방식을 훨씬 뛰어 넘어 전형적으로 규정된 방식을 채택해야 했다.
도큐먼트 모델
1990년대와 2000년대 초반 신클라이언트 HTML 패러다임이 진화했을 때 그것은 이미 가치 있는 자산인 콘텐츠(종류 불문)에 HTML 뷰를 “생성”만 함으로써 기존의 백엔드 인프라를 증가시키는 단순한 요소로 보였다. 실제로 테이블이 생성되었고, 전송된 차트 이미지가 스크롤링으로 뷰에 나타났으며, 폼이 선택 가능한 입력 수단의 핵심이 되었다.
그러나 이제 전체 서비스 스택은 새로운 전략 패러다임을 지원하려면 웹의 “무상태성”과 기업의 상호교환성 사이에서 가교 역할을 해야 했다. 과거의 멀티페이지 뷰를 지원하기 위해 자동화된 프레젠테이션의 새 레이어가 꽃을 피웠다. PHP, 콜드퓨전ColdFusion, JSP, JSF, .NET, 스프링Spring 등 서버 측 “스크립팅이 가능한 기능script-ables”은 모두 빠른 속도로 발달하며 변화를 뒷받침했다.
고전적인 도큐먼트 기반의 전송 모델은 (비록 인공호흡이 필요했지만) 여전히 건재하다. 가치 있다고 여겨지는 자산(예: 콘텐츠, 미디어, 데이터)은 오로지 ‘렌더링’ 작업만 하는 수천 가지의 초창기 서버 팜에서 마크업 스트림으로 간단히 전송되었다. 그 결과로 “템플레이팅된” 페이지 출력이 생기며 생산성을 많이 끌어올렸다. 하지만 고객에게 진정한 상호적인 경험을 제공하기에는 아직 역부족이었다.
설상가상으로 1990년대와 2000년대 초반에는 브라우저 전쟁이 치열하게 벌어지고 있었다. IE6이출시된 2001년까지 마이크로소프트 인터넷 익스플로러는 소비자 브라우저 시장의 80% 이상을 차지했다. 하지만 이후 애플 사파리(2003), 모질라 파이어폭스(2004), 구글 크롬(2008) 등이 속속 등장하며 웹 개발 분야를 바꾸어놓았다.
인터넷 브라우저가 제각각인 데다 HTML, 자바스크립트, CSS 구현에 일관성이 없으니, 원하는 상호적인 경험은 고사하고 템플릿 페이지 콘텐츠를 전달하기도 더 어려워졌다.
2005-2006년 무렵부터 자바스크립트 라이브러리(예: 프로토타입, 제이쿼리)는 웹 개발의 크로스 브라우저 시맨틱을 단순화하기 시작했다. 이런 자바스크립트 라이브러리가 떠오르며 과거의 고전적인 데스크톱과 달리 시각화, 폼 조작, 에이잭스AJAX를 통해 동적으로 로딩한 콘텐츠, 유저 이벤트 인터랙션을 추가하기 쉽게 되었다.
개발자들은 새로운 기능들을 열렬히 환영했다. 갑자기 폼 기반의 애플리케이션에 단순한 “제출Submit” 버튼 그 이상의 권한이 생기자, 진정 상호적인 웹 경험으로 가는 길에 더 이상 장애물은 존재하지 않았다. 유틸리티 라이브러리가 경쟁적인 브라우저 시장을 평준화하면서 고급 내비게이션, 인터랙티브 미디어, 그 밖의 시각적 효과가 진화했다. 여러 브라우저에 기준과 기능이 생겨나고 있었지만 개발 생산성은 하루가 다르게 치솟았다.
인재 풀
“인간의 가장 위대한 자산은 인간의 정신 그 자체이다”라는 말이 있다. 우리의 일생생활을 둘러싼 비즈니스/소셜 업계에도 영락없이 통하는 말이다. 아주 상호적인 동물로서 인간은 비즈니스 도구도 상호적이기를 기대한다. “이걸 요약하고 저걸 검색해서 의미 있는 세상을 보여다오!” 안 될 것 없지 않은가? 좋든 나쁘든 그것은 우리 생활에 꼭 필요한 요소가 되었다.
자바스크립트 유틸리티 라이브러리와 초기 프레임워크가 처음 도입되며(이후 진화하며) 웹의 노동 인구도 그에 발을 맞추었다. 새롭고 흥미진진하며 광범위한 사용자 표시 매체가 등장했고 여기저기서 차용되었다.
2000년대 초반, 많은 기업은 몇 가지 브라우저만 지원하는 웹사이트를 구축했다. 하지만 사실 그배경에는 두 가지 원인이 있었다.
당시에는 브라우저의 기능이 한정되어 있었다.
경쟁 브라우저와의 미묘한 차이를 완벽하게 이해하는 개발자가 몇 명 없었다.
그럼에도 인터넷 인구가 급증하고 자바스크립트 라이브러리 통합이 쉬워지면서 웹 개발 노동 인구는 빠른 속도로 증가해 향후 십 수 년 간 시장을 지배했다. 하지만 오늘날 개발/지원 관리자가 아직도 어쩔 수 없이 치러야 할 대가가 있다. 바로 특정 프레임워크에 대한 선호도이다.
대개 그런 도구를 사용하며 처음에는 프로토타입과 제이쿼리에 대한 선호도가 생긴다. 실제로 프로토타입과 제이쿼리는 오늘날 간소화된 DOM, 이벤트, 레이아웃 관리는 물론 1세대 데이터 바인팅 컴포넌트와 템블릿 엔진에 대한 기준을 설정했다. 대체로 이런 라이브러리들은 지속적으로 진화하는 브라우저 렌더링 엔진들에서 미묘한 차이를 끌어냈다.
그러나 2007-2008년에 들어서며 다른 라이브러리와 프레임워크도 등장했다. 특히 기업에서는 상호적인 “웹 애플리케이션”이라는 개념을 받아들이기 시작하면서 웹 개발에 DOM을 기반으로 접근하는 방법을 대체하는 YUI, Dojo, Ext JS가 개발되었다. 이와 같이 더 거대하고 종합적인 프레임워크는 통합된 위젯과 유틸리티를 자랑하기 때문에 크로스 브라우저 애플리케이션의 신속한 개발이 가능해졌다.
2000년대 중반에서 후반에 이르자, 개발자들은 기술 방향을 크게 두 가지로 고려해야 했다.
고전적인 마크업 장식(템플레이팅), 저레벨 CSS, 에이잭스 기본형
백엔드 서비스 환경에서 발견되는 진정한 객체 기반(OOP/MVC) 패턴을 따르고 이상적으로 단순한 방법을 이용해 규모가 큰 애플리케이션의 스타일링하기
편리하다는 인식으로 첫 번째를 선택하는 개발자는 사업 목표를 달성하기 위해 자신이 가장 익숙하다고 생각하는 하나 이상의 라이브러리를 선택한다. 시간이 지나며 선호가 결정되고 안정적인 환경이 자리를 잡는다. 논쟁의 소지가 많을 때는 개인적인 선택이 면접 주제와 기획 회의의 핵심이 되는 경우가 많았다.
하지만 기능이 풍부한 컴포넌트는 직접 제작해야 했고, 12개 이상의 브라우저 유형에서 “슈퍼 데이터 테이블”이 작동하게 만들려면 상당한 기술을 요했다. 개발자의 높은 이직률에 더해 “과거의 코드” 유지는 큰 문제가 되었고, 일관성 있는 애플리케이션 구조가 없어 엉망인 “스파게티 코드”가 결과로 나왔다.
두 번째를 선택하는 개발자는 프로토타입과 제이쿼리 같은 작은 유틸리티 라이브러리를 넘어 더 거대하고 종합적인 프레임워크(예: YUI, Ext JS)를 찾는다. 이 집단에서도 각기 선호하는 프레임워크 가 있지만 웹 애플리케이션 개발에 객체를 기반으로 접근하는 한편 선호하는 프레임워크 구조를 택하자 코드가 깔끔해지고 유지 문제도 줄어들었다. 기능이 풍부한 컴포넌트는 프레임워크에 존재하는 위젯에서 쉽게 확장할 수 있었다. 대부분의 프레임워크가 특정한 패러다임을 따르기 때문에 개발자 이직률과 “과거의 코드”는 문제가 되지 않았다.
서비스 지향 아키텍처(SOA)의 등장
주류 에이잭스 라이브러리와 도구가 등장하며 단지 미디어 콘텐츠와 데이터셋을 전송하는 비용을 줄이기 위해 서버 아키텍처가 채택되었다. 예전의 풀 페이지 생성 프로세스는 매개 중심의 서비스 아키텍처로 대체되었다. 2010년 여러 기업의 개발팀은 백엔드 아키텍처로 방법을 바꾸고 MVC(그 밖에 등장한 변형들 포함)와 웹 서비스 API(REST, SOAP 등)를 결합했다.
클라이언트 측에 MVC 디자인 패턴을 도입하자 새로운 방법으로 체계적인 개발을 하며 다수의 소비자를 지원할 수 있었다. 또한 더 방대한 시스템에 단위 시험과 검수 시험을 더 많이 할 수 있게 되었다. 브라우저의 경우, 모델과 뷰의 개념으로 명백하게 관심사가 분리되었고, 재사용 가능한 컴포넌트와 모델 저장 구조를 다수의 사업 계획에 동시다발적으로 활용했다. 이런 수요에 기존의 자바스크립트 라이브러리와 프레임워크는 다양한 방식으로 반응했다. 2012년 즈음 새로운 라이브러리, 애드온, 지원 플러그인이 다수 탄생하며 다른 라이브러리 저작자가 만든 기존 인기 스택의 범위를 넓혔다.
돌이켜 보면 최근의 이런 변화를 몇 가지로 정리할 수 있겠다.
“세분화된 모듈 라이브러리”로 접근하는 방법은 더욱더 “세분화”되었다. 언제부터인가 이처럼 추가적인 상위 라이브러리의 종속성을 관리하는 작업은 또 다른 “모듈”(예: RequireJS)이 맡아서 처리했다.
광범위하게 분포된 공용 서버 또는 방대한 내부 코드 저장소에서 수많은 종속성을 모으려 하기 때문에 초기 페이지/애플리케이션 로딩 시간이 2배(때로는 3배)로 늘었다.
개발 중에는 “생산성 관점”에 마음이 끌릴지 모르지만, 이제 “구축 프로세스”는 애플리케이션 자체의 일부가 되어서 사용자는 느린 애플리케이션을 시작하는 것이 참기 힘들다고 생각한다.
대개 8개 이상의 종속 라이브러리에 대해 장황하게 출시 영향 분석을 해야 하니 지속적인 유지 시간이 길어졌다. 새로운 브라우저가 출시만 되어도 각각의 종속 라이브러리가 전체 유저 베이스에 대한 영향을 평가하면서 1년에 적어도 2회는 종속성 영향 주기가 완전하게 나타난다. 그 결과, 제품 출시 일정은 한두 가지가 아니라 여러 요소의 영향을 받는다.
유틸리티 라이브러리는 사전에 구성품을 많이 포함하지 않은 채로 전송된다. 고급 데이터 시각화와 폼 유효성 검사 컴포넌트는 처음부터 자체 개발하거나(그 과정에서 광범위한 브라우저 호환성을 유지해야 한다) 커뮤니티에서 또 다른 종속성을 통해 가져와야 한다. 이 경우 동적으로 로딩할 때와 동일한 품질을 보장하지 않는다.
신참 개발자는 오픈 라이브러리에서 다양한 MVC, MVVM 관련 패턴 때문에 원치 않는 좌절감을 느낄 수 있다. 모든 프로젝트 담당자가 저마다 선호하는 프레임워크가 있으므로 의견 일치를 보기 힘들어 “최고”의 패턴/제품을 선택하기 어려워졌다.
다수의 부수적인 라이브러리에서 도큐멘테이션, 중요한 튜토리얼, 지속적인 지원은 아예 존재하지 않거나 최소한으로만 존재했다. 솔루션을 처음으로 사용하는 이는 사용 가능한 지원 도구가 부족해 저작자의 구현 방식을 적절히 이해하지 못할 수 있다.
다양한 자바스크립트 라이브러리가 완전한 스택을 갖추며 내부적으로 새로운 개발자 교육을 하기 힘들어졌다. 복잡한 관계와 연쇄적인 종속성은 거의 문서로 남기지 않기 때문이다.
SOA는 분명 굉장한 혁신을 가져왔지만 그 결과로 클라이언트 측에 발생한 단편화는 기업 애플리케이션에 그리 적합하지 않았다. 간단히 말해, 모듈형 라이브러리 스택에 초세분화된 방식으로 접근하자 시스템 통합, 구축 프로세스, 출시 주기, 번거로운 유지 작업에 많은 문제가 생겼다는 뜻이다. 반면, 더 종합적인 자바스크립트 프레임워크 접근법을 선택한 프론트엔드 개발자들은 기업의 요구에 맞춰 더 일관성 있고 신뢰할 수 있는 패턴에 정착했다.
완전한 기능의 프레임워크 대 모듈형 라이브러리 스택
2005년 주류 자바스크립트 유틸리티 라이브러리가 등장한 직후, 자바스크립트 “프레임워크”라는대체 구현 방식이 도입되었다. 개발 시작 단계에서 Ext JS 같은 제품은 웹 기반의 애플리케이션 개발의 기술을 더욱 단순화했다. 컴포넌트 전체를 확장할 수 있고, 갈수록 진화하는 서비스 아키텍처에서 제공하는 거대한 데이터셋을 관리하는 공식 전략이 존재하기 때문에 가능했다.
이 아키텍처를 근본으로 삼아, 현재에는 자바스크립트 프레임워크 사이에서도 공식적으로 MVC 디자인 패턴을 광범위하게 사용하고 있다. 2010년 클라이언트 측 전송 지원을 하는 최초의 자바스크립트 프레임워크 센차 터치가 나왔고, 그 직후인 2011년 Ext JS가 뒤를 따랐다.
이렇게 등장한 제품들은 근본적으로 강력한 추출 기능을 제공해 복잡한 크로스 브라우저 HTML 시맨틱, 복잡하고 동적인 DOM 구조, 아주 단순화된 이벤트 관리에서 개발자들을 자유롭게 했다. 종래의 템플레이팅을 사용하면(서버에서 생성한 마크업을 통해) 몇 주나 걸리던 작업이 단순한 객체와 가벼운 스크립팅으로 며칠 만에 완성 되었다. 지나치게 많은 페이지 생성 서버를 단계적으로 중단하고 고성능 SOA로 전환하자 자본 지출이 낮아지고 유지 비용이 절감되었으며 사업 운영도 단순해졌다.
논리(모델 그리고/또는 컨트롤러)와 표시(뷰)를 확실하게 분리하자 애플리케이션 개발 자체를 재구성하는 새로운 방법들이 탄생했다. 사용자 인터페이스 디자인과 스타일링을 가장 잘 처리하는 인력은 서비스/통합 개발과 비교적 독립적으로 작업을 완수할 수 있었다. 백엔드 서비스 개발을 하며 성장한 개발자(예: HTML이나 CSS 스킬이 없다)는 모델/스토어/서비스 통합에 초점을 맞출 수 있다. 한편 프론트엔드 개발자는 뷰와 보기 좋은 프레젠테이션에 집중하면 된다.
2007년 처음 출시된 Ext JS는 이후 라이벌로 등장한 라이브러리와 프레임워크 대부분을 꺾고 지금까지 명맥을 이어오고 있다. 최근 Ext JS 5 출시로 증명되었듯, 종합적인 컴포넌트, 차트, 데이터 관리 요소, 비주얼 디자인 도구, 강력한 구축 자동화 툴킷을 집대성한 것은 센차뿐이다.
HTML 템플레이팅 엔진
MVC와 MVVM 아키텍처 패턴을 모두 지원
URL 라우트
모델과 데이터 통합 레이어(완벽한 트랜잭션 코디네이션과 RPC 바인딩으로)
곧바로 사용 가능한 차트와 컴포넌트가 100여 개
완전한 확장성을 갖춘 종합적인 클래스 시스템
쉽게 환경을 설정할 수 있는 객체로 개발 프로세스 단축
크로스 브라우저와 멀티 디바이스 지원
다수의 (확장 가능한) 테마
종속성 관리 자동화
통합적인 구축/배포 도구
완전한 API 도큐멘테이션, 튜토리얼, 온라인/인라인 샘플
전 세계적인 교육과 지원
전문 서비스
확립된 공개 포럼과 커뮤니티(전 세계 개발자들 200만 명 이상 포진)
결론
현실을 직시하자. 초창기 자바스크립트 라이브러리가 없었더라면 오늘날 우리가 아는 웹은 전혀 다른 위치에 있었을지도 모른다. 초기 자바스크립트 라이브러리는 여러 면에서 효율적이고 능률적인 작업을 만들었고, 진화하는 웹 표준에 영향을 미쳤고, 미래에 대한 상상력을 자극했으며, 현재의 경험을 몹시 향상시켰다.
“마이크로 프레임워크”라는 세분화된 기능 스택과 완전한 기능을 갖춘 프레임워크를 모두 견딘 사람은 각각의 방법에 장점이 있다고 인정할 것이다. 전문가들은 “프레임워크”가 개발자의 자유와 아키텍처 표현을 너무 엄격하게 옥죄었다고 주장할 수 있다. 단순한 콘텐츠와 미디어 전송 프로젝트라면 그 주장이 어느 정도 일리가 있다. 하지만 기업형 애플리케이션 개발은 다양한 요구를 수용해야 한다. 그 점을 감안하면 일관성 있는 애플리케이션 아키텍처, 생산성 표준, 명백하게 정의된 모범 사례를 제공하는 Ext JS 5 같은 종합적인 프레임워크는 상당한 가치가 있다고 할 수 있다.
전체적인 규모의 기업용 웹 개발을 할 때, 센차 Ext JS 프레임워크는 자주 사용되는 “마이크로 프레임워크”와 비교해 여러 가지 핵심적인 장점이 있다. 견고하면서 확장성 있는 UI 위젯, 유연하고 확장/축소가 용이한 애플리케이션 아키텍처, 객체 지향적 클래스 시스템은 개발 시간을 절약해준다. 그리고 유지 비용을 현저히 낮추고 제품의 품질도 향상시킨다. 제멋대로인 기술 스택과 단기적인 인력 풀로 겪는 문제를 줄여줌으로써, Ext JS를 사용하는 기업은 기하급수적인 속도로 엔드 유저에 놀라운 애플리케이션을 전달할 수 있다.
종합적인 프레임워크를 사용하는 장점과 센차 기술을 이용한 컴포넌트 기반의 개발 등에 대해 더 자세히 알고 싶다면 "모던 웹 스택 심층 분석" 을 참고하기 바란다.
[역자주 : 본 문서는 아래 문서를 한글화한 것입니다.]
Achieving Faster Results with Structured Front-End Dev
http://pages.sencha.com/Achieving-Faster-Results-with-Structured-Front-End-Development.html
