Cloud Computing On Demand

요즘 가장 핫(Hot)한 개발 트렌드는 무엇일까? 사람에 따라서 가장 관심있는 개발 기술이 다를 것이기 때문에 어떤 것이 가장 관심을 받고 있다고 잘라 말하기는 애매하다. 하지만 일반적인 개발 생태계 전체를 놓고 보면 눈에 띄는 것들이 몇몇 있다. 마이크로소프트가 열심히 밀고 있는 윈도폰, 윈도8을 위한 메트로 스타일(Metro Style) 개발이 그 중 하나일 것이다. 스마트 디바이스를 위한 개발은 여전히 아이폰과 Objective-C 가 가장 뜨거운 관심을 받고 있다. 

그렇다면 웹 개발 영역에서는 어떤 것이 가장 핫한 개발 트렌드 일까? HTML5 나 CSS3 를 이야기 하는 사람들이 많을 것이다. 하지만 개인적으로는 그 보다도 자바스크립트, 더 정확하게는 node.js 가 사람들이 가장 관심을 많이 갖고 있는 웹 개발 영역에서의 아이템일 것 같다.

node.js 가 도대체 뭘까?

node.js 는 뒤에 붙은 접미사가 .js 라는 것으로 미루어 보아 분명 자바스크립트(JavaScript)와 관련된 무언가라고 추측할 수 있을 것이다. 그러면 혹시 jQuery 처럼 클라이언트 사이드의 자바스크립트 라이브러리일까? 그건 그렇지 않다. node.js 는 클라이언트에도 사용될 수 있지만 그것은 제공되는 기능의 일부일 뿐이다. node.js 가 만들어진 주 목적은 바로 서버측에서 구동되는 자바스크립트 개발 환경을 위해서이다.

 
많은 사람들에게 자바스크립트는 브라우저에서 구동되며 웹 사이트에서 다양한 클라이언트단에서 프로그래밍적인 요소가 필요한 상황에서 사용되는 클라이언트 사이드(Client-side) 언어일 것이다. 그런데 쌩뚱맞게도 node.js 는 서버에서 구동되는 개발 환경이라니 이게 무슨 소리인가 싶을지도 모르겠다.

이 글을 읽고 있는 사람이라면 ASP.NET, JSP, PHP 와 같은 서버 사이드(Server-side) 스크립트에 대해서 잘 알고 있을 것이다. 서버 사이드 스크립트는 서버에서 구동되어 동적인 컨텐츠를 만들어 내어 클라이언트(보통 브라우저)에게 전달하는 역할을 하게 된다. 컨텐츠 전달의 중간에는 웹 서버(Web Server), 웹 어플리케이션 서버(Web Application Server)가 있다는 것은 길게 설명할 필요가 없을 것이다.

node.js 를 요약해서 이야기 하자면 웹 서버 혹은 웹 어플리케이션 서버이면서 동시에 서버 사이드 스크립트의 역할도 하는 자바스크립트 기반의 서버 개발 환경이다. 어떻게 자바스크립트가 서버에서 구동되고 쓰이게 되는지에 대해서는 더 자세한 이야기를 기술해 놓은 곳들이 많으니 한번 찾아보면 좋을 것 같다. 중요한 것은 자바스크립트 엔진의 발달로 자바스크립트의 구동속도가 서버에서 쓰일 수 있을 만큼 빨라졌고 오히려 그 간결함과 익숙함, 효율성을 통해 생각치 못했던 더 많은 것을 할 수 있다는 것이다.


다음 포스팅에서는 node.js 를 윈도우 환경에서 직접 설치해 보고 간단한 샘플 코드를 통해서 node.js 를 통한 개발이 얼마나 쉬운지 한번 살펴보는 시간을 갖도록 하겠다.

- NoPD -

크로스 플랫폼에 대한 개발은 늘 개발자들의 로망이 되어 왔습니다.
같은 플랫폼 계열의 모바일, 데스크탑 어플리케이션 통합은 어느정도 가능했습니다.
윈도우 모바일과 윈도우 데스크탑은 Win32 혹은 .NET Framework 라는 공통분모가 있었죠.
최근에 각광받고 있는 아이폰과 맥 역시 윈도우의 그것과 비슷한 Subset + 알파 개념의 SDK 가 뒤에서 든든하게 지원을 해주고 있었습니다.

하지만 이기종 간의 개발은 어떨까요?
아이폰 앱을 개발하고 윈도폰 용으로 그대로 쓸수 있는 방법이 있을까요?
이제는 사람들의 관심에서 꽤나 멀어진 Delphi 가 재미있는 도구를 발표했습니다.
Delphi XE2 버전에서 이기종간의 크로스 플랫폼 개발을 하는 영상도 같이 공개 했습니다.

윈도우용 어플리케이션을 만들고 이를 맥으로 포팅할 수 있습니다.
맥용 어플리케이션을 만들고 이를 윈도우에도 쓸 수 있습니다.
물론 아이폰을 여기에 끼워 넣어도 됩니다.
일단 아래 동영상 보시고...

 

완벽한 이기종간의 크로스 플랫폼 개발은 아닙니다.
하지만 나름 리즈너블한 방법과 도구를 제시하고 있다는데 의미가 있겠네요.
개발 언어가 파스칼 계열인 것 같은데 (제가 델파이를 안써봐서 ;;;)
이 것에 대한 거부감만 없애면 간단한 시도들은 쉽게 할 수 있을 것 같습니다.

맥, 아이폰쪽 개발도 Xcode 에서 사용 가능한 형태로 Export 한 다음 다시 컴파일을 하는 과정이 있으니
앱에 대한 등록 심의도 큰 문제는 없어 보입니다.
다만 크로스 플랫폼을 지원하는 데 한계가 어떤것이 있는지는 한번 확인해 봐야겠지요 :-)

- NoPD - 

iBatis.net 을 사용하면 확실히 닷넷 코드 레벨에서 데이터베이스 관련하여 고민할 것이 많이 줄어들기 때문에 무척 좋습니다. Entity Framework 를 쓰면 얻을 수 있는 더 많은 잇점들이 있지만 간단하게 데이터베이스 엑세스에 대한 부분을 정리하고 간편화하는데에는 iBatis.net 이 훨씬 투입 공수가 적은 장점이 있습니다.

다만 iBatis.net 단에서 문제가 발생했을 때는 트러블 슈팅이 쉽지 않은편입니다. 오픈소스기 때문에 누가 책임을 져주는 것도 아니고 한번 내부적으로 처리된 에러 메세지들이 나오기 때문에 더 상세한 오류 원인을 찾으려 삽질하기 일쑤지요. 이번에 개발된 내용물을 클라우드 서버에 포팅하면서 겪은 문제 역시 마찬가지였습니다. 기록 차원에서 블로그에 정리해 둡니다.

에러의 시작, " Unable to open connection to ... "

로컬에서 MS-SQL 을 가지고 작업을 할때 아무런 문제가 없었던 로직. iBatis.net 의 장점을 십분 활용해 실서버 환경에서 provider.config 를 오라클에 맞추어 조정하면 가볍게 끝날것으로 생각했던 작업은 만 하루가 넘게 걸리고서야 해결될 수 있었습니다. 오래걸린 주요한 이유 중 하나가 바로 iBatis.net 가 추상적으로 던진 에러의 원인을 찾기 위함이었네요.

로컬은 32bit 개발환경이고 공교롭게도 처음 포팅했던 서버는 Windows Server 2003 32bit 버전이어서 더욱 오래 걸렸던 이번 에러. 두번째 포팅한 서버가 Windows Server 2008 R2 64bit 환경이었고, 여기에서 System.Data.OracleClient 네임스페이스에 매핑된 라이브러리가 32bit 냐 64bit 냐 때문에 발생하는 것이었습니다.  


비주얼 스튜디오로 빌드를 하면서 특별히 빌드 환경을 지정하지 않고 Any CPU 로 하고 있던게 화근이었습니다. iBatis.net 이 계속 에러를 토하는 과정에서 내부 에러를 살펴보니 아래와 같은 메세지를 내놓고 있었습니다. 기본적으로 iBatis.net 이 던져주는 Exception 의 Message 로는 확인이 되지 않는 부분이었습니다.


여러가지 해결 방법들이 제시되었고 가장 많은 것이 Oracle Client 를 환경에 맞게 재설치 하는 것이었는데 제가 전담하는 서버도 아니고 해서 그 방법을 쓰는건 너무 위험해 보였습니다. 그래서 x86 과 x64 로 빌드후 포팅을 해보기로 했는데, x86 으로 재빌드 하고 나서 아무런 문제가 없이 잘 수행되는게 확인 되었습니다.

혹시 비슷한 오류를 겪으시는 분들은 서버 환경에 따라 빌드 옵션을 다르게 주고 빌드한 다음 테스트를 해보시는 것을 추천해 드립니다. 이것 때문에 하루를 넘게 소비했다는 것이 참 어이가 없을 뿐입니다. 아무쪼록 누군가에게 도움이 되고 스스로에게도 언젠가 레퍼런스로 활용할 수 있도록 블로그에 글 남겨둡니다.

- NoPD -
 

지난 포스팅에서 Binary 버전으로 다들 NAnt 를 설치하셨나요? Binary 버전을 설치해도 되지만 NAnt 를 이용하는게 주 목적이라면 굳이 Source 를 받아서 컴파일 하실 필요는 없을 것 같습니다. 지난 포스팅을 보지 않고 오셨다면 아래 링크를 이용해서 NAnt 를 먼저 설치하고 오시는게 순서입니다 ^^

 
NAnt 가 빌드하는 원리는 별로 복잡하지 않습니다. 빌드 하고자 하는 프로젝트의 루트 폴더에 *.build 파일을 만들고 이 파일에 빌드에 필요한 함목들을 정의해 주면 됩니다. 앞으로 하나씩 살펴 볼 것들이 바로 *.build 라는 파일에 들어가야 하는 내용을 살펴보는 것이 목적입니다.

간단하게 구성된 소스코드를 이용해서 먼저 NAnt 를 이용한 빌드를 해보고 *.build 파일에 무슨 내용이 기술되어 있는지 살펴보겠습니다. NAnt 공식 다운로드 링크에서 2001년에 개발된 0.1.3 버전의 NAnt 를 이용해서 빌드를 한번 해보도록 하겠습니다. 최근 소스는 규모도 크고 빌드하는 시간도 많이 소요되니 간단한 걸로 먼저 보자는 것이지요!

 
 
다운로드 받은 소스코드를 임의의 경로에 풀어놓고 명령 프롬프트를 실행합니다. 해당 경로로 이동한 다음 nant 라고 치면 위의 화면과 같이 출력되며 빌드가 끝납니다. 참 쉽죠? 0.1.3 버전 폴더에 이미 NAnt.exe 가 있기 때문에 Path 로 열심히 잡은 버전이 실행된 것은 아닙니다. 첫줄에 NAnt.build 파일을 이용한다는 내용이 눈에 띄시죠?

 
바로 확장자 build 를 가진 파일이 빌드에 대한 정보를 담고 있는 파일입니다. 어떤 컴파일러를 사용해서 어떤 경로에 어떤 확장자를 가진 파일을 어떤 소스코드와 리소스를 이용해서 빌드할 것인지를 XML 형태로 기술한 파일입니다. 간단한 소스코드인 만큼 정말 간단한 내용이 들어가 있습니다.

 
빌드 경로에 정말 파일이 생겼는지 찾아가 보았습니다. 네, 잘 생긴게 보입니다. 디버그로 컴파일이 되었기 때문에 pdb 파일이 같이 생성이 되었구요, 실행파일 형태의 NAnt.exe 가 만들어진 것을 볼 수 있습니다. 요게 어떻게 보면 NAnt 의 가장 중요하고도 전부일 수 있는 내용인 것 같습니다. (파면 더 나오겠지만... 일단 크게 보자면 그렇다는 말입니다! ^^) 바로 저 XML 을 어떻게 만드느냐! 에 따라 빌드 자동화를 얼마나 훌륭히 수행할 수 있는지 판가름 날 것 같습니다.

- NoPD -