프레임워크와 라이브러리는
무엇이 다른가

면접에서든 사내 위키에서든 한 번쯤 나오는 질문입니다. 프레임워크와 라이브러리는 무엇이 다른가. 대개는 "라이브러리가 더 작은 것" 정도로 정리되고 넘어갑니다. 틀린 답은 아니지만 쓸모 있는 답도 아닙니다. 크기로 나누면 경계가 늘 애매해집니다.

이 글은 그 구분을 다시 세우고, 거기서 시작해 조직이 실제로 무엇을 표준화해야 하는지까지 짚어 봅니다. 결론부터 말하면 대부분의 조직은 프레임워크를 표준화하는 데서 멈추고, 정작 개발 시간을 잡아먹는 컴포넌트는 팀마다 제각각으로 둡니다.

차이는 크기가 아니라 제어의 방향이다

라이브러리는 재사용 가능한 코드 묶음입니다. 함수나 클래스 정의의 모음이고, 가져다 쓰는 쪽이 언제 어디서 부를지 정합니다. jQuery나 D3.js가 그렇습니다. 내가 필요한 자리에서 내가 부릅니다.

프레임워크는 서로 잘 맞물리는 라이브러리들이 하나의 목적을 위해 짜인 것입니다. 그런데 결정적인 차이는 구성이 아니라 제어의 역전입니다. 프레임워크에서는 내 코드를 어디에 넣을지를 아키텍처가 정하고, 개발 규칙도 프레임워크가 갖습니다. 내가 부르는 것이 아니라 프레임워크가 내 코드를 부릅니다.

이 구분이 실무에서 왜 중요한가. 프레임워크를 고르는 일은 규칙을 고르는 일이기 때문입니다. 라이브러리는 마음에 안 들면 그 자리만 걷어내면 되지만, 프레임워크를 바꾸는 것은 애플리케이션의 뼈대를 바꾸는 일입니다. 그래서 프레임워크 결정은 무겁고, 조직이 표준화에 공을 들이는 대상도 대개 여기까지입니다.

표준화는 대개 프레임워크에서 멈춘다

중견 이상의 조직에서 IT 관리자나 프로젝트 관리자는 늘 프로세스를 표준화하고 방법론을 통합하려 합니다. 생산성을 올리고 비용을 줄이기 위해서입니다. 자바스크립트 개발팀에 대해서는 그 노력이 보통 프레임워크 선택으로 향합니다. React냐 Angular냐 Vue냐 Ext JS냐, 아니면 순수 자바스크립트냐.

그런데 그 결정이 내려진 다음은 어떻게 됩니까. 프레임워크가 정해졌다고 해서 각 팀이 만드는 그리드가 같아지지는 않습니다. 폼도, 필터도, 레이아웃도 마찬가지입니다. 같은 프레임워크 위에서 열 개 팀이 열 개의 데이터 그리드를 만듭니다.

사일로에서 실제로 벌어지는 일

큰 조직의 개발팀은 각자의 프로젝트에 맞춘 작업 방식과 코드를 갖고 있습니다. 어떤 팀은 특정 프레임워크를 선호해 그에 맞춰 코드를 써 두었고, 다른 팀은 전혀 다른 방법론을 쓰면서도 기능적으로는 비슷한 코드를 만들고 있습니다. 팀은 사일로 안에서 일하고, 어딘가에서 반드시 바퀴를 다시 발명합니다.

재사용 가능한 컴포넌트가 없는 팀이 하는 일은 셋 중 하나입니다. 오픈소스에서 찾거나, 상용 벤더에서 구매하거나, 직접 씁니다. 그런데 여기서 끝나지 않습니다. 무료로 구할 수 있는 컴포넌트는 모든 시나리오를 염두에 두고 만들어진 것이 아니라, 필요한 기능이 없거나 성능이 모자랄 수 있습니다. 그러면 개발자는 가장 뻔한 길을 갑니다. 코드를 복제하고, 손보고, 그 사본을 유지보수합니다.

시간만 드는 것이 아닙니다. 그 컴포넌트를 여러 플랫폼과 브라우저, 운영체제, 환경에서 테스트하는 일이 뒤에 붙습니다. 그리고 같은 회사 안의 다른 팀에서 그 노력이 비슷하게 반복됩니다.

중앙 컴포넌트 라이브러리가 하는 일

중앙에 검증된 UI 컴포넌트 저장소를 두는 것은 그 반복을 끊는 방법입니다. 바로 쓸 수 있는 컴포넌트와 디자인·반응형 레이아웃 해법을 팀과 사업부가 공유합니다.

이것이 개발자의 자유를 막자는 이야기는 아닙니다. 개발 주기를 아껴 그 시간을 다른 데 쓰자는 이야기입니다. 앱의 UX 설계와 테스트, 기능 개선, 성능 최적화처럼 사업 성장에 실제로 기여하는 자리 말입니다.

컴포넌트를 만들 것인가, 사올 것인가

고전적인 질문이고 팀마다 답이 다릅니다. 완전히 직접 만드는 쪽, 상용을 사는 쪽, 섞어 쓰는 쪽이 있습니다. 뛰어들기 전에 따져야 할 것이 셋입니다.

나중에 붙을 기능. 사내에서 만든 그리드·폼·차트·레이아웃 매니저는 있을 수 있는 사용 시나리오를 다 고려하기 어렵습니다. 결국 기능이 모자란 컴포넌트가 남고, 쓰는 사람이 그때그때 확장하고 손봐야 합니다. 코드에 대한 통제권은 완전히 갖지만, 상용 라이브러리에는 이미 들어 있는 기능이 우리에게는 없습니다.

지금 있는 자원. 공유 가능한 컴포넌트를 오래도록 만들고 유지할 자원이 충분하다면 직접 만드는 쪽이 맞을 수 있습니다. 사내용 소규모 앱이고 요구가 제한적이라면 특히 그렇습니다. 반대로 자원이 빠듯하고 출시 시점이 중요하다면 라이선스를 사는 편이 분별 있는 선택입니다. 사내 컴포넌트 개발은 주기가 길고, 품질과 성능 기준을 엄격하게 지켜야 합니다.

기술부채. 이직은 반드시 일어납니다. 팀이 미리 대비해 두면 좋겠지만 대개는 그렇지 못합니다. 만든 사람이 떠나면 남은 사람이 그 코드를 읽는 데 시간을 씁니다. 그 시간은 어느 예산 항목에도 잡혀 있지 않습니다.

국내 상황에 대입하면

국내 대기업과 금융권에서는 이 문제가 계열사 단위로 한 번 더 커집니다. 같은 그룹 안에서 계열사마다 SI를 따로 발주하고, 그 결과 화면 부품이 각각 만들어집니다. 그룹 표준 UI 가이드가 문서로는 있는데 구현체가 없는 경우가 흔합니다. 가이드는 색과 여백을 정할 뿐, 그리드가 어떻게 동작해야 하는지는 정하지 못합니다.

여기에 국내 특유의 조건이 하나 더 붙습니다. 웹 접근성 인증입니다. 컴포넌트마다 접근성을 따로 맞추면 그 검수를 프로젝트 수만큼 반복하게 됩니다. 중앙 컴포넌트를 한 번 맞춰 두면 그 검수도 한 번으로 끝납니다. 상용 컴포넌트를 검토할 때 접근성 대응 수준을 함께 보셔야 하는 이유입니다.

인력 교체 주기가 짧은 것도 같은 방향으로 작용합니다. 프런트엔드 인력이 얇고 프로젝트 단위로 움직이는 조직에서, 직접 만든 컴포넌트는 만든 사람이 나가는 순간 읽을 수 없는 코드가 됩니다. 문서와 예제가 갖춰진 상용 컴포넌트는 그 지점에서 값을 합니다.

이 글은 Sencha 백서 Adopting a Unified Component Library Strategy (Kirti Joshi)의 내용을 바탕으로 미래웹 주식회사가 국내 독자를 위해 재구성한 것입니다. 본문의 도식과 이미지는 Sencha가 발표한 자료이며 저작권은 Sencha / Idera, Inc. 에 있습니다. 「국내 상황에 대입하면」 항목은 원 자료에 없는 미래웹의 해설입니다.