음, 그러니까 말이죠…

한국에서 이해관계 조정을 해내는 조직은 대법원과 헌재재판소 밖에 없나, 하는 아득함을 자주 느낀다. 아니면 해외 사례 정도가 유일한 조정 기준 일까나. 행정부는 해외 사례가 나올 때까지 좌충우돌하고, 입법부는 이리저리 긁어모아 법률을 만들어 보지만 어느 쪽이든 나오는 순간 손해보는 이익 집단이 헌법 소원을 집어넣는 이상에야… 오늘 대화의 결론은, “헌재 재판관 선출을 직선제로나 해볼까요?”였음. -_-;;

– 아니 정말 농담이 아니라 내각제 국가였다면 내각에서 이뤄져야 할 파워 게임이 헌재에서 이뤄지는 국가라면, 그 파이널 배틀의 배틀러!;;를 국민이 직접 뽑을 기회 정도는 줘야 하는 거 아닌가, 3배수 정도를 대통령, 국회, 대법원장이 각각 추천하고 렛츠 배틀! 이라는 감각으로.;;;

– 트위터에서 은둔을 선택했더니 블로그가 트위터화 되어가는구만. -_-;;;

– 개인적으로는 국회에서 전원 추천 후 호선 하는 쪽을 선호하긴 합니다. 다만 임기를 1/3씩 엇갈리게 해서 1/3씩 선출하는 것으로.

부동산의 가격: 월세 합의 현재가치란 관점에서.

부동산의 가격을 이용기간 동안 월세 합의 현재가치로 평가하면 현재 서울 부동산 특히 주택 가격을 감당할 수 있는 이는 많지 않을 것이다. 특히 재건축 비용을 자산 가치 증가로 만회하기 힘들어지면서 내구 연한이 지난 아파트의 잔존 가치와 이용 가능 기간은 크게 감소하였고, 잔존가치가 0이라면 이로 인한 가치 저하 폭은 이자율(연 2~5%)에 따라 40~60%에 달한다. 물론 대지 지분과 재건축 조합 자격의 가격을 마냥 0은 아닐지라도 인구구조상 장기적으로 재건축 비용(부담금)이 늘면 늘었지 줄어든다고 보기는 어렵다. 국민은행의 자료를 보면 서울의 실질 아파트 가격은 08년 대비 약 7.5%의 조정을 거쳤으나, 이러한 측면에서 보면 아직 완전히 바닥을 다졌다고 보기는 어렵다. 재건축 제도의 변경, 일반분양분 수요 추이에 따라 재건축 비용은 변할 수 있으나, 투자용으로는 물론이고 실거주용 아파트의 구입 또한 매우 신중해야 할 필요가 있다.

팁으로 30년간 아파트가 버티고 재건축 비용(철거,건축,이주,재입주 모두 포함)이 새 아파트 구입 가격에 준한다고 가정할 경우, 30년치 월세의 현재 가치는 연 이율 5%에서는 월세의 192배, 2%에서는 월세의 274.2배이다. 역으로 말하자면 현재 가격을 저 숫자로 나누면 실제론 월세를 얼마 내면서 살고 있는 것인가에 대한 답이 나온다. 4.8억 수준일 경우, 30년간 매월 약 200만원 수준의 월세를 지불하는 것과 같은 지출이 되는 셈이다. 이는 대지 지분과 재건축 조합 자격의 가격을 고려하지 않았지만, 자신의 부담이 어느 정도인지에 대한 기준 정도는 될 것이다.

– 재건축까지의 기간이 짧아지는 노후 아파트의 경우엔 훨씬 더 가혹한 계산이 필요하다.

– 그런 면에서 재건축이 용이한 저층에 세대가 적은 연립 주택의 경우가 더 유리할 수도 있다.

월탱, 장갑형 전차.

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

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

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

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

애플, 역사는 반복되는가.

이번 애플 워치와 새 맥북을 보면 잡스가 쫓겨난 이후 맥 비즈니스에서 쇠퇴를 거듭하던 옛적 애플이 슬쩍 보인다. 당시 애플은 윈도95 이후 좁아지는 기술적 격차에 새로운 장르의 제품들을 선보이고 기존 제품(맥)의 고급화로 이윤폭을 지키려는 필사적인 노력을 경주하고 있었다. 뉴튼, Duo처럼 재미있고 선구적인 제품들도 있었지만 실제 소비자들에게 그만한 가치를 제공했냐 하면 비관적일 수 밖에 없었다. 초기 호응이 좋았다하더라도 결국 꾸준한 추가 매출을 올리는데는 다 실패했었는데, 애플 워치와 포트가 사라진 새 맥북은 그 전철을 피할 수 있을까?

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, 컨텐츠 거래에 있어서는 소비자보호보다는 개발, 공급을 장려하고 국제성을 중시하는 예외 규정이 현실적으로 필요해 보인다.

 

ARM의 Big.LITTLE: 이게 무엇인가? #1/2

모바일 시스템은 성능과 전력의 trade-off가 큰 문제다. 대기 중 기능할 필요가 없는 노트북의 경우는 그나마 나으나 스마트 기기, 특히 계속 통화대기가 필수인 스마트폰은 더욱 심각하다. 하지만 스마트기기의 고성능화를 멈출 수는 없고 배터리 용량을 늘리는 것도 한계가 있다. 이를 해결하기 위해서 ARM은 Big.LITTLE(이후 “빅.리틀”로 표기)이라 불리는 구조를 고안했다.

핵심은 저전력-저성능 코어(리틀 코어)와 고성능-고전력 코어(빅 코어)를 한 칩에 박아넣어서 나누어 쓰는 것. 대기상태나 낮은 부하의 작업에는 리틀 코어만을 구동시키다가 게임, HD동영상 플레이 등 고부하의 작업이 시작되면 리틀 코어를 끄고 꺼두었던 고성능 코어(빅 코어)를 켜서 실행한다는 아이디어다. 한 종류의 코어들만으로 구성된 칩에 비해 얻어지는 이득은 두 가지로,

  1. 대부분의 사용시간을 점하는 저부하 작업에서의 전력 소모가 줄어들고,
  2. 고성능 코어는 성능향상에 좀 더 집중할 수 있으므로 더 높은 최고 성능을 제공할 수 있다.

이 점들을 ARM(과 삼성)은 이 문서와 이 문서에서 다음 그림들과 같이 설명하고 있다. (현 세대에서 ARM과 삼성은 리틀 코어로 Cortex-A7 아키텍쳐를, 빅 코어로는 Cortex-A15 아키텍쳐를 적용하고 있다.)

Cap 2013-08-04 22-13-06-866
녹색 실선으로 칠해진 부분이 고성능 코어만으로 구성했을 때보다 저부하 상황에서 절감되는 소비전력이다.
Cap 2013-08-04 22-14-00-610
Async Architecture는 단일 종류 코어들만으로 구성된 구조를 뜻한다. 전력관리를 위해 코어별로 서로 다른 전압/클럭 주파수를 적용하게 된다.

단점이라면 (동시사용모드인 MP는 아직 제대로 구현되지 않았으므로) 빅, 리틀 코어들을 동시에 구동할 수는 없어서 OS에 제공되는 코어수에 비해 칩이 더 커진다는 점인데, 삼성은 엑시노스 시리즈에서 리틀 코어들이 빅 코어들의 칩 다이 면적 대비 13% 정도만 차지하므로 큰 부담은 아니라고 밝히고 있다. 또한 빅-리틀 코어간 변환(Migration)이 멈추는 느낌이 들지 않도록 매우 빠르게 이루어져야 하는데, ARM은 20000 사이클, 1GHz 속도에서 0.02초 이내에 마칠 수 있다고 언급하고 있다. 실제 최초로 판매된 빅.리틀 구조의 엑시노스 5 옥타 (엑시노스 5410, 갤럭시S4에 탑재)에서 갑자기 느려지거나 잠깐 멈추는 등의 불만은 찾을 수 없는 점으로 보아 이 점도 잘 보완되어 있다고 생각된다. 사실 이 칩의 실 동작으로부터 추정할 수 있는 문제점들이 더 있긴 한데, 일단 이는 이 글의 후속편에서 다루도록 하겠다.

이론상으로는 칩 다이 면적의 증가를 감수할 수 있다면 구동시간과 성능을 모두 잡아낼 수 있는 매력적인 솔루션이다. ARM은 빅.리틀 구조를 향후 핵심 구조로 삼고 계속 발전시키겠다는 전략을 표방하고 있다.

다만 현실에서 그렇다고 하기에는 아직 문제가 많이 남아있다. 이를 이해하기 위해서 일단 ARM이 이 빅.리틀 구조를 어떻게 구성했는지 알아보자. AMD의 불도저 아키텍쳐처럼 빅-리틀 코어 2개를 각각 붙여서 하나의 모듈로 만드는 방법이 직관적이지만, ARM은 빅 코어들과 리틀 코어들을 각각 클러스터로 묶고, 이를 버스(Cache Coherent Interconnect라 칭한다. 명칭대로 각 클러스터의 L2캐시들을 동일하게 유지하는 것이 역할)로 연결하는 방법을 택했다. 이렇게 함으로서 AMD처럼 완전히 새로운 모듈 시스템을 디자인하지 않고(불도저-파일드라이버 아키텍쳐의 개발지연을 보라.), 각각의 멀티코어 CPU를 통합하는 형식으로 빠르게 개발이 가능했을 것으로 보인다. 또한 리틀 코어와 빅 코어의 숫자가 같을 필요가 없어지는 장점이 있다. (ARM은 제어SW가 너무 복잡해지지 않도록 그 두 숫자가 같기를 권장하고 있기는 하다.) 이를 간단하게 개념화시키면 다음 그림과 같다. (출처)

Cap 2013-08-04 23-11-07-729

 

그리고 리틀-빅 코어간 변환은 세 가지 모드가 있다. 클러스터 변환, CPU별 변환, 그리고 리틀-빅 가리지 않고 모든 코어들을 사용하는 MP모드가 그들인데 이중 MP모드는 아직 제대로 구현되지 않은데다가 빅.리틀 구조의 장점을 대부분 포기하게 되므로 일단 클러스터와 CPU별 변환만을 보자.

클러스터 변환은 단순하게 리틀 코어 클러스터와 빅 코어 클러스터가 몽땅 변환되는 것이다. 즉, 빅.리틀 CPU는 리틀 코어들만 동작하고 있던가 아니면 빅 코어들만 동작하고 있던가 둘 중 하나다. 이렇게 하면 단순히 두 개의 멀티코어CPU 중 하나만 켜서 구동하고 있는 셈이므로 구현이 매우 쉬워진다. 현재 삼성 엑시노스 5410은 이 모드로만 동작한다. 그게 문제인데, 다음 글에서 다루겠다.

CPU별 변환(CPU Migration)은 각 코어들이 자유롭게 리틀-빅, 빅-리틀 변환을 한다. 즉 다음 그림과 같다. (출처는 바로 위 그림과 동일.)

Cap 2013-08-04 23-22-55-521

리틀 코어들 중 부하가 한계치를 넘어서는 하나의 코어만이, 빅 코어 하나를 깨워서 자기 일을 떠넘기는 게 가능한 모드이다. 즉 위 그림처럼 변환이 이루어지고 나면, 저 듀얼-듀얼 빅.리틀 CPU는 리틀 코어 하나(A7 CPU0)와 빅 코어 하나(A15 CPU0)만이 켜져서 동작하는 상태가 된다. 물론 빅 코어가 작업을 끝내고 저부하 상태가 되면 이제 다시 CPU1을 깨워서 넘겨주고 자기는 꺼진다. 이 작업을 OS에서 보면 다음 그림과 같은 형태로 제공된다. (출처)

Cap 2013-08-04 23-28-24-892
이 그림에서는 각 빅-리틀 코어가 1대1로 매칭되는 것처럼 보인다. 이론상으로는 그럴 필요가 없으나, 리눅스에서는 이렇게 여기게 되고 현재 실제 존재하는 칩들은 같은 숫자의 빅-리틀 코어들을 가지므로 실제로도 저렇게 동작하게 된다.

위 그림을 보면, 리틀-빅 코어간 변환 과정에 CPU freq 전환이 표시되어 있다. 바로 여러분들이 윈도 노트북, 데스크탑에서 자주 보는 CPU클럭 전환 기능을 이용하여 리틀-빅 간 변환을 한다. 부하가 걸리면, 리눅스는 리틀 코어의 클럭을 계속 올리게 되는데 빅.리틀 구조에서는 100%이상의 속도로 올릴 수 있도록 지원한다. 즉 100% 이상으로 올릴 때 빅 코어로의 전환이 일어나는 것이다. 빅 코어를 쓰다가 부하가 줄어들어 리눅스가 100% 이하의 클럭으로 내리면 그 때 다시 리틀 코어로 전환하게 되는 구조다. 바로 이런 특성 때문에 CPU Migration은 또한 In-Kernel Switching이라고도 불린다. 리눅스 커널의 컨트롤로 변환이 일어나기 때문이다.

필요한 만큼만 전력 많이 쓰고 뜨거운 빅 코어를 가동시킨다는 점에서 CPU별 변환이 되어야 빅.리틀 구조의 장점, 특히 저전력 특성이 살아난다. 실제로 현재 ARM 개발사들의 개발모임인 Linaro의 문서들에서는 클러스터 변환은 언급도 잘 되지 않고 있다. 또한 CPU별 변환을 하려면 각 코어별 클럭 주파수 조정이 핵심이라는 점을 위 문단에서 확인해볼 수 있다.

그런데… 정작 첫 판매물인 엑시노스 5, 그리고 갤럭시S4는 클러스터 변환만이 가능한 상태다. CPU별 변환이 가능하지 않다른 이야기도 흘러나오고 있다. 사실 엑시노스 5410의 구조상 불가능해 보인다. 그렇다. 현재 발매 중인 갤럭시 S4는 발열도 악명이 높은데, 이는 엑시노스 5 5410의 잘못된 설계가 불러온 것이다. 이 점을 까는 게 다음 글의 주제다. 사실 이 이야기를 하고 싶어서 배경지식으로서 이 글을 작성했다고 보아도 무방하다. 기대하시라.

에바Q 1회차 감상후기

일단 네타바레가 난무하는 글입니다. 아직 안 보신 분들이라면 포스터 밑으로는 읽지 말길 권해드립니다.

– 하나만 하자면, 아, 슬프다. 정품의 운명이여… 어쩌다 야바위꾼을 만나서.

Continue reading “에바Q 1회차 감상후기”