리액트 네이티브에서 길 잃지 않기
슬기로운 앱개발 - React Navigation
리액트 네이티브는 웹을 만드는 언어인 자바스크립트와, 앱을 만드는 언어인 네이티브 언어(Objective C , JAVA) 사이에 일종의 브릿지를 두어 하이브리드 앱을 제작할 수 있도록 만들어진 프레임워크이다. 자바스크립트 언어로 특별히 약속된 문법규칙 몇가지를 지켜서 코드를 작성하면 디바이스 내부의 네이티브 언어로 변환되어 화면에 렌더된다. 리액트 프레임워크로 웹을 그리고 api 통신을 하는 방식과 크게 다르지 않지만 html 태그인 div, span 등을 사용할 수 없고 View, Text 등 리액트 네이티브가 가진 태그이름을 사용해야 한다. 이게 앞서 말한 '특별히 약속된 문법규칙'에 해당하는 부분이다.
이 새로운 태그이름에는 금방 적응할 수 있고, 모를 때마다 공식 문서를 찾아보면 된다. 오히려 신경써야할 부분은 내비게이션과 라우팅이다. 내가 원하는 페이지의 목록 사이에서 자유롭게 이동할 수 있는 네비게이션과, 특정 버튼을 터치할 때 다른 지점으로 이동시켜주는 라우팅을 미리 짜임새있게 만들어놓고 디버깅을 시작해야 시간낭비를 줄일 수 있다. 그리고 페이지를 쌓는 순서에도 신경을 써야 한다. 웹에 비해 모바일은 화면이 작다. 웹의 메뉴바가 길어져도 어떤 항목들이 있는지 금방 파악할 수 있지만 모바일에서 내비게이터를 열었을 때 곧바로 눈이 가는 항목은 많아야 세개 정도다. 사용자들이 자주 이용할 기능들, 연달아 이용할 기능들을 고려해 최적의 경로로 이용할 수 있도록 메뉴를 배치하는 것이 좋다.
내비게이터, 나침반
브라우저에서 디버깅을 할 때와 가장 큰 차이점은 '뒤로가기' 버튼이 없다는 부분이었다. 주로 크롬의 개발자도구를 이용해 웹개발을 할때에는 브라우저가 기본으로 제공하는 뒤로가기, 앞으로가기, 새로고침 기능을 이용할 수 있었기 때문에 내가 새로 만든 웹앱 내부에 버튼이 없더라도 뷰 이동에 제약이 크지 않았다. 하지만 모바일기기에서는 이러한 브라우저의 이점을 이용해 디버깅하기가 번거로웠다. 리액트 네이티브에서도 개발모드에서는 reload 기능과 debug 모드를 제공하지만, debug 모드 클릭시 크롬브라우저가 열리기 때문에 모바일 기기와 브라우저를 둘다 봐야하는 불편함이 있었다. 그래서 debug 모드는 콘솔내용을 확인하는 용도로만 사용하기로 했다.
효율적인 디버깅을 위해 가장 먼저 한 일은 react navigation 라이브러리를 이용해 내비게이션 작업을 하는 일이었다. 즉, 이정표를 만들어두어 페이지 이동을 자유롭게 만들었다. 좌측에서 메뉴가 나오도록 하려면 App.js 의 가장 바깥부분에 Drawer Navigation을 만들어 앱을 감싸면 된다. 엄지손가락으로 스크린을 왼쪽에서 오른쪽으로 스와이프하면 메뉴가 나타나기 때문에 메뉴의 구성순서와 스타일만 신경쓰면 된다. 각 페이지의 헤더는 직접 만들어서 사용할 수도 있고, 혹은 각각의 Navigation screen name을 지정해 자동으로 표시되도록 할 수도 있다.
만약 업무가 분담되어있어 일정 분량의 페이지들을 화면에 퍼블리싱하는 작업에만 집중해야 하는 상황이라면, Stack Navigator 로 페이지 리스트를 나열해두고 각 페이지의 스타일링 작업을 마친 후 나중에 연결을 할 수도 있다. 임시로 사용할 페이지 리스트 페이지를 만들어 일종의 홈 라우트로 이용하는 것이다. react navigation 라이브러리에서는 screen 에 해당하는 각각의 페이지들이 navigation 을 props 로 전달받는다. navigation가 가진 속성 중 이동 속성(push, navigate)을 통해 페이지 이동을 자유롭게 할 수 있다. 이동하려면 다음과 같이 버튼을 만들어 onPress 함수를 동작시키면 된다.
<Button
title="Go to Details"
onPress={() => navigation.push('Details')}
/>
Home , Detail 순서로 스크린이 쌓여있을 때 Home에 이 버튼을 넣어주면 디테일 페이지로 이동할 수 있다. 이는 navigation.navigate('Details') 로 바꾸어도 똑같이 동작한다. push 와 navigate 의 차이점은 동일한 라우트로 이동시킬 때 발생한다. 이 버튼을 Detail 페이지에 넣을 경우 navigation.navigate('Detail')을 onPress 로 가진 버튼을 누르면 아무런 변화가 없다. 그러나 push 속성을 가진 버튼을 누를 경우 Detail 위에 새로운 Detail 라우트가 스택으로 쌓이게 된다. 여기서 뒤로가기를 하면 Home 이 아니라 바로 앞단계에 쌓은 Detail 페이지로 이동하는것이다.
제플린 디자인시안, 지도
개발을 시작한 이후 지금까지 주로 제플린으로 디자인 소통을 해왔다. 정말 유용한 툴이다.
어떤 프로젝트든 그렇겠지만 리액트 네이티브 작업을 하면서 디자인 시안이 없이는 한치 앞도 나아갈 수 없다는 생각이 들었다. 리액트 네이티브는 모든 것이 이미 갖추어져있다. 물론 플러터처럼 모든 기능을 내장형으로 가지고 있지는 않지만 웬만한 필요한 기능은 공신력 있는 오픈소스 라이브러리의 도움을 받아 훌륭하게 구현할 수 있다. 우선, 리액트 네이티브는 컴포넌트 종류만 해도 굉장히 많다. 스크롤되는 ScrollView, 노치영역을 포함하지 않는 SafeAreaView, 윗줄 상태바의 색을 제어할 수 있는 Statusbar, 문자를 표시하는 Text 와 같이 목적과 용도를 고려해 세분화한 컴포넌트가 아주 많아서 별도의 기능구현 없이도 휴대폰 앱에서 필요한 기본적인 스크롤, 스와이프를 구현할 수 있다. 스크롤과 스와이프의 방향도 옵션설정이 간단하다. 여기에 React Navigation 를 설치하자 페이지를 뚝딱 만들고 다른페이지로 이동도 시킬 수 있게 되었다. 한마디로 React native 를 활용한 앱 제작은 어렵지 않다. 그렇기 때문에 더더욱 스타일링에 중점을 두어야 한다.
예쁜 디자인, 사용자에게 친화적인 디자인, 화려하고 신기한 다자인... 스타일 컨셉을 잡는 것은 디자이너의 몫인 것이다. 개발자로서 스타일링에 중점을 두어야한다고 말한 포인트는 개발을 할때 준수할 가이드 시안이 꼭 필요하다는 의미이며, 그것이 구체적일수록 개발의 효율과 즐거움이 최대화되고 어려움과 고민은 깊어진다는 데에 있다. 디자인 시안이 없으면 작업은 더뎌지고, 여러번 엎어진다. 리액트네이티브에서는 그게 더 심한 것 같다. 내비게이터가 나침반이라면 디자인 시안은 지도와 같다.
지도에는 없는 탐험의 영역
디바이스가 가진 자원을 활용하여 디자인대로 동작하도록 만드는 데에는 개발자의 고민이 필요하다. 가령 이러한 고민들이 있을 수 있다.
노치영역(스크린 상단의 파여있는 부분)을 헤더로 설정하고 SafeAreaView 로 화면을 렌더시킬 것인가, 아니면 View로 전체 스크린을 덮고 위쪽에 Padding 속성을 줄 것인가.
화면의 스택을 어떤 순서로 쌓을 것인가.
ScrollView로 화면스크롤이 가능한 경우 푸터 영역을 숨길 것인가. 또한 스크롤이 가능함을 넌지시 알려주기 위해 스크롤을 내려야 보이는 버튼의 일부를 미리 살짝 보이도록 할 것인가. 어느 정도? 10%? 20%?
세부적인 부분까지 미리 논의되고 디자인에 반영된 채 개발을 시작한다면 고민은 줄어들겠지만, 조심스럽게 말해보자면 내 생각엔 '세부적인 부분' 은 무한히 많아질 수 있는 것 같다. 세부의 세부, 세부의 세부... 이렇게 논의할 것이 끝도 없이 많아질 수도 있다고 생각하고, 그래서 어느 정도 선까지 기획과 디자인 논의를 한 후 제플린에 옮겨 개발을 하면서 개발자가 스스로 고민하거나 디자인 수정을 위한 회의를 하는 편이 더 좋다고 생각한다.
그래서 개발자는 디자인 시안을 지도삼아 나아가면서도 언젠가는 미지의 영역이 존재함을 염두에 두고 그 상황을 맞닥뜨렸을 때 당황하지 말아야 한다.
TMI.
노마드코더 니꼴라스가 플러터와 리액트 네이티브, asp.net 과 리액트 오픈소스생태계에 대해 비교와 분석을 하며 설명해주는 영상을 보았다. 설명을 참 잘해놓았다.
플러터는 구글에서, asp.net 은 마이크로소프트에서 미리 이것저것 다 만들어놓은 부속품들을 가지고 작업물을 만드는 것인 반면, 리액트 오픈소스 생태계에서는 어디에 소속되지 않은 사람들이 자유롭게 만들어둔 컴포넌트들을 설치해서 버그를 감수하며 (제작자가 고쳐주길 의존하며) 작업물을 만드는 것이다. 전자의 단점이라고 한다면 구글이나 마이크로소프트에서 갑자기 해당 플랫폼을 접을 수 있는 위험이 도사리고 있다는 것이다. 오픈소스는 생태계를 가진 언어나 플랫폼은 인기가 없어서 사라지더라도 천천히 이용자가 줄어들면서 점진적으로 사라질 테니 이보다는 위험이 덜할 수 있다.
하지만 계속해서 새로운 언어와 플랫폼이 등장하고, 이전에 공부하고 작업했던 기반이 있다면 적응을 못할 리가 없기 때문에 이러한 단점들이 정말로 단점이라고 생각하지는 않는다.
TMI2.
우리회사는 재택근무에 돌입했다. 분명 업무를 하고 있는데 거실 혹은 주방으로부터 집안일에 참여하라는 무언의 압박이 들어와 심리적, 물리적 어려움을 겪고 있다...^^
Photo by Martin Reisch on Unsplash
