어떤 사람이던 성장을 한다. 어려서부터 많이 먹고 자라서 키도 크고 몸무게도 커지면서 육체적인 성장을 하고 학교 등에서 배움으로 지식도 성장한다. 그리고 다양한 경험을 통해서도 성장하곤 한다. 특히 어려운 일을 당해서 곤욕을 치룬 뒤에 얻는 경험을 통한 성장은 매우 소중하다는 생각이 든다.

최근에 회사에서 일이 많이 몰려서 꽤나 바쁘다. 그것도 대형껀수로 2~3개가 한꺼번에 몰리니 정신이 없다. 그리고 그것 모두 회사 입장에서는 놓칠 수 없는 큰 금액이 걸려있기에 담당자인 나를 계속 쪼아대고 있는 상황이다. 쪼아대는 것이 적절치 못한 표현이라면 그렇겠지만 꼭 해야한다고 계속 압박하고 있는 중이다.

회사에서 내가 맡은 일이 여러가지가 있고 모두가 다 중요한 일이지만 그 중에서 서버 컨퍼넌트 모듈을 만드는 일이 있다. DRM 서버도 내가 맡았지만 지금은 밑에 직원이 와서 그 친구에게 넘겨줬고 DRM 적용 툴도 넘겨줬지만 DRM 서버 컨퍼넌트 모듈은 아직 못넘겨줬다. 솔직히 서버와 적용 툴은 어느정도 최적화가 되고 안정화가 된 상태여서 넘겨줄 수 있었지만 서버 컨퍼넌트 모듈은 어떤 환경에서 어떻게 적용될지 모르기 때문에 쉽게 넘겨줄 수 없었다. 게다가 서버와 적용 툴은 윈도 기반 응용 프로그램이지만 서버 컨퍼넌트 모듈은 윈도 기반, 리눅스 기반, 유닉스 기반 등 어떤 OS에서 돌아갈지 모르는 상황이고 또 웹서버 위에서 올라가는 모듈인지라 ASP가 될지 PHP가 될지 JSP가 될지 모르는 정말 다양한 변수가 존재하는 모듈인지라 못넘겨주고 그냥 내가 갖고 있는 상태였다.

이번에 E사에 DRM 서버를 업그레이드하면서 서버 컨퍼넌트 역시 업그레이드를 하는 작업을 했다. 그런데 예전까지는 서버 컨퍼넌트 모듈을 CGI로 만들어서 작업했는데 그것이 문제가 되어 이번에 JSP용 모듈로 교체하기로 한 것이다. 그래서 들어가서 서버 컨퍼넌트 모듈을 교체하는 작업을 하는데 문제가 생겼다. 제대로 올라가지 않는 것이다.

일단 E사의 환경부터 살펴보면 서버는 HP 서버 머신이고 OS는 HP-UX며 웹서버는 WebToB, WAS는 제우스를 돌린다. 이미 여러번 WebToB에 제우스 환경에서 JSP용 서버 컨퍼넌트 모듈을 만들어본 경험이 있었기 때문에 큰 문제가 없겠다 싶었다. 하지만 문제는 HP 머신 위에 HP-UX 위에서 올라가는 것은 처음해본 일이기 때문에(IBM 머신 위에서 AIX에서는 해봤다) 걱정이 앞섰다. 첫날에는 어떤 문제인지 제대로 파악도 못한 상태로 사무실로 들어와야 했다.

다음날에 다시 E사에 가서 그 서버에 붙어서 작업을 계속했다. 일단 JSP 모듈로 만들기 전의 라이브러리부터 검증하기 시작했다. 원래 윈도 기반의 모듈을 리눅스용으로 만들었고 그걸 다시 유닉스용으로 만들었기 때문에 플랫폼에 따른 설정의 차이로 문제가 생길 수 있겠다는 생각이 들었기 때문이다. 역시나 라이브러리부터 문제가 보였다. 그래서 하나하나 디버깅하면서 잡아내기 시작했다. 역시나 제일 큰 문제는 메모리 배열문제. 흔히들 Endian 문제라 말하는 int형 메모리 배치문제가 컸다. 윈도나 리눅스의 경우 Little-Endian을 사용하기 때문에 윈도 소스를 그대로 리눅스에서 사용할 수 있었지만 유닉스에서는 대부분 Big-Endian을 사용하기 때문에 메모리 배치를 바꿔줄 필요가 있었다. 솔직히 여기까지 알아내는데 이틀이 걸렸다. 그 전에는 왜 엉뚱한 값을 가져와서 에러를 내는지 알 수 없었으나 한참의 고민끝에 예전에 비슷한 경험을 한 것이 생각나서 혹시나 싶어서 알아본 것이 정답이었던 것이다. 결국 둘째날도 Endian 문제임을 확인하고 다시 사무실로 돌아왔다.

사무실로 돌아와서는 회사에 HP 머신과 HP-UX를 지원해달라고 요청했고 그 다음날 테스트를 할 수 있는 HP-UX가 설치된 HP 머신을 받아서 맹렬히 디버깅을 했다. Endian 문제를 해결하고 32/64비트 문제도 해결해서 라이브러리 단계에서의 디버깅을 끝낸 뒤에 JSP용 모듈로 만들어서 테스트를 했다. 그런데 라이브러리 테스트는 무리없이 끝났는데 JSP 모듈 테스트에서 계속 죽는 현상이 발견되었다. JSP용 모듈을 만드는데는 자바의 JNI 기술을 사용해서 만든다. 라이브러리는 C로 만들어졌기 때문에 자바 기반의 JSP 모듈은 결국 자바로 만들어야 했고 다른 언어를 자바로 적용시키는 JNI 기술을 이용해서 만들게 된다. 그래서 혹시 JNI를 사용하는 것에 문제가 있을까 싶어서 걱정을 했다. 나는 그 부분에 대해서는 모르기 때문이다. 자바에 대해서도 거의 모른다(기본적인 문법은 알지만). 그렇기 때문에 덜컥 겁이 났다. 회사 안에서도 이 부분에 대해서 아는 사람이 아무도 없기 때문이다. 주변에 이 부분에 대해서 물어볼 사람도 없다. 결국 내가 막히면 끝이라는 얘기다. 어쩔 수 없이 구글을 붙들면서 JNI에 대한 정보를 찾으면서 JNI 문제가 아닌 혹시 다른 문제가 아닐까 하는 생각으로 문제를 계속 찾아봤다.

그런데 재미난 것은 3개의 모듈이 올라가는데 1개는 올라가고 2개는 안올라갔다. 즉, JNI쪽 문제는 아니라는 얘기다. JNI쪽 문제라면 3개 모두 안올라가야 정상인데 1개가 올라갔다는 것은 JNI를 사용한 모듈이 제대로 동작하고 있다는 증거다. 그래서 내린 결론은 라이브러리를 만들때 사용하는 GCC(리눅스, 유닉스에서 사용하는 C 컴파일러)에서 버퍼 오버플로(할당된 메모리 영역을 넘어가는 것)를 제대로 못잡아주는데 JSP에서 사용하는 JVM(자바 가상 머신)에서는 그것을 귀신같이 잡아내주고 있다는 결론을 내렸다. JVM이 민감해서 GCC에서 못잡은 문제를 끄집어냈다는 의미다. 그렇다면 어디서 오버플로가 나는지 확인하는 일을 해야 했다.

그런데 문제가 생겼다. 어디서 오버플로가 나는지 어떻게 찾아내야 하나? GCC에서는 못찾았고 GDB를 이용해서 시도했지만 제대로 못잡아냈다. 결국 무식한 방법으로 라이브러리의 각 단계마다 주석처리를 하고 하나씩 풀어가면서 오버플로가 나는 부분을 찾아내기 시작했다. 컴파일하고 모듈 만들고 올리고 실행해서 에러가 안나면 다음의 주석을 제거하고.. 이런 방식으로 4시간을 돌려서 오버플로가 나는 부분을 찾을 수 있었다. 또 전날에 수정했던 Endian 문제도 다시 수정했다. 2개의 모듈에 문제가 있었는데 하나는 4시간이 걸렸고 나머지 하나는 3시간이 걸렸다. 여하튼간에 겨우 문제를 해결했다.

그리고 오늘. 다시 E사에 와서 작업을 하는데 첫날처럼 또 안되는 것이다. 왜 안되나 싶어서 계속 살펴봤는데 문제가 없어야 하는데 계속 문제가 있는 것이다. 게다가 에러가 나지 말아야 할 부분까지 에러가 나는 것을 보고는 황당했다. 하지만 흥분을 가라앉히고 찬찬히 살펴보니 라이브러리를 읽어들이는 경로에 변화가 생긴 것을 확인했다. 예전에 작업했던 경로가 아닌 그 한단계 앞으로 다 변경이 된 것이다. 계속 예전 경로로 라이브러리를 복사해두고 테스트를 했으니 에러가 나오는 수 밖에. 결국 제자리로 돌린 다음에 테스트를 하니 제대로 되는 것을 볼 수 있었다. 다행이라 생각해서 맘을 돌릴 수 있었다.

물론 현재 제대로 돌아가고 있는 것이 아니다. JSP용 서버 컨퍼넌트 모듈이 그 HP머신의 HP-UX에 맞는 모듈임을 확인은 했으나 WAS인 제우스의 환경설정에 제대로 안물려서 잘 돌아가지 않는 상황이다. 하지만 이 부분은 내가 해결해야 할 부분이 아니라 여기 서버 담당자가 해결해야 할 문제이기에 지금 담당자를 기다리면서 이렇게 블로그에 그동안에 있었던 일들을 쭉 풀어내고 있다.

DRM 서버 컨퍼넌트 모듈은 위에서도 얘기했듯 윈도나 리눅스, 유닉스 모두에서 돌아가도록 만들어야 한다. 그리고 어떤 웹 스크립트 언어를 사용했느냐에 따라서도 또 다 적용을 해야한다. ASP, PHP, JSP에 모두 적용이 가능해야 하니 그 가지수도 꽤 된다. ASP야 윈도의 IIS에서만 돌아가니 큰 문제는 없고(얘는 DLL로 만들어주면 된다) 문제는 역시나 PHP와 JSP. 윈도용으로 PHP와 JSP에 맞도록 DLL을 만들어주고 테스트를 해야 한다. 또 IIS용과 윈도 아파치용은 조금 다르다. 여하튼 변수가 좀 많다. 더 골때리는 것은 리눅스와 유닉스용이다. 리눅스용은 좀 괜찮은 편이다. 윈도와 비슷하기 때문에 큰 무리없이 적용을 시킬 수 있었다. 리눅스가 유닉스보다 덜 민감해서 어지간한 에러나 오버플로에도 잘 버틸 수 있다는 것도 리눅스용 서버 컨퍼넌트 모듈이 한결 쉬울 수 있는 이유다. 하지만 유닉스로 넘어가면 얘기가 달라진다. 솔라리스, HP-UX, AIX 등 유닉스 종류도 각기 다를 뿐만 아니라 메모리 배치도 다르고 JSP는 더 까다롭다. 이번에 겪었던 일로 확실히 유닉스가 왜 안전한지 알 수 있었던 계기가 되었다. 이렇게 까다로우니 어지간한 버그는 사전에 다 차단되지 않겠는가.

이번 일을 겪으면서 기존에 있었던 서버 컨퍼넌트 모듈 소스에 있었던 잠재적인 버그들을 다 잡을 수 있었다. 그것은 매우 큰 소득이었다. 언제 터질지 모르는 잠재적은 버그들이 수없이 많이 존재하고 있었는데 이번 디버깅을 통해 그런 버그들을 잡았으니 윈도와 리눅스용 모듈에 안정성을 더해줄 수 있을 것이다. 또 다른 유닉스(솔라리스, AIX 등)에서도 잘 적용할 수 있는 소스로 강화되었다는 것도 큰 소득이라 할 수 있을 것이다. 일주일동안의 고생이 단지 삽질로 끝난게 아니라는 것이다.

이번 일로 나 자신이 내부적으로 성장했음을 많이 느꼈다. 어떻게 디버깅을 해야 하는지, 어떻게 오버플로를 막아야 하는지, 어떤 OS에서든 어떻게 적용을 해야할지 등 수많은 경험을 몸소 느끼면서 내 자신의 기술적인 향상을 어느정도 이룰 수 있었던 계기가 되었다.

역시 엔지니어는 삽질을 통해서 성장하는거 같다.

* 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

 학주니닷컴의 포스트을 읽고 괜찮으셨다면 여러분의 RSS 리더에 구독하세요~ ^^;

MS가 야후 인수를 위해 단단히 결심을 한 모양이다. 적대적 M&A를 고려한 야후 인수의 모든 방법을 다 동원하겠다고 한다. 즉, 적대적 M&A를 위한 준비절차에 들어갔으며 MS 이사회에서 곧 승인이 날 것이라고 한다. MS 입장에서는 어떻게든 야후를 인수하여 인터넷 시장에 기반을 확실히 다지겠다는 의지를 보일려고 하는 것이다.

MS가 야후를 인수하기 위해 위임장 대결을 생각하고 있다고 한다. 위임장 대결은 일반 주주들에게 권리를 위임받아서 주주총회때 야후 이사진과 표대결을 벌이겠다는 것이다. 일반적으로 기업에서 적대적 M&A를 할 때 많이 사용하는 방법이라고 한다. 야후의 주주총회는 작년에 6월에 열렸다. 올해도 6~7월쯤 열린다고 가정했을 때 MS는 대략 2~3천만달러정도를 M&A 컨설팅 고용과 주주들의 연락 등에 사용할 것이라 한다. 그러나 2~3천만달러는 야후의 주가가 1달러씩 올라가면서 지출하게 될 돈에 비해서는 무척이나 저렴한 것이다. MS의 CEO인 스티브 발머는 야후 주식을 주당 31달러로 책정한 것은 매우 적절하다고 주장하고 있다. 야후의 주식을 더 높게 쳐주지는 않겠다는 것이다.

야후 역시 M&A 방어를 위해 나름 노력하고 있는 듯 하다. 그러나 1000명을 감축하는 등 경영상태가 악화되어있는 상태에서 야후가 내놓은 방안이 논란이 되고 있는 듯 하다. 야후 입장에서는 인수가 되더라도 챙길 것은 챙기겠다는 복안인듯 싶다.

빌 게이츠 MS 회장 역시 MS가 인터넷 사업쪽으로 더 발전하기 위해서는 야후의 우수한 인력이 필요하다고 말했다. 야후의 인수로 야후의 핵심 엔지니어들을 끌어들여서 구글과의 격차를 최대한 좁혀야 한다는 것이 MS가 앞으로 해야 할 일이라는 것이다. 야후 인수에 있어서 MS의 최악의 시나리오는 야후 인수에는 성공했으나 핵심 엔지니어들이 다른 회사로 이적하는 것이다. 어느 서비스든 서비스 자체보다는 그 서비스를 운영하거나 만든 엔지니어의 가치가 더 높은 것은 당연한 것이다. 모든 서비스의 질은 그것을 개발하고 운영하는 사람에게 달렸다는 것은 서비스에 있어서 만고의 진리다. MS가 노리는 것은 야후의 서비스들 보다는 우수한 야후의 엔지니어들이다.

이렇게 공격적으로 MS가 야후의 인수에 대해서 나오는데 구글은 어떤 반응을 보일지 모르겠다. 1차 MS의 인수제안을 거부하는데 한몫했던 구글은 AOL 등과의 공동전선으로 MS의 야후 인수를 어떻게든 방해할 것임은 당연하기 때문이다. 하지만 여전히 엄청난 자금력을 지닌 MS의 이런 공격적인 야후 인수 움직임에 구글은 어떻게 맞설 것인가를 지켜보는 것도 재밌을 듯 싶다. 당사자들은 죽어나겠지만 말이다.

* 관련 뉴스 *
‘야후 적대적 인수’ 칼뽑은 MS (조인스닷컴)
빌 게이츠「구글 이기려면 야후의 인재 필요」 (ZDNet Korea)
Microsoft-Yahoo Battle Getting Expensive. Should Microsoft Give Up? (TechCrunch)

* 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

 학주니닷컴의 포스트을 읽고 괜찮으셨다면 여러분의 RSS 리더에 구독하세요~ ^^;

프로젝트 이름부터 의미심장하다. 화려한 휴가. IT업종 종사자들, 특히 SI나 보안관련 업체쪽 종사자들이 주로 공감할 듯 하다.

IT종사자 프로젝트명「화려한 휴가」(ZDNet Korea)

많은 경우의 회사 내 전산 담당자들은(대표적으로 서버 관리자들이나 보안관제 담당자들, 혹은 타기업의 솔루션 프로젝트를 담당해서 진행하고 있는 SI업체 담당자들) 휴가나 휴일도 아마 쉬는거 같지는 않을 것이다. 일만 터졌다 싶으면 쉬고있는 중에도 언제든지 회사로 달려가거나 근처의 인터넷이 연결되는 PC를 찾아서 문제를 해결해야 하기 때문이다. 그렇기 때문에 이들은 휴가중에라도 휴대폰의 전원을 늘 켜놓고 있어야 하며 언제 어떻게 전화가 올지 모르기 때문에 늘 긴장하고 있어야 한다.

나 역시 예전에 SI 업체쪽에서 일하면서 다른 회사의 네트워크 솔루션을 공동 개발한 적도 있었고 지금 다니는 회사에서도 SI는 아니지만 다른 회사와 협력관계로 일하면서 많은 일들이 터지면 휴가 여부를 떠나서 새벽이라도 회사에 나와서 일을 해야하는 경우가 많았다. 다만 지금은 예전보다는 그런 경우가 덜하다는게 그나마 다행이라고나 할까. SI쪽에 일하고 있을 때에는 정말 월화수목금금금이라는 말처럼 주말도 없었다. 쉬는날 나와서 근무하는 것은 기본이요 야근, 철야는 밥먹듯 하고 새벽에도 자다가도 호출받아서 출근해서 일해야 하는 경우도 종종 있기 때문이다.

한때 IT종사자들의 비애라는 주제로 몇개의 글들이 떠다니는 적이 있었다. 대부분의 IT업종 종사자들은 공감하는 내용이었다. 진짜 심한 경우에는 IT 엔지니어(특히나 SI쪽에서의 갑을병정에서 병이나 정에 해당하는 경우)들은 사람취급도 못받을 경우가 있었다. 휴가때도 갑이나 을의 눈치를 보면서 늘 휴대폰을 켜놓고 있어야 하고 휴가중에도 일이 터지면 호출받아서 나와서 일해야 하며 반납된 휴가를 보상도 못받고 지내는 경우가 대부분인 것이 오늘날 우리 한국의 SI(넓은 의미의 IT)의 현실이다. 그렇다고 휴대폰 등 연락할 수 있는 연결을 끊게 되면 휴가 후 자기의 책상이 없어지는 황당한 꼴도 많이 당하는 것이 우리네 IT 업종의 현실이다. 갑의 위치에 있는 회사는 을 이하 나머지 협력업체가 말 잘듣는 개를 원하지 주인의 뜻을 거스리는 사나운 개를 원하지 않기 때문이다. 그렇기 때문에 울면서도 어쩔 수 없이 일을 하는 것이다.

대부분의 서비스들이 웃긴것이 휴가때나 쉬는 날에 장애가 더 많이 나온다는 것이다. 머피의 법칙도 아니고, 꼭 새벽때나 주말, 아니면 자신이 휴가를 받아서 쉬는 날에 더 많은 장애를 기록한다. 차라리 일하고 있는 주중의 낮에 장애가 일어나면 업무중이니 언제든지 처리할 수 있지만 장애라는 것이 시기를 가리고 나타나는 것도 아니고 무작위로 아무때나 톡톡 나오는 건지라 예측할 수 없으니 늘 가시방석에 앉아있는 기분일 것이다. 같이 일하는 사람이라도 많으면 나눠서 할 수 있겠지만 현재 한국의 IT 업무 종사자들은 개인이 맡은 하나의 일은 그 개인만 담당하는 경우가 많기 때문에 담당자가 자리를 비웠다면 일을 처리할 수 없다는 단점까지 안고 있는 현실이다. 이것이 현재 IT 업무 종사자들의 현재 상태라고 할 수 있겠다.

휴가도 휴가같지 않게 보내고 결혼을 했으면 와이프나 아이들에게 좋은 소리 못듣고, 결혼을 안했더라도 애인이나 있으면 애인에게 싫은 소리를 듣는 것이 우리네들 IT 업무 종사자들의 비애가 아닐까 싶다. 정말 영화 '화려한 휴가'처럼 말이다.

* 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

 학주니닷컴의 포스트을 읽고 괜찮으셨다면 여러분의 RSS 리더에 구독하세요~ ^^;

CNetNew.com에서 마이클 카넬로스가 쓴 칼럼이 ZDNet Korea에 번역이 되어 올라왔다. 해석에 약간 이상한 점이 있어서 원문을 볼려고 했는데 CNetNews.com에서 찾아볼려고 했으나 못찾았다. 그래도 읽어볼만한 글이다 싶어서 링크를 걸어본다.

첨단산업의 메카 미국, 이대로 주저앉을 것인가 (ZDNet Korea)

현재 미국의 침체기에 대해서 논한 글이다. 간략하게 정리해보자.

SIA(Semiconductor Industry Association) 회장 조지 스칼리제(George Scalise)는 몇 년동안 미국의 쇠퇴를 주장해왔다. 그 중심에는 아시아가 있다는 것이다. 몇 년전부터 아시아는 생산의 중심이 되었다. 예전의 하청업에 불과했던 아시아는 이제는 칩 등의 하이테크 첨단 기술 제조 분야로 그 영역을 넓혀가고 있다(이미 반도체 분야쪽에서 한국의 삼성과 같은 회사는 미국 회사들의 역량을 넘어셨다고 본다). 그리고 세계 첨단 칩 기술의 투자를 담당했던 미국의 투자율이 점점 줄어들고 있다. 35%에서 지금은 10~12%정도밖에 안된다는 것이다. 그 중심에는 중국이 있다. 현재는 미국에서 건너간 엔지니어들이 중심으로 활동하고 있지만 머지않아 자체적으로 엔지니어를 발굴해서 그들이 이끌 것이다. 게다가 현재 HDD의 최대 생산국은 태국이다. 이렇듯 아시아로 생산의 중심이 넘어가고 있음을 우려하고 있다.

미국 대학들도 세계화 되어가고 있다고 한다. 그 예로 코넬은 카타르에 의대를 운영하고 있으며 카네기 멜론과 텍사스 A&M도 카타르에 4년 코스의 엔지니어링 프로그램을 개설했다. 또 메사추세츠 공대는 아부다비의 대체 에너지 전문 대학원 설립을 지원하고 있다. 싱가포르 정부는 바이오폴리스(Biopolis) 바이오테크 허브에 필요한 거물급 교수 영입에 나섰으며, 미국 스타일의 메디컬 스쿨을 설립하기 위해 듀크 대학과 협력하고 있다. 왜 이렇게 되었는가? 대학들은 이렇게 해야 재정문제나 비자문제로 인해 미국으로 유학을 올 수 없는 해외의 우수한 학생들을 끌어들일 수 있다는 것이다. 이 부분에서 그들은 걱정을 하고 있다. 우수한 인재들이 미국에 와서 공부해야 할 이유가 사라지고 있기 때문이다.

대중문화도 세계화 되어가고 있다고 한다. 미국 문화를 극도로 열광하는 몇몇 소수를 제외하고는 값싼 대중문화가 영어권 문화를 장악했다고 한다. 애니메(Anime)는 카툰(cartoon)을 지배한다. 예로 중국에서는 200여개 이상의 유튜브 모델을 만들어내고 있으며 몇개는 현재의 유튜브를 능가한다. 또한 구글은 중국에서 바이두에 밀려 힘을 못쓴다. 이것은 한국에서도 마찬가지다. 구글, 야후 등의 글로벌 기업도 네이버를 필두로 한 한국의 포털에 밀려 제대로 힘을 못쓰고 있는 현실이다. 신흥 시장으로 비즈니스를 확대할 수 있는 황금 같은 기회는 이미 사라진지 오래다.

필자는 이러한 현실에서 4가지 아이디어를 제시했다.

첫 번째는 실패를 겸허히 수용하라는 것이다. 그것은 좌절하지 말라는 이야기다. 미국의 경우 정리해고가 관용적으로 수용되고 있는 나라다. 언제든지 기업 상황이 좋지 않으면 종사자들은 언제든 나갈 준비를 해야한다. 이런 상황은 늘 있다. 이런 상황에서 좌절하지 말고 새로운 길을 모색하는 기회로 삼으라는 이야기다.

두 번째는 영주권 허용을 확대하라는 이야기다. 재능있는 해외 유학생, 엔지니어, 석사, 박사들을 계속 끌어모으라는 이야기다. 위에서 언급했든 미국 대학들이 세계화 되어서 미국 내에서 학생들을 유치하는 것이 아니라 밖으로 나가서 유치하고 있다. 그것은 미국 안에서 뛰어난 인재를 수용하고 발굴하는 것이 아니라 오히려 밖으로 빼앗기는 결과를 초래할 수 있다고 한다.

세 번쩨는 미국의 학교 시스템이 얼마나 간단한지 강조하라는 이야기다. 그 이야기는 미국으로 많은 학생들이 유학을 올 수 있도록 적극 장려하고 홍보하라는 이야기다. 두 번째 이야기와 비슷한 맥락에서 해석할 수 있다. 우수한 인재들을 미국 안에서 활용할 수 있도록 만들라는 이야기다.

네 번째는 기업에 보조금과 세제 혜택을 제공하라는 것이다. 기업이 좀 더 활동하기 좋은 환경을 만들라는 것으로 해석할 수 있다.

위의 내용들은 미국 입장에서 쓴 글이라 한국에서의 적용은 솔직히 힘들다는 것이다. 얼추 정리는 해봤지만 내가 봐도 맞는 이야기다. 현재 미국은 침체기에 접어들었고 선두를 지키던 여러 분야에서 타국(특히 중국)에 밀리는 모습을 보였다. 그런 부분을 생각할 때 미국이 다시 회생할려면 위의 4가지 아이디어 이외에도 획기적인 변화가 필요할 때가 아닌가 싶다.

다른 것은 몰라도 하도 국내에서 IT업종에 대한 서러움들이 쌓여있어서 그래도 국내보다 대우가 좋은 미국쪽으로 갈려고 하는데 여러가지 걸리는게 있어서 실행을 못했다. 그런데 두 번째 이야기처럼 영주권 허용이 확대되면 미국으로 해외 취업이나 이민이 쉬워질듯 하기는 하다. 그게 좋은 것인지 나쁜 것인지는 후에 알게 되겠지만 말이다.

* 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

 학주니닷컴의 포스트을 읽고 괜찮으셨다면 여러분의 RSS 리더에 구독하세요~ ^^;

하도 ZDNet Korea가 업데이트가 안되서 답답했는데 이번에 가보니 동작은 하더라. 그래서 못다한 기사나 칼럼등을 쭉 읽어보고 있었다. 그리고는 다음의 칼럼에 눈이 꽃혔다.

웹 애플리케이션 전쟁 본격화 되나? (ZDNet Korea)

칼럼에서는 구글 기어(Google Gear)를 차세대 웹 플랫폼의 모델로 지목을 했다. 구글 기어란 뭔가? 간단한 것이다. 일반적으로 웹을 통한 정보 전달은 말 그대로 웹을 통해서고 그것은 곧 온라인에서 전달됨을 의미한다. 인터넷이란 온라인에서 의미가 있다. 그런데 이 부분을 오프라인까지 확대하겠다는 것이다. 구글 기어는 파이어폭스와 같은 웹 브라우저의 플러그인 형식으로 제공되며 온라인일 때 데이터들을 웹 브라우저의 데이터베이스에 저장해뒀다가 오프라인일 때 온라인떄와 같이 저장된 데이터를 보여주겠다는 것이다. 이것은 웹 브라우저의 캐시와 비슷하다는 생각을 갖게 된다. 저장해뒀다가 꺼내쓴다는 개념은 비슷하기 때문이다. 온라인일때 지속적으로 새로운 데이터가 오면 업데이트 한다는 부분까지가 구글 기어의 개념이라고 보면 된다. 현재는 구글 리더에 적용되고 있다. 즉, 구글 리더에 구독된 RSS를 저장해뒀다가 오프라인일 때 구글 리더로 저장된 RSS를 온라인일때처럼 보여준다는 것이 구글 기어라고 할 수 있다. 난 아직 설치를 안해봐서 어떻게 동작하는지 실제로 본적은 없지만 찾아보니 이렇다.

차세대 웹 플랫폼으로 구글 기어를 지목한 이유는 바로 온/오프라인의 통합모델이라는 것이다. 위에서도 언급했지만 웹을 통한 정보의 전달은 노트북이나 PDA, PMP, 휴대폰 등 기기가 인터넷에 연결되어 있을 때 가능한 것이다. 웹 브라우저는 늘 새로운 정보를 웹을 통해서 보여줄려고 시도를 한다. 연결이 끊어지면 새로운 정보를 받을 수 없기 때문에 의미가 없다. 온라인과 오프라인 사이의 갭이 너무 크다는 것이 현재 인터넷 웹 플랫폼의 한계라고 볼 수 있다. 그래서 그러한 갭을 줄이고자 구글 기어에서 사용하는 온라인 때 정보를 저장하고 오프라인 때에도 저장된 정보를 활용한다는 전략이다. 구글 기어는 그 선구자 역할을 할려고 하고 있다고 보여진다. 기술적으로는 파이어폭스 등의 웹 브라우저에서 SQLite를 지원하기 때문에 그것을 이용한 DB 저장이라는 것이고, API가 공개되었으니 잘 이용하면 비슷한 효과를 거두지 않겠는가 하는 것이다.

내가 봤을 때 해외에서는 효과가 있겠지만 과연 국내에서는 어떨까 하는 생각이 든다. 위에서 언급했듯 구글 기어와 같은 모델이 나온 것이 온/오프라인의 갭이 크기 떄문이었다. 사무실 안에서나 집에서는 충분히 인터넷을 사용하기 때문에 구글 기어와 같은 모델은 의미가 없고 인터넷 연결이 어려운 집이나 사무실 밖에서의 사용환경에서 그 의미를 찾을 수 있겠다. 그런데 국내에서는 이제 WiBro와 HSDPA와 같은 무선 신기술들이 계속적으로 개발되어가고 있다. 아직 보편화되지 않았고 제대로 보급화나 인프라 구축이 잘 안되어 있지만 국내 시장에서 빠르게 무선 통신망이 자리를 잡아가고 있는 이 시점에서 과연 오프라인을 대비한 전략이 제대로 먹힐 것인가 하는 부분에 있어서는 의문을 갖게 된다. 앞으로 한국은 내가 봤을 때 실내외 모두가 온라인으로 연결될 수 있는 그러한 인프라가 구축될 것이기 때문이다. 유선의 인터넷 속도만큼 무선도 빨라졌다. WiBro나 HSDPA는 내가 듣기로 시속 100km로 달리는 기차안에서도 꽤 높은 수준으로 업로드, 다운로드가 가능하다고 한다. 비행기와 같은 약간 통신 사각지대만 제외하고는 지상에서 가까운 모든 장소에서는 인터넷이 가능하다는 얘기가 된다. 모든 상황에서 온라인이 되어버리니 오프라인을 대비한 구글 기어와 같은 솔루션이 국내에서는 어느정도 위력을 발휘할 수 있을지는 모르는 일이 되어버렸다.

그렇다고 구글 기어가 가져다주는 의미가 퇴색되는 것은 아니다. 온/오프라인의 갭을 줄이기 위한 노력과 그 기술은 정말 대단하다. 잘은 모르겠지만 구글 기어를 적용한 구글 리더를 사용하는 네티즌은 온라인이나 오프라인이나 비슷한 수준으로 구글 리더를 통해서 블로깅을 할 것이다. 이러한 노력과 더불어 웹 브라우저에 SQLite를 이용한 API의 공개로 다른 형식의 어플리케이션을 만들 수 있다는 장점도 있으니 구글의 저런 노력은 칭찬해줘야 하며 계속 독려해서 다른 기술들도 개발하고 활성화 시키도록 해야 한다. 물론 우리네들 엔지니어들도 그러한 부분에서 아이디어를 제공받아서 비슷하거나 아니면 다른 기술을 만들수도 있고 말이다.

구글 기어에 대한 국내 시장의 반응은 해외처럼 뜨겁지는 않을 것이다. 하지만 위에서 언급했듯 구글 기어와 같은 아이디어를 이용해서 새로운 웹 애플리케이션을 개발할 수 있다면 그것은 뜨겁지는 않아도 의미가 있는 반응이 될 것이다.

* 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

 학주니닷컴의 포스트을 읽고 괜찮으셨다면 여러분의 RSS 리더에 구독하세요~ ^^;

IT업종에 다니는 엔지니어들 사이에서 거의 성전화 되고 있는 글입니다. 정말 100% 공감합니다.

IT맨, 내가 사직서를 쓴 이유 (MoveOn21)

한국의 모든 IT 기업들은 정신 차려야 합니다. 그리고 쪼이면 한다고 생각하는 PM들이나 '갑'쪽 사람들도 정신 차려야 합니다.

한국에서는 IT 엔지니어들은 제대로 평가 못받고 삽니다. 차라리 해외로 나가는 것이 훨씬 이득이라고 봅니다. 저도 할 수만 있으면 나가고 싶습니다. 가까운 일본이라도 말이죠.

해외에서는 한국 엔지니어들을 높게 쳐준다고 하는데 어디 좋은 자리 없을련지. -.-;

* 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

 학주니닷컴의 포스트을 읽고 괜찮으셨다면 여러분의 RSS 리더에 구독하세요~ ^^;