당분간의 시장은 단순히 기존 올드미디어에 대해 "종이를 대신하는 정도" 로만 쓰일 것이다.

나 자신이 만화를 그렸기 때문에 알 수 있는 일이지만, 기존의 올드미디어의 핵심을 담당하는 40대 작가들은 디지털 세대가 아니기 때문에, 현재 10대에서 30대 까지의 디지털 네이티브 세대들이 생각하는 것과는 틀리게 그 이전 작업이 상당히 느릴 것이다. 어쩌면... 아예 이전을 하지 못할 수도 있고...

수익을 발생시키는 중요한 기점이 될 "디바이스의 능력을 충분히 활용해서 재미를 만들어내는 작업방식의 변화" 와 "기존의 올드미디어가 가진 수익성의 빈약함" 은 돈이 되지 않음으로서 디지털을 구성하는 젊은 개발자들이 쉽사리 접근하는데 어려움을 만들어낼 수 있을듯 싶다.

말 그대로 돈이 되는 핵심 작가진들은 개발자의 접근이 많이 필요할 작업을 하지 않을테고, 젊은 작가진들은 개발자가 수익을 나누어 먹기엔 상당히 빈약한 수익성을 가지기에 어려움이 있다...

이 시장이 과연 어떻게 돌아갈 것인가? 라는데 약간의 의문이 생기고 있다. 이 시장의 승리자들에 개발자 등을 비롯한 디지털을 만들어내는 사람들이 나눠먹을 시장이 있을것인가? 라는데 약간의 회의가 들기도 하고... 아마, 이 시장이 의미하는 것은 거대한 유통 플랫폼을 가진 기업들의 포지셔닝 전쟁이 될 가능성이 높지 않을까 싶다. 추가적인 수익이 발생한다면 유통업자와 작가진의 수익분배가 될 가능성이 높다.

생각하는 것처럼 아이패드와 같은 디지털 페이퍼 디바이스들이 포화되어 수익성이 악화되고 있는 웹, 어플리케이션 시장의 대안이 되지는 않을 것 같다는 생각이 든다.

자세한 내용들을 쓰기엔 내용이 너무 방대하기 때문에 나중에 시간이 남으면 써보기로 하고... 작업 동안 경험했던 간단한 팁들을 안내해볼까 합니다.

1 . Font, Embed Font 의 표현

매우 필요했지만, 한글 폰트 자체의 용량 덕분에 쓰는 것이 주저되었던 Embed Font 의 사용환경이 TLF 에 들어서는 매우 좋아진 편입니다.

일단, Embed Font 의 용량자체가 상당히 줄었기 때문에 (이전에 약 7MB 짜리 폰트가 TLF 에서는 2MB 정도로 압축가능 하기 때문에) 독립적인 swf 로 분리해서 사이트 전체적으로 런타임 공유를 통해 사용한다면 크게 부담되지 않는 수준입니다.

다만, 여러개의 폰트들을 그룹으로 지정해서 1순위 폰트에 필드가 없을 경우, 다음 순위의 폰트에서 글자를 찾는 fontFamily 의 존재에도 불구하고 fontLookup 의 일방성 덕분인지 embedFont 에 없는 한자나 특수문자의 표현에는 무리가 있는 편이네요... embed font 에 없는 필드를 device font 로 대체할 수도 있지 않을까 싶긴 한데... 아직 방법은 찾지 못했습니다. (아니면, 테스트에 사용한 나눔고딕에 한자 필드가 아예 없는게 아니라, 공백으로 넣어뒀을 가능성도 있겠군요...)

2 . ITextLayoutFormat, TextLayoutFormat

TLF 에서 사용하는 TextLyaoutFormat 은 크게 paragraph (문단) 의 모양을 조절하는 기능과 font 의 모양을 조절하는 기능 (FTE 에서 FontDescription) 과 글의 모양을 조절하는 기능 (FTE 에서 ElementFormat) 과 그 외, 몇가지 추가적인 기능들이 짬뽕되어 있는 포맷 형식 입니다.

이전에 사용하던 TextFormat 보다는 상당히 디테일한 지원을 해줍니다. 딱히 정리해서 설명하긴 어렵고, TLF 를 사용할때 모든 모양에 대한 조절을 원한다면 이 flashx.textLayout.formats.ITextLayoutFormat 을 살펴보면 됩니다.

다만, 링크에 대한 서식설정은 FlowElement 에 존재하는 linkNormalFormat, linkHoverFormat, linkActiveFormat 을 사용해야 합니다.

3 . 마법의 InlineGraphicsElement

TextFlow 상에 여러 그래픽스 오브젝트를 넣는데는 InlineGraphicsElement 가 사용되어질 수 있습니다. 이게 단순히 그림만을 지원하는 것이 아니기 때문에 원한다면 DisplayObject 를 상속받은 모든 그래픽스 오브젝트들을 TextFlow 상에 집어넣을 수 있다는 이야기가 됩니다.

제 경우에는 TLF 에 없는 html 의 <hr> 기능이나 <ol>, <ul> 등의 기능을 이 InlineGraphicsElement 를 통해 구현시켰죠. 원한다면 <table> 과 같은 고급 서식 기능을 만드는 것도 불가능하지 않다는 이야기가 됩니다. 그리고, <video> 기능을 문서 흐름속에 포함시킬 수도 있다는 이야기가 되겠죠...

InlineGraphicsElement.source 는 크게 세가지 정도를 줄 수 있는데, "image.png" 와 같은 String 형태의 uri 와 DisplayObject 로 인스턴스가 생성되는 class, 마지막으로 아싸리 DisplayObject 자체를 집어넣을 수 있습니다.

이 기능은 아직 저차원적인 수준의 지원만을 해주는 TLF 를 보다 강력한 문서표현이 가능하도록 확장시킬 수 있는 기반이 되어줍니다. 사용하기에 따라서 여러가지 것을 만들 수 있을 것 같네요.

이미지 uri 의 경우, ContainerController 에 문서 구현을 시켜주면 자동으로 로드처리를 해주는데 이때, StatusChangeEvent.INLINE_GRAPHIC_STATUS_CHANGE 이벤트를 감지해서 container update 를 시켜줘야 합니다.

그리고, InlineGraphicElement 에는 좀 특이한 버그(인지 아닌건지 잘 모를 에러)가 있는데, InlineGraphicElement 중에서 source 가 uri 로 지정된 녀석이 하나라도 있으면 Selection 시에 문제가 없는데, 아예 자체적으로 생성된 DisplayObject 나 Class 로만 source 가 구성된 녀석들만 있으면 Selelction focus 가 들어가는 순간 모든 그래픽스들이 removeChild 되어서 사라져버립니다... (ㅡ ㄴ ㅡ;;;) 이건 버그인건지 뭔지 잘 모르겠는데... 그런 문제들이 지속적으로 발생한다면 더미로 uri 로드를 하는 녀석을 하나 박아넣으면 해결이 됩니다.

4 . TLFTextField, ContainerController, TextLineFactory 의 선택

TLF 의 텍스트 표현에는 크게 세가지 정도의 선택이 있습니다.

일단, Interaction 이 전혀 되지 않는 순수하게 그림을 그리는 용도로 사용할 수 있는 TextLineFactory 기반의 기능들이 있습니다. 글자마다 서식이 다른 복잡한 녀석이라면 TextFlowTextLineFactory 를 사용할 수 있고, 서식이 하나로 통일된 단순한 녀석이라면 StringTextLineFactory 를 사용할 수 있습니다. 이 Factory 방식은 인터렉션이 필요하지 않은 아주 디스플레이용 글을 표현할 경우에 매우 유용합니다. 그리고, 무엇보다 이 Factory 방식에서는 truncation 기능 (긴 글의 마지막을 ... 으로 줄여주는 기능) 을 사용할 수 있기 때문에 굉장히 유용합니다. 주의할 점으론 TextLine 을 사용하고 난 뒤에는 수동으로 TextLineRecycler 를 통해 풀에 다시 집어넣어줘야 한다는 점 정도가 있겠네요.

그리고, ContainerController 나 좀 더 단순화된 TextContainerManager 는 좀 더 디테일한 기능의 조절이 가능합니다. 말 그대로 TextFlow 를 컨트롤하는 원천이기 때문에 Interaction 이 가능한 글을 만들려 할때는 가장 베이스가 되는 녀석입니다. 다만... 원천인 녀석답게 단순하게 쓰는데는 매우 편리하고 가볍지만, 복잡한 "쓰기", "스크롤" 기능들을 만들때는 매우 해야할게 많습니다. 특히나 쓰기에서 displayAsPassword 나 restrict 기능들이 하나도 구현되지 않은 정말 저수준의 녀석이기 때문에 시간이 넘쳐 흐르지 않는 이상 이 것으로 "쓰기" 기능을 구현하지 않는 것이 정신건강에 좋습니다.

마지막으로 Flash 에 포함되어 있는 TLFTextField 나 Flex SDK 에 포함된 input component 들이 있는데 쓰기 기능들을 구현하는데는 그냥 만들어져 있는 이 기능들을 사용하는게 좋습니다. TLFTextField 의 경우엔 좀 Class 가 정체를 알 수 없는 느낌으로 TextField 적인 api 와 TLF 의 api 가 짬뽕된 녀석이라 좀 거시기하지만... 정신의 평온을 위해선 이걸 쓰는 것을 추천합니다.

결론을 이야기 하자면

걍 디스플레이 용도의 간단한 텍스트 = TextLineFactory 계열
자유롭게 커스텀 할 수 있는 간단한 용도 = Controller 계열
쓰기 등 복잡한 처리가 필요한 폼 형식 = TLFTextField 등의 컴포넌트 계열

을 사용하면 될 것 같습니다.

사용법이 각각 계열마다 상당히 큰 차이가 나므로 익혀야 하는 api 수가 TextField 보다 많지만, 이래저래 성능 고려하거나 합리적으로 만들려고 할때는 도움이 많이 됩니다.

5 . TextFlow 의 후가공 처리

TextFlow 에는 getElementByID 와 getElementsByStyleName 이라는 두가지 메서드를 통해서 각 Element 를 불러오는 것이 가능합니다. 이 기능은 CSS 라는 일괄 서식지정 기능이 없는 TLF 에 도움이 많이 되고, 특히나 위에서 이야기한 InlineGraphicsElement 등을 사용하는데 도움이 많이 되는 편입니다.

getElementByStyleName 을 통해서 같은 스타일의 Element 들을 일괄적으로 모은 뒤에 서식지정을 한다거나 하는데 도움이 많이 됩니다.

6 . TextConverter, ITextExporter, ITextImporter

TLF 가 기존 TextField 보다 좋아진 점 대표적으로 꼽을 만한 것은 XML 형태의 전용 마크업 언어가 있다는 것인데요... 이를 통해서 서식이 지정된 텍스트를 저장하거나 읽어들이는 작업이 가능합니다.

다만, 마크업 언어 자체가 아직까지는 단순 서식 문서 정도만 지원하기 때문에 복잡한 처리를 위해서는 필연적으로 위에서 언급한 InlineGraphicElement 를 통해 확장시킬 필요가 있습니다.

제 경우에는 복잡한 쓰기 기능은 그냥 TLFTextField 를 사용하기로 했기 때문에 주로 flashx.textLayout.container 와 flashx.textLayout.conversion, flashx.textLayout.elements, flashx.textLayout.factory, flashx.textLayout.formats 만 보고 있습니다. flashx.textLayout.operations 나 flashx.textLayout.edit, flashx.textLayout.undo 의 경우엔 만지기 시작하니깐 사람 상당히 피곤하게 만드는 경향이 있어서 작업하다가 아예 포기해버렸습니다. 뭐... 혹시나 플래시로 위지윅 에디터 만들려는 사람들 아니라면 딱히 만질일이 별로 없는 부분이기도 합니다. 쓰기 부분을 피해서 알아보면 의외로 분량이 그다지 많지 않은 편입니다. 텍스트 엔진을 TLF 베이스로 바꾸고 싶으신 분들에겐 조금 참고가 되지 않을까 하네요...

그럼 이만~ 앙뇽~

한참 애플과 구글이 치고박고 하는 중에 조용히 뒷구녕으로 움직이는 MS 의 움직임이 심상치 않아 보였다. 슬쩍슬쩍 보이긴 했는데 애플과 구글에 너무 집중된 조명 탓에 그냥 저냥 스쳐지나갔었는데...

이번 새로운 라이브 에센셜즈를 계기로 얘네들이 뭔가 엄청난 대공사를 하고 있다는게 눈에 보이는 것 같다.

역사상 최강의 윈도우라고 부를만한 windows7 부터 시작해서, 아직 드러나진 않았지만 상당한 정리가 이루어진 windows phone7, 공상과학 영화에서나 봤던 xbox 키넥트, 아직은 좀 병신같지만 상당한 성능을 자랑하는 검색엔진 bing, 그리고, 이번 라이브 에센셜즈에 포함된 여러 서비스들 까지 포함해서...

격전끝에 모든 패를 다 꺼내보이고 있는 구글이나 애플과는 틀리게 MS 는 잠수동안 지금까지의 MS 기반을 뛰어넘는 더 엄청난 크기의 성을 쌓고 있다는 느낌이 든다. 너무 대공사라서 이게 건물인지 잘 모르겠을 정도로 거대한 공사같다...

MS 답지 않음이 서서히 MS 다움으로 변해가는 느낌이 든다. 과거의 "더럽게 불편하지만 모든게 다 윈도우이기 때문에 MS 를 썼던" MS 스러움을 부시기 위해 애플과 구글이 공성전을 하는 와중에 그 성 뒤에서는 새로운 MS 스러움이라는 새 성을 쌓고 있는듯 보인다. 시간이 지나 이 MS 스러움이 완성되면 과연 대권은 누구에게로 향하게 될까...

아이폰 OS 업데이트를 하면서 예전에 그려놓았던 그림들을 정리하다 보니 그런 느낌이 갑자기 들더라...

문득 내 컴퓨터에 열려있는 이클립스가 상당히 낯설어 보였다.

'나... 뭐하고 있는거지?'

그런 생각이 들었다. 정말 나 뭐하고 있는거지... 이젠 "나 만화 그렸어요... 그리고, 디자이너 였는데?" 하면 사람들이 어디 듣도보도 못한 동인지 만화나 그리다가 포토샵으로 그림 좀 자르고, 개발하는 건줄 안다... ㅡ ㄴ ㅡ;;;

그냥... 그렇다고...

정확히 국민학교 4학년 무렵부터 만화질을 시작했기 때문에 내 인생의 잠자는 시간을 뺀 2/3 가량은 책상에 앉아서 보냈다고 보면 된다. 책상에 앉아서 만화를 그렸고, 책상에 앉아서 글을 썼으며, 그것은 프로그래밍을 하고 있는 지금에까지 상큼하게 이어져오고 있다. (하루 죈종일 앉아서 일하는 직업의 대표주자이지...)

어릴때 보약을 물먹이듯 쳐먹였다는 나름 약물로 탄생한, 무려 20대 후반까지는 감기로 약국조차 가지 않았던 무적의 면역력을 가진 나의 육체는 그렇게 책상에 앉아서 썩어문드러져갔고, 그 중, 가장 크게 고장난 곳은 바로 책상에 앉아지내면 필연적으로 찾아오는 측만 (허리뼈 뒤틀림) 과 거북목 (목뼈 뒤틀림) 이었다.

바늘로 찌르는 듯한 목과 허리의 고통은 장난이라 말하기엔 상당히 끔찍한 것이어서, 카이로 프랙틱이다 한의원이다 정형외과다 해서 병원비로만 거의 수백에 가까운 돈을 꼴아박고, 의자조차 나름 중고가에 해당하는 녀석들을 사서 앉았었다. 듀오백과 메시 의자를 거쳐 찾아낸 우리들체어 라는 등받이가 없는 특이한 형태의 의자에 관심을 보이지 않을 수가 없었다.

이놈의 우리들체어 라는 것이 "발톱깍기 같은 것 조차 인터넷에서 검색하면 어지간하면 사용기가 있는" 보통의 제품들과 달리 검색을 졸라게 해도 드럽다 싶을 정도로 사용기가 없었다. 딱 하나... 그것도 구입을 결정하기엔 좀 부족한 글 하나가 전부였다. 그래서, 결국 대전에 있는 매장을 직접 찾아가서 앉아보았다. 사실 의자라는게 왠만큼 앉아보고 경험해보지 않으면 알 수 없는 것이기 때문에 단순히 매장에서 앉아보는 것 만으로는 부족했지만... 젠장... 베타테스터가 된다고 생각하고 그냥 질러버렸다.

허리와 목이 안아픈가?

일단... 아프다. 한가지 먼저 이야기를 하자면... 이 의자를 포함 좋다는 의자들을 사용해 본 결과... 결국 사람이 앉아있다는게 문제다. 사람이 너무 오랫동안 앉아있으면 아픈게 당연한거구나... 라는 생각에 결론이 미친다. 뭘 해도 아프다. 결국 오래 앉아있으면 아프다.

어쩌면 인간의 육체는 앉아있는 것에 적합하지 않은 것일지도 모른다.

예방은 된다.

그럼에도 이 의자가 의미있는 한가지 점은 "편한 의자가 아니라는 것" 이다. 사실 생각해보면 허리와 목이 망가지는 주된 원인은 책상에 오래 앉아있다보니 몸이 근질거리고 쑤셔서 몸을 이리저리 아크로바틱한 형태로 틀어서 앉는 것에서 부터 시작된다.

대표적으로 책상에 다리를 올리고 뒤로 푹 기대고 있다던가, 다리를 꼬고 있다던가, 대표적인 pc 방 자세인 뒤로 눕다시피 앉아서 허리에 끔찍한 부담을 준다거나 하는 자세들이다...

이 의자는 일단 그런짓이 안된다. 뒤로 기댈 곳도 없으며 다리를 책상 위로 올릴 수도 없다. 적어도 아크로바틱한 자세로 인해서 허리와 목의 급격한 붕괴를 일으키지는 않는다.

다만... 그렇기 때문에 책상에 앉아서 주구장창 있으려 한다면 그다지 편한 의자가 아니다. 쉽게 말해 편한 늘어지는 자세를 취할 수 없다. 기껏해봐야 이 의자가 권장하는 앞으로 기댄 척추가 정상적으로 안쪽으로 휘어지는 형태가 아닌, 뒤로 약간 구부정하게 척추가 바깥쪽으로 휘어지는 정도다.

만일 학생이라거나 아직 허리와 목이 뽀개지지 않은 사람이라면 이 의자를 필수적으로 권장하고 싶다. 의자에서 아크로바틱 한 자세를 취할 수 없다는 것 만으로도 충분히 예방은 된다.

참고로 이 의자를 놓고나서 몸이 좀 뻐근하다 싶으면 그냥 누워서 쉬는 경우가 많아졌다. 몸이 뻐근하다고 편한 자세를 취할 수 있는 의자가 아니기 때문이다. 내가 생각하기엔 쉴땐 그냥 의자바깥에서 편하게 눕는게 낫다 싶다... 기존 의자는 그 뻐근한 상태에서 조차 편함을 추구할 구멍이 있기에 허리와 목의 부담이 증가되는 것 같다.

의자의 부족한 점들

일단 이 의자는 그럭저럭 인간이 의자에 앉아있을때 좋을 상당히 레퍼런스한 자세를 취하게 해준다. 허리를 안쪽으로 휘게 해주는데 도움을 주고, 팔을 댈 수 있기 때문에 목이 구부정하게 앞쪽으로 쳐지는 것 역시 방지해준다.

그럼에도 아직 몇가지 부족하다 싶은 점들이 있는데...

일단 팔을 기댈 수 있다는 팔걸이가 그냥 원형으로 돌아버린다. 도대체 이 기능은 왜 넣은건지 잘 모르겠다는 생각이 든다. 돌려서 뭘 맞추라는데 상식적으로

저 팔걸이를 빙글빙글 돌려서 뭘 체형에 맞게 맞추라는 건가... 팔걸이라면 오히려 위아래로 높낮이 조절이 되야 하지... 더군다나 약간만 돌려도 가슴, 배와 각도가 맞지 않기 때문에 돌려서 사용한다는 것은 무리다. 다시 조금 돌리면 팔을 걸칠 각도가 이상해진다. 돌릴 이유가 없는 것을 돌아가게 만들었다는 생각이 든다. 어짜피 돌리면 못쓴다.

그리고... 저 팔걸이의 기능이 가슴받이의 역할을 같이 한다고 되어있지만 높이가 낮아서 사실상 배받이다.

그리고, 이 의자가 허리를 안쪽으로 휘게 해주는데는 의자 뒷쪽에 있는 돌출부위가 엉덩이 (똥꾸멍쪽?) 을 밀어주기 때문인데 레퍼런스하게 앉는 것을 강제하고 싶었다면 이 부분을 좀 딱딱하게 만들어줬으면 어땠을까 싶다. 사실 좀 오래쓰면 왠지 이 돌출부위가 주저 앉는 것 같다.

뭐 그래도 쓸만한 의자...

아직 보완할 점들이 보이는 의자이긴 하지만... 어쨌든 허리가 아직 망가지지 않는 사람들의 예방차원 이라던가 아프더라도 증세를 악화시키지 않는데는 충분한 역할을 해주는 의자다.

"편하게 앉게 해주면서 동시에 안아프게 해주는" 의자는 아니다. 단지, "편하게 앉지 못하게 함으로서 안아프게 해주는" 의자는 된다. 그리고, 동시에 "좋은 자세로 앉았을때 불편함 없이 좀 더 오래 앉아있을 수 있는 의자는 된다. 팔걸이, 발받이... 좋다 싶은 자세를 오랫동안 유지할 수 있는 의자는 별로 많이 않다." 하지만... 그래도 오래 앉아있으면 불편하다. 아니, 애초에 그런 의자가 있을 수 있는건지도 궁금하고...;;;

이런 의자는 나같이 눈뜨자 마자 의자에 앉아서 잠자기 전에 의자에서 내려오는 장시간 앉아있는 직업을 가진 사람에게는 작지만 충분한 역할을 해준다.

앞으로 이 의자가 어떤 업그레이드를 한다면 괜히 쓰잘데기 없니 등받이다 뭐다 붙이지 말고, 그냥 "보다 레퍼런스한 자세를 유지하도록 더욱 더 강제시켜주면서, 그 부자유스러움 이라는 강제성을 기반으로 척추의 건강을 지켜주는" 형태로 발전시키는게 좋지 않을까 싶다.

척추전문 병원에서 만든 의자

이 의자는 일단 척추전문 병원에서 만든 독특한 이력을 가진 의자다.

하지만, 그런 이력에 걸맞지 않게 이 의자를 통해 어떤 이득을 얻을 수 있는지, 어떤 것이 내 척추의 붕괴를 막는데 도움이 되는지에 대한 자세한 "의료적 조언" 이라는 서비스가 곁들여지지 않았다는 생각이 든다. (얼마전에 부산 놀러갔다가 동래파전 먹으러 가는 길에 이 우리들 병원을 봤다... 의자를 산 뒤라서 새삼스러웠다...)

홈페이지 역시 이 의자가 어떤 색을 가지고, 어떤 재질을 가지고 하는 잡스러운 정보들 보다는 소홀하게 취급된 어떤 식으로 사용하는 것이 당신의 건강에 도움이 되는지에 대해 촛점을 맞추는게 좋지 않았을까 싶다. 왜 병원에서 만든 의자인데 의료적인 컨텐츠가 없나...

내가 이 의자를 사는데 많은 망설임을 가졌던 것은 "인터넷 검색을 통한 사용기에 대한 정보가 없어서 보다는, 이 의자가 건강에 도움이 될만한지에 대한 충분한 확신을 가질 수 없었기 때문이다..." 의료적 어드바이스가 충분했다면 그런 망설임을 걷어내는데 많은 도움이 되었으리라 본다.

사실 이 의자는 나름 "초장시간 의자에서 앉아 일하기 때문에 허리와 목에 고통을 느끼는" 사람들이 관심을 가질만한 의자이고, 그런 사람들은 왠만해서 통증에 대한 비용을 지불할 준비가 되어있다고 본다.

나 역시 허리와 목의 통증 때문에 병원을 전전하는 신세이다 보니 의사들과 이 의자를 샀고, 이 의자에 대한 의료적 조언을 구하고 싶을때가 있지만... 물어봐도 모를 것 같아서 그만두는 편이다.

이 의자를 만든곳이 병원 이라면 좀 더 디테일한 의료적 지원 서비스를 같이 곁들이는 것도 좋지 않을까 싶다. 장시간의 의자 생활에 의한 척추질환이 늘어나는 시점에서 의자에 앉아서 생활하는 것에 대한 생활추적과 정기적인 엑스레이등을 통한 척추상황에 대한 확인, 그에 따른 적당한 의료적 어드바이스가 곁들여진 토탈케어 시스템이 현재 많이 필요한 시점이지 않을까 싶다. (a/s 가 아니라 비지니스 형태는 틀리지만 애플케어와 같이 유료 지원서비스 지원도 충분히 고려해볼만 하지 않았을까 싶다.)

그런 서비스는 "필요하기에 비용을 지불하고라도 고마움을 느낄만한 서비스" 에 속한다. 그런 고통을 받는 나와 같은 사람들이 많기에... 단지 의자만 파는 것보다는 병원 이라는 시스템을 살려서 그런 예방에 대한 서비스를 같이 하는 것도 나쁘지 않다고 본다.

그 작업 중에서 가장 큰 문제를 일으킨 녀석은 다름아닌 애플 블루투스 키보드 였는데, 맥에서는 멀쩡히 되는 이놈이 윈도우에서는 아예 페어링 자체가 안되는 문제들이 발생했다.

해도해도 안되다가 클리앙의 도움을 받아서 해결을 보게 되었다.

1 . 우선 OSX 에서 기존에 키보드의 블루투스 페어링을 끊어줘야 한다. 주의 할 것은 그냥 "연결해제" 만 시켜주는 것이 아니라, 아예 블루투스 환경설정에서 삭제 시켜줘야 한다는 것이다.

2 . 이렇게 해놓고 윈도우로 들어가서 페어링을 해보면 정상적으로 페어링 진행이 되는 것을 확인할 수 있다.

3 . 다시 OSX 으로 돌아가서 블루투스 페어링을 시켜준다.

이런 순서로 하면 OSX 에서도 부트캠프 윈도우에서도 정상적으로 블루투스 키보드를 이용할 수 있다.

...

하지만... 이런 개삽질을 하게 된 애플 블루투스 키보드에 유감이 아주 많이 생기는 것은 어쩔 수 없다. 마우스도 키보드도 블루투스를 사용하고 있지만, 이놈의 블루투스 라는게 사람을 아주 잡는다 싶을 정도로 피곤하게 만드는 경우가 많다.

MS 의 아크마우스와 아크키보드가 왜 usb 수신기를 사용하는 원시적인 방법을 쓰는걸까 싶었는데... 아예 하드웨어적으로 연결처리를 하는 것이 훨신 깔끔하구나... 페어링 삽질 필요없이 그냥 꼽으면 되는것이 좋구나 싶다. 정말 어지간하면 블루투스 제품 보다는 그냥 무선 usb 장비를 사길 바란다고, 도시락 싸들고 다니면서 말하고 싶다.

왠만한 그래픽스를 addChild 를 안쓰고 몽땅 BitmapData 나 Graphics 로 처리하려고 하는 병에 어지간해서 자원들을 new 없이 pooling 시키거나 gc 걸리게 하는 것에 극도로 예민한 병에 걸린것 같다.

텍스트 처리 마저 자꾸 Bitmap 에 찍어버릴라는 짓을 하게 되어서 framework 설계에 상당한 부하가 걸리고 있다.

하지만... 대충 체크해보니깐 cpu 도 memory 도 별 차이 안남... ㅡ ㄴ ㅡ;;;

대책없이 아끼는 것도 좋지 않다는 깨달음에 도달하게 되었다. 코딱지 만큼 아낄라고 작업량을 두세배로 늘리는건 바보같은 짓인 것 같다고나 할까... (불편해지면서 까지 flash 로 만들 필요가 뭐 있나... 차라리 C 로 만들고 말지...)

일의 경중을 나눠서 정말 성능 딸려서 당췌 못쓸 지경이다 싶은 부분에 쓸 방법들과 큰 타격이 없기 때문에 좀 편하게 작업하는게 좋겠다 싶은 부분에 쓸 방법들을 분리해서 만들어야 겠다는 생각이 든다. 다만... gc 를 불러들일 수 있도록 자원을 해제시키는 구간은 좀 더 신경쓰고...

성능고려에 이것저것 지금껏 겪었던 많은 문제점들을 해결하기 위한 구조들을 새롭게 만들다보니 점점 flash 스러운 사용법에서 좀 멀어지는 듯도 싶다. 대신 성능이나 작업편의성은 올라가긴 하는 것 같고... 플래시의 기본적인 방식이 좀 뭐랄까... 그닥 좋지는 않은 방식인 것 같다...

이 내용을 보면서 여러가지 생각이 들더라...

현재 소프트웨어 시장이 나락으로 빠지는 이유가 과연 인재부족 때문일까? 내가 보기엔 아니다... 프리랜서로 여기저기 돌아다니면서 일하지만, 프로젝트 대부분이 삽질에서 태어나서 그 삽질의 뒷감당을 하다 끝난다.

최초에 삽질을 안하기 위해서는 "이 비지니스에 어떤 기술들을 사용해야 할 것인가?" 라는 명확한 타겟팅이 필요하다. 개발자를 꾸역꾸역 키우고, 꾸역꾸역 투입해서 어쩔건데... 막상, 프로젝트에 투입되는 노동력의 2/3 가량이 "그럴듯하게 있어보이게 만드는데 촛점을 둔 비현실적인 문서를 구현하는데 쓰이거나, 아니면, 뭘 해야할지 갈피를 못잡아서 이것저것 유행따라 찔러보는 식으로 만들어진 기획을 구현하는데 쓰이는" 삽질에 들어가는 것을...

명확한 타겟팅은 개발인력의 노동력을 가치라는 딴딴한 근육으로 만들어준다. 애플의 제품들이 그렇다. 애플 제품들을 보면 쉽게 느낄수 있는 것들이 "의외로 안되는게 드럽게 많다." 라는 것이다. 기본적인 디바이스 부터 시작해서 OS 까지 안되는게 드럽게 많다. 하지만, 명확한 타겟팅으로 제품에 투자되는 노동력이 가치로 뭉쳐져서 나오게 된다. 명확한 타겟팅 없이 개발자만 틀어박는 것은 돌맹이 깨부시겠다고 두부 100모 만드는 것과 비슷하다. (돌맹이 하나면 두부 100모 따위 곤죽으로 만들 수 있다. 그게 바로 아이폰이다...)

개발자의 기술을 가치있게 쓰지 못하는 기획력의 부족 위에서는 개발자를 백날 키워봤자 산업의 비곗살 밖에는 되지 않는다... 개발자의 노동력의 대부분이 가치없는 것에 투자되는 상황속에서는 아무리 난리를 쳐봤자 산업의 근육이 되지 않는다.

산업 전반적으로 키워야 할 인력이 어떤 것인지 잘 갈피를 못잡고 있는 것이 아닐까 싶다. 개발자의 기술력은 이미 차고 넘친다... 정말 필요한 신규 인력은 소프트웨어 비지니스에 있어 "소비자에게 무엇이 필요할지 찾아내는, 그것을 소프트웨어 적으로 어떻게 풀어내면 될 것인지를 파악해내는" 그런 인력이다.

애플이 파는 것은 구슬을 꿰어 만든 목걸이다. 애플의 제품엔 생각보다 많은 구슬이 들어가 있지 않다. 보다 우수한 개발자를 만들어서 경쟁력을 갖추겠다는 지금의 모습은 말 그대로 구슬 더 만들어야 한다고 호들갑 떠는 것과 같다. 구슬도 꿰어야 보배라는데... 꿸 놈이 없다는 이야기다.

말 그대로... 전문 기획자가 필요하다. 파워포인트 잡고 앉아 있다가 프린터기 앞에서 문서 나오길 기다리는 그런 인력이 아니라... 비지니스에 필요한 현실적인 소프트웨어 형태를 만들어내는 제대로된 기획자가 필요하다. (더불어 포토샵 잡고 그림 그리는게 다가 아닌 전문 디자이너도 필요하다.)

소프트웨어를 가치 있게 만드는 방법으로 아직까지 개발에게 답을 찾고 있다면 아직 갈 길을 찾지 못한 것일지도 모른다. 소프트웨어 경쟁력의 중요성은 이미 Code 를 떠난지 오래다... 그리고, 그 경쟁력을 만들어내는데 필요한 진짜 인력은 아직 황무지 상태고...

Mac 용 프로그램들은 종종 잡다한 유틸들을 모아서 세트로 저렴하게 팔때가 있는데, 의외로 알짜배기 들이 많아서 의외로 사용하다보면 어둠의 경로를 타지 않은 유료 프로그램들의 숫자가 늘어나는 편이다.

기회가 있을때마다 구입한 프로그램들이나 그 외에 이래저래 사용하는 잡다한 것들을 정리해보자면

MacJournal

그냥 메모하기 좋다.

블로그로 퍼블리싱도 되긴 하는데 쓸일이 별로 없다.

Ecto

블로그를 (그나마 멀쩡하게 쓸 수 있는) 프로그램 이긴 한데... 사실 무료인 Windows Live Writer 보다 후지다... 다만... 맥에선 이거 말고 쓸게 없다.

Things

GTD 방식의 TODO 관리 프로그램인데...

윈도우로 다시 갈아탈까? 하는 생각을 막아서는 유일한 어플... 윈도우에서 대체할 만한 녀석이 없다.

아이폰과 연동도 되는데, Wi-Fi 싱크를 시켜야 한다는게 상당히 불편하긴 하지만, 프로그램 자체가 가지는 간단함이 무척이나 매력적인 녀석... 개발일정에 Cloud Sync 기능이 Full Speed 로 개발중이라고 하니, 조만간 그 단점 역시 해결되지 않을까 싶다.

이녀석을 찾고 나서 번잡시러운 Trac 을 버렸다. (물론... 팀작업의 경우엔 얘기가 틀려지겠지만...)

Text Wrangler

윈도우로 치면 아크로 에디터에 해당하는 녀석... 무료다.

그냥저냥 쓸만한 수준...

Flow

FTP 프로그램... 상당히 깔끔하다. 소스코드 등을 간단하게 수정시킬 수 있는 기능도 들어있다.

HTTPScoop

http 패킷을 보는데 사용하는 녀석. 나쁘지 않은 수준이다.

Ripit

DVD 를 굽는데 사용하는 녀석이다. 뭐 기본 기능으로 구워도 되긴 하는데... 그냥 UI 자체가 무진장 심플한데다가, 예전에 무료로 구입한 패키지에 껴있는 녀석이라서 쓴다.

1Password

패스워드 관리 프로그램... 사파리, 크롬, 파이어폭스를 모두 지원한다.

Tweetie

트위터 클라이언트... 알림기능도 있고 해서 걍 쓴다. 광고가 붙은 무료버전도 있는데, 그냥 예전에 패키지를 구매하다 껴 있어서 어쩌다 유료버전으로 쓰게 된 녀석

뭐... 대충 딱히 맥 전용에, 쓸만한 녀석들은 이정도다. 이 중에서 "어머 이건 맥을 써야해~" 라고 할만한 녀석은 Things 말고는 존재하지 않고, 또, 그나마 방법을 내려고 하다보면 다 대체가능한 녀석들이다.

맥 어플은 그 갯수가 매우 부족하다. 그리고, 무료로 배포해서 장사가 될만큼 맥 시장 자체가 크지 않기 때문에 왠만한건 다 (자잘한 돈이지만) 유료다. 광고붙여 팔래도 뭐 쓰는 사람들이 많아야 그럴텐데 그렇지가 않다는게 문제...

하지만, 이런 "윈도우에도 있는 프로그램들" 이 (심지어는 무료로 널려있기도 한) 매우 단순하고, 별 시덥잖은 짓거리들을 하지 않아도 알아서 잘 굴러가는 Mac OS 에서 굴러간다는 상황을 가지면 그 파괴력은 상당히 높아진다.

그리고, 맥이라는 가시밭길 OS 를 사용하는 사람들의 특징은 대부분이 뭘 많이 하려는게 아니라, 몇가지의 것들을 편하게 하기 위해 사용하는 편이라는 특징이 있는데... 맥용 어플들은 그런 유저들의 특징에 맡게 제약적인 기능들을 가지더라도 굉장히 쉽게 쓸수 있는 형태를 가지는 녀석들이 많다. 이 룰에서 벗어나는 녀석들은 Adobe 나 Eclipse, Firefox 같은 크로스 플랫폼을 통해 넘어오는 녀석들이다. (심지어는 번잡시럽고, 드러운 사용성을 가지기 일쑤인 개발용 어플들 마저 맥용은 무지하게 간단한 UI 를 가지는 편이다...)

OS 자체도 잡스럽지 않은데, 사용자들의 요구 또한 잡스러운걸 싫어하는 사람들이 많고, 또 무료로 판매해서 광고수익을 챙길만한 여건도 안되고 그렇다고 클라우드 데이터의 클라이언트로 개발하기에도 마땅치 않아서 쓰잘데기 없는걸 집어넣지 않다보니... 맥의 사용환경은 전체적으로 무지하게 간단하게 컴퓨터를 사용할 수 있게 해준다.

말그대로 맥의 사용환경은 윈도우처럼 되는게 많지 않은대신... 잡스러운 것들이 별로 없다.

그런 특징들은 늘상 하는 것들은 무지하게 간단하게 할 수 있는 효율성을 주는 대신, 윈도우처럼 되는게 많지 않다는 단점역시 존재하게 한다.

즉... 맥이 아무리 쉽고 편한 OS 라고 지랄을 한다해도, 맥의 점유율이 높아 클라우드 데이터 클라이언트나 광고 같은 기능들이 따라붙는 어플들이 많고, 컴퓨터의 성능 역시 우후죽순인데다 사용자들이 너무 많아 이것저것 기능 넣어달라는 요청사항이 많아서 어플들이 복잡해질 일이 없기 때문에 맥의 사용성은 매우 쉽고 간단하다는 느낌이 든다.

맥 OSX 을 윈도우에서처럼 이것저것 커스터마이징 하려면 왠만해서 Unix console 띄어야 하는데...;;; 맥 OS 가 쉽다는 말은 구라다...

뭐랄까 아무리 좋은 풍경을 가진 숨겨진 관광지라도 TV 한 번 타고 유명해져서 사람들이 많이 유입되다보면 왠만해서 정동진 꼴 나기 마련이다. Mac의 쉽고 간단한 사용성은 사람이 적기에 요청사항들이 별로 없고, 그러다보니 그냥 "되는거나 좀 쉽게 되게 해줘..." 라는 요청들이 많은탓에 갖춰지는 것이 아닐까 싶다. OS 가 가진 기본적인 특징 역시 그러하지만... 그보다는 사용자들이 많고 다양한 요청들이 존재하기에 이것저것 잡탕이 되지 않아서 하나의 어플이 왠만해서 하나의 목적만을 해결해주는 특징이 생긴 바람에 벌어지는 현상이 더 크지 않나 싶다.

즉... 맥을 쓰다보면 자주 만나게 되는 윈도우와의 사이에서 딜레마가 간단하고 편하니깐 좋은데, 막상 딱 입맛에 맞는 녀석은 없다는 문제들이 존재하게 된다. 맥 쓰면서 입맛에 딱 맞는 프로그램을 찾으면 답이 없다... 그런 짓거리는 윈도우처럼 비슷한 어플들이 산처럼 쌓여있어서 그중에 골라써야 하는 OS 에서나 할짓이다... 맥 쓰면서 컴퓨터 환경에 대해 고민하는 사람은 그래서 바보다... 걍 주는대로 있는대로 쓰면 된다... (윈도우에서는 찾아 쓰지 않으면 정말 사람 미치게 하지만, 맥은 던져주는거 걍 쓰는게 제일 편하다...) 입맛에 맞는 어플찾아 삼만리 할거면 차라리 AppleScript 를 익혀서 처리하는게 더 빠르다.

https://chrome.google.com/extensions/detail/pabfempgigicdjjlccdgnbmeggkbjdhd

chreme stylist 익스텐션을 깔아준다.

옵션에서 styles 에

*{
font-family:NanumGothic, sans-serif !important;
font-family:NanumGothic, serif !important;
}

이와 같이 입력시켜준다. (폰트는 자기 취향대로)

익스텐션에 버그가 좀 있어서 Add New Style 로 입력한 스타일이 사라지게 된다. (정확히 말하자면 새로 입력한 마지막 스타일이 사라지는 버그인듯...) 이런 경우에는 Add New Style 을 통해서 입력하고자 하는 스타일을 입력해놓은 다음에, 다시 Add New Style 을 통해서 (대신 사라질) 스타일을 만들어주면, 입력한 스타일은 남아있고, 더미로 만든 스타일은 없어져버린다.

그러면 돋움이나 굴림으로 지정된 웹페이지와 맥의 만남이 빚어내는 대참사 대신 위와 같이 나눔고딕으로 깔끔하게 웹페이지들을 볼 수 있다.

같은 내용의 css 를 *.css 파일로 만든 다음에 safari 의 설정에서 고급으로 들어간 뒤에 스타일시트에 넣어주면 사파리에서도 나눔고딕의 웹페이지들을 볼 수 있다.

다만, 이렇게 사이트들을 보는데 익숙해졌다가 가끔 자기 홈페이지에 윈도우로 들어갔을때 보이는 대참사에 넋을 잃게되는 경우가 종종 생김... (지금 내 블로그가 아마도 그렇겠지...)