요즈음 대세인 와이드 모니터는 너무 넓다고 생각하게 되는 경우가 있다. 영화감상보다는 문서(코딩) 작업이 주가 되어 놓아서 넓은 화면보다는 긴 화면이 더 절실한데 그렇다고 모니터를 돌려놓을 수도 없는 것이, 내 모니터는 Cinema Display HD 라서...
다만 모니터가 넓다 보니까 어느 순간부터인가 화면을 반으로 나눠 양쪽에 문서를 열어 놓고 작업하는 사람들이 있는 모양이다. 창 배치를 수동으로 하다 보니 이게 너무 귀찮아서 그런 기능이 나온 것 같은데, 이게 애플에는 기본으로 되어 있지 않는 것 같다. 그리고 근시일 내 나올 모 운영체제는 전혀 흥미가 없지만 이 기능이 기본으로 탑재되어 있어서 살짝 부러웠다.
그러던 어느 날 눈에 띄는 문장... position windows to fill exactly half the screen.. 원하던 그 것이이다. 게다가 프리웨어... 이 곳에서 받을 수 있다.
맥에서 사용하는 Killer App 중에 TextMate 라는 것이 있다. 어느 순간부터인지는 잘 모르겠지만 되도록 오픈소스 프로그램을 사용하려 하고 있었기에, TextMate 를 쓰지 않았다. 능숙하지는 않아도 기본적으로 vi 를 다룰 수 있었고, kenu 형이 smultron 이라는 프리웨어 에디터를 알려 주었기에 특별히 TextMate 를 쓸 이유는 없었다.
그러던 중 최근 django 를 만지게 되면서 TextMate 의 명성을 접해 보고 싶은 생각이 들어 한 번 설치해 보았다. 자세한 것은 아직 잘 모르겠지만 조금 만져 보았더니 역시 좋은 에디터구나 싶기는 한데, 이게 치명적인 것이 한글을 제대로 지원하지 않다. 검색해 보니 이미 고질적인 문제이다. 웬만하면 사서 쓰려 했는데 뭔가 지원이 석연찮은 -그 동안 한글 지원에 대해 많은 사람들이 줄기차게 요청을 해 왔으나 아직도 지원이 요원하다고 한다- 문제를 보고 그다지 끌리지 않았다. 해결이 되면 사던가, 아니면 회사에 요청해서 사 주면 쓰던가...
어플리케이션을 실행하고, 로그파일 보면서 편집을 하고 하다 보니 어차피 vi 가 더 편한 부분도 있다. 그러다가 MacVim이란 것을 알게 되었다.
이거 상당히 마음에 든다(물론 오픈소스). cocoa 기반이라 매우 깔끔하고, 덕분에 맥의 기본 단축키들이 그대로 작동한다고 홈페이지에도 써 있다. 스크린샷에서 보듯이 매우 자랑스럽게 한글 지원도 된다는 것을 과시하고 있다. 하지만 과시해도 된다고 생각한다. 정말 고마운 부분이다.(TextMate는 제대로 못 하는 부분이 아닌가...)
콘솔에서 사용하는 것과는 뭔가 다른 이질감이 있지만 조금 사용하다 보면 극복할 수 있겠지. 보다 vi 에 능숙할 수 있도록 해야겠다.
아쉬운 부분이라면, TextMate 의 'mate' 나 TextWrangler 의 'edit' 처럼 터미널에서 바로 MacVim 을 호출하는 명령을 제공했으면 매우 좋았을텐데... 아직 맥에 익숙하지 않아서 그런 방법을 모르는 것일 수도 있겠다. 조만간 그 방법을 찾아 보거나 만들어 내거나 해 봐야지. 패키지 내부에 보면 mvim 이라는 셸 스크립트가 들어 있다. $HOME/bin 등 적당한 곳에 옮겨 놓으면 셸에서 MacVim 을 실행하는 데 사용할 수 있다.
맥에서 ntfs 를 사용하기 위해서는 많이 알려진 대로 MacFUSE 를 사용한다. 정확한 정보가 아니면 적지 않는 것이 상책이지만... 잘못된 것이 있으면 누군가 바로잡아 주겠지 하는 안일한 마음가짐으로 적어 나가 본다.
...
조금 적어 보려 했더니 많이 복잡하다. 그냥, 하려던 이야기나 해야겠다.
원래는 ntfs 로 포맷된 외장 하드에 "쓰기" 위해서 방법을 찾다 보니까 MacFUSE 라는 것을 설치해야 하는 것을 알게 되었고 이게 ntfs 지원 뿐만이 아니라 여러 가지 놀라운 파일시스템을 지원하며, sshfs 라는 것과 관련한 내용도 보게 되었다. 제목에서 짐작할 수 있듯, ssh 프로토콜을 이용해서 원격 시스템을 마운트하는 것 처럼 해 주는 것이겠지 싶었다. 하지만 당시에는 fuse 를 통한 ntfs 접근이 너무 느려 터져 당장 급한대로 쓰기는 했지만 쓸모없다고 생각했었고, sshfs 역시 같은 MacFUSE 기반이라 느리면 느렸지 빠를 리 없다고 생각하여 nfs 마운트에 관심을 가졌었다. 그런데 nfs 역시 실망스럽기는 마찬가지였다.
아무튼 하고 싶었던 것은 외장 하드를 사용하듯이 원격 시스템을 마운트하여 사용하여는 것이었으나 이것저것 다 만족스럽지 않아 그냥 scp 로 원격 파일 전송만 사용했었는데, 최근 expandrive 라는 프로그램에 대해 알게 되었다. 대략 살펴 보니 ssh 프로토콜을 이용하여 원격 파일 시스템을 마운트 해 주는 유틸리티라는데 자기들 말로는 매우 빠르다고 한다. '빠른' 원격 마운트 기능이 사실이라면 매력적이라 생각해서 받아 써 보려고 했더니, 결국 MacFUSE 기반인 듯 하다. 즉, 상용인데 MacFUSE 프론트엔드인 것이다. 실망감을 감추고 약간 사용해 보니 생각보다 속도 면에서 쓸만했다. (물론 scp 보다 빠를 리는 없다. 이 부분 알고 보니 대략 MacFUSE 의 sshfs 구현이 대폭 개선된 것 같던데, 자세한 것은 나중에 다시...)
결국 MacFUSE 기반이라면, 뭔가 다른 대안이 없을까 해서 찾아 보니 Macfusion 이라는 것이 있었다. 프리웨어이며 sshfs 뿐 아니라 ftp 원격 마운트도 지원한다. scp 를 이용한 단순 파일 전송을 사용했을 때 보다는 마치 로컬 파일 시스템처럼 파일을 다룰 수 있게 해 주기에 상당히 유용하다고 생각한다. 물론 콘솔에서 sshfs 마운트를 직접 하면 되긴 하지만, 이를 통하는 것이 편리하다. 사용법도 간단해서 (+) 를 눌러 sshfs / ftpfs 두 가지 중 하나를 고르면 되는데 sshfs 를 선택한 경우 다음과 같은 창이 뜨고 적절한 정보를 입력하면 된다. 
실질적으로 sshfs 프론트엔드인 셈인데, MacFUSE 사이트를 대략 둘러보니 2008년 하반기에 sshfs 에 대한 대폭적인 성능 개선이 있었던 것 같다(역시 나중에 확인해 보도록 한다.).
다만, Expandrive 는 Amazon S3 도 지원을 하는데 사용하고 있지 않기 때문에 당장은 MacFusion 이 내게는 가장 적합한 답인 듯 하다.
역시 조금만 검색해 보면 쉽게 찾을 수 있는 내용이지만 몇 가지 첨언을 하며 적어 본다.
의도적으로 윈도우를 사용하지 않으려고 하고 있지만 아무튼 윈도우는 필요하고 이런저런 이유로 가상 머신을 최적의 해답으로 간주하고 사용하고 있다. 물론 일부 정부 사이트에서 프린터 인증시 가상머신은 안된다던가 하는 말도 안 되고 어이없는 상황들이 있기에 100% 가상화 기반 환경만으로 해결할 수 없는 경우도 있다는 점이 슬프다. ActiveX 맹신도들 때문에.
맥북 프로에 가상 머신의 디스크 용량을 애초부터 크게 잡는 것이 아깝기도 했고, 언젠가 필요하면 확장하면 되지 뭐 하는 조금은 안일한 생각에 처음에 한 5G 정도 공간만을 할당했었다. 되도록 아무 것도 안 깔고 최대한 기본적인 것만을 사용하려고... M$ 윈도우에게 많은 디스크 공간을 내 주는 것이 별로 내키지 않았었다.
데스크탑은 리눅스 기반으로 하면서 역시 거기에도 가상머신을 설치하였고 업무상 필요한 것은 주로 여기에 다 설치를 했다. 그 핵심은 말할 것도 없이 M$ 오피스 스위트이고. 까다롭기 그지없는 회사 메일 계정 설정도 완료한 상태였다. 그런데 이게 어느날부터 느끼기에 너무 느리다. 비교를 해 보니 맥북의 경우에는 거의 속도 저하를 느낄 수 없는 반면에 리눅스 데스크탑에서는 현저하게 가상머신 성능이 떨어진다. (이 부분에 대해서는 생각을 달리 해 보면 튜닝을 할 수 있는 여지가 있을 것도 같다. 하지만 그건 다음에 시도해 보아야겠다.)
그래서 다시 맥북 상의 가상화를 주로 사용하기로 마음먹었는데 애초에 가상 디스크 크기를 너무 작게 잡아서 가상머신을 끄고 용량을 늘린 후 다시 부팅해 보니, 용량이 늘긴 늘었는데, 하나로 붙은 게 아니라 파티션이 나뉜 형태라서... 바라던 바가 아니었다.
관련한 내용을 찾아 보니까 리눅스/윈도우 버전의 VMWare 패키지에는 이미 그런 기능을 하는 외부 유틸리티가 존재하는데 VMWare Fusion(맥용)의 경우 그러한 툴이 포함되어 있는 것 같지는 않았다. 결국 찾아 본 내용이 필요한 과정을 잘 설명해 주고 있는데, 우선은 그냥 VMWare 에서 제공하는 기능으로 디스크 이미지를 하나 추가해서 드라이브를 추가하는 형태로 사용하라. 이게 가장 속편하다. 라고 말하고 있었다. 그래도 정 기존 디스크 이미지 자체를 늘리고 싶다면... 하면서 설명하는 내용이 이어진다(다행이다).
적용해 본 바 별 이상없이 제대로 반영이 되었다. 정말 뭐같은 ActiveX 관련 사항 때문에 가끔씩 가상머신이 불편할 때가 있지만 어떤 면에서는 가상머신이 더 유연한 모습을 갖는 경우가 있으며 이 경우도 그러한 경우 중 한 가지 예가 아닐까 한다. 실제 시스템의 하드 용량을 늘리려면 이보다 매우 번거로운 과정을 거쳐야 할 것이다.
그런데... 정작 용량을 늘리고 나서 생각해 보니 추가로 오피스를 설치하는 것은 그렇다 쳐도 지긋지긋한 아웃룩 설정이 떠올라 짜증날 뻔 하다가... 그냥 리눅스에서 사용하던 가상 머신을 복사해 와서 작동시켰더니... 잘 된다. --;
지금까지 무슨 삽질을 한 것인지 참 허탈했던 시간이었다.
에어포트 유틸리티 업데이트 안내가 나오길래 여느 때처럼 조건 반사적으로 업데이트를 했다.
업데이트를 한 이후에 타임캡슐 설정 화면 진입 불가능하고 -6753 에러 메시지가 나온다. 검색해도 찾을 수 없고 해서 고통에 쩔어 있다가 하다가 혹시나 해서 다른 키워드로 찾아보니니, 이 문제에 대한 포럼 결과물이 나온다.
처음에 찾았던 검색어는 time capsule error 6753 이었고, 혹시나 해서 다시 찾아 본 것이 airport utility 6753 이었다. 타임 캡슐 문제가 아니라 에어포트 유틸리티 문제였던 것인데, 엎어치나 메치나. 발생한 지 얼마 되지 않아서 검색에 노출되지 않았던 것일 수도 있고.
아무튼 나만의 문제가 아니라 기존 에어포트 유틸리티 5.3.2 에서 5.4.1 로 업데이트 한 이후 나타나는 현상이었고, 아직 애플에서는 응답이 없으며, 누군가 제시한 해결책은 에어포트 유틸리티 다운그레이드였다.
별 수 없이 다운그레이드를 해서 일단 문제는 해결한 것 같은데 에어포트 유틸리티의 위치를 찾느라 조금 헤멨다(/Applications 에 있지 않고 /Applications/Utitlties 에 있다).
애플을 쓰면 쓸 수록 실망하게 되는 내용들이 계속 눈에 띄고 있다. 충분한 검증도 없이 업데이트가 나오다니... 수동 다운로드 사이트에서 보니 나온 날짜도 벌써 며칠이 지난 3월 3일이다. JDK 문제부터 시작해서 파일명 인코딩 문제, 그리고 오늘과 같은 문제 등...
어느 것이든 완벽한 것은 없기는 하지만... 점점 애플에 대한 환상이 깨지고 있다.
뚜렷한 이유는 없지만 M$ 를 별로 좋아하지 않는다. 특히 우리 나라에서 모든 것이 M$ 제품군 위주로만 돌아가는 상황은 상당히 못마땅하다.
그런데, 리눅스가 더 매력적인 부분도 있고 OS X가 더 좋은 부분도 있었지만 슬프게도 java나 MySQL 등은 M$ 플랫폼에 더 설치하기 쉬우며 더 잘 작동한다. 당장 업무를 하는 데 필수적인 요소들이다. M$ 와 안 친할 것 같은 제품들이 오히려 M$ 에서 제대로 작동하다니, 참으로 묘한 상황이다.
그럭저럭 맥 기반 java 환경에서 프로젝트를 잘 진행해 왔었다. 그러던 어느 날 프로젝트를 분리하면서 비정상적인 작동 형태를 보이기 시작했다. 컴파일이 제대로 되지 않는다... 아직도 그 부분에 대해서는 원인이 무엇인지 모르겠다. 지금은 팀도 갑자기 바뀌어 그 부분에 대해 신경을 쓸 수가 없다.
며칠 전에 잠시 짬을 내어, 그새 Mac 의 java 가 업데이트 되었다는 이야기를 떠올리며 애플 사이트를 뒤져 봤지만 그런 일은 없었던 것 같다. 별다른 기대를 하지 않고, 그러나 실은 무지 많은 기대를 품으며 계속 찾다 보니 맥에서 사용할 수 있는 다른 형태의 jdk 에 대한 글을 보게 되었다.
그 이름은 soy latte 라고 하며, 원래는 sun 에서 FreeBSD 용으로 공개한 버전이라고 한다. 이 것을 맥 용으로 포팅한 버전인데 아마도 처음에는 누군가가 직접 컴파일해서 간단한 자바 바이트코드를 실행하고 성공했던 결과를 포스팅한 것이 시작이었던 것 같다. 지금은 dmg 로 묶어놓은 버전을 구할 수 있다.
역시 습성대로 받아 놓은지는 몇 주가 되었습니다. 마음을 다잡아 사적인 프로젝트를 진행하기 위한 준비 작업을 행하기 앞서 이 jdk 를 테스트해 보았다. 기존에 작업하던 프로젝트에서 테스트 케이스를 돌려 보았더니 뭔가 한 곳에서 에러가 발생하기는 하는데, 이전처럼 cannot resolve symbol 같은 컴파일 에러가 나오는 것 같지는 않았다. 아무튼 조금 더 진행해 보아야겠지.
갑자기 회사 동료에게 자극을 받아 흥미가 동하여 실로 오랫만에 간단한 이클립스 플러그인을 만들게 되었다. 그냥 기존의 기억을 되살려 예제 플러그인을 하나 생성하고 런타임 워크벤치를 실행했는데... 작동이 안 된다...
문제를 접한 순간에는, 그냥 어설프게 - 항상 느끼는 것이지만 이러면 안되는데 - 그동안 이클립스를 업데이트 하면서 시스템이 꼬였나 싶어서, 깨끗한 이클립스를 받아 플러그인을 만들어보는 삽질을 감행했다.
작동이 잘 된다. 그래서 그 동안 사용하던 이클립스에 뭔가 문제가 생겼다고 생각하려는 순간, 워크벤치 JRE 를 살펴보니... 새로 실행한 이클립스는 1.5 다. (지금 작업하던 이클립스는 1.6) 환경을 조절해 보니 1.6 에서 런타임 워크스페이스가 뜨지 않는다.
이후 조사를 진행해 보니까 현재 이클립스가 carbon 기반이고, cocoa 기반으로 바뀌지 않는 한, 혹은 애플의 1.6 JRE 에 변화가 있지 않는 한 해결할 수 없는 문제라고 한다.
요즈음 외국 서적이나 웹 사이트 등을 보면, 예제 화면을 Mac OS X 에서 캡쳐한 것을 많이 볼 수 있다. 이렇게 사용하는 사람이 많아졌으면 최소한 이런 문제들은 안 생길 것도 같은데, 아직 멀었나 보다.
업무를 처리하는데 주로 자바를 사용하고 있고 그 사용 환경이 이클립스이다. 하긴, 누구인들 그렇지 않으랴만은... 맥에서 이클립스 UI 자체는 상당히 만족스럽고 그 부분에 혹한 것이 있다는 점을 부인할 수는 없겠다.
그런데 고통스러운 것이 (윈도우 기반에서 작업하는) 다른 동료들은 아무 문제가 없는데 유독 내 환경에서만 테스트가 실패한다던가 하는 특이점이 발생하여 사람을 매우 괴롭게 한다.
테스트 실패하는 부분에서 사용한 사내 제작 라이브러리의 경우 몇 번의 메일을 주고받은 끝에 만든 쪽에서 자신들이 버그가 있어 그랬다고 수정본을 주었지만, 그 쪽에서 '자신들의 버그'라고 했음에도 불구하고 그게 과연 그 팀의 버그였는지 단정할 수는 없는 상황이다. 설명에 의하면 프로토콜 설계하면서 경계 조건에서 뭔가 다른 부분이 있어서 그랬던 것이지만 왜 유독 맥의 1.6 버전에서만 그런 일이 발생하는가 하는 점은, 뭔가 1.6이 JVM 스펙을 정확히 준수하지 않았을 지도 모른다는 생각이 들게 한다.
오늘 개발환경 설정을 완료하였다.
개발 환경 자체야 자바 기반에 이클립스를 사용하는 것이니 맥이라고 특별히 문제될 것이 없었지만 로컬에서 작동 테스트를 하기 위해서는 회사에서 만든 아파치모듈이 작동되어야 한다. 해서 이는 가상 머신으로 리눅스를 돌리고 그 안에서 아파치를 실행하는 것으로 해결하였다.
그 동안 설치한 내역이다.
그 동안 리눅스 및 M$ Windows 에서 각종 가상화 프로그램을 돌려 보았지만 매킨토시 호스트만큼 빠르고 안정적인 경우를 경험하지 못했다. 우선 가상화 운용 환경이 매우 만족스러웠다. 회사 내부 프로그램상 어쩔 수 없이 윈도우XP도 하나 가상 머신으로 돌리고 있는데 그다지 부하가 느껴지지 않았다. 리눅스 서버 및 테스트용 리눅스 데스크탑, 이렇게 세 개의 가상 머신이 작동하고 있는데 체감 속도가 별로 떨어지지 않는다.
이클립스는 UI가 매우 깔끔하여 보기가 좋습니다.특히 기본 글꼴이 매우 마음에 들었다. 아직은 코코아가 아닌 카본 기반이라는 것이 조금 아쉽지만 언젠가 나아지겠지 싶다.
로컬(호스트)에서 작동하는 톰캣과 가상 머신의 웹 서버를 프락시 연동하여 프로젝트 어플리케이션이 작동하는 것을 확인하였다.
남들 다 사용하고 있는 플랫폼을 버리고 모험을 걸었었는데 다행히 애플 노트북이 값비싼 장난감으로 전락하는 일이 발생하지는 않을 것 같다.
우여곡절 끝에 회사에서 노트북을 지급받았다. 처음에는 전폭적인 지원을 할 것 같이 말해주더니 역시나 조정 과정이 있었다.
처음에는 17인치 모델에 1920x1200 업그레이드를 신청했었지만 반려되었고, 해서 맥북으로 하향조정했다가 조심스레 맥북 프로 15인치 모델로 신청을 했는데 다행히 승인되었다.
대신 기존에 사용하던 데스크탑을 반납하는 조건이지만, 그게 더 낫다. 다만 모든 기반 환경을 M$에서 맥 환경으로 바꿔야 하는데 적응은 그렇다 쳐도 M$ 종속적인 각종 주변 환경을 어떻게 극복해야 할 지는 앞으로 고민해 보아야 할 것 같다.
얼마 전에 맥 미니 코어 솔로 버전을 비교적 저렴하게 구입했었다. 최근 한 대 더 살까 했는데, 그다지 싼 매물이 있지도 않았고 CPU는 코어 2 듀오가 나왔는데 아직까지도 맥 미니는 코어 듀오 모델이 최상위이다. 해서 코어 듀오 산다는 것도 좀 그러하여 약간 검색해 봤더니 해외에서는 코어2듀오로 업그레이드를 성공한 사례가 보였다. 결국 보드에서 지원을 한다는 이야기라 분해만 잘 하면 교체는 별로 어렵지 않을 듯 하다.
단 CPU가 메롬(모바일용)이어야 해서 대박 비싸 다나와에서 한 23만원 정도 하는 것 같다. 그래도 잘 뒤져보니 상당히 저렴게 구할 수 있어서 다들 말리는데도 불구하고 업그레이드 작업을 감행했다.
뭐 사실 맥 미니라고 다를 게 있을까? 일반 조립 PC보다 분해가 까다롭긴 하고 만에 하나 부품을 고장내거나 하면 다시 구할 수 없다는 점이 걸리긴 하지만.
이후로는 약간 시간을 두고 돌려 보아 안정성만 검증되면 될 것 같다.
