SVN 주소를 브라우저에 넣었는데도 checkout이나 update가 막히면, 보통은 “URL이 틀렸나?”부터 떠올리게 된다.
이전 Tech(KR) 글: VirtualBox 화면 크기 자동 조절 안 될 때, Guest Additions부터 VMSVGA까지
그런데 웹으로 보이는 화면과 SVN 클라이언트가 확인하는 경로는 완전히 같은 검사가 아니다.
이번에는 설치 방법보다, 웹 접속 오류를 URL 매핑·인증·경로 권한으로 나눠 보는 순서부터 정리해본다.
먼저 오류를 한 덩어리로 고치려 하지 않는 편이 훨씬 안전하다.
핵심 요약
- SVN 웹 주소가 열려도 Subversion 클라이언트의 WebDAV 요청까지 정상이라는 뜻은 아니다. 먼저 읽기 전용 확인으로 URL과 응답을 분리해 본다.
- 한 저장소를 노출하는
SVNPath와 여러 저장소를 URL 아래에 매핑하는SVNParentPath는 주소 구조가 다르다. - 401은 신원 확인 단계, 403은 경로 권한 단계, 404는 대개 URL 매핑 단계, 301은 Apache의 위치 설정 충돌 가능성을 먼저 살펴볼 신호다.
- 설정을 바꾸기 전에는 실제 SVN URL, Apache의
Location경로, 저장소 이름, 접근하려는 하위 경로를 같은 문자열로 적어 비교하는 것이 좋다.
브라우저 화면과 SVN 클라이언트는 같은 검사가 아니다
Apache로 공개한 Subversion 저장소는 mod_dav_svn을 통해 HTTP 위의 WebDAV/DeltaV 요청을 처리한다. 그래서 웹 브라우저에서 어떤 페이지가 열렸다는 사실만으로 저장소 URL, 인증 도전, 디렉터리 목록, 경로별 읽기 권한까지 전부 확인됐다고 보기는 어렵다.
가장 먼저는 실제 사용하려는 URL로 읽기 전용 조회를 해 본다. 예를 들어 svn info https://호스트/접두어/저장소 또는 svn ls https://호스트/접두어/저장소처럼, 쓰기 동작이 아닌 조회 명령으로 URL과 서버 응답을 확인할 수 있다. 이 글에서는 어떤 서버에도 명령을 실행하거나 설정을 바꾸지 않았다.
이 단계에서 중요한 건 비밀번호를 반복해서 바꾸는 일이 아니다. URL, 반환 코드, 인증 창이 뜨는지, 어느 하위 경로에서 막히는지를 함께 남겨야 다음 판단이 흔들리지 않는다.
먼저 URL 매핑을 한 문장으로 적어 본다
Apache 설정의 Location은 요청 URL의 접두어를 정하고, 그 안에서 DAV svn이 Subversion 백엔드로 넘긴다. 저장소 하나를 직접 연결할 때는 SVNPath를, 여러 저장소를 같은 접두어 아래에 둘 때는 SVNParentPath를 쓰는 구조가 대표적이다.
예를 들어 URL이 https://svn.example.com/svn/team-repo라면, /svn이 Apache의 Location인지, team-repo가 상위 디렉터리 아래의 저장소 이름인지부터 분명해야 한다. 이 구분이 흐리면 클라이언트에는 404처럼 보이지만, 실제 원인은 저장소가 없는 것이 아니라 웹 URL과 서버 매핑이 어긋난 경우일 수 있다.
이때 확인할 값은 네 가지면 충분하다. 사용 중인 정확한 URL, Apache의 Location 경로, SVNPath 또는 SVNParentPath 값, 그리고 저장소의 실제 이름이다. 이 네 값을 복사해 한 줄씩 맞춰 보면 오타와 접두어 중복을 훨씬 빨리 찾는다.
401·403·404·301을 같은 오류로 묶지 않는다
401 또는 인증 창 반복은 Apache가 사용자를 식별하는 단계에서 막혔을 때 먼저 보는 신호다. 인증 방식, 사용자 파일 또는 인증 제공자, 그리고 클라이언트가 접근한 URL의 인증 영역을 관리자에게 확인한다. Require valid-user는 해당 Location에 인증된 사용자를 요구하도록 만드는 설정이다.
403은 로그인 자체가 성공했더라도 그 저장소 또는 하위 경로의 읽기 권한이 부족할 때 나타날 수 있다. Subversion의 AuthzSVNAccessFile은 저장소 안의 경로별 접근 규칙을 읽으므로, “로그인됐다”와 “그 폴더를 읽을 수 있다”는 별개의 판정이다. 특정 팀 폴더만 막힌다면 이 층을 먼저 본다.
404는 URL 접두어·저장소 이름·Location 매핑을 다시 대조할 시점이다. 반면 301은 같은 URL 공간을 Apache의 DocumentRoot와 SVN Location이 함께 해석하는 구성 충돌에서도 생길 수 있다. 응답 코드를 보고 문제 층을 좁히면 설정을 여러 군데 동시에 바꾸는 실수를 줄일 수 있다.
권한 파일은 로그인 뒤에 다시 한 번 판단한다
Apache의 기본 인증 설정은 “누구인지”를 확인하고, mod_authz_svn의 경로 기반 규칙은 “그 사용자가 어디까지 읽고 쓸 수 있는지”를 판단한다. 따라서 팀원이 루트 저장소에는 들어가지만 특정 프로젝트 디렉터리에서만 실패한다면, 계정 생성 여부보다 그 경로의 authz 규칙과 그룹 포함 관계를 점검하는 쪽이 맞다.
반대로 익명 읽기를 허용하는 구성이라면 인증 창이 뜨지 않는다고 해서 권한 정책이 없다는 뜻은 아니다. 익명 읽기와 인증된 쓰기, 또는 민감한 하위 경로만 인증 요구 같은 혼합 정책도 가능하다. 운영 중인 정책을 단순화하려고 무심코 전체 익명 접근이나 전체 쓰기를 열면 안 된다.
안전하게 확인하는 순서
- 문제가 난 정확한 SVN URL과 시각, 401·403·404·301 같은 응답 또는 클라이언트 오류 문구를 기록한다.
- 쓰기 명령 대신 읽기 전용 조회로 동일 URL을 확인한다. 인증 정보를 명령줄이나 공유 문서에 남기지 않는다.
- 관리자 권한이 있는 사람이 Apache의
Location,SVNPath/SVNParentPath, 저장소 이름을 순서대로 대조한다. - 인증이 통과한 뒤에도 막히면 authz 규칙에서 저장소와 하위 경로, 사용자 또는 그룹의 읽기 권한을 확인한다.
- 한 번에 하나의 설정만 바꾸고, 같은 읽기 전용 확인을 반복한다. 해결을 위해 권한을 넓히는 방식은 마지막 수단이어야 한다.
이 순서는 장애를 자동으로 고치는 방법이 아니라, 원인을 한 층씩 좁히는 방법이다. 특히 운영 저장소에서는 현재 설정 백업, 변경 승인, Apache 오류 로그 확인 같은 조직의 운영 절차를 먼저 따른다.
Appendix. SVN URL에서 자주 헷갈리는 두 경로
웹 주소의 /svn 같은 접두어는 Apache가 요청을 받아들이는 Location일 수 있고, 그 뒤의 /team-repo는 실제 저장소 이름일 수 있다. 그 안의 /trunk나 /branches는 다시 저장소 내부 경로다. 세 층을 구분하지 않으면 저장소 이름을 경로처럼 쓰거나, 반대로 내부 경로를 서버 매핑 문제로 오해하기 쉽다.
예전 서버 구축 글의 명령을 그대로 복사하기보다, 현재 Apache와 Subversion 버전, 인증 제공자, 프록시 유무, 조직의 접근 정책을 먼저 확인하는 편이 안전하다. 이 글은 매수·매도 추천이 아니라 운영 문제를 읽기 위한 기술 정보다.
출처 및 업데이트
- 2026-10-07 확인: Version Control with Subversion — Apache HTTP Server configuration
- 2026-10-07 확인: Apache Subversion Quick Start
- 2026-10-07 확인: Apache Subversion FAQ
