디테일에 강한 애플? 딴 나라 이야기.

 <편집자주> 민트기술에서는 외부 집필자의 도움으로 애플/맥에 관한 좋을 글들을 받아서, 홈페이지를 통해서 제공하려고 합니다.이번에는 한민석님께서 애플의 디테일에 관한 글을 기고해 주셨습니다.

들어가며
애플은 디테일에 강하다. iOS 제품 사진 속 9시 41분의 비밀은 이미 널리 알려진 이야기이고, 헤드폰과 스피커 볼륨을 기억하고, 헤드폰을 뽑으면 음악이 일시정지되며, 심지어 일부의 경우에는 연결된 헤드폰을 구별해 볼륨을 설정해준다고까지 한다. 그런 이야기는 잠깐 놀라고 나면 당연시 하게 되는데, 그러다가 애플이 정말 뭔가에 무신경하다고 느낄 때가 있다. 물론 한글에 관련된 이야기이다.
iOS 5에서의 새로운 한글 서체 도입과 상대적으로 빨랐던 신제품 국내 출시와 더불어 여러모로 에플의 한국 “대우”가 과거에 비해서 좋아졌다고 하지만, 애플이 한국에서 벌어들이는 연 2조 이상 매출과 일반적 인식에 비해 정말 당황스러운 것이 한 두가지 아니다.
거져줘도 안쓴다: 한글 자동교정

애플의 아이폰 제품 사양 소개에 따르면, 아이폰의 언어 지원에서 한국어는 (1) 언어 (2) 키보드 (3) 사전 (자동 입력 및 자동 교정 기능) 모두에 포함되어 있다. 영어, 일본어, 중국어 등 수십 개의 다른 지원 언어 중 하나이다. 과연 이 언어 지원에 대한 광고가 다른 비-영어 언어 환경에서 얼마나 정확한지 알지 못하지만, 한글 언어 지원은 정말이지 거져줘도 쓸 수 없는 쓰레기 수준이라고 해도 과장이 아니다.
아이폰의 자동 교정 기능은 사용자의 입력 패턴과 추천 단어 사용 여부에 따라 계속해서 정확성이 높아진다고 하지만, 정확한 구현 방식을 알지는 못한다. 하지만 한글 자동 교정 기능이 얼마나 엉망인지, 굳이 예를 들지 않아도 잘 알려져 있으리라 믿는다. 제대로 입력된 “칠월”을 “팔월”로 바꾸라고 한다든가, “ㄱ”을 잘못 입력한 “자공교정”을 다섯 철자가 다른 “자동소총”으로 교정한다든가 하는 식이다.
물론 해외에서 개발된 제품의 한글 지원이 일정 수준(읽기, 쓰기) 이상이고, 게다가 새 서체 도입으로 미관상으로도 괜찮아진 시점에서, 거의 대부분의 한글 사용자들이 자동 교정 기능을 해제할 수 있는 한 별 말없이 아이폰을 쓰고 있는 것이 현실인 듯하다. 하지만 iOS가 진정으로 국제화되고 세계에서 가장 진보된 운영 체제라면서 그냥 눈 감고 있기에는 너무한 것 아닐까.
영문을 중심으로 개발되고 지금도 계속해서 진보하고 있는 iOS의 자동 교정 기술이 아이폰의 국문 사용 환경에 얼마나 부적합한지 애플에서 알고 있다면, 적어도 항상 영문과 국문 키보드 모두를 사용할 수 밖에 없는 한글 사용자를 위해서 언어별 자동 교정 사용 여부를 선택할 수 있도록 해야하는게 아닐까. 어쩌면, 애플에서는 한글 사용자가 영문 사용자와 달리 한글 키보드만으로는 이메일 주소, 웹 페이지 주소 조차 입력할 수가 없다는 것을 모르는게 아닐까. 설마.
아마추어? 한글 애플 웹사이트
디테일을 논하면서, 애플코리아 홈페이지를 언급하지 않을 수가 없다. 작년 2011년 아이폰 4S가 처음 발표되었을 당시 애플코리아 첫 페이지를 장식한 오류를 보면, 애플 웹사이트의 한글화가 얼마나 대충 이루어지는지 알 수 있다.
엉망 진창인 줄 간격을 차치하고서라도, 아직 뭐가 잘못되었는지 못 알아차렸다면, 다시 한번 천천히 읽어보시라. 지금까지 가장 놀라운  iCloud? “It’s the most amazing iPhone yet”을 국문 번역하면 그렇게 바뀌나보다. (물론 몇 일 후 이 화려한 첫 페이지 오류는 수정되었다.)
그냥  첫페이지 문구 정도야(!) 한 번 실수할 수 있다고 쳐도 아래 오류들은 어떻게 봐야할까. (대부분 현재 접속해서 직접 확인 가능하다. 수정되기 전까지는.)

맥북에어가 참 탄탄한가보다. [MacBook Air – OS X] –> 수정됨 (2012년 7월 10일)

레티나 디스플레이 강점? 눈에 보이는 것이 전부인데. [iPad]
나가며
애플 제품을 정말로 아끼고 좋아하는 만큼 실망이 커지는 법. 실망을 안하려면 기대를 하지 말았어야 하는데, 연인 사이에서 그게 어디 쉬운가.

<편집자주> 본 컬럼의 내용은 민트기술의 의견은 아닙니다. 민트기술에 컬럼을 기고하실 분께서는 메일(wangsy@wangsy.com)로 문의 바랍니다.

맥 OSX과 터미널

<편집자주> 민트기술에서는 외부 집필자의 도움으로 애플/맥에 관한 좋을 글들을 받아서, 홈페이지를 통해서 제공하려고 합니다. 이번에는 김정님께서 OS X 과 터미널에 대한 글을 기고해 주셨습니다.


터미널(Terminal)이란 단어는 일상 생활 속에서도 익숙한 단어다. 하지만 OS X에서는 누구에게나 편하기만 하지않은 미지(?)의 영역이라고 할 수 있다. 복잡해 보이는 터미널 환경에 대해 이야기해보자.
 
우리가 알고 있듯이 터미널이란 단어의 뜻은 주로 “끝에 있는”, “마지막에 있는” 무언가를 의미한다. 그래서 버스 터미널은 버스 종착역을 의미한다. 그렇다면 OS X의 터미널 앱은 어떤 의미가 있는걸까? 그것은 컴퓨터 역사에서 터미널의 역할을 되짚어 보면 알 수 있다.

초창기 대형 컴퓨터들은 엄청난 크기의 몸집을 갖고 있었다. 그리고 커다란 본체 입력을 하기 위해서, 초창기에는 천공카드 입력기를 사용했지만, 점차 타자기처럼 생긴 작은 기계를 연결해서 사용했었다. 실제로 초창기 터미널들은 그림과 같이 타자기와 같은 모습이었다. (그래서 현재 UNIX/Linux에서 터미널을 의미하는 TTY라는 단어도 TeleTYpewriters 에서 나온 것이다)
 

대형 컴퓨터를 만드는 업체들이 차츰 UNIX 기반 운영체제를 사용하도록 진화해 가면서, 시분할 접속 방식으로 여러 사람이 동시에 접속해서 사용할 수 있게 됐다. 지금도 남아있는 RS-232 같은 시리얼 방식도 터미널에 연결 방식으로 도입되었고, DEC에서는 최초로 ANSI 규격을 준수하는 그림과 같은 VT100 현대적인(?) 터미널이 만들었다. 워낙 컴퓨터 제조사의 터미널 마다 화면에 글씨를 표시하는 방식이 다르기 때문에 ANSI 표준을 정했었다. 그리고 이 당시 대부분의 터미널의 글자색이 녹색이었고 ASCII 문자만 표시할 수 있었기 때문에, 지금까지도 터미널 앱에서 검은색 배경에 녹색 글씨로 쓰는 사람이 많다.

90년대 모뎀으로 접속하는 PC통신을 해본 사람들이라면 이미 터미널 화면에 익숙하다고 할 수 있다. 왜냐하면 당시의 국내 PC 통신 서비스들이 모두 터미널 기반의 접속 서비스였기 때문이다. 하늘소 팀에서 만든 “이야기”가 가장 인기 있던 터미널 에뮬레이션 앱이었다.
시간이 흘러서 개인용 컴퓨터가 발전하면서 대형 컴퓨터에 접속하기 위한 전용 터미널들은 의미가 없어졌다. 대신 PC에서 터미널을 에뮬레이션해서 다른 컴퓨터에 접속하도록 화면과 통신 프로토콜만 맞춰주면 되는 시대가 됐다. 맥 OS9까지는 zterm같은 에뮬레이터 앱은 있었지만 공식적인 터미널 앱은 없었다. 그렇지만 OS X부터 유틸리티 디렉터리에 터미널 앱과 함께 콘솔 앱까지 제공한다. 참고로 콘솔은 터미널과 비슷한 듯하지만 쓰임새는 사뭇 다르다. 터미널은 일반 사용자가 대형 컴퓨터에 입-출력을 하기 위한 것이라면, 콘솔은 대형 컴퓨터를 운영하는 운용자가 시스템을 관리하기 위해 로그을 확인하는 용도인 것이다. (물론 운용 명령어를 알고 있다면 터미널로 접근해서 마치 콘솔처럼 활용할 수 있다)

OS X는 FreeBSD가 기본적으로 포함되어 있고, 오픈그룹의 인증까지 받은 UNIX 머신이다. UNIX 명령을 사용하기 위해서는 당연히 가상의 터미널이 필요하게 되었고, 터미널에서 사용하는 수많은 UNIX 명령어들도 기본적으로 제공하고 있다. 사실 OS X의 수많은 기능들은 UNIX 명령으로 만들어져 있고, 명령의 결과를 GUI로 보여주기 위해 Aqua 윈도우 시스템을 활용하고 있다. 예를 들어 환경 설정 – Preferences 앱을 실행하면 시스템 혹은 홈폴더 아래 있는 /Library/Preferences/ 디렉터리에서 plist 파일들을 열어 화면으로 보여주고, 설정을 변경하면 이 파일들을 수정해서 저장한다. 그리고 이 파일들에는 환경 설정에서 보여주지 않는 숨겨진 기능까지 저장되어 있다.
OSX을 포함해서 모든 운영체제는 시스템 내부를 관리하고 프로그램을 실행하는 커널과 그 커널을 보호하기 위해 둘러싸고 커널의 기능 중에서 한정된 기능만을 사용하도록 하는 쉘이 있다. 여러 가지 쉘 중에서도 UNIX기반 쉘은 터미널에서 쓸 수 있도록 텍스트 기반의 쉘로 발전했고, GUI 기반의 매킨토시와 윈도 시스템은 탐색기나 파인더가 부분적으로 쉘 역할을 한다. OS X은 NeXTSTEP과 Mac OS의 화려한 GUI와 UNIX의 강력한 터미널 기능이 멋지게 결합된 형태라고 할 수 있다. 따라서 터미널 앱을 실행하고 OS X에 접근하기 위해서는 UNIX 쉘과 명령어들에 익숙해져야 한다. 결국 OSX의 터미널 앱은 UNIX 쉘을 사용하기 위한 접속 도구일 뿐인 것이다.
다음에는 OS X의 터미널에서 사용하는 여러 가지 쉘 환경과 유용한 명령어들을 살펴보도록 하겠다.

<편집자주> 본 컬럼의 내용은 민트기술의 의견은 아닙니다. 민트기술에 컬럼을 기고하실 분께서는 메일(wangsy@wangsy.com)로 문의 바랍니다.

사용자 인증과 친구 찾기

<편집자주> 민트기술에서는 외부 집필자의 도움으로 애플/맥에 관한 좋을 글들을 받아서, 홈페이지를 통해서 제공하려고 합니다. 이번에는 박세현님께서 아이폰에서의 개인 정보 문제에 대한 글을 기고해 주셨습니다.

많은 iOS용 SNS/메시지 앱 들이 최초 가입 과정을 전화번호 인증으로 대신한다. 또, 인증된 사용자의 친구를 자동으로 찾아주기 위해, 주소록 데이터를 서버에 올려 사용한다. 이 두 기능으로 사용자에게 빠르고 편하게 서비스를 제공할 수 있게 된다.
그러나 두 가지 기능 모두 애플로 부터 “사용 금지” 처분을 받게 될 것으로 보인다.
주소록 데이터 사용 
주소록 데이터 사용 건부터 먼저 살펴보자. 주소록 데이터를 가져다가 친구맺기에 쓰는 경우는 이전부터 허다하게 많았는데, 최근 이 문제가 붉어진 이유는 바로 Path 때문이었다. 미려한 UI, 사진 필터링 등으로 많은 인기를 얻은 이 앱이 사용자 동의 없이 주소록 데이터를 서버로 올리고 있다는 사실이 블로거 Arun Thampi에 의해 알려졌기 때문이다.
Path의 CEO, Dave Morin이 블로그에 사과 글을 재빠르게 올리고, 수정한 버전을 앱스토어에 등록했지만 이 사건의 여파는 쉽게 가라앉지 않았다. 눈치 빠른 개발사들은 사건의 심각성을 파악하고, 신의 앱이 주소록 정보 사용 시 사용자의 동의를 구하도록 변경하거나, “친구 찾기”와 같은 문구를 “연락처 업로드하기”로 변경하고 있다.
미 의회의 Henry Waxman과 G.K. Butterfield 의원도 이 사건을 가볍게 보지 않고, 애플에 해명을 요구하였다. (서신을 통해 전달한 8가지 정도의 관련 질문의 답을 2월 29일까지 요구하고 있다.)
일단 애플은 대변인 Tom Neumayr를 통해, 이에 대한 해결책을 제시하긴 했다. 주소록 정보에 접근할 때, 사용자의 허가를 구하는 방식인데, 이는 애플리케이션이 사용자의 위치 정보를 사용하고자 할 때, 알림 팝업을 통해 동의를 구했던 것과 유사할 것이다.
캘리포니아 주 법무부의 최근 발표는 여기서 한단계 더 나아갔다. 모바일 앱 시장을 제공하는 여섯개 업체(애플과 구글, 아마존, HP, MS, RIM)가 모두 동의했다는 새 표준에 따르면, 앱 스토어에서 다운받는 앱의 개인 정보 정책을 미리 확인 할 수 있게 된다. 또한, 이 사항을 위반하는 앱을 쉽게 신고할 수도 있어야 한다. 이를 위반하는
개발사는 캘리포니아 주법을 위반하는 상황에 처할 수도 있다 하니, 많은 앱의 개인 정보 활용 정책을 분명히 파악하기가 쉬워질 것으로 보인다.
Path로 시작된 이 문제는 사실, 국내 개발사 입장에서는 큰 이슈가 아닐지도 모르겠다. 이미 대부분의 SNS/메시징 애플리케이션은 이미 첫 구동시(혹은 가입시)에 개인 정보 활용 동의를 해야만 서비스를 이용할 수 있으니 말이다. 혹, 지금껏 그리 하지 않았더라도 이제 동의 절차를 추가하고 (개발사가 안하더라도 새 버전의 iOS에서 알아서 처리가 될 터이고) 언젠가 앱 스토어의 개인 정보 정책을 채워넣기만 하면, 주소록 데이터의 사용 자체가 막힌 것은 아니니까.
전화번호 인증
사실 당면한 더 큰 문제는 아마 전화번호 인증 “금지”일 것이다. 번거로운 가입 절차를 사용하는 ID/Password 시스템 대신, 전화번호 인증을 통해 사용자를 “가입과 동시에 구분”하는 방식은 대다수의 SNS/메신저 애플리케이션이 사용하는 인증 방식이다. 국내 메신저 서비스인 카카오톡 뿐만 아니라 WhatsApp도 사용하고 있고, 심지어 페이스북의 메신저 앱도 이 방식을 사용한다.
애플이 공식적으로 “SMS 인증을 금지”한다고 한 적은 없는 것으로 알고 있지만, 이로 인해 카카오톡이 업데이트가 지연되고 있다는 뉴스가 간헐적으로 들려왔었다. 국민 메신저 앱인 카카오톡의 업데이트를 지연시키고, 인증 방식을 변경하라는 요구가 국내 언론에 곱게 비춰지지는 않는 것 같다.
“애플 관계자”에게 문의해본 결과, 뉴스에 나온 대로 SMS를 통한 사용자 인증을 금지시킬 계획인 것으로 보였다. 일단 추측할 수 있는 이유는, 주소록 사건과 마찬가지로 “개인 정보 보호”를 위함이라고 해석할 수 있을 것이다. 애플이 사용자 개인의 정보나 디바이스에 해당하는 정보의 사용을 막은 것은 이번이 처음이 아니다. 작년 하반기 경, iOS 5가 출시되면서 UDID(디바이스 식별정보)를 사용해 디바이스나 사용자를 인증(혹은 식별)하는 방식을 금지시킨 전례가 있었다. 그 전까지, 이 정보를 통해 디바이스를 구분하던 업체들은 UUID라는 고유 키를 사용하거나, 인증을 위한 다른 방법을 새로 고안할 수밖에 없었다. 이 때에도 애플은 개인 정보 보호라는 명목으로 UDID사용을 막았다.
SMS 인증이 가진 다른 문제는 휴대전화 분실이나, 전화번호 변경 등을 생각해 볼 수 있을 것이다. 사용자를 식별하는 정보가 분실되거나, 변경되는 경우 해당 사용자의 기존 데이터가 다른 사람에게 유출되거나, 기존 사용자가 복원할 방법을 찾기가 어려워진다는 문제가 있다. iPad와 iPod Touch를 판매하는 애플 입장에서는, 이 두 기기만 쓰는 사용자에게는 서비스가 제한될 수 있다는 점이 마음에 안들었을 수 있다. 그러나, 이런 이유로 SMS 인증을 막은 것 같지는 않다. 정확한 이유는 모르겠지만 일단 가장 겉으로 보이는 가장 큰 이유는 개인정보 보호일 것이다.
해결책 
애플이 그렇게 하겠다니 뭐 어쩌겠는가? 일단 급한대로 해결책을 마련해야 하지 않겠는가? 결국은 애플이 제시하는 방향으로 갈 수 밖에 없을 것이다.
주소록 문제는 간단하다. 사용자에게 주소록 정보 사용에 대해 알려주고, 동의를 구하면 될 것이다.
그럼 SMS인증은 어찌하나?

어쩔 수 없이, ID/Password 방식으로 가야할 것이다. Facebook이나 Twitter 계정에 빌붙는 방법도 있겠다. 어쨌든 SMS를 통한 사용자 인증은 더 이상 허용되지 않을 것으로 보인다.
주소록 데이터와 SMS 인증, 두 개의 별개의 문제가 한 곳에서 만나는 지점은 바로 ‘친구 찾기’ 기능이다. (사실, 이 기능 때문에 이 글을 주절주절 쓰게 되었다.) 주소록 데이터에 등록되어있는 친구들의 연락처(주로 전화번호)로 친구맺기 서비스를 제공하려면 사용자의 전화번호를 받아야만 한다. (그리고 그 번호가 해당 사용자의 번호인지 인증해야만 한다.) 다행이도, 사용자 인증을 위한 SMS의 사용은 금하지만, 사용자가 친구 찾기를 위해 자신의 번호를 등록하는 것은 허용할 것으로 보인다.
절차가 좀 번거로워지긴 하지만, id/password (혹은 다른 방식의) 사용자 인증 후, “친구 찾기”를 위한 주소록 데이터 사용 동의, 개인 전화번호 등록 등의 과정을 거친다면, 기존의 자동 친구 맺기 기능은 사용자의 명시적인 동의 하에 계속 서비스할 수 있을 것이다.
애플의 속셈?
개인 정보를 보호하고픈 애플의 의도는 이해가 간다. 그런데 SMS 인증을 막는 것이 정말 그 때문일까?
나는 다음 두 가지 정도의 숨은 의도가 있지 않나 추측해본다.
1. 전화 번호의 기능 축소
전화 번호는 통신기기에만 부여되는 식별 번호이다. 한 개인이 여러 개의 번호를 갖기도 힘들고(돈이 많이 들고), 맥과 iPad, iPod Touch와 같이 전화번호와 사실 별 상관 없는 기기들도 많이 존재한다.
그리고 무엇보다도 전화번호는 애플이 통제하기 쉬운 시스템이 아니다. 여전히 통신사에 속한 영역인 것이다.
애플 입장에서는 애플 기기에서 돌아가는 서비스에서 사용자 간의 네트웍을 구축하는 식별 정보로 전화번호를 쓰기보단, 이메일을 쓰는 것이 더 편하다. FaceTime 앱이나 OS X용 Messages 베타를 사용해보면 이 말이 무슨 의미인지 알 수 있을 것이다. 이메일을 쓰면, 아이폰 간 커뮤니케이션 뿐만 아니라, (전화번호와 상관 없는) 각종 기기 간의 통신이 훨씬 수월해진다.
2. 애플이 제공하는 인증 시스템
첫 번째 추측에 더해, 애플은 아예 애플의 계정(.Mac, MobileMe, iTunes, iCloud 계정으로 뒤죽박죽이 되어버렸으나 iCloud로 통합하고 싶어보이는) 시스템으로 모든 사용자의 인증과 식별을 전부 통합하길 원할지도 모른다.
Game Center와 같이 애플이 제공하는 API를 통해 사용자를 인증하는 시스템을 도입해 준다면 어떻게 될까?
애플리케이션을 처음 구동할 때, 인증 서비스를 사용할 지 묻고, 애플 계정을 입력하면 애플리케이션에는 특정 키를 내려주는 식으로 처리할 수 있을 것이다. 아니면 Game Center가 그냥 더 확장되어 일반 애플리케이션에서도 커뮤니케이션과 인증 용도로 사용할 수 있게 되거나…
물론 이 시스템은 iOS와 OS X을 사용하는 환경에서만 동작하겠지만, 이는 현재 Game Center도 마찬가지다. 그럼에도 불구하고, 모바일 시장의 메이저 플레이어인 애플이기에, 많은 게임 개발사들은 Game Center를 지원한다. (물론, 타 플랫폼과의 호환을 위해 별도의 랭킹 시스템을 함께 도입하는 경우도 많다.)
이런 기능이 도입되면, 멀티 플랫폼 개발자 입장에서는 id/password 시스템과 병행해야하는 부담감이 적지 않을 것이다. 그러나, 그것은 개발사의 문제이지, 애플의 문제가 아니다.

<편집자주> 본 컬럼의 내용은 민트기술의 의견은 아닙니다. 민트기술에 컬럼을 기고하실 분께서는 메일(wangsy@wangsy.com)로 문의 바랍니다.