UI 라이브러리.. 써, 말아?

UI 라이브러리를 활용하는 개발팀과 발생하는 이슈

시작하기에 앞서

글 두개를 너무 무겁고 길게 쓴 이유로, 이번에는 가볍고 짧게 쓰고자 한다.

UX를 업으로 하는 사람이 같은 회사의 다른 역할자와 함께 일하기 때문에 겪는 일을 이야기하겠다.

멋진 화면 기획안의 구현을 꿈꾸며

UX는 사용자 경험을 디자인하는 일이다. 사용자에게 좋고, 훌륭한 경험을 선사하기 위해 많은 일을 한다. 화면을 나이스하게 디자인을 하고, 화면에서 사용하는 인터렉션을 디자인한다. 그리고 완성한 기획안을 바라볼 때는 나 자신이 무척 대견하고 뿌듯하다. 자신에게 감동을 준 기획안에 그래픽 디자인을(나는 미적 감각이 없다.)하고 개발자에게 이대로 개발해달라고 전달한다.

하지만 얼마의 시간이 흐르지 않아, 공통 모듈 개발팀, 또는 업무 개발자에게 연락이 온다. 이런 기획은 자신들이 사용하는 라이브러리로 구현 못한다고 한다. 도대체 라이브러리라는 게 뭔데 나를 이렇게 힘들게 하는가. 라이브러리를 왜쓰는데? 아놔.....

라이브러리란?

개발팀과 함께 일하면, 앞서 말한 상황을 종종 마주한다. 라이브러리가 무엇인지 알면 적어도 현업 개발자와의 커뮤니케이션에 도움이 될 것이다

library. 사전적으로는 도서관을 의미한다. 네이버 국어사전에서는 다음으로 정의한다. "컴퓨터 프로그램에서 자주 사용되는 부분 프로그램들을 모아 놓은 것. 언제든지 자유롭게 이용할 수 있도록 구성되어 있다". "프로그램에서 자주 쓰는 부분"은 사용빈도가 높은 기능 정도로 해석할 수 있겠다. 개인적으로는 "개발자가 여러 복잡한 기능을 다른 개발자가 쉽게 쓸 수 있도록 미리 만든 것"이라 정의하겠다.

select box, 출처 : https://www.drupal.org

예를 들겠다. 여러 옵션 중에 하나를 선택하는 것을 구현할 때 select box를 사용한다. select box가 수행하는 기능은 3가지로 말할 수 있다.

1. select box를 선택 시 내가 선택할 수 있는 옵션을 보여준다.

2. 사용자가 옵션을 선택하면 그 옵션을 select box를 닫는다

3. 2번 액션과 동시 선택한 옵션을 select box 부분에 표현한다.

이런 기능을 하는 코드를 사용해야 하는 화면마다 세상 모든 개발자가 직접 만들면 모든 개발자가 피곤하다.

앞서 말한 3가지 기능을 수행하는 코드를 어딘가에는 짜 두었다. 하나의 쉬운 이름(select box)으로 지정하여 복잡한 코드는 숨겨두고, 일반 개발자들이 이름(select box)을 사용할 수 있도록 구현했다. 물론 select box를 라이브러리라고 하기에는 너무 보편적이지만, 위 맥락으로 라이브러리를 이해하기 바란다.

라이브러리를 왜 쓸까?

UX 하는 사람에게 연관성이 높은 라이브러리는 UI 라이브러리라 생각한다.

UI 라이브러리로 유명한 것이 JQueryUI, JqGrid 등이 있다. UI라이브러리는 사용자의 화면에서 요소별 인터랙션과 기능을 담당한다. JQueryUI는 컴포넌트 인터렉션과 그래픽 라이브러리로써, 예쁜 셀렉트 박스, 멋진 다이어로그, 화려한 화면 전환이 가능하도록 한다.

기본 테이블, 출처:jqgrid.com

 JqGrid는 화면 컴포넌트의 하나인 테이블을 지원하는 라이브러리이다. 행 추가, 트리구조 테이블, 테이블 헤더를 활용한 콘텐츠 정렬 등 많은 기능을 지원한다. 이런 기능을 하나하나 개발한다면 정말 오랜 시간이 걸린다. 필자의 경험으로 테이블 헤더를 고정할 수 있는 테이블 내 스크롤 기능을 구현하는데 3달이 걸렸다.

개발팀이 라이브러리를 쓰는 이유는 빠르고, 좋은 품질의 소프트웨어를 만들기 위해서 이다.

라이브러리는 이미 능력 있는 개발자들이 만들었다. 비용 정책(오픈 소스냐 라이선스 피를 내느냐)은 다음에 논한다 치고, 라이브러리만을 보면 능력 좋은 멋진 개발자가 만든 것이다. 현업 개발자는 필요한 기능(예 : 테이블 내 정렬)을 쉽게 적용(직접 만드는 게 아니므로)할 수 있으므로 필요한 기능 구현에 고민하는 시간을 업무 프로세스를 구현하는데 시간을 쏟아, 궁극적으로 좋은 제품을 짧은 시간에 빠르게 만들 수 있다.

라이브러리 존재는 현업 개발자에게 필요한 기능은 "만든다"가 아니라 "찾는다"라는 개념을 제공한다.

고로 라이브러리를 안 쓸수는 없다. 어쩌면 우리에게는 가혹한 운명이다

현업 개발자가 UX 기획자에게 왜 이슈를 제기할까?

간단하다 현업 개발자가 가진 라이브러리가 기획을 구현할 수 없거나, 라이브러리를 수정하는 상황 때문이다.

1) 라이브러리가 기획을 구현할 수 없는 상황

작성한 기획이 라이브러리로 구현이 불가능하면 현업 개발자가 직접 만들어야 한다.  개발팀이 산정한 일정에 라이브러리에 없는 프로그램을 개발할 시간을 고려했으면 다행이다. 고려하지 않은 경우가 문제이다. 이 경우 기획자와 현업 개발자가 '일정에 납기가 가능한지를 전제로' 기획안이 구현 가치가 있는지 확인한다. "개발할 가치가 있다" 판단하면 개발하되 납기 일정을 맞추기 위한 노력(인력을 더 투입, 납기 일정을 늘리는 커뮤니케이션)을 한다. "개발할 가치가 없다" 판단하면 다르게 기획하여 최대한 비슷한 원 기획안의 콘셉트를 살릴 수 있는 방법을 찾아야 한다.

2) 라이브러리를 수정하는 상황

먼저 납기 내 수정해야 한다. 납기와 관련 이슈는 구현할 수 없는 상황과 동일하되 2가지 이슈가 더 발생한다.

1. 수정의 부작용

라이브러리는 현업 개발자가 만든 코드가 아니다. 따라서 다른 사람(라이브러리 개발자)이 만든 복잡한 코드를 100% 이해한다는 것은 불가능에 가깝다.(가끔 천재가 계시므로).  완벽한 이해를 전제하지 않는 상태에서 현업 개발자는 라이브러리 코드 수정이 라이브러리 내부에 어떤 영향을 줄지 예측할 수 없다. 고로 현업 개발자는 라이브러리 수정을 부담스러워한다.

2. 버전 업 이슈

현업 개발자가 완벽하게 이해해서 수정하여도 이슈가 없는 것은 아니다. 라이브러리는 생명을 가졌다. 본인이 운영하는 블로그든, github를 이용하든 라이브러리를 사용하는 다른 개발자로부터 피드백을 받는다. 피드백을 반영하여 라이브러리 개발자는 꾸준히 업데이트를 한다. 현업 개발자가 라이브러리를 기획의도에 맞게 바꾸었다면, 업데이트를 반영해야 하는지 말아야 하는지를 선택해야 한다. 업데이트를 하면, 1. 기존에 자신이 변경한 로직을 다시 업데이트한 라이브러리에 넣어야 하며, 2. 변경한 로직으로 인한 부작용을 다시 확인해야 한다. 기능 업데이트라면 안 하고 버텨도 되지만, 업데이트가 보안 이슈를 해결하던지, 크리티컬한 문제를 해결한 경우라면 어쩔 수 없다. 그렇기에 라이브러리 수정을 꺼린다.

그럼 기획자는 어떻게 해야 하는가?

개발팀에서 사용하는 UI 라이브러리와 그 라이브러리가 지원하는 인터렉션, 화면 전환을 확인해야 한다.

라이브러리가 지원하는 제한된 인터렉션에서만 기획하라는 뜻이 아니다. 궁극적으로 우리가 디자인을 하는 목적은 상품의 출시이다. 콘셉트상 반드시 필요한 인터렉션과 화면 전환은 개발팀에 어필하여 개발의 필요성을 주장해야 한다. 불필요한 인터렉션을 기획하지 말라는 뜻이다. 시간을 미리 확보하여, 나중에 어쩔 수 없는 상황을 만들지 말라는 뜻이다. 어떤 것이 있는지 알아야 주장을 할 수 있고, 미리미리 이슈 제기를 할 수 있다. 고로 지피지기면 백전불태이듯이 개발팀의 라이브러리를 이해하여, 기획자로서 내가 어떻게 해야 하는지 미리 고민하는 시간을 갖기를 바란다.

.