이 메마르기 그지 없는 사막에서, 당장의 갈증을 덜어줄 물 한 모금 되지 못하는 먼 오아시스 얘기는 그저 신기루와도 같다. 소프트웨어 기술의 즐거움과 향기에 대하여 목청 껏 외칠 수 있으리라 기대했던 곳 역시, 사막 한 가운데 놓인 조그만 천막에 지나지 않는 다는 엄연한 사실을 미처 알아보지 못했다.
새로 나오는 Visual Studio 2010에는, 어쩌면 ML의 .NET 판이라고 할 수 있는 F# 언어가 정식으로 포함되어 있다. 사실 이런 ML 류의 언어들은 산업에서 이미 확고한 자리를 잡았고, 소프트웨어의 안전성과 성능이 중요한 분야부터 서서히 그 쓰임새를 다져가고 있다. 하지만, 이 나라 이 바닥에서 이런 얘기를 했다가는 “오따구”나 “매니아” 취급 받기 쉽상. 어이가 없지만 내가 일하는 이 곳에서도 그 다지 반응은 다르지 않다. 슬프지만 현실은 현실, 생각보다 사람들은 “기술 그 자체”를 알고 싶어 하지 않는다. 그리고 먹고 사는 문제와 좋아하는 것이 하나가 되는 순간, 대부분의 경우에 우리는 더 이상의 즐거움만을 좇아 자유로울 수 없다.
하지만 그래도 오아시스는 있다. 그리고 우리가 현실에 허덕이는 사이, 이 바닥의 운 좋은 몇몇은 수십년도 전에 그 곳을 찾아내어 선구자로서 고생한 댓가를 톡톡히 누리고 있다.
“Programming in Haskell (하스켈로 배우는 프로그래밍)”. 좋은 책이다. 이 책의 추천사는 내가 썼다. 같은 공을 들일 것 같으면 좀 잘 팔리는 이야기에 이름 석자를 얹어야 할 터인데, 나에게는 꼭 이런 주제들만 인연이 된다. (이 책을 옮겨 쓴 이들과는 인연의 깊이가 적지 않다. 한 사람은 내 후배이자 제자고, 다른 한 사람은 1990년 말 경에, Newsgroup에서 C++와 Functional Programming로 얘기를 나누다가 알게된 동지다. 이 사람은, 2005년부터 포틀랜드 주립대학에서 하고 싶은 공부를 열심히 하고 있다. 박복한 내게는 너무 부러운 일이다.)
하필이면, 내가 꼭 추천사를 써야하는 까닭을 물었더니, MIT의 저명한 프로그래밍 교과서 “컴퓨터 프로그래밍의 구조와 해석 (Structure and Interpretation of Computer Programs, SICP)”이라는 책이 번역되어 출간되는 것을 보고 용기를 얻어 시작했으니, 내가 적임자라는 게다. ( SICP는 옮겨쓰는데 4년 이상이 걸렸던 책이자, 내 서른 중반의 열정을 담뿍 담았으되, 끝내 5장은 다른 분이 하셔야 했고, 그러고서도 마음에 들지 않아서 제대로 마무리 짓지 못한 미련을 버리지 못한 책. 그 무엇보다 쉬운 우리말로 써야 겠다고 고집을 부리는 통에, 여기저기서 숱한 뭇매를 맞았던 애증의 책이기도 하다. 그리고 중요한 사실. 이 책이 아무리 많이 팔려도 내게는 동전 한 푼 안 떨어진다. ^^;; )
저명한 수학자의 이름을 딴 이 하스켈 (Haskell)이란 언어가 Microsoft의 기술 연구 역사와 깊은 관계가 있다는 사실을 아는 이는 직원들 가운데서도 거의 없다. Microsoft란 회사의 이미지가 이런 기술 연구와는 거리가 멀다고 생각했던지 1998년에는 만우절 유머로 “Microsoft And Yale Conclude Agreement To License Technology For Haskell” 같은 글이 우스갯 거리로 인터넷을 돌아다니기도 했다. 그런데 황당하게도 이 사건은, 얼마 지나지 않아서 Haskell 관련 연구 공동체의 대가라 해도 과언이 아닌, Simon Peyton Jones가 Microsoft로 간다고 발표를 한 것이다. 그리고 정말 기사 내용대로 하스켈 언어로 COM 스크립트 쓰는 기술, Web Server Page 기술 들이 차례로 학계에 발표되기도 했다. 현재 Microsoft가 내놓고 있는 수많은 관련 기술들이 어느 날 하루 아침에 그냥 튀어나온 것들이 아니란 얘기다.
이 책의 추천사에 썼듯이, 오로지 재미로 이 기술을 즐길 수 있는 드물게 복된 사람이라면, 이런 기회를 마다할 까닭이 없다. MSDN에는 고맙게도 저자인 Erik Meijer을 비롯한 기라성 같은 학자와 쟁이들의 동영상 자료가 숱하게 올라와 있다. http://channel9.msdn.com/tags/Haskell/
그리고 여러 분이 혹시 모르고 있는 사이, 이 사막 같은 곳에서도 조금 씩 오아시스를 찾아 움직이고 있는 사람들이 있다.
국내 여느 대학 교수님이 웹 페이지에 썼던 짤막한 글에서 처럼, 나는 솔직히 이 조그만 발걸음이 ‘작은(?) 대세’임을 조금도 믿어 의심치 않는다. 하지만 그 머지 않은 앞날의 주인공 속에 과연 여기의 ‘우리’ 가운데 몇이나 시대를 즐기고 있을까? 과연 우리에게 그런 자격은 있는가?
아직 재미있는 일은 시작도 안했건 만, 혹시나 그 동안 뭐하고 있었나 궁금할 지도 모를 양반들을 위해서 중간 보고 올리는 바이다. 요사이 공부 무지하게 하고 있다. 역시나 셈말 꾼이 터전을 옮긴다는 것은, 그간의 삶을 옮기는 것 만큼이나 버거운 일이다. ( 실제로 조사를 해봐도 그렇게 나온다지? 주로 쓰는 셈말을 바꿔치는 일이 그다지 흔치 않다는 게다. 뭐, 사람말이든 셈말이든 처음 생각의 틀을 잡을 때에 배워 쓴 말은 “엄마 말"(Mother Tongue)”이나 마찬가지. 영어를 열심히 공부해도 머릿 속에서 일어나는 생각은 우리말로 하게 되어있는 게지. 그렇다 해도, 알맞은 일에 알맞은 셈말을 배워 쓸 줄 아는 것은 쟁이가 갖추어야 할 바탕 가운데 바탕이겠다. )
아래는 그 간의 삽질 보고 되겠다.
- 끝내는 SUA 의 모든 걸 다 깔아서, 거의 Unix 환경을 만들어 버렸다. ( .NET 공부한다더니 지금 뭐하고 있는 거냐?—;; 배보다 배꼽이 더 크쟎아~~. ) Windows 위에 Unix Subsystem을 만들어 올리는 방법은 다음과 같다.
- 맨 먼저 Windows 그 머시기냐 소프트웨어 깔고 지우고 하는 제어판가서 Subsystem for Unix Apps가 하는 놈을 깐다.
- Utils & Apps for SUA 이거 받아다 깐다.
- SUA에 가서 Complete Toolset 깐다. 이 때 괜히 패키지가 쓰임새 따라 아래 같이 여러 묶음으로 나누어 놓았는데 괜한 헛삽질 말고 “Complete Toolset” 받아 까는 것이 좋다. 이 때 준비할 것은 “무한한 참을 성”이다. 내
려 받는 속도가 가끔씩 살인적이다. ( 성질 급한 우리나라 네떡 꾼들에게는 주금인 것이지, 이런거 vv;; 어지간 하면 이런데도 돈 좀 들이지. 기왕 고생해서 만든 것을 뭐 이렇게 마무리하고 있냐.) - 특히 이거 깔 때, Local administrator로 깔아야 한다. 다시 말해, Administrators의 Group에 들어있는 id로 해서도 안된다. 그냥 앞뒤 가리지 말고, Domain에 등록된 id말고, 로컬 곧 컴터에서 administrator라는 id로 들어가서 돌려야 된다. (나 이거하다 무지하게 헛 삽질했다. vv;;)
- pkg-current-bundlecomplete60.exe 돌리면 깔기 시작하는데 이거 역시 “느긋한 마음”이 가장 큰 준비물이다. ClaimsAV라고 병 걸린 놈(virus)이나 못된 놈(malware) 잡아내는 서비스(Unix 말로는 daemon이라고 하지들) 올리고 엔진 업데이트를 하나 본데, 이 오픈소스 프로젝트 하는 분이 잠적을 하셨는지 어쩐지 이거 계속 해볼려고 하다가 포기하고, 다음 단계로 넘어 가지 까지 시간 많이 걸린다. 그러니 그냥 놔두고 잊어먹고 있으면 된다.
-
다 끝나면 Subsystem for Unix-based Applications라는 메뉴판에서 bash가 걸려있는 것을 볼 수 있다!! Olleh! 하지만 주로 쓰는 id에서 이거 별 문제 없이 쓰고 싶으면, administ
rator 계정에서 걍 항상 Run as administrator로 뜨도록 손봐주고, 또 글꼴 이쁜 거 쓰고 싶으면 코드 페이지도 손봐주고 화면 크기도 맞추고 해주는 게 속편하다. ( 다른 id로는 .lnk 파일 손도 못대게 묶어 놨다. 아 물론 삽질 좀 하면 되시겠으나 편하게 사시라고 ^^;; )
-
옆에 DISPLAY라는 변수 보이시 것지들? X Window 뜬 다는 얘기 되것다. 진짜 뜬다. Xming이라는 이름인데, 이거 Minimalist GNU Win32. 줄여서 MinGW라고, GNU 컴파일러랑 갖가기 것들 Windows로 옮겨 놓은 꾸러미 있었는데, 그 힘을 빌어서 만든 것 같다. 역시 OSS의 “십시일반” 힘은 무시 못할 일이겠다. 여간 삽질 아니 었을 텐디. 그 토록 오랫동안.
-
아 물론, 왼편 그림과 같은 Setuid 방식이나 어마 무시한 root power를 주는 것은 두 subsystem을 일치시키는데 한계가 있는 부분이다.
오늘의 생각
- Cygwin 같은 거 있다는 거, 나도 안다. 좀 쓰기도 했다. 패키지도 더 많고 깔기도 더 쉽다. 하지만 Cygwin은 dll 한 덩어리로 포장된 emulation layer 위에 올라간다. SUA와 처럼, 아래와 같은 아키텍처
- 커널 위에 서브시스템으로 올라가는 구조가 갖는 장점을 누리지 못한다. 이러한 아키텍처는 끝내 “가상화(Virtualization)” 기술의 본질과도 깊은 관계가 있다. 이 것만 알아두자. 이런 연구 개발 노력이 일견 무한 삽질인것 처럼 보이지만, 현재의 어떤 뛰어난 기술도 과거의 우직하고 멍청한 삽질 없이는 생겨나지 않는다. - 아래는 SUA 시스템에 영향을 준 수많은 관련 기술 자산들이다. 마치 내 지나온 발자취를 그려 놓은 것 같아서 그냥 넘어갈 수 없었다.
- 어쩌다 보니 깔기는 했지만, 이 서브시스템이 얼마나 뛰어난 어플리케이션 호환성을 제공하는지, 실용성이 얼마나 괜챦은지에 대해서는 뭐라 말 못하겠다. 쓰다보면 알게 되겠지.
- 살펴보니 적쟎이 공들인 것 인정한다. 하지만 할거면 이런 서비스 제대로 좀 했으면 한다. 어찌 어치 알아가지고, 내려 받고, 만져 주고… 아~~ 번거롭다. 그리고, 안정성 중요하지만 어떤 것은 너무 옛날 것들이다.
그냥 묵혀 버리기에는, 아래 같은 노력들이 너무 아쉽지 않은가? 가상화 기술로 VM에서 리눅스 올려 쓰라고? 하기사 cygwin 보다는 나은 방법인데… 아 나도 모르겠다.
아~~ 이제는 Unix 삽질은 고만하고, 코딩을…. 할꺼나?
일단 글 꼭지부터 바꾸었다. 너무 길어서다. 그 대신 딸린 제목을 더 길게 쓰기로 했다. 읽는 사람이 헛갈려도 할 수 없다. (누가 진짜 읽기는 하남? ^^;;)
내가 처음으로 닷넷으로 연습삼아 해보고 싶은 놀이는, 2008년 PDC, The Future of C# 에서 Microsoft Technical fellow자 C# Chief Architect로 일하고 있다는 Anders Hejlsberg가 보여주었던 Compiler-As-a-Service 예제다. 데모에서 크게 감명을 받았다거나 그래서가 아니라, 앞으로 실험해 보고자 하는 놀이에 Meta-Programming 기술이 꼭 필요하기 때문이고, 그 과정에서 Mono 팀이 삽질하고 있는 C# Interactive Shell 이라도 만들어 가지고 놀 수 있으면 무지 즐겁겠다는 생각이 들어서다.
문제는 이 맛갈나는 오프소스 자산을 가져다 쓰면서 tar, bzip은 아카이빙 도구들은 물론이고 make 등등 UNIX 프로그래밍 환경에서 거의 매일 쓰다시피하는 UNIX 명령어들이 줄줄이 등장하노니… 이 거 진짜 삽질이다.
그리하여, 그간의 삽질보고 되겠다.
- 아름드리님 가르침대로 GUI Shell command 만들어 넣는 삽질하다가 알게되었는데, Windows Registry Editor Version 5.00이라는 글귀를 파일 맨 첫머리에 넣지 않으면 이런 메시지 뜬다. 이 글귀가 없으면 이 파일 type 못알아 보나 브다. UNIX file system에서 말하는 Magic Number랑 비슷한 건가 이거?
- Meta-Programming을 지원하려면, (C#) Parser / Evaluator / Compiler Agent 같은 API set들이 필요하다. 결론은, .NET 4에는 아직 없다. 그리고 간단한 Command Line shell이라도 만들어 보려면 GNU의 readline 같이 line editor 기능이 갖추어진 Input Stream Reader가 있어야 한다.
- 필요할 때마다, GNU Unix 유틸들 하나씩 찾아서 깔다가, 결국은 SUA (Subsystem for Unix-based Applications)라는 거 깔았다. Microsoft에서 이런 거 많들어 놓았는지 진짜 몰랐다. 왜 아무도 말 안해 주는 거냐!!! 한 술 더떠서, 이런 곳도 있다. 덩실 덩실! SUA Community라는 게 있는 거다. { 이제 이거보고 열심히 따라 해야 겠다. 그럴 바엔 차라리 그냥 Unix 쓰라고 하고 싶으시겠지만 좀 참으시라. 뭐, 교육 비디오 두편도 Microsoft에서 만들어 준 거 같은디. 어쨌든 기쁨일지어다. }
- 오, Windows/SUA 밑에 널브러진 그 친숙한 디렉터리 생김새들과, bin 아래에 화면 가득히 펼쳐진 정겨운 이름들이여!! 땡스 어랏!
새로 시작하는 글타래 이름을 “그냥 …”이라고 시작해 봅니다.
이 바닥 만큼 거품 잔뜩 들어 기름기 잘잘 흐르는 낱말이 사람 어지럽게 만드는 곳도 드물기 때문에, 무슨 뜻으로 굳이 왜 저런 이름 붙였는지는 제가 군말하지 않아도 잘 아실겝니다. 이 바닥 사람들 연설하는 걸 듣고 있자면 적쟎이 어지럽고 메슥거릴 때가 적지 않죠. ‘저 사람은 진짜 저 말이 무슨 뜻인지 알고 뱉어내는 걸까?’ 갸우뚱 하신 적이 적지 않을 겝니다.
“그럼 그러는 당신은 안그랬수?.”
사실 누군가 제 얘기를 한 번이라도 들어보신 분이 이렇게 되 쏘아붙인다면, 저 역시도 할 말 없습니다. 저 또한 안팎으로 이런 저런 기술 얘기 떠들어 대면서 아는 낱말은 다 같다 붙여 써대고, 거품끼고 기름기 덕지 덕지한 얘기 적지 않게 즐기며 살아 왔습니다. 그보다 되려 “아, 누구세요? 나는 당신 얘기 들어본 적 없는데?” 그러시다면 저로서는 차라리 맘 편한 일이겠습니다.
그래서 이제부터, 기름 뺴고 거품 뺀 쉬운 기술 얘기, 차 한 잔 마시며 전화기로도 슬슬 읽어 넘길 수 있는 담백한 기술 얘기 시작해 보려고 합니다. 그 첫 애깃 거리는 “클라우드 컴퓨팅 (Cloud Computing)”입니다. 버터 기름 쭉 빼고 그냥 “구름 셈법”이라고 할까요? ^^
2010년 새해부터 클라우드 컴퓨팅. 참 오랜 만에 이 바닥이 시끄럽습니다. 여기 저기서 구름 얘기가 뭉게 뭉게 피어납니다. 구름의 생김새가 꼭 “거품”을 닮았습니다. 여러 큰 장사꾼들이 저마다 자기 구름이 좋다고 말합니다. 사람마다 좋다는 구름도 가지 가지 입니다. 높새 구름, 하뉘 구름, 먹구름 … 심지어는 열린 구름(public cloud)이니 닫힌 구름(private cloud)이니 하는 얘기도 떠 돕니다.
마이크로소프트도 그 가운데 하나입니다. 저도 어쩌다 보니 그 한 가운데서 자못 목소리를 높여야 할 처지에 있습니다. 더 크게 떠들어야 먹고 살 수 있는지라, 너나 할 것 없이 떠들어 대는 구름 이야기를 저 또한 덩달아서 아니할 수야 없겠지만, 이제 부터 제가 하려는 얘기가 “밥을 물에 말아서, 된장 찍은 청량 고추”로 한 끼니 때우는 마냥, 담백하고 때로는 톡쏘는 먹을 거리로 다가갔으면 합니다.
어떻게 얘기를 시작할까요? 어… 그러니까… 이제부터 고민 좀 해봐야 겠습니다.
클라우드 컴퓨팅에 대한 이야기가 여기 저기에서 많이 나오고 있습니다. 과연 이 기술에 관심을 가져야 할까요? 혹시 잠시 버즈만 일으키고 사라져 버렸던 다른 IT 용어 들 중의 하나로 기록되지는 않을까요?
아래 제가 포스팅을 하고 링크를 건 클라우드 컴퓨팅과 관련한 내용들은 그런 의문에 대한 답을 얻는데 자그마한 참고가 되실 것으로 생각 합니다. 개인적으로는 지금 당장 모두에게 클라우드 컴퓨팅이 필요한 것은 아니겠지만, 어느 누군가에게는 정말 필요한 기술이며, 향후에도 중요한 기술이 될 것이라고 생각을 합니다.
첫번째 포스팅인 클라우드 컴퓨팅과 마이크로소프트 윈도우 애저 에서는 처음 클라우드 컴퓨팅에 관심을 가지시기 시작한 분들을 대상으로 클라우드 컴퓨팅에 대한 간단한 개념과 마이크로소프트의 클라우드 컴퓨팅 기술인 애저에 대한 소개와 관련 링크들을 넣어서 .
그리고 클라우드 컴퓨팅으로써 Azure가 활용되고 있는 사례를 몇가지 알아보았는데요, Azure 사례 - 구름위의 트위터 클라이언트 TwittZure 에서는 twitter와 같은 소셜 애플리케이션을 클라우드에 왜 올렸는지, 어떤 이득이 있는지에 대해서 기술해 보았습니다.
세번째 Azure 사례 - 구름을 통한 소프트웨어 배포 Siemens 에서는 Siemes 같은 글로벌 업체에서 수많은 장비들에 설치된 소프트웨어를 업데이트 하기 위해서 클라우드 서비스를 활용한 사례를 알아보았습니다.
세가지 정도의 추가 Azure 를 통한 클라우드 컴퓨팅 사례를 더 알아보고 그 이후에는 Azure 를 통해 클라우드 개발을 위해서 필요한 간단한 가이드 들을 포스팅하도록 하려고 합니다. 클라우드 기술에 관심 있는 분들께 도움이 되기를 바랍니다.
끝으로 위의 포스팅 들이 올라가는 제 개인 블로그 주소는 중스닷넷(http://joongs.net) 이며, 각 포스팅에 대한 질문이 있으시면 댓글로 남겨주시면 답변 달아 드리겠습니다.
오늘의 삽질기
늙다구니 왕초보를 보살피실 줄 아는 “아름드리” 님의 친절한 댓글 덕택에 오늘의 틈삽질 - 틈나는 대로 하는 삽질 ^^;;은 꽤 즐겁다.
- Command Line은 아니지만 서도, CDPATH 나름 대체하는 방법은 해결,
오늘은 아침부터 삽질 시작. 댓글 보고 곧바로 Registry 고치기 부터 시작. 어제 깔아 두었던 VI(VIM)로 아래 같이 reg 파일 만들어 start로 실행. 꾹꾹! 뱅!
[HKEY_CLASSES_ROOT\Directory\shell\Command]
@="Code Here"
[HKEY_CLASSES_ROOT\Directory\shell\Command\command]
@="cmd.exe /k \"C:\\Program Files\\Microsoft Visual Studio 10.0\\VC\\vcvarsall.bat\" x86"
오, 그리고 짜잔. Live Mesh로 공유된 JoP(Joy Of Programming) 폴더를 클릭하니, “Code Here”이라는 아이템이! 헉 그런데 왜 이거 실행시키니 왜 JoP가 아닌 그 위 Documents로 떨어지는 것이냐… 새로 태어난 아기 쉘 프로세스의 Current Working Directory를 클릭했던 폴더로 잡아주는 방법은 없으..까나… 뭐 꼭 또 갈켜 달라는 것은 아니고…
- 아름드리 님이 갈쳐 주신 “SnippetCompiler”를 살펴보다 여기 저기 뒤져 보니, 나같이 생각하는 생각하는 사람들이 적지 않았던 모양. 그럼 그렇지! 2004년 6월 MSDN에 날마다 필요한 10가지 개발자 도구 가운데 하나로 꼽힌 것을 보니 제법 오래된 듯 한데. 다만, 아쉽게도 내가 만져보려는 .NET 4 판은 아직인듯.
- 그래서 결국 다시 손에 익은 VI로 돌아왔으나, 산처럼 쌓인 뱀처럼 긴 이름의 API 이름들을 주무르려면 곧 힘에 부칠 듯. Mac OS X에서 쓰던 TextMate 비스무리 한 에디터만 있어도 딱일 터인데 하는 생각이.
- 서버 급히 만질 때 써보려고 X Terminal 비스무리 한 걸 찾았으나, 이 문제는 골치아파 무기한 연기. RDC는 아무래도 내 타입이 아냐… oTL. 프로그래밍 언어 문제는 아무래도 오늘 고민 좀 더해야 할 듯.
오늘 느끼기를
- 여전히 \랑 /의 차이는 이겨 내기 쉽지 않고나. 비슷하게 clear vs. cls, 무심코 find 해보다가 허걱하는 일 되풀이 하고 있고, dir vs. ls는 각기 오래 익어서 헛갈리지 않지만 서도.
- cd 해놓고 왜 프롬프트가 그대로인지 멍하니 지켜보는 스스로를 또 한심하게 지켜보는…
- 그런다고 cd ~하는 것은 또 뭐냐
- csc가 C# compiler 이름이라는 거, 참 오랜만에 기억났다. 그래도 cl은 무심코 떠오르더만
- 고작해야 환경 변수를 다루는 것인데 – Registry도 Enviroment요, Shell 변수도 Environemnt요, 다 본질도 같고 역할 도 같것만, 고치는 방법도 다르고, 관례도 서로 다르고… 이건 여전히 문제. 반드시 그래야 할 까닭도 없이 단순한 것을 어렵게 만드는 이 분야의 고질적인 버릇은 Unix, Windows, Mac OS X 할 것 없이 여전.
중딩 시절부터 1년 만땅으로 코딩 한 줄 안하고 세월을 보낸 것은 여기 와서 처음.
그럼 이제부터는 코딩 시작!? 할 수 있으까…?
윈도우즈(Windows) 한 번도 안 써봤다면 거짓말이겠다. 어떻게든 윈도우즈는 쓸 수 밖에 없지, 이 나라에서는.
허나, 솔직히 말하건데, 지금 글을 쓰고 있는 나는, 적어도 지난 여섯 해 동안 윈도우즈에서 진지한 프로그램을 짜 본 일이 거의 없다. C#은 고사하고, C++로도. 한 술 더떠서, 편지 보내고 글 쓰고 웹 서핑 따위 일도 거의 Unix에서. 그 밖에 꼭 윈도우즈 써야할 일은, Die Hard 윈도우즈 유저이신 마눌님께서 해주시옵고. (Olleh!) 그래서 본래는 글 제목을 “Die-Hard Unix 유저…” 어쩌고 저쩌고 하려고 하다가, “Die Hard”란 낱말이 마음게 걸려 바꿨다.
어쨌든, 어떤 까닭에서 건, 나는 지금 아주 오랫만에 윈도우즈에서 소프트웨어 개발을 해야만 한다. 그 것도 신기술을 가능한 한 껏 끌어들이면서…
사실 이런 일로 블로그 글까지 써야 할까 하다가, 몇 년 전에 Apple Forum을 자주 들락 거릴 때 (빈도수는 줄었지만 나는 여전히 이 포럼의 오랜 회원이기도 하고 틈 나는 대로 들려서 좋은 정보도 많이 얻고 있기도 하다.), “Die-Hard Windows 개발자의 Mac 적응기” 던가… 하여간 그런 제목의 연속된 블로그 글을 재밌게 읽었던 기억이 났다. 좀 더, 털어 놓자면, 나는 지난 거의 10년 동안 Mac OS X을 썼다. 대충 SCO Xenix –> SCO Unix –> NextStep –> 386BSD –> Linux -> Solaris –> FreeBSD로 이어지는 내 스무해 넘는 Unix 여정의 종착역인 셈이다. 따라서 Objective C를 모르지는 않지만, 그렇다고 Mac OS X 개발자라 하기는 어렵다. 아직도 내 집에는 두 대의 맥킨토시가 있다. 듀얼 G5 데탑 한 대, 검정 맥북 한대. 최근에 검정 맥북 한대에는 Windows 7을 깔았다. 이 정도면 내 “골수”의 깊이를 더 이상 늘어 놓지 않아도 될 듯.
{ 마이크로소프트 직원이 아직도 Mac OS X을 쓰면 되겠냐고? 호호, 안될게 뭐있나? 그럼 이건 뭐라고 설명할까? http://www.microsoft.com/mac/default.mspx (Mactopia). 그리고 iPhone에 ActiveSync 라이선스는 왜 해줘쓰까? 더불어, Google에는 또 왜 ActiveSync 라이선스는 왜 해줬으까? 이 밖에도 기술 편가르며 말싸움하기 좋아하는 버릇을 못버리는 사람들로서는 이해 못할 수많은 “적과의 동침”이 하루가 멀다하고 자연스레 생겨나는 곳이 바로 이 판이다. 기술과 제품의 성패는 생태계의 건전성으로 판가름 나는 것이지, 그 자체의 기술적 우수성과 소수 집단의 비 논리적 충성도로 지켜질 수 있는 것이 아니다. 지금 까지 이 분야의 역사가 증명하듯이. }
아 뭐가 어찌되었던, 이 글에서 중요한 것은 어떤 필요에서건 (1) 이제 그간 죽자고 Unix / Java 환경에 더 가까운 방식으로 프로그램 짜던 사람이, 윈도우즈에서 과감히 삽질을 해보기로 마음 먹었다는 것이고, (2) 연배와 경륜이 어떠하던 간에 여하간 누군가의 도움이 절실히 필요하다는 것 (3) 그 과정에서 겪고 있는 궁금증과 난점을 눈 딱 감고 용감하게 떠벌이고 있다는 사실이겠다.
사실 옆자리에 전문가들이 즐비하지만, 사실 내겐 거의 도움이 되질 않는다. 내가 물어보는 것이 “하도 오래전이라 기억이 안나는데, C# 컴파일러 이름이 뭐유?” 또는 “cmd 창에서 굴림체 말고 다른 글꼴은 쓸 수 없수?” 같은 너무 잡스럽고 촌스런 것이기도 하거니와 일단 너무들 바빠서 얼굴 보기도 힘든 사람들에게 어이없는 질문을 던지기가 선뜻 내키지가 않는다. 그리고, “당신이 왜 이제와서 윈도우즈 프로그래머가 되려고 하지?”라고 대놓고 물으면 뭐 딱히 대답할 답이 떠오르지 않는다. ( 내가 뭔가 열심히 몰래 준비하고 있다는 것만은 사실이지만.) 이 무슨 황당한 풍요속의 빈곤이던가? 그래서 용감한 척 (뭐 모르는 것은 모른다고 해야지…) 하면서 이렇게 공개적으로 대놓고 물어보는 거다. 혹시 안팎으로 누군가 답해 주지 않을까 싶어서…
아래는 그 첫번째 삽질 보고서다 - 미리 말하건데 보고 웃지들 마시라. 그리고 플랫폼 전략이 어쩌고 저쩌고 하는 양반이, 3백만년 전 아해들이 고민하던 문제를 이제 와서 들먹이냐고 퇴박 놓지도 마시라. 그저 마흔 줄에 기꺼이 삽질하는 사람의 마음을 어여삐 여기사, 과감한 도움의 손길을… ^^;;
뭐, Simon Peyton Jones 같은 어르신도 윈도우즈 쓰시면서 http://research.microsoft.com/en-us/um/people/simonpj/win32-cheat.html 이러셨나 본데 나라고 별 수 있겠남? 뭐든 익숙하지 않으면 불편한게다. 예전 우리 할머니 이불 빨래를 하시는 데도, 세탁기 마다하고 손빨래 하셨듯이. 각설하옵고.
- X Terminal을 완전히 대체할 기능을 찾다가 반나절만에 포기. Remote Desktop Connection으로 대체 가능? 이 기능을 한 두 쪽으로 잘 설명해 놓은 글은 웨 검색해도 잘 않나오는 거냐. 솔직히 Help 별 도움 안됐다. 어쨌거나, RDC로 연결했을 때, Server 쪽 GUI 다 뜨는 거 말고, Shell만 어찌 뜨게 할 수는 없을까? 그리고 그 쪽에서 실행시킨 어플 화면을 내 컴터 쪽으로 보이게 하려면 어찌해야 되지? 너무 어렵거나 잘 안된다면 하는 수 없는 일. 윈도우즈에는 나름의 사는 방식이 있을 터이지. 뭐 꼭 같은 기능 필요하다고 우겨댈 생각은 없다.
- Cmd로는 Unix shell를 대체하기는 좀 역부족인 듯. Powershell? 문뜩 배보다 배꼽이 더 클 듯한 느낌이… 아 무엇보다 Cmd를 실행시킨 콘솔 창에서는 Defaults 세팅에서 Codepage를 437로 바꾸니, Consolas나 Lucida 같은 글꼴을 쓸 수 있는데, 왜 Powershell 창에서는 Defaults 세팅에서 Codepage를 바꾸지도 못하는 거지… –;; 이거 VI 에디터 쓸려면 굴림체나 raster 글꼴은 좀 … 그런데… 아… 괴롭다. 좋은 코드는 좋은 글꼴에서 나오는 벱이야~~~(지발 글꼴 바꾸는 방법 좀 갈쳐 주시구랴.)
- 왜 IDE 안쓰냐고? Visual Studio 좋은지는 저도 알지라. 뭐 앞으로는 꼭 써볼 틴티…. 근디 olleh! world 정도로 간단한 실험 코드 쓸라는데, IDE 열고 프로젝트 만들려고 엉성한 이름 짓고 … 그 건 좀 아직 좀 그러하네… 익숙치 않아서 그런건가? 이럴 땐 EMACS 쓰기도 부담시려.
- .NET 공부하는데, 꼭 C# 써야하남? 이 번에 나온 .NET 4 버전부터는 Ruby나 Python 쓰면 안될까? 아직도 좀 쓰기가 좀 그런가? Ruby on Rails를 꼭 쓰겠다는 것은 아니지만, 가볍고 날렵하게 즐기기에는 Interpreter 방식으로 즉문 즉답하는 환경에서, Typing 신경 끄고 노는 것이 사실 더 맘에 드는데… 흠 고민
- Command line 컴파일러 쓰려다 보니, 환경 변수 세팅하는 것 때문에 고민 중이었는데, Visual Studio 2010 Ultimate Beta 까니까 PATH에 환경 변수 물어서 cmd 창 띄워주는 메뉴가 떡 하니 생기던데, 왜 Visual Studio 2010 Express 판에서 C# 판 깔고나면 왜 그런 메뉴 같은 것이 아예 뵈질 않은 겨… 사무실 데탑에는 Ultimate 판 몽창 깔고 싶지 않은데… –;; { cmd 대신 powershell 물려 띄울려면 어찌 해야하지? }
- cmd 창 뛰우니 Visual Studio 2010 설치된 폴더로 가는 군. 이거 C Shell의 CDPATH 처럼 자주 가는 directory로 한 방에 cd로 가도록 환경 세팅할 방법은 없는가? 아니면 나도 모르는 획기적인 뭔가가? … 이거 안되면 무쟈게 귀챦은데… –;;
이 번 삽질은 요기까지. 어쨌거나, 이거 쉽지 않군. oTL
2010 년 1월 13일, 사무실에서 퇴근 전 막판 1 시간 남겨두고 삽질하면서
드디어 대망의 2010년 새해가 밝았습니다! 먼저 새해 복 많이 받으십시오!
한국 마이크로소프트에서 새해 처음으로 개발자들의 새로운 희망인 윈도우 폰 애플리케이션 개발 세미나에 여러분을 초대합니다! 이번 세미나는 새해 처음으로 여는 행사인 만큼 푸짐한 선물들을 준비했습니다. 조기 마감이 될 수 있으니 어서 아래의 등록 버튼을 클릭해 주세요!!
마이크로소프트가 상호운용성(Interoperability, http://www.microsoft.com/interop/)을 높이기 위한 하나의 활동으로 노력한 결과물, Moonlight 2가 발표되었습니다. 이 프로젝트는 마이크로소프트와 노벨이 2007년 9월 처음 발표한 프로젝트로 Microsoft Silverlight 기술을 LINUX에 구현하는 것을 목표로 했습니다. 마이크로소프트는 노벨에게 Silverlight 테스트 스위트를 주고, LINUX 사용자가 Microsoft Media Pack이 가진 다양한 코덱을 이용할 수 있는 라이선스를 제공했습니다. Moonlight 2(http://go-mono.com/moonlight/)는 Silverlight 2 기능과 Bitmap API, 파일 다이얼로그, 지우기 기능, 플러그 가능한 미디어 파이프라인과 맞춤 코덱과 같은 Silverlight 3 일부 기능이 구현되었습니다. 지원이 되는 LINUX 환경은 SUSE Linux Enterprise Desktop 11, openSUSE 11.x, Ubuntu 9.10, and Fedora 12 + Firefox 2.0, 3.0, and 3.5입니다.
다음 계획으로 Silverlight 3 기능 구현 프로젝트 목표 시기가 내년 3분기이고, Silverlight 4도 이후에 진행할 예정이라고 합니다. Moonlight 프로젝트가 시작되었을 때, 몇 년이나 Microsoft가 지원할지를 묻는 분들이 계셨는데, 이제 2년은 지났고 3년 계획은 가시화되었습니다.
Information as a Service, Data as a Service라고도 부를 수 있을 것 같습니다. 웹 페이지, IT 시스템 등에서 가장 핵심이 되는 것이 무엇일까요? 아주 화려한 UI, UX, 프로그램 코드? 물론 다 중요하지만 핵심은 데이터 입니다. 알맹이가 없는 밤이 버려지는 것처럼 컨텐츠가 없는 UI는 공허한 하나의 껍데기인 것이죠.
데이터의 종류는 방대합니다. 신문 기사, 방송국의 뉴스, 영화, 또는 통계청, 국세청, 국방부 등 정부기관의 데이터, 미국 NASA의 우주 사진, 항공 사진 등 방대한 자료를 개별 회사, 정부기관이 보유하고 있습니다. 이러한 데이터를 잘 가공해서 판매한다면 괜찮은 비즈니스가 되지 않을까요? 즉 무료로 공개하거나 각 기관이 판매하고자 하는 정보를 하나의 마켓플레이스에 모아 둔다면 데이터를 서비스로 구매, 가공하여 또 그 데이터를 판매하여 수익을 얻는 일이 가능할 것 입니다. 이것을 Data as a Service라고 부르는데, 마이크로소프트의 클라우드 플랫폼, Windows Azure와 SQL Azure를 이용하여 마이크로소프트가 직접 개발한 Dallas가 발표되었습니다. 앞에서 설명한 것처럼 데이터, 이미지, 실시간 웹 서비스도 포함되어 있습니다. 통합된 프로비저닝과 빌링 프레임웍이 포함되어 있습니다. 다시 말하면, Dallas API를 이용하여 개발자나 정보근로자가 웹, 모바일 등의 플랫폼에 관계 없이 프리미엄 콘텐츠를 소비할 수 있는 통로를 제공 합니다.
시나리오
1. 소비자, 비즈니스용 차세대 킬러 애플리케이션을 만드는데 필요한 컨텐츠 확보
2. 현재 애플리케이션이나 리포트의 품질을 향상시킬 수 있는 가치 있는 데이터를 찾아 구매
3. 이종의 데이터 집합을 결합하여 비즈니스 성능과 프로세스를 향상 시킬 수 있는 통찰력 획득
4. Blob, 구조, 비구조적 데이터와 실시간 웹서비스를 API를 이용하여 가시적으로 탐색
5. 리포팅과 분석을 위해 마이크로소프트 오피스, SQL 서버 내부에 있는 제 3의 데이터를 쉽게 사용 가능
http://pinpoint.microsoft.com (마이크로소프트의 애플리케이션 마켓플레이스, Pinpoint)에서 Dallas를 찾으면 현재 데이터를 제공하는 데이터 제공자들의 내역을 확인할 수 있는데 구독을 선택하면 됩니다. 현재는 무료로 서비스되고 있습니다.
http://pinpoint.microsoft.com/en-US/PartnerDetails.aspx?PartnerId=12884901889&LocId=1249835483137
구독을 하면 아래와 같이 Dallas 창을 통해 원하는 데이터를 조회하거나 다운 받을 수 있습니다. UN의 WHO(세계 보건 기구) 데이터, 예를 들면 대한민국의 2006년 기준 예상 수명을 조회한 데이터 입니다. 82살이라고 나오네요. 이런 값을 전체적으로 가져와서 애플리케이션의 데이터로 활용하면 재미있는 Data 서비스를 만들 수 있지 않을까요?
향후에 상용화도 가능하겠죠. 이건 너무 무궁무진해서 생각하는 만큼 비즈니스가 될 것 같은데, 어떻게 생각하세요? 의료, 법률, 통계청 각종 통계 데이터, 기상청 날씨 데이터 등등 제가 그냥 생각하는 것도 만만치 않게 많네요. 이후에 재미있는 사례가 올라오면 좀 더 공유해보도록 하겠습니다.
마이크로소프트의 “Windows Server & 솔루션 그룹”과 “Windows Azure 그룹”이 하나로 합해져 “Server & Cloud Division”이 만들어졌습니다.
이 말은 마이크로소프트의 클라우드, 즉 Windows Azure Platform을 만들면서 습득한 다양한 기술을 Windows Server에 적용하여 고객들이 Windows Server를 이용하여 직접 Windows Azure Platform과 같은 클라우드 플랫폼을 구축할 수 있도록 하겠다는 의지라고 해석할 수 있습니다. 실제로 Windows Server AppFabric이 바로 클라우드에서 취득한 기술이 On-Premise 서버로 제공되는 첫 번째 사례 입니다.
마이크로소프트의 소프트웨어 플러스 서비스 전략, 기억 나시나요? 고객은 On-Premise로 운영하고 싶을 때가 있고, 클라우드 방식으로 이용하고 싶을 때가 있는데, 클라우드에서 On-Premise로 넘어오거나, On-Premise에서 클라우드로 이관하는 것이 자유로운 Hybrid 세상, 그 비전이 구체화되고 있습니다.
안녕하세요. IISKOREA 팀블로그 의 김대우 입니다. 이번에 소개해 드리고 싶은 내용은 최근 커뮤니티 사이트 작업하면서 진행한 유용한 Rewrite 기능들 소개 입니다.
단순 하지만 SEO와 Fancy URL 처리 등에 유용한 내용이기 때문에 그냥 옮겨 옵니다.
수행 예제 등은 아래의 참고 링크를 확인하세요.
1. URL의 맨 뒤에 “/” 슬래쉬를 항상 붙이거나 항상 떼어내는 방법 - SEO에 신경쓰신다면 꼭 이용하세요.
2. 영문 URL을 모두 알파벳 소문자로 처리 하는 방법
3. Canonical Hostname – 서버명 정형화(?) 처리
Canonical 이라는 단어 처리가 애매해서 그냥 넣었습니다. 제가 이번에 사용한 내용인데요.
http://iiskorea.net 이라는 경우와 www.iiskorea.net 으로 URL을 치는 경우가 있는데, SEO나 RSS처리에 좋지 않아서 항상 저는 www를 붙입니다. 이것을 URL Rewrite를 이용하면 Transfer Rule로 쉽게 제작 가능합니다. 저의 경우는 아래와 같습니다.
<rule name="iiskorea Canonical Hostnames" enabled="true" stopProcessing="true">
<match url=".*" />
<conditions logicalGrouping="MatchAll">
<add input="{HTTP_HOST}" pattern="^iiskorea.net$" />
</conditions>
<action type="Redirect" url="http://www.iiskorea.net/{R:0}" redirectType="Permanent" />
</rule>
참고로, Textcube는 URL Rewrite를 php 파일로 처리하게 되는데요. rewrite.php 파일에서 처리. - 위의 Canonical Hostnames URL Rewrite Rule을 처리하기 위해선 우선 순위를 높여 두어야 합니다. 즉 rewrite.php Rule보다 위에 먼저 수행 하게 두어야 동작합니다.
4. HTTPS로 리다이렉트
5. 503 상태 응답 코드 리턴
6. 이미지 직접 링크 방지 – 트래픽 제한 등이 걸려있을 경우에 유용할 겁니다.
7. 다른 사이트, 서버로 Reverse Proxy 처리
8. Reverse Proxy에서 프로토콜 프리픽스 예약
9. Request 쿼리 스트링으로 Rewrite / Redirect 수행
10. ASP.NET 웹 리소스 요청에 대해서 Rewrite 수행 제한
도움 되시길 바랍니다.
참고자료
http://blogs.iis.net/ruslany/archive/2009/04/08/10-url-rewriting-tips-and-tricks.aspx
지난 포스트 링크 - URL Rewrite 관련
URL Rewrite 1.1 (URL 재작성) - (1) 소개 및 설치
URL Rewrite 1.1 (URL 재작성) - (2) URL 재작성
URL Rewrite 1.1 (URL 재작성) - (3) 요청 필터링과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (4) ASP.NET 라우팅과 URL Rewrite
URL Rewrite 1.1 (URL 재작성) - (5) Apache의 mod_rewrite 규칙 가져오기(import)
URL Rewrite 1.1 (URL 재작성) - (6) Rewrite Map 사용
