Bookworm’s Archive 잡동사니 속에 숨겨진 보물 찾기

216/104

안드로이드의 개방과 자유가 낳은 호환성이란 독(毒)

안드로이드는 아이폰의 대항마로 개방과 자유의 상징처럼 이야기 됩니다. 아이폰의 일방적인 제약에 비해 안드로이드는 개방적이고 많은 업체들에게 자유롭습니다.

그러나 이런 개방과 자유는 호환성 문제를 일으킵니다. 벌써 국산 안드로이드 폰은 이런 문제를 일으키고 있습니다.  (주1)

이런 문제는 이번이 처음이 아닙니다. MS의 포켓피씨(PocketPC)와 윈도우 모바일(Windows Mobile)도 그러했습니다. 그나마 이 둘은 좀 나은 편이었습니다. 브루(BREW)나 위피(WIPI) 같은 것은 같은 플랫폼 개발사에서 개발하고, 같은 핸드폰 제조사에서 만들고, 같은 이동통신사에서 출시되었음에도 불구하고 모델에 따라 호환성 문제를 일으켰습니다.

물론 개방과 자유가 만들어내는 다양한 환경에서도 호환성을 높힐 수 있습니다. 예를 들자면 윈도우(Windows)와 같은 것 말입니다. 그러나 이런 다양성을 확보하기 위해서는 운영체계(OS)가 커질 수 밖에 없습니다. 운영체계가 커지는 것은 성능이 낮은 모바일 환경에서는 치명적일 수 있습니다. 바꿔말해 모바일용 운영체계는 스스로 호환성을 제공하는데 한계가 있다는 말입니다.

그렇기에 호환성을 핸드폰 제조사와 이동통신사가 만들어주어야 합니다. 그러나 현실은 그렇지 못 합니다. 왜냐하면 독점적인 지위를 통해 얻던 이익을 포기하기 쉽지 않기 때문입니다. 비호환성을 통해서 얻는 수익의 달콤함을 버리지 못 하는 것입니다.

그래서 MS도 윈도우 폰 7에서 아이폰과 같은 방식을 채택한 것으로 보입니다. 윈도우 폰 7은 아이폰과 달리 제조사에서 자체적으로 생산이 가능하나, 버튼의 갯수와 위치 하나까지 정한대로 따라야 합니다. 이렇게 함으로서 기존 윈도우 모바일이 가졌던 호환성과 성능 문제를 상당 부분 제거 할 수 있을 것입니다.

이렇게 개방적이고 자유로운 환경이 단점을 가지는데 비해, 폐쇄적 환경이 반드시 실패를 하는 것만도 아닙니다. 아이폰 보다 더 폐쇄적인 환경을 가진 게임기는 이미 20년 넘게 잘 팔리고 있습니다. 오히려 개방과 자유를 선택했던 아타리는 아타리 쇼크를 통해서 망하고 말았습니다. (주2)

구글도 이런 문제를 알고 넥서스 원이라는 레퍼런스를 통해 해결하려하는 것으로 보이나, 제조사와 이통사의 욕심을 뛰어넘기란 쉽지 않을 것 같습니다.

호환성 문제를 해결하기 위해 구글이 강력한 라이센스 규제를 통해 해결하려 나서야 할 것입니다.

독(毒)은 쓰기에 따라 약이 되기도 한다고 합니다. 개방과 자유가 낳은 호환성이란 독을 구글이 어떻게 약으로 쓸지 앞으로 지켜보려고 합니다.

주1) 국내 안드로이드폰의 호환성 문제 해결 되야 합니다.
주2) 아타리 쇼크 - 위키백과

305/100

최신 OS의 핵심은 검색

초기의 OS는 사용자에게 의존하는 방식이었습니다. 당시의 컴퓨터 성능을 고려 할 때 그 이상을 제공하기 힘들었을 겁니다. 프로그램을 하나를 실행하려고 해도 위치와 이름을 기억하고 있어야 했고, 동작을 변경시키려면 다양한 옵션을 외워야 했습니다.

그러던 것이 점차 컴퓨터 성능이 좋아지면서 사용자에게 선택지를 보여주고 그 중 하나를 고르는 방식으로 바뀌어 나갔습니다. 바탕 화면에 놓여있는 아이콘들이나 독(Dock)이 이런 예입니다.

그러나 점점 사용자가 설치하는 프로그램이나 파일의 개수가 많아지자 선택지를 보여주고 고르게 하는 방식을 사용하기 힘들어졌습니다. 그래서 현대의 OS는 검색을 강화하는 방향으로 나아가고 있습니다.

Mac OS를 시작으로 리눅스와 윈도우 7이 이런 경향을 뒤쫓고 있습니다. 윈도우 7에서 '윈도우 키'를 누르면 예전에는 시작 메뉴를 보여주었지만 지금은 검색창에 커서가 올라가는 것이 기본 동작으로 되어 있습니다.

최신의 OS를 사용하신다면 검색을 충분히 활용하여 보다 효율적으로 컴퓨터를 사용하실 수 있습니다.

105/100

티스토리용 플러그인 만들기

이번에 티스토리용 플러그인을 개발 할 기회가 있었습니다. 내부 개발은 완료했고 사내 QA와 약간의 소스 코드 정리 작업 후 다음에 전달 할 예정입니다.

티스토리 플러그인은 텍스트큐브와는 달리 사용자가 임의적으로 설치는 불가능하고 다음과의 업무 협의를 통해서만 등록이 가능합니다.

티스토리 플러그인 개발을 위해서는 텍스트큐브 1.5.x 버전을 기준으로 개발하면 되는데 티스토리와 텍스트큐브가 완전히 모양새가 일치하는 것은 아니어서 조금 어림잡아서 개발 할 수 밖에 없는 것 같습니다. 티스토리 개발 환경이 제대로 갖춰진다면 좀 더 쉽고 정확한 개발이 가능 할 것 같은데 앞으로 꼭 좀 나왔으면 좋겠습니다.

기본적으로 플러그인 개발은 텍스트큐브 플러그인 문서를 참고로 개발하면 됩니다. 다만 해당 문서의 버전이 다른 것인지 알 수 없으니 문서와는 좀 다르게 작성해야 하는 부분이 있었습니다.

문서에서는 tag나 listener의 핸들러를 속성으로 작성하라고 되어 있습니다. 이렇게 말이죠.

<binding>
<listener event="ViewPostContent"  handler="Helloworld_Show" />
</binding>

그런데 실제로 이렇게 속성으로 주니 잘 되지 않더군요. 저는 이렇게 해결을 했습니다.

<binding>
<listener event="ViewPostContent" >Helloworld_Show</listener>
</binding>

이것은 고유 URL을 생성하는 <listener>에도 동일하게 적용됩니다.

또 하나는 <adminMenu>에서 파라미터를 넘겨줄 때 <name>, <type> 외에 <default>도 필수로 적어주어야 값이 전달된다는 점입니다. <mandatory>는 필요한 경우에만 적어주고 나머지는 생략이 가능 합니다.

그리고 위키 문서에는 전역 변수에 대한 설명이 없는데, 이 설명은 TNF 포럼에서 볼 수 있습니다.

이번에 티스토리용 플러그인을 만들면서 느낀게 텍스트큐브의 플러그인 개발 관련 문서가 공식적인 문서라기 보다는 인터넷 강좌 정도라는 점이 좀 아쉬웠습니다. 결국 플러그인 개발을 위해서는 텍스트큐브의 소스 코드를 들여다보고 문서화 되지 않은(Undocumented) 변수나 함수를 이용해야 하는 경우가 생길 수 있을듯 합니다.

공식적인 문서인만큼 워드프레스 수준의 상세한 문서화가 앞으로 이루어졌으면 좋을 듯 합니다.