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

최근에 회사에서 일이 많이 몰려서 꽤나 바쁘다. 그것도 대형껀수로 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의 2007 DevDay에서 김명호 박사가 SW 개발자에 대해서 언급한 내용이 있다.

SW 개발자의 길, 아니다 싶으면 포기하라! (ZDNet Korea)

SW 개발자는 전문가로 거듭나야 하며 개발자와 기획자는 엄연히 다른 영역이라고 말하면서 다음의 지침을 내놓았다.

1. 기본에 충실해야 한다.
2. 지식의 포트폴리오를 유지하라.
3. 분야 전문가나 해박한 지식을 갖춰라.
4. 학습을 두려워 마라.
   

모두 개발자라면 공감하는 내용이라 본다.

기본에 충실해야 하는 것은 당연한 일이다. 최근 IT 업계로 쏟아져나오는 개발인력들은 대부분 비트교육센터나 삼성멀티캠퍼스 등의 IT교육기관을 거쳐서 기술적인 부분을 습득한 상태로 나오게 된다. 그런데 문제는 이 인력들이 모두 전산과나 컴퓨터공학과, 혹은 정보통신관련학과 등 IT 계열 개발 관련학과 출신은 아니라는 것이다. 공대출신은 맞지만 전산계열이 아닌 타계열 학과 출신들도 많으며 이과가 아닌 문과출신도 상당수 존재한다는 것이다. 전산계열 학과출신들은 그래도 대학에 다닐때 기본적인 전산관련 지식들을 습득하고 나온다. 그렇기때문에 어느정도의 기본지식은 갖춰져있다고 봐도 좋을 것이다. 하지만 타계열학과출신들은 전산관련 기본지식이 없는 상태에서 교육기관에서 배우는 응용지식만을 갖고 실전에 투입하게 된다. 즉, 기술적 지식기반이 없는 상태에서 기술요령만을 익히고 나온다는 이야기다. 당장에는 그 능력을 활용할 수 있겠지만 어느정도 시간이 지나면 교육받은 기술요령은 곧 바닥을 드러내고 도태되어버리는 것이 현실이다.

기본에 충실하게 되면 새로운 기술이 나와도 대부분 학교에서 배운 기본지식 위에서 응용하는 것들이 대부분이기 때문에 조금만 노력해서 공부하면 어렵지않게 습득하고 응용할 수 있다. 하지만 기본이 약하면 새로운 기술이 나와도 기본과 연계되는 부분을 찾지못해 해매게 되며 아예 새로운 기술을 처음부터 다시 시작해야 하는 어려움이 있다. 그렇기 때문에 기본에 충실해야 하는 것이 중요하다. 이론적인 바탕없이 기술적인 내용만 안다면 분명 스스로 막히는 부분이 있을 것이다. 그리고 발전없이 지내다가 결국 뒷전으로 밀리는 꼴이 되어버린다.

지식의 포트폴리오를 유지하는 것도 중요할 것이다. 일반적으로 보편화되어있는 기술들이나 지식들을 습득하는 것도 중요하지만 그와 함께 자기만의 기술을 계속 개발해서 일반 기술 속에 요긴하게 써먹을 수 있도록 해야한다. 개발자는 남들이 다 하는 그러한 기술만을 구사해서는 도태될 수 밖에 없다. 남들이 다 아는 기술 속에 나만이 아는 기술을 갖고 있어야 대접받는 개발자가 될 것이다. 자기만의 전문기술을 계속 키워야 하는 것이 중요하다. 나만의 라이브러리를 갖는 것은 내 재산을 늘리는 것, 혹은 내 필살기를 키우는 것과 마찬가지일테니까 말이다.

분야 전문가나 해박한 지식을 갖추는 것도 중요하다. 말 그대로 개발자는 자기가 있는 분야에서 전문가여야 한다는 것이다. 개발을 하다보면 어떤 문제가 생길지 모른다. 디버깅을 하면서 문제가 생기면 해결을 해야하는데 해당 분야의 전문가라면 그 문제의 본질을 파악하고 그 원인을 없애는 기술을 사용할 것이다. 전문가가 아니기 때문에 땜빵식의 코드를 사용하고 나중에 그 코드가 또 다른 문제를 야기하는 원인이 되어버리는 악순환이 이어진다. 또한 다양한 지식을 갖추게 되면 자기 분야에 연계해서 더 고급스러운 개발을 할 수 있다. 메인 분야에 대해서는 전문가 수준의 지식을 갖추고 관련 분야에 대해서는 어느정도 일정 지식을 갖추게 되면 어떤 돌발적인 상황이 닥쳐도 당황하지 않고 해결할 수 있는 실력을 갖추게 되는 것이다. 개발자는 말로 하는게 아니라 실력으로 보이는 것이기 때문이다.

학습을 두려워해서는 안된다. 개발자는 끊임없이 공부해야 한다. IT 세계에서 신기술은 계속 쏟아져나오고 있다. 그 주기도 점점 짧아지고 있으며 IT 트랜드 역시 시시각각 변화하고 있다. 이렇게 엄청나게 빨리 변화하는 IT 세계속에서 살아남기 위해서는 계속 관련 지식을 습득해야 한다. 기본에 충실한 개발자라면 새로운 기술이 나와도 기본에 입각하여 손쉽게 습득할 수 있겠지만 그렇지 못한 개발자라면 부지런히 공부해서 기본을 충분히 익히면서 새로운 기술에 대한 공부도 병행해서 해야할 것이다. 기본에 충실하다면 새로운 기술이나 트랜드에 겁먹을 필요는 없다. 다만 계속 공부를 해서 시대에 뒤떨어지는 개발자가 되어서는 안된다는 것이다.

김명호 박사가 제시한 지침도 중요하지만 무엇보다 중요한 것은 자신이 개발자로서의 소양이 없다고 판단한다면 과감히 이 길을 버리고 다른 길로 가야 한다는 점이다. 어떤 직업이든 적성이 중요하다고 보는데 개발자로서의 적성이 안맞는데 억지로 이 길로 간다면 스스로에게도 힘든 일이며 도태될 가능성이 크기 때문이다. 개발자가 아니더라도 다른 분야에서 전문가는 충분히 될 수 있다는 점을 생각해야 한다(솔직히 이 부분은 이 길에 접어든 현직 종사자들에게 참으로 눈물나는 이야기다. 또한 나는 이 얘기에 동의하지 않는다). 개발자도 적성에 맞아야 한다는 것이다.

현재 IT가 3D업종으로 전락하고 있는 결정적인 이유로는 IMF때 나온 IT 육성정책과 개발자를 제대로 대우하지 않는 IT업계 경영자들의 생각부재에 있다고 본다. 외환위기때 돌파해보겠다고 IT 육성정책을 내놓은 것은 좋았는데 실제로 소득있는 정책이 아닌 그저 단시일에 실천할 수 있는 정책만을 내놓아서 지금의 수많은 개발자들이 나오게 되었다. 또한 대한민국 IT의 현실이 주로 SI쪽에 몰려서 프로그램 전문가들 보다는 그저 코더(프로그램을 코딩하는 사람)만 필요로 하게 되었다는 것이다. 그러다보니 경영자들은 개발자를 그렇게 높게 대우하지 않게 된다. 여러 다른 이유들도 존재하겠지만 말이다.

김명호 박사는 개발자들에게 이제는 무한경쟁체제에 돌입해야 한다고 말하고 있다. 스스로 계속 노력해서 전문가가 되는 소수의 개발자들만 살아남게 될 것이라고 한다. 실제 회사에서 일을 하는 사람들은 소수에 불과하다. 나머지는 그 소수의 일을 서포트해주는 역할에 지나지 않는다는 점이다. 핵심 인력이 되기 위해서는 위에서 언급했던 4가지 지침을 잘 지켜서 스스로를 더 업그레이드 시키는 것이 중요하다는 점이다.

글쓴이 : 학주니

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

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

현재 한국 웹 시장의 상황은 어떨까? 아니, 조금 더 범위를 좁혀서 웹2.0이라는 시장에서의 상황은 어떨까? 한국은 현재 Winner takes all 시장을 형성하고 있다고 한다.

웹2.0 시대, 웹 기업의 미션 (ZDNet Korea)

Winner takes all은 도대체 뭔가? 영어 그대로 해석하면 ‘승자가 모든 것을 다 취한다’는 것이다. 그리고 그 뜻대로 현재 한국 웹 시장에서 각 분야에 따라 No.1 기업들이 시장의 많은 부분을 차지하고 있다고 보여진다. 보통 50% 이상이며 심하면 80% 정도까지 점유율을 차지하고 있다고 보여진다.

예를 들어서 포탈 사이트에서의 네이버가 그렇고 웹 소핑몰(혹은 마켓프라이스 시장)에서는 G마켓과 옥션이 그러하며 인터넷 구인 시장에서는 잡코리아가 그 대표적인 경우다. 이들 서비스들은 해당 분야에서 적게는 50%, 많게는 8~90%까지 그 점유율을 차지하고 있다. 2위와의 격차가 엄청나게 벌어지고 있는 셈이다.

그리고 그러한 서비스들의 원천은 트래픽과 방문자수에 있다. 위에서 말하는 서비스들은 각 분야에서 독보적으로 트래픽 유입과 방문자수를 자랑하고 있다. 그렇게 때문에 새로 진입할려는 신규 서비스나 기존에 서비스를 했던 서비스나 모두 트래픽과 방문자수를 확보하기 위해 노력하고 있으며 그것은 곧 이미 다른 서비스를 사용하는 사용자들까지 끌어모을려고 하는 시도로 이어지게 된다. 즉, 새로운 트래픽이나 방문자수의 증가보다는 제살 깎아먹기에 지나지 않는다는 이야기다.

선두하는 서비스에서 성공한 서비스들을 후발 주자들은 똑같지는 않지만 비슷한 컨셉으로 따라하게 된다. 물론 기존 서비스보다는 더 좋은 기능을 첨가하지만 기본 골격은 결국 같다는 이야기다. 그렇기 때문에 시장에서 각 분야마다 서로 비슷한 모양의 서비스들이 자기가 잘났다고 각축전을 벌이고 있는 셈이 되었다. 비슷비슷한 놈들끼리 도토리 키제기를 하고 있는 셈이다.

한국에서는 이미 미국에서 얘기하고 있는 웹2.0 컨셉을 먼저 실현한 서비스들이 많다. 네이버의 지식iN이 그렇고 싸이월드 미니홈피가 그러하며 판도라 TV가 UCC의 대표주자로 나설 수 있을 것이다. 이들 서비스들은 국내에서 웹2.0 유행이 일어나기 전부터 기반을 닦아놓고 서비스를 하고있던 서비스들이다. 우리가 알고있는 웹2.0 컨셉과 거의 비슷하거나 동일하다고 보면 된다.

하지만 왜 국내에서 서비스를 했던 많은 웹2.0 서비스들이 웹2.0과 비슷하기는 하지만 미국 등에서 말하는 웹2.0과는 차별화되어 저평가를 받고 있는가? 국내에서는 저런 서비스들이 웹2.0의 어떤 기술을 기반으로 만들어졌지만 실제로 웹을 통해서 구현하고자 하는 부분을 제대로 실현하지 못하고 있기 때문이라고 기사에서는 전하고 있다. 즉, 웹2.0의 기본 철학인 참여, 공유, 확산의 3가지 철학을 비지니스 마인드에서 실천하지 못하고 그저 비지니스 스킬의 업그레이드로만 활용했기 때문이라는 것이다.

확실히 네이버의 지식iN은 위키피디아의 컨셉과 비슷하지만 위키의 경우 다른 사용자들이 수정할 수 있지만 지식iN은 그렇지 못하다는 단점이 있다. 또한 외부에서의 검색도 막혀있는 상황이라 그저 네이버 안에서의 서비스에 불과하다는 평이다. 싸이월드 미니홈피 역시 마이스페이스보다 앞서 나왔고 기능이나 파급력 역시 뛰어났지만 싸이월드 안에서만 통용되는 서비스다. 즉, Open API 등의 지원이 미흡하고 외부로의 연결이나 매시업 등이 불가능하기 때문이다. 판도라 TV의 경우 구글의 YouTube와 비견될 수 있을 것이다. 그러나 ActiveX의 사용이나 동영상 공유라는 뛰어난 업적에도 불구하고 제약사항이 많은 점이 YouTube와 비교되는 부분이라 할 수 있겠다.

왜 저런 현상이 일어났는가? 웹2.0의 기술적인 부분만 가져와서 비지니스의 기술만 업그레이드 할려고 노력했을 뿐 진정한 웹2.0의 철학적인 부분은 가져오지 못했다는 것이다. 위의 어떤 것들도 제대로 웹2.0의 철학인 참여, 공유, 확산을 실현한 서비스는 없다(판도라 TV의 경우는 예외일 수는 있겠지만 말이다). 외국의 웹2.0 서비스들에 비해서 왠지 뭔가 부족하다고 생각이 들게 만드는 서비스들이다.

그렇다고 위에서 소개한 서비스들이 잘못된 것은 아니다. 이미 우리는 웹2.0을 어느정도 실천하고 있다. 웹2.0의 개념이 세상에 알려지기 이전부터 말이다. 즉, 언제든지 웹2.0에 대한 기반은 마련되어 있다는 말이다. 결국 웹2.0의 철학적인 부분만 제대로 도입을 한다면 한국의 현재 진행중인 웹2.0 관련 서비스들은 더욱 더 빛을 낼 수 있을 것이다. 이미 기술적인 부분만 따져서는 국내의 웹2.0 관련 서비스들은 전 세계를 상대하기 충분한 기술력을 지니고 있기 때문이다.

어떤 경우나 어떤 부분이던 기술적인 부분이나 실무적인 부분을 진행하기 전에 철학적이나 정신적인 부분을 배워야하는데 국내 웹2.0 관련 산업들은 그런 부분에서 소홀했다는 점이 너무 아쉽다는 생각이다. 기사에서 지적했듯 비슷비슷한 서비스들이 난무하는 현재 웹2.0 시장에서 철학적인 부분만 더 보안을 한다면 뭔가 차별화된 서비스를 구축할 수 있지 않을까 하는 생각을 하게 된다.

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

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

뉴스를 보는데 재미난 기사를 읽었다.

MP3 달린 세탁기… LG전자의 '당찬' 도전 (한국일보 2007. 5. 31)

MP3 플레이어 기능이 담긴 세탁기에 대한 특허를 미국 특허청에 신청했다는 얘기다. 외신들은 시끄러운 세탁기에 왜 MP3P를 달 생각을 했으며 다용도실 등 외딴 곳에 있는 세탁기 앞에서 누가 음악을 듣겠는가 하며 도저히 이해할 수 없다는 반응이었다고 한다. 하기사 내가 생각해봐도 이해하기 어려운 일이다.

그런데 이렇게도 해석할 수 있다. 세탁기에서 음악을 들을 수 있도록 조용한 세탁기, 즉 저소음 세탁기를 만들겠다는 의지일 수도 있다. 지금은 소음때문에 시끄러워서 베란다나 다용도실 등 외진곳에 세탁기를 갖다놓고 쓰고 있지만 지금의 냉장고 정도의 소음만 들릴 정도로 저소음 세탁기를 개발한다면 세탁기의 디자인을 지금보다 더 세련되게 만들어서 거실이나 주방 등에 배치할 수 도 있을 것이다. 아마도 그런 것까지 계산하고 특허를 신청하지 않았을까 한다.

앞으로의 일은 모르기 때문에 기술의 선점은 상당히 중요한 부분으로 대두되고 있다. 앞으로 어떤 기술이 나와서 히트를 칠 수 있는지 알 수 없기 때문이다. LG가 특허를 신청한 MP3P가 달린 세탁기 기술도 소음 문제만 해결하고 디자인을 더 미려하게 만들 수 있다면 충분히 히트가 가능한 제품일 것이라 생각이 든다. 저소음 세탁기는 삼성도 역시 같이 동참해서 만들어가고 있다. 적어도 백색가전의 경우 한국 제품이 세계 어느 제품과 비교해봐도 뒤떨어지지 않는다. 오히려 더 앞선 제품들도 많다. 그러한 상황에서 앞으로 나올 수 있는 가능성이 있는 기술을 미리 선점한다면 기업 입장에서나 혹은 국가 입장에서도 큰 도움이 될 수 있을 것 같다.

생각의 전환, 다른 관점에서의 판단 등 일반 사람들이 상상할 수 없는 그러한 부분까지 생각해서 대처한다면 그거야 말고 미래 권력의 주도권을 갖게 되는 지름길이 아닐까 하는 생각이 든다.

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

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