도움말 - 글감 수집하기 (인용)

도움말 - 부분 리뷰 작성하기

Meteor 프로젝트 생성과 React 설정

Meteor 프로젝트 생성

$ meteor create md-flow

 포스팅 시점(17.09.13) Meteor 1.5.2 버전의 meteor dependencies가 설치되고 다음 메시지가 뜬다. 

Created a new Meteor app in 'md-flow'.        
To run your new app:
cd md-flow
meteor
If you are new to Meteor, try some of the learning resources here:
https://www.meteor.com/tutorials
meteor create --bare to create an empty app.
meteor create --full to create a scaffolded app.

./md-flow 구조는 아래와 같다. 
tree -L 1 -a 명령어의 위대함을 찬미하며 살펴 보자.

.
├── client
├── .gitignore
├── .meteor
├── node_modules
├── package.json
└── server

상기 구조가 의미하는 바를 알아보기 전에 Meteor 프레임워크란 무엇인지 알아볼 필요가 있을 거 같다.

Meteor 프레임워크란 무엇인가?

라이브러리와 프레임워크

 건축을 예시로 들어보자. 집을 짓는다고 했을 때 시멘트와 물, 철근 등이 필요하다. 사실 우리가 사용하는 시멘트나 철근 등은 이미 누군가가 만든 기성품이다. 우리가 직접 시멘트와 철근까지 제작한다면,  우리는 짓던 집을 고분으로 설계를 바꿔야 할지도 모른다. 죽기 전에 완성 못할테니까.

 이렇듯 건축에서 건축가의 편의를 위해 이미 만들어진 재료나 기성품을 개발에 대입해본다면 라이브러리의 역할에 대해 감을 좀 잡은 것이다. 라이브러리는 개발자의 의도와 설계에 맞게 가져다가 쓸 수 있다.


  미리 만들어진 재료들을 가져다가 창문도 없고 문짝도 없이 단순히 벽돌만 쌓아올리고 시멘트를 바르는 식으로 단순한 집을 짓는다면 별다른 설계 지식이나 노하우 없이 건축이 가능할 것이다. 그런데 만약 수영장을 만든다면? 물을 채워넣기 위한 용적이며, 수도관 설치, 배수 처리를 위한 설계 등등 고려해야하는 부분이 많다. 이미 재료만 가져다가 뚝딱 뚝딱 짓는 수준을 아득히 넘어버렸다. 수영장 건설을 위해 치밀한 설계도를 그려야하고, 상하수도 사업소에 연락하여 물을 끌어오고, 또 배수할 방법까지 의논하고 계약하고 할 일이 태산이다. 다시 한 번 말하지만 이미 만들어진 수도관이나, 수영장 바닥 타일 등등의 소재만 갖춰졌다고 만들 수가 없는 것이다.

 이 때, 수영장 건설에 조예가 깊은 컨설턴트가 나타난다. 이 컨설턴트는 수영장 설계도도 지니고 있고, 이미 상하수도 사업소와 계약도 마쳐 자신이 물을 끌어오고 배수할 수 있는 권한도 가지고 있다. 게다가 자신이 즐겨쓰는 건축 자재들도 이미 구비를 해놓은 상태다. 이제 우리는 선택하는 것만 남았다. 일단 이 사람이 제공한 것들을 그대로 넙죽 받아서 수영장을 하나 먼저 만들어볼 것인지, 이 사람이 제공한 설계도와 재료들을 면밀히 분석해서 약간의 튜닝을 가하여 자신의 입맛에 맞는 수영장을 만들 것인지.

 여기서 말하는 컨설턴트는 일종의 수영장 건축을 위한 '틀과 규칙'을 제공해준다. 그 틀과 규칙 속에 얽매인 상태에서 우리는 수영장을 만들어야 한다. 그런데 이 틀과 규칙이란 굉장히 느슨할 수도 있고, 무척 빡빡할 수도 있다. 틀과 규칙이 느슨하다면 명시된 재료가 아닌 다른 재료를 가져다가 쓸 수도 있고, 설계도도 마음대로 수정할 수 있을 것이다. 빡빡하다면 그 반대가 될 것이고.

 바로 이 틀과 규칙을 개발에서는 프레임워크라 부른다. 프레임워크는 개발자가 고려해야하는 자잘한 것들을 상당 부분 해결해준다. 즉 알아서 상하수도 사업소랑 계약도 끝내고(예: 특정 DB와 연동) 내부 구조에 대한 설계도도 만들어놓고(예: 프레임워크 코어) 심지어는 간략하게 수영장 외관까지 대충 만들어둔 상태다(예: 예시로 제공하는 보일러플레이트 코드).
 이런 프레임워크에서도 개발자의 의도와 설계는 여전히 유효하다. 즉 프레임워크를 적용해서 프로젝트를 만들다고 수영장을 만드는 프로젝트가 갑자기 파스타 요리를 만드는 프로젝트로 바뀌는 건 아니라는 거다. 적어도 건축이라는 의도에 맞는 프레임워크를 도입하기로 했다면 말이다.


 물론 개발자는 프레임워크에 얽매인 상태이기 때문에 레스토랑을 만드는 프레임워크를 사용해서 레스토랑 요리를 만드는 프로젝트를 진행하는 것은 불가능하다. 여기서 불가능이 의미하는 것은 망치와 톱 등의 공구와 레스토랑 설계도를 가지고 치킨 스튜를 만든다는 의미로 보면 된다. 만들려고 한다면 결과물이나 소요되는 시간이 어찌되었든 만들 수는 있을 거란 이야기다.

 하지만 라이브러리는 가져다가 쓰는 것이기 때문에 개발자는 얼마든지 자유롭게 라이브러리를 가져다가 쓰면 된다. 레스토랑을 건축할거라면 시멘트를 가져다가 쓰면 되고, 치킨 스튜를 만들거라면 밀가루를 가져다가 쓰면 된다.


 이렇게 개발자가 가져다가 쓰는 라이브러리를 보통 개발자가 안는다 라고 말하고, 개발자가 얽매여있는 프레임워크개발자가 안긴다 라고 말한다. 주로 개발 커뮤니티에서 말하는 "내가 안으면 라이브러리이고 내가 안기면 프레임워크입니다."가 바로 그 뜻이다.


 그리고 틀과 규칙이 느슨한, 즉 유기성을 높혀서 다른 라이브러리와도 결합이 가능하도록 설계된 프레임워크라면 해당 프레임워크가 권장하는 라이브러리 외의 다른 라이브러리를 사용할 수도 있는 것이다. 수영장을 만드는 프레임워크에서 하얀 벽돌이라는 라이브러리를 가져다가 쓰라고 틀을 정하고 규칙을 정했는데, 개발자는 빨간 벽돌이라는 라이브러리를 가져다가 쓸 수도 있다는 이야기다. 어쨌거나 벽돌은 벽돌이기 때문에 별 문제가 없을수도 있고, 수영장물이 시뻘겋게 물드는 부작용이 생길수도 있다.

Meteor 프레임워크

 이제 Meteor 프레임워크가 대충 어떤 역할을 하는지 약간 감이 온다. 그런데 node.js 커뮤니티나 스택 오버플로우를 보면 종종 보는 질문이 있다.

 express.js 프레임워크랑 Meteor.js 프레임워크는 뭐가 다른가요?

 node.js 생태계에 대해 전혀 모르던 시절, 정말이지 넘쳐나는 자바스크립트 라이브러리와 프레임워크 때문에 진절머리가 났다. 범람하는 프레임워크와 라이브러리들의 용도와 관계를 짚어가기 위해서 위와 유사한 질문을 나도 제법 가졌더랬다.

 간단하게 위에 든 예시대로 이야기하자면, express.js는 수영장을 만들 때 상하수도 사업소와 계약하고 물이 어느 배관을 통해 어느 시점에서 흘러나오는지, 얼만큼 나오는지, 어떻게 배수로로 물이 빠지는지 등등 을 결정하는 프레임워크다. 수영장 외벽이나 바닥 타일은 뭘로 할 건지, 어느 수도꼭지를 조작해야 나오는지, 어느 탱크에 얼마나 물을 저장할 건지 이런 건 고려하지 않는다.

 그럼 이 관계를 리스트로 다시 써보자.

  • 상하수 시설과 배관 설계 및 물의 흐름 제어 => 서버 데이터 흐름 => 백엔드
  • 수영장 외벽이나 바닥 타일 디자인 => 디자인 => 웹 퍼블리싱
  • 수도꼭지 조작 => 사용자 반응에 따른 이벤트 처리 => 프론트엔드
  • 물탱크 저장 => 데이터 저장과 관리 => 데이터베이스

하나의 웹앱을 만든다고 할 때 가장 기본이 되는 구조가 이와 같다면, express.js는 바로 저 백엔드만을 다루는 프레임워크라고 보면 된다. 그리고 자바스크립트와 jQuery를 공부한 사람이 있다면 이렇게 이야기 해줄 수도 있다. 

node.js와 express.js의 관계는 (브라우저의 DOM 제어에 한해서) Javascript와 jQuery와의 관계

 그럼 Meteor.js는 무엇을 아우르는 프레임워크일까? 어마무시하게도 저 리스트에 있는 것 모두를 아우르는, 즉 백엔드, 프론트엔드, 데이터베이스, 웹퍼블리싱 전부를 관장하는 프레임워크다. 엄밀히 말해서 웹퍼블리싱은 기본으로 제공하는 패키지에서는 없다고 봐야 하겠지만.

 즉 Meteor.js라는 프레임워크는 서버 역할을 하며 흔히들 개발자들이 백엔드라 부르는 영역에도 영향을 미치고, 클라이언트가 받는 데이터나 사용자와의 조작도 관여를 한다. 게다가 minimongo라 부르는 자체 데이터베이스까지 가지고 있다.

 이런 이유로 Meteor.js는 풀스택 프레임워크라고 부른다. MEAN스택이나 MERN스택이라는 말을 들어봤는가? 바로 MongoDB + express.js + Angular.js 또는 React.js + node.js 조합으로 웹서비스를 구축할 때 사용하는 용어이다. 그런데 Meteor.js는 저런 조합을 생각할 거 없이 그냥 얘 하나로 다 된다. node.js를 중심으로 한 웹개발 분야의 페이커라고 보면 되겠다.

Meteor 프로젝트 구조

 서론이 길었는데, 다시 앞서 생성한 Meteor 프로젝트의 디렉토리 구조를 보자.

.
├── client
├── .gitignore
├── .meteor
├── node_modules
├── package.json
└── server
  • client: Meteor 프로젝트에서 클라이언트의 제어를 담당하는 프론트엔드와 관련된 디렉토리
  • .gitignore: 버전관리로 git을 사용할 경우, 내용이 변경되어도 git에는 반영하지 않을 목록을 가진다
  • .meteor: Meteor 프레임워크의 코어와 npm packages가 아닌 Meteor Packages를 관리하는 디렉토리
  • node_modules: npm dependenices가 저장된, 즉 npm으로 관리하는 node.js 관련 모듈이 저장된 디렉토리
  • package.json: npm dependecies를 관리하기 위한 일종의 setting 값이 저장된 문서
  • server: Meteor 프로젝트에서 서버와 데이터를 주고 받기 위해 백엔드와 관련된 디렉토리.

여기서 npm packages가 의미하는 건 npm으로 관리가 가능한 패키지들을 이야기 한다. 이 패키지들은 다음 명령어로 설치가 가능하다.

$ npm install --save react react-dom

 반면에 Meteor packages가 의미하는 것은 meteor 명령어로 관리하는 패키지이다. 이 패키지들은 다음 명령어로 설치한다.

$ meteor add react-meteor-data

 사실 npm 패키지들도 다음 명령어처럼 meteor를 사용하긴 한다.

$ meteor npm install --save react react-dom

 그런데 meteor가 제공하는 npm 버전이 심히 낮은 관계로, 나는 그냥 최신 npm을 사용하기로 정했다. 참고로 npm 5버전이 꽤나 불안정하다고 하니 패키지들이 꼬이거나 맛탱이가 가는 걸 방지하고 싶다면 meteor npm을 쓰는 것을 추천한다. 난 무조건 최신 버전을 써야만 밤에 잠을 잘 이루는 타입이라 아무래도 안 되겠지만.

React 라이브러리

 Meteor 프레임워크에 대해 말이 많았는데, 그렇다면 이 프로젝트에서 프론트엔드로 사용하기로 했던 React는 라이브러리일까 프레임워크일까?

 당연히 라이브러리이다. 왜냐면 내가 이미 라이브러리라고 제목에 써놨으니까(...) 그럼 제목에다가 라이브러리라고 쓴 이유는 무엇이냐고? 당연히 공식 React github에서 React를 다음과 같이 라이브러리라고 소개하고 있기 때문이다(...)

근데 사실 잘 들어갈 일 없는 곳이다. 공식 문서로도 충분하기 때문.
A declarative, efficient, and flexible JavaScript library for building user interfaces

 따라서 React는 라이브러리이다. 라이브러리임 아무튼 라이브러리임.

 +  조금만 썰을 더 풀어보자면, 단방향 데이터 흐름을 가지는 React는 단순히 View만 관리한다. Routing이라든가, Flux 아키텍쳐를 구현한 Redux를 조합하여 Model과 Controller 역할 또한 수행 가능하지만, 해당 라이브러리를 조합했을 때 가능한 이야기지 순수 React만으로는 View만을 담당하는 라이브러리로 봐야 한다고 한다.

Meteor와 React

 어쨌거나 Meteor는 풀스택 프레임워크이고, React는 View를 관리하는 프론트엔드 라이브러리라고 했을 때, 둘을 조합한 웹앱이 의미하는 바는 다음과 같다.

 Meteor의 프론트엔드 부분을 React 라이브러리로 대체한 웹앱

 Meteor의 프론트엔드라고 하면 아까 Meteor 프로젝트 구조에서 client 디렉토리에서 이루어지는 작업을 떠올릴 수 있을 것이다.

 즉, 이 client 디렉토리에 React 프로젝트를 만든다고 생각하면 좀 더 이해가 쉬울 것이다.


 원래 React 프로젝트는 초기 설정에 손이 많이 가는 편이었다. ES6 문법을 사용할 경우 webpack에 babel 설정을 해줘야 하고, React 코드를 수정했을 때 변경된 코드를 반영시키려고 빌드를 수작업으로 해줄 게 아니라면 빌드 자동화를 위해 hotloader도 설정해줘야 하고, webpack이 버전별로 사용법이 달라진 터라 자신이 사용하는 버전에 맞게 webpack 사용법도 숙지하고 있어야만 한다.
 이런 귀찮은 작업들과 코드들을 보일러플레이트 코드들이라고 하는데, React는 그 보일러플레이트 코드가 유독 심한 편이다. 그래서 결국은 React의 초기 설정을 알아서 해결해주고 오로지 React 자체의 문법과 논리에만 집중하면 되는 create-react-app 이라는 것도 나왔다.

 하지만 Meteor에서는 그런 걸 전혀 신경쓰지 않아도 된다. 그냥 필요로 하는 React 패키지만 설치해서 client 디렉토리에 component들을 만들기만 하면 된다.

React 설치

.
├── client
├── .gitignore
├── .meteor
├── node_modules
├── package.json
└── server

 위 구조에서 client 디렉토리를 삭제한다.

$ rm -rf client
.
├── .gitignore
├── .meteor
├── node_modules
├── package.json
└── server

그럼 다시 client 디렉토리를 만들고, 안에 main.js와 main.html 을 만든다.

$ mkdir client && touch ./client/main.html ./client/main.js

해당 client 디렉토리는 알맹이는 텅빈 main.html과 main.js를 가지고 있다. 지금 당장 코드를 채워넣고 싶지만, 일단 React를 설치해야 한다.

>= npm5

$ npm i react react-dom

< npm5

$ npm i --save react react-dom

React 설정

document.querySelector가 main.html의 render-target 클래스를 찾아서 App 컴포넌트를 해당위치에 렌더링한다.

위 코드에 대한 자세한 설명은 생략한다. 주석도 달아놨으니 특별히 설명을 덧붙여야 할 요소는 없으리라 생각한다.

main.html 과 main.js를 위와 같이 작성했다면 저장하고 다음 명령어를 입력하자.

$ meteor
[[[[[ ~/Coding/md-flow ]]]]]                  
=> Started proxy.
=> Started MongoDB.
=> Started your app.
=> App running at: http://localhost:3000/

http://localhost:3000/ 로 접속해보면 다음 문구를 볼 수 있다.

Hello, Meteor & React

이상, Meteor에 대한 설명과 React 설치 및 설정에 대해 마무리 짓는다.

+ 참고로 실행시킨 meteor를 종료하려면 Ctrl+C를 눌러주자. 보통 어느 서버든 종료할 때는 해당 키로 종료가 가능하다.

리뷰
포스팅 시점(17.09.13) Meteor 1.5.2 버전의 meteor dependencies가 설치되고 다음 메시지가 뜬다. 

ㄹㅇㄴㅁㄹㅇㄴ

ㅇ아러ㅣㅏ어ㅏㄴㅇ