Unique Visitor에 대해

 요즘 흔히 인터넷 서비스의 사용을 평가하기 위해 Unique Visitor(이하 UV)를 사용하는 것을 자주 보았을 것이다. UV는 순 방문자 수를 뜻한다. 즉, 한 사람이 여러 번 같은 사이트를 방문했더라고 한 명으로 측정되는 기준을 말한다. UV는 Page View(PV), 트래픽(traffic), 대역폭(bandwidth)과 더불어 해당 서비스의 사용자 분석 및 마케팅 자료로 널리 사용되고 있다. 하지만 connection-less의 웹 환경에서 UV를 정확하게 계산하는 것은 여간 어려운 일이 아니다. 현재 여러 가지 시도를 통해 더 정확한 UV를 계산하기 위한 노력이 이뤄지고 있다.

 UV를 계산하는 방식은 크게 사이트 중심(site centric) 방법과 사용자 중심(user centric) 방법으로 나눈다[1]. 두 가지 방법 중 가장 많이 사용되고 있는 방법은 사이트 중심 방법이다. 사이트 중심 방법의 대표적인 것은 수집된 로그를 분석하는 것이다. 다시 말해서 수집된 로그에서 유효한 데이터를 추출하여 UV를 계산하는 것이다. 수집된 로그에서 사용되는 속성으로 IP가 많이 사용된다. 하지만 이는 공유 IP 환경에서 문제가 될 수 있다. 같은 IP 주소로 기록된 로그라도 실제 다른 사용자 일 수 있고 DHCP(Dynamic Host Configuration Protocol)를 기반을 사용하는 ISP 업체의 서비스 종류에 따라 IP는 요청 시 변경될 수 있다. 개선된 방법으로 IP와 User-Agent를 동시에 확인하는 방법이 제안되었다. 하지만 이 방법 또한 IP와 User-Agent 모두 같은 환경에서 사용자를 구분해 낼 수는 없다.

 사이트 중심 방법 중 비교적 정확하다고 알려진 방법은 첫째로 로그인 기반 정보를 이용하는 방법이다. 이 경우 특정 시간대별로 사용자를 구분해 낼 수 있다. 두 번째로 쿠키(cookie)를 이용해서 계산하는 방법이다. 처음 방문할 때 해당 서비스에 대해 쿠키가 생성되고 쿠키가 만료되기 전까지는 여러 번 방문하더라도 같은 사용자로 인식한다. 구글(Google)의 Analytics 서비스도 이 방법을 사용한다[2]. 하지만 첫 번째 경우 한 사용자가 중복된 계정을 통해서 같은 서비스를 이용할 경우 오차가 발생하게 되고 두 번째 경우는 같은 컴퓨터를 여러 명이 사용하는 공공 환경에서의 통계는 활용할 수 없다는 문제점이 있다. I/Pro, NetCravity, MachLogic가 사이트 중심 방법을 채택하고 있다.

 사용자 중심 방법은 표본 추출에 기초한 패널을 구성한 뒤 데이터 수집 소프트웨어를 설치해 행동을 추적한다. TV 시청률 조사 방법인 피플미터(people meter) 방식과 유사하다. 사용자 중심 방법의 전제 조건으로 독립적이고 객관적인 제3의 기관에 의해 측정됨으로써 객관성이 확보되어야 한다. 패널 기반으로 하고 있기 때문에 인구 통계학적 특성 및 시간 경과에 따른 사용 누적 통계 파악이 가능하다. 하지만 사용자의 요청들과 행위들을 모두 수집하는 데 어려움이 있고 데이터를 수집하는 소프트웨어에 따라 정확도와 신뢰성이 크게 좌우될 수 있다. ComScoreMatrix, Nielsen/NetRations, 코리안 클릭 등이 사용자 중심 방식을 채택하고 있다. 

 코리안 클릭은 iTrack이란 소프트웨어를 사용하고 1만 명 가량의 패널을 사용하여 인구 비례에 맞추어 전체 인터넷 사용자의 패턴을 역산한다[3]. iTrack의 특성상 윈도우(Windows)의 인터넷 익스플로어 사용자로 범위가 제한된다. 패널에 설치된 iTrack을 이용해 방문한 사이트 정보를 실시간으로 전송받아 패널이 속한 고객 세그먼트에 따라 통계적 기법을 적용하고 추정한다.

Fig.1 Count on Confusion[4]

 상이한 수집방법과 오차들로 때문에 통계 수집기관마다 결과가 달라질 수 있다. 2008년 월스트리트 저널에 실린 한 기사[4](Fig.1 참고)에 따르면 닐슨(Nielson)이 수집한 UV 데이터와 comScore의 데이터가 서도 다름을 알 수 있다. 아직 마땅한 대안이 없어 많은 마케터들이 광고비 지출에 대해서는 comScore나 닐슨, iTrack같은 웹 측정 회사에 의존하고 있는데 이러한 결과의 맹목적인 신뢰는 잘못된 의사결정으로 이어질 수 있는 문제점이 있다. 심지어 “인터넷에 진실은 없다.”라는 말도 이 있다. 이것은 보는 관점에 따라 무엇이든 진실이 될 수 있다는 의미로 생각한다. 국내에서는 통계 수집기관이 다양하지 않음으로 인해 그 결과의 완전히 신뢰하는 것은 의사판단에 위험이 너무 크다. 따라서 의사 결정에서 이러한 통계는 참고자료로만 활용해야 하고 실제로 정확한 통계를 필요할 경우 가지고 있는 인프라나 다른 신뢰할 수 있는 채널을 통해 정보를 얻는 것이 바람직하다고 생각한다.@

[1] 넬슨코리안클릭

[2] Unique Visitors (or Absolute Unique Visitors)

[3] 인터넷 포털에서의 과학 토픽 검색에 관한 연구 / 송대섭 / 2009

[4] Agencies Know the Score on Web Tracking

클라우드 컴퓨팅 (Cloud Computing)

http://www.flickr.com/photos/pagedooley/4340727578/

 세상이 달라졌다. 얼마 전까지만 해도 아이디어를 실현하는 일은 쉽지 않았다. Facebook과 같은 아주 좋은 아이디어가 있다고 해도 그 아이디어를 실현하기 위해서는 많은 자본, 설비, 네트워크 비용, 운영을 위한 전담 팀이 필요했었다. 이 많은 것들을 준비하기 위해서는 많은 돈이 필요했었다. 결국, 회사나 개인은 아이디어를 실현하는 데 있어서 소극적일 수밖에 없고 그러는 사이에 경쟁에서 뒤처지게 된다. 하지만, 이제는 아니다. 소셜 네트워크 서비스들을 살펴보라. 누구나 한 번쯤은 생각했던 서비스들이 하루가 멀다 하고 쏟아져 나오고 있다. 이들의 숨은 원동력은 무엇일까?

구글(Google) 서비스를 예를 들어서 한번 생각해 보자. 지메일(Gmail)을 쓸 때 네트워크 비용이 얼마나 들지 고민하면서 사용하는가? 피카사(Picasa) 웹 앨범에 파일을 올릴 때 스토리지 가용성 얼마나 되는지 파일의 신뢰도는 얼마나 되는지를 고민하는 사람이 있을까? 그냥 단순히 우리는 사용하기만 할 뿐이다. 필요할 때 용량을 구매하고 필요할 때 네트워크 비용을 추가 지불한다. 이것이 바로 클라우드(Cloud)인 것이다

그리드(Grid) 컴퓨팅이라고 들어봤는가? 이전에 유행하던 그리드 컴퓨팅을 클라우드와 같은 것으로 생각해서는 안 된다. 그리드 컴퓨팅은 인터넷상에 연결되어 있는 서버와 클라이언트 PC 등의 비어 있는 컴퓨팅 파워를 합하여 하나의 컴퓨터로 인식하는 것을 말하지만 클라우드는 더 넓은 범위의 데이터센터를 하나의 자원으로 보이게 한다는 점에서 이와 확실히 구별된다.

이처럼 놀라운 클라우드는 그 발전가능성에 많은 주목을 받고 있다. 구글의 CEO인 에릭 슈미트(Eric Emerson Schmidt)는 한 포럼에서 웹 3.0이란 구름 속에 있는 웹 애플리케이션들의 조합이 될 것이라고 답한 적도 있다. 구글이 이렇게 얘기했다니 그대로 실현될 것만 같은 느낌이 든다. 사실 다른 선진국으로 눈을 돌려보면 클라우드는 이제 막 시작되는 우리나라에서와는 다르게 이미 이슈가 되어왔고 상당히 보편적으로 사용하는 서비스가 되어가고 있다. 우리나라는 클라우드 선진국과 비교할 때 약 4년 정도의 격차가 존재한다고 하지만 분명히 우리도 클라우드 영역에 들어섰고 앞으로의 미래도 이와 같은 형태로 발전할 것임은 믿어 의심치 않다.

소프트웨어의 클라우드는 다음과 같은 세 단계로 발전해왔다. on-premise 방식으로 즉, 회사, 파트너, 고객 스스로 데이터 센터를 구축하고 완전히 컨트롤하고 100% 책임지는 방법에서부터 시작해서 지난 10년간 가지고 있는 하드웨어를 임대하여 사용하는 host 환경이 유행하였고 최근에 돈을 주고 컴퓨팅 리소스 풀을 사용하는 클라우드 컴퓨팅이 나타나고 있다. 클라우드 컴퓨팅은 리소스 풀을 필요에 따라 줄이거나 늘릴 수 있다. 따라서 우리가 원하는 공급 곡선과 유사하게 클라우드 자원을 늘이거나 줄일 수 있다는 말이고 비용도 공급과 비례하게 합리적으로 지불하면 되는 것이다.

클라우드는 모바일과 더불어 하나의 큰 패러다임(paradigm)으로 우리에게 다가오고 있다. 이를 어떻게 활용하는가에 따라 큰 기회가 될 수 있음을 이런 변화를 통해 상기해야 한다. 지금까지는 아이디어를 실현하는 것이 성공의 열쇠였다면 앞으로는 그 아이디어 자체와 아이디어를 실현하는 속도가 성공의 열쇠가 될 것이고 바로 클라우드가 이런 기회를 제공하게 될 것이다.@

알고리즘의 선택과 활용

Algorithms

 컴퓨터 공학(Computer Science)에서는 다음과 같은 3가지 기본적인 계층(Layer)으로 구성되어 있다고 말할 수 있다. 수학과 통계 그리고 이를 이용한 알고리즘(Algorithm)[1]과 데이터 구조, 그리고 이것들을 가공하여 네트워크(Network), 데이터베이스(Database), 그래픽스(Graphics)를 통해서 표현하는 계층으로 나눌 수 있다. 각 계층은 하위 계층을 바탕으로 상위 계층의 문제들을 풀어갈 수 있다. 때문에 하위 계층일수록 그 역할이 아주 중요하다. 이런 계층 중 수학적 이론에 기반을 두고 이를 통해 실 세계 문제들 풀어갈 수 있는 알고리즘 대해 얘기해보고자 한다.

알고리즘의 목표는 무엇일까? 그것은 어떤 문제를 남들보다 효과적으로 빠르게 해결하고자 하는 것이다. 알고리즘을 잘 만들기 위해서는 잘된 디자인(Design)과 좋은 분석(Analysis)과정이 필요하다. 다시 말해서 어떻게 문제를 풀어나갈지 디자인하는 것과 그것이 다른 방법보다 우수한지 분석할 수 있는 능력이 필요하다는 것이다. 이 과정의 기술은 하루아침에 이루어지는 것이 아니라 어떤 문제가 주어졌을 때 그 문제에 접근(Approach)하는 습관을 꾸준히 길러야만 가능하다.

실제로 많은 개발자들이 프로그램을 만들다 보면 앞으로 증가할 데이터의 양과는 상관없이 현재 테스트 되는 데이터를 가지고 결과가 어느 정도 만족할 수준의 속도라면 그냥 넘어가는 경향이 있다. 10건일 때 결과가 0.1초가 나와서 만족했지만 100만 건 1,000만 건일 때 10시간 100시간 이상이 걸릴 수도 있다. 보통 이런 문제들은 개발 단계에서 나타나기보다는 실제 시스템을 운용할 때 나타나고 그에 따른 손실은 개발 비용과 비교할 수 없을 만큼 크다. 이 때문에 설계 단계부터 알고리즘의 선택은 설계단계부터 아주 신중하게 고려되어야 한다.

아주 간단한 예를 들어 살펴보면 1부터 10까지 숫자가 무작위로 나열되어 있는데 이를 정렬하는 문제를 풀어야 한다고 생각해보자. 모든 문제가 그렇듯이 무한정 시간과 자원이 주어진다고 가정하고 하나씩 정렬하다 보면 언젠가는 답이 나오기 마련이다. 다시 말해 Brute-Force[2] 방식을 통해 하나하나 모두 나열해 가면 복잡한 디자인 과정 없이도 우리는 이 문제를 풀 수는 있다. 이는 시간복잡도로 표현하면 O(n^2)로 나타낼 수 있다. 작은 양의 데이터의 문제에서는 꽤 좋은 방법이라고 생각될 수도 있겠지만, 대용량 데이터의 문제에서는 그것이 과연 좋은 접근 방법인지는 다시 생각해볼 필요가 있다.

다른 방법으로 큰 집합은 한번에 정렬하기 어려우니 1부터 5까지 그리고 6부터 10까지 나누는 등 작게 쪼개어 부분집합을 정렬하는 방식인 Divide and Conquer[3]를 생각해볼 수도 있겠다. 결국, 그 유명한 Quick Sort[4]를 적용하는 것이 되는데 위에 Brute-Force 방식보다는 확실히 빨라진다. O(log n) 정보의 시간복잡도가 나올 것으로 예상된다. 하지만, 이것이 최적의 방법일까? 더 나은 방법이 없을지 계속 고민해봐야 한다.

상황에 따라 다르겠지만, 직관적인 방법이 빠를 때도 있다. 10Kg 가방에 넘치지 않게 제한적인 보석을 넣는 0-1 Knapsack[5] 문제를 생각해 보자. 이 문제를 Brute-Force 방식이나 Divide and Conquer를 이용해 풀기는 어려울 수 있다. 다른 방법으로 현재 취할 수 있는 최선의 결과를 미래에 줄 영향을 고려하지 않은 채 선택하는 Greedy를 생각해 볼 수 있을 것이다. 문제에 따라 Greedy가 위 두 가지 문제보다 훨씬 더 빠른 해답을 줄 수 있다. 하지만, 이 방법이 항상 Global optima 결과를 반환해 줄지는 생각해봐야 한다. 하지만, 이 경우에서 Greedy는 Local optima이라는 문제가 있다.

그럼 Global optima를 구하기 위해서는 어떻게 해야 할까? 0-1 Knapsack 문제에서는 가방에 보석을 담을 수 있는 모든 경우를 생각해보면 Global optima를 구할 수 있다. 트리를 이용해 해당 보석을 담을 경우와 담지 않을 경우를 나누어 모두 탐색하면 최적의 해를 구할 수 있다. 트리를 탐색하다 보면 leaf 노드에 다다랐을 때 잘못된 경로를 통해서 왔는지를 깨 닳은 경우가 있는데 이럴 땐 Backtrack 해 다른 노드를 탐색하게 하는 방법이 Backtracking[6]이다. 또한, 미래의 데이터를 예측해 더는 자식 노드를 탐색하지 않아도 된다고 판단하는 방법이 Branch and Bound[7] 방법이다.

이 외에 Hill climbing, Genetic algorithm 등등 수많은 많은 알고리즘이 존재한다. 모든 경우를 설명할 수 없지만 잊지 말아야 할 것은 풀어야 할 어떤 문제에 대해서 여러 방법으로 풀 수 있는 경우가 항상 존재하고 그 중에 어떤것이 가장 좋은지 그 솔루션을 분석해 더 좋은 것을 취할 수 있는 선택이 주어진다는 것이다.

어떤 알고리즘을 선택하느냐는 문제의 종류와 프로그램을 사용하는 고객이 원하는 결과 수준에 따라 달라질 수 있다. 하지만, 개발자들은 항상 지금 해결해야 할 문제보다 더 좋은 다른 방법이 있을 수 있다는 것을 인지하고 어떻게 풀어갈지를 설계(Design), 분석(Analysis)해 최적의 방법을 적용할 수 있는 능력을 꾸준히 길러야 할 것이다.@

[0] http://ai.cau.ac.kr (Daewon Kim)
[1] http://en.wikipedia.org/wiki/Algorithm
[2] http://en.wikipedia.org/wiki/Brute-force_search
[3] http://en.wikipedia.org/wiki/Divide_and_conquer_algorithm
[4] http://en.wikipedia.org/wiki/Quicksort
[5] http://en.wikipedia.org/wiki/Knapsack_problem
[6] http://en.wikipedia.org/wiki/Backtracking
[7] http://en.wikipedia.org/wiki/Branch_and_bound