‘협업’과 ‘생산성’에 초점 맞춘 오픈소스 프레임워크

본 공개SW 활용 성공사례는 컴퓨터월드와 정보통신산업진흥원(NIPA) 공개SW 역량프라자가 공동으로 발굴한 기사입니다.

[컴퓨터월드] 웹 개발의 경우 안드로이드나 iOS, 윈도우의 경우와 달리 플랫폼 벤더가 주도하는 특정 프레임워크가 존재하지 않는다. 오픈된 형태로 발전하는 기술이기 때문에 표준화 된 프레임워크가 존재하지 않는 대신 프레임워크의 개발자가 중요하다고 생각하는 요소를 강화한 다양한 형태의 프레임워크가 제안되는 편이다. 배달의민족을 서비스하고 있는 우아한형제들은 최근 자체 개발 프레임워크를 깃허브(Github)를 통해 공개하고 기술블로그를 통해 이를 밝혀 눈길을 끌고 있다.

 

‘빠른 생산성’을 갖춘 프레임워크의 필요

프레임워크는 또렷하게 정의되기 어려운 단어다. GoF(Gang of Four)로 불리는 네 명의 컴퓨터과학 연구자 중 한 명인 랄프 존스(Ralph Johnson)는 프레임워크를 ‘소프트웨어의 구체적인 부분에 해당하는 설계와 구현을 재사용이 가능하게끔 일련의 협업화된 형태로 클래스들을 제공하는 것’으로 정의하고 있다.

프레임워크란 효과적인 개발을 위해 다양하게 제안되는 일련의 개발 가이드라인으로 볼 수 있다. 어떤 방식이 더 효과적인지, 정의하는 사람·조직에 따라 상이하며, 이에 따라 사용하고자 하는 목적을 분명히 하고 선택하는 것이 중요하다. 최근에는 앵귤러JS(AngularJS)나, 리액트(React.js) 등이 주목받고 있으며, 국내외로 많이 사용되고 있다. 구글이나 페이스북도 자체 개발한 프레임워크를 가지고 있고 이들 프레임워크는 개발자들에게 많은 관심을 받고 있다.

우아한형제들의 경우 자바스크립트를 능숙하게 다룰 수 있는 프론트엔드 엔지니어의 수보다 HTML과 CSS를 사용하는 웹 퍼블리셔의 수가 많은 상태였다. 그러한 이유로 이들 퍼블리셔가 내부에서 생산하는 페이지도 많은 비율을 차지하고 있으며, 생산해야 하는 속도 또한 사업의 진행에 맞춰 빠르게 진행돼야 했다. 기존 프레임워크는 이러한 점에서 원활한 협업이 어려웠다. 기존 프레임워크가 엔지니어 친화적이며, 자바스크립트를 익숙하게 다룰 줄 안다는 것을 가정하고 있기 때문이었다.

우아한형제들의 우아한JS(WoowahanJS)는 이 점에 주목해 만들어졌다. 기존의 프레임워크는 퍼블리셔의 입장에서 접근이 어려웠을 뿐 아니라, 많은 기술지원 요청들을 원활하게 해결하기 어려웠다. 게다가 기존 프레임워크가 장점으로 내세우는 성능 또한 일상적인 웹앱 개발에서 발생하지 않는 지나치게 극단적인 상황에서 테스트된 성능 지표이기에 성능에 대한 이점 역시 크지 않았다.


사용하기 편리하게 해 생산성 높여

우아한형제들이 개발해 공개한 우아한JS는 협업과 빠른 생산성에 초점을 맞춰 개발됐다. 기존 프레임워크와의 가장 큰 차이점은 자바스크립트를 HTML/CSS와 명확히 분리해냈다는 것이다. 자바스크립트를 모르는 웹 퍼블리셔도 HTML 파일로 쉽게 작업할 수 있다.

▲ 우아한형제들 내부사용자용 ‘UI마트’ 화면

아직 외부적으로 공개된 기능은 아니지만 내부적으로는 UI마트를 사용해 생산성을 높이고 있다. 전형적인 틀을 갖춘 웹페이지의 경우 쇼핑하듯 편하게 제작이 가능하다. 구성할 화면을 고르고 다운로드 받아 프로젝트의 API를 연결하고 화면에 맞춰 가공하면 웹페이지가 쉽게 생성된다.

우아한JS는 J쿼리(JQuery)와 백본JS(Backbone.js)를 기반으로 만들어졌다. 처음 개발될 당시에는 백본JS를 기반으로 그 위에 우아한형제들이 생각하는 웹개발 방식을 덧입힌 형태로 개발됐다. 따라서 현재까지는 백본JS를 많이 포함하고 있었지만 초기의 우아한JS와 다르게 현재는 사용되지 않는 기능 또한 많다. 따라서 개발자들은 우아한JS에서 백본JS의 주요 기능을 더욱 거둬내 자체 기능을 강화해 나갈 계획이다.

▲ 우아한JS 아키텍쳐

하지만 프레임워크 개발이 처음부터 쉽지는 않았다. 자체개발 프레임워크에 대한 거부감 때문이었다. 비단 프레임워크뿐만 아니라 특정 솔루션을 자체개발해 내부에서 사용하는 경우 개발자 개인에게 종속성이 생기는 경향이 있다. 이러한 경우 개발한 인원이 회사를 떠나면 기술지원이나 후속개발이 불가능하다는 점이 위험요소로 꼽힌다.

회사뿐 아니라 개발자 차원에서도 우려를 받는다. 현재도 개발자직군의 이직률은 굉장히 높은 편이다. 이들은 대부분 같은 직군으로 이직하기에 어떤 기술을 다뤄왔는지가 중요 이력사항이 되곤 한다. 사내 개발 프레임워크로만 일했을 때는 이직에 있어서 불이익을 받기 쉽다. 특히 우리나라는 인기있는 프레임워크 사용자를 우대하는 경향이 높아 개발자들도 이들 프레임워크를 선호하곤 한다.


소스공개의 목적은 ‘동기부여’

이러한 우려를 타계하기 위한 방책으로 우아한형제들은 과감한 선택을 했다. 사내 프레임워크를 오픈소스로 공개한 것.

특히 우아한형제들이 ‘우아한JS’의 코드를 공개한 목표는 시장을 선도하는 프레임워크가 되는 것이 아니었다. 김민태 우아한형제들 수석연구원은 코드 공개의 목표를 크게 두 가지라고 설명했다. 하나는 공개라는 방식을 통해 프레임워크의 배포를 관리하는 것이고, 다른 하나는 내부 개발자의 동기부여였다.

소스를 공개함으로써, 누구나 접근할 수 있는 열린 공간에 새로운 버전을 배포하고, 릴리즈하는 주기를 관리할 수 있게 됐다. 별도 시스템을 사용하지 않고도 사내 사용자들이 프레임워크를 최신 버전으로 사용하는데 큰 어려움이 없게 됐다.

개발자들의 동기부여 또한 중요한 목표중 하나였다. 최근에는 공개SW에 코드를 기여하거나 커뮤니티에 참여하는 것이 개발자의 주요 능력 중 하나로 인정받고 있으며, 기업 차원에서 참여를 권장하기도 한다. 하지만 현실적으로 회사에 속한 개발자가 공개SW 개발에 참여하거나 코드를 기여하는 것이 쉽지는 않은 상황이다. 반면 우아한JS의 경우 자체 개발한 프레임워크를 공개하게 되면서 내부 개발자들이 오픈소스에 참여할 수 있는 진입 장벽은 낮아졌다.

이러한 변화는 일하는 방식의 전체적인 변화를 이끌었다. 기존에는 어떤 프로젝트건 프로젝트가 진행되면 사용된 정보와 지식들이 프로젝트 내부에 갇히는 경향이 있었다. 외부에서 프로젝트 개발에 대해 관여하기 어려웠던 것. 반면 우아한JS의 코드가 공개된 후 사내 피드백과 의견제시가 활발해졌다. 개선점에 대한 많은 의견과 필요한 기능에 대해 사내 사용자들이 손쉽게 제안할 수 있게 됐다.

<인터뷰> “공개SW, 목적을 확실히 해야”


▲ 김민태 우아한형제들 CTO실 수석연구원


‘우아한JS’의 소스를 공개하면서 가장 어려웠던 점은?

 

문서화가 가장 어려웠다. 처음부터 문서화에 많은 시간을 들였다. 소스 공개가 한 달 정도 늦어지더라도 문서화에 공을 들일 정도였다. 외부 사용자에게 개발 철학과 사용방법을 드러낼 수 있는 방법이 문서밖에 없다고 생각했다.
 

타 공개SW의 사용이 어려운 이유도 문서의 현행화가 지연되기 때문인 경우가 많다. 이런 경우 실제 동작과 문서상의 지시가 달라 시행착오를 겪어야만 한다. 규모가 작은 공개SW의 경우 코드를 확인하면 되지만 규모가 커질수록 녹록하지 않다. 문서의 유지보수가 코드보다 훨씬 중요하고 어려울 수 있다.
 

아쉬운 점은 현재까지 문서가 전부 한글로만 제공되고 있다는 점이다. 영어 사용자들의 경우 피드백을 훨씬 많이, 훨씬 쉽게 주고받는 경향이 있다. 한글 문서로 인해 이들이 역으로 진입장벽을 느끼는 것 같아 아쉽다. 아직 여력이 부족해 영문 문서 제공이 어렵지만 향후 제공하고자 한다.
 

코드를 공개하며 기대한 바가 있다면?
 

프레임워크의 경우, 유명프레임워크에 쏠림현상이 심한 경향이 있다. ‘우아한JS’의 경우, 애초부터 우리 프레임워크를 많이 가져다 쓰라는 의미로 코드를 공개한 것은 아니다. 유명 프레임워크를 뛰어넘으려는 것이 아니었음에도 ‘왜 만들었느냐’는 피드백을 가장 많이 받았다.

웹에는 표준화된 개발방식이 있을 수 없다. 다양하게 여러 사람들이 더 좋은 방식에 대해 제안해볼 수 있다. 그 중 효과적인 것이 시장에 안착하는 것이다. 프레임워크 선택에도 사용목적에 맞는 선택이 중요하다. 국내의 경우 유명 프레임워크를 우선적으로 취사선택하는 경우가 많다. 그런 부분이 아쉬웠다.
 

국내 공개SW 사용/공개 풍토에 대해서

라이선스상의 이유뿐 아니라 처음부터 공개는 의무라고 생각했다. 널리 알리거나 시장을 선도하는 것을 중요하게 생각하지는 않았다. 공개SW는 참여 자체가 큰 가치다. 커뮤니티의 규모나 코드의 기여 등으로 랭킹을 메기는 것이 중요하지 않다. 하지만 사실상 참여조차 시도하지 못하는 개발자가 많다.

공개SW의 장점은 양날의 검이다. 오픈돼 있다는 것은 소스코드가 어떻게 구현돼 있는 건지 저자의 설명 없이도 코드를 통해 읽어낼 수 있다는 것이다. 라이선스의 규제를 받지만 이러한 콘셉트와 기술력을 얼마든지 응용해 자산화 할 수 있다. 단점이라면 코드를 봐야한다. 구매한 솔루션이라면 사용법이나 개선에 대한 요청이 가능하지만 공개SW의 경우 그것이 제한적이다.

결국 공개SW 사용에는 전략이 필요하다. 라이선스 전략이든 회사의 전략이든 목표를 분명히 하고 접근하는 것이 좋다. 어떠한 목표를 가지고 있느냐에 따라 공개SW 사용이나 소스코드 공개에 대한 전략 또한 달라진다.
그런 전략에 대해 이해 없이 상용 구매패턴과 많이 벗어나지 않은 공개SW 사용 경향은 아쉽다.

 

 

저작권자 © 컴퓨터월드 무단전재 및 재배포 금지