퓨어 자바스크립트부터 프레임워크까지 우리의 선택은?

[컴퓨터월드]

▲ 김대원 투비소프트 프리세일즈팀 책임

▲ Vanilla JS 홈페이지
‘바닐라JS(Vanilla JS)’에 대해 들어본 적 있는가? 가볍고 빠른데다 높은 호환성을 주장한다기에 당장 검색을 해봤다. “Vanilla JS is fast, lightweight, cross-platform framework for building incredible, powerful JavaScript application”이라는 문구가 있는 홈페이지를 쉽게 찾을 수 있었다. 친절하게 기능별로 선택해서 다운로드 받을 수 있는 링크도 제공하고 있었다.

호기심에 몇 개를 선택하고 다운로드 받아보고는 놀라움을 금치 못했다. 파일 사이즈가 0KB였다. 링크가 잘못되거나 파일이 잘못 받아진 게 아니다. 바닐라JS를 사용하기 위해서는 별도의 파일이 필요 없기 때문이란다. 바닐라JS는 ‘Pure Javascript’, 즉 별도의 라이브러리나 프레임워크를 배제하고 순수 자바스크립트를 사용하는 것이 더 가볍고 빠르며 호환성 또한 좋다는 이야기를 하고 있는 것이다.


그들은 왜 Vanilla JS를 주장하는가?

최근 자바스크립트 시장 변화를 보면 이러한 주장이 나올만하다는 생각이 든다. 기술이 범람하고 있다는 이야기를 할 만큼 다양한 라이브러리와 프레임워크들이 생겨나고 변화하다 사라지고 있다. 어떤 것을 사용하는 것이 가장 좋은 선택인지 구분해내기조차 힘들 정도로 말이다. 거기다 파편화 문제, 호환성 등 메이저 프레임워크에서조차 발생하고 있는 문제점들을 보면 혼란스러운 것이 사실이다. 정리해보자면 다음과 같다.

1. 학습의 어려움

HotFrameworks.com는 깃허브(Github) 점수, 스택오버플로우(Stack Overflow) 질문 개수를 토대로 프레임워크 순위를 보여주는 사이트로, 170여 가지가 랭크돼있는 것을 볼 수 있다. 게다가 우리는 웹 기반 프로젝트를 진행하기 위해 단순히 라이브러리와 프레임워크 외에도 다양한 도구들을 함께 사용한다.

출처: 웹Frameworks

이들을 프로젝트 상황에 따라 적절하게 조합해 활용하며 그에 따른 학습도 충분히 이뤄져야 한다. 하지만 각기 서로 다른 방식의 스크립트를 사용하고 있고 학습난이도 또한 천차만별이다. 가장 많이 사용되는 프레임워크 중 하나인 앵귤러(Angular)의 경우 앵귤러JS(1.x)에서 앵귤러(2.x)로 버전업되면서 타입스크립트(TypeScript) 기반을 채택해 그에 따른 학습이 필요하게 됐다. 최소한의 개발기간으로 진행되는 것이 일반적인 우리 상황에서 별도의 학습기간을 확보하기란 쉽지 않다. 따라서 높은 수준의 개발품질을 기대하기도 힘들다.

2. 파편화 문제

웹 기반 프로젝트를 진행하면서 가장 힘든 작업 중 하나는 바로 브라우저별 파편화 처리다. 최적의 웹 환경을 제공하기 위해 예외처리나 우회처리는 필수이며, 브라우저별 또는 브라우저 버전별 테스트가 수반돼야 한다. 이러한 문제를 좀 더 쉽게 해결하거나 신경 쓰지 않기 위한 목적으로 라이브러리나 프레임워크를 선택하기도 한다. 하지만 최근 이러한 파편화 문제를 이들이 오히려 가중시키고 있는 것이 아닌가 싶다.

출처: BuiltWith.com

한 예로 J쿼리(jQuery)는 탑 밀리언 사이트에서 약 80% 이상 사용되고 있는 라이브러리다. 다양한 커뮤니티와 예제 및 활용방법이 공유되고 있고, J쿼리 기반으로 구현된 컴포넌트들도 쉽게 찾아볼 수 있다. 그러나 안타깝게도 모두 파편화 문제를 내포하고 있다. 오픈소스 커뮤니티의 특성상 해당 자료에 대한 검증은 사용자 몫이며, 발생하는 문제에 대해 빠른 피드백을 기대하기도 어렵다. 긴박하게 운영되는 프로젝트 진행 중 이러한 문제가 발생할 경우 수정을 요구할 수도, 자체 해결할 수도 없는 진퇴양난에 빠질 수 있다. 이 문제는 생각보다 자주 발생해 실무자들의 큰 고민거리가 되고 있다.

3. 호환성 문제

각각의 라이브러리나 프레임워크 버전에 따른 호환성 문제도 이슈다. 앵귤러의 경우 1.x에서 2.x로 버전업하면서 성능이슈가 발생했고, 양방향 바인딩 기능을 제한했으며, 앞에서도 잠시 이야기했던 것처럼 타입스크립트를 채택하며 하위버전에 대한 호환성을 제공하지 않았다. 결국 앵귤러JS(1.x)에서 앵귤러(2.x)로 버전업하기 위해서는 새로 개발해야 하는 이슈가 발생한 것이다. 빠른 주기로 버전업되고 있는 상황 또한 불안요소가 아닐 수 없다. 물론 앵귤러JS(1.x)에서 앵귤러(2.x)로 버전업 때처럼 패러다임의 변화는 없지만, 같은 상황이 발생하지 않는다는 보장은 없다.

J쿼리의 경우 호환성 문제에 대응하기 위해 J쿼리 마이그레이션 플러그인(jQuery Migration Plugin)을 제공하고 있으나 임시방편이라는 느낌이다. 제공되는 마이그레이션 플러그인은 1.9이하 버전 사용자를 1.9~3.0 버전을 사용할 수 있도록 해주는 버전과, 1.9이상 버전 사용자를 3.0이상 버전을 사용할 수 있도록 해주는 버전으로 구성돼있으며, 상황에 따라 함께 사용하도록 돼있다. 1.9이하 버전 사용자가 3.0이상 버전을 사용하기 위해서는 2개의 플러그인을 모두 사용하는 방식이다. 파일사이즈가 성능을 좌우할 수 있는 웹 환경에서 결코 합리적이지 않다.

4. 기술지원 및 유지보수

기술지원과 유지보수는 오픈소스 프로젝트 형태의 라이브러리나 프레임워크의 숙명적인 문제점이라고 볼 수 있다. 작업자의 업데이트만을 기다릴 수밖에 없는 구조이기 때문이다. 물론 프로젝트에 참여하거나 자제적인 디버깅 및 수정이 가능하겠지만, 높은 난이도의 스크립트 작업과 파편화에 대한 문제를 벗어날 수는 없다. 앵귤러JS나 리액트(React) 같은 기업형 오픈소스의 경우 지속적인 관리 및 개선을 진행하지만, 우리나라 기업용 시스템에서 요구하는 수준의 기술지원과 유지보수를 바라기는 힘든 상황이다.


해답은 Vanilla JS?

그렇다면 정말 바닐라JS가 해답인 걸까? 쉽게 그렇다고 답변할 수는 없다. 우리는 바닐라JS로 프로젝트를 진행하던 시절이 있었고 문제점 또한 경험을 해봤다. 그리고 그에 대한 돌파구를 라이브러리나 프레임워크에서 찾고자 했다.

새로운 길에서 벽을 만났다고 원점으로 회귀하는 것이 현명한 선택은 아니다. 현재 상황에서는 프로젝트의 성격에 맞는 최선의 선택과 위험을 최소화할 수 있는 합리적인 판단이 필요하다고 생각된다. 그에 대한 내용을 정리해본다.

Vanilla JS 이용한 개발에 적합한 프로젝트

▲ Vanilla JS 이용한 개발 시 장단점

바닐라JS로 개발 시 장단점을 기반으로 효과적인 프로젝트를 생각해보면 다음과 같은 형태로 나눠질 수 있다.

첫째, 단순한 콘텐츠로 구성된 시스템이다. 기업용 업무시스템의 화면처럼 높은 수준의 기능요구사항이 많은 시스템을 구현할 경우 작업의 난이도, 개발 생산성, 유지보수에 문제를 야기할 수 있다.

둘째, 수정보다는 일정기간 후 리뉴얼 진행이 이뤄지는 경우다. 정적인 콘텐츠 구성하기에는 용이할 수 있으나, 화면의 변화가 많거나 수정사항이 빈번히 발생하는 경우 화면을 새로 구현하는 것보다 많은 작업량이 필요할 수 있다. 예를 들어 HTML DOM 구조의 변경이 발생했을 경우 HTML 구조에서부터 구현된 스크립트까지 전반적인 수정이 필요할 수 있으며, 연관된 기능에 대한 분석 및 검증 작업이 진행돼야 한다.

셋째, 소규모 또는 단독으로 프로젝트를 진행하는 시스템이다. 적은 인원으로 구성해 프로젝트를 진행할 경우 개발품질 유지가 가능하지만, 작업인원이 많아질수록 개발품질 유지 및 유지보수에 많은 노력이 필요할 수 있다.

넷째, 브라우저를 제한하거나 브라우저 파편화에 대한 영향도가 낮은 시스템을 들 수 있다. 바닐라JS로 프로젝트를 진행할 때 가장 문제시되는 것이 바로 파편화 처리라고 볼 수 있다. 지원해야 하는 브라우저가 증가할수록 테스트기간이 증가할 수 있으며, 발견된 문제들은 프로젝트 내에서 직접 해결해야 한다.

그리고 추가적으로 바닐라JS로 프로젝트를 진행할 경우 개발자의 역량이 결과물에 큰 영향을 줄 수 있으므로, 개발자 선정 및 개발자 교육 그리고 개발 품질관리에 많은 노력이 필요하다.

라이브러리나 프레임워크 이용한 개발에 적합한 프로젝트

▲ 라이브러리나 프레임워크를 이용한 개발 시 장단점

라이브러리나 프레임워크 이용한 개발에 적합한 프로젝트는 다음의 예를 들 수 있다.

첫째, 기능적 요구사항이 많은 시스템이다. 라이브러리나 프레임워크는 높은 수준의 기능 및 예제를 제공하고 있으며, 그에 따른 개발 공수를 절약할 수 있다. 하지만 다양한 기능을 제공할수록 스크립트 구성이 무거워 질 수 있으므로 단순한 구조의 시스템에는 적합하지 않다.

둘째, 다양한 사용자 환경을 지원해야 하는 시스템이다. 라이브러리나 프레임워크에서 제공되는 기능은 대개 브라우저에서 검증된 것들이며, 브라우저 파편화에 대한 이슈를 어느 정도 해결할 수 있다. 하지만 저마다 지원하는 브라우저 버전이 다를 수 있으므로 반드시 사전에 확인해야 한다.

셋째, 지속적인 유지보수 관리가 필요한 시스템의 경우다. 프레임워크는 의도된 제약 및 구조화된 스크립트 방식을 제공하고 있으며 바닐라JS 대비 유지보수 관리가 용이하다. 라이브러리는 단순히 기능적인 요소를 제공하고 있는 경우가 많으므로 바닐라JS와 마찬가지로 유지보수의 어려움이 있을 수 있다.

그러나 라이브러리, 프레임워크도 그에 대한 학습이 전제돼야 한다. 또한 안정적인 서비스, 요구 기능에 대한 대응, 서로 간 호환성 문제 등 다각도로 확인이 필요하다. 그리고 학습이나 호환성의 문제로 여러 종류의 라이브러리와 프레임워크를 조합해 사용하는 것은 권장하지 않는다.


또 다른 대안은 없는가?

국내 기업용 시스템을 개발하는 입장에서 봤을 때, 위에서 언급한대로 검토하고 그에 맞춰 프로젝트를 진행하기에는 현실적인 어려움이 있다. 최소한의 기간 내에 복잡한 기업 업무를 빠르게 개발하고, 사용자 환경에 맞춰 안정적으로 운영 유지보수까지 소화해야 하는 국내 환경과는 거리가 있을 것이다. 게다가 이 모든 조건들을 검토하고 구현할 수 있는 개발자 리소스를 수급하는 것도 쉽지 않은 현실이다.

그에 대한 대안으로 웹 솔루션 제품을 이용하는 방법이 있다. 국내 웹 솔루션 제품의 경우 라이브러리나 프레임워크 형태로 구성돼있고, 예상되는 문제들에 답을 제공할 수 있는 솔루션들이 존재한다. 특히 학습과 기술지원에 대한 이슈에서 자유로울 수 있다는 장점이 있다. 정리해보면 다음과 같다.

첫째, 비교적 수월하게 라이브러리나 프레임워크를 도입할 수 있다. 국내 제품들은 개발자 교육, 기술지원, 개발자 수급 등 프로젝트 진행에 있어 필요한 서비스들을 제공하므로 오픈소스 대비 초기 진입장벽이 낮다.

둘째, 라이브러리나 프레임워크 파편화 이슈 해소가 가능하다. 대부분의 솔루션에서 단일버전정책으로 솔루션을 공급하고 있으며, 별도의 연계 없이 대부분의 기능을 자체적으로 제공하고 있어 파편화에 대한 이슈를 어느 정도 해소할 수 있다.

셋째, 기술지원 및 유지보수가 용이하다. 특히 국내 제품인 경우 자체적인 기술지원 조직 및 개발자 인력을 보유하고 있어 소통이 원활하고 긴밀하게 도움을 받을 수 있으며, 기술 응대까지 소요되는 시간이 오픈소스 대비 매우 짧다.

넷째, 자체 도구를 풍부하게 제공한다. 개발도구뿐만 아니라 컴포넌트, 패키지매니저, 디버깅, 빌드 등 개발 전반에 걸친 도구들을 제공하고 있어 선택 및 검증해야 하는 수고를 덜 수 있다.

이처럼 국내 웹 솔루션을 선택할 경우 일반적인 라이브러리나 프레임워크 대비 우리 개발환경에 맞는 서비스를 보다 편안하고 안정적으로 제공받을 수 있는 장점이 있다. 하지만 각 벤더사 또는 솔루션마다 제공되는 수준의 차이가 발생할 수 있으므로 관련내용을 세심하게 확인해볼 필요가 있다.

 

웹 시장은 하루가 다르게 변화와 성장을 거듭하며 다양한 시도들이 이뤄지고 있다. 그 과정에서 새로운 기술들이 빠른 속도로 생겨났다 사라지고, 우리는 뒤쳐지지 않기 위해 늘 고민하며 최선의 답안지를 찾기 위해 노력하고 있다.

하지만 언제나 돌파구는 있을 것이다. 수많은 기술과 솔루션은 우리를 돕기 위해 존재하며, 다만 선택은 각자의 몫이라고 생각된다. 이 긴 글이 같은 고민에 빠져있는 개발자 동료들이 생각을 정리하는 데 조금이라도 위로와 도움이 됐으면 하는 바람이다.

저작권자 © 아이티데일리 무단전재 및 재배포 금지