CoDeveloper BLOG

[상품 리뷰] 인디랩 보조배터리 사용 후기

2011-12-29T07:32:00.007+09:00

Olleh 클럽에서 인디랩 보조배터리 체험단에 당첨이 되어 인디랩 보조 밧데리를 체험 해보았습니다.

1. 구성품

메인 본체, 사용자 설명서, 충전용 케이블, 파우치
파우치가 포함되어 있다는 것은 너무 좋았으나, 충전용 어덥터가 포함되지 않은게 아쉬운 부분이었다.
그러나 정격입력이 5V/2A max 이므로 기존에 가지고 있던 USB 충전 어뎁터를 아무거나 써도 무난 할 듯 하다.

2.본체 구성

본체 디자인은 생각보다 이뻤으며 크기도 휴대하기 무난하게 만들어진 것 같다. 그리고 4단 LED를 사용하여 남은 용량을 자세하게 표시 해주는 것도 좋은 부분 같다.

아쉬운 부분은 왼쪽 사진과 같이 서브모델 확장이 가능한 모델이기 때문에 하단 부분이 서브 모델 연결 커넥터가 있었으며, 이 부분 디자인 색이 파란색인 것이 너무 마음에 안들었다. 확장성도 좋지만 확장을 안하려는 사용자에 대한 배려가 부족한 디자인 같다. 추후에 하단 커버가 나왔으면 좋겠다.

파우치에 넣었을 때 사진

3. 사용 결과

아이폰4, LG 옵티머스 LTE, 모토쿼티에서는 정상 충전이 되는 것을 확인 하였으나,
아래 그림과 같이 아이패드2에서는 위와 같이 충전중이 아님이라는 문구가 떠있는 것으로 보아 출력이 약한 것으로 보인다.(충전이 되고 있는지 안되고 있는지는 정확히 모르겠으나, 아이패드 UI상 충전안됨 문구가 뜬다면 문제가 있는 것으로 보인다.)

4. 최종 후기

장점

1. 적당한 큭에 디자인은 섬세하고 상단 디자인은 예쁨.

2. 사용하기 무난한 파우치 제공은 참 괜찮은 선택임

단점

1.하단 부분에 디자인이 미흡한 것 같으며, 확장을 하지 않은 사용자에 배려가 부족한 부분이 있었으며 하단 부분은 확장을 사용하지 않을 시 하단 얇은 커버를 제공 해줌으로써 파란색이 아닌 원색(검정,흰색)으로 일체감을 줄 필요성을 느낀다.

2.아이패드와 같은 높은 입력 A를 요구하는 단말기에 대해 고려가 필요하다

3. 어뎁터 미제공은 아쉬었으며(보통 USB충전기 어뎁터 대체가 가능한 부분이었음^^) 만약 사용자가 정격 입력보다 높은 어덥터를 사용할 경우에 대한 대책이 미흡함(만약 사용자가 높은 전압 또는 전류용 어덥터를 사용하여 제품에 손상이 있는 경우에는 제품에서 제공한 어덥터를 사용했는지 유무로 사용자 과실을 확인하는데 기본 어덥터가 없는 관계로 문제 발생이 우려가 됨)

고객을 위하여 보다 나은 제품을 만들기를 바라겠습니다.

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

한국 개발자가 모두 공감하지만 절대 공감해서는 안되는 말

2011-05-09T22:30:00.001+09:00

- 우리는 너무 바빠서 문서를 쓸 시간이 없다.

- 우리는 고객의 요구사항이 너무 자주 바껴서 스펙을 작성할 수가 없다.

- 우리가 개발하는 시스템은 너무 복잡해서 문서로 만드는데 한계가 있다.

- 우리가 개발하는 시스템은 너무 복잡해서 테스트 시간이 오래 걸려 테스트를 자주할 수가 없다.

- 우리가 개발하는 시스템은 너무 복잡해서 개발자만이 테스트가 가능하다.

- 우리가 개발한 기술은 너무 어려워서 문서로 설명하기가 힘들다.

- 우리가 개발한 기술은 너무 어려워서 개발자가 코드를 보고 이해하는데도 1년 이상 걸린다. 그러므로 문서로는 더욱 이해 할 수가 없다.

- 우리의 프로젝트는 너무 촉박해서 제대로된 프로세스를 밟을 수 없다.

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

[WINDOWS] 저장된 네트워크 드라이브 계정 정보 삭제

2011-04-27T15:09:00.002+09:00

네트워크 드라이브에 암호를 저장해 놓고 사용하다가 계정을 다른계정으로 바꾸어 쓸 경우 문제가 되는 경우가 종종 있습니다.

시작 >> 실행 에서 control userpasswords2 라고 치고 엔터를 치면 사용자 계정 관리 대화상자가 열립니다.

고급 탭에서 암호 관리 버튼을 클릭하면 현재 암호가 저장되어 있는 서버의 아이피 주소가 나옵니다.

해당 아이피를 삭제하면 다른 계정으로 연결이 가능해집니다.

(출처 : http://coolthinking.tistory.com/1 )

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

드러난 빙산의 비밀 - 조엘온 소프트웨어

2011-04-27T00:42:00.000+09:00

조엘온 소프트웨어 25장

너무 공감되고 알아두면 좋을 듯한 내용이므로 글 올립니다.고객은 자신이 원하는 내용이 뭔지를 모릅니다. 고객이 자신이 원하는 내용이 뭔지를 알아내길 기대하지 마십시오.소프트웨어는 빙산과도 똑같습니다. 멋진 사용자 인터페이스는 작업의 5%만 차지합니다.그러나 고객은 5%의 인터페이스 가지고 모든 것을 평가 합니다...진짜 비밀 프로그래머만이 알고 있습니다.

핵심 원리 1
프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘못된 화면을 보여주면 사람들은 전체 프로그램의 90%가 잘못 됐다고 생각합니다.

핵심 원리 2
프로그래머가 아닌 사람에게 사용자 인터페이스로 100% 무장한 화면을 보여주면, 프로그램이 거의 끝났다고 생각 할 것입니다. 화면에 보이니 "실제 기능 구현이 어려우면 얼마나 어렵겠어"라고 생각할 겁니다. 절대 프로젝트 초기에 사용자 인터페이스를 먼저 만들어 고객에게 보여주지 마십시오. 그러면 고객은 기능 구현시 아무일도 안하고 빈둥거린다고 생각 할 것입니다.

핵심 원리 3
프 로그램을 평가를 받을때에는 외형에 신경써서 만드십시오. 그러면 더욱 실용적인 프로그램보다 더 좋은 평가를 받을 겁니다.

핵 심 원리 4
고객에게 프로젝트를 승인 받어야 할 경우에는 그래픽 디자인 버젼을 몇개 더 만드 십시오. 치명적인 영향이 없는 디자인을 고객이 직접 하게 하여 고객 참여가 소중하다는 느낌을 들게 하십시오. 고객이 200번을 바꾼다 하더라도 설계에는 아무런 상관이 없으니..

핵심 원리 5
전시 할때는 100% 화면만 고려 하십시오. 전시회에서 보통 디자인을 보지 기능을 보는 사람은 거의 없을 겁니다.

위의 내용은 제가 임의적으로 해석하여 쓴 겁니다..실제 원문을 보실 분은 조엘온 소프트웨어 서적을 참고 하십시오

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

[앱마켓] 유머하는 고양이 유머캣

2011-04-27T00:20:00.005+09:00

유머캣으로 오늘부터 좀 더 유머있고, 재치있는 사람이 될 수 있습니다.
지루한 출근길, 등교길, 약속을 기다리며 즐길수 있는 짧은 유머와 넨센스퀴즈를 좀 더 시간을 알차게 보낼 수 있습니다.
지금 바로 유머하는 귀여운 고양이 유머캣을 만나보세요.
그리고 SMS, 메일로 친구들과 유머를 공유해 보세요.

-컨텐츠는 앱 업데이트 없이 컨텐트만 다운로드 받는 방식이므로 지속적으로 컨텐츠 업데이트 될 것을 약속 드립니다.
-버그 / 개선 사항을 남겨 주시면 다음 버전에 적극 반영하겠습니다.
-어플 구동시 인터넷에서 최신 유머 업데이트를 위하여 데이터 통신을 하게 되며 3G 사용시에는 각 요금제에 따라 데이터 요금이 발생 할 수 있습니다.

다운 방법

1.마켓에서 유머캣으로 검색 하세요.
2.아래 URL 링크를 클릭하세요
3.아래 QR코드를 찍어보세요.

https://market.android.com/details?id=com.cats.smilecat&feature=search_result

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

아이폰이 한국에 변화를...

2009-09-28T10:27:00.008+09:00

아이폰이 한국의 상륙이 거의 결정 되면서 여러 분분한 의견들이 많다
그중 가장 이슈는 아이폰이 한국 시장에 얼마나 영향력을 미칠 것이냐는 것이다.
영향력이 미비 할 것이라는 추측 기사도 많이 나오고 있다. 여기서 중요한 건 아이폰 자체적으로 한국 시장의 영향력을 이야기 하는 것 같다.
저도 아이폰의 시장 영향력은 부정적이라고 생각이 든다. 왜냐하면 제가 생각하는 한국 시장은 아직 스마트 폰에 대한 인식이 좋지 않다고 볼 수 있다. 길거리를 가더라도 핸드폰 + 여러 멀티미디어 기기를 다들 들고 다니는 것을 볼 수 있다.저 또한 핸드폰은 전화를 받기 위한 도구로 사용 할 뿐 최신 컨텐츠와 멀티미디어를 사용하기 위해서 다른 멀티미디어 기기들을 하나씩 들고 있다. 이러한 한국 문화에서 아이폰이 살아남기 위해서는 기존 핸드폰 + 기존 멀티미디어기기를 통합하여 사용할 수 있을 뿐만 아니라 유지비도 비슷해야지 성공 할 수 있다고 본다. 그래서 제 생각은 생각보다 아이폰 자체적 한국 시장의 영향력은 크지 않을 꺼라고 본다.

중요한 것은 아이폰이 자체적 영향력 보다는 아이폰이 가지고 있는 WIFI 기술이라고 본다.
아이폰은 이미 GPS와 WIFI를 탑재 되어 있다. 핸드폰에 WIFI가 탑재 되서 발매 된다는 것은 이래적인 일이다. 즉 핸드폰 WIFI에 대한 이동통신사의 규제가 풀린다는 이야기이다. 현재 우리나라 제품(삼성,LG) 핸드폰도 WIFI가 가능한 모델들이 있다. 그러나 이것들은 모두 수출용이지 한국에서는 WIFI를 제외한 모델을 사용하게 되어 있다.

"WIFI가 뭐가 좋은데..."
WIFI를 사용 가능하게 되면 사용자는 보다 빠른 접근성에 인터넷 환경을 맛 볼 수 있다. 또한 데이타 요금에 대한 걱정은 전혀 할 필요가 없다. 이러한 장점은 아이팟에서 많은 사용자들이 느껴던 장점이다. 그래서 아이팟 유저들은 아이폰을 선호 하게 된다. 언제 어디서나 아이팟 하나만으로 인터넷 세계를 항해 할 수 있는 기쁨이라는 것은 사용해 본 자만이 알게 된다.

"WIFI 불가능 지역에 가면 별 필요 없자나?"
저 같은 경우는 WIFI가 가능 지역의 노출 시간은 하루에 24시간 중에 20시간 이상이 된다. 특히 한국에서는 WIFI 가능 지역은 생각보다 넓다. 종로 한복판에 서서 WIFI Tracking을 하게 되면 20개 이상은 잡히게 된다. 거기서 오픈 되어 있는 것만도 10개 이상이다. WIFI 불가능 지역에 있을 시간은 하루에 4시간 정도라는 것이다. 그 4시간을 보충해 주는 것이 모바일 네트워크 환경이 되겠다. 이것은 다른 멀티미디어 기기들이 할 수 없는 핸드폰기기만이 가능한 일이다.

"왜 WIFI는 필요한가?"
현재 데스크탑 환경에서도 웹 어플리케이션의 트렌드가 한창이다. 브라우저를 통한 사용자에게 서비스 지향 접근 방법이 생각보다 적중한 것이 사실 이다. 데스크탑 환경에서도 이런 추세라면 모바일 환경에서는 이 트렌드는 더욱 빨리 받아 들여지게 될 것이다. 그 예로는 OZ를 꼽을 수 있다. OZ는 모두 모바일 네트워크 환경에서 하기 때문에 사용자가 답답함을 많이 느낄 수 있다는 단점에도 불구하고 최대한의 수입 효과를 냈으며, LG 텔레콤의 회생 시켜줬다고 해도 과언이 아니다.
만약 WIFI와 모바일 네트워크가 접목되어 24시간중 4시간만을 모바일 네트워크 환경이라면 사용자들 전혀 불편함을 느끼지 않을 것이다. 또한 데이타 이용료도 훨씬 줄게 될 것이다.(이런 부분에서 이통사는 싫어 할 것이다.)

"한국의 인터넷 인프라의 최대 효과"
한국 시장은 최고의 인터넷 인프라를 가지고 있으면서 WIFI를 제대로 활용을 못하는 사례가 많이 있다. 현재 WIFI를 통한 모바일 웹 브라우저 환경으로 최대한 이익을 볼 수 있는 나라가 한국이다. 휴대폰을 사용에 세상을 모두 가져다 줄 수 있을 나라는 한국이 가장 빠를 것이다. 또한 더욱 더 많은 정보를 사용자는 접할 수 있으며, 사용 요금 및 유지비는 더욱 떨어지게 될 것이다.

PS. 이 글은 저의 개인적인 생각이며 아이폰을 빗대어 설명 하였지만 핸드폰+WIFI의 모바일기기에 모두 해당 되는 것입니다. 아이폰을 통한 한국시장의 각성을 이루었으면 하는 바램입니다.

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

Web as Mobile Platform

2009-09-24T10:45:00.006+09:00

Cross Platform에 대한 고민은 오래전부터

Mobile Platform시장은 비약적인 발전을 하고 있지만, 너무나 많은 플랫폼이 존재하여 시장발전을 저해한다는 근본적인 문제는 해결되지 않고 있다. 이를 해결하기 위해 다양한 접근을 하고 있으며, Cross Platform에 대한 연구와 솔루션들이 빠르게 시장에 나오고 있다.Cross Platform은 Mobile에만 한정되는 고민은 아니었으며 이미 PC시장에서도 동일한 접근은 오랫동안 있어 왔지만, 깔끔한 해결책은 아직은 찾지 못하고 있다. 이러한 고민 중에서 Ajax, html5 등과 같은 새로운 기술이 적용되면서 자연스레 "Web as Platform"이라는 접근이 이루어지게 된다.

간단히 서문만 가져왔습니다. 자세한 내용은 원문내용 클릭 클릭!!

원문 내용 : Web as Mobile Platform - 모바일 컨텐츠 이야기

My Comment

먼저 길면서 아주 알찬 내용의 포스터네요.. 감동 감동^^ 꼭 다른 분도 읽어 보시길..
제 생각은 천천히 데스크탑과 모바일 소프트웨어는 웹으로 향하고 있다는 건 사실입니다. SOA, Cloud Computing, Mashup 이라는 신종 용어들도 웹을 통하여 서비스를 하자는 목적에 가까울 겁니다. 그 중 HTML5 표준으로 인해 가장 먼저 적용 되는 분야는 모바일 웹이 될 것입니다. 또한 개발 플랫폼이 향상 된다면 그 파급 수준은 AJAX를 뛰어 넘을 것입니다. 저는 웹 어플리케이션이 대중화 될 것은 사실이다고 생각 되며, 몇몇 네이티브 어플리케이션은 웹 어플리케이션으로 대체 될꺼라고 생각합니다.그렇다고 네이티브 어플리케이션이 사라지는 것은 아닙니다. 웹 어플리케이션에서도 아직 부족한 부분이 많이 있으며, 웹 어플리케이션과 네이티브 어플리케이션은 계속 공존 할 것입니다.그러나 플랫폼이 나누어 질 수도 있을 것입니다.문제는 데스크탑 플랫폼(범용 목적의 플랫폼)을 웹 어플리케이션이 가져간다는 것입니다. 웹 어플리케이션이 범용 플랫폼인 데스크탑이나 모바일 기기가 될 것이며, 네이티브 어플리케이션은 특정한 목적의 컴퓨터 프로그램으로 계속 사용 될 것라는 짤막한 저의 생각이였습니다.

미래를 구글과 함께

2009-09-24T09:11:00.015+09:00

원문 : Google Is Searching For Beautiful Minds, But So Far No M.I.T. Students Have Broken Its Code
구글이 입사할 수 있는 비밀 코드를 MIT 캠퍼스에 붙여 놓았다.

그러나 MIT 학생 아무도 이 암호를 깨지 못했다고 한다.

암호

8MLDQ6 T UI 6TFML RH AA NRA6Q 8EFL DMQ86II2 O3 2S5J 13JXOJ

해독방법

0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ

0123을 제외 하고, (J=0, O=1, B=2, S=3) 으로 바꾸어 주면

매칭 코드는

456789ABCDE2FGHIJKL0MNOP1QRS3TUVWXYZ

즉 변환 테이블은

0 1 2 3 4 5 6 7 8 9 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

4 5 6 7 8 9 A B C D E 2 F G H I J K L 0 M N O P 1 Q R S 3 T U V W X Y Z

이 되게 된다.

암호문 : 8MLDQ6TUI6TFMLRHAANRA6Q8EFLDMQ86II2O32S5J13JXOJ

해독문 : CONGRATULATIONSKEEPSEARCHINGORCALL6176390570×10

결과 : CONGRATULATIONS KEEP SEARCHING OR CALL 617 639 0570 (extension 10)

My Comment

저도 설마 전치 암호겠어 하고 생각 했는데 전치 암호화를 했네요 중요한 키워드는 JOBS인거 같은데 이게 정말 답이 맞는 건지는 전화 해보면 알겠네요... 문제는 ㅋㅋ전화 시 영어로 말하면 맞는지 틀린지 모른다는 것 뿐...

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

[글로벌 칼럼] 구글 독스 vs MS 오피스 ‘관건은 신뢰성 확보다’

2009-09-23T13:22:00.005+09:00

지난 수년간 마이크로소프트는 생산성 스위트(productivity suites)에 관한 한 독보적인 위치를 고수해 왔다. 개인 및 기업 고객들 대다수가 생산성 스위트에 대해 별다른 고민을 할 필요가 없었다. 마이크로소프트 오피스를 선택하면 그만이었다.

그러나, 기업들 사이에 클라우드 컴퓨팅의 개념이 확산되면서 추세가 바뀌기 시작했다. 물론, 오피스는 여전히 기업들의 생산성 스위트 대부분을 차지하고 있지만 구글 독스의 웹 기반 오피스 스위트가 점차 주목을 얻어가고 있다. 소기업들뿐만 아니라 대기업들로부터도 말이다.

구글은 공식 블로그를 통해 현재 175만 기업, 학교 및 기관들이 구글 독스를 사용 중이라고 밝혔다. 모토로라 역시 구글 독스를 사용중인 기업들 중 하나이다. 또한, 구글은 구글 독스를 사용하는 기관들이 하루에도 3,000곳씩 늘어나고 있다고 전했다.

특히 교육 부문에서의 약진이 두드러지는데, 구글에 따르면, 현재 145개 이상의 국가에 있는 수 천 개의 대학교들에서 5백만 명 이상의 학생들이 구글 독스를 사용하고 있다. 이는 지난해의 400%에 달하는 수치다.

구글은 현재 보스톤, 시카고, 뉴욕 및 샌프란시스코 등지에서 왜 기업들이 구글 독스를 사용해야 하는지를 알리는 빌보드 광고 캠페인을 벌이고 있다.

물론, 마이크로소프트가 가만히 앉아서 구경만 하고 있는 것은 아니다. 출시를 앞두고 있는 마이크로소프트 오피스 2010에는 구글 독스와의 경쟁을 염두에 둔 웹 기반의 워드, 액셀 및 파워포인트 등의 인기 애플리케이션 특징들이 첨가됐다. 그러나, 이들 웹 기반 버전의 성능은 구글 앱스에 비해 떨어진다.

구글 역시 일부 클라이언트 기반의 특징들을 더함으로써 구글 독스를 데스크탑으로 확장시켜오고 있다. 물론, 이들 클라이언트 기반 버전의 성능도 마이크로소프트 오피스에 비해서는 떨어질 수밖에 없다.

그러나, 시간이 지남에 따라 구글 독스와 마이크로소프트 오피스 간의 차이는 점차 축소될 것으로 보인다. 오피스는 클라우드 기반의 스토리지 및 기타 웹 기반의 특징들을 얻게 될 것이고, 구글 독스는 강력한 클라이언트 기반의 특징들을 갖추게 될 것이다. 그러나, 한동안은 클라이언트 기반의 서비스는 마이크로소프트가, 웹 기반의 서비스는 구글 독스가 주를 이루게 될 가능성이 높다.

그렇다면, 기업들은 어떤 생산성 스위트를 선택해야만 할까? 구글 독스일까 아니면 마이크로소프트 오피스일까? 궁극적으로는 신뢰성의 문제가 될 것이다. 단순히 특정 기업에 대한 신뢰가 아닌 기업의 특정 기술방식, 즉, 클라우드 기반의 서비스인지 또는 클라이언트 기반의 서비스인지에 대한 신뢰성의 문제인 셈이다.

이달 초에 있었던 지메일의 100분간 서비스 중단사고는 구글 독스로의 전환을 꾀하던 이들로 하여금 주저하도록 만들었을 것이다. 마이크로소프트로서는 경쟁사의 이 같은 사고에 그야말로 쾌재를 불렀을 것이다.

기업체를 운영하는 입장에서, 회사 내의 워드 프로세싱, 엑셀 스프레드, 프레젠테이션 등의 소프트웨어 서비스가 모두 중단되어 버렸다고 상상해 보자. 정말 끔찍하지 않겠는가?

적어도 현재로써는 웹 기반의 스위트보다 클라이언트 기반의 스위트에 더욱 신뢰가 갈 것이다. 게다가, 마이크로소프트는 자동화된 설치 및 관리 기능에서도 볼 수 있듯이 오피스를 설치하고 지원하는 데는 오랜 경험을 갖고 있으니. 이것만으로도 마이크로소프트 오피스를 선택할 충분한 이유가 생기는 셈이다.

물론, 생산성 스위트의 선택은 가격, 회사규모 및 필요충족요건 등에도 영향을 받게 된다. 예를 들어, 오늘 작은 기업체를 시작하려고 하는 이가 있다면, 구글 독스를 선택할 가능성이 높다. 마이크로소프트 오피스보다 라이센싱 요금이 저렴할 뿐만 아니라, IT 직원이나 인프라스트럭쳐가 없이도 사업환경을 구성할 수 있기 때문이다.

필요한 것은 웹 액세스뿐이다. 이에 따른 비용절감 효과는 단순히 라이센싱 요금을 절약하는 것을 떠나 가끔씩 있을 수 있는 서비스 중단의 결점조차도 보완해 줄 수 있을 정도다.

반면, 인프라스트럭쳐, 기술력 및 전문성 등에 상당한 투자를 하고 있는 대기업들은 실효성이 입증된 클라이언트 기반의 서비스를 선택하려 들 것이다. 그러나, 클라우드가 더욱 신뢰를 얻게 되고 구글이 기업들이 원하는 서비스를 개발하게 되는 향후에는 결정이 그리 쉽지 많은 않을 것이다. editor@idg.co.kr

출처 : http://www.idg.co.kr/newscenter/common/newCommonView.do?newsId=59305

My Comment

웹 기반의 오피스는 구글독스가 최고의 위치에 있는 것은 확실하다. 그러나 웹 기반의 오피스가 가지고 있는 문제점은 신뢰성과 보안성이다. 현재 구글독스를 사용하는 유저들은 Anywhere의 장점 보다는 Anywho의 장점일 것이다. 즉 공유 문서의 장점을 최대한 활용하다는 것이다.
기업에서 웹 기반의 오피스를 채택하기 위해서는 신뢰성과 보안성이 최대한 보장 되어야 한다. 보안성에서는 기업 문화에서 자기들만의 노하우를 오픈 될지도 모른다는 생각에 더욱 웹 기반의 오피스는 가장 걱정해야 할 문제이다. 신뢰성 또한 마찬가지이다. 문서를 작성하다보면 2~3시간 작성을 할 때도 있으며, 빠른 시간안에 작성해야 할 상황도 있기 마련이다. 2~3시간의 문서가 다 허공으로 날라간다면. 그리고 급하게 작성해야 하는데 오피스가 열리지 않는다면. 사용자들은 그 즉시 그 오피스를 외면하게 될 것이다. 간단한 공유를 원하는 문서가 아닌 기밀 문서나 중요한 문서에 웹 오피스는 시기 상조라고 생각 한다.

구글 웨이브가 뭐지?…인터넷 판도 뒤엎는다는데

2009-09-16T11:27:00.000+09:00

한국경제 블로그 blog.hankyung.com/kim215

인터넷이 등장한 지 40년이 됐습니다. 네이버와 다음이 상용 서비스를 시작한 지도 10년 남짓 됐습니다. 인터넷 초창기에는 참으로 변화가 많았습니다. 하루가 다르게 새로운 서비스가 추가되곤 했죠.그러나 성숙단계에 접어든 지금은 변화가 거의 없습니다. 그렇다면 인터넷 서비스는 앞으로 어떻게 발전할까요?인터넷의 발전 방향을 짐작하게 하는 서비스가 있습니다. 30일부터 서비스가 시작되는 '구글 웨이브(Google Wave)'입니다. 구글 웨이브는 실시간 커뮤니케이션 플랫폼입니다. 이 서비스에 대해 온라인 미디어 매셔블은 '게임 체인저(Game Changer)'라고 표현했습니다. 판을 뒤엎을 수 있는 변수라는 얘기죠.구글 웨이브가 뭐길래 '게임 체인저'라고 할까요？ 매셔블은 구글이 5월 말 웨이브를 공개한 이후 다양한 분석기사를 게재했습니다. '구글 웨이브의 6가지 게임－체인징 특징'이 대표적입니다. 블로그 사이트인 웹스튜디오13은 최근 '구글 웨이브가 무서운 7가지 이유'를 실었습니다. 두 글을 묶어 정리합니다.

1.실시간 온라인 협업같은 웨이브에 접속한 사람들은 그룹 메시지 편집에 참여할 수 있다. 누군가 올려놓은 메시지를 여러 사람이 동시에 첨삭할 수 있다. 가령 회원들한테 만찬 일정을 알리고 참석 여부를 이메일로 받아 정리하려면 복잡하다. 그런데 구글 웨이브를 이용하면 참석/불참/미정 명단을 순식간에 작성할 수 있다.

2.구글 웨이브 확장구글 웨이브 안에 서드파티 어플리케이션을 붙일 수 있다. 예를 들어 트웨이브라는 웨이브 가젯을 붙이면 구글 웨이브 안에서 트위터를 이용할 수 있다. 트위터나 페이스북과 마찬가지로 서드파티 어플리케이션 개발이 붐을 이루면 구글 웨이브는 '올인원(all－in－one) 커뮤니케이션 플랫폼'이 될 수 있다.

3.드래그&드롭 파일 업로드이메일의 경우 파일을 검색해 첨부한 다음 발송하면 수신자가 파일을 열어본다. 구글 웨이브에서는 이런 과정이 필요 없다. 파일을 드래그&드롭 하기만 하면 업로드가 되며 웨이브 접속자들은 누구나 이걸 볼 수 있다. 기업에서는 구글 웨이브를 커뮤니케이션 및 파일 공유 플랫폼으로 활용할 수 있다.

4.다른 사이트에 웨이브 임베드웨이브를 블로그,회사 웹사이트，소셜 네트워킹 사이트 등에 임베드(embed) 할 수 있다. 이렇게 하면 많은 사람들과 편하게 커뮤니케이션 할 수 있다. 예를 들어 회사 웹사이트에 웨이브를 임베드 해 놓고 이것을 이용해 고객관리를 할 수 있다. 이렇게 되면 단방향 코멘트가 아니라 실시간 대화가 가능하다.

5.구글 웨이브 소스 공개구글 웨이브가 오픈소스 플랫폼이란 점은 매우 중요하다. 구글이 웨이브 소스를 공개하면 개발자들은 이걸 이용해 다양한 응용 프로그램을 만들 수 있다. 웨이브 코드를 더욱 발전시키고 수정할 수도 있다. 이렇게 되면 구글 웨이브는 급속히 확산돼 커뮤니케이션 판을 바꾸는 게임 체인저가 될 수 있다.

6.실시간 커뮤니케이션웨이브에 접속한 사람들이 동시에 커뮤니케이션을 할 수 있다. A와 B가 구글 웨이브에서 대화를 하고 있다고 가정하자.A가 글자를 입력하면 B는 입력 내용을 실시간으로 볼 수 있다. A도 B의 입력 내용을 볼 수 있다. 물론 입력 내용을 엔터키 누르기 전엔 상대가 보지 못하게 할 수도 있다.

7.로시 번역 로봇로시(Rosy)라는 실시간 자동 번역 로봇을 이용하면 다양한 언어로 커뮤니케이션하면서 실시간으로 협업할 수 있다. 영어 사용자와 프랑스어 사용자가 협업할 경우 영어로 입력하면 상대방 웨이브에는 실시간으로 프랑스어로 번역돼 나타나고 프랑스어로 입력하면 상대방 웨이브엔 영어로 번역돼 나타난다. 구글 웨이브의 특징을 요약했습니다. 핵심은 '실시간(real-time)' 서비스라는 점입니다. 트위터가 등장한 이후 인터넷 업계는 실시간 기능 도입에 열을 올리고 있습니다. 이걸 집대성한 게 구글 웨이브라고 할 수 있습니다. 아시다시피 구글은 인터넷 선두주자입니다. 선두주자가 판을 바꾸려 하다니 놀랍습니다.

구글웨이브 9월말 공개베타 서비스

2009-09-15T13:33:00.004+09:00

황치규 기자 delight@zdnet.co.kr 2009.07.22 / PM 04:58

[지디넷코리아]구글이 이메일과 메신저 등 각종 커뮤니케이션 도구를 하나로 통합한 '구글웨이브' 공개베타 서비스를 오는 9월 30일 시작하기로 했다고 21일(현지시간) 밝혔다.

구글은 5월말 IO 컨퍼런스에서 웨이브를 선보인 이후 6천명 가량의 개발자들에게만 공개해왔다. 그러나 이번에 10만명으로 사용자수를 확대한 뒤 9월말 공개베타에 들어가기로 했다.

구글웨이브는 이메일, 메신저, 블로깅, 멀티미디어 관리, 위키, 문서 공유 기능을 모두 아우르고 있다. 지금까지 볼 수 없었던 서비스 유형이다. 이메일에 실시간 커뮤니케이션 및 협업 기능이 대폭 강화됐다.
구글은 '웨이브'를 통해 실시간 협업 환경을 제공, 이메일의 한계를 뛰어넘겠다는 야심을 보이고 있다.

My Comment

MSN 메신저를 따라 잡을 수 있는 최고의 아이템인 구글웨이브가 곧 공개되는군요..
빙 VS 구글 , 구글웨이브 VS MSN메신저 대결 누가 승기를 잡을 지가 궁금하네요.
개인적으로는 구글웨이브에 녹아들어있는 AJAX 기술, Javascript 기술이 어느 정도가 될 지 궁금하며, 새로나올 HTML5의 기술이 포함되면 어느정도의 웹 어플의 성능이 될지 짐작이 안가네요. 생각보다 빠르게 웹 어플이 데스크탑 어플을 잠식할 가능성도 존재하네요.
AJAX의 파급 속도만큼 HTML5가 파급 된다면 2020년이 아니라 2013년 정도면 HTML5 정착과 새로운 웹 어플들을 많이 볼 수 있겠네요.

[칼럼]모바일SW넘어 모바일웹을 주목하라

2009-09-13T23:36:00.003+09:00

박재현 IT칼럼니스트 jaehyunpark.kr@gmail.com 2009.08.31 / PM 05:47

모바일 시장에서 두각을 나타날 만한 아이디어를 갖고 있는 개발자가 성공적으로 투자를 받아 회사를 창업했다고 하자. 멋지게 해당 서비스를 기획하고 실제 개발을 해야 하는 상황에 이르렀다고 하자.

그렇다면 아마도 이러한 문제에 직면할 것이다. 도대체 어떤 플랫폼용으로 만들 것인가?

앱스토어라는 애플리케이션 마켓플레이스가 가장 활성화되어 있는 애플용이 좋을 까? 아니면 전 세계에서 가장 많은 휴대폰을 판매하는 노키아나 삼성전자 휴대폰을 대상으로 할 것인가? 아마도 여러 복합적인 의사 결정에 따라 애플 아이폰 SDK나 심비안 SDK 또는 윈도모바일 SDK 중의 하나를 이용해 애플리케이션을 개발하게 될 것이다.

이같은 개발 환경은 개발자와 개발회사에 커다란 부담이다. 가장 근본적인 고민은 모바일 플랫폼이 너무 많다는 것이다.

현재 공개된 대표적인 모바일 플랫폼만 하더라도 애플 아이폰 SDK, MS 윈도 모바일 SDK , 구글 안드로이드SDK , 심비안 SDK , 팜 Mojo SDK 등이 시장에 나와있다.

이들 SDK중 하나를 선택하는 것은 쉬운 일은 아니다. 가령 여러가지 상황을 고려해서 플랫폼을 선택했다고 하더라고 해당 플랫폼에 최적화된 애플리케이션을 개발하기 위해서는 해당 플랫폼에 정통한 모바일 애플리케이션 개발자가 필요하다.

일반적으로 웹이나 PC 플랫폼과 달리 모바일 플랫폼에서 개발할 때는 디바이스 자체의 특성을 잘 이해해야 좋은 성능과 품질의 애플리케이션을 개발할 수 있다.

일단 여러 우여곡절 끝에 하나의 모바일 애플리케이션을 개발했다고 치자. 시장 확대를 위해서는 다른 플랫폼용으로 해당 모바일 애플리케이션을 포팅해야 한다. 말이 포팅이지 거의 새롭게 개발하는 수준이다. 이를 위해서는 숙련된 개발자를 확보해야 하는 등 많은 비용이 든다. 개발 후에는 유지보수를 위해 또 비용이 발생한다. 참으로 비극적인 상황이 아닐 수 없다.

더 우울한 것은 동일한 모바일 플랫폼이라고 하더라도 버전에 따라 호환이 안되는 경우도 다수 발생하기 때문에 많은 버전을 개발하고 관리해야만 한다는 것이다.

이러한 상황을 해결하고 보다 손쉽게 모든 모바일 플랫폼상에서 구동되는 모바일 애플리케이션을 개발할 수 없을까?

물론 몇가지 방법을 상상할 수 있을 것이다. 먼저 모바일 플랫폼을 하나로 통합하고 이를 기반으로 개발하는 것이다. 마치 PC 플랫폼이 윈도로 통일되었듯이 모바일 플랫폼들을 하나의 특정 플랫폼으로 통합하는 것이다. 그러나 이 방법은 불가능하다. 사용자도 플랫폼 통합에 관심이 없겠지만 업체들 입장에서도 이해관계가 다양하기 때문에 통합은 불가능하다.

또 하나 생각해 볼 수 있는 방법으로는 모든 모바일 플랫폼상에서 구동되는 통합된 API를 이용하는 것이다. 마치 노키아가 심비안 S60 플랫폼을 통해 개발하듯이 모든 모바일 플랫폼상에 운용되는 애플리케이션을 개발할 수 있는 SDK를 개발한 후 이용하는 것이다.

그러나 이 방법도 하부에 있는 모바일 플랫폼에 의존적이기 때문에 완벽한 이식성을 제공하기 어려울 뿐만 아니라 이러한 공통 API를 설계하고 개발하는 것은 무척 어렵다. 왜냐하면 모바일 플랫폼은 디바이스 의존도가 강하기 때문이다.

현재 차이나모바일, 소프트뱅크, 보다폰 세개의 이동통신사업자가 만든 컨소시엄인 JIL(Joint Innovation Lab)은 이러한 접근 방법을 사용한다. JIL(www.jil.org)은 JIL JavaScript Extension을 이용하여 모바일 디바이스를 제어하는 위젯을 개발하고 이를 구동하는 런타임 환경을 제공한다. 이 위젯은 모바일 플랫폼과는 무관하게 구동된다. 그러나 JIL은 모바일 애플리케이션을 위한 것이 아니라 위젯 개발을 위한 개발 환경이다.

또 하나의 방법은 개발과 포팅 환경을 통합하여 하나의 통합된 개발 환경에서 개발을 하고 이를 바탕으로 원하는 플랫폼으로 보다 손쉽게 포팅하게 해주는 것이다. 무척 현실적인 방법이나 모바일 플랫폼간 포팅은 쉽지 않아보인다.

실제 이클립스 펄서(Pulsar)는 이러한 접근 방법을 사용한다. 이클립스 펄서는 이클립스 툴 기반의 모바일 애플리케이션 개발 환경으로 모바일 업체들이 자체 SDK를 펄서 명세에 맞춰 공급하면 플러그인 방식으로 다운로드하여 사용할 수 있다.

현재 모토로라는 현재 자바 ME SDK과 노키아 포럼 S60 SDK, 그리고 모바일용 eRCP(embeded Rich Client Platform)를 제공하고 있다. 현재 수준은 모바일 플랫폼 업체들의 SDK를 이클립스 기반으로 통합하여 단일 환경에서 개발할 수 있게 해주는 수준이다.

지금까지 고민해 본 방법은 마치 데스크톱상의 윈도 플랫폼에서 구동되는 윈도 프로그램을 개발하는 것처럼 모바일 디바이스 상에서 구동되는 모바일 애플리케이션을 개발하는 것이다. 그러나 생각을 좀 바꿔 보면 특정 모바일 플랫폼 종속에서 벗어나는 모바일 애플리케이션을 개발할 수 있다. 바로 웹 기반 모바일 애플리케이션을 개발하는 것이다.

모바일 웹 애플리케이션은 모바일 다바이스에 설치되어 운영되는 모바일 애플리케이션이 아니라 네트워크를 통해 언제 어디서나 접속하여 다운로드를 받은 후 웹 브라우저를 통해 사용할 수 있다. 이러한 방법을 모바일 클라우드 기반 애플리케이션이라고도 한다.

이러한 클라우드 기반 모바일 웹 애플리케이션 개발에 있어 해결해야 할 문제로 모바일 애플리케이션의 킬러 분야인 게임 분야에서 우수한 프로그램의 개발이 가능한가? , 네트워크가 불가능한 상황에서 웹 애플리케이션을 어떻게 구동할 것인가?, 그리고 웹 프로그래밍을 통해 디바이스의 제어가 가능한가? 등을 꼽을 수 있다.

결론부터 말하자면 이러한 문제들은 일부는 해결되었고 일부는 해결되어 가고 있으며 모바일 웹이 모바일 플랫폼의 주류중 하나가 될 것이다.

이러한 흐름의 중심에는 W3C가 마련한 HTML5 표준이 있다. 기술적인 내용을 살펴보는 것에 앞서 표준은 산업체간 이해관계가 걸린 전쟁이라는 것을 이해해야 한다. 단순히 업체간 협의에 의해 결정되는 것이 아니라 철저한 이해관계에 의해 움직인다. 현재 HTML5 표준을 강력하게 추진하고 있는 업체는 구글과 애플, 그리고 팜 , 오페라 등을 들 수 있다. MS 반대 진영이 강력하게 추진하고 있는 상황이라고 할 수 있다. 물론 실세는 구글이다. 구글은 W3C 표준에 자신들의 기술을 반영하여 웹 표준을 리드하고 있다.

이러한 HTML5에는 앞서 언급한 모바일 웹 애플리케이션을 개발할 때 발생하는 문제점들의 해결 방안을 상당수 포함하고 있다. 대표적인 것이 게임처럼 복잡한 그래픽 처리를 가능하게 하는 Canvas 태그와 네트워크가 불가능한 상황에서도 디바이스에 있는 스토리지를 이용할 수 있어 응용 프로그램을 구동하고 이를 온라인 접속시 동기화 시키는 것을 가능하게 하는 기능 등이 포함되어 있다. 이 스펙은 구글의 오픈소스 프로젝트 구글 기어스(Gears)를 HTML5에 포함시킨 것이다.

최근 W3C는 Device API Working Group을 발족하여 웹이나 가젯 등의 애플리케이션에서 다바이스를 제어하는 표준API를 제정에 착수했다.

W3C Device API외에 자바스크립트로 모바일 디바이스를 제어할 수 있도록 해주는 표준으로 BONDI가 있다. BONDI는 이동통신 사업자들의 포럼인 OMTP(Open Mobile Terminal Platform)에서 제정한 런타임 플랫폼으로 웹애플리케이션이나 위젯 등에서 모바일 디바이스 기능을 안전하게 제어하게 해주는 모바일 웹 플랫폼이다.

BONDI는 HTML, JavaScript, CSS 등 표준 웹 개발 기술로 작성된 웹 애플리케이션에서 모바일 디바이스에 있는 애플리케이션 , 카메라, 커뮤니케이션 로그, 이미지 갤러리, 위치 정보, 메시징, 스토리지, 개인정보 관리(PIMS) , 디바이스 정보 등을 제어할 수 있게 해주는 모바일 웹 플랫폼이다.

이를 위해 BONDI는 모바일 디바이스를 제어할 수 있는 자바스크립트 EXtension를 제공한다. 현재 1.0 스펙까지 출시되었고 참조 구현체와 SDK를 배포하고 있다. 현재 BONDI API와 노키아 API가 W3C Device API에 제출되어 있는 상태이기 때문에 W3C Device API에 유사 표준이 포함될 것으로 예상된다.

이러한 HTML5, Device API, BONDI 등의 이면에는 여러 업체들의 복잡한 이해관계가 존재한다. 물론 이러한 이해관계의 끝에는 모바일 웹 애플리케이션이 존재한다. 실제 표준을 진행하는 과정에서 자신의 기술과 스펙을 표준화시키는 것은 아주 중요하다. 바로 그것이 경쟁력이기 때문이다. 이를 위해서는 먼저 자신의 기술을 확보해야 하는 것이 필수이다.

현재 모바일 웹을 가장 적극 채용하고 있는 업체는 구글과 팜이다. 구글은 올해 5월 구글 개발자 컨퍼런스인 Google I/O에서 HTML5를 기반 기술로 적극 추진한다고 공표했고 새롭게 개발하고 있는 크롬OS도 HTML5 기반으로 개발하고 있다.

과거 PDA 황금기를 주도했었던 팜은 '팜프리'라는 새로운 스마트폰을 출시하면서 웹 OS라는 혁신적인 개발 환경을 발표했다. 웹 OS는 Webkit과 dojo를 기반으로 한 Mojo라는 웹 SDK를 제공한다. Mojo는 CSS,HTML,Javascript만을 이용하여 모바일 애플리케이션을 개발할 수 있다.

파이어폭스3.5 , 오페라 9.6 , 사파리 4 등 브라우저들도 동영상, 오디오 등 HTML5의 주요 기능을 제공하기 시작했다. 지원 기능은 시간이 흐를 수록 늘어날 것이다.

이러한 모바일 애플리케이션 개발 환경이 웹 중심으로 수렴되는 것은 모바일 애플리케이션 개발에 있어 기존 디바이스 의존적인 방법보다 높은 생산성을 주는 것과 더불어 긍정적인 많은 변화를 가져다 줄 것이기 때문이다. 어떤 변화들이 올 지 예상해보자.

- 중·저가형 스마트폰 시장이 보다 빠르게 형성될 수 있다.
기존 스마트폰 시장은 주로 고가 제품이 주를 이루고 있다. 모바일 애플리케이션을 구동하기 위해서는 고성능 사양이 필요하기 때문이다. 그러나 모바일 웹 애플리케이션은 웹 브라우저가 구동되는 환경이라면 구동이 가능하기 때문에 중저가 스마트폰 시장이 보다 빠르게 형성되고 주류가 될 수 있다.

- 모바일 웹 애플리케이션이 일반화되면 모바일 애플리케이션 생태계도 변하게 된다.
애플 앱스토어를 비롯해 현재 모바일 마켓플레이스를 통해 제공되는 대부분의 모바일 애플리케이션은 디바이스에서 구동되는 순수 모바일 애플리케이션들이다. 마치 윈도용 프로그램 라이선스를 구매하여 사용하는 것과 동일한 방식으로 모바일 마켓플레이스에서 라이선스를 구매하고 이를 디바이스에 설치한 후 사용한다.

그러나 모바일 웹은 이러한 방식의 변경을 요구한다. 모바일 웹애플리케이션은 인터넷을 통해 언제,어디서나 접속해 사용할 수 있기 때문에 과금도 라이선스를 구매하는 방식이 아니라 사용한 만큼 비용을 지불하는 방식인 SaaS(Software As As Service) 모델로 전환될 것이다.

이에 따라 앱스토어 같은 기존 모바일 마켓플레이스도 많은 영향을 받을 것이며 후발 업체들의 경우 새로운 기회를 맞게 될 것이다. 이러한 측면에서 가장 개방되고 우수한 클라우드를 보유하고 있는 구글과 팜의 웹OS가 가장 많은 기회를 얻을 수 있다.

- HTML5, CSS, 자바 스크립트로 개발된 모바일 웹 애플리케이션이 W3C의 Device API 등을 통해 직접 디바이스를 제어하게 된다면 아주 재미나고 놀라운 것들이 가능하다. 가령, 웹 서버와 Device API를 지원하는 냉장고용 제어 프로그램을 개발하면 사용자는 휴대폰 브라우저를 통해 냉장고에 접속한 후 해당 프로그램을 사용할 수 도 있으며 특정 상품의 재고가 부족하면 자동으로 특정 웹 쇼핑몰에 주문하게 할 수도 있다.

HTML5 표준은 2012년 정도에 완성될 것으로 예상되고 있다. 그러나 일반적으로 표준에 앞서 관련 업체들의 모바일 웹 관련 기술은 더욱 빠르게 발전할 것이다. 과거 우리는 IBM의 호스트 환경에서 데스크톱 기반의 클라이언트/서버 환경으로, 그리고 다시 웹으로 변화를 할 때 마다 이를 미리 준비하지 못할 경우 막대한 비용을 지불해야 만 했다.

이처럼 모바일 개발자들과 디바이스 개발자들은 다가올 모바일 웹 환경을 위해 미리 준비를 해야 할 것이다.

전 세계 SOA 서비스 시장 전망

2009-09-12T09:32:00.002+09:00

서비스지향아키텍처(SOA) 시장의 성장 가능성 논란은 국내뿐만 아니라 해외에서도 뜨겁다. 그 핵심은 사실 SOA 프로그램(프로젝트)의 범위를 어디까지로 볼 것인지에서 시작한다. 이는 SOA가 기술이라기보다는 하나의 사상으로 자리 잡아가는 상황에서 단순히 제품·기술만으로 SOA가 적용된 IT시스템이라고 판단하기는 어렵기 때문에 나타나는 현상이다.

IDC 월드와이드 서비스그룹에서 최근 발표한 ‘2009∼2013 전 세계 SOA 서비스 시장 전망’ 보고서를 기반으로 SOA 서비스 시장의 명확한 규정과 성장 추이를 살펴보고, 시장에서 나타나는 동향을 바탕으로 그 성장 가능성을 짚어보고자 한다.

#SOA서비스 시장의 범위

SOA 서비스 시장을 규정하고 규모를 산정하기 위해 IDC는 우선 다음과 같은 제한을 두었다. 서비스 계약을 기반으로 하는 SOA 서비스 즉, 개별 SOA 계약건으로 제공되는 서비스만을 시장 규모 산정에 포함시킨다. 이는 독립된 시장이 아니라 IDC가 규정하는 IT서비스 시장에 포함된 것이다. 다시 말해 IDC가 정의내리고 있는 서비스 기본 시장(컨설팅, SI, 커스텀 애플리케이션 개발, 소프트웨어/하드웨어 설치 및 지원 서비스, 애플리케이션 아웃소싱, IT 교육 등)의 한 부분이다.

#성장동인과 저해요인 상존

2009∼2013 전 세계 SOA 서비스 시장 전망’ 보고서에서는 SOA 서비스에 대한 기업들의 투자가 2009년에서 2010년에 걸쳐 감소할 것으로 예상되지만, SOA의 성장 가능성을 부정적으로 전망하는 우려와 달리 활기를 띠고 긍정적으로 성장하고 있다고 분석한다. 여타 서비스 영역처럼 SOA 시장도 현재와 같은 전 세계적인 경제위기 속에서 비즈니스와 IT 양 분야 모두에서 나타나는 비용 절감 추세에 영향을 받고는 있지만, 내년에는 두 자릿수의 성장세와 함께 서비스 벤더에 지속적인 매출 성장 동력으로 작용할 것으로 전망하고 있다.

SOA 서비스 시장의 성장 가능성을 가늠해 보기 위해 이에 영향을 미치는 성장 동인과 저해 요인을 정리해 보면 다음과 같다.

우선 성장 동인은 △투자수익률(ROI) 증명에 대한 벤더들의 능력 향상 △비용 절감, 비즈니스 민첩성, 실시간 정보 접근성 등과 같은 SOA의 가치 제안의 부각 △기존 사용자 사이의 SOA 적용 범위 확대 △웹2.0, 클라우드 컴퓨팅, 비즈니스프로세스관리(BPM) 촉매로서의 SOA 역할 확대 △SOA를 통해 더 효율적인 비즈니스 인텔리전스와 분석 가능 △인수합병(M&A)과 기업의 세계화 움직임으로 인한 통합 역량 요구 증대 등이다.

반대로 장애 요인으로는 △SOA 사업 투자 유보와 중단을 가져온 세계 경제위기 △가격 압박과 늘어진 세일즈 주기 △SOA의 주 수요처였던 금융권의 전반적인 침체 △개별 SOA 사업보다는 다른 프로젝트에 포함돼 번들 형태로 제공되는 양상 증가 등이 있다.

전 세계 SOA 서비스 시장에서 나타나고 있는 동향 중 특징적인 요소만 간단히 살펴보자.

◇SOA 적용 범위 증가=전 세계적인 경제 위기에도 불구하고 SOA의 기존 고객은 파일럿 프로젝트에서 나아가 이기종 시스템의 통합 프로젝트로 본격적인 사업을 진행하면서 적용 범위를 확대하고 있다. 특히, 기업의 세계화와 인수합병(M&A) 작업은 이러한 양상을 촉진하고 있다.

◇비즈니스 중심으로의 포커스 이동 및 프로세스 최적화 개발=SOA 적용의 주체가 기술 부서에서 비즈니스 부서로 옮겨가고 있으며 이러한 추세는 앞으로도 지속될 것이다. 따라서 IT 부서는 비즈니스 부서에 SOA에 대한 견실한 비즈니스 사례를 제공해야 한다는 압박을 받을 것이다. 또 비즈니스 부서가 SOA 프로그램에 참여하는 일이 증가하면서 SOA는 점차 유연한 비즈니스 프로세스를 개발하는 데 초점을 맞출 것이다.

◇비즈니스 프로세스 자동화와 관리=SOA 시장이 비즈니스 프로세스 향상에 주력하는 가운데 BPM에서도 SOA는 적정한 솔루션으로 부각되고 있다. 따라서 BPM과 SOA의 연계는 향상된 애플리케이션의 통합 능력으로 기업에 유연성과 민첩성을 제공해 주는 것으로 드러나고 있다. 그러나 두 기술의 조합이 비용이나 복잡성을 높인다는 인식이 팽배해 아직까지 성장 속도가 더디다.

◇엔터프라이즈 매시업=SOA를 기반으로 느슨하게 연결된 솔루션들과 컴포지트 애플리케이션 시장의 긍정적인 전망은 나오고 있지만, 본격적인 성장을 위해서는 지속적인 서비스 창출과 통합 수준이 높은 솔루션의 관리·통제 등과 같은 기반 요소가 먼저 마련돼야 한다.

◇고객 관리=SOA는 기존 고객 유지와 좀 더 나은 고객 서비스 요구 충족에 중요한 역할을 담당한다. SOA를 통한 안정적인 통합과 자동화를 이룸으로써 고객 요구에 즉각 대응할 수 있는 실시간 정보를 제공할 수 있어 콘택트센터 서비스의 질적 향상을 가져온다.

◇톱다운 접근=SOA 프로그램 실행에서 비즈니스 부문의 참여가 증가하면서 SOA 도입 방식이 점차 보텀업(bottom-up)에서 톱다운(top-down)으로 옮겨가고 있다.

◇임베디드 SOA=SOA를 기존의 다른 서비스 즉, IS 아웃소싱, 애플리케이션 아웃소싱, 레거시의 현대화, 유지보수 서비스 등에 포함시켜 제공하는 추세가 점차 보편화하고 있다. 이로써 서비스 업체는 그들이 제공하는 기존 서비스의 부가가치를 높일 수 있을 뿐 아니라, 신기술 도입에 대한 고객의 거부감을 줄여 시장 접근이 용이해지고 있다.

◇클라우드 컴퓨팅과 웹2.0=클라우드 컴퓨팅과 SOA는 점차 분리할 수 없는 개념으로 인식되고 있으며, 웹2.0 실행에서도 SOA는 중추적인 역할을 담당하고 있다. SaaS(Software as a Service) 또한 SOA 기반 위에 한층 유연한 서비스를 제공할 수 있는 것으로 나타나고 있다. 따라서 클라우드 컴퓨팅, SaaS와 더불어 SOA와 웹2.0의 결합은 서로 다른 비즈니스 조직 간의 원활한 교류 및 통합으로 전반적인 비즈니스 모델의 변화를 초래할 것으로 보인다.

◇SOA 거버넌스의 변화=SOA 거버넌스의 중요성이 확대되고 있는 가운데 성숙된 시장에서는 단순히 서비스 등록, 검색, 모니터링에 국한되던 거버넌스가 비즈니스 프로세스와 비즈니스에 가치를 부여할 수 있는 서비스 능력을 강화하기 위해 서비스 정책을 정의하는 것과 같은 비즈니스적 이슈를 강조하는 기능으로 바뀌고 있다.

◇서비스 아웃소싱=SOA 프로그램으로 조직 내에 창출된 서비스의 관리 및 유지보수 수요가 증가함에 따라 애플리케이션 아웃소싱이 점차 서비스 아웃소싱과 동일시될 것으로 보인다.

◇정보의 범람=범람하는 기업들의 비즈니스 정보 및 데이터 관리와 통합에 SOA의 역할이 점차 중요해질 것으로 보인다. 전자 의무기록과 스마트 그리드 즉, 지능형 전력망이 대표적인 사례다.

◇금융산업아키텍처네트워크(BIAN)=2008년에는 SAP와 마이크로소프트 등이 주요 은행 및 금융 애플리케이션 벤더들과 함께 은행권의 SOA 구현을 돕기 위해 BIAN을 설립했다. 이를 기반으로 선도적인 산업 전문가 그룹은 글로벌 은행과 함께 금융권에서 SOA 기반을 확대하기 위해 도메인 지식과 전문 기술을 공유하고 있다.

◇4대 인도 서비스 업체=인도 기반 서비스 업체들은 SOA 역량 확보를 위해 방대하게 투자하고 있다. 이들은 가격경쟁력을 확보하고 명확한 ROI를 제시하며 대규모 SOA 프로젝트를 진행함으로써 전 세계 시장에서 강력한 경쟁자로 부상하고 있다.

#침체 극복 후에는 고성장 기대돼

2009년 전 세계 SOA 서비스 시장은 2008년 대비 26.5%의 성장률을 기록하며 160억달러 규모에 이를 것으로 전망된다. 또 2013년까지 향후 5년간 21.7%의 연평균 성장률을 나타내며 337억달러 규모로 성장할 것으로 보인다.

결과적으로 비록 현재 SOA 서비스 시장이 전반적인 경제위기 때문에 다소 침체 양상을 보이고 있지만 △레거시 시스템의 현대화 △SOA의 장점 인식 확대 △비즈니스 부서에서 발생하는 복잡한 요구를 충족시키기 위해 한층 확장된 서비스 수요 확대 △웹2.0 및 클라우드 컴퓨팅 실현을 위한 SOA의 역할 증대 △BPM 수요 증가 등이 SOA 서비스 시장 성장에 동력으로 작용할 전망이다. 이런 이유로 장기적으로는 높은 성장세를 구가할 것으로 예상된다.

김경민 한국IDC IT서비스리서치그룹 선임연구원 mkim@idc.com

Simple SMS(Web Application)

2009-09-10T11:58:00.012+09:00

1 . 어플리케이션 개요
현재 SMS를 무료로 제공하는 사이트는 많이 있으나, 제공하는 사이트마다 각 계정을 따로 로그인을 해야 하며, SMS 이력관리가 각자 관리됨에 따라 불편함이 많이 있다. Simple SMS에서는 자신의 SMS의 사이트를 통합 관리하며, 보다 쉽게 무료 SMS을 보내며, 이력이 통합 관리하는데 목적을 두고 있다. 또한 웹으로 접속하여 사용 가능하게 하여, 언제 어디서나 쉽게 무료 SMS문자 메시지를 보낼 수 있는 장점을 가지고 있다.

2 . 시스템 구성

Simple SMS에서는 두가지의 어플리케이션으로 이루어진다.

1) 웹 어플리케이션
사용자의 편리를 위하여 웹을 통하여 SMS서비스를 제공하며, 언제 어디서나 브라우저가 되는 데스크탑이나 모바일 기기에서도 SMS 서비스가 가능하다.

2) 서버 어플리케이션
SMS Control은 서버 어플리케이션으로써 무료 SMS를 제공하는 사이트(Http 통신사용)나 서버(TCP/IP 통신사용)에 접속하여 SMS 데이터를 전송하고, SMS 전송 이력 데이터를 DB에 저장하여 관리한다.

3 . 어플리케이션 구성
1) 웹 어플리케이션
① 메인 화면

② 관리화면

2) 서버 어플리케이션
웹 어플리케이션이 SMS 전송 명령을 보낼 때마다 각 등록된 무료 SMS 사이트의 로그인하여 상태를 확인하고, SMS 메시지를 각 사이트마다 특정 방법에 따라 문자 메시지를 전송한다.

① HTTP 요청 프로토콜을 이용한 메시지 전송
Http 요청 프로토콜을 이용하여, 자동으로 서버 어플리케이션이 자동으로 직접 사이트에 로그인을 요청하고, SMS 메시지를 보내는 Http 요청하는 방법
② TCP/IP 소켓을 이용한 메시지 전송
특정 SMS 제공 사이트는 직접 SMS 전송 서버에 접속하여 그에 따른 SMS 전송 프로토콜
에 맞추어 SMS데이터 전송하는 방법

4. 추가 서비스
사이트 게시 SMS 알리미 서비스
사용자가 원하는 사이트의 게시 현황을 실시간으로 SMS 전송 해 주는 서비스로써 등록 해놓은 사이트의 글이나 데이터가 새로 게시되거나 수정되면 사용자에게 SMS문자로 게시된 글을 알려준다.
- 현재 가능 사이트 : Twitter, Cyworld, Naver Mail
** 상위의 사이트는 제가 필요에 의해서 채택한 사이트입니다.

사이트 게시 SMS 알리미 서비스 프로세스

위의 프로세스는 웹으로 서비스를 하는 모든 사이트에 적용 가능하다.

5. 개발환경
1) 개발언어
- 웹 어플리케이션 : ASP.NET Framework 3.5
- 서버 어플리케이션 : C#

2) 개발운영체제
- 서버: Windows 2003 Enterprise Server, IIS
- DBMS : MS-SQL 2005

3) 사용 TOOLS
- S/W 개발 : Visual Studio 2008

6. 나의 담당업무
웹 페이지 프로그래밍
SMS 전송 페이지 UI 디자인 및 웹 페이지 프로그래밍
서버 어플리케이션 프로그래밍
각 무료 SMS 문자 사이트 HTTP 분석 및 서버 TCP/IP 프로토콜 분석 및 서버 어플리케이션 프로그래밍, 특정사이트(Twitter, Cyworld, Naver 등) HTTP 요청 및 응답 분석

http://codeveloper.blogspot.com의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

HTML 5를 개척하는 새로운 웹

2009-09-09T20:26:00.006+09:00

Google 편

문서를 보기 위한 웹에서 응용 프로그램 플랫폼으로 HTML 5의 등장이 웹을 크게 바꾸려고 합니다. 해당 HTML 5에 대한 주요 웹 브라우저 벤더는 어떻게 생각하고 대응하려고 하고 있을까?
개방된 형태로 HTML 혁신을 추진하라
이번에는 구글 오이카와 타쿠야와 소프트웨어 엔지니어 타무라씨에게 Google Chrome 관련 HTML 5의 노력에 대한 이야기를 들었습니다.

그림 1 오이카와

타쿠야 그림 2 타무라

질문] 구글은 올해 샌프란 시스코에서 Google I/O, 일본에서 Google Developer Day 2009 에서 HTML 5에 대하여 크게 어필을 시작하고 있고 구글에서 HTML 5를 통해 일어나는 웹 세계는 어떤 것이라고 생각하고 있나요?

답변] 오이카와 올해 구글은 HTML 5에 대해 대대적으로 메시지를 보내고 있지만, 사실 작년부터 HTML 5는 시작하고 있었습니다. 지난해 Google I/O, 일본에서 Google Developer Day에서 클라우드, 연결성, 클라이언트 3개의 C가 중요하다는 이야기를 했습니다. 그 중 Connectivity와 관련된 상황에서 환경이 안정되어 있지 않거나 오프라인이 되거나 하는 상황에 대한 답변으로 Gears를 소개했습니다.
그 때의 Gears 방향으로 HTML 5의 표준화를 추진하고 있다는 것을 분명히 하고 있습니다. 그런 부분에서 HTML 5라는 키워드를 발표했습니다.
그 때부터 사실 메시지는 변경되지 않았고 웹 브라우저 크롬을 개발하고 있는 것도 똑같은 생각에서 앞으로의 웹은 정적 정보의 발신, 수신뿐만 아니라 응용 프로그램을 사용하는 장이 될 것입니다.
실제로, 많은 사람들이 PC에서 사용하는 것이라고 하면 웹 브라우저와 메일, 그리고 메일도 대부분의 웹 메일을 사용하도록 되고 있습니다.
이렇게 많은 사람들이 웹 쪽으로 사업과 생활을 나누게 될 때 네이티브 응용 프로그램이 웹에서도 얼마든지 할 수 있는 것이 당연한 모습이 아닐까요!
그때 필요한 것이, HTML의 혁신입니다. 그것도 개방된 형태로 혁신을 추진해야만 한다, 이것이 지난해부터 계속해 온 좋은 메시지 입니다.
HTML 5 스펙으로는 아직 네이티브 애플리케이션을 만들 수 없다.

질문] 당연히 웹에서도 네이티브 응용 프로그램과 동일한 수준이 가능할까요?

답변] 오이카와 그렇지 않습니다.

질문] 같을 수 있다는 점에서 많은 사람들이 회의적이라고 생각합니다. 네이티브 응용 프로그램과 웹 응용 프로그램의 자유도 및 실행 속도와 표현력에 차이가 있는 것은 아닐까. 하지만 그것들은 HTML 5를 기반으로 하므로 극복할 수 있다고 믿어도 될까요?

답변] 오이카와 네 그럴 것 같습니다. HTML 5는 그것을 때로는 가능 여부의 검증을 위해 사용할 때도 있지만, 좁은 의미의 HTML 5는 둘러싼 기술과 개방형 웹 기술이라는 것을 사용한다면 극복할 수 있다고 생각합니다.
현재 구굴 엔지니어링 부분 부사장인 Vic Gundotra는 이전 MS의 핵심 엔지니어로 있을 때 웹 애플리케이션과 데스크탑 애플리케이션에서 할 수 있는 것은 다르다고 생각했었다.
그 떄 당시 그가 주목하던 소프트웨어 공급 업체 중 하나인 KeyHole 라는 회사의 입체적인 지구가 빙글 빙글 움직이는 이런 것이야 말로 웹 응용 프로그램이 없는 원시 응용 프로그램이다 라고 알고 있었다고 합니다.
이것이 문득 생각이 나 KeyHole라는 회사를 구글에서 인수하였으며 또한 Gmail도 나오고, 점점 로컬에서 밖에 할 수 없다고 생각했던 응용 프로그램들을 웹에서도 가능하도록 시도 하고 있습니다.
비슷한 일이 앞으로 몇년 동안 일어날 것이고, 과연 웹에서 무리라고 생각했던 것이 HTML 5를 중심으로 한 개방형 기술을 웹 브라우저가 도입하고 그것을 응용 프로그램에서 사용한다면 가능하게 될 것입니다.

질문] 이렇게 HTML 5를 중심으로 한 새로운 표준과 기술과 함께 구글이 주력하고 있는 것은 무엇이 있습니까?

답변] 오이카와 먼저 기술이 개방되고 있는 것은 매우 중요하다고 생각합니다. 또한 예를 들면 Gears에서 하고 있는 것은 오프라인 기능, 프로세스, 스레드와 스케쥴링을 제공하는 Web Worker와 같은 것을 여러분의 동의를 얻어 구현과 표준화를 추진할 예정입니다.
O3D(웹 브라우저에서 3D 그래픽을 표시하기 위한 Google에서 제공하는 새로운 기술) 는 아직 연구 중인 HTML 5의 Canvas에 2D 그래픽스를 실현할 수 있게 되면 다음은 역시 3D가 아닌가 생각합니다. 이 부분 역시 구현을 진행해 가면서 표준화를 추진해 나가는 식이 될 것 같습니다.

질문] O3D 를 연구하는 것처럼 HTML 5에 아직 부족한 부분이 많이 있다고 생각합니다. HTML 5에 부족한 부분이 있다면 어떤 것이라고 생각합니까?

답변] 타무라 개인적인 느낌은 지금의 HTML 5의 스펙은 네이티브 애플리케이션과 같은 것을 만드는데 매우 부족하다고 생각합니다. 여러 방면의 API와 기능이 필요하다고 생각합니다.

답변] 오이카와 아직 HTML 5에 들어 있지 않은 스펙으로는 구글이 하려고 하는 것 중에 contentEditable 기능이 있습니다.
이 기능을 사용하여 웹 브라우저에서 쉽게 리치 텍스트 편집기를 제공할 수 있지만 현재는 표준이 충분하지 않기 때문에 웹 브라우저마다 구현이 상당히 다릅니다. 예를 들면 블로그에 편집기 같은 것들을 많이 구현되어 있고 편집기에서 텍스트를 선택하고 굵게 변경하고 다른 웹 브라우저에서 다시 편집기를 통해 원래대로 되돌리려고 해도 되돌아 가지 않는 경우가 있습니다.
이런 웹 브라우저마다 구현의 차이에 대응하기 위해 JavaScript를 사용하여 복잡한 프로그램을 써야 합니다. 그런데 이것의 표준화가 제대로 된다면 불과 몇 줄로 끝날 수 있습니다.
이 부분은 곧 HTML 5 스펙에 건의를 할 수 있는 상황에 와 있지 않나 생각합니다.
이 외에도 Notification 이라는 것을 검토하고 있습니다. 이것은 예를 들면, Google Calendar에 경고를 표시하기 위해서는 웹 브라우저 탭이나 어딘가에 열려 있지 않으면 안됩니다. 다른 탭에서 작동하는 경우에도 경고가 표시되면 강제로 탭에 포커스를 잃게 하는 것은 문제점이 있다고 생각합니다.
이러한 웹 응용 프로그램에서 알림 기능은 로컬 응용 프로그램처럼 응용 프로그램 화면에서 독립적인 모양이 좋지 않을까요? 이것은 표준화 작업 전에 구글에서 프로토타입을 만들고 그것을 보면서 표준화를 추진하려고 합니다.
그 이외에 아직 아이디어 단계에 있는 것들을 예로 들면, 역시 P2P의 일종, 웹 응용 프로그램이여 반드시 웹 서버와의 통신만 하는 것이 아닌 피어간의 통신을 하는 것들도 필요하지 않을까 생각합니다. 채팅 때는 일일이 서버를 경유하지 않아도 되니 괜찮을지 모릅니다.
또한 드래그앤 드롭 기능도 아직 한정되어 있으며 또는 파일 API에도 업로드 불가능한 파일을 제거하는 방법 등이 고려할 여지가 있을지 모릅니다.
예를 들면, 웹 브라우저 간에 여러 형태의 데이터 통신이 발생하는 것은 웹 개발팀에서 고민을 하고 있습니다. 실시간 채팅의 경우라면 짧은 데이터로 매우 빠르게 상호 작용하게 됩니다. 반면에, 많은 사진을 드래그 앤 드롭 하면 훨씬 많은 데이터를 전송하게 됩니다. 여러 파일 데이터 액세스 등이 필요하게 될 것입니다.
또는 웹 카메라와 마이크에 대한 액세스인데 이것은 Flash를 사용하고 있습니다. Flash에 의존하지 않고 로컬 리소스에 액세스를 가능하게 하고 싶습니다.

답변] 타무라 Gmail은 첨부 파일을 업로드하는 기능은 올 3월 경부터 Flash를 사용하여 다중 파일 처리와 업로드 상태 진행률 바를 나타내도록 하고 있지만 특정 브라우저 버전과 플래시 버전에 따라 동작의 차이가 있어, 역시 플로그인에 의존하는 것은 어렵다는 느낌을 받습니다. 이래서 파일을 다룰 부분은 검토하고 싶습니다.
또 하나의 Gmail이나 Docs 풀다운 메뉴가 있지만 브라우저 호환성을 위한 처리 떄문에 수천 줄 같은 코드를 작성하게 됩니다. 이것은 HTML 5의 메뉴 기능이 쉽게 구현할 수 있게 될 것으로 기대하고 있습니다.
폼 입력의 유효성에 대한 것은 HTML 5는 쉽게 할 수 있습니다. 개인적으로 이메일 주소의 유효성은 웹 사이트마다 제 각각이여 곤란한 경우가 종종 있는데 HTML 5의 검증(Validation)을 사용하여 type = email 로 쓰면 됩니다.

답변] 오이카와 웹 포럼에서 반각 문자(영어와 같은)에 치우치지 말고 자동으로 IME를 설정해주면 좋을 텐데라고 생각합니다. 아직 일본이나 아시아의 언어로 부드럽게 설정하려는 곳이 있기 때문입니다. 사실 이 부분은 가까운 미래에 아마 제 멋대로 될 것이라 생각합니다. IME 통합 등은 W3C 및 기타 브라우저 벤더들 하기 나름이기 때문에 대화로서 좋은 방법을 찾으려 하고 있습니다.
우리의 목표는 로컬 응용 프로그램과 유사한 다양한 웹 애플리케이션에 있습니다. 온라인과 오프라인에서 모두 사용 가능하게 되는 것입니다. 거기에 부족한 것은 구현하고 표준화를 진행하고자 합니다.

질문] 그런 기술을 보급하는데 얼마나 많은 시간이 걸릴 것으로 예상하고 있습니까?

답변] 오이카와 어떤 것을 기준으로 해야 할지 어렵습니다.

질문] 예를 들면 Gmail 또는 Google Wave에서 HTML 5의 기술을 사용하여 공개 출시하는 것이나 그와 비슷한 것들?

답변] 오이카와 HTML 5를 사용한 것은 꾀 빠르다고 생각합니다. 지금 Google Wave팀과 긴밀한 커뮤니케이션을 하고 있지만 HTML 5의 기술을 매우 이른 단계에서 사용하기 시작한 것이 아닐까 생각하고 있습니다.
왜냐하면, HTML 5를 말하는데 가장 중요한 것은 일부 스펙은 사용하기 시작한지 얼마 되지 않았고, Canvas의 경우에는 올해 반년 동안 매우 빠른 속도로 사용되어지고 있기 때문이 아닐까 생각합니다.

답변] 타무라 Gmail도 지금 각 브라우저에서 저장이나 응용 프로그램 캐시 기능을 구현하는 것을 시작하고 있기 때문에 조속히 구현하고 있습니다. 이런 식으로 무엇인가 구현을 시작한다는 느낌입니다.
(리오 : 결론은 아직 한참 멀었다는 이야긴가?)

답변] 오이카와 또 Canvas가 구현되지 않은 Internet Explorer는 ExplorerCanvas라는 JavaScript 라이브러리를 사용해서 기본적인 기능을 사용할 수 있습니다. 그리고 Flash에서 사용되고 있는 벡터 형식의 그래픽을 허용하는 SVGweb은 JavaScript 라이브러리를 Google에서 지원합니다. 사실 이외에도 있지만 비밀입니다.(웃음)

질문] 모바일에 관한 이야기는 없나요? 지금까지 모바일과 PC는 각각 기술적으로 나누어진 세계였습니다. 그러나 특히 iPhone과 Android의 등장으로 PC와 모바일에서 동일한 웹의 세계를 볼 수 있도록 되어있습니다. 앞으로는 모바일 및 PC 웹이라는 것이 기술적으로 동일하게 흘러간다고 생각합니다만 어떻게 생각하세요?

답변] 타무라 네 맞는 말이라고 생각합니다. Android와 iPhone는 대중적이고 휴대전화 전용 웹이라는 것은 사라져 간다고 생각합니다.

답변] 오키카와 완전히 동감입니다. 인터넷이 장치에 의해 분리되었다는 것은 매우 이상하다고 생각합니다. 그 원인은 기술 문제와 비즈니스 모델의 문제가 겹쳐서 발생했던 것입니다.
사업 모델에 대해서는 각 이동 통신사들 및 컨텐츠 제공 업체가 별도라는 생각 떄문에 그런 것 같습니다. 기술에 의한 분단은 이제 확실하게 사라져 간다고 생각합니다.
그러나 몇 가지 제약이 있습니다. 메모리와 프로세서 파워 등은 PC와 같이 매년 증가해가는 것은 당분간 어렵다고 생각합니다. 그리고 넓은 대역폭과 지연시간에 대해서 좀더 개선해야 한다고 생각합니다. 그런 측면에서 모바일의 웹 브라우저와 PC용 프로그램을 모바일에서 사용하기 위한 준비도 빠르게 진행되기란 어려울 것입니다.

소감] 오늘 이야기를 들어 보았던 HTML 5의 스펙과 구현의 목적은 역시 응용 프로그램 플랫폼 표준화가 되어가는 것이군요. 마치 Window + .NET과 JavaVM + Java SE 처럼도 보입니다.

소감] 오이키와 그런 것 같네요. 구글은 그런 멋진 말은 없지만, 웹이 플랫폼이 되는 것은 맞습니다. 또 “웹 브라우저” 에서 묵묵히 “웹 클라이언트”으로 변해 갈 수도 있습니다. 그것이 플랫폼으로 인프라가 되려고 하고 있고 그것은 사실이라고 생각합니다.

요약(필자)
구글이 웹 브라우저 응용 프로그램 플랫폼 만들고 있다는 사실은 지금까지 누구라도 알고 있습니다. 그러나 그 목표가 “웹 브라우저에서 네이티브 응용 프로그램 같은 것을 제공한다”라고 명확하게 한 것에 대해 놀라지 않을 수가 없습니다. 게다가 그것을 플러그인 기술이 아닌 기본 스펙에서 실현하려는 수단까지 명확하게 하고 있습니다. 구글이 여기까지 영입하고 자원을 투입하고 있는 이상, 그것은 아마도 언젠가는 실현되는 것이 분명할 것입니다. 아니 “그것이 언제 실현 될지?” 라는 질문할 수 있는 시점까지 와 있는지 모릅니다.

요약(리오)
짧은 인터뷰 내용이지만 구글의 HTML 5 그리고 표준화에 대한 진행은 웹 이라는 것을 새로운 플랫폼으로 재 탄생 시키려는 혁신이고, 구글의 미래이자 다가올 웹의 미래가 아닐까 생각해봅니다.
최근 구글은 넷북 시장에 관심을 갖고 있으며 여기에 크롬 OS와 앱 스토어와 같은 마켓 플레이스를 향하고 있다는 생각을 해봅니다. 결과는 아래의 그림과 같은!?

[CoDeveloper 생각] 제 생각에는 넷북 시장이 아니라 모바일 시장을 노리고 있습니다. 데스크탑에서 넷북으로 시장으로 옮기는 것보다 모바일쪽으로 옮기는 게 커다란 목표 일 것입니다. 그런데 문제는 아직 웹으로 커버하기에는 기술적으로 문화적으로나 문제가 있다는 것입니다. 넷북은 이미 웹으로 넘어간 상태이고요. 안드로이드에 크롬OS가 혼합한다며 서비스 시장을 구글이 잠식하는 것은 시간 문제지요.. 마소 저리 가라 입니다...

그림 3 미래 구글의 마켓 예상
더 큰 그림이 있겠지만 HTML 5를 중심으로 한 개방된 기술의 형태 그리고 네이티브 애플리케이션들이 웹 애플리케이션으로 바뀐다는 것은 윈도우에 종속되었던 네이티브 애플리케이션 시장이 이제 웹에서도 똑같이 열릴 수 있다는 것입니다.
구굴이 생각하는 시나리오는 성공하리라 생각해봅니다.
지금부터 조금씩 준비해 나가면 새로운 시장에서 개발자 각 개인도 애플 앱 개발자들 처럼 작은 꿈을 꿀 수 있지 않을까?
구굴이 주도 하는 HTML 5의 중심의 웹의 미래를 미리 짐작해 볼 수 있는 좋은 자료인 것 같습니다.
하지만 오역이 있을 수 있습니다. : )
출처 : http://www.atmarkit.co.jp/fwcr/design/benkyo/html5_01/01.html

출처 : http://rhio.tistory.com/331

My Comment
HTML5 이전에 스펙을 봤지만, 저도 의아해 한게 왜 웹소켓이 서버끼리만 되게 하는 건지 P2P형식이면 보다 효율적일껀데라 생각했는데 똑같은 답변을 해주네요.. 서버 사이드는 서비스 끼리 개방적으로 묶여야 하겠지만 클라이어트 사이드도 클라이언트끼리 묶고 싶어하는 게 현실입니다. 기존 C/S 구조에서도 사용자가 P2P를 원했으면, 당연히 웹에서도 원하는 건데.. 또한 이슈 되는 것은 오프라인일때 대책이 너무 없다는 거죠. 특히 OS가 웹OS로 바뀐다면 그 문제는 해결 해야 하는 것이죠. 구글 혼자서 해결 했다고 해서 모든 사용자가 쌍수 들며 환영하는 것은 아닐테니까요.. 그리고 왜 웹이 응용어플을 대체 해야 하는 건지도 꼭 그럴 필요가 있는지 응용 어플과 웹이 공존하는 방법도 괜찮겠지요. 지금처럼 말입니다. 어떻게 생각하면 소비자는 고래 싸움이 새우등 터지는 꼴 나는 거죠. 웹이든 응용어플이든 편하고 서비스 더 좋은 것을 사용자는 선택할 권리가 있습니다. 당연 언젠가는 웹으로 바뀐다면 사용자는 스스로 선택하여 바꿀 지 언정 표준(사용자,기업,단체의 서로에게 이로운 방향으로 가야하는게 맞음)이나 기업의 횡포에 의해 바뀌면 안된다는 것은 당연한 사실입니다.

나의 관심사와 내가 생각하는 소프트웨어 미래...

2009-09-07T18:32:00.007+09:00

1. Rich Internet Application
새로운 어플리케이션의 혁명은 바로 “Rich Internet Application”(이하 RIA) 일 것이다.
그러면 무엇이 RIA인가? 현재는 RIA는 "인터넷을 풍부하게(Rich)"한다는 의미에서 동적 웹 어플리케이션을 지칭하고 있으나 이것들은 현재의 RIA일지는 몰라도 앞으로의 RIA가 될 수는 없다. 확실한 것은 RIA는 플랫폼 독립성이어야 하며, 사용자가 언제 어디서나 어플리케이션에 접근이 가능하여야 한다. 이러한 이유로 Adobe의 "Flash"나 Microsoft의 "Siverlight"는 미래의 RIA의 시장의 대표가 될 수 없을 것이다. 앞으로 RIA가 어떻게 탄생 할지는 개발자의 몫에 담겨 있으며, 나도 이 그룹에 합류하고 싶다.

2. JQuery
AJAX라는 새로운 혁명은 거의 사장되고 있던 JavaScript를 회생 시켜주었다. 현재 JavaScript의 프레임워크는 계속 발전하고 있으며, 차기 Visual Studio 2010 프레임워크에 포함될 JQuery에 관심을 가지고, 공부 하고 있는 중에 있다. 그러면 “왜 JQuery가 선택한 것인가?” JQuery는 까다로운 크로스 브라우저 해결할 수 있다. Flex나 Siverlight처럼 미들웨어를 설치하지 않고도 바로 동적 웹 어플리케이션을 제작이 가능하다. 나는 AJAX와 더불어 JQuery(또는 다른 Java Script Framework)가 새로운 RIA를 탄생 시킬 것이라고 생각하고 있다.

3. Cloud Computing
인간의 역사는 돌고 돌게 되어 있다. 컴퓨터의 역사 또한 그 진리를 벗어나지 못할 것이다. 컴퓨터의 역사는 Mainframe인 중앙 컴퓨팅 방식에서 Desktop인 개인 컴퓨팅 방식, 그리고 서로 통신을 위해 네트워크 컴퓨팅 방식으로 변화해 왔다. 이러한 결과는 다시 중앙 집중 컴퓨팅 방식인 Cloud Computing으로 회기 하고 있다. 한번은 "Cloud Computing: New Wine or Just a New Bottle?"라는 매거진을 읽은 적이 있다. 결론은 개발자가 어떻게 사용하느냐에 따라서 미래가 결정 될 것 이다는 내용이었다. 과연 “나의 생각은 어떠할까?” 새로운 와인은 아닐 지 몰라도, 앞으로 발전할 분야라는 것은 확실하다고 생각한다.

4. Service Oriented Architecture
Service Oriented Architecture(이하 SOA)는 정의가 잘된 인터페이스와 서비스들간의 연결을 통해 서비스를 하기 위한 모델이다. 구현은 각 하드웨어 플랫폼, 운영 체계에 따라 독립적으로 정의 되어 다양한 시스템에서 설계가 가능하나 인터페이스 자체는 중립적 인터페이스로 여러 시스템에서 접근이 가능하여야 하는 약 결합 구조로 만들어져야 한다. 오늘날 잘 알려진 SOA 구조는 웹 서비스로 SOAP 프로토콜을 통한 XML 데이터 전송방식으로 데이터 전송이 이루어진다. “왜 나는 SOA에 관심이 있는가?” 내가 관심 있는 분야는 말하자면 웹 서비스가 절대 아니다. SOA라는 개념에 관심이 있는 것이다. 서비스 지향으로 설계 하는 것이야 말로 앞으로 어플리케이션의 혁명이 될 Mashup, Cloud Computing으로 쉽게 갈 수 있는 징검다리 역할을 할 것이 분명하기 때문이다. SOA를 만들 수 있는 것이 현재 웹 서비스로 알려져 있지만, 유일한 해결책은 아니라는 소리다. 예전에 RPC 분야에서도 SOA는 가능했다. 그러나 웹 서비스의 장점인 플랫폼 독립성을 확보하지 못했다는 커다란 약점은 RPC의 대표 주자 CORBA에게는 치명적인 약점이 될 수 밖에 없었다. 그러나 웹 서비스도 약점이 없는 것은 아니다. XML은 모든 플랫폼에 적용될 수 있는 최고의 솔루션일지 몰라도 성능상 약점을 많이 가지고 있다 그러면 “SOA는 어떻게 바뀔 것인가?”에 대한 의문은 모든 개발자들이 가지고 있을 것이다. 앞으로 나도 더욱 소프트웨어를 공부하여 IT분야의 기술을 이끄는 인재가 되고 싶다.

5. 결론
Rich Internet Application, Cloud Computing, Service Oriented Architecture는 앞으로 어플리케이션의 새로운 기술이 될 수 없을지는 몰라도, 흐름을 알 수 있는 중요한 열쇠 역할을 한다. 3개의 공통점은 중앙 집중식 서버 방식을 추구 한다는 것이다. 앞으로 사용자 플랫폼은 지금보다 더 가벼워지고, 더 다양해 질 것이며 그에 맞는 서비스를 제공하기 위해서 예전처럼 특정 플랫폼의 설치형 어플리케이션이 살아 남기 힘들 것이다. 즉 지금 현재에서 가장 미래의 서비스를 맞추고 있는 어플리케이션은 웹 어플리케이션이라고 볼 수 있다. 그리고 모든 서비스는 서비스들끼리 네트워크를 이룰 것이다. 현재 데스크탑끼리 네트워킹이 되는 것처럼 말이다. 앞으로 Cloud Computing, RIA, SOA,, Mashup이라는 용어는 사라지거나 다른 새로운 용어로 대체 될지 모르지만, 서버 중심의 어플리케이션은 계속 발전해 나갈 것이다. 소프트웨어 개발자들은 앞으로의 흐름을 먼저 내다 보고 준비해야지 새로운 소프트웨어의 세계에서 적응해 나아갈 수 있을 것이다.

6. 내가 생각하는 소프트웨어의 미래는…

클릭하시면 크게 보실 수 있습니다.

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

MS 준 HD, 윈도 모바일 7 코어 기반으로 출시

2009-08-31T10:30:00.004+09:00

마이크로소프트 준(ZUNE) 시리즈는 지난 2007년 말 출시된 2세대까지 줄곧 마이크로소프트 윈도 CE 운영체제 기반이었습니다. 하지만 다음 달 북미 시장에 출시되는 준 HD는 운영체제로 윈도 모바일 7이 탑재될 것으로 보입니다.

윈도 모바일 7은 2010년 상반기 정식 공개될 예정이며 이번에 처음 공개되는 준 HD 윈도 모바일 7 코어 탑재 관련 소식은 그동안 마이크로소프트 정책상 이에 관한 언급 자체가 미뤄져 왔습니다.

준 HD에 탑재될 윈도 모바일 7은 모뎀(3G 통신), 카메라 등이 제외된 하드웨어이며 가벼운 형태의 라이트(Lite) 형태의 코어를 기반으로 합니다. 2010년 상반기에 출시되는 윈도 모바일 7은 초기에 테그라, 스냅드래곤 칩셋으로만 지원될 것으로 알려져 있는데 준 HD 역시 테그라 칩셋이 탑재돼 윈도 모바일 7 하드웨어 요구조건을 만족시킵니다.

윈도 모바일 7은 기존 마이크로소프트 모바일 운영체제와 크게 달라진 모습을 보입니다. 우선 완벽한 커널 구조 개선과 변경으로 성능과 시스템 안정성 모두 기존과 완전히 다른 수준으로 바뀌었고 수많은 윈도 모바일 애플리케이션과도 호환됩니다.

윈도 모바일 기반 윈도 CE 역시 기존 5.0에서 6.0 버전으로 완전히 변경돼 비교하기 어려운 수준으로 성능이 높아졌습니다. 차세대 모바일 운영체제 탑재로 준 HD용 애플리케이션은 크게 달라진 모습으로 등장할 가능성이 높습니다.

마이크로소프트가 10여 년간 사용하던 모바일 운영체제 커널을 걷어내고 새로운 커널 기반으로 개발한 윈도 모바일 7을 모바일 미디어 플레이어 준 HD에 탑재했다는 사실은 분명히 환영할만한 요소입니다.

애플리케이션 설치를 통한 확장 지원 여부는 더욱 확실시 되었다고 볼 수 있는데요. 과연 마이크로소프트가 준 HD를 진정한 아이팟 터치의 대항마로서 키워나갈 수 있을지 주목됩니다.

준 HD를 위한 XNA(마이크로소프트가 개발한 게임 개발 프레임워크) 라이브러리 역시 포함되어 있어 엑스박스360 게임 콘텐츠도 사용할 수 있을 것으로 보여 여러 면에서 아이팟 터치와의 흥미로운 비교거리가 될 것으로 보입니다.

My Comment
역시 윈도우 모바일 7을 운영체제로 하게 되었군요. 역시 애플의 서드파티를 무시 할수 없겠죠. 그동안 나왔던 수많은 애플의 어플들을 새로 시작하면서 따라잡기는 힘들 것 같습니다... 그러나 WM7으로 나온다면 이야기가 조금 달라지죠. 그동안 나온 WM용 어플도 무시 못할 만큼 상당하니까요.
과연 승자는 누가 될것인가?
저도 되게 궁굼하네요.

참고로 MS와 Apple의 입장을 보면 MS는 소프트웨어를 팔아서 이윤을 챙기는 회사이며, Apple은 하드웨어를 팔아서 이윤을 남기는 회사입니다. 역시 MS는 소비자를 가두기 위해 소프트웨어로 가둬야 좋은 것이며, Apple은 하드웨어로 가둬야 하는 것입니다. 70년대 하드웨어가 비싸던 시절은 컴퓨터 시장에서 IBM, SUN, Apple은 하드웨어로 큰 이윤을 남겼으며, 90년대 소프트웨어의 발전을 예견치 못한 하드웨어 업체들은 MS라는 강적을 만나 무수히 쓰러져 갔으며, MS는 소프트웨어로 모든 소비자를 가두었답니다. 다시 포터블 시장이 커지면서, 어떤 것이 우선일지는 기업이 잘 판단하여, 앞을 내다봐야 하는 겁니다. MS는 컴퓨터 시장에서 최근 소프트웨어보다 서비스 시장이 발전할지 예견치 못한 체, 계속 구글에게 카운터를 맞고 있으며, 포터블 시장에서 작은 소비자를 잡지 못하여 Apple에게 크로스를 맞고 넉다운 중입니다. 거기에 데스크탑 시장의 비스타가 한 역활은 무시하지 못하죠. 그래도 거대 공룡인 아니 거대 제국인 MS를 흔들리기 하기에는 아직 부족한 부분이 많죠. 거대 기업 IBM은 지금도 살아 있으니 말입니다. ㅎㅎㅎ 어째거나 MS와 Apple의 모바일 시장의 경쟁, MS와 Google의 서비스 시장의 경쟁, 추가로 MS,Google,Apple의 OS 시장의 경쟁은 소비자에게 많은 선택권과 혜택을 가져 올 것은 당연지사입니다. 앞으로 어떻게 될지 2010년 이후 IT는 어떻게 흐를지는 앞으로 지켜보면 재미있을 것 같습니다.

PS. 이놈의 한국은 이러한 기업 경쟁으로 인한 소비자의 선택및 혜택을 제공 받기는 힘들 것 같습니다. 특히 서비스는 관공서, 공공기관까지도 MS OS가 아니면 안되는 진짜 선택도 할 수 없는 자기만 생각 하는 나라 같네요. 이런 천재일우에서 MS의 손아귀에서 빠져 나올 수 있는 방법은 많이 있을 텐데 말입니다. 그렇다고, OS를 TMAX OS를 모두 바꾸자고 주장하는 정부라면 이런... 할말 잃습니다. 머리가 있으면 그렇게 안하겠죠. TMAX의 OS는 MS의 OS의 복제판일 뿐이니까요. 그렇게 될 경우에는 서비스 시장도 기존 체제 그대로 유지가 가능하겠지만, MS의 손아귀에서 빠져 나온 것은 아니라는 것을 명심해야 합니다.

클라우드 컴퓨팅, SSD 확산의 기폭제 된다

2009-08-26T17:56:00.004+09:00

클라우드 컴퓨팅, SSD 확산의 기폭제 된다 IDG 2009.08.26
급성장하고 있는 두 가지 기술인 클라우드 컴퓨팅과 플래시 기반 스토리지가 인기가 날로 높아지고 소셜 네트워크 서비스의 데이터센터에서 만나 상호 성장의 기회를 만들어내고 있다.
마이스페이스와 페이스북 같은 웹 기반 소셜 네트워크 서비스 업체들은 수천 명의 사용자에게 동시에 데이터를 전송해야 하는 서비스의 특성 상 향후에는 플래시 스토리지 기술이 필수적일 것으로 전망하고 있다.
올 여름 샌프란시스코에서 열린 기가OM 네트워크 스트럭처 09 컨퍼런스(GigaOM Network's Structure 09 conference)에서 마이스페이스의 기술 담당 부사장(vice president of technical operations) 리처드 버킹엄은 “지난 20년간 디스크 스토리지의 회전 속도는 사실 거의 빨라지지 않았고, 지금 우리는 플래시 기술과 함께 스토리지 기술 변화의 첨병에 있다고 볼 수 있다”고 밝혔다.
같은 컨퍼런스에서, 페이스북의 기술 담당 부사장 조나단 하일리거(Jonathan Heiliger)는 “플래시는 단지 저장장치로서가 아니라 전체 인프라스트럭처로서 매우, 매우 중요한 위치를 차지하게 될 것이다. 플래시는 적어도 싱글코어에서 멀티코어로 이행하는 정도의 파급효과를 가져올 것”이라고 전망했다.
플래시 저장장치는 특정 데이터 비트를 읽기 위해 디스크가 회전할 필요가 없기 때문에 하드디스크 드라이브보다 빠르다. 저장장치의 어느 지점에 위치한 데이터를 읽기 위해 수백 ms가 걸리는 기존의 하드디스크 드라이브에 비해 SSD(Solid-State Disk)와 PCI 익스프레스 플래시 카드와 같은 플래시 기술을 이용하면 훨씬 짧은 시간 안에 데이터를 읽을 수 있다. 또한 SSD와 플래시 스토리지 시스템은 디스크 스토리지에 비해 공간을 적게 차지하고 전력 소모도 적다.
포레스터 리서치의 분석가 앤드류 라이히만은 클라우드 기반 기업들의 데이터센터는 너무나 규모가 크기 때문에 플래시 스토리지의 장점이 더욱 두드러지게 나타난다고 설명했다.
그러나 분석가들에 따르면 기업 IT 부서가 성능 향상에 따른 이익을 기대할 수 있는 반면, 플래시 기술의 높은 비용이 기업 시장에서 플래시 보급을 더디게 할 것으로 보인다. IDC의 분석가 제프 자누코비츠는 SSD 저장장치가 디스크 저장장치에 비해서 기가바이트당 25배 가량 비싼 것으로 분석했다.
그럼에도 불구하고 IDC는 더 나은 성능과 향상된 용량, 그리고 낮은 전력 소비량에 대한 대규모 웹 기반 기업들의 수요 증가는 2013년까지 기업용 SSD 판매량을 매년 평균 165%씩 증가시킬 것으로 전망한다. 가트너 또한 플래시 사용량이 급증할 것으로 전망하며, 작년의 5만 9,000대 판매에 비해 2009년에는 28만 1,000대의 SSD가 판매될 것으로 예상하고 있다.
클라우드에 저장된 데이터에 대한 빠른 접근과 더불어 페이스북은 플래시 저장장치가 다른 스토리지 시스템에 비해 현저히 적은 전력을 소모함으로써 엄청난 신뢰도 향상을 가져다 줄 것으로 기대하고 있다.
마이스페이스는 플래시 스토리지가 사용자들이 요구하는 빠른 페이지 로딩 속도를 유지하면서도 데이터센터의 공간을 절약해 줄 것으로 기대하고 있다. 디스크 드라이브를 플래시 스토리지로 교체함으로써 마이스페이스는 두꺼운 2U 서버 대신 1U 모델들을 사용할 수 있게 되며, 이는 총 60,000평방피트를 차지하고 있는 데이터센터의 공간을 획기적으로 줄일 수 있다는 것을 뜻한다.
버킹엄은 또한 앞으로 자주 사용되는 데이터와 검색 인덱스를 캐싱하는 데에 플래시 기술을 이용할 계획이라고 밝혔다.
하지만 이들 소셜 네트워킹 서비스는 사용자들이 올린 사진과 같은 보관용 데이터를 저장하는 데는 플래시를 사용하지 않을 것으로 보인다. 버킹엄은 회사의 데이터 중 1/20 정도만이 플래시에 저장할 것이라며, “나 같으면 뭔가를 SSD에 저장해 놓고 영원히 지속되기를 바라진 않을 것”이라고 덧붙였다.
마이스페이스는 현재 플래시 제조업체들과 함께 기준이 될만한 성능과 신뢰도 수준을 정립하기 위해 작업을 진행 중이다.
이렇게 날로 증가하는 수요에 맞춰 지난 해 주요 스토리지 업체들은 앞다퉈 플래시 기반 스토리지 제품을 발표했다.
EMC는 그들의 몇몇 스토리지 제품군에 SSD 테크놀로지를 추가했고, IBM은 올해 말까지 자사의 모든 기업용 스토리지 플랫폼에서 플래시를 선택할 수 있게 할 예정이다. 한편 HP는 자사의 하이엔드 XP 스토리지 어레이와 미드레인지 엔터프라이즈 버츄얼 어레이에 SSD 기술을 적용했으며, 자사 서버 제품에 탑재할 수 있는 퓨전아이오의 플래시 스토리지 제품도 공급하고 있다.

My Comment
SSD가 빠르다는 것을 몰랐던건 아닙니다. 그러나 아직 네트워크 속도가 뒷받침 못해준다는 것과 아직 SSD 제품군이 비싸다는 두가지 이유 때문에 안쓰고 있다고 생각 드네요. 지금은 아직 시기상조 앞으로는 많이 쓰일 스토리지 제품군이니까 투자하는 것도 나쁘지는 않은 생각입니다.

마이크로소프트 MS 워드 특허침해 기사

2009-08-26T17:25:00.002+09:00

MS 워드, 특허침해로 3억 달러 배상에 판매 금지 판결 2009년 8월 13일 idg.co.kr
마이크로소프트가 거의 3억 달러에 가까운 손해 배상금을 캐나다 업체 i4i에 지불해야 한다. 마이크로소프트의 워드가 XML 커스텀 포맷 기반 문서 시스템에 관한 i4i의 특허를 침해했다는 것.
미국 지방법원 판사 레오나드 데이비스는 또 마이크로소프트의 워드 2003, 워드 2007, 그리고 맥용 워드 2008의 미국 내 판매 금지 명령도 내렸다. 이 금지 명령은 오는 10월 10일부터 효력이 발생한다.
지난 5월 배심원들은 i4i에 2억 달러의 손해 배상을 하라는 평결을 내렸지만, 데이비스 판사의 최종 판결은 지난 11일까지 내려지지 않고 있는 상태였다. 이번 판결에서 마이크로소프트에 내려진 손해배상 총액은 다음과 같다.

- i4i 특허 침해에 대한 손해 배상
- 마이크로소프트의 고의적인 침해에 대한 추가 손해배상 4,000만 달러
- 5월 배심원 평결 이후의 추가 손해 1,180만 달러
- 지연손해금 3,880만 달러

총액은 2억 9,060만 달러에 달한다.
마이크로소프트는 이번 판결에 항소할 계획이라고 밝혔다. 마이크로소프트의 대변인 케빈 커츠는 “이번 법원의 결정에 매우 실망하고 있다”며, “우리가 특허를 침해하지 않았고, i4i의 특허가 유효하지 않다는 것을 증거가 보여주고 있다”고 강조했다.
데이비스 판사의 명령에 따르면, 마이크로소프트는 워드 2003과 워드 2007, 이들을 기반으로 하는 마이크로소프트 워드 제품을 판매할 수 없으며, 향후에도 커스텀 XML을 포함하고 있는 .XML이나 .DOCX, .DOCM 파일을 열 수 있는 워드 제품은 판매할 수 없다.
.DOCX는 오피스 2003부터 도입된 것으로, 워드 2003과 워드 2007의 기본 파일 포맷이며, .DOCM은 동일한 파일 포맷이지만, 매크로를 사용할 수 있다. 워드 2003과 워드 2007의 파일 포맷은 다르지만, 둘 다 XML 기반이란 점에서 동일한 규제를 받는다.
이미 판매가 되고 있는 맥용 워드 2008과 내년 상반기에 출시될 것으로 예상되는 오피스 2010에 포함된 워드 2010 역시 동일한 파일 포맷을 지원하기 때문에 이번 판결의 영향을 받는다.
마이크로소프트 오피스의 파일 포맷이 문제가 된 것은 이번이 처음은 아니다. 대표적인 사례가 지난 주 마이크로소프트가 유럽 지역에서 판매되는 오피스 2010에서는 밸럿 방식으로 파일 포맷을 선택할 수 있도록 하겠다고 밝힌 것이다.

MS 워드 판매 중지 명령, “신속한 항소 진행, 유예는 불가” 2009년 8월 26일 idg.co.kr
연방법원이 마이크로소프트의 워드 프로그램 판매 금지 명령에 대한 마이크로소프트의 신속처리 청원을 승인했다.
미국 연방순회항소법원은 지난 주 마이크로소프트가 항소심을 신속하게 진행해 달라고 한 요청을 받아 들였다. 하지만 법원은 기존 명령이 효력을 상실할 수 있다는 이유로 명령의 집행 유예 신청은 받아들이지 않았다.
마이크로소프트에게 오는 10월 10일부터 워드 2003과 워드 2007을 현재 형태로 판매하지 못하도록 한 이 명령은 지난 8월 11월 미국 지방법원 렐오나드 데이비스 판사가 내린 것이다. 마이크로소프트가 텍사스 배심에 의해 캐나소 소프트웨어 개발업체 i4i의 특허를 침해한 것이 유죄라고 인정됐기 때문이다. 데이비스 판사는 이와 함께 i4i에 2억 9,000만 달러상당의 손해배상을 지급하라고 판결했다.
마이크로소프트는 8월 18일 항소가 이뤄질 때까지 명령을 유예해 달라는 재정신청을 제출했다. 이 신청서에서 마이크로소프트는 명령이 유예가 되지 않으면, 자사의 판매는 물론 델이나 HP와 같은 OEM 협력업체들까지 엄청난 혼란을 겪게 될 것이라고 경고했다.
경력 17년의 특허 전문 변호사는 마이크로소프트가 워드의 문제가 된 커스텀 XML 기능을 제거한 버전을 신속하게 만들 수 있을 것이라고 지적했지만, 마이크로소프트 측은 워드 2003과 워드 2007을 10월 10일까지 수정하는 것은 불가능하다고 주장했다.
항소법원의 소송 일정에 따르면, 마이크로소프트는 8월 26일까지 명령 유예를 위한 자사의 논지를 요약한 약식 보고서를 제출해야 한다. 이에 대한 i4i의 대응 보고서는 2주 후인 9월 8일까지, 그리고 이에 대한 마이크로소프트의 답변은 9월 14일까지 제출해야 한다.
구두 청문회는 9월 23일, 즉 명령이 발표되기 3주 전에 열릴 예정이며, 이후 항소법원이 마이크로소프트의 청원에 대한 평결을 내리게 된다.
1심 재판을 맡은 데이비스 판사는 판결 요약문에서 5월 재판에 제출된 증거로 볼 때 마이크로소프트가 커스텀 XML 기능을 워드에 추가해 i4i의 소프트웨어를 “쓸모없는 것”으로 만들었다고 밝혔다.
데이비스 판사는 또 마이크로소프가 이런 평결과 명령에도 기존의 사업을 그대로 유지하려 한다며, “수년 간의 소송과 배심의 침해 평결에도 불구하고 마이크로소프트는 자사의 문제 제품을 계속 판매할 것으로 요청하고, 똑같은 특허 침해 기능을 가진 신제품을 출시하려 한다”고 지적했다.
한편 i4i는 이렇게 당겨진 소송 일정에 대해 아직 아무런 코멘트도 하지 않고 있다. editor@idg.co.kr

My Comment
마이크로소프트는 이래저래 소송에 휘말리네요.. 벌려놓은 일이 많으니 기세가 약할 때 죽이는게 상책인지... 어떻게 될지 궁금하네요..

마이크로소프트는 어째서 Zune HD용 소프트웨어를 개발할 수 없을까?

2009-08-25T16:23:00.004+09:00

RoughlyDrafted Magazine

Daniel Eran Dilger in San Francisco

Why Can’t Microsoft Develop Software for Zune HD?

August 15th, 2009

http://www.thehighconcept.com/zuneHD.jpg

Daniel Eran Dilger

한 아이폰 개발자로부터 제보가 있었다. 자신의 트위터 앱을 Zune HD용으로 포팅할 수 있다면 "상당한 돈(a bucket of money)"을 주겠다는 약속이 있었다는 내용이다. 분명한 질문은, Zune 소프트웨어 작성에 그정도의 돈이 들어가는데 마이크로소프트 스스로 하지 않는 이유가 무엇인가이다. 스스로 작성하면 그만큼 절약할 수 있잖은가?

진짜 이유는 이러하다. Zune용 소프트웨어 개발이 돈이 안된다는 점을 마이크로소프트도 알고 있다. 따라서 자신의 자원을 이런 가치낮은 소프트웨어 개발에 투자하고 싶어하지 않는다.(마이크로소프트에게는 막대한 현금이 있다.) 그러나 문제가 있다. Zune HD용 앱을 개발하기 위해 아이폰 앱스토어를 떠날 모바일 개발자들이 과연 있겠느냐이다. 소비자들 또한 새 소프트웨어 없이는 Zune HD를 구매할 이유가 거의 없다.

마이크로소프트의 돈은 오로지 소프트웨어 라이센싱에서 나온다. 플랫폼 개발과 하드웨어 판매가 아니다. 이 역시 충분히 이상한 일이기는 하다. 마이크로소프트의 Windows Everywhere 사업 모델은 증명이 되었다. 이 모델을 마이크로소프트는 왜 포기하려할까? 어째서 마이크로소프트는 Zune을 가지고, 완전히 다른 모델인 애플의 하드웨어-중심 모델을 따르려들까?

빌 게이츠가 호응하고 선전했던 Windows Everywhere 환상/전략이 끝났음을 마이크로소프트도 인정하고 있는 셈이다. 마이크로소프트는 애플을 극복하여 우월함을 찾기보다, 애플과 같은 감각있는 숙주의 내장을 파고들어가야만 살 수 있는 기생충임을 스스로 인정해버렸다.

숙주를 떠난 직후에 자기 스스로 살아나기 위해서, 마이크로소프트는 일단 재빠르게 애플 그림자로 기어들어가 애플이 가는 방향으로 가야 함을 발견하였다. 이제 질문은 다음과 같다. 마이크로소프트가 과연 이런 거머리 사업모델을 다시금 이뤄낼 수 있을까? 애플이 그렇게 되도록 가만히 있기나 할까?

How Microsoft Climbed On Top: Software.

기술업계에서 돈을 어떻게 빼낼 수 있을지를, 마이크로소프트는 대단히 잘 알고 있다. 80년대 후반 이래 마이크로소프트는 데스크톱 PC 업계에서 엄청난 이윤을 뽑아내왔다. 그것은 소프트웨어에 집중해서이다. PC 하드웨어는 업체들에게 맡겨버렸다. 그 결과 PC 가격이 떨어지고 경쟁이 심해지면서, 하드웨어 이윤 마진은 줄어만들었다.

그러나 소프트웨어 경쟁에서는 비슷한 현상이 일어나지 않았다. 가격은 거의 그대로이거나 심지어 상승하기도 하였다. 마이크로소프트 오피스의 가격은 최근, 구글 앱과 오픈오피스의 경쟁압박때문에 가격이 떨어지기는 했지만 그것도 최근 일이다. 의미있는 경쟁이 없다시피한 윈도 가격은 10년 전에 비해 두~세 배 뛰어올랐다.

PC 소프트웨어 시장을 지배하는 마이크로소프트의 탄생은 1981년, PC-DOS를 공급하기 위핸 IBM과의 계약부터였다. IBM에게는 오리지날 PC의 가치를 DOS가 부여한다는 점을 인식하지 못하였다. 특히 컴팩 외 다른 기업들이 IBM 하드웨어를 베껴서 PC 디자인이 DOS와 DOS-호환 앱을 돌리는 범용 기기가 되어버렸으니 더욱 그러하다.

IBM은 PS/2라는 크게 개선된 PC 디자인을 소개하려 노력했지만, 컴팩 외 다른 호환기기 회사들은 이미 "IBM PC-호환"의 가격을 내려놓고 있었다. 따라서 하드웨어 공간에서 진짜 혁신이 일어날 여지는 크게 좁아져버렸다. 1995년 내내 PC 가격은 계속 떨어져갔고, 마이크로소프트의 DOS 사업은 PC 클론 업체들로부터 관심을 빼앗아가며, 계속 번영해가고 있었다.

애플은 PC 소프트웨어 세상을 어떻게 바꿀까

Microsoft's Monopoly Maintenance.

윈도 95가 나오자, 마이크로소프트는 DOS 시장을 파괴하였다. DOS와 윈도 환경을 결합시킨 것이다. 이는 분면 반독점 법 위반이었다. 마이크로소프트는 또한 Lotus나 WordPerfect같은 DOS 소프트웨어 개발사들을 기습공격하였다. DOS 독점을 활용하여 DOS 소프트웨어에서 마이크로소프트의 오피스 95로 이주시키기 위해서였다. 이로써 마이크로소프트는 PC 데스크톱용 소프트웨어에 있어서 두 번째 독점을 구축하게 된다.

90년대 내내 마이크로소프트는 하나 하나 시장을 파괴해갔다. 윈도에 인터넷 익스플로러 브라우저를 번들시키는 것만으로 넷스케이프 웹브라우저 사업을 없앴으며, 애플의 퀵타임도 죽이려 들었다. 마이크로소프트는 자신의 독점적 지위를 가지고 경쟁사와 윈도 간의 호환성을 깨뜨리거나, 번들을 막았다. 경쟁사가 호환성 있는 대안을 아예 제공하지를 못하게 만든 것이다. 대안 플랫폼 구축도 붕괴시켰고, 다른 제품들의 접근 시도마저 막아버렸다. 직접적인 계약으로, 혹은 간적접인 잘못된 정보 뿌리기, 공포와 불확실성, 의심 확산시키기로 말이다.

소수의 비판자들을 빼고, 기술 언론은 반-경쟁 행위를 일삼으며 성공을 거두는 마이크로소프트에 대해 대거 축하를 해주었다. 더 큰 경쟁사들과 경쟁을 하는 것이라면, 마이크로소프트의 힘은 확실히 칭찬을 받을만했을지 모른다. 그러나 마이크로소프트는 실질적인 탈법을 저지르며 공정하게 사업을 하지 않았다. 추가하자면, 마이크로소프트는 IBM부터 애플에 이르기까지 다른 기업들 덕분에 성공할 수 있었다.

예전 게이츠는 특허법이 경쟁을 막는다며 불평한 바 있었다. 하지만 마이크로소프트가 특허를 소유하여 새 경쟁을 없앨 수 있는 위치에 올라서자, 견해를 바꾼다. 마이크로소프트는 거대한 기생충이 되었으며, 자기 스스로 만든 기생충에 대해서는 전혀 관용을 보여주지 않았다. 그러나 문제가 있었다. 남들이 만든 가치를 빼앗아오는 것 외에, 마이크로소프트는 스스로 뭘 만들어낼 능력이 전혀 없었다.

90년대 OS의 역사
오피스워즈 4: 마이크로소프트 대 IBM과 로터스
퀵타임을 죽여라

The Floundering Parasite.

더 안 좋은 일도 있었다. 마이크로소프트는 더 이상 성공도 거둘 수 없다는 점이 드러나기 시작한 것이다. 윈도 기생충으로부터 영양을 빼앗겨 고사직전이었던 애플은 90년대 초, 뉴튼 메시지패드를 발표한다. 뉴튼은 90년대 초, 굉장한 기대를 받았고, 마이크로소프트는 타블렛 컴퓨팅 아이디어를 베껴낸다. 그러나 제일 비용 효율적이고 대중화된 플랫폼을 만든 곳은 Palm이었다. 그러자 마이크로소프트 기생충은 새 숙주, Palm을 발견한다. 그러나 마이크로소프트가 내놓은 모든 제품들은 90년대 내내 모바일 PDA 시장에서 허우적거리기만 하였다.

PDA의 미래가 휴대폰과의 융합이라는 사실을 깨달은 Palm은 Treo 스마트폰을 개척하기 시작한다. 그러자 마이크로소프트는 휴대기기 사업 이름을 Handheld PC에서 Pocket PC로, 그 다음엔 윈도모바일로 계속 바꿔가지만, 역시 매력적인 제품은 하나도 제공하지 못하였다.

그동안 다시금 상쾌해진 애플이 아이포드를 판매하기 시작했다. 마이크로소프트의 관심을 아이포드가 가져가자, 마이크로소프트는 PlaysForSure와 Zune으로 아이포드를 따라간다. 또한 콘솔게임이 마이크로소프트 PC 독점을 무너뜨릴 수 있다는 두려움에 소니 플레이스테이션2의 성공을 베끼려 노력하기도 하였다.

성공하는 회사 수입을 어떻게든 빼오기 위해 촉수를 모두 키웠음에도 불구하고, 마이크로소프트의 Zune과 엑스박스, 윈도모바일은 모두 수입 이상의 자본을 소모하고말았다. 도대체 마이크로소프트는 소프트웨어 전략으로 성공을 계속 누리지 않고, 어째서 하드웨어 사업을 자꾸만 추구하고 있을까?

PC 사업이 끝나가고 있음을 알기 때문이다. 잠재성장력이 고갈됐기 때문이다. 따라서 마이크로소프트는 현재 죽어가는 섬 위에 갇혀 있는 상황이다. PC 판매는 물론 신흥시장에서 더 늘어날 수 있지만, 역사적으로 대단히 두터운 마이크로소프트의 소프트웨어 이윤을 중국과 인도같은 신흥시장이 제공해주지는 못한다. 신흥시장은 불법복제가 횡행하고 고유의 운영체제를 쓰려 노력하고 있기 때문이다. 마이크로소프트의 값비싼 대안보다 무료 오픈소스 기반의 소프트웨어로 말이다.

마이크로소프트가 이윤을 내는 세 번째 기둥인 서버 소프트웨어 또한 유닉스와 Lotus Domino/Notes에 대한 기생충 공격이랄 수 있었다. 그리고 이 공격은 윈도 NT/2000/XP/Exchange Server 개발에 상당히 도움이 될 정도로 돈을 모아 주었다. 그러나 기업시장 역시 끝나가고 있다. 기업들도 이제 무료 오픈소스 쪽으로 이주할 기회를 엿보고 있기 때문이다. 마이크로소프트의 폐쇄형 솔루션에 돈을 넣어줘야 하는 상황이 오히려 성장 잠재력을 갉아먹고 있다.

오피스워즈 2: 마이크로소프트의 막대한 오피스 이윤
WinCE와 Windows Mobile의 처절한 실패사

Eating Up Time.

지난 10년간 마이크로소프트는 아이디어에 필사적이었다. 윈도 XP는 애플 맥오에스텐과는 다르게 만들려 시도했었고, 마이크로소프트는 애플 기술의 마이크로소프트식 버전을 롱혼 개발에 투입시키겠노라 계속 약속하였다. 그러나 계획단계에서 너무나 오랜 세월 끝에 나온 비스타는 대실망이었다. 현재 마이크로소프트는 비스타를 윈도 7으로 다시금 내보낼 준비를 마치고 있다. 윈도 7이 잃어버린 10년을 채워주리라 기대하면서 말이다.

하지만 문제가 있다. 시간이 모든 유기체를 파괴하기 때문이다. 지난 10년간 마이크로소프트는 자신의 면책성과 전지전능함을 잃어버렸고, 약했던 경쟁사들과 지난 숙주들이 힘을 되찾으면서 브랜드 이미지도 퇴색되었다. 사용 유닉스는 리눅스로 재탄생하였고, 기업시장에서 상당한 반응을 얻어냈다. 마이크로소프트가 지원하는 잘못된 정보 캠페인도 이제는 활기를 잃을 수밖에 없게 되었다.

일반 컴퓨터 판매가 주춤거리게 되자, 애플은 재빠르게 소매 사업에 발을 들여 놓았다. 마이크로소프트의 촉수로부터 계속 멀어지면서 말이다. 애플의 소매점 진출은 이제 10년째 되었고, 확장할 수 있는만큼 빠르게 성장중이다.

이에 마이크로소프트도 소매 스토어 두 곳 개점 계획을 발표하였다. 직판에 대한 경험 없이, 소매점 구축에 대한 재능 없이, 기존 소매 채널을 격분시키게 할 뿐인 제품 라인업도 없이 말이다. 소매로 이윤을 올리려면 수 년은 더 있어야 할 것이다. 설사 모든 일이 마이크로소프트에게 유리하게 흘러가더라도(물론 마이크로소프트 소매 스토어는 잘 작동하지 않을 것이다), 애플보다 10년 늦은 소매사업 진출이다.

윈도 7은 또다른 Zune이다.
Microsoft to open new retail stores like Apple

Moving At The Speed of Zune.

마이크로소프트는 빠르게 움직여야 한다. 분명하다. Zune은 이제 나온지 3년째이지만 마이크로소프트의 독점력을 발휘하려는 최고의 노력에도 불구하고 비참한 실패를 기록하였다. 모든 전문가들로부터 잘못된 정보를 게워넣어도 실패하였다. 2년째 모델들의 실패는 마이크로소프트의 오만이 벌거벗은 임금일 따름이었다는 사실을 증명시켜주었다. 애플은 저렴한 비디오 나노를 만들어서 오리지날 Zune을 무색하게 만들었으며, 아이포드 터치를 선보여서 두 번째 Zune을 앞서나아갔다.

이제 마이크로소프트가 아이포드 터치를 베낀 Zune을 선보이려한다. (여러가지 유용한 아이포드의 기능 대신 라디오를 다시금 집어 넣었다. 지난 2년간 이 방식이 먹히지 않았는데도 말이다.) 하지만 중요한 뭔가가 없다. 다름 아닌 써드 파티 소프트웨어다. 지난 해 내내 애플은 아이폰/아이포드터치 모바일 소프트웨어 플랫폼을 구축하여, 이제는 6만 5천여 앱이 생겨났다. 마이크로소프트가 이런 거인과 경쟁하려면 두 가지 선택을 할 수 있을 뿐이다. 유용한 애플리케이션을 스스로 계속 개발하거나, 아니면 애플 방식 베끼기이다. 마이크로소프트는 후자를 선택하였다. 써드파티 개발자들의 힘을 이용하기이다.

하지만 이것은 대실수다. 늦게 등장해서, 성숙성과 질도 고려하지 않은 채 따라만든 플랫폼가지고 성공한 역사적인 사례가 없다. IBM은 PC 이전 시장(대부분 CP/M이었다)을 평정하였으나, IBM은 독점력을 기업용 머신으로 활용했었다. 애플의 맥은 다소 약한 출발을 보였고 10년 후에 마이크로소프트가 조성하고 훨씬 거대해진 윈도/DOS PC에게 압도당한다. 저렴한 Amiga나 Atari ST가 아니었다. 그런데 독점력을 지렛대로 활용하려는 마이크로소프트의 시도는 이제 성공보다는 실패가 더 많아지고 있다.(PDA, 웹검색, 게임, 휴대폰, MP3 플레이어 등) 마이크로소프트의 마이너급 Zune이 애플의 아이포드/아이폰/아이튠스 사업으로부터 뭐라도 빼내올 수 없으리라 기대하는 편이 합리적이다.

또 있다. 심지어 이번에는 하드웨어 파트너들의 지원조차 없다. Zune은 마이크로소프트의 MP3 파트너쉽을 없애버렸다. 게다가 스마트폰에서부터 MP3 플레이어 기기에 이르기까지, 노키아의 Internet Tablet에서 넷북과 여러 휴대기기들까지 모두가 다 애플과 경쟁을 벌이려 하고 있다. 이런 상황에서 개발자들이 Zune HD로 흘러갈 수 있을까? 이미 존재하는 기존 Zune API에도 다가서지 않았는데 말이다.

Zune Sales Still In the Toilet

Doesn't Microsoft Write Software?

자, 따라할 검증된 사업모델을 이미 가지고 있다. 게다가 남의 아이디어 따라하기는 마이크로소프트가 제일 잘 하는 일이다. 그럼에도 불구하고, 마이크로소프트는 애플이 아이폰을 어떻게 만들었는지에 대해 잘 알아보지 않았다. 이해하기 힘들 정도다.

아이폰의 성공을 제일 잘 이해하려면, 뉴튼 메시지패드와 비교해보는 것이 좋다. 아이폰을 처음 출시할 때부터 애플은 기본 기능을 아주 많이 포함시킨 채로 출시를 하였다. 그러한 투자를 벌충해줄 정도로 저변에 충분히 넓어지게 될 경우, 언젠가 써드파티가 개발할 잠재기능을 많이 남겨둔 채로 출시하지 않았다. 애플은 오리지날 아이폰용 앱을 많이 작성해 두었고, 써드파티에게 API를 제공하겠다고 발표하기도 전에 이미 500만 대를 팔았다.

이와 비교해 볼 때, 마이크로소프트는 출시한지 3년이 됐는데도 아직 Zune 400만 대를 못팔았다.Zune HD의 출발점은 제로이기도 하다. 별도의 개발 플랫폼을 사용하기 때문이다. 물론 애플도 아이포드에서 아이폰으로 이주할 때 마찬가지로 하였다. 그러나 애플은 개발 API를 공개하기도 전에, 첫 해에만 500만 대 이상의 아이폰을 팔아냈다는 점이 확연히 다르다. 따라서 아이폰의 경우, 처음 API를 공개할 때부터 애플리케이션 개발에 동기를 불어다 넣어줄 충분한 기반과 흥미가 있었다.

뉴튼의 교훈

The Problem with Third Party Developers.

Android와 Palm Pre, Zune HD는 현재, 모두 개발자들을 초대하고 있다. 기반이 무시해도 좋을 정도밖에 안되는데도 말이다. 이는 뉴튼이 나왔던 시절 애플이 이미 경험했던 바 있다. (맥과 넥스트 플랫폼을 출시하면서 스티브 잡스도 몸소 경험한 바 있는 상황이다.) 정말 장사하기는 힘들다. 써드파티 개발자들이 특별히 같이 행동할 이유를 못느낀다면 더더욱 어렵다. 써드파티는 개별적인 존재다. 즉, 더 나은 조건이 나타나지 않으면 바로 떠나거나, 기꺼이 등 뒤를 찌를 수 있다는 얘기다.

애플과 잡스는 이미 이 점을 알고 있다. 1981년 당시 잡스는 게이츠를 불러서, 맥 플랫폼용 소프트웨어 개발을 의뢰하였다. 마이크로소프트가 거의 성공을 보인 바 없는 애플리케이션 개발 사업에 마이크로소프트가 들어설 기회를 준 것이다. 마이크로소프트가 중요한 맥용 애플리케이션 개발사가 된 다음, 애플을 배반하는 편이 훨씬 더 거대한 이익이 있음을 깨닫자, 마이크로소프트는 이를 바탕으로 애플 맥 기술 권리를 탈취하고 애플에 반하는 목적으로 사용하였다. 윈도 개발만이 아니라 룩앤필 소송에서 애플 소프트웨어 저작권에 대한 애플 방어 또한 성공리에 좌절시킬 수 있었다.

당시 마이크로소프트는 어떻게든 애플을 포기한 상태였다. 맥용 워드와 엑셀을 그냥 놓아둔 채로, 모든 개발 역량을 윈도 버전 개발에 쏟아 부었기 때문이다. 게이츠는 또한 넥스트용 소프트웨어 작성을 거부하기도 하였다. 더 우월한 플랫폼용 오피스를 만들 경우, 윈도에게 치명타를 입히리라는 점을 알았기 때문이다. 마이크로소프트는 맥용 오피스 지원을 최소한에 국한시키고 있다. 여전하다. 맥용 오피스가 이런 불충분한 쓰레기로 남아있을 때, 애플은 이 상태를 유지시키려 노력중이며, 한 편으로는 iWork을 만들어냈다.

Android와 Palm의 WebOS, Zune HD는 구매자들을 이끌어낼 매력적인 하드웨어와, 개발자들이 사용할 충분히 좋은 툴을 제공할 수 있어야 써드파티 개발자들을 모을 수 있다. 이것이 지금까지 제일 심각한 문제점이다. 구글과 Palm도 알아야 한다. 리눅스 커널상의 기본 플랫폼으로, 개발자들이 바로 떠나갈 수 있기 때문이다. 쉽게 오면, 쉽게 나간다. 중국을 보라. 여러분의 기술을 곧바로 국유화시키는데 일가견이 있는 나라가 중국이다. 모두들 행운이 있기를 빈다.

오피스워즈 3: 마이크로소프트는 어떻게 독점을 차지하였나

Again, Doesn't Microsoft Write Software?

이 모든 것은, 마이크로소프트가 아이폰과 아이포드 터치에 경쟁시키기 위해, 뛰어난 모바일 앱을 Zune HD에 넣어서 제공해야 한다는 의미이다. 그러나 그렇지가 않다. CNET은 인터넷 익스플로러 6(!)의 기본 버전이 포함되어 있음을 떠벌리고는 있지만, 시판에 나서게 되면, 진짜 모바일 브라우저들과 쉽사리 비교가 될 것이다. 윈도 광들마저도 어째서 Zune에 대해 침묵하는지 궁금히 여기지 않을까?

현실상 Zune의 웹브라우저는 끔찍하게 보인다. 가상 키보드(아이폰에 나타났을 때 윈고 열광론자들이 비난하던 바로 그 개념이다)가 디스플레이를 더 많이 잡아먹고 조잡해 보인다. 확대/축소와 일반적인 네비게이션도 너무나 안좋은 나머지 마이크로소프트 스스로도 일반에 공개하지 않을 정도다. 이와 반대로 애플은 아이폰이 시판되기 6달 전에, 아이폰의 새 브라우저를 속속들이 보여줬었다. 안드로이드와 Palm 또한 시판에 앞서 보여준 것이 웹브라우저이다. 둘 모두 WebKit을 사용하고, WebKit은 이미 검증된 엔진이다. Zune HD는 윈도모바일 이용자들이 오페라를 다운로드받게 만든, 바로 그 브라우저를 사용한 채로 한 달 뒤 시판된다.

마이크로소프트 웹브라우저가 이토록 안좋다면, 다른 무엇이 더 안좋을 수 있을지 궁금하실 것이다. 일반적인 네비게이션 또한 끔찍스런, 화면 끝으로 길게 늘어지는 텍스트 목록일 뿐이다. Zune의 첫 두 세대에서도 흥분을 만들어내지 못한 것이다. Zune HD는 전화기능 없는 윈도모바일이다. 얼마나 안좋을지 생각해 보시라. 아니, 잠시 멈추고 떠올리기만해도 된다. 와우.

그렇다면 Zune HD는 무엇을 제공하는가? HD Radio와 HD video 송출 기능이 있는데, 독특하기는 하지만, 딱히 수요가 있지는 않다. 이와 반대로 오리지날 아이폰은 전화이기는 하되, 주소록과 달력, 메일 기능, 날씨나 주식 외 위젯을 탑재하고 나왔었다. 뒤에 나온 버전은 메시지 푸시 기능과 사진, 비디오 녹화 기능을 덧붙였다. 마이크로소프트도 이렇게 할 수 있다. 하지만 마이크로소프트는 뭔가 해야 한다고 생각하지를 않았다. 엄청난 실수이다.

Zune HD's Bing-powered Web browser MP3 Insider – CNET Reviews

Why Isn't Microsoft Developing for the iPhone?

마이크로소프트는 그동안 아이폰용 소프트웨어 앱을 전혀 제공하지 않았다. 지난 1년 반동안 제일 성공한 모바일 소프트웨어 플랫폼인데도 말이다. 마이크로소프트는 죽어가는 자신의 독점을 유지하기 위해 장님이 되어버렸다. 이제 지리멸렬해가는 자신의 방식에 혁신을 기할 진짜 기회를 놓치고 있는 셈이다.

마이크로소프트가 맥용 오피스를 제공하는 이유는 애플과의 계약을 지키는 것, 그리고 경쟁 오피스의 등장을 막기 위해서이다. 맥용 인터넷 익스플로러와 윈도미디어를 제공했던 이유 또한 독점의 유지때문이었다. 그런 동기가 사라지자, 제품도 사라졌다.

제일 위험하던 시기의 애플은 클라리스웍스를 맥용은 물론 윈도용으로도 재빠르게 출시했었다. 마이크로소프트 Works와 경쟁하기 위해서였다. 당시 애플은 클라리스를 포기하였으나, 클라리스는 맥 플랫폼에서 마이크로소프트에 대한 잠재적인 위협을 보여줄 수 있었다. 퀵타임이 살아남은 이유는 맥 플랫폼에 있었기 때문이었고, 나중에 애플은 퀵타임을 크로스 플랫폼으로 되살려서, 윈도용 아이튠스를 제공하였다. 뒤이어 윈도용 사파리와 윈도용 MobileMe도 나왔다.

즉, 기회를 제공한다면, 애플은 주요 애플리케이션을 라이벌 플랫폼용으로 출시하는 것도 꺼리지 않는다. 그렇다면 핵심적인 독점상태가 흔들리고, 새 기회가 절실한 형편인 마이크로소프트는 어째서 아이폰용 모바일 앱을 훌륭하게 잘 만들 기회를 잡지 않을까? 마이크로소프트가 "꼭 있어야 할" 아이폰 앱을 여러 가지 제공할 수 있다면, 이 사용자들을 윈도모바일과 Zune으로 이끌어낼 수 있잖을까? 마이크로소프트가 멍청한 것일까, 아니면 능력이 없는 것일까?

오피스워즈 (Office Wars)

Failure to Launch.

필자는 능력이 없다고 본다. 맥이 태어났을 때, 마이크로소프트는 MultiPlan(후의 엑셀)을 늦게 제공했었고, 맥용 오피스도 늦게 제공하고 있다. 언제나 느리고, 서두르는 모양새였다. 윈도 비스타라는 재앙을 보면, 이것이 맥용 프로그램만 있는 문제가 아님을 알 수 있다.

사실 마이크로소프트가 돋보이는 분야는, 비교할 대상이 없는 분야 뿐이다. 경쟁상대가 없다면 Zune도 괜찮아 보이지만, 아이포드 옆에 갖다 놓으면 적어도 하드웨어는 1년, 소프트웨어는 더 많이 뒤쳐지게된다. 2000년 당시 필자는 윈도 CE 기기 또한 Palm과 비교를 하지 않을 때에만 괜찮게 보인다고 쓴 바 있다. 최근 한 프로젝트에서 오피스를 꼭 써야될 상황이 필자를 좌절시키고 짜증나게 만들었었다. 필자는 iWork에 익숙해져 있었다. iWork는 마이크로소프트 독점 유지보다는 작업을 위한 디자인이다.

마이크로소프트 고객들을 보시라. 대안을 찾지 않는 이들만이 마이크로소프트를 만족하며 쓴다. 그리고 핵심 고객들 대다수는 윈도 열광론자들과 마이크로소프트판인 전산실이다. 이들은 현실에 노출될 경우 신앙이 흔들릴까봐, 대안을 알아보지도 않는다.

마이크로소프트가 아이폰용 소프트웨어를 개발하려 시도해 본다면, 마이크로소프트가 얼마나 능력이 없는지 드러날 것이리라고 본다. 이 문제의 주된 원인은 경영진이다. 마이크로소프트 직원들과 얘기해보면, 이들은 얼마나 안좋고 형편없는 제품이 만들어지는지에 대한 짜증과 좌절을 토로하곤 한다. 새로운 뭔가를 구축해보기보다는, 현상유지를 위한 하향식 관리라서 그러하다. 이런 방식은 90년대 중반 애플을 죽인 바 있다.

애플은 어째서 되살아났을까

Death is Always the Answer.

현상유지보다 더 나은 것이 있음을 생명체는 알고 있다. 그리고 우리들 모두는, 죽도록 프로그래밍되어 있다. 이러한 상황때문에 우리는 수동적으로 기대어 눕기보다는 어려운 결정들을 내려야 한다. 더 중요한 것이 있다. 이 상황은 우리의 문명과 유전자의 진보를 막을 수 없게 만들기도 한다.

우리는 늙어갈수록 변화에 저항하여, 시야도 보수적으로 된다. 우리가 200살까지 산다면, 전체 글로벌 사회는 후퇴하여, 진보에 미적거리는 채, 거절만 하는 남북전쟁 세대로 가득찼을 것이다. 이들은 상상속 영광스러운 과거를 그리워하며 미신에 사로잡힌 소수로 남지 않고, 공민권과 선거권 시대로 시계를 되돌려놓기를 주장할 것이다.

과거로부터의 사슬을 끊을 유일한 방법은 과거를 더 좋아하는 이들 모두가 자연스레 사라지는 것이다. 자연은 대단히 우아한 방식으로 이를 행한다. 우리에게 시계를 주고, 우리를 매정하게 죽인 다음, 스스로를 개척해야 할 아이들을 남기는 식이다. 무엇이 옳고 그른지에 대한 조상들의 인식 속에 영원하 살지 않게 하기 위해서이다. 죽음이 없다면, 혁명도 없고, 지구 탐사도 없었을 것이다. 아직도 지구는 평평하다고 알고 있을련지 모를 일이다. 제일 적합하지 않은 현재의 지배체제 아래 탈출할 희망도 없을 것이다.

죽음은 DNA의 새로운 조합으로 싹트지 않는 모든 것을 죽이고, 새로운 시도를 살려 놓는다. 90년대 중반 애플은 다시 살기 위해 죽어야 했다. 그리고 오늘날, 마이크로소프트는 더 빠르고 혁신적인 경쟁사들의 연이은 공격에, 죽음으로 향해 가는 독성의 기생충이 되어버렸다.

오늘날의 마이크로소프트는 죽을 것이다. 이전의 IBM 독점과 영국 제국, 카이사르, 공룡이 그랬듯이 말이다. 과연 마이크로소프트가 자신을 재탄생시켜서 새로운 형태로 살아남을지, 아니면 사회 기술 진보를 가로막은 문제많은 질병으로 사라질지가 유일한 문제이다.

출처 - http://www.roughlydrafted.com/2009/08/15/why-cant-microsoft-develop-software-for-zune-hd/#more-3703

My Comment

Daniel Eran Dilger씨 또한 Apple Hollic이다. 특별히 Microsoft에 당한게 많은 Apple 같은 경우 Apple Hollic 입장에서 찢어 죽여도 시원찮은 회사이다. 나 또한 MiroSoft는 거대 공룡이면서, IT업계의 기생충이라는 말은 어느 정도 공감이 간다. 그러나 객관적으로 판단해 볼때 MS는 나름대로 사업을 구축하고 있다고 본다.
앞에서 언급한 MS의 Zune, Vista, XBox, Mobile Window는 모두 실패작이 아니였다. 준과 비스타 꽤 그럴듯하게 실패했다. 비스타의 경우 특별히 실패작은 아니라고 본다. 발매 시기가 빨랐을 뿐이다. 현재 저로써도 비스타를 싫어하지만 어쩌다가 사용하면 놀라운 섬세함과 많은 숨겨진 기능들을 발견하고 놀라곤한다. 문제는 그러한 섬세한 기능과 숨겨진 기능이 기본적인 유저간의 커뮤니케이션이 불편해도 눈감아줄 만큼은 아니다는 것이다. Zune의 경우는 완전 퍼펙트하게 망했다고 해도, 할말은 없지만 Xbox360같은 경우 게임업체의 원조격인 Sony를 무너 뜨릴만큼 성공에 가깝다고 볼 수 있다. 물론 Nintendo의 지원사격이 있었다는 것도 인정한다.
그러므로 준 HD와 아이팟(아이폰)과의 대결은 지켜봐야 한다. 아이팟이 지금 가진 서드 파티 개발자는 아이팟 어플만 개발하게 완전히 가두어져있는 것도 아니며 개발자는 언제나 편한 곳으로 이동하게 되어있다. 저자도 언급한것과 같이 서드 파티 개발자는 그 회사에 종속되어 있지 않으면 언제나 자기 뜻대로 이동할 수 있다는 것이다. 물론 처음에는 많은 어플을 가진 아이팟이 우세하겠지만, 마이크로소프트가 어떻게 하냐에 따라서 역전 될 수 있는 가능성은 배제 할 수 없다. 준HD는 망하는게 아니라 앞으로 어떻게 하는가에 따라서 결정 되는 것이다.

한국 앱스토어도 마찬가지이다. 현재 삼성과 LG도 앱스토어 사업을 추진한다고 밝힌 바 있다. 삼성,LG는 오히려 MS보다 앱스토어 사업에 더 불리한 입장에 서있는 것이다. Daniel Eran Dilger씨가 삼성과 LG의 이런 사정을 안다면.. ㅋㅋ 안봐도 뻔하다. MS보다 더 무지막지하게 밟았을 가능성이 농후하다. 현재 앱스토어는 애플이 선전하고 있는 분야이긴 하지만 앞으로 어떻게 될지는 지켜봐야 알 수 있을 것 같다.

미래의 블로그 와 웹은 어떻게 될 것인가?

2009-08-25T14:24:00.005+09:00

오늘 Problogger에 올라온 포스트

Let me Show You Inside a Secret Blogging Alliance

비록 짧지 않은 글이긴 하지만 블로그 운영에 대해 참 많은 생각을 할 수 있었습니다.

사실 비슷한 주제의 블로거들이 서로 연대하고 함께 커간다는 아이디어 자체는 그리 새로울 것도 없지만 이렇게 블로그 초창기부터 지속적인 상호 신뢰를 바탕으로 성공을 일궈낸 사례는 처음 듣는 것 같습니다. 이제 막 블로그를 시작하는 분이나 충분한 경험이 있는 분 모두 하나의 성공적인 롤 모델로 블로그 연합을 고려해 보는 것도 괜찮을 듯 합니다.

먼저 여기서 말하는 블로그 연합 (Blogging Alliance)은 소위 말하는 블로그 네트워크와는 다릅니다. 블로그 네트워크는 보통 회사와 공식적인 계약을 맺고 스킨이나 광고 집행 등에서 일정 정도의 강제성이 부여되는데 반해 블로그 연합은 그냥 비슷한 주제를 가진 몇 명의 블로거들이 모여서 만든 친목단체와도 비슷합니다. 딱딱한 계약관계 보다는 그냥 독립적으로 자신의 블로그를 운영하면서 특정 영역에서만 전략적인 제휴를 하는 느슨한 파트너쉽이라고 볼 수 있죠.

아무튼 여기 사례를 보면 일단 같은 니치에 있었던 2명의 블로그가 최초 연대 관계에 동의를 하고 이후 각자 3명씩 영입 의사를 물어 최종 7명이 블로그 연합을 결성합니다. 7명 모두 자신만의 스타일로 블로그를 운영하지만 일단은 비슷한 관심사와 주제를 공유하고 있습니다. (흥미롭게도 거부 의사를 밝힌 유일한 한 명의 블로그는 현재 운영이 중단된 상태라고 합니다.. –_-)

이후 일정 시간을 정해 주기적인 온라인 미팅을 하고 계속 만남을 유지하기로 약속하면서 각자의 블로그 운영 사례에 대한 공유와 함께 무엇을 해야 하고 도울 수 있을지를 고민합니다.

그로부터 2년이 지나고 이들 7명의 블로그 모두 비약적인 성공을 경험했으며 이들 중 5명은 현재 풀타임 블로거로 활동하고 있고 남은 2명 역시 본인의 직업을 포기하기로 마음먹는다면 충분히 되고도 남을 만큼 자리를 잡았다고 합니다.

그럼 블로그 연합을 통해 이들은 무엇을 했고 어떤 것을 얻어냈을까요?

1. 댓글 달기

거창하게 블로그 연합을 시작해놓고 겨우 댓글이냐고 하시겠지만 사실 지속적인 댓글의 힘은 상당히 강력합니다. 아무리 공들여 쓴 포스트라도 블로그 초창기에는 댓글 얻기가 무척 힘이 들기 때문에 다른 멤버의 RSS를 구독하면서 서로 댓글을 달아주다보면 점차적으로 블로그에 생명력이 돌고 파급효과가 나타납니다. 방문객 입장에서도 0개의 댓글이 달린 포스트 보다는 7개가 달린 포스트를 더 주목하려 하고 같이 대화에 동참하여 댓글을 남기고 싶어하니까요.

이밖에 전문 영역이 비슷한 7명의 블로그들이 자신의 글을 읽는 것을 알기 때문에 좀 더 컨텐츠에 공을 들이게 되고 점차 좋은 글을 쓰도록 노력하게 만드는 것도 상호 댓글의 부수 효과라고 할 수 있습니다. 물론 이렇게 되기 위해서는 그냥 ‘좋았어요’ 같은 선심성 댓글이 아니라 실제 도움이 되고 또 다른 영감을 줄 수 있도록 진정한 토론이나 비판이 되야 하겠지요.

2. 링크 걸기

블로그 사이드바에 서로의 링크를 홍보하는 것 외에 매주 한 명씩 주제를 정하고 해당 포스트 속에 관련 있는 다른 블로그의 링크를 포함시킵니다. 모두 비슷한 니치를 다루기 때문에 자연스럽게 할 수 있는 전략인데요. 실제로 별다른 강제성 없이 시작했어도 점차 시간이 지나면서 매주 2~3건씩 각자 다른 연합 블로그에 링크 될 수 있었습니다. 물론 누적된 링크와 함께 구독자의 공유와 검색엔진 랭크의 상승도 당연히 뒤따라오게 되고요.

3. 소셜 북마크 & 트위터

블로그 포스트의 직접적인 링크 언급과 병행해서 트위터 같은 소셜 미디어와 딜리셔스 같은 소셜 북마크 사이트에 서로의 링크를 홍보해줍니다. 소규모 그룹이라 그렇게 강력한 효과는 없지만 시간과 함께 각자의 소셜 미디어 영향력이 커지고 링크가 누적되면서 일정한 트래픽 효과가 나타나게 됩니다. 처음에는 각자 일주일에 하나씩 선별적으로 홍보했지만 이제 몇몇 블로그는 자신의 포스트 뿐만 아니라 다른 멤버의 포스트까지 자동으로 트위트 되게 설정했다고 하네요.

4. 게스트 포스트

방침은 한 달이지만 실제로는 일주일에 한 번 정도 주기적으로 돌아가면서 다른 멤버들의 블로그에 글을 올립니다. 처음엔 휴가나 여행 등 구성원들이 자리 비운 것을 도와주기 위해 시작했지만 결과적으로 각자의 구독자 사이에서 서로의 프로필을 홍보하는 좋은 기회가 되었다고 합니다.

5. 조인트 프로모션

7명이 뭉쳐서 프로모션을 진행하기 때문에 한 명일 때 보다 스폰서를 구하기도 쉽고 구독자를 위해 좀 더 큰 상을 준비할 수 있습니다.

6. 수익화

혼자일 때는 광고주를 구하기도 힘들뿐더러 다양한 제휴마케팅과 광고를 실험하느라 많은 시간과 리소스를 낭비하지만 블로그 연합에서는 7명 모두 각자의 광고 방식과 실제 수익, 성공하거나 실패한 경험담 등을 허심탄회하게 공유합니다. 이렇게 공유된 정보를 통해 서로에게 광고주를 소개해 주기도 하고 혼자라면 불가능 했을 광고주를 7명이 함께 계약하기도 합니다.

7. 직접적인 블로그 홍보

본인 블로그의 구독자에게 다른 멤버 블로그의 뉴스레터나 RSS 구독자가 되도록 직접적으로 홍보하는 방식입니다. 소개하는 블로그의 장점을 나열하면서 뉴스레터와 피드 주소를 강조하는데 지금까지의 결과는 나름 환상적이었다고 합니다.

8. Thank You 페이지 프로모션

보통 뉴스레터 등을 구독하면 주인장이 감사를 표시하는 Thank You 페이지로 연결되는데요. 여기에 다른 멤버 블로그를 추천하면서 함께 구독하라고 홍보하는 방식입니다. 흔한 마케팅 전략이지만 블로거 입장에서는 신선한 아이디어네요.

9. 자투리 광고 프로모션

블로그에 광고 스팟이 비어있으면 다른 멤버 블로그의 배너를 로테이션 하면서 걸어주는 홍보 방식입니다. 작은 트래픽도 쌓이면 힘이 되죠.

10. 상품 프로모션

이북이나 회원제 사이트 등 어떤 상품을 내놨을 때 구성원 모두가 집중적으로 홍보해 줍니다. 그냥 댓가 없는 홍보가 아니라 멤버에게만 상위 제휴마케팅 레벨을 적용해서 멤버를 통해 상품이 팔릴 때 마다 좀 더 많은 커미션을 돌려줍니다. 상품이 많이 팔릴수록 상품 제작자 뿐만 아니라 멤버들의 수익도 늘어나니 자연스럽게 홍보 의욕도 함께 늘어납니다.

11. 공동 상품 제작

관심사가 비슷한 만큼 각자의 컨텐츠나 기술을 이용해 상품을 내놓고 수익을 공유하는 것도 가능해집니다.

12. 인적 네트워크

각자 알고 있는 인적 자원이 합쳐져 다양한 방면의 조언을 구하고 상호 교류를 통해 네트워크를 확장할 수 있습니다.

13. 오프라인 모임

당연한 말이지만 온라인과 오프라인 상의 만남에는 큰 차이가 있죠. 오프라인 모임에서는 자신의 블로그 경험담을 프리젠테이션 하거나 향후 수익화 계획 또는 서로의 블로그에 대한 품평회 등 온라인에서 하기 힘든 좀 더 진지한 토론을 진행합니다.

이밖에 겉으로 확연히 드러나는 효과는 아니지만 블로그 연합은 지속적인 블로깅에 큰 힘이 됩니다. 지치거나 매너리즘에 빠져 블로그를 포기하고 싶었을 때도 다른 구성원들의 격려와 신뢰를 통해 어려운 상황을 극복할 수 있었다고 하네요.

마지막으로 인터뷰를 진행한 블로거가 밝힌 블로그 연합의 성공 비결입니다.

참여한 블로그의 크기 규모가 모두 비슷했던 것 (지금도 마찬가지)
모두 겸손한 태도를 유지하고 서로 도움을 주기 위해 노력했던 것
인위적인 홍보를 위해 강제성을 띄지 않았던 것 (거부 의사도 상호 존중)

이런 블로그 모델 어떤가요?

출처 - http://www.choboweb.com

My Comment
저도 예전부터 미래의 블로그는 모두 합쳐질 것이다는 생각을 가져왔습니다. SOA 기술이 나오면서 현실로 쉽게 다가 올수 있었죠. 블로그 뿐만 아니라 이제 모든 웹은 더욱 거미줄과 같이 엉키게 되며 더욱 밀접해지며, Accessblity가 높아질 것이라는거죠. 즉 정보는 더욱 더 오픈 되는 것입니다. 이 세상의 모든 웹이 모두 연결이 된다면 웹은 무궁무진한 정보의 데이터 창고가 될 수 있는 겁니다.

그러나 그게 가능하기 위해서는 지구촌화가 가장 먼저 실현 되어야 할 것 같습니다. 아직 모든 사람들은 각 나라의 언어에 따른 불안함과 거부감을 가지고 있기 때문에 웹 또한 지역화가 되어 가고 있는 것 같습니다.

특히 한국이라는 나라는 더욱 그러하죠. 한국만의 Messenger, 한국만의 Portal, 한국만의 twitter라는 한국형 서비스를 외치고 있습니다. ㅋㅋ 그렇다고 제가 한국것이 아닌 외국것만을 사용하자는 사대주의는 아닙니다. ㅋㅋ 이야기가 이상한 쪽으로 빠지네요.. 이쪽에서 저의 생각은 한국에서만이 아닌 세계적으로 한국형 서비스를 세계화된 서비스로 바꾸면 좋겠지요.. (만약 가능하다면 ;;;)

웹의 지역화가 안되게 하려면 가장 먼저 해결 해야 할 문제는 의사소통이 가능해야 합니다. 그러기 위해서는 소프트웨어 번역 기술이 발전하던가? or 인간들이 언어를 통합 하던가? 둘 중에 하나겠죠. 당연 후자는 거의 불가능한 사항.

이상하게 말이 계속 꼬여 가는데 결론은 미래의 모든 웹은 더욱 거미줄과 같이 엉키게 되며 더욱 밀접과 Accessblity가 높아질 것이라는거죠. 그러나 아직은 시기 상조라고 생각합니다.

Scrum 방법론

2009-08-18T12:30:00.010+09:00

Foundation

Process Control

1. 산업 공정 제어 이론

1> Defined Process Control (명시적 공정 제어 모델)

사전에 잘 정의된 일련의 입력들이 주어지면 매번 동일한 결과물을 산출

소프트웨어는 예측 가능할 정도로 명시적이지 않고, 명시적 접근법을 쓰기에는 사고와 창조성을 요구하는 지식 집악적인 산업, 명시적 방법 적용하면 통제력 상실 불안전 제품생산

2> Empirical Process Control (경험주의적 공정제어 모델)

불완전하게 정의되어 예상 못한 결과를 만들어내는 프로세스를 빈번하게 검사하고 적응하는 방식을 통해 프로젝트를 제어하는 방법

S/W Process에 적당 하다.

전통적 방법론 vs . Agile 방법론

- 10명의 개발자, 10개의 Task, 하나의 관리자가 있을 때 업무의 분배의 예

전통적 방법론 - 각자 한 개의 일을 병렬 처리 부분 최적화를 통한 최대 최적화

Agile 방법론 -일단 n개의 일을 먼저 협업, 끝나면 다음 n개 협업 집단 학습, 자율적 업무 분배

방법론의 종류

ASD(Adaptive Software Development-1974), Scrum(1991), Crystal method(1996), XP(eXtreme Programming(1996), FDD(Feature Driven Development-1995),
DSDM(Dynamic System Development Method-1995)

Scrum

1. Introduction

1> History : 제조업 분야에서 시작 – 신제품 개발에 사용하기 위한 새로운 방법론
Sutherland, Schwaber 공동연구로 OOPSLA ‘95에 논문 발표

2. Skeleton

3.Roles

1> Pigs and Chickens
직접 책임 있는 3가지 역할 - Pigs
관심과 연관은 있으나 직접 참가하지 않는 나머지 - chickens

2> Product Owner ( 기획 책임자, 고객 ) – 비즈니스 이해 관계를 잘아는 사람
요구사항 작성/정리, 요구사항을 비즈니스 가치순으로 우선 순위화-Product Backlog
초기 ROI 목표, 초기 배포 일정 수립, 투자자에게 ROI 비전 제시

3> Scrum Master – 간접 권한, NOT Controlling, ( 전통적 PM과 다름 )
프로세스 규칙과 실행 방안을 따르도록 유도하고 가르침
조직 문화의 허용범위 내에서 Scrum 프로세스 구현
프로젝트 성공에 대한 책임이 아니라, 성공확률을 높일수 있도록 하는데에 책임
팀을 괴롭히는 것으로부터 팀을 보호-때때로 정치적 행동도 필요
팀과 Product Owner가 하나로 움직일수 있도록 장벽 제거
창의성과 위임 촉진 – 팀의 생활 향상,궁극적으로는 생산성 향상
팀의 진행상황을 최신으로 유지하고 모두에게 제시-툴과 기술 향상

4> Scrum Team-Self-managing, Self-organizing, Cross-functional
Backlog 분석/기능 추가, 자신의 일을 스스로 관리, 필요에 따라 조직구조도 변경, 기능을 만들어 갈 책임, Sprint Backlog 관리

4.Flow

1> 기본 준비 단계 : 모호함 배제, 개발어가 아닌 비즈니스어, 점차적으로 상세화
Product Owner : 투자자에게 비전 제시 위한 전반적 실행 계획 수립
A. Product Backlog 작성
B. Functional or Non-functional, 비전에 부합, 비즈니스 가치에 다라 우선순위로 정렬, 초기 릴리즈 계획에 따라 그룹핑, 동적으로 변화

2> Sprint
연속 1주~4주 정도 주기의 Iteration, 실제 업무가 시행되는 단계, Inspection Adaption이 목적

3> Sprint Planning Meeting : Product owner, team간 협의 Sprint기간동안 할일 결정
첫번째 파트
Product Owner : product backlog에서 우선 순위 작업 선택 & 설명
Team : Back log 질문, 추정비용 바탕 가능한 많은 backlog 선택,
최선을 약속, 결과를 약속 하는 게 아님 - PO는 팀의 선택 신뢰 해야 함
두번째 파트
확고한 실행 계획 수립 – 계획 수립 후 추후 관리 책임은 팀에 있음
비용 예측의 불확실성 : 비용산정은 미래 예측임, 약속일 수 없음.

4> Daily Scrum
성격 : 하루마다 정해진 시간/장소에서 개최, 15분이내, 모든 Pig 참가
내용 : 어제 한 일, 오늘 할 일, what blocks you?
목적 : Socialization and Synchronization, 진행에 필요한 별도 회의 스케쥴링, 관리자가 진척상황을 확인 /지시하기위한 것이 아님.

5> Sprint Review Meeting
성격: sprint 막바지에 개최, 4시간 이내
내용:Product Owner와 주요결정권자에게구현사항 시현,(기능시현,형식적이지않음)
목적 : 팀이 다음에 할일 결정에 도움, 기대치/실측치비교 목표 재조정, 관리자에게 보고하기 위한 자리가 아님

6>Sprint Retrospective Meeting
성격:3시간이내, Chicken은 참가하지 않음.
내용:지난 Sprint에서 잘진행된 것은? 다음 Spring때 향상 시킬수 있는 것은?
Scrum Master가 내용 요약, 개선점을 Product Backlog에 추가
목적 : Scrum Process 범위 내에서 보다 효과적이고 재미있는 프로세스로 개선, Scrum Master가 문제에 대한 해답을 내놓기 위한 자리가 아님.
한계점 : 개인의 성향에 따라 의견차가 큼, 개선비용 큰부담, 시간낭비 가능성

5. Artifacts

Product Backlog : 일반적인 Spec List, Product Owner가 작성
Sprint Backlog : Product backlog의 일부, 선택권은 Prodcut Owner, 관리책임은 Team
Burndown Chart: 팀의 재추정수치 기반, 업무진행 정도를 Chart로 표시
중간결과물: Sprint마다 Demo가 가능한 결과물이 나와야 함,잠재적출시가능상태

6.요약

- Three Rols : Product Owner, Scrum Master, Development Team
- Three Ceremonies : Sprint Planning, Daily Scrum meeting, Sprint Review
- Three Artifacts : Product backlog, sprint backlog, burndown chart

유연성 : XP와 접목, 다수의 팀으로 확대 적용

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

분산시스템 & ORB

2009-08-14T11:14:00.003+09:00

분산시스템이란
- 가상적으로 all-large 컴퓨터 기반 시스템을 모두 분산시스템이라 함
- 단일 머신이 아닌 다수의 컴퓨터에서 정보 처리가 분산되어있음
- 분산 소프트웨어 공학은 매우 중요하다

시스템 종류
- Personal System : 분산되어있지 않고 PC나 Workstation에서 동작되게 디자인됨
- Embedded : 단일 processor나 집적된 processor에서 동작되게 디자인됨
- software가 느슨하게 집적된 연동 processor가 네트워크에 의해 link되어있는 시스템에서 동작됨

분산시스템 특징 - 자원 공유, 개방성, 동시성, 확장성, fault tolerance, 투명성
분산시스템의 단점 - 복잡성, 보안성, 관리, 예측불가능
분산시스템에서의 이슈- resource identificiation, 통신, QOS, 소프트웨어 구조

분산시스템 구조
- client-server 구조 : 분산 서비스는 클라이언트에 의해 호출됨, 서비스 이용 및 제공에 따라 서버와 클라이언트가 구분됨
- 분산 객체 구조 : 클라이언트와 서버의 구별이 없음. 시스템상의 어떠한 객체든지 사용될 수 있고, 다른 객체를 사용할 수 있다.

Middleware 정의 : 시스템의 중간(middle)에 위치하여, 분산시스템의 서로 다른 요소(component)들을 관리
- 시스템에 따라 새로작성되기보다는, 이미 만들어져 있는 제품이 사용됨(off-the-shelf)

멀티프로세서 구조
- 가장 단순한 형태의 분산시스템 형태
- 시스템은 서로 다른 프로세서상에서 실행되는 다수의 프로세스로 구성된다.
- 많은 대형 real-time시스템의 모델
- 프로세서에 대한 프로세서의 분산형태는 사전에 결정되어있거나, dispatcher에 의해 컨트롤됨

client-server 구조
- 서버에 의해 제공되는 서비스들의 집합으로 짜여진 application과 이 서비스들을 이용하는 클라이언트들로 구성됨
- 클라이언트는 서버의 존재를 인지하지만, 서버는 그렇지 않다
- 클라이언트, 서버 모두 논리적인 프로세스들이다
- 반드시 프로세서와 프로세스가 1:1 대응될 필요는 없다

layered application architecture
- presentation layer : 연산결과를 시스템 사용자들에게 보여주고, 사용자들의 입력과 관련된 layer
- application processing layer : 특정 기능을 제공하는것과 관련된 layer(ex : baking system에서 계좌 열기와 같은 기능)
- data management layer : database 시스템을 관리하는것과 관련된 layer

thin and fat clients(both 2-tier system)
- thin client model : 모든 processing과 data 관리는 서버가 실행한다. 클라이언트는 단순히 presentation layer에 대해서만 응답함. legacy system이 C-S 구조로 이전될때 사용됨. 서버와 네트웤에 너무 많은 부하가 걸리는 단점
- fat client model : 서버는 data management layer만 관리함. 클라이언트가 presentation 및 application processing layer를 담당. application processing이 지역적으로 실행되는것처럼 procesing이 위임됨. client 시스템의 가용성이 좋은 C/S system에 적합. thin model보다 복잡하고, 세심한 관리가 필요함. application이 update될 경우 모든 클라이언트가 설치해야 됨

3-tier architecture
- application layer가 서로 다른 processor에서 실행됨.(그림상에서는 server 2대가 각각 application 및 data management를 담당. client는 presentation만 담당)
- thin model보다 좀 더 좋은 성능을 갖고 fat model보다 관리가 수월함
- 확장성이 좋음 : extera server가 추가될 수 있다.

분산객체 구조
- 클라이언트와 서버 사이에서 분산객체 구조의 구별이 없다.
- 객체 통신은 ORB라는 미들웨어를 통해 이루어진다.
- C/S 구조보다는 설계하기가 복잡하다.

분산객체 구조의 장점
- 설계자가 언제 어떻게 서비스를 제공해야할지 결정에 갖는 시간부담이 감소됨(?)
- 필요하면 새 resource가 추가될 수 있는 개방구조
- 유동적이고 확장 가능함
- 네트웍상에서 객체를 이동함으로써 동적으로 시스템 재설정이 가능

분산객체구조의 사용
- 논리적 모델로써 시스템을 구성하고 조직할수 있음.
- 논리적으로는 C/S 모델이지만, client와 server 모두 소프트웨어 bus를 통해 통신하는 분산된 객체이다.

CORBA(Common ORB Architecture) : 분산객체에 나오는 미들웨어의 ORB에서 Common한 사항 구조화
- ORB<분산객체간의 통신을 담당하는 미들웨어>에 대한 국제 표준
- 비슷한 표준으로 MS의 DCOM이 있음
- application object를 위한 object model
- ORB가 객체 서비스에 대한 요청을 관리함
- 분산 application들에 대해 유용한 일반 객체 서비스들이 존재하고, common components가 최상위에 존재한다.
- C++과 유사한 공통 언어인 IDL로 표현된 interface 정의가 있어야한다. IDL과 일반 언어(C++,JAVA)간의 mapping이 존재하기 때문에, 서로 다른 언어로 쓰여진 객체들이 통신할 수 있다.
- Naming,Trading,Notificatiion,Transaction service를 제공

ORB(Object Request Broker): 분산 객체간의 통신을 위한 미들웨어, 객체 복덕방, 객체 소프트웨어 버스
- 객체간 통신을 관리함. 시스템상 모든 객체들의 존재 및 위치를 파악하고있음
- ORB를 사용함으로써 호출하는 객체는 호출되는 객체의 interface를 정의하는 IDL stub를 binding한다
- binding된 stub를 호출하면 결과적으로 ORB가 호출되며, ORB는 서비스 구현에 대한 interface에 link되어있는 IDL skeleton을 통해 필요로하는(호출되는) 객체를 호출한다.

Stub : Caller에서 객체를 대신해주는 대리인 // skeleton : Calee에서의 대리인 // proxy:파라미터,결과전달

inter-ORB communication
- ORB는 보통 독립적인 프로그램이 아니라 application이 개발될 때 link된 library안에서 객체 집합임
- 분산시스템에서 각 computer들은 고유한 ORB를 가지고 있고, inter-ORB 통신은 분산된 객체 호출에서 사용된다

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

UML - The Unified Modeling Language

2009-08-14T11:01:00.006+09:00

Modeling을 하는 이유 2가지
- 시험해볼 구체적인 것이 있고, 코드로 시험해보는 것보다 비용이 덜 들 때
- 코드보다 읽기 쉽고, 만들기 쉬운 경우

UML 소개
- 복잡한 소프트웨어가 만들어지며 사람들간의 커뮤니케이션이 중요해졌지만, 여러 가지 테크닉들이 존재하기 때문에 커뮤니케이션이 어려움. à 표준화된 Modeling Language가 필요 à UML 등장. Concept은 ER 다이어그램에서 차용함. 엔티티 (Entity), 객체 (Object), 인스턴스 (Instance)는 비슷함. 이와 마찬가지로 엔티티 집합 (Entity Set), 클래스 (Class), 타입 (Type)은 비슷하다. 또한 관계 (Relationship)과 연관관계 (Association)도 비슷한 개념이다. 하지만, ER은 데이터 중심, OOP는 책임(Role) 중심 이여야 함.
- ER Data Model에는 behavior가 없지만 UML은 Behabior가 있다.

Association VS Generalization
- Association(연관) – 클래스 사이의 연관은 대개 다른 객체의 참조를 가지는 인스턴스 변수(가로 화살표)
- Generalization(상속) – 상속관계로 화살촉 방향은 모두 소스 코드 의존성의 방향이다. (세로 삼각형)

Aggregation VS Composition
- Agregation(집합) is part of relationship(하얀다이아몬드/다각형)
- Compostion(합성) is also a part of relationship, but whole live and die together(까만다이아몬드)

UML 다이어그램의 종류

System behavior – 유즈케이스 다이어그램 사용
- Use-Case diagram: 맨 처음 시스템이 어떻게 행동하느냐, 바깥에 있는 사람이 그 시스템을 바라봤을 때 뭘 원하느냐 (뭐가 input이고, output 인지)를 나타냄. 별로 그릴 필요 없음. 오른쪽 그림과 같이 Actor, Use-Case, Association으로 구성됨. Association은 Actor와 유즈케이스의 연결하거나 유즈케이스가 다른 유즈케이스를 사용하거나 유스케이스가 다른 유즈케이스의 확장한 경우이다.

Class Structure – 클래스 다이어그램 사용
- 클래스 다이어그램: 시스템 내 객체 타입과 그들 사이에 존재하는 여러 가지 정적인 관계를 설명. 정적인 관계에는 연관(association) (Phone그림 참조)과 일반화(generalization) (Employee 참조)이 있다.

Class behavior- interaction, activity, state diagram 사용
- Interaction diagram: 한 쓰임새의 여러 객체들을 설명하는데 유용. (Sequence diagram이 이에 속함.)
- State diagram: 한 객체가 여러 쓰임새에 걸쳐서 취하는 행동을 설명하는데 유용 (하나의 객체가 어떤 상태를 가질 수 있는지, 그 객체가 이벤트의 응답으로 어떻게 상태를 변화시키는지나타냄.)
- Activity diagram: 병렬적으로 프로세스 흐름들을 관찰하기 좋음. (Activity에서 다른 activity로 변화는 과정을 보여줌.)

Architecture
- Package diagrams, deployment diagrams

UML 요약
- Use-case diagram – 시스템이 어떻게 행동해야 하는지 보여준다.
- Sequence diagram – 하나의 Usecase에서 객체들의 행동을 보여준다.
- Class-diagram – 객체, 클래스를 서술하고 객체간의 정적인 관계를 보여준다.
- Interaction diagram – 객체가 어떤 행동을 위해 어떻게 서로 협력하는가를 보여준다.
- Activity diagram – 프로세스 흐름을 보여준다.
- State diagram – 주어진 한 클래스의 행동을 자세히 보여준다. // 여러 Usecase에서 객체들의 행동
- Package diagram – 클래스 사이의 의존성을 보여준다.
- Deployment diagram – 소프트웨어 컴포넌트와 하드웨어 컴포넌트간의 물리적 연관성을 보여준다.

유스케이스란 무엇인가?
= Goal Statements(간단한 문장) + Scenario(조금 구조화된 구어체, structured narration)
- 요구사항을 뽑아내는 수단 / 시스템의 범위를 정하는 것을 돕는다.
- 최종 사용자 혹은 고객과의 의사소통 수단
- 유스케이스 다이어그램과 유스케이스 기술서로 구성되어 있다.

Usecase-How to do
- Actor 정의(사람,시스템)
- Goal Statements 작성
- Scenario 작성 = 반복을 통해 상세함을 더한다.
- 메인시나리오는 정상적인 Flow로 작성(10 step 이하)

RUP(Rational Unified Process) – Key concept
- Inception 도입 - initial concept development
- Elaboration 정련 - detailed requirements, high-level analysis, baseline architecture, construction plan
- Construction 구축 - build system interactively,Iteration = 분석+ 설계+ 구축+ 시험
- Transition 전이 - Optimization, beta testing, user training
- Key concept: 반복적iterative + 점진적incremental

CRUD Use Case
어떻게 처리할 것인가? 나눌것인가/그냥 Manage할 것인가?
- 초반에는 Manage하고 점점 복잡해 지면 새로운 하위 레벨로 유스케이스를 뽑아낸다.

방법론 Methodology= Notation(UML)+Process(RUP)+Tool(Rose)

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

Extreme Program Installed

2009-08-11T17:11:00.005+09:00

Extreme Program Installed – Ron Jeffreis, Ann Anderson, Chet Hendrickson

프로젝트 4가지 변수 (비용, 시간, 품질, 범위) 중 범위에 초점
의사소통, 단순성, 피드백, 용기 라는 4가지를 중요하게 생각하는 소프트웨어 개발 방법
고객, 관리자, 프로그래머 각각의 역할에 초점을 맞춰 각 역할에 적절한 권리와 의무를 부여

1. 관리자 : 개발자의 장애물을 치워주는 것.

2. 릴리즈(release) > 반복(iteration) > 스토리(story) > 작업(task)

3. pair programming 가장 중요

4. Prog 전 아이디어 필요할 경우 Quick design session – 10분 정도이상적, 30분을 넘기지 않음.

5. Spike-solution dedutction : 연역법 추론

6. Xp의 12가지 원칙 :

(1) The planning process : 고객이 요구하는 비즈니스 가치를 정의하고 개발자가 필요한 것은 무엇이며 어느 부분에서 지연될 수 있는지 알려준다.
(2) Small release:작은 시스템을 먼저 만들고 짧은 단위로 업데이트 한다.
(3) Metaphor:공통적인 이름의 체계를 갖고 공통적인 시스템 서술서를 갖게 되면 개발과 의사소통을 돕는다.
(4) Simple design:현재의 요구사항에 들어맞는 가장 단순한 시스템을 설계한다.”미래를 위해서”는 필요없다. 리펙토링을 통해서도 좋은 설계를 할 수 있다.
(5) Testing:XP는 항상 소프트웨어의 적합성에 초점을 두고 있다. 개발자는 테스트를 먼저한후 소프트웨어를 작성한다. 그렇게 되면 테스트에서 이미 요구사항을 충족하게 된다.
(6) Refactoring: 개발하는 동안 내내 시스템의 설계를 향상시킨다.
(7) Pair programming : 개발자 둘이서 짝으로 코딩한다. 혼자 하는것보다 비슷하거나 적은비용.
(8) Collective ownership:모든코드는 모든 개발자에게 속해있다.팀을 최상의 속도로 움직이게 하며 변경이 필요할 때도 지연을 줄인다.
(9) Continuous integration:매일 여러 번씩 소프트웨어를 통합하고 빌드.
(10) 40 hour week:피곤한 개발자가 실수를 더 많이 한다.
(11) On site customer : 의사소통을 향상시키고 문서의 양을 줄일수 있다.
(12) Coding standard : 효과적인 공동작업을 위해서는 모든 코드에 대한 코딩 표준 정의

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

Asynchronous JavaScript And XML

2009-08-11T16:56:00.009+09:00

AJAX는 Asynchronous JavaScript And XML의 약어로써 동적인 웹 어플리케이션을 제작하기 위한 요구에서 시작 되었으며, 2005년 2월 Jesse James Garrett에 의해 처음 사용이 되면서 많은 웹 개발자들의 주목을 받게 되었다. 또한 Google의 구글맵스(http://maps.google.com/)의 등장으로 IT 분야의 주목을 받게 되었고, 하루가 다르게 이 기술로 구현된 새로운 제품 및 서비스가 쏟아져 나오고 있다. AJAX가 가지는 특징은 다음과 같다.[1]
XMLHttpRequest와 JavaScript를 이용한 비동기 통신
XML를 통한 데이터 교환과 처리
DOM을 지원하여 다이나믹 표현 가능
CSS와 XHTML을 이용한 표준 기반 표현
이 중 통신기술에서는 기존 웹 어플리케이션과 차이를 보이는데 이를 비교하면 아래와 같다.

그림 1. classic web application model (synchronous)

그림2. Ajax web application model (asynchronous)

그림 1의 전통적인 웹 어플리케이션은 클라이언트가 전송하고자 하는 내용을 웹 서버 측에 요청하고 웹 서버 측은 클라이언트 측이 요청한 내용에 따라서 새로운 웹 페이지를 작성하여 클라이언트 측에 되돌려준다. 이는 클라이언트와 웹 서버 사이의 동기적으로 이루어지며, 클라이언트에서는 웹 서버로부터 요청을 대기하게 되며, 이러한 방식은 복잡한 대화형 사용자 인터페이스 작성을 어렵게 한다. 또한 최초의 클라이언트 측이 가지고 있는 내용과 서버가 되돌려 주는 두 내용 사이에 중복되는 HTML 코드로 인해 많은 대역폭을 낭비하게 된다. 대역폭의 낭비는 단순히 회선의 낭비를 넘어서서 많은 초과 투자를 낳게 된다.

반면에 그림 2와 같이 Ajax 이용한 웹 어플리케이션은 클라이언트 측에 필요한 데이터만을 웹 서버 측에 요청할 수 있다. 또한 비동기 방식으로 처리 되기 때문에 응답이 오기까지 사용자의 다른 작업을 계속 할 수 있다. 이러한 이유로 웹 브라우저와 웹 서버 사이의 교환되는 데이터량이 줄어들고, 응답성이 좋아지게 된다. 요청을 주는 수많은 컴퓨터에서 이 같은 일이 일어나기 때문에, 전체적인 웹 서버 처리량도 줄어들게 된다.
최근 많은 웹 사이트가 AJAX를 이용하고 있으며, 가장 보편적인 예를 Google의 구글맵스(http://maps.google.com/)를 들 수 있다.

Reference -[1] Jess James Garrett, “Ajax: A New Approach to Web Applications”, 2005

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

Cloud Computing에 대한 생각

2009-08-10T00:40:00.010+09:00

데스크탑 기반의 애플리케이션이 아닌 웹 기반(서버에서 수행되는) 애플리케이션을 수행하기 위한 운영 플랫폼을 cloud computing이라고 볼 수 있습니다. 앞에서 설명한 웹 기반 오피스와 같은 제품을 사용자에게 delivery하기 위해서는 엄청나게 많은 스토리지와 컴퓨팅 자원이 필요하게 됩니다. 전 세계의 모든 회사원, 학생들로부터 문서 저장에 대한 요구와 철자검사 등과 같은 요청이 초당 수만/수십만 이상으로 발생하게 됩니다. 대부분의 회사에서 구축되어 있는 컴퓨팅 자원으로는 불가능한 일입니다. cloud computing을 주장하는 회사들을 보면 이런 규모의 컴퓨팅을 능력을 보유하고 있는 회사들입니다. MS, Google, Amazon, IBM 등입니다. 그 중에 Google이 가장 우수한 환경을 구성하고 있다고 생각합니다. Google은 이미 백만대 정도의 서버를 운영하고 있으며 전세계를 대상으로 하는 많은 서비스를 보유하고 있으며 사용하는 사용자 또는 최대 규모라 할 수 있습니다. 다음 그림은 제가 생각하는 앞으로 다가올 컴퓨팅 플랫폼에 대한 예상입니다.

cloud computing은 위의 그림에서와 같이 수많은 컴퓨터를 이용하여 거대한 스토리지와 컴퓨팅 자원을 제공하는 역할을 수행하게 됩니다. Google의 경우 Google File System, Bigtable, Chubby, Map&Reduce 등을 통해 이런 인프라를 이미 구성하였으며 수십만 ~ 수백만대의 서버를 운영하는 노하우도 이미 축적된 상태입니다. 이런 것들이 바로 MS가 가장 무서워하는 것입니다. 현재 MS와 Google은 서로 비즈니스 영역이 틀리지만 싸우고, 견제하는 것도 이런 이유때문입니다. MS가 Yahoo를 인수할려는 최근의 움직임도 최근 Yahoo가 Hadoop을 포함한 Google 인프라에 필적할 만한 것을 만들어 가고 있는 것도 하나의 이유일 것입니다. wikipedia의 cloud computing에 대한 내용중 "See Also" 부분에는 다음과 같은 목록이 있습니다.

그러면 기업의 컴퓨팅 환경을 생각해 봅시다. Google 오피스를 사용하고 gmail을 이용하여 회사내의 기밀 문서를 보관, 전송할 수 있을까요? 물론 작은 기업은 충분히 그럴수 있지만 어느 정도 규모가 있는 회사는 절대로 인터넷 기반 애플리케이션을 사용하지 않을 겁니다. 그럼 기업 시장은 여전히 테스크탑 기반으로 남아 있을까요? 제 생각에는 인터넷 기반 컴퓨팅 플랫폼이 기업내 인트라넷의 핵심 플랫폼으로 구성되고 그 위에 이미 인터넷에서 실행되도록 만들어진 다양한 응용 프로그램들이 탑재되는 형태가 될 것입니다. 말 그대로 기업 내부적으로 소규모 환경이 구성되는 것입니다. 기업은 자신들이 주로 사용하는 응용 애플리케이션이 최적으로 돌아갈 수 있는 플랫폼을 선택하게 됩니다. 이것은 물론 일반 사용자도 동일합니다. 지금도 Linux 보다 Windows가 더 많이 사용되는 것도 같은 이유 때문이죠. 그렇게 되면 어떤 플랫폼이 더 많은 응용 애플리케이션을 제공하느냐가 기업의 선택 조건이 됩니다. Google 플랫폼이나 미래의 MS가 내놓을 인터넷 컴퓨팅 플랫폼 중에서 고민하겠죠. 너무 이상적인 모습인가요? Google 오피스가 현재의 데스크탑 오피스 수준의 기능을 제공하고 구글이 오피스를 만드는데 사용된 많은 컴포넌트를 SDK 형태로 제공하고 Google 내의 기본 서비스들을 쉽게 다른 응용 애플리케이션에서 사용할 수 있는 API를 제공하는 그 순간이 바로 이런 컴퓨팅 환경이 일반화 되는 시기일 것입니다. Google은 이미 Android, Search API, Chart API, Gadget API, Calendar API, Map API , Web Toolkit, Album API 등 많은 API를 오픈하여 제공하고 있습니다.미래의 컴퓨팅 플랫폼 시장을 장악하는 회사가 결국은 살아남게 될 것이고 그 가운데 cloud computing 이라는 개념이 핵심 기술로 사용될 것이며 결국 MS와 Google의 양분하는 형태로 갈 것이라는 예상을 해 봅니다.

또 한번의 중요한 변화의 시기에 우리는 과거와 같이 아무런 준비를 하고 있지 않습니다. 그저 변화가 끝난 다음에 그 변화에 적응할려는 모습만 있습니다. 소프트웨어 산업의 변방에서 중심으로 이동하기 위해서는 이런 변화에 적극적으로 참여하여 변화를 주도해야 합니다.오랜만에 쓰는 긴 칼럼이라서 무척 힘드네요. 몇번 정리한다고 마음만 먹고 못하고 있었는데 제대로 정리했는지 모르겠습니다. 앞에서 언급했듯이 cloud computing이라는 것이 아직 정의가 제대로 되지 않았기 때문에 많은 다른 의견이 존재할 것입니다. 새로운 의견 많이 제시해 주세요.

출처 - http://www.jaso.co.kr/232

My Comment
클라우드 컴퓨팅은 다시 메인프레임으로 돌아가는 거 같네요. 클라이언트 환경이 보다 심플해지면서 (모바일 환경이나 포터블 환경)
요즘 사용자는 자신의 플랫폼에 또다른 어플을 설치하는 것을 꺼려하게 됐죠. 그래서 나온 패러다임이 클라우드 컴퓨팅이라고 보고 있습니다. 엄청난 새로운 기술은 아니라고 생각 되네요.그러나 가장 큰 이슈는 보안 문제네요.예전 메인 프레임은 인트라넷 환경이라면 클라우드는 인터넷 환경을 대표하는 것이니 그에 따른 양날의 검인... 보안을 어떻게 해결 할 것인가가 가장 큰 이슈 겠죠... 과연 어떻게 해결 할 것인가???
No Silver Bullet에 따르듯이 소프트웨어 기술은 발전하지 않고 있죠. 말그대로 페러다임의 변화... 또는 말장난이라는 것을.. 요즘 소셜 네트워크다 뭐다 정신 없는데.... 개발자라면 그러한 시대흐름도
잘 따라야 한다고 생각합니다.

신종 웹어플리케이션 -Mashup 소개-

2009-08-08T16:08:00.002+09:00

Duane Merrill, Writer, Freelance
2006 년 10 월 31 일
mashup은 대화형 웹 애플리케이션의 한 장르로서, 외부 데이터 소스에서 가져온 콘텐트를 사용하여 완전히 새롭고 혁신적인 서비스를 만듭니다. 비공식적으로 Web 2.0이라고 알려진 2 세대 웹 애플리케이션을 의미하기도 합니다. 이 글에서는 mashup의 의미, 오늘날 구현되는 대중적인 mashup들, mashup 개발자들이 애플리케이션을 구현할 때 활용하는 기술들을 소개합니다. 또한, mashup 개발자들이 직면한 기술적, 사회적인 많은 문제점들도 있습니다.

머리말
신종 웹 기반 데이터 통합 애플리케이션이 인터넷을 통해 자라나고 있다. 비공식적으로 mashups이라고 불리는 이 애플리케이션은 대화형 사용자 참여를 강조하고, 자기 파괴적인 방식으로 서드 파티 데이터를 한데 모은다. mashup에 대한 정의는 다음과 같다; mashup 웹 사이트는 웹에 기반하여, 외부의 데이터 소스에서 가져온 콘텐트와 기능을 사용한다.
mashup의 모호한 데이터 통합에 대한 정의는 정확한 것은 아니다. mashup을 생각하는 가장 좋은 방법은 이 용어의 어원을 생각해 보는 것이다. 대중 음악에서 차용된 것으로, mashup은 (보통 다른 장르에 속한) 두 개의 다른 노래들에서 보컬과 악기 트랙을 혼합한 새로운 노래이다. “잡종 팝송(bastard pop)” 과 마찬가지로, mashup은 콘텐트를 비정상적이고 혁신적으로 혼합한다. (종종 관련성이 없는 데이터 소스에서도 가져온다.) 전산 소비가 아닌 인간이 소비할 수 있도록 만들어진다.
그렇다면, mashup은 과연 어떤 모습일까? ChicagoCrime.org 웹 사이트는 매핑 mashup의 좋은 예제이다. 언론에서 광범위한 대중성을 확보한 첫 번째 mashup 중 하나인 이 웹 사이트는 Chicago Police Department의 온라인 데이터베이스에서 얻은 범죄 데이터를 Google Maps의 지도 제작법과 혼합한다. 사용자들은 이 mashup 사이트와 인터랙팅 할 수 있다. 이를 테면, South Chicago의 최근 모든 강도 사건의 상세를 나타내는 푸쉬업(pushup)을 포함한 지도를 지리적으로 디스플레이 할 수 있다. 개념과 표현은 단순하고, 범죄와 지도 데이터의 합성은 시각적으로 강력한 힘을 발휘한다.
In mashup 장르에서는, 매핑 mashup을 포함한 대중적인 mashup 장르를 연구할 것이다. 관련 기술에서는 mashup의 구현과 작동과 관련된 기술을 검토할 것이다. 기술적 문제와 사회적 문제 섹션에서는 시급한 기술적, 사회적인 도전 과제들을 규명할 것이다.

mashup 장르
이 섹션에서는, 대표적인 mashup 장르를 간단히 설명할 것이다.

매핑 mashup
정보 기술 세대에서, 사람들은 물건과 행위에 대한 상당한 데이터를 모으게 된다. 두 가지 모두 위치에 대한 주석이 달린다. 위치 데이터를 포함하고 있는 이 모든 데이터들은 지도를 사용하여 지리적으로 표현되고 있다. mashup이 등장하기 까지 가장 큰 촉매제가 된 것 중 하나가 Google의 Google Maps API이다. 이것은 웹 개발자들(취미 활동가, 사상가, 기타)이 모든 데이터들(핵 재앙에서부터 보스턴의 CowParade까지) 지도로 가져왔다. Microsoft (Virtual Earth), Yahoo (Yahoo Maps), AOL (MapQuest)의 API들이 바로 뒤를 이었다.

비디오 mashup과 사진 mashup
사진 호스팅과 Flickr 같은 소셜 네트워킹 사이트와 사진 공유를 표방하는 API들이 등장하면서 다양한 mashup들이 생겨나고 있다. 이러한 콘텐트 프로바이더들은 그들이 호스팅 하고 있는 이미지와 관련된 메타데이터(누가 사진을 찍었는지, 어떤 사진인지, 어디서 언제 찍었는지 등)를 갖고 있기 때문에, mashup 디자이너들은 사진을 이 메타데이터와 제휴될 수 있는 다른 정보들과 혼합한다. 예를 들어, 하나의 mashup이 노래 가사나 시를 분석하고 관련 사진들의 모자이크나 콜라주를 만들 수 있고, 또는 공통적인 사진 메타데이터(제목, 타임스탬프, 기타 메타데이터)에 기반하여 소셜 네트워킹 그래프를 디스플레이 한다. (CNN 뉴스 사이트 같은) 웹 사이트에서 뉴스의 단어들을 사진들과 매칭시키는 방식으로 텍스트를 렌더링 할 수 있다.

검색 mashup과 쇼핑 mashup
검색과 쇼핑 mashup은 mashup이라는 용어가 생겨나기 전부터 존재했다. 웹 API 전에, BizRate, PriceGrabber, MySimon, Google Froogle 같은 비교 쇼핑 톨들은 b2b 기술이나 screen-scraping의 결합을 사용하여 가격 비교 데이터들을 모았다. mashup과 기타 웹 애플리케이션들을 활용하기 위해, eBay와 Amazon 같은 사용자 마켓플레이스는 이들의 콘텐트에 프로그래밍 방식으로 액세스 할 수 있는 API를 만들었다.

뉴스 mashup
뉴스 소스(New York Times, BBC, Reuters)는 2002년부터 RSS와 Atom 같은 신디케이션 기술을 사용하여 다양한 토픽과 관련된 뉴스 피드를 보급했다. 신디케이션 피드 mashup은 사용자의 피드를 모아서 웹에 나타낸다. 독자의 특수한 취향에 맞게 제공되는 개인적인 신문을 만든 것이다. Diggdot.us가 한 예인데, 이는 기술 관련 뉴스 소스인 Digg.com, Slashdot.org, Del.icio.us 등에서 피드를 결합한다.

관련 기술
이 섹션에서는 mashup의 개발에 활용할 수 있는 기술들을 살펴보도록 하겠다. 기술에 대한 자세한 내용은 참고자료 섹션을 참조하기 바란다.

아키텍처
mashup 애플리케이션은 논리적으로나 물리적으로 떨어진(네트워크와 구성 영역에 의해 분리된 것 같다.) 세 개의 다른 참여자들로 구성된다: API/콘텐트 프로바이더, mashup 사이트, 클라이언트의 웹 브라우저.
API/콘텐트 프로바이더. 이들은 혼합되는 콘텐트의 공급자들이다. ChicagoCrime.org mashup 예제에서, 공급자는 Google과 Chicago Police Department가 된다. 데이터를 가져올 수 있도록 하기 위해, 공급자는 REST, 웹 서비스, RSS/Atom 같은 웹 프로토콜을 통해서 웹 콘텐트를 노출한다. 하지만 많은 잠재적인 데이터 소스는 아직까지는 편리한 방법으로 API를 노출하지 않는다. Wikipedia, TV Guide, 그리고 가상의 모든 정부 및 공공 도메인 웹 사이트에서 콘텐트를 추출하는 mashup은 스크린 스크래핑 기술을 사용하여 이를 사용한다. 이러한 상황에서, 스크린 스크래핑이 의미하는 것은, 원래 인간이 소비하기로 되어있는 공급자의 웹 페이지를 파싱하여, 콘텐트 프로바이더에서 정보를 추출하는 과정을 의미한다.
mashup 사이트. 이곳은 mashup이 호스팅 되는 장소이다. 여기에 mashup 로직이 있다는 이유 때문에 여기에서는 반드시 실행될 필요가 없다. 반면, mashup은 자바 서블릿, CGI, PHP, ASP 같은 서버 측 동적 콘텐트 생성 기술을 사용하는 전통적인 웹 애플리케이션과 비슷하게 구현될 수 있다.
또는, mashup 콘텐트는 클라이언트 측 스크립팅(JavaScript)이나 애플릿을 통해 클라이언트의 브라우저에서 직접 생성될 수도 있다. 이러한 클라이언트 측 로직은 mashup의 웹 페이지에 직접 삽입된 코드와 스크립팅 API 라이브러리나, 이러한 웹 페이지들이 참조하는 애플릿들의 결합이다. 이 방식을 사용하는 mashup을 rich internet applications (RIA)이라고 하는데, 대화형 사용자 경험을 강조한다는 뜻을 내포하고 있다. (리치 인터넷 애플리케이션은 "Web 2.0"이 표방하고 있는 것이다.) 클라이언트 측에서 혼합할 때의 이점은 mashup 서버를 대신하기 때문에 오버헤드가 적고(데이터는 콘텐트 프로바이더에서 직접 가져올 수 있다.), 보다 완벽한 사용자 경험이 가능하다는 점이다. (페이지들은 전체 페이지를 리프레쉬 하지 않고도 콘텐트의 일부만 업데이트할 것을 요청할 수 있다.) Google Maps API는 브라우저 측 JavaScript를 통한 액세스를 위한 것이고, 클라이언트 측 기술의 한 예가 된다.
종종 mashup은 서버 측 로직과 클라이언트 측 로직의 결합을 사용하여 데이터를 모은다. 많은 mashup 애플리케이션들은 자신들에게 직접 제공된 데이터를 사용하여, (적어도) 한 개의 데이터 세트는 로컬로 만든다. 게다가, 다중 소스 데이터("Kevin Bacon과 공동 주연을 했던 영화 배우가 사들인 평균 부동산 가격")에 대한 복잡한 쿼리는 클라이언트의 웹 브라우저 내에서 많은 일을 수행해야 한다.
클라이언트의 웹 브라우저. 이곳에서 애플리케이션은 그래픽으로 실행되고, 사용자 인터랙션이 발생한다. 앞서 설명한 것처럼, mashup은 종종 클라이언트 측 로직을 사용하여 혼합 콘텐트를 조합 및 합성한다.

Ajax
Ajax가 약어(어떤 사람은 "Asynchronous JavaScript + XML"의 합성으로 본다.)인지 아닌지에 대한 논의가 있다. Ajax는 특정 기술이기 보다는 웹 애플리케이션 모델이라고 할 수 있다. 비동기식 로딩과 콘텐트의 표현에 초점을 맞춘 여러 기술들을 구성하고 있다.
- 스타일 표현을 위한 XHTML과 CSS
- 동적 디스플레이이와 인터랙션에 의해 노출된 Document Object Model (DOM) API
- 비동기식 데이터 교환, 일반적으로 XML 데이터
- 브라우저-측 스크립팅, 주로 JavaScript
이러한 기술들이 함께 사용될 때, 그 목적은 사용자 액션 후에 전체 페이지를 재 로딩 및 재 실행 하기 보다는, 소량의 데이터를 콘텐트 서버와 교환하여 보다 원활한 사용자 경험을 만들어 내는 것이다. JavaScript에서 구현된 다양한 Ajax 툴킷과 라이브러리(Sajax 또는 Zimbra)에서 mashup용 Ajax 엔진들을 구현할 수 있다. Google Maps API에는 상용 Ajax 엔진이 포함되어 있고, 사용자 경험 역시 강력하다. 페이지 재 로드를 실행하는 조작 화살표나 트랜슬레이션 화살표에 대한 스크롤바가 없다는 점에서 진정한 로컬 애플리케이션처럼 작동한다.

웹 프로토콜: SOAP과 REST
SOAP과 REST는 원격 서비스들과 통신하는 플랫폼 중립적인 프로토콜이다. 서비스 지향 아키텍처 패러다임의 일부로서, 클라이언트는 SOAP과 REST를 사용하여 기반 플랫폼에 대한 지식 없이도 원격 서비스들과 인터랙팅 할 수 있다. 서비스의 기능은 요청 및 응답 받은 메시지의 디스크립션에 의해 전달된다.

SOAP은 웹 서비스 패러다임의 기본 기술이다. 원래, Simple Object Access Protocol의 약어였던 SOAP은 Services-Oriented Access Protocol (또는 그냥 SOAP)으로 개명되었다. 초점이 객체 지향 시스템에서 메시지 교환의 상호 운용성으로 이동했기 때문이다. SOAP 스팩에는 두 개의 핵심 요소가 있다. 첫 번째는 플랫폼 중립적인 인코딩을 위한 XML 메시지 포맷이고, 두 번째는 헤더와 바디로 구성된 메시지 구조이다. 헤더는 애플리케이션 페이로드(바디), 이를 테면, 인증 정보에 국한되지 않는 콘텍스트 정보를 교환한다. SOAP 메시지 바디는 애플리케이션 스팩의 페이로드를 캡슐화 한다. 웹 서비스용 SOAP API는 WSDL 문서로 기술되는데, 서비스가 노출하는 작동, 메시지 포맷(XML Schema 사용), 접근 방법 등이 설명되어 있다. SOAP 메시지는 HTTP를 통해 전달되지만, 다른 트랜스포트(JMS 또는 이메일)도 가능하다.

REST는 Representational State Transfer의 약어로서, HTTP와 XML을 사용한 웹 기반 통신 기술이다. 단순함과 프로파일의 부족 때문에 SOAP과 분리되고 매력도 떨어진다. 현대 프로그래밍 언어에서 찾을 수 있는 동사 기반 인터페이스(getEmployee(), addEmployee(), listEmployees() 같은 다양한 메소드로 구성됨)와는 달리, REST는 근본적으로 모든 정보 조각에 사용할 수 있는 몇 가지 연산들(POST, GET, PUT, DELETE)만 지원한다. REST에서 강조하는 것은 리소스라고 하는 정보이다. 예를 들어, 사원에 대한 정보 기록은 URI로 구분되고, GET 연산을 통해 가져오고, PUT 연산으로 업데이트 되는 식이다. 따라서 REST는 SOAP 서비스의 document-literal 스타일과 비슷하다.

스크린 스크래핑
앞서 언급했던 것처럼, 콘텐트 프로바이더에서 오는 API의 부족 때문에, mashup 개발자들이 스크린 스크래핑에 의존하여 그들이 혼합하고자 하는 정보를 가져온다. 스크래핑(Scraping)은, 프로그래밍 방식으로 사용 및 조작될 수 있는 정보의 시맨틱 데이터 구조를 추출하기 위해, 소프트웨어 툴을 사용하여 인간이 소비하도록 작성된 콘텐트를 파싱하고 분석하는 프로세스이다. 일부 mashup은 데이터 획득에 스크린 스크래핑 기술을 사용한다. 특히, 공공 섹터에서 데이터를 가져올 때 그렇다. 예를 들어, 부동산 매핑 mashup은 지도 제작 공급자의 지도와 판매 또는 임대 리스팅을 스크랩 된 “comp” 데이터를 혼합할 수 있다. 데이터를 스크래핑 하는 또 다른 mashup 프로젝트로는 XMLTV가 있는데, 이것은 전 세계, TV 리스트를 모으는 툴의 컬렉션이다.
스크린 스크래핑은 세련되지 않은 솔루션으로 간주된다. 여러 가지 이유가 있다. 두 개의 근본적인 단점들이 있기 때문이다. 첫 번째는 인터페이스를 가진 API와는 달리, 스크래핑은 콘텐트 프로바이더와 콘텐트 소비자 간 지정된 프로그램 방식의 콘트랙트가 없다. 스크래퍼는 소스 콘텐트의 모델과 관련하여 툴을 디자인 해야 하고, 공급자는 지속적으로 표현 모델에 의존해야 한다. 웹 사이트는 룩앤필을 주기적으로 정비하여 스타일을 유지해야 한다. 툴이 이 일을 하지 못하기 때문에 스크래퍼의 고통만 늘어난다.
두 번째 문제는 고급의, 재사용 가능한 스크린 스크래핑 툴킷 소프트웨어, 즉 scrAPIs의 부족이다. 이 같은 API와 툴킷이 부족한 이유는 각 스크랩핑 툴이 애플리케이션을 필요로 하기 때문이다. 때문에 많은 개발 오버헤드가 생기고, 개발자들은 콘텐트를 역 엔지니어링 하고, 데이터 모델을 개발하며, 공급자 사이트에서 미가공 데이터를 파싱 및 모아야 한다.

시맨틱 웹과 RDF
스크린 스크래핑의 세련되지 못한 특성은 인간이 소비하도록 만들어진 콘텐트가 자동화된 머신이 소비하기에 좋은 콘텐트가 되지 못한다는 사실에서 기인한다. 시맨틱 웹은, 기존 웹이 머신도 읽을 수 있는 정보를 사용하여 인간을 위해 설계된 콘텐트를 보완하도록 증가될 수 있다고 표방한다. 시맨틱 웹이라는 정황에서, 정보는 데이터와는 다르다. 데이터가 의미를 전달할 때에는 정보가 된다. 시맨틱 웹의 목적은 의미를 전달하는 메타데이터를 가진 데이터를 보강하여, 자동화, 통합, 추론, 재사용에 맞는 웹 인프라스트럭처를 만드는 것이다.
Resource Description Framework (RDF)로 알려진 W3C 스팩군은 데이터를 기술하는 문법 구조를 확립하는 방식을 제공한다. XML로는 충분하지 않다. 같은 데이터를 기술하는데 많은 방식으로 코딩 할 수 있다는 점에서 너무 모호하다. RDF-Schema는 RDF의 기능에 추가되어 머신이 읽을 수 있는 방식으로 인코딩 한다. 일단 데이터 객체가 데이터 모델에서 기술될 수 있다면, RDF는 subject-predicate-object(subject의 S는 relationship R과 object O를 갖고 있다.)를 통해서 데이터 객체들 간 관계 구조를 제공한다. 데이터 모델과 관계 그래프의 결합은 온톨로지의 생성에 적용되고, 이는 검색 및 추론될 수 있는 계층적 지식 구조가 된다. 예를 들어, it "eats" other "animal-type" 라는 제약 조건을 가진 "animal-type"의 하위 클래스로서 "carnivore-type" 모델을 정의할 수 있고, 이것에 대한 두 개의 인스턴스를 만든다. 하나는 치타와 북극곰과 이들의 습성과 관련된 데이터로 전개되고, 또 다른 하나는 가젤과 펭귄과 이들 각각의 습성과 관련된 데이터를 전개할 수 있다. 추론 엔진은 이러한 개별 모델 인스턴스들을 “혼합”하고 치타가 펭귄이 아닌 가젤을 잡아먹는다는 추론을 내린다.
RDF 데이터는 다양한 분야에서 빠르게 채택되고 있다. 소셜 네트워킹 애플리케이션(FOAF -- Friend of a Friend)과 신디케이션(RSS)도 한 예이다. 게다가, RDF 소프트웨어 기술과 컴포넌트는 어느 정도 성숙해졌고, 특히 RDF 쿼리 언어(RDQL과 SPARQL)와 프로그래밍 프레임웍과 추론 엔진(Jena와 Redland) 분야가 성장했다.

RSS와 ATOM
RSS는 XML 기반 신디케이션 포맷의 일부이다. 신디케이션은 콘텐트를 배포하고자 하는 웹 사이트가 RSS 문서를 만들고 이 문서를 RSS 퍼블리셔로 등록한다. RSS가 실행되는 클라이언트는 퍼블리셔의 피드에서 새로운 콘텐트를 검사하고 알맞은 방식으로 이에 대응한다. RSS는 뉴스 아티클과 헤드라인, CVS checkins나 wiki pages용 changelog, 프로젝트 업데이트, 라디오 프로그램 같은 오디오 데이터까지, 광범위한 콘텐트를 합성한다. Version 1.0은 RDF 기반이지만, 최신 2.0 버전은 그렇지 않다.
ATOM은 새롭지만 더 유사한 신디케이션 프로토콜이다. Internet Engineering Task Force (IETF)의 제안 표준이고 RSS 보다 더 좋은 메타데이터를 관리 할 방법을 모색하고 있으며, 더 좋은 문서를 제공하고, 구조 개념을 일반 데이터 표현에 적용한다.
이러한 신디케이션 기술은 뉴스와 웹로그 애그리게이터 같은 이벤트 기반 콘텐트 또는 업데이트 중심 콘텐트를 모으는 mashup에는 잘 맞는다.

기술적 문제
다른 데이터 통합 분야와 마찬가지로, mashup 개발에는 기술적 문제들이 많이 있다. 특히 mashup 애플리케이션들은 더욱 많은 기능들을 갖추어야 한다. 이 섹션에서는 몇 가지 문제점들을 규명해보도록 하겠다.

데이터 통합 문제: 시맨틱 의미와 데이터 품질
오늘날 기업의 제 1의 IT 관심사는 엔터프라이즈 가상 구조에 데이터 통합하기라는 조사가 있었다. 가상 구조(virtual organization)는 연합 비즈니스 단위의 합성이며, 각각은 관리 도메인 안에 포함되어 있음을 의미한다.) (현재 비즈니스 조건들을 반영하는 기업 대시보드를 만들기 위해) 레거시 데이터 소스를 통합해야 하는 도전에 직면한 많은 엔터프라이즈 IT 관리자들과 마찬가지로, mashup 개발자들도 이종의 데이터 세트 간 공유 시맨틱 의미를 추출해야 한다는 비슷한 도전 과제를 안고 있다. 따라서, mashup 개발자가 무엇을 해야 하는지 알고 싶다면 엔터프라이즈 IT가 직면한 통합 문제를 검토해 봐야 한다.
예를 들어, 데이터 모델들 간 트랜슬레이션 시스템들이 설계되어야 한다. 데이터를 일반 형식으로 변환할 때, 매핑이 완전한 것이 아닐 때 추론이 이루어진다. (예를 들어, 하나의 데이터 소스가 하나의 모델을 가질 수 있고, 주소 유형에는 국가 필드가 포함되어 있는 반면, 다른 것은 그렇지 않다.) mashup 개발자들은 소스 데이터 모델 분야에는 전문가가 될 수 없다. 이 모델은 이들에게는 서드 파티에 해당하고, 추론은 매력적이거나 명확하지 못하다.
소실된 데이터나 불완전한 매핑 외에도, mashup 디자이너는 그들이 통합하고자 하는 데이터가 머신 자동화에 맞지 않다는 것을 알게 된다. 정리가 필요하다. 예를 들어, 법 집행 체포 기록은 일관성 없이 입력될 수 있다. 이름을 줄여서 쓰고(어떤 곳에서는, "mkt sqr"로, 또 다른 곳에서는 "Market Square"로 표기한다.), 추론이 어렵게 된다. RDF 같은 시맨틱 모델링 기술은, 데이터 스토어에 빌트인 된다면, 다른 데이터 세트들 간 자동화 추론 문제를 완화시킨다. 레거시 데이터 소스들은 시맨틱 모델링 기술에 사용되기 전에 분석과 데이터 청소의 관점에서 인간의 노력이 많이 필요하다.
mashup 개발자들은 IT 통합 매니저가 겪지 않은 여러 문제들과도 싸워야 한다. 이중 하나가 데이터 오염 문제이다. 이들의 애플리케이션 디자인의 일부로서, 많은 mashup들은 퍼블릭 사용자 인풋을 끌어들인다. WIKI 애플리케이션 도메인에서 분명해졌듯이, 이는 양날이 선 칼이다. 공개 기여와 데이터 혁신을 가능케 하기 때문에 강력하지만, 일관성 없고, 부정확 하게, 또는 의도적으로 데이터 입력을 유도한다. 후자는 데이터 신뢰성에 대해 의심하게 되고, 이는 mashup이 제공하는 가치를 충분히 상쇄한다.
mashup 개발자들이 직면한 또 다른 통합 문제는 스크린 스크래핑 기술이 데이터 획득에 사용될 때 발생한다. 이전 섹션에서도 설명했지만, 파싱과 수집 툴과 데이터 모델을 추출하는 데는 상당한 역 엔지니어링이 필요하다. 이러한 툴과 모델이 만들어지는 최고의 상황에서도, 소스 사이트가 콘텐트를 표현하는 방식을 리팩토링 해야 한다. 따라서 통합 프로세스에 제동이 걸리고 mashup 애플리케이션 오류로 이어진다.

컴포넌트 문제
Ajax 모델의 웹 개발은 보다 풍부하고 완벽한 사용자 경험을 제공할 수 있지만, 난점도 안고 있다. Ajax는 브라우저의 클라이언트 측 스크립팅 기능과 DOM을 결합하여 브라우저 디자이너가 생각하지 못했던 콘텐트 전달 방식을 이룩해야 한다. (아마도 Ajax의 해킹 특성에 기인한 것 같다.) 하지만, 이는 Ajax 기반 애플리케이션을 Microsoft created Internet Explorer 이후 웹 디자이너를 난감하게 하는 같은 브라우저 호환성 문제로 가져온다. 예를 들어, Ajax 엔진은 XMLHttpRequst 객체를 사용하여 원격 서버들과 비동기식으로 데이터를 교환한다. Internet Explorer 6에서, 이 객체는 원시 JavaScript가 아닌 ActiveX로 구현된다.
보다 근본적으로는, Ajax의 경우, 사용자 브라우저 안에 JavaScript가 실행되어야 한다. 하지만 JavaScript를 지원하지 않거나 실행되지 않는 브라우저나 자동화 툴을 사용하는 특정 사용자들도 있기 마련이다. 이 같은 툴 세트로는 인터넷과 인트라넷 검색 엔진용 정보를 모으는 로봇, 스파이더, 웹 크롤러 등이 있다. Ajax 기반 mashup 애플리케이션은 소수의 사용자 기반과 검색 엔진 가시성을 잃게 된다.
페이지 내에 비동기식으로 콘텐트를 업데이트 할 때 JavaScript를 사용하면 사용자 인터페이스 문제가 생긴다. 콘텐트는 더 이상 브라우저의 주소 바에 있는 URL로 연결되지 않기 때문에, 사용자는 브라우저의 백(back) 버튼의 기능과 BOOKMARK 기능을 기대할 수 없다. Ajax는 비점증적 콘텐트 업데이트를 요청함으로써 레이턴시를 줄일 수 있지만, 형편 없는 디자인 때문에 사용자 경험이 엉망이 되고, 업데이트의 세분성은 양에 비해 너무 적고 업데이트 오버헤드는 가용 리소스를 갉아먹는다. 또한, 인터페이스 로드나 콘텐트가 업데이트 되는 동안 사용자(진행 바 같은 비주얼 피드백을 가진)사용자를 지원해야 한다.
분산된, 크로스 도메인 애플리케이션과 마찬가지로, mashup 개발자와 콘텐트 프로바이더는 보안 문제도 다루어야 한다. 아이디의 개념은 성가신 주제가 될 수 있다. 전통적인 웹은 익명 액세스용으로 구현되었다. 싱글사인온은 바람직한 기능이지만, 많은 기술들이(Microsoft Passport에서 Liberty Alliance 까지)있고, 반드시 통합되어야 하는 아이디 네임스페이스에 부조화를 만든다. 콘텐트 프로바이더는 자신들의 API에 인증과 권한 스킴을 적용하여(보안 아이디나 안전하게 구분할 수 있는 애트리뷰트 개념이 필요하다.) 유료 등록자나 민감한 데이터가 포함된 비즈니스 모델에 실행해야 한다. 민감한 데이터는 기밀성(암호화)이 필요하고, 이들을 다른 소스들과 결합할 때 특별한 주의를 기울여야 한다. 아이디는 감사와 규제 순응에 필수적이다. 게다가, 서버와 클라이언트 측에서 발생하는 데이터 통합의 경우, 사용자부터 mashup 서비스까지 아이디와 보안이 필요하다.

사회적 문제
이전 섹션에서 설명한 기술적 문제 외에도, mashup이 대중성을 확보하면서 생기는 사회적인 문제도 있다.
mashup 개발자들이 직면한 가장 큰 사회적 문제들 중 하나는 지적 재산의 보호와 소비자 프라이버시 대 공정 사용과 정보의 자유로운 흐름 간 대립이다. 무식한 콘텐트 프로바이더(스크린 스크래핑의 표적)와 데이터 검색을 위해 API를 노출하는 콘텐트 프로바이더들은 자신들의 콘텐트가 승인되지 않는 방식으로 사용되고 있다는 것을 알아야 한다. 웹 애그리게이션과 규제와 관련하여, 참고자료를 참조하라.

mashup 웹 애플리케이션 장르는 아직 유아기에 머물러 있다. 여가 시간에 많은 mashup을 만드는 정도이다. 이러한 개발자들은 보안 같은 문제들을 인식하지 못한다. 게다가, 콘텐트 프로바이더는 머신 기반 콘텐트 액세스에 API를 제공하는 것의 가치를 이제서야 깨닫기 시작했고, 많은 사람들은 이것을 중요한 비즈니스 문제로 간주하지 않는다. 이러한 사실들이 결합하여 저질의 소프트웨어를 양산하고, 테스팅과 품질 보증 같은 우선순위들은 개념 입증과 혁신의 뒤로 물러나 있다. 커뮤니티는 보다 성숙한 소프트웨어 개발 프로세스를 위해서 오픈 표준과 재사용 가능한 툴킷들을 조합해야 한다.
mashup이 재미있는 장난감에서 세련된 애플리케이션으로 변모하기 전에, 강력한 표준, 프로토콜, 모델, 툴킷 등의 제반 사항들이 해결되어야 한다. 많은 소프트웨어 개발 리더, 콘텐트 프로바이더, 기업가들이 mashup의 가치, 즉 mashup이 귀중한 비즈니스 모델이라는 것을 인식해야 한다. API 프로바이더는 자신들의 콘텐트에 요금을 부과할 것인지의 여부를 결정해야 하고, 부과할 것이라면, 그 방법도 모색해야 한다. (예를 들어, 등록비 또는 사용료) 아마도, 다양한 서비스 품질이 제공될 것이다. eBAY나 Amazon 같은 프로바이더들은 자신들의 API를 무료로 사용할 수 있도록 하는 운동을 벌이고 있다. mashup 개발자들은 광고 기반의 수익 모델을 모색하거나, 흥미진진한 mashup 애플리케이션을 개발해야 할 것이다.

요약
mashup은 웹 애플리케이션의 신종 장르이다. 시맨틱 웹에서 기인한 데이터 모델링 기술을 약결합, 서비스 지향, 플랫폼 중립의 통신 프로토콜과 결합하면, 웹에서 사용할 수 있는 거대한 정보를 활용 및 통합할 수 있는 애플리케이션을 위한 인프라스트럭처를 제공하게 된다. mashup 애플리케이션이 대중성을 얻어가면서, 공정 사용과 지적 재산권, 그리고 그리드 컴퓨팅과 b2b 워크플로우 관리 같은 사회적 문제들에 어떤 영향을 미치는지를 보는 것도 재미있는 일이다.
mashup 개발에 대해 자세히 알고 싶다면 developerWorks의 새로운 튜토리얼 시리즈를 기대하기 바란다. mashup 구현 방법을 설명할 예정이다. 시맨틱 웹 기술과 온톨로지를 사용하여 자신의 mashup을 구현하는 방법을 설명할 것이다.

기사의 원문보기
Mashups: The new breed of Web app

참고자료
교육
Programmable Web
Considering Ajax, Part 1: Cut through the hype (Chris Laffra, developerWorks, May 2006)
Ajax page Mozilla Development Center.
The Interplay of Web Aggregation and Regulations (LawTech)
DB2 and open source: Put yourself on the map with Google Maps API, DB2/Informix, and PHP on Linux (Marty Lurie and Aron Y. Lurie, developerWorks, March 2006)
Building Web service applications with the Google API (Nicholas Chase, developerWorks, May 2002)
The ultimate mashup -- Web services and the semantic Web
Second Generation Web Services
REST and the Real World
W3C Semantic Web Activity
W3C RDF Activity
Introduction to Jena: Use RDF models in your Java applications with the Jena Semantic Web Framework (Philip McCarthy, developerWorks, June 2004)
What is RSS?

소프트웨어 공학 자료

2009-08-08T01:45:00.011+09:00

대학원 -소프트웨어 공학 자료-
내가 소프트웨어를 새로운 시각으로 볼 수 있게 해준 강의였으며, 기존의 이론적 소프트웨어 공학 수업이 아닌 실제 실무에서 사용하는 방법으로 접근 하는 방법을 알려주신 강사님께 감사 드리며 자료를 포스팅한다.

Introduction to Software Engineering I
00.ObjectIntro.pdf
03.Inheritance.pdf

Introduction to Software Engineering II
How_Microsoft_builds_software.pdf

UML - The Unified Modeling Language
UseCaseIntro.pdf
UseCaseTalk.pdf
UML.pdf

개발 방법론
Scrum개발방법론.pdf
XP_Installed.pdf
ch11_분산객체.pdf
EJB_(with_chapter_11).pdf

Inspection
InspectionLecture(Adam_Porter).pdf

Software Testing
softwaretesting(200811).pdf
Test_Driven_Development.pdf
JUnit-20081125.pdf

Aspect Oriented Programming
Aspect-Oriented-Programming.pdf

CMM
CMM_(with_chapter_25).pdf

Function Point
FunctionPoint.pdf

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

"맨먼스 미신"을 읽고

2009-08-08T01:38:00.006+09:00

두 명의 프로그래머가 개조한 자기 집 차고에서 대규모 프로그래밍 팅이 최대한으로 노력한 결과보다 더 우수한 프로그램을 개발해냈다는 기사는 이따금 신문에 실리곤 한다. 프로그래머라면 누구나 듣는 이야기 이며 별 거부감 없이 받아들인다.그럼 필드에서는 두명의 팀을 짜서 개발을 하지 않는 이유는 무엇일까?그것은 무엇을 생산 하느냐에 따라 달라지는 것이다.위에서 말한 프로그램은 자체가 완결적이며, 개발 기반인 시스템에서 의해 실행될 준비가 되어있다...필드에서는 프로그램 + @가 필요하다.

@는 두가지 종류

1. 프로그래밍 제품프로그램이 프로그래밍 제품이 되기 위해서는 테스트,문서화,일반화,유지관리가 있어야 한다.

테스트 - 믿고 의지해도 문제가 되지 않을 만큼 철저히 테스트 해야 한다.

문서화 - 누구나 쉽게 사용할 수 있는 문서 및 개발 할 수 있는 문서를 만들어야 한다.

일반화 - 누구나 쉽게 제품을 사용할 수 있게 일반화 해야 한다.

2. 프로그래밍 시스템프로그래밍 시스템이란 프로그램의 집합으로써 서로 기능이 조화되기 위한 인터페이스 설계되어야 하며 인터페이스간의 무결성 검사를 해야 한다.

위의 @의 노력은 일차함수의 노력 증가가 아니라 제곱의 기하급수적인 노력이 필요하게 된다..

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

The Joel Test: 나은 코딩을 위한 12단계

2009-08-07T20:04:00.003+09:00

글 : Joel Spolsky번역 : B.K. Chung 정봉겸 감수 : Jang Han Goo 구장한

2000년 8월 9일

SEMA에 대해서 들어보신 적이 있습니까? 소프트웨어 팀이 얼마나 잘하는지를 재는 나름대로 복잡한 시스템입니다. 앗, 아니! 그 링크를 누르지 마세요. SEMA를 "이해"만 하는데 아마 6년정도가 걸릴것입니다. 그래서 소프트웨어 팀이 얼마나 좋은지 등급을 매길 수 있는 - 좀 무책임하고 되는대로의 - 자체적인 버젼의 테스트를 만들었습니다. 이 테스트의 장점은 3분정도밖에 걸리지 않는다는 것입니다. 절약되는 시간으로 의대에 가서 공부할 수도 있을 것입니다.

The Joel Test
Source Control(소스 컨트롤)을 사용하십니까?
한번에 빌드를 만들어낼 수 있습니까?
daily build(일별 빌드)를 만드십니까?
버그 데이타베이스를 가지고 있습니까?
새로운 코드를 작성하기 전에 버그들을 잡습니까?
up-to-date(최신) 스케줄을 가지고 있습니까?
spec(설계서)를 가지고 있습니까?
프로그래머들이 조용한 작업환경을 가지고 있습니까?
돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
테스터들을 고용하고 있습니까?
신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
hallway usability testing(무작위 사용성 테스팅)을 하십니까?

Joel Test이 특별한 점은 각 직문에 예/아니오로 바로 대답할 수 있다는 것이다. lines-of-code-per-day(하루동안 산출되는 코드의 줄수)나 average-bugs-per-inflection-point(산출 시점의 평균 버그수) 같은 것은 알 필요가 없습니다. "예"에 해당 하는 질문에 1점씬 가산됩니다. 하지만 이 테스트는 핵 원자로에 사용하는 소프트웨어가 안전한지를 검사하는등 에는 사용하지 말아주십시오.
12점은 완벽, 11은 충분한 점수이지만 10점이나 그 이하는 심각한 문제가 있다는 신호입니다. 사실은 대개의 소프트웨어 회사 들이 2~3점을 받고 있고, 심각한 도움을 필요로 하고 있습니다. Microsoft같은 회사는 12점 만점을 받고 있습니다.
당연한 이야기지만 이것들만으로 성공과 실패를 가를 수는 없습니다. 특히, 아무도 필요없는 제품을 굉장히 훌륭한 소프트웨어 팀이 만들고 있다면, 역시나 아무도 원하지 않을 것입니다. 반대로 이런 방식을 따르지 않는 명인들이 세상을 바꾸는 소프트웨어 를 만드는 경우로 생각할 수 있겠습니다. 그러나, 이 12가지 이외의 요소를 모두 동등하게 놓고 본다면, 이들만 제대로 한다면 지속적으로 좋은 결과를 내는 잘 훈련된 팀이 될 것입니다.

1. Source Control(소스 컨트롤)을 사용하십니까?
상용 소스 컨트롤 패키지들도 사용해보았고, 무료로 사용할 수 있는 CVS도 사용해보았습니다. CVS는 무료이기는 하지만 충분합니다. 그렇지만 소스 컨트롤이 없다면 프로그래머들을 조율하는 일이 상당히 피곤할 것입니다. 프로그래머들은 다른 사람들이 어떤 것을 했는지 알 수 있는 방법이 없습니다. 이를 사용하면 실수를 쉽게 롤백할 수 있습니다. 소스 컨트롤의 다른 장점은 소스코드 자체가 모든 프로그래머의 하드디스크에 체크아웃(check out)되어 있다는 것입니다. 소스 컨트롤을 사용하는 프로젝트에서 코드를 날렸다는 이야기를 들어본 적이 없습니다.

2. 한번에 빌드를 만들어낼 수 있습니까?
"최신의 소스로부터 몇단계를 거쳐서 완제품(shipping build)을 만들 수 있습니까?"라는 의미의 질문입니다. 잘 되어있는 팀인 경우라면 하나의 스크립트로 checkout부터 시작하여 각 소스를 리빌드(rebuild)하고 각 버젼, 언어, #ifdef같은 조건별로 실행파일을 만들어내어 마지막 CDROM 레이아웃, 다운로드할 수 있는 웹사이트를 만들어 내는 정도까지 되어 있을 수 있겠습니다.
만일 이 과정이 하나의 단계 이상을 거친다면, 여기서부터 에러가 발생할 확률이 생깁니다. 정해진 기일이 가까워질수록 "마지막" 버그를 수정하고 실행파일을 만드는 등을 위해 빠른 사이클을 필요로 할 것입니다. 코드를 컴파일하고 설치파일을 구성하는데에 20단계가 필요하다면 급박한 시간때문에 사소한 실수를 저지르게 될 것입니다.
필자가 마지막으로 근무했던 회사에서는 이런 이유로 WISE를 InstallShield(역자주 : 두 제품 모두 설치본을 만들기위한 도구 입니다.)로 교체하였습니다. 설치 과정을 스크립트를 통해서 NT 스케줄러로 밤새에 자동으로 실행하도록 하고자 하였는데, WISE는 스케줄러로 실행할 수 없던 이유입니다. (WISE의 친절한 분들이 최신 버젼에는 이것이 가능하다고 알려왔습니다.)

3. daily build(일별 빌드)를 만드십니까?
소스 컨트롤을 사용하다 보면 누군가가 빌드를 실패하게 만드는 코드를 체크인 할 수 있습니다. 예를 들면, 새로운 소스파일을 추가해서 그 사람의 컴퓨터에서는 잘 컴파일되지만, 이를 코드 레파지토리(repository)에는 추가를 하지 않았을 수 있습니다. 이 사람은 이를 잊고 만족한 상태에서 컴퓨터를 잠그고 집에 돌아갑니다. 그렇지만 이로 인해 다른사람들은 작업을 할 수 없게 되고 결국 찝찝하지만 결과없이 집으로 돌아갈 수 밖에 없습니다.
모르는 사이에 빌드를 실패하는 이런 컴파일 오류가 나지 않도록 daily build를 만들게 됩니다. 큰 팀에서는 이런 경우를 위해서 daily build를 매일 오후 - 점심시간등 - 에 합니다. 사람들은 점심시간 이전에 될 수 있는 한 많이 체크인을 합니다. 점심을 먹으로 갔다가 다시 돌아오면 빌드는 이루어져 있습니다. 빌드가 실패하면, 사람들은 빌드가 성공한 이전 소스로 작업을 하면 됩니다.
엑셀팀에서는 누군가 빌드를 깨면 벌칙으로 다른 사람이 다시 깰때까지 빌드를 관리하도록 벌칙을 주었습니다. 이는 빌드를 깨면 받는 벌칙으로써 뿐만 아니라 모든 이들이 돌아가면서 빌드를 관리할 수 있게하여, 어떻게 돌아가는 지를 익히게 하는 방법으로써도 좋았습니다.
daily build에 관해 더 자세히 아시려면 저의 기사 daily builds are your friend를 읽으십시오.

4. 버그 데이타베이스를 가지고 있습니까?
뭐라고 반박하셔도 확신합니다. 코드를 짜고 있다면 설령 혼자 짜더라도 정리된 버그 명세 데이타베이스를 가지고 있지 않다면 낮은 질의 코드로 제품을 출시할 것입니다. 많은 프로그래머들이 머리로 버그들을 모두 기억할 것이라고 생각합니다. 말도 안되는 이야기입니다. 제 경우에는 한번에 2~3개의 버그밖에 기억을 못하고, 다음날이 되거나 출시를 위해 급해지면 전부 잊어버리게 됩니다. 버그를 제대로 트래킹해야합니다.
버그 데이타베이스는 복잡할 수도 있고, 간단할 수도 있습니다. 최소한으로 갖추어야할 요소는 다음과 같습니다:
버그를 완벽하게 재현할 수 있는 과정
버그가 없었다면 이루어졌어야할 결과(동작)
버그로 인하여 생긴 결과(동작)
누가 이 버그에 할당되어 있는지
고쳐진 버그인지 아닌지
버그 데이타베이스를 사용하지 않는 이유가 제품들이 너무 복잡해서라면, 이것들을 포함한 5컬럼의 테이블을 만들어서 사용하기 시작하세요.
버그 트래킹에 관해 더 읽으려면, Painless Bug Tracking을 읽으세요.

5. 새로운 코드를 작성하기 전에 버그들을 잡습니까?
마이크로소프트 Windows용 Word의 첫 버젼은 죽음의 프로젝트였습니다. 끝이 없었습니다. 계속해서 스케줄을 펑크냈습니다. 팀 전체는 말도 안되는 시간동안 일했고, 계속해서 연기되고 또 연기되었습니다. 그 스트레스는 엄청났습니다. 빌어먹을 제품이 몇년 후에 출시되었을때, 마이크로소프트는 팀 전원을 Cancun으로 휴가보내고, 이 원인을 분석하기 시작했습니다.
그들이 깨닫게 된 것은 프로젝트 매니저들이 스케줄을 너무 강요하였기 때문에 프로그래머들은 코딩을 빨리 할 수 밖에 없었습니다. 게다가 버그를 고치는 단계는 스케줄에 아예 존재하지 않았습니다. 결과적으로 질이 아주 나쁜 코드를 만들게 되었습니다. 버그 갯수를 줄이려는 노력은 전혀 하지 않았습니다. 한 프로그래머는 텍스트의 높이를 계산하는 루틴 대신에 "return 12;"로 대체하여 버그 리포트로부터 이 값이 어떤 영향을 주었는지를 알고자 했습니다. 스케줄은 단지 버그일 수 밖에 없는 기능들을 모아 놓은 체크리스트였습니다. 나중에 이 상황을 "무한 결함 방식(infinite defects methodology)"이라고 이름지었습니다.
문제를 해결하기 위해서 마이크로소프트는 반대의 "무결함 방식(zero defects methodology)"라는 방식을 체택했습니다. 많은 프로그래머들은 경영진들의 명령에 의해서 버그 갯수를 줄일 수 있다고 생각했음직한 이 방식의 이름 탓에 이를 비웃었습니다. 하지만 실제로는 "무결함(zero defects)"이라는 이름은 주어진 시간에 가장 우선순위가 높은 것은 코딩하기전에 버그를 잡는 것이란 사실을 지칭하는 말이었습니다. 이유는 다음과 같습니다.
일반적으로 버그를 고치지 않고 방치하는 시간이 길어지면 길어질수록 고치는데 더 많은 시간과 금전이 요구된다는 것입니다.
예를 들면, 오타나 문법오류등은 컴파일러가 쉽게 잡아서 고치는데도 별로 문제가 되지 않습니다.
만일 버그가 처음 실행시에 발생하여 보이게 되면, 모든 코드가 머릿속게 생생하게 존재하기에 바로 고칠 수 있을 것입니다.
며칠전에 작성한 코드에서 버그를 찾게 되면 이를 고치기 위해 조금 시간이 더 걸릴 것입니다. 아마도 코드를 다시 보게 되면 대부분의 내용이 기억나고 적정한 시간내에 버그를 고칠 수 있을 것입니다.
하지만 몇달전에 작성한 코드에서 버그가 발견된다면 이미 그 코드에 관해서 많은 것이 이미 생각나지 않을 것이고, 고치기도 상대적으로 힘들 것입니다. 그때쯤 되면 다른 사람의 코드를 수정하고 있는 와중일지도 모르고, 그사람은 Aruba로 휴가를 떠나있을지도 모릅니다. 이렇게 된다면 버그를 고치는 것은 기술을 익히는 것같이 되어버릴 것입니다. 천천히 꼼꼼하게 그리고 주의 깊게 코드를 살펴봐야 하고, 물론 문제를 해결하는데에 얼마나 걸릴지 정확하게 판단하기 힘든 상황이 될 것입니다.
게다가 이미 출하된 코드에서 버그를 발견한다면, 이를 고치는데에 큰 대가를 치뤄야할지도 모를 것입니다.
이렇게 시간이 적게 들기 때문이라는 이유가 하나의 이유가 됩니다. 또다른 이유는 버그를 수정하는데 걸리는 시간을 예상하는 것보다는 새로운 코드를 작성하는데 걸리는 시간을 예상하기가 훨씬 쉽기 때문입니다. 예를 들면, 내가 당신에게 리스트를 소트하는 코드를 만드는데 얼마나 걸리냐고 물어본다면, 꽤 정확한 대답을 할 수 있을 것입니다. 그렇지만, 질문을 바꿔서 당신의 코드가 Internet Explorer 5.5만 설치되어있으면 동작하지 않는 버그를 고치는데 걸리는 시간을 묻는다면, 문제가 무엇인지도 모르는 상황이기 때문에 얼마나 걸릴지 추측하지도 못할 것입니다. 3일이 걸릴 수도 있을 것이고, 운좋으면 2분이 걸릴 수도 있을 것입니다.
이것이 의미하는 바는 고쳐야할 버그가 많이 존재하는 상태의 스케줄이라면 그 스케줄은 정확할 수가 없다는 것입니다. 그렇지만 이미 알고있는 버그들은 모두 고친 상태라면 그 스케줄은 상대적으로 상당히 정확하게 지킬 수 있는 스케줄일 것입니다.
버그 갯수를 0에 가깝게 하는 또하나의 좋은 점은 경쟁에서 훨씬 빠르게 대응할 수 있다는 것입니다. 어떤 프로그래머들은 이를 두고 제품을 바로 출하할 수 있는 항상 유지하는 것이라고 이야기합니다. 경쟁자가 고객들을 가로채갈만한 굉장히 좋은 기능을 새로 만들었다면 축척된 많은 버그를 수정할 필요없이 바로 이 기능을 추가할 수 있을 것입니다.

6. up-to-date(최신) 스케줄을 가지고 있습니까?
비즈니스에 당신의 코드가 조금이라도 중요한 부분이라면, 코드가 언제쯤 완성될 수 있는지를 아는 것 또한 중요하다는 것은 당연할 것입니다. 프로그래머들은 엉터리 스케줄을 만드는데 악명이 높습니다. "언젠가는 될꺼야!"하고 외칩니다.
불행하게도 그런 식으로는 해결할 수 있는것은 없습니다. 비즈니스에는 코드를 출하하기 전에 데모, 전시회, 광고등등 미리 많은 것들을 판단하여 결정해야합니다. 이를 할 수 있는 단 한가지 방법은 스케줄을 가지고 이를 계속해서 현실적으로 최신내용으로 유지하는 것입니다.
스케줄을 가져야하는 또다른 중요한 이유는 이를 통해서 어떤 기능이 필요한지를 결정하게끔 만들어준다는 것입니다. 때문에 어떤 기능이 덜 중요한지 결정해야하고 featuris 가 되기 전에 이들을 포기하도록 합니다.
스케줄을 관리하는 것이 어려울 필요는 없습니다. 제 글Painless Software Schedules 에 좋은 스케줄을 만드는 간단한 방법을 설명하였습니다.

7. spec(설계서)를 가지고 있습니까?
스펙을 만드는 것은 이빨을 쑤시는것과 같습니다: 모든 사람들이 좋다고 인정하지만, 아무도 하지 않습니다.
왜 그런 현상이 일어나는지는 정확히 모르겠습니다만, 아마도 프로그래머들이 문서를 만드는 것을 굉장히 싫어하는데에 기인하는 것 같습니다. 그 결과로, 프로그래머밖에 없는 집단에서 한가지 문제를 해결하고자 하면, 이들은 문서를 만들기 보다는 코드로 자신들의 의견을 표명하려 합니다. 스펙을 먼저 만들기보다는 차라리 코드를 짜서 보여주는 것을 택한다는 것입니다.
설계 단계에서 문제를 발견하면 몇줄을 고쳐서 이를 수정할 수 있습니다. 그렇지만 코드가 짜여진 상황이라면 이 문제를 수정하는 댓가는 감정적으로나(코드를 그냥 버리는 것을 좋아하는 사람은 없습니다) 시간적으로나 훨씬 높게 되고 더 힘든 작업이 되어버립니다. 스펙을 통해서 만들어지지 않은 소프트웨어는 대개 설계가 잘못되어 스케줄을 엉망으로 만들어놓습니다. Netscape에서도 이런 문제로 인해 브라우저의 초기 네개의 버젼이 너무 엉망이 되어 결국 관리자들이 멍청하게도 코드를 전부 버리고 다시 짜도록한 결정을 내려버리게 되는 상황이 벌어졌습니다. 거기다 한술 더 떠서 Mozilla에서 이런 실수를 다시 반복하여 겨우 Alpha 단계에 가는데 몇년이라는 시간이 걸리게 되었습니다.
필자의 지론은 이 문제는 프로그래머들이 문서를 작성하는데 거부감이 없도록 작문 강의를 듣도록 보내는 것으로 해결할 수 있다는 것입니다. 다른 해결책이라면 스펙같은 문서 작성에 능숙한 관리자를 두는 것입니다. 두 경우 모두 "스펙없는 코드는 금물"이라는 간단한 규칙을 따라야 할 것입니다.
저의 4부짜리 글에 스펙 작성하는 요령에 대해 이야기했습니다.

8. 프로그래머들이 조용한 작업환경을 가지고 있습니까?
지식 근로자에게 공간, 조용함, 프라이버시를 줌으로해서 많은 생산성 향상을 얻는다는 것은 이미 증명된 사실입니다. 소프트웨어 관리의 고전인 Peopleware에서는 이 생산성 향상에 대해 자세히 기술합니다.
문제는 여기에 있습니다. 지식 근로자는 "in the zone"상태라고도 하는 "flow"상태에 들어섬으로써 가장 최상의 상태가 되어 일에 완벽히 집중하고 외부에 개의치 않게 됩니다. 완벽한 집중으로 시간 가는 것을 잊고 좋은 결과를 내게 됩니다. 이때에 바로 대부분의 생산적인 일들을 처리하게 됩니다. 작가, 프로그래머, 과학자 그리고 심지어 농구선수들까지도 "in the zone"상태가 있음을 이야기할 것입니다.
문제는 "zone"으로 들어가는 것이 쉽지 않다는 것입니다. 측정해보면, 최상의 생산성으로 일을 하기 위해서는 평균 15분이 걸립니다. 하지만 어떤 경우에는 피곤하고 이미 많은 일을 한 상태에서 "zone"상태에 들어가지 못하고 다른 일을 하거나 웹서핑이나 테트리스로 시간을 허비하게 될 수도 있습니다.
또다른 문제는 "zone"상태에서 빠져나가는 것이 매우 쉽다는 것입니다. 잡음, 전화소리, 점심식사, 잠시 스타벅스에 5분간 갔다오는 것 그리고 특히 동료에 의한 방해등에 의해 바로 "zone"에서 빠져나가게 됩니다. 동료가 1분이라는 짧은 시간 동안이라도 질문을 하여 "zone"상태에서 빠져나간다면 다시 되돌아가기 위해서 30분이 넘는 시간이 걸려 전체 효율에 치명적인 영향을 미칠 수 있습니다. 카페인 가득한 닷컴 회사들이 좋아하는 합숙소같은 곳에 옆의 마케팅 부서에서 계속해서 오는 전화에 대고 소리지르는 그런 시끄러운 환경이라면 계속된 방해로 지식 근로자들의 생산성은 추락하여 "zone"상태에 절대 이르지 못할 수도 있습니다.
프로그래머들에게 있어서 특히 어렵습니다. 생산성은 단기적인 기억력으로 한번에 얼마나 많은 작은 세부사항들을 다루느냐에 달려있습니다. 어떠한 방해도 이런 세부사항들을 잊어버리게 할 수 있습니다. 일을 다시 재개하면 그것들을 다시 기억하지 못하여 (사용하던 지역변수나 검색 알고리즘을 만들던 중에 어디에서 멈줬었는지등) 다시 찾아보게 되고, 이로 인해 다시 속도가 붙을때까지 느려지게 됩니다.
직관적으로 계산해보면 다음과 같습니다. 만일 프로그래머가 단 1분이라도 방해를 받아서(명백한 근거에 의해) 15분의 생산성을 날려버린다고 합시다. 철수와 영희 두 프로그래머가 낮은 칸막이로 주욱 늘어선(a standard Dilbert veal-fattening farm) 열린 사각 파티션 옆자리에 앉아 있다고 합시다. 영희가 strcpy함수의 유니코드 버젼 이름을 잊었습니다. 30초면 찾아볼 수 있겠지만, 철수한테 물어보면 15초가 걸립니다. 그래서 바로 옆에 앉아 있는 철수에게 묻습니다. 철수는 산만해지고 - 영희의 15초를 아끼기 위해 - 15분을 낭비하게 됩니다.
이번에는 벽과 문으로 나뉘어진 별도의 사무실로 가정을 합시다. 여전히 영희는 함수를 기억하지 못합니다. 다시 찾아보는 것으로 30초를 보낼 수 있을 것이고 옆 방에 있는 철수에게 물어보기 위해서 (일반적인 프로그래머의 평균 물리적인 건강상태를 봐서는 쉽지 않은) 일어나서 걷는 것을 포함한 45초를 보낼 수 있을 것입니다. 결국 찾아보는 것을 선택하여 30초를 보내게 되지만 철수의 15분을 벌어주게 됩니다. 대단하죠!

9. 돈이 허락하는 한도내의 최고의 툴들을 사용하고 있습니까?
컴파일 되는 언어로 코드를 작성하는 것은 여전히 아무 PC에서 할 수 없는 것 중의 하나입니다. 컴파일을 하는데 몇초 이상 걸린다면 최상의 기종을 사용함으로써 시간을 절약할 수 있을 것입니다. 15초 이상 걸린다면 지루해서 그 시간동안 The Onion을 읽게 될 것이고 너무 재미있는 관계로 거기에 빠져 수시간의 생산성을 날려버릴 것입니다.
모니터 하나로 GUI코드를 디버깅한 것은 불가능하지는 않지만 고통스러운 작업입니다. GUI코드를 작성하고 있다면, 2대의 모니터로 훨씬 쉬운 작업을 할 수 있을 것입니다.
대개의 프로그래머들은 아이콘이나 툴바를 위해 비트맵을 수정해야하고 대부분의 프로그래머 역시 좋은 비트맵 에디터를 가지고 있지 않습니다. 마이크로소프트에서 기본적으로 제공하는 Paint 프로그램으로 비트맵을 수정하는 것은 웃긴 일이지만 대부분 이렇게 하고 있습니다.
필자의 가장 최근 직장에서 시스템 관리자가 계속해서 자동적으로 스팸을 보냈습니다. 이유인 즉슨 220MB이상의 하드드라이브를 사용하고 있다는 것이었습니다. 필자는 요즘 HD가격을 본다면 이 공간의 환산된 가격은 내가 이용하는 화장실 휴지보다 싸다는 것을 지적했습니다. 디렉토리를 정리하기 위해 10분을 허비하는 정도로도 큰 생산성 저하일 것입니다.
"최고의 개발팀은 절대 그들의 프로그래머들을 고문하지 않습니다!" 후진 제품으로 인한 작은 불편함이 쌓여서 프로그래머들이 불만에 찰 수도 있습니다. 그리고 그로 인한 불만에 찬 프로그래머는 비생산적인 프로그래머이기 쉬울 것입니다.
이런 것들을 모두 종합하면 프로그래머들은 최고/최신의 것들로 쉽게 매수된다는 뜻이 됩니다. 이는 높은 연봉을 주는 것보다는 훨씬 싼 방법일 것입니다!

10. 테스터들을 고용하고 있습니까?
팀이 최소한 2~3명의 프로그래머에게 테스팅만 전담하는 테스터가 할당되어 있지 않다면, 버그가 많은 제품을 출하하고 있거나 시간당 $100짜리 프로그래머에게 시간당 $30의 일을 시키는 낭비를 하고 있는 것입니다. 테스터를 고용하는 것이 낭비로 생각하는 것은 정말 잘못된 계산을 하고 있는 것이며, 많은 사람들이 이를 깨닫지 못하고 있는데에 놀랍니다.
이에 관해 더 자세히 알고자 한다면 Top Five (Wrong) Reasons You Don't Have Testers 를 읽으십시오.

11. 신입사원들은 면접때 코드를 직접 짜는 실기시험을 봅니까?
마법사를 고용하는데 그의 마법을 보지 않고 고용하시겠습니까? 당연히 그렇지 않겠죠.
결혼식에 요리사를 고용하는데 요리사가 만든 요리의 맛도 모르고 고용하시겠습니까? 그렇지 않을것입니다.(역자주: 실제로 결혼식장 요리사의 맛을 보는 비유는 우리나라에 맞지 않을 것 같네요. 이 문구의 뜻만 이해하세요)
하지만 현실에서는 매일 인상적인 이력서나 면접에서 맘에 든 이유로 고용하는 일들이 일어납니다. 혹은 ("CreateDialog()와 DialogBox()의 차이점은 무엇입니까")등의 문서만 보면 알 수 있는 사소한 질문으로 채용하기도 합니다. 프로그래머를 채용하는데 있어서 중요한 것은 그런 사소한 것들을 얼마나 많이 외웠느냐가 아니고 코드를 잘 작성할 수 있느냐입니다. 혹은 "아하!"류의 질문으로 채용하기도 합니다. "아하!"류의 질문이란 답을 알면 간단하지만 모르는 경우에는 절대 맞출 수 없는 질문을 이야기합니다.
제발 이런 방식을 그만 두십시오. 면접때 무얼해도 상관없지만 반드시 코드를 작성하도록 해야합니다.(더 많은 것을 알고 싶다면 Guerrilla Guide to Interviewing를 읽으십시오)

12. hallway usability testing(무작위 사용성 테스팅)을 하십니까?
무작위 사용성 테스트(hallway usability test)는 복도를 지나가는 다음 사람을 붙잡고 방금 짠 코드를 사용하게 하는 방식입니다. 5명에게 이 테스트를 한다면 95%의 사용성 문제에 대해 배울 수 있을 것입니다.
좋은 사용자 인터페이스 설계는 생각처럼 어려운 것이 아니고 사용자들이 당신의 제품을 구입하고 사용하게 하는데 있어서 절대적으로 중요합니다. 짧은 프로그래머 입문서로 UI 설계에 관해 필자가 쓴 무료 온라인 책을 읽어보실 수 있습니다.
하지만 사용자 인터페이스에서 제일 중요한 것은 많은 사람들에게 당신의 프로그램을 보여주면(5~6명이면 충분합니다) 제일 큰 문제점을 빠른 시간에 발견할 수 있다는 것입니다. Jakob Nielsen의 글에서 그 이유에 대한 설명을 찾을 수 있습니다. UI 설계 경험이 별로 없다고 하더라도 - 비용이 전혀 들지 않는 - 무작위 사용성 테스트를 한다면 당신의 UI는 훨씬 좋아질 것입니다.

Joel Test를 사용하는 4가지 방식
자신이 속한 소프트웨어 팀의 점수를 매기고 그것에 대해 언급할 수 있도록 결과에 대한 이유를 필자에게 알려주십시오.
프로그래머 팀의 관리자라면, 당신의 팀이 최대한 잘 운영될 수 있는지 확인할 수 있는 지표로 사용하십시오. 12점을 받기 시작하면 프로그래머들을 간섭없이 그냥 두고 비즈니스쪽 사람들이 그들을 간섭하지 못하게 하는데에 모든 시간을 할 수 있습니다.
프로그래머 일을 맡을지를 결정해야하는 상황이라면 그 팀의 친한 사람에게 이 테스트 결과가 어떤지를 물어보십시오. 결과 점수가 너무 낮다면 이를 고칠 수 있는 권한을 받을 것인지를 확인하십시오. 그렇지 않으면 불만과 스트레스에 빠질 것입니다.
프로그래밍 팀을 평가하여야 하는 투자자이거나 당신의 회사가 다른 소프트웨어 회사와 합병을 한다면 이 평가가 급한대로 괜찮은 지표가 될 것입니다.

소프트웨어 개발이 힘든 이유

2009-08-07T19:47:00.006+09:00

브룩스(Frederick P. Brooks, jr.) 에 의하면 ..소프트웨어 개발을 힘들게 하는 이유로 근본적인 문제 복잡성, 순응성, 변화성, 불가시성의 문제로 들었다. 이 문제를 해결하기는 힘들 것이라고 말했다.

이 중 가장 큰 두 문제는 불가시성과 변화성이다.

고객(사용자) 입장에서 소프트웨어 설계 자체가 보이지 않기 때문에 쉽게 여기고 잦은 요구사항 변경으로 인한 Changeabilty가 생겨 날 수 밖에 없다.그래서 프로토타입을 만들어 고객에게 피드백을 받으면서 요구 변경을 최대한 줄이겠다는게.. 한 방법이다..

위에 말도 맞는 말이다... UML, USECASE, Requirement Analysis등을 이용하여 고객과 의사소통이 가능하며 요구사항 변경을 최대한 줄일 수 있다.만약 이게 100% 가능하다면 고객과 의사소통이 100% 된다고 하면 소스를 크게 변경하는 요구는 없어 질 것인가...????

전혀 아니다. 소프트웨어 개발이 가장 힘든 이유는...

고객 조차 자신이 요구하는 사항이 무엇인지를 정확하게 모른다는 것이다...

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

"대한민국에는 소프트웨어가 없다"를 읽고

2009-08-07T19:36:00.008+09:00

" 한국의 비지니스에서는 하나의 공통점은 무형의 가치를 잘 인정하지 않으려고 하는 것이 그것이다. 자동차나 냉장고 같은 하드웨어는 제값을 받고 파는데 문제 없지만, 소프트웨어는 그 가치를 잘 인정하려고 하지 않는다. 하물며 대화나 하면서 자문을 해주는 것에는 돈을 지불하지도 않는다. "

이러한 특성 때문에, 한국에서는 제대로 된 소프트웨어를 만들기 힘들다. 그러나 구글과 네이버 같은 서비스 산업이 더욱 활성화 될것이다. 왜냐하면 구글이나 네이버는 사용자들이 자기가 직접 사용료를 지불하지 않기 때문에 본인이 돈을 지불하고 사용하고 있는지 모르기 때문이다.

"미국에서 소프트웨어를 구매할 때 보면 항상 유지보수 비용으로 연 15%가 더 붙는데, 제품을 구입하는 첫해부터 선불로 지불한다. 유지보수는 보험과 같다. 자동차 보험 안들고 있다가 사고 난후에 그때부터 보험들 테니 보험처리해 달라고 하면 누가 해주겠는가..보험들고 보험료 타먹지 못한다고 아까워하면 안된다."

그러나 한국은 다르다. 한국은 소프트웨어가 문제가 발생하면 그 때 유지보수를 신청하는 경우가 많이 있다. 유지보수의 가치를 제대로 모르기 때문이다. 1,2년에 한 두번 문제가 생길 것을 대비하여 돈을 지불하려는 기업은 없다.

후기
처음 읽을 때는 간단히 대한민국 소프트웨어의 사회적인 전반적인 내용만 언급하는 책인줄 알았다.그런데 읽다보니, 특히 중간관리자나 프로그래머에게 쓰는 글에는 조엘온 블로그 글과맞먹는 개발 노하우 및 경험이 쓰여져 있어서 너무 좋았고, 소프트웨어 업체 종사하는 사람이라면 개발자부터 경영자까지 꼭 읽어야 할 책이라고 본다.도서관에서 빌려서 읽은 책이지만 소장용으로 구매 할 생각이다.

2009년 4월 28일

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

"Professional 소프트웨어 개발"을 읽고

2009-08-07T19:32:00.006+09:00

반대하거나 논쟁하기 위해 독서하지 말라. 내용을 그대로 믿거나 화술의 밑천으로 삼기 위해 독서하지 말라. 다만 생각하고 생활하기 위해 읽어라. - 프란시스 베이컨 -

소프트웨어 = 캘리포니아 골드러쉬 캘리포니아 골드러시는 바위덩어리 속이 아니라 그저 강바닥에서 금이 발견되었다는 점에서 대단한 것이었다. 그것은 주석 냄비와 개척정신만 있다면 누구나 부자가 될 수 있다는 것을 의미햇다. 그러나 1849년 후반으로 가면서 쉽게 발견할 수 있었던 금은 이미 모두 발견 되었고, 그때부터는 하루 10시간 이상 찬 물속에서 땅을 파고, 씻고 옮겨야만 겨우 금을 캘 수 있었다. 1850년대 초반에는 채굴자가 혼자 일해서 수지 맞추는 것은 불가능한 일이 되었다. 다른 사람들과 기술의 도움이 필요해 진것이다. 이후, 채굴자들은 모임을 만들었고 그모임은 회사가 되었다. 소프트웨어도 골드 러쉬로 본다. 처음에는 한두명의 전형적인 골드러시 주인공으로 이름을 날리겠지만, 이후에는 쉽게 소프트웨어로 부자가 될 가능성은 희박하다. 처음 골드러쉬때에는 비정형화된 프로세스, 짧은 개발 기간, 적은 문서 작업, 말뿐인 품질 보증 즉 영웅중심의 소프트웨어 개발을 할 수 있을련지 모르지만, 지금은 그렇게하면 소프트웨어 개발은 실패할 수 밖에 없다.
-스티븐 맥코넬 -

나의 생각에 가장 큰 문제는 캘리포니아의 골드러시에는 사람들이 채굴자 혼자 일해서는 힘들다는 것은 바로 알수 있지만, 소프트웨어 골드러시에서는 그것을 깨닫기가 어렵다는 것이다. 초반의 골드러시 시기의 영웅 중심 소프트웨어 개발의 성공을 잊지 못하고 계속 명맥을 이어가는 이유도 이중 하나이다.

2009.06.02

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

드러난 빙산의 비밀 - 조엘온 소프트웨어

2009-08-07T19:26:00.004+09:00

조엘온 소프트웨어 25장

너무 공감되고 알아두면 좋을 듯한 내용이므로 글 올립니다.고객은 자신이 원하는 내용이 뭔지를 모릅니다. 고객이 자신이 원하는 내용이 뭔지를 알아내길 기대하지 마십시오.소프트웨어는 빙산과도 똑같습니다. 멋진 사용자 인터페이스는 작업의 5%만 차지합니다.그러나 고객은 5%의 인터페이스 가지고 모든 것을 평가 합니다...진짜 비밀 프로그래머만이 알고 있습니다.

핵심 원리 1
프로그래머가 아닌 사람에게 사용자 인터페이스의 90% 분량이 잘못된 화면을 보여주면 사람들은 전체 프로그램의 90%가 잘못 됐다고 생각합니다.

핵심 원리 2
프로그래머가 아닌 사람에게 사용자 인터페이스로 100% 무장한 화면을 보여주면, 프로그램이 거의 끝났다고 생각 할 것입니다. 화면에 보이니 "실제 기능 구현이 어려우면 얼마나 어렵겠어"라고 생각할 겁니다. 절대 프로젝트 초기에 사용자 인터페이스를 먼저 만들어 고객에게 보여주지 마십시오. 그러면 고객은 기능 구현시 아무일도 안하고 빈둥거린다고 생각 할 것입니다.

핵심 원리 3
프로그램을 평가를 받을때에는 외형에 신경써서 만드십시오. 그러면 더욱 실용적인 프로그램보다 더 좋은 평가를 받을 겁니다.

핵심 원리 4
고객에게 프로젝트를 승인 받어야 할 경우에는 그래픽 디자인 버젼을 몇개 더 만드 십시오. 치명적인 영향이 없는 디자인을 고객이 직접 하게 하여 고객 참여가 소중하다는 느낌을 들게 하십시오. 고객이 200번을 바꾼다 하더라도 설계에는 아무런 상관이 없으니..

핵심 원리 5
전시 할때는 100% 화면만 고려 하십시오. 전시회에서 보통 디자인을 보지 기능을 보는 사람은 거의 없을 겁니다.

위의 내용은 제가 임의적으로 해석하여 쓴 겁니다..실제 원문을 보실 분은 조엘온 소프트웨어 서적을 참고 하십시오

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

TCP/IP and OSI

2009-08-07T19:14:00.005+09:00

TCP/IP and OSI
프로토콜이란 무엇인가?
* 개체(어플리케이션 프로그램)와 다른 시스템과 통신이 가능하게 하는 것이다.
- 개체 – 파일 전송 패키지, 데이터베이스 관리 시스템, 전자 메일, 터미널
* 두 개체 사이에 통신을 하기 위한 규약
* Sytax, Semntics, Timing이 포함 된다.
왜 프로토콜 구조를 사용하는가?
* 데이터 통신은 복잡한 절차를 요구한다.
- 보내는 쪽은 데이터 path와 받는 쪽을 알아야 한다.
- 시스템들간의 준비를 위한 협약이 필요하다.
- 어플리케이션간의 준비를 위한 협약이 필요하다.
- 파일 포멧의 번역이 필요하다.
* 프로토콜 구조 : 통신기능을 수행하는 구조화된 모듈의 집합이다. = modular structure
Modular Approach
* 복잡한 업무들을 여러 업무로 쪼갠다.
* 각자 모듈은 각자의 특별한 업무를 맡는다.
* 통신
- 같은 시스템 안의 다른 모듈들 간에 통신
- 다른 시스템 안의 같은 모듈들 간에 통신
Advantages of Modularity
* 쉽게 어플리케이션 개발이 가능
* 네트워크는 모든 프로그램의 수정 없이 변경 가능
Three – Layer Model
* 분산된 데이터 통신에서 3개의 주 컴포넌트
- 네트워크, 컴퓨터, 어플리케이션
* 대응하는 레이어
- Network access layer, Transport layer, Application layer
Network Access Layer
* 컴퓨터와 네트워크 사이에 데이터 교환 관련
* Addressing, routing, prioritizing, 등 포함
* 네트워크는 다른 소프트웨어의 Network Access Layer를 요구한다.
Transport Layer
* 어플리케이션간의 신뢰성 있는 정보 전달
* 신뢰성을 제공하는 메커니즘 : 어플리케이션과 독립적
* Flow Control 과 Error checking 포함
Application Layer
* 다양한 유저 프로그램의 로직 포함
* 각자의 어플리케이션은 다른 소프트웨어의 Application Layer 요구한다.
Addressing
* 2가지 Addressing이 필요
- 컴퓨터들은 각자의 유일한 N/W address를 필요로 한다.
- 어플리케이션들은 각자의 유일한 address를 필요로 한다. Ex> Service access points, or ports
- 각 어플리케이션이 트랜스포트 레이어의 서비스에 개별적으로 접속하는 사실을 내포함
Data Transmission
* Application layer은 data block를 생성한다.
* Transport layer은 PDU(Protoco -Data Unit) 생성하여 헤더에 붙인다
- 도착지 SAP, 시퀀스 넘버, 에러-디텍션 코드
* Network layer는 다른 헤더를 붙인다
- 도착지 컴퓨터, facilities Ex> priority
Standardized Protocol Architectures
* 벤더는 그들의 제품을 더욱 마켓터블하게 만들 수 있다.(생산성 증대)
* 소비자는 다른 밴더의 제품을 상호 연동 할 수 있다.
* 2개의 protocol 표준
- TCP/IP : 널리 사용됨
- OSI : 많이 사용되지 않으나 모델링이나 개념을 학습하는데 유용하다
TCP/IP
* TCP/IP 프로토콜을 전송 제어
* DARPA 의해 개발
* No official protocol standard(공개된 프로토콜)
* 5 Layer
- Application , Host-to-Host(Transport), Internet, Network Access, Physical
TCP/IP Physical Layer
* DTE와 전송 매체 또는 네트워크 사이의 물리적 인터페이스
- 관심 - 매체의 특성, 자연 신호, 데이터 레이트
TCP/IP Network Access
* 공유된 네트워크에서 시스템간의 데이터 교환 (노드와 노드 사이)
* 호스트와 목적지의 어드레스를 활용
* 우선순위 전송이 사능
* 네트워크에 의존적
- Ex> X.25 vs Ethernet
* 소프트웨어랑 네트워크의 분리
TCP/IP Internet Layer
* 인터넷은 두개 또는 그 이상의 네트워크들간의 통신
* 인터넷 레이어는 Network Access layer와 유사하나 노드와 노드 사이보다 네트워크사이의 핸들링
* IP를 가지고 네트워크 라우팅
* 종단 시스템과 라우터에 구현 되어 있음
TCP/IP Transport Layer
* Host to Host Layer라고도 불림
* 어플리케이션간의 신뢰성 정보 교환 (어플리케이션의 성질과는 독립된 신뢰성 제공)
* 전송을 위해 TCP 프로토콜 사용
TCP/IP Application Layer
* 어플리케이션 별로 다양한 로직이 있음
* 어플리케이션 형태에 따라 모듈을 분리함
TCP & UDP
* 대부분 TCP/IP 어플리케이션에서는 Transport layer를 위하여 TCP를 사용
* TCP는 두 개체 간의 연결 시 플로우 체크 에러들을 제공,연결지향형
* UDP는 연결을 유지하지 않으며, 전달을 보장하지 않고, 순서도 없으며, 중복체크도 없다
IP and IPv6
* IP는 32비트 어드레스, IPv6는 128비트 어드레스
* IPv6로의 변경은 천천히 진행 될것이다.

TCP/IP Applications
* SMTP (Simple Mail Transfer Protocol)
- 기본적인 이메일, 호스트간의 메시지 전송하는 어플리케이션
* FTP (File Transfer Protocol)
- 한 시스템에서 다른 시스템으로 파일을 전송하는 어플리케이션
* Telnet
- 리모트 시스템에 터미널을 통하여 접속하는 어플리케이션
Internetworking
* 네트워크들의 상호 연결로써 주로 TCP/IP 사용
* 글로벌 인터넷은 가장 큰 인터네트워킹의 예이며, intranet과 extranet도 있다
Routers
* 독립적인 네트워크 상호 연결하는 장비
* 일반적이 필수 기능
- 네트워크 사이에 링크 제공
- 라우팅과 네트워크들 간의 데이터 전송 제공
- 네트워크 추가시 상위 레이어 변경을 할 필요 없다.
Router Issues
* 어드레싱 스키마
* 최고 패킷 사이즈
- Fragmentation : 어떤 망에 패킷들이 다른 망으로 전송되도록 더 작은 조각으로 나누어져댜 할지 모름
- 패킷의 최대 크기 예 : 이더넷 최대 1,500바이트, 프레임릴레이 최대 1,600바이트
* 인터페이스, 신뢰성
TCP Segment (TCP PDU)
* 소스포트(16비트), 데스티네이션포트(16비트)
* 시퀀스 넘버(32비트)
* Acknowledgment number(32비트)
* Header Length[Data Offset](4비트), Reserverd(6비트), Flag(6비트) : URG, ACK, PSH, RST, SYN, FIN, Window(16비트)
* Checksum(16비트), Urgent Pointer(16비트)
* Option(Variable), Padding
TCP Segment (UDP PDU)
* 소스포트(16비트), 데스티네이션포트(16비트)
* 세그먼트길이(16비트), 체크섬(16비트
IPv4 Header
* Version(4비트), Internet herader length(4비트), Type of Service(8비트), Tota -length(16비트)
* Identification(16비트), Flags(3비트), Fragment Offset(13비트)
* Time to Live(8비트), Protocol(8비트), Header Checksum(16비트)
* Source Address(32비트)
* Destination Address(32비트)
* Options(variable), Padding(variable)
Why Study OSI?
* 여전히 우수한 모델 => 프로토콜 구조를 개념화하고 이해하는데 있어서
* Key points: Modular, Hierarchical, 레이어간의 경계 = 인터페이스
OSI
* 개방 시스템의 상호 연결, ISO에서 개발
* 7개의 레이어
- Application, Presentation, Session, Transport, Network, Data link, Physical
OSI Lower Layers - Physical, Data Link, Network
OSI Physica -Layer
* 비트 전송, 하드웨어로 구현, 전기적 기계적 인터페이스
OSI Data Link Layer
* error-free, 신뢰성 있는 전송
* flow control, error correction
OSI Network Layer
* 네트워크를 통해 메시지 라우팅
* 스위칭 타입(virtua -circuit, packet),
* 네트워크 라우팅 ( 보통 패킷 스위칭 네트워크 사용)
OSI Upper Layers - Transport, Session, Presentation, Application
OSI Transport Layer
* 메세지를 나눔
* 커뮤니케이션 채널의 성능 모니터
* 전송에 필요한 가장 적합한 서비스 선택
OSI Session Layer
* 시스템 사이의 가상 커넥션
* log-on,패스워드 교환,log-off등을 관리
* 세션이 끝나면 커넥션 끊김
OSI Presentation Layer
* code 교환 및 형식 설정
* Ex> 파일 컨버젼 ASCII to EBDIC,
OSI Application Layer
* 엔드유저를 위한 네트워크 access 제공
* 유저 측에서 활용 가능

CoDeveloper의 저작물인 이 저작물은 크리에이티브 커먼즈 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용할 수 있습니다.

"한국형 클라우드" 첫걸음 뗀다

2009-08-07T18:26:00.004+09:00

정부, 국회, 산학연 등이 손잡고 한국형 클라우드 컴퓨팅 발전전략 마련을 위한 대규모 정책토론의 장을 마련한다. 한국형 클라우드 컴퓨팅 표준화 정책을 연구하는 ‘클라우드컴퓨팅포럼’도 본격 출범한다.　방송통신위원회는 7월 8일 서울 삼성동 코엑스 인터컨티넨탈 호텔에서 한국과학기술정보연구원(KISTI)·한국클라우드서비스협회·한국IT서비스산업협회·클라우드컴퓨팅포럼·전자신문 공동 주관으로 ‘더 클라우즈(The Clouds) 2009’ 콘퍼런스를 개최한다.　이날 행사에는 이용경, 박영아 국회의원이 직접 참석해 산학연 관계자들로부터 클라우드 컴퓨팅 발전에 관한 의견을 수렴하며, 방통위와 함께 행정안전부도 클라우드 컴퓨팅 정책을 발표한다. 　미국 선마이크로시스템스와 IBM 본사 임원 등 해외 전문가들도 방한해 ‘글로벌 IT 트렌드가 클라우드로 간다’ ‘미래 사회와 클라우드’라는 주제로 각각 기조연설을 갖는다.　클라우드 컴퓨팅이 IT업계의 새로운 화두로 떠오르면서 이른바 한국형 클라우드 전략 수립 요구가 대두된 가운데 정부, 국회, 산학연 전문가들이 함께 발전방향을 논의하는 자리는 이번이 처음이다.　그간 클라우드 컴퓨팅에 대한 관심이 높아졌지만 해외 기술에 초점이 맞춰진 나머지 국내 IT 인프라와 산업구도에 맞는 한국형 클라우드 연구가 미흡하다는 지적이 함께 제기돼 왔다.　이에 따라 이날 행사 말미에는 주요 참석자가 패널로 참여해 ‘K(한국형)-클라우드의 방향’을 주제로 공개토론회를 가질 예정이다.　더불어 K-클라우드의 첫 걸음인 국내 표준화 정책을 연구하는 ‘클라우드컴퓨팅포럼’ 출범식도 함께 열린다. KISTI와 차세대컴퓨팅산업협회 등이 참여하는 포럼은 국내외 클라우드 컴퓨팅 발전 동향 연구를 기반으로 한국형 클라우드에 적합한 표준화 정책 연구를 수행한다.　행사 대회장을 맡은 안문석 고려대 교수는 “클라우드 컴퓨팅이 ‘웹 2.0’ 이후 IT업계에서 가장 많은 관심을 모으고 있지만 그만큼 많은 혼선을 빚고 있는 상황”이라며 “더 클라우즈 콘퍼런스가 제 2의 디지털 혁명으로 불리며 차세대 IT서비스 산업 촉진에 기여할 것으로 기대되는 클라우드 컴퓨팅 발전의 초석이 될 것”이라고 말했다.

이호준기자 newlevel@etnews.co.kr

Cloud Computing

2009-08-07T17:22:00.001+09:00

2007년 인터넷의 핵심 키워드는 웹2.0이라 할 수 있습니다. 그럼 2008년의 핵심 키워드는 무엇이 될까요? 현재까지는 cloud computing이라고 생각합니다. 구글의 CEO인 에릭 슈미츠는 연초부터 구글 플랫폼을 중심으로 하는 cloud computing에 대해 자주 언급하고 있습니다.그럼 cloud computing은 무엇일까요?
웹2.0이라는 용어가 처음 나왔을 때에도 RIA, 집단지성 등 수많은 정의와 모호함이 있었습니다. cloud computing도 마찬가지 입니다. wikipedia에는 cloud computing을 다음과 같이 정의하고 있습니다.

Cloud computing is a new (circa late 2007) label for the subset of grid computing that includes utility computing and other approaches to the use of shared computing resources. Cloud computing is an alternative to having local servers or personal devices handling users' applications.

Grid computing, Utility computing, Distributed computing, SaaS(Software as a service), Network computing, 가상화 등에서 설명하고 있는 개념과도 비슷합니다. 그럼 cloud computing 이라는 용어가 이런 과거의 기술을 또 다른 미사어로 포장한 마케팅적인 단어일까요? 제 생각은 그렇지 않습니다. 앞에서 설명한 모든 개념을 포함하지만 조금은 다른 차원에서 접근이 필요한 단어라고 생각합니다.이번 칼럼에서 cloud computing을 플랫폼적인 관점에서 분석해보겠습니다. 플랫폼이라고 하는 것은 사용자 애플리케이션이 수행되는 하드웨어 구성과, 소프트웨어 아키텍처를 의미합니다. 우리가 가장 많이 사용하고 있는 플랫폼이 마이크로소프트의 윈도우 플랫폼입니다. 오피스 프로그램이나 포토샵 프로그램 실행을 위해 인텔 또는 AMD CPU가 장착된 x86 계열의 하드웨어가 필요하고 그 위에 Windows라는 소프트웨어 플랫폼이 필요합니다.
플랫폼이 틀려지면 애플리케이션도 다르게 만들어야 합니다. 예로 Windows환경에서 수행되는 프로그램을 수정하지 않고 Linux나 MacOS에서는 수행시킬 수는 없습니다. 최근 몇년 동안 또 다른 개념의 플랫폼이 등장하고 있습니다. 구글은 몇년전부터 지속적으로 웹브라우저를 사용자 애플리케이션이 수행되는 플랫폼으로 만들려는 시도를 계속하고 있습니다. 이미 몇개의 필수 프로그램은 웹브라우저 플랫폼 상에서 실행되고 있습니다. MS의 핵심 애플리케이션에 대응하는 gmail, Word, Excel등과 같은 google office(아직은 데스크탑 환경 수준에 많이 못 미치지만) 등이 있습니다.
cloud computing은 웹브라우저를 플랫폼으로 사용하고자 하는 시도의 연장선상에 있다고 생각합니다. 다만 사용자 애플리케이션이 실행되는 환경이 웹브라우저만 아니라 모든 디바이스로 확장될 뿐입니다. Network computing, ubiquitous computing 개념과 비슷합니다. 프로그램을 사용하는 최종 사용자 입장에서 프로그램이 실행되는 플랫폼은 웹브라우저 또는 다른 디바이스에서 제공하는 실행 환경이 됩니다. 하지만 그 프로그램을 만드는 개발자 입장에서는 어떨까요? 웹 프로그램과 마찬가지고 두 군데로 나누어집니다. 서버단에서 수행되는 부분과 사용자의 디바이스에서 수행되는 부분입니다. 사용자 디바이스에서의 플랫폼은 사용자 디바이스별로 제 각각일 것입니다. 물론 표준화된 브라우저를 탑재하면 동일한 플랫폼이 될 수도 있겠죠. 제가 관심을 가지는 부분은 서버 부분입니다. 브라우저에서 수행되는 포토샵, 워드, 엑셀, MP3 플레이어등 기존의 데스크탑 환경에서 수행되는 모든 프로그램을 웹 기반 만들어야 한다고 생각해보세요. 그럼 어떤 운영환경을 구성할까요?
웹서버, 애플리케이션 서버(Tomcat, IIS), DB(Oracel, MySQL 등), 파일시스템(NAS, SAN 등), 개발언어(JAVA, .NET, PHP 등) 등 많은 고려 사항이 있습니다. 개발이 완료된 다음 사용자에게 delivery는 어떻게 할까요? 웹 기반이니까 사용자 디바이스에 직접 설치할 필요는 없지만 서버 측에 많은 컴퓨팅 자원이 필요하게 됩니다. 오피스 계열의 프로그램의 경우 전세계 모든 PC 사용자를 대상으로 서비스 해야 하는 상황도 발생하게 됩니다. 어떤 경우는 몇몇 사용자들만 대상으로 할 수 있겠죠. 여기서 cloud computing의 필요성이 나타나게 됩니다.
데스크탑 기반의 애플리케이션이 아닌 웹 기반(서버에서 수행되는) 애플리케이션을 수행하기 위한 운영 플랫폼을 cloud computing이라고 볼 수 있습니다. 앞에서 설명한 웹 기반 오피스와 같은 제품을 사용자에게 delivery하기 위해서는 엄청나게 많은 스토리지와 컴퓨팅 자원이 필요하게 됩니다. 전 세계의 모든 회사원, 학생들로부터 문서 저장에 대한 요구와 철자검사 등과 같은 요청이 초당 수만/수십만 이상으로 발생하게 됩니다. 대부분의 회사에서 구축되어 있는 컴퓨팅 자원으로는 불가능한 일입니다. cloud computing을 주장하는 회사들을 보면 이런 규모의 컴퓨팅을 능력을 보유하고 있는 회사들입니다. MS, Google, Amazon, IBM 등입니다. 그 중에 Google이 가장 우수한 환경을 구성하고 있다고 생각합니다. Google은 이미 백만대 정도의 서버를 운영하고 있으며 전세계를 대상으로 하는 많은 서비스를 보유하고 있으며 사용하는 사용자 또는 최대 규모라 할 수 있습니다. 다음 그림은 제가 생각하는 앞으로 다가올 컴퓨팅 플랫폼에 대한 예상입니다.
cloud computing은 위의 그림에서와 같이 수많은 컴퓨터를 이용하여 거대한 스토리지와 컴퓨팅 자원을 제공하는 역할을 수행하게 됩니다. Google의 경우 Google File System, Bigtable, Chubby, Map&Reduce 등을 통해 이런 인프라를 이미 구성하였으며 수십만 ~ 수백만대의 서버를 운영하는 노하우도 이미 축적된 상태입니다. 이런 것들이 바로 MS가 가장 무서워하는 것입니다. 현재 MS와 Google은 서로 비즈니스 영역이 틀리지만 싸우고, 견제하는 것도 이런 이유때문입니다. MS가 Yahoo를 인수할려는 최근의 움직임도 최근 Yahoo가 Hadoop을 포함한 Google 인프라에 필적할 만한 것을 만들어 가고 있는 것도 하나의 이유일 것입니다. wikipedia의 cloud computing에 대한 내용중 "See Also" 부분에는 다음과 같은 목록이 있습니다.
그러면 기업의 컴퓨팅 환경을 생각해 봅시다. Google 오피스를 사용하고 gmail을 이용하여 회사내의 기밀 문서를 보관, 전송할 수 있을까요? 물론 작은 기업은 충분히 그럴수 있지만 어느 정도 규모가 있는 회사는 절대로 인터넷 기반 애플리케이션을 사용하지 않을 겁니다. 그럼 기업 시장은 여전히 테스크탑 기반으로 남아 있을까요? 제 생각에는 인터넷 기반 컴퓨팅 플랫폼이 기업내 인트라넷의 핵심 플랫폼으로 구성되고 그 위에 이미 인터넷에서 실행되도록 만들어진 다양한 응용 프로그램들이 탑재되는 형태가 될 것입니다. 말 그대로 기업 내부적으로 소규모 환경이 구성되는 것입니다. 기업은 자신들이 주로 사용하는 응용 애플리케이션이 최적으로 돌아갈 수 있는 플랫폼을 선택하게 됩니다. 이것은 물론 일반 사용자도 동일합니다. 지금도 Linux 보다 Windows가 더 많이 사용되는 것도 같은 이유 때문이죠. 그렇게 되면 어떤 플랫폼이 더 많은 응용 애플리케이션을 제공하느냐가 기업의 선택 조건이 됩니다. Google 플랫폼이나 미래의 MS가 내놓을 인터넷 컴퓨팅 플랫폼 중에서 고민하겠죠. 너무 이상적인 모습인가요? Google 오피스가 현재의 데스크탑 오피스 수준의 기능을 제공하고 구글이 오피스를 만드는데 사용된 많은 컴포넌트를 SDK 형태로 제공하고 Google 내의 기본 서비스들을 쉽게 다른 응용 애플리케이션에서 사용할 수 있는 API를 제공하는 그 순간이 바로 이런 컴퓨팅 환경이 일반화 되는 시기일 것입니다. Google은 이미 Android, Search API, Chart API, Gadget API, Calendar API, Map API , Web Toolkit, Album API 등 많은 API를 오픈하여 제공하고 있습니다.미래의 컴퓨팅 플랫폼 시장을 장악하는 회사가 결국은 살아남게 될 것이고 그 가운데 cloud computing 이라는 개념이 핵심 기술로 사용될 것이며 결국 MS와 Google의 양분하는 형태로 갈 것이라는 예상을 해 봅니다.

또 한번의 중요한 변화의 시기에 우리는 과거와 같이 아무런 준비를 하고 있지 않습니다. 그저 변화가 끝난 다음에 그 변화에 적응할려는 모습만 있습니다. 소프트웨어 산업의 변방에서 중심으로 이동하기 위해서는 이런 변화에 적극적으로 참여하여 변화를 주도해야 합니다.오랜만에 쓰는 긴 칼럼이라서 무척 힘드네요. 몇번 정리한다고 마음만 먹고 못하고 있었는데 제대로 정리했는지 모르겠습니다. 앞에서 언급했듯이 cloud computing이라는 것이 아직 정의가 제대로 되지 않았기 때문에 많은 다른 의견이 존재할 것입니다. 새로운 의견 많이 제시해 주세요.