Xcode 3.1을 제가 사용해 보면서 눈에 뛰는 점들만 알아 보겠습니다. 사용 경험이 없어 틀린 내용이나 중요하지만 언급하지 않은 내용들이 많이 있을 수 있습니다. 틀린 내용들은 알려 주시면 수정하겠습니다.

제목 그대로 깊이 없고 두서 없는 '둘러보기'식 내용이니, 정확하고 체계적인 내용은 애플에서 제공하는 아래의 문서들을 확인해 보시기 바랍니다.



1. 인트로(Welcome) 화면
Xcode 시작시에 인트로 화면이 추가되었습니다. 보통 어플리케이션 사용시에 이런 Welcome이나 오늘의 팁 같은 기능들은 잘 사용하지 않습니다. 하지만 Xcode에서는 RSS로 새로운 소식들도 보여주고, 순간 관심이 가는 링크들을 클릭해서 내용도 읽어 보기 위해서 하단의 'Show at launch'를 체크해 놓고 시작할 때 마다 한번씩 새로운 소식들을 확인해 볼 수 있습니다. 화면은 아래와 같이 다섯개의 색션으로 되어 있습니다.

1) Getting Started
  • Create your first Cocoa application
  • Build your user interface
  • Store your application data
  • Optimize your application

위와 같이 4개의 내용으로 구성되어 있으며 각 제목을 클릭하면 해당 도움말이 열립니다. Xcode 3을 처음 실행하는 분들은 한번씩 읽어 볼만한 내용들입니다. Xcode는 소개화면에서 다섯개의 색션중 최종적으로 선택한 색션을 기억하고 있습니다. 'Getting Started'는 한번정도 볼만한 내용이므로 RSS 색션을 선택해 놓고 종료하면 다시 실행될 때 RSS 색션으로 열립니다.

2) iPhone Dev Center
아이폰 개발과 관련된 Video, Sample Code, Reference Library에 대한 링크로 구성되어 있습니다. 클릭하면 ADC의 해당 문서가 웹브라우져에서 열립니다. 모바일에서의 개발이 맥에서 개발보다 앞에 위치 있다는 것은 애플이 iPhone에 많은 기대를 가지고 있다는 것을 보여 주는 것 같습니다. 개발자도 iPhone 개발자들이 더 많은지는 잘 모르겠습니다.

3) Mac Dev Center
내용은 위와 동일하며 OS X에서 개발에 관련된 Video, Sample Code, Reference Library에 대한 링크로 구성되어 있습니다.

4) Xcode News [RSS]
맥 개발과 관련된 최신 뉴스를 확인할 수 있습니다. 하단의 Mac OS X, Mac OS X server, Core Foundation, Quicktime, Internet & Web, Games, Graphics & Imaging, Networking 링크를 클릭하면 해당 색션의 RSS를 등록할 수 있습니다. 애플에서 제공하는 개발 관련 RSS 목록은 'More RSS feeds...'를 클릭하거나 개발자 RSS Feeds 페이지에서 확인할 수 있습니다.

5) Mailling Lists
맥 개발과 관련된 메일링 리스트들입니다. 뉴스와 마찬가지로 RSS로 등록하여 확인할 수 있습니다. 애플과 관련된 전체 메일링 리스트들은 'More...'를 클릭하거나 Apple Mailing Lists 페이지에서 확인할 수 있습니다.

6) Tips
Xcode 사용에 관련된 팁들이 있습니다. 주로 Xcode 3에서 추가된 기능들에 관한 설명들이 있으며, 아쉽지만 내용이 다시 실행될 때 마다 변경되지는 않는 것 같습니다. 버젼업 때마다 변경되는 것인지 일정 기간을 두고 변경되는지도 모르겠습니다.


2. New Project
가장 먼저 New Project를 실행해 보았습니다. UI를 제외하고는 이전과 비슷해 보입니다.
사용자 삽입 이미지
iPhoneSDK를 설치하였기 때문에 템플릿중에 iPhone OS 항목이 있습니다. 이외에 MAC OS X의 Application항목에서 Cocoa-Python과 Cocoa-Ruby에 관련된 템플릿들이 많이 추가되었습니다.

사용자 삽입 이미지


3. 에디터
'TestXcode3'로 새로운 Cocoa Application 프로젝트를 생성하였습니다. 겉으로 단순히 보기에는 Xcode 2.5와 큰 차이점이 보이지 않습니다.
사용자 삽입 이미지
이 프로젝트에서는 텍스트 필드에 입력 받은 내용을 버튼을 클릭하면 라벨에 출력하는 간단한 어플리케이션을 만들어 볼려고 합니다. 먼저 AppController 클래스를 생성하였습니다.

1) 자동완성/제안 기능 향상
사용자 삽입 이미지
IB까지 입력하면 IBAction과 같이 출력 됩니다. 여기서 엔터를 입력하면 자동으로 IBAction이 입력됩니다. IBO까지 입력하면 좌측과 같이 IBOutlet이 출력되며 이상태에서 엔터를 입력하면 IBOutlet으로 완성됩니다. 프레임워크 와 사용자가 정의한 변수, 함수, 상수등의 모든 입력에서 적용됩니다.

사용자 삽입 이미지
메소드에서도 인자의 정보를 알 수 있어 편리합니다. 얼마 사용하지 않았지만 일반적으로 팝업을 뛰우는 방식과 비교해서 매우 빠르고 편리한 것 같습니다.
 
2) 블럭
* Focus ribbon

사용자 삽입 이미지
또 하나 재미있는 기능은 구역별로 범위를 확인하거나 감출 수 있다는 것입니다. 이런 기능을 가진 툴들은 보았지만 시각적인 효과에 있어서는  Xcode가 가장 인상적인 것 같습니다.

새로 추가된 좌측의 회색 바(Focus ribbon)를 보면 내부로 구역이 중첩될 수록 진하게 표시됩니다. 저 범위에 마우스를 가져가면 범위를 확인하거나 출력되는 삼각형 모양의 아이콘을 클릭하여 해당 범위를 감출 수 있습니다.


* Code folding
사용자 삽입 이미지
가장 바깥쪽의 @implementation 구역에 마우스 커서를 가져가면 좌측과 같이 해당 구역만 하이라이트되어서 보여집니다.

상하로 삼각형 모양의 아이콘이 범위의 시작과 끝을 알려 줍니다. 이 아이콘을 클릭하면 아래와 같이 @implementsion 내의 내용이 생략되어 보여집니다.






사용자 삽입 이미지
[''']가 구역내의 내용이 생략되었다는 표시입니다. 좌측의 삼각형을 클릭하면 다시 위와 같이 펼쳐집니다.

아래의 이미지들을 확대해서 위의 이미지와 비교해서 보시면 이 기능과 화면효과에 대해서 짐작이 가실 것입니다.
사용자 삽입 이미지사용자 삽입 이미지사용자 삽입 이미지

사용자 삽입 이미지
또하나 입력시에 (), [], {}가 끝나는 부분에서 대응되는 시작위치를 알려 주는 기능이 좀 더 시각적으로 변경되었습니다.

4) Message bubbles
이제 빌드를 해보겠습니다. 아래가 빌드 후에 결과 화면입니다.

사용자 삽입 이미지

오류와 경고 메시지가 아주 이쁜(?) 모양으로 강조되어 출력됩니다. 첫번째 오류는 k++ 다음에 ';'를 생략해서이고, 그 아래의 경고는 헤더 파일에서 setLabelText의 선언을 구현과 다르게 해놓았기 때문에 출력되었습니다. 물론 이전과 같이 별도의 결과창도 존재합니다.

5) 스냅샷
스냅샷은 소스내의 변경사항을 간편하게 저장하고 복구할 수 있는 간편한 방법입니다. 소스를 변경하고 Control+Command+s 또는 메뉴에서 File/Make Snapshot을 클릭하면 현재의 상태가 저장됩니다.

#import <Cocoa/Cocoa.h>

@interface AppController : NSObject {
    IBOutlet NSTextField *inputText;
}

@end

AppController.h에서 위의 상태에서 스냅샷을 설정하고 다시 "- (IBAction)setLabelText:(id)sender;" 선언을 추가한 후에 다시 스냅샷을 설정합니다. 이제 File메뉴 밑의 Snapshot을 실행합니다.
사용자 삽입 이미지
위와 같이 처음 설정한 곳과 다음 설정한 곳의 차이점을 diff와 같이 보여 줍니다. 툴바의 'Restore' 버튼을 클릭하면 이전 상태로 복구됩니다. 이와 같이 CVS나 SVN을 사용하지 않는 혼자서 진행하는 간단한 프로젝트에 사용하거나 저장소와 병행하여 간편하게 사용할 수 있습니다.

6) 리펙토링
클래스나 변수, 함수의 이름을 변경하고 슈퍼클래스를 생성하고 메소드를 상위 클래스 또는 하위 클래스로 이동하는 작업을 편리하게 관리할 수 있습니다. 변경된 사항은 관련된 소스와 파일에 자동으로 반영됩니다.

사용방법은 변경할 아이템을 선택한 후에 Shift + command + j 또는 메뉴의 Edit에서 Refactor...를 선택하면 실행됩니다. 

* Rename
AppController 클래스의 이름을 변경해 보겠습니다. 선택사항을 확인한 후에 입력창에 변경될 이름을 입력합니다. Snapshot에 체크를 하면 변경된 내역이 스냅샷에 저장이 됩니다. 저는 아래와 같이 'MyAppController'로 입력하였습니다. 변경될 이름을 입력했으면 [Preview] 버튼을 클릭합니다.
사용자 삽입 이미지
하단에 변경될 파일들과 항목의 수를 알려 줍니다.
사용자 삽입 이미지
파일의 클릭하면 해당 파일에서 변경될 내역들을 이전 내용과 비교하여 확인할 수 있습니다. 이상이 없으면 Apply 버튼을 클릭하여 적용합니다.
사용자 삽입 이미지
Xcode에서 파일이름이 'MyAppController.*'로 변경되고 각 소스에 해당 내용이 변경되었음을 확인할 수 있습니다.

사용자 삽입 이미지

* Extract
선택된 내용을 새로 메소드나 함수를 생성하여 추가하여 줍니다. 'abc = newValue;'에 적용하면 아래와 같이 소스 코드가 변경됩니다. (사용방법은 Rename과 거의 유사하기 때문에 생략합니다)

변경전
- (void) setAbc: (int) newValue {
  abc = newValue;
}

 Extract 적용 후
- (void) extracted_method: (int) newValue  {
  abc = newValue;

}
- (void) setAbc: (int) newValue {
  [self extracted_method: newValue];
}

* Encapsulate
클래스 맴버 변수의 setter/getter를 자동으로 생성하여 줍니다. 'int abc;'로 멤버변수를 만들고 Encapsulate를 실행하면 헤더파일과 소스파일에 아래의 내용이 자동으로 추가됩니다.

*.h
- (int) abc;
- (void) setAbc: (int) newValue;

*.m
- (int) abc {
  return abc;
}

- (void) setAbc: (int) newValue {
  abc = newValue;
}

* Create Superclass
해당 클래스의 슈퍼클래스를 생성합니다.

* Move Up
선택된 변수와 메소드를 상위 클래스로 이동합니다.

* Move Down
선택된 변수와 메소드를 하위 클래스로 이동합니다.

* Modernize Loop
아래와 같이 반복문에 적용하면 Objective-C 2.0에 추가된 문법으로 변경하여 줍니다.
while ((item = [enumerator nextObject]) != nil) => while (item in itemArray)

Xcode 3에서 코딩은 아직 해보지 못했지만 몇 번 실행은 시켜 보았습니다. 인터페이스 빌더만 조금 변경된 것 같고 Xcode는 Objective-C 2.0외에는 그다지 변경된 내용이 없는 줄 았았습니다. 하지만 잠시 사용해 보았지만 구석구석 편리한 기능들이 많이 추가되고 개선된 것 같습니다. 다른 개발툴에도 있는 기능들이지만 사용하기 편리하고 보기 좋게 잘 만들어 놓은 것 같습니다.

용어도 잘 모르겠고 제 손에 걸린 것들만 언급을 해서 내용이 매우 부실하니, 시작시에 언급한 문서들에서 확인하시기 바랍니다. 몇 달 더 사용해 보고 '둘러보기'가 아닌 제목으로 다시 한번 포스팅 해보겠습니다.

저는 동물 관련 다큐를 굉장히 좋아해서 정규방송이나 케이블 또는 특집 프로등을 자주 봅니다. 그 중 고양이과 맹수들은 많은 동물 관련 프로그램에서 자주 다루는 매력적인 동물들입니다. 저도 물론 좋아합니다.

고양이과 맹수들이 오랜 기간 사냥을 위하여 진화된 날카로운 송곳니와 발톱, 유연하고 빠른 몸을 이용해 자신보다 덩치가 훨씬 큰 동물들을 사냥하는 모습은 경이롭고 두렵기까지 합니다.

사용자 삽입 이미지

애플은 OS X의 코드명에 이 고양이과 맹수들의 이름을 사용하고 있습니다. 현재까지 나온 OS X의 버젼과 코드명은 아래와 같습니다.

  • 10.0 치타(Cheetah)
  • 10.1 퓨마(Puma)
  • 10.2 재규어(Jaguar)
  • 10.3 팬더(Panther)
  • 10.4 타이거(Tiger)
  • 10.5 레퍼드(Leopard)

'10.3 재규어' 부터 공개적으로 마케팅에 코드명을 사용하고 있습니다. 이제 다음 버젼의 OS X는 어떤 고양이과 맹수가 코드명으로 나올지 궁금해집니다. 아직 안나온 대형 고양이과 맹수중엔 당연히 사자(Lion)가 가장 먼저 떠오릅니다. 하지만 위키피디아를 보니 애플은 Lynx(살쾡이)와 Courgar(쿠거)를 트레이드마크로 등록해 놓았다고 합니다.

사용자 삽입 이미지
lion, lynx, cougar외에는 일반인들이 널리 알고 있는 고양이과 동물들의 이름은 대부분 사용한 것으로 보입니다. 제 생각에는 앞으로 4개 남은 10.X대 버젼에선 고양이과 동물을 그대로 유지하지 않을까 생각됩니다. 바로 다음 버젼인 10.6에선 어떤 고양이과 동물을 사용할지 모르겠습니다. 

그리고 만약 애플에서 이런 특정 동물의 이름을 사용하는 전통을 유지한다면 11.X 버젼(OS XI가 될려나요?)에선 어떤 류의 동물들을 사용할지 궁금하네요. 개인적으론 맹금류(eagle, hawk, condor, owl, kite 등)도 괜찮지 않나 생각해 봅니다.

보면 외국(특히 미국) 사람들은 소프트웨어나 관련된 제품에 동물을 많이 활용하는 것 같습니다. 오렐리의 책들 표지에서도 동물들을 활용하거나(OS와 관련된 유명한 공룡책도 있죠), 애플의 OS X의 고양이과 동물 코드명들과 shark, lynx, tomcat, python등 동물이름의 프로그램들, 그리고 리눅스의 팽귄, mysql의 돌고래, 파이어폭스의 여우등의 마스코트에도 다양하게 사용하는 것 같습니다. 

영어의 동물명은 제가 영어에 익숙하지 않아서인지 괜찮게 들리는 것 같습니다. 하지만 우리나라 말로 '사자, 호랑이, 표범'등의 이름은 어플리케이션 이름에 사용하기에 좀 밋밋하지 않나하는 생각이 듭니다. 우리나라 말이 너무 익숙해서 그런 것 같습니다.

만약 다음 세상이 있다면 컴퓨터와는 거리가 먼 동물 다큐멘터리를 촬영하는 사람으로 태어 났으면 좋겠습니다.

'기타' 카테고리의 다른 글

스크래치 사이트 한글화  (0) 2008.07.02
각 언어별 Hello World 출력  (0) 2008.05.08
OS X 코드명과 동물이름  (10) 2008.04.22
Xcode 3 시연 동영상  (4) 2008.03.26
구글 온라인 강좌 - Google Code University  (1) 2008.03.25
맥미니 분해 및 업그레이드  (4) 2008.03.14

이번에 열린 PWN 2 OWN 컨테스트의 결과로 ZDnetMacBook Air falls in two minutes at PWN 2 OWN란 기사가 났습니다. 짧은 영어로 번역하면 "맥북 에어 PWN 2 OWN에서 2분만에 나가 떨어지다" 인 것 같습니다.

맥북대신 OS X나 레퍼드가 와야 할 것 같은데 애꿎은 에어가 비난을 받게 되었네요. 다소 친 MS적인 성향을 보이는 ZDnet 뿐만 아니라 많은 기사에서 OS X가 아닌 MacBook Air로 나와있습니다. 맥북 에어엔 당연히 OS X가 깔려 있으니 억지는 아니지만 의도가 궁금하네요.
 
사용자 삽입 이미지
관련 사이트를 가보니 이 아저씨(보기엔 아저씨로 보이지만 얼굴만 보면 아닐지도 모른다는 생각도 듭니다)의 팀에 의해서 성공한 것 같은데 재밌게도 사용한 컴퓨터가 맥북으로 보입니다.

제로데이 어쩌고 하는 것으로 보아 아직 패치가 되지 않은 비교적 최근에 알려진 사파리의 취약점을 공격한 것으로 생각됩니다.

(사진출처: TippingPoint)

관련 사이트들에 달린 댓글들을 보니 이런 우리나라와 비슷하게
'OS X가 해킹당한게 아니고 아무 문제없다'
'결과가 이런데도 mac fanboy들은 역시 수긍을 안한다'
고 역시 치열하게 싸우고 있습니다.

이번 결과로만 놓고 OS의 보안성을 논의 한다는 것은 그다지 의미가 없다고 생각됩니다. 다만 해외 사이트들의 글들을 보아도 저도 중년의 맥 fanboy고 맥과 OS X를 좋아하고 취향에 맞지만, OS X를 완벽한 OS 또는 타 OS 보다 월등하다고 여기는 글들은 사실도 아니고 악플을 달아 달라고 고사를 지내는 것과 같다고 여겨집니다.

저는 회사 다닐 때 부터 지금까지 제 PC를 잘 안 끄는 습성이 있습니다. 이유는 물론 귀찮아서고요. 이런 면에선 지금까지 제 경험으론 Win 200X, OS X, Vista가 가장 안정적이었던 것 같습니다. (데스크탑으로서 Linux는 그리 많이 사용해 보지 않아 잘 모르겠지만 역시 안정적일 것으로 생각됩니다)

지금 쓰고 있는 OS X와 Vista에 새로운 소프트웨어를 무지막지 하게 깔았다 지워보고 합니다. 전혀 증명되지 않은 제 체감에 의한 것이지만 확실히 XP에 비해서는 Vista가 리소스나 이런 부분에서 관리를 잘 하는 것 같습니다. XP와는 달리 수많은 소프트웨어를 설치해도 속도와 안정성을 처음 같이 잘 유지하고 있는 것 같습니다.

개인적으로 IDC에서 리눅스 서버를 운영하고 있습니다. 관리할 사람이 없어 제가 관리하는 데요. 그럴리야 없겠지만 저처럼 덜 떨어진 관리자가 운영하는 서버에 저런 전문가들이 죽자 살자 달려들면 2분은 커녕 2초 안에 root 패스워드가 변경되어 있을 것 같습니다. ^^;

사용자 삽입 이미지

녹스퀘스트님의 '위젯이 동작하지 않는다'는 댓글을 보고 확인해 보니,
이전에 올린 위젯이 현재 맥 OS X에서 동작을 하지 않아 수정하여 다시 올립니다. 대쉬보드를 거의 사용하지 않았더니 언제부터 동작하지 않았는지는 잘 모르겠습니다.

올블로그의 RSS는 변경된 것 같지 않고 확실하지는 않지만 아마 OS X에서 보안 관련 패치가 되면서 동작하지 않은 것 같습니다. 방식을 변경해서 동작하도록 만들어서 다시 업로드 합니다. 필요하신 분들은 다시 설치 하셔야 할 것 같습니다. 아래의 파일을 다운로드 받으신 후에 압축을 푸시고 위젯 아이콘을 더블클릭하시면 다시 설치됩니다. 불편을 드려 죄송합니다.

'습작 소프트웨어' 카테고리의 다른 글

광고 차단툴 - AntiAD  (7) 2008.04.18
파일명 일괄 변환 툴  (2) 2008.04.11
맥 OS X용 올블로그 실시간 인기글 위젯 수정본  (2) 2008.02.26
티돌이(티스토리 알리미) 윈도우 버젼  (4) 2008.02.06
티돌이 1.0B  (24) 2008.01.07
티돌이 0.7B  (2) 2007.11.08

MS윈도우에서 사용하는 PE와 유닉스의 ELF 포맷은 유명하지만 맥에서 사용하는 Mach-O 포맷은 상대적으로 덜 알려져 있는 것 같습니다. 그래서 OS X의 실행파일 포맷 중 헤더 부분에 대해서만 간단히 알아 보도록 하겠습니다.

실행 파일 헤더 구조라는 다소 무거운 제목과는 달리 간단히 구조만 알아 보고 몇가지 편리한 툴들을 살펴 볼려고 합니다. 상세한 자료가 필요하신 분들은 ADC에서 아래의 문서를 참조하시면 될 것 같습니다.

1. Mach-O & fat-binary

사용자 삽입 이미지
Mach 커널을 사용하는 OS X는 Mach-O란 실행파일 포맷을 사용합니다. Mach-O 파일 포맷은 좌측과 같이 되어 있습니다. (이미지는 ADC에서 가지고 왔습니다.)

Mach-O 파일은 헤더와 load commands, 세그먼트들로 구성된 데이터로 이루어져 있습니다.

load commands는 OS가 어플리케이션 실행시에 라이브러리를 올리는 등의 실행에 필요한 명령어들의 집합입니다.

헤더에 대한 상세한 내용은 툴 사용법과 함께 알아 보겠습니다.


fat-binary (멀티아키텍쳐 바이너리)
위의 구조는 한 아키텍쳐를 위한 단일 구조이며, OS X에서는 여러 아키텍쳐를 지원하는 유니버셜 바이너리를 위하여 fat이란 구조를 사용하고 있습니다.

사용자 삽입 이미지
fat은 하나의 실행파일이 여러 아키텍쳐에 적용될 수 있게 하기 위한 포맷입니다. 이는 OS X에서 PPC(PowerPC)와 x86 코드를 사용할 수 있게 하여줍니다. 우리가 흔히 유니버셜 바이너리(UB)라고 부르는 실행파일 포맷입니다.

좌측을 보면 위의 구조(thin)와는 달리 fat에 관련된 헤더들이 추가되었습니다. 각각의 Fat Architecture는 각각의 실행 코드를 가르키고 있으며, OS에서 로드시에 해당 아키텍쳐에 맞는 코드 블록(Mach-O 포멧)이 로딩됩니다.     




2. lipo
lipo는 OS X에서 유니버셜 바이너리를 관리하기 위한 툴입니다. lipo를 이용해서 유니버셜 실행 파일로 부터 한 아키텍쳐를 지원하는 실행파일을 추출을 할 수 있습니다.

사용자 삽입 이미지
웹브라우져인 오페라 실행파일로 테스트를 해보겠습니다. 실행파일은 해당 어플리케이션 디렉토리 (Opera.app)에서 Contents/MacOS/ 내에 있습니다.

터미널에서
> lipo -detailed_info ./Opera
를 실행하시면 좌측과 같은 fat과 지원하는 각 아키텍쳐들의 세부 정보를 확인할 수 있습니다.


오페라는 유니버셜 바이너리(fat)로 되어 있으며 위와 같이 nfat_arch(fat_arch 구조체 갯수)가 2이이므로 두개의 네이티브 코드를 가지고 있습니다. 그 아래의 메지시로 PPC와 i386(x86)을 지원한다는 것을 알 수 있습니다. 각각의 내용은 fat_arch 구조체의 내용입니다. fat_arch 구조체는 아래에서 확인해 보겠습니다.

이제 lipo의 "-thin" 옵션을 이용해서 PPC만 지원하는 실행파일을 추출하여 보겠습니다. 터미널에서 아래와 같이 lipo 명령을 실행합니다.

사용자 삽입 이미지

실행이 완료되면 위와 같이 Opera2란 파일로 ppc 네이티브 실행파일이 만들어져 있습니다. 파일 크기를 확인하시면 fat 헤더와 x86 코드가 빠져있기 때문에 거의 반으로 줄어 있습니다. 새로 생성한 PPC 파일을 Opera로 이름을 변경하고 GUI에서 확인해 보겠습니다.

사용자 삽입 이미지

좌측이 유니버셜 버젼이 적용된 원래 모습이며, 우측이 lipo를 이용하여 새로 만든 PPC로 적용시킨 후 확인해 본 모습니다. Universal에서 PowerPC로 변경되어 있습니다.

3. otool
otool은 실행파일(or obj, lib 등)의 정보를 보여주는 OS X에 내장된 툴입니다. OS X는 기존의 유닉스 계열과는 달리 "ldd"라는 공유라이브러리의 의존성을 검사하는 툴이 없습니다. otool은 ldd의 기능도 포함하고 있으니 OS X에서는 이를 사용하면 됩니다.

터미널에서 "otool"만 입력하시면 아래와 같이 간단한 사용방법을 보실 수 있습니다.

사용자 삽입 이미지

> otool -L ./Opera 로 오페라에서 사용하는 공유라이브러리 정보를 출력합니다. 위와 같이 오페라는 "카본 프레임워크"를 사용하고 있음을 알 수 있습니다.  또한 위의 lipo 보다 더 실행 파일의 다양한 헤더들과, load command등의 정보를 확인할 수 있습니다. (lipo는 유니버셜 바이너리 파일만 적용할 수 있습니다.)

4. OxED
사용자 삽입 이미지
0xED는 맥에서 바이너리 파일을 볼 수 있는 핵사 에디터입니다. 일반 텍스트 에디터에서 얻을 수 없는 바이너리 파일들의 정보를 얻을 수 있습니다.



아래는 0xED를 이용하여 오페라의 실행파일(유니버셜)을 열어 본 모습입니다.

사용자 삽입 이미지

헤더의 시작은 fat_heaer와 fat_arch로 이루어져 있습니다. 우선 /usr/include/mach-o/fat.h에서 이 구조체들을 확인해 보겠습니다.

#define FAT_MAGIC   0xcafebabe
#define FAT_CIGAM   0xbebafeca  /* NXSwapLong(FAT_MAGIC) */

struct fat_header {
    uint32_t    magic;      /* FAT_MAGIC */
    uint32_t    nfat_arch;  /* number of structs that follow */
};

struct fat_arch {
    cpu_type_t  cputype;    /* cpu specifier (int) */
    cpu_subtype_t   cpusubtype; /* machine specifier (int) */
    uint32_t    offset;     /* file offset to this object file */
    uint32_t    size;       /* size of this object file */
    uint32_t    align;      /* alignment as a power of 2 */
};

fat_header
첫번째 4바이트의 "CA FE BA BE"를 보시면 fat_headerd의 magic 값이며 소스에서 FAT_MAGIC 정의된 값입니다. 이는 실행파일이 fat 구조이며 유너버셜 바이너리라는 것을 알려 줍니다.

두번째 nfat_arch는 이 실행파일이 지원하는 아키텍쳐의 갯수이며 그 아래에 위치할 fat_arch 구조체의 갯수와도 동일합니다. 4바이트 int형으로 [00 00 00 02]로 2개의 아키텍쳐를 지원합니다.

fat_arch
지원하는 아키텍쳐의 정보를 담고 있는 구조체 입니다. 첫번째는 cpu의 종류를 나타내는 cputype입니다. 16진수 [00 00 00 12]로 10진수 18의 값을 가지고 있습니다. 두번째 fat_arch는 이 값이 [00 00 00 07]로  7의 값을 가지고 있습니다.

#define CPU_TYPE_POWERPC        ((cpu_type_t) 18)

#define CPU_TYPE_X86        ((cpu_type_t) 7)
#define CPU_TYPE_I386       CPU_TYPE_X86        /* compatibility */

이 값들은 /usr/include/mach/machine.h 파일에 아래와 같이 정의 되어 있습니다. 각각 PPC(18)와 x86(7) 아키텍쳐를 지원하고 있음을 알 수 있습니다.

다음은 lipo로 만든 PPC 실행파일을 열어 본 모습니다.
사용자 삽입 이미지

fat_ 과 관련된 구조체 없이 바로 mach_header가 위치합니다. 아래는 mach_header가 정의된 /usr/include/mach-o/loader.h 헤더파일의 일부입니다.

/*
 * The 32-bit mach header appears at the very beginning of the object file for
 * 32-bit architectures.
 */
struct mach_header {
    uint32_t    magic;      /* mach magic number identifier */
    cpu_type_t  cputype;    /* cpu specifier */
    cpu_subtype_t   cpusubtype; /* machine specifier */
    uint32_t    filetype;   /* type of file */
    uint32_t    ncmds;      /* number of load commands */
    uint32_t    sizeofcmds; /* the size of all the load commands */
    uint32_t    flags;      /* flags */
};

/* Constant for the magic field of the mach_header (32-bit architectures) */
#define MH_MAGIC    0xfeedface  /* the mach magic number */
#define MH_CIGAM    0xcefaedfe  /* NXSwapInt(MH_MAGIC) */

각각의 값들은 아래와 같습니다.

magic [FE ED FA CE]
Mach-O 포맷의 파일을 알려 주는 필드입니다. 이는 빅 엔디언을 사용하는 PPC 파일의 값이고 리틀 엔디언을 사용하는 x86을 지원하는 코드에서는 "CE FA ED FE"를 가지고 있습니다.

cputype [00 00 00 12]
12로 위와 동일하게 PPC를 지워합니다.

cpusubtype [00 00 00 00]
PPC subtype의 0은 CPU_SUBTYPE_POWERPC_ALL로 정의되어 있습니다.

filetype [00 00 00 02]
파일타입 2는 MH_EXECUTE로 정의 되어 있으며 실행파일을 의미합니다.

ncmsds [00 00 00 0B]
11개의 load command를 가지고 있음을 의미합니다.

sizeofcmds [00 00 08 CC]
load command의 크기로 2252byte입니다.

flags [00 00 00 85]
bit로 정의된 상세 정보입니다. 아래와 같은 세가지 bit가 세팅되어 있습니다.

#define MH_NOUNDEFS 0x1     /* the object file has no undefined
                       references */
#define MH_DYLDLINK 0x4     /* the object file is input for the
                       dynamic linker and can't be staticly
                       link edited again */
#define MH_TWOLEVEL 0x80        /* the image is using two-level name
                      space bindings */

cputype과 cpusubtype의 값에 대해서는 /usr/include/mach/machine.h 헤더파일을 그 외 정보들은  /usr/include/mach-o/loader.h에서 자세한 정보를 확인하실 수 있습니다.

딱 저의 궁금증 까지만 알아 보았습니다. 더 자료가 필요하신 분들은 위에 링크된 ADC 레퍼런스와 또 다른 문서인 Universal Binary Programming Guidelines가 도움이 되실 것입니다.

이전부터 애플, 맥, OS X, 개발에 관한 포스팅을 할려고 마음 먹고 있었습니다. 최근에 이와 유사한 글을 올린적이 있었지만 여러 이유로 삭제를 하였습니다. 하지만 이전 부터 써보고 싶었던 내용을 기술적인 내용-이 부분은 제 능력 밖입니다-이 아닌 그냥 제 생각, 경험, 감정등을 편하게 써내려 가려고 합니다.

실력은 없었지만 저도 개발자라는 직책으로 10년 넘는 세월을 보냈습니다. 이 얘기는 맥에 대한 혐오감을 가지고 있는 동료 개발자와 술자리에서 "나도 얼마 안써봤지만 맥을 써보니 이러 이러 하니 한번 가지고 놀아봐라" 라는 내용 정도로 보시면 될 것 같습니다.

다만 하루에 200명도 안 오는 무명 블로그이지만 이런 주제가 자칫하면 맥빠 vs 맥까의 소모적인 논란이 될까봐 먼저 한가지만 말씀 드리겠습니다.

커밍아웃합니다. 전 맥빠입니다


저는 사무실과 집에서 모두 맥만 사용합니다. 다만 예외는 PC에서 개발이 필요한 경우와 맥에서 사용이 불가능한 웹서비스를 이용할 때, 그리고 곰TV에서 스타 중계를 볼 때 입니다.

이 사실을 먼저 말씀드린 이유는 개인적으로 비스타/XP 보다 맥 OS X를 더 좋아하기 때문에 맥을 사용하고 있습니다. 그리고 "OS X에서 cocoa 맛보기"란 타이틀로 블로그를 운영 하는 제가 쓰는 이 글에 혹시나 바라시는 OS X나 애플에 대한 신랄한 비판이나 겉만 화려한 깡통 OS다라는 고해성사는 없습니다. 오히려 제가 어떻게 맥빠가 되어 갔는가에 대한 수기라고 보셔도 됩니다.

그렇기 때문에 애플, 맥, OSX 이런 단어에 대해서 무조건적인 불쾌감을 가지고 있는 분들은 읽지 않는 것이 정신건강에 좋으실 것입니다. 최대한 불편하지 않게 써볼려고 하지만 제 개인적인 취향과 선호도가 곳곳에 보일 수도 있습니다.


우선 개발자에게 맥을 권하는 이유는 크게 2가지 입니다.

1. 일반사람들에 비해 적응이 쉽다.

저는 맥이 좋다고 말하지만, 맥을 다른 사람들에게 권하지는 않습니다. 제 아이맥과 맥미니를 보고 익숙하게 보던 윈도우즈와는 다른 모습에 대한 호기심, 깔끔한 하드웨어 디자인 때문에 "이번에 PC를 사야하는데 나도 맥을 살까?"하는 지인들이 있습니다. 하지만 대부분의 경우에 절대 사지말라고 합니다.

제가 맥 구입을 만류하는 몇가지 이유와 그런 단점에 대한 제 생각입니다.

1) 게임을 할 수 없다.
PC의 중요한 사용 용도 중에 하나가 게임일 것 입니다. 많은 분들이 게임을 위해 하드웨어를 바꿀 정도로 게임은 인터넷과 함께 컴퓨터의 주 사용 용도 중에 하나 입니다.

하지만 맥에서는 외국의 블리자드나 몇몇 업체들을 제외하고는 주위의 많은 사람들이 즐기는 카트라이더, 리니지, 한게임등의 게임들을 할 수가 없습니다.

저는 위에 언급한 게임들은 하지를 않습니다. 스타크래프트 이후로는 게임에 대한 관심이 급격히 줄어 간단한 아케이드, 퍼즐류외에는 게임을 하지 않습니다. PC에서는 쳐다 보지도 않을 게임일 수도 있지만, 아기자기하게 즐길 수 있는 게임들이 많지는 않지만 즐길만큼은 있습니다. 그래서 맥에서 버틸 수 있는 것 같습니다.


2) ActiveX가 있는 서비스를 사용할 수가 없다.
쇼핑몰, 은행을 비롯해 많은 엑티브엑스를 사용하는 우리나라의 인터넷 서비스들을 제대로 이용할 수가 없습니다. 점점 나아지고 있다는 것을 체감적으로 느끼지만 아직도 이부분은 많이 불편합니다. 엑티브엑스 사용에 대한 유용성 및 타당성 논의에 앞서 일단 사용자 입장에선 "맥에선 안된다"라는 것입니다.

저는 게임과 동일한 방법(?)으로 해결합니다. ActiveX를 사용하는 사이트에는 가지를 않습니다.  제가 가는 사이트들은 RSS에 등록된 블로그, 올블로그, SLR클럽, 구글, 리멤버더밀크, 애플 사이트이며 그 외에는 가끔 네이버 까페등을 다닙니다. 그러니 별 불편한 점을 느끼지 못합니다.

한달에 한번 정도 인터넷 쇼핑몰을 이용하는데 이 때는 XP가 깔린 노트북을 사용하며, 뱅킹은 모바일을 이용해서 해결합니다.


3) MS 오피스가 없다.
MS 오피스의 doc, xls, ppt 파일들이 표준문서로 자리잡고 있습니다.  제목과는 다르게 맥에는 MS 오피스가 있습니다. 하지만 한글사용등의 문제로 오픈오피스를 더 많이 사용하고 있는 실정입니다.

doc, xle, ppt등 받아 봐야 할 경우에는 네오오피스, 제가 문서를 보내야 할 경우에는 키노트나 페이지에서 작업 후에 pdf 파일 포맷으로 보냅니다. 다행히 업무용으로 pdf 파일을 보내는 것에 대해 거부감을 느끼거나, doc, hwp 포맷으로 보내 달라는 요청은 경험해 보지 못했습니다.

오히려 수정/변경을 못하게 하기 위해 일부로 pdf로 보냈는지 알거나, pdf 파일로 변환방법에 대해 물어 보는 분들이 많았습니다.


4) 비주류 OS이다.
맥관련 동호회와 메타블로그 사이트를 보면 맥 사용자가 조금 되는 것 같습니다. 하지만 유명세(?)에 비해 인터넷을 제외하고 주위에서 실 사용자를 보기가 희귀한 OS입니다.

당연한 예기지만 윈도우즈에 비해 어플리케이션 수가 상대가 되지 않습니다. 윈도우즈에선 프리 어플리케이션도 많아 선택의 기회가 많지만, 맥에선 존재 자체 하나로 감사함을 느끼게 됩니다.

또한 문제가 발생하였을 경우에는 윈도우즈는 주변에 항상 있는 컴퓨터를 잘 다루는 사람에게 물어 보면 되지만, 맥은 주위에서 쉽게 찾을 수도 없고 인터넷에서도 관련 자료는 많이 부족합니다.

문제가 생기면 네이버에서 찾기는 힘들 수 있지만, 관련 동호회, 구글링, 정 못 찾으면 외국 사이트에서라도 찾을 수 있습니다. 물론 관련 데이터는 PC에 비해 턱없이 부족하긴 합니다.

어플리케이션수도 많이 부족하지만, "필요한 것은 다 있다" 입니다. 저는 iusethiscoolosxapps 사이트에서 구하고 있습니다.


5) 다시 적응해야 한다.
현재 컴퓨터=윈도우즈 입니다. 유사한 부분이 많지만 응용프로그램이 동작하는 방식, 단축키등 모두 다시 적응해야 합니다. 예를 들면 아래와 같습니다.

윈도우즈에서는 복사가 contol+C 이지만 맥에선 command(사과키)+C입니다. 마치 태어났을 때부터 가지고 있었던 본능과도 같은 control+c가 복사가 아니다라는 사실 하나로 적응하기에 얼마나 많은 난제가 있을지 예상이 됩니다. 

사용자 삽입 이미지
맥에도 좌측과 같이 윈도우의 창크기 최대화 버튼같이 보이는 버튼[+]이 있지만 동작은 다르게 합니다. 윈도우가 포함한 컨텐츠를 보기에 적당한 크기로 변경됩니다. 또한 닫기 버튼[X]을 클릭하면 윈도우즈와 같이 응용프로그램이 완전히 종료하는 것이 아니라 프로세스는 남아있고 윈도우만 닫깁니다. (둘 다 예외는 있습니다.)

사용자 삽입 이미지
또한 대부분의 설정창에서는 윈도우즈에 익숙한 확인, 취소 버튼등이 없습니다. 설정을 입력하면 바로 저장되는 방식입니다. 매우 편한 방법이지만 [확인] 버튼을 클릭하여야만 뭔가가 저장되는데 익숙한 사용자들은 꼭 한번 다시 열어서 정말 저장되었나 확인하게 됩니다.


위와 같이 윈도우즈에서 익숙해진 행동과 상식에 대해서 다시 배우고 익숙해져야 합니다. 물론 많은 부분이 상식선에서 유사하지만, 본인이 윈도우즈에도 익숙하지 않다고 생각하는 일반 사용자들에게는 곤혹스러운 부분입니다.

저도 많은 혼돈이 있었지만 이젠 PC에서 Alt+c로 복사를 할려는 제 모습을  보게됩니다. 초반 불편하고 답답할 때도 있지만 생각보다 쉽게 적응됩니다. 다른 방식에 다시 익숙해져야 하는 괜한(?) 노력이 필요하지만 노력에 대한 댓가는 있습니다.

게다가 개인적으로 터미널을 자주 사용해야는데, 리눅스에서 중복되는 명령인 Control+c를 복사 명령으로 사용하지 않는 것이 편리합니다.


이런 제한이 많은 맥을 왜 개발자에게는 권하나?

저렇게까지 하면서 맥을 쓰고 싶을까? 하는 생각이 들 것입니다. 대답은 물론 "네" 입니다. 제가 사용하는데는 위의 단점 이외에 더 많은 장점이 있기 때문입니다. 하지만 위의 단점과 제한외에도 많은 어려움이 있습니다. 그렇기 때문에 일반 컴퓨터 사용자에게는 맥구입을 권유는 커녕 오히려 반대를 하게 되는 것입니다.

저 자신도 오래전 부터 대학시절 포토샵 강좌 아르바이트를 하던 동생과 디자인, 편집 일을 하는 컴맹인 동시에 맥사용자인 집사람 덕분에 맥을 곁에 두고 있었습니다. 겉보기에(?) 멋진 맥을 집에서 몇번을 메인 컴퓨터로 사용해 볼려고 하였지만, 사용하는데 있어 위와 같은 한계와 답답함 때문에 보름을 넘긴적이 없는 것 같습니다.

하지만 올 초 우연히 "진짜 맥사용자가 되보자"라는 결심과 함께 사무실 책상에서 PC를 한켠에 두고 집에 있는 아이맥을 가져다 놓았습니다. 하지만 초반 암초들이 곳곳에서 나타났습니다. 메일 보내면 한글과 첨부파일이 깨져서 가고 doc 파일 네오오피스에서 다시 편집해서 보내면 레이아웃 다 깨졌다고 하고... 까불지 말고 빨리 네이트온(당시는 맥용이 없었습니다.)으로 들어 오라는 거래처 담당자들. 한달 정도 갑갑하더군요.

하지만 점점 해결책과 방법을 찾아 가면서 윈도우즈는 점점 멀어져 갔습니다. 그러다 집에 있는 PC도 맥미니로 바꾸고 시간이 조금 흐르고는 하드 아까워 부트캠프, 페러럴즈와 윈도우즈를 지웠습니다. 맥빠가 되었습니다.

"맥을 사용하는데 있어 제한 사항을 알고 있고, 이와 같은 어려움을 극복할 수 있을 만큼 기본적으로 컴퓨터를 잘 사용하고, 새로운 환경에서 적응하는데 드는 노력을 귀찮음 보다 즐거움으로 여길 수 있다면 추천해 드릴 수 있습니다."

그러니 제가 맥 사용을 추천한다면 권할 수 있는 1순위가 평소에도 컴퓨터, OS, 인터넷을 이해하고 능숙하게 사용할 수 있고, 새로운 환경을 두려워 하지않고 극복할 수 있는 개발자가 아닐까요?

지금까지의 예기를 요약하면 "좋으니까 써봐라가 아니라, 너넨 쓸 수 있으니까 써봐라" 정도가 되겠네요.


2. 다양한 환경에 대한 경험.

개인적으로 프로그래머는 다양한 환경에 대한 경험과 이에 대해 왕성한 호기심을 가지고 있어야 한다고 생각합니다. 그 이유 때문에 후배 개발자들에게 맥을 많이 추천 합니다. (하지만 동의하는 후배들 대부분도 이를 충족시킬 세컨드 OS로 맥 대신 우분투등을 선택합니다. 구하기 쉬운 PC 하드웨어와 비용적인 측면일 겁니다.)

대부분의 개발자들은 윈도우즈 환경에는 익숙한 정도를 넘어 필요하면 어플리케이션을 직접 만들어 쓸 수도 있습니다. 너무 익숙해 일탈을 꿈꿀 무렵이되면 슬그머니 다른 OS로 눈을 돌려게 됩니다. 이때 쉽게 보이는 것이 리눅스와 OS X입니다. 이중 리눅스는 제외로 하고 이 글의 주제인 OS X에 대해 이야기 해 보겠습니다.

맥 터미널에서 vi, makefile, gcc, gdb를 이용하여 IDE 환경이 아닌 개발자들의 조상들이 써오던 원시적인 환경이지만 Unix/Linux에선 아직도 사용되는 군더더기 없이 깔끔한 개발환경을 체험해 볼 수 있습니다. (노파심에 마지막으로 이런 한마디 드리면 VS는 군더더기 많고 지저분한 개발환경이란 예기가 아닙니다.)

또한 Xcode라는 통합 개발툴을 무료로 제공합니다. 최상의 개발환경이라는 수식어로 한 시대를 풍미했지만 비싼 가격으로 사용자가 없었던, NeXTSTEP의 후계자인 Xcode의 개발환경을 맛 보실 수 있습니다.

Xcode는 java, c/c++등 많은 언어와 플랫폼을 지원하며, 맥용 어플리케이션을 만들기 위해서는 Objective-C를 사용하는 cocoa란 플랫폼을 사용합니다. 위도우즈와는 다른 OS X라는 개발 환경과 objective-c라는 생소한 언어로 인해 윈도우즈와는 다른 프로그래밍의 색다른 맛을 느낄 수 있습니다.    

하지만 다른 모든 사항과 마찬가지로 개발툴과 환경도 MS 비하면 열악 합니다. MSDN과 같이 방대하고 잘 정리된 도움말을 제공하지 않습니다. 또한 윈도우즈처럼 많은 개발자료나 소스도 없습니다. 윈도우즈에서 필요한 것이 있으면  우선 소스를 찾고 대부분이 존재합니다. 그 외에만 집중하면 됩니다. 하다 막혀도 개발 커뮤니티에서 검색만 하면 대부분 나옵니다.

비쥬얼 스튜디오와 MSDN에 익숙한 사용자가 처음 Xcode와 맥의 개발환경을 보면 뭔가가 빠진 것 같고 모자란 것 같고, 필요한 것을 찾기가 상대적으로 힘듭니다. 이 역시 개발자의 근성을 가지고 위의 맥과 같이 적응하시라는 무책임한 이야기를 드려야 겠습니다. 힘들게 찾으면 뭐라도 하나 더 남지 않을까요?

이런 맥 개발환경이 MS에 비해 상대적으로 열악하다기 보다는 "방대하고 있어야 될 것은 다 있는 윈도우즈 개발환경"과 "최소한 있어야 될 것만  있는 맥 개발환경"으로 비교하고 싶습니다. 개인적으로 최고의 통합 개발환경(IDE)은 사용자 GUI가 제외된 Linux 그 자체라고 생각하고 있습니다. 물론 지극히 제 주관적인 취향입니다.


그래도 애플과 맥은 싫다!

맥을 비난하는 많은 개발자들의 포스트를 보았습니다. 이전부터 이런 포스팅을 한번 해보고 싶었던 이유 입니다. 때론 몇몇 글들에 트랙백을 달기 위해 글을 써본적도 있었지만, 분란에 더 일조하는 것 같아 삭제하였습니다. 그런 아쉬움 때문에 이런 글을 쓰고 있는지도 모르겠습니다.

1) 애플이 싫다.

- 폐쇄성이 싫다.
OS X를 맥이란 하드웨어에서만 사용할수 있게 만들고, 특유의 폐쇄성이 싫다는 글들을 자주 보게 됩니다. 개인적으론 [애플 하드웨어 + OS X]를 맥으로 보기 때문에 OS X가 일반 하드웨어에 설치가 안된다고 불만은 없습니다. 하지만 이에 대해 폐쇄적이라는 의견에도 반대는 하지 않습니다. 애플이 하드웨어 회사이든 뭐든 이 문제에 대해서는 잘 모르고 뚜렷한 의견이 없습니다.

다만 정확히 폐쇄적이라는 것이 무엇을 의미하는지 명확히 이해가 가지 않지만, OS X가 폐쇄적이라는데 대해서는 동의 하지 않습니다. MS나 애플이나 오픈소스 재단도 아니고 무조건 공개하라는 말은 무리가 있게 들립니다.

다만 MS는 시장을 장악하고 있는 영향력으로 인해 새로운 표준을 만들어 내고 강요하는 경우가 많지만, OS X는 산업 표준 또는 오픈소스를 사용하거나 필요한 경우에는 참여도 하는 경우가 많습니다. 이 부분의 저의 미천한 경험에 의한 것이고, 이 내용 하나만으로 배보다 배꼽이 더 커질 것 같아 자세한 언급은 하지 않겠습니다.


- 한글(or 한국)을 무시한다.
이전 맥에서도 한글과 관련해서 문제가 있었고 아직도 소소한 문제점이 보입니다. 또한 근래에 나온 아이폰과 아이팟 터치에서는 한글이 입력이 안됩니다. (애플의 이런 문제에 대부분 그렇듯이 사용자에 의해 해결은 된 것으로 알고 있습니다.) 한국에서 출시가 안된 아이폰은 봐준다고 하더라도 아이팟 터치는 이해가 안가는 부분입니다.

애플은 한글(한국)을 무시하는 것이 아니라 아무 관심이 없는 것 같아 보입니다. 한마디로 시장이 작아서 관심을 기울일만 한 가치가 없거나, MS 윈도우즈의 일방적인 우세로 파고들을 틈이 없는 것으로 판단한 것 같습니다.

이 문제에 있어서는 시장이 적다거나 개발자가 적다는 이유로 애플을 이해해 줄 마음이 전혀 없습니다. 특히 터치일 경우에는 수입 대행사를 통해서도 아니고, 정식으로 한국에서 판매되는 제품을 구매하는데 한글입력이 안되는 것은 문제가 있다고 생각합니다. 하지만 한국이라 특별히 열받을 필요는 없습니다. 중국어와 러시아어도 지원하지 않았으니까요. 동북 아시아를 무시 하는건지도 모르겠습니다.

또 하나 자주 입에 오르내리는 것이 한국 애플의 AS입니다. 삼성과 같은 비정상적으로 훌륭한(?) A/S를 기대하지도 않고, 비용을 지불하고 보증을 해주는 애플케어에 관해서도 합리적이라고 생각 합니다. 그래도 관련 커뮤니티나 블로그에서 터져 나오는 개인 쇼핑몰 같은 수준의 고객응대와 A/S에 대한 불만은 개선되어야 할 것입니다.

이 외 비싼 주변기기, 이해가 안가는 램/하드 업그레이드 가격 등 단점을 찾을려면 수도 없이  있습니다. 하지만 장점도 찾아 보면 많겠죠.


2) 광적인 맥사용자가 싫다.

PC는 그냥 어디서나 보고 쓸 수 있는 컴퓨터, 의자나 책상과 같은 존재라면 맥은 맥이라는 특별한 하나의 존재로 여깁니다. 많은 맥 사용자들은 맥을 컴퓨터라고 부르지 않습니다. 심지어는 맥북을 맥부기, 맥돌이라고 의인화 까지도 합니다.

저 자신 또한 맥빠이기 때문인지 맥을 컴퓨터라고 부르지 않고 맥이라 부릅니다. 다른 사람한테 내가 맥을 쓴다는 것을 알리려는 의도가 아니라 마음속으로도... "오늘 집에 컴에다 뭐 깔아봐야지"가 아닌 "오늘 집에 맥에다 뭐 깔아봐야지" 이렇게 마음속으로 생각을 합니다.

역시 컴퓨터에 불과한 맥을 무슨 대다한 기계처럼 일반 컴퓨터로 여기지 않는 것은  맥 사용자가 아닌 입장에선 편하게 받아 들이기 쉽지 않은 부분일 수 있습니다. 제 경험으로 십수년 전 모회사에 다닐 때 잡지에 광고를 내기 위해 디자인을 했던 맥사용자있었습니다. 어느날 그가 저에게로 와서 말했습니다.

"제 맥이 아픈 것 같아요"

저한테 애교 부리는 것인가요? 당시 저에게는 이해할 수 없는 표현이었습니다. "고장 났어요", "부팅이 안되요", "하드가 맛이 갔어요"도 아니고 컴퓨터가 아프다는 표현은 생소하였습니다. 가보니 폭탄화면이 있더군요. 하지만 저 또한 OS X에 로그인시에 틀린 패스워드를 입력하니 부르르 떨어 대는 모습을 본 뒤로는 이해가 가는 부분입니다.

소수의 사용자로 인한 희귀성, 맥 특유의 UI로 인해 사용자들이 많은 애착이 있는 경우가 많습니다. 하지만 윈도우즈에 대한 이유없는 비논리적인 비교, 비판은 비맥사용자들에게 불쾌감을 주는 것 사실 입니다.

장단점과 사실을 인정하지 않고 맹목적으로 추종하거나, 자신이 좋아하는 것이외에 남들의 다른 선택을 무시하는 모습은 애플 사용자건 윈도우즈 사용자건 보기 좋지 않습니다. 하지만 애플 사용자에게서 이런 모습이 많이 보이는 것은 맞는 것 같습니다.

마지막으로 애플과 일부 맥 사용자가 싫어 말없고 죄없는 OS X까지 밉게 볼 필요는 없을 것 같습니다.  


여건이 된다면 맥에서의 개발을 한번 경험해 보는 것도 괜찮습니다.

사실 개발자들이라고 맥으로의 완벽한 스위칭을 권유할 수 없습니다. Linux 서버/웹 개발자들은 업무용으로도 사용할 수 있습니다. 하지만 많은 수의 어플리케이션 개발자들은  윈도우즈에서 개발해야 하며 업무를 위해선 반드시 윈도우즈가 필요합니다. 웹개발자라고 하더라도 반드시 대부분의 사용자들이 사용하고 있는 윈도우즈의 IE에서의 테스트가 필요 합니다.

하지만 다음과 같은 경우에는 Mac을 염두에 두어 보는 것도 괜찮을 것 같습니다.
  • 세컨드 PC를 생각하고 있는 경우.
  • 따로 노트북을 생각하고 있는 경우.

뭐 결론도 없고 논리적이지도 않고 게다가 딱히 주제도 없지만, 제가 평소에 한번 주저리 써보고 싶었던 맥에 관련된 생각을 정리도 안하고 "내가 쓰고 싶은 내용을 써보는 내 블로그"라는데  위안을 갖고 포스팅 해봅니다.


원 글에 트랙백을 위한 포스트인데, 원글이 삭제된 관계로 별다른 준비와 생각없이 쓴 제 글도 내용을 삭제하였습니다. 관심 가져 주신분들에게 감사드립니다.

다른 포스트로 대체합니다.

현재(2008.02.26) OS X에서 동작하지 않아 수정하여 다시 올렸습니다. 여기서 다운로드 받으셔서 사용해 주세요.


사용자 삽입 이미지
올블로그에 종종 놀러 가다가 문득 위젯이 있으면 좋을 것 같아 만들어 보았습니다.

대쉬코드로 만들려고 실행을 했더니 베타가 익스파이어드 되었다고 실행이 안되네요.  그래서 그냥(?) 대충 만들어서 설정 부분이나 모양이 안좋습니다.
 
아래와 같이 10개의 오늘의 추천글을 보여 주며, 제목을 클릭하면 해당 포스트로 연결됩니다.
사용자 삽입 이미지

설정은 간단합니다. 올블로그로 부터 데이터를 확인하는 시간(간격) 설정과 올블로그 링크를 삭제(올블로그 툴바가 안 나옵니다)하고 링크하는 옵션이 있습니다.
사용자 삽입 이미지

아래의 파일을 다운로드 받으셔서 클릭하시고 설치하시면 됩니다.