짧았던 설연휴가 끝나고...

너무 푹 잤다..
시간 정말 아깝다..
알고리즘 소스 코드 짜는것도 4장을 훑어보니 수십개나 되는 알고리즘을 어떻게 수요일까지 하리오..
거의 현실 도피하다시피 하루종일 잤다..
덕분에 부담감 100% 상승...
아.. 교수님께 면목이 없구나.. OTL

String문자열을 Char문자열로 변환하는 방법

String 클래스의 toCharArray()메소드를 이용하시면 됩니다.

간단한 확인 코드는 다음과 같습니다.

test.java

public class test
{
 public static void main(String[] args)
 {
  String str = "test";
  char[] charArray = str.toCharArray(); //Char[]로 변환

        System.out.println("intput Value : "+str); //입력 String 출력
  for(int i = 0 ; i < str.length() ; i++){
   System.out.println("Char["+i+"] = "+charArray[i]); //변환된 Char 출력
  }
 }
}

2차 과제 - 올해 관심있는 트렌드 주제 선정 발표

10분 발표...
뭘 정할까... 고민되네...

1. 클라우드 컴퓨팅
2. 넷북
3. ?

2009년 트렌드 모두 보기

=더 자세한 트렌드 기사=

클라우드 컴퓨팅 보기...

<2009 IT 트렌드 29>16. 클라우드 컴퓨팅

제 2의 디지털 시대 이끈다

컴퓨팅 업계의 대변혁이 예고된다. 그동안의 PC는 잊어도 좋다. 이제 자신의 PC에 워드나 엑셀 등을 설치하지 않고도 필요할 때마다 컴퓨팅 자원이 할당돼 작업을 실행할 수 있게 된다. 바로 새로운 컴퓨팅 패러다임인 클라우드 컴퓨팅이 이를 가능케한다. 웹2.0을 뛰어넘는 뜨거운 키워드로 등장한 클라우드 컴퓨팅은 성숙된 가상화 기술을 기반으로 일반 PC 환경에서부터 기업들의 데이터 센터까지 영역을 확장하고 있다. 특히 구글, IBM, 마이크로소프트(MS) 등이 본격적인 준비를 마치고 시장 개화에 나섬에 따라 시장이 보다 활성화될 것으로 예상된다. 성현희 기자 ssung@ittoday.co.kr “웹 3.0의 진전은 클라우드 컴퓨팅이 중심이 될 것이다” - 에릭 슈미츠 구글 CEO “제2의 디지털시대가 다가오고 있다. MS 플랫폼이 클라우드 컴퓨팅 혁명의 중심이 될 것이다” - 빌 게이츠 전 MS 회장 컴퓨팅 기술이 해를 거듭하면서 진화하고 있는 가운데 차세대 컴퓨팅 패러다임으로 클라우드 컴퓨팅(Cloud Computing)이 지목되고 있다. 특히 가트너가 선정한 2009년 10대 전략기술에 두 번째로 선정되면서 더욱 관심이 높아지고 있으며, IBM, MS, SAP, 오라클 등 최대 IT업체들도 클라우드 컴퓨팅에 막대한 투자를 시작했다. 특히 최근 마이크로소프트가 클라우드 컴퓨팅 운영체제인 ’윈도 애저(Azure)’를 발표하자마자 프로세서 업체인 AMD가 애저 운영체제를 지원하는 최적으로 프로세서로 쿼드코어 AMD 옵테론을 발빠르게 소개하는 등 잇따라 이슈를 낳으며 시장을 달구고 있다. 국내 시장 분위기도 해외시장과 별반 다르지 않다. 새로운 컴퓨팅 패러다임에 따른 변화에 대한 기대감와 함께 관련 업체들이 새로운 비즈니스 기회 창출에 주시하고 있다. 또 최근 1~2년 사이에 다양한 협단체에서도 클라우드 컴퓨팅 관련 세미나를 여러번 개최했다. 오는 12월에는 클라우드 컴퓨팅의 기술 활성화와 정책 방안을 마련하기 위한 한국클라우드컴퓨팅협의회도 출범한다. 뿐만 아니라 ETRI를 비롯해 LG CNS, KT(비즈메카) 등도 클라우드 컴퓨팅이라는 새로운 시장 대응을 위한 준비로 분주하다. 한국마이크로소프트 개발자 및 플랫폼 사업총괄 신혁석 부장은 "클라우드 컴퓨팅으로 인해 새로운 혁신이 오고 있다. 지금까지 소프트웨어 중심적으로 컴퓨팅이 발전해 왔다면 이제는 서비스적으로도 변화가 일어나고 있다는 것을 보여주는 것"이라고 설명했다. 클라우드 컴퓨팅, 이미 생활 속에 스며들었다 클라우드 컴퓨팅은 아직 초기 도입기 시장인 만큼 국내에서는 정확한 범위와 정의가 내려지지 않은 상황이다. 때문에 여러 의미들과 혼동해서 사용하는 경우가 종종 있다. 온라인 백과사전 위키피디아에 따르면 클라우드 컴퓨팅에서 클라우드(Cloud, 구름)는 인터넷 기반이라는 의미다. 클라우드는 컴퓨터 네트워크 구성도에서 인터넷을 구름으로 표현하는데서 나온 것으로, 숨겨진 복잡한 인프라 구조를 의미하고 컴퓨팅은 컴퓨터 기술을 사용한다는 뜻이다. 시장 조사 기관인 가트너는 클라우드 컴퓨팅을 ’인터넷 기술을 활용해 다수의 고객들에게 높은 수준의 확장성을 가진 IT자원들을 ’서비스’로 제공하는 컴퓨팅’으로 설명한다. 다시말하면 기업이 애플리케이션을 개발하거나 서비스할 때 서버나 스토리지 등 컴퓨팅 자원 등을 자체적으로 보유하기보다 이 같은 자원을 갖고 있는 클라우드 컴퓨팅 플랫폼 제공자를 통해 운용하는 것을 의미한다. 즉, ’인터넷을 통한 IT 자원의 온디맨드 아웃소싱 서비스’로 클라우드 컴퓨팅을 정의내릴 수 있다. 클라우딩 컴퓨팅은 기존의 씬 클라이언트와도 유사한 개념이지만 단말기의 속도나 크기에 제한없이 인터넷 접속만 가능하면 고성능 기기가 아니어도 원격으로 쉽게 업무를 수행할 수 있다. 이 외에도 클라우드 컴퓨팅은 기존 시장에서 많이 사용되던 그리드 컴퓨팅과 유틸리티 컴퓨팅, SaaS(서비스로서의 소프트웨어) 등과 혼용되고 있다. 클라우드 컴퓨팅은 기술적으로는 그리드의 분산 컴퓨팅을, 과금모형으로는 유틸리티 컴퓨팅을 채택한 컴퓨팅 개념으로 이해하면 된다. 또한 SaaS와의 관계는 클라우드 컴퓨팅이 보다 더 큰 개념으로, SaaS를 포함하는 광범위한 IT자원에 대한 아웃소싱 모형이라 할 수 있다. 클라우드 컴퓨팅과 기존 컴퓨팅 개념들과의 차이 주요 개념 클라우드 컴퓨팅과의 관계 Grid Computing 높은 컴퓨팅 리소스를 필요로 하는 작업의 수행을 위해 인터넷 상의 분산된 다양한 시스템과 자원들을 공유하여 가상의 슈퍼컴퓨터와 같이 활용하는 방식 (분산 컴퓨팅 아키텍쳐) Grid방식의 분산 컴퓨팅과 Utility개념의 과금모형을 혼합한 컴퓨팅 방식 Utility Computing 컴퓨팅 리소스를 구매하거나 소유하지 않고, 가스, 전기등과 같이 유틸리티로 필요할 때 마다 사용하는 방식(사용량 기반 과금모형) Server Based Computing 서버에 애플리케이션과 데이터를 두고 필요할 때마다 접속해서 사용하는 방식 (클라이언트는 입.출만 처리. 모든 작업은 100% 서버가 처리-Thin Client 방식) 클라우드 컴퓨팅은 가상화된 분산컴퓨팅에, SBC는 특정 기업의 서버에 중심 중심을 둔다는 차원에서 개념적으로 구분. 그러나 SBC가 발전으로 점차 구분이 모호해 짐 Network Computing SBC와 비슷하나, 애플리케이션을 서버에서 로드하여 로컬에서 수행하는 형태 (이용자의 CPU를 사용하여 동작) 이용자의 컴퓨팅 리소스보다는 클라우드 상의 IT 리소스를 사용하므로 개념적 구분 SaaS 서비스 제공자의 서버에 저장된 SW를 인터넷을 통해 서비스로 이용하는 SW 딜리버리 모형 클라우드 컴퓨팅은 모든 IT자원을 서비스로 활용한다는 차원에서 보다 SaaS를 포함하는 포괄적인 개념                                                                                                                      <자료 : 한국소프트웨어진흥원> 클라우드 컴퓨팅도 이미 우리의 생활속에서 적용돼 왔다. 포털사업자들이 제공하는 웹메일이나 블로그뿐만 아니라 웹하드 서비스 등도 클라우드 서비스의 일부분에 속한다. 때문에 클라우드 컴퓨팅과 관련 서비스는 이미 오래전에 등장했던 것이다. 한국소프트웨어진흥원 정책연구센터 정제호 박사는 "클라우드 서비스의 경우 이미 SW와 IT자원들을 인터넷을 통해 사용하려는 시도들이 많았지만 SW와 네트워크의 기술적 한계로 인해 인터넷을 통해 제공될 수 있는 서비스의 수준과 범위가 지극히 제한적이었기 때문에 성장의 기회가 적었다"며 "하지만 네트워크 고도화와 가상화 등의 기술 발전으로 클라우드 서비스 환경이 조성되면서, 그 잠재적인 가치에 대한 시장의 평가도 새롭게 이뤄지면서 새로운 키워드로 부상하고 있다"고 말했다. 아마존, 구글에 이어 MS, IBM 등도 가세 클라우드 컴퓨팅의 대표적인 사례로는 아마존을 꼽을 수 있다. 아마존은 2006년 유틸리티 컴퓨팅의 개념을 도입한 EC2(Elastic Compute Cloud)와 S3(Simple Storage Service)를 제공하면서 클라우드 컴퓨팅 서비스를 본격화했다. 서버와 스토리지를 자체적으로 소유하기 힘든 소기업이나 개발자를 겨냥한 것으로, 현재 많은 기업들과 개인들이 자체적인 IT인프라를 구축하지 않고 아마존의 이런 클라우드 서비스를 통해 필요한 IT서비스와 검색 엔진 서비스를 구매하고 있다. 아마존은 지난 10년간 클라우드 컴퓨팅 사업에 20억 달러 이상을 투자했고 지금까지는 성공적이라는 평가를 받고 있다. 현재 테스트 중인 DB 서비스까지 본격화되면 아마존의 입지는 더욱 탄탄해질 것으로 보인다. 아마존에 이어 세계적 IT기업들도 클라우드 컴퓨팅 시대에 대비한 준비로 바쁜 모습이다. 구글은 지난해말 공개된 모바일 웹 플랫폼 안드로이드에 이어 올해 앱 엔진(App Engine)도 선보였다. 앱 엔진은 개발자들이 구글의 플랫폼 상에서 웹 애플리케이션을 자유롭게 개발해 이용할 수 있도록 하는 PaaS(Platform as a Service) 전략이다. 현재는 베타서비스로 무료로 제공 중이며, 정식 서비스는 서비스 유형에 따라 유료화될 예정이다. 구글은 또한 이미 ‘구글 캘린더’를 통해 클라우드 컴퓨팅을 시도해왔다. 개인 일정 등을 관리해주는 이 프로그램은 PC가 아닌 데이터베이스센터에 자료를 저장하는 것으로, 이미 100만명 이상이 구글 캘린더를 이용하고 있다. 아마존과 구글에 이어 마이크로소프트도 지난 10월 클라우드 컴퓨팅을 위한 운영체제인 ‘윈도우 애저(Windows Azure)와 서비스 플랫폼인 ‘애저 서비스 플랫폼(Azure Services Platform)을 발표하며 시장에 뛰어들었다. 아직은 베타버전이 나오기 이전 특정 사용자들을 대상으로 사용할 수 있도록 하는 CTP로 제공하고 있지만 내년 이후로는 상용화될 것으로 예상된다. 이처럼 구글과 아마존 등이 데이터센터를 중심으로 한 인터넷 서비스를 제공하는데 이어 마이크로소프트까지 시장에 가세함으로써 인터넷 서비스 업체 간의 경쟁은 더욱 치열해질 전망이다. 여기에 IBM과 델도 서둘러 클라우드 컴퓨팅 시장에 뛰어들겠다고 선언하며 투자를 본격화함으로써 시장이 보다 빠르게 확대될 것으로 예상된다. 클라우드 컴퓨팅 활용도 높아 클라우드 컴퓨팅이 차세대 컴퓨팅으로 떠오르고 가운데 수혜가 가장 클 것으로 예상되는 시장들이 거론되고 있다. 특히 클라우드 컴퓨팅은 기업들에 IT자원에 대한 다양한 선택권과 유연성을 부여하기 때문에, 꼭 필요하지만 늘 사용하지 않는 서비스의 경우 이를 직접 구매해 설치하기 보다는 필요한 경우에 클라우드 서비스를 사용하면 유용하다. 예를 들어 가끔씩 사용하게 되는 웹 컨퍼런스의 경우 기업들은 비싼 인프라와 SW를 구매해 사용하기 보다는 클라우드 서비스를 통해 제공하는 편이 더 효과적일 수 있다. 또한 온라인 게임을 운영하는 업체들도 갑자기 동시 사용자가 폭주 하더라도 클라우드 서비스를 활용하면 안정적인 서비스를 지원할 수 있다. 특히 바이오 테크놀로지 분야의 경우 단기간에 엄청난 컴퓨팅 파워가 필요하다. 지금까지는 슈퍼 컴퓨팅을 쓰기도 했지만 웹에서 올려서 다양한 자원을 응용하고자 할 때는 클라우드 컴퓨팅이 제격이다. 또 월드컵이나 올림픽 등 2∼3주내 사용자가 얼마만큼 들어올지 예측하기 힘든 경우에도 쉽게 적용할 수 있다. 일반 기업에서도 월말 정산이나 회계 시스템에 적용할 수 있고, 대학의 경우 학사시스템에 안성맞춤이다. 한국마이크로소프트 신혁석 부장은 "클라우드 컴퓨팅은 갑자기 사용자가 늘어났을 때 이론적으로 무한 확장할 수 있는 것이 특징"이라며 "IT 업체들의 경우도 SW 개발이나 테스트 작업에 용이하게 이용할 수 있다"고 설명했다. 가트너 역시 2009년 10대 전략기술로 클라우드 컴퓨팅을 꼽는 배경에, 클라우드 컴퓨팅의 활용으로 기업들이 시장 진입시 비용을 절감할 수 있고, 탄력적으로 시스템을 운영할 수 있다는 점을 꼽았다. 2011년 약 1600억 달러 시장 형성 여기에 유비쿼터스 시대에 접어들면서 클라우드 컴퓨팅은 더욱 확산될 것으로 보인다. 모든 디지털 디바이스에서 가정용 전자기기에 이르기까지 인터넷을 통해 연결되는 세상에서 지금까지의 관리 방식으로는 엄청난 양의 데이터와 리소스를 처리하기가 벅차기 때문이다. 또한 클라우드 컴퓨팅은 이미 자체적으로 IT인프라를 구축하고 있는 기업들 보다는 개인들과 신생업체들을 중심으로 성장 기반이 다져질 것으로 예상된다. 아직은 초기 도입 시장이기 때문에 활용 수준과 범위가 넓지 않지만 마이크로소프트와 IBM과 같은 거대 IT 기업들이 본격적으로 시장에 뛰어들면서 기업의 핵심 비즈니스 영역에서의 도입도 멀지않아 활발히 이뤄질 것으로 보고 있다. 때문에 국내외적으로 시장 성장에 대한 기대치는 체감적으로 모두 높게 산정하고 있다. 하지만 아직 본격적인 도입기 단계가 아니기 때문에 조사기관들에서도 뚜렷한 성장예상치를 내놓지 못하고 있는 실정이다. 지금까지는 금융기관인 메를린치에서 발표한 보고서가 전부다. 메를린치는 2011년 클라우드 컴퓨팅 시장이 약 1600억 달러에 달하며, 그 중 950억 달러는 비즈니스와 생산성 애플리케이션에서, 나머지 650억 달러는 광고시장에서 나타나게 될 것으로 전망했다. 그리고 2020년에는 1000억 달러 이상의 시장을 예상했다. 국내 시장의 경우 IT기반 기술에 있어서는 약점을 갖고 있지만 인터넷 활용 측면이나 인터넷 인프라 측면에서는 가장 앞선 만큼 클라우드 컴퓨팅 분야에 기대를 걸고 있다. 또한 새로운 서비스에 대한 사용자들의 수용도가 높은 편이어서 수요자 측면에서도 높은 잠재력을 가지고 있다. 통신 사업자나 SI 업체들, 그리고 일반 기업들도 클라우드 인프라를 이용해 새로운 비즈니스 기회가 창출됨으로써 전반적인 IT 시장의 새로운 활력소로 그 진가를 발휘할 전망이다. 클라우드 컴퓨팅 시장 규모 전망

기사입력 : 2008.12.21

넷북 보기...

<2009 IT 트렌드 29>26. 넷북

데스크톱에서 노트북으로…노트북에서 다시 넷북으로

시티폰을 아시는가? 무선호출기(삐삐)와 휴대폰 사이에 잠시 반짝 시장을 형성했던 시티폰은 얼마 못가 우리들의 기억에서 사라졌다. 시티폰은 삐삐로 호출 받은 전화를 걸기 위해 공중전화 앞에 길게 줄을 서는 수고를 덜어줬지만 휴대폰이 등장하고 활성화되면서 삐삐와 함께 사라졌다. PC시장에도 시티폰과 같은 존재가 있었다. 바로 UMPC(Ultra Mobile Personal Computer)와 MID(Mobile Internet Device). 휴대성이 필수인 노트북도 들고 다니기엔 다소 무겁다는 점 때문에 틈새시장을 노리고 등장 했지만 불편한 입력장치와 비싼 가격으로 인해 활성화되지 못했다. 대신 적정성능을 발휘하며 저렴한 가격과 가벼움을 전면에 내세운 미니노트북(넷북)에 자리를 내줬다.  송영록 기자 syr@ittoday.co.kr 방 한칸을 가득 채웠던 원조 컴퓨터 애니악으로 시작해서 가정에 한 대 씩 필수적으로 보유하는 물품 1호가 된 데스크톱PC. 이동이 잦은 비즈니스맨을 위한 노트북PC로 발전됐고 이제는 넷북으로 진화했다. 무게에 민감한 여성과 인터넷과 문서작업을 주로 하는 학생들이 타깃이었던 넷북은 기존 노트북PC의 서브PC로 진화하며 1인 2 PC 시대를 예고하고 있다. 더 작아진 노트북 등장 넷북이란 인텔에서 처음 사용한 용어로써 이동성을 강조한 작은 크기에 인터넷, 문서 작업, 이메일 등의 기본적인 기능에 충실하도록 제작된 미니 노트북을 말한다. 넷북은 신흥시장을 중심으로 PC를 처음 구입하는 사용자와 선진시장에서 서브 PC용으로 수요가 크게 증가하고 있다. 넷북이 출현하게 된 계기는 인텔의 아톰 프로세서의 역할이 컸다. 지난 3월에 출시된 아톰 프로세서는 인터넷 전화, 이메일, 검색 등 인터넷 사용에 중점을 둔 낮은 가격의 프로세서이다. 기존 노트북용 프로세서와 비교해서 가격은 1/4 수준이고 전력은 1/10 수준에 불과하다. 또한 넷북은 일반노트북에 비해 비교적 가격이 낮고 크기가 작다는 것(7~10인치)이 특징이다. 저용량의 저장장치(SDD, HDD혼용)를 탑재한 1Kg남짓의 무게에 모바일 인터넷 환경에 최적화돼 있다. 기존 노트북과 비슷한 키보드를 채용한 점도 특징이다. 이같은 측면이 기존의 UMPC(Ultra Mobile Personal Computer)나 MID(Mobile Internet Device)의 한계를 극복할 수 있게 해줬다. PC시장에 돌풍을 일으킬 것으로 예상됐던 UMPC는 기존 노트북보다 작은 사이즈에 인터넷이 되고 엑셀과 워드에 최적화된 제품이었지만 100만원이 넘는 비싼 가격과 불편한 입력장치 등으로 인해 성공하지 못했다. 단순 엔터테인먼트 중심이었던 MID도 마찬가지로 성공가도를 달리지 못하고 사양길로 접어들었다. 이런 상황에서 등장한 것이 바로 넷북인 것이다. UMPC•MID•넷북 비교 UMPC MID 넷북 직장인을 위한 비즈니스 단말기 일반 소비자 지향형 단말기 다양한 소비층. 기존 노트북의 서브노트북으로 인기. 윈도 비스타와 같이 무거운 운영체제 사용 리눅스와 같은 가벼운 운영체제 사용 저가/저전력인 아톰 CPU사용. 운영체제는 적정성능의 윈도 XP 엑셀, 워드 작업 등에 최적 영화, 음악 등의 재생에 최적 인터넷 작업과 문서검색에 최적 넷북은 대만 PC제조 업체인 아수스가 선도했고, HP와 델이 뒤쫒고 있는 형국이다. 국내 시장에선 최근 삼성과 LG도 넷북 시장에 진출하면서 치열한 경쟁구도를 만들고 있다. 아톱CPU 출시 전인 지난해 10월부터 판매된 아수스 EeePC 701은 펜티엄M CPU를 채용하고 290달러 내외의 가격에 선보였다. EeePC는 8개월 만에 250만대가 팔리는 성과를 얻어냈다. 소비자들이 저가 노트북을 선호한다는 사실을 확신하게 된 아수스는 아톰CPU가 출시된 지 3개월후인 지난 6월 아톰CPU를 채용한 넷북 ’EeePC 901’을 출시하기에 이른다. 아수스의 Eee PC가 지난 3분기(7월 ~ 9월)동안 국내 시장에서만 3만대 판매를 기록하며 전 세계 미니노트북 시장의 역사를 다시 쓰고 있다. 아수스의 성공에 자극받은 에이서 등 기존 PC업체들이 지난 6월 대만 IT전시회인 ’컴퓨텍스 2008’을 계기로 경쟁에 가세했다. 에이서, MSI, 기가바이트, ECS, 고진샤, 인텔 등 대만업체들을 중심으로 아톰을 채용한 넷북을 발표했다. 이에 질세라 HP, 델 등 PC업계의 1,2위를 달리는 업체도 넷북 시장에 뛰어들었다. 넷북 시장에 대해 탐탁지 않게 생각했던 삼성과 LG까지 어쩔 수없이(?) 뛰어들면서 넷북 시장은 점점 달아오르고 있다. 외산 VS 국산 경쟁 ’치열’ 주요 넷북 사양 비교 업체명 삼성전자 LG전자 삼보컴퓨터 델 HP 아수스 고진샤 제품명 NC10 X110 HS-103 인스피론 미니9 HP2133P N10 W130K 프로세서 1.6GHz 인텔 아톰 1.6GHz 인텔 아톰 1.6GHz 인텔 아톰 1.6GHz 인텔 아톰 1.6GHz VIA 1.6GHz 인텔 아톰 1.33GHz 인텔 아톰 하드디스크 160GB HDD 160GB HDD 80GB HDD 8GB SSD 120GB HDD 250GB HDD 80GB HDD 메모리 1GB 1GB 1GB 1GB 2GB 2GB 1GB 사이즈 10.2인치 10.2인치 10.2인치 8.9인치 8.9인치 10인치 8.9인치 무게 1.33Kg 1.19Kg 1.1Kg 1.03Kg 1.13Kg 1.6Kg 1.0Kg 미니노트북 시장은 삼성전자, LG전자 등 국내 업체와 HP, 아수스, 델 등 해외 업체가 저마다 차별점을 내세워 경쟁하고 있다. 먼저 삼성전자와 LG전자 등 국내 업체는 애프터서비스 시스템이 잘 갖춰져 있다는 점이 강점이다. 삼성전자의 NC10은 B5정도의 작은 사이즈에 최대 8시간 이상 사용이 가능한 대용량 배터리를 포함하고도 무게가 1.3Kg에 불과하다. 일반 노트북과 비슷한 크기(93%)의 키보드를 적용해 사용성을 높였다. 또한 10.2인치 LCD, 120GB 하드디스크 등이 장착됐다. LG전자의 10인치 미니노트북 엑스노트MINI(X110)는 1.19Kg의 무게에 커버와 바닥의 색상이 동일하게 디자인됐다. 특히 ’시프트(Shift)’키의 활용도가 높은 한글의 특성을 고려해 ’시프트’키를 기존 미니 노트북보다 2배 넓게 만들어 오타 가능성을 줄였다. 삼보컴퓨터의 에버라텍 버디 HS-100은 1.1Kg의 무게에 10.2인치 화면을 갖췄다. 해외 업체들의 경우 미니노트북 시장을 주도했던 아수스 등 대만 업체가 중심이 돼 시장을 공략하고 있다. 아수스의 N10은 LCD보다 발열이 낮고 전력 소모가 적은 LED백라이트 LCD를 탑재했다. 250GB의 하드디스크는 용량이 큰 영화 등의 파일도 넉넉히 저장할 수 있다. 운영체제(OS) 부팅 없이 8초 만에 인터넷을 즐기는 ’익스프레스 게이트’ 기술과 얼굴을 인식하는 최첨단 스마트 로그온 기술 등이 적용됐다. 무게는 1.6Kg. 델의 인스피론 미니9은 플래시메모리 방식의 하드디스크인 SSD(Solid State Disk)가 탑재돼 있어 본체 크기와 무게를 줄였다. 1.03Kg의 무게에 A4용지의 절반 보다 조금 큰 크기(232X172mm)의 초소형 디자인으로 휴대성이 뛰어나다. 또한 정보 저장이 빠르며 발열 및 소음도 적다. LG전자 DDM마케팅팀장 이우경 상무는 “유비쿼터스 무선 환경의 빠른 성장과 노트북의 휴대 사용에 대한 중요성이 부각되면서 시장 수요가 본격적인 성장세를 타고 있다”며 “이러한 미니 노트북의 시장성과 고객의 요구를 반영해 LG전자도 엑스노트 MINI를 새롭게 출시하고 본격적인 미니노트북 시장에 뛰어들게 됐다”고 설명했다. 삼성전자 컴퓨터시스템사업부장 김헌수 부사장은 "’NC10’은 기존 넷북의 가장 큰 문제점으로 지적되어 온 사용성 문제를 삼성전자의 차별화된 기술력으로 해결한 획기적인 제품"이라며 "향후 와이브로, HSDPA 등 통신 모듈을 내장한 제품을 지속적으로 출시할 계획"이라고 말했다. 넷북시장 내년 2300만대 2008년 하반기를 강타한 세계적인 경기침체는 소비자들의 지갑을 꽁꽁 묶어 놨다. 소비자들은 70만원에서 120만원에 달하는 노트북 가격을 비싸다고 보기 시작했다. 하지만 2007년 하반기에 대만의 아수스가 50만원 정도에 Eee PC를 선보인 이후, Eee PC는 넷북 시장에서 공전의 히트를 쳤다. 이 성공을 발판삼아 HP나 델 등 세계 PC시장의 1,2위 업체도 8.9인치와 10.1인치 넷북을 개발하고 시장에 냈다. 미니노트북의 수요가 확대된 원인은 기존 노트북PC의 성능과 기능을 갖춘 채 가격을 낮춘 것이 주요했다. 기존 노트북PC는 그래픽 성능이 뛰어나고 고화질 디스플레이와 대용량 하드디스크 등 고기능을 갖췄지만 가격이 높았고 무거우며 배터리 사용시간이 짧았다. 반면 넷북은 CPU 성능과 메모리 용량 그리고 화면 사이즈를 줄여 제품의 소형 경량화 및 저가격화를 동시에 실현했다. 미니노트북(넷북)시장 전망<자료=디스플레이서치> 또한 사용자들이 보통 자주 사용하는 인터넷 검색과 워드프로세스 등으로 기능을 제한함으로써 가격을 낮췄다. 주요 시장조사기관들은 미니노트북이 세컨드PC로써 높은 수요증가세를 보이고 있으며 향후 성장세가 이어질 것으로 전망했다. 디스플레이서치는 미니노트북PC의 출하량이 2007년 70만대에서 매년 높은 비율로 성장하여 2009년에는 2300만대, 2015년에는 7400만대에 이를 것으로 전망했다. 가트너(Gartner)사는 오는 2012년 글로벌 넷북 출하대수가 전체 노트북의 10% 수준인 약 2600만대에 이를 것으로 예상했으며, 메릴린치(Merrill Lynch) 증권은 이보다 빠른 2010년 10% 수준에 이를 것이라 전망했다. 최동원 LG디스플레이 상무는 "넷북이 처음 나왔을 땐 너무 작고 기능도 많지 않아 성공하지 못할 것이라고 말하는 사람이 많았지만 현재 아수스, 엑시스 등을 보면 한 달에 100만대 이상씩 팔고 올해는 1300만대를 돌파할 것으로 전망된다"고 말했다. 최동원 상무는 이어 내년도 넷북의 사이즈에 대해 "7인치 넷북이 있었지만 너무 작았다"며 "2009년엔 8.9 인치와 10.1인치의 넷북이 5대5의 비율로 시장을 휩쓸 것이다"라고 전망했다. 힘빠진 데스크톱…힘솟는 넷북 데스크톱PC 수요가 더 이상 오르지 못하고 정체된 가운데 노트북PC가 PC시장을 주도하고 있다. 2006년부터 2008년 상반기까지 데스크톱PC 수요는 연평균 5%이하의 성장에 머물렀고, 내년은 마이너스 성장이 예상된다. 반면 노트북PC는 지난 2003년부터 2007년까지 5년간 연평균 29%씩 성장을 거듭했다. 2007년도 노트북PC의 수요는 1억800만대로 전체 PC수요의 40%를 차지했다. 올해는 전체PC수요의 절반 가까이를 차지할 것으로 보인다. 지난해 노트북PC에서 넷북 시장의 규모를 살펴보면 전체 노트북PC 시장 1100억대의 0.7%인 72만대로 미미했다. 하지만 아수스의 Eee PC 등 500달러 내외의 넷북 출시를 계기로 미니노트북PC 시장이 급성장했다. 수요는 지난해 70만대에서 올해 1000만대 이상으로 급증할 것으로 보인다. 삼성경제연구원에 따르면 노트북PC 시장은 1인1PC에 대한 욕구가 확대되면서 일인당 PC보금률 이 50%를 넘은 선진시장과 달리 10% 내외에 머물고 있는 아태 지역 등 신흥시장을 중심으로 수요가 늘어날 전망이다. 이같은 PC수요의 중심엔 넷북이 큰 역할을 차지할 것으로 보인다. 신흥시장의 소비자들 연평균 소득이 2000~5000달러 이하인 경우가 대부분이기 때문. 저가격을 내세운 넷북으로 수요가 쏠릴 것으로 보인다. 신흥시장뿐만 아니라 선진시장에도 넷북 열풍은 이어질 전망이다. 넷북으로의 노트북PC 교체수요가 이어지고 서브노트북으로써 추가구매 욕구를 자극하기 때문인 것. 넷북의 향후 전망을 살펴보면 단순히 새로운 저가시장을 창출할 것으로 보였던 시장이 성장을 거듭해 기존 노트북PC 시장을 잠식할 가능성이 높아지고 있다. 삼성경제연구원측은 또 선진시장에선 기존 노트북PC의 서브노트북 정도로 여겨졌으나 경기침체로 인해 소비자들이 가격에 민감한 반응을 보임으로 인해 넷북으로 기존 노트북PC를 대체하려는 경향이 많아질 것으로 보인다고 분석했다. 또한 저가 미니노트북인 넷북으로 인해 전체 노트북PC시장의 가격이 떨어지는 현상이 발생할 가능성도 충분하다고 연구원측은 전망했다. 마이크로소프트의 윈도도 비스타가 고기능에도 불구하고 사용자들을 충분히 끌어들이지 못했고 소비자들은 낮은 가격에 적당한 성능을 보여주는 윈도XP를 선호했다. 삼성경제연구원은 저가 PC에서 적정 성능을 경험한 소비자들이 다시 비슷한 가격에 더 높은 성능을 요구할 것이라고 예상했다. 내년은 업체간 가격경쟁에 불이 붙는 해라는 전망도 나왔다. 현재 넷북의 평균사양은 이렇다. 인텔 아톰 CPU에 8~10인치 디스플레이, 최대 메모리 2GB, 무게는 1~1.4Kg에 가격은 400~900달러. 삼성경제연구원은 디자인을 제외하면 성능에서 업체 및 제품 간 차이가 거의 없어 가격경쟁이 불가피하다고 밝혔다. 누가 얼마나 더 낮은 가격에 제품을 공급하느냐가 관건이라는 것. 낮은 가격에 제품을 공급하기 위해선 SoC(System On Chip), 저가 플랫폼 개발 등 제품설계나 생산 공정 설계 단계에서 저가화를 추진해 수익성을 확보해야한다고 연구원측은 분석했다. 최동원 LG디스플레이 상무는 "앞으론 누가 더 저렴한 넷북을 만드느냐가 중요할 것으로 전망된다"고 말했다. 와이브로 날개 달고 넷북 ’훨훨’ 날까?   넷북과 와이브로의 결합으로 언제나 자유롭게 초고속인터넷을 이용할 수 있게 됐다 환율이 상승하면서 저렴함으로 승부했던 넷북의 가격도 점점 올라가고 있다. 이같은 상황에서 넷북을 시중보다 저렴하게 살 수 있는 넷북과 와이브로 단말기 패키지 제품’이 눈길을 끌고 있다. KT는 지난 9월 와이브로의 시장 경쟁력을 강화하고 국내 IT관련 산업의 활성화를 위해 넷북, PMP, 내비게이션, 전자사전 등 휴대형 디지털기기 업체들과의 전략적 제휴를 발표한 했다. 이번 제휴에는 전 세계 와이맥스(WiMAX)의 확산을 주도하고 있는 인텔을 비롯해 넷북 제조사인 삼성전자, LG전자, TG삼보, HP, 고진샤, 성주, 제이씨현 등이 참여했다. 전략적 제휴를 통해 진행 중인 ’넷북과 와이브로 단말기 패키지 제품’은 KT가 와이브로 활용 저변 확대를 위한 발판으로 노트북 제조사와 손잡고 넷북 할인 혜택을 제공하는 공동마케팅이다. 와이브로란 노트북 등 휴대단말기에서 언제나 자유롭게 초고속 인터넷을 이용할 수 있는 서비스. 휴대성을 강조한 넷북과 와이브로의 결합은 찰떡궁합인 셈이다. KT 와이브로에 가입하면 삼성 NC10, LG-X110, HP2133P 등 제품을 시중가격보다 최대 20만원 까지 싸게 살 수 있다. 넷북에 탑재된 아톰 프로세서의 제조업체인 인텔의 윤은경 대고객영업본부장은 "전 세계 와이맥스 확산을 주도하는 인텔과 KT 와이브로와의 전략적 협력을 통해 보다 적극적으로 시장을 개척할 수 있게 됐다"라고 말했다. 표현명 KT 휴대인터넷 사업본부장은 “밖에서도 자유롭게 쓸 수 있는 무선 초고속인터넷으로서의 와이브로가 이제는 생활의 일부로 자리 잡게 될 것이며, 이번 KT와 휴대형 디지털기기 업체 간의 전략적 제휴를 통해 국내 IT산업 활성화는 물론 고객들은 보다 저렴하고 편리한 서비스를 제공받게 될 것”이라고 밝혔다. 전략적 제휴에 따른 효과에 대한 질문에 대해 표현명 본부장은 “와이브로 가입자는 10월 말까지 약 18만 명이지만 넷북과의 결합패키지로 인해 나타난 효과에 대해 아직 정확히 파악하진 못하고 있다. 다만 넷북의 반응이 시장에서 좋기 때문에 앞으로 결합상품으로써 와이브로 가입자도 꾸준히 증가할 것으로 기대 한다"고 말했다. 현재 와이브로 서비스는 수도권 지역에 한정돼 있다는 단점이 있지만 점차 광역시를 중심으로 서비스를 확대해 나갈 예정이라고 KT측은 밝혔다. 이처럼 와이브로와 휴대형 디지털기기의 결합이 본격적으로 개시됨으로써 음성중심의 휴대폰시장과는 다른 인터넷 중심의 새로운 개인형 무선 초고속인터넷시장이 본격적으로 열리게 될 것으로 전문가들은 내다보고 있다.

기사입력 : 2008.12.21

1차 과제 - 왜 개발자가 되려하는가?

취업과 직업의 세계 이력서 과제때 썼던 자기소개 부분인데...
거의 동기에 가깝다고 생각되는데... 내가 이 일을 하게된 계기를 적은거니...
이걸 내면 되지 않을까하는 생각이 들어...

개발동기 보기

“그만 해라, 쉬면서 해라,”

글자만으로도 뭔가 ‘지나치다’라는 느낌을 받을 수 있듯이 어려서부터 신기한 것, 재밌는 것, 하고 싶은 것에 빠지면 하나에만 집중하고 몰두하곤 하였습니다.

초등학교 2학년 때 누나에 의해 집에 286 컴퓨터를 사게 되어 처음으로 컴퓨터라는 기계를 접하였습니다. 그때 당시에는 286으로 나왔던 고인돌이라는 게임을 하는 것이 그렇게 신기할 수 없었고 밤늦게 게임을 하는 일이 적지 않았습니다.

이 신기한 기계를 접하게 된지 몇 년이 지나고 중학생이 되면서 PC통신을 알게 되면서 PC통신에 빠지게 되었습니다. 다시 몇 년이 지나서 고등학교에 들어가게 되었고, 학교 클럽 활동 중 컴퓨터 전산부에 들어가게 되었습니다.

전산부에 들어가게 되면서 프로그래밍에 대해 접해보았고, 간단한 프로그램을 만들어보면서 재미를 느꼈습니다. 그 때 즈음 인터넷이 보급되고, 처음으로 홈페이지라는 것을 만들어 보게 되었습니다.

디자인은 이쁘지는 않았지만 인터넷에서 누구나 접속할 수 있는 인터넷에 존재하는 홈페이지를 만들어 보게 되면서 ‘신기하고, 재밌다‘라는 것을 느꼈습니다.

그렇게 프로그램을 만드는 것이나 홈페이지 제작이나 컴퓨터로 할 수 있는 일이면 전 항상 즐거웠고, 재미를 느꼈습니다.

대학교를 지원하고 과를 컴퓨터공학과를 선택하게 된 계기도 어릴 적부터 고등학생 때까지 줄곧 컴퓨터와의 인연이 있었기에 컴퓨터 공학과를 선택하게 되었고, 군대를 갔다 오고 나서도 여전히 머릿속에는 컴퓨터 말고는 머릿속에 남아있는 것이 없었습니다.

그렇듯 컴퓨터에 대한 생각이 남들보다 지나칠 정도로 크다고 말할 수 있습니다. 대학교를 다니면서 전공 수업을 들으면서 프로그래밍 할 때 막히는 게 있으면 밤을 새서라도 해결을 봐야 했습니다.

노트북이 생기고 나서부터는 하루 24시간 중 컴퓨터와 함께하는 시간은 잠자는 시간과 밥 먹는 시간을 제외하고는 거의 저와 함께 있습니다.

컴퓨터를 접한지도 벌써 15년이라는 세월이 지났습니다. 컴퓨터는 저의 친구이자 저의 하나 밖에 없는 보물 같은 존재라고 말할 수 있고 앞으로 제가 하려는 일, 하고 싶은 일은 바로 이 컴퓨터로 웹 프로그래밍을 하는 일입니다.

[WINDOWS 계열] Apache 2.x - 가상디렉토리 설정 방법 및 최적화

<IfModule mod_alias.c>
Alias /project "D:/project"
<Directory "D:/project">
Options Indexes FollowSymLinks MultiViews ExecCGI
AllowOverride None
Order allow,deny
Allow from all
</Directory>
</IfModule>

위 스크립트를 httpd.conf 파일에 추가하세요.
해당 디렉토리는 http://localhost/project 를 통해 확인하실 수 있고,
중요한것은 디렉토리의 검색을 위해 옵션에 Indexes가 추가되었다는점.
상단의 모듈 추가하는 부분에서 그리고 mod_alias의 주석을 없애서 모듈을 추가해야 한다는점.
혹시나 아직 모르시겠다면 저도 GG..

ref. http://httpd.apache.org/docs-2.0/mod/mod_alias.html
ref2. http://www.apmsetup.com/?ct=24

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

C 드라이브에 APM 을 설치했습니다.
D 드라이브 project 파일에 홈페이지 제작한 것들이 있는데요...

그 폴더에 있는 것들을 htdocs 로 옮기지 않고... 브라우져에서 주소쳐서 볼 수 있는 방법이 있을까요?

php로 제작된 페이지들이 많아서 그걸 제 컴에서 볼려고 하는데... 다 옮겨야 하는지 궁금해서 질문 드립니다.. 좋은 하루 되세요~
------------------------------------

출처 : http://www.apmsetup.com/board.php?ct=12&bid=100&bs_type=subject&bs_str=가상&pg=0&mode=view&uid=2875

[출처] [펌] Apache 가상디렉토리 설정하기 

APACHE 1.x - http.conf 파일 한글화

아파치 메인 설정파일인 http.conf 의 한글화버전...
현재 아파치 2.x 버전을 쓰고 있지만 아래 설정파일이 한글로 표기되있어서
처음 아파치 서버를 설정할때 많은 도움이 되리라 생각된다.

=파일을 보려면 아래 클릭하세요=

http.conf (펼침)

#####################################################################
  #
  # 다음 한글화된 설정 파일은 Apache 1.3.12을 위한 것입니다.
  #
  # 번역         : 이 만 용 <yong@linuxkorea.co.kr>
  # 수정 및 추가 : 김 정 균 <admin at oops.org>
  #
  # 번역 상의 오류나 더 매끄러운 번역을 위한 제안 사항은 언제나
  # 환영합니다.
  #
  #####################################################################
  #
  # 베테랑 아파치 서버 관리자들에게 보내는 메시지)
  # -----------------------------------------------
  #
  # 아파치 설정 파일은 전통적으로 httpd.conf, srm.conf, access.conf
  # 이렇게 3 개로 구성되어 있다.  그러나 내부적으로는 3 개의 파일에
  # 대한 구별을 하지 않고 순차적으로 읽어나갈 뿐이다.
  #
  # 3 개의 파일 내용은 관례적인 것일 뿐이다.  아파치 신 버전부터는
  # 모든 설정 내용이 하나의 거대한 파일 httpd.conf에 들어 있고 나머지
  # 두 파일은 빈 파일로 제공되고 있다.
  #
  # 이런 사실을 알아두기 바란다.
  #
  #####################################################################
  #
  # 팁하나!)
  #
  # 1) 문제가 발생했을 때에는 httpd.conf (srm.conf, access.conf) 설정
  #    파일의 문법을 제대로 지켰는지 먼저 점검하고 다른 아파치 관리자
  #    들에게 도움을 요청하는 것이 좋습니다.
  #
  #    /usr/sbin/httpd 명령에 -t 옵션을 주면 문법만 점검합니다.
  #    기타 다른 옵션에 대하여 알고 싶을 때에는 -h 옵션을 사용하십시오.
  #
  #    예1) 문제가 없는 경우
  #
  #    # /usr/sbin/httpd -t
  #    Syntax OK
  #
  #    예2) 설정에 실수가 있는 경우
  #
  #    #/usr/sbin/httpd -t
  #    Syntax error on line 91 of /etc/httpd/conf/httpd.conf:
  #    ServerType must be either 'inetd' or 'standalone'
  #
  #####################################################################
  #
  # Rob McCool 씨의 NCSA 서버 설정 파일에 기초한 것임.
  #
  # 이 파일은 아파치(Apache) 서버 주 설정 파일이다.  이 파일에 들어있는
  # 설정 지시자(directive)를 통해 서버의 작동 방식을 지시한다.
  # 각 지시자에 대한 자세한 정보를 원하면 http://www.apache.org/docs를
  # 참고하라.
  #
  # 정확한 이해 없이 대충 읽어나가는 일이 없도록 하자. 여기에 적은
  # 내용을 그대로 여러분의 상황에 적용시키려 하지 말라.  다음 내용은
  # 실제 지시 내용을 위한 힌트라고 생각하자.  내용에 대하여 의문이
  # 있을 때에는 온라인 문서를 참조하라.  이 사실에 대하여 지금 여러분
  # 에게 충분히 경고해두었음을 밝히는 바이다.
  #
  # 아파치 서버는 이 파일을 읽고 난 후, /home/httpd/conf/srm.conf
  # 파일을 처리하고 그 다음 /home/httpd/conf/access.conf 파일을
  # 읽는다. 지금 현재 이 설정 파일에서 ResourceConfig, AccessConfig
  # 지시자를 사용하여 설정 파일 이름을 바꾸면, 변경된 이름의 설정 파일을
  # 읽는다. (여기서 /home/httpd 부분은 아파치 서버의 기본 디렉토리로
  # 대체하여 생각하면 된다.  예를 들어 여러분이 직접 아파치를 컴파일하여
  # 설치하는 경우에는 일반적으로 /usr/local/apache 가 된다.)
  #
  # 지시자는 3 개의 기본적인 섹션으로 묶여 있다:
  #  1. 아파치 서버 프로세스의 전반적인 작동을 제어하는 지시자
  #     ('global environment, 전체 환경')
  #  2. 가상 호스트에 의해 처리되지 않는 요청을 모두 처리하는 주 서버
  #     또는 기본 서버의 작동을 제어하는 지시자.
  #     이 지시자 내용은 모든 가상 호스트의 기본값이기도 하다.
  #  3. 다른 IP 주소 또는 다른 호스트 이름에 대한 요청을 처리할 가상
  #     호스트 설정
  #
  # 설정 파일과 로그 파일 이름 : 만약 파일 이름이 "/"로 (또는 Win32
  # 버전의 경우 "드라이브명:/" ) 시작하면 주어진 파일 이름 그대로를
  # 사용한다. 그러나 "/" 로 시작하지 않을 때에는 ServerRoot 의 값이
  # 그 앞에 추가된다. 따라서 "logs/foo.log"는 ServerRoot 값 (예를
  # 들어 "/usr/local/apache")이 앞에 추가되어 서버는 최종적으로
  # "/usr/local/apache/logs/foo.log"를 사용한다.
  #####################################################################

  ### 섹션 1 : 전체 환경 (Global Environment)
  #
  # 이 섹션에 적힌 지시자는 예를 들어 아파치 서버가 처리할 수 있는
  # 동시 요청의 갯수라든지 다른 설정 파일의 이름 등 아파치 서버의
  # 전반적인 작동에 영향을 미친다.
  #

  #
  # 서버 유형(ServerType)은 inetd 또는 standalone 둘 중 하나이다.
  # inetd 방식은 유닉스 플랫폼에서만 지원된다.
  #
  ServerType standalone

  Server의 Type을 지정하는 것으로, standalone은 httpd 데몬 프로세스가
  사용자의 요청을 처리하는 것이고, inetd는 inetd 데몬프로세스가 처리하게
  하는것이다. web demon처럼 사용자의 query가 많을 때는 standalone이 더
  효율적인 방법이다.

  #
  # 서버 루트(ServerRoot) : 서버의 설정 파일, 에러 파일, 로그 파일이
  # 기록되는 디렉토리의 최상위 경로명.
  #
  # 주의! 만약 서버 루트를 NFS (또는 기타 네트웍 파일 시스템) 마운트된
  # 곳에 두고자 한다면 LockFile 문서를 꼭 읽어보아야 한다.
  # (<URL:http://www.apache.org/docs/mod/core.html  #lockfile>);
  # 문서를 읽고 나면 앞으로 닥칠 지 모르는 몇 가지 문제점을 피할 수
  # 있다.
  # 디렉토리 경로 뒤에 슬래쉬(/) 문자를 쓰지 않는다!!!
  #
  ServerRoot "/etc/httpd"

  Apache 설정 file에서 사용될 경로중 상대 경로의 기준을 위해서 정해
  진다. Web의 Root directory와는 상관이 없다. DSO의 지원으로 인하여
  ServerRoot의 상대 경로를 주의있게 설정해야 한다. Alzza 에서는 DSO
  module들의 절대 경로가 /etc/httpd/modules 가 되므로 아래의 DSO
  쪽의 상대 경로와 틀어지지 않게 조심해야 한다.

  #
  # LockFile 지시자는 아파치를 USE_FCNTL_SERIALIZED_ACCEPT 또는
  # USE_FLOCK_SERIALIZED_ACCEPT 옵션을 주고 컴파일한 경우, 잠금
  # 파일을 경로를 지정할 때 사용한다.  이 지시자 값은 일반적으로 기본
  # 값이 되도록 놔둔다.  이 값을 바꾸는 경우는 로그 디렉토리가 NFS
  # 마운트된 곳에 있는 경우로서 잠금 파일은 항상 네트웍 파일 시스템이
  # 아닌 로컬 디스크에 저장되어야 하기 때문이다.  주 서버 프로세서의
  # PID 값이 자동으로 파일 이름 뒤에 붙는다.
  #
  #LockFile logs/accept.lock

  #
  # PidFile: 서버가 시동될 때 자신의 프로세스 고유 번호를 기록할 파일
  #
  PidFile /var/run/httpd.pid

  #
  # ScoreBoardFile: 내부 서버 프로세스 정보를 기록하는데 사용하는 파일.
  # 모든 아키텍쳐에서 꼭 필요한 것은 아니다.  하지만 필요하다고 생각하는
  # 경우에는 하나의 아파치 프로그램을 두 번 이상 실행시키는 경우 값이
  # 중복되지 않도록 해주는 것만 잊지 않으면 된다.
  #
  ScoreBoardFile logs/apache_runtime_status

  #
  # 표준 설정에서 서버는 httpd.conf, src.conf, access.conf 파일을
  # 차례대로 읽어나간다.  나중에 있는 2 개의 파일은 현재 아무 내용도
  # 없는 빈 상태로 배포되고 있다.  왜냐하면 모든 지시자를 그냥 하나의
  # 파일에 적는 것이 더욱 명료하기 때문이다.  주석으로 처리되어 있는
  # 값은 기본값이다.  서버가 이 파일 내용을 무시하도록 하기 위해서는
  # "/dev/null" (유닉스의 경우) 또는 "nul" (Win32) 값을 지정한다.
  #
  #ResourceConfig conf/srm.conf
  #AccessConfig conf/access.conf

  #
  # Timeout: 받기/보내기 타임 아웃 시간
  #
  Timeout 300

  클라이언트가 정보를 받을때까지 소요되는 대기시간의 최대값을
  지정한다. 쉽게 말해서 요청한 url이 없을 경우 error message가
  뜨기 까지의 시간이다. 네트워크가 응답이 늦을 수록 수치를 늘리는
  것이 좋다.

  #
  # KeepAlive: 지속성(persistent) 접속을 허가할 것인가 말 것인가?
  # (한 번의 접속에서 여러 개의 요청을 처리할 것인가 여부)
  # 허가하지 않기 위해서는 "Off"로 설정한다.
  # 허가하지 않는 것과 허가하는 것과의 효율 차이는 매우 크다.
  #
  KeepAlive On

  HTTP 1.0에서는 요청이 일어날 때마다 client와 Server간에 새로운
  연결이 만들어 지는데 이 설정으로 인하여 하나의 연결에서 여러
  요청이 가능하므로 요청을 처리하는 시간을 증진 시킨다. 이 기능을
  끄려면 off로 한다.

  필자의 경험상의 생각은 대형 site일 경우에는 이 기능을 끄기를
  권장한다. 이 기능을 Off를 시킬 경우에 system의 부하가 상당히 늘어
  나는 것을 느낄수는 있으나 Web상의 속도에서는 속도가 On일 경우보다
  더욱 빠르다는 것을 체감할수 있다. 즉 Web Server만을 돌린다면 Off로
  하는 것을 권장하며 여러 서비스를 할 경우에는 On으로 하라는 의미이다.
  참고로 이런 것을 체험할 정도의 대형 서비스란 하루 웹로그가 1G이상
  쌓이는 경우를 의미 하며 왠만한 site에서는 이 부분에 대해서 신경을
  쓰지 않아도 상관이 없다.

  #
  # MaxKeepAliveRequests: 지속성 접속 기간 동안 처리할 수 있는 최대
  # 요청 갯수 0 을 넣으면 무한대이다.  높은 성능을 내기 위해서 높은 값을
  # 추천한다.
  #
  MaxKeepAliveRequests 100

  접속된채로 특별한 요청이 없음에도 계속 연결을 유지시킬 수치를 지정
  한다. 값이 너무 크면 하나의 client가 Server의 resource를 독점 할 수
  있으므로 적당 하게 잡는 것이 좋다.

  #
  # KeepAliveTimeout: 같은 접속 상태에서 같은 클라이언트의 요청이 타임
  # 아웃되는 시간 (초 단위)
  #
  KeepAliveTimeout 15

  #
  # 서버 풀(Server-pool) 크기 조정.  몇 개의 프로세스가 필요한지 여러분
  # 에게 추측하도록 하기 보다는 현재의 부하 상태에 자동으로 적응하도록
  # 되어 있다. 아파치 서버는 현재의 부하 상태와 순간적으로 급격히 상승
  # 하는 경우 값 (예를 들어 하나의 네스케이프 브라우져에서 동시에 여러
  # 개의 요청이 들어올 수 있다)을 처리할 수 있는 충분한 갯수의 서버
  # 프로세스를 유지하려 노력한다.
  #
  # 아파치 서버는 주기적으로 몇 개의 서버가 요청 대기 상태인지 점검한다.
  # 만약 MinSpareServers 보다 적다면 여유 서버 프로세스를 생성한다.
  # 만약 MaxSpareServers 보다 많으면 불필요한 여유 프로세스를 제거한다.
  # 이 곳에 제시된 기본값은 거의 대부분의 사이트에 적합하다.
  #
  MinSpareServers 8
  MaxSpareServers 20

  httpd 데몬프로세스의 child 프로세스에 대해 MinSpareServers보다
  작으면 새로운 프로세스를 생성하고, MaxSpareServers보다 많으면
  여분의 프로세스를 죽이는 것을 지정한다.

  #
  # 처음 시동할 때 만들 서버의 갯수 -- 합리적인 근사치여야 한다.
  #
  StartServers 10

  httpd 서버를 처음 실행시킬때, 여분의 프로세스를 생성시킬 수치를
  지정한다. 반응 시간을 짧게 하기 위해 StartServers항목에서 말하는
  만큼의 Server process를 이미 만들어 두는 것인데, 실제로
  Service를 하고 있지 않을 경우에는 잠자고 있으므로 System에
  부하를 주거나 하지는 않는다.

  #
  # 서버 프로세스의 최대값, 즉 동시에 접속할 수 있는 클라이언트 갯수를
  # 제한하는 값이다. -- 만약 이 값에 도달한다면 클라이언트의 요청은
  # 봉쇄될 것이다.  따라서 이 값이 너무 낮아서는 안된다.  이 값은
  # 아파치 서버가 너무 많은 자원을 소비하여 전체 시스템을 먹통이 되도록
  # 하는 것을 방지하기 위해 사용될 뿐이다.
  #
  MaxClients 150

  동시에 접속할 수 있는 Client의 수를 지정한다.

  #
  # MaxRequestsPerChild: 각 자식 프로세스가 죽기 전까지 처리할
  # 수 있는 요청 갯수.  한 프로세스가 너무 오랫 동안 사용되면 메모리
  # 누출이나 자원 누출(아파치 때문에 또는 잘못된 라이브러리 때문에)
  # 이 발생할 수 있으므로 자식 프로세스는 자동으로 죽는다.  대부분의
  # 시스템에서는 필요치 않으나 솔라리스에서와 같이 라이브러리에서의
  # 자원 누출 현상을 막기 위해 필요하다.
  #
  MaxRequestsPerChild 100

  child 프로세스가 응답할 수치를 지정한다. 대부분의 system에서는
  이 기능이 필요 없다. 다만 Solias와 같은 몇몇의 system에서는 이
  기능을 지정해 줘야 하는 듯 하다.

  #
  # Listen: 아파치를 기본값 이외에도 특정 IP 주소 또는 포트에 연결
  # 하도록 해준다.  <VirtualHost> 지시자도 참고하라.
  #
  #Listen 3000
  #Listen 12.34.56.78:80

  Virtual host설정에 관한 부분이다. Virtual Host에 관한 사항은 Name
  Server와 관련이 있으므로 따로 강좌를 하게 될 것이다.

  #
  # BindAddress: 이 옵션을 사용하여 가상 호스트를 지원할 수 있다.
  # 이 지시자를 이용하여 서버가 귀기울일 IP 주소를 지시할 수 있다.
  # "*", IP 주소, 또는 완전한 인터넷 도메인 이름을 사용할 수 있다.
  # <VirtualHost>, Listen 지시자도 참고하라.
  #
  #BindAddress *

  하나 이상의 IP address가 있는 Server에서 사용한다. Server가 어떤
  address에서 요청을 기댜려야 할지 정한다. Default로 주석 처리 되어
  있어 Server가 모든 address를 청취한다. Default로 나두면 된다.

  # 동적 공유 객체(Dynamic Shared Object, DSO) 지원
  #
  # DSO 방식으로 만들어진 모듈의 기능을 사용하기 위해서는 그 기능에
  # 관련된 지시자를 사용하기에 앞서 알맞게 `LoadModule' 지시자로
  # 모듈을 지시해주어야 한다.  DSO 작동방식에 대하여 자세히 알고 싶은
  # 사람은 아파치 1.3 배포 파일의 README.DSO 를 읽어보라.  여러분이
  # 갖고 있는 httpd 바이너리에 내장된(정적으로 링크되어 항상 사용
  # 가능한) 모듈 목록을 알고 싶을 때에는 `httpd -l' 명령을 실행한다.
  #
  # 주의: 모듈을 적재하는 순서는 매우 중요하다.  전문가의 조언 없이
  #       아무렇게나 순서를 바꾸지 말라.
  #
  # 예:
  # LoadModule foo_module libexec/mod_foo.so
  #
  # 모듈 관련 문서는 HTML 형식으로 "/home/httpd/manual/mod" 에
  # 놓아두었다.
  #
  # 주의: LoadModule 설정을 하나라도 바꾸었다면 LoadModule 설정 뒤에
  #       따라 나오는 AddModule 설정도 똑같이 바꾸어주기 바란다.
  #

  #LoadModule mmap_static_module  modules/mod_mmap_static.so
  LoadModule env_module           modules/mod_env.so
  LoadModule config_log_module    modules/mod_log_config.so
  LoadModule agent_log_module     modules/mod_log_agent.so
  LoadModule referer_log_module   modules/mod_log_referer.so
  #LoadModule mime_magic_module   modules/mod_mime_magic.so
  LoadModule mime_module          modules/mod_mime.so
  #LoadModule negotiation_module  modules/mod_negotiation.so
  LoadModule status_module        modules/mod_status.so
  LoadModule info_module          modules/mod_info.so
  LoadModule includes_module      modules/mod_include.so
  LoadModule autoindex_module     modules/mod_autoindex.so
  LoadModule dir_module           modules/mod_dir.so
  LoadModule cgi_module           modules/mod_cgi.so
  #LoadModule asis_module         modules/mod_asis.so
  #LoadModule imap_module         modules/mod_imap.so
  LoadModule action_module        modules/mod_actions.so
  #LoadModule speling_module      modules/mod_speling.so
  LoadModule userdir_module       modules/mod_userdir.so
  #LoadModule proxy_module        modules/libproxy.so
  LoadModule alias_module         modules/mod_alias.so
  LoadModule rewrite_module       modules/mod_rewrite.so
  LoadModule access_module        modules/mod_access.so
  LoadModule auth_module          modules/mod_auth.so
  #LoadModule anon_auth_module    modules/mod_auth_anon.so
  #LoadModule dbm_auth_module     modules/mod_auth_dbm.so
  LoadModule db_auth_module       modules/mod_auth_db.so
  #LoadModule digest_module       modules/mod_digest.so
  #LoadModule cern_meta_module    modules/mod_cern_meta.so
  LoadModule expires_module       modules/mod_expires.so
  LoadModule headers_module       modules/mod_headers.so
  #LoadModule usertrack_module    modules/mod_usertrack.so
  #LoadModule example_module      modules/mod_example.so
  #LoadModule unique_id_module    modules/mod_unique_id.so
  LoadModule setenvif_module      modules/mod_setenvif.so
  #LoadModule bandwidth_module    modules/mod_bandwidth.so
  #LoadModule put_module          modules/mod_put.so

  #
  # 확장 모듈
  #LoadModule php_module         modules/mod_php.so

  PHP2를 위한 Module로서 요즘에는 별로 사용을 안한다. 무시해랏!

  #
  # 다음 모듈은 MySQL 데이터베이스와 더불어 서버 스크립팅 언어로
  # 인기를 누리고 있는 PHP3 모듈입니다.
  #
  # 참고 사이트 : http://www.php.net
  #
  #LoadModule php3_module        modules/libphp3.so

  PHP3 module을 설치했을 경우 주석을 풀어주고 사용을 하면 된다.

  #
  # 다음 모듈은 아파치 펄 모듈로서 CGI 스크립트로 펄을 많이
  # 사용하는 사람들에게 펄 코드 실행 속도의 향상을 가져다 줍니다.
  #
  # 주의 : 설정을 바꾼 후 한 가지 할 일이 더 있다.
  #
  #        <Location /perl> ... </Location>
  #
  #        위와 같은 설정을 찾아서 펄 스크립트를 사용할 수 있는
  #        디렉토리를 설정해주어야 한다.
  #
  #LoadModule perl_module        modules/libperl.so

  #
  #  모듈 실행 순서를 정확하게 하기 위해 사용 가능한 모듈(정적 또는
  #  공유 모듈 포함)로부터 완전한 목록을 다시 만들어 둔 것이다.
  #  [LOADMODULE 섹션을 하나라도 수정했다면 이 부분도 역시 알맞게
  #  수정하라]
  #
  ClearModuleList
  #AddModule mod_mmap_static.c
  AddModule mod_env.c
  AddModule mod_log_config.c
  AddModule mod_log_agent.c
  AddModule mod_log_referer.c
  #AddModule mod_mime_magic.c
  AddModule mod_mime.c
  #AddModule mod_negotiation.c
  AddModule mod_status.c
  AddModule mod_info.c
  AddModule mod_include.c
  AddModule mod_autoindex.c
  AddModule mod_dir.c
  AddModule mod_cgi.c
  #AddModule mod_asis.c
  #AddModule mod_imap.c
  AddModule mod_actions.c
  #AddModule mod_speling.c
  AddModule mod_userdir.c
  #AddModule mod_proxy.c
  AddModule mod_alias.c
  AddModule mod_rewrite.c
  AddModule mod_access.c
  AddModule mod_auth.c
  #AddModule mod_auth_anon.c
  #AddModule mod_auth_dbm.c
  AddModule mod_auth_db.c
  #AddModule mod_digest.c
  #AddModule mod_cern_meta.c
  AddModule mod_expires.c
  AddModule mod_headers.c
  #AddModule mod_usertrack.c
  #AddModule mod_example.c
  #AddModule mod_unique_id.c
  AddModule mod_so.c
  AddModule mod_setenvif.c
  #AddModule mod_bandwidth.c
  #AddModule mod_put.c

  # Extra Modules
  #AddModule mod_php.c
  #AddModule mod_php3.c
  #AddModule mod_perl.c

  #
  # ExtendedStatus 지시자는 "server-status" 처리기가 호출되었을
  # 때 아파치가 "매우 자세한" 상태 정보를 생성시킬 것인지
  # (ExtendedStatus On) 아니면 매우 기본적인 정보만 생성시킬
  # 것인지를 (ExtendedStatus Off) 제어한다.  기본값은 Off 이다.
  #
  ExtendedStatus On

  #
  #####################################################################

  ### 섹션 2: '주(Main)' 서버 설정
  #
  # 이 섹션에 있는 지시자는 <VirtualHost> 정의에 의해 처리되지
  # 않는 모든 요청에 응답할 '주' 서버가 사용할 값을 정한다.
  # 이 값들은 또한 이 파일 뒷 부분에서 정의할 모든 <VirtualHost>
  # 컨테이너의 기본값을 제공하기도 한다.
  #
  # 여기 나오는 모든 지시자는 <VirtualHost> 컨테이너 안에서도
  # 사용할 수 있으며 그 안에서 사용되면 해당 가상 호스트에 대하여
  # 전체 기본값을 무시하고 새롭게 정한 값이 채택된다.
  #

  #
  # 만약 ServerType ('Global Environment' 섹션에서 설정)이
  # "inetd"인 경우, inetd 설정 내용을 따르기 때문에 다시 몇 가지
  # 지시자는 아무런 효력을 발휘하지 않는다.
  # ServerAdmin 지시자까지 그냥 건너뛴다.
  #

  #
  # Port: 독립실행형(standalone) 서버가 요청을 기다리는 포트.
  # 1023 번보다 낮은 번호의 포트에 대해서는 httpd가 처음에는
  # root 권한으로 실행되어야 한다.
  #
  Port 80

  시스템에 의해 미리 httpd를 위해 예약된 포트 번호는 80번이다.
  0에서 1023까지의 포트번호는 시스템에 의해 미리 예약되어 있다.
  그 이상의 포트번호를 지정하여 일반사용자도 httpd을 설치,
  운영가능하다. http://aaa.bbb.ccc:8080/ 등으로 사용할 수 있다.
  만약 Server type을 Inetd로 했다면 /etc/services에서 지정을 해
  줘야 한다.

  #
  # httpd가 다른 사용자 또는 그룹 권한으로 실행되게 하려면 우선은
  # httpd가 root 사용자 권한으로 실행되고 나서 설정한 다른 사용자
  # 권한으로 전환해야 한다.
  #
  # User/Group: httpd가 실행된 권한의 사용자/그룹의 이름(또는 #번호)
  #  . SCO (ODT 3)에서는 "User nouser"와 "Group nogroup"을
  #    사용한다.
  #  . UPUX 에서는 nobody로 실행하는 경우 공유 메모리를 사용할 수
  #    없을 것이다.  이 때는 www 등의 사용자를 만들고 그 사용자
  #    권한으로 실행되도록 한다.
  # 주의) 몇몇 커널들은 60000 이상의 (unsigned) 그룹 값을 설정하면
  # setgid(Group), semctl(IPC_SET) 함수를 거부한다.
  # 이런 시스템에서는 Group   #-1을 사용하지 말라!
  #
  User nobody
  Group nobody

  이 항목은 Default로 나두기를 권한다. 지정한 사용자와 그룹이 존재
  하지 않으면 서버가 동작하지 않기 때문이다. 굳이 설명을 하자면 이
  설정은 ServerType이 standalone일 때만 적용되는 것으로, 서버가
  사용자의 요청에 대해서 생성하는 child httpd 프로세스에 대한
  user id, group id 이다. 일반적으로 시스템에서 사용하지 않는
  것들로 지정하는 것이 바람직하다.

  #
  # ServerAdmin: 서버에 문제가 발생했을 때 메일을 보낼 메일 주소.
  # 이 주소는 예를 들어 에러 문서와 같이 서버가 생성하는 페이지에
  # 나타날 것이다.
  #
  ServerAdmin admin at oops.org

  #
  # ServerName은 클라이언트 프로그램에게 돌려주는 서버 이름이
  # 다른 경우 호스트 이름을 설정할 수 있게 해준다. (예를 들어,
  # 호스트의 실제 이름이 아닌 'www'를 사용하도록 하는데 사용할
  # 수 있다.)
  #
  # 주의: 호스트 이름을 아무렇게나 만들어선 안된다.  이 이름은
  # 여러분의 호스트에 주어진 타당한 DNS 이름이어야 한다. 잘
  # 모르겠으면 네트웍 관리자에게 문의하라.
  # 호스트가 등록된 DNS 이름을 갖고 있지 않는 경우에는 이 곳에
  # IP 주소를 적는다.  어찌 되었든 IP 주소를 사용하여(예를 들어
  # http://123.45.67.89/) 접속할 수 있다.  이런 식으로 해서
  # 리다이렉션이 작동하도록 할 수 있다.
  #
  ServerName www.oops.org

  서버의 도메인 네임을 지정한다. 자신의 서버가 도메인 네임을
  가지지 않았다면 ip address로라도 꼭 적어 주어야 계정 접속을
  할때 ~account 뒤에 "/"를 붙이지 않고 접속을 할수가 있다.
  도메인 이름을 가지고 있다면 주의할 것은 꼭 실제로 존재하는
  URL 이어야 한다는 것이다.

  #
  # DocumentRoot: 제공할 문서의 상위 디렉토리.
  # 기본적으로 모든 요청은 이 디렉토리로부터 처리된다. 하지만
  # 심볼릭 링크나 앨리어스(alias)를 사용하여 다른 위치를
  # 가리키도록 할 수 있다.
  #
  DocumentRoot "/home/httpd/html"

  웹 문서의 기본 directory이다. 보통 우리가 url을 쳤을때 접속되는
  최초의 directory이다. 소스로 apache server를 설치했을 경우에는
  default로 /usr/local/apache/htdocs이며 알짜 RedHat에서는
  /home/httpd/html 이다. 참고로 이전 버전의 apach를 소스로
  compile을 했을 경우에는 /usr/local/etc/httpd/htdocs 가 된다.
  1.3.4 부터 위와 같이 변경이 되었다. "@@ServerRoot@@ 를 이용
  하여 ServerRoot 인자의 directory 경로의 값을 변수와 같이 사용
  할 수도 있다.

  <IfModule mod_bandwidth.c>
    #
    # 전송속도 제한에 관한 설정이다. BandWidthModule 지시자는
    # 전체 설정에 사용이 되어지며, BandWidth, LargeFileLimit,
    # MinBandWidth는 지역 설정에서 사용을 할수도 있다.
    #
    BandWidthModule On

    #
    # 문  법: BandWidth <도메인|IP주소|all> <속도>
    # 기본값: 없음
    # 사용처: 전체 설정, 디렉토리별 설정, .htaccess
    #
    # 호스트에 따라 속도의 제한을 걸 수 있다. all은 모든 호스트에
    # 대해서 제한을 거는 것이며 도메인이나 IP주소로 접속 호스트를
    # 지정할 수 있다. 그리고 네트워크/마스크 포맷*으로 지정할 수도
    # 있다. (예: 192.168.0.0/24)
    #
    # 속도는 Bytes/second로 지정을 하며 0의 경우는 제한이 없다.
    #
    # 디렉토리별 설정 예
    #
    # <Directory /home/httpd/html>
    #   BandWidth 192.168.1 0
    #   BandWidth foobar.net 0
    #   BandWidth all 1024
    # </Directory>
    #
    # /home/httpd/html 디렉토리에서의 제한을 한 것이다. 192.168.1.*
    # IP 주소를 가진 호스트와 *.foobar.net이라는 도메인명을 사용하는
    # 호스트에 대해서는 제한을 걸지 않으며 그 외 모든 접속에 대해서
    # 1024Bytes/sec으로 제한을 한다.
    #
    BandWidth       all     0

    #
    # 문  법: LargeFileLimit <파일크기> <속도>
    # 기본값: 없음
    # 사용처: 전체 설정, 디렉토리별 설정, .htaccess
    #
    # 일정 이상의 크기를 가진 파일을 누군가가 받아 가려 할 때
    # 그 속도의 제한을 걸 수 있다. 파일크기는 KByte 기준이며 속도는
    # 역시 Bytes/secound 이다.
    #
    # LargeFileLimit 1024 4096
    # LargeFileLimit 2048 2048
    #
    # 위 예제는 1024 ~ 2047KB 크기의 파일을 받아가려 할 때 속도를
    # 4KB/sec으로 제한하고 2048KB 이상의 파일은 2KB/sec으로 제한을
    # 하는 것이다.
    #
    # LargeFileLimit 1024 4096

    #
    # 문  법: MinBandWidth <도메인|IP주소|all> <속도>
    # 기본값: all, 256
    # 사용처: 전체 설정, 디렉토리별 설정, .htaccess
    #
    # 데이타 전송의 최저 속도를 지정한다.
    #
    # BandWidth를 4096 (4KBytes/sec)으로 지정하고 MinBandWidth가
    # 1024로 지정이 되어 있을 때:
    #
    #   - 지정된 호스트에서 하나만 접속할 경우, 4096bytes/sec이
    #     최고의 속도가 된다.
    #
    #   - 지정된 호스트에서 두개가 동시에 접속할 경우, 각각의 세션에
    #     대해 2048Bytes/sec이 최고의 속도가 된다.
    #
    #   - 더 많은 동시 접속이 일어나도 세션 당 최고 속도는
    #     1024Bytes/sec 이하로는 줄지 않는다.
    #     (MinBandWidth 값이 1024기 때문에)
    #
    # MinBandWidth가 "-1"로 지정되면 모든 세션에 대해 최고 속도는
    # BandWidth나 LageFileLimit에서 지정한 속도가 나올 수 있게 된다.
    #
    # BandWidth를 4096으로 지정하고 MinBandWidth가 -1이라면 동시에
    # 지정된 호스트에서 몇개의 접속을 하더라도 각 세션의 속도는
    # 4096Bytes/sec 까지 나오게 되는 것이다.
    #
    MinBandWidth    all     -1
  </IfModule>

  IfModule 이라는 지시자는 module을 올렸을 경우에만 작동을
  가능하게 해 주는 지시자 이다. 즉 Module로 올라와 있지 않을
  경우에는 작동을 하지 않는다.


  #
  # 아파치가 접근할 수 있는 각 디렉토리에 대하여 어떤 서비스와
  # 기능을 허용할 것인지 거부할 것인지 여부를 설정할 수 있다.
  # 디렉토리에 대한 설정 내용은 그 하부 디렉토리에도 영향을 미친다.
  #
  # 우선, "기본값"을 매우 제한적인 상태로 설정한다.
  #

  <directory> tag에 의하여 각 directory마다 적절하게 permission을
  걸수가 있다.

  <Directory />
    Options FollowSymLinks
    AllowOverride None
    Order allow,deny
    Allow from all
    Deny from env=no_access
  </Directory>

  "Deny from env=no_access" 설정에 대해서는 뒤에 다루기로 한다. 

  #
  # 이 곳부터 허용할 특정 기능을 알맞게 설정해나간다는 사실을
  # 주목하자. 여러분이 기대한 대로 작동하지 않는 것이 있다면 그
  # 기능을 가능 상태로 설정해두었는지 점검하기 바란다.
  #

  #
  # 다음 내용은 여러분이 설정한 DocumentRoot 값으로 변경해서
  # 사용한다.
  #
  <Directory "/home/httpd/html">

  #
  # 다음 값에는 "None", "All", 또는 "Indexes", "Includes",
  # "FollowSymLinks", "ExecCGI", "MultiViews"의 자유로운
  # 조합이 가능하다.
  #
  # "MultiViews" 만큼은 "Options All"을 사용한다 할 지라도
  # 명시적으로 적어야만 작동한다는 사실을 알아두자.
  #
      Options Indexes FollowSymLinks Includes

  지정할수 있는  옵션의 예이다.

None	어떤 옵션도 이용할 수 없다.
All	지정한 directory에서 모든 명령을 이용할 수 있다.
Indexes	URL에 지정된 디렉토리에 (index.html 같은) 지정된 파일이 없을 경우 디렉토리의 파일 목록을 보여주는 옵션.
Includes	서버측의 추가적인 정보를 제공할 수 있게 한다.
IncludesNoExec	서버측의 추가적인 정보를 제공할 수 있게 하지만, 어떠한 실행 파일을 실행하는 것을 방지한다.
FollowSymLinks	디렉토리상의 심볼릭 링크를 사용가능하게 한다.
ExecCGI	CGI 스크립트를 실행할 수 있게 한다.
MultiViews	All 옵션이 설정되었을 때만 지정된 목록의 multiviews를 허용한다.

  #
  # 다음은 각 디렉토리에 위치한 .htaccess 파일에서 어떤 옵션을 
  # 마음대로 제어할 수 있는지 결정한다.  
  # "All" 또는 "Options", "FileInfo", "AuthConfig", "Limit"의
  # 자유로운 결합이 가능하다.
  #
      AllowOverride None

  .htaccess파일은 서버의 각 디렉토리에 만들어서 각 디렉토리에
  대한 접근을 제어하기 위한 것으로 디렉토리에 .htaccess파일이
  있으면, 서버 전체에 작용하는 access.conf 보다 우선권을 가진다. 

  .htaccess파일에 대한 Override에 대한 옵션이다. 가능한 옵션은
  다음과 같다.

None	.htaccess파일을 읽을 수 없게 한다.
All	모든 지정에 대해 가능하게 한다.
Options	규정된 디렉토리 형식을 콘트롤하는 지정의 사용을 허락한다.
FileInfo	문서형식을 콘트롤하는 지정의 사용을 허용한다.
AuthConfig	사용자 인증 지정의 사용을 허용한다. 사용자 인증 변수를 사용한다.
Limit	호스트 접근을 콘트롤하는 지정을 허용한다.

  #
  # 서버로부터 자료를 얻어갈 수 있는 위치를 제어한다.
  #
    Order allow,deny
    Allow from all
    Deny from env=no_access

  Limit에 관련된 부분을 설정을 한다.

  order : 서버가 access control을 수행하는 순서를 나타낸다. 여기서는  
        allow기능을 먼저 수행하고, deny기능을 수행하라는 것이다.

  deny, allow - deny 지시자 부터 검사하고 allow 지시자를 검사 
  allow, deny - allow 지시자 부터 검사하고 deny 지시자를 검사 
  mutual-failure - allow목록에 없는 모든 host에게 접속을 거부

  allow from : 나열되는 주소들에 대한 access control을 가능하게 한다.  
         사용 가능한 주소는 도메인 네임, 호스트 이름 주소, 호스트 ip 
         주소, ip 주소의 앞부분 3바이트, 모든 주소에 해당하는 all
         이 있다.
  deny from : allow from과 반대되는 개념이며, 사용가능한 주소는 
         allow from과 같다.
  require : 사용자, 그룹에 대한 접근을 통제할 수 있다.
         사용방법 : require entity en1 en2 ... enn
         entity에 들어갈 수 있는 것은 user, group, valid-user의 
         세가지이다.
  user : 지정된 사용자들에게만 접근을 허용하는 것으로, 지정된 사용자에 
         대한 정보는 AuthUserFile에서 지정한 파일에 있다.
  group : 지정된 그룹에게만 접근을 허용하는 것으로, 지정된 그룹에 대한 
         정보는 AuthGroupFile에서 지정한 파일에 있다.
  valid-user : AuthUserFile에 있는 모든 사용자에 대해 접근을 허용한다.

  </Directory>

  #
  # UserDir: ~user 요청을 받았을 때 사용자의 홈 디렉토리 뒤에 추가할
  # 디렉토리 이름.
  #
  UserDir htdocs

  계정 사용자들의 home directory를 지정한다.
  보통 http://url/~계정 이런식으로 접속했을때 계정에 이곳에 지정된
  이름의 directory를 만들고 home directroy로 사용하면 된다. 보통 
  public_html 이나 htodcs, home 을 많이 쓴다. 다른 이름으로 해도
  상관은 없다. 계정 사용자가 사용을 못하게 하려면 DISABLED 옵션을
  주면 된다.

  참고를 할것은 RedHat 계열에서는 user를 생성을 하면 user의 home
  directory는 700의 권한을 갖게 되므로 httpd.conf에서 아무리 설정을
  해 줘도 forbidden error만 만나게 된다. 그러므로 계정에서 homepage를
  운영하기 위해서는 꼭 chmod a+x ~accountname 명령을 실행을
  해 줘야 한다.

  #
  # UserDir 디렉토리에 대한 접근을 제어한다.  다음은 사용자 홈
  # 페이지에 대하여 읽기만 가능하도록 한 예제 설정 내용이다. 
  # 참고 자료로 사용하기 바란다.
  #
  #<Directory /*/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>

  위의 설정중 "*" 사용에 관해서 언급을 할것이 있다. 보통 "*"는 all의
  의미로 많이 사용이 된다. 즉 위에서 /*/public_html 은 어떠한
  경로에 있는 모든 public_html을 뜻한다고 할수 있다. 하지만 이는
  그렇게 호락호락하게 되지는 않는듯 하다. 필자의 경험에 의하면
  같은 레벨의 깊이에 있는 public_html 만 적용이 되는듯 하다. 즉
  위의 설정대로라면 /home/public_html은 적용이 되지만
  /home/oops/publci_html 은 적용이 되지 않더란 말이다.

  #
  # DirectoryIndex: 준비된 HTML 디렉토리 인덱스로 사용할 파일이나
  # 파일 목록의 이름을 나열한다.  여러 개를 나열할 때는 스페이스로
  # 구분한다.
  #
  DirectoryIndex index.html index.htm index.shtml index.php3 index.cgi

  특정 파일을 지정하지 않고 디렉토리만 지정했을 때 불러들일
  문서를 지정한다. 앞에서 부터 써나간 대로 지정된 file이 있는
  지 확인을 하고 없으면 그 다음으로 지정한 file을 찾는다.

  #
  # AccessFileName: 각 디렉토리에 대하여 접근 제어 정보 내용을
  # 담고 있을 파일 이름
  #
  AccessFileName .htaccess

  서버가 디렉토리를 출력할 때 참고할 파일을 지정한다. directory
  user들은 그 directory에 .htaccess라는 file에 지시자를 넣어
  srm.conf의 설정을 덮어 쓸수 있다. 인증을 시도하기 위하여 참조
  하는 file이라고 생각하면 된다. <Directory> tag 에 관련 분이
  설명되어 있다.

  #
  # 다음 행은 웹 브라우져가 .htaccess 파일을 접근할 수 없도록
  # 하는 설정이다.  .htaccess에는 인증 정보가 들어있는 경우가
  # 빈번하므로 보안 상 이유로 이 파일에 대한 접근은 불허해야
  # 한다. 웹 방문객들이 이 파일을 보게 하고 싶으면 다음 행들을
  # 주석 처리하라. 만약 AccessFileName 설정을 다른 파일명으로
  # 바꾸었다면 알맞게 .htaccess를 그 이름으로 바꾸어준다.
  #
  <Files "^\.ht">
      Order allow,deny
      Deny from all
  </Files>

  이 설정 역시 1,3,4에서 부터  새로 추가된 설정이다. .htaccess에
  접근을 하여 password file을 훔쳐가려고 하는 것을 미연에 방지
  하기 위하여 file 자체에도 permission을 걸수 있도록 해 놓았다.
  문법은 <directory> tag에서 설명을 한 limit 문법과 동일하다.

  위의 설정은 정규 표현식(RegEx)을 이용한 것으로 .ht로 시작하는
  모든 파일을 의미한다.

  #
  # CacheNegotiateDocs: 기본적으로 아파치는 내용에 따라 협상된
  # 문서에 대해서는 "Pragma: no-cache" 내용을 전송한다.  이 행은
  # 프록시 서버로 하여금 문서를 캐쉬하지 않도록 요청한다. 다음 행의
  # 주석을 풀면 이 기능을 해제하고 모든 프록시가 문서들을 캐쉬할 수
  # 있도록 한다.
  #
  #CacheNegotiatedDocs

  이 설정은 Proxy Server를 거치는 사용자들을 위한 것이다. Proxy
  Server가 "교섭" 문서, 즉 CGI script의 출력이나 Server가 생성한 
  index page처럼 직접 수신되지 않는 문서를 cache 하도록 한다. 
  Default로 주석 처리 되어 있고 그냥 이대로 두면 된다.

  #
  # UseCanonicalName: (1.3 버전에 새롭게 등장) 이 설정을 켜두면,
  # 아파치가 자기 참조 URL(반응이 오고 있는 서버를 다시 가리키는
  # URL)을 만들 필요가 있을 때마다 "공식적인" 이름을 만들기 위해
  # ServerName과 Port를 사용한다.  그렇지 않으면 아파치는 가능한 한
  # 클라이언트가 제공한 호스트이름:포트 값을 사용한다.
  # 이 설정은 CGI 스크립트의 SERVER_NAME, SERVER_PORT에도 영향을
  # 미친다.
  #
  UseCanonicalName On

  #
  # TypesConfig 는 mime.types 파일 또는 이에 해당하는 파일을 찾을
  # 위치를 결정한다.
  #
  TypesConfig /etc/mime.types

  #
  # DefaultType이란 파일 확장자와 같은 것을 통해 MIME 타입을
  # 알 수 없는 문서에 대하여 사용할 기본 MIME 타입을 말한다. 
  # 여러분의 서버에 주로 텍스트나 HTML 문서가 많다면 
  # "text/plain"을 쓰는 것이 좋다. 대부분이 실행 프로그램이나
  # 이미지 등 바이너리인 경우에는 웹 브라우져가 텍스트라고
  # 생각하여 바이너리 파일을 화면에 표시하지 않도록 하기 위해 
  # "application/octet-stream"를 적는다.
  #
  DefaultType text/plain

  Server가 갖고 있지 않은 MIME type의 확장자가 있는 file을 client
  가 요청 했을경우 DefaultType의 MIME type이 사용된다. file
  확장자에서 MIME type으로의 map은 AddType 지시자로 추가할
  수도 있다.

  #
  # mod_mime_magic 모듈을 사용하면 파일의 내용을 가지고 파일의
  # 타입에 힌트를 얻는다.  MIMEMagicFile 지시자를 사용하여
  # 모듈에게 힌트 정보가 저장되어 있는 파일을 설정한다.
  # mod_mime_magic은 기본 서버의 일부가 아니다.(따라서
  # LoadModule 설정을 사용하여 모듈을 추가해야 한다.) 또는
  # 서버를 다시 컴파일해서 mod_mime_magic을 추가해야 한다.
  # 그렇기 때문에 <IfModule> 컨테이너에 포함되어 있는 것이다.
  # 다음 설정은 모듈이 서버에 포함되어 있을 때에만 MIMEMagicFile
  # 지시자를 처리하도록 해준다.
  #
  <IfModule mod_mime_magic.c>
      MIMEMagicFile conf/magic
  </IfModule>

  이것 역시 1.3.12에서 부터 새로 추가된 module이다. 사용을 하기
  위해서는 DSO 설정에서 mod_mime_magic line의 주석을 해제해야
  한다.

  #
  # HostNameLookups: 클라이언트의 이름 또는 IP 주소만을 기록할
  # 지 여부. 예를 들어 www.apache.org (on) 또는 
  # 204.62.129.132 (off) 기본값이 off 인 이유는 각 클라이언트 요청이
  # 올 때마다 최소한 1 번 이상의 네임 서버 요청이 발생하기 때문이다.
  #  그러나 꼭 필요한 경우에는 이 기능을 켜둔다.
  #
  HostnameLookups Off

  웹서버에 대한 접근을 도메인네임이나 ip주소 (on) 또는 ip주소
  만으로(off) 접근하게 할 것인지를 결정하는 것이다. Apache 
  1.3.4 부터 이 기능은 default가 off로 변경되었다. 이것이 off로 
  설정되어 있다고 해서 도메인으로 접근을 못하는 것은 아니다.
  다만 webserver에서 해당 request에 대한 도메인을 해석을 
  할것인지 안할 것인지를 지정하는 것이므로 그리 걱정은 하지
  않아도 상관이 없다. 대표적인 예로는 on으로 되어 있으면 
  log에 revers mapping이 가능한 ip address들은 domain 
  name으로 log를 남기며, 그렇지 않은 것들은 ip address로
  남기게 된다. off일 경우에는 무조건 ip address로 남게 된다.

  또한 이 지시자의 값이 Off일 경우에는 apache에서 제공하는
  Cookie인 REMOTE_HOST 역시 작동을 하지 않는다.

  #
  # ErrorLog: 에러 기록 파일의 위치.
  # <VirtualHost> 컨테이너 안에서 ErrorLog 설정을 하지
  # 않으면 그 가상 호스트에 관련된 에러 메시지도 역시 이 곳에
  # 기록된다. <VirtualHost> 컨테이너 안에서 에러 로그 파일을
  # 정의하면 관련된 에러 메시지는 그 파일로 저장된다.
  #
  ErrorLog logs/error_log

  Server에서 발생하는 error를 기록하는 log file을 지정한다.
  상대 경로로 지정을 하면 위의 Server Root의 값이 앞에 자동으로
  부여 된다.

  만약 ErrorLog를 남기고 싶지 않다면 /dev/null로 지정을 해 주면
  된다. 예: ErrorLog /dev/null

  #
  # LogLevel: error_log에 기록될 메시지 분량을 제어한다.
  # debug, info, notice, warn, error, crit, alert, emerg 등의
  # 값이 가능하다.
  # alert, emerg.
  #
  LogLevel warn

  #
  # 다음 지시자는 CustomLog 지시자(아래 참고)에서 사용할 몇 
  # 가지 형식에 대한 별명을 정의한다.
  #
  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

  #
  # 접근 로그 파일의 위치와 형식(공통 로그파일 형식)
  # <VirtualHost> 컨테이너 안에서 접근 로그파일 설정을 하지
  # 않으면 모든 기록이 이 파일에 남게 된다.  이와 반대로 각
  # <VirtualHost> 마다 접근 로그파일을 정의하면 모든 처리가
  # 바로 그 파일에 기록된다.
  #
  CustomLog logs/access_log common

  만약 CustomLog를 남기고 싶지 않다면 ErrorLog와는 달리 Log에
  대한 설정을 모두 주석 처리를 하면 된다. ErrorLog와 같이
  /dev/null로 설정을 해도 상관은 없다.


  #
  # 에이전트 로그파일과 참조자(referer) 로그파일을 갖기 위해서는
  # 다음 지시 내용의 주석 처리를 해제하라.
  #
  #
  # 여기서 에이전트란 여러분의 사이트에 방문하는 브라우져를 말한다.
  # 에이전트 로그를 남기면 여러분의 사이트에 방문하는 브라우져의
  # 종류에 대한 통계를 낼 수 있다.
  #
  # 참조자란 주로 배너 광고주에게 중요한 것으로서 여러분의 사이트
  # 바로 직전에 방문한 사이트를 말한다.
  #
  #CustomLog logs/referer_log referer
  #CustomLog logs/agent_log agent

  #
  # 하나의 로그파일에 접근, 에이전트, 참조자 정보를 다 저장하기
  # 위해서는 (통합 로그파일 형식) 다음 지시 내용을 사용하라.
  #
  # 몇 달만 운영해도 접속이 많은 사이트에서는 combined 로그 파일이
  # 어마어마하게 커져서 루트 파일 시스템을 꽉 채워 버리는 일이
  # 발생할 수 있다!
  #
  #CustomLog logs/access_log combined

  이 설정은 위의 CustomLog logs/referer_log referer, 
  CustomLog logs/agent_log agent 를 합쳐 놓은 것이라 
  생각하면 된다. 이 행의 주석을 풀어 주기 위해서는 위의 두행이 
  주석처리가 되어 있어야 한다. 

  #
  # 부차적으로 서버가 생성하는 페이지(에러 문서, FTP 디렉토리
  # 목록, mod_status, mod_info 출력 등, 그러나 CGI 생성 문서는 
  # 제외)에 서버 버전과 가상 호스트 이름을 포함하는 행을 추가
  # 하도록 한다. "Email"로 설정하면 ServerAdmin으로의 mailto:
  # 링크를 포함한다. On | Off | EMail 중 하나로 설정한다.
  #
  ServerSignature On

  역시 1.3.4에서 새로 추가된 module이다. 에러 메시지에 
  ServerName과 ServerAdmin을 표시해 줄수 있다.

  #
  # Aliases: 필요한 만큼의 별칭을 만들어 사용한다.(제한 없음)
  # 형식은 다음과 같다.
  # Alias 가짜이름 실제이름
  #
  # 가짜 이름 뒤에 / 를 포함하면 아파치 서버는 URL에도 / 이 있어야
  # 처리함을 잘 알아두자.  따라서 "/icons"는 별칭 처리되지 않고
  # "/icons/"만 별칭 처리된다.
  #
  Alias /icons/ "/home/httpd/icons/"

  <Directory "/home/httpd/icons">
      Options Indexes MultiViews
      AllowOverride None
      Order allow,deny
      Allow from all
  </Directory>

  #
  # ScriptAlias: 서버 스크립트를 포함하는 디렉토리를 제어한다.
  # ScriptAlias는 근본적으로 Alias와 같으나 가리키고 있는 실제
  # 디렉토리 안에 들어있는 문서를 실행 프로그램으로 취급하여
  # 실행한다. 맨 뒤에 붙는 "/" 에 대한 규칙은 Alias와 마찬가지이다.
  #
  ScriptAlias /cgi-bin/ "/home/httpd/cgi-bin/"

  서버에서 사용하는 cgi를 담은 디렉토리를 지정한다. 이 디렉토리의
  파일들은 서버에 의해 cgi스크립트로 인식되어 활성화 시켜준다.

  주의할 것은 ScriptAlias로 지정한 곳에서는 오로지 실행 파일만
  인식을 한다는 것이다. 일반 파일들은 권한 에러를 발생하게 된다.

  #
  # "/home/httpd/cgi-bin" 부분은 ScriptAlias로 별칭 처리된 실제 CGI
  # 디렉토리로 설정해야 한다.
  #
  <Directory "/home/httpd/cgi-bin">
      AllowOverride None
      Options ExecCGI
      Order allow,deny
      Allow from all
  </Directory>

  #
  # PUT 방법에 의한 업로드를 허용할 것인지 아닌지 결정을 한다.
  # 이 기능은 mod_put module을 dso로 설정을 해 놓아야지 가능하다.
  #
  <IfModule mod_put.c>
    Alias /upload /tmp
    <Location /upload>
       EnablePut On
       AuthType Basic
       AuthName "Upload Area"
       AuthUserFile /etc/httpd/conf/passwd
       EnableDelete Off
       umask 007
       <Limit PUT>
         require valid-user
       </Limit>
    </Location>
  </IfModule>

  #
  # Redirect를 사용하면 서버의 이름공간에 존재했으나 현재에는 
  # 존재하지 않는 문서에 대하여 클라이언트에게 통보할 수 있도록
  # 해준다.  이렇게 함으로써 위치가 변한 새로운 문서를 어디에서
  # 찾을 수 있는지 클라이언트에게 알려줄 수 있다.
  # 형식: Redirect 예전URI 새URI
  #

  자료파일을 url에 지정된 문서로 Redirect 한다.

  #
  # 서버가 생성하는 디렉토리 목록의 표시 상태를 제어하는 지시자.
  #

  #
  # FancyIndexing은 예쁜 디렉토리 목록 또는 표준적인 디렉토리
  # 목록 여부를 결정한다.
  #
  IndexOptions 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/*

  IndexOptions에서 FancyIndexing이 지정되었을 때 이 지시자는 
  file마다 MIME type에 따라 어떤 icon을 사용 할지 정한다.

  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^^

  Server가 file과 Directofy를 표시하는데 어떤 icon을 사용할 지 
  지정한다.

  #
  # DefaultIcon이란 명시적인 아이콘을 갖고 있지 않는 파일에 대한
  # 기본 아이콘 파일을 설정한다.
  #
  DefaultIcon /icons/unknown.gif

  #
  # AddDescription은 서버 자동 생성 인덱스의 파일명 뒤에 간단한
  # 설명을 넣을 때 사용한다.  FancyIndexing을 사용할 때에만 보인다.
  # 형식: AddDescription "설명" 화일명
  #
  AddDescription "GZIP compressed document" .gz
  AddDescription "tar archive" .tar
  AddDescription "GZIP compressed tar archive" .tgz

  # META 태그를 사용하여 Content-type의 charset을 설정하지 않은
  # 문서에 대하여 기본 문자셋을 iso-8859-1 로 해 버리는 패치에
  # 대한 설정. 1.3.12에서 추가됨.
  AddDefaultCharset Off
  #AddDefaultCharset euc-kr

  이 설정은 apache 1.3.12에 들어와서 Cross Site Scripting 보안 문제
  패치를 하면서 기본 글꼴을 iso-8859-1 로 하는 현상이 발생 하므로
  한글 사용을 위해서는 어쩌면 필요한 설정일지도 모른다. 일단 문제가
  없으면 그냥 놔두는 것도 괜찮을지 모르겠지만 문제가 된다면 설정을
  해보는 것도 괜찮을것 같다. 일단 필자의 테스트 로는 euc-kr로의
  설정은 문제가 발생한다.

  #
  # ReadmeName은 서버가 디렉토리 목록 뒤에 내용을 덧붙여 넣을
  # README 파일의 이름을 설정한다.
  #
  # HeaderName은 디렉토리 인덱스 앞에 내용을 덧붙일 파일명을 
  # 설정한다.
  #
  # 서버는 먼저 name.html을 찾고 그것이 있으면 그 내용을 포함
  # 한다. 만약 없다면 서버는 name.txt 파일을 찾고 평범한 텍스트 
  # 내용으로 추가한다.
  #
  ReadmeName README
  HeaderName HEADER

  디렉토리 목록을 보여줄 때 목록의 마지막 부분 뒤와 목록의 시작
  전에 보여줄 내용을 담고 있는 파일을 지정한다. 여기서는 목록의
  뒤에 README, 목록의 처음에 HEADER를 보여주게 지정되어 있다.

  #
  # IndexIgnore는 디렉토리 인덱싱에 있어 목록에서 제외시킬 파일
  # 명을 설정한다. 쉘 스타일의 와일드 카드를 사용할 수 있다.
  #
  IndexIgnore .??* *~ *  # HEADER* README* RCS CVS *,v *,t

  디렉토리를 출력할 때 무시할 파일들을 지정한다.

  #
  # AddEncoding은 특정 브라우져(모자익/X 2.1+)로 하여금 자료를
  # 받으면서 정보의 압축을 풀 수 있도록 해준다.  
  # 
  # 주의:  모든 브라우져가 이 기능을 지원하는 것은 아니다.  
  # 이름이 유사하기는 하지만 다음부터 나오게 될 Add로 시작하는
  # 지시자 들은 FancyIndexing과는 관련이 없다.
  #
  AddEncoding x-compress Z
  AddEncoding x-gzip gz

  압축 코드에 대한 인코딩정보를 지정한다.

  #
  # AddLanguage는 문서의 언어를 명시한다.  내용 협상 과정을 통해 
  # 브라우져가 이해할 수 있는 언어의 문서를 제공하는 것이 가능하다.
  # 접미어(suffix)는 언어 키워드와 꼭 같은 필요는 없다.  예를 
  # 들어 폴란드어(Polish)로 된 문서는 네트웍 표준 언어 코드가 pl 
  # 이지만 펄 스크립트와 확연히 구별하기 위해 "AddLanguage pl .po"
  # 라고 사용한다.
  #
  <IfModule mod_negotiation.c>
    AddLanguage ko .ko
    AddLanguage en .en
    AddLanguage fr .fr
    AddLanguage de .de
    AddLanguage da .da
    AddLanguage el .el
    AddLanguage it .it
  </IfModule>

  Server가 다국 언어로 문서를 제공한다면 이 지시자를 사용해 file 
  확장자를 언어를 지정 하는 약어에 대응시킨다. 언어의 약어는 보통 
  인터넷 국가 코드를 사용한다. client가 home.html이라는 file을 
  요청하면 browser는 프랑스어 사용자라는 것을 전하고 server는 
  이 지시자를 찾아서 어떤 file 확장자가 프랑스어 문서에 사용되는지 
  알아본다. 프랑스어 사용자라면 home.html.fr을 받게 된다. 다만 
  home.html이라는 file이 존재 한다면 home.html.fr을 받지 못하고 
  home.html을 받아 버리게 된다.

  #
  # LanguagePriority는 내용 협상 중 동점이 발생하는 경우 언어 
  # 우선권을 부여한다.  언어의 우선권을 내림차순으로 나열하면 된다.
  #
  <IfModule mod_negotiation.c>
    LanguagePriority ko en fr de
  </IfModule>

  site에 위에서 지정한 것과 같은 home.html.fr과 같은 문서가 있고 
  client가 언어를 선택하지 않고 home.html을 요청할때(home.html이 
  없을 경우) 서버가 보낼 문서를 지정한다. 이 지시자는 여러 언어를 
  내침 차순으로 나열한다.

  #
  # AddType를 사용하면 mime.types 파일 수정없이 MIME 설정을 할 수 
  # 있고 또는 어떤 파일들에 대하여 특정 타입으로 처리하도록 할 수 
  # 있다.
  #
  # 예를 들어, PHP3 모듈(아파치 배포파일에 포함되어 있지 않다)에
  # 대해서는 다음과 같이 사용한다.
  #
  <IfModule mod_php3.c>
    AddType application/x-httpd-php3 .php3 .ph .html .ins
    AddType application/x-httpd-php3-source .phps
  </IfModule>

  php3를 사용할 확장자를 지정하는 mime type이다. php3를 사용했을
  경우 웹상에서 source를 보여 주고 싶다면 xhttpd-php3-source mime
  type을 이용하면 된다.

  php는 확장 module이다. 그렇기 때문에 apache에 기본적으로 포함
  되어 있지는 않다. php를 사용하기 위해서는 php source를 구해서
  apache module로 compile을 하여 사용하여야 한다. Alzza user 같은
  경우에는 설치시에 mod_php package를 설치 하였다면 별 지장없이
  위의 주석만 풀어주고선 사용을 할 수가 있다.

  #다음은 PHP/FI (PHP2)를 위한 것이다.
  <IfModule mod_php.c>
    AddType application/x-httpd-php .phtml
  </IfModule>

  요즘은 잘 안쓰인다. 무시해 버리자..

  #
  # AddHandler를 사용하면 특정 파일 확장자와 "처리기"를 연결
  # 하거나 특정 파일 타입에 특정 동작(action)을 연결할 수 있다.
  # 서버에 내장되어 있거나 또는 Action 명령을 사용하여 추가할 수
  # 있다.(아래 참고)
  #
  # 서버 측 포함(SSI) 또는 ScriptAlias 처리된 디렉토리 외부에
  # 존재하는 CGI 스크립트를 사용하고 싶을 때는 다음 내용의
  # 주석을 없앤다.
  #
  # CGI 스크립트를 사용하기 위해:
  #
  #AddHandler cgi-script .cgi .pl .sh

  서버의 어떤 위치에 있던지 '.cgi' 확장자를 가진 파일은 
  cgi-script로 인식하게 한다. '.pl', '.sh' 등의 다른 확장자도 
  추가할 수 있다. 보안을 이유로 account user들에게 CGI 권한을 
  주지 않으려면 이행을 주석 처리해야 한다. 반대로 account user
  들에게 CGI권한을 주기 위해서는  이 행의 주석을 풀어 줘야 한다.

  #
  # 서버 처리 HTML 파일 사용하기 위해:
  #
  AddType text/html .shtml
  AddHandler server-parsed .shtml
  AddHandler text/x-server-parsed-html .html .txt

  Server Side Includes (SSI)를 사용할 때 필요하다. SSI는 HTML파일 
  속에 어떤 실행 프로그램의 결과나 특정 파일을 포함할 수 있게 한다.

  shtml 확장자가 아닌 파일에서도 SSI를 사용할 수 있게 하려면 위에서와
  같이 x-server-parsed-html mime type설정을 이용한다.

  #
  # 아파치의 send-asis HTTP 파일 기능을 사용하기 위해..
  #
  <IfModule mod_asis.c>
    AddHandler send-as-is asis
  </IfModule>

  #
  # 서버 처리 이미지 맵 파일을 사용하려면...
  #
  <IfModule mod_imap.c>
    AddHandler imap-file map
  </IfModule>

  #
  # type map을 사용하려면...
  #
  #AddHandler type-map var

  # perl 모듈을 사용하려면 다음 세션의 주석을 풉니다.
  #
  #Alias /perl/ /home/httpd/perl/
  #<Location /perl>
  #SetHandler perl-script
  #PerlHandler Apache::Registry
  #Options +ExecCGI
  #</Location>

  #
  # Action을 사용하면 매칭되는 파일이 호출될 때마다 그 미디어
  # 타입에 맞는 스크립트를 시행시킬 수 있다.  빈번하게 사용되는 
  # CGI 파일 프로세서에 대하여 반복적으로 URL을 사용하지 
  # 않아도 된다.
  # Format: Action media/type /cgi-script/location
  # Format: Action handler-name /cgi-script/location

  #
  # MetaDir: 아파치 서버가 메타 정보 파일을 찾을 디렉토리 이름.
  # 이 파일에는 문서를 보낼 때 추가하고자 하는 추가 HTTP 헤더 
  # 정보가 들어있다.
  #
  #MetaDir .web

  CERN HTTP 서버의 meta information을 emulate해 주는 부분이다. 
  자세한 내용은 CERN HTTP 서버문서를 읽어보길 바란다.

  #
  # MetaSuffix: 메타 정보를 담고 있는 파일의 접미어를 설정한다.
  #
  #MetaSuffix .meta

  #
  # 사용자 정의 에러 반응 메시지 (아파치 스타일)
  #  다음 3 가지 방법으로 가능하다.
  #
  #    1) 보통의 텍스트
  #ErrorDocument 500 "The server made a boo boo.
  #  주목: " 표시는 텍스트임을 알려주는 것으로서 그 자체는 출력
  #        되지 않는다.
  #    2) 지역적인 방향 전환
  #ErrorDocument 404 /missing.html
  #  지역적 URL인 /missing.html로 방향 전환하기
  #ErrorDocument 404 /cgi-bin/missing_handler.pl
  #  주목: 스크립트나 SSI로 방향 전환시킬 수 있다.
  #
  #    3) 외부 방향 전환
  #ErrorDocument 402 http://some.othercom.com/subscription.html
  #  주목: 원래 요청과 관련있는 환경 변수의 상당수가 스크립트에
  #  전달되지 못한다는 점을 알고 있어야 한다.

  서버에러에 대한 응답을 지정해 주는 부분이다. 각 에러 코드에 
  대한 응답을 cgi나 일반 텍스트로 만들어서 사용자에게 보여줄 
  수 있다. 어떤 서버에 접속하면 해당 URL이 없다는 등의 한글
  메시지가 가능한 것도 이것을 이용하는 것이다. 

  아래는 (2)번의 내부 redirects를 사용한 예이다. 나의 경험 상으
  로는 외부 방향 전환을 이용했을때 CGI와 htaccess 인증시에 505 
  Internal Server error가 발생 했다. 왜 그런지 이유는 잘 모르겠다. 
  내부 방향 전환에는 전혀 이상이 없었다. 

  ErrorDocument 400 /message/400error.html
  ErrorDocument 401 /message/401error.html
  ErrorDocument 403 /message/403error.html
  ErrorDocument 404 /message/404error.html
  ErrorDocument 405 /message/405error.html
  ErrorDocument 500 /message/500error.html
  ErrorDocument 501 /message/501error.html

  또는 스크립트를 이용하여 변수를 전달시킬수도 있다.

  ErrorDocument 400 /message/error.php?ecode=400
  ErrorDocument 401 /message/error.php?ecode=401
  ErrorDocument 403 /message/error.php?ecode=403
  ErrorDocument 404 /message/error.php?ecode=404
  ErrorDocument 405 /message/error.php?ecode=405
  ErrorDocument 500 /message/error.php?ecode=500
  ErrorDocument 501 /message/error.php?ecode=501

  #
  # 다음 지시자는 보통의 HTTP 반응 방식을 수정한다.
  # 첫번째 것은 네스케이프 2.x 또는 그를 흉내내는 브라우져에 
  # 대하여 KeepAlive 기능을 쓰지 않도록 한다.  이 브라우져들은 
  # KeepAlive 구현에 문제점을 갖고 있기 때문이다.
  # 두번째 것은 HTTP/1.1을 잘못 구현하였고 301 또는 302 (redirect)
  # 반응에 대하여 KeepAlive를 제대로 지원하지 못하는 Micro$oft
  # 인터넷 익스플로러 4.0b2를 위한 것이다.
  #
  BrowserMatch "Mozilla/2" nokeepalive
  BrowserMatch "MSIE 4\.0b2;" nokeepalive downgrade-1.0 \
                              force-response-1.0

  "\"는 한줄로 쓰라는 것을 의미하는 것이다.

  #
  # 다음은 기본적인 1.1 반응도 제대로 처리하지 못함으로써 HTTP/1.1 
  # 스펙을 위반하고 있는 브라우져에 대하여 HTTP/1.1 반응을 하지 
  # 않도록 한다.
  #
  BrowserMatch "RealPlayer 4\.0" force-response-1.0
  BrowserMatch "Java/1\.0" force-response-1.0
  BrowserMatch "JDK/1\.0" force-response-1.0

  #
  # BrowserMatch 지시자를 이용하여 User Agent별로 접근을 제어
  # 하도록 한다.
  #
  BrowserMatch "WebZIP" no_access
  BrowserMatch "Teleport" no_access
  BrowserMatch "NamoWebEditor" no_access
  BrowserMatch "WebTrack-HTTPP" no_access
  BrowserMatch "WebSymmetrix" no_access

  <Directory "/home/httpd/html/edu">
  AllowOverride None
  Options ExecCGI
  Order allow,deny
  Allow from all
  Deny from env=access_forbidden
  </Directory>

  이 부분은 기본적으로 들어 있는 설정이 아니다. Apache 문서를 
  참고하여 작성을 해본 예일 뿐이다. 이를 응용하면 접근을 막고 싶은 
  application들을 유용하게 막을 수가 있다. 위의 예제는 Teleport와 
  WebZIP을 이용하여 긁어 가는 것을 막고 있다. 일단 BrowserMatch 
  지시자로 환경 함수를 정의한 다음 <Directory> 지시자의 
  Limit부분에서 Deny부분을 설정을 해 주는 것이다.

  #
  # http://servername/server-status을 통해 서버 상태 보고를 허용한다.
  # 여기서 ".your_domain.com" 부분을 허용할 도메인으로 바꿔 사용하라.
  #
  <IfModule mod_status.c>
    <Location /server-status>
        SetHandler server-status
        Order deny,allow
        Deny from all
        Allow from localhost
        #Allow from all
        #AuthName "administrator Area"
        #Authtype Basic
        #AuthUserFile /home/.htpasswd
        #AuthGroupFile /dev/null
        #require valid-user
        #satisfy all
    </Location>
  </IfModule>

  서버의 상태결과를 http://servename/server-status의 URL에 접근 
  하면 볼 수 있게 해주는 옵션이다. 'allow from 서버 도메인네임'의 
  형식 으로 접근이 가능하다.

  하단의 주석 처리가 되어진 부분은 .htpasswd file에 기록되어 있는
  User와 Password로 인증을 하여 보게 하는 설정의 예이다.
  .htpasswd 인증을 위해서는 mod_auth.c 가 활성화되어 있어야 한다.

  그럼 여기서 살짝 꽁수를 써보도록 하겠다. 일정 ip address에서는
  ip address check만하고 인증을 안하도록 하고 다른 ip address에서
  는 인증을 하게 하는 방법을 설정해 보도록 하겠다.

  <IfModule mod_status.c>
    <Location /server-status>
        SetHandler server-status
        Order deny,allow
        Deny from all
        Allow from localhost
        AuthName "administrator Area"
        Authtype Basic
        AuthUserFile /home/.htpasswd
        AuthGroupFile /dev/null
        require valid-user
        satisfy any
    </Location>
  </IfModule>

  원래의 설정과 위의 설정과의 차이를 보도록 하면, 일단 원래의 설정에서
  주석 처리 되어 있는 부분이 모두 주석이 제거가 되어 있다. 그리고 제일
  마지막 option인 satisfy의 값이 all에서 any가 되어 있다. 이것이 바로
  키포인트이다. 즉 Allow from에 지정된 ip address나 domain name은 인증
  을 안하고 바로 보여주며, 그 외의 주소들은 /home/.htpasswd 에 있는 유
  저의 이름과 패스워드를 비교하여 인증을 해서 출력을 하게 된다.

  이것은 아래의 server-info에도 적용이 가능하다.

  #
  # http://servername/server-info를 통하여 원격 서버 설정 보고를 
  # 허용한다. 여기서 ".your_domain.com" 부분을 허용할 도메인으로
  # 바꿔  사용하라.
  #
  <IfModule mod_info.c>
    <Location /server-info>
        SetHandler server-info
        Order deny,allow
        Deny from all
        Allow from localhost
        #Allow from all
        #AuthName "administrator Area"
        #Authtype Basic
        #AuthUserFile /home/.htpasswd
        #AuthGroupFile /dev/null
        #require valid-user
        #satisfy all
    </Location>
  </IfModule>

  1.3.4 에서 부터 새로 추가된 module이다. 이 기능은 
  http://servername/server-info의 url으로 접근을 했을 경우 apache
  에서 실행이 가능한 module들의 목록등 apache의 전반적인 정보를 
  보여준다.

  #
  # 1.1 버전 이전의 오래 된 버그를 악용하려는 사람들이 있다는 보고를
  # 받았다. 이 버그는 아파치 일부분으로 제공한 CGI 스크립트와 연관
  # 있다. 이 부분의 주석 처리를 없애면 이 버그를 악용하는 공격이 있을
  # 때 phf.apache.org 상의 기록 스크립트로 방향 전환시킬 수 있다.
  # 또는 support/phf_abuse_log.cgi 스크립트를 사용하여 여러분 직접 
  # 기록할 수도 있다.
  #
  <Location /cgi-bin/phf*>
      Deny from all
      ErrorDocument 403 http://phf.apache.org/phf_abuse_log.cgi
  </Location>

  #
  # 프록시 서버 지시자.  프록시 서버 기능을 작동시키려면 다음 행의
  # 주석을 해제시켜준다.
  #
  <IfModule mod_proxy.c>
    #ProxyRequests On
    #
    #<Directory proxy:*>
    #    Order deny,allow
    #    Deny from all
    #    Allow from .your_domain.com
    #</Directory>

  #
  # HTTP/1.1 "Via:" 헤더를 처리할 것인지 여부를 결정한다.
  # ("Full"은 서버 버전을 포함하고 "Block"은 나가는 모든 자료에서
  # Via: 헤더를 제거한다.)
  # Off | On | Full | Block 중 하나의 값을 지정한다.
  #
    #ProxyVia On

  #
  # 캐쉬 기능도 사용하기 위해서는 다음 행의 주석을 풀어준다:
  # (CacheRoot가 없으면 캐쉬하지 않음)
  #
    #CacheRoot "/home/httpd/proxy"
    #CacheSize 5
    #CacheGcInterval 4
    #CacheMaxExpire 24
    #CacheLastModifiedFactor 0.1
    #CacheDefaultExpire 1
    #NoCache a_domain.com another_domain.edu joes.garage_sale.com

  </IfModule>
  # 프록시 설정 끝

  #  #  # 섹션 3: 가상 호스트
  #
  # VirtualHost: 여러분의 리눅스 박스에 여러 개의 도메인/호스트
  # 이름을 관리하고 싶다면 각각에 대하여 VirtualHost 컨테이너를 설정
  # 한다. 가상 호스트를 설정하기에 앞서 자세한 설명을
  # <URL:http://www.apache.org/docs/vhosts/>에 들러 읽어보기 바란다.
  # 가상 호스트 설정 내용을 점검해보기 위해서는 아파치를 실행할 때
  # 명령행 옵션으로 '-S'를 사용한다.

  #
  # 이름 기반의 가상 호스트를 사용하려면 사용할 IP 주소 (최소 1 개,
  # 그리고 포트 번호)를 정의해주어야 한다.
  #
  #NameVirtualHost 12.34.56.78:80
  #NameVirtualHost 12.34.56.78

  #
  # 가상 호스트 예제:
  # 거의 모든 아파치 지시자가 VirtualHost 컨테이너에 올 수 있다.
  #
  #<VirtualHost ip.address.of.host.some_domain.com>
  #    ServerAdmin webmaster@host.some_domain.com
  #    DocumentRoot /www/docs/host.some_domain.com
  #    ServerName host.some_domain.com
  #    ErrorLog logs/host.some_domain.com-error_log
  #    CustomLog logs/host.some_domain.com-access_log common
  #</VirtualHost>

  #<VirtualHost _default_:*>
  #</VirtualHost>