알고보니 이미 필자가 블로그 용도로 애용하고 있는 GitHub 페이지에 DB같은 외부 의존성이 주렁주렁 안 달려있는 웹 애플리케이션 정도는 깔끔하게 올려버릴 수 있었다. 사실 아무리 필자가 서버 만지기를 좋아한다고 해도, 개인적인 작은 웹 서비스 하나를 위해 새로 물리적인 서버 (혹은 퍼블릭 클라우드)를 구축해 운영하는 것은 부담스럽다. 귀찮기도 하고, 비용 측면에서도 무시할 수 없기 때문이다. 이렇게 빛을 보지 못하는 코드들이 전세계 곳곳에 있을 터인데, GitHub 페이지 같은 서비스들이 정말 한줄기 빛을 내려주는 것 같다.

본론으로 들어가서, 필자는 create-react-app으로 제작한 간단한 웹 애플리케이션을 GitHub 페이지에 업로드할 것이다. 다른 도구를 사용해 앱을 제작하신 분들, 또는 다른 기술을 사용하시는 분들은 본인의 상황에 맞게 적당히 참고만 해주길 바란다. 먼저 본인의 프로젝트를 올릴 수 있는 GitHub 상의 저장소를 준비해 주셔야 한다. 이미 프로젝트를 GitHub에 올려두고 있다면 다음 단계로 넘어가자.

알맹이

먼저 내 프로젝트의 package.json 파일에 들어가 homepage 값을 추가하자. 아래와 같은 형태로 집어넣으면 된다.

"homepage": "https://<GitHub-유저명>.github.io/<프로젝트-저장소>"

그 다음 npm run build 명령어를 콘솔에 입력해보자. 아마 아래와 같은 출력값이 나올 것이다.

Creating an optimized production build...  
Compiled successfully.

File sizes after gzip:

 45.92 KB  build\static\js\main.bd9efe87.js
 289 B     build\static\css\main.9a0fe4f1.css

The project was built assuming it is hosted at /SithJS/.  
You can control this with the homepage field in your package.json.

The build folder is ready to be deployed.  
To publish it at https://<GitHub-유저명>.github.io/<프로젝트-저장소>, run:

 npm install --save-dev gh-pages

Add the following script in your package.json.

   // ...
   "scripts": {
     // ...
     "deploy": "npm run build&&gh-pages -d build"
   }

Then run:

 npm run deploy

package.json에 GitHub 페이지를 홈페이지로 사용한다는 정보를 넣었더니, 친절하게도 알아서 앞으로 어떻게 해야 하는지 과정을 설명해준다. 그럼 저항 없이 컴퓨터님의 목소리를 따라 앞으로 나아가 보자.

그런데 잠깐. gh-pages 명령어는 처음 보는데, 그냥 무시해도 되나? 당연히 무시하면 안된다. 컴퓨터님이 무리없이 명령어를 소화시킬 수 있도록, npm install --save-dev gh-pages 명령어를 얼른 콘솔에 입력해 미리 플러그인을 추가해 두도록 하자. (gh-pages는 웹 앱의 구동에 필수적인 플러그인이 아니니 --save-dev 명령어로 저장하면 프로덕션 빌드에서는 자동으로 빠져 편리하다.)

플러그인 추가도 마쳤으니, 다시 package.json을 열고 아래 스크립트를 추가해 보자. 위에서 친절하게 설명받은 그것이 맞다.

"deploy" : "npm run build&&gh-pages -d build"

짠. 이제 남은 것은 실행하는 것밖에 없다. npm run deploy 명령어를 콘솔에 입력해보자. 아까와 비슷한 출력값이 나오다 Published 와 함께 명령이 종료되면 정상적으로 업로드 된 것이다. 이제 웹 브라우저에서 https://<GitHub-유저명>.github.io/<프로젝트-저장소> 주소로 접속해보자. 본인이 방금 업로드한 그것이 정상적으로 나온다면 성공.

위 과정 후 내 GitHub 저장소에 들어가보면, 새로운 gh-pages라는 새로운 branch가 생겼고, 그 안에 구동 파일들이 잘 담겨 있을 것이다. 나중에 새로 deploy를 해도 이쪽으로 알아서 갱신되니 걱정하지 않아도 된다.

필자는 얼마 전 만든 divergence라는 간단한 웹 애플리케이션을 업로드했다. 이렇게 작동하니 참고할 것.

정말 말 그대로 모든 것들이 네트워크에 연결되기 시작하면서, 우리는 점점 전통적인 사무 공간에서 벗어날 수 있게 되었다. 개개인에 따라 크게 와닿지 않을 수는 있지만, 세상에는 디지털 노마드 라는 말이 유행할 정도로 건물숲을 뛰쳐나와 내가 원하는 공간에서 업무를 진행하는 사람들이 많이 늘어났다.

사실 꼭 디지털 노마드 운운할 필요도 없이, 집 근처 카페에만 가 봐도 노트북을 들고 업무를 보는 사람들을 쉽게 발견할 수 있다. 필자도 그런 부류다. 개인적으로 휴식하는 공간인 집과 무언가 머리쓰는 일을 하는 일터(물론 아직 필자는 백수다…ㅠ) 가 한 공간에 있으면 도저히 집중을 못하는 스타일이라 꾸역꾸역 돈 써가며 노트북 들고 카페라도 나가고 있다.

그런데 말이다. 카페 등의 공공장소에서 업무를 보고 있을 때, 단시간 자리를 비워야 할 경우 어떻게 할 것인가? 휴식이 되었던, 잠깐 전화를 받고 오던, 자리비움은 업무에 꼭 필요한 중요한 일이다. 그런데 카페나 도서관에서는 실행하기 영 어렵다. 내가 내 짐들을 두고 자리를 비웠을 때, 아무도 내가 언제 돌아오고 무엇 때문에 나갔는지 알 수가 없기 때문이다. 이는 곧 다른 이용객들의 눈치, 장소 관리인과의 불화, 심지어 개인 물품 도난으로까지 이어질 수 있다. 물론 카페나 도서관보다 사정이 낫다 뿐이지, 사무실에서도 머릿속을 텅 비우고 벌떡 일어나 룰루랄라 나갈 수는 없다. 언제 누가 나를 찾을지 모르기 때문에, 신경쓰이기는 마찬가지다.

그럼 어떻게 해야 하는가. 좀 더 편하고 효과적으로 이런 일을 해결하기 위해, 약간의 시간을 투자하여 장난감을 하나 만들었다. 이름하여 divergence 다.

divergence?

divergence는 잠시 자리를 비울 때 다른 사람들에게 내가 왜 나갔고, 언제 돌아오는지 알려줄 수 있는 웹 애플리케이션이다. 샤워하고 있는데 갑자기 떠올라서 한시간 끄적거려 만들었다. 이름은 이 글의 제목과 같이 ‘내가 자리를 비웠다는 것을 다른 사람들에게 발산하라’ 정도로 알아주면 될 것 같다. 쓸데없이 거창한 것 같긴 한데 원래 소프트웨어 개발자의 본 업무는 이름 짓기니까 뭐 그렇다고 쳐 줘라.

언제 있을지 모르는 자리비움 상태를 대비하기 위해 디바이스에 무언가 설치할 필요 없이, 필요가 있을 때 웹 브라우저로 접속하면 되니 편하고 깔끔하다. 같이 확보되는 기기 범용성은 덤이다.

접속했을 때 출력되는 입력창에 내가 무엇을 위해 자리를 비우는지, 그리고 언제까지 돌아올 것이지 입력하면 창 가득 자리비움 이유와 시간이 출력된다. 이 상태로 밖에 나갔다 오면 끝.

민감할 수 있는 데이터가 입력되는 만큼 애플리케이션 자체적으로 무언가 기록하고 저장하는 기능은 없다. 애초에 DB도 연결되어 있지 않고. 브라우저를 닫으면 그대로 세션도 닫힌다.

요즘 관심 가지고 만져보고 있는 React.js 기반으로 디자인했고, 가운데의 타이머 구현을 위해 npm에서 react-countdown-clock이라는 모듈을 하나 받아 사용했다. 개발자님 고마워용.

아직 누군가가 사용해줄지는 잘 모르겠다. 필자가 보기에는 괜찮은 것 같은데 남이 보면 또 어떨지 모르니까. 그래도 누군가는 좋아해주지 않을까 믿는다. 아무도 내 창작물을 사용해주지 않는다고 생각하면 앞으로 새로운 무언가를 만들 가능성도 0이 되버리니까 말이다.

• 더 자세한 기술적 내용은 divergence의 GitHub 저장소 에서 확인할 수 있다.

최근 글쓰기가 뜸했다. 인정한다. 여러모로 바빴다. 웹 애플리케이션 하나도 만들고 있고, 결과는 암담하지만 면접도 한번 보고 왔다. 슬슬 글 하나 정도는 써주지 않으면 영원히 쓰지 않을 것 같아 부랴부랴 올린다. 없겠지만 혹시라도 기다렸던 분들 있으면 미안하다.

왜 react-router v4 인가?

react-router로 페이지 라우팅 하는 법을 다루려면 그냥 react-router 라고만 적지, 왜 버전명이 같이 언급됬는지 궁금하신 분들 계실 거다. 결론부터 말하면 react-router v4와 그 이전 버전의 사용법이 많이 달라졌기 때문이다. 다시 말해, 잘 사용하던 코드를 v4에 그대로 끼얹으면 작동을 안 한다는 소리다.

말만 들어도 고통스럽다. 벌써부터 온몸이 아파온다. 그래도 이것이 지금의 JS다. 15년 전 홈페이지에 눈내리기 효과 넣어주던 ‘매크로’가, 하루가 다르게 새로운 기술이 나오고 파이썬, 루비 등과 어깨를 나란히 하는 활발한 스크립트 언어가 되었다. 몸 좀 아파도 끝없이 성장해나가는 JS를 위해 우리 좀 참아주자.

알맹이

아래는 기존에 사용되던 알맹이 코드이다.

<Router history={browserHistory}>
      <Header />
        <Route path="/" component={Main}>
            <IndexRoute component={Main}/>
            <Route path="auth" component={Auth}/>
        </Route>
    </Router>

나름 직관적으로 적혀 있어 React를 조금 만져보신 분들이라면 이해에 큰 어려움이 없을 것이라 생각된다. 처음 홈페이지를 접속했을 때(/) Main 컴포넌트가 뜨고, /auth 주소로 접속하면 Auth 컴포넌트가 뜨는 코드다. (browserHistory는 웹페이지에서 뒤로가기를 눌렀을 때도 전체가 새로고침 되지 않도록 도와주는 기능, IndexRoute는 웹페이지의 첫 화면을 정의해주는 기능이다.)

문제는 아까 말했듯 이렇게 열심히 작성한 코드가 최신 v4 버전에서는 깡통이 되어버린다는 것이다. 깡통이라는 표현이 절대 빈말이 아니다. v4 버전에 적용해보면 정말 아무것도 랜더링하지 못한다. 하얀 화면만 끝없이 펼쳐질 뿐이다. 숙련자들도 골치 아픈 문제지만, 특히 처음 React를 접한 분들에게는 더 치명적이다. 나는 분명 가이드 글에 맞추어 코드를 짰는데 아무것도 나오지 않는다. 으악.

이 글을 찾아오신 분들도 대부분 위같은 문제에 시달리고 있을 것이다. 그럼 더 이상 뜸들이지 않고, 위 코드를 v4에서 작동될 수 있는 코드로 변환해 보겠다.

<Router>
    <div>
      <Header />
      <Route path="/" exact component={Main} />
      <Route path="/auth" component={Auth} />
    </div>
  </Router>

짜잔. 비슷하면서도 조금 더 간결해지지 않았는가. 이전 버전에서 사용했던 페이지 전체 새로고침 방지 목적의 browserHistory는 더 이상 사용하지 않아도 되고 (역할이 많이 바뀐 것 같다. 자세한 것은 나중에 추가할 예정), IndexRoute 대신 exact를 사용해 첫 페이지를 정의해줬다.

마치며

react-router는 위 같은 간단한 페이지 라우팅을 넘어 훨씬 더 복잡하고 많은 일을 할 수 있지만, 이 글의 목적은 그 ‘간단한 페이지 라우팅’ 이였다. 가장 기본이 되는 기능이고, 또 없어서는 안될 기능이다. 지금까지 골머리 썩었던 분들이 도움을 받아갈 수 있었으면 좋겠다.

우리는 알게 모르게 오래 일하는 것을 미덕으로, 휴식을 죄악으로 생각하는 문화를 가지고 있다. 누구가 잠을 줄여 높은 점수를 맞았다는 이야기는 학창 시절에 꼭 들어보는 이야기다. 우리는 자라오면서 그렇게 교육받았고, 그렇게 생각하는 것이 몸에 배어있다. 그리고 이런 악습은 잠을 줄여 공부하던 학생이 성인이 되었다 하더라도 없어지지 않는다. 여전히 공무원 시험 등을 위해 휴식과 잠 대신 책을 잡거나, 취직을 하더라도 많은 경우 상습적인 야근 요구를 받는다. 결론을 한 마디로 말하겠다. 야근과 업무 효율성은 전혀 비례하지 않는다.

사람을 포함한 동물이 휴식을 취하고 잠을 자는 것은 다 이유가 있다. 누구나 아무리 편하게 지낸다고 해도 쌓이는 스트레스를 해소하고, 일일 처리 한계에 다다른 뇌를 슬립 모드로 넘겨 자료를 정리하고 찌꺼기를 걸러내야 한다. 그런데 이런 당연한 과정을 무시한 채, 단순히 오래 앉아 있기 = 오래 작업하기 로 생각하는 일부 몰지각한 고용주들이 끊임없이 만행을 저지르고 있다.

문제는 이러한 일이 깊은 집중력과 정신력이 필요한 IT 분야에서까지 그대로 벌어지고 있다는 뜻이다. 아니, IT 분야의 야근은 적어도 대한민국에서는 서로 떨어지지 않는 짝꿍 키워드다. 인간이 하루에 집중할 수 있는 시간은 대충 2~3시간 정도로 알려져 있다. 하루 정상근무 8시간을 한다고 해도 2~3시간 정도만 집중해서 작업할 수 있으면 그날 몫은 다 했다는 뜻이 된다. 나머지 시간은 수다떨고 멍때리고 간식 먹는 시간으로 쑥쑥 지나간다.

‘깊은 집중력과 정신력이 필요한 일’이 만드는 결과물이 과연 양으로 따질 수 있는 것인가? 아니다. 어디까지나 질이 가장 중요하다. 똥덩어리 코드 100줄보다 깔끔하게 동작하는 코드 5줄이 결국 훨씬 이득이다. 필자가 이전에 읽은 한 글에서는 ‘코드를 짜기 위한 야근’이 마치 ‘따뜻한 얼음’과 같이 모순되는 말이라고 했다. 정상 업무 시간동안 단순 반복 업무만 계속하라고 해도 힘들 것인데, 야근까지 하며 정신력을 소모하는 일이 절대 잘 돌아갈리가 없다.

그렇다고 당장 야근에 반대하며 파업에 들어가라는 것은 아니다. 우리는 힘없는 소시민이라 잘못하면 당장 생계가 위험해질 수도 있으니 말이다. 이 글의 요지는 야근이라는 행위 자체의 업무적인/개인적인 이득이 전-혀 없는 것을 다시 한번 자각하고 어떻게 하면 조금 더 실용적인 방향으로 업무 스타일을 바꿀 수 있을지 고용인과 피고용인 가리지 않고 고민해보는 시간을 가져보자는 것이다. 물론 그것이 가능했으면 진작 이 지경까지 오지 않았겠지만, 가만히 손을 놓고 있으면 영원히 바뀌는 것은 없다. 약간의 추진제 역할만 해준다고 해도 충분하다. 누군가는 당연한 것이라고 생각하지 않고 있어야 더 나은 방향으로 나아갈 수 있다.

어디서 한번쯤 들어보지 않았는가. “RESTful 한 웹서비스를 만들어야 한다.”, “우리 웹 애플리케이션도 REST를 고려하고 만들어졌나요?” 머릿속이 복잡해져 다시 REST가 무엇이냐 물어보면 우물쭈물 명확한 대답은 안 나온다. 자기들도 확실히 모르는 개념을 웹 서비스에 적용하라고?

진정하자. 지금부터 무엇인지 알아갈 것이다. 복잡할 것 없이 REST는 일종의 웹 서비스 설계 기준일 뿐이다. 가이드라인이 존재하고, 그것을 준수해 웹 애플리케이션을 만들었으면 그게 RESTful한 웹 서비스가 되는 거다!

쓰면 어디에 좋나요?

REST 아키텍처는 이미 전 세계에서 사실상 표준으로 자리잡았다. 다시 말해, 어떤 OS/브라우저를 사용하던 모두 커버할 수 있는 범용성이 보장된다는 소리다. 십수년 전에는 IE만 지원하면 장땡이였지만, 지금은 메이저 PC 브라우저도 훨씬 많고 심지어 모바일 환경도 존재한다. 이 많고 많은 환경을 일일히 따로 설계해 지원할 것인가? 별로 좋은 생각은 아닌 것 같다. 주민등록 주소지를 회사 사무실로 새로 신고해야 할 수도 있다.

REST 가이드라인을 따르면 위와 같은 참사를 피할 수 있다. 내 시스템 디자인을 명확하게 확립할 수 있게 해주고, 여러 기기에서 모두 사용할 수 있는 범용성도 보장할 수 있다. 나머지 이점들은 아래 특징들과 함께 살펴보도록 하자.

특징

위키피디아의 REST 문서를 살펴보면 이것저것 외계어가 적혀 있다. 물론 전부 알아두면 좋지만, 당장 끌어올 뇌 리소스가 부족한 분들은 아래 핵심 개념 2가지만 살펴봐도 충분하다.

URI는 직관적, 그리고 의미 중복 없이 정보(자원)을 가르켜야 하고, 모든 상호작용은 HTTP 메소드를 사용해야 한다.

먼저, 맨 앞의 ‘URI‘는 ‘URL’의 오타가 아니다. URI는 URL을 포함하는 상위 개념 정도로 보면 된다. 기존 우리가 알고 있던 URL의 역할처럼, 온라인 상의 무언가를 가르키는 주소다. 예를 들어, https://www.google.com 은 URI이면서 URL이다. 아직까지는 이해가 잘 안될 것인데, 다른 예시를 하나 더 가져와 보겠다. https://www.google.co.kr/search?q=uri 주소의 /search 까지가 URL, 그리고 ?q=uri(쿼리스트링) 부분은 ‘URN‘이다. 외계어를 하나 더 꺼내와서 미안하다. URN도 마찬가지로 URI의 하위 개념 중 하나이다. 그리고 방금 예시로 보여준 주소처럼, URL + URN = URI가 되는 것이다. 조금 빙 돌아온 느낌이 없잖아 있는데, 대충 URI가 무엇인지 느낌이라도 알았다면 성공한 거다.

이제 뒷부분을 보자. ‘모든 상호작용은 HTTP 메소드를 사용해야 한다’ 라고 했는데, 여기서 ‘HTTP 메소드‘는 어쩌면 익숙할 수도 있는 GET, POST, DELETE 등을 뜻한다. 여기서 일일히 메소드들의 종류를 전부 나열하지는 않겠다. 대신 위 링크에 들어가 자세한 메소드, HTTP 응답 코드 등을 살펴보길 바란다.

아래 RESTful한 HTTP 메소드 예시는 이곳을 참고했습니다. 작성자님 감사합니다.

아래는 바람직하지 않은 글 목록에서 5번 글을 받아오는 GET 메소드 예시이다.

GET /posts/show/5

영 좋지 않다. HTTP 메소드 GET은 이미 정보 검색을 서버에 요청하는 기능을 담고 있는데, 또 URI에 show라는 동사를 넣어 ‘보여준다’ 라는 의미를 중복시킬 이유는 없다. 위 URI는 아래처럼 수정할 수 있다.

GET /posts/5

깔끔하고 좋지 않는가? 직관적이고 의미 중복도 없어졌다.

마치며

“엥? 이게 끝이야?” 라고 물어볼 수도 있을 거다. 예. 끝입니다. 이 글의 취지는 REST 라는 개념을 이해하는 것이였지, 어떻게 당장 웹 애플리케이션을 RESTful하게 짤 수 있는지에 대한 글은 아니다. 어쩌면 나중에 다룰 지도 모르겠다. 그때가 되면 이곳에 링크를 달아 두겠다. 필자처럼 웹에 무한한 매력을 느껴 새로 홀려버린 분들을 위한 글이였다.