가끔은 만나는 분으로부터 홈페이지에 소개된 조건들을 언급하며 부럽다는 말씀을 듣게 되는 적도 있습니다. 그럴때마다 스스로 좋은 회사라 자부하고, 이렇게 좋은 조건에도 왜 많은 사람들이 지원하지 않을까 생각해 본 적도 있었습니다.

하지만, 요즘 하루가 다르게 더 좋은 조건을 제시하는 회사들이 나타나는 듯 합니다. 세간에 화제가 된 회사 뿐 아니라, 적지 않은 스타트업에서도 파격적인 대우를 제시하는 것들을 접하게 됩니다. 좋은 인재와 함께 하기를 바라는 마음에서 그런 대우를 보게 되면 우리도 뒤지면 안되는데 하는 걱정이 앞서게 됩니다. 대찬 조건을 내세울 수 있는 능력이 부럽기도 하고, 상대적 박탈감에 시기심이 느껴지기도 합니다. 베팅 경쟁에 빠진 도박판에 있는 것 같기도 하고, 여기서 밀리면 안된다는 절박감이 들 때도 있었습니다. 하지만 이미 너무 멀리 달아나 쫒아가기도 힘들게 된 것 같기도 합니다.

언젠가 80대 한 부호가 자신의 엄청난 재산을 내세우며, 18세 처녀를 구한다는 것을 본 적이 있습니다. 많은 지원자가 따랐다는 이야기도 있었습니다. 처음에는 단지 요지경이라는 생각이 들었습니다. 하지만 그렇게 해서 만난 두 사람의 대면 상황과 내면 상황은 어떨까 상상하게 되었습니다. 그리고 어쩌면 비약일 수 있겠지만, 우리에겐 그런 모습이 없는지 반추하게 됩니다. 우리는 서로에게 무슨 기대를 하고 있을까요?

끌리는 조건과 대우를 제시하고, 거기에만 이끌려 생긴 만남이라면, 과연 아름다울 수 있을까? 화려한 조건으로 유혹하고는 서로에게 진심을 요구하고 있는 것은 아닌가? 우리는 아름다운 모습을 하고 있는 것일까요?

물론 화려한 조건의 대부분은 회사의 진심을 담고 있다고 생각합니다. 보이는 것이 믿는 것이라고, 공허한 약속, 보장되지 않는 미래의 일 보다는, 손에 잡히는 실질적인 혜택이 진심을 반영한다고 생각합니다. 김중배와 심순애 사이의 다이아몬드가 진심 일수도, 서로의 진심을 벗어날 수도 있습니다. 딱히 정의할 수는 없지만, 우리는 그 경계를 넘어가는 순간을 느낄 수 있습니다.

어짜피 회사라는 것이 금전적 이익을 목적으로 모인 집단이라 정의할 수도 있겠지만, 여전히 본질은 사람과 사람의 만남인 것은 부정할 수 없습니다.

사춘기 소녀의 마음으로 돌아가려고 합니다. 빨간머리 앤이 말하는 운명적인 만남을 기다리려 합니다.

우리는 우리가 하는 일이 매력적이기를 바랍니다.

우리는 우리의 일하는 방식이 매력적이기를 바랍니다.

우리는 우리 스스로가 함께 일하기에 매력적인 사람들이 되기를 바랍니다.

우리가 매력적일 수 있도록 계속적으로 노력할 것입니다.

그리고, 만남이 영원히 오지 않아도 좋습니다. 그냥 순수한 마음을 잃지 않고 싶습니다.

하지만, 오픈마켓이 되는 것은 쉬운 일이 아니었습니다. 아마도 오픈마켓이라는 명목으로 좋지 않은 경제적 사기사건이 많았던 것 같습니다. 그래서 자격을 까다롭게 하고 진입장벽을 높여놓았습니다. 우리는 시작부터 오픈마켓이 될 자격이 없었습니다. 오픈마켓이냐 아니냐의 구분은 판매상품에 대한 책임을 누가 지냐는 것으로 구분합니다. 판매하는 상품을 직접 책임을 지면 쇼핑몰이고, 상품을 판매할 수 있는 자리만 제공하고 중개하는 역할만 한다면 그것은 오픈마켓입니다. 대부분 오픈마켓 사이트에 가면 하단에 조그맣게 “본 제품에 대한 책임은 해당 오픈마켓에 있지 않습니다”라고 쓰여져 있습니다.

그래서 우리는 종합쇼핑몰을 하기로 했습니다. 오픈마켓이라는 목표는 이후로 미루고, 당장은 종합쇼핑몰로 시작하기로 계획했습니다. 우리가 직접 제품을 구매해서 제품을 판매하는 서비스를 만들기로 했습니다.

우리는 모두가 소프트웨어를 만드는 사람입니다. 상거래에 대해서 잘 알지 못합니다. 소프트웨어가 전문가가 아니면 쉽게 접근할 수 없듯이, 상거래도 엄연한 전문분야 입니다. 경험없고, 기본 지식 없이 함부로 뛰어들어서 할 수 있는 그런 영역은 아닙니다. 하지만 또다른 딜레마가 있습니다. 우리는 쇼핑몰 플랫폼을 만들고 싶은데, 아무도 사용하지 않는 플랫폼은 검증될 수 없습니다. 발전할 수도 없습니다. 머리속으로 상상해서 만들어서 좋을 것이라고 가정하는 것은 아무런 의미가 없습니다. 실제로 사용되고, 끊임없이 피드백을 받고, 불평불만을 받아들여서, 개선해 나가야만 좋은 플랫폼으로 모습을 갖출 수 있습니다. 그럴려면, 소프트웨어만 집중해서는 안되고, 실제 서비스를 오픈하고 사람들로 하여금 사용되게끔, 다시 말하면 주문이 들어오게끔 해야 합니다.

사실 이것이 우리의 딜레마의 시작인 것 같습니다. 말로는 좋은 앱, 좋은 서비스를 만드는 것에 포커스 한다고 했지만, 막상 성공의 방정식은 쇼핑몰의 판매량으로 판단하려고 한 것 같습니다. 생각만으로는 좋은 쇼핑몰 서비스에서 시작해서 좋은 상품을 갖추고, 많은 사람들이 들어와서, 많이 주문을 함으로써, 많은 피드백을 받아, 다시금 좋은 서비스로 거듭난다는 시나리오를 그릴 수 있지만, 처음 시작하는 시점에서 좋은 서비스 제작, 좋은 사용자 경험 제공, 많은 주문, 쇼핑몰로써의 성공을 모두 같은 톤으로 강조하는 것은 혼란스러울 수 밖에 없다고 생각합니다.

그래서 많은 사람들이 걱정하기 시작했습니다. 개발을 하면서도 많이 팔려야 할텐데… 과연 쇼핑몰로써 경쟁력이 있을까? 나라면 과연 여기서 물건을 살까? 내가 늘 이용하는 쇼핑몰에 비해 우리는 무슨 장점이 있을까?

그러다가 그것이 절망으로 이어질 수도 있습니다. 에이 안될꺼야… 잘될 이유가 없는걸… 도대체 무슨 이유로 여기서 물건을 사야하는 것을 설득할 수 있을까?

다른 비유를 들어보도록 하겠습니다.

푸드코트를 오픈하기로 했습니다. 우리는 모두 건축가 입니다. 좋은 푸드코드를 설계하는 것을 고민하기 시작했습니다.  좋은 식당이 갖추어야 할 건축물에 포커스를 했습니다. 그러다 그 푸드코트를 직접 경영하기로 했습니다. 그리고 시간이 지나다 보니, 승부는 맛에서 난다는 것을 알게 되었습니다. 어떻게 하면 맛있는 식당이 될 수 있을까? 건축가가 하는 맛있는 식당에 대한 고민, 혼란스러울 수 밖에 없습니다.

그래서 우리는 처음으로 돌아가서, 좋은 쇼핑 플래폼이란 무엇인가를 고민하기 시작했습니다. 편리한 쇼핑 경험이란 무엇일까? 사용자가 가장 손쉽게,가장 편안하게 쇼핑을 할 수 있는 방업은 무엇일까 고민을 해야 한다고 생각했습니다. 무슨 상품이 잘 팔릴까? 어떻게 하면 고객이 원하는 가격에 상품을 제공할 수 있을까? 같은 고민은 잠시 내려놓기로 했습니다.

우리는 우리가 가지고 있는 모든 기술적 경험을 동원해서, 사용자가 가장 편리한 방법으로 쇼핑을 할 수 있는 방법을 제시하려고 합니다.

쇼핑이라는 말에는 여러가지 사건을 포함하고 있습니다. 때로는 아이쇼핑과 같이 상품을 둘러보는 행동 일 수도 있고, 결심한 상품을 구매하는 과정 일 수도 있습니다. 요즘은 쇼셜커머스와 같이 신뢰할 만한 상품을 발견하는 과정일 수도 있고, 특별한 가격에 특별한 상품을 살 수 있는 기회를 포착하는 과정일 수도 있습니다. 우리는 이중에 가장 기본적인 상품을 둘러보고, 상품을 구매하는 과정에 촛점을 맞추기로 했습니다.

현재 가능한 모든 기술을 동원해서, 쇼핑의 가장 기본적인 과정을 가장 아름답게 풀어내는 것이 숙제 입니다. 매력적인 상품, 구미를 당기는 가격, 노련한 판매 수단 이것들이 없어도 상관없습니다. (이것들이 필요없다는 뜻이 아닙니다) 적어도 우리는 우리가 가장 잘 할 수 있는 분야에서, 가장 어려운 문제를 먼저 풀고 있으니까요.

이것이 mintshop 이 하려고 하는 과제 입니다.

민트기술에서는 두어달 전부터 쇼핑몰 프로젝트를 시작했습니다. 사실 많이 공유하지는 못했지만, 민트샵을 시작하기까지도 많은 우여곡절이 있었습니다. 올 초부터 자체 프로젝트를 다각도로 시도하였고, 가시적인 성공은 거두지 못했지만, 나름 여러 시행 착오를 거치는 중이었습니다. 그에 반해 좋은 조건도 갖추어 졌습니다. 외부 웹개발자를 영입하여, 웹 서버쪽 개발 능력이 갖추어졌습니다. 그래서, 유틸리티성 앱개발만 가능했던 것에서, 서비스 개발도 가능해 졌습니다.

그래서, 제가 개인적으로 오래동안 숙원해 오던 쇼핑몰 프로젝트를 시작하게 되었습니다. 이 과정에서 다같이 공감하게 되는 과정이 없었던 점이 많이 아쉬운 점으로 남아 있습니다. 그래서, 이참에 공감이 될지는 모르겠지만, 쇼핑몰 프로젝트를 시작하는 생각을 공유하려고 합니다.

일단 온라인 쇼핑몰이 오랫동안 개인적으로 의미한 것은, 내가 나름 꽤 많이 사용하는 서비스, 하지만 사용성이 너무 많이 떨어지는 서비스, 나 개인적으로 꽤 많이 만들어 온 서비스, 하지만 만들기만 했을 뿐 그 어떠한 의견도 받아들여지지 않았기 때문에, 나또한 내가 엉터리라고 생각한대로 만들수 밖에 없었던 서비스 였습니다. 내가 많이 사용하지만, 그리고 서비스의 사용성은 형편없이 떨어지지만, 다른 대안이 없기 때문에 (시장지배력, 혹은 법적인 조치) 벗어날 수 없는 또 다른 예로 대표적인 것인 인터넷 뱅킹이 있었고, 아이폰이 나오기 전까진 모바일 디바이스도 그랬었습니다. 둘은 내가 해결할 방법이 없지만, 그나마 쇼핑몰은 내가 할 수 있지 않을까 하는 생각을 가져 볼 수 있는 부분이기도 합니다. 해외의 우수한 온라인 쇼핑 서비스를 이용하며 그 편리함과 우수함에 부러움을 감출 수 없었습니다. 나도 이런 것을 만들고 싶다. 물론 국내에도 이런 서비스의 시도가 없었던 것은 아니지만, 여러가지 이유로 나의 이러한 소망을 접기엔 아직 부족한 것이 많았습니다.

그리고, 또 한가지. 인터넷 세상이 많이 바뀌고 있다는 점입니다. 대략 2000년을 기점으로 본격적인 온라인의 시대로 이동하였다면, 2010년을 기점으로 본격적인 모바일의 시대로 이동하고 있다는 점입니다. 즉 온라인 시대로 넘어오면서 없던 온라인 쇼핑의 카테고리를 새롭게 만들면서 그 기틀을 잡았다면, 이제는 모바일 쇼핑의 기틀을 잡을 시점이라는 점입니다. 온라인 쇼핑은 개인적으로는 만족스러울 수 없지만, 어느정도 새로운 틀이 들어갈 수 없는 견고한 상태입니다. 그에 반해 모바일 쇼핑은 아직 틀이 마련되지 못했습니다. 그래서 바로 이 시점이 모바일 쇼핑을 중심으로 새로운 틀을 짤 수 있는 기회라는 생각을 했습니다.

모바일이라는 것은 단지 핸드폰 단말기를 말하는 것은 아닌 것 같습니다. 제가 이해하는 것은 오히려 멀티디바이스에 더 가깝습니다. 일찍이 Tim O’Reilly 는 주변에 있는 얼리어댑터, 해커와 같은 집단을 Alpha Geek 이라 부르고 그들이 하는 행동 패턴이 곧 다가올 미래에 일반인들이 사용할 것이라고 했습니다. 마찬가지로 내 주변의 매우 편향되어 보이는 집단이지만, 이들이 편리하다고 생각하는 것이 머지않은 미래에 곧 모두가 편리하다고 생각할 것이라 생각합니다. 이들의 행동 패턴은, 자하철에 서 있을 때에는 핸드폰 단말기를 들여다 보고, 쇼파에 앉아서는 태블릿을 사용하고, 까페에 앉을 때에는 노트북을 열고, 책상 앞에 앉아서는 데스크탑을 사용 합니다. 이것이 모바일 세상이고 이런 멀티 디바이스 사이를 자연스럽게 연결해 주는 것이 바로 모바일 세상이 가져다 준 축복이라 생각합니다.

이러한 생각을 담은 쇼핑 서비스는 국내에 아직 없는 것 같습니다. 해외도 아직 없는 것 같습니다. 하지만 앞으로도 계속 없을 것 같지는 않습니다. 매일 매일 관련하여 쇼핑과 관련한 좋은 시도를 발견하고 있고, 아직 내 눈에는 보이지 않았지만, 기막힌 서비스들이 많이 준비되어 있다는 생각이 듭니다.

우리도 여기에 참여하고 싶습니다. 우리가 새롭게 올 모바일 쇼핑의 세상에서 주역이 되면 너무 좋겠지만, 그렇지 않아도 좋습니다. 새롭게 그려질 그림의 한 획이라도 그려넣었으면 좋겠다는 생각이 먼저입니다. 좋지 않은 사용성을 가진 방식이 시장지배력을 바탕으로 굳히기에 들어가기 전에, 많은 사람에게 좋은 모바일 쇼핑 서비스를 경험하게 하고 싶은 마음입니다.

예전 90년대, 내가 원하는 물건을 찾아 온 시장을 발품팔며 돌아다니던 시절의 기억이 있습니다. 소비자에게 정보가 거의 없는 제품일수록 온갖 사기꾼들이 기생하며 살던 적이 있었습니다. 인터넷 쇼핑은 이러한 상거래의 모습을 완전히 뒤집어 놓았습니다. 저는 아직은 모르지만, 모바일 상거래가 이만큼, 혹은 이보다 더 큰 변화를 가져다 줄 거라는 생각을 가지고 있습니다. 아직 답을 찾지 못했을 뿐이죠. 그 답을 찾아 나가는 과정을 해 보고 싶습니다.

기회가 허락한다면 말이죠.

http://mintshop.com

민트오피스 사이트는 제가 개인적으로 몇년 전부터 간단히 진행을 하다가, 4월부터는 외부개발자 강성희님의 도움을 받아서 같이 진행하고 있습니다. 개발은 Ruby On Rails 를 이용해서 개발하고 있습니다.

우리회사는 오래전 웹개발을 할 시절부터 대기업 혹은 공공기관의 사내 ERP 혹은 그 부속 사이트 웹 개발에 많은 참여를 하였습니다. 최근에는 모바일 개발을 한참 하면서, 모바일 오피스 개발에도 참여를 하고 있습니다. 이렇게 개발을 하다보면, 우리 회사랑은 전혀 어울리지 않고, 저런 것은 어디에 필요할까 하는 부분도 있지만, 또 어떤 것은 우리회사에도 저런 도구가 있으면 좋겠다는 생각을 갖게 하는 것도 많이 있습니다. 하지만 우리회사 같은 작은 회사가 대기업이나 공공기관 같이 대규모 사업발주 하여 스스로 개발해서 쓴 다는 것은 엄두가 잘 나지 않는 일입니다. 우리회사는 그나마 개발회사라 시도는 해 볼 수 있겠지만, 그렇지 않은 회사는 이러한 시도도 해 볼 수 없겠다는 생각이 들었습니다.

물론 시중에는 많은 ASP 서비스들이 존재합니다. 중소기업을 위한 각종 패키지와 서비스가 즐비합니다. 하지만 개인적으로는 매우 낯설게 느껴 졌습니다. 저뿐만 아니라 그렇게 생각하는 사람들이 적지 않게 있을거란 생각이 듭니다. 왜냐면, IT 에 종사하는 많은 회사들이 웹, 모바일 등등에는 매우 익숙하지만, 이러한 도구에는 매우 낯설어 하기 때문입니다. 그래서, 우리에게 맞는 도구를 직접 만들어야 겠다는 생각을 하기 시작했습니다.

민트오피스의 일차적인 목표는, 민트 내부 목적에 충실하자 입니다. 우리에게 꼭 필요한 것을 하나씩 만들어 가기 시작했습니다. 회사 조직 관리, 회계관리 등의 기본 개념은 매우 부족하지만, 우리가 아는 언어로 우리가 이해하는 언어로 시스템을 만들어 쓰면 좋겠다는 생각을 가지며 진행을 해왔습니다.

민트오피스의 주요 기능은 다음과 같습니다.

• 인사 관리
• 사원 정보 관리
• 경력증명서 PDF 출력
• 근태 관리
• 휴가 관리
• 연봉 관리
• 급여 관리
• 입사지원 시스템
• 신규 입사자 지원 시스템
• 회계관리
• 세금계산서 관리
• 은행 계정 관리
• 신용카드 계정 관리
• 소액 현금 관리
• 지출 내역 관리
• 원장 관리 및 전표 관리
• 은행계정/신용카드 계정의 엑셀파일 업로드를 통한 입력
• 각종 보고서의 엑셀/PDF 파일 출력
• 프로젝트 관리
• 프로젝트별 원가 산출
• 프로젝트별 리소스 관리
• 문서 관리
• 연락처 / 거래처 관 리
• 구글 연락처 연동 기능
• 계정 관리
• 구글/다음/네이트 연동

아직은 완전히 구현했다기 보다는, 기능만 벌려놨다는 점이 없지않아 있습니다. 아마도 빠르면 올해말쯤 되어야 우리 내부적으로 쓸만하지 않을까 싶습니다. 그래도 조금씩 만들때마다, 직접 써 가면서, 피드백을 통해서 보강해 가기 때문에, 무언가 스스로에게 유용함을 준다는 느낌은 있는 것 같습니다.

위 기능은 대부분 웹으로 구현하였습니다. 하지만, “반응형 웹디자인”을 통해서, 태블릿, 모바일폰에서도 쉬운 접근이 가능하도록 하려고 하고 있습니다. 그리고 필요하다면, 모바일앱을 통한 기능 향상도 꽤하고 있습니다.

우리 스스로에게 충분이 유용하다면, 우리와 같은 입장의 작은 회사들도 이런 서비스를 제공하면 좋겠다는 바람을 가지고 있습니다. 언제가 될지는 아직 잘 모르겠습니다.

첫번째 버젼이 작년 11월 이니, 대략 8개월 만입니다. 사실은 대부분 작업은 작년에 다 이루어 졌으나, 여러가지 법적 문제 때문에 많은 고민이 있었습니다.

현재, 고스톱의 경우 사행성 게임으로 청소년 이용불가 등급입니다. 하지만, 대표적인 모바일 앱스토어인 애플 앱스토어와 구글의 플레이 마켓은 우리가 파악하고 있기엔, 한국 스토어에는 청소년 이용불가 등급을 올릴 수 없는 것으로 알고 있습니다. 그래서, v1.0 의 경우, 올려두었지만, 사실상 대부분 국내에서는 받을 수 없는 처지였습니다. 그래서 애써 준비된 v2.0 의 경우도 마무리를 해서 올리는 것이 쉽지 않게 되었습니다.

하지만, 오랜 시간이 지난 뒤에야, 다시 본래의 뜻으로 돌아가서, 진행을 마무리 해야 겠다고 생각이 들었습니다. 그래서, Android, iOS 버젼을 업데이트 진행을 마무리 하고 공개하기로 하였습니다.

v2.0 의 가장 큰 특징은 “세로보기” 입니다. 80맞고의 최초의 기획은 iPad 를 고려하여 만들었습니다. 모든 디자인이 iPad 크기에 최적화하여 작업하였습니다. 그러다 보니, iPhone 이나, 7인치 이하의 Android 폰에서 게임을 하기에는 편하지 않은 문제점이 있었습니다. 그래서 폰전용 사이즈인 “세로보기”를 만들었습니다. Android 의 경우 화면 크기를 알기 어려운 점이 있어서, 가로보기, 세로보기 모두 지원하며, 서로 전환할 수 있도록 하였습니다. iOS 의 경우에는 폰의 경우 세로보기로, iPad의 경우 가로보기로 동작하도록 만들었습니다. 또한 한손으로 게임을 하기 편하게, 패를 하단에 배치하는 등, 편의성도 고려하였습니다.

iOS 의 경우 아직, 등록전입니다. Android 의 경우, Google Play 에는 현재 내린 상태이며, Tstore에 등록한 상태입니다. 청소년 이용불가이기 때문에, 로그인을 해야만, 게임을 볼 수 있습니다.

현재 v3.0 버젼을 준비중에 있습니다. v3.0 버젼의 경우 Mac OS X 버젼을 준비하고 있습니다. iPad 버젼을 포팅하여, Mac AppStore 에서 게임을 받을 수 있도록 할 예정입니다.

v4.0 이후에는 iCloud 지원, 그리고 대망의 네트워크를 통한 대전을 지원할 예정에 있습니다. 이후에도 계속 80맞고를 발전시켜나갈 생각입니다.

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

들어가며

애플은 디테일에 강하다. 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)로 문의 바랍니다.

오늘은 본 프로젝트의 시작에 앞서, 이 프로젝트 진행에 관해서 논했습니다.

• 해야 하는 다른 프로젝트가 생겼습니다. 그래서, 다르 프로젝트 진행과 본 프로젝트 진행을 어떻게 해야 할지 고민했습니다.
• 결론은, 일단, 이 redmine tool 프로젝트가 왠만큼 완성될 때까지 지속한다 였습니다.
• 그래서, 선을 그엇습니다.
• 3월 세째주, 3월 16일까지 redmine tool 을 어느정도 진행한다로 목표를 삼았습니다.
• 저희 예측으로는, 그때쯤이면 릴리즈 가능한 모양새가 나올 것 같습니다.
• 그리고, 그 다음부터는 다른 프로젝트를 진행한다.

일단 여기까지 토론하는데, 시간이 꽤 걸렸습니다. 그래서 오늘은 개발에 시간이 조금 모자랐습니다.

본격, redmine tool 개선에 관해서 논의를 했습니다. 일단, 지난번에 다 채우지 못한 기능을 채우는데 촛점을 맞추기로 했습니다. 오늘은 하지 못하지만, 좋은 제안도 나왔습니다.

• 새로운 이슈를 생성하는 창 만들기
• 이슈간 선/후 관계, 부모/자식 관계를 비주얼하게 보여주는 창. 사실 레드마인에서는 복잡한 관계를 형성할 수 있게 해 주지만, 이것을 한눈에 알아볼 수 없기 때문에 쉽게 사용할 수 없는 단점이 있습니다.

일단 위 안은 좋기는 하지만, 만들기 간단하지 않기 때문에, 잠시 접어 두고 아래와 같은 기능 개선에 촛점을 맞추기로 했습니다.

• webpage 링크
• 현 이슈 웹페이지
• 새 이슈 만들기 웹페이지
• 하위 이슈 만들기 웹페이지
• 위키 목록 웹페이지
• 이슈 컨트롤
• assignee 바꾸기
• 시작/종료시간 바꾸기
• 목표버전 바꾸기
• 추정시간 변경
• 우선순위 변경
• 필터
• 내 이슈 보기
• 다른 사람 이슈 보기
• 목표버전별로 보기
• 이슈목록 5개 해제
• 시간 추적
• 타이머 동작/끝
• 동작 성공 여부 확인
• 캐시된 내용 다시 불러 오기
• 마지막 프로젝트/이슈 기억하기

이 중 몇몇은 생각과 달리 API 지원이 없어서 만들 수 없었습니다.

• 위키 목록 웹페이지
• 위키의 첫 페이지로 가는 것으로 수정
• assignee 바꾸기
• 해당 프로젝트의 등록사용자 목록 불러오기 불가 (1.4 부터 지원)
• 다른 사람 이슈 보기
• 해당 프로젝트의 등록사용자 목록 불러오기 불가 (1.4 부터 지원)

그리고 개발 중에 기발한 아이디어도 나왔습니다. 그것은 메뉴바의 타이틀 자체를 이슈 번호로 표시하는 것입니다. 그리고, 이슈 진행 시간도 바로 표시해 주는 것입니다. 아마도 하다보면 계속 좋은 아이디어가 많이 나올 것 같습니다.

이번에는 3시간반 정도 개발할 수 있었습니다.

두번째 보다 훨씬 메뉴가 복잡해 졌습니다. 그래도 기능이 꽤 많이 들어간 듯 합니다.

현재 상태를 볼 수 있을 뿐 아니라, 즉각 변경도 가능합니다.

우선순위도 지정 가능합니다.

목표 버젼도 변경 가능합니다. 위 화면은 약간 버그가 있는 듯 합니다.

시작일과 마감일을 메뉴에서 볼 수 있고, 선택하면, 변경 가능한 창이 나타납니다.

이슈 목록 필터 입니다. 나에게 지정된 이슈와 모든 이슈를 고를 수 있습니다. 여기서 고르면, Issues 목록이 바뀌게 됩니다.

목표 버젼별로도 이슈를 선택할 수 있습니다. 지정된 목표 버젼의 이슈만 선택할 수됩니다.

약간 이제는 우리가 쓸 수도 있겠다는 생각이 들기 시작합니다. 어쩌면 3일투자 (대략 반나절씩) 치고는 꽤 쓸만한 물건인 것 같습니다. 그리고 앞으로 4번 더 한다면 충분히 공개 가능한 버젼이 나올 듯 합니다.

오늘의 애자일 방법론에 대한 회고 입니다.

• 어느 정도 자리가 잡힌 듯 합니다.
• git 의 merge 는 역시 어렵습니다. merge 후, 지난 변경이 돌아간 경우가 몇번 있었습니다. 다같이 동시에 비슷한 부분을 작업을 많이 하다보니, 이 부분의 어려움은 어쩔 수 없는 것 같습니다.

다음주를 기대합니다.

이번 모임에서, 지난주에 이어서 계속 진행하기로 하였습니다. 지난주 5시간의 투자로 우리는

• Redmine 의 JSON 인터페이스를 통해서, Mac OS X 앱을 만들어서 이용할 수 있다는 사실을 확인하고
• 메뉴바 애플리케이션(Status Item) 을 만들어서 손쉽게 접근 가능하면 좋겠다는 희망을 가졌고,
• 간단하게 나마, 기능 구현을 완성하였습니다.
• 로그인 성공여부 확인하기
• 프로젝트 목록 가져오기
• 해당 프로젝트에 속한 이슈 목록 가져오기
• 해당 이슈 목록의 웹페이지로 이동하기

지난주에 진행한 것은 위와 같습니다. 아직은 우리도 스스로 쓰기엔 부족함이 많습니다. 하지만, 5시간 투자한 것 치고는 꽤 쓸만한 것이 나왔다는 것에 만족하고 있습니다. 오늘 또 5시간을 더 투자하면 어떤 결과가 될지 기대가 되었습니다.

시작에 앞서, 오늘은 무엇을 할까 고민을 하였습니다. 무엇을 더하면 우리가 쓸만한 놈이 될까? 고민을 해 보았습니다. 토론 끝에 두가지 쟁점이 있었습니다. 우리가 지금 해야 할 것은

• 여러가지 기능을 추가하는 것인가?
• UI 적인 기둥을 만들어 보는 것인가?

위 두가지 방향성 중, 토의 끝에, 지금 먼저 해 보고 싶은 것은 UI 적인 기둥을 만드는 것이라 생각했습니다. 왜냐면, 기능적인면은 UI 기둥을 만들면, 쉽게 추가가 가능할 것 같다는 생각이 들었기 때문입니다.

그래서, 어떤 사용 시나리오가 좋을까 고민을 하도록 했습니다. 여기서도 두가지 갈래가 나왔습니다.

• 윈도우를 기반으로 하고, 맨 왼쪽에 프로젝트 목록을 선택하고, 중간에 이슈 목록을 보여주고, 그리고 맨 오른쪽에 해당 이슈의 상세 내용을 보여주는 것입니다.
• 메뉴바 내의 메뉴에 표기하는 것입니다. 메뉴에서 현재 프로젝트를 선택하고, 현재 이슈를 선택하고 나면, 메뉴 상단에 현재 선택된 이슈의 내용을 간략하게 보여주고, 거기서 바로 이슈의 상태를 변경하는 것입니다.

위 두가지를 가지고 토론을 했습니다.

위도우 기반으로 했을 때에는,

• 그 장점으로,
• 향후, 복잡한 기능성을 대폭 담을 수 있고,
• 어짜피 결국에는 이런 방식을 해야 하기 때문에, 처음부터 이렇게 시각하는 것이 좋지 않을까
• 여러 프로젝트에 흩어진 여러 이슈들 간을 편리하게 이동할 수 있다.
• 단점으로는,
• 어짜피 모든 기능은 웹에서 이미 다 제공하고 있는데, 굳이 동일한 기능을 똑같이 반복해서 만들 필요가 있을까?
• 개발중 복잡한 화면 속에서 또다시 이 창을 찾기란 매우 힘들지도 모른다.
• 5시간 내에 어느정도 틀을 만들어 낼 수 있을까?

• 그 장점으로는,
• 지난번 만든 것에서, 조금 만 더 손보면 되기 때문에, 쉽게 만들어 낼 수 있겠다.
• Mac OS X 의 Space 기능으로 화면 전환을 해도, 늘 메뉴에 붙어 있기 때문에, 항상 쉽게 접근해서 쓸 수 있을 것이다.
• 작업의 특성상, 하나의 이슈에 고정되어 있기 때문에, 그 경우 오히려 편리하다.
• 단점으로는,
• 한번에 하나 이상의 이슈는 다룰 수 없는 한계가 있고,
• 사용성이 직관적이지 않아 불편하고,
• 많은 기능을 담기에는 한계가 있을 것이다.

위 쟁점을 토론한 결과, 일단은 메뉴바로 기반으로 해 보자는 결론을 냈습니다. 보다 쉽게 구현할 수 있다는 점이 크게 어필한 것 같습니다

메뉴바 기반의 UX 를 생각하고, 그림을 그려 봤습니다. 화이트 보드 상에서 간략하게, 구현이 됐을 때, 사용하는 상황을 대충 그려 보았습니다.

화이트 보드에 그린 모습

메뉴 상단에 몇줄의 메뉴를 통해서 “현재 선택된 이슈”에 대한 간략한 정보 ( 이슈 번호, 이슈 제목, 이슈 상태, 진척도 ) 등을 표시하고, 상태와 진척도는 오른쪽 서브메뉴를 통해서 즉각적으로 수정할 수 있도록 한다. 그리고, 그 아래에 Add Comment 메뉴를 통해서, 커멘트도 바로 기록할 수 있도록 한다. 그리고, 그 하단에는 프로젝트 선택의 서브메뉴에서 “현재의 프로젝트”를 선택하고, 이슈 선택의 서브 메뉴에서 “현재의 이슈”를 선택하도록 한다.

썩 직관성 있는 사용방법은 아니지만, 일단 만들어 보기로 했습니다.

지난번에서 추가해야 할 주요 작업으로는

• 추가 프로토콜 지원
• 프로젝트 내용 업데이트, 프로젝트 상태 목록 등
• Comment 입력 UI 만들기
• 메뉴바 현재 이슈 내용 표시하기

생각보다 쉽게 진행되는 듯 했다. 하지만, 중간에 생각치 못한 난관이 있었습니다.

• 프로젝트 업데이트 프로토콜이 생각되로 잘 진행되지 않았습니다.
• 이는 Content-Type 을 application/json 으로 보내주지 않았기 때문이었습니다.
• 내친김에 이미지 업로드 기능도 넣고 싶었습니다.
• 현재 Redmine 1.3 버젼에서는 API 가 지원되지 않는 듯 했습니다.

그리고, 5시간 후, 결과를 만들어 낼 수 있었습니다.

프로젝트 목록 보여주기. 이중 하나를 선택하면, 현재 선택된 프로젝트가 된다.

 

이슈 선택하기. 현재 선택된 프로젝트내의 이슈목록을 보여준다. 이중 하나의 이슈를 선택하면, "현재 선택된 이슈"가 된다.

현재 선택된 이슈는 항상 메뉴 최상단에 그 정보가 보여진다. 위 화면은 진척도를 보여주고, 서브메뉴를 통해서 진척도를 변경할 수 있다.

또한, 현재 이슈의 상태를 볼 수 있고, 그 상태를 바로 변경할 수 있다.

Add Comment 메뉴를 선택하면, 새로운 창이 뜨고, 이 창에서 새로운 Comment 를 입력할 수 있다.

또 다른 5시간을 투자해서, 꽤 쓸만한 기능이 많아 진 것 같습니다. 하지만, 아직은 스스로 매일 매일 쓰고 싶은 상태까지는 아닌 듯 합니다. 항상 두가지가 교차하는 것 같습니다. 5시간으로 꽤 많은 일을 할 수 있다는 것과, 일주이에 한번으로는 여전히 많이 부족하다는 점입니다. (이번주부터는 일주일에 두번 하기로 하였습니다.)

오늘의 애자일 방법론에 대한 회고입니다.

• 오늘은 대화가 조금 부족했습니다. 대화가 부족하다 보니, 긴장감도 조금 떨어지고, 병목 현상이 많았습니다. 서로가 각자의 맡은 부분을 하다보니, 마지막에 가서야 현재의 상황을 알 수 있었습니다. 이것은 우리가 원래 원하던 그림이 아니었습니다. 다같이 서로 이야기 하면서 진행하는 것인데, 하다보니 대화가 없어지고 각자 하는 스타일로 돌아가 버렸습니다.
• 위에서 말한 병목현상. 한 사람이 무엇을 먼저 해 주기를 기다립니다. 그리고, 그 사람이 끝나기를 기다리는데, 시간이 꽤 걸립니다. 그리고, 이번에는 그 다음걸 할려고 하는데, 미쳐 생각치 못한 것들이 또 나옵니다. 즉각적으로 대화를 문제를 풀지 못했기 때문인 듯 합니다.

하지만, 몇 사이클이 지나면, 분명 우리 스스로에게는 꽤 쓸만한 물건이 될 것은 같습니다.

<편집자주> 민트기술에서는 외부 집필자의 도움으로 애플/맥에 관한 좋을 글들을 받아서, 홈페이지를 통해서 제공하려고 합니다. 이번에는 김정님께서 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인증은 어찌하나?