월탱, 장갑형 전차.

월탱에서 장갑형 전차를 탄 플레이어들은 자주 방어에 치중하는데, 두꺼운 장갑이 있다면 왠만하면 전진하는 쪽이 좋은 결과를 낸다. 당연히 무리하게 전진하다 십자포화를 얻어맞으면 안 되겠지만 다가오는 적들만 상대하다가보면 어느 순간엔가 포위 당하거나 경전차가 돌파해 온다. 뒤에 구축이 받쳐주는 상위 티어 장갑 헤비의 전진은 자주포 아니면 답이 없다. 느리지만 전진해야 한다. 장갑은 방어가 아닌 돌파를 위해 있는 것이다.

세리프체의 부활을 바라며.

LCD 등 고정 해상도 모니터가 일반화되면서 전자매체에서는 산세리프체가 일반적이다. 출판에서는 여전히 세리프체가 널리 쓰이지만 픽셀 밀도가 낮은 모니터에서는 세리프가 제대로 표현되지 않아 외려 읽기 힘들기 때문인데, 이미 옛적 레이저 프린터에 맞먹는 픽셀 밀도를 가진 모바일 기기에서도 산세리프체가 기본인 것은 관성적인게 아닌가 생각된다. 글꼴 추가가 힘든 스마트 기기들의 설정 문제도 있다.

하지만 앞으로는 가독성면에서 여전히 우위에 있는 – 출판에서 세리프체가 여전히 주류인 이유다 – 세리프체를 고밀도 모니터로 가져오는 작업이 많아지고 일반화 되었으면 한다. 보통 무료로 사용할 수 있는 세리프 글꼴은 koPub 명조, 나눔명조 정도인데 산세리프체만큼 다양한 선택권이 생겼으면 좋겠다. 텍스트를 읽는 데는 여전히 세리프체의 장점이 많으니까.

ARM의 Big.LITTLE: 삼성 엑시노스는 뜨거울 수 밖에 없다. #2/2

일단 제1편 ARM의 Big.LITTLE: 이게 무엇인가? 부터 읽고 보시는 쪽이 이해가 쉽습니다. 글이 굉장히 늦어졌는데, 삼성이 갤럭시 S4A, 노트3 등에 퀄컴 스냅드래곤 800을 주로 탑재하면서 이리저리 미루다가 기다리시는 분들이 계신다는 이야기를 듣고 정리, 완성했습니다. 기대하라고 써 놓고 너무 늦어서 죄송합니다. 기다리신 분들에게 양해의 말씀 드립니다. ^^;

삼성은 처음부터 빅.리틀 프로세서를 동일 클럭 방식(Synchronous Clock Architecture, 이하 sync 구조)로 만들려고 했다. 이 문서에서 삼성은 코어별 클럭 방식(Asynchronous Clock Architecture, 이하 async 구조)에 비해 sync 구조가 성능은 물론이고, 전력 소모와 발열 면에서도 더 나을 수 있다고 주장한다. 요약하면 다음 그래프와 같이, 코어를 고클럭으로 짧게 구동함으로서 async 구조가 갖는 여러 추가부담 없이 바로 전력 소모를 줄일 수 있다고 본 것이다.

Cap 2013-12-08 23-37-55-475
전력소모 = 전력소비율(Power) x 구동시간(Time) 이므로, 높은 클럭을 빠르게 구동한 후 코어를 꺼버리는 방법으로 sync 구조의 전력소모를 async 구조와 같은 수준으로 줄일 수 있다는 삼성의 그래프.

또한 해당문서에서 삼성은 빅.리틀 아키텍쳐의 경쟁자로서 asynchronous architecture를 명시하면서 빅.리틀 자체를 sync 구조로 이해하고 있음을 드러낸다. 이렇다면 코어별로 클럭을 통해 개별 변환되는, aync 구조가 필연적인 CPU별 변환(CPU Migration)은 최소한 삼성의 빅.리틀 프로세서에서는 불가능한 방식이었다. ARM 개발사들의 모임인 Linaro의 이 문서에서도 현행 하드웨어(삼성 엑시노스 5410)에서는 클러스터가 각각 sync 구조라서 IKS, 즉 CPU별 변환이 불가능하다고 명시적으로 밝히고 있다. CPU별 변환 개념이 사실상 MP모드 이후에 나온 절충적 개념이라서 생긴 문제로 보인다. MP모드는 이론상으로는 가장 완벽해보이지만 실질적으로 상당한 문제가 있는데, 이는 이 글 후반부에서 다루겠다.

클러스터 변환이 왜 문제인가? 이는 곧 왜 갤럭시S4는 온도 제한을 90도까지 올려서 발매해야 했는가?라는 문제이다. 가장 큰 문제는 안드로이드 앱들이 대부분 싱글 스레드라는 점에 있다. 한 앱이 고성능을 요구하는 상황을 생각해보자. 당연히 리틀 코어로는 성능이 부족하므로 빅 코어로 변환이 일어난다. 클러스터 변환이므로 리틀 코어들은 꺼지고, 빅 코어들이 모두 구동된다. 그리고 빅 코어 하나는 이 앱을 돌리기 위해서 클럭을 필요할 수준까지 계속 올라가야 한다. Sync 구조이기 때문에 나머지 빅 코어들 또한 할 일이 없음에도! 그 고클럭으로 동작해 버린다. 실 동작은 안 하므로 그나마 일하고 있는 코어보다는 낫겠지만, 클럭이 올리는 이상 전력 소모와 발열을 피할 수 없다. 멀티 스레드 앱이라면 그나마 빅 코어들이 분담하면서 클럭 상승이 억제되겠지만, 싱글 스레드는 그렇지 않다. 엑시노스 5410의 경우 한 클러스터가 4개 코어를 가지므로, 빅 코어 하나를 구동시키기 위해서 나머지 3개를 모두 같은 클럭으로 올려야 하는 낭비가 일어나는 것이다. 만약 온도 제한을 낮춘다면, 엑시노스 5410은 다른 프로세서에 비해 훨씬 더 빨리 온도로 인한 클럭 제한을 받을 수 밖에 없다.  갤럭시S4는 뜨거울 수 밖에 없는 것이다.

잠깐, 그렇다면 할 일 없는 빅 코어들은 꺼버리면 되지 않을까? MP모드에서도 코어들을 모두 동작시킬 수는 없으므로 이 기능은 필요하지 않은가. 이는 결국 CPU hotplugging 문제가 되는데, 현재 리눅스에서 제대로 지원되고 있지는 않다.(참고) Linaro에서도 올해 8월에는 작업 중이었다고 한다. 리눅스에서도 개발 중이므로 실제 안드로이드에 적용되려면 더 많은 시간이 필요할 것이다.

실제로도 사용시간 벤치마크를 보면, 디스플레이와 GPU가 꺼지고 CPU와 모뎀만이 동작하는 통화시간에서 엑시노스 5410을 장착한 갤럭시 S4는 퀄컴 스냅드래곤 600을 장착한 버전에 비해 사용시간이 60% 수준밖에 되지 않는다. 디스플레이가 켜지는 다른 작업들도 스냅드래곤 버전을 이기지는 못한다. 특히 비디오 재생에서는 1시간 정도까지 차이가 난다. 성능은 준수한 것으로 나오지만, 온도 제한이 강화된 S4에 대한 벤치마크는 찾을 수가 없었다.

멀티 스레드 안드로이드 앱들이 일반화된다면 상황은 많이 나아질 것이나, 멀티 스레드는 그 자체로 개발업무량을 몇 배로 증가시킨다. 더해 파편화가 심각한 안드로이드 시장에서 개발자/사가 저가형 기기에서는 오히려 성능이 떨어질 수도 있는 멀티 스레드화를 선호할 것이라 기대하기 힘든 상황이다.

CPU별 변환이 안 된다면, MP모드(삼성 표현으로는 Heterogeneous Mulit-Processing, 이후 HMP로 표기.)는 가능하지 않을까? 삼성은 올해 4분기에 고객들에게 HMP 지원을 하겠다고 발표했었지만, 12월 중순이 되어가는 지금까지도 별다른 결과물은 나오지 않고 있다. 이게 쉬운 일이 아니다. 내 예상으로는 (빅.리틀 아키텍쳐를 계속 쓴다면) (가장 빠르게 잡아서) 갤럭시 S5에서나 가능하지 않을까 싶다.

HMP가 어려운 가장 큰 이유는 삼성이 붙인 이름대로 Heterogeneous해서, 즉 상이한 코어들을 관리해야 하기 때문이다. 지금까지 대부분의 멀티 프로세서 OS들은 SMP(Symmetric Multi-Processing) 구조이다. 말 그대로 각 코어들이 모두 같고 동등하다는 가정 하에 (그래서 대칭적 Symmetric이라는 이름이 붙었다.) 개발된 것이다. 리눅스도 마찬가지이다. 이를 Heterogeneous하게 만들려면 단순한 기능추가로 끝나는 것이 아니라 알고리즘부터 완전히 새로 설계해야 한다. 현 리눅스 커널의 스케쥴러는 2003년 말 2.6 시절에 크게 바뀐 후 지금까지 끊임없이 보강, 개선되어 온 코드인데 이보다 더 복잡한 스케쥴러를 안정적으로 개발한다? 결코 쉬운 일이 아니다. 단순히 우선도를 부여하는 정도로는 역부족이다. 거기에 덧붙여 아까 이야기했듯이 cpu hotplugging 또한 아직 준비가 되어 있지 않다. 쓰지 않은 코어들을 끄지 못하는 HMP는 전력소모에서 결코 유리하지 못하다. 비유하자면, 땅은 평평하다고 생각하고 설계하고 지어왔던 집을 이번에는 언덕 위에 만들어야 하는 상황이다.

예를 들자면, 어떤 앱이 고성능을 요구하는지 어떻게 알 수 있는가? 일단 돌려보고 CPU를 많이 잡아먹으면 빅 코어에 할당한다? 그럼 그 기간 동안 앱은 동작이 끊길 것이다. 구동 내내 별 성능요구가 없던 앱이 동영상 등을 재생하면서 갑자기 높아질 수도 있다. HW적으로 변환을 매끄럽게 만들어 낸 ARM은 대단하지만, SW적으로 구현하는 것은 또다른 문제다.

HW에서도 L2 캐시를 클러스터 별로 따로 쓰므로 상시 동기화에 들어가는 비용에 더해 용량이 상대적으로 줄어든다는 문제가 있다. L2캐시에 더해 Cache Coherent Interconnect까지 구현하려면 다이 크기 문제도 있고 수율에서 강점을 보이는 삼성만이 현재 빅.리틀을 채용한 이유가 있다. 매우 비싼 아키텍쳐인 것이다.

빅.리틀 구조에 대해 알아볼수록 SW, 특히 OS에 대한 이해가 적었던 두 개발사 -ARM과 삼성-이 SW 작업을 너무 가볍게 보고 진행한 아키텍쳐가 아닌가 싶다. 인텔도 IA64 아이태니엄 개발하면서 비슷한 실수를 했던 사례가 있다. 특히 서버 등을 노린 고성능 프로세서와 값싼 임베디드용 저전력 프로세서를 개발하면서, “이걸 한데 묶으면 굳이 새 거 안 만들어도 하이엔드 모바일 프로세서로 잘 써먹을 수 있지 않을까?”라는 기똥찬 잔머리?를 굴렸던 ARM은 삼성이 결국 독자적인 아키텍쳐를 준비하기로 하는 등 그 대가를 호되게 치르고 있다. 삼성은 갤럭시 S4 이후 S4A, 노트 3에 이르기까지 (통신 모뎀의 이유도 있지만) 주력 하이엔드 제품들에 퀄컴 프로세서를 사다 써야 했다.

현재로서는 빅.리틀 프로세서 즉 엑시노스 옥타는 퀄컴 스냅 드래곤 등 async 구조의 프로세서에 비해 장점이 없다. HMP가 제대로 구현된다면 나름 장점이 생기겠지만, 그 SW는 여전히 개발단계에 머물러 있다. 안정화되려면 년 단위의 시간이 더 필요할 것이다. 지금 엑시노스는 구입할 이유가 없다. 그러니까 결론은 하나입니다. 갤럭시 S4 사지 마세요, 굳이 갤럭시가 필요하면 S4A로 사세요.

 

애플 앱 스토어 사업자등록증 요구: 근거와 단상.

참고 링크

  1. 문제는 세금이야 , 이 바보야. – 6116
  2. 외국 개발자들의 경우 연락처 정보 추가 노출도 압박이 심할 듯… – being nice to me
  3. 구글 플레이의 한국 판매시 개인 정보의 요구 – Google Play
  4. 애플, 개인 개발자 사업자 등록 강제… 왜? – 이데일리
  5. 전자상거래등에서의 소비자보호를 위한 법률 – 국가법령정보센터
  6. Korea’s iTunes App Store gets personal, wants developers to show contact details – TECHINASIA
  7. 앱스토어 개발자 등록 해프닝, 원인은 ‘전자상거래법’ – Blotter.net
  8. 애플 앱 스토어 계약서 – Apple
  9. 구글 Play 법률정보 – Google

제2판 업데이트: 참고링크 7번의 기사를 먼저 읽어보시면 이해가 더 쉽습니다. 저도 초본에서 잘못한 부분들을 이 기사를 보고 바로 잡았습니다.

며칠 전부터 애플 앱 스토어에서, 앱 등록 시에 실명, 주소, 전화번호, 이메일 주소, 사업자등록번호(외국인은 예외)로 요구하기 시작했다. (참고1,2 )  구글 또한 플레이 스토어에서 한국 내 판매를 위해서는 개발자의 연락정보를 요구하고 있다.(참고3) 애플의 경우, 현재는 요구하지 않고 있다고 한다.

이 요구에 대해 앱 판매 수익에 대한 과세 문제로 접근한 기사(참고4)도 있기는 한데, 그 근거는 다른 곳에 있다. “전자상거래등에서의 소비자보호를 위한 법률” 제20조 제1항, 제2항과 그에 따르는 시행령 제25조 제1항이 그것이다. 즉 이번 제한은 소비자 보호를 위한 법률에 그 근거를 둔다. 참고4의 기사에서는 조세 관련 기관에게만 문의했는데, 이 법률을 집행하는 기관은 대부분 공정거래위원회이다. (이 글 초본에는 제10조로 논했었으나, 제10조는 사이버몰 운영자 자신에 대한 조항이다. 참고7을 보고 바로 잡는다. 참고7에서는 제20조 제2항만을 언급하였는데 실제 사업자 등록번호를 요구하는 법령은 시행령임.) (추가: 아직 공정위가 이 법령의 적용여부에 대해 확인했다는 소식은 찾지 못했음.)

법률 제20조(통신판매중개자의 고지 및 정보제공 등) ① 통신판매중개자는 자신이 통신판매의 당사자가 아니라는 사실을 소비자가 쉽게 알 수 있도록 총리령으로 정하는 방법으로 미리 고지하여야 한다.

② 통신판매업자인 통신판매중개자는 통신판매중개를 의뢰한 자(이하 “통신판매중개의뢰자”라 한다)가 사업자인 경우에는 그 성명(사업자가 법인인 경우에는 그 명칭과 대표자의 성명)·주소·전화번호 등 대통령령으로 정하는 사항을 확인하여 청약이 이루어지기 전까지 소비자에게 제공하여야 하고, 통신판매중개의뢰자가 사업자가 아닌 경우에는 그 성명·전화번호 등 대통령령으로 정하는 사항을 확인하여 거래의 당사자들에게 상대방에 관한 정보를 열람할 수 있는 방법을 제공하여야 한다.

시행령 제25조(통신판매업자인 통신판매중개자의 정보제공) ① 법 제20조제2항에서 “성명(사업자가 법인인 경우에는 그 명칭과 대표자의 성명)·주소·전화번호 등 대통령령으로 정하는 사항”이란 법 제13조제1항 각 호의 사항(사업자가 법인이 아닌 경우 그 대표자의 성명을 갈음하여 사업자의 성명) 및 사업자등록번호를 말하고, 통신판매업자인 통신판매중개자가 다음 각 호의 정보를 보유한 경우에는 이를 포함한다.

1. 공인인증기관(「전자서명법」 제2조제10호에 따른 공인인증기관을 말한다. 이하 같다) 또는 신용정보회사(「신용정보의 이용 및 보호에 관한 법률」 제2조제5호에 따른 신용정보회사를 말한다. 이하 같다) 등을 통하여 확인한 신원정보

2. 해당 통신판매업자인 통신판매중개자가 제공하는 통신판매중개의뢰자의 신용도에 관한 정보

애플 앱 스토어와 구글 플레이가 이 법에서 규정한 “통신판매업자인 통신판매중개자”에 해당되기 때문에 이들은 앱 판매자(이 법률 내에서는 “통신판매업자”로 규정된다.)의 관련 정보를 게시해야 될 의무가 있다. 왠 뜬금없는 법인가? 라고 생각하시는 분들도 계실텐데, 이 법률은 당초 “인터넷 쇼핑몰”을 규제하기 위해서 만들어진 것이다. 즉, 옥션 등 오픈마켓을 생각하면 쉽다. 오픈 마켓에서 어떠한 물품을 사고 구매결정 등 결제를 했는데 결함 등의 사후 문제가 생겼을 때, 이를 책임질 주체를 명확히 알리기 위해서 만들어진 조항이다. 스마트 기기의 앱에서 비슷한 사례를 찾자면, 피싱 등 범죄 앱으로 피해를 입었을 때 소비자가 누구에게 피해보상을 받을 수 있을지 분명하고도 공개적으로 알 수 있도록 하는 목적이다. (추가: 이 법에서 “사업자”란 제조-수입-판매 등을 하거나 용역을 제공하는 자를 지칭하는 용어(동법 제2조 6호 참조, 참고 5)이므로 사업자가 아닌 자는 해당 재화/용역의 제조-유통의 상행위 과정에 있지 아니한 자를 뜻한다. 중고 거래 등을 상정한 조항으로 보인다. 제2항 뒷부분에서 “거래의 당사자들”, (제공이 아닌) “열람”이라는 표현에서 그러한 점이 엿보인다.)

이 조항은 개인 개발자에게 문제이다. 기업의 경우에는 크게 문제될 것이 없다. 어차피 사업자등록은 했을 것이며 그 영업주소는 법인의 경우 공개되어 있기 때문이다. 하지만 개인 개발 및 판매자는 전업이라면 세금 등 법적으로 사업자 등록을 하는 것이 옳겠으나 자택 개발의 경우에 사업자 등록 번호만으로 충분할 터인데도 자신의 거주지 및 전화 번호까지 공개적으로 밝혀야 하는가,라는 사생활 보호의 문제가 있다. (이는 참고6에서처럼 외국인 개발/판매자의 경우에도 문제된다.) 그리고 겸업하는 경우 사업자등록으로 인한 겸업금지의무 또는 영리활동금지의무 위반이 발각되는 사태를 우려하는 이야기도 있다. 용돈벌이 등 소소한 취미로 개발하는 학생의 경우에도 자영업자로 규정되는 사업자 등록이 부담스럽다는 의견도 있었다. 대부분 개인들의 활발한 개발을 장려해야 할 정부가 오히려 위축시킨다는 비판이 많았다.

그렇다면 개인 개발/판매자들, 특히 전업이 아니라 겸업이나 취미로 하는 이들이 이 법의 적용을 피할 수 있을까. 검토해보면, 유료로 앱을 판매하는 경우에는 벗어나기가 매우 힘들다.  동법 제2조 제3호를 보면 다음과 같다.

3. “통신판매업자”란 통신판매를 업(業)으로 하는 자 또는 그와의 약정에 따라 통신판매업무를 수행하는 자를 말한다.

“업(業)으로 한다”는 표현은 해석상 정기적으로 일어나거나 꾸준히 행해지면 충분한 것으로, 이로 인해 생계를 유지하거나 이익을 보지 않아도 적용된다. 즉 앱 스토어에 앱을 등록하고 판매/서비스를 지속하고 있으며, 이에 더해 업데이트까지 이루어지고 있다면 실질적으로는 앱 판매로 이익을 보지 않고 있더라도 “통신판매업자”이다. 앱 판매는 애플이나 구글이 하는 것이고 개인 개발자가 직접 판매하는 것은 아니지 않은가, 라는 의문이 있을 수 있겠으나, 애플, 구글 모두 자신들의 마켓 계약, 약관에서 제3자가 제작한 앱 판매 시에는 제작자와 구매자 사이에 판매가 이루어지는 것이라고 명확히 하고 있다. (참고8, 9 및 아래 인용 참조) 즉 판매자 맞다.

(애플의 계약서) iTunes는 귀하에게 Mac App Store 및 App Store를 통해 제공되는 소프트웨어 제품(총칭하여 “App Store 제품”)를 사용할 수 있는 라이센스를 귀하에게 판매하는 것입니다. App Store 제품으로는 다음과 같이 두 종류가 있습니다. (i) Apple이 개발하여 iTunes가 귀하에게 라이센스해주는 상품들 (“Apple 제품”); 및 (ii) 제삼자인 개발자가 개발하여 귀하에게 라이센스해주는 상품들 (“제삼자 제품”). 특정 제품의 종류는 (즉, Apple 제품 또는 제삼자 제품 중 해당되는 것) Mac App Store 또는 App Store 신청서에 표시됩니다.
(… 중략 …)
귀하는 본 스토어를 통해 구매한 각각의 Apple 제품에 대한 라이센스가 귀하와 iTunes사이에 구속력이 있는 합의라는 것을 인정합니다. 귀하는 귀하가 제삼자 제품을 iTunes를 통해 취득한 경우, 해당 출판인과 직접적으로 귀하의 해당 제삼자 상품 사용에 대한 구속력 있는 계약을 체결하는 것이라는 점; 및 iTunes는 해당 제삼자 제품에 대한 귀하와 출판인 사이의 라이센스의 당사자가 아니라는 것을 인정합니다. 각 제삼자 제품의 출판인만이 그 제삼자 제품, 그 내용, 부인되지 않은 범위의 보장 및 귀하 또는 다른 당사자가 제삼자의 제품 사용과 관련하여 제기하는 청구에 대해 책임을 부담한다는 것을 인정합니다.

(구글의 약관) 2. Google Play 제공
직접, 대리인 및 앱 판매. 귀하가 Google Play에서본건 제품 (데이터 파일, 애플리케이션, 글로 된 텍스트, 모바일 기기 소프트웨어, 음악, 오디오 파일 또는 기타 음원, 사진, 동영상 또는 기타 이미지로 정의됨)을 구입할 때에는 아래와 같이 세 경로를 통해 구입하게 됩니다.
(… 중략 …)
(c) Android 앱의 경우 앱 제공자로부터 (“앱 판매”).
귀하는 본건 제품을 구입할 때마다 다음과 같이 별도의 매매계약을 체결하게 됩니다.
(… 중략 …)
(c) 앱 판매의 경우, 귀하가 구매한 본건 제품의 제공자와
이와 같은 별도 계약은 본건 서비스의 이용에 대하여 귀하가 Google Inc.와 체결한 계약에 추가적입니다.

무료 앱 개발자의 경우에도 이러한 면에서 앱 개발 및 제공을 “업”으로 하는 자는 맞다. 다만 무료인 경우에, 이를 “판매”로 볼 수 있는지가 애매하다. 판매는 매매(정확히는 매매계약 청약의 유인)인데, 매매의 핵심은 “유상계약” 즉 대가의 지급에 있다. 증여 등 무상계약 등으로 다룰 수 있는가는 다른 문제이고, 일단 “판매업자”로 분류하는 것은 무리이다. 다만 인 앱 결제 기능이나 광고 등으로 사실상 수익을 얻을 수 있는 앱의 경우에 단순히 앱 스토어에서 앱을 무료로 제공한다고 하여 이를 “판매”로 보지 않을 것인가 하는 문제가 있다.

소비자 보호가 목적이므로 이러한 “무료제공인 수익성 앱” 또한 예외를 인정하기 힘들다.  세금은 인 앱 결제나 광고수익이 발생할 때에 준해서 징수하면 된다. 이는 앱 스토어의 문제라기보다는 결제 서비스 제공자나 광고수익 지급자와 관계가 있으므로, 앱 등록과는 관계가 없다. 하지만 앱의 결함 또는 그로 인한 소비자의 부가적 피해를 책임질 공급자를 명확히 한다는 목적에서는 적용이 가능하다고 볼 수 있다. 판매는 매매의 청약 유인, 즉 “이거 사세요.”라는 뜻을 전달하는 행위이다. 무료제공 앱이라도, 설치 이후 사용 중에 매매(즉 구입)이 이루어진다면 무료 제공 자체를 판매 과정의 일부분으로 볼 수 있는 여지가 있다. 무료 앱을 설치하는 사용자 또한 소비자로 여길 만하다. 사실 이런 경우에는 앱 자체 내에 공급자의 정확한 정보를 포함시킬 것을 요구하는 것이 더 직관적이지만 꼭 그렇게 해야 한다고 보기는 어렵다. 하지만 이런 상황에서 판매자, 소비자 지위를 어디까지 인정해야 하는가에 대한 정확한 결정 또는 판결은 내가 아는 한 아직은 없다.

정리하자면, 해당 앱으로 수익을 내는 한에는 이 법률의 적용을 피할 방법은 없어 보인다. 다만 수익요소가 없는, 단순한 무료배포 앱은 “판매”를 전제하는 이 법률이 적용되기 어렵다고 생각된다.

법률 적용은 그렇다치면, 과연 오픈 마켓 등 “인터넷 쇼핑몰”을 염두에 둔 이 법률을 스마트 기기용 앱 마켓에 그대로 적용하는 것이 바람직한가? 즉 일반적인 인터넷 쇼핑몰, 오픈 마켓을 염두에 두고 만들어진 이 법률의 규제가 앱 마켓에도 적합한가,는 이야기다. 오픈 마켓과 앱 마켓은 일단 몇십만원에 달하는 상품들이 자주 거래되는 오픈 마켓에 비해서 앱 마켓은 무료도 많고, 유료라고 해도 $5 이하가 대다수이다. 또한 피싱 등의 범죄를 제외하면 스마트 기기 앱 자체의 문제로 인해 소비자가 큰 피해를 입는 경우는 매우 적다. 또한 피싱, 스매싱 등 불법/범죄 앱은 공식적인 마켓에서 판매되는 경우보다는 별도의 설치 파일 형식으로 전파되는 경우가 많다.

이 둘 간의 가장 큰 차이라면 판매자의 국적 다양성이다. 옥션에서 해외 판매자가 한국인을 상대로 판매하는 경우는 배송, 결제, 통관 등의 문제로 인해 굉장히 적지만 앱 마켓에서는 매우 일반적이다. 이 법률 제10조는 사이버몰 운영자에게 자신의 “사업자등록번호”를 표시할 것을 명시적으로 요구하고 있지만 구글 플레이를 운영하는 미국의 구글 본사에 등록번호가 있을 리가 없고 또한 표시되어 있지 않다. (상호명과 대표자명, 주소, 전화번호만이 나온다.) 구글이 이럴진대, 다른 해외 앱 개발자들이 사업자등록을 하기를 기대하기란 매우 힘들다. 하지만 “사업자”인 제작자이므로 시행령 제25조에 따라 사업자등록번호는 의무적으로 제시해야 한다. 국내 제작자면서 사업자등록을 하지 않은 경우 또한 마찬가지이다. 현재 국내 앱 마켓에서는 사업자등록을 하지 않은 개인 개발자의 경우엔 사업자 등록번호를 제공하지 않고 서비스 중이다.(참고7의 후단 그림 참조) 사실 이는 전자상거래소비자보호법이 제작, 수입, 판매하는 이들(“사업자”)들은 당연히 사업자등록을 하였을 것이라 묵시적으로 전제하고 들어갔기에, 법에 틈이 생긴 셈이다.

또한 소비자와 사회적 이익을 생각해보자. 기업을 아닌 해외의 개인 개발자가 굳이 자신의 이름, 주소, 전화번호, 이메일 주소를 공개할만큼 한국 시장이 매력적인가? 무료로 공개하는 앱들의 경우에는 더할 것이다. 해외 앱들이 한국 시장에서 이탈하면 한국 소비자들에게 불이익이라는 점은 명백하다. $5 정도의 피해를 구제받기 위해서 해외 사업자에게 연락을 취할 이익이 있을까 하는 점까지 생각해보면, 이들의 이탈에 비해 실질적인 이익을 기대하기는 매우 힘들다. 해외 공급자들에 대해 주소 등의 공개를 의무화함으로써 기대해볼만한 최대의 이익은 해외에서 만들어지는 피싱 등 불법 앱의 감소 정도일텐데, 이도 크지는 않을 것이 이미 피싱 범죄는 국제조직화 되어 있다. (최소한 해외의 사기 팀과 한국 내에서의 수금 팀 정도는 협력하고 있다.) 그들이 해외에서 만들어지는 피싱 앱을 솔직하게? 제작자를 밝히며 올릴 것이라 기대할 수 있을까? 거기에 앞에서 말했듯이 가장 위험한 피싱 앱들은 SMS등 다른 경로로 전파된다.

사업적인 측면에서 가장 중요한 문제라면, 국내-해외 앱 마켓 간 평등권, 즉 차별 문제다. 국내 통신사 앱 마켓들에는 강력하게 요구하면서 외국회사(애플,구글 등)에 대해서는 요구하지 못하면 이는 차별이다. 외국계 마켓에서는 외국제 앱과 국내 개인 개발자 앱을 쉽게 구할 수 있고, 국내 마켓에서는 사업자 등록을 한 전업 개발자들의 국산 앱 위주로만 구할 수 있다면 경쟁력 차이는 확연해질 것이다. 이러한 차별은 해당 통신사 투자자들의 반발을 불러올 가능성도 크다. 현재 애플 앱 스토어는 다시 이 법률 상의 정보들을 요구하지 않고 있지만, 국내 앱 스토어들이 이미 표시하고 있다. 개인 개발자라면 어느 쪽에서 앱을 팔고 싶겠는가?

정책적으로 거래금액과 피해우려가 적은 앱 마켓에 대해 소비자 보호(및 세수확보)와 스마트 기기 앱 개발/공급자 활성화를 비교해보면, 아무래도 후자쪽이 더 무겁지 않나 생각된다. 국내에서 제작되는 피싱 앱들에게는 어느 정도 강력한 규제가 되겠지만, 앞서 말했듯이 마켓을 통해 전파되지 않거나, 외국에서 만들어지는 경우가 많은데 큰 소용이 있을까 싶다. 하지만 전자 상거래 전반에 대한 소비자 보호를 소홀히 할 수는 없으므로, $10 정도의 소액인 SW, 컨텐츠 거래에 대해서는 제작/공급자의 신원 정보들의 제공 의무를 면제하며 일정 액수 이상의 판매액을 올린 이들에 대해서만 마켓 운영자가 세무당국에 통보하도록 하고, 범죄 앱들의 경우에는 사후 차단 및 별도의 제작자 추적 제도를 도입하는 예외를 두는 것이 가장 현실적이고 효과적인 대안이라고 생각된다.

글이 길어졌다. 세 줄(이지만 역시 좀 긴) 요약.

  1. 현행 전자상거래 소비자보호 법률상 앱 공급자의 이름,주소,전화번호,사업자등록번호 제공 의무는 완전한 무료 앱을 제외하면 피하기 힘들다.
  2. 가격의 소액성, 외국인 앱 개발/공급자의 대거 이탈, 국내-해외 앱 마켓간의 평등, 피싱 앱의 해외 개발 및 허위공개를 고려하면 소비자보호를 위한 공개의무는 현실적이지 않다.
  3. 소액의 SW, 컨텐츠 거래에 있어서는 소비자보호보다는 개발, 공급을 장려하고 국제성을 중시하는 예외 규정이 현실적으로 필요해 보인다.

 

애플 아이폰4S 단상: 디스플레이 전쟁, 시작되다.

이번 아이폰은 다 업그레이드되었는데, 단 하나 디스플레이만 아니어서 4S가 됐다. 디스플레이가 안 바뀌니 기구물(프레임)도 바뀌어봤자 모양도 별 차이없어서 어쩔 수 없이 4S로 이름붙인 듯하다. 사실 3G시절부터 4S까지 얼마나 큰 업그레이드가 있었나 생각해보면 이번 4S가 딱히 5라 부르지 못할 정도로 마이너 업그레이드는 아니다. 삼성 이재용 사장의 커멘트를 고려해보면 삼성에서 차세대 디스플레이 대량공급을 거절해버린 모양이다.

LCD업체들 사정이 별로 좋지 않다. 레티나 디스플레이는 LG와 일본업체들이 공급하는데, 같은 해상도의 4인치면 픽셀 피치가 틀려져서 생산라인을 대량수정해야 하는데 0.5인치 확대에 그럴 메리트가 있는가? 같은 dpi로 크기만 키우는 것도 패널 생산성+ 앱 호환성 문제가 생긴다. 레티나만 해도 생산성에 문제가 많았는데, 그 이상 해상도라면 과연 애플이 필요로 하는만큼 대량생산이 가능할지도 의문시된다. 게다가 경제위기인 요즘에 생산라인에 대규모 투자를 단행하기에는 LG도 도시바도 샤프도 자금사정이 그리 좋지 않다. 애플의 투자는 1년 정도밖에 안 됐고 생산라인에 영향을 끼치려면 아무리 빨라도 1년이상은 더 기다려야 한다. 그것도 신 패널 개발이 잘 진행된다는 전제 하에.

어떤 분께서는 LTE망의 확산을 기다리느라 5가 아니라 4S라 하시던데, 그보다는 차세대 디스플레이를 확보하지 못한 게 가장 큰 이유가 아니었나 싶다. 3->4도 3G망 내에서 했는데, 굳이 5를 LTE용으로 발매할 필요는 없지 않을까. LCD는 생산과 개발 기술 모두에서 일시적이나마 한계에 와 있고, OLED는 삼성 모바일 디스플레이 외에는 당장에는 대량생산이 힘든 상황이다. 다만 LCD 진영에서는 레티나를 두 세대 아이폰에서 사용하면서 자금과 시간 여유를 가질테니 이들이 어떤 대응(OLED양산까지 포함해서)을 보여주느냐에 따라서 애플의 아이폰5가 출시될 것 같다.

이번에 삼성은 디스플레이를 무기로 대단한 호기를 맞았다. 애플이 여전히 레티나에 머무르는 동안 갤럭시 시리즈에 온갖 OLED 패널을 적용해서 대중의 아이폰 프리미엄을 깎아낼 절호의 찬스가 온 셈이다. 그리고 애플과 삼성의 밀월시대는 확실히 끝났다.

애플은 이번에는 당했지만 디스플레이에서 계속 밀릴 수는 없다. 애플의 고객 충성도는 한세대 정도 디스플레이 향상이 없다고 문제가 생길 정도는 아니고, 애플의 현금과 주문량을 생각해보면 앞으로 모바일 디스플레이 시장을 대대적으로 재편할 힘이 있다. LG와 일본업체들도 모바일에서 살아남으려면 애플의 주문이 필수적이다. 어느 업체가 애플에게 선택되느냐에 따라서 나머지 업체들은 도태되는 것도 각오해야 할 지경이다.

애플이 아이폰 5출시를 포기하고 4S로 가면서, 디스플레이가 앞으로 스마트폰 경쟁의 핵심이 됐다. 다 업그레이드 해도 디스플레이가 좋아지지 않으면 완전한 신제품으로 내놓을 수 없는 것이다. 그리고 그 선제공격을 얻어맞은 기업이 바로 현금과 주문량에서 압도적인 애플이다. 모든 모바일 디스플레이 업체들이 휘말려들 전쟁이 시작됐다.

Firefox 5 정식판 출시 & 버전 넘버에 대한 단상.

링크: 파이어폭스 한국어 홈페이지

어느샌가 파이어폭스 5가 정식버전으로 나왔습니다. 저야 beta판으로 계속 쓰고 있었는데 어느샌가 정식판으로 나와있더군요. 확실히 릴리즈 속도가 빠르긴 빨라졌습니다. CSS지원 등 기술적인 면은 상당히 보강되어 있는데, 실상 사용자 입장에서는 체감속도가 크롬 12 수준까지 향상되었다는 점 이외에는 별 차이는 없습니다. 개인적으로는 이정도라면 4.1이나, 높인다면 4.5 정도가 되었어야 하는데, 역시 크롬이 미친듯이 버전(숫자만) 업하고 있는 상황이라 버전 5가 된 것 같습니다. 어쨌든 안정적이고 속도도 빠르고 안전합니다. 아직까지 파이어폭스를 써 보시지 않으셨다면 이번 버전5는 추천할만한 웹 브라우저입니다.

FreeBSD도 그렇고, firefox도 그렇고 진중한? 버전업을 이어가던 소프트웨어들이 급진화?하고 있는 걸 보면 좀 씁쓸한 기분이 듭니다. <Major Versioin>.<Minor Version>.<Build Number>의 버전 넘버링은 이젠 개발관리에서나 사용하는 개념이 되어버렸습니다. 마이크로소프트가 연도/코드명 + Service Pack 개념으로 버전넘버를 마케팅에 이용하고, 리눅스 진영에서 배포판 만들면서 릴리즈마다 버전을 마구 올린 덕분에 이젠 출시명으로는 어느 정도 바뀌었는지 알기 힘듭니다. 이젠 소프트웨어의 넘버링이 버전이 아니라 출시날짜를 지칭하고, 릴리즈조차 time-base 즉 시간되면 내놓는 경우도 늘어나고 있습니다. 마이크로소프트의 경우에는 마이너 버전업에도 새 이름을 붙여서 (괜한) 업그레이드를 유도하기 위한 측면이 강했고, 리눅스 배포판의 경우에는 통일된 관리가 힘들어서 (품질이야 어찌되든) 걍 시간 되면 내놓는 모델로 가는 경우가 많아졌는데 과연 이게 바람직한 길인지는 의구심이 듭니다.

마이크로소프트의 경우에는 오히려 업그레이드에 대한 회의적 반응이 나오고 있을 지경입니다. 이건 마소의 제품군들이 어느 정도 성숙기에 접어든 탓도 크지만, 계속 새기술이라면서 마이너한 개량을 신제품 삼아 업글을 촉진한 마소의 마케팅에 대한 피로감도 커 보입니다. 윈도의 경우 XP SP1과 SP2는 천지차이고, Vista와 7은 사실 그 코어는 별반 차이가 없습니다. 그러니 고객들이 충분히 기다린 다음에 업글하려고 하는 측면도 강합니다. 마소는 몽땅 다 혁신이라는데 사실 크게 바뀌는 게 없다는 걸 배운 측면도 강하니까요.

리눅스 배포판의 경우에는 아예 Rolling release화 되어 가는 경향이 보입니다. 어떠한 기능과 품질을 달성한 후 다음 페이즈로 넘어가는 것이 아니라, 소소한 개량이 이어지면서 달 차면 버전 붙이는 경향이 늘어나고 있습니다. 우분투가 그 선두주자인 셈입니다. 리누스 트로발즈도 이미 리눅스 커널이 time-based release 즉 달차면 나온다…라고 언급하기도 했습니다. 개개 프로젝트 내부에서는 잘 관리되는 프로젝트들도 많고 오픈소스 소프트웨어들을 검증 및 지원하는 비즈니스(ex 레드햇)들도 많아서 별반 문제가 되지 않을 수도 있습니다. 하지만 데비안조차 time-based release로 이행하는 경향은 개발하는 입장에는 편리하고 재미있을지도 모르지만, 품질을 최우선시 하는 배포판들이 계속 줄어들고 있다는 점은 오픈소스의 일반화에 걸림돌이 될지도 모르니 불안한 것도 사실입니다.

결론은 Firefox 5 써보시고, 버전 넘버 너무 믿지 마시라는 글이 되겠습니다. 🙂

Chromebook: 문제는 가격, 요점은 보안.

링크: 구글 크롬북 홈페이지

태블릿보다 싸고 배터리 오래가면서 더 나은 웹 성능을 제공하는 컨셉의 크롬북. 데이터를 모두 구글에 저장해야 하는 점을 제외하면 괜찮은 솔루션이라고 생각한다. 특히나 비즈니스에서는 built-in hardware를 통한 보안 기능이 상당히 매력적이다. 다만 문제는 넷북보다 비싼 가격. 하드웨어 구성에서는 암호화 하드웨어를 제외하면 넷북에서 HDD가 빠진 정도인데 윈도 라이센스 가격도 빠질 터인데 넷북보다 비싸다. 솔직히 저 자격이면 개인에게는 화이트박스 넷북에 우분투 등 리눅스에 구글 크롬 브라우저를 기동시키는 게 낫다. 하지만 비즈니스에서는 좀 다르다. 가격에서의 요점은, 3G망 그리고 보안.

인터넷에 항상 연결되어 있어야 하므로, 사실상 3G망이 필수다. 월 $31에 기기할부값과 100MB 통신을 모두 제공하는 듯한데, 이런 조건이라면 데스크탑 사용자라면 모바일 기기로 사용해도 괜찮을 것 같다. 아마도 싱크 방식으로 동작할 가능성이 높으므로 Wifi를 병용한다면 생각보다 통신 사용량도 많지는 않을 것이다. 구글이 월100MB 정도를 적정량으로 보고 있기도 하다. 다만 스트리밍이 문제인데, 멀티미디어의 경우에는 캐시를 대량으로 사용하는 방식일 가능성이 크다. 100MB라면 멀티미디어보다는 정적인 웹과 gmail/docs/calendar 등의 사무작업용이다. 정해진 사이트에서만 3G망을 사용할 수 있도록 하는 기능도 있을 수 있겠다.

보안이 중요하다면 크롬북은 생각보다 비싸지 않다. 일반 넷북에 스토리지 단위로 암호화를 (성능저하없이) 적용하려면 적어도 기기당 $50은 들 것이다. 별도 칩과 하드디스크 분리방지장치가 필요하니, 사실 저 가격도 싸게잡은 편이다. 거기에 윈도를 쓰려면 윈도용 보안제품도 따로 구매할 필요가 있다. 구글 크롬은 가장 보안이 좋은 브라우저 중 하나이고, OS 자체 내에서 built-in 보안이 통합되어 있다. 개인적으로 저 built-in hardware based security가 크롬북에서 가장 매력적이었다. 꼭 구글 독스가 아니더라도, MS 웹 오피스를 크롬북에서 구동하지 못할 이유는 없다. 어쩌면 가격 대비 가장 안전한 단말기일지도 모르겠다. 그리고 그런 면에서 크롬박스가 기대된다.

일단 기업용으로 대량으로 팔리기 시작한다면 개인들에게도 싼 가격에 제공할 수 있을 것이다. 최소한 넷북보다 낮은 가격이 필요하다. 어차피 x86에 제한될 이유도 없는 시스템(모두가 웹, 즉 스크립트 형식으로 돌아간다.)이니 ARM등이 싼 가격에 웹 처리에 부족함이 없는 수준까지 올라온다면 ARM 등 기반의 SoC 기반으로 발전할지도 모른다. 안드로이드 태블릿과 같은 하드웨어를 갖추게 될 가능성도 크다. 인텔이든 ARM이든 구글은 적합한 솔루션을 골라쓸 수 있다. 특히 안드로이드가 Java 관련해서 오라클과 소송중인데, 웹 앱의 가능성을 실험해보는 테스트 베드로서도 쓸만하다.

문제는, 이 모든 개념들이 서버 집중식의 Network Computer와 하나도 다를 것이 없다는 점이다. PC와 웍스테이션이 등장한 이후, Sun, Oracle 등 쟁쟁한 도전자들이 기업들에게 제안했지만 모두 실패해 왔던 넷 컴퓨터. 과연 구글은 이를 성공시킬 수 있을까? 내 생각으로는 안드로이드 태블릿의 하드웨어가 발전하면 그보다 더 큰 스크린, 더 오래가는 배터리, 커다란 키보드를 달고 비즈니스용 머신으로 발전할 것이라고 본다.

48/2(9+3), 끼어든 김에 A/S도 해야겠지…

밑 글을 쓸 때, 나는 공학용 전자계산기 결과를 가지고 싸우는 글들을 염두에 두고 있었다. 그래서 두번째 문단에서 기계와 논리를 언급했던 것인데, 그 이후로 2를 주장하는 글들을 읽어보면서 이게 병림픽…이었음을 알게 되었다. 논리는 간데없고 권위있다고 생각되는 자료들을 끌고와서 끼워맞추는데 사람들이 혈안이 되어 있었다. 초등학교 산수계산 문제에 대수학의 변수를 다루는 공리들을 끌어들이는 부분은 압권이었다. 그래서, (9+3)이 a라고? 변수면 변수고 상수면 상수지 미소년이 여장했다고 자기 마누라 삼겠다고 하실 분들이다. 어떤 강사는 이거 고민하다가 학생들이 헷갈려서 대수학 문제 틀릴까봐 걍 2로 봐! 라고 강변하기도 하더라만…

그나마 인정할만한 논리는 이 기사처럼 식이 잘못됐다, 이다. 상수끼리 곱하는 경우니까 곱셈 연산자를 생략 못한다고 보는 견해이다. 즉, 2(9+3)라는 항이 잘못되었다는 것. 상수 사이에 연산자가 없을 경우에는, 더 기본적인 공리, 즉 십진법(왼쪽에 있는 숫자는 바로 그의 오른쪽에 붙어있는 숫자보다 10배 큰 값을 나타낸다.)이 적용되지 않는 괄호에는 적용할 공리가 없기 때문이다. (해석불가. 그러니까 이 식을 에러내는 MS엑셀이 잘 짜인 프로그램이라는 이야기다.) 사실, 변수가 없는 단순 계산식이기 때문에 상수고 뭐고 말할 필요조차 없지만서도. 즉 연산자 생략이 불가능하다는 논리가 성립한다. 따라서 초등학생에게는 음수랑, 0으로 나누는 것처럼 링크한 기사에 따라서 걍 이 문제 중고등학교에서 배우니까 지금은 식이 틀렸다고 생각해, 하고 넘어가야 할 것이다.

하지만 이 식이 잘못되었다고 하기에는 이 식을 계산할 수 있도록 추가할 수 있는 공리들이 있으므로 찝찝하다. 공리를 추가하기로 하고 넘어가보자. 물론 위 식은 변수가 없어서 대수학의 공리들을 적용하면 안 된다. 덕분에 제멋대로 추가해야 하는 병림픽이지만, 이긴 병신이 되기 위해서라도 2인지 288인지를 결론지어줘야 할 것 아닌가.

답이 2이냐 288이냐를 따진다면, 답은 288쪽이다. 왜냐면 288은 상수끼리의 곱셈 연산자를 어느 한 항이 괄호로 싸여있으면 생략할 수 있다, 라는 공리 하나만 추가하지만, 2는 그에 더해서 그 경우 생략된 곱셈 연산자는 다른 곱셈, 나눗셈 연산자보다 우선한다, 라는 공리를 하나 더 요구하기 때문이다. 그리고 수학에서는 가장 적은 공리들(혹은 연산들)로 이루어진 계에서 식을 다루어야 한다. 누구는 (구글에서 찾아지지도 않던) 미 수학협회의 리뷰어 가이드를 언급하던데, 굳이 전문가들인 리뷰어들에게 언급할 정도면 당연히 이는 (해당 Article과 review에 쓰이도록 특별히 언급되어야만 하는) 추가되는 공리로  봐야 하는 것 아닌가? 어째서 합의되는 최소한도의 공리로 해결되는 문제에 특별히 다른 공리를 더해서 적용하려고 하는지 이해가 되지 않는다. 나도 분명히 덧셈 연산자를 생략한 수식 작성자의 의도는 모두 분모라고 표현하려는 것이었다고 생각한다. 하지만 우리가 수학식을 볼 때 그걸 쓴 사람의 의도를 생각해서 계산해야 하는가? 아니다, 중요한 것은 공리들이고 그로 인한 전개과정(적용)일 뿐이다. 이런 면에서 변수 문제에서 애들이 틀릴까봐 벌벌 떨어야 하는 위 링크동영상의 강사도 이해는 간다. 하지만 일단 답이 나와야 한다면 288이다.

즉 생략된 곱셈 연산자에게 더 높은 우선순위를 부여하는 근거가 어디 있냐는 것인데, 여기저기서 종결자라고 하던 중학교 교과서를 들이민 이의 글을 보면 그거 전부다 변수 다루는 代수학 쪽의 설명이다. a가 (9+3)이랑 같다고 생각해서 그리 쓴 것일텐데 미안하지만 전혀 그렇지가 않다. 대수학 원론만 봐도 그런 거 잘 나오니까 새로 설명하지는 않겠다. 내 전공이 아니기도 하고.

알아듣기 쉽게 비유를 하자면, 초등학생들끼리 경쟁하는데 친구들 사이의 평판이나 시험 성적, 운동 능력 등이 아니라 어른들의 사정을 들고 와서 겨루는 것과 같은 사고방식인 것이다. 현실적으로는 먹힐 수도 있겠지만, 그게 옳은 답인가?

글이 길어졌다. 오랫만에 세줄 요약 들어간다.

  1. 숫자와 사칙연산, 괄호만으로 이루어진 초등학교 산수 레벨에서는 이 식은 잘못된 것이다.
  2. 계System 이론에서는 해당 식을 계산할 수 있는 최소 공리의 계가 옳다고 본다.
  3. 1.의 계를 확장해서 공리를 추가해야 하는데, 이중 2개 추가하는 2보다는 1개만 추가하는 288이 옳은 답이다.

이렇게 써 줘도 변수를 다루는 공리들을 적용해야 한다는 사람들이 개종?할 것 같지는 않지만, 어? 288이 아니라 2인가보다… 라는 사람들에게 도움이 됐으면 한다.

48/2(9+3), 왜 이런 게 문제가 되지?

48/2(9+3), 이 수식의 답을 두고 2파와 288파가 나뉘어 싸우고 있다고 한다. 전산학 전공 입장에서 보자면, 이는 매우 단순한 Parsing 문제이다. 즉, 문제의 수식을 다음 중 어느 쪽으로 해석할 것인가의 문제이다. (해당 수식은 이 사이트를 통해 생성한 gif 파일이다.)

위 수식의 경우는 답이 288이요, 아래 수식의 경우에는 2가 될 것이다. 수학식의 계산 순서는,

  1. 괄호가 존재하면 괄호 내 식을 우선적으로 계산한다.
  2. 곱셈, 나눗셈이 더하기, 빼기보다 우선하고 각 둘 사이는 동등하다.
  3. 왼쪽으로부터 오른쪽으로 계산해 나간다. (즉 왼쪽의 연산자가 우선한다.)

라는 원칙에 따라서 움직인다. 빠른 원칙이 먼저 적용된다. 이에 따르면 아래 수식으로의 해석은 불가능하다. 나누기, 곱하기는 동등한 우선순위를 가지며, 따라서 2(9+3)=2*12의 곱셈을 먼저 계산한 후 그 결과로 나눌 이유가 없다. 다만 시각적으로 아래 수식을 한 줄에 표시한 것으로 보일 수도 있으나, 엄격하게 수학식의 규칙을 따른다면 답은 288이다. 곱셈 연산자의 생략은 단지 편의상의 생략일 뿐, 더 강한 우선순위를 정해주는 것은 아니다. 만약 2로 답을 내는 계산기가 있다면 그 계산기가 stack관리에 문제가 있는 제품이라는 뜻이다. 학부생이 계산기 프로그램 짜면 자주 틀리는 부분이기도 하다. -_-;;; 아니면 계산기를 만든 엔지니어가 곱셈의 생략을 분모로 표시하려는 의사로 간주했던지. 하지만, 그것은 편리할지는 몰라도 원칙에서 어긋난 잘못된 구현이다.

기계보다는 논리를 따라야 한다. 기계는 논리의 현실적 구현일 따름이다. 즉, 버그는 숙명이다. 사람은 시각에 크게 의존하니, 연산자를 생략한 부분이 더 높은 계산순위를 가지는 것으로 착각하는 것은 이해할 수 있다. 다만 그것을 가지고 문제가 있는 계산기까지 들먹이며 옳다고 우기면 곤란하다. 나도 소프트웨어 엔지니어 출신이지만, 전자기기란 버그 투성이이기 일쑤이다. 이 기계는 이러한 결과를 내고, 저 기계는 저러한 결과를 내니 두 결과가 존재할 수도 있다는 주장은 틀렸다. 거기에 괴델의 불완전성 정리처럼 수학문제는 답이 없거나 여러 개인 상태를 넘어서서 답이 있는지 없는지조차 모르는 상태가 종종 나오지만, 48/2(9+3) 수식 정도에서 그러한 문제가 터지면, 비행기는 떨어지고 인터넷은 바로 마비되어야 할 것이다. 간단히 말하면 아닌 건 아닌 거다. 48%2*(9+3)이면 누구도 이론이 없을 결과를 가지고 설왕설래하는 것은 보니 정말 외관에 홀리면 답이 없다.

그리고 한국의 수학, 논리학 교육 수준을 알 만 하다. 도대체 왜 이게 인터넷에서 난리여야 하나? 어떤 매체는 전세계 네티즌의 논란이라고 썼던데, 얼굴이 화끈거렸다. 수학공식 외울 줄만 알았지, 수학식의 계산 순서조차 모르는 사람들이 우글거리는 곳, 그 곳이 바로 대한민국이다. 더욱더 문제는 패거리를 이루면 옳게 될 수 있다고 믿는 사람들과, 그걸 두 답이 나왔다며 논란이라고 써 주는 언론의 무능한 기자들이다. 이러다가 마트에서 1플러스1 행사라면서 3개 줬다고 1+1=3이라고 우기는 작자들이 나타나지나 않을까 정말로 걱정된다.

Windows Vertex 발표: 클라우드에서의 윈도 – 만우절 농담.

— 만우절 장난입니다. 🙂

링크: Windows Azure Tools 페이지의 Windows Vertex

마이크로소프트(이하 MS)가 윈도 버텍스(Windows Vertex, 이하 “Vertex”)를 발표했다. 간단히 말하면, MS의 클라우드 서비스인 Windows Azure에 상시접속(일시적으로는 Stand alone도 가능)하는 조건으로 무료로 이용가능한 최소한의 윈도. 번들로 제공되는 소프트웨어는 Internet Explorer 9 for Azure Vertex와 일종의 분산 파일 시스템 탐색기인 Azure Explorer만이다. 즉 그림판, 계산기, 게임 등의 보조 프로그램들과 탐색기는 제공되지 않는다. 제공되는 스크린샷으로 보면 Aero는 적용되는 듯 하다. Vertex 자신의 설치운용공간 외에도 로컬 하드디스크에 NTFS 파일시스템을 만들고 접근할 수는 있으나, 이는 Azure Distributed File System(이하 “ADFS”)의 일부로만 가능하다고 한다. 다만 Azure가 타 클라우드와의 차이점으로 강조하는 로컬 어플리케이션 지원을 이용하면 윈도용 프로그램을 실행시키는 것도 가능하다고 되어있다. 위 링크 페이지에서는 Office 2010(Web Office도 보인다)와 Adobe Photoshop CS5를 그 예로 보여주고 있다. 사실상 ADFS를 거친다뿐이지 대부분의 윈도 프로그램들을 실행할 수 있을 것으로 기대된다.

사실 Vertex는 개인사용자들을 위한 것이 아니라, 기업내에서 Private Azure System을 구축해서 각 단말 PC에 Vertex를 설치하여 일종의 Private Cloud를 구성하는 것을 목표로 하는 윈도다. MS는 실수요자인 기업들이 확장할 때 들지도 모를 추가 라이센스 비용을 걱정하지 않도록 Vertex는 무료로 제공하는 것 같다. (나머지 Azure System은 잘 모르겠지만…) Live 계정을 이용해서 MS의 공공 Azure 클라우드에 접속하는 방법으로도 사용가능하겠지만, 이는 ADFS로 자신의 데이터를 내놓아야 한다는 점에서 그닥 권할만한 방법은 아니다. 개인사용자에게는 클라우드 서비스를 만들어보고, 테스트해보는 실험용의 성격이 더 강하다. 잔머리를 굴려보자면, Azure Standalone Server를 Vertex에 설치해서 PC내에서 북치고 장구치는 1PC 클라우드를 만들면 잘 돌 것 같기도 한데, 이제 발표되었으니 어떻게 해킹될지도 관심사다. 잘만하면 무료로 정품 윈도를 사용하는 방법이 될 지도 모른다. 또한 Vertex를 무료로 뿌려서 윈도 Live 서비스와 Azure 클라우드에 의존시킨 후에 유료화 또는 광고 투입 등으로 수익을 내는 모델도 생각해볼 수 있겠다. 사실 윈도 어플리케이션을 로컬에서 돌릴 수 있는 Vertex가 무료로 제공될 경우에 확실히 Google Chrome OS의 미래는 어둡다.

레이 오지가 떠날 때는 걱정했는데, MS의 전략은 확실히 바뀐 것 같다. 윈도 자체에서의 수익은 계속 줄 수 밖에 없으니 클라우드에 의존하는 가장 간단한 윈도를 무료로 뿌려서 져변을 확장하고, 실질적으로 수익은 클라우드 서비스에서 발생키는 거대한 실험을 시작했다. 나도 MSDN 블로그가 아니었으면 이런 시제품?이 발표된 것도 몰랐을 정도로 MS의 첫 시작은 소극적이지만, 이 또한 무료 윈도의 파괴력을 생각해보면 기업용 시장에서 조심히 시작하는 MS를 이해못할 것은 아니다. 거인 MS가 진심으로 움직이기 시작했다.

– 만우절 장난치고는 너무 머리를 많이 굴리고 품이 들어서, 왠지 실현됐으면 하는 강한 바람이 들기 시작했다. -_-;;;