이전에는 왠만큼 긍정적인 느낌이 들었는데... 어느정도 사용하다 보니깐 체력이 고갈되었을때 자세가 흐트러져서 허리나 목이 아픈것은 다른 의자들과 크게 다르지 않다는 느낌이 든다.

우리들 체어에 필요한 기능이 있다면 일단 허리를 받쳐주는 기능이 필요하다고 본다. 엉덩이 뒷쪽 부분을 받쳐주는 것만으로는 허리를 피는 것을 강제하기가 힘들다.

우리들 체어를 사용하다가 자세가 늘어지게 되는 경우는 딱 한가지... 허리가 뒷쪽으로 굽게 되는 것이다. 이건 체력이 떨어지기 시작하면 자연스럽게 이루어지더라... 허리를 꼿꼿히 계속 피고 있는 것이 어느정도 작업에 몰입하다보면 힘들어진다. 결국 허리가 뒷쪽으로 빠지게 되면, 이전의 의자들과 크게 차이가 없는 자세가 되어버린다. 단지, 발받침과 팔걸이가 있어서 이전의 의자들 보다는 그럭저럭 괜찮은 자세를 유지할 수 있긴한데... 오십보 백보랄까...

뒷쪽에 등받침이 아닌 (이게 있으면 뒤로 기대서 자세가 다시 엉망이 되어버릴테니...) 허리 받침이 필요할 것 같다. 허리를 뒤로 빼려고 해도 안되도록 해야만, 좋은 자세를 강제적으로 유지시켜줄 수 있을 것 같다. 지금으로서는 자세에 신경을 곤두세워야만 좋은 자세가 유지가 된다. 하루 12시간을 넘게 의자에서 생활하는 사람으로서 그걸 유지한다는게 쉽지는 않다 솔직히...

나름 장시간 사용을 했는데 이전에 생각했던 것보다 점수가 좀 더 박해졌다는 느낌이다. 등이 뒤로 굽는 것을 해결하지 못한다면 다른 의자들과 결국 크게 다를바 없다는 느낌이 든다.

대충 web site out 기능을 만드는 중... 기본적인 원리는

http://ssen.name/docs/?id=67

이렇다...

아 졸라게 할 거 많다... 에러도 졸라 많고... 힘들어서 못해 쳐먹겠네... SQLite 에 Actionscript 에, PHP 에, CSS, Cross Browser 이슈들 까지 한꺼번에 덤비니깐 이 언어 하다, 저 언어하다 헷갈려 미쳐버릴 것 같다. AS 랑 JS 는 그럭저럭 비슷해서 할만한데, PHP 랑 같이 하니깐 뇌가 흔들흔들... AS 에다가 this-> 를 쓰고, PHP 에다가 $this. 를 쓰고...

대충 기본적인 web out 뼈대는 만들었기 때문에 이 기능들을 활용해서 기존의 내 홈페이지 구성들을 죄다 갈아치울 생각이다. 포트폴리오 데이터도 몽땅 옮겨놨기 때문에 옮기는데는 큰 무리가 없을듯...

문제는 IE 라는 이 빌어쳐먹을 브라우저인데... 다른 브라우저들하고 이 새끼만 차이가 나니... 아주 미쳐버릴 것 같다. 지금까지 한 작업들보다 이놈의 크로스 브라우저 맞추는게 더 짜증나...

아... 어쨌든 일단 뭐가 나오긴 나오는 시점이니 조금만 더 힘을 내자...

8개월 동안의 변화라면 정신줄을 확 놔버린 덕분에 몸무게가 무려 88kg 에 육박하고 있다는 것과 부대끼며 살던 서울생활의 스트레스가 사라짐으로 인해 흰머리가 거의 없어졌다는 것... 살찌고, 흰머리 없어지고, 정신적으로 꽤 편안한 상태가 되었다는 것 만으로도 대전생활에 의미가 있지 않을까 싶다.

간단한 알바 정도의 일들이나 좀 뛰면서 개인작업에 몰두 했더니 나름 끝이 보일 것 같지 않았던 framework 도 끝이 보이는 중이고, 무려 6년 정도나 끌어왔던 wiki 프로젝트 조차도 어설프게나마 첫삽을 성공적으로 떠놓은 상태다. (아직 보완해야 할 부분들이 많지만... 어쨌든 의도대로 돌아는 가는 상태니...)

물론... 이 지랄을 하는 동안 돈은 쭉쭉 나가서 통장에 천만원도 남지 않은 비참한 상태가 되어버렸고, 나름 액션스크립트로 탱자탱자 밥벌이 할 수 있었던 시절이 아이폰 한방으로 작살나는 덕분에 새로운 캐시카우를 찾아야 하는 난감함이 생겨버린 덕분에 "이제 나 뭐먹고 살아야 하나..." 라는 고민도 하곤 하지만...

그냥 보통 만들어준거 사용하는 framework 의 widget control 들을 바닥 코드부터 쌩으로 짜올려봤던 미친짓을 해본 경험이 있으니 뭐가 되든 되겠지... 라는 생각을 가지고 있다. 아마 기초 control 들 만으로도 충분히 쓸 수 있기에 전반적으로 UI 에 대한 원초적인 코드 접근이 없던 스마트폰과는 틀리게 태블릿 시장이 오면 내가 쌓아온 지식들이 유용해지지 않을까 생각된다. 당분간 플래시 개발로 버티면서 지금까지 했던 framework 삽질을 iOS 와 안드로이드에서 재현해보는 것으로 공부를 진행해보려 한다.

그리고... 삶... 이란 것에 대해서는 아무것도 모르겠다. 정답이 있다 믿는 것조차 아닌, 정답은 만들어나가는 것이라고 생각하며 무언가 치열하게 살았지만, 그 치열함이 그냥 발광일 뿐이었다는 생각도 가끔 든다. 내 인생의 젊은 시절이 불과 같음을 동경했다면, 지금은 조금 커다란 나무를 동경하고 있는 것도 같다. 뿌리를 깊게 내리고, 잔잔하게 살고 싶다.

기본적인 프로그램의 목적은

1. 위키언어를 통해서 프리젠테이션 양식과는 별도의 데이터를 구성한다.
2. HTML, Flash, mobile HTML 등 어떤 플랫폼을으로든 파서를 구현한다. (그래서 다른 위키 언어들에 비해서 심각하다 싶을 정도로 단순하다는게 문제...;;;)
3. 데이터는 하나의 폴더에 sqlite db 파일 하나와 첨부파일이 되는 폴더들로 구성되고, 이 데이터는 웹에 올린 다음 PHP 나 JSP 등의 서버 모듈과의 결합을 통해 보여질 수 있도록 한다.
4. ===plugin=== 문법을 통해 javascript, actionscript 등으로 위키 언어를 확장시킬 수 있다.

뭐 대충... 위의 것들을 합치면 지금까지 내가 경험했던 "아 썅! 이놈의 글들은 써놓으면 플래시에 올리기도 애매하고, 홈페이지 리뉴얼 할때마다 스타일 수정하느라고 졸라 피곤해!" 가 될 것 같다... ㅡ ㄴ ㅡ;;; 애초에 홈페이지 만들다가 글관리가 왜이리 빡센가... 라는 짜증으로 부터 시작한 글관리 프로그램 이니깐... 뭐...

어쨌든 글의 원론적인 데이터를 아주 단순한 위키 문법을 써서 관리하고, 위키 언어의 불편함을 극복시키기 위해서 전용 프로그램을 만들었고, 데이터는 sqlite + 첨부파일이라는 단순한 형태로 존재하기 때문에 뭘로든 결합시켜가지고 view 를 다양하게 만들 수 있다... 는게 이 프로그램의 목적...

원노트나 에버노트와 같은 프로그램들이나 블로그툴 같이 졸라 좋은 프로그램들 보다 쬐끔 좋은 점은 프리젠테이션 서식에 독립적이라는 점과 데이터가 단순해서 간단한 프로그래밍으로도 다양한 활용을 할 수 있다는게 아닐까 싶다. (그거 하나 바라보고 몇 달동안 이 개고생을 해서 만든거니... 원 글 관리하기가 이렇게 힘들어서야... ㅜ ㄴ ㅜ)

뭐 아무도 참여할 것 같진 않지만... 어쨌든 소스가 공개되어 있는 프로그램...

http://dev.naver.com/scm/viewvc.php/trunk/?root=ssen

최하단의 Button 부터 Scroll, ScrollPane, Selector 등 모든 기능들을 죄다 개인적으로 만든 framework 를 사용해서 만들었더만 시간이 무진장 오래 걸려버린 케이스 이긴 하지만, 만들면서 왠만한 컨트롤의 작동 구조를 파악했다는 자산은 남았다.

위키언어를 새로 만들어서 진행하고 있고, 아직 파서가 Javascript 용 밖엔 없는데, 컨텐츠들에 대한 이주가 다 끝나면 Flash 와 RSS, PHP 용으로도 새로 만들 생각이다.

막상 다 만들고 나니 내가 왜 이 개고생을 했는지 의문이 드는 프로그램이기도 한데... 어쨌든 만들긴 만들었다는...

AIR 로 만드는 중이고, 개인적으로 만든 framework 를 사용하고 있는 중이다.

원래는 web 쪽에 데이터를 두고, 데스크탑 관리자가 서비스를 호출해서 사용하는 방식을 할까 생각했었는데, 그냥 거꾸로 데스크탑 쪽에 데이터를 만들고, (sqlite 와 각 종 첨부파일들이 있는) 데이터 폴더를 ftp 로 올리면 php 가 해당 파일들을 읽어서 웹서비스가 되도록 하는 형태로 생각을 바꿨다.

대충 쓰고, 읽고 하는 부분들이랑 카테고리 관리자 까지는 만들었는데 자잘한 부분들이 아직 많이 남아있다.

이번달 안으로 어플리케이션을 완성시키고, 다음달 부터는 지금까지 내가 제작했던 모든 컨텐츠들을 이 stutter 기반으로 옮길 생각이다.

그다지 복잡하지 않은 프로그램인데 개인 framework 의 첫 적용 사례도 되는지라 framework 의 수정이랑도 겹쳐져서 작업시간이 꽤 걸리고 있다. 하여튼... 빨리 완성시켜야지...

과연 web 은 죽은걸까? 라는 이야기를 하기 이전에 중요한 것은 web 이 무엇인지 먼저 살펴볼 필요가 있지 않을까 싶다.

web 서비스를 분해해보면 그 요소들로 데이터와 HTML 이나 Flash 등 웹브라우저로 표현되는 프리젠테이션으로 나뉘어질 수 있지 않을까 싶다. 지금껏 web 서비스의 설계 라는 것은 이 두가지 요소가 밀접하게 결합되어 진행되어 왔기에 하나의 틀로 보였을 뿐이지, 사실상 jsp 나 asp, php 등 웹서버 서비스를 개발하는 개발자들은 "web 개발자" 라기 보다는 데이터 서비스의 원형을 개발하면서, 동시에 web 으로 프리젠테이션 되는 요소의 일부를 같이 개발하는 사람이었을 뿐이다.

web 대신 app 이 뜨고 있다는 배경에는 데이터 서비스의 프리젠테이션 요소로서 기존의 웹브라우저에 웹사이트 주소를 입력해서 보던 web 대신, 설치하는 app 이 사용되고 있다는 것이다.

그런 배경에는 몇가지 요소들이 작용을 하고 있다고 보는데

1 . 과거의 자잘한 사이트들이 난립하던 시대를 지나 트위터나 구글과 같은 거대 서비스 채널로 단순화 되고 있다
2 . 그로 인해서 web 이라는 이도저도 표현해야 하기 때문에 매우 "저수준의 표현능력 밖엔 갖추지 못했던" 프리젠테이션 채널 대신에, 아싸리 데이터에 최적화된 프리젠테이션을 보여줄 수 있는 app 이 선택되어 지고 있다는 것
3 . 채널이 단순화 되는데는 웹서비스 채널의 매스미디어화를 통한 "채널 선택권의 제한" 과 동시에 모바일과 같이 뭘 이것저것 하기엔 상당히 불편한 디바이스의 등장이 있을 수 있다.

대충 저런 이유들로 인해 사람들이 사용하는 웹서비스의 채널이 점차적으로 줄어들고, 그에 뒤따라 필연적으로 그런 서비스를 구지 "저급한 표현능력 밖엔 갖추지 못한 web 을 통해 보여주느니 차라리 app 으로 만들고 말지..." 라는 선택이 진행되어버리는데 있지 않을까 싶다.

이는 Flash 와도 연결이 될 수 있는 문제인데 이전까지 "저급한 표현능력" + "어플리케이션을 설치하게 되는데까지 걸리는 고생이 매우 높다" 라는 상황에서 표현능력의 증진을 위해서 Flash 가 사용되었던 시장 배경이 사라지고, 서비스 채널의 단순화와 앱스토어 시장의 활성화로 인해서 "사용하는 웹서비스 채널의 단순화로 인한 app 활용도의 강화" + "어플리케이션을 설치하는데 까지 큰 노력이 필요없다" 는 시장배경이 생겼다는 것을 의미한다. (즉... 사용되는 웹서비스 채널이 매스미디어 화 될 수록 플래시의 입지는 확연히 줄어들 가능성이 높고, 플래시의 죽음은 필연적이 되어버릴 수 있다.)

하지만, 프리젠테이션 채널이 단순히 웹브라우저에서 표현되는 html, flash 와 같은 기술에서 native app 으로 이동이 된다해서 web 이 죽은 것이다. 라는 이야기를 하기에는 무리가 있다고 본다. meta weblog api 와 같이 web url 을 기반으로 작동하는 api 서비스는 web 일까 아닐까? 라는 이야기가 되기도 하는 것이고...

앞으로의 서비스들은 지금까지의 웹서비스의 데이터 + 프리젠테이션의 결합도에서 벗어나서 데이터 서비스가 독립적으로 개발되고, web 은 그런 데이터 서비스를 2차적으로 활용하는 선으로 내려갈 가능성이 높다고 본다. 그러기 위해서는 데이터의 원형에 대한 정의내리는 표준안 역시 대대적으로 등장할 가능성이 높다고 본다.

현재 트위터 데이터 서비스 > 트위터 앱 서비스와 같이 직렬 연결을 가지는 서비스는 시간이 지나며 점차적으로 사라질 케이스가 될 것이라고 본다. 결과적으로 보자면 트위터, 버즈, 페이스북 > 데이터 서비스 표준 > 표준안을 수용하는 클라이언트 앱의 방향으로 갈 가능성이 높다고 본다. 뭐 서비스가 완전 윈도우처럼 완벽한 독점력을 가지는 서비스라면 특화된 클라이언트 기반이 될 가능성이 높지만, 사람들이 사용하는 서비스 플랫폼이 많아질 수록 데이터 표준안의 필요성은 더욱 더 커질 것이다. 트위터나 페이스북 같은 서비스들이 메신저와는 다른 면모를 가지는 이상 어쩔 수 없는 일이 될 것이다.

그리고, 만일 현재처럼 완벽한 독점력을 가지는 서비스들이 흐지부지 되고 이것저것 우후죽순의 서비스들이 늘어나기 시작한다면 app 기반의 데이터 소비는 사라지고, web 프리젠테이션 기반이 살아날 가능성이 높고...

app 과 web 의 차이는 단순하다. 데이터 서비스는 어짜피 뭘로 보든 상관없는 것이고... (하나나 보다 적은수의 서비스 채널에 특화된) app 과 (완전히 넓은 모든 서비스 채널을 포용할 수 있는) web 의 차이일 뿐이다.

이런 상황에서 사실 상 가장 득세할 사람들은 클라우드 데이터 서비스 개발자들이 아닐까 싶다. 아이폰 앱이다 안드로이드 앱이다 말들이 많지만, 그 모든 것들은 다양한 클라이언트과 서비스들의 판도변화에 빠르게 적응할 수 있는 포용력 있는 데이터 서비스를 개발할 수 있는가? 라는 데이터 서비스 개발자들의 능력이 돋보이게 될 가능성이 높다고 본다. 그리고, 가장 핵심에 가까운 분야일수록 벌이가 쏠쏠한 것 역시 사실이고... 클라이언트 개발자들이야 존나게 뛰는거지...

뭐... 생각은 있는데 쉽게 이야기 할 수 있는 주제가 아닌지라 삼천포로 빠지고 난리도 아닌데... 결론을 이야기 하자면

web 프리젠테이션은 전반적인 시장의 독점상황에 따라 죽거나 살 수 있는 문제이고, 현재의 흐름대로라면 html5 같은 기술은 시대착오적인 기술이 될 가능성이 높은 것이 사실이라는 것...

web 데이터 서비스는 현재의 web 프리젠테이션으로 직렬적으로 이어지던 기술의 흐름에서 벗어나서 점진적으로 open api 형태의 서비스로 변화될 가능성이 높다는 것... 여러 디바이스의 프리젠테이션을 포용할 수 없는 특정 프리젠테이션으로 직렬되는 서비스만 개발하는 서버 개발자들은 시대에 쓸려 떠내려갈 가능성이 높다는 것...

이런 상황에서 과연 web 은 죽은 것이라고 할 수 있는 것일까? 없는 것일까? 어느쪽에 포인트를 맞추느냐에 따라 틀릴 뿐이지, 결국 web 은 시대에 적응해 변화되는 것일뿐 web 의 사멸이라고 보기엔 무리가 있는 것일지 모른다.

그리고, 시대가 데이터 서비스의 병렬화와 특화된 클라이언트 app 들의 등장을 가르키는 것이 바로 "스페셜 리스트 + 폭넓은 이해력" 을 이야기 하는 것이라면, 이 상황에서 지금까지처럼 "이도 저도 전반적인 작업을 하는데 딱히 뭐라 하긴 힘든" 직렬적 서비스들을 개발하던 인력들은 시대의 청소대상이 될 가능성이 높을 것이다.

기본적으로 기술직은 "어떻게" 의 비중이 높은 편이다. 최하로 "그림을 그린다" 나 "코드를 짠다" 라는 "어떻게"가 받쳐주지 않으면 애초에 모든 것이 가능하지 않은 상태가 되어버리므로, 지식적인 면에서 "어떻게" 에 매달리게 되는것이 지금까지는 당연하다 싶은 상황이었다.

하지만, "어떻게" 만 파들어갈 수 있었던 배경에는 다른 요소들에 대한 분업화가 뒷받침 되었었는데, 그런 분업화의 배경에는 다시 "물리적인 제약성" 을 바탕으로 한 규칙성이 존재했다. 즉, 물리적으로 "어짜피 이렇게 만들 수 밖에 없기 때문에" 그런 일정한 약속을 바탕으로 한 분업화가 가능했다고 본다.

최근들어 IT 라는 "신이 내려준 물리적인 법칙" 이 아닌, "인간이 최저 단위부터 만들어가는" 배경이 생기면서 그런 약속들은 많이 무너져 내리고 있다고 본다. 내가 겪었던 많은 프로젝트들의 실패에는 "물리적인 약속의 붕괴" 로 인한 파트간의 부조화가 상당히 큰 몫을 했던 것 같다. 즉, 일정한 약속이 없는채로 분업화가 생기면서 각각 "어떻게" 에만 치중해온 파트들이 잘못된 "어떻게" 를 바탕으로 일을 하게 되고, 그 어그러짐이 합쳐지면서 요소들이 아귀가 안맞으면서 붕괴되었다는 것이 상당히 큰 이유가 되었었던 것 같다.

도저히 개발되기 힘든 달나라 떡방아 찧는 것 같은 상식 밖의 기획서와 작동에 대한 기초적인 상식도 없이 그냥 그려버린 디자인이 부실공사를 초래하고, 그 부실공사가 실제 구현단이 되어버리는 개발에서 붕괴되는 현상은 지금껏 실패했던 모든 프로젝트에서 공통적으로 존재했던 문제들이고, 그 비중이 상당히 컸다.

그리고, 그런 이전 파트 작업들의 붕괴는 다른 파트의 "어떻게" 에 대해 상식에만 의존하는 것에서 부터 시작되는 경향이 높다.

물리적인 약속이 무너지는 시점이 되면서 "어떻게" 에 집중되던 직업 개념엔 "왜" 와 "무엇을" 을 생각해야 하는 시점이 되었다고 본다. 작업단위가 그간 "왜 > 무엇을 > 어떻게 > 어떻게 > 어떻게..." 와 같이 "왜" 와 "무엇을" 을 계획단에서 정하고 그 이후로는 무작정 "어떻게" 만 반복하는 개념에서 "왜" 와 "무엇을" 을 모든 파트가 공유해야 하는 상황이 되었다고 본다.

"누가" 와 "언제" 와 "어디서" 라는 것은 아직까지 계획단에서 잡아도 될만한 문제이지만, 가장 원초적인 이유가 되는 "왜" 와 어떻게의 이전 단계가 되는 "무엇을" 을 기술적 지식이 없는 계획단에서만 잡는 것은 이젠 상당한 리스크를 지니게 된다고 본다.

시대상황에서 "분업화를 바탕으로 한 산업시대" 는 이미 종말을 맞이 했다고 본다. 그것은 "생산 경쟁력" 을 위주로 한 "어떻게" 에 대해 집중한 전문가 시대가 끝났다는 것을 의미한다고도 할 수 있을 것 같다. 시대가 원하는 "보다 창조적인" 것에 대한 집중은 전반적인 상황을 살피고, "어떻게" 를 판단할 수 있는 인력을 필요로 한다고 할까...

신이 내려준 물리적인 제약은 모바일과 네트워크를 통해 공간이 붕괴되고, 터치스크린을 통한 센서의 간접적 활용이 늘어나면서 점진적으로 인간이 만들어낸 디지털로 인해 사라질 것이다. 즉... 이전까지 (나름 창조라고 깝쳤지만 알고보면 무진장의 물리적 제약속에서) 만들어지던 모든 것들의 상식이 붕괴되고, 가장 원론적인 단계에서부터 작업되어야 하는 상황이 된다고 본다. 그런 상황에서 "어떻게" 라는 가장 노동력을 크게 잡아먹는 요소에 대한 집중은 결국 "실패" 를 "재작업" 함으로서 해결하려는 기존의 패턴을 "원론적인 단계" 에서 부터 반복해야 하기 때문에 끔찍한 실패를 만들어낼 수 밖에 없는 실패의 수식이 되어버린다.

즉, "누가", "무엇을", "언제", "어디서", "왜" 라는 요소들에 대한 파악은 실패의 리스크를 줄여줌으로서 "어떻게" 라는 비용이 큰 단계를 절약할 수 있게 해준다. 그리고, 이런 "어떻게" 이전 단계가 이루어지기 위해서는 자신의 "어떻게" 에 대해서만 파악하는 점적 기술인력이 아닌 주변지식을 깔고 있는 범위적 기술인력이 뒷받침 될때 가능하고...

대충 callback 구조로 변경을 하면서 multicallback 구조도 만드는 중인데, 그간 일방적인 수신구조를 가지던 event 구조에 대비해서 독점권 구조를 넣고 있다. 대단한 건 아니고, 그간 stage mousemove 와 같은 이벤트를 일방적인 수신을 함으로서 A 와 B 등의 다중 인스턴스들이 모두 이벤트를 강제로 받음으로서 발생하는 에러를 방지해보려는 것이 첫번째 목적이다.

var callbacks:Callbacks = new Callbacks();
var node1:SLLNode = callbacks.append(callback1);
var node2:SLLNode = callbacks.append(callback2);
var node3:SLLNode = callbacks.append(callback3);
callbacks.dispatch(); // 모든 callback 에 이벤트 전달
callbacks.monopoly(node1);
callbacks.dispatch(); // 독점권이 설정된 callback1 에만 이벤트 전달
callbacks.open();
callbacks.dispatch(); // 모든 callback 에 이벤트 전달

위와 같은 구조로 만들었다. 이로 인해 독점 이벤트가 발생해야 하는 일부 기능들에 대해서 비활성 상태에서 강제로 이벤트가 날아듦으로 인해 발생하던 에러를 원론적인 단계에서 거부할 수 있게 되었다.

문득 만들면서 이게 왠 삽질인가 싶은 느낌이 들고, 혹은 개발하기 졸라 불편하겠는데 싶기도 하지만... 뭐 불편하다 싶으면 다시 뒤집어 엎으면 되는거고... 인생 뭐 있나...

1 . 오토메이터를 연다
2 . 템플릿에서 응용프로그램을 선택한다
3 . AppleScript 실행을 작업에 추가한다
4 . Script 입력 창에 아래와 같이 입력한다

do shell script "
if ! test -e /Volumes/\"ramdisk\" ; then
diskutil erasevolume HFS+ \"ramdisk\" `hdiutil attach -nomount ram://4000000`
fi
"

대충 저게 2G 정도의 램디스크를 생성하게 되는데 취향에 맞게 조절해주면 된다.

5 . 저장을 하면 응용프로그램(.app) 으로 저장이 되게 되고, 실행시에 ramdisk 를 만들어주는 역할을 해주게 된다
6 . 환경설정 > 계정 > 자기 계정 > 로그인 항목에 만들어진 응용 프로그램을 등록해준다

이제 부팅, 로그인 할때마다 ramdisk 가 자동으로 만들어지게 된다.

그리고, 브라우저 캐시의 경우는 프로그램의 어떤 설정을 바꾼다기 보다는 Unix 의 "링크" 기능을 이용해서 캐시 디렉토리를 램디스크로 대체 링크 시키는 방법을 응용하는 것이다.

간단하게 설명을 하자면 보이는 com.apple.Safari 의 경우는 원래 하나의 폴더였지만, 저걸 램디스크가 대체할 수 있도록 만들어놓은 것...

위의 방법을 사용하기 위해서는 간단한 bash shell script 를 알 필요가 있다.

1 . 일단 위에 보이는 Caches 폴더에서 com.apple.Safari 폴더를 지워준다
2 . 일단 터미널을 연다
3 . cd /Users/자기 계정명/Library/Caches/ 를 입력해서 위 그림에 보이는 Caches 폴더로 이동한다
4 . ln -s /Volumes/ramdisk/ com.apple.Safari 를 입력해주면
5 . 위의 그림과 같이 가상본이 하나 생기는 것을 볼 수 있고

이제 사파리를 실행해보면 캐시들이 램디스크에 생기는 것을 확인할 수 있다.

뭐 동일한 방법으로 구글 크롬의 캐시 역시 교체해줄 수 있다. 구글 크롬의 캐시위치는 같은 캐시 폴더내에 Google/Chrome/Default 에 축적되는 것을 확인 할 수 있는데, 같은 방식으로 ln -s /Volumes/ramdisk Default 를 입력해주면

위와 같이 크롬의 캐시폴더가 램디스크로 링크되어 작동되는 것을 확인할 수 있다.

위와 같이 사파리와 크롬의 캐시가 ramdisk 로 대체되어 작동되게 된다.

데이터의 종류 중에서 "보존" 할 필요가 없는 캐시 데이터들의 경우엔 위와 같은 방식으로 몽땅 링크 시켜버림으로서 좀 더 빠르게 사용할 수 있다. 근데, 브라우저 캐시의 경우엔 "저장된 캐시" 를 읽어들이는 것이 아닌, "새롭게 다운로드" 받는것이 되어버리기 때문에 의외로 자주 방문하는 사이트들의 경우 최초 로딩때문에 더 느리게 느껴질 수 있다. 그리고, 애초에 사파리나 크롬의 경우엔 속도가 상당하기 때문에 체감적으로 뭔가 느껴지지도 않는 편이고... ㅡ ㄴ ㅡ;;; 그냥 디스크를 긁는 횟수를 방지한다는 점에서 의미가 있다.

그리고, 미친 방식 중에 하나로 위에서 언급한 링크의 경우 디렉토리로 링크된 경우 아싸리 디렉토리로 인식되어 버리기 때문에 몇몇 파일 읽고 쓰는 시간으로 세월 다 보내는 작업의 임시작업소로 사용할 수도 있다. (다만, 다운되면 작업 다 날리는 것이기 때문에 추천하고 싶지는 않다...)

위와 같이 xcache 를 ramdisk 에 연결시킬 경우

eclipse 에서는 아예 저렇게 폴더로 나와버린다... 이런 방식은 테스트용 swf 들이 좍좍 쌓이는 폴더를 대체하고, 재부팅 하면 파일들이 자동으로 다 없어져버리게 하는데도 사용할 수 있다. 정 할 일 없거나 (맥은 대부분 사양이 높은 편이라 해당사항 없겠지만) 컴퓨터가 미치도록 느리다 싶을때 SVN 으로 작업을 지속적으로 저장하고 SVN 으로 작업폴더를 복원하는 식으로도 사용이 가능하긴 하다... ㅡ ㄴ ㅡ;;;