행정‧공공기관 대국민 웹 사이트 최적화 관리방안

2017.10.

	전 자 정 부 국 정보자원정책과

			목 차

Ⅰ. 개  요	1

1. 추진배경	1

2. 추진경과	1

Ⅱ. 현  황 및 문제점	2

1. 현황	2

2. 문제점 및 시사점	3

Ⅲ. 웹 사이트 최적화 관리개선	5

1. 웹 페이지 용량 감축 등 최적화 추진	5

2. 웹 사이트 적정 응답속도 기준 마련	5

3. 웹 사이트 최적화 점검‧관리체계 정립	6

4. 웹 사이트 수준평가 강화	6

Ⅳ. 향후계획	6

참고: 1. 웹 사이트 최적화를 위한 주요기법

2. 웹 로그 수집 및 분석방식

I. 개 요

□ 추진 배경

❍ 행정‧공공기관의 대국민 웹 사이트는 국민의 공공정보 접근 및 정책참여의 핵심수단으로 역할을 하고 있으나,

- 웹 페이지 용량이 커서 접속지연이나 장애발생 우려가 있어 행정‧공공기관의 웹 사이트 신뢰성이 저하되고 이용에 불편을 초래하고 있음

※ 경주지역 지진발생 후 (구)국민안전처 홈페이지 접속장애(‘16.9월)

❍ 따라서, 국민의 공공정보 접근성 및 신뢰성 향상을 위해 웹 사이트 최적화 등 이용자 관점에서 서비스 수준 관리 필요

- 또한, 동일한 용량의 서버와 네트워크 등을 사용하여 더 많은 요청처리를 위한 웹 페이지 경량화 등 최적화 관리방안*을 마련

* 서버, 데이터 구조, 응용프로그램, 네트워크 등은 제외

□ 추진경과

❍ 행정‧공공기관 주요 웹 사이트 첫 화면 용량 조사 및 경량화 요청(‘16.10.24)

※ 주요홈페이지(800개) 조사결과 255개(32%)가 초기화면 용량 5M 이상

❍ 최적화 기준 마련과 기술안내서 개발을 위해 전자정부지원 사업 정책과제 신청(‘16.12.20, 50백만원) ※ 지원사업 관리비를 이용한 연구과제 미 승인(기재부, 1.20)

❍ 행정‧공공기관 대상, 웹사이트 최적화 필요성 등 교육(3.29, 3.31, 500여명 참석)

❍ ‘행정공공기관 웹 사이트 구축‧운영 가이드’에 최적화 주요기법 등 반영(5.16)

❍ 최적화 기준 마련을 위해 ‘17년 하반기 정책연구 과제 신청(6.28, 46백만원)

※ 정책연구과제 심사(7.11) 결과 미 선정

❍ 웹 사이트 최적화 추진계획 수립(7.14), 민간기관 연구자료 조사(7월, 17건)

❍ 웹 사이트 최적화 관리방안 마련 및 전문가 자문(9.8)

Ⅱ. 현황 및 문제점

□ 현  황

❍ (응답속도) 대표 홈페이지의 첫 페이지 응답속도*는 평균 13초 소요

- 중앙부처가 평균 10.4초로 제일 빠르고 그 다음으로 교육청, 광역시도임

* 페이지내 구성요소 전체 다운로드와 사용자 기기에 표출하는 시간으로 실제 사용자가 체감하는 속도와는 차이가 있음

<행정기관 대표 홈페이지 응답속도 현황, ‘17.8.기준>

(단위: 초, 웹사이트 수)

구분	평균 속도	계	3초 미만	3~5초 미만	5~7초 미만	7~10 초미만	10~15 초미만	15~20 초미만	20초 이상
계	13.3	81	4	7	15	10	17	14	14
중앙부처	10.4	47	4	7	10	7	8	6	5
광역시도	20.2	17	-	-	3	1	2	5	6
교육청	14.3	17	-	-	2	2	7	3	3

※ 공개 tool(https://www.webpagetest.org)로 조사(기준: 서울, IE11, ’17.8～9/3회측정 평균)

- 테스트 시간, 웹 브라우저, 이용자 기기 등에 따라 응답속도 차이가 발생할 수 있음

❍ (페이지 용량) 대표 홈페이지의 첫 페이지 평균용량은 6.2M로 운영

- 중앙부처가 4.8M로 가장 작고, 그 다음으로 교육청, 광역시도 순서임

- 배경화면‧이미지 크기, 콘텐츠 수 등에 따라 용량에 차이가 있음

<행정기관 대표 홈페이지 페이지 용량, ‘17.8.기준>

(단위: MB, 웹사이트 수)

구분	평균 용량	계	1M 미만	1~3M미만	3~5M 미만	6~10M 미만	10~15M 미만	15~20M미만	20M이상
계	6.2	81	2	19	18	30	9	2	1
중앙부처	4.8	47	2	16	12	14	3	-	1
광역시도	9.0	17	-	3	1	6	1	1	1
교육청	7.2	17	-	5	10	1	1	1	-

❍ (최적화 관리) ‘16년 9월 국민안전처 홈페이지 장애 후 행정‧공공기관에 웹 페이지 경량화 요청(’16.10) 등 기관 자율적으로 관리

- 웹 페이지 경량화 등 최적화 필요성 교육(‘17.3),「행정공공기관 웹사이트 구축운영 가이드」에 최적화 주요기법 등 반영(’17.5)

□ 문제점 및 시사점

❍ 웹 사이트의 적정 응답속도 기준이 부재하고, 기관 간의 편차가 큼(최소 1.9초, 최대 56초, 편차 54.1초)

- 응답속도를 3초 이내로 관리해야 이용자 만족도를 제고할 수 있지만, 행정기관의 평균 응답속도는 13초로 4배 이상 높음

⇒ 이용자 만족도 향상과 기관 간의 큰 격차를 줄이기 위해 적정 응답속도 기준이 필요

【참고: 응답속도와 이용자 만족도 관계】

◈ 서비스별 차이는 있지만 응답속도가 3초를 초과할 경우에 이용자 만족도는 50%이하로 떨어짐

< 출처: DEVIEW 2012 발표자료, NHN 김일환 >

◈ 47%의 소비자는 2초 이내에 웹페이지가 열릴 것으로 기대하고, 40%의 소비자는 3초 이상 걸리면 웹페이지를 이탈할 것으로 예측(Kissmetrics*)

* 글로벌 마케팅 데이터 분석 솔루션 기업으로 Akamai(컨텐츠 전송 네트워크 솔루션 기업)와 Dynatrace(웹사이트 및 서버 운영 모니터링 전문기업)의 자료를 기반으로 분석

◈ 페이스북 앱 이용자 37%가 외부 웹사이트로 전환되는 시간이 3초 이상 걸리는 경우 브라우저를 닫는 것으로 나타남(’16.09.02, 아시아투데이)

❍ 웹 페이지의 적정 용량에 대한 기준이 없고, 기관 간에 편차가 큼(최소 0.7MB, 최대 20.4MB, 편차 19.7M)

- 웹사이트 중 73%가 페이지별 평균 전송량이 3MB미만이나, 행정 기관의 평균은 6.2MB로 2배 이상임

HTTP Archive(2010년에 설립, WebPagetest에서 테스트된 백만 여개 사이트에서 웹 페이지 용량, 구성요소, 에러 등 정보를 수집하여 공개)

< 페이지별 평균 전송용량, 출처: http Archive, ’17. 8.기준 >

⇒ 웹 페이지 용량이 응답속도에 밀접한 영향을 미치므로 웹 페이지 적정 용량의 기준을 정하여 최적화 추진 필요

❍ 최적화 점검체계가 부재하고, 행정기관 홈페이지의 용량이 증가(1.7MB) 추세임

- 79개 기관 중 55개가 증가하고 20개는 감소, 나머지 4개 기관은 유지

⇒ 웹 사이트 최적화 여부를 지속적으로 점검‧관리하는 체계와 이행력 확보를 위해 평가 필요

< 대표 홈페이지의 용량증감 비교 >

구 분	용 량(MB)			증감 기관 수
	‘16.11	‘17.8	증감	증가	감소	유지
평균 / 계(79개)	4.5	6.2	1.7	55	20	4
중앙부처(45)	3.6	4.8	1.2	31	12	2
광역시도(17개)	5.7	9.0	3.3	13	4	-
시도교육청(17개)	5.8	7.2	1.3	11	4	2

Ⅲ. 웹 사이트 최적화 관리개선

□ 웹 페이지 용량 감축 등 최적화 추진

❍ 웹 페이지 용량은 3M*이하로 최소화하여 운영‧관리

* 홍보, 쇼핑몰 등 사이트 특성에 따라 3M를 초과할 있음. 따라서 웹 사이트 유형에 따른 상세한 용량 가이드는 ‘18년 연구용역을 통해 제시 예정

❍ 대표 등 주요 웹 사이트는 ‘18년까지, 그 이외는 ’19년까지 최적화 추진

- 전송 데이터 압축, 이미지 최적화, 중복 또는 미사용 스크립트 제거 등 웹 페이지 용량 감축

- 페이지 내 콘텐츠 수 및 DNS* 조회 최소화, 캐시 사용 등으로 사용자 기기와 서버간의 연결 최소화(100회 전후)

* DNS(Domain Name System) 인터넷 주소를 숫자로 된 IP주소로 변환하는 기능

- 구성요소의 적절한 배치*를 통해 이용자가 체감하는 속도 향상 제고

* 스타일시트는 HTML문서 상단에, 스크립트는 하단에 배치하여 콘텐츠를 점진적으로 화면에 표시

□ 웹 사이트 적정 응답속도 기준 마련

❍ 공공정보 접근성과 신뢰성 향상을 위해 응답속도는 3초 이하로 권장*

* 응답속도는 HW 등 인프라, 웹 서비스 운영방식(클라우드, CDN 서비스 등), 최적화, 사용자 기기, 통신환경 등에 영향이 있으므로 일괄 결정이 곤란

- 단, 각 기관의 웹 사이트별 인프라 환경과 운영방식을 고려하여 적정 응답속도 기준을 달리 정해 웹 사이트 운영‧관리 가능

□ 웹 사이트 최적화 점검․관리체계 정립

❍ (행안부) 행정기관의 최적화 추진 및 관리실적 등을 총괄 점검관리

- 각 기관은 별도 요청에 따라 점검실적을 매년 반기말(6월, 12월)까지 제출

※ 웹 사이트 성능 및 품질관리 평가 제도를 도입할 경우 그 이후에는 관리실적 제출 제외

❍ (행정기관) 소속기관 및 산하 공공기관을 포함하여 최적화 및 관리계획을 수립하고, 최적화 추진 및 운영현황 등을 점검관리

- (운영기관/부서) 해당 웹 사이트 최적화 계획 수립, 최적화 추진,  최적화 운영 및 로그 등 이용현황을 점검하여 웹 사이트 운영‧개선

< 행정기관 웹 사이트 최적화 관리체계 >

	행정안전부
	↑		↑
중앙행정기관			광역시도․시도교육청
↑			↑
소속기관, 산하 공공기관(자체)			소속기관․시군구․ 지역교육청, 산하 공공기관(자체)

□ 웹 사이트 수준평가 강화

❍ 웹 사이트 성능과 품질향상을 위한 품질 관리방안, 평가지표 개발(‘18년)

- 구축‧운영 단계별 품질관리 요소‧방법‧절차 등 품질관리 가이드 개발

- 반응형 웹, 쇼핑몰 등 웹 사이트 특성을 고려한 웹 페이지 용량 기준 등 마련

- 웹사이트의 품질수준, 성능, 표준준수 등 웹 서비스 수준을 종합적으로 평가할 수 있는 평가지표 및 방법 등 개발

※ 현재는 웹 사이트의 표준(정보 접근성, 웹 호환성) 준수 여부와 총량감축 실적 평가

❍ 웹 사이트 성능 및 품질향상을 유도하고 이행력 확보를 위해 중앙 부처 행정관리 역량평가와 지자체 합동평가 지표에 반영(‘19년)

Ⅳ. 향후계획

❍「행정‧공공기관 웹사이트 구축운영 가이드」개정(10월)

❍ 행정‧공공기관별 웹 사이트 최적화 추진계획 수립(11월)

❍ 행정‧공공기관 웹사이트 최적화 추진 및 관리현황 점검(‘18년~)

❍ 웹 사이트 품질관리 방안 및 평가지표 개발(‘18년) 및 평가(‘19년)

참고 1		웹 사이트 최적화를 위한 주요기법

◈ 야후 등 민간기관 등에서 웹사이트 경량화 시 사용하는 기법 중 주요 14가지 기법 소개(참고: 웹 사이트 최적화 기법, 스티브 사우더스 지음/박경훈 옮김, 2008)

① HTTP 요청 최소화

- HTML 웹 문서를 웹서버에서 다운로드 받는 시간은 웹 문서의 구성 요소를 다운로드 받는 시간에 비해 적기 때문에 웹 문서 구성 요소를 줄이면 HTTP 요청수가 감소하기 때문에 응답 시간을 줄일 수 있음

- 특히, 웹 페이지의 이미지 개수 및 용량 수를 분석하고 요청 수가 많으면 이미지 맵, CSS Sprite방식 등을 사용하여 웹브라우저가 웹서버에 데이터를 요청하는 횟수를 최소화 하는 방식으로 개발 필요

- (이미지 맵) 이미지 맵을 이용하면 한 이미지로 여러 개의 URL을 연결할 수 있기 때문에 UI의 변경 없이 HTTP 요청수를 줄일 수 있음

* 예) 이미지 버튼을 3개의 이미지를 구분해서 하이퍼링크를 설정하면 3번의 HTTP요청을 하게 되는데, 이미지 맵을 이용할 경우 한 번의 HTTP요청만 하게 되므로 응답 시간을 줄일 수 있음

- (CSS Sprite) CSS Sprite기법은 여러 이미지를 하나로 만들고 CSS속성을 이용해서 필요한 부분의 이미지만 보여주는 기술로 여러 이미지를 하나의 이미지로 합치기 때문에 HTTP요청 횟수를 줄일 수 있음

* HTML문서에 이미지가 5개일 경우 총 6번의( html(1번) + 이미지(5번) ) 요청(HTTP)이 생기되어 속도에 영향을 미침

② 헤더에 만료기한 추가

- 웹브라우저는 캐시를 이용하여 HTTP요청을 줄일 수 있기 때문에 변화가 많지 않은 구성요소에 만료기한 이전일 경우 HTTP요청을 하지 않고 캐시를 이용하여 속도를 향상시킴

- 헤더 만료기한 설정은 이미 방문했던 페이지만 영향을 주기 때문에, HTTP 요청 횟수를 줄이기 위해서는 웹브라우저에 캐시가 빈 상태가 되지 않도록 웹 문서의 구성 요소를 캐시에 저장할 수 있도록 설정하면 반응속도가 빨라지는 요과가 발생할 수 있음

- 헤더 만료기한 설정을 이미지뿐만 아니라 스크립트, 스타일시트 등에 포함한다면 여러 번 요청하더라도 다운로드를 하지 않기 때문에 속도를 향상 시킬 수 있음

③ Gzip 컴포넌트 사용

- 웹브라우저가 압축한 파일을 인식할 수 있을 경우 서버에서 HTML, 스크립트 등을 압축해서 다운로드 한다면 용량이 적어 속도가 빨라질 수 있음

* 이미지와 PDF 등은 이미 압축된 파일인 경우가 많기 때문에 Gzip를 적용하지 않음

- GZip은 웹서버에서 압축하고 이용자PC에서 압축을 해제하는 방식이기 때문에 파일 크기가 2KB보다 큰 경우 적용하는 것이 바람직함

* Gzip이 적용된 경우 평균 약 70%정도의 압축 효과를 갖게 됨.

④ 스타일시트를 위에 배치

- 웹브라우저는 스타일시트를 다 다운받지 않으면 HTML의 렌더링이 안 되고 웹브라우저에 계속 빈 화면이 나타나기 때문에 이용자는 웹서비스가 늦다고 생각함

- 따라서 가장 먼저 스타일시트를 다운로드 받을 수 있도록 HTML문서의 상단에 배치를 하여 점진적으로 렌더링 되는 것을 보여줌으로써 웹 페이지 구성요소를 더 빨리 표시함

⑤ 스크립트는 아래에 배치

- 스크립트는 다운로드할 때 렌더링 되지 않고 선택을 했을 경우에 동작하기 때문에 아래에 배치

- 스크립트가 포함된 웹 문서는 크기와 실행 속도를 높이기 위해 압축, 분산과 같은 기법을 사용하여 스크립트 웹 문서 크기를 줄일 수 있음

⑥ 콘텐츠 전송 네트워크(CDN) 이용

- 동영상, 이미지 등 콘텐츠를 효율적으로 전달하기 위해 분산된 서버에 콘텐츠를 저장하여 사용자에게 전달하는 시스템으로, 많은 사람이 동시에 이용할 경우 과부하가 발생해 전송속도가 떨어지거나 서비스가 중단되는데, CDN은 이런 문제를 해결해 주는 서비스*

* CDN은 사용자와 가장 가까운 곳에서 서비스하는 개념으로 주요 ISP망에 콘텐츠를 분산시켜두고 사용자의 위치에 따라 가장 가까운 곳에서 콘텐츠를 전송하여 서비스 품질과 전송속도가 좋음. 동영상 방송, 파일 다운로드, 이미지 캐싱, 온라인 게임, E-러닝 등 대용량 콘텐츠를 서비스하는데 이용

- 행정‧공공기관은 관련 규정 등 성격상 CDN서비스 이용이 어려울 수 있으므로, 대용량 콘텐츠를 서비스하는 웹 사이트는 콘텐츠를 웹 서버와 분리된 별도의 서버에 구성하여 트래픽 분산처리로 웹 서비스 지연예방 및 성능을 향상시킬 수 있음

⑦ 스크립트, 스타일시트(CSS)를 외부 파일로 제공

- 웹문서에 공통적으로 자주 사용하는 스타일시트, 자바스크립트의 경우 모든 웹문서에 개별적으로 포함하지 말고 공통내용을 별도 파일 형태로 제공해서 캐시기능을 이용하여 빠르게 제공할 수 있음

* 자주 찾는 웹페이지의 경우 캐시가 되어 있으면 빠르게 동작할 수 있는 장점이 있음

- 따라서 캐시를 이용하는 비율이 높다면 스크립트와 CSS를 외부 파일로 제공하는 것이 유리하나

- 이용자 당 페이지 뷰가 적을 경우 또는 캐시를 이용하는 비율이 낮은 경우에는 외부파일보다는 인라인으로 페이지 안에 포함하는 것이 좋음

⑧ DNS(Domain Name System) 조회 수 줄여야함

- DNS를 조회하는데 시간이 소요되고 완료될 때가지 다운로드가 불가능하기 때문에 DNS조회 수를 줄여야함

* 일반 적으로 웹브라우저에서 특정 호스트 이름의 IP 주소를 조회하는데 20～120ms 정도가 소요되며, 웹브라우저는 DNS조회가 완료될 때 까지 어떤 것도 다운로드 받을 수 없음

⑨ 자바스크립트 최소화

- 코드의 불필요한 문자를 줄여서 파일 크기를 줄여 응답 시간을 개선하는 방법으로 모든 주석뿐만 아니라 필요 없는 공백(스페이스, 개행, 탭)을 제거

- 스크립트 최소화와 Gzip을 병행하여 사용하면 전송 데이터 크기를 더 줄일 수 있음

⑩ 리다이렉트 사용 자제

- 리다이렉트*는 HTML문서 자체의 다운로드를 지연시키기 때문에 사용을 자제해야 함  * 이용자를 한 URL에서 다른 URL로 다시 보내는 것을 의미

- (주소 뒤에 슬래시(/)를 빼는 것) 가장 낭비가 심하고 자주 사용하는 방식으로 이 경우 주소 뒤에 슬래시(/)를 넣지 않을 경우 요청 결과로 301 응답과 함께 슬래시(/)가 포함된 주소로 리다이렉트 됨

* 주소 뒤에 슬래시(/)가 없을 경우 오토 인덱싱(자동으로 index.html)과 같은 기본 위치로 가게 하는 것)을 사용할 수 있게 하고 현재 디렉토리로 부터 상대적인 위치에 있는 URL을 불러올 수 있게 해 줌

⑪ 중복되는 스크립트 제거

- 한 페이지에 같은 스크립트를 중복하여 포함시키면 불필요한 HTTP 요청이 생긴다는 것과 스크립트 실행이 낭비되는 점이 있음

- 웹 사이트 규모가 크거나 개발자가 많은 경우에 이러한 현상이 자주 발생함

⑫ ETag를 설정

- ETag(Entity Tag)는 웹 서버와 브라우저가 캐시된 구성요소의 유효성을 확인하기 위해서 사용하는 기술로, 브라우저의 캐시에 저장 되어 있는 구성요소와 원본 서버의 구성요소가 일치하는지 판단하는 또 다른 방법임

- ETag는 단일 서버에서 운영되는 웹 사이트에 적용할 수 있음

※ 캐시 만료기간의 유효성을 확인하는 또 다른 방법은 조건부 GET 요청

- (문제점) ETag는 사이트를 서비스하는 서버에서만 고유한 값으로 이루어짐. 따라서 사이트가 여러 개의 서버에서 운영될 경우에 생성된 ETag가 같은 구성요소라 하더라도 ETag가 불일치하여 구성요소의 모든 데이터를 다시 받음으로 속도가 느려짐

⑬ 캐시지원 Ajax사용하기

- Ajax*의 이점 중의 하나는 이용자가 원하는 데이터를 즉시 제공함

* 이용자가 요청한 새 정보를 클라이언트가 새로 고침 없이 보여줄 수 있게 해 주는 DHTML에서 사용하는 기술로써. 클라이언트를 대신해 서버에 정보를 요청하고 UI단에 이를 전달하여 화면에 필요한 부분만 갱신

- Ajax요청이 수동적인 요청과 능동적인 요청이 있음. 능동적인 요청은 이용자가 응답을 기다리고 있어야 할 수도 있음.

- 따라서 능동적인 Ajax 요청의 성능을 개선하기 위한 방법 중 가장 중요한 부분이 캐시를 지원하게 만드는 것

참고 2		웹 로그 수집 및 분석방식

1. 개 요

❍ (목적) 이용현황 등을 지속적으로 분석하고 웹 사이트 운영 및 개편 시 이를 반영하여 접근성을 개선하고 이용자 만족도 향상을 제고

❍ 웹 로그를 통해 얻을 수 있는 기본적인 정보

- 방문자는 평균 몇 페이지를 둘러보고 떠나는가? 그리고 그 추세는?

- 이벤트/캠페인 후 어느 정도의 방문자가 증가하였는가?

- 재방문을 하는 방문자의 비율은 어느 정도 되는가?

- 어떤 페이지/콘텐츠를 방문자들이 가장 선호하는가?

- 방문자는 어떤 페이지에서 웹 사이트를 떠나는가?

- 어떤 검색엔진 및 검색단어로부터 웹 사이트를 방문하는가?

- 어떤 검색엔진에 어떤 키워드 광고를 해야하는가?

- 어떤 웹 사이트가 우리 웹 사이트를 링크하고 있는가?

- 방문자의 웹 브라우저, 언어 등 사용 환경은 어떻게 되는가?

- 언제 배너의 이미지 등을 바꿔서 관심도를 높여야 하는가?

- 특정 페이지 내 어떤 링크를 선호하여 클릭하는가?

- 방문자는 웹 사이트 내에서 어떤 경로로 이동을 주로 하는가?

- 방문자는 페이지별 몇 분정도로 머무르고 있는가?

<출처: 원명미, 웹 로그분석을 통한 인터넷 쇼핑몰에 관한 연구, 청주대, 2008)

2. 웹 로그 수집 방식

웹 로그를 수집하는 방식으로는 웹 서버 로그파일 방식, 패킷 스니핑 방식, 페이지 태깅 방식 등이 있음

[그림 1] 웹 로그 수집 방식

가. 웹 서버 로그파일 방식

1) 개요

❍ 로그파일은 웹 서버에 접근한 IP 주소와 전송한 객체에 대한 기록해 놓은 문자(텍스트) 파일로서, 웹 서버에서 자동으로 생성

❍ 웹 서버 상의 웹 로그를 분석하면 방문자가 어떤 경로를 통해 접근했고 어떠한 이용 패턴을 보였는지를 알 수 있음

❍ 웹 로그파일에는 오류(Error)정보, 접속(Access)정보, 조회(Referal)정보, 에이전트(Agent)정보 등이 담겨 있으며, 아파치와 IIS 등의 웹 서버에서는 이들을 조합하거나 확장된 형태로 로그파일에 남길 수 있음

① (Access Log) 일반적으로 사이트 방문기록 등을 기록하며 Access 로그파일을 기반으로 사이트 방문시간, 방문경로 파악이 가능

② (Referer Log) 이용자가 사이트 방문을 위해 어떠한 검색엔진을 활용하여 어떤 키워드를 검색하여 방문하였으며, 어느 URL경로를 통해 접속하였는지를 알 수 있음

- 검색된 키워드를 통해 이용자들이 원하는 콘텐츠를 구성할 수 있음

③ (Agent Log) 이용자의 웹 브라우저 및 OS의 종류, 화면해상도 등에 관한 정보를 알 수 있음

- 웹 사이트를 이용하는 주 이용자의 브라우저 종류나 화면 해상도를 파악할 수 있어 화면 설계 등 웹 사이트 구성에 단서를 제공

④ (Error Log) 웹 서버에서 발생하는 모든 에러와 접속 실패 등을 기록

- 링크 오류나 프로그램이 정상적으로 작동하지 않은 경우 등 에러 로그가 자주 발생하면 사이트의 신뢰성에 치명적이기 때문에, 에러 로그를 주기적으로 점검하여 사이트 수정‧보완 필요

2) 운영 구조

❍ 웹 서버 내의 로그파일을 로그 분석 솔루션으로서 이용자 수 통계, 이용 콘텐츠 통계, 접속 경로, 이용 환경 등의 이용 통계를 분석

[그림 2] 웹 서버 로그파일 방식의 운영 구조(자료 넷스루)

3) 장단점

❍ (장점) 웹 서버에 남는 로그를 그대로 활용하므로 로그 수집을 위한 별도의 서버가 추가로 필요하지 않음

❍ (단점) 웹 서버가 많은 경우에 서버에 남겨진 로그파일들을 관리하기 어려우며, 로그 기록을 로그 분석 솔루션이 설치된 서버로 이동하는 과정에서 여러 원인에 의하여 웹 로그가 누락될 수 있음

4) 적용 환경: 웹 서버 로그파일 방식은 다음의 경우에 적합

▸자체적으로 웹 서버를 운영하고 있는 경우

▸웹 로그 분석 솔루션 도입이나 개발이 가능한 경우

▸웹사이트 운영 기관 내에 웹 로그 분석과 이용 통계 관리를 위한 인력이 있는 경우

▸분석 대상 데이터의 기간에 구애받지 않고 다양한 형태로 로그를 분석할 필요가 있는 경우

▸웹 로그파일을 외부에 공개하기를 꺼려하는 경우

▸SSL(Secure Sockets Layer)을 사용하는 서비스가 있을 경우

나. 패킷 스니핑 방식

1) 개요

❍ 패킷 스니핑이란 네트워크 패킷을 수집하는 방식으로서, 네트워크 경로 상에 패킷을 엿볼 수 있는 장치인 스니퍼를 삽입하여 웹 로그를 수집하는 방식

2) 운영 구조

❍ 웹 서버가 연결된 Switch/Tab 장비로부터 패킷을 추출하는 스니퍼를 삽입하여 웹 로그를 수집 서버에 축적하고, 로그를 분석

[그림 3] 패킷 스니핑 방식의 운영 구조(자료: 넷스루)

3) 장단점

❍ (장점) 웹 페이지의 수정이 필요 없고 데이터를 한 곳에서 관리한다는 장점이 있음

- 네트워크 단에서 데이터를 수집하므로 콘텐츠 전송 중 취소되는 시점, 보안 이슈 분석이 가능

❍ (장점) 추가적인 하드웨어가 필요하고 대용량의 트래픽을 갖는 웹사이트의 경우 수집을 위해 고(高)사양의 장비가 필요

- 또한 다수의 CP(Contents Provider)로 구성되거나 웹 서버가 네트워크적으로 분산되어 있는 경우에는 데이터 수집에 어려움

4) 적용 환경: 패킷 스니핑 방식은 다음의 경우에 적합하다.

▸자체적으로 웹 서버를 운영하고 있으며 웹 서버의 수가 5대 이상인 경우

▸로그 분석 솔루션에 투자가 가능한 경우

▸웹사이트 운영 기관에 이용 통계 관리를 위한 전문인력이 있는 경우

▸웹사이트 운영 기관들이 다양한 이용 현황 분석을 원할 경우

▸웹사이트 운영 기관들이 웹 로그를 외부에 공개하기를 꺼려할 경우

▸다수의 웹 서버를 동일 네트워크 환경에서 운영하여 관리 Point 감소가 필요한 경우

다. 페이지 태깅 방식

1) 개요

❍ 웹 페이지에 웹 로그를 수집하는 스크립트를 삽입(tagging)하는 방식으로 웹 사이트를 구성하는 콘텐츠, 서버, 제공자, 네트워크 구성에 무관하게 웹 로그 수집 가능

2) 운영 구조

❍ 이용자가 웹 페이지를 이용할 때마다 해당 웹 페이지 내에 삽입된 스크립트가 실행되면서 이용자의 접속경로, 웹 페이지의 URL, 이용자 환경(OS, 브라우저 등) 등의 정보를 실시간으로 수집 서버로 전송

- 수집 서버에 수집된 로그 기록을 실시간으로 분석하는 방식

[그림 4] 페이지 태깅 방식의 운영 구조(넷스루)

3) 장단점

❍ (장점) 스크립트가 삽입된 페이지에 대한 정보만 수집 서버로 전송 되므로 불필요한 로그파일이 쌓이지 않아 로그 파일의 크기가 타 방식에 비해 상대적으로 작음

- 또한, ASP(Application Service Provider) 서비스 형태로 이용할 경우 별도의 SW나 HW가 필요 없어 다수의 CP(Content Provider)로 구성 되거나 웹 서버가 네트워크적으로 분리되어 서비스되는 경우에 유리

❍ (단점) 웹 페이지에 스크립트가 누락되면 통계적으로 오류가 발생

- 또한 자체적으로 로그 수집 및 저장을 위해서는 별도의 서버 필요

4) 적용 환경:  페이지 태깅 방식은 다음의 경우에 적합

▸웹사이트 규모가 비교적 작은 경우

▸웹 서버를 직접 관리하지 않는 경우

▸웹사이트 이용 통계를 실시간으로 파악하고 싶은 경우

▸웹사이트 운영 기관이 웹 로그의 외부 유출을 꺼려하지 않을 경우

▸로그 분석 솔루션 도입을 위한 투자가 어려운 경우

▸로그 분석 솔루션 운영 인력이 없는 경우

3. 데이터 분석 방식

❍ 웹 로그 데이터 분석은 로그 분석 솔루션이나 분석 도구를 구입, 설치하여 활용하는 ‘소프트웨어 운용 방식’과 외부 서비스를 활용하는 ‘호스팅 서비스 이용 방식’으로 구분

[그림 5] 웹 로그 데이터 분석 방식

가. 소프트웨어 운용 방식

1) 개요

❍ 로그 분석 솔루션이나 플러그인 등을 설치하여 웹 로그파일을 분석하는 방식으로, 웹 서버 로그파일 방식, 패킷 스니핑 방식, CMS(Contents Management System) 플러그인(Plug-in) 방식이 있음

CMS에 웹사이트 접속 통계를 추출하기 위한 플러그 인을 설치하여 사용하는 방식이다.

- 페이지 태깅 방식도 수집 및 분석 서버를 자체적으로 운영하는 경우는 이 방식에 속함

❍ 로그 분석 솔루션이나 플러그인 구입비 등 초기 비용이 소요되나, 원하는 만큼의 정보를 분석하여 활용할 수 있다는 장점이 있음

2) 적용 환경:  소프트웨어 이용 방식은 다음의 경우에 적합

▸웹 서버를 직접 운영하고 있는 경우

▸웹 로그 분석 솔루션 도입을 위한 신규 투자가 가능한 경우

▸웹 로그 분석과 이용 통계 관리를 위한 인력이 있는 경우

▸분석 기간에 구애받지 않고 다양한 형태로 로그를 분석할 필요가 있는 경우

▸웹사이트 운영 기관들이 웹 로그를 외부에 공개하기를 꺼려할 경우

▸다수의 웹 서버를 관리해야 하는 경우

▸로그분석 결과를 전략적으로 활용하고자 하는 경우

▸SSL을 사용하는 서비스가 있을 경우

나. 호스팅 서비스 활용 방식

1) 개요

❍ 로그 분석 솔루션을 구입‧설치하지 않고 외부 전문기관의 서비스를 이용하는 방식으로, 무료도 있으나 일반적으로 사용료를 지급

❍ 외부기관의 서비스를 이용하는 페이지 태깅 방식이 대표적이며, 호스팅 업체에서 제공하는 이용 통계를 활용하는 방식(이를 ‘웹 서버 지원기능 활용 방식’으로 부르기로 함)도 이에 속함

2) 적용 환경: 호스팅 서비스 방식은 다음의 경우에 적합

▸웹사이트 규모가 비교적 작은 경우

▸웹 서버를 직접 관리하지 않는 경우

▸웹사이트 이용 통계를 실시간으로 파악하고 싶은 경우

▸웹사이트 운영 기관이 웹 로그의 외부 유출을 꺼려하지 않을 경우

▸로그 분석 솔루션 도입을 위한 투자가 어려운 경우

▸로그 분석 솔루션 운영 인력이 없는 경우

[표 ] 웹 로그 분석 방식간 비교

구 분	웹서버 로그파일 방식	패킷 스니핑 방식	페이지 태깅 방식	CMS Plug-in 방식	웹서버 지원기능 활용 방식
개요	웹 서버에 저장된 로그 파일을 분석하는 방식	데이터 네트웍을 직접 감시하면서 패킷을 검출하고, 패킷에 포함된 HTTP 데이터를 찾아내어 웹 로그 포맷으로 기록하는 방식	분석하고자 하는 웹 사이트의 페이지에 스크립트를 삽입하여 별도의 분석용 로그를 남기는 방식	CMS에 접속 통계를 분석하기 위한 Plug-in 프로그램을 설치하고, 실시간으로 접속 통계를 분석하는 방식	웹 호스팅 서비스업체에서 접속통계를 제공하는 방식
특징	가장 일반적인 방법. 로그 수집을 위한 별도의 장치나 작업이 필요없고, 웹 서버에서 설정만 하면 됨	패킷 스니핑 솔루션을 이용하며, 반드시 별도의 로그 수집 장비가 필요함	기존 웹 페이지의 수정이 필요하며(스크립트 삽입), 별도의 로그 수집 장비가 필요함	로그파일을 이용하지 않고 CMS에 요청되는 요구에 의하여 접속 통계 분석. 별도의 투자비가 소요되지 않음	웹 호스팅 업체가 웹 서버에 대한 request에 의하여 접속 통계를 분석하므로 별도의 투자비가 필요치 않음
장점	과거 데이터 분석에 용이, 웹페이지 수정 불필요	과거 데이터 분석에 용이, 웹페이지 수정 불필요, 다수의 웹서버 관리시 분석용이	실시간 분석이 용이함, 스토리지 부담 없음 웹 서버와 독립적으로 운영	투자비가 소요되지 않으며, 실시간 모니터링이 가능함	접속 통계 산출을 위한 SW 투자비나 관리 인건비가 필요치 않음
단점	실시간 분석이 어려움, 스토리지 부담, 대형 웹사이트의 경우 측정이 어려움 별도의 운영인력 필요, 기술적 통계 중심(서버통계)	실시간 분석이 어려움, 스토리지 부담, 별도의 운영인력 필요, 기술적 통계 중심(서버 통계)	웹페이지 수정 필요, 정확한 통계를 위해 모든 페이지 수정 마케팅적 통계 중심(방문자 통계)	마케팅 전략에 필요한 접속 경로, 사용 환경 등에 대한 정보를 제공하지 않음	접속자 수, 페이지 뷰, 히트 수 등 제한적 정보만 제공
적합 환경	SSL을 사용하는 서비스가 있을 경우	다수의 웹 서버를 하나의 네트워크 환경에서 운영하여 관리 포인트 감소가 필요한 경우	웹 서버 로그 파일 방식이나 패킷 스니핑 방식으로 로그 파일을 수집할 수 없는 환경	단순히 접속 통계를 실시간으로 파악하고자 하는 소규모 기업이나 공공기관에 적합	웹 호스팅 서비스를 이용하거나 데이터 센터를 이용하는 경우에 적합