Empty

iOS 앱 첫 심사 요청 후,

하루도 채 안되서 시원하게 리젝 먹었다.

리젝 메일로 iTunes Connect > Resolution Center 통해서 자세한 사항을 읽어보니..

"ipv6 환경에서 테스트 하는데 네 앱에서 에러 메시지가 뜨더라."

라고 하며 ipv6 환경에 대한 가이드 라인을 blah-blah 적어놨더라.

심지어 친절하게 스크린샷까지 첨부해줬다.

 <- 전달받은 스크린샷의 일부.

1. 애플의 함정

 - ipv6 환경이라니. iOS 9부터 ipv6 환경은 필수적으로 지원해야 한다고

애플에서 공식적으로 발표한 것은 알고 있었다. 하지만 막상 이렇게 닥치니 멘붕.

 - 정말 이 오류가 재현이 되는지 확인해보고 싶었다.

 - 그래서 리젝당한 메일을 따라 ipv6 환경 셋팅 방법 문서을 읽어내려갔다.

( https://developer.apple.com/library/content/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW16 )

- 읽다보면 wifi 없이 네트워크에 연결된, 맥이 설치된 장비가 필요한데 나는 맥북밖에 없었고

랜선을 직접적으로 꽂을 수가 없었다.

- usb 이더넷 젠더를 따로 구매해야 하나 심각하게 고민하던 중에...

- 유니티 포럼에서 나와 비슷한 상황에 처한 사람들이 많은 것을 발견.

( https://forum.unity.com/threads/solved-unity-5-6-1-iaps-cannot-initialize-on-ipv6-network.477122/ )

- 위 url 에서 unity 개발자가 마지막에 남긴 코멘트를 자세히 읽어보면..

"unity는 이미 ipv6를 지원하고 있으므로 애플이 던진 모든 리젝이 ipv6와 꼭 관련이 있는 건 아니다."

- 이 코멘트에 따르면 확실히 ipv6 문제가 아니다. 애플이 던진 함정에 빠진 것이었다.

문제를 다시 생각해보니.. 내가 전달받은 문제의 스크린샷이 실마리였다.

2. 실마리

- "구매 가능한 상품이 없습니다." 이게 해결의 실마리였다.

유니티 공식 문서에 따르면 다음과 같은 문구가 있다.

( https://docs.unity3d.com/kr/current/Manual/UnityIAPiOSMAS.html )

NoProductsAvailable 초기화 오류가 발생하는 경우 다음의 사항을 확인해야 합니다.

• - iTunes Connect 제품 식별자가 Unity IAP에 제공된 제품 식별자와 정확하게 일치해야 합니다.
• - iTunes Connect 애플리케이션에 대해 애플리케이션 내 구매가 활성화되어 있어야 합니다.
• - 해당 상품이 iTunes Connect에서 판매 중이어야 합니다.
• - iTunes Connect 제품을 새로 생성한 경우 구매가 가능하려면 몇 시간이 소요될 수 있습니다.
• - 최신 iTunes Connect 개발자 약관에 동의하고 유효한 계좌 정보를 등록해야 합니다.

- iTunes Connect 에서 '앱 내 구매' 메뉴를 들어가보니 이게 웬일...

첫 심사 때 같이 심사 받았던 인앱상품으로 등록해둔 상품들이 전부 리젝 먹으면서 "개발자의 조치가 필요함"

이라는 에러 메시지를 남기고 있었다.

- 문제가 되는 상품을 클릭해보니 현지화 부분에서 에러 표시가 남겨졌지만

정확히 어떤 부분이 문제가 되는지는 알 수가 없었다. 그래서 관련 검색 시작.

( 1 : http://mmzzuu.tistory.com/67 )

( 2 : https://swifteyes.blogspot.kr/2017/04/itunes-connect.html )

- 미리 경험해 본 선배님들의 글에 따르면 표시 이름(display name)에 문제가 있다고 한다.

그래서 나도 수정했다. 어떻게 수정해야 될지 몰라서 일단 기존에 표시 이름과 설명이 동일하게 해둔 것을

설명은 그대로 두고 표시 이름만 짤막한 단어 형식으로 변경했다.

- 그 외는 건드리지 말라고 해서 인앱 상품 에러만 수정해서 다시 재심사 요청.

(display name 수정 + 혹시 몰라서 수정한 display name이 출력되는 스크린샷 재첨부)

3. 승인

- 하루가 지나고 애플의 답변이 왔다. 24시간 이내로 앱이 출시될 거라는 메일이..

남들은 3차 이상 리젝 먹고 출시하는 경우도 허다했지만 그래도 그동안 고생한 것 생각하면 무척 기뻤다..

- 이 일을 계기로 2가지의 교훈을 얻었다.

(1) 문제를 해결하려고 하기 전에 문제가 정확히 무엇인지 파악하자.

(2) 화면에 에러 메시지 출력하는 것을 절대 귀찮아 하지 말자.

- 만약 내가 에러 핸들링 제대로 안 하고(대충 로그만 박는다든가) 심사 요청했으면 

과연 어떤 리젝이 날아왔을지.. 실마리 못 찾고 하마터면 ipv6 연결해서 테스트 해보고 좌절하고 

온갖 쓴맛을 다 봤을지도.. 생각만 해도 소름..

https://developer.apple.com/support/itunes-connect/kr/

대부분 iOS 앱 출시 준비하다가 발생하는 에러들을 보면..

위 가이드 대로 충실히(?) 이행하지 않아서 발생하는 경우가 대부분이다.

'~카더라' 통신 보다는 공식 가이드 문서를 잘 읽도록 하자.. (영어라 하더라도 orz...)

- 앱 거절 : 앱 아이콘 투명 라운딩 처리 

  => 투명 제거 아이콘을 유니티에서 올리고 자동으로 리사이징 맡김

  => iOS 7 이후 부터(?) '.png, 알파없음' 포맷만 허용하는 듯 (xcode 업로딩 실패 메시지로 뜬다)

- 앱 거절 : 앱스토어 아이콘 파일을 찾을 수 없다 

  => 1024x1024 앱스토어용 아이콘 이미지 파일 준비 (.png, 알파없음)

  => xcode 에서 프로젝트 Resources 우클릭 후 이미지 파일 추가

  => images.xcassets 에서 앱 아이콘에 추가한 파일 등록

- 앱 경고 : Missing push notification xx => 별도 포스팅 (http://secretroute.tistory.com/entry/1802101737)

- 인앱 결제 : 

  => 아이튠즈 커넥트 - 계약, 세금 및 금융 정보 등록 및 승인

  => app id : 앱내구입 활성화

  => 프로젝트에서 결제 구현

  => xcode9 빌드 설정 - Capabilities - 인앱 결제 활성화 - 빌드 후 업로드

  => 아이튠즈 커넥트 - 나의 앱 - 앱내 추가기능 - 앱내구입 - 상품 등록

  => 아이튠즈 커넥트 - 사용자 및 역할 - 테스터로 초대할 사람 추가 (iTunes connect 사용자(관리자급) / sand box 테스터)

  => test flight 에서 업로드 된 빌드에 대해 테스터 추가 (iTunes connect 그룹은 빌드 업로드시 자동 메일 알림 옴)

  => 테스터는 test flight 앱 설치 후 수신한 테스터 메일을 통해 초대 승인, 설치, 테스트 개시

  => 테스터가 결제하는 경우 iOS 팝업 상에 '베타 테스터에게는..(어쩌구저쩌구)' 가 추가로 기입되어있다.

   (Development 버전의 경우에는 [Environment: SandBox] 로, Production은 위와 같이 알림 표시 확인 -> 실제 결제x)

  => 구글 플레이는 가짜 영수증 발행해주는데.. 애플 스토어는 결제 안 될 거라고 표시만 해주고 아무런 알림도, 영수증도 없었다.

xcode 에서 빌드하고 앱스토어에 앱을 업로드할 때..

업로드는 됐긴 했어도 "Missing Push Notification Entitlement" 라는

경고 메일이 애플로부터 날아올 때가 있다.

이건 대체 뭔 소리인지..

- 요약 이슈 : 당신의 앱은 push 를 사용하지만 app id 상에서는 push가 활성화되어있지 않다.

이를 체크해서 검사한 뒤 다시 업로드 해라. (업로드 거절까지는 아니고 경고 메시지임)

- 경고 메시지이나 무시하면 앱 심사 거절 사유 + 업로드할 때마다 매번 경고 메일 날아옴.

- 해결 : 아래 절차대로 수행

(1) 애플 개발자 로그인 - app id 수정 - push 활성화 - push 용 개발자 인증서 생성 및 빌드머신에 인증서 설치

  : provisioning 상에서 entitlement: aps-environment 표시 확인 가능

(2) xcode 에서 프로젝트 열고 설정 창 - Capabilities 탭에서 Push Notifications 활성화

  : 아래 이미지처럼 앱 업로드 할 때 확인 가능

- 참고 링크 : http://blog.themuser.xyz/ios-missing-push-notification-entitlement-이슈-해결/

- (1)만 했더니 계속 경고 메일 날아와서 완전 멘붕했었는데.. xcode 8 부터 푸시 인증서 따로 요구 했다고 한다..

애플 진짜 짜증.. 이메일에서 참고하라는 링크 따라가면 xcode 설정 얘긴 없어서 헤맬 뻔했다.. 검색/공유 만세.

# =============== #

# Unity generated #

# =============== #

Temp/

Obj/

UnityGenerated/

Library/

# ===================================== #

# Visual Studio / MonoDevelop generated #

# ===================================== #

ExportedObj/

*.svd

*.userprefs

*.csproj

*.pidb

*.suo

*.sln

*.user

*.unityproj

*.booproj

# ============ #

# OS generated #

# ============ #

.DS_Store

.DS_Store?

._*

.Spotlight-V100

.Trashes

Icon?

ehthumbs.db

Thumbs.db

오랜만에 포스팅!

C 공부하다가 문득 printf()로 format에 맞춰 정수를 출력할 때,

"%ul"과 "%lu"의 차이가 뭔지 궁금해졌다.

내가 알기로는 보통 "%ul"이라는 format을 많이 쓰는 걸로 알고 있는데

찾아보니 이는 틀린 format이라고 한다. - 실제 일부 컴파일러는 에러를 내뿜는다고 함.

그런 의미로 평소에 별 생각없이 사용했던 printf()가 어떤 녀석인지 정확히 알 필요가 있을 것 같다.

일반적으로 위의 인터페이스에 따라 사용하고는 한다. (이 외의 인터페이스는 귀찮으니 생략)

다들 알다시피 printf는 format에 적힌 내용 중에 argument들을 변환하고 formatting 해준 다음,

standard output에 그 결과를 출력하는 일을 한다. return value로는 출력된 문자들의 갯수를 반환한다.

format에 입력할 수 있는 내용으로는 2가지가 있다. 

하나는 standard output stream에 그대로 복사되는 일반 문자들,

다른 하나는 argument들을 어떻게 변환/formatting할 것인지에 대한 conversion specification이다.

'[]'으로 묶인 내용은 선택적인 값을 의미한다. (명시해도 그만, 안 해도 그만. 필요하다면 명시해야겠죠?)

서식을 하나씩 살펴보면,

flag : 왼쪽 or 오른쪽 정렬할 것인지에 대한 표시. 

명시를 안하면 기본은 오른쪽이고, 왼쪽 정렬하려면 '-'을 붙이면 된다.

width : 출력물(?)이 차지할 너비로 숫자 값이다. 

오른쪽 정렬 상태에서 너비가 출력할 문자열 길이보다 크다면, 왼쪽이 텅 비겠죠?

.precision : 앞에 '.'은 width 값이랑 precision 값을 구분하기 위해서 넣어준다. 

precision은 숫자 값으로 무엇을 출력하느냐에 따라 값의 의미가 다르다. 문자열 또는 실수를 출력한다면, 문자나 소수점 이하 숫자의 최대 길이를 의미한다. 정수를 출력한다면 숫자의 최소 길이를 의미한다.

length : 정수를 short로 출력하려면 'h', long으로 출력하려면 'l'(소문자 ell).

specifier : argument를 어떻게 해석할 것인지에 대한 문자 값.

구체적인 conversion table이 있으나 이 포스팅의 제목에 초점을 맞춰서 'u'만 언급한다.

'u' = int; unsigned decimal number.

"%ul"과 "%lu"의 차이를 알기 위해 길게 돌아왔는데, 아마 감이 왔을 것이다.

서식의 순서를 보면 length 한정자가 먼저 나오기때문에 "%lu"가 맞고, "%ul"은 틀리다.

예제 코드들을 보면 "%ul"이라고 쓰는 경우가 굉장히 많은데 (심지어 책에서도 보인다)

바로 알고 쓰도록 하자~!

* Reference

- http://stackoverflow.com/questions/23852073/whats-the-difference-between-ul-and-lu-c-format-specifiers

- The C Programming Language 2nd edition (K&R) : 7.2 절

(2015-03-21 15:42)

바이두가 딥러닝에 주목하는 이유

딥러닝 시장이 뜨겁다. 가트너는 2014년 세계 IT 시장 10대 주요 예측 중 딥러닝을 포함했다. 빌게이츠 마이크로소프트 창업자 겸 기술 고문은 한 인터뷰에서 만일 지금 컴퓨터 과학을 공부하는 학생이라면 어떤 분야에 몰두했을 것 같냐는 질문에 딥러닝을 들기도 했다.

딥러닝은 컴퓨터가 여러 케이스를 조합해 자율적으로 학습하는 구조다. 인간의 뇌 같은 인식 구조와 유사한 형태의 학습을 통해 신경망으로 불리는 인공지능을 구축하는 것. 쉽게 말하자면 딥러닝은 인간의 사고방식을 컴퓨터에 적용하려는 것이다. 음성인식이나 자연어 처리, 검색 품질 등 다양한 작업에 접목할 수 있다. 요즘 주목받는 자동 운전이나 자율 로봇의 움직임 같은 것도 딥러닝을 필요로 하는 분야 가운데 하나다.

구글이나 바이두, 마이크로소프트, 페이스북 같은 해외 기업은 물론 네이버와 다음카카오 등 국내 업체도 딥러닝을 적용하고 있다. 네이버의 경우 네이버 딥러닝랩을 통해 음성 인식을 테스트하는 한편 뉴스 요약 서비스, 이미지 분석 등에 딥러닝 알고리즘을 적용하고 있다. 구글도 딥러닝에 열심이다. 구글은 인공지능 업체인 딥마인드를 지난 2014년 1월 4억 달러에 인수한 바 있다.

딥러닝을 언급할 때 함께 따라오는 말이 바로 머신러닝(Machine Learning), 기계학습이다. 기계학습이란 사람의 학습 능력을 본뜬 인공지능 체계를 말한다. 인공지능 개발을 위한 기본 개념으로 인간의 지식이나 정보, 경험 등을 컴퓨터에 넣어서 분석하는 것이다. 분석 데이터를 통해 머신러닝 체계를 구축하게 된다. 엔비디아 역시 3월 17∼20일까지 실리콘밸리 산호세컨벤션센터에서 열린 GTC(GPU Technology Conference) 2015 기간 중 딥러닝에 상당 시간을 할애했다. 그렇다면 엔비디아가 딥러닝에 주목하는 이유는 뭘까.

엔비디아 입장에서 중요한 건 GP GPU(General Purpose GraphicsProcessing Units), 그러니까 GPU 병렬 컴퓨팅이다. GP GPU는 GPU를 연산에 활용하는 기법이다. GPU 내부에 잇는 수많은 코어를 병렬로 여러 개 연결해서 한 번에 움직이게 하는 것. 이런 GPU 병렬 프로그래밍을 위해 쓰이는 표준 격인 이종 플랫폼 병렬처리 언어가 오픈CL(OpenCL)이다.

엔비디아는 이런 오픈CL과 비슷한 엔비디아만의 전용 GPU 병렬 프로그래밍 언어인 쿠다(Cuda)를 밀고 있다. 쿠다는 엔비디아의 다양한 게임웍스 모듈을 포함하고 있다.

엔비디아가 쿠다를 미는 이유는 엔비디아가 기본적으론 GPU를 많이 팔아야 성장하는 회사라는 점이 작용한다. 물론 엔비디아는 쿠다로 구현한 병렬 프로그래밍이 훨씬 좋은 성능과 효율을 낸다고 말한다. 실제로 쿠다의 가장 큰 장점은 성능에 있기도 하다.

하지만 그보다 더 이면에는 오픈CL이 업계 공용인 반면 자사의 전용 병렬 프로그래밍 언어를 이용하면 결국 엔비디아의 GPU 성장으로 이어질 수 있다는 포석이 자리 잡고 있다. 엔비디아는 구글 브레인이나 이미지, 영상 코덱 처리 등 다양한 작업을 쿠다로 만들어 GPU 시장 확대와 성장을 노린다.GTC는 이런 점 때문에 지난 1년 동안 쿠다로 구현한 애플리케이션은 어떤 게 나왔고 사례는 어떤 게 있었는지 확인하는 자리이기도 하다.

딥러닝(Deep Learning), 머신 러닝 역시 이런 맥락에서 이해할 수 있다. 엔비디아는 지난해와 마찬가지로 올해도 머신러닝을 강조하고 있다. 머신러닝을 CPU만이 아닌 GPU로 병렬 처리하면 훨씬 빠르게 구현할 수 있다는 것이다.

딥러닝은 GPU의 킬러 애플리케이션 중 하나가 될 가능성이 높다. GPU가 딥러닝에 주목하는 이유는 딥러닝 과정 자체가 병렬 연산 덩어리 같은 것이기 때문. CPU에 병렬 연산을 잘하는 GPU를 요구하는 적당한 대상이라는 얘기다.

주요 IT기업도 딥러닝에 공을 들이고 있다. 바이두는 지난 1월 딥러닝 슈퍼컴퓨터인 밍와(Minwa)를 개발했다고 밝혔다. 이 슈퍼컴퓨터는 딥러닝 알고리즘에 최적화한 것. 밍와는 36노드로 이뤄져 있다. 노드마다 6코어 인텔 제온 E5-2620 2개와 엔비디아 테슬라K40M GPU 4개, 56Gbps FDR 인피니밴드 등으로 이뤄져 있다. GPU의 부동소수점 연산 성능은 4.29TPLOS다. 밍와에 들어간 GPU 개수는 모두 144개다. 밍와의 당시 이미지 인식 에러율은 5.98%로 구글이 세운 6.66%보다 뛰어나다. 사람의 에러율은 5.1%로 알려져 있다.

딥러닝을 대규모 데이터 분석을 필요로 한다. 고성능 GPU는 이런 문제를 해소할 수 있는 방법 가운데 하나다. 딥러닝이 각광을 받게 된 것도 복잡한 구조를 처리할 수 있는 뛰어난 컴퓨팅 파워, 연산 능력이 생겼기 때문이기도 하다. 딥러닝은 복잡한 신경망 구조를 지니고 있는데 이를 뒷받침할 만한 컴퓨팅 파워가 등장한 것이다.

미국 실리콘밸리 산호세컨벤션센터에서 열린 GTC(GPU TechnologyConference) 2015 기간 중인 3월 19일(현지시간) 키노트에 나선 앤드류 응(Andrew Ng) 바이두리서치 책임자는 2007년까지만 해도 CPU 커넥션은 100만이었지만 2008년 GPU 커넥션은 10배 높은 1,000만에 달했다고 밝혔다. 여기에 2011년 클라우드로 확장되면서 CPU 커넥션은 10억까지 확대됐다고 밝혔다. 다시 2015년에는 GPU를 통해 1,000억으로 늘어났다. 그는GPU 하나로 딥러닝을 처리할 경우 212시간이 걸리던 게 GPU를 16개로 늘리면 20시간, 32개면 다시 8.6시간으로 줄어든다고 설명했다.

얼굴 인식 에러율의 경우 마이크로소프트는 3.67%, 페이스북 1.63%,CUHK 0.53%, 구글 0.37%인 반면 바이두는 0.15%에 불과했다고 밝혔다. 6,000개 이미지 테스트 샘플 중 에러는 9개에 불과한 수준이라는 설명인 것.

바이두는 현재 음성 인식과 딥이미지(Deeep Image)라고 불리는 화상 인식, 자연어 처리 연구 등을 진행하고 있다. 지난 2014년에는 바이두판 구글글라스 격인 바이두 아이(Baidu Eye)를 선보이기도 했다. 본체 좌우에 있는 카메라를 이용해서 사물은 인식한 다음 관련 정보를 음성으로 제공하는 것이다. 그는 바이두의 음성 인식 에러율이 애플이나 마이크로소프트, 페이스북, 구글보다 더 낮다고 밝혔다.

앤드류 응은 현장에서 바이두의 음성 인식 성능을 시연하기도 했다. 비교 대상과의 테스트에서 바이두의 음성 인식을 통한 텍스트 변환 성능은 잡음을 높인 상태에서도 상당한 인식률을 보여 눈길을 끌었다. 앤드류 응은 음성인식 기술이 웨어러블과 자동차, 가정용 전자기기 등 사물인터넷 시장을 바꿔놓을 것이라고 말한다. 그는 이렇게 딥러닝의 기회가 이미지와 음성, 행동 패턴 등에 있다는 점을 강조했다.

전자신문인터넷 테크홀릭팀

이석원기자 techholic@etnews.com

'펭귄 제국' 텐센트, 한국을 넘보다 (2014.11.20)

‘펭귄의 제국’이 전 세계로 영토를 확장하고 있다. 기업가치 160조원(1590억 달러), 전 세계 8위 기업. 온라인 사업만으로 삼성전자와 어깨를 나란히 할 정도의 덩치를 키운 회사. 이미 텐센트는 알리바바, 바이두와 함께 세계를 대표하는 중국 기업으로 이름을 날리고 있다. 불과 16년 만에 일궈낸 성과다.

텐센트의 핵심 플랫폼인 QQ(출처 : QQ 홈페이지)

텐센트를 한마디로 정의하기란 쉽지 않다. 워낙 서비스가 다양하고 얽히고설켜 있어서다. 서비스 브랜드를 나열하기조차 어려울 정도로 다양한 사업에 손을 뻗고 있다. 한 가지는 분명하다. 메신저가 주력인 IT 기업이라는 사실. ‘QQ’만 알면 텐센트의 절반 이상은 이해하고 있는 셈이다.

QQ는 국내 서비스에 비유하자면 네이트온과 싸이월드를 섞어놓은 메신저 서비스다. 겉모습은 MSN을 닮았고 수익모델은 싸이월드와 흡사하다. QQ를 중심으로 수많은 서비스들이 달라붙어 있다. 말하자면 QQ는 텐센트 네트워크의 허브다. 여기에 각종 콘텐츠 서비스와 게임, 전자결제, 전자상거래, 포털 등이 가지처럼 붙어 있다. 국내에 잘 알려진 위챗도 QQ가 모바일 메신저 시장으로 확장하면서 탄생한 부산물이다. 어찌보면 텐센트는 ‘메신저의 왕국’이라 할 만하다.

두 젊은 해커가 세운 ‘펭귄 제국’

텐센트는 1998년 마화텅과 장지동, 두 젊은 해커들 손에서 탄생했다. 당시 이들의 나이는 27세와 26세. 중국 선전대 소프트웨어공학과 출신의 프로그래머가 의기투합해 세계 8위 기업을 빚어냈다.

텐센트도 시작은 초라했다. 마화텅은 장지동과 함께 1998년 12만달러로 텐센트를 설립했다. 마화텅은 주식투자로 벌어 둔 자금을 창업에 쏟아부었다. 그리고 이듬해 2월 ‘OICQ’라는 인터넷 메신저를 선보이며 사업을 본격화했다. 창업 당시 해외에선 이스라엘 스타트업이 개발한 ‘ICQ’라는 인스턴트 메신저 서비스가 1200만명의 가입자를 확보하며 인기를 얻고 있었다. 이를 벤치마킹해 ICQ의 중국버전을 개발한 것이다.

출시 초기만 하더라도 OICQ는 중국 내 여러 메신저 서비스 중 하나일 뿐이었고 시장점유율도 높지 않았다. 출시 2달 만에 20만명의 가입자를 모았지만 다소 더뎌 보였다. 이 때 창업자인 마화텅은 인생을 바꿔놓는 결단을 내린다. OICQ를 무료 다운로드로 전환한 것이다. 애초 마화텅은 중국 이동통신사에 유료로 판매하는 서비스를 염두에 뒀다. 그 자신이 페이징 서비스를 연구해왔고 수익 모델도 그에 맞춰져 있었다.

무료 다운로드에 대한 사용자들의 반응은 즉각적이었다. 수많은 젊은 이용자들이 OICQ를 내려받았고 사용자수는 하루가 머다하고 늘어났다. 서비스 개시 9개월 만에 100만 사용자를 넘어섰고 2001년에는 무려 5천만명이 사용하는 인스턴트 메신저로 성장했다.

호사다마라 했던가. 가입자 폭증이 한창이던 1999년 8월, ICQ를 인수한 AOL로부터 소송이 제기됐다. AOL의 인터넷 메신저 ICQ와 텐센트의 OICQ가 상표가 유사하다는 이유에서다. AOL는 ICQ를 글로벌 서비스로 확장하기 위해 사용자 유치에 눈독을 들이던 때였다. 지적재산권에 무지했던 두 청년은 밖으로는 상표권 소송에 휘말리며 첫 번째 고민에 빠져들었다.

QQ 가입자수 증가 그래프(출처 : QQ 사이트)

안타깝게도 텐센트는 상표권 소송에선 패소했다. 결국 이들은 OICQ라는 서비스명을 버리고2001년 4월 QQ로 서비스명을 변경했다. 빠른 속도로 성장하고 있는 서비스가 감당하기엔 무척이나 벅찬 결정이었다. 무단으로 사용하던 아이콘 이미지도 모두 교체했다. 사용자들에게 사과까지 했다.

하지만 상표권 분쟁은 전화위복이 됐다. QQ라는 서비스명이 부르기 쉽다는 평가가 주를 이뤘다. 교체한 아이콘들도 호평을 불러왔다. 위기를 기회 삼아 더 큰 성장판을 연 계기가 됐다.

갑작스러운 고속 성장엔 통증이 따라오기 마련이다. 텐센트도 피해갈 수 없었다. 하루가 다르게 늘어나는 사용자로 서버 비용을 감당하지 못하면서 텐센트는 자금줄을 찾아다니기 시작했다. 서버를 늘리지 못한다면 곧 서비스가 마비될 정도였다. 이때 구원의 손을 내민 이가 남아프리카공화국 미디어 기업인 내스퍼다. 내스퍼는 자회사 MIH를 통해 2001년 텐센트의 지분 46.5%를 매입했다.

내스퍼의 투자로 자금을 수혈한 텐센트는 서비스 확장을 위한 광폭 행보를 시작했다. 2003년 9월 QQ게임과 RTX, 2003년 12월 포털사이트 QQ닷컴에 이르기까지 숨가쁘게 신규 서비스를 시장에 내놓았다. 그리고 2004년 6월 홍콩 증시에 상장하면서 일약 스타덤에 오르게 됐다. 현재 텐센트는 내스퍼의 MIH가 33.73%, 마화텅 회장이 10.16%, JP모건 체이스가 6.83%의 지분을 소유하고 있다.

메신저 QQ, 월활성사용자만 8억명 이상

텐센트 홀딩스 2014년 2분기 실적자료 85페이지. 주요 지분 현황.

텐센트 서비스의 대부분은 인스턴트 메신저 QQ의 파생상품이다. 모든 서비스는 QQ의 네트워크 파워에 기대어 성장하는 흐름을 보인다. QQ의 사용자를 흡수해 부가적인 수익 모델을 덧붙이는 식이다.

2014년 6월30일 현재 QQ의 월활성사용자수(MAU)는 8억2930만명이다. 이 가운데 모바일 등 스마트 디바이스로 접속하는 월활성사용자수는 5억2천만명. 특히 모바일로 접속하는 사용자수는 가파르게 늘어나고 있다.

모바일 메신저 위챗 성장세도 눈부시다. 중국 웨이신과 글로벌 위챗을 통합한 월활성사용자수는 4억3820만명이다. 5억명을 갓 돌파한 왓츠앱과 자웅을 겨룰 만한 규모로 성장했다. 참고로 네이버 라인의 월활성사용자수가 1억7500만명이다. 텐센트의 블로그형 SNS인 Q존도 규모로는 QQ 못지않다. QQ를 가입하면 자동적으로 개설되는 블로그지만 현재 월활성사용자수는 6억4500만명으로 페이스북 월활성사용자수(13억5000만명)의 절반 규모로 성장했다.

텐센트는 중국 내 유망 인터넷 서비스도 여럿 사들였다. 중국 2대 온라인 쇼핑몰인 JD닷컴의 지분 15%를 2억1400만 달러에 매입했다. JD닷컴은 올초 나스닥에 상장되면서 20조원 이상 시장 가치를 평가받았다. 텐센트는 중국의 옐프라고 불리는 디안핑에도 지분 20%를 받는 조건으로 4억 달러를 투자했고 검색엔진 소구의 지분 36.5%를 인수하기 위해 4억4800만 달러를 투입하기도 했다. 리그오브레전드(LoL)의 라이엇 게임즈는 아예 인수한 경우다.

싸이월드 아이템 거래에서 착안 수익 모델

월활성사용자 6억명이 넘는 텐센트의 QQSHOW 첫화면.

텐센트의 수익 모델은 여러모로 싸이월드를 떠올리게 한다. 아바타를 꾸미기 위해 도토리를 화폐로 사용하고 아이템을 구매하는 형태, 그 방식이 고스란히 녹아있다. 이를 VAS(Value Add Service)라고 부른다. 텐센트 쪽이 밝히고 있듯 싸이월드의 수익 모델을 벤치마킹했다.

마화텅은 아마존처럼 플랫폼 접근은 무료로 제공하면서 서비스를 이용에 따른 부가 상품으로 수익을 창출하는 전략을 구사하고 있다. 텐센트의 핵심 플랫폼은 QQ, TM, RTX, 위챗 등 메신저와 QQ닷컴 같은 포털 서비스다. 여기에 다양한 부가 서비스를 얹어 사업을 확장한다. 예를 들어 QQ는 부가서비스로 Q존, QQ멤버십, QQ쇼, QQ뮤직, QQ라이브, QQ러브, QQ데이팅을 제공하고 있다.

VAS는 이들 부가 서비스에서 발생하는 아이템 판매, 프리미엄 서비스 가입료로 구성돼 있다. 예를 들어 벨소리, 음악, 영화 시청, 상품 거래 수수료 등으로 수익을 올린다. 여기에 2003년 12월 개시한 게임 플랫폼 QQ게임이 더해졌다. 지금은 전체 매출의 최고 비중을 차지할 정도로 큰 규모로 성장했다. QQ게임 플랫폼에 다양한 게임 서비스를 유치해 게임코인으로 결제를 유도하고 있다. 자연스럽게 결제 서비스로 확장하는 계기가 되기도 했다.

VAS 수익은 2014년 2분기 기준으로 텐센트 전체 매출의 80%를 차지한다. 2014년 2분기 VAS 매출은 157억1300만위안, 우리돈으로 2조8394억원에 이른다. 2013년 2분기와 비교하면 VAS가 전체 매출에서 차지하는 비중은 5% 증가했다. 이 가운데 게임 매출 비중은 상당하다. 일단 모바일게임으로만 30억위안(5421억원)을 2분기에 거둬들였고 ‘LoL’, ‘블레이드앤소울’ 등 PC게임으로 여전히 매출을 창출하고 있다. 이외에도 온라인광고, e커머스 등으로 수익을 만들어낸다.

싸이월드에서 배운 서비스로 한국을 겨냥하다

텐센트는 국내 시장에도 깊숙히 들어와 있다. 다음카카오의 지분 9.9%를 보유하고 있는 대주주다. 지난 3월에는 CJ게임스 지분 28%를 인수하면서 자회사로 편입시켰다. 이처럼 굵직한 투자로 한국 시장을 전방위로 겨냥하고 있다. 이미 국내 게임 업계에선 큰손으로 대접받는다. 텐센트 손을 거쳐 중국 시장에 진출해 성공을 거둔 사례도 적지 않다.

싸이월드를 참조해 수익 모델을 확장한 텐센트는 싸이월드와 달리 세계적인 기업으로 성장해가고 있다. 중국이라는 광대한 시장을 발판으로 삼았기에 갖출 수 있었던 위용이다. 모방을 넘어 창조적 벤치마킹으로 성장한 텐센트가 이젠 국내 기업이 넘볼 수 없는 기업으로 커가고 있다.

삼성전자의 기업가치를 넘어서는 시점도 어쩌면 앞당겨질 수 있을지 모른다. 실리콘밸리만 바라볼 때가 아니라는 사실을 텐센트는 일깨워주고 있다. 중국 선전을 개혁개방으로 이끈 덩샤오핑, 그의 후예들이 실리콘밸리의 천재들보다 더 빠르게 한국 시장에 도달하고 있다. 이들의 몸집은 상대하기 힘들 만큼 커지고 있다.

참고 자료

• China Daily.(2009.1.12). A mysterious message millionaire
• China Internet Watch.(2014.2.11). The Story of the Rise of Tencent Empire
• Wikipedia. Ma Huateng

출처 : http://www.bloter.net/archives/213241

저물어가는 프로그래밍의 시대 - 칼럼니스트 임백준

마크 주커버그는 고등학생 시절인 2000년대 초반에 시냅스(Synapse)라는 소프트웨어를 개발했다. 사용자가 듣는 음악의 패턴을 파악해서 자동으로 플레이리스트를 만들어주는 MP3용 소프트웨어였다. 상당한 히트작이었다. 어떤 회사가 꼬맹이 주커버그에게 10억 원을 제시하면서 스카우트를 제안했을 정도였다. 하지만 그는 대학에 진학해야 한다는 생각으로 그런 제안을 정중히 거절했다. 
 
시냅스에 대한 소문은 해커들을 중심으로 널리 회자되었다. 전문적인 프로그래머가 아닌 주커버그가 어떻게 그런 스마트한 소프트웨어를 만들 수 있었는지에 대해서 많은 사람들이 궁금해 했다. 그러한 궁금증과 관련한 질문을 받았을 때 주커버그는 아무렇지도 않게 대답했다. 
 
“수학이요.” 
 
자신이 작성한 소프트웨어의 핵심은 사용자의 음악패턴을 포착하는 수학 공식에 있었다는 대답이었다. 그러한 수학이 요즘에는 머신러닝이라는 이름으로 불린다. 
 
IBM의 CEO 로메티는 왓슨(Watson)을 소개하는 자리에서 우리가 이미 인지 컴퓨팅(cognitive computing)의 시대로 접어들고 있다고 단언했다. 그녀는 컴퓨터의 역사를 3단계로 분류했다. 처음 등장했을 때 컴퓨터는 간단한 계산을 수행하는 계산기에 불과했다. 전자식 주판이라고 불리는 것이 어울릴 정도였다. 그래서 이름도 컴퓨터(computer0였다. 그것이 첫 번째 단계다. 
 
컴퓨터에 프로그램을 적재할 수 있는 기능이 추가되고, 하드웨어와 소프트웨어 기술이 눈부시게 발전을 하면서 그것은 엄청난 종류의 일을 수행할 수 있는 범용기계가 되었다. 이것이 두 번째 단계다. 계산기는 작은 아이콘으로 줄어들어서 컴퓨터 내부의 어딘가에 저장되는 조촐한 존재로 변했다. 오늘날의 프로그래머들은 바로 이러한 시대의 한복판에서 학습을 하고, 일을 하고, 놀이를 한다. 그런 우리들에게 컴퓨터는 프로그램을 짜서 넣는 대상이다. 생각은 우리가 하고, 기계는 실행한다. 
 
로메티는 그런 시대가 빠른 속도로 저물어가고 있다고 말한다. 어마어마한 수준의 머신러닝 기능을 탑재한 왓슨과 같은 존재가 등장하면서 인간은 이제 ‘프로그램’이 아니라 자연스러운 말과 글을 통해서 컴퓨터와 의사소통을 할 수 있게 되었다. 혹은 곧 그렇게 될 것이다. 세 번째 단계의 출현이다. 
 
기계가 학습을 수행하는 속도가 빠르고 다루는 데이터의 분량이 방대하기 때문에 왓슨과 같은 존재가 우리의 예상을 뛰어넘는 수준의 일을 수행하는 시대는 생각보다 빠르게 우리 곁에 다가올 것이다. 그때가 되면 사람이 일일이 코드를 짜서 컴퓨터에게 프로그램을 넣어주는 기능은 컴퓨터 내부의 어딘가에 저장되는 조촐한 존재로 변하게 될 것이다. 생각은 기계가 하고, 우리는 학습을 시킨다. 
 
유투브에서 Humans Need Not Apply라는 제목의 동영상을 찾아서보라. 어쩌면 10년, 20년이라는 멀지 않은 미래에 지금 우리가 프로그래밍이라고 부르는 ‘행위’를 기계가 대신 해주고 있을지 모른다. 그 시대를 사는 청년들은 과거에 살았던 우리를 보면서 마치 책을 인쇄하지 못해서 일일이 손으로 필사해서 복사하던 시대를 되돌아보는 지금 우리의 심정이 될 것이다. 
 
프로그래밍과 머신러닝의 차이는 주판과 양자컴퓨터의 차이만큼 극적이다. 프로그램은 정교하게 작성되었다고 해도 능력이 고정되어 있다. 프로그램이라는 개념 자체가 변화를 상정하지 않기 때문이다. 프로그램에게 있어서 변화는 버그다. 하지만 머신러닝에서는 변화가 생명이다. 학습이라는 개념 자체가 변화를 상정하기 때문에 머신러닝이 갖는 능력은 시간이 지나고 경험이 쌓일수록 크고 깊어진다. 
 
머신러닝은 이미 어디에나 있다. 우리가 페이스북에 글을 올리면 주커버그의 소프트웨어는 우리의 감정을 분석한다. 감성 분석(sentiment analysis)이라는 무기를 탑재한 머신러닝 알고리즘은 페이스북이나 트위터에 올라오는 글은 물론, 여러 웹사이트에 올라오는 댓글을 자동적으로 분석해서 그 글이 특정한 주제나 대상에 대해서 부정적인지 아니면 긍정적인지 판단한다. (이런 기능이 정치적인 목적으로 사용된다고 생각하면 끔찍하다.) 
 
사람들이 편지봉투 겉면에 쓰는 우편번호는 이미 오래전부터 손 글씨를 인식하는 머신러닝 알고리즘에 의해서 자동으로 읽히고, 분류되고, 전송되어 왔다. 사람이 눈으로 우편번호를 읽고 분류하던 시절에 비해서 훨씬 더 빠르고, 정확하고, 일관성 있는 작업이 가능해진 것이다. 자동차의 번호판이나 사람의 얼굴을 인식하는 머신러닝 알고리즘도 널리 사용되고 있는 중이다. 
 
구글 뉴스를 보면 다양한 기사들이 보기 좋게 주제별로 분류되어 있는데, 그러한 분류를 어떤 사람이 일일이 수행하는 것이 아님은 물론이다. 구글의 프로그램이 부지런히 뉴스를 긁어오면 문서를 분류하는 머신러닝 알고리즘이 자동적으로 문서를 내용에 맞는 범주로 분류한다. 구글이 야심차게 진행하고 있는 무인 자동차도 머신러닝 알고리즘을 탑재해서 경험을 쌓을수록 운전 실력이 더욱 정교해진다. 
 
불법소프트웨어나 악성코드를 검출할 때도 머신러닝이 활용되고 있고, 금융권에서 대출심사를 할 때, 주식시장을 예측할 때, 신용카드 범죄를 포착할 때에도 머신러닝이 사용되고 있다. 또한 게임에서, 공장에서, 전자상거래에서, 병원에서, 보험회사에서, 기상예보에서, 온라인광고에서, 교육에서 머신러닝은 이미 활용되고 있으며, 적용되는 범위가 무서운 속도로 늘어나고 있다. 
 
머신러닝이 프로그래머를 대체할 거라는 이야기가 믿기 힘들다면, 사람 웹디자이너가 수행하는 사이트 개발과 디자인을 머신러닝이 대신할 거라는 이야기는 어떻게 들리는가? 이것은 미래의 이야기가 아니다. 그리드(thegrid.io)는 현실이다. 사이트를 방문해서 확인해보라. 가까운 장래에 우리가 방문하는 웹 사이트의 대부분은 사람이 아니라 기계가 만든 장소로 변하게 것이다. 
 
머신러닝을 전문적으로 다루는 사람을 보통 데이터 과학자(data scientist)라고 부르는데, 현재 전문적으로 프로그래밍을 하는 사람들이 모두 데이터 과학자가 될 필요는 없다. 하지만 머신러닝의 기본적인 개념과 그것을 실전에 응용할 수 있는 방법 정도는 알아두는 것이 좋다. 그것은 마치 일상적인 프로그래밍을 위해서 컴파일러의 내부를 자세하게 알 필요는 없지만, 좋은 컴파일러를 선택하고 활용할 줄 알아야 하는 것과 마찬가지다. 
 
고전적인 의미에서의 프로그래밍의 시대는 확실히 저물고 있다. 하지만 걱정할 필요는 없다. 한 시대의 종말은 새로운 시대의 서막을 의미할 뿐이다. 물경, 새로운 의미에서의 프로그래밍의 시대가 동트는 새벽을 맞이하고 있는 중이다. 기회의 바다다.

출처 : http://www.zdnet.co.kr/column/column_view.asp?artice_id=20141104074223&type=xml

나는 여태까지 C++ 은 정적 컴파일이다보니

동적으로 뭔가를 한다는 게 불가능할 줄 알았는데,

그냥 내가 무식했나보다...ㅎㅎㅎ..

C++ 에서 4 가지 캐스팅 연산자 (dynamic_cast, static_cast, const_cast, reinterpret_cast) 가운데

dynamic_cast 에 대해 알아보고자 한다.

+추가로

객체가 위치한 메모리의 시작부분을 찾는 데도 사용된다고 한다.

아래와 같이 p 에 시작주소가 담겨진다.

void* p = dynamic_cast<void*> (ObjectPointer);

[예제1]

class Base {
public:
    virtual void print() { cout << "This is Base" << endl; }
};

class Derived : public Base {
public:
    void print() { cout << "This is Derived" << endl; }
};

void main()
{
    Base* pBase1 = new Base;
    Base* pDerived1 = new Derived;

    Derived* pDerived2 = new Derived;
    Derived* pDerived = nullptr;

    // 컴파일 실패 : 부모는 자식이 될 수 없음
    pDerived = pBase;

    // 컴파일 성공 : but 부모는 자식이 될 수 없으므로 널 포인터를 리턴한다!
    pDerived = dynamic_cast<Derived*> (pBase);
    if ( pDerived == nullptr )
        cout << "failed to casting pBase->pDerived" << endl;


    // 컴파일 실패 : pDerived1 의 타입이 Base* 이므로, 부모는 자식이 될 수 없음
    pDerived = pDerived1

    // 컴파일 성공 : 런타임에 타입 변환이 성공하여 Derived 타입의 포인터를 리턴한다!
    pDerived = dynamic_cast<Derived*> (pDerived1);
    if ( pDerived )
        pDerived->print();


    // 컴파일 성공 : 이런 경우에는 캐스팅이 필요없다.
    pDervied = pDerived2;
}

위 예제에서의 키포인트는 

'포인터가 실제로 가르키는 대상이 캐스팅이 될 수 있는 녀석인가' 이다.

dynamic_cast 는 캐스팅에 실패할 경우,

대상이 pointer 면 nullptr 를 반환하고

대상이 참조자이면 bad_cast 예외를 던진다.

이 점이 위에서 언급한 안전한 타입 캐스팅의 의미이다.

캐스팅의 가능 여부를 런타임에 검사하여 처리할 수있다.

다음은 다중 상속일 때, 기본 클래스 간의 타입 캐스팅(Cross-Casting)을 다룬다.

[예제2]

class BaseOne {
public:
    virtual void print() { cout << "This is BaseOne" << endl; }
};

class BaseTwo {
public:
    virtual void print() { cout << "This is BaseTwo" << endl; }
};

class Derived : public BaseOne, public BaseTwo {
public:
    void print() { cout << "This is Derived" << endl; }
};

void main()
{
    BaseOne* pBaseOne = nullptr;
    BaseTwo* pBaseTwo = new Derived;

    // 컴파일 실패 : BaseOne 과 BaseTwo 타입은 호환 불가
    pBaseOne = pBaseTwo;

    // 컴파일 성공 : 기본 클래스 간의 타입 캐스팅 가능
    pBaseOne = dynamic_cast<BaseOne*> (pBaseTwo);

    if ( pBaseOne )
        pBaseOne->print();
}

[예제2] 를 정리하자면 아래의 그림과 같다.

크로스 캐스팅의 한 사용 예로는 

각 기본 클래스 포인터(or 참조자) 타입의 컨테이너 혹은 배열을 운용하면서 

서로 간의 요소를 교환할 때 사용할 수 있다.

여기까지 dynamic_cast 의 용도를 알아보았다.

( [예제1] : 다운 캐스팅, [예제2] : 크로스 캐스팅 )

참고로 다중 상속은 권장하지 않는 분위기(?)라서 설계를 재검토 하도록 하자.

※ 포스팅 참고 자료:

http://prostars.net/55

http://msdn.microsoft.com/ko-kr/library/cby9kycs.aspx

포스팅의 엄청난 도움을 주신 (+게으른 저를 포스팅하게 만들어 주셨습니다)

http://prostars.net/55 님께 감사의 인사를 덧붙입니다. (__)

자바스크립트-CSS 창시자들과의 대담 

(지디넷코리아=임민철 기자) 웹이 유럽입자물리연구소(CERN)에서 과학 연구를 위해 태어난지 올해 25주년이다. 웹은 이제 단순히 정보를 전달하는 역할을 넘어 사람들의 일상 활동에도 깊숙하게 뿌리를 내린 하나의 문화가 됐다. 

웹을 빠르게 확산시킨 기폭제는 '자바스크립트(JavaScript)'와 '캐스케이딩스타일시트(Cascading Style Sheets, CSS)'라는 2가지 기술이었다. 자바스크립트와 CSS는 각자 웹 사용자 기반을 넓히는 동시에 그 스스로가 거대한 커뮤니티를 갖춘 생태계로 20년간 발전에 발전을 거듭해왔다. 

한국이 웹을 받아들인지도 이제 20년이 됐다. 이를 위해 웹 생태계의 구루들이 한국을 찾았다. CSS와 자바스크립트의 창시자들이 한국을 찾았다. 자바 스크립트를 만든 브렌던 아이크(Brendan Eich) 전 모질라 최고기술책임자(CTO), CSS창시자인 하콤 비움 리(Håkon Wium Lie) 오페라소프트웨어CTO가 주인공이다. 

이들은 지난 17일 세종대학교 '한국웹20주년기념 국제컨퍼런스'에서 마련된 좌담회에도 참석해 패널 토론 시간도 가졌다. IT평론가인 김국현 에디토이 대표가 사회를 맡아 두 사람과 대담을 진행했다. 주요 대화 내용을 정리했다.

▲ 17일 서울 세종대학교에서 한국웹20주년기념 국제컨퍼런스가 진행됐다. CSS 표준 제안자 하콤 비움 리 오페라소프트웨어 CTO와 자바스크립트 창시자 브렌던 아이크 전 모질라 CTO가 오전 순서인 웹의 과거와 미래를 주제로 한 토론에 패널로 참석했다.

■웹기술 '아버지'들에게 '엄마는 누구냐' 묻자… 

김국현(이하 '김'): (웹이 나오고 나서 5년쯤 지나 자바스크립트와 CSS가 공개되고 발전한 과정을 물으며) 20년 전, 대체 무슨일이 있었던 건가 

하콤 비움 리(이하 '리'): 20년전(1994년) CERN 연구실에 있을때 HTML 코드를 보고 있었다. (웹의 창시자) 팀 버너스 리와 함께 웹을 개발중이었다. 웹을 개발하며 느낀것은 웹이 잘 작동했지만 몇몇 요소들이 빠져 있었다는 점이다. 텍스트를 글꼴, 색깔 등으로 '프리젠테이션'하는 방법, 문자와 이미지를 함께 배치하는 등 정보를 표현하는 방법 등이 부족했다. 그래서 CSS를 제안하게 됐다. 

브렌던 아이크(이하 '아이크') : 자바스크립트는 CSS보다 늦게 나왔다. 올해 5월기준으로 정확히 19주년을 맞았다. 내1995년 4월 넷스케이프에 합류해 (창립자 마크 안드레센을 포함한) 동료 2명과 함께 개발했다. 나와 동료들은 컴퓨터 전문가 아니더라도 쓸 수 있는 간단한 언어가 웹에 필요하다고 생각했다. 그래서 1995년 9월 넷스케이프 시험판에 '라이브스크립트(LiveScript)'란 이름으로 탑재된 언어 개발에 참여했다. 라이브스크립트는 이후 '자바스크립트'로 바뀌었다. 자바와 아무 관계가 없었기 때문에 상당한 혼란이 있기는 했지만...

▲ (왼쪽부터) 김국현, 브렌단 아이크, 하콤 비움 리. 사진=한국웹20주년컨퍼런스 제공.

김: 당신들이 자바스크립트와 CSS같은 주요 웹기술의 '아버지'라 불린다면, '엄마'라고 부를 수 있을만한 사람은 누굴까 

리: CSS 개발을 위해 '기스베르트 보스(Gijsbert Bos)'와 협력했다. (편집자 주: 기스베르트 보스는 베르트 보스(Bert Bos)라고도 불리며, 네덜란드 출신 컴퓨터과학자로 CSS 구현 및 테스트용 브라우저 '아르고(Argo)'를 개발하고 'CSS-웹을 위한 디자인'이란 CSS 개론서를 하콤 비움 리와 공동 집필함.) 또 사용자 커뮤니티로부터 CSS 완성에 많은 도움을 받았다. 

CSS 초안을 1994년 10월 10일 내놨다. 사흘후 넷스케이프 브라우저가 나왔지만 CSS는 거기에 구현되지 않았다. 72시간밖에 여유가 없었기 때문이다. 94년 10월은 CSS에겐 매우 중요한 한 달이었다. 당시만 해도 CSS는 많은 추가 작업을 필요로 하던 상황이었다. CSS에 참여할 수 있는 커뮤니티 메일링리스트가 있는데, 지금도 활발하게 활동하는 중요한 커뮤니티다. 1990년 이후 1만7천개 메시지가 쌓여 있다. 이들 참여자가 없었다면 CSS는 오늘과 같은 모습을 갖추거나 광범위하게 사용되는 성과를 거두지 못했을 거다. 

아이크: 자바스크립트도 너무 서둘러 만들어졌다. 불과 10일 남짓한 기간에 지금의 자바스크립트에서 장단점으로 꼽을만한 것들이 만들어졌다. (넷스케이프 브라우저 보급으로 자바스크립트 확산을 거든) 마크 안드레센을 '어머니'라 불러도 될 것 같다. 

하콤이 말한 것처럼 커뮤니티의 도움도 중요한 역할을 했다. 커뮤니티 멤버들은 자바스크립트 프로그래밍 언어에 있는 문제를 찾아내고, 부족한 요소에 대해 추가해줄 것을 요구했다. 나는 그런 요구를 최대한 빨리 수용하려고 노력했다. 

김: 당신들이 자바스크립트와 CSS란 기술을 만들어내지 않았다면, 지금쯤 뭘 하고 있었을 것 같나, 그리고 두 기술과 만나지 못한 '웹'에는 어떤 일이 벌어졌을 것 같나 

리: 웹에 개방형 표준 언어가 없었다면, 지금과 많이 다른 성격을 띠었을 거다. 마이크로소프트(MS)나 통신사같은 상업적 회사, 한국 등의 대기업이 (웹을) 장악했을 거라 생각한다. 개인적으로 (웹 생태계에) 오픈 스탠더드, 오픈소스가 상당히 중요하다고 생각한다. 

그리고 나는 노르웨이 농장지대에서 사과 농사를 한 적이 있는데, (CSS를 만들어내지 않았다면) 어쩌면 0과 1로 조합된 일(IT산업)이 아니라 농부가 됐을지도 모르겠다. 세상에는 농부와 같이 컴퓨터공학자와 전혀 별개인 영역의 삶과 역할도 중요하다고 생각한다. 농업은 쉽지 않다. 

아이크: (자바스크립트 개발) 당시 다니고 있던 넷스케이프는 벤처회사였다. 인터넷닷컴 '로켓'이 처음 우주로 발사된 시점이었다. 넷스케이프에서 나와 들어간 모질라에서도 자바스크립트를 개발했는데, 개인적으로는 그걸 시작하지 않았다면… 내가 있을만한 다른 영역이 있었을 거라 본다. 

웹의 경우, 수천개 혁신이 가능한 개방된 환경에 놓여 있었다. 자바스크립트를 만들지 않았다면 그거와 비슷한 'BB스크립트'나 'MS스크립트'같은 게 만들어졌을 거다. MS는 프로그래밍 언어를 만드는 능력과 플랫폼을 만드는 기술을 갖고 있었다. 

MS 플랫폼의 언어는 (독점 SW인) 윈도 비주얼스튜디오에서 쓰는데 웹에선 자바스크립트를 쓴다. 자바스크립트가 없었다면 MS같은 회사가 웹을 장악했을 것이다. 사실 자바스크립트 개발에 MS의 '비주얼베이직'이 영감을 줬다. 디테일을 참조한 게 아니라, 언어를 초심자 프로그래머도 쉽게 쓰도록 만들었다는 점에서 그렇다. 

김: 자바스크립트나 CSS 라이브러리는 매우 많다. 대단한 생태계를 만든 셈이다. 축하드린다. 하지만 이건 사람들이 현재 자바스크립트와 CSS의 기본 기능에 답답하고 불편함을 느낀다는 점을 방증한다. 그 한계를 극복하려는 이들이 그만큼 많다는 것인데, 이런 점은 불편하지 않나. 

리: 라이브러리는 지루하거나 반복적 작업을 대신해 '아티스트'의 수고를 덜어 준다. 요긴한 라이브러리 기능은 CSS에 탑재하는것도 의미 있을 것이다. 이를 위해 워킹그룹에서 그런 것처럼 (표준화 단체와 커뮤니티가) 양방향 작업을 할 수도 있다. 

(과거 자바스크립트를 사용해야 했던 표현들도 지금은 CSS로 가능한 게 많아) 10년 전에 비하면 사람들이 원하는 표현을 구현하기 위해 CSS를 쓰는 것이 훨씬 쉬워졌다. 프로토타이핑도 효율적으로 할 수 있다. 요즘은 라이브러리로 기능을 확장하려면 그냥 혼자 쓰면 된다. 예전엔 그걸 위해 많은 사람을 설득해야 했다. 

아이크: (많은 라이브러리는 자바스크립트의) 광범위한 성공을 나타낸다고 생각한다. 표준은 (그걸 확장하는 라이브러리와 함께) 항상 공동 진화 체제를 갖춰야 한다. 혼자 경직되거나 도태돼선 안된다. 개발자요구를 반영해야하고 계속 나아져야 한다. 

스티브 잡스가 애플 플랫폼을 만든것처럼 "이 플랫폼에선 이런 방법으로만 해야한다"가 아니라, 다양한 방식을 수용할 수 있어야 한다. 애플을 나쁘게만 말하는건 아니지만, 애플 플랫폼은 매우 통제되고 협의적인 플랫폼이다. 효율적인 환경이지만, 웹은 그런식으로 되지 않는다. (발전이) 더 개방적으로 이뤄져야한다. 

■애플-구글발 웹 생태계 위협? 

김: 애플 얘기가 나온김에…애플과 구글이 웹 개방성을 강화시켜준건 사실인 것 같다. (브라우저를 탑재한 스마트폰 확산으로 데스크톱에서 많이 쓰이던) 플러그인을 사라지게 했다든지. 그런데 모바일 애플리케이션 플랫폼 시장을 양분하면서 웹에 대한 기존 개발자의 관심도 흡수해버렸다. 구글과 애플(플랫폼)에 치우친 개발자들 관심은 웹의 위기인가, 기회인가, 어떻게 봐야할까 

리: 리스크라고 생각한다. 애플은 휴대폰에 다양한 (자체) 애플리케이션프로그래밍인터페이스(API)를 제공한다. 이것을 쓰기 위해 앱 개발자들이 구글이나 애플과 '계약서'를 쓰고(편집자 주: 앱 장터 개발자 프로그램 등록을 뜻함) 뭘 만드는 게 좋지만은 않다. 

하지만 웹으로 구성하는 경험을 이런 (모바일 앱 생태계같은) 독점 세상에 묶이게 하면 한계를 보일 수 밖에 없다. 웹의 미래가 상업적인 기업에 장악되는 셈이기 때문이다. 누구도 그걸 원치는 않을 것이다. 이번 컨퍼런스에선 웹 기술로 앱을 대체할 방법을 주제로한 세션도 준비됐다. 당장 실현되진 않겠지만 가능성이 있는 얘기다. 

아이크: (위험이 있다는 의견에) 동의한다. 나는 웹이 앞으로 어떻게 성장할 지에 대해 말하고 싶다. 난 구글과 애플이 웹을 버렸다고 생각지 않는다. 이들은 웹에 많은 혁신을 가져왔다. 혼재된 이해가 섞여 있다. 대형 벤더만 웹을 주도할 순 없다. 네이티브 기술과 웹이 혼용된 페이스북 앱만 보더라도. 웹은 앱, 네이티브 시스템과 함께 성장할 것이다. 물론 그러려면 많은 개발자의 관심과 사랑을 필요로 한다. 

김: CSS와 자바스크립트의 한계를 고쳐보려는 기업들의 노력이 두드러진다. 명시적으로 구글 언어 '다트(Dart)'가 궁극적으로 자바스크립트 지위를 빼앗으려는 시도로 보이는데, 어떻게 생각하는지 

아이크: 다트는 원래 '대시(Dash)'란 이름으로 알려져 있었다. 당시 자바스크립트를 대체하려는 언어로 구글 언어를 표방했다. 그런데 구글은 입장을 바꿔 "자바스크립트 컴파일(변환)을 하겠다, 다트는 (자바스크립트 역할을 대신하지 않아도) 그 자체로 훌륭한 언어다, 다른 브라우저에도 쓰이길 원한다"고 말한다. 

이건 구글이 현실을 보는거라 생각한다. 자바스크립트를 없애긴 거의 불가능한 일이다. (생물 진화 과정에) '미토콘드리아'가 세포안에 들어왔듯, 지금 와서 이를 바꿀 수 없다. 그냥 품은 채로 진화를 하는거다. 다트 역시 자바스크립트의 진화나 혁명을 돕거나 함께 해나갈 수는 있지만, 대체는 불가능하다. 
  
리: CSS도 다른 언어가 대체하진 못 할거다. 어려움이 많을 것이다. 서로 다른 기술을 다루는 공학자들 사이에서 (기술 언어간의) 긴장은 항상 있었다.CSS에 대해서도 많은 이론적 접근이 있지만, 향후 많은 연구가 이뤄져야한다고 본다. 

미래엔 CSS도 '컴파일' 될 거다. 선호하는 문법이 있을 거고, 다른 네이티브CSS로 전환될 수도 있을 거다. 이것도 시간이 오래 흘러야 가능한 일이다. 그래서 결론적으로 웹은 500년 이상 유지될 것이다. 지금 작성한 HTML,CSS, 자바스크립트 코드가 500년 뒤에도 계속 읽힐 거란 얘기다. 

김: 웹의 '공유'를 촉진하기 위해 만들어진 기술들이 현대 '컴퓨팅' 분야에서 핵심 역할을 하는 것 같다. 대단한 일이다. 그런데 지금처럼 자바스크립트같은 기술의 활용 분야가 (성능개선을 위한 asm.js 같은 아이디어로) 컴퓨팅에 치중하다보면 접근성 강화를 비롯한 웹의 근본 철학에서 멀어지는 게 아닐까 

리: 난 텍스트에디터로 CSS 코드를 직접 쓴다. 앞으로도 그럴 예정이다.CSS는 사람들이 내용을 쓰고 읽을 수 있고, 텍스트와 이미지의 기초적인 표현 언어로서 기본적인 역할을 할 수 있어야 한다. 하지만 언어와 그걸 위한 라이브러리는 양자택일 관계에 있는 게 아니다. 함께 활용해 나가는 것이다.

아이크: 나는 500년 앞을 내다보기는 어려운데, 1천년 쯤 미래는 어떨까? (좌중 웃음) 하콤의 의견에 동의한다. 자바스크립트는 살아있는 언어로, 사람이 손으로 코드를 쓸 수 있는 언어라 생각한다. 대중적인 기반 언어가 되길 원하고, 많은 사람들이 쓰길 원한다. 여러 프로그래밍 언어와 비교해 보면 자바스크립트는 계속 성장 중이라 생각한다. 

김: 좀 그런 질문일지 모르겠는데, 두 사람이 각자 애용하는 라이브러리는 뭐가 있나 

리: 슬라이드를 만들 때 쓰는 라이브러리가 있다. 이름은 정확하게 기억나지 않는데 굉장히 좋다. 그 기능을 CSS 표준에 포함했으면 하는 생각이 들 정도다. 물론 실제로 그걸 표준화하려면 해당 안건이 위원회를 통과해야 하고, 테스트와 설득 과정을 거쳐야 한다. 쉽진 않은 과정이다. 

아이크: 리빌(Reveal.js)이라는 프리젠테이션용 라이브러리를 쓴다. 자바스크립트는 핵심 부분만 표준화하고, 라이브러리를 통해 개발자들이 빨리 작업을 수행케 하는 게 좋다. 개발자들의 요구사항을 모두 표준화하는 건 불가능하다. 새로운 라이브러리가 나오면 과거 라이브러리는 무용지물이 되기도 한다. 

리: 라이브러리를 많이 쓰는데 호버링(hovering, 편집자 주 : 웹페이지 구성요소 중 마우스 커서를 올렸을 때와 같이 초점이 맞춰진 상태를 가리킴) 개념이 유용했다. 자바스크립트를 안 쓰고 CSS 코드만으로 쓸 수 있게 만들어졌다. 과거 자바스크립트로 구현된 뒤 CSS에 들어간 기능 사례다. 

아이크: 웹의 진화에 대해, 'extensiblewebmanifesto.org'라는 사이트에 가 보면 이런 논의가 있다. 표준을 최소한으로만 유지하면 됐지, 너무 많은 라이브러리를 다 표준화할 필요는 없다는 얘길 한다. 더 많은 개발자가 빨리 구현하길 원하는 부분을 직접 작게 만드는 게 났다는 생각인데, 매우 공감된다. 

리: 그런 웹기술에 대한 확장가능성(extensibility) 논의에는 오해 소지가 다소 있다. 내가 타이포그래피 쪽 일을 했던 사람이라 그런지, 내 생각은 좀 다르다. 요즘도 웹은 CSS 요소를 대부분 라인, 컬럼, 페이지 형태만으로 사용한다. 그 이외 것을 구현하기 위한 핵심요소가 지금의 CSS엔 빠져 있다. 

■CSS-자바스크립트의 긴장관계? 

김: 예전엔 (웹 애니메이션같은) 자바스크립트로만 가능했던 기능을 이제CSS만으로도 할 수 있는 경우가 생겼는데, 이렇게 CSS와 자바스크립트의 역할 중첩을 어떻게 봐야 할까 

리: 언어는 경우에 따라 경쟁 관계에 놓일 수 있다. 일반 프로그램이 웹에 오면 자바스크립트와 경쟁하게 된다. 웹에서의 프로그래밍이 쉽다고 하는 얘기는 CSS보단 자바스크립트 덕분이다. 

이와 별개로 간단히 퍼블리싱 작업을 하기 위한 기반은 CSS가 유용하다. 구현된 값과 속성 설정에 익숙하면 자바스크립트 없이도 결과물을 낼수 있다. 프로그래밍은 더 편리할 수 있겠지만, 그런 건 인류의 90%가 아니라 1%정도만 하면 된다고 생각한다. 전세계에 뛰어난 프로그래머가 흔하진 않기 때문에, CSS가 (규모의 경쟁에선) 승리할 것 같다. (좌중 웃음) 

아이크: 동의한다. CSS는 프리젠테이션과 퍼블리싱에 유용하다. 자바스크립트는 혁신적인 프로그래밍을 하는 사람에게 유용한 언어다. 트위터가 (프론트엔드 구현용 라이브러리로) 내놓은 '부트스트랩'처럼 많은 이들이 (시각적인 표현을 위해) 자바스크립트를 쓰지 않고 CSS 기능을 활용하는 추세다.

김: 당신들의 2가지 기술이 열린 웹 생태계를 20년간 키워 왔는데, 더 중요한 앞으로의 시대에 가장 큰 위협은 뭐가 될 것이라 생각하나 

리: 어떤 기업이 (표준) 개발을 다 장악해 버리는 것. 애플과 구글은 지금도 (표준화 과정에서의 영향력이) 굉장히 막강하다. 그런데 오픈스탠다드가 규칙이 아닌 세계에 살고 싶진 않다. 개방형 표준의 관점에서 지난 2005년 최대 위협은 (브라우저 시장을 독점한) MS였는데, 이런 위협은 계속 변화하며 대두될 것이다. 

오픈 커뮤니티가 더 강해져야 한다. 정부나 규제당국의 노력으로는 (독점 환경을) 이길 수 없다. 열정을 갖춘 사람들이 개방형 웹 커뮤니티를 든든히 지원하며, 즐겁게 일해야 한다. 웹은 더 많은 사람들에게 필요하고 어떤 거래 동의서 작성같은 게 필요치 않은 공간이기에 훨씬 더 중요하다. 

아이크: OS기반(네이티브) 앱의 영향력이 커지면서 웹에 많은 도전과제가 생겼다. 스티브 잡스가 아이폰을 들고 나와 발표할 때, (모바일 사파리에)CSS3 표준의 '라운디드코너'나 '애니메이션 트랜지션'을 위해 CSS를 활용했다고 얘기하기도 했다. 스마트폰이 웹을 잘 쓰게 된 건 좋은 일이고 앞으로 더 많이 이뤄져야 할 현상이다. 

내가 우려하는 부분은 상업적인 기업이 독점 기술의 하위구조에 CSS와 자바스크립트를 가져간다든지, 계정, 인증서, 보안, 이런 부분을 독점하는 게 문제로 작용할 수 있다는 점이다. 여러분이 자신의 데이터를 갖고 있어야 하는데 실제로는 쉽지 않다. 데이터가 언제나 클라우드 서비스에 수집되고 있어서다. 이는 작은 기술보다는 큰 시스템의 문제다. 

김: 한국에선 일상생활을 순수한 웹으로 하지 못하는 경우가 참 많은데, 두 사람이 만일 오늘부터 한국에서 살기로 결정했다면 어떻게 하고 싶겠나 

리: 아직도 한국에서 일상적인 웹 활용을 위해 IE가 필요한가? 그렇다면 잘못됐다고 생각한다. 한국은 기술적으론 선두권에 있는 나라인데, 때론 액티브X처럼 (도입이) 너무 앞서나간 게 아닌가 할 때가 있다. 난 이걸 고치려고 노력할 것 같다. 여러분 중에도 그런 활동가가 많을 것 같다. 

아이크: 안드로이드나 iOS같은 스마트폰엔 액티브X같은 게 없다고 보는 경향이 있는 듯하다. 그래서 한국의 인증서나 액티브X가 사라질 거라고들 전망하는데, 한국이 그런 기존 환경에서 벗어나는 과정은 내 생각보다 좀 더 오래 걸리는 것 같다. 내가 한국에 산다면 IE를 사용해야 될 것 같다. 하지만 웹의 발전을 위해선 계속 노력할 것이다. 

김: 당신들이 여기 와 계신, 개발자를 비롯해 웹 업계에 종사하는 다양한 참석자들과 입장을 바꿔 보자…오늘 당장 웹 생태계에서의 경력을 시작하는 입장이라면 많은 생각이 들텐데, 당장 뭐부터 시작할 것 같나 

리: 일단 기초를 다지기 위해 반드시 필요한 HTML을 15분동안 공부할 거다. 그리고 45분동안 CSS 기초를 익힐 거다. 그럼 1시간 정도 공부를 한 거다. (아이크를 보면서) 자바스크립트는 얼마나 걸릴지 모르겠는데? 

아이크: '열흘' 걸린다. (편집자 주 : 자신이 자바스크립트 개발에 들인 기간 정도를 지칭한 유머) (좌중 웃음) 

리: 그 뒤 500년 동안은 편히 일할 수 있다. 좀 진지하게 말하자면, 반드시 기술에 대한 이해가 필요하다. HTTP, URL, 특히 HTML(웹의 창시자 팀 버너스 리가 실제로 만든 3가지 기술)을 다 이해해야 한다. '앱'도 연구해 볼 것 같다. 특정 기업이 독점한 구조는 따르지 않겠지만. 

즉 앱을 만들겠지만, 결국 많은 사람들에게 접해보게 할 수 있는 웹 기반의 방법을 찾을 것 같다. 웹은 아이폰같은 최신 스마트폰을 쓰지 못하는 국가에 사는 사람들도 피처폰, 모바일폰, 인터넷카페 컴퓨터 등으로 세계 어디서나 쓸 수 있다. 미국 서부나 내가 사는 노르웨이에 국한하지 않는다. 

웹을 지칭하는 표현 앞에 '월드와이드'가 붙는 이유는, 그게 이제껏 웹이 해온 일이기 때문이다. 언제나 웹으로 활용 가능한 콘텐츠가 만들어지고, 전세계에서 통용된다. 진정한 세계적 범주에서 퍼져나가는 건 웹 뿐이다. 산업화된 선진국뿐아니라 어디서든 쓰인다. 따라서 새로운 시장도 계속 열린다. 

아이크: 내 이력을 되짚어 보면 과거 베이직, 하스켈, C 프로그래머가 인기있었다. 지금은 자바스크립트도 많이 쓰는데 파이썬, 루비도 있고, C++도 (진화를 거듭해) 세번째, 네번째 삶을 이어가고 있다. 스마트폰 프로그래밍에도 많이 쓰인다. 더 '제너럴리스트'가 되라고 조언하겠다. 

특정 분야만 파고드는 게 아니라 다양한 언어를 배우길 권한다. 그리고 배포와 컨트롤 시스템뿐 아니라 다른 시스템도 알아야 한다. 이런 다방면의 지식을 공유하는 개발자들의 수가 엄청나다. 과거 어느때보다 많다. 앞서 얘기한 (커뮤니티의) 공동의 진화는 프로그래밍을 시작하는 데에 큰 도움이 된다. 지금은 내가 배우기 시작했을 때보다 훨씬 개방적이고 책을 살 필요도 없이 지식을 구할 수 있다. 

김: 마무리하는 의미에서 한국과 관련된 질문을 드리고 싶은데, 한국분들은 앞으로 어떻게 해야할까? 오페라소프트웨어 본사 소재지인 노르웨이를 포함해 북구 스칸디나비안 지역의 (웹 분야) 경쟁력이 크다면, 그런 스칸디나비안의 강점이 한국에 시사할바가 있을까 

리: 오페라 창립한 1995년에 난 거기없었지만, 강력했다. 더이상은 아니지만, 노키아나 에릭슨같은 휴대폰 개발사들도 경쟁력이 있었다. 똑똑한 사람이 많고, 그런 소프트웨어와 서비스가 다수 구현됐다. 하지만 이제 많은 개발은 미국 서부에서 주도한다. 지금은 그게 '혁신의 자석'처럼 작용하고 있고, 성공적이라고 생각된다. 앞으로 이게 세계 각지로 분산됐으면 한다. 삼성, LG같은 제조사를 둔 한국을 포함해 전세계로, 균형잡힌 분포가 이뤄졌으면 한다. 

웹과 관련된 기술 대부분이 CERN에서 개발됐다. 팀 버너스 리도 당시 연구소 컴퓨터서비스랩의 여러 연구진 가운데 한 사람이었다. 당시 웹을 개발했을 땐 오늘날처럼 퍼져나가리라고는 아무도 예상하지 못했다. 여러분들도 그런 (자신이 만든 기술 결과물이 널리 확산되는) 기회를 누리기 바란다. 웹은 전세계 누구에게든 그런 기반이 돼 줄거라 생각한다. 

아이크: 나는 삼성과 개인적으로 일한 적이 있고, LG도 모질라와 (파이어폭스OS 단말기로) 협력 관계에 있다. 이제 미국 서부에 많은 순수한 소프트웨어 회사들도 (벤처 창업을) 생각해보기 바란다. 

오늘날 소프트웨어로 성공을 거두려면 미국 서부로 가야한다고 생각하곤 하는데, 구글은 스탠포드에서, 페이스북은 하버드에서 시작했다. 소프트웨어는 예술, 과학 같은 거다. 하드웨어식으로 접근해선 안된다. 여러분에겐 순수한 소프트웨어에 집중하고 많은 '이니셔티브'를 해보길 권한다. 

김: 마지막으로 웹개발자들에게 해줄 말이 있다면 

아이크: 자바스크립트에 투자하시라. 

리: 가능할 경우엔, CSS를 쓰시라. (좌중 웃음) 

김: 한국에 웹이 도입된지 20주년 되는 해인데, 좌담회를 마치며 앞으로 500주년이 될 때를 위해 만세를 외쳐보자. 만세~ 

리&아이크 : (사회자의 행동을 보고 머뭇거리다가 통역을 듣고 난 뒤) 만세~ (좌중 웃음)