React로 만드는 Electron 웹 애플리케이션; 레이아웃, AntD Customization
QueryPie 개발기 #4: 프론트엔드 개발을 시작하며
지난 1년간 머리 속에서 떠나지 않는 생각이 있다.
그것은 바로 새로운 웹 애플리케이션을 만들어야 한다는 것이다.
새로운 웹 애플리케이션, 정확히는 데이터베이스 쿼리를 Windows, Mac, Linux에서 모두 실행할 수 있고 최신 웹 기술 기반으로 개발되어 예쁘고 섹시한 애플리케이션이다.
오랜 시간 프론트엔드 개발자로 살아오면서 든 생각은 앞으로 HTML/CSS/ES가 가장 오래 살아남는 주류가 될 것이라는 점이다. 요즘의 흐름을 보면 웹 기술을 응용 프로그램 부분에 접목하는 일이 너무나 자연스러워지고 있고, 나 역시 그 방향으로 나아가야 한다고 생각하고 있다.
그리고 이런 생각이 들기 시작하자 요즘 가장 주목받는 Electron을 이용하여 Webview를 렌더러로 사용하고 그 위에 React로 제작된 컴포넌트들을 Webpack으로 번들링하여 SPA(Single Page Application)로 만들어야겠다는 그림이 그려졌다.
이 새로운 애플리케이션의 이름은 QueryPie로 정해졌고, QueryPie 개발팀은 애플리케이션 개발에 필요한 이슈들을 계획한 뒤 2주일 동안 할 수 있는 일들을 묶어 스프린트 단위로 관리하기로 했다. 그리고 각 스프린트가 끝날 때마다 스프린트 동안의 경험을 모아서 회고의 글을 쓰기로 했다.
오늘은 그 중에서도 가장 기본이 되는 QueryPie의 레이아웃이 어떻게 탄생했는지에 대해 이야기하려고 한다.
QueryPie 레이아웃의 발전 과정
첫 번째 레이아웃: Slack 스타일
첫 레이아웃을 그려보기 시작했다. 위 이미지는 새로운 애플리케이션을 만들기로 했을 때 처음으로 기획했던 레이아웃 안이다. 왼쪽부터 접속 정보, 데이터베이스와 개체 정보, Query 에디터, 실행 결과의 순으로 배치하면 좋겠다고 생각했다. 보이는 것처럼 구조를 단순화하고 간단한 SQL문장을 작성하고 결과를 보는데 큰 문제가 없게 구성했다.
하지만 만들어놓고 나니 많은 부분 Slack과 비슷한 느낌이 난다. 이 때 당시 Electron 애플리케이션 중에 성공한 Slack의 레이아웃에 빠져 있던것 같다. 간결한 스타일은 좋았지만 데이터베이스 툴에서 중요한 테이블, 뷰, 트리거, 함수 등의 개체 정보 등을 확인하기 위한 공간의 배려가 부족하다는 생각이 들었다.
두 번째 레이아웃: Sequel Pro 스타일
두 번째로 고려했던 레이아웃 안은 Sequel Pro 스타일이다(크루들 중 Brant가 특히나 이 레이아웃을 좋아했다). 이 레이아웃을 선택하게 되면 테이블(개체) 단위로 구조, 내용, 관계, 트리거, 정보를 직관적으로 볼 수 있는 장점이 있다.
이런 직관성을 극대화하기 위해서 왼쪽 개체 목록을 트리가 아닌 리스트 형태로 보여주고 있고, 상단바의 큰 아이콘을 배치하여 선택 테이블의 원하는 정보를 웹사이트의 메뉴처럼 볼 수 있게 해주었다.
솔직히 이 레이아웃을 보고 든 첫 느낌은 어색함이었다. 오랜 기간 Windows 애플리케이션의 UX에 길들여진 탓인지 이런 구성은 다소 생소하게 느껴졌다. 하지만 차근차근 시간을 두고 살펴 볼 수록 나쁘지 않다는 생각을 하게 되었다.
그 이유 중 하나는 데이터베이스 관리 프로그램도 점점 더 간결한 디자인으로 가는 추세이기 때문이다. 직군에 따라 차이는 있을 수 있지만, 데이터베이스 관리 프로그램에 접속해서 하는 일 중 대부분은 테이블이나 개체의 정보를 확인하는 일들이고 많은 양의 SQL 문장을 작성하는 일은 상대적으로 적다고 생각했다.
복잡한 애플리케이션의 경우에는 ORM(Object-Relational Mapping)을 이용하여 길거나 어려운 SQL 문장을 만드는 일이 줄어들고 있고, 간단한 애플리케이션 개발의 경우 테이블 간의 관계가 거의 없는 경우가 많기 때문이다.
하지만 여전히 단점이 존재했는데, SQL 문장을 작성하면서 개체 정보를 확인하는 일이 어렵고 Query를 동시에 여러 개 작성할 수 없어서 불편하다는 것이다. 또한 상단 바의 크기가 커서 공간을 많이 차지 하고 있다는 느낌을 지울 수 없었다.
세 번째 레이아웃: QueryPie 스타일
이런 생각들을 바탕으로 세 번째 레이아웃을 만들게 되었다. 위에서 살펴본 2가지 레이아웃 외에도 수 많은 애플리케이션을 벤치마킹하고 레이아웃을 수십 차례 다시 그려야 했다. 현재도 완전히 확정된 안은 아니지만, 이전 안들과 비교해보면 훨씬 더 완성도가 높다고 할 수 있다.
이 레이아웃의 경우는 우선 쿼리를 중앙에 배치하고 탭으로 관리할 수 있도록해서 SQL 작성이 편하도록 했다. 또 개체 정보는 우측 개체 정보창에 원하는 만큼 모아둘 수 있게 하였다. 사실 세 번째 안이 정해지기 전에 어느 정도 프론트엔드 작업이 진행되고 있었기 때문에 많은 부분을 재작업 해야 했지만, React 컴포넌트를 재구성하기만해도 되는 부분이 있었기에 변경에 많은 시간이 필요하지는 않았다.
아직 세 번째 레이아웃에 대한 단점은 따로 언급하지 않기로 하겠다. 완벽하다는 의미가 아니라 우리가 선택한 레이아웃이 은하계에서 가장 잘 설계된 레이아웃이라고 생각해야 남은 개발이 즐거울 것 같기 때문이다.
다만 앞으로 더 나은 UI/UX를 위해 최선의 노력(기획/디자인팀에서 수 많은 실험과 고민을 해나가고 있고)을 계속해 나아갈 것이고 CHEQUER의 최강 프론트엔드 개발팀은 유연하게 변화를 수용하고 어떤 레이아웃이든 편리하고 아름답게 개발할 수 있다고 자신한다.
Ant Design 커스터마이징: Modal과 FormItem Validation
효율적인 Front-end 개발을 위해서는 잘 짜여진 UI Framework가 꼭 필요하다. 특히나 React 개발자라면 Framework의 중요성에 대해 다시 말할 필요가 없다. 하지만 세상에는 너무나 많은 UI Framework가 존재한다.
Framework로는 주로 Ant Design을 활용했는데, 이전 글에도 Ant Design에 대한 이야기를 한 적이 있어서 선택 이유에 대해서는 링크로 대체하기로 한다.
어쨌든 프로젝트를 시작하면서 자연스럽게 $ npm i antd 하고 시작했다.
한 동안은 본격적인 작업보다 준비 작업을 주로 했기 때문에 큰 문제가 없었다. 하지만 계획대로 될 리가 없었다. 디테일하게 변경해야 하는 부분이 생기고 문제를 해결하기 위해 많은 부분을 수정해야 했다. 겪었던 다양한 문제들 중에 AntD Modal Animation과 FormItem Validation에 관련된 내용들을 공유하고 싶다.
AntD Modal Animation; Slidedown
AntD Modal Animation은 사용자의 액션이 발생한 곳에서 시작하여 최종 목적지까지 점점 제자리를 찾아가는 방식이다. 이 애니메이션은 구현하려면 손이 많이 가고 어려운데, 이미 잘 만들어진 애니메이션이기 때문에 지금까지는 큰 불만없이 사용하고 있었다. 그런데 이번 프로젝트에서는 왠지 딴 생각이 들기 시작했다.
딴 생각은 VSCode에서 출발했다. VSCode에서는 사실 Modal이 없는 것과 다름 없지만 많은 UI 요소들이 위에서 아래로 슬라이딩 되고 있었다. 그러자 “슬라이딩 방식으로 변경 할 수 없을까?” 라는 생각이 들었다. UI/UX 측면에서도 애플리케이션에서 같은 기능을 하는 창이 항상 같은 곳에서 떨어진다고 기대하게 하는 편이 사용자에게 편안함을 줄 수 있다고 생각했기 때문이다.
이런 생각을 하게 된 또 다른 이유는 내가 아는 한 가장 디테일한 UI Framework가 이 정도 수준의 사용자 배려조차 하지 않았을리가 없다고 생각했다.
아마 어딘가에 Animation을 설정할 수 있을꺼야
AntD Modal의 API문서를 정독했다. 개발을 16년 넘게 하고 있지만 API를 정독하는 일은 늘 어렵다. 그런데 아무리 찾아봐도 Animation의 Ani도 없었다. 매우 난감한 일이었다.
힌트를 찾아야 했다. 일단 AntDesign 저장소를 뒤져봤다.
중국어로 달린 주석을 보면서 코드에 한글로 주석 달지 말아야 겠다는 다짐을 하게 된다. 하지만 주석은 역시 한글로 달아야 제 맛이다.
import Dialog from 'rc-dialog';그 결과 AntD Modal은 rc-dialog를 이용하여 작동한다는 사실과 transitionName이란 속성이 있다는 것을 찾을 수 있었다.
하지만 곧 내가 알아낸 사실들이 빙산의 일각에 불과하다는 것을 깨닫는다. React에서 animation을 사용하기 위해서는 애니메이션의 상태를 관리해야 하는데, 여기에는 여러가지 방법들이 있다는 것이었다. 예를 들어 ‘React animation’ 이란 검색어로 구글에 검색하면 수 많은 글이 있고 수 많은 라이브러리들이 존재함을 알게 된다.
그들 중 rc-dialog 라이브러리는 ‘react-transition-group’ (React팀에서 개발한)과 비슷한 작동원리로 개발되었다는 것을 파악했고, 따라서 CSS에서 ‘enter, appear, leave’의 class를 어디서 구현했는지 찾으면 된다고 생각했다.
그리고 어렵지 않게 찾을 수 있었다. Modal transitionName값을slidedown으로 정하고 less 파일에 위의 코드를 추가해주었다. transitionName으로 시작하는 각각의 상태에 해당하는 css class들을 재정의 해주니 아래 영상과 같이 Modal 등장 애니메이션이 변경되었다.
해결하고 나서 돌아보면 “참 별것 아닌 문제인데 고민을 했구나” 하게 된다. 하지만 역시 다양한 애니메이션 요소를 추가하기 위해서는 끊임없는 공부가 필요하다고 생각하게 된다.
AntD Form Item Validation
다음으로 해결한 문제는 파일 선택과 Validation 문제이다. AntD에서 Form을 만들고 FormItem값의 입력을 확인하기 위해서는 fileDecorator를 이용할 수 있다. 여기에서 rules 옵션을 추가해주면 form이 submit될 때, rule이 추가된 FormItem값이 비어 있는지 자동으로 체크해주고 편리하게 메세지를 출력해준다.
하지만 문제는 체크해야 할 입력도구가 일반 Input이나 Select가 아니라는 점 이었다. 여기에서는 파일을 선택하고 선택된 파일을 전송해야 하는데, file input은 그 디자인이 정말 마음에 들지 않았다.
그래서 별도의 FileSelect 입력도구 컴포넌트를 만들기로 했다.
FileSelect컴포넌트는 Button에서 click이벤트가 발생하면 참조된 input file엘리먼트에 click이벤트를 발생시켜주고, input file 엘리먼트에 change이벤트를 감지하여 사용자가 선택한 파일을 폼에서 사용하는 방식으로 개발했다.
이렇게 만든 FileSelector를 FormItem아래에 두고 onChange이벤트를 받았고, setFieldsValue를 이용하여 FileSelector에서 받은 값을 FormItem 값으로 전달하여 문제를 해결하였다. 파일 선택은 FileSelector 컴포넌트에서 처리하고, 입력값에 대한 존재 여부는 fieldDecorator가 담당하여 FileSelector 아래에서 마치 한 몸 인 것처럼 출력하게 해주었다.
맺음말
이렇게 QueryPie의 초기 레이아웃 발전 과정부터 Ant Design을 활용해서 Modal과 FormItem Validation을 어떻게 구현했는지 살펴보았다.
수 많은 어려움과 의사결정 과정을 거쳐 지금 새로운 애플리케이션 개발에 착수 하게 되었고 첫 스프린트를 마치고 이렇게 회고의 글을 쓰게 되어 매우 기쁘다. 앞으로 수 많은 스프린트를 쉼없이 해결해 나가며 원하는 목표를 달성해 나갈 것이다.
새로운 분야에 대한 도전은 언제나 설레고 즐겁다. 물론 그 과정 속에서 겪는 어려움들은 많지만 결과로 얻게되는 성취감은 중독성이 너무 강해서 일하면서 힘들었던 순간들은 모두 머리속에서 지워지게 된다.
오늘도 이런 생각으로 열심히 개발 중이고, 언젠가 QueryPie 프로젝트를 완성하고 회고의 글을 쓸 수 있는 날을 상상하며 첫번째 글을 조촐하게 마무리하겠다.
이어지는 개발기에서는 과거와 요즘의 트렌드를 살펴보며 애플리케이션 내 Resizing 및 Drag&Drop 구현 방법을 다뤄 볼 예정이다.
