웹 사이트 이용 패턴 발견하기

[비내림이]

데이터 마이닝 첫삽뜨기 3
웹 사이트 이용 패턴 발견하기
고객의 웹 클릭으로 생성되는 웹 데이터들은 지속적으로 누적되는데 이 데이터를 수집, 저장, 정리, 관리하여 분석하는 것은 온라인 고객과의 관계를 생성하고 유지시키며 생산성 있는 웹 사이트의 최전선을 구축하는 데 있어 결정적 열쇠가 됩니다.

유동하 | mozala@hufs.ac.kr

넷스루 데이터 마이닝 연구소에서 웹 서버 로그 파일을 분석하는 웹 마이닝 시스템을 설계하고 있으며,
한국 외국어 대학교 경영학 석사 과정에 웹 마이닝 과목을 개설해 출강하고 있다.

사용자가 웹 사이트에 접속한 후 모든 작업들은 웹 서버를 통해 이뤄집니다. 즉 우리가 웹 서버에 요청을 하게 되면 그 이후의 모든 작업들은 웹 서버에 미리 정해 놓은 위치에 데이터로 남게 됩니다. 이러한 웹 서버 로그 파일은 웹 사이트를 통해 이뤄지는 모든 작업들에 대한 기록이라 할 수 있습니다. 따라서 로그 파일을 분석하면 누가 언제 무엇을 웹 서버에 요청했고 가져갔는지를 알 수 있으며, 웹 서버에 얼마나 많은 사람들이 왔는지, 어디로부터 왔는지, 무엇을 좋아하는지, 무엇을 가장 싫어하는지, 가장 오래 보는 페이지와 가장 많이 보는 페이지는 무엇인지 등을 알 수 있습니다. 그러나 웹 로그 데이터를 제대로 이해하기 위해서는 사용 중인 웹 서버의 특성과 관리 등에 대해서 자세히 알고 있어야 합니다. 이번에는 로그 파일과 같은 웹 데이터의 획득과 해석으로부터 데이터 마이닝의 응용인 웹 데이터에서 지식을 발굴하는 웹 마이닝(web mining) 방법을 살펴보겠습니다.

데이터 수집

어느 웹 사이트에 심심해서 방문을 했든지 그렇지 않으면 구체적인 목적을 갖고 방문을 했든지 간에 기업의 웹 사이트에 한번이라도 접속해서 사람들이 웹 사이트에서 행한 모든 일은 기록으로 남게 되는데 이것을 로그 파일이라고 합니다. 로그 파일은 웹 서버의 종류와 설정이 어떻게 되었는지에 따라서 파일 포맷과 이름이 다르긴 하지만 이것을 분석하면 방문자가 어떤 경로를 통해 들어왔는지 알 수 있습니다. 웹 사이트 방문자의 행동 기록을 담고 있는 로그 파일과 같은 웹 데이터의 수집은 클라이언트로부터 수집하는 방법과 서버로부터 수집하는 방법이 있습니다.

클라이언트로부터 수집

웹 사이트 방문자 즉 클라이언트 측으로부터 데이터 수집은 모든 웹 페이지마다 스크립트를 삽입하여 사용자가 웹 페이지를 요청할 때 실시간으로 로그 데이터를 수집하는 방식으로, 자바스크립트나 자바애플릿과 같은 에이전트를 사용합니다. 이 경우 모든 페이지마다 일일이 스크립트를 삽입해야 하기 때문에 스크립트를 유지하고 관리하는데 많은 시간과 노력이 들며 자바 애플릿의 경우는 로드될 때 오버헤드가 발생하기도 합니다.

이 외에도 익스플로러와 같은 브라우저에 플러그인 시키거나 전용 브라우저를 사용하는 방법이 있습니다. 이러한 방법은 데이터 수집을 위해 사용자의 협조가 필요합니다. 서버로부터 데이터 수집에 비해 캐시(cache)와 세션 구분(session identification) 문제를 해결할 수 있는 이점이 있지만, 단일 사용자에 대한 데이터만을 수집하게 됩니다. 하지만 현실적으로 한 대의 컴퓨터는 여러 사람이 함께 사용하는 경우가 많으며 수정된 브라우저를 사용할 수 있도록 사용자에게 인센티브를 줘야 하는 어려움도 있습니다.

서버로부터 수집

웹 서버의 로그에 기록된 데이터는 다중 사용자에 의한 웹 사이트 접근을 거의 동시에 기록합니다. 이 데이터는 기록되는 내용의 범위에 따라 일반 로그 포맷(common log format) 또는 확장 로그 포맷(extended log format)과 같이 다양한 형식으로 저장됩니다. 또한 웹 서버의 로그에는 쿠키(cookie)와 파라미터의 쿼리 데이터(parameter query data)도 저장할 수 있지만 쿠키(사용자 인증에 관한 사용자 브라우저와 서버간의 주고받은 기록)의 경우 사생활 침해와 관련된 문제를 안고 있습니다. 이렇게 로그 파일은 웹 서버에 요청된 모든 기록을 담고 있지만 그것을 해석하는 관점에서 본다면 네트워크에 존재하는 다양한 층의 캐시 때문에 완전한 데이터라고 할 수 없으며 클라이언트가 시도한 작업 메쏘드가 포스트(post) 방식인 정보는 자세히 기록되지 않습니다. 즉 이것을 데이터 마이닝하기 위해서는 데이터 전처리 및 변환의 노력이 많이 필요하다는 의미이기도 합니다.

<그림 1>에서 보면 사용자가 웹 사이트에 방문하는 다양한 방식으로 인해 각 서버에는 접근 기록이 남게 됩니다. 클라이언트 3는 ISP(Internet Service Provider) 서버를 이용해 웹 사이트를 방문하고, 클라이언트 2는 프록시 서버를 이용해 웹 사이트를 방문합니다. 이때 방문하는 웹 서버의 로그에는 ISP 서버와 프록시 서버의 정보만 남게 됩니다. 클라이언트 1은 별도의 서버를 거치지 않고 직접 웹 사이트에 방문하기 때문에 웹 서버의 로그에 클라이언트 1의 행동 기록이 남게 됩니다.

프록시 서버는 방화벽으로 알려져 있지만 인터넷 사용자들에게는 속도를 빠르게 해주는 캐싱 서버로 더 많이 알려져 있습니다. 또한 ISP 서버도 프록시 서버 기능을 합니다. 가능하다면 ISP 서버나 프록시 서버의 로그 데이터를 분석 자료로 사용하면 좋겠지만 특별한 경우를 제외하고는 이 데이터를 분석 데이터로 활용하는 경우는 거의 없습니다. 이 외에도 TCP/IP 패킷으로부터 트래픽을 모니터링 할 수 있는 패킷 스니핑(packet sniffing) 기술이 웹 서버 로그를 통한 데이터 수집의 대안이 되기도 하지만 별도 서버를 구축해야 하므로 비용이 많이 드는 단점이 있습니다. 필자는 웹 사이트 방문 시 모든 기록을 담고 있는 웹 서버 로그를 분석 대상 데이터로 하여 설명하겠습니다.

데이터 탐구

웹 사이트에서 이뤄지는 대부분의 작업들을 기록하고 있는 웹 서버 로그 데이터는 웹 사이트 이용패턴을 발견하기 위한 매우 중요한 데이터입니다. 이들 로그 파일들은 아파치(Apach)처럼 여러 가지 포맷으로 여러 파일에 나눠 저장되기도 하고, IIS (Internet Information Service)처럼 한 파일에 저장되기도 합니다.

초기 로그 파일의 데이터 항목들은 웹 서버마다 형태와 종류가 달라 한 로그 분석 프로그램이 모든 로그 파일을 분석할 수 없었습니다. 그래서 등장한 것이 CERN과 NCSA에서 HTTP 프로토콜로 규정한 CLF(Common Log Format)입니다. 이 경우 공통적인 형식으로 로그 데이터를 저장하기 때문에 웹 서버가 다르다 하더라도 로그 데이터 형식은 비슷하게 됩니다. 하지만 여전히 CLF 이외에도 해당 웹 서버가 고유하게 제공하는 형식도 남아 있으므로 여러분 웹 서버의 종류와 설정을 확인해 보기 바랍니다.

웹 서버 로그 파일

CLF는 보통 트랜스퍼(transfer) 또는 액세스(access) 로그라고 불리며 데이터의 항목은 고정적인 형식으로 각각 스페이스로 구분되어 <리스트 1>과 같은 형식으로 기록됩니다. 이때 값을 가지지 않는 항목들은 ‘-’로 기록됩니다. 첫 번째 데이터 항목인 호스트(host)는 클라이언트의 도메인 이름 또는 IP 주소가 기록됩니다. Ident는 Identity Check가 활성화되어 있고 클라이언트 측에서 Identd(Identification daemon)를 실행하고 있다면 클라이언트 측으로부터 제공되는 정보가 저장되지만 현재는 이 부분을 사용하고 있지 않으며 항상 ‘-’로 기록됩니다.

Authuser는 만약 해당 사이트가 기본적인 HTTP 인증을 요구한다면 이 내용이 사용자 ID가 됩니다. Date는 웹 서버에 작업을 요구한 시간과 날짜로 형식은 [day/month/year:hour :minute:second zone] 이며 타입은 <표 1>과 같습니다.

Request는 다른 필드들과 달리 따옴표(“ ”)로 묶여 있으며 클라언트측에서 요청한 정보를 나타냅니다. 이것은 세 개의 세부 필드를 기록하는데 GET, POST, HEAD 등의 명령어와 실제 명령대상의 파일이름 그리고 전송 프로토콜 이름/버전으로 구성되어 있습니다. Staus는 클라이언트로 보내지는 데이터의 상태 코드로 100부터 500까지의 5개의 카테고리로 구분됩니다. 마지막으로 Byte는 헤더 정보를 제외하고서 전송된 데이터의 크기를 기록한 것입니다.

반면에 ECLF(Extended Common Log Format Standard) 는 확장된 로그 형식으로 사용자가 직접 로그 파일의 데이터 항목을 결정할 수 있습니다. <리스트 2>와 같이 ECLF는 일반적으로 CLF의 형식에 Referrer, Agent 정보가 추가됩니다. Referrer 정보는 해당 웹 페이지를 요청하기 전에 어디에 있었는지 대한 정보로, 외부 웹 사이트 뿐만 아니라 내부적으로 네비게이션을 파악하는 자료로도 쓰일 수 있습니다. Agent 정보로 부터는 클라이언트의 브라우저와 OS에 대한 지식을 얻을 수 있습니다. 더불어 쿠키 정보도 기록할 수 있는데 쿠키 정보는 웹 사이트에서 필요에 의해 설정한 사용자의 정보가 저장되는 부분으로, 회원 등록을 통해 사이트를 운영하는 곳이라면 누가 방문해서 어디를 보았는지에 대한 궁금증을 해결할 수 있습니다.

데이터 전처리

로그 파일이 웹 사이트에서 일어나는 모든 기록을 담고 있지만 웹 브라우저에 캐시된 페이지들을 사용자가 요청할 경우 이는 로그에 기록되지 않습니다. 그러므로 분석하는 과정에서 정상적으로 진행될 수 없는 네비게이션일 경우 캐시된 페이지이거나 뒤로 가기 버튼(back button)을 사용한 경우라고 유추할 수 있습니다. 또한 사용자 구분을 일반적으로 클라이언트 IP 주소로 구분하기 때문에 여러 사용자가 하나의 IP 주소로 방문해도 한 사용자로 처리될 가능성이 있습니다. 이 경우는 쿠키 등 다른 항목들의 도움을 받아 정교하게 분석해야 합니다.

이처럼 로그 파일의 데이터를 전적으로 신뢰할 수 있는 것이 아니기 때문에 이용 패턴 발견을 위해서 데이터를 정제하고 보정하는 전처리 과정이 필요합니다.

데이터 정제

HTTP 프로토콜은 웹 페이지 구성 요소를 웹 서버에 독립적으로 요청하므로 사용자가 웹 페이지 하나를 보려고 웹 서버에 요청하면 웹 서버의 로그에는 요청한 웹 페이지와 그것의 구성 요소까지 전부 기록됩니다. 예를 들어 A.html 페이지에는 a1.gif, a2.gif, a3.gif라는 3개의 이미지 파일이 포함되어 있습니다. 이때 사용자가 A.html 파일을 웹 서버에 요청할 경우 A.html은 포함되어 있는 3개의 이미지 파일을 같이 요청하게 됩니다. 결국 사용자는 A.html이라는 1개의 파일만을 웹 서버에 요청했지만 웹 서버 로그 파일의 기록에는 A.html, a1.gif, a2.gif, a3.gif 라는 4개의 요청 기록이 <표 2>와 같이 남게 됩니다. <표 2> 데이터는 예제로 제시한 데이터 이지만 트래픽이 많은 사이트의 경우 기본 설정으로 로그 데이터를 남길 경우 이처럼 페이지 구성요소가 모두 기록되므로 그 파일 크기는 분석을 포기하고 싶게 할 수도 있습니다.

분석의 목적이 사용자의 웹 사이트 이용 패턴을 발견하는 것이라면 사용자가 요청하지 않은 이미지 파일과 스크립트 파일의 요청들은 제거할 필요가 있습니다. 또한 각종 소프트웨어 로봇의 접근에 대한 요청을 제거할 필요도 있습니다. 즉, 분석의 목적이나 관점에 따라 정제되는 데이터의 범위는 달라질 수 있습니다.

사용자 구분

웹 사이트에 접근한 사용자를 구별(user identification)하기 위해서는 웹 로그에 사용자 정보가 포함되도록 웹 서버를 수정하거나 프로그래밍하고 쿠키를 사용하는 등의 기법이 필요합니다. 그렇지 않고 CLF나 ECLF 형식의 로그 데이터를 대상으로 사용자를 구분하려면 IP 주소를 이용할 수밖에 없습니다. 이때 여러 사용자가 같은 IP 주소를 할당받아 사용한다면 서로 다른 OS로 사용자 구분을 하기도 하고 브라우저의 버전이나 종류의 비교를 통해 사용자를 구분할 수 있습니다.

예를 들어 <표 3>의 정제된 웹 서버 로그 데이터는 같은 IP 주소를 가지고 있으며 사용자 ID는 기록되어 있지 않습니다. 그러나 Agent 정보를 비교하면 5, 6, 8, 10번째 엔트리에서 나머지와는 다른 OS 환경을 사용해 접속한 것을 알 수 있습니다. 이것으로 최소 2명의 사용자가 있음을 추정할 수 있고 윈도우 98 환경이 아닌 사용자의 네비게이션 경로는 A-B-C-J 임을 알 수 있습니다.

다음으로 사용자의 네비게이션 경로를 가지고 사용자를 구분합니다. 이때 사용되는 로그 데이터 항목은 <표 3>의 Referred 항목이고 <그림 2>와 같이 웹 사이트 내 하이퍼링크(hyperlink)의 연결 구조를 알 수 있는 정보가 필요합니다. 로그 데이터에서 하나의 IP 주소가 방문한 페이지들이 하이퍼링크를 통해 접속한 것이 아니라 어떤 페이지를 직접 접속하였다면 이 IP 주소를 같이 사용하는 다른 사용자가 존재한다고 추측할 수 있습니다.

<표 3>의 데이터를 보면 3번째 엔트리의 페이지 L은 A 또는 B의 페이지 경로를 통하지 않고 직접 접속했습니다. 또한 7번째 엔트리의 Referred 정보를 보면 L로부터 연결되어 R로 접속했는데 L은 이전의 어떤 엔트리와도 연결되어 있지 않습니다. 그리고 <그림 2>를 보면 네비게이션 경로상 L은 E를 통해 접속할 수 있는데 <표 3>의 데이터에는 E를 요청한 기록이 없습니다. 이것으로 같은 IP 주소를 가진 세 번째의 사용자를 추론할 수 있고 이 사용자의 네비게이션 경로는 L-R임을 알 수 있습니다. 마지막으로 윈도우 98을 사용하는 나머지 사용자의 네비게이션 경로는 A-B-F-O-G-A-D임을 확인하게 됩니다. 그러나 한 사용자가 두 개의 웹 브라우저를 사용하는 경우나 URL을 직접 타이핑해 접속한 경우도 있기 때문에 현실적으로 이때 다른 사용자라고 명쾌히 말할 수 없는 것이 웹 로그 데이터의 특징입니다.

이처럼 사용자를 구분할 때 IP 주소를 기반으로 하지만 쿠키를 이용하는 경우 로그 데이터에 사용자 정보를 남겨 사용자를 구분하는 방법도 있습니다. 아파치 웹 서버의 로그 파일에 쿠키 정보를 추가해 ECLF 포맷으로 기록하면 <리스트 3>과 같이 쿠키 정보를 뒷부분에 남길 수 있습니다.

쿠키에 사용자 ID 정보가 있을 때 사용자를 구분하는 방법을 살펴보겠습니다. <표 4>의 데이터를 보면 쿠키 정보가 있는 엔트리 4, 9는 사용자 ID가 있습니다. 즉, hojin이라는 ID의 사용자가 접근한 페이지 경로는 F-O입니다. 즉 최종적으로 각 사용자는 A-B-G-A-D, F-O, A-B-C-J, L-R이라는 경로로 웹 사이트를 네비게이션했음을 알 수 있습니다.

세션 구분

일정 시간의 주기 동안에 같은 사용자가 여러 번 웹 사이트에 접속하는 경우는 흔한 일입니다. 세션 구분(session identifi cation)의 목적은 사용자가 여러 번 방문할 때 방문 횟수를 구분하기 위함입니다. 세션은 한 사용자가 웹 사이트에 접속해서 웹 사이트를 떠날 때까지를 말합니다. 따라서 실제 한번 방문했을 때 사용자의 웹 사용 패턴을 발견하기 위해서 세션을 구분하는 것은 데이터 마이닝을 위한 입력 데이터로서 매우 중요한 의미를 가지게 됩니다.

그러나 실제 웹 로그 데이터만으로 세션을 구분하기에는 어려움이 있습니다. 사용자들은 로그아웃(logout) 버튼을 누르지 않고 웹 브라우저를 닫는 경우가 많습니다. 세션 구분의 가장 단순한 방법은 타임 아웃(time out) 방법이 있습니다. 이 방법은 사용자의 요청이 있은 후 일정한 시간 동안 요청이 발생하지 않은 경우 사용자는 웹 사이트를 떠난 것으로 간주하고 세션을 종료시킵니다. 그 후 사용자가 다시 웹 사이트에 접근하면 새로운 방문을 시작하는 것으로 가정하게 됩니다. 일반적으로 30분을 타임아웃 값으로 지정하고 있지만 이 값은 웹 사이트의 특성에 따라 다릅니다.

결국 세션의 의미는 연속된 행동의 단위를 의미하는 것입니다. 잠시 다른 웹 사이트로 이동했다가 돌아온 경우라 하더라도 같은 웹 브라우저로 30분 이내에 재방문한 경우를 연속된 동작으로 파악합니다. 왜냐하면 웹 로그 데이터에서는 이 경우를 구분할 수 없기 때문입니다.

<표 4>에서 같은 IP 주소를 사용하는 엔트리 11의 시간(time) 정보를 보면 엔트리 10의 요청이 있은 지 거의 2시간 만에 요청이 발생하였습니다. 이때 사용자의 세션은 30분 타임아웃을 초과했기 때문에 이미 엔트리 10에서 방문이 끝났고 엔트리 11부터 재방문한 것으로 추정할 수 있습니다. 이때 이 세션의 네비게이션 경로는 A-D임을 알 수 있습니다.

<그림 3>에서 보면 A-D 경로를 가지는 세션은 이전에 G 페이지를 웹 서버에 요청한 후 시간이 30분을 넘었기 때문에 다른 세션으로 구분된 것입니다. <표 4>의 데이터처럼 사용자 정보가 있을 경우는 사용자의 로그인 시점과 로그아웃 시점을 알 수 있어 세션을 좀더 정확히 발견할 수 있습니다. 이때 <그림 3>에서와 같이 사용자 정보가 있는 엔트리가 요청한 페이지 F와 O에서 사용자는 로그인과 로그아웃했음을 정확히 알 수 있습니다. 이 사용자는 로그인하여 F-O 경로로 웹 사이트를 네비게이션하고 로그아웃하여 방문을 마쳤기 때문에 세션종료 하였다고 보는 것이 맞습니다.

하지만 같은 IP 주소를 가지는 사용자의 로그인 이전의 이동 경로와 로그아웃 후의 이동 경로도 동일한 세션으로 추정해 볼 수 있습니다. 단 이때 세션 타임아웃 없이 연속적인 요청이 웹 서버에 있어야 합니다. 이 경우는 사용자가 웹 사이트에 방문하여 네비게이션하는 매우 일반적인 패턴입니다. 예를 들어 인터넷 쇼핑몰에 접속하면 먼저 관심있는 물건을 살펴보고 구매의사가 있을 때 로그인하는 게 보편적 습성일 것입니다. 이때 로그인하기 전 둘러본 상품에 대한 경로를 로그인해서 구매한 것과 같은 세션으로 보지 않으면, 로그인하지 않은 사용자 정보가 없는 세션에서 발견된 네비게이션 패턴은 구매 없이 상품만 둘러보는 것으로 단정지을 수 있습니다.

정확한 세션 구분을 위해서는 다양한 알고리즘을 적용하는 것이 바람직하며 <그림 3>과 같이 로그인 이전과 로그아웃 이후의 경로도 동일한 세션으로 처리되어야 합니다. A-D 경로로 시작하는 다음 세션은 타임아웃으로 이전 A-B-F-O-G 세션과는 구분되어지며 이후에 다시 로그인 정보가 있는 페이지들이 타임아웃 없이 나타나면 그 페이지들과 같은 세션으로 결합되어질 것입니다. 이러한 세션 구분 과정을 통하여 방문 시 사용자는 각각 A-B-F-O-G, A-D, A-B-C-J, L-R라는 경로로 웹 사이트를 네비게이션했음을 알 수 있습니다.

경로 보정

세션은 한 사용자가 웹 사이트에서 돌아다닌 기록의 단위 묶음이라 할 수 있습니다. 하지만 가끔 이 묶음에는 이해할 수 없는 경로가 나타나기도 합니다. 웹 사이트의 하이퍼링크 구조상 존재하지 않는 경로가 세션 내에서 만들어 졌다면 믿을 수 있는 사용자 세션을 만들기 위해서 이러한 경로를 보정해(path completion) 줘야 합니다. 이것은 클라이언트에 캐시된 내용을 사용자가 요청해서 접속이 이뤄졌기 때문입니다.

이때 웹 로그 데이터의 기록을 살펴보면 한 사용자가 웹 서버에 요청한 히스토리에 하나의 페이지가 아닌 여러 페이지가 포함되어 있을 것입니다. 연속된 페이지 요청에서 존재하지 않는 경로의 페이지 요청이 있다면 이 페이지에 가장 가까운 히스토리 내에 이 페이지로 하이퍼링크되는 페이지가 있었을 것이고 그 페이지는 이미 사용자의 브라우저에 캐시되어 있을 것입니다.

이런 경우 <그림 2>와 같은 사이트 구조를 통해 경로를 보정할 수 있습니다. 페이지 G는 페이지 O로부터 직접적으로 접속할 수 없습니다. <표 4>의 데이터를 보면 엔트리 11에서 요청된 페이지 G에 대한 Referred 정보는 페이지 B입니다. 이것은 사용자가 웹 브라우저에서 뒤로 가기 버튼을 이용해서 페이지 B로 되돌아갔음을 추측할 수 있습니다. 그래서 웹 로그 데이터에는 페이지 B를 요청한 기록이 페이지 G와 가까운 시간 내에는 없고, 단지 Referred 정보에만 기록되어 같은 엔트리에 나타난 것입니다. 즉 페이지 G를 접근한 사용자의 요청 히스토리를 살펴보면 엔트리 2와 4가 요청한 페이지 B와 페이지 F가 브라우저에 캐시되어 있었음을 추측할 수 있습니다. 페이지 F와 B를 세션의 페이지 경로에 포함시켜 보면 사용자는 각각 A-B-F-O-F-B-G, A-D, A-B-A-C-J, L-R라는 경로로 웹 사이트를 네비게이션했음을 알 수 있습니다.

그러나 이러한 경우는 북마크를 통해 방문했을 수도 있고 웹 사이트가 거대해지며 복잡해지고 있기 때문에 현실적으로 이와 같은 경로 보정이 꼭 바람직하다고는 할 수 없지만 독자들은 학습하는 입장에서 이해하기 바랍니다.

데이터 마이닝 기법의 적용

데이터 마이닝은 대용량 데이터베이스로부터 기존에 알려지지 않은, 즉 단순한 질의어로 추출할 수 없는 형태의 ‘유용한’ 정보를 찾아내고 이를 바탕으로 데이터에 대한 통찰을 얻는 것으로 정의할 수 있습니다. 이때 웹에서 발생하거나 웹 사이트에 저장한 데이터를 대상으로 유용한 패턴을 찾아내는 기술을 웹 마이닝 또는 웹 데이터 마이닝이라고 합니다. 데이터 마이닝 작업이 전처리에서 많은 노력과 시간이 소비되듯 웹 마이닝 또한 로그 데이터 전처리와 세션을 구분해 경로를 찾아내는 데 어려움이 많습니다.

고객의 웹 클릭으로 생성되는 로그 데이터를 전처리해 방문 경로를 추적할 수 있도록 만들어 놓은 것을 클릭 스트림 데이터라고 하는데 이 데이터를 고객 프로 파일들과 통합해 분석하면 매우 유용한 정보가 됩니다. 웹 사이트에서 수집한 클릭 스트림 데이터와 고객 등록 정보들을 마이닝하면 어떤 제품들이 교차판매에 유리한지 어떤 정보들을 어떻게 링크시킬 것인가, 그리고 어떤 판촉광고가 홈페이지 방문자들에게 인기가 있었는지에 대한 정보를 고객의 성별, 연령 등의 인구 통계학적인 특성을 바탕으로 제시할 수 있습니다. 웹 사이트 방문자들의 지리적 분포 또한 우편번호의 집계를 통해 산출해 낼 수 있어 웹 사이트를 활성화시키는데 필요한 주요 정책들을 결정하는데 도움을 줄 수 있습니다.

클릭 스트림 데이터와 고객 프로파일 데이터에 데이터 마이닝 기법을 적용시켜서 얻을 수 있는 지식을 살펴보겠습니다. 연관 규칙(association rules)은 하나의 세션에서 발생한 아이템 사이의 연관성을 찾아주는 기술로, 사용자가 하나의 세션에서 본 페이지들 사이의 연관성을 찾을 수 있습니다. 이를 통해 사용자가 웹 사이트를 방문해서 함께 참조하는 페이지 정보를 얻을 수 있습니다. 예를 들어 <표 5>의 데이터는 사용자의 방문 세션(SID)에 이동하는 페이지 경로(pages) 정보를 가지고 있습니다. 이것을 이용해 “사용자들은 웹 사이트에 방문해서 A 페이지와 D 페이지를 함께 보는 경향이 있다”는 정보를 얻을 수 있습니다.

순차 패턴(sequential patterns)은 시간적인 순서에 따른 페이지의 집합을 나열했을 때 각 세션 간 페이지의 연관성을 찾아줍니다. 사용자의 과거 방문 세션에서 이동한 페이지 경로는 일정한 기간 후에 방문해서 이동한 페이지 경로와 연관성이 있을 수 있습니다. <표 6>의 예와 같이 사용자(UID)를 중심으로 과거 세션 정보 묶음({})으로 연관성을 찾아보면 “B 페이지를 방문한 사용자는 일정한 시간 이내에 웹 사이트를 다시 방문해서 C 페이지도 방문하는 경향이 있다”라는 패턴을 발견할 수 있습니다.

클러스터링(clustering)은 유사한 특징이 있는 여러 가지 객체를 몇 개의 군집으로 생성하는 마이닝 기술입니다. 웹 마이닝에서 클러스터링의 대상이 되는 객체는 웹 사이트를 방문한 사용자와 웹 사이트를 구성하는 페이지가 됩니다. 클러스터링 기법을 적용할 수 있는 데이터를 살펴보면 <표 7>은 페이지(PID) 정보와 그 페이지의 트래픽 정보(pageview, error, duration)를 담고 있습니다. 이 정보를 이용해서 “A 페이지와 D 페이지는 웹 트래픽으로 판단해 볼 때 같은 군집에 속하는데 이 군집의 특성은 에러 발생이 높고 페이지뷰도 높으며 머문 시간이 작다”라는 지식을 얻을 수 있습니다.

또한 <표 8>과 같은 데이터는 어느 기간 동안 특정 페이지를 본 사용자(UID)와 그 사용자의 웹 사이트 접근 정보(pageview, visit), 구매 횟수(buy)를 담고 있는데 웹 사이트 이용 패턴을 가지고 사용자를 유사한 형태의 군집으로 묶을 수 있습니다. 예를 들어 “사용자 1과 사용자 2는 웹 방문 패턴으로 볼 때 같은 군집에 속하는데 이 군집의 특성은 특정 페이지를 본 페이지뷰가 다른 군집에 비해 낮지만 방문수와 구매횟수가 높다”는 정보를 얻을 수 있습니다. 이때 이 그룹에 속하는 사용자들은 상품을 여러 번 보지 않고도 구매율이 높은 사용자들 이므로 어떤 상품을 구매하고 싶어하는 지 먼저 예측하여 적절한 상품 판촉메일을 보낼 수 있습니다.

무궁무진한 도전 과제들

실제로 웹 서버에 관심을 가지고 웹의 환경적인 부분을 살펴보면 우리는 운영 중인 웹 사이트 환경에서 분석 가능한 로그 데이터를 만드는 데 어려운 점을 찾아 볼 수 있습니다. 개발 당시 디렉토리 구조, 파일 명명 규칙 등 사전 설계 작업 등이 없이 개발이 이뤄져 물리적 사이트 맵이 의미가 없는 경우라면 로그 데이터가 제대로 저장된다 하더라고 이를 분석하는 과정은 그리 쉽지 않습니다. 더불어 웹 컨텐츠는 시간이 흐를수록 증가하여 요즘은 CMS(Content Managemet Systems)에 의해 관리되어 동적 페이지로 이뤄지는 웹 사이트가 많으며 프로그램에 의해 자동 생성되는 페이지는 사이트 구조 도출의 어려움이 존재합니다. 이 경우 웹 로그 데이터만을 가지고 사용자를 구분하고 경로 보정 없이 분석해야 합니다. 현재 상용 웹 로그 분석기의 기술적 흐름은 웹 로그 데이터만을 가지고 분석하는 단순 웹 로그 통계 분석에서 레거시(legacy) 데이터를 활용하는 방향과 통계 분석에서 마이닝 분석 방향으로 고도화되고 있습니다.

방대한 데이터 마이닝의 통계적 기법과 복잡한 알고리즘, 무수히 적용 가능한 응용을 단 3회의 연재에 걸쳐 설명하려다 보니 용어 및 개념부터 기초 알고리즘 소개, 웹 데이터로의 응용까지 주마간산처럼 지나쳐 버리지 않았나 싶습니다. 하지만 데이터 마이닝에 대해서 조금이라도 관심을 가지도록 도왔다면 필자는 보람을 느낄 수 있을 것 같습니다. 살펴보았듯이 데이터 마이닝은 통계적 전문성과 컴퓨팅 파워, 비즈니스 백그라운드에 기반한 다양한 지식의 산물이므로 다방면에 관심이 있어 하는 프로그래머에게는 매우 매력적인 도전이기도 합니다. 대용량의 데이터를 빠르고 정확하게 분석할 수 있는 아직 발견되지 않은 알고리즘을 연구하거나 요즘의 멀티미디어 세대에 맞추어 발견된 지식을 그래픽하게 표현하는 기술도 개발돼야 합니다. 이처럼 데이터 마이닝이라는 이름이 말해주듯 아직도 발굴할 수 있는 연관 분야가 여러분들에게 무궁무진한 도전 과제로 남겨져 있습니다.


정리 | 위윤희 | iwish@korea.cnet.com


*출처 : 마이크로소프트웨어 12월호