김군...

구글이 마이크로소프트(MS)의 웹브라우저인 ‘인터넷 익스플로러(IE) 6’ 버전 지원을 중단키로 하면서 국내 누리꾼들이 비상이 걸렸다. IE 6 사용자가 줄어들고 있는 외국과 달리 국내에선 여전히 IE 6 이용자 수가 많기 때문. 심지어 지난해 말부터는 다시 늘어나 누리꾼 절반 가까이가 IE 6를 쓰고 있는 실정이다.

■구글 “익스플로러 6, 3월부터 지원중단”

구글은 G메일과 구글 독스(Docs), 캘린더 등 자사 서비스가 오는 3월 1일부터 IE 6에 대한 지원을 중단할 예정이라고 지난달 30일(현지시간) 공지했다. 그간 구글은 유튜브와 자사 사이트들에서 익스플로러 사용자들에게 버전을 업그레이드할 것을 권고해 왔었다. IE 6가 웹표준을 지키지 않는데다 보안이 취약하다는 것이다.

그러나 구글이 아예 IE 6에 대한 배척에 나선 직접적인 계기는 최근 벌어진 중국에서의 해킹 사건 때문이다. 구글은 이날 공지를 통해 “최근 중국으로부터 브라우저의 취약점을 파고든 정교한 사이버 공격으로 문제가 발생했다”며 “향후 비슷한 사건의 방지를 위해서도 사용자들이 브라우저를 업그레이드할 것을 권장한다”고 밝혔다.
구글은 인터넷 익스플로러7 버전 이상, 파이어폭스 3.0 이상, 구글 크롬 4.0 이상, 애플 사파리 3.0 이상의 브라우저를 사용해 줄 것을 당부했다. 구글의 이런 조치에 앞서 프랑스와 독일은 자국민들에게 인터넷 익스플로러 사용을 자제하라고 권고한 바 있다.

■IE 6 사용비율, 세계 13%·국내 50%

IE 6는 2000년대 초반 돌풍을 일으킨 윈도XP 운영체제에 끼워 팔렸다. 그러나 뒤이어 나온 브라우저들에 비해 현저히 보안이 취약하고 웹표준을 지키지 않아 인터넷 환경을 악화시킨다는 지적을 받아 왔다. 심지어 제작사인 MS가 사용자들에게 익스플로러8 등 웹표준과 보안성을 강화한 제품으로 변경할 것을 권하고 있을 정도다.

이 때문에 IE 6에 대한 퇴출 운동은 그간 전세계적으로 진행돼 왔다. 해외에서 일어난 ‘IE 6 노모어(Nomore)’, ‘IE 6 머스트 다이(Must Die)’ 등의 캠페인에 이어 지난해 말엔 국내에서도 한 웹 개발자가 ‘익스플로러6 이제 그만’이라는 홈페이지(ie6nomore.kr)를 열고 100만명을 목표로 서명운동과 배너달기에 나서기도 했다.

그러나 이같은 캠페인으로 전세계 점유율은 지속적인 하락 추세를 그려왔지만 국내에서는 오히려 지난해 9월 이후 IE 6 사용자의 비율이 오르는 기현상이 벌어지고 있다. 시장조사기관 스탯카운터에 따르면 전세계 IE 6 이용자 비율은 지난해 1월 23%에서 올들어 13.4%로 꾸준히 감소했지만 국내 IE 6 이용자 비율은 지난해 9월 39%로 저점을 찍은 뒤 올 1월에는 50%로 다시 올랐다.

구글코리아 관계자는 “당장 IE 6로 구글 서비스를 이용하지 못하는 것은 아니나 앞으로 구글 서비스의 새로운 기능이 나와도 IE 6에서는 이를 사용하지 못할 가능성이 있다”며 “또 IE 6 사용으로 발생하는 버그를 수정하는 등의 지원책도 더 이상 제공되지 않을 것”이라고 설명했다. 이 관계자는 “국내 IE 6 이용자들도 버전을 업그레이드하거나 다른 브라우저를 이용할 것을 권장한다”고 덧붙였다.

[디자인 패턴]

=================================================================================

 디자인 패턴은 많은 프로그래머들이 성공적인 프로젝트에서 무수히 반복해 사용했던 문제 해결 기술을 발견해 정형화한 것이다.
 각 패턴은 특정 맥락의 문제를 효과적으로 해결할 수 있게 해주며, 패턴들은 해결하는

 문제의 맥락(GoF의 용어로는 Intent)이 다르다.

 분명 패턴을 잘 이해하고 사용하면, 수많은 개발자, 연구자들의 “아하(Aha)!” 경험을

 (그들이 들였던 노력에 비해서는) 손쉽게 사용할 수 있게 된다.
 하지만 패턴은 빈번히 발생하는 ‘특정’ 문제에 대해 적용할 수 있는 해결책이기
 때문에 객체들 간의 게임에 법칙에 관한 일반 룰까지 알려주지는 않는다.

 패턴이 좋은 게임의 규칙을 이용해 객체들의 관계를 맺고 있음은 분명하다
 (좋은 게임의 규칙을 사용하고 있지 않다면, 특정 문제에 대해서도 좋은 해결책이 나올 수 없다).
 그런데 이 때 패턴이 암묵적으로 사용하는 게임의 법칙을 모르면,
 패턴이란 고도의 게임 전술을 유용하게 구사할 수 없게 된다.
 패턴은 성공한 프로젝트 코드들에서 발견, 일반화되는 과정에서 코드에서
 디자인으로 추상화됐기 때문에 이들 다시 코드로 구체화하려면 패턴이 사용하는
 게임의 법칙을 알아야 한다.
 이를 모른다면 장님이 코끼리 다리 만지듯 패턴을 사용하게 될 위험이 있다.
 패턴을 사용해 프로그램을 만들었는데, 괜히 복잡해지기만 하던 걸? 글쎄….

 

===============================================================================================
[객체지향 설계의 원칙]
 
- 소프트웨어 설계 모델의 메타적인 원리가 디자인 패턴의 단위라고 한다면
  디자인 패턴에 등장하는 좋은 구조들에 대한 메타적인 원리가 (ISP, SRP, DIP, OCP, LSP)정도 된다.

=================================================================================================

 

- LSP::리스코프 치환 원리
  "서브 타입은 언제나 기반 타입으로 교체할 수 있어야 한다."
  상속은 구현 상속(extends 관계)이든 인터페이스 상속(implements 관계)이든
  궁극적으로는 다형성을 통한 확장성 획득을 목표로 한다.
  LSP 원칙도 역시 서브 클래스가 확장에 대한 인터페이스를 준수해야 함을 의미한다.
  다형성과 확장성을 극대화하려면 하위 클래스를 사용하는 것보다 상위의 클래스(인터페이스)를 이용하는 것이 좋다.

주의점::

 “서브 클래스에서는 기반 클래스의 사전 조건과 같거나 더 약한 수준에서 사전 조건을 대체할 수 있고,
   기반 클래스의 사후 조건과 같거나 더 강한 수준에서 사후 조건을 대체할 수 있다.”

=================================================================================================

 

- SRP::단일 책임 원리
  SRP는 하나의 클래스에 한 가지 책임을 가르치는 원칙이다.
  우리는 설계 관점에서 우리가 인식하지 못하는 SRP 위반을 자주 하게 된다.
  이 위반을 경계하기 위해 깊은 통찰력이 필요하지도 않다.
  단지 머리에 ‘책임’이란 단어를 상기하는 습관이면 된다. 

 

  적절한 책임 분배는 객체지향 원리들의 대전제 격인 OCP뿐 아니라 다른 원리들을 적용하는 기초가 되어준다

  설계자는 분리의 ‘크기(granularity)’를 고민한다.

  작은 단위로 섬세하게 사용할 수 있는 미세단위(fine-grained)로 구분할 것인가, 아니면 단순하지만

  입도가 큰(COARSE-GRAINED) 단위로 구분할 것인가에 대해서 말이다.
  이 문제의 경우 애플리케이션에서 문제 영역이 각각 서로 다른 케이스 바이 케이스로 이루어지기 때문에 명백히

  일관적으로 적용할 가이드라인을 제공하기 힘들다.

  하지만 그 기준은 대상에 대한 복잡도, 크기, 용도가 된다.
  복잡도가 높고 부피가 큰데 반해 그 용법이 단순하다면 COARSE-GRAINED가 적합하다.
  역으로 복잡도가 낮고 부피가 작으며 용법이 다양하다면 fine-grained가 적합하다.

 

 SRP 위반의 악취는
   -‘여러 원인에 의한 변경(divergent change)’
   -‘산탄총 수술(shotgun surgery)’
  을 들 수 있다.

 

  여러 원인에 의한 변경은 한 클래스를 여러 가지 다른 이유로 고칠 필요가 있을 때 발생한다.
  즉, 하나의 클래스에 여러 책임이 혼재하고 있어서 하나의 책임의 변화가 다른 책임에게 영향을 준다.

  산탄총 수술이란 하나의 책임이 여러 클래스에 분산되어 있기 때문에 발생한다.
  한 클래스가 너무 많은 책임을 맡고 있어도 곤란하지만,
  책임을 식별하지 못해 이를 담당할 클래스를 만들지 않고 여러 클래스에 흩뿌려 놓는 것 또한 문제가 있다.
  이는 보통 프로그램의 전체 책임을 올바로 분담하지 못해서 발생하게 된다.

 SRP를 적용하면 클래스의 숫자가 늘 수는 있다.
 하지만 클래스 숫자의 증가가 프로그램의 복잡도 증가와 비례하는 것은 아니다.
 오히려 SRP를 잘 따르는 프로그램은 적절한 책임 분배로 인해 클래스 숫자와
 프로그램의 복잡도가 반비례하는 경향이 있다고도 할 수 있게 된다.

====================================================================================================

 

- OCP::개방 폐쇄 원리
 소프트웨어 구성 요소(컴포넌트, 클래스, 모듈, 함수)는 확장에 대해서는 개방돼야 하지만
 변경에 대해서는 폐쇄되어야 한다고 말한다.
 변경을 위한 비용은 가능한 줄이고 확장을 위한 비용은 가능한 극대화해야 한다는 의미다.
 목적은 앞의 예처럼 객체간의 관계를 단순화해 복잡도를 줄이고, 확장·변경에 따른 충격을 줄이는 데 있다.

 

주의점::

 OCP에서 주의할 점은 확장되는 것과 변경되지 않는 모듈을 분리하는 과정에서 크기 조절에 실패하면 오히려
 관계가 더 복잡해져서 설계를 망치는 경우가 있다는 것이다.
 설계자의 좋은 자질 중 하나는 이런 크기 조절과 같은 갈등 상황을 잘 포착하여
 (아깝지만) 비장한 결단을 내릴 줄 아는 능력에 있다.

 모듈 영역에서 예측하지 못한 확장 타입을 만났을 때 인터페이스 변경하려는 안과 어댑터를 사용하려는

 안 사이에서 갈등하게 된다.
 위의 두 예에서처럼 변경의 충격이 적은 후자를 택하는 경우가 대부분이다.
 한 번 정해진 인터페이스는 시간이 갈수록 사용하는 모듈이 많아지기 때문에 바꾸는

 데 엄청난 출혈을 각오해야 한다.
 자바의 deprecated API가 대표적인 경우다.

 즉, 인터페이스는 가능하면 변경해서는 안 된다.
 따라서 인터페이스를 정의할 때 여러 경우의 수에 대한 고려와 예측이 필요하다.
 물론 과도한 예측은 불필요한 작업을 만들고 보통, 이 불필요한 작업의 양은 크기 마련이다.
 따라서 설계자는 적절한 수준의 예측 능력이 필요한데, 설계자에게 필요한 또 하나의 자질은 예지력이다.
 

 인터페이스 설계에서 적당한 추상화 레벨을 선택하는 것이 중요하다.
 우리는 추상화라는 개념에 '구체적이지 않은' 정도의 의미로 약간 느슨한 개념을 갖고 있다.
 그래디 부치(Grady Booch)에 의하면 ‘추상화란 다른 모든 종류의 객체로부터 식별될 수 있는
 객체의 본질적인 특징’이라고 정의하고 있다.
 즉, 이 '행위'에 대한 본질적인 정의를 통해 인터페이스를 식별해야 한다.

=====================================================================================================
High Cohesion, Loose Coupling::높은 응집도, 낮은 결합도
=====================================================================================================

 

낮은 응집도를 갖는 구조는 변경이나,확장 단계에서 많은 비용을 지불해야 하며 높은 결합도의 경우도 마찬가지이다.

응집도는 ‘하나의 클래스가 하나의 기능(책임)을 온전히 순도 높게 담당하고 있는 정도’를 의미하며
이들은 서로 조화될수록 그 구조는 단순해진다.

응집도가 높은 동네에서 내부 개체가 변했을 때 다른 개체에 충격을 주는 것은 오히려 당연한 징후이다.
이들은 하나의 책임아래 서로 유기적인 관계를 갖고 있기 때문에 내부 개체가 변했을 때 다른 개체의 변경 확률이 높아진다.
마치 예쁜 부츠를 사면 부츠에 어울리는 치마를 입어야 하듯이…

응집도의 종류는 다양한데 다음은 권장할 만한 순기능적 응집 관계들이다.

 

* 기능적 응집(Functional Cohesion)
일관된 기능들이 집합된 경우를 말하며 <그림 3>의 데이터 맵퍼는 DB 처리라는 기능 항목의 높은 응집성을 갖는다.

 

* 순차적 응집(Sequential Cohesion)
한 클래스 내에 등장하는 하나의 소작업(메쏘드)의 결과가 다음 소작업(메쏘드)의
입력으로 사용되는 관계(파이프라인 방식의 처리 체인 관계).

 

* 교환적 응집(Communicational Cohesion)
동일한 입력과 출력 자료를 제공하는 메쏘드들의 집합을 말하며,
팩토리 클래스는 전형적인 교환적 응집도가 높은 인터페이스를 갖는다.

 

* 절차적 응집(Procedural Cohesion)
순서적으로 처리되어야 하는 소작업(메쏘드)들이 그 순서에 의해 정렬되는 응집관계

 

* 시간적 응집(Temporal Cohesion)
시간의 흐름에 따라 작업 순서가 정렬되는 응집관계

 

* 논리적 응집(Logical Cohesion)
유사한 성격의 개체들이 모여 있을 경우를 말하며 java.io 클래스들의 경우가 대표적인 예이다.

 

이와 반해 결합도는 ‘클래스간의 서로 다른 책임들이 얽혀 있어서 상호의존도가 높은 정도’
를 의미하며 이들이 조합될수록 코드를 보기가 괴로워진다.
이유는 서로 다른 책임이 산만하고 복잡하게 얽혀있기 때문에 가독성이 떨어지고 유지보수가 곤란해지기 때문이다.
이유는 필요 없는 의존성에 있다.
마치 키보드의 자판 하나가 고장나도 키보드 전체를 바꿔야 하는 것처럼.
하나의 변경이 엄청난 민폐를 야기하는 관계이다.

다음은 수용할 수 있는 수준의 결합 관계들이다.

 

* 자료 결합(Data Coupling)
두 개 이상의 클래스가 매개변수에 의해서 결합 관계를 가지므로 낮은 수준의 결합도로 연관되는 경우

 

* 스탬프 결합(Stamp Coupling)
자료 결합의 경우에서 매개변수 일부만을 사용하는 경우

 

* 제어 결합 (Control Coupling)
두 클래스간의 제어 이동이 매개변수를 이용하여 사용되는 경우로 커맨드 패턴이 대표적인 사례이다.

구글이 크롬OS라는 새로운 운영체제를 발표했습니다. 구글이 지난 7월에 처음 크롬 OS의 존재를 이야기하면서 안드로이드와는 전혀 별개의 새로운 운영체제라고 하여 많은 사람들이 의아해 했습니다. 이미 안드로이드가 큰 이슈가 되며 채택되어가고 있는데 왜 구글은 전혀 별개의 새로운 운영체제를 개발하는지 두개가 상충되는 부분은 없는지 궁금해 했습니다. 안드로이드는 모바일폰에서부터 넷북까지 아우를 수 있는 플랫폼으로 알려져 있는데 새로운 넷북용 OS를 개발한다고 하니까요.

구글의 대답은 서로 다른 장치를 위한 서로 다른 운영체제라는 것이었습니다. 안드로이드는 작은 스크린 사이즈를 가지는 모바일 폰을 위주로 개발되었고, 크롬은 10인치 가량의 큰 스크린 사이즈를 가지는 넷북을 위해 적합하게 개발되어 서로 충돌하지 않는다고 했습니다. 하지만 크롬 OS가 공개되기전 이미 몇몇 PC 제조사들이 안드로이드 넷북을 개발하여 출시했습니다. 물론 구글이 말한대로 현재의 안드로이드는 작은 스크린 크기를 가지는 장치들에 적합하기 때문에 출시된 넷북들은 아직 쓸모있는 수준이 못되었습니다. 가능성만을 살짝 보여주었을 뿐이지요. 그래도 안드로이드 기반의 넷북 개발에 들어간 업체들은 크롬OS가 신경쓰일 수 밖에 없었습니다.

마침내 크롬OS가 공개되었고 그동안의 우려는 깨끗이 사라졌습니다. 크롬OS는 ‘웹브라우저가 OS였고 웹페이지가 애플리케이션’이었습니다.

새로운 형태의 애플리케이션 프레임워크나 API가 존재하는 운영체제가 아니었기에 충돌할 부분은 별로 없었습니다. 이 새로운 운영체제는 장기적으로 구글이 클라우드 컴퓨팅 시장으로 가고자 하는 비전을 명확히 보여주었습니다. 하지만 각광을 받고 있는 안드로이드와는 달리 당장은 틈새 시장을 위한 제품으로 윈도우즈와 인텔이 장악하고 있는 시장과 산업 구조에 큰 영향을 주기는 힘들것 같습니다. 하지만 앞으로는 어떨까요?

크롬OS를 공개할때 구글의 창업자인 세르게이 브린은 공식 발표 이후에 “안드로이드와 크롬OS는 시간이 지나며 서로 수렴하게 될 것이다”고 말을 했습니다. 이것은 폰이 점점 PC를 닮아가고 있고 PC가 점점 이동성과 연결성이 중요해지고 있다는 흐름과도 맞아 떨어집니다. 또한 두 프로젝트에 모두 리눅스와 웹킷(WebKit)이 사용되니 가능성은 충분하죠.

하지만 현재는 전혀 다른 두개의 프로젝트로 관리되고 있고 언제쯤 이 두개의 프로젝트가 합쳐질수 있을지, 기술적으로 가능할지, 뚜렷한 목표가 있는지에 대해서는 아직 알수가 없습니다. 언젠가 이 두개가 만났을때의 그 가능성에 대해서는 많은 기대와 상상을 하게 됩니다. 저는 안드로이드에 대해서 ‘모바일 컴퓨팅도 클라우드로 간다. 그 흐름에 가장 적합한 플랫폼이 안드로이드이며 남보다 앞장서 갈것이다”라고 항상 이야기를 하는데 그 길에서 크롬 OS와 만나게 될것 같습니다.

‘왜 애초에 하나의 궁극적인 플랫폼을 내놓지 않았는가’에 대해서는 웹에 기반한 구글의 소프트웨어 개발 방식이 잘 들어가 있다고도 볼 수 있습니다. 지구를 지배할 궁극의 플랫폼을 개발하는데는 5년이 걸릴지 10년이 걸릴지 모릅니다. 대신 일단 불완전하더라도 제품을 내어놓고 하나둘씩 발전시켜 나아가는 방식을 구글은 운영체제에도 적용하고 있네요. 구글맵이 처음 나왔을 때 웹에서 지도 정보를 검색하는 것 정도로 봤지, 지금 처럼 턴바이턴 내비게이션 회사들을 한방에 몰아세울지 생각도 못했습니다. 안드로이드와 크롬OS가 발전하여 하나가 되는 것은 먼 훗날일지 모르겠지만 큰 혁신이 될 것이라는 것은 짐작할 수 있습니다.

요즈음의 안드로이드로 돌아와보면, 안드로이드는 폰을 위한 플랫폼이라고 했는데 그 부분은 이제 상당 부분 완료가 되어가고 있습니다. 안드로이드는 단계적으로 다른 형태의 장치를 지원해가고 있는데 2.0 버전에서 나온 결과물을 봤을때 내년 안드로이드 3.0 에서는 공식적인 형태의 안드로이드 MID가 출현할 수 있을 것 같습니다. 루머에 의하면 다음 버전의 안드로이드는 국내 제조사와 작업하고 있다는 이야기도 있으니 더 기대가 됩니다.