Cloud Computing On Demand

node.js 를 사용하면서 가장 애를 먹는 것중 하나가 설치한 모듈을 찾지 못한다는 메세지를 만날때 입니다. 환경에 따라 모듈의 설치 경로가 달라질 수 있고, node.js 가 설치된 모듈을 찾아가는 순서에 영향을 받기 때문입니다. 간단한 몇 가지 명령을 통해 node.js 가 어떤 순서로 모듈을 탐색하는지 확인하고 글로벌 모듈로 설치된 경우 이를 명시적으로 node.js 가 이용할 수 있도록 알려줌으로써 어느정도 문제를 해결할 수 있습니다.

아래와 같이 npm 에서 -g 옵션을 이용하여 모듈을 설치하면 글로벌 모듈로 설치가 됩니다. 프로젝트에 관계 없이 설치된 모듈을 이용할 수 있어야 하는 것이지요. 일부 환경에서는 sudo 명령을 이용하여 관리자 권한으로 설치를 해야 할 수도 있습니다.

이렇게 -g 옵션을 이용하여 글로벌 모듈로 설치하는 경우, 그 경로는 어떻게 될까요? 아래와 같은 명령을 이용하여 글로벌 모듈로 설치하는 경우의 Path 를 확인할 수 있습니다.

간혹 글로벌 옵션을 이용하여 설치한 모듈을 찾을 수 없다고 나오는 문제를 겪고 있다면, 위의 명령으로 확인한 경로를 NODE_PATH 라는 환경 변수에 저장하여 node.js 가 글로벌 모듈을 찾을 때 참조할 수 있도록 명시적인 지정을 할 수 있습니다. 반복적으로 사용해야 하는 값이기 때문에 홈 디렉토리의 .bash_profile 파일에 포함하여 터미널 실행시 셋업되도록 하면 되겠습니다. 윈도 환경에서는 시스템 환경 변수에 넣어주면 됩니다.

글로벌 모듈 이외에 현재 프로젝트에서 모듈을 찾아가는 탐색 순서를 확인하려면 아래와 같이 간단한 자바스크립트 구문을 node.js 를 이용하여 실행해보면 됩니다. 아래의 경로로 모듈을 찾아본 뒤, NODE_PATH 에 지정한 경로까지 탐색하여 현재 환경에서 모듈을 찾고 이용하게 됩니다. 

- NoPD -

CentOS 환경에서 NPM (node package manager) 와 node.js 를 설치하는 방법을 정리해 봅니다. 환경 셋업을 자주 하지 않다보니 필요할때마다 겪는 시행착오를 줄이기 위해서 블로그에 적어둡니다 ^^;; 주기적으로 디지털 오션을 통해서 서비스 받고 있는 뉴욕 가상머신과 싱가폴 가상머신을 깨끗하게 정리하곤 합니다. 왠지 대청소를 하는 기분이라... 이렇게 해놓고 나면 바로 밀려오는 것이 패키지 설치에 대한 귀차니즘이죠.

간단한 테스트를 할일이 있어 DNS 셋업을 하고보니 가상머신에 아무런 패키지도 설치되지 않은 클린 설치라는 것을 발견했습니다. 이미지를 구워 놓아도 되련만, 그 이미지 조차도 왠지 찜찜해서 종종 하는 작업이 왠지 모르게 아깝게 느껴집니다. 오늘 정리하는 내용은 CentOS 에서 (버전은 6.7 입니다) yum repository 를 업데이트하고 nodejs, npm 을 설치하는 방법입니다.

yum 에 설정된 기본 repository 에는 nodejs 와 npm 이 존재하지 않습니다. 대신 epel repository 에 존재하는데요, epel repository 를 사용하기 위해서 위의 명령으로 epel 을 이용할 수 있도록 해봤습니다.

yum 명령으로 nodejs 와 npm 을 한번에 설치해 보겠습니다. 새롭게 준비한 epel repository 를 이용하기 위해서는 yum 옵션으로 --enablerepo=[repository이름] 을 지정해 주셔야 합니다. 위의 커맨드처럼 입력하시면 되겠죠? 약간의 시간이면 두 패키지와 종속된 패키지들이 모두 설치가 완료됩니다. 중간중간 인터렉티브하게 물어보는 질의에는 y 를 눌러주시면 됩니다. 

간편한 nodejs 버전 관리를 위해서는 n 을 설치해 주어야겠지요? 이제 npm 이 생겼으니 npm install -g n 명령으로 n 을 설치해 줍니다. 다른 지역의 가상머신과 node.js 버전을 맞춰주기 위해서 4.4.2 버전을 설치했습니다. 

간단한 테스트를 해보기 위해서는 node.js 의 핵심 패키지가 필요하겠죠. express 패키지가 그나마 익숙해서 요것까지 설치를 했습니다. 

- NoPD -

Node 의 새로운 버전이 릴리즈 되었습니다. Node 는 새로운 버전이 발표될 때마다 LTS (Long Term Support) 버전과 Stable 버전으로 나누어 공개하곤 합니다. 이번에 발표된 버전은 v4.4.2 (LTS) 버전과 v5.10.0 (Stable) 버전입니다. 아시는 분들은 아시겠습니다만 Stable 버전의 경우 이름의 뜻과는 달리 실험적인 기능들을 비롯한 덜 안정적인 기능들이 많이 들어간 버전이며 LTS 버전이 안정적인 버전이라고 생각하시면 되겠습니다.

Node 의 버전을 업데이트 하는 방법은 여러가지 있겠습니다만 개인적으로 추천드리는 방법은 n 을 이용하여 업데이트 하는 방법입니다. n 을 설치하고 사용하는 방법인 예전 포스팅에서 찾아보실 수 있습니다 (관련글 : http://ondemand.tistory.com/220) . n 은 여느 Node 패키지와 마찬가지로 NPM 을 이용하여 설치할 수 있습니다. 

간만에 또 한번 싱가폴에서 열심히 놀고 있는 서버에 접속을 했습니다. 업데이트를 하기 전 n 을 이용하여 현재 설치되어 있는 버전을 확인해 보았습니다. n 명령을 실행하면 현재 설치되어 있는 버전이 열거되며 활성화 되어 있는 버전은 특별히 밝은 색상과 o 표시가 되어 있어 식별이 쉽습니다. 

현재 설치되어 있는 버전이 두가지 이고 활성화된 버전은 4.2.4 로 확인됩니다. 새로 출시된 버전이 4.4.2 버전이니 n 명령을 이용해서 새로운 버전의 LTS 버전을 다운로드 받아 활성화 해보도록 하겠습니다. 명령은 무척 간단해서 n 뒤에 파라메터로 버전명을 기술해 주면 됩니다. 

약간의 시간동안 다운로드를 받고 설치하는 과정이 끝나면 준비 완료입니다. 다시 한번 n 명령을 이용해서 버전을 확인해보면 새로운 버전이 추가된 것을 확인할 수 있고 활성화까지 된것을 볼 수 있습니다. 느낌이 오셨겠지만 n 을 이용하면 현재 머신에서 어떤 버전을 활성화 해서 사용할 것인지도 쉽게 선택할 수 있습니다. 설치된 버전 목록에서 버전 넘버를 확인한 후, 다시 한번 n 명령 뒤에 해당 버전을 기술해 주면 됩니다. 저는 0.10.28 버전으로 다시한번 전환해 봤습니다.

네, 참 쉽습니다 ;-) 

2017.5.4 추가) 혹시 JSON 에서 주석을 어떻게든 써야겠다고 생각되시면 JSON5 규격에 대해서 살펴보시기 바랍니다 [바로가기]

고난이도의 알고리즘을 이용하여 프로그램을 만들다가도 가끔 멍~한 질문에 당황할 때가 있습니다. API 의 사용이 대중화되고 그 중요성이 커지면서 API 좀 다루어 보지 않은 엔지니어를 찾아보기 힘든게 요즈음입니다. API 는 초기에 SOAP 과 같은 오버헤드가 큰 방식들이 사용되다가 요즘은 JSON 형태의 경량화된 포맷이 사실상의 표준 처럼 사용되고 있습니다. 아, 물론 단순한 스트링과 델리미터로 값을 전달하는 경우도 여전히 있습니다만 가독성이나 주고받는 자료의 가독성, 관리 용이성 등의 관점에서 별로 좋은 접근은 아닙니다.

JSON 이 대중화되어 사용되다 보니 API 를 통해 리턴 받은 데이터이든 API 를 향해 던지는 데이터이든 습관적으로 JSON 포맷을 머릿속에서 이해하고 사용하고 있습니다. 그런데 오늘 문득... 그런 생각이 들었습니다. JSON 포맷에는 주석 혹은 코멘트(Comment)를 위한 표준이 정의되어 있는 걸까요? 만약 정의되어 있다면 어떤 형태로 사용해야 하는 걸까요? 이런 고민과 논란이 2012년 즈음에 있었던 것 같습니다. JSON 표준의 창시자로 알려진 더글라스 크록포드(Douglas Crockford)가 구글 플러스에 올렸던 업데이트를 인용해봤습니다.

글씨가 좀 작아서 잘 안보이시는 분들을 위해 본문만 다시 한번 인용해 봤습니다. 절대 블로그 포스팅 분량을 늘리기 위한 행동을 아닙니.......

I removed comments from JSON because I saw people were using them to hold parsing directives, a practice which would have destroyed interoperability. I know that the lack of comments makes some people sad, but it shouldn't. 

 

Suppose you are using JSON to keep configuration files, which you would like to annotate. Go ahead and insert all the comments you like. Then pipe it through JSMin before handing it to your JSON parser.

결론적으로 JSON 에는 주석 혹은 코멘트가 들어가지 않는것이 맞다고 창시자는 이야기하고 있습니다. 상호 호환성과 같은 시스템 간의 연동, 이종 시스템들간의 이해를 방해하지 않게 하겠다는 것이 의도인데요, 꼭 필요한 경우라면 코멘트를 사용하되 최종적으로 JSON 파서들은 코멘트가 제거된 데이터를 핸들링 할 수 있게 하는 것을 이야기하고 있습니다. 실제로 시장에 유통되고 있는 일부 JSON 파서 혹은 구현체에서는 JSON 코멘트를 허용하되 더글라스가 언급한 것처럼 최종적으로는 제거하는 케이스들도 있는 것으로 보입니다.

JSON 을 사용한다면, 조금은 아쉽지만, 주석 / 코멘트를 사용하지 않는 것이 미덕이겠습니다. 꼭 필요하면 내부적으로만 사용하시되 외부와 연동하는 단계에서는 꼭~ 제거하는 센스가 필요하겠네요! 

/* 추천도서 */ - API 설계 실무에 바로 적용하는 JSON [자세히 살펴보기]