매달 1일에만 멈추는 업로드

10월 1일, 글에 쓸 이미지를 올리는데 워드프레스가 거절했습니다. “디렉터리 wp-content/uploads/sites/3/2026/10 생성 불가”라는 메시지였습니다. 디스크는 넉넉했고, 9월까지는 같은 작업이 아무 문제 없이 됐습니다. 바뀐 것은 달이 넘어간 것뿐이었습니다.

이상한 것은 같은 서버에 있는 다른 블로그였습니다. 같은 워드프레스 설치, 같은 PHP 프로세스를 쓰는 블로그 하나는 10월 1일 아침에 10월 폴더를 혼자 만들어 두고 멀쩡히 돌고 있었습니다. 코드가 같고 실행 사용자가 같은데 결과가 갈렸다면 원인은 코드 밖에 있습니다. 어디인지 찾아서 쟀습니다.

같은 설치, 같은 사용자, 갈린 결과

이 서버는 워드프레스 멀티사이트입니다. 블로그가 세 개 있고, 업로드 파일은 한 트리 안에 나뉘어 들어갑니다. 첫 번째 블로그는 uploads/2026/, 나머지는 uploads/sites/2/2026/와 uploads/sites/3/2026/입니다. 이 연도 폴더 세 개의 상태를 나란히 놓고 보니 차이가 한눈에 보였습니다.

연도 폴더	소유자	모드	10월 폴더
uploads/2026	apache:apache	2775	자동 생성됨
uploads/sites/2/2026	root:root	755	실패
uploads/sites/3/2026	root:root	755	실패

웹 서버와 PHP는 apache 사용자로 돕니다. 프로세스 목록을 세어 보면 httpd 3개와 php-fpm 5개가 모두 apache이고, FPM 풀 설정도 user = apache 한 줄뿐입니다. 그러니까 이미지를 올릴 때 폴더를 만드는 주체는 세 블로그 모두 같은 사용자입니다. 그런데 첫 번째 블로그의 연도 폴더는 그 사용자 소유에 그룹 쓰기가 열려 있고, 나머지 둘은 root 소유에 755입니다. 755는 소유자만 쓸 수 있다는 뜻입니다.

일곱 달 동안은 아무 일도 없었습니다

첫 번째 블로그의 월 폴더가 언제 만들어졌는지 생성 시각을 뽑아 봤습니다.

폴더	만들어진 시각
2026/04	4월 1일 11:37:23
2026/05	5월 1일 09:19:12
2026/06	6월 1일 10:28:24
2026/07	7월 1일 09:37:22
2026/08	8월 1일 09:40:37
2026/09	9월 1일 09:42:09
2026/10	10월 1일 09:05:52

일곱 달 연속으로 1일 오전에 만들어졌습니다. 전부 apache:apache 2775입니다. 손댄 적이 없으니 워드프레스가 그날 첫 업로드를 처리하면서 스스로 만든 것입니다. 이것이 정상 동작입니다.

워드프레스는 업로드 경로를 연·월로 나눠 둡니다. 매달 1일의 첫 업로드만 새 폴더를 필요로 하고, 그 뒤 한 달 동안은 이미 있는 폴더에 파일만 넣습니다. 그래서 권한이 어긋나 있어도 평소에는 아무 일도 일어나지 않고, 달이 바뀌는 날에만 터집니다. 9월까지 멀쩡했던 것은 9월 폴더가 이미 있었기 때문이지 권한이 맞았기 때문이 아닙니다.

범인은 폴더 한 칸이었습니다

추측을 멈추고 직접 만들어 봤습니다. 아직 오지 않은 11월 폴더를, 웹 서버와 같은 사용자 권한으로 세 자리에 각각 만들어 보는 것입니다.

시도한 경로	apache 권한	www 권한
uploads/2026/11	성공	성공
uploads/sites/2/2026/11	Permission denied	Permission denied
uploads/sites/3/2026/11	Permission denied	—

확인한 뒤 만들어진 폴더는 바로 지웠습니다. 결과는 분명합니다. 워드프레스도, PHP도, 플러그인도 아닙니다. 연도 폴더 한 칸의 소유자와 모드가 전부였습니다. 10월 1일의 실패 메시지는 “부모 디렉터리가 쓰기 가능한지 보라”고 정확히 알려 주고 있었는데, 저는 그 부모를 업로드 폴더 전체로 읽었습니다. 부모는 연도 폴더 하나였습니다. 로그가 알려 주는 것을 제대로 읽는 일에 대해서는 에러 로그를 열면 내 잘못은 몇 줄일까에서도 한 번 겪었습니다.

업로드 폴더 전체를 열 필요는 없습니다

권한 문제를 검색하면 거의 항상 “업로드 폴더를 755나 777로 바꾸라”는 답이 나옵니다. 그래서 반대 방향으로도 재 봤습니다. 업로드 트리의 맨 위인 uploads/ 자체는 root:root 755이고, 여기에 apache 권한으로 폴더를 만들어 보면 Permission denied가 납니다. 그런데도 첫 번째 블로그는 일곱 달 동안 멀쩡했습니다.

즉 맨 위를 열지 않아도 됩니다. 워드프레스가 매달 만들어야 하는 것은 연도 폴더 안의 월 폴더 하나뿐이고, 필요한 쓰기 권한도 그 연도 폴더 한 칸입니다. 트리 전체를 777로 여는 것은 문제를 고치는 것이 아니라 필요 없는 범위까지 같이 여는 것입니다.

2775의 가운데 숫자가 하는 일

잘 되는 쪽의 모드는 755가 아니라 2775였습니다. 앞자리 2는 setgid 비트입니다. 이 비트가 붙은 폴더 안에서 만들어진 파일과 폴더는 만든 사람의 그룹이 아니라 부모 폴더의 그룹을 물려받습니다.

이 서버에서는 그게 꼭 필요합니다. 업로드 트리에 쓰는 주체가 둘이기 때문입니다. 웹으로 올리면 apache가 쓰고, 명령줄 도구로 올리면 www가 씁니다. 실제 파일 소유자를 세어 보니 www:apache 484개, apache:apache 267개였습니다. 사용자는 둘로 갈렸지만 그룹은 전부 apache입니다. setgid가 없었다면 명령줄로 만든 파일은 그룹이 www가 되어 웹 서버가 읽지 못하는 파일이 생겼을 것입니다. 실제로 11월 폴더 생성 테스트에서도 www 권한으로 만든 폴더가 www:apache로 나왔습니다. 소유자는 만든 사람, 그룹은 부모에게서 온 것입니다.

업로드 폴더에 파일이 어떻게 불어나는지는 워드프레스가 만든 썸네일은 대부분 쓰이지 않는다에서 따로 셌습니다. 그 511개 파일이 모두 이 권한 규칙 위에 올라가 있습니다.

고친 조치가 다음 고장을 예약했습니다

10월 1일에 막혔을 때 저는 급한 대로 10월 폴더를 직접 만들어 넣었습니다. 발행은 그날 바로 됐고, 저는 해결했다고 적었습니다. 그런데 이번에 상태를 다시 재면서 알게 된 것이 있습니다.

두 블로그의 연도 폴더는 상태가 바뀐 시각이 10월 3일 01:59:20으로 같고, 그 안의 10월 폴더가 만들어진 시각도 같은 초입니다. 제가 폴더를 만든 그 작업이 연도 폴더를 root:root 755로 남겨 놓은 것입니다. 그 전에는 쓰기가 됐습니다. 9월 폴더가 9월 28일에 apache:apache 2775로 만들어져 있기 때문입니다. 손으로 만들어진 것이 아니라면 그때는 자동 생성이 되고 있었다는 뜻입니다.

막힌 달을 수동으로 뚫으면서, 다음 달에 같은 자리에서 다시 막히도록 만들어 놓은 셈입니다. 앞의 11월 폴더 생성 테스트가 Permission denied로 끝난 것이 그 증거입니다. 증상만 치우고 원인을 그대로 둔 조치는 고친 것이 아니었습니다.

고치고 나서 다시 쟀습니다

원인이 분명해졌으니 적용했습니다. 연도 폴더 두 개의 소유자를 웹 서버 사용자로 바꾸고 모드를 2775로 올렸습니다. root:root 755에서 apache:apache 2775가 됐습니다. 명령 두 줄이고, 파일은 하나도 건드리지 않았습니다.

바꾼 범위는 연도 폴더 두 칸뿐입니다. 그 위의 uploads/sites/와 각 블로그 폴더는 root:root 755 그대로 뒀습니다. 맨 위를 열지 않아도 된다는 것은 이미 첫 번째 블로그가 일곱 달 동안 보여 줬기 때문입니다.

고친 뒤 같은 테스트를 다시 돌렸습니다.

시도한 경로	고치기 전	고친 뒤
uploads/sites/2/2026/11	Permission denied	성공 (apache:apache, setgid)
uploads/sites/3/2026/11	Permission denied	성공 (apache:apache, setgid)

만들어진 폴더에는 setgid가 그대로 붙어 있었습니다. 부모에게서 물려받은 것입니다. 확인한 뒤 지웠고, 기존 월 폴더와 그 안의 파일은 소유자도 모드도 그대로입니다.

다만 이것은 아직 재현 테스트일 뿐입니다. 진짜 확인은 11월 1일입니다. 그날 첫 이미지를 올렸을 때 워드프레스가 폴더를 스스로 만들면 끝난 것이고, 또 막힌다면 제가 원인을 잘못 짚은 것입니다. 그날 다시 재서 적겠습니다.

어떻게 쟀는가

쓴 명령은 세 가지뿐입니다. 첫째, find로 업로드 트리의 디렉터리를 모두 뽑으면서 모드·소유자·시각을 같이 출력했습니다. 둘째, stat으로 연도 폴더와 월 폴더의 상태 변경 시각을 초 단위로 확인했습니다. 셋째, 웹 서버와 같은 사용자 권한으로 아직 오지 않은 달의 폴더를 실제로 만들어 보고, 결과를 확인한 뒤 지웠습니다.

프로세스 실행 사용자는 ps로, FPM 풀 설정은 설정 파일에서 직접 확인했습니다. 파일 소유자 분포는 find로 소유자만 뽑아 세었습니다. 고칠 때 쓴 것은 chown과 chmod 두 줄이고, 고친 뒤에는 같은 폴더 생성 테스트를 한 번 더 돌렸습니다. 추가로 설치한 도구는 없습니다.

자주 묻는 것

왜 매달 1일에만 실패합니까

워드프레스가 업로드 경로를 연/월로 나누기 때문입니다. 새 폴더를 만들어야 하는 순간은 그 달의 첫 업로드 한 번뿐이고, 그 뒤로는 이미 있는 폴더에 파일만 들어갑니다. 권한이 어긋나 있어도 평소에는 드러나지 않고, 달이 바뀌는 날에만 보입니다. 1일에 업로드를 하지 않으면 실제로 처음 올리는 날까지 미뤄집니다.

업로드 폴더를 777로 바꾸면 되지 않습니까

동작은 합니다. 다만 필요한 범위보다 넓습니다. 이 서버에서 확인한 바로는 업로드 트리의 맨 위는 root 소유 755로 두고 웹 서버가 쓸 수 없게 해도, 연도 폴더 한 칸만 맞으면 일곱 달 동안 자동 생성이 됐습니다. 고쳐야 할 자리가 한 칸이라면 한 칸만 고치는 편이 낫습니다.

setgid 비트는 꼭 필요합니까

업로드 트리에 쓰는 사용자가 하나면 없어도 됩니다. 둘 이상이면 필요합니다. 이 서버는 웹에서는 apache가, 명령줄 도구에서는 www가 같은 폴더에 파일을 만듭니다. setgid가 있어서 양쪽이 만든 파일의 그룹이 모두 apache로 통일되고, 그래서 어느 쪽이 만들었든 웹 서버가 읽을 수 있습니다. 실제 파일 751개의 소유자가 두 종류로 갈려 있는데도 문제가 없는 이유가 이것입니다.