calmglow (최진호)

개인용 노트북에 우분투를 설치했다. 재미로, 혹은 실험삼아 하는 것이었기에 쓰지 않는 용량작은 하드디스크에 설치했다.
앗, 그런데 우분투 너무 좋다. 이것저것 갖고 놀다보니 제대로 쭉 사용하고 싶은데 하드디스크 용량이 작아서 고민이라면?
우분투는 윈도우 멀티부팅환경까지 완전히 복제해서 새로운 넓은 용량의 하드디스크로의 이사를 할 수 있는 기능을 제공한다.

Clone your Ubuntu installation onto a new hard disk

핵심은 이렇다.

세가지 과정이 필요한데,

First, you must discover how Ubunturefers to the hard disks. Second, you must install ddrescue and thenuse it to clone the disk. Third, once ddrescue has finished, you mustuse the Gparted utility to expand the disk partition(s) (assuming thatthe new disk is bigger than the old one, which is almost certainlygoing to be the reason for upgrading in the first place).

It's not a good idea to clone a hard disk that's in use (any morethan it's a good idea to repair a car while it's being driven), so youmust use your Ubuntu install CD's live distro mode. To carry out thefollowing instructions, boot from your Ubuntu install CD, and selectTry Ubuntu from the boot menu.

CEP와 EDA의 관계와 정의내리기로 지금 한창 관련자들은 바쁜 중.
Giles Nelson 이라는 자가 자신의 블로그에 CEP와 SOA그리고 EDA에 대하여 다음과 같은 정의 및 구분을 지었다.

• CEP is a technology. SOA and EDA are not technologies. SOA andEDA are philosophies for the design and build of modern distributedcomputing architectures.
• A SOA is a loosely coupled set of services, the functionality ofwhich closely reflects an organisation’s business functions andprocesses. A SOA will typically use modern, Web services technology andstandards for implementation, but is not required to. Building SOA infrastructure requires much thinking about the services that the SOA will use.
• An EDA is a loosely coupled architecture, the endpoints of whichinteract with one another in an event-driven fashion. Information flowsaround the EDA as events. An EDA will have endpoints which produceevents and endpoints which consume events. An EDA works in a “sense andrespond” fashion. Building an EDA requires much thinking on theevent-types that the EDA will use.
• An EDA may use business focussed services as endpoints. An EDA may therefore also be a SOA but it does not have to be.
• CEP is a capability within an EDA, providing analysis and matchingof multiple events being sent between endpoints. You can have an EDAwithout CEP.
• If you’re building your architecture and focussing on defining event-types, it’s very likely you’re building an EDA.
• If you are using CEP then you have at least the beginnings of anEDA because you will have been focussing on event-types. Your EDA may asimple one, with one event producer and consumer, but it’s still anEDA.

사람들이 알고있는 내용과 크게 다르지는 않는 정의들이다. 하지만 Tim Bass란 이는 CEP는 단지 기술이나 툴뿐만이 아니며 EDA와 상관없이 IT역사에서 언제나 있었던 기술내지는 패턴이었음을 이야기하고 있고, 줄곧 CEP에 대한 전문적인 글을 써온 Opher는 전체적인 내용에는 동의를 하면서도 몇가지 토를 달면서, 또 다른 논쟁인 CEP가 먼저냐 EDA가 먼저냐에 대하여 그것은 의미없는 일이다, 어떤 고객은 전사 아키텍처를 먼저 생각하지만 어떤 고객은 툴 도입에만 신경을 쓸 수도 있으니 그때 그때 다르지 않겠냐는 입장이다. 어쨌든 웹상에서 EDA, CEP전문가들이 어떻게 보면 별로 중요하지도 않을 것 같은 개념에 열을 올리면서 커뮤니티를 만들어가고 있는 모습에서 EDA와 CEP의 밝은 미래를 엿볼 수 있을 것 같다.

저의 아버지 연세는 올해 68, 낼모레면 일흔을 앞두고 있는 아버지는 제가 제일 존경하는 엔지니어입니다. 서른시절부터 줄곧 전기기술자로 지내오신 아버지는 지금도 어느 건물에서 전기주임을 맡고 한달에 백만원이 넘는 월급을 받고 엔지니어로서 지내고 계시죠. 아마도 노환으로 거동을 못하시는 때가 오지 않는 한 그 일을 하실 것 같아요. 그만큼 직장에서 기술적으로 확실한 신임을 받고 계신 엔지니어입니다.

당신은 어떤 엔지니어를 꿈꾸십니까? 혹시 스티브 잡스나 빌게이츠같은 엄청난 대박을 이룬 엔지니어들만을 꿈꾸고 있지는 않는가요? 엔지니어가 이룰 수 있는 꿈은 로또와도 같은 대박만 있을까요? 저는 그렇게 생각하지 않습니다. 자신이 좋아하며 열심히 하는 기술이 있는 한, 그리고 그 기술을 나이에 상관없이 끊임없이 공부하는 마음이 있는 한, 자신의 손에 익은 연장으로 기술 하나만큼은 누구에게도 꿀리지 않을 수 있는 자신감으로 평생을 살아갈 수 있다면 그것은 우리 엔지니어에게 있어서 또 다른 꿈이 아닐까요?

이러한 엔지니어의 롱런의 꿈, 가늘고 길게 가지만 충분히 행복할 수 있는 엔지니어의 삶이 정말 어려운 것일까요? 저는 제 아버지를 바라보며 그것이 결코 어려운 게 아니라고 늘 생각합니다.

얼마 전 아버지는 저에게 인터넷으로 무언가를 부탁하셨습니다.
'인터넷으로 Metal Detector 설계 도면을 찾아봐라'
'아버지 그건 왜요?'
'얼마 전 간단한 설계도면을 가지고 금속탐지기를 만들었더니 성능이 너무 형편없어서 좀 더 강력한 것을 만들어보려고.'

아버지는 그저 취미로 금속탐지기를 만들어서 무언가에 쓰시려는 것이었어요. 낼모레면 일흔이신 분이 돈 더주고 완제품을 사도 될 것을 굳이 스스로 만드려는 꼬장꼬장한 엔지니어의 자세. 아마도 아버지의 그 자세를 제가 물려받아 저 역시 엔지니어의 길을 걸어가고 있는 것 같습니다.

그렇습니다. 이러한 엔지니어의 자세만 있다면 나이가 들어도 엔지니어로서 스스로 자족할 수 있는 인생은 얼마든지 열려있고 이러한 영원한 평생직장의 세계가 바로 다른 직업은 절대 누릴 수 없는 엔지니어만의 특권이 아닐까요?

물론 너무 현실을 모르는 이야기 아니냐고 하시는 분들도 많으실겁니다. 엔지니어의 오랜 경험과 숙련도를 대우하지 않는 사회적인 분위기도 우리를 힘빠지게 합니다. 하지만 주위를 가만히 둘러보면 결국 진정한 엔지니어들, 스스로 자족할 줄 알고 언제나 공부하며 자신의 결과에 장인과도 같은 철저함으로 무장한 사람들은 결코 죽는 법이 없다는 것을 종종 보게됩니다.

당신이 만약 이제 막 엔지니어의 길에 들어온 사람이라면 용기와 자신감을 가지세요. 엔지니어는 의사 변호사만큼 장수만세할 수 있는 직업이고 자신의 노력 여하에 따라 다양한 희망을 보여줄 수 있는 직업입니다. 주위 선배 엔지니어들의 패배주의와 자조섞인 한숨에 휩쓸리지 않고 엔지니어의 길을 꿋꿋하게 즐길 수 있다면 당신은 성공할 것입니다. 비록 그것이 빌게이츠의 길은 아니지만 제 아버지와 같은 스스로 행복할 수 있는 또 다른 길은 우리에게도 충분히 열릴 것이리라 저는 확신합니다.

• REST 사용에 있어서 주의할 점
• HTTP Method에 맞게 사용하라. retrieve하는 용도로 GET을 쓰지 말자.
• 되도록이면 Stateless REST 서비스를 사용하자. 복잡해진 만큼 그것의 장애가능성도 높아진다.

• REST 서비스는 결국 자원을 웹 플랫폼에서 활용하는 서비스이므로 되도록이면 그 자원의 구조도 디렉토리구조대로 만들면 편할 것이다.
• Table 1. Common MIME types used by RESTful services
  

  MIME-Type	Content-Type
  JSON	application/json
  XML	application/xml
  XHTML	application/xhtml+xml

• 출처: http://www.ibm.com/developerworks/webservices/library/ws-restful/index.html
  

혼자 컴퓨터에서 쓰는 프로그램, 즉 워드나 파워포인트같은 1인용 프로그램의 성능을 판단하는 기준은?
응답시간(Response time)이다.
개인 사용자 관점에서 얼마나 반응이 빠른가가 가장 중요하고 이는 중요한 몇개의 기능에 대한 응답시간의 평균으로 그 성능을 판단할 수 있다.

그렇다면 웹 애플리케이션같은 다수의 사용자가 HTTP 요청을 통해 폼데이타와 HTML메시지를 주고받는 경우의 성능을 판단하는 기준은?
여러 요인이 있을 수 있지만 가장 의미있는 기준은 최대 TPS(Transaction Per Second)이다.
개인 사용자 관점에서야 응답시간이 중요할 수 있지만 웹 애플리케이션처럼 다수가 사용하는 경우 동시 접속자수가 증가하면 응답시간은 지속적으로 증가하기 때문에 응답시간의 절대적인 수치를 측정할 수가 없다. 반면에 TPS는 해당 웹 애플리케이션이 처리가능한 최대의 트랜잭션 양이므로 메시지 크기가 크게 다르지 않다는 가정에서는 일정 수준 이상 증가하다가 최대 수치를 기록한 이후 더이상 증가하지 않는다. 따라서 이 최대 TPS를 가지고 해당 웹애플리케이션의 성능을 상대적으로 비교하는 것이 가능하다.

이 TPS는 지금까지도 웹 애플리케이션의 성능을 평가하는 데 가장 중요한 요소로서 많은 벤치마크테스트에서 활용되고 있다. 그러나 최근 이 TPS만 가지고는 변화해가는 웹 환경에서 절대적인 기준으로 활용하기에 적합하지 않은 시나리오가 종종 발생하고 있으며 이는 조금씩 증가하고 있다는 느낌이다.
상황의 발단은 UCC나 Web 2.0시대로 접어들면서 과거보다 훨씬 큰 크기의 데이타가 한 트랜잭션에서 전송되는 테스트시나리오 및 고객 상황이 발생하고 있는 것이다.
즉 트랜잭션마다의 특성이 너무나 천차만별이기에 동일한 웹 애플리케이션으로 성능을 테스트하더라도 애플리케이션 특성상 다양한 크기의 데이타를 가지고 테스트해야만 하는 상황이 많이 발생하였다. 특히나 웹과 같은 오픈환경에서 멀티미디어 데이타 전송을 처리하려는 TELCO회사들에서 진행하는 벤치마크 테스트에서 자주 접해볼 수 있었다. 더욱이 클라우드 컴퓨팅의 시대에 접어들면서 더 많은 컴퓨팅 파워를 클라우드에 일임하고 그럼으로써 대용량의 트랜잭션 처리가 날이 갈수록 절실하게 요구되고 있다.

아래 그림에서 보면 WebApp1의 TPS는 4, WebApp2의 TPS는 1이다. 어떤 고객은 요청 크기가 커졌다고는 하지만 어떻게 TPS가 4이던게 1로 뚝 떨어질 수 있는가, 성능이 너무 떨어지는 것이 아니냐고 하지만 결과적으로 보면 두 상황은 동일한 성능의 다른 수치일 뿐 성능을 제대로 표현하고 있는 기준으로 이야기하고 있는 것이 아니다.




그래서 나는 최근에 경우에 따라서는 고객에게 TPS만이 성능을 판단하는 절대기준이 아니며 때로는 BPS (Bytes Per Second)가 더 유효한 성능 기준임을 강조하고 있다.

얼마 전 차세대 프로젝트를 하고 있는 모 사이트에 잠깐 들러서 일을 한 적이 있다. 1년 가까이 빡센 프로젝트를 진행하는 통에 사무실을 들어서자 마자 뭔가 그런 곳에서만 맡을 수 있는 묘한 포스를 느꼈다. 항상 그런 곳에서는 사람들의 눈빛과 얼굴빛 그리고 책상과 보드판을 살펴보게 된다. 누렇게 뜬 얼굴과 충혈된 눈, 업데이트가 되어있지 않은 일정 상황판, 퀘퀘한 냄새... 이것이 장기 프로젝트에서 흔히 보게 되는 사무실 모습이다.
장기 프로젝트는 거의 언제나 만족스럽지 못한 결과를 만드는 것같다. 그것은 나의 느낌뿐만 아니라 많은 선배들의 책에서도 언급되고 있다. 길면 길수록 프로젝트는 산으로 간다. 내가 갔던 그 사무실의 프로젝트도 산에 가있다고 사람들은 하소연을 하고 있다. 일정은 자꾸 지연된다. 거의 모든 장기 프로젝트에서 듣게 되는 하소연들...
당신이 어느 프로젝트에서 아키텍트가 되어 설계를 한다면 최대한 완벽을 기하려 할 것이다. 어떻게든 처음 설계할 때 모든 게 완벽하기를 바랄 것이다. 하지만 그것은 실패를 보장한다. 너무나 완벽해서 더이상 변하지 않는 설계면 누구나 해피하겠다. 개발자, 고객, 설계자 모두가 해피하겠다. 하지만 현실은 그렇지 않질 않은가?
그런데 문제는 현실이 그렇지 않음에도 불구하고, 그래서 실수와 변경과 잦은 재설계와 완벽할 수 없는 사람의 특성을 인정해야 함에도 불구하고 고객과 설계자와 그 외 모두는 그것을 잘 인정하지 못한다. 그것이 당연함에도 불구하고 인정하지 못한다. 애초에 설계했던 사람은 어떻게든 자신이 처음 설계한 것에서의 잘못을 잘 인정하지 못한다. 자존심때문이다. 인정하는 순간 고객은 꼬투리를 잡는다. 그리고 서로가 서로의 설계에 고집을 부리는 순간 프로젝트는 점점 산으로 간다.
기민한 개발과 설계가 중요한 것은 누구나 알고 있고 적용하는 것 역시 좋은 효과를 볼 것이다. 하지만 나는 그것이 현실적이기 어려운 이유는... 설계는 바뀌고 상황은 바뀌고 사람은 완벽할 수 없다는 것에 대한 이해를 모두가 하기 어려운 프로젝트의 특성때문이 아닌가 싶다.

전세계적인 금융위기에 모두가 움추려있는 때. 대한민국 기상청만한 예측능력을 가진 가트너 IT리서치 회사는 US에서 열린 'IT and The Economy'라는 컨퍼런스에서 내년도 전세계 IT예산 전망을 예측하였다.
약 3.6조 달러가 IT예산에 쓰일 것이며 이는 2008년의 3.4조 달러에 비하여 약 6% 증가하는 수치이다. 세부적으로는 전체 IT예산의 반 이상을 차지하는 텔레콤 쪽에서는 6%의 증가(2.1조달러)가 예상되고 소프트웨어와 IT서비스는 각각 8%와 7%의 예산 증가가 예상된다. 반면에 하드웨어 부분의 투자는 약 4%정도의 증가가 예상된다고 하였다.
극심한 금융위기에도 불구하고 IT예산이 우려에 비해 높게 책정될 것이란 예상을 하는 이유로는 비즈니스와 IT가 이제는 더이상 따로 떨어진 별개의 것이 아니라 긴밀한 협력관계에 있다보니 불황이라고 하여 쉽게 IT예산을 급감할 수는 없을 것이며 여러 해동안 진행되온 IT관련 투자 프로그램을 갑작스레 중단할 수도 없기 때문이라고 한다.
그러나 가트너 역시 내년의 세계 경제가 어떠한 상황이 될 지 예측할 수 없다는 측면에서 보았을 때 상당히 낙관적인 발표가 아니었을까 싶다. 가트너가 덧붙여 주장한 것은 US나 유럽, 일본등의 IT예산은 증가하기 어려운 반면 신흥 시장 즉 아시아쪽은 여전히 괄목할만한 IT예산 증가가 예상된다고 하지만 당장 중국이나 한국의 경제가 어떻게 될런지는 장담하기 어렵다. 더구나 US나 유럽이 어려우면 중국의 IT산업 역시 많은 투자를 하기가 쉽지 않을 수도 있겠다.
하지만 어쨌든 내년 IT투자 예산이 경기 하강처럼 큰폭으로 떨어지지는 않을 것임을 어느 정도는 예측해볼 수 있는 중요한 발표가 아니었나 싶다.

실제로 현재 경제적으로 많은 어려움을 겪고 있는 미국정부가 올해 내놓은 2009년 IT투자 예산은 생각보다 매우 공격적이다.
미국 정부의 2009년 IT예산은 올해 대비 3.8% 증가하였다. 아무리 경제가 어려워도 신성장 동력중의 하나인 IT에 대한 투자는 결코 소극적이어서는 안된다고 생각하는 부시 정부의 생각이 담겨있다. 비록 IT정책을 조율하는 별도의 부서가 있는 것은 아니지만 각 공공부서들이 각자의 분야에서 IT에 대한 투자를 매우 중요하게 생각하기 때문에 내년도 예산에서 IT투자가 차지하는 비중은 여전히 높은 것이다.

그렇다면 한국시장도 마찬가지일 것인가?
이미 들어 아는바와 같이 내년도 정부가 발표한 정부 정보화 예산은 올해 대비 7% 감소한 3조억원 가량이다. 더욱이 순수한 소프트웨어 관련 산업이나 벤처업체에 대한 지원의 확장에 대한 내용은 그다지 들어있지 않는 듯 하다. 그 중에는 문화컨텐츠 부분에 대한 투자 예산의 증액이 고무적이라고 할 수 있지만 전반적으로는 업계의 사람들로 하여금 허탈함을 줄 수 있는 수치인 것은 분명하다. 참으로 우려되는 부분이며 신성장 동력을 찾고자하는 현 정부의 주장을 고려해볼 때 의아스러운 모습이 아닐 수 없다.
아무튼 전세계 금융위기에도 불구하고 모두가 IT예산은 어떻게든 확보하기 위해 노력하는데 라디오나 붙잡고 앉아있는 대한민국 정부의 IT에 대한 인식이 자못 아쉽기만 하다.