.htaccess 생성기
웹사이트를 위한 일반적인 .htaccess 규칙을 생성합니다. 필요한 옵션을 선택하고 생성된 코드를 복사하세요.
Performance
Security
• The .htaccess file should be placed in the root directory of your website
• Make sure mod_rewrite is enabled on your Apache server
• Always backup your existing .htaccess file before replacing it
• Some hosting providers may restrict certain .htaccess directives
.htaccess 생성기 사용 방법
- 1
도메인 입력
example.com 같은 도메인 이름을 Domain Settings 입력란에 입력하세요.
- 2
규칙 선택
Force HTTPS, www 강제 또는 제거, GZIP 압축, 핫링크 방지, 사용자 지정 오류 페이지처럼 필요한 옵션을 선택하세요.
- 3
리디렉션 추가
URL 리디렉션의 경우 이전 경로와 새 경로를 입력하고 영구(301) 또는 임시(302) 리디렉션을 선택하세요.
- 4
복사 또는 다운로드
Copy to Clipboard 또는 Download .htaccess를 사용해 파일을 사이트의 루트 디렉터리에 업로드하세요.
Apache .htaccess 파일 완전 정복
.htaccess 파일이 실제로 하는 일
.htaccess 파일은 Apache 웹 서버를 위한 디렉터리별 구성 파일입니다. Apache가 AllowOverride를 켠 상태로 빌드되면, 서비스 중인 디렉터리에 있는 .htaccess 파일과 그 위 모든 상위 디렉터리의 .htaccess 파일을 읽어 해당 요청에 지시문을 적용합니다. 덕분에 메인 서버 구성을 건드리거나 Apache를 재시작하지 않고도 서버 동작, 리디렉션, 캐싱, 접근 제어 등을 바꿀 수 있습니다. 변경 사항은 바로 다음 요청부터 적용되며, 메인 구성에 접근할 수 없는 공유 호스팅에서 .htaccess가 그토록 편리한 이유가 바로 이것입니다.
파일 이름은 말 그대로 .htaccess로, 앞에 점이 붙고 확장자가 없으며, 유닉스 계열 시스템에서는 이 점 때문에 숨김 파일이 됩니다. 이 파일은 동작을 바꾸고 싶은 디렉터리에 두며, 가장 흔하게는 사이트의 문서 루트에 둡니다. 루트의 규칙은 더 깊은 곳의 .htaccess가 재정의하지 않는 한 사이트 전체에 적용됩니다.
Apache 전용: Nginx 등은 무시한다
규칙을 한 줄이라도 쓰기 전에 가장 먼저 확인할 것은 이것입니다. .htaccess는 Apache 기능입니다. 또 다른 주요 웹 서버인 Nginx는 설계상 .htaccess 파일을 전혀 읽지 않으며 앞으로도 그러지 않습니다. 사이트가 Nginx에서 돌아간다면 루트에 .htaccess를 넣어도 아무 일도 일어나지 않으며, 동등한 리디렉션, 재작성, 헤더는 대신 Nginx 서버 블록에 표현해야 합니다. LiteSpeed와 몇몇 Apache 호환 서버는 .htaccess 구문을 이해하지만, Nginx, Caddy, IIS는 각각 자체 구성 형식을 씁니다.
어떤 서버를 쓰는지 확실치 않다면 Server 응답 헤더를 확인하세요. 이 사이트의 HTTP Header Viewer로 볼 수 있습니다. 거기에 Apache가 보이면 .htaccess가 동작한다는 확인이고, nginx가 보이면 이 파일로는 방향을 잘못 잡은 것입니다.
mod_rewrite를 이용한 리디렉션과 정규화
.htaccess의 가장 흔한 임무는 URL 리디렉션이며, 이는 RewriteEngine On 블록으로 감싼 mod_rewrite 모듈을 통해 이루어집니다. 단순한 영구 이동에는 이전 경로에서 새 경로로 가는 Redirect 301을 쓰고, RewriteRule은 정규 표현식을 이용한 패턴 기반 리디렉션을 처리합니다. 거의 모든 사이트가 필요로 하는 두 가지 정규화 작업은 단일 호스트 이름 강제(항상 www이거나 항상 www 없음)와 HTTPS 강제인데, 둘 다 들어오는 요청을 검사하는 RewriteCond에 이어 정규 버전으로 301을 발급하는 RewriteRule로 이루어집니다.
계속 유지할 이동에는 언제나 301(영구)을 쓰세요. 301은 링크 가치를 목적지로 전달하고 검색 엔진에 색인을 갱신하라고 알리기 때문입니다. 미묘하지만 중요한 점은 리디렉션 사슬을 피하는 것입니다. http://example.com 을 먼저 https://example.com 을 거쳐 튕기지 말고, 한 번에 https://www.example.com 으로 곧장 보내세요. 한 번씩 더 거칠 때마다 지연 시간이 늘고 순위 신호가 조금씩 희석되는데, 이 사이트의 Redirect Chain Checker가 그것을 찾아내는 데 도움이 됩니다.
성능: 압축, 캐싱, 그리고 AllowOverride 비용
두 가지 .htaccess 기능이 즉각적인 성능 향상을 줍니다. mod_deflate로 구성하는 GZIP 압축은 HTML, CSS, JavaScript 같은 텍스트 기반 응답을 보내기 전에 줄여 주며, 흔히 전송 크기를 60~80퍼센트까지 줄입니다. mod_expires나 mod_headers를 통해 Cache-Control과 Expires 헤더로 설정하는 브라우저 캐싱은 브라우저에게 이미지와 글꼴 같은 정적 자산을 방문할 때마다 다시 내려받지 말고 재사용하라고 알립니다. 이 둘은 함께 쓰면 들이는 노력 대비 효과가 가장 큰 속도 개선에 속합니다.
다만 .htaccess 자체에 숨은 비용이 있습니다. Apache는 모든 요청의 경로를 따라 모든 디렉터리에서 .htaccess 파일을 확인해야 하므로, AllowOverride를 켜 두면 요청마다 파일 시스템 조회가 더해집니다. 직접 관리하는 트래픽 많은 사이트라면 이 지시문을 메인 서버 구성으로 옮기고 AllowOverride None으로 설정하는 편이 측정 가능할 만큼 더 빠릅니다. 공유 호스팅에서는 보통 선택의 여지가 없고 편리함이 그 부담을 상쇄하지만, 성능이 중요한 서버에서 .htaccess가 권장되지 않는 이유를 알아 둘 가치는 있습니다.
보안, 오류 페이지, 접근 제어
리디렉션과 성능을 넘어 .htaccess는 사이트를 단단히 하고 다듬는 데 널리 쓰입니다. ErrorDocument 지시문으로 설정하는 사용자 정의 오류 페이지는 삭막하기 쉬운 기본 Apache 오류 화면을 404와 500 응답에 맞는 브랜드 페이지로 바꿔 주며, 이는 사용자와 보안 양쪽에 더 낫습니다. 핫링크 보호는 Referer 헤더에 대한 RewriteCond를 이용해 다른 사이트가 내 이미지를 끼워 넣고 내 대역폭을 소모하는 것을 막습니다. 또한 Header 지시문을 통해 X-Frame-Options, Content-Security-Policy, Strict-Transport-Security 같은 보안 헤더를 보낼 수 있습니다.
접근 제어 측면에서 .htaccess는 IP 주소로 디렉터리를 제한하거나 .htpasswd로 비밀번호를 요구할 수 있고, 콘텐츠 관리 시스템에서 사용자 이름을 캐내려는 작성자 열거 스캔을 차단할 수 있습니다. 이런 제어는 정말 유용하지만, Apache가 정상 경로로 요청을 처리할 때만 동작한다는 점을 기억하세요. .htaccess에만 의존하지 말고 제대로 된 애플리케이션 수준 보안과 함께 쓰세요.
구문은 봐주지 않는다: 믿기 전에 테스트하라
.htaccess의 가장 큰 위험은 구문 오류가 보통 조용히 실패하지 않는다는 점입니다. 대신 해당 디렉터리 아래 모든 페이지에 500 Internal Server Error를 일으켜, 파일을 고칠 때까지 사이트 전체를 다운시킵니다. 컴파일 단계도, 배포 전 검증도 없으므로 오타 하나, 빠진 모듈 하나, 호스트가 비활성화한 지시문 하나가 순식간에 모든 것을 망가뜨릴 수 있습니다. Apache 지시문은 순서에도 민감합니다. 재작성 규칙은 위에서 아래로 평가되며, 구체적인 규칙 앞에 둔 넓은 규칙이 구체적인 규칙이 잡아야 할 요청을 삼켜 버릴 수 있습니다.
안전한 작업 방식은 변경하기 전에 항상 기존 .htaccess를 백업하고, 트래픽이 적은 시간대에 변경을 배포하며, 배포 직후 사이트를 즉시 불러와 여전히 응답하는지 확인하는 것입니다. 500 오류가 보이면 먼저 백업을 복원하고 디버깅은 그다음에 하세요. 어떤 지시문이 mod_rewrite나 mod_deflate 같은 모듈에 의존한다면, 빠진 모듈에 대한 규칙은 오류를 낼 수 있으니 호스트가 그 모듈을 활성화했는지 확인하세요.
자주 묻는 질문
이 생성기는 어떤 규칙을 만들 수 있나요?
301 리디렉션과 302 리디렉션의 차이는 무엇인가요?
생성된 .htaccess 파일은 어디에 두나요?
Nginx나 다른 서버에서도 작동하나요?
생성된 코드가 어딘가로 전송되나요?
관련 도구
이런 편리한 도구도 함께 사용해 보세요