macOS 프로그래밍

1.
근래에는 회사 업무 때문에 드디어 맥OS에다가 xcode까지 좀 건드릴 일이 있었다. 작년에 애플에서는 자기네 PC용 운영체제의 공식 명칭을 macOS라고 붙이면서 mac이라는 단어를 다시 복귀시켰던데, 이건 잘한 조치라고 생각된다. mac을 빼고 OS X라고 하는 건 영 아니었다. 무슨 OS/2도 아니고. 물론 걔네들 입장에서는 iOS 같은 타 기기용 운영체제와 명칭 표기를 통일하느라 mac을 소문자 형태로 살린 것이었다.

맥OS에서 메뉴를 꺼내는 단축키는 웬 뜬금없는 Ctrl+F2이구나(Win은 F10 또는 Alt). 그리고 한 프로그램 안에서 문서 창을 전환하는 단축키는 Cmd+` 이다(Win은 Ctrl+Tab 또는 Ctrl+F6). 이런 왕초보 기초부터 다시 시작했다.

Visual Studio와 C++과는 너무 다른 프로그래밍 방법론이 여전히 적응이 안 됐지만.. 나름 맥OS에 대한 이해가 예전보다는 더 깊어질 수 있었다. NextStep에서 딴 NS... 이런 명칭은 게임브리오 소스에 있는 NI... (넷이멀전) 접두사와 비슷한 느낌이 들었다. N으로 시작하고, 지금은 대외적으로 쓰이지 않는 이름. 마치 MFC의 Afx처럼 말이다.

한번은 각종 설정들을 이것저것 건드린 뒤부터 멀쩡한 프로젝트에서 정체를 알 수 없는 링크 에러가 나서 한참 고생한 적이 있었다.
링크 에러라면 당연히 extern "C"처럼 함수 호출 규약이나 심벌 decoration 방식의 충돌이 1순위로 의심되겠지만, 알고 보니 프로젝트 파일 리스트와는 별개로 관리되는 빌드 대상 목록에서 몇몇 소스 파일이 실수로 누락되어 벌어진 일이었다. 둘이 동일한 개념이 아니었 것이다.

하긴 Visual Studio도 각각의 파일들에 대해서 속성을 줘서 exclude from build를 지정하는 게 있긴 했다. 그걸 몰라서 딴 데서 한참을 헤맸다.
IDE에서 각종 경고를 출력하는 인텔리센스와 문맥 감지 색깔 처리가 정상적으로 되고 있어서 이 파일이 애초에 컴파일이 되지 않고 있다는 건 상상을 못 했었다.

2.
맥OS는 자기네 그래픽 비주얼은 그렇게도 뛰어나면서 정작 그래픽 툴을 제공하는 건 왜 그리 인색한지 모르겠다. 맥OS에는 Windows의 '그림판'에 해당하는 기본 프로그램이 내가 알기로 여전히 없다.
개발툴 중에서도 Visual Studio는 간단한 아이콘이나 비트맵 정도 편집할 수 있는 그래픽 에디터를 내장하고 있는 반면, xcode는 그런 거 없고 viewer만 있다. 비트맵 그래픽 편집을 어떻게 해야 할지 모르겠다.

그리고 또 인상적인 점으로는 맥 진영은 Windows에서는 거의 듣보잡이나 마찬가지이던 tif/tiff를 좋아하는 듯하다. 화면 캡처 기본 앱이 그림 파일을 tif로 저장할 때부터 뭔가 심상찮았는데.. 타 xcode 프로젝트들을 보니까 비트맵/아이콘에 역시 tif가 들어가 있구나.

그런데 tif도 다 같은 tif가 아닌지, Windows에서 돌아가는 타 그래픽 에디터에서 저장한 tif는 맥에서 못 읽는 것 같다.

3.
명령 프롬프트로 가 보면, 공백이 포함돼 있는 파일명을 명령 프롬프트에서 표현할 때 Windows는 파일명을 따옴표로 싸서 공백을 표현하는 반면, 맥은 그렇지 않은 듯하다. 역슬래시+공백이라는 탈출문자 기법을 사용한다. 그러니 "a b"냐 a\ b냐의 차이가 발생한다. 디렉터리 구분자부터가 슬래시이니 역슬래시를 저렇게 C스럽게 탈출문자 용도로 활용한다는 게 아주 흥미롭다.

명령 프롬프트가 현재 가 있는 디렉터리(폴더)를 기준으로 탐색기 또는 그에 준하는 파일 관리 셸을 여는 것도 자주 행해지는 작업이다. 숨김 속성 때문에 셸을 통해 접근할 수 없거나 접근 방법이 까다로운 폴더를 다루고 싶을 때 말이다. Windows에서는 start .이던데 맥은 open .이다. 리눅스는 어찌 되려나 궁금하다.

4.
그리고... 결정적으로 맥용 IME 예제도 다뤄 봤다. 골치 아픈 DLL이 아니라 쿨하게 EXE 형태이고, regsvr32 따위 할 필요 없이 그냥 프로그램을 특정 디렉터리에다 얹어 놓기만 하면 바로 IME가 동작하는 게 참 깔끔해 보였다. 여기에다가 날개셋 엔진만 얹으면 내 프로그램이 맥용으로 나오는 것도 불가능하지는 않겠다는 생각이 들었다. 물론 글자만 달랑 찍히는 수준을 넘어서 완성도 있는 제품을 만드는 건 지금 시간과 내 실력만으로는 아직 어림도 없는 요원한 일이다.

오래 전부터 인지했던 것이긴 하지만, Windows와 맥은 문자 입력 시스템을 설계한 형태가 서로 크게 다르다.
Windows는 IME가 또 내부적으로 한영 상태를 갖고 있고 자기 상태를 아이콘을 통해 출력하는 형태이다. 즉, Windows 8식 용어로 표현하자면 brand icon과 state icon이 따로 있다.
그러나 맥은 그렇지 않고 한글 입력 상태가 영문 상태만큼이나.. Windows식으로 표현하자면 별도의 input locale이다. 일단 한글 IME 상태에서 한영 키로 한영 전환을 하는 게 아니라, 입력 로케일 전환인 Ctrl+Shift가 한영 전환인 셈이다. state icon이 없고 brand 자체가 state 역할을 한다.

그러나 <날개셋> 한글 입력기는 자기 brand 하에서 2개 이상 열몇 개까지 입력 항목을 추가할 수 있는 형태이다. 이것부터 맥OS에서는 어떻게 표현을 해야 할지 모르겠다. 맥에서 <날개셋> 한글 입력기는 편집기 계층은 제대로 구현하지 못하고 그냥 입력기 계층 하나 수준에 머물러야 할 수도 있다.

맥에서는 IME가 독립된 프로그램이고 시스템 전체에서 동일한 한영 상태가 유지된다는 것도 매우 흥미로운 점이다. Windows도 IME가 애초에 이런 형태였으면 지금처럼 32비트와 64비트가 공존까지 하는 시대에 IME를 개발하기가 훨씬 더 깔끔해지지 않았을까 싶은 생각이 든다.
언제든지 자기 자신을 죽이고 재시작만 하면 업데이트도 아주 간편하게 할 수 있다. Windows는 DLL에다 memory-mapped file크리까지 겹쳐서 프로그램 강제 종료나 재시작 같은 지저분한 짓 없이는 IME의 업데이트라든가 전체 상태 동기화가 몹시 어렵다.

다만, 그 구조의 특성상 IME를 디버깅 하는 도중에 잠시 딴 프로그램에서 타 IME를 구동해서 문자를 입력하기가 좀 난감한 점은 있다. IME는 그 특성상 타 입력기로 대체만 될 뿐 '스스로 종료'라는 개념이 없는 프로그램인데, Windows에서는 자기 DLL을 사용하는 프로그램이 하나만 존재하면 그것만 끝내면 디버깅도 원활하게 종료되는 반면, 맥에서는 그런 것도 없어서 그냥 IME 프로그램을 강제 종료해야 한다.

그리고 IME 프로그램은 내 자신이 실행하는 게 아니라 운영체제가 on-demand로 구동해 주는 형태이다. 그러니 개발툴이 처음부터 IME를 디버깅 할 수 있는 게 아니라 이미 구동돼 있는 IME 프로세스에다 디버거가 붙는(attach) 식으로 디버깅을 해야 한다.
이렇게 붙으면 NSLog를 찍는 게 xcode의 output 창에 나타나질 않는 문제가 있더라. 그 이유는 모르겠다. 운영체제의 문자 입력 프로그램이라는 건 어떤 형태로 만들더라도 디버깅이 어려운 구석이 있는 듯하다. 동력분산식과 동력집중식만큼이나 서로 일장일단이 있는 셈이다.

5.
코딩을 하면 할수록 Objective C의 고유 문법과 일명 NSFramework 라이브러리는 독립된 언어라기보다는..
Windows로 치면 COM처럼, 그냥 API/라이브러리의 컴포넌트화, 그리고 운영체제-내 프로그램 간의 통신을 위한 바이너리 수준의 프로토콜에 가까운 물건이라는 생각이 든다.

쉽게 말해 NSObject는 IUnknown에, YES/NO는 S_OK, S_FALSE에, @문자열은 BSTR, SysAlloc/FreeString 등에, xib/nib는 리소스 겸 type library에 대응하는 식이다. 뭐 가상 머신이 따로 돌아가는 급은 아니지만 그래도 가벼운 garbage collector도 있다.

물론 기능 호출 방식은 서로 큰 차이가 있다. COM은 함수 포인터 기반인 C++과 더 비슷하지만 옵씨는 진짜 SendMessage 같은 방식이다.
그러니, NSObject에 뭐가 이렇게 오버라이드 가능한 메소드들이 많이 정의돼 있는지, 리스트를 보고 깜짝 놀라곤 했다. v-table 기반의 가상함수라면 상상도 못 할 일이다. MFC도 v-table 크기 부담 없이 운영체제 메시지 처리를 C++로 하기 위해 message map이라는 별도의 메커니즘을 도입한 것이다.

옵씨라고 해서 말 그대로 C만 쓸 수 있는 건 아니며 C++ 코드도 작성 가능하다. 그러니 [ ] 어쩌구로 시작하는 그쪽 ‘오브젝트’와 해당 문법은 운영체제로부터 호출을 받는 것에 대처할 일이 있을 때만 사용하게 되더라.
아무튼 지구를 떠나서 달이나 화성에서 사는 건 어렵고, Windows 홈그라운드를 떠나 타 OS에서 사는 건 여전히 몹시 어렵다!

Posted by 사무엘

2017/03/11 08:31 2017/03/11 08:31
,
Response
No Trackback , 2 Comments
RSS :
http://moogi.new21.org/tc/rss/response/1336

Trackback URL : http://moogi.new21.org/tc/trackback/1336

Comments List

  1. 경헌 2017/03/11 12:14 # M/D Reply Permalink

    안그래도 지금 맥 한글 입력기가 몇몇 있긴 하지만 무주공산(?) 인 상황인데요..
    날개셋 입력기를 언젠가 맥에서 쓸 수 있는 날을 고대해 봅니다 ㅎㅎ

    1. 사무엘 2017/03/11 16:19 # M/D Permalink

      타 OS 포팅 작업을 해 보면 지금 날개셋 엔진 내부도 플랫폼 종속적인 부분과 그렇지 않은 부분에 대한 추상화 수준이 더 올라갈 수 있겠습니다. 하지만 정말 쉽지 않을 것 같습니다. ^^;;

Leave a comment

1.
지난 5월 말, 석가탄신일 연휴 때 고향에 가서 부모님께서 쓰시는 컴퓨터를 여러 군데 손 봤다. XP 정도나 돌릴 수 있는 구형 컴퓨터이다. 내가 없는 사이에 컴퓨터 A/S를 받아서 하드를 포맷하고 운영체제를 새로 설치했다고 하던데, 파일 시스템이 웬 생뚱맞게 FAT32로 되어 있어서 당장 NTFS로 바꿨다.

그리고 드디어 IE7을 설치했다. 부모님의 반응은 “서울 컴퓨터와 같은 인터페이스이구나”였다. 내가 있는 곳에서는 XP가 없고 비스타만 있기 때문이다. 탭을 지원하고 메뉴가 기본적으로 숨어 있는 IE7의 외형과, 그렇지 않은 IE6의 외형은 부모님이 보시기에도 차이가 명백했던 것이다.

때가 2010년인데 IE8이 아닌 IE7을 선택한 이유는 짐작하다시피 병맛 같은 국내 사이트 때문이다. 교사가 쓰는 컴퓨터에다 NEIS가 안 돌아가는 브라우저를 설치할 수는 없는 노릇이고, 본인 역시 IE8을 비스타 64비트에서 한번 설치해 봤다가 국민 은행 뱅킹이 에러 메시지도 없이 그냥 전혀 동작하지 않는 걸 보고, 혼비백산하여 곧바로 IE7로 복귀해야만 했다. 본인의 개인 노트북에만 IE8을 설치해 쓰는 중이다.

IE8이 IE7보다 그렇게도 가벼워지고 성능이 향상되고 ACID 지수도 올라갔다고 하는데 본인은 거기까지는 잘 모르겠다. 그저 탭의 윗부분 색깔이 colorful해졌다는 차이밖에 안 보인다. 세월이 흐르면서 본인은 얼리 어답터 기질은 다 죽어서 업데이트 같은 걸 귀찮아하는 타입. O<-<

그럼에도 불구하고 본인이 지금까지 서울 각지에서 이용해 본 PC방들은 어쩜 이리도 한결같이 IE6을 쓰고 있으니 과연 충격과 공포이다. 각종 통계에 잡히는 IE6 사용자들의 상당수가 PC방이 아닐까 하는 생각이 들 정도였다.
윈도우 XP sp3이면 어차피 IE8까지 돈도 안 들이고 업그레이드 가능한데 왜 이런 투자에 인색한 걸까?

여기서 IE의 역사를 좀 살펴보자. 1은 가히 듣보잡이고, 2는 윈도우 95 번들로 제공된 최초의, 그러나 정말 빈약한 버전이었다.
3은 드디어 넷스케이프 3과 맞장뜨기 시작한 버전인데, 넷스케이프의 플러그 인에 대응하여 ActiveX를 최초로 내장했다. IE3은 MS가 개발한 프로그램 중 전무후무하게 toolbar에 텍스처가 존재했으며, 마우스가 가리키고 있는 버튼에만 윤곽이 나타나는 소위 flat 스타일 toolbar를 최초로 도입한 프로그램이었을 것이다. 나름 산뜻한 외형을 지향했다는 뜻.

오늘날의 IE의 근간이 잡힌 건 4부터이다. HTML 도움말, 액티브 데스크톱 같은 갖가지 기술이 이때 첫 도입됐다. 5에서는 complex script, global IME 등 다국어 처리 능력이 크게 강화된 걸로 기억하며, 무려 윈도우 3.x를 지원한 마지막 버전이다. 그 이후의 버전에 대해서는 설명을 생략하겠다.

윈도우 XP와 같은 시기에 출시된 IE6이 수 년간 엄청 장수하고 독점적인 지위를 누리면서, MS에서는 이제 IE 팀을 해체할까 하는 생각까지 했다고 하는데 흠좀무. 그러던 차에 2004년 가을을 생생히 기억한다. 모질라 재단에서 파이어폭스라는 획기적인 브라우저를 내놓으면서 현재까지 IE의 독점 구도를 크게 무마하는 데 성공했다. 오늘날은 잘 알다시피 구글 크롬까지 빠른 속도를 강점으로 승부 중이다.

2.
오늘날처럼 블로그나 트위터 같은 게 생기기 전, 너도 나도 나모 웹에디터 같은 프로그램으로 아기자기한 홈페이지 만들던 시절이 있었다. 딱 그런 옛날 스타일 홈페이지를 보면 감회가 새롭다. 애니메이션 gif, 아주 초보적인 수준의 플래시, 그리고 테크노트나 제로보드 기반 게시판들. 본인이 학창 시절 때 몇몇 선생님들이 만든 홈페이지가 아직도 그런 스타일이다. 옛날 생각이 난다.

본인이 인터넷이란 걸 처음 접한 게 1997년 말이다. 내가 저장해 놓은 적이 없는 새로운 글과 그림이 화면으로 쏟아져 나오는 게 이리도 신기할 수 없었다. 그때 조선일보던가 MBC던가.. 국내 언론사들은 웬 VivoActive player라는 듣보잡 ActiveX로 동영상도 보여주곤 했다. 물론 지금과는 비교조차 할 수 없는 열악한 화질이었지만 말이다. 그때는 RealAudio/Video도 있었으나, 컴퓨터와 네트워크 속도의 향상 덕분에 이내 mp3 등에 캐발리고 말았다. 그리고 얼마 안 가 넷스케이프도 IE에 완전히 발린다.

3.
맥 OS에는 애플에서 자체 개발한 사파리라는 브라우저가 기본 내장되어 있다. 비록 사파리는 크로스 플랫폼 프로그램이기는 하지만, 윈도우에서는 별 재미를 못 보고 있는 모양이다. <날개셋> 한글 입력기도 그렇게 윈도우, 맥, 리눅스를 다 날아다니는 프로그램이었으면 얼마나 좋을까?

그나저나 맥 OS 클래식은 9까지만 해도 메모리 보호와 선점형 멀티태스킹조차 지원되지 않았다니 대체 뭐야... 90년대 말까지 쓰이던 운영체제가 기술적으로는 그 허접한 윈도우 3.1과 다를 바가 없었다는 말인지? CPU가 16비트였는지 32비트였는지? PC 쪽과는 역사가 너무 다르니 그저 궁금할 따름이다. 어렸을 때부터 본인에게 매킨토시에 대한 이미지는, 전자 출판과 복잡한 그래픽 작업처럼 PC하고는 가히 넘사벽인 최고급, 최고가 컴퓨터였기 때문이다.

아울러 맥 OS X에는 그림판뻘 되는 간단한 그래픽 편집기를 내장하지 않고 있다는 것에도 깜짝 놀랐다. 워드패드와 메모장 둘의 역할을 훌륭하게 해 내는 TextEdit는 있지만 그림판에 대응하는 프로그램은 없다니... =_=

Posted by 사무엘

2010/06/18 08:55 2010/06/18 08:55
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/298

Trackback URL : http://moogi.new21.org/tc/trackback/298

Leave a comment

블로그 이미지

철도를 명절 때에나 떠오르는 4대 교통수단 중 하나로만 아는 것은, 예수님을 사대성인· 성인군자 중 하나로만 아는 것과 같다.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2018/06   »
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30

Site Stats

Total hits:
973163
Today:
0
Yesterday:
524