Apache 서버가 갑자기 움직이지 않게되거나,

기동이 안되고 다음과 같은 에러를 낼때 대응

 

File size limit exceeded$HTTPD -DSSL

 

이 경우에는 아파치가 만들어내는 로그의 크기가

엄청나게 커져서, ext2시스템이 인식할수 있는

파일크기의 한계인 2G를 넘어선 경우이다..

 

# tail /PATH/TO/logs/error_log
[notice] child pid 10132 exit signal File size limit exceeded (25)
[notice] child pid 10131 exit signal File size limit exceeded (25)

# ls -al /PATH/TO/logs -rw-r--r--   1 root   root   2147483647 Sep 28 11:01 access_log
-rw-r--r--   1 root   root   2147483647 Oct 13 14:03 error_log

이후에  해당 파이을 백업을 하고,  재기동을 하면 정상적으로
기동된다.
 
# mv /PATH/TO/logs/access_log /PATH/TO/logs/access_log.bak
# mv /PATH/TO/logs/error_log /PATH/TO/logs/error_log.bak
# service httpd start
2007/08/08 14:23 2007/08/08 14:23
출처 블로그 > [스케치]
원본 http://blog.naver.com/tripsketch/3703720
=======================================================================
출처 : http://www.ricky.co.kr/jsboard/read.php?table=system&no=17&page=1
=======================================================================
[제목] 아파치 로그 파일 - 특이한 녀석들은 따로 담거나 없애기* 제목이 좀 이상하네요........^.^작성자 : 김칠봉 <san2(at)linuxchannel.net>작성일 : 2001. 04. 30대상자 : 초보- 힌트 URL : 임은재님이 쓴 글을 보고 나서   http://kltp.kldp.org/stories.php?story=00/10/22/9724184- 관련 문서 : 아파치 제공 문서   http://httpd.apache.org/docs/mod/mod_log_config.html   http://httpd.apache.org/docs/mod/mod_setenvif.html목차1. 배경2. 기초지식  2-1. 로그포맷과 CustomLog 지시자  2-2. 아파치 환경변수 설정3. 예제  3-1. 특정 IP 주소만 환경변수로 설정하기  3-2. 특정 타입의 파일만 환경변수로 설정하기  3-3. 특정 User-Agent 만 환경변수로 설정하기  3-4.  종합예제 : 사오정(?) 로그 분석 피하기------------------------------------------1. 배경몇 달 전부터 Webalizer 라는 로그 분석기로 제가(이하 '필자') 운영하는 싸이트의로그를 대충 분석(?)해 봤는데 사오정(?) 분석이 되어 버렸더군요.결정적으로 필자가 운영하는 싸이트의 대부분은 php로 구성되어 있는데, 이는 실제로 - 방문자 외에 localhost에서 php가 실행하는 로그 기록 - 로봇들의 접근 기록 - 운영자(필자)가 접근한 로그 기록 등등이 함께 기록되어 있어 순수 방문자 통계에 약간 덜(?) 정확한 통계가 나오더군요. 따라서 이런 유형들의 로그는 없애거나 따로 로그기록하는 것이 낫을 것 같더군요. 위의 내용이 이하 다루는 내용입니다.2. 기초지식2-1. 로그포맷과 CustomLog 지시자Module mod_log_config 은 아파치 기본 모듈입니다.    로그 포맷 스트링    %a : 원격의 IP 주소    %b : 헤더를 포함한 전송량(bytes)    %{var}e : 환경 변수 "var"    %f : 파일이름    %h : 원격의 호스트    %{hdr}i : 서버에 들어오는(요청) 헤더 값 "hdr"    %l : 원격의 로그인 ID(지원한다면)    %{label}n : 다른 모듈에서 "label" 구성    %{hdr}o : 응답 헤더 값 "hdr"    %p : 서버의 Canonical 포트 번호    %P : 자식 프로세스 ID(PID)    %r : 첫번째 요청 라인    %s : 상태코드    %t : 시간 포맷(CLF 포맷)    %{format}t : "format"으로 구성된 시간 포맷    %T : 서버에 요청하는 시간(초)    %u : 원격의 유저이름(인증시)    %U : 요청한 URL    %v : 클라이언트 요청에 따른 Canonical 서버네임    %V : UseCanonicalName 설정에 따른 서버네임일반적으로 아파치를 설치하고 나면, 다음과 같이 기본설정되어 있을 겁니다.(굳지 수정할 필요없음)    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined    LogFormat "%h %l %u %t \"%r\" %>s %b" common    LogFormat "%{Referer}i -> %U" referer    LogFormat "%{User-agent}i" agent    CustomLog /usr/local/apache/logs/access_log common물론 이 정도는 다 알고 계시리라 믿습니다.    로그 기록 지시자    CookieLog    CustomLog    LogFormat    TransferLogCookieLogs는 제외하고 나머지 지시자에 대해서 알아봅시다.LogFormat 지시자Syntax: LogFormat format|nickname [nickname]Default: LogFormat "%h %l %u %t \"%r\" %>s %b"Context: server config, virtual hostStatus: BaseCompatibility: Nickname only available in Apache 1.3 or laterModule: mod_log_configCustomLog 지시자Syntax: CustomLog file|pipe format|nickname [env=[!]environment-variable]Context: server config, virtual hostStatus: BaseCompatibility: Nickname only available in Apache 1.3 or later.Conditional logging available in 1.3.5 or later.Module: mod_log_configTransferLog 지시자Syntax: TransferLog file|pipeDefault: noneContext: server config, virtual hostStatus: BaseModule: mod_log_configLogFormat 지시자는 앞에서 예제가 있으므로 생략하고 비슷한 기능을 가진CustomLog, TransferLog 지지자에 대해서 잠깐 알아봅시다.둘다 file 에 로그를 기록한다는 면에서는 동일한 기능입니다.(pipe 기능도 동일)    같은점    1. 둘다 file에 로그를 기록한다.    2. |pipe 에 설정한 외부 프로그램을 인자로 사용할 수 있다.    3. 둘다 다중 로그를 사용할 수 있다.    다른점    1. CustomLog 지시자는 LogFormat 지시자에서 설정한 nickname이나 Log format을        인자로 사용할 수 있다.    2. CustomLog 지시자는 환경변수를 인자로 가질 수 있다.따라서,이하 다룰 내용은 환경변수를 설정하고 이 환경변수(env)와 동일(=)하거나 그렇지 않은(!=)특정 유형에 대해서 로그에 기록해야하 하므로 당연히 CustomLog 지시자를 사용해야합니다.*주의)환경변수를 인자로 사용할 경우 하나만 가능.이해가 되셨는지 모르겠네요....2-2. 아파치 환경변수 설정아파치에서 환경변수를 설정하는 방법은 몇가지 있습니다.예를 들어,    - mod_env 모듈에 의한       SetEnv       지시자 이용    - mod_setenvif 모듈에에 의한       BrowserMatch       BrowserMatchNoCase       SetEnvIf       SetEnvIfNoCase       지시자 이용등이 있습니다.여기에서 주로 사용할 지시자는 BrowserMatch 지시자와 SetEnvIf 지시자입니다.*참고)xxxxNoCase 지시자는 대소문자를 구분하지 않겠다는 의미입니다.이 두개의 지시자에 대한 사용법만 간단하게 알아봅시다.BrowserMatch 지시자Syntax: BrowserMatch regex envar[=value] [envar[=value]] ...Default: noneContext: server config, virtual host, directory, .htaccessOverride: FileInfoStatus: BaseModule: mod_setenvifCompatibility: Apache 1.2 and above (in Apache 1.2 this directive was found in thenow-obsolete mod_browser module); use in .htaccess files only supported with1.3.13 and laterSetEnvIf 지시자Syntax: SetEnvIf attribute regex envar[=value] [envar[=value]] ...Default: noneContext: server config, virtual host, directory, .htaccessOverride: FileInfoStatus: BaseModule: mod_setenvifCompatibility: Apache 1.3 and above; the Request_Protocol keyword andenvironment-variablematching are only available with 1.3.7 and later; use in .htaccess files only supportedwith 1.3.13 and later   환경변수 지정 및 값 지정 방법   1.varname, or   2.!varname, or   3.varname=value   예 :   BrowserMatch ^Mozilla forms jpeg=yes browser=netscape   BrowserMatch "^Mozilla/[2-3]" tables agif frames javascript   BrowserMatch MSIE !javascript   BrowserMatchNoCase Robot is_a_robot   SetEnvIfNoCase User-Agent Robot is_a_robot   BrowserMatchNoCase mac platform=macintosh   BrowserMatchNoCase win platform=windows   SetEnvIf Request_URI "\.gif$" object_is_image=gif   SetEnvIf Request_URI "\.jpg$" object_is_image=jpg   SetEnvIf Request_URI "\.xbm$" object_is_image=xbm        :   SetEnvIf Referer www\.mydomain\.com intra_site_referral        :   SetEnvIf object_is_image xbm XBIT_PROCESSING=1   SetEnvIfNoCase Host Apache\.Org site=apache   SetEnvIf 지자자에서 attribute 에 올 수 있는 것들 :   Remote_Host - the hostname (if available) of the client making the request   Remote_Addr - the IP address of the client making the request   Remote_User - the authenticated username (if available)   Request_Method - the name of the method being used (GET, POST, et cetera)   Request_Protocol - the name and version of the protocol with which the request                                    was made (e.g., "HTTP/0.9", "HTTP/1.1", etc.)   Request_URI - the portion of the URL following the scheme and host portion   그외   Host, User-Agent, and Referer 가능   see http://www.rfc-editor.org/rfc/rfc2616.txt따라서,BrowserMatch와 SetEnvIf User-Agent 는 서로 동일하다는 것을 알 수 있을 겁니다.*중요)CustomLog 지자자와 다르게 환경변수 인자에 여러 개를 설정할 수 있음.여기까지 이해가 되셨다면 다음은 보지 않아도 될듯 하군요.......^.^3. 예제3-1. 특정 IP 주소만 환경변수로 설정하기- 환경변수 이름 : do_not_log- 목적 : 이 환경변수에 해당되는 특정 IP 주소는 access_log에 기록하지 않는다.    SetEnvIf Remote_Addr "^127.0.0.1$" do_not_log    SetEnvIf Remote_Addr "^211.35.159.12[89]$" do_not_log    SetEnvIf Remote_Addr "^211.35.159.1[345][0-9]$" do_not_log    위에서 설정한 특정 IP 주소는    127.0.0.1 자기자신을 말하는 루프백 주소    211.35.159.128, 211.35.159.129 두개의 IP 주소    211.35.159.130 ~ 211.35.159.139 10개의 IP 주소    211.35.159.140 ~ 211.35.159.149 10 개의 IP 주소    211.35.159.150 ~ 211.35.159.159 10 개의 IP 주소즉 원격의 IP 주소(Remote_Addr)가 위와 일치하면 do_not_log 환경변수에 지정하는 예임.*참고)^ 은 시작을 의미$ 은 마지막을 의미[0-9] 0~9까지의 숫자중 어느 하나3-2. 특정 타입의 파일만 환경변수로 설정하기    SetEnvIfNoCase Request_URI "\.(gif|jpg|png|css|js|java)$" do_not_log    요청 URI(Request_URI) 파일이    *.gif    *.jpg    *.png    *.css    *.js    *.java    로 끝난 파일인 경우(대소문자를 구별하지 않음) do_not_log 환경변수에 지정함3-3. 특정 User-Agent 만 환경변수로 설정하기- 환경변수 이름 : do_not_log 과 is_a_robot- 목적 : 이 환경변수에 해당되는 특정 User-Agent는 access_log에 기록하지 않고,             따로 로그(robot-log)에 기록하거나 기록하지 않기 위함.    BrowserMatchNoCase "ru-robot" do_not_log is_a_robot    BrowserMatchNoCase "Slurp/si" do_not_log is_a_robot    BrowserMatchNoCase "Mercator" do_not_log is_a_robot    BrowserMatchNoCase "Gulliver" do_not_log is_a_robot    BrowserMatchNoCase "SyncIT/" do_not_log is_a_robot    BrowserMatchNoCase "FAST-WebCrawler" do_not_log is_a_robot    BrowserMatchNoCase "Lycos_Spider" do_not_log is_a_robot    BrowserMatchNoCase "^ia_archive" do_not_log is_a_robot    BrowserMatchNoCase "^tv" do_not_log is_a_robot    BrowserMatchNoCase "Scooter" do_not_log is_a_robot    BrowserMatchNoCase "ZyBorg/" do_not_log is_a_robot    BrowserMatchNoCase "KIT-Fireball" do_not_log is_a_robot    BrowserMatchNoCase "Googlebot/" do_not_log is_a_robot    BrowserMatchNoCase "DIIbot/" do_not_log is_a_robot    BrowserMatchNoCase "teoma_agent3" do_not_log is_a_robot    BrowserMatchNoCase "empas_robot" do_not_log is_a_robot모두 로봇으로 맞게 설정되었는지 모르겠네요...............T.T각각의 정규표현식 조건에 맞는 User-Agent 인 경우, do_not_log 환경변수와is_a_robot 이라는 두개의 환경변수에 설정한 예입니다.is_a_robot 이라고 또 하나의 환경변수를 지정한 이유는 앞서 얘기했듯이이 조건게 맞는 User-Agent가 접근할 경우 따로 로그에 기록하기 위함입니다.이 BrowserMatchNoCase 지시자 대신에 SetEnvIfNoCase User-Agent 로 대신할 수 있는데첫번째 부분을 다음과 같이 설정할 수 있습니다.(둘다 똑 같은 결과임)    SetEnvIfNoCase User-Agent "ru-robot" do_not_log is_a_robot3-4.  종합예제 : 사오정(?) 로그 분석 피하기앞의 3개의 예제를 모두 적용하면 다음과 같습니다.목적은 배경에서 설명했듯이 가능한 access_log 파일에 - 방문자 외에 localhost에서 php가 실행하는 로그 기록은 기록하지 않는다. - 로봇들의 접근 기록은 따로 robot-log 파일에 기록한다. - 운영자가 주고 접근할 IP 주소는 로그에 기록하지 않는다. - *.gif, *.jpg, *.png, *.css, *.js, *.java 등과 같은 파일은 로그에 기록하지 않는다. 이 정도의 조건이라면 가능한 어느 정도 수준으로 순수 방문자의 접근 기록만 access_log 파일에 기록할 수 있습니다. -- httpd.conf(실제로 필자가 운영하는 아파치 설정 내용임) --------------------#### 중간 생략##LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combinedLogFormat "%h %l %u %t \"%r\" %>s %b" commonLogFormat "%{Referer}i -> %U" refererLogFormat "%{User-agent}i" agentLogFormat "%h %l %u %t \"%r\" %>s %b \"%{User-Agent}i\"" use_robot#### 중간 생략#### 환경변수 do_not_log에 일치하지 않은 접근만 access_log 파일에 기록함.##CustomLog /usr/local/apache/logs/access_log combined env=!do_not_log## 중간 생략## 로봇들은 따로 robot_log 파일에 user_robot 포맷에 맞게 기록함##CustomLog /usr/local/apache/logs/robot_log use_robot env=is_a_robot## 중간 생략## 특정 IP 주소는 로그에 기록하지 않는다.## 주로 서버 IP 주소와 운영자가 자주 접속하는 IP 주소들##SetEnvIf Remote_Addr "^127.0.0.1$" do_not_logSetEnvIf Remote_Addr "^211.35.159.12[89]$" do_not_logSetEnvIf Remote_Addr "^211.35.159.1[345][0-9]$" do_not_log## 중간 생략## 주로 이미지 파일을 요청했을 경우 로그에 기록하지 않는다.##SetEnvIfNoCase Request_URI "\.(gif|jpg|png|css|js|java)$" do_not_log## 중간 생략## 로봇들의 환경변수 지정##BrowserMatchNoCase "ru-robot" do_not_log is_a_robotBrowserMatchNoCase "Slurp/si" do_not_log is_a_robotBrowserMatchNoCase "Mercator" do_not_log is_a_robotBrowserMatchNoCase "Gulliver" do_not_log is_a_robotBrowserMatchNoCase "SyncIT/" do_not_log is_a_robotBrowserMatchNoCase "FAST-WebCrawler" do_not_log is_a_robotBrowserMatchNoCase "Lycos_Spider" do_not_log is_a_robotBrowserMatchNoCase "^ia_archive" do_not_log is_a_robotBrowserMatchNoCase "^tv" do_not_log is_a_robotBrowserMatchNoCase "Scooter" do_not_log is_a_robotBrowserMatchNoCase "ZyBorg/" do_not_log is_a_robotBrowserMatchNoCase "KIT-Fireball" do_not_log is_a_robotBrowserMatchNoCase "Googlebot/" do_not_log is_a_robotBrowserMatchNoCase "DIIbot/" do_not_log is_a_robotBrowserMatchNoCase "teoma_agent3" do_not_log is_a_robotBrowserMatchNoCase "empas_robot" do_not_log is_a_robot## 이하 생략##------------------------------------------------------END
2006/09/11 14:11 2006/09/11 14:11
출처 블로그 > 정신없이 어디로 뛰어야 하는걸까?
원본 http://blog.naver.com/vhfpss/20002975774

* tomcat 4. 대까지 적용


앞으로 test 라는 context에서 작업 하고자 한다면.....

구조는 c:\Tomcat4.1\webapps\test 폴더를 하나 만드시고,
test\WEB-INF\classes 가 되도록 폴더 구조를 만드시면 됩니다.(WEB-INF 반드시 대문자)

그리고, server.xml 에서 268 라인 쯤에


<Context path="/test" docBase="test" debug="0" reloadable="true"/>


<Context path="/test" docBase="webapps/test" debug="0" reloadable="true"/>라고 하니깐 안되더군요...



라고 하시면 끝....reloadable="true"는 무엇이냐 하면, 소스 코드가 바뀌었을 때 Tomcat 를 껐다 켜지 않아도 자동적으로 리로드 되게 하는 것입니다.
그러나, 경험에 의하면 자동적으로 되긴 되는데 빨리빨리는 안된다는 말씀...ㅠㅠ;;

파일들이 가야할 위치는, 앞으로 작업하게 될 jsp, html 등은 test 밑에 있으면 됩니다.
그리고, servlet 이나 기타 .java 파일들, 즉 class 파일들은 test\WEB-INF\classes 밑에 가면 됩니다.

여기까지 하시고, 간단한 html 을 작성하여 test 밑에 두시고,
브라우저에서 호출할 땐, http://localhost:8080/test/hello.html 하시면 됩니다.....



* tomcat 5. 대 적용


1. 톰캣 어드민 페이지를 연다. 예)http://도메인:8080/admin

2. $TOMCAT_HOME/conf/tomcat-users.xml파일을 아래와 같이 수정


---------------------------------------------------------------------------------------

<?xml version='1.0' encoding='utf-8'?>
<tomcat-users>
  <role rolename="admin"/>
  <role rolename="manager"/>
  <user username="tomcatusername" password="tomcatpassword" roles="admin,manager"/>
</tomcat-users>

---------------------------------------------------------------------------------------

3. tomcat-users.xml에서 기재했던 사용자아이디와 패스워드를 이용 admin페이지에 로그인한다.

4. 오른쪽 상단에 commitchange버튼을 클릭한다.

5. $TOMCAT_HOME/conf/Catalina/localhost 디렉토리에 기존에 없던 ROOT.xml 파일이 생성된다.

6. ROOT.xml 파일을 자신이 원하는 디렉토리 경로로 변경하면 된다.


----------------------------------------------------------------------------------------

** default 설정 예)

<?xml version='1.0' encoding='utf-8'?>
<Context displayName="Welcome to Tomcat" docBase="/usr/local/tomcat/webapps/ROOT" path="" workDir="work/Catalina/localhost/_">
</Context>

----------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------

** 변경된 설정 예)

<?xml version='1.0' encoding='utf-8'?>
<Context displayName="Welcome to Tomcat" docBase="/usr/local/tomcat/webapps" path="" workDir="work/Catalina/localhost/_">
</Context>

----------------------------------------------------------------------------------------


2006/09/11 14:07 2006/09/11 14:07
목록보기 | 아파치 (70) 목록열기

[펌] httpd.conf 완벽 가이드! (비공개) | 아파치 포스트 삭제 2004/12/14 23:26
http://blog.naver.com/zeldign/40008797301
출처 카페 > windows 와 linux.. / 고슴도치
원본 http://cafe.naver.com/praying4u/22


 httpd.conf 파일은 크게 세부분으로 나누어져 있다.

   Section 1: Global Environment  : 아파치 전체적인 영향이 미치는 설정
   Section 2: 'Main' server configuration : 주 서버에 대한 설정
   Section 3: Virtual Hosts : 가상 호스트에 대한 설정

 자, 그럼 이제부터 이 아파치웹서버의 모든 환경을 설정하는 아파치환경파일 httpd.conf파일의 설정방법에 대해서 상세히 알아보도록 하자.


### Section 1: Global Environment

 전제환경설정 파트로 Section 1에서 설정하는 것들은 아파치 웹서버에
전반적인 영향을 미친다.

ServerType standalone

 서버의 구동방법으로는 standalone과 inetd방식이 있는데,  standalone
방식은 하나의 웹데몬(아파치서버)이 클라이언트의 접속을 모두 처리하는
방식으로 응답속도가 빠른 방법으로 주로 이방식을 사용한다. inetd 방식은
inetd라는 시스템의 /etc디렉토리 끝에 존재하는 inetd라는 슈퍼데몬이
클라이언트의 접속요구가 있을 때마다 웹서버를 구동하는 방식이다.
일반적으로 응답속도가 빠르고 효율적인 standalone으로 설정하여 사용한다.


ServerRoot "/usr/local/apache"

 아파치서버의 홈디렉토리를 지정하며 절대경로로 지정한다. 이후로 나오는
대부분의 패스들은 이 경로에 대한 상대경로로 지정이 된다. 예를 들어
환경설정파일, 에러로그파일등의 상대경로의 기준이 되는 위치이다.


LockFile logs/accept.lock

 아파치 컴파일시 USE_FCNTL_SERIALIZED_ACCEPT나
USE_FLOCK_SERIALIZED_ACCEPT으로 컴파일 했을 때 사용되는
LockFile의 경로지정시에 사용된다. 가급적 기본값으로 사용한다.


PidFile logs/httpd.pid

 PidFile 설정은 ServerType을 Standalone으로 설정했을때만 유효한
것으로 아파치 서버의 프로세스가 생성되어 있을 때 그 프로세서ID(PID)를
기록하는 파일을 지정한다.  당연히 아파치서버가 재시작되거나 과부하로
인해 PID가 바뀌게 될 경우에는 이 파일의 PID값도 바뀌게 된다.  즉
다시말해서 여기서 지정된 파일(httpd.pid)에 실행되고 있는 아파치서버의
프로세스번호(PID)값이 기록된다고 하면 정답이다. ServerRoot를 기준으로한
상대경로로 지정된다.  절대경로로 지정하려면 "/"로 시작하는 절대경로를
적어주면 된다.



ResourceConfig conf/srm.conf
AccessConfig conf/access.conf

 아파치 서버의 환경설정파일은 3개이au httpd.conf, srm.conf, access.conf
가 그것이다. 그러나 하나의 설정파일로 하는 것이 효율적이기 때문에
지금은 httpd.conf파일안에 3개의 파트(Section)로 나누어서 하나의
파일안에서 설정을 하고 있다. srm.conf와 access.conf파일의 내용은 현재
비어있는 상태이지만, 필요하다면 이 파일 내에도 설정을 할 수 있다.
아파치 서버가 실행이 될 때는 httpd.conf, srm.conf, access.conf 순으로
언제나 이 3개의 파일을 모두 읽고 난뒤에 실행이 되기 때문이다. 만약 이
두 개의 파일을 서버가 무시하도록 하려면 다음과 같이 하거나 "#"으로 붙여
두면 주석처리되어 무시된다.

ResourceConfig /dev/null
AccessConfig /dev/null


Timeout 300

 클라이언트의 요청에 의해 서버와 연결이 되었을 때 클라이언트와
서버간에 아무런 메시지가 발생하지 않았을 때 오류로 처리될 시간을
초단위로 설정한다. 초기값은 1200이며 보통은 300초로 지정을 한다.
네트웍의 속도가 나쁠수록 수치값은 높게 설정하는 것이 좋다.

KeepAlive On

 접속한 채로 특별한 요청없이 지속적인 연결을 허용할 것인지를 설정한다.
허용하지 않으려면 off

MaxKeepAliveRequests 100

 클라이언트가 접속된 시간동안 아파치서버에 요청할 수 있는 최대의
개수를 지정한다. 0을 지정하면 제한없음을 의미하며, 서버의 성능향상을
위하여 가능한 높은 값이 좋다.

KeepAliveTimeout 15

 아파치 서버는 같은 접속상태의 클라이언트에서 여기서 지정한 초만큼의
요청이 없었을 때 접속을 끊게 된다.

MinSpareServers 5
MaxSpareServers 10

 아파치 웹서버는 성능향상과 빠른 응답속도를 위해 유휴서버(현재
서비스대기 중인 프로세스)를 만들게 되는데 이 유휴서버의 개수는 시스템의
상황에 따라 달라지게 된다. 유휴서버가 MinSpareServers의 개수(5) 보다
적게되면 추가로 생성을 하게 되며 MaxSpareServers의 개수(10)보다 많게
되면 죽이게 된다. 즉, 유휴서버의 개수를 적절히 조절하기 위한 것이라
생각하면 된다.


StartServers 5  

 아파치 웹데몬이 구동될 때 자식프로세스를 몇 개로 할 것인가를
지정한다. 시작할 때 동시에 띄우게 될 웹데몬의 개수이다. 그러나 웹데몬이
구동되고 난 뒤엔 시스템의 상황(부하율등)에 따라 대부분 합리적인
개수만큼 동적으로 생성되었다가 죽기도 하므로 큰 의미를 가지는 것은
아니다.

MaxClients 150

 아파치웹서버에 접근할 수 있는 클라이언트의 최대갯수는 이 상한값으로
제한한다. 여기서 지정한 개수이상의 클라이언트의 요청이 생긴다면
아파치는 응답하지 않고 이 요청을 무시한다.  이를 제한하는 이유는
시스템의 자원을 아파치 웹서버가 무한정 차지하는 것을 방지하기 위한
것이다.

MaxRequestsPerChild 30

 아파치 웹서버의 자식프로세스들이 클라이언트의 요청 개수를 지정한다.
만약 자식프로세스가 이 값만큼의 클라이언트요청을 받았다면 이
자식프로세스는 자동으로 죽게된다. 이 값이 0으로 설정이 된다면
자식프로세스가 자동으로 죽는일은 없을 것이다. 그러나 0아닌 다른 값으로
설정함으로서 프로세스의 수를 적절히 조절하여 시스템의 부하조절과
자원낭비를 어느정도 방지 할 수 있다.

Listen 3000
Listen 12.34.56.78:80

 시스템의 기본값이외에 다른 IP Address와 포트에 대해서도 연결할 수
있도록 해 준다. 환경설정파일(httpd.conf) 맨뒤에 나오는 가상호스트(Virtual
Host)부분에서 설정되는 가상호스트를 설정하기 위해 필요하다.


BindAddress *

 서버가 응답할 수 있는 IP Address를 설정하는 것이다. 하나의 시스템에
있는 아파치웹서버 하나로 여러 웹서버처럼 관리하는 웹호스팅서비스등에서
많이 이용하는 것으로 여러 IP Address를 인식할 수 있게 한다. "*"으로
설정이 되었다면 모든  IP Address에 대해 응답할 수 있으며, IP Address를
지정한다면 지정한 IP Address에 대해서만 응답할 수 있게 된다.  여러개의
IP Address를 ISP로부터 할당받아서 웹호스팅서비스를 하고자 한다면
이부분에서 지정해 주면된다. 이 설정파일의 맨 뒷부분에 나오는
<VirtualHost>~</VirtualHost>부분의 IP bind 가상호스트부분에서 아파치
웹서버가 응답할 수 있도록 하려면 여기서 IP Address를 지정해 줘야 한다.

ExtendedStatus On

 server-status로 아파치웹서버의 상태를 상태를 모니터링 할 때
"자세한상태정보"기능을 제공할 것인지(On) 아닌지(Off)를 설정하는 것이다.

### Section 2: 'Main' server configuration

 Section 2에서 설정하는 항목들은 아파치의 주된서버가 사용할 값들을
지정한다. <VirtualHost>에 정의된 가상호스트들에서 지정하지 않는 것은
여기서 지정된 값이 기본값으로 적용된다. 또한 여기서 지정하는 값을 각
<VirtualHost>내에도 지정할 수 있으며 이경우엔 각<VirtualHost>내에서
지정한 값이 우선적용된다.

Port 80

 아파치웹서버의 기본포트를 지정한다. 특별하게 사용하는 것이 아니라면
80번으로 해둬야 한다. 사용가능한 포트는 0 ~ 65535이며 1024이하의
포트번호는 시스템에서 특별하게 예약되어 있으므로 80번 이외의 다른
포트를 사용하려면 1024이상의 포트번호를 지정해서 사용해야 할 것이다.
특별한 지정이 없다면 <VirtualHost>에 정의된 각각의 가상호스트들의
기본포트가 된다. 만약 <VirtualHost> 내에서 Port가 지정이 된다면 그
포트번호가 우선한다.

(특별히 PORT를 따로 지정해 줄 필요가 있을 때는 따로 지정해 주며,
이때는 웹서버로 접근할 때 반드시 따로지정한 PORT번호로 접근해야 한다.
예를들어 Port 1234로 지정했다면, 접근시 : http://www.domain.co.kr:1234
로 접속해야한다. 단, 80번은 default이므로 Port번호를 입력하지 않아도
도메인만으로 그냥 접근할 수 있다. 예: http://www.domain.co.kr )

User nobody
Group nobody

 아파치 웹데몬이 요청을 받았을 때 여기서 지정한 user와 group으로
응답을 하게된다. 이 설정은 ServerType이 Standalone방식이며, 아파치의
실행이 root권한으로 실행이 되었을 때 유효한 것이다. 많은
웹서버관리자들이 nobody로 설정을 해 두고 있으며, 만약 시스템에 nobody
user가 없다면 새로생성(useradd)을 해야 할 것이다. 단, root로 설정하는
것은 절대로 있어서는 안되며 nobody이외의 다른 시스템사용자 id로 지정을
한다면 정말 신중히 모든면(시스템 보안 및 자원사용등)에서 깊게 고려를
해봐야 한다.

ServerAdmin webmaster@www.domain.co.kr

 여기서 지정하는 email address는 웹문서 로딩에러등의 문제에서
클라이언트측으로 보내질 메일주소값이다. 대부분
웹서버관리자의 email address로 설정을 한다.

ServerName new.host.name

 클라이언트에게 보여주는 호스트이름을 지정한다. www를 쓰지않는
호스트에서 www를 쓰는 것처럼 보이게 할 수 있다. 예를 들어
bbs.manualand.co.kr을 www.manualand.co.kr로 지정해서 쓸 수 있다.
이곳에 IP Address를 적게 되면 클라이언트에는 Ip Address를 보여준다.

DocumentRoot "/usr/local/apache/htdocs"

 아파치 웹서버의 웹문서가 있는 경로를 지정한다. 예를 들어
"http://www.manualand.co.kr/index.html"의 초기 문서라면 이 초기문서의
절대 경로는 여기서 지정된 "/usr/local/apache/htdocs/index.html"이 된다.
경로의 맨 마지막에 "/"를 추가해서는 안된다. Alias를 사용하여 다른 위치를
지정할 수도 있다.

<Directory />
   Options FollowSymLinks
   AllowOverride None
</Directory>      
               

<Directory>에서 지정되는 값에 대한 옵션은 다음과 같은 의미를 가지고
있다.
       None : 일단 모든허용을 하지 않는다.
       All : 모든허용을 한다.
       Indexes :
       Includes :
       FollowSymlinks :
       ExeCGI :
       MultiViews :


UserDir public_html

 하나의 아파치 웹서버에서 여러 사용자의 홈페이지를 별도로 만들어
관리할 때 필요한 개별 가입자의 홈페이지 디렉토리이름이다. 예를 들어
sspark이란 계정가입자의홈페이지는 "http://manualand.co.kr/~sspark"라는
홈페이지를 가지고 있을 때 sspark의 계정에서 "public_html"이란
디렉토리가 홈디렉토리가 되어 이 디렉토리에 있는 초기문서 index.html을
불러서 보여주게 된다.

<Directory /home/*/public_html>
   AllowOverride FileInfo AuthConfig Limit
   Options MultiViews Indexes SymLinksIfOwnerMatch
IncludesNoExec
   <Limit GET POST OPTIONS PROPFIND>
       Order allow,deny
       Allow from all
   </Limit>
   <Limit PUT DELETE PATCH PROPPATCH MKCOL COPY
MOVE LOCK UNLOCK>
       Order deny,allow
       Deny from all
   </Limit>
</Directory>

계정사용자의 홈페이지(public_html)의 접근에 대한 옵션을 지정한 것이다.


DirectoryIndex index.html

 디렉토리만을 지정했을 경우에 그 디렉토리에서 찾게될 문서의 순서를
지정해 준다. 즉, 디렉토리 이름만을 지정하더라도 여기서 지정한
index.html을 찾아서 웹브라우즈에 보여준다. 여러개의 파일을 지정할 수
있으며, 이런 경우에는 순서대로 찾아서 보여준다. 예를 들어
"DirectoryIndex index.html index.htm"로 지정했다면 먼저 "index.html"을
찾아서 있다면 이 파일을 로딩하고, "index.html"이 없다면 "index.htm"을
찾아서 로딩해 준다.

AccessFileName .htaccess

 디렉토리별로 접근제어할 정보(ID, Password)를 담고 있는 파일을
지정한다. 디렉토리별로 인증을 거쳐서 접근할 수 있는 설정을 하기위한
것이다. 예를 든다면 어떤 홈페이지의 전부나 혹은 일부에로 접근하려고 할
때 ID, Password를 묻는 창이 뜨면서 맞게 입력한 경우에만 접근허용하는
것이다.  보안상의 이유로 이 파일의 이름을 다른 이름으로 바꾸로 싶다면
".htaccess"대신에 다름이름을 적어주면 된다.

<Files ~ "^\.ht">
   Order allow,deny
   Deny from all
</Files>

 바로위에서 설정한 파일(".htaccess")의 내용을 볼 수 없게 할 때 사용하는
옵션이다. 보안상의 이유로 이 옵션은 설정해 두는 것이 좋다. 만약 이
옵션을 주석처리해 둔다면 ".htaccess"파일에 대한 보안은 누구도 장담할 수
없을 것이다.


UseCanonicalName On


TypesConfig conf/mime.types

웹서버의 mime type을 지정한 파일을 지정한다. mime.types파일은 서버에
의해 리턴될 수 있는 파일명과 mime형식을 기술해 놓은 파일이다.

DefaultType text/plain

mime.types 파일에 정의 되어있지 않은 파일형식에 대한 요청을 받았을 때
알 수 없는 문서타입에 대하여 사용할 기본적인 mime 타입을 정해둔다.


HostnameLookups Off

 웹서버의 로그(access_log)를 지정하는 Format에서 "DNS Lookup"으로
지정하였을 때, domain으로 남길 것인가, IP Address로 남길 것인가를
지정한다. Default로 Off는 IP Address로 남기는 것이며, Domain으로 변경할
필요가 없으므로 on으로 설정한 것보다는 속도가 조금빠르다.on으로 하게
되면 IP address를 IP Domain으로 변환해야 하므로 속도가 조금 느릴 수
있다.

ErrorLog logs/error_log

 아파치 웹서버의 에러로그 기록파일을 지정한다.  참고할 사항은 맨
마지막에 설정하는 <VirtualHost>부분에서 각서버에 대한 에러파일을
지정해 두지 않으면 그에 대한 에러로그도 여기에 기록되며, 지정해 두게
되면 그에 해당하는 로그는 이 파일에 기록되지 않는다.

LogLevel warn

 바로위에서 설정한 에러로그 파일에 얼마나 자세하게 적을 것인지를
결정한다. 다음에 해당하는 순서대로 중요도가 정해진다. " debug → info →
notice → warn → error → crit → alert → emerg "

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\"
\"%{User-Agent}i\"" combind
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

 바로 아래에서 사용할 CustomLog에서 사용할 몇가지 로그형식의 별명을
정한 곳이다.
웹서버의 관리자나 서버관리자는 이 부분을 특히 유심히 봐둬야 한다.
웹서버의 로그를 어떤 식으로 남길 것인가를 결정하는 Format을 지정하는
곳이다. 원하는 정보를 지정해서 볼 수 있으므로, 관리자에게 필요한
Format으로 설정해야 하며, 또한 접속통계를 내기에 적당한 Format으로
설정해 둬야 한다.

CustomLog logs/access_log common

 위에서 정한 로그형식(여기선 common)대로 로그를 남기게 된다.
맨마지막에서 지정하는 <VirtualHost>부분에서도 아파치 1.3.9버전 부터는
CustomLog를 가상호스트별로 지정할수 있도록 CustomLog를 제공한다.
<VirtualHost>에서 CustomLog를 지정하지 않으면 여기서 지정한 형식대로
로그를 남기게 되며 <VirtualHost>부분에서 CustomLog를 지정했을
경우에는 여기서 지정한 로그형식은 무시된다.

#CustomLog logs/referer_log referer
#CustomLog logs/agent_log agent
#CustomLog logs/access_log combined

 위에서 지정한 4가지의 로그형식(combind, common, referer, agent)중에서
원하는 부분의 #(주석행)을 제거하면 지정된다.

ServerSignature On

 서버가 생성하는 문서(error documents, FTP directory listings,
mod_status and mod_info output etc., but not CGI generated documents)의
trailing footer line의 설정을 가능하게 한다.

Alias /icons/ "/usr/local/apache/icons/"

 필요한 만큼의 디렉토리 별칭을 만들어 쓸 수 있다. 사용하는 형식은
다음과 같다.
Alias fakename(가상이름) realname(진짜이름)

ScriptAlias /cgi-bin/ "/usr/local/apache/cgi-bin/"

 ScriptAlias는 서버스크립트를 포함한다. ScriptAlias는 실제디렉토리 안에
들어있는 문서를 서버에 의해 응용프로그램으로 취급되어 실행되는 것을
제외하고는 근본적으로 Aliases와 같다.


IndexOptions FancyIndexing

 IndexOPtions는 디렉토리목록을 표시할 때 사용할 옵션을 지정한다.
Standard는 표준적인 디렉토리를 나타내며, FancyIndexing은 좀더 예쁜
디렉토리목록을 표시해 준다.


 아래에서 지정하는 AddIcon으로 시작하는 설정은 바로위에서 설정한
디렉토리인덱싱 옵션을 FancyIndexing으로 한 경우에 해당하며 디렉토리
목록을 표시할 때 각 파일 확장자에 따라서 어떤 아이콘을 선택하여 보여줄
것인지를 지정한다.

AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip
AddIconByType (TXT,/icons/text.gif) text/*
AddIconByType (IMG,/icons/image2.gif) image/*
AddIconByType (SND,/icons/sound2.gif) audio/*
AddIconByType (VID,/icons/movie.gif) video/*

AddIcon /icons/binary.gif .bin .exe
AddIcon /icons/binhex.gif .hqx
AddIcon /icons/tar.gif .tar
AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv
AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip
AddIcon /icons/a.gif .ps .ai .eps
AddIcon /icons/layout.gif .html .shtml .htm .pdf
AddIcon /icons/text.gif .txt
AddIcon /icons/c.gif .c
AddIcon /icons/p.gif .pl .py
AddIcon /icons/f.gif .for
AddIcon /icons/dvi.gif .dvi
AddIcon /icons/uuencoded.gif .uu
AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl
AddIcon /icons/tex.gif .tex
AddIcon /icons/bomb.gif core

AddIcon /icons/back.gif ..
AddIcon /icons/hand.right.gif README
AddIcon /icons/folder.gif ^^DIRECTORY^^
AddIcon /icons/blank.gif ^^BLANKICON^^


DefaultIcon /icons/unknown.gif

 여기서 지정한 확장가가 아닌 경우에 여기서 지정한 기본아이콘으로
보여준다.

AddDescription "GZIP compressed document" .gz
AddDescription "tar archive" .tar
AddDescription "GZIP compressed tar archive" .tgz

 AddDescription은 서버가 생성한 인덱스의 파일 뒤에 간단한 설명을
표시할 때 사용한다. 이 설정은 IndexOptions가 FancyIndexing으로
설정되었을때만 표시되며, 설정형식은 다음과 같다.
형식 : AddDescription "표시할 설명" 파일확장자

ReadmeName README

 ReadmeName은 디렉토리목록표시 뒤에 붙여서 보여줄 README파일의
이름을 지정한다.(일종의 꼬릿말)

HeaderName HEADER

 HeaderName은 디렉토리목록표시 앞에 붙여질 파일의 이름을 지정한다.
(일종의 머릿말)

IndexIgnore .??* *~ *# HEADER* README* RCS CVS *,v *,t

 디렉토리목록을 인덱싱할 때 제외할 파일명을 지정한다. 즉 디렉토리
목록에 포함하지 않을 파일을 지정한다. 쉘스타일의 와일드카드(*, ?)가
허용된다.

AddEncoding x-compress Z
AddEncoding x-gzip gz tgz

 AddEncoding은 특정브라우즈(Mosaic/X 2.1+)에서 받고있는 중에 정보에
대한 압축해제를 할 수 있도록한다. 단 모든 웹브라우즈에서 이 기능을
제공하는 것은 아니다.

AddLanguage en .en
AddLanguage fr .fr
AddLanguage de .de
AddLanguage da .da
AddLanguage el .el
AddLanguage it .it

 AddLanguage는 문서의 언어를 지정하게 한다.

LanguagePriority en fr de

 언어의 우선순위를 내림차순으로 지정한다.

AddType application/x-httpd-php3 .php3
AddType application/x-httpd-php3-source .phps
AddType application/x-tar .tgz

 AddType은 mime.types의 실제 편집없이도 mime을 설정할 수 있다.

AddHandler cgi-script .cgi

 AddHandler는 파일확장자를 처리기(Handler)에 매핑(연결)시켜주게 된다.

AddType text/html .shtml
AddHandler server-parsed  .shtml

 SSI(Server Side Include)문서를 인식하게 하기위한 설정이다. SSI코드가
들어가 있는 문서는 확장자가 *.shtml이다. 시스템의 날짜와 카운터등
CGI프로그램을 하지 않아도 HTML문서에서 단 몇줄로 CGI의 효과를 낼 수
있는 SSI기능을 인식하게끔 하는 설정이다. "7장. 아파치와 SSI"편에서 자세히
설명되어 있다.


#Format: Action media/type /cgi-script/location
#Format: Action handler-name /cgi-script/location

 Action은 매칭되는 파일이 호출될때마다 스크립트를 실행시킬 수 있도록
미디어 타입을 정의한다.

MetaDir .web

 MetaDir은 아파치가 찾을 메타정보파일들의 디렉토리이름을 지정한다. 이
파일들은 문서를 전송할 때 포함되는 HTTP 헤더정보가 포함되어 있다.

MetaSuffix .meta

 MetaSuffix는 메타정보를 포함하고 있는 접미어의 이름을 지정한다.


에러발생시 응답을 정의할 수 있는 방법을 3가지 나타내고 있다.

   1) 일반적인 텍스트

ErrorDocument 500 "The server made a boo boo.

   2) 지역적인 방향전환

ErrorDocument 404 /missing.html
ErrorDocument 404 /cgi-bin/missing_handler.pl

   3) 외부 방향전환

ErrorDocument 402
http://some.other_server.com/subscription_info.html


 다음의 BrowserMatch는 keepalives기능을 쓰지못하게 하며 HTTP
헤드방식을 설정한다.

BrowserMatch "Mozilla/2" nokeepalive

 이 설정은 Netscape 2.x 또는 이를 따르는 브라우즈에 대하여 KeepAlive
기능을 쓰지 못하게한다.

BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0
force-response-1.0

 이 설정은 잘못구현된 HTTP/1.1과 301또는 302반응에 대하여
KeepAlive를 적절히 제공하지 못하는 마이크로소프트 인터넷익스플로러
4.0b2d에 관한 것이다.

BrowserMatch "RealPlayer 4\.0" force-response-1.0
BrowserMatch "Java/1\.0" force-response-1.0
BrowserMatch "JDK/1\.0" force-response-1.0

 위의 3가지 설정은 기본적인 1.1반응도 처리하지 못하며 HTTP/1.0 스팩을
제한하고 있는 브라우즈에 대하여 HTTP/1.1반응을 하지 못하게 한 것이다.

<Location /server-status>
   SetHandler server-status
   Order deny,allow
   Deny from all
   Allow from www.manualand.co.kr
</Location>

 서버의 상태를 점검할 수 있게하는 설정이다. 이는
"http://www.manualand.co.kr/server-status"와 같은 형식으로 서버의 상태를
점검할 수 있다. "6장. 아파치서버 모니터링"편에서 자세히 설명되어 있다.
여기서 지정한 "SetHandler server-status"의 설정으로 인해 서버
모니터링을 할 수 있는 것이다.

<Location /server-info>
   SetHandler server-info
   Order deny,allow
   Deny from all
   Allow from www.manualand.co.kr
</Location>

 이설정을 위해서는 mod_info.c가 적재되어야 하며, 이는
"http://www.manualand.co.kr/server-info"와 같은 방식으로 서버의 정보를
볼 수 있다. 위에서 설정한 server-status와 함께 실행중인 웹서버의
상태점검을 위한 것이다.

<Location /cgi-bin/phf*>
   Deny from all
   ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
</Location>

 아파치 1.1이전 버전의 오래된 버그에 대한 악용이 있을시에는 지정한곳
(http://phf.apache.org/phf_abuse_log.cgi) 으로 방향을 전환시킨다.


<IfModule mod_proxy.c>
ProxyRequests On

 아파치 웹서버를 Proxy서버로 사용할 때 on을 해줘야 한다. 즉  
프락시서버 지시자로서 프락시서버를 on 시킨다.

<Directory proxy:*>
   Order deny,allow
   Deny from all
   Allow from .your_domain.com
</Directory>

ProxyVia On

 HTTP/1.1 "Via:"헤드처리를 활성화시킬 것인지 비활성화 시킬것인지를
지정한다. Off, On, Full, Block중 하나가 올 수 있으며 Full은 서버버전을
포함하며, Block은 나가는 모든 것에 대해 Via:헤더를 제거한다.

CacheRoot "/usr/local/apache/proxy"
CacheSize 5
CacheGcInterval 4
CacheMaxExpire 24
CacheLastModifiedFactor 0.1
CacheDefaultExpire 1
NoCache a_domain.com another_domain.edu joes.garage_sale.com

 이 설정은 캐시기능을 활성화 하기 위한 것이다.

### Section 3: 가상호스트 설정

 여러분의 시스템에서 여러개의 도메인이나 호스트네임을 설정하여
관리하고자 한다면 <VirtualHost>부분을 설정해 줘야 한다. 가상호스트에
대한 정보는 http://www.apache.org/docs/vhosts/를 참조해 보면 좀더
자세한 정보를 얻을 수 있다.  '-S'옵션을 사용함으로써 가상호스트의 설정에
대한 점검을 할 수 있다.  name-based 가상호스트를 사용하길 원한다면
적어도 한 개이상의 IP Address를 정의할 필요가 있다. "4-2절의 내용"과
"10장.웹호스팅 서비스를 위한 가상호스트"편에서 자세히 설명되어 있다.

NameVirtualHost 12.34.56.78:80
NameVirtualHost 12.34.56.78

<VirtualHost www.manualand.co.kr>
   ServerAdmin webmaster@manualand.co.kr
   DocumentRoot /home/sspark/public_html
   ServerName www.manualand.co.kr
   ErrorLog /home/sspark/public_html/aw/error_log
   CustomLog /home/sspark/public_html/aw/access_log common
</VirtualHost>

       ServerAdmin은 해당서버의 관리자 전자우편이며,
       DocumemtRoot는 해당서버의 홈디렉토리이며,
       ServerName은 해당서버의 도메인이며,
       ErrorLog는 해당서버의 에러파일 위치이며
       CustomLog는 로그파일위치와 포맷을 지정한 것이다.

<VirtualHost _default_:*>
</VirtualHost>

 Default 가상호스트 설정으로 위에서 설정되지 않은 다른 모든 호스트에
대해서 응답을 하고자 할 경우설정해 준다.

2006/09/11 13:37 2006/09/11 13:37
출처 블로그 > xinfra님의 블로그
원본 http://blog.naver.com/xinfra/80008688603
/
인터넷 검색 사이트에서 특정 단어를 입력했을 때 검색 순위를 인위적으로 올려주는 업체들이 성행하고 있다.

이러한 기법은 불법이 아니고 워낙 교묘한 방법을 동원하기 때문에 포털 사이트들도 속수무책이다. 하지만 돈을 주고 인기 순위를 올리는 사이트가 늘어나면서 반대로 정상적인 사이트가 순위가 떨어져 피해를 입는 사례가 많아지고 있다.

아이뉴스24 * 2003/4/5 기사 중에서

검색결과 첫 페이지가 중요한 홍보 방법으로 알려지면서 소위 '상위등록'에 대한 관심이 높아지고 있다. 그에 따른 오해와 부작용도 함께.

검색결과 상위에 올라가려는 이런 노력을 한 쪽에서는 검색순위 조작이라고 비난을 하고, 다른 쪽에서는 정당한 마케팅 방법이라고 단호하다. 어느 쪽 말이 맞는 걸까?

결론부터 말하자. 검색결과 상위에 올라가려는 노력은 비난 받을 일이 아니다. 다만 적절한 선을 무시하는게 문제일 뿐이다. 스팸메일은 문제지만 이메일을 이용한 홍보 자체는 비난받을 일이 아닌 것 처럼.

포탈에 돈내고 광고 한 것은 괜찮고, 검색결과에 올라가려고 HTML 문서를 잘 꾸미고 키워드를 배치한 것은 비난 받아야 한다면 어딘가 굉장히 어색하다.

  • 홈페이지를 만드는 이유는 다른 사람에게 보여주기 위해서다.
  • 사람들은 검색엔진으로 필요한 정보(홈페이지)를 찾는다.
  • 그래서 홈페이지를 만들 때 검색엔진을 염두에 두고 만든다.
  • 이런 노력 자체에는 아무런 문제가 없다. 다만 일부 업체들이 마술사처럼 거짓말을 하거나 적절한 선을 넘는 것이 문제다.

    인기 키워드에 대한 집착만 버린다면 상위등록이 그리 어렵지 않다고 말하고 싶지만, 어떤 경우에는 부득이 전문업체에 상위등록 대행을 맡겨야 하는 경우가 있다.

    그동안 "믿을 만한 상위등록 업체"를 알려달라는 질문을 많이 받았다. 특정 업체를 지목할 수는 없다. 대신 좋은 업체를 고를 몇 가지 기준을 함께 생각해보자.

    첫째, '상위등록'이 아닌 '마케팅'을 말하는 업체

    엄밀히 말해서 상위등록과 검색엔진 마케팅은 다르다. 상위등록은 어떤 키워드에서든 높이 올라가면 그만이지만 마케팅은 고객을 부르고 상품을 파는 활동이다.

    검색결과에 먼저 나오는 것은 마케팅 전략의 한 부분일 뿐이다. 적절한 키워드 선정, 홈페이지 구성, 효과분석, 고객 흐름의 설계와 관리 등 종합적인 노력이 필요하다.

    검색엔진 마케팅을 하겠다면 조회수만 보고 엉뚱한 키워드를 공략하는 일은 무의미하다. 1000 트래픽(Traffic) 보다는 10명의 고객이 나은 법이다.

    검색순위 조작 능력을 자랑하는 업체보다는 마케팅 전략을 말하는 업체를 고르자.

    둘째, 고객 방문 그 이후를 말하는 업체

    고객은 움직인다. 키워드 검색을 하고, 사이트를 방문하고, 활동을 하고, 다시 찾아온다. 검색엔진 마케팅은 이 모든 고객 흐름을 염두에 두어야 한다.

    공략 키워드 선택에서 메뉴 이름까지 하나하나 연결 시켜야 한다.

    셋째, 합리적인 가격을 말하는 업체

    누구나 싼 가격에 흔들리기 마련이다. 그러나 마케팅을 할인 판매할 수는 없는 것이다. 검색엔진 마케팅은 저렴하지만 그래도 돈이 들어간다. 어떤 경우에는 스폰서링크 같은 광고를 해야하는 경우도 있다.

    타겟별로, 예산과 전략에 따라 가격은 다를 수밖에 없다. 때로는 유료 광고를 해야하는 경우도 있다. 공장에서 기계를 찍듯이 가격을 말하는 업체 보다는 합리적인 가격을 제시하는 업체를 찾자. 마술쇼를 하듯이 터무늬없는 가격을 부르는 곳도 마찬가지로 다시 살펴보자.

    넷째, 효과분석을 철저히 하는 업체

    검색결과 상위에 올라갔다고? 그게 그렇게 대단할까?

    • 트래픽은 얼마나 늘었는가?
    • 고객은 얼마나 늘었는가?
    • 매출은 얼마나 늘었는가?
    • 늘지 않는다면 그 이유는 무엇이고 어떻게 개선할 것인가?

    ROI(투자수익률)를 말할 수 없다면 투자는 의미가 없다. 로그분석에 효과분석까지 철저히 짚어주는 업체를 찾아보자.

    다섯째, 검색엔진 구석구석을 이용하는 업체

    통합 검색결과에 먼저 나오려면 디렉토리 상위등록이 중요하다. 그러나 디렉토리는 한계가 뻔한 곳이다. 먼저 나온다는 것 빼고는 차별화도 불가능하다. 자유로운 마케팅이 불가능하다. 웹페이지 검색, 스폰서링크 등 검색엔진 각 검색결과를 총체적으로 이용하는 전략이 필요하다.

    여섯째, 미디어 믹스(또는 마케팅 믹스) 전략을 말하는 업체

    당연한 말이지만 인터넷 마케팅에는 검색엔진만 있는 것이 아니다. 이메일, 입소문 등 다른 매체 전략과의 연계가 있어야 더 큰 효과를 발휘한다. 때로는 오프라인과의 연계도 필요하다.

    종합적인 마케팅 대행사를 찾으라는 의미는 아니다. 이런 총체적인 시각으로 전략을 구사할 줄 아는 곳을 찾으라는 의미다.

    일곱째, 장기 전략을 말하는 업체

    디렉토리 빠른 등록은 길어야 일주일이면 끝난다. 상위등록이 바로 될 수도 있다. 그러나 마케팅은 속전속결일 수 없다. 단기간에 이룰 수 있는 건 어떤 키워드에서 높이 올라간다는 사실 뿐이다.

    제대로 검색엔진 마케팅을 하려면 6개월 내외의 장기전 준비를 해야한다. 이런 정도 기간의 단계별 전략과 경험을 제시하는 업체를 찾아야 한다.

    ◆◇◆◇◆◇

    이런 업체를 찾기가 힘든가? 그렇다면 만나는 상위등록 업체에게 요구하라. 이제까지는 검색결과 첫 페이지 올리기로 충분했는지 모른다. 그러나 이제는 더 큰 효과로 더 큰 시장을 만들어야 한다.

    일부 업체들은 말한다. "제대로 하고 싶지만 고객들이 상위등록 요구만해서 마케팅 이야기는 엄두도 못내요."

    시장을 제대로 키우는 책임은 소비자에게도 있다. 업체를 비교하자. 없다면 요구하자.

    세상엔 많은 검색엔진이 있다. 사람들다마 각자의 성향에 따라 즐겨 사용하는 검색엔진도 다 다르다. 그 가운데서 유독 전세계적으로 많은 매니아층을 끌어 들이는 구글 검색엔진은 여러 가지 신선한 아이디어로 항상 매니아층을 흥분시키곤 했다. 비록 일반 사용자들이 야후, 네이버, 엠파스, 한미르 등을 더 많이 사용한다고는 하지만(구글의 사이트 순위), 어느 정도 검색 엔진에 조예가 있는 사람들에겐 언제나 구글은 동경심의 대상이었다.

    이러다보니 구글과 관련한 사이트들도 전세계적으로 상당히 많이 생겨났다. 이들 중에는 단순히 구글을 사랑하는 사람들이 만든 팬사이트 형식의 사이트부터, 구글 기술과 관련한 사이트, 구글 검색 결과의 상위에 노출되는 방법을 알려주는 사이트 등 여러 사이트들이 있다. 그만큼 애정을 가진 사람들이 많다는 것이다.

    오늘은 이런 사이트들 중 흥미있는 사이트를 하나 소개하도록 하겠다.

    사이트를 운영하는 사람치고 검색엔진 결과 리스트의 상위에 노출되고 싶지 않은 사람은 없을 것이다. 오늘 살펴 볼 사이트는 구글의 검색 스파이더가 사이트를 어떻게 해석하는지 잘 보여주는 사이트이다.

    푸들 프리딕터(Poodle Predictor)란 사이트인데, 이 사이트는 구글 검색엔진이 각각의 사이트를 어떻게 해석하는지 시뮬레이션 해주는 사이트이다.

    이 사이트에 가서 korea.internet.com으로 검색한 결과는 다음과 같다.

    이 검색 결과의 첫 번째 항목은 구글 검색 결과에 어떻게 나타날지를 시뮬레이션 해준 것이고, 그 아래 쪽 결과는 검색엔진이 수집한 해당 페이지의 모든 링크를 보여준 것이다.

    이번엔 구글 검색엔진에서 korea.internet.com으로 검색한 결과를 한 번 보자.

    푸들 프리딕터에서 검색을 한 경우와 구글에서 검색을 한 경우 검색 결과에 나타날 요약문이 거의 동일함을 알 수 있을 것이다.

    푸들 프리딕터 이럴 때 유용하다

    하지만 이 요약문이 서로 다른 경우도 많이 있다. 이것은 푸들 프리딕터는 해당 페이지의 실시간 결과를 보여주는 것이고, 구글은 과거에 수집한 내용을 기반으로 결과를 보여주기 때문이다.

    이것은 무엇을 의미하나? 그렇다. 만일 검색엔진에 나타날 결과를 예측하여 페이지를 수정하였는데 막상 구글 검색엔진에 반영되는데 걸리는 시간은 1달 이상 걸릴 수 있다. 그런데 1달이 지나고 나서 결과를 보니 예상했던 것과 다르다면 얼마나 난처한 일일까? 다시 결과를 바로 잡기 위해 1달을 더 기다린다? 이럴 때 푸들 프리딕터의 도움을 받을 수 있다. 푸들 프리딕터는 현재 페이지에 대한 실시간 결과를 시뮬레이션 해서 보여주기 때문에 향후 구글 검색엔진 결과에 어떻게 나타날지를 쉽게 예측할 수 있게 해준다.

    푸들 프리딕터의 사이트 바라보기

    앞서 푸들 프리딕터는 구글 검색엔진이 각각의 사이트를 어떻게 해석하는지 시뮬레이션 해준다고 하였는데, 과연 어떤식으로 시뮬레이션 해주는 것일까?

    아래 그림처럼 푸들 프리딕터의 결과 요약문 아래 있는 "Diagnostics View" 메뉴를 클릭해 보기 바란다.

    이 메뉴의 결과를 보면 검색엔진 스파이더가 어떻게 페이지를 해석하는지 잘 알려준다. 즉, 스파이더 입장에서 페이지 내용중 관심 없는 항목들은 과감히 생략하여 보여주기 때문에, 즉, 스파이더가 관심있는 항목들만 정리하여 결과를 보여주기 때문에, 검색엔진 마케팅을 위해 페이지를 어떤 식으로 수정하면 좋을지 시뮬레이션 하는데 많은 도움을 얻을 수 있을 것이다. 이 결과들을 보면서 자신의 홈페이지를 검색엔진 스파이더가 관심을 갖도록 바꿔보는 것은 꽤 흥미있는 일이 될 것이다.


    /

    "검색엔진들이 지식 검색에 열을 올리고 있다. 검색엔진의 미래와 어떤 관련이 있을까?"

    최근에 받았던 질문이다. 아주 오랜만에 포탈 검색 서비스에 변화가 생겼다. 반가운 일이다. 변화가 생기고 경쟁이 생겨야 사용자가 행복하고 소비자가 즐겁다. 그리고 산업과 기술도 발전한다.

    최근 검색엔진 변화에 불을 당긴 것은 네이버의 지식인(지식iN) 서비스(이하 지식인)이다. 네티즌끼리 질문과 답을 주고 받는 서비스로 네이버 검색결과에서 먼저 나타난다.

    네이버의 중고차 검색 결과

    ▲ 네이버의 '중고차' 검색 결과 처음

    2002년 10월에 시작해서 5개월만에 인기있는 서비스로 자리잡았다.

    • 하루 이용자 수 650만명에 40만 건 이상의 자료가 구축되었다.
      (네이버 발표)
    • 네이버 사용자 100명중 24명이 지식인을 이용한다.
      (인터넷메트릭스 2월말 조사)
    • 일반 검색에 비해서 두배 이상의 체류 시간을 보인다.
      (인터넷메트릭스 2월말 조사)

    이제 네이버 검색의 슬로건은 '지식까지 찾아주는 검색'이다.

    다른 포탈들의 움직임도 심상치 않다. 엠파스는 지식인의 원조격인 디비딕(DBDIC)을 인수해서 '지식거래소'라는 이름으로 통합을 추진하고 있다. 세이클럽은 세이테마(SayTheme)라는 서비스를 이미 시작한 상태이다. 다른 포탈도 비슷한 서비스를 한창 준비하고 있다.

    지식인 서비스 자체는 성공적이라고 할 수 있다. 화제로 떠오르고 사람들이 모이니 말이다. 그럼 아까 받았던 질문으로 넘어가 보자.

    "지식 검색을 검색의 미래로 볼 수 있을까?"

    이 바람을 일으킨 네이버 지식인을 검색의 관점에서 살펴보는 것이 답변의 출발이 될 것 같다.

    ■ 지식인이 성공한 이유

    잘 알다시피 지식인은 이 분야 최초의 서비스가 아니다. 2000년 디비딕이란 서비스가 이미 화제가 되었다. 그런데 요즘 새삼스럽게 네이버의 지식인이 인기를 얻는 이유는 무얼까? 서비스 자체의 장점 말고 바깥쪽의 관점, 즉 검색의 관점에서 살펴보자.

    1. 검색엔진과 연결되었기 때문이다.

    기존의 디비딕은 독립 서비스였다. 그러나 네이버의 지식인은 검색과 연결되어 있다. 검색과 연결되어 있지 않았다면 오늘의 성공은 없었을 것이다. 'SM5'로 검색한 사용자가 'SM5 랑 옵티마랑 둘 중에 어느거 살까여?'라는 질문을 발견했기 때문에 지식인이 성공하는 것이다.

    포탈은 수십, 수백개의 서비스로 이루어져 있다. 그동안 브랜드는 하나였으나 제각각 움직이고 있었다.

    네이버는 지식인을 별도의 서비스로 놔두지 않고, 검색이라는 끈으로 연결했다. 사실 포털이 그렇게도 되고 싶은 미디어(Media)의 열쇠 하나가 검색엔진이다. 미디어는 메시지이고, 메시지는 기본적으로 연결 고리가 필요하다.

    포털의 검색은 여러 서비스 중의 하나가 아니다. 검색은 서 말의 구슬을 꿰어 보배로 만드는 힘이다. 때로는 포탈 그 자체이다.

    2. 웹페이지 검색 정보가 부족하기 때문이다.

    웹페이지 검색의 정보가 부족한 것도 지식인 활성화에 도움이 되었다. 우리나라는 영어권에 비해 웹 정보가 부족한 편이다. 수량에서도 차이가 나지만 내용에 있어서도 분야별 편차가 다소 심하다. 작년 모 언론사와 함께 우리나라 개인 홈페이지를 조사할 기회가 있었다. 엔터테인먼트(영화, 게임 등)와 컴퓨터 분야는 다양했으나 정치, 경제 분야 같은 경우는 홈페이지를 찾기가 쉽지 않았다.

    안타깝게도 우리나라는 정보 소비자는 많지만 아직 상대적으로 정보 생산자는 적은 편이다. 이런 정보 소비자 중심의 구조는 웹페이지 정보 부족으로 곧바로 연결된다.

    또 하나 국내 검색엔진의 웹페이지(웹문서) 검색에 대한 게으름도 한 몫한다. 국내 검색엔진들은 웹페이지에 신경을 덜 쓰는 경향이 있다. 업데이트 주기, 스파이더의 개선 등 여러 곳에 아쉬움이 있다.

    웹페이지가 늘어나고 복잡해질수록 검색엔진도 함께 발전해야 한다. 국내 웹페이지 검색엔진 시장이 워낙 작기 때문에 개선을 위해 큰 비용을 계속 들이는 것이 쉽지는 않을 것이다. 그러나 운영과 관리도 소홀하다면 이야기는 다르다.

    통합검색과 테마검색(혹은 컨텐츠 검색)이라는 이름으로 서퍼들의 편집 부분에 노력을 기울이는 것도 중요하다. 그러나 웹페이지 검색을 사용하는 사람 역시 적지 않다. 이 둘은 서로 상호보완적인 영역이지 어느 한쪽을 완전히 대신할 수가 없다.

    3. 정리된 지식을 찾을 수 있는 행운이 있다.

    얼마전 진심반 시험반으로 해외 리조트(resort) 여행에 관한 질문을 올린 적이 있다. 질문을 올린지 하루만에 2건의 답변이 올라왔고 그 중 하나는 제법 만족스러운 것이었다. 그리고 "때가 어느 때인데 해외여행에 외화를 낭비하느냐"는 따끔한 충고도 덤으로 얻을 수 있었다.

    로봇에게 묻든 사람에게 묻든 우리가 원하는 것은 답을 얻는 것이다. 자동 로봇이 찾아온 결과는 대개 생자료(raw data)인 경우가 많기 때문에 그것을 비교분석하는 것은 사용자의 몫이다. 그러나 지식인의 검색결과는 완결된 답변의 형태로 돌아올 가능성이 상대적으로 높다.

    필자가 이것을 행운이라고 표현했다. 답변이 돌아올 것이라는 보장도, 그 답변이 정확할 것이라는 보장이 없기 때문이다.(이에 대해서는 뒤에서 더 다루기로