728x90
새로운 언어나 개발환경에 익숙해 지는데에는 간단한 실습만한 것이 없다. Hello World 를 출력하는 프로그램이 모든 언어의 첫번째 예제가 되는 것은 다 이유가 있다. Hello World 를 출력하는 프로그램을 통해 언어가 가지고 있는 기본적인 코드 구성 방법을 이해할 수 있고 표준 입출력을 이용하여 결과값을 출력해 볼 수 있기 때문이다. 

node.js 역시 마찬가지 방법으로 접근을 해보고자 한다. 다만 javascript 에 익숙치 않은 사람들을 위하여 점진적으로 코드를 완성해 나가는 방식을 이용해 앞으로 설명을 하고자 한다. NoPD 역시 OOP 기반의 언어들에 익숙한 상태라 처음 javascript 에 익숙해 지는데 시간이 무척 오래 걸렸다. javascript 가 궁극의 개발 언어라고 주장하는 사람들은 이런 javascript 의 코드 개발 방식을 들기도 하니 유심히 살펴볼 필요도 있을 것 같다


자바스크립트로 서버를 만든다고?

node.js 는 서버 혹은 클라이언트에서 사용될 수 있는 스크립트임을 앞선 포스팅에서 이야기 했다. 클라이언트야 그렇다 치고 서버에서는 도대체 무슨 역할을 할 수 있는 것일까? node.js 는 로직을 가지고 있는 javascript 로서의 역할도 충분히 하겠지만 그 보다는 웹 서버, 소켓 서버 등의 역할로 사용되는 경우가 더 많다. 서버에 설치된 웹 서버 (예> IIS, Apache) 의 유무와 상관없이 독립적으로 동작이 가능하다.

웹 서버라는 것이 결국은 특정한 포트 (예> 80) 를 통해 TCP 통신을 받아들일 수 있도록 해주는 역할이라고 해석한다면 소켓 서버를 특정한 포트로 만드는 것과 별반 다른 것이 아니라는 점을 이해할 수 있을 것이다. 이제 간단한 웹 서버를 만드는 코드를 통해 node.js 의 구조를 이해하고 얼마나 생산성 높은 개발 환경인지를 알아보도록 하자.

var http = require('http');

먼저 위와 같이 코드를 입력해 보자. var 는 자바스크립트에서 변수를 선언할 때 사용되는 키워드이다. http 라는 변수를 선언하고 이 변수에는 require('http') 라는 문장을 통해 node.js 의 http 모듈의 객체 인스턴스를 생성하도록 했다. node.js 은 다양한 모듈을 가지고 있는데 모듈을 사용하기 위해서는 위와 같은 코드를 이용한다. 다른 언어에서 include 나 using, import 와 같은 역할을 한다고 보면 된다.

코드의 구조를 잡아보기

객체 인스턴스를 생성했으면 이제 이 인스턴스가 제공하는 다양한 메소드를 이용하기만 하면 된다. node.js 의 서버 모듈이 제공하는 다양한 메서드와 이벤트는 공식 웹사이트의 도움말을 참고하면 좋다 (바로가기 :  http://nodejs.org/api/http.html) 우리는 일단 간단한 웹 서버를 만들어 볼 예정이니 문서가 제공하는 방대한 내용을 다 이해할 필요는 없다. 이제 코드에 살을 좀 붙여보자.

var http = require('http');

http.createServer(function (request, response) {

});

생성한 http 인스턴스가 제공하는 createServer 메소드를 호출하는 코드이다. createServer 메소드는 파라메터로 requestListener 를 받는다고 공식 문서에 정의되어 있다. requestListener 는 특별한 것은 아니고 공식 문서에도 기술되어 있는 것처럼 request 이벤트의 이벤트 핸들러 형태를 따르는 함수면 된다. 그런데 이 서버는 어떤 포트를 통해 요청을 받을 것인지가 명시 되어 있지 않다. http 객체가 제공하는 listen 메소드를 이용해 1234번 포트로 요청을 받는 서버를 만들어 보도록 하자.

var http = require('http');

http.createServer(function (request, response) { 

}).listen(1234);

참 간단하다. 이제 이 코드에 우리가 추가해야 할 것은 요청(request) 가 들어 왔을 때 무엇을 회신(response) 할 것이냐이다. 웹 서버라는 것이 별 것은 아니고 사용자의 요청이 들어왔을 때 적절한 회신을 해주는 것임을 생각해 보면 이해하기는 어렵지 않다. 회신할 내용을 만드는 코드를 넣고 서버가 동작중임을 알리는 콘솔 메세지를 추가해보자.

var http = require('http');

http.createServer(function (request, response) {
  response.writeHead(200, {'Content-Type': 'text/plain'});
  response.end('Hello World~!\n');
}).listen(1234);

console.log('Server running at http://127.0.0.1:1234/');
결과 확인해 보기! 

어렵지 않게 웹 서버를 무사히 만들어 냈다. 물론 진짜 웹 서버에 비하자면 동적인 웹 페이지의 생성, 적절한 결과의 응답등이 빠져 있지만 이런 부분들은 앞으로 여러 포스팅을 통해 다양한 모듈을 활용하여 풀어나갈 수 있는 부분이니 여기선 구조를 이해하는 선이면 충분할 것 같다. 이제 node.js 에서 만든 코드를 실행해 보도록 하자.  

 
서버가 동작중임을 알려주는 메세지가 화면에 출력되어 있다. 기본적으로 createServer 는 별도로 종료하지 않는한 계속 구동되고 있게 된다. 서버를 종료하는 별도 로직을 추가하거나 (특정한 요청에 응답?) Ctrl-C 등을 눌러 프로세스를 종료 시키면 서버는 종료되게 된다. 물론 서버가 종료되면 안되는게... 기본 동작 요구사항일 것이므로 그냥 그렇다고만 알고 있자. 이제 웹 브라우저를 이용하여 웹 서버에 접근을 해보도록 하자.


놀랍지 않은가? 단 몇줄의 코드로 웹 서버를 구동시켜 보았다. 앞서 이야기 한 것처럼 보완할 부분이 많은 말 그대로 껍데기 밖에 없는 웹 서버이지만 node.js 의 원리를 이해하고 강력한 기능을 맛보기에는 충분한 예제였다. 앞으로 node.js 를 이용하여 재미있는 것들을 많이 만들어 나가도록 하자.


- NoPD -

 
728x90
728x90
CDN(Content Delivery Network) 는 그리 오래되지 않았지만 상당히 진부한 느낌을 주는 소재입니다. 아카마이(Akamai), 라임라이트(LimeLight), 씨디네트웍스(CDNetworks)가 전세계 CDN 시장의 대부분을 장악하고 있으며 이 구도가 참 오랫동안 깨지지 않고 있는 시장이기도 합니다. 

네트워크 전송망 자체의 속도가 점점 빨라지고 주고 받는 컨텐츠에 대한 압축이나 경량화 등에 대한 기술적인 진보가 많아지면서 예전에 비해 CDN의 중요성이 상대적으로 덜 중요한게 아니냐는 분들도 많습니다. 하지만 알게 모르게 이런 기술적인 진보의 이면에 CDN이 여전히 자리잡고 있으며 대용량 컨텐츠 전송이 필요한 산업들은 그 규모가 더 커지고 있는 중입니다.

Cloud CDN 과 기존 CDN의 차이는 뭘까?

결론부터 이야기를 하자면 Cloud CDN 과 기존 CDN 의 차이는 없습니다. 스트리밍이던 다운로드던 Cloud 라는 이름이 붙은 CDN 과 그렇지 않은 CDN 의 큰 차이는 분명히 없습니다. 그렇지만 Cloud CDN 은 Cloud 라는 단어가 가지는 여러가지 의미들 중 "Pay As You Go" 의 개념을 탑재(?)했다고 보면 적절하지 않을까 싶습니다.

기존 CDN 들이 대부분 대역폭(Bandwidth) 단위로 약정 계약을 하고 있기 때문에 계약된 대역폭을 다 쓰지 못하더라도 비용을 내야하는 문제가 있었습니다. 또한 대역폭을 초과하는 경우 다음 약정 단위로 증가하기 때문에 비용 증가의 폭이 부담스러울 정도였지요. 하지만 Cloud CDN 은 전송량(Transfer)에 근간하여 과금을 하기 때문에 알차게 비용 지불을 할 수 있는 장점이 있습니다.

고속도로 차선을 임대할 것인가 아니면 톨비만 낼 것인가? (http://www.thestar.com)

 
T cloud biz 의 Cloud CDN
 
국내 기업형 클라우드 시장은 통신사 중심으로 여전히 현재 진행형으로 만들어 지고 있습니다. CDN 도 마찬가지 인데요, 시장에 상품을 먼저 내놓은 것은 KT 입니다. KT 는 ucloud CDN 이라는 상품을 이미 런칭하여 시장에 내놓은 상태입니다. 조금 늦은 듯 하지만 SKT도 Cloud CDN 상품을 어제 출시해서 시장에서 일전을 준비하고 있습니다.


SKT 가 내놓은 Cloud CDN 의 장점 중 하나는 다양한 소스 출처(Origin)를 사용하여 CDN 서비스를 구성할 수 있다는 점일 것 같습니다. 일반적인 서버에 위치한 파일을 Origin 으로 사용할 수 있는 것은 당연하고 아마존의 스토리지 서비스인 S3 에 올려둔 리소스의 버킷(Bucket)을 사용할 수도 있습니다. 거기에 더하여 최근에 출시한 SKT의 S3 호환 스토리지 서비스인 이지스토리지(Easy Storage)의 버킷도 사용할 수 있어 유연함을 보여주고 있습니다.

Cloud CDN 은 어떻게 동작하는 것일까?

Cloud CDN 은 일반 CDN과 구동 원리가 동일합니다. 사용자는 CDN 관리자 화면을 통해서 CDN 을 통해 빠르게 전송하고 싶은 컨텐츠의 위치를 지정합니다. CDN 서버는 등록된 위치에 있는 파일 혹은 버켓의 리소스들을 국내 ISP 별 데이터센터에 위치한 서버(이걸 엣지 서버라 부릅니다)에 복제하게 됩니다.

복제된 각 리소스들은 고유의 CDN URL 을 가지게 되는데요, 이 CDN URL 을 통해 사용자가 접속을 하면 CDN 서버는 사용자의 네트워크, 위치 등을 감안하여 가장 가까운 곳에 위치한 엣지 서버에서 리소스를 이용할 수 있도록 가이드를 해주게 됩니다. 이러한 원리로 CDN 은 사용자에게 빠른 속도로 컨텐츠를 제공할 수 있게 되는 것입니다

http://www.tcloudbiz.com

 
CDN 에 Cloud 라는 글자가 붙는 것에 대한 갑론을박은 참 많습니다. 하지만 Cloud 가 내포한 다양한 의미를 생각해 보면 Cloud 라 이름 붙이는 것도 그리 틀린 개념만은 아닌 것 같습니다. 아마존의 Cloud Front 에서 시작된 클라우드 서비스들의 CDN 전쟁은 이제 제대로 막이 오르는게 아닌가 싶네요~!

 
- NoPD - 
728x90
728x90
페이스북이 타임라인 (Timeline) 이라는 것을 발표한 이후 페이스북에 대한 관심이 더욱 높아지고 있습니다. 구글 플러스 출시 이후 빠른 기능 개선과 시장 발굴에 위협을 느낀 것일까요? 페이스북은 선두이면서도 변화의 보폭을 더욱 넓게 가져가는 느낌입니다. 시장은 역시 경쟁이 있어야 발전한다는 논리가 딱 어울리는 두 서비스가 아닐까 싶습니다.

페이스북의 인기 만큼이나 페이스북 앱 개발에 대한 관심도 높아지고 있습니다. 하지만 뭔가 접근하기 왠지 어려워 보이는 게 사실이었고 별다르게 개발에 대한 가이드나 책이 나온 것도 아니라 도전하는 사람만 많고 성과를 얻어낸 사람을 찾기 힘들었습니다. 그래서 준비했습니다. NoPD 스스로도 해본 거 없으면서 일단 준비했습니다 ㅎㅎ NoPD 의 시행착오와 함께 하는 페이스북 앱 개발! 지금 시작합니다 ㅋ

페이스북 개발자 페이지를 방문해 보자

오픈 API 의 제공과 개발자를 위한 도구 제공이 이제 웹 서비스의 기본이 된지 오래입니다. 페이스북 역시 개발자 페이지를 제공하고 있습니다. 주소는 http://developer.facebook.com 으로 페이스북에서 어플리케이션으로 만들 수 있는 것들과 어떤 어플리케이션이 있는지, 그리고 기타 여러가지 Open Graph 를 포함한 API 들에 대해서 다루고 있습니다.


크게 페이스북의 외부 인터페이스는 세가지로 나뉩니다. 1) 별도의 웹사이트, 블로그 등에 Plug-in, Add-On 방식으로 페이스북을 연계하는 방법 (Build for Websites), 2) 모바일 애플리케이션을 위한 인터페이스 (Build for Mobile), 3) 페이스북에서 구동되는 앱을 개발하는 방법 (Build Apps on Facebook) 이 바로 그것들 입니다. NoPD 는 우선 3번에 대해서 같이 알아보도록 하겠습니다. 시간이 되면 2번, 1번도...

페이스북 개발자 페이지의 Apps 메뉴

페이스북이 제공하는 세가지 중 빌트인 되어 구동되는 어플리케이션 개발이 아마 많은 분들이 가장 관심있어 하는 부분일 것 같습니다. 징가와 같은 게임 업체들이 제공하는 소셜 게임들도 다 이 방식으로 개발된 앱이라고 보시면 됩니다. 말은 복잡한데 인증만 공통 처리를 하고 필요한 소셜 데이터를 공유하면서 결론적으로 " 아이프레임 (iframe) 으로 웹 사이트 임베딩 하는 방식 " 이라고 보시면 됩니다. 참 쉽죠?

 
이곳으로 진입하기 위해서 개발자 페이지 상단의 Apps 라는 메뉴를 누르시면 됩니다. 이미 앱을 등록한 것들이 있다면 몇가지가 좌측 네비게이션 바에 떠오를 거구요 없다면 덩그러니 빈 화면과 위 그림에서 보이는 몇가지 버튼이 보입니다. 그 중 가장 구미가 당기는 Create New App 버튼을 한번 누질로 보겠습니다.  

만들기 위한 앱의 정보를 등록하자

앱을 만들기 위해서 가장먼저 해야 할 작업은 앱의 고유 ID 와 비밀키 (Secret Key) 를 받는 과정입니다. 페이스북이 제공하는 Open API 를 사용하기 위해서 호출자를 식별하고 향후 통계 작업을 위한 고유 ID 가 있어야 겠지요? 그리고 사용자의 인증과 데이터 트랜잭션을 하면서 정상적인 호출임을 파악하기 위한 토큰 (Token) 생성을 위해 비밀키를 알고 있어야 합니다. 앱 정보 등록 과정을 통해 바로 이런 정보를 만들 수 있습니다. 이해가 잘 안가신다면 그냥 " 그렇구나! NoPD 잘난척 하지 마라 재수없다! " 하고 넘어가시면 됩니다. 

 
여기서 부터 슬슬 저도 잘 모르는 부분들이 나옵니다. 친절하게도 You can update this later 같은 문구가 있어서 과감히 넘어갈 수 있었습니다 ㅎ. 사용자들이 앱을 사용할 때 화면에 표시되는 이름과 네임스페이스를 정하는 화면입니다. 제가 잘 모르는 네임스페이스는 나중에 다시 설명하도록 하겠습니다. 이름을 정하고 우리가 잘하는 개인정보 보호에 동의한다고 하고 Continue 를 누릅니다. 마음에 안들어도 동의 안하면 앱이 안만들어지니 무조건 동의하시기 바랍니다.

 
앱 자동 생성기가 있어서 뭐 할거냐 싶긴 하지만 친절하게 Captcha 점검도 합니다. 어려운 말이 나오면 Try different words 를 누르면 새로운 문자가 화면에 나옵니다. 실수로 an audio captcha 를 누르면 더 패닉상태에 빠질 수 있으니 주의하시기 바랍니다! 화면에 나온 문자를 입력하고 Submit 을 누르면 다음 화면으로 넘어갑니다.


어라? 그런데 화면이 넘어가지 않는다고 " 역시 NoPD 는 구라쟁이야! " 하시는 분들이 좀 보입니다. 무슨 문제일까요? 화면에 나온 영어를 자세히 읽어보면 답이 나와 있긴 합니다만... 혹시나 영어가 약하고 저처럼 귀찮아서 읽기 싫고 next, next 를 좋아하시는 분들을 위해 답을 드리자면, facebook, fb 와 같은 키워드는 앱 제목으로 사용이 금지되어 있습니다. 재빨리 다른 단어로 바꾸고 다시 보안 문자를 입력하면 오케이!


다음 화면을 가지 이제 뭔가 많이 나옵니다. 여기서 부터는 보안적으로 취급해야 할 것들이 많으니 주의 하셔야 합니다. 특히 최상단에 나온 정보들중 Secret Key 는 유출에 주의하셔야 합니다. 이 Key 는 페이스북 서버가 기억하고 있다가 우리가 만들 어플리케이션이 페이스북을 호출할때 사용하는 Token 을 위해 보안이 유지되어야 하는 Key 입니다. 그러면서 화면에 덩그러니 캡쳐해서 올렸다고 뭐라하실분 계시죠? 네, 화면 캡쳐하고 저는 Reset 을 눌렀습니다. 제 인생에 대박을 가져올 이 앱을 그냥 공개할 순 없겠죠 ㅋ Key 오른쪽에 Reset 을 누르면 key 가 재생성 됩니다만, 누르실때는 주의해야 겠죠!

자 일단 제가 아는게 여기까지라 포스팅은 여기서 마무리 하겠습니다. (응?) 다음 포스팅에서는 앱 설정 기능에 대해서 조금 살펴보도록 하겠습니다. 아는게 많이 없어 자세히 살펴보지는 않을 예정입니다. 쿨럭.

- NoPD -
 
728x90
728x90
프로젝트를 진행하다가 급하게 SMTP 서버를 구축하는 경우가 많습니다. 하지만 SMTP 서버로 사용할 자원이 없거나 다양한 이슈로 운영이 힘든 경우에는 외부의 메일서버를 사용하는 경우가 많습니다. 가장 대표적인 것이 구글에서 제공하는 SMTP 서버입니다. Gmail 계정만 있으면 사용할 수 있고 SSL 통신등도 지원하기 때문에 무척 사랑받고 있습니다.

그런데 Gmail 계정을 이용해서 smtp.gmail.com 을 사용하는 경우 문제가 하나 있습니다. 메일 헤더에 발신자(From)를 아무리 설정해도 인증을 받는 구글 계정으로 발신자가 표시되는 문제점이 바로 그것입니다. 한참동안 구글링을 하면서 해결 방법을 찾아보다가 너무 가까운 곳에서 해답을 찾았습니다. 같은 고민 하시는 개발자 분들을 위해 정리해 봤습니다.


Gmail 에 로그인 하신 다음 설정으로 먼저 들어갑니다. 설정의 여러가지 탭들 중 Accounts and Import 탭으로 이동해서 Send mail as 항목을 수정하는 것이 바로 해결책입니다. 기본적으로 gmail 계정이 등록되어 있는데 하단의 Send mail from another address 를 눌러 사용하는 이메일 계정을 추가해 주면 됩니다.

이메일을 추가한 다음 실제로 살아있는 정상 계정인지 확인을 위해 Verification 메일로 확인 코드를 전달해 줍니다. 해당 코드를 입력함으로써 이메일 추가가 완료됩니다. 이후 smtp.gmail.com 서버를 통해 메일 발송시에 새로 설정한 메일이 발신자로 기록되게 됩니다. 우측에 make default 버튼을 눌러서 꼭 default 로 설정하는 것 잊지 마시구요.

- NoPD -
 
728x90

+ Recent posts