FTP로 워드프레스 파일 올릴 때 꼭 확인할 것들

워드프레스를 쓰다 보면 결국 한 번은 FTP 클라이언트를 켜게 됩니다. 테마 zip 파일이 용량 제한에 걸려서 올라가지 않거나, 플러그인 하나 잘못 켰다가 관리자 화면이 통째로 안 열리거나, 예전 사이트에서 이미지 수천 장을 옮겨와야 하거나. 관리자 화면(wp-admin)은 워드프레스가 정상 동작할 때만 쓸 수 있는 도구라서, 워드프레스가 죽어 있으면 아무 소용이 없습니다. 그때 남는 유일한 통로가 파일 시스템에 직접 접근하는 FTP입니다.

문제는 FTP가 편한 만큼 위험하다는 점입니다. 관리자 화면 업로드는 워드프레스가 압축을 풀고, 위치를 정하고, 퍼미션을 맞춰줍니다. FTP는 그걸 전부 사람이 해야 합니다. 경로 하나 틀리면 아무 일도 안 일어나고, 전송 모드 하나 틀리면 이미지가 깨지고, 퍼미션을 잘못 주면 사이트 전체가 500 에러로 넘어갑니다. 그래서 “올리는 법”보다 “올릴 때 확인할 것”이 훨씬 중요합니다.

한눈에 · 접속 방식(FTP/FTPS/SFTP)과 포트 확인 → 웹 루트와 wp-content 경로 찾기 → 바이너리 모드로 전송 → 폴더 755 / 파일 644 퍼미션 적용 → 관리자 화면·프론트에서 인식 확인

왜 아직도 FTP로 파일을 올리게 되는가

워드프레스 관리자 화면에는 이미 업로드 기능이 다 있습니다. 외모 → 테마 → 새로 추가 → 테마 업로드, 플러그인 → 새로 추가 → 플러그인 업로드. 그런데도 FTP를 찾게 되는 상황은 대략 정해져 있습니다.

업로드 용량 제한: PHP의 upload_max_filesize, post_max_size 값보다 큰 zip은 올라가지 않습니다. “업로드한 파일이 php.ini의 upload_max_filesize 지시자보다 큽니다” 같은 메시지가 뜹니다. 공유호스팅은 이 값을 사용자가 못 바꾸는 경우가 흔합니다.
관리자 화면 자체가 안 열림: 플러그인 충돌로 500 에러나 백지 화면이 뜨면 wp-admin에 들어갈 수가 없습니다. 이때는 FTP로 해당 플러그인 폴더 이름을 바꿔서 강제로 끄는 게 사실상 유일한 응급 조치입니다.
대량 미디어 이관: 이미지 3천 장을 미디어 라이브러리에서 하나씩 올리는 건 현실적이지 않습니다.
테마 파일 한 줄 수정: 테마 편집기가 막혀 있거나(DISALLOW_FILE_EDIT), 편집기로 저장했다가 사이트가 죽은 경우 되돌릴 방법이 필요합니다.

여기서 핵심은 FTP는 웹서버(PHP)를 거치지 않고 파일 시스템에 직접 손대는 작업이라는 점입니다. 워드프레스가 알아서 해주던 압축 해제, 경로 배치, 소유자 설정을 전부 생략하고 파일만 툭 놓는 겁니다. 그래서 빠르고, 그래서 잘 깨집니다.

SSH를 쓸 수 있는 환경이라면 사실 FTP보다 scp나 rsync가 훨씬 편합니다. 다만 국내 저가 공유호스팅이나 무료 호스팅은 SSH를 열어주지 않는 곳이 많습니다. 그런 환경에서는 FTP가 유일한 파일 접근 수단입니다.

기본적으로 제일 많이 쓰는 FTP프로그램이 있습니다. 바로 FileZilla (www.filezilla-project.org) 입니다. 비영리단체에서 만드는 프로그램이라 무료이고, 누구나 다운 가능하고 워드프레스 파일 올리기엔 제일 적합한 프로그랩입니다.

시작 전 확인: FTP·FTPS·SFTP 중 무엇으로 붙고 있나

파일 시스템에 직접 손대는 일이라면, 그 통로부터 안전한지 보고 들어가는 게 순서입니다. 여기서 세 가지를 구분해야 합니다.

일반 FTP는 21번 포트를 쓰고, 아이디와 비밀번호가 암호화 없이 그대로 네트워크에 흘러갑니다. 카페 와이파이에서 접속하면 같은 망에 있는 사람이 계정 정보를 그대로 볼 수 있다는 뜻입니다. FTPS는 이 FTP에 TLS 암호화를 씌운 것으로, 포트는 그대로 21번을 쓰면서 접속 직후 AUTH TLS 명령으로 암호화를 시작합니다(명시적 FTPS). SFTP는 이름은 비슷하지만 완전히 다른 물건입니다. FTP와 아무 관계가 없고, SSH(22번 포트) 위에서 파일을 주고받는 방식입니다.

구분	기본 포트	암호화	서버 조건
FTP	21	없음(평문)	FTP 서버(vsftpd, ProFTPD 등)
FTPS	21 (제어) + 데이터 포트 범위	TLS	FTP 서버 + TLS 인증서 설정
SFTP	22	SSH로 전체 암호화	SSH 접속 허용 계정

선택 기준은 단순합니다. SFTP가 되면 SFTP, 안 되면 FTPS, 둘 다 안 되면 어쩔 수 없이 FTP. 마지막 경우라면 최소한 공용 와이파이에서는 접속하지 마세요.

포트 21과 22, 어느 쪽으로 붙어야 하나

접속이 안 될 때 의외로 흔한 원인이 포트 착오입니다. 호스팅사가 “SFTP 지원”이라고 안내했는데 클라이언트에서 프로토콜을 FTP로 두고 포트만 22로 바꾸면 붙지 않습니다. 프로토콜 자체를 SFTP로 바꿔야 합니다. 반대로 SFTP를 지원하지 않는데 22번으로 붙으려 하면 이런 메시지가 나옵니다.

Error: Connection refused
Error: Could not connect to server

즉 ECONNREFUSED는 “그 포트에서 아무도 안 듣고 있다”는 뜻입니다. 반면 Connection timed out은 응답 자체가 없는 것으로, 방화벽에서 조용히 버리고 있을 가능성이 큽니다. 회사 네트워크에서 21번을 막아두는 경우가 꽤 있습니다.

호스팅사 안내 페이지에서 확인할 항목은 네 가지입니다. 호스트명(도메인 또는 IP), 포트, 프로토콜, 그리고 접속 IP 제한 여부. 마지막 항목을 놓치면 아이디·비밀번호가 맞는데도 계속 로그인이 실패합니다.

수동 모드로 바꿔야 하는 순간

FTP에는 능동(Active)과 수동(Passive) 모드가 있습니다. 한 줄로 정리하면, 데이터 연결을 서버가 내 쪽으로 거느냐(능동), 내가 서버 쪽으로 거느냐(수동)의 차이입니다. 요즘은 대부분의 사용자가 공유기와 방화벽 뒤에 있어서, 서버가 내 쪽으로 거는 능동 모드는 거의 실패합니다.

증상이 아주 특징적입니다. 로그인은 성공했다고 나오는데 파일 목록에서 멈춥니다.

Status: Connection established, waiting for welcome message...
Status: Logged in
Status: Retrieving directory listing...
Command: LIST
Error: Connection timed out after 20 seconds of inactivity
Error: Failed to retrieve directory listing

이 로그가 나오면 십중팔구 전송 모드 문제입니다. FileZilla에서는 편집 → 설정 → 연결 → FTP에서 전송 모드를 수동으로 바꿉니다. 사이트별로 다르게 주고 싶으면 파일 → 사이트 관리자에서 해당 사이트를 고르고 전송 설정 탭에서 “수동”을 선택하면 됩니다. 프로토콜과 암호화 선택은 같은 창의 일반 탭에 있습니다.

어디에 올려야 하나: 워드프레스 디렉터리 구조 이해하기

접속이 됐다면 다음 관문은 경로입니다. 여기서 틀리면 두 가지 중 하나가 벌어집니다. 아무 일도 안 일어나거나, 사이트가 죽거나.

먼저 웹 루트를 찾아야 합니다. 호스팅사마다 이름이 다릅니다. public_html, www, htdocs, html, 계정 폴더 아래 도메인 이름 폴더 등. 이름으로 추측하지 말고 내용으로 판단하세요. index.php와 wp-config.php, 그리고 wp-admin / wp-includes / wp-content 세 폴더가 같이 보이는 곳이 진짜 워드프레스 루트입니다.

/home/hosting_users/myaccount/www/
├── index.php
├── wp-config.php
├── wp-login.php
├── .htaccess
├── wp-admin/
├── wp-includes/
└── wp-content/
    ├── themes/
    ├── plugins/
    └── uploads/

여기서 wp-admin과 wp-includes는 워드프레스 코어입니다. 원칙적으로 손대지 않습니다. 수정해봐야 다음 업데이트 때 통째로 덮어써져서 날아갑니다. 커스터마이징은 전부 wp-content 안에서 합니다.

테마와 플러그인 올리는 위치

경로는 딱 정해져 있습니다.

테마: wp-content/themes/테마이름/
플러그인: wp-content/plugins/플러그인이름/

가장 많이 하는 실수는 zip 파일을 그대로 올려두는 겁니다. wp-content/plugins/wordfence.zip을 올려놓고 관리자 화면에서 아무리 새로고침해도 목록에 안 뜹니다. 워드프레스는 plugins 폴더 안의 폴더를 스캔하고, 그 안에서 플러그인 헤더 주석이 들어 있는 PHP 파일을 찾습니다. 반드시 압축을 풀어서 폴더째로 올려야 합니다.

또 하나. zip을 풀었더니 폴더가 이중으로 겹치는 경우가 있습니다.

잘못됨: wp-content/plugins/wordfence-7.11.0/wordfence/wordfence.php
올바름: wp-content/plugins/wordfence/wordfence.php

압축 해제 후 폴더 안에 들어가서, PHP 파일들이 바로 보이는 그 폴더를 올려야 합니다.

미디어(uploads)는 폴더 구조가 중요하다

wp-content/uploads/ 는 조금 다릅니다. 워드프레스 기본 설정은 연/월 폴더로 나눠 저장합니다.

wp-content/uploads/2026/02/photo-01.jpg
wp-content/uploads/2026/02/photo-01-300x200.jpg
wp-content/uploads/2026/02/photo-01-1024x683.jpg

이 구조를 무시하고 uploads/ 바로 아래에 파일을 던지면, 나중에 DB에 기록된 경로와 어긋납니다. 다른 사이트에서 미디어를 이관하는 중이라면 원본과 똑같은 연/월 구조를 유지하세요. 리사이즈된 파일(-300x200 같은 것)도 같이 옮겨야 썸네일이 깨지지 않습니다.

그리고 중요한 점 하나. FTP로 이미지를 uploads에 넣어도 미디어 라이브러리에는 안 뜹니다. 미디어 라이브러리는 파일 시스템이 아니라 DB(wp_posts 테이블의 attachment 레코드)를 봅니다. 라이브러리에 등록하려면 “Add From Server”나 “Media Sync” 같은 플러그인으로 스캔을 돌려야 합니다. 다만 글 본문에서 URL로 직접 참조하는 이미지는 등록 없이도 잘 보입니다.

파일이 깨지는 진짜 이유: 전송 모드와 한글 파일명

경로도 맞고 파일도 올라갔는데 뭔가 이상하다면, 대개 이 두 가지 중 하나입니다.

바이너리와 ASCII, 언제 무엇을 쓰나

FTP에는 전송 모드가 두 가지 있습니다. ASCII 모드는 텍스트 파일을 옮기면서 줄바꿈 문자를 서버 방식에 맞게 바꿔줍니다(윈도우 CRLF → 유닉스 LF). 바이너리 모드는 아무것도 건드리지 않고 바이트 그대로 옮깁니다.

여기서 사고가 납니다. 이미지나 zip 파일을 ASCII 모드로 올리면 파일 중간의 0x0D 바이트가 변조되어 파일이 손상됩니다. 그림은 열리지 않고, zip은 “압축 파일이 손상되었습니다”가 뜹니다. FTP에서는 파일이 멀쩡히 보이는데 브라우저에서 이미지가 깨지거나 404처럼 안 나오는 전형적인 원인입니다.

파일 종류	권장 모드	ASCII로 올렸을 때 증상
.jpg .png .gif .webp	바이너리	이미지 안 열림, 일부만 표시
.zip .tar.gz .pdf	바이너리	압축 해제 실패, 파일 손상
.php .css .js .html	어느 쪽이든 대체로 무방	줄바꿈만 변환, 보통 문제없음
.php (헤더 앞 공백 민감)	바이너리 권장	드물게 BOM/공백으로 헤더 에러

결론은 간단합니다. 고민하지 말고 바이너리로 고정하세요. FileZilla에서는 편집 → 설정 → 전송 → 파일 형식에서 “바이너리”를 선택합니다. 기본값인 “자동”도 확장자 목록을 보고 판단하기 때문에 대부분 잘 동작하지만, 확장자가 없는 파일이나 .htaccess 같은 건 헷갈릴 수 있습니다.

파일 크기가 0바이트로 올라간 경우도 자주 봅니다. 원인은 둘 중 하나입니다. 전송 중 연결이 끊겼거나(로그에 Critical file transfer error가 남습니다), 계정 용량이 꽉 찼거나. 후자라면 서버에서 이런 게 나옵니다.

Error: 552 Disk full - please upload later

용량은 호스팅 관리 페이지에서 확인하는 게 빠릅니다. 0바이트 파일은 반드시 지우고 다시 올리세요. 덮어쓰기가 안 되는 경우가 있습니다.

한글 파일명은 되도록 피하는 편이 낫다

제품사진 (최종).jpg 같은 파일명은 여러 단계에서 문제를 일으킵니다. FTP 클라이언트의 문자셋, 서버 파일 시스템의 문자셋, 웹서버의 URL 인코딩이 전부 맞아떨어져야 정상 표시됩니다. 하나라도 어긋나면 FTP 목록에서 ????????.jpg나 ?쒗뭹?ъ쭊.jpg 처럼 깨져 보입니다.

FileZilla에서 문자셋을 강제하려면 사이트 관리자 → 해당 사이트 → 문자셋 탭에서 “사용자 지정 문자셋”을 고르고 UTF-8 또는 EUC-KR을 입력합니다. 서버가 어느 쪽인지 모르면 둘 다 시도해 보는 수밖에 없습니다. 오래된 국내 호스팅은 EUC-KR인 경우가 남아 있습니다.

가장 확실한 해결책은 애초에 안 쓰는 겁니다. 영문 소문자, 숫자, 하이픈만. 공백과 괄호도 URL에서 %20, %28로 인코딩되면서 문제를 만듭니다. product-photo-final.jpg 정도로 통일하는 게 나중에 덜 고생합니다.

올린 다음이 진짜 문제: 소유자와 퍼미션

전송까지 잘 끝냈는데 사이트가 안 되는 경우, 여기서 막히는 사람이 가장 많습니다.

리눅스에서 모든 파일은 소유자(owner)와 그룹(group), 그리고 접근 권한(permission)을 가집니다. FTP로 올린 파일의 소유자는 FTP 계정입니다. 그런데 웹서버(Apache/Nginx)와 PHP는 보통 다른 계정으로 돕니다. www-data, apache, nobody, 또는 호스팅사에서 만든 별도 계정. 이 소유자 불일치가 FTP 업로드 후 생기는 대부분의 권한 문제의 근원입니다.

FTP만 쓸 수 있는 환경에서는 소유자를 바꿀 수 없습니다(chown은 보통 root 권한이 필요합니다). 대신 퍼미션을 조정해서 다른 계정도 읽을 수 있게 만드는 겁니다.

폴더 755, 파일 644를 한 번에 적용하기

워드프레스 공식 권장 기준은 이렇습니다.

대상	퍼미션	의미
디렉터리 전체	755	소유자 읽기·쓰기·실행, 나머지는 읽기·실행
파일 전체	644	소유자 읽기·쓰기, 나머지는 읽기만
wp-config.php	640 또는 600	DB 비밀번호가 들어 있어 더 조임
.htaccess	644	워드프레스가 퍼머링크 저장 시 수정

FileZilla에서 일괄 적용하는 방법은 이렇습니다. 대상 폴더를 우클릭 → 파일 권한 → 숫자값 입력 → “하위 디렉터리로 재귀 적용” 체크. 여기서 반드시 주의할 게 있습니다. 바로 아래에 “모든 파일과 디렉터리에 적용 / 파일에만 적용 / 디렉터리에만 적용” 라디오 버튼이 있습니다.

이걸 나눠서 두 번 실행해야 합니다.

숫자값 755 입력 + 재귀 적용 + 디렉터리에만 적용
숫자값 644 입력 + 재귀 적용 + 파일에만 적용

한 번에 755를 전부 적용하면 PHP 파일까지 실행 권한이 붙습니다. 반대로 644를 전부 적용하면 폴더에 실행 권한이 사라져서 그 안으로 들어갈 수 없게 되고, 사이트가 통째로 500 에러로 넘어갑니다. 이건 복구가 번거로우니 순서를 꼭 지키세요.

SSH가 되는 환경이라면 이게 훨씬 간단합니다.

cd /var/www/html
find . -type d -exec chmod 755 {} \;
find . -type f -exec chmod 644 {} \;
chmod 640 wp-config.php

find 명령의 조건별 일괄 처리가 익숙하지 않다면 find로 파일 찾아 한 번에 처리하기, -exec와 xargs 실전 정리를 같이 보면 이해가 빠릅니다.

777로 풀면 왜 안 되나

퍼미션 문제로 헤매다 보면 결국 777 이야기를 만납니다. 777은 소유자·그룹·기타 사용자 모두에게 읽기·쓰기·실행을 전부 허용하는 값입니다. 되긴 됩니다. 문제가 사라지는 것처럼 보입니다.

그런데 공유호스팅은 한 서버에 수십, 수백 개의 계정이 같이 삽니다. 777로 풀린 디렉터리는 같은 서버의 다른 계정에서도 쓰기가 가능하다는 뜻입니다. 누군가 그 폴더에 PHP 백도어를 하나 심어두면 끝입니다. 실제로 워드프레스 해킹 사례에서 uploads 폴더가 777로 열려 있고 그 안에 정체불명의 .php 파일이 있는 경우를 흔하게 봅니다.

많은 호스팅사는 777 디렉터리에서 PHP 실행을 거부하도록 설정해 두기도 합니다. 그래서 777로 바꿨더니 오히려 500 에러가 나는 경우도 있습니다. 755와 644로 안 되면 원인은 퍼미션이 아니라 소유자입니다. 호스팅 고객센터에 문의하는 게 맞습니다.

관리자 화면이 자꾸 FTP 정보를 물어볼 때

플러그인을 설치하려는데 워드프레스가 FTP 호스트명·아이디·비밀번호를 입력하라고 하는 화면이 뜰 때가 있습니다. 이건 워드프레스가 “내가 이 파일에 직접 쓸 권한이 없구나”라고 판단했기 때문입니다. 웹서버 실행 계정과 파일 소유자가 다를 때 나타납니다.

임시 우회는 wp-config.php에 아래 한 줄을 추가하는 겁니다.

define('FS_METHOD', 'direct');

이건 “무조건 직접 파일 시스템에 쓰겠다”는 선언입니다. 실제로 권한이 없으면 이번엔 에러가 납니다. 근본 해결은 소유자를 웹서버 계정으로 맞추는 것이고, 그건 SSH나 호스팅사 지원이 필요합니다. wp-config.php에 넣을 만한 다른 설정들은 wp-config.php 필수 설정 12가지, 보안과 성능 한 번에 점검하기에 정리해 뒀습니다.

자주 만나는 에러 메시지와 대처

앞에서 다룬 원인들이 실제로는 어떤 문장으로 튀어나오는지 모아 봤습니다. 검색해서 왔다면 아마 이 중 하나를 보고 있을 겁니다.

530 Login authentication failed 로그인 실패입니다. 순서대로 확인하세요. ① 아이디·비밀번호 오타(복사할 때 앞뒤 공백 주의) ② 호스트명이 맞는지 — 도메인이 다른 서버를 가리키고 있을 수 있으니 호스팅사가 준 IP나 ftp.도메인 형태로 시도 ③ 접속 IP 제한 설정 ④ FTP 계정이 비활성 상태이거나 만료. 비밀번호에 특수문자가 많으면 클라이언트가 잘못 처리하는 경우도 드물게 있습니다.

550 Permission denied / 550 Failed to open file 접속은 됐는데 그 파일에 접근할 권한이 없습니다. 대상 파일의 퍼미션과 소유자를 확인하세요. 관리자 화면에서 자동 설치한 플러그인 폴더는 웹서버 계정 소유라서 FTP 계정으로 삭제·수정이 안 될 수 있습니다. 이 경우 FTP로는 방법이 없고 관리자 화면에서 삭제해야 합니다.

553 Could not create file 파일을 만들려는 그 위치, 즉 상위 디렉터리에 쓰기 권한이 없습니다. 파일이 아니라 폴더 퍼미션을 보세요. 그리고 경로가 실제로 존재하는지도 확인하세요. 없는 폴더에 파일을 올리려 해도 같은 메시지가 납니다.

ECONNREFUSED / Connection timed out 앞서 말한 대로, 전자는 포트가 안 열려 있는 것이고 후자는 응답 자체가 없는 것입니다. 포트 번호, 프로토콜, 회사·공유기 방화벽, 그리고 수동 모드 설정을 차례로 점검하세요.

Critical file transfer error가 반복될 때 연결이 불안정하거나 서버가 동시 접속 수를 제한하고 있습니다. FileZilla 설정 → 전송에서 최대 동시 전송 수를 1~2로 줄이고, 설정 → 연결에서 재시도 횟수를 늘려 보세요. 대용량 파일 하나를 올리는 중이라면 이 값 조정만으로 해결되는 경우가 많습니다.

업로드 후 화면이 백지일 때 백지(White Screen of Death)는 PHP 치명적 오류가 났는데 에러 출력이 꺼져 있는 상태입니다. 원인을 보려면 디버그 로그를 켜야 합니다. wp-config.php에 아래를 넣습니다.

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

그러면 wp-content/debug.log 파일에 에러가 쌓입니다. FTP로 내려받아 마지막 몇 줄을 보면 대개 어떤 파일 몇 번째 줄이 문제인지 바로 나옵니다. 문제를 잡은 뒤에는 WP_DEBUG를 다시 false로 되돌리세요. 관리자 화면 자체에 못 들어가는 상황이라면 워드프레스 관리자 로그인 안 될 때, 원인별 복구 순서 정리의 순서를 같이 따라가면 됩니다.

실무 팁과 대안: FTP를 언제까지 써야 하나

에러를 다 잡았다면, 이제는 애초에 덜 다치는 방식으로 옮겨갈 차례입니다.

대량 업로드는 zip으로

파일 3천 개를 FTP로 개별 전송하면 정말 오래 걸립니다. FTP는 파일 하나마다 별도의 데이터 연결을 열고 닫기 때문입니다. 파일 개수가 많을수록 이 연결 오버헤드가 전송 시간을 지배합니다. 실제 데이터는 얼마 안 되는데 시간만 몇 시간씩 갑니다.

해결책은 로컬에서 zip 하나로 묶어 올리고, 서버에서 푸는 겁니다. 대부분의 호스팅 관리 패널에는 파일 관리자가 있고 거기에 압축 해제 기능이 있습니다. cPanel이면 File Manager → 파일 선택 → Extract. SSH가 되면 더 간단합니다.

cd ~/public_html/wp-content/uploads
unzip media-backup.zip
rm media-backup.zip

파일 하나로 묶으면 연결이 한 번만 열리기 때문에, 같은 용량이라도 전송 시간이 몇 배 차이 납니다.

수정 전 백업 습관

FTP로 뭔가 덮어쓰기 전에는 반드시 원본을 남기세요. 특히 wp-config.php와 테마 폴더. 방법은 거창할 필요 없습니다. 서버에서 다운로드한 뒤 로컬에 wp-config.php.bak 처럼 날짜 붙여 보관하면 됩니다.

주의할 점 하나. 백업 파일을 서버 웹 루트에 남기면 안 됩니다. wp-config.php.bak이나 wp-config.old는 확장자가 .php가 아니라서 PHP로 처리되지 않고 텍스트 그대로 브라우저에 표시됩니다. DB 비밀번호가 그대로 노출됩니다. 백업은 로컬로 내려받으세요. 파일과 DB를 함께 챙기는 절차는 워드프레스 백업, 파일과 DB 둘 다 챙기는 실전 순서에 정리해 뒀습니다.

그리고 테마 파일을 직접 고치는 습관은 버리는 게 좋습니다. 테마가 업데이트되면 수정한 내용이 전부 사라집니다. 자식 테마(child theme)를 만들어서 거기서 덮어쓰는 게 정석입니다.

파일 전송 방식 비교

방식	적합한 상황	장점	단점
FTP/FTPS	SSH 불가한 공유호스팅	GUI로 직관적, 어디서나 지원	느림, 파일 많으면 비효율
SFTP	SSH 계정이 있을 때	암호화, FTP와 사용법 동일	SSH 허용 필요
rsync over SSH	반복 배포, 대량 동기화	변경분만 전송, 압도적으로 빠름	CLI, SSH 필수
Git 배포	코드 형상 관리가 필요한 팀	이력 관리, 롤백 용이	초기 세팅 필요, 미디어에는 부적합

FTP 계정 자체도 관리 대상입니다. 접근 범위를 웹 루트 하위로만 제한하고(홈 디렉터리 밖으로 못 나가게), 협업자에게 만들어 준 계정 중 안 쓰는 건 삭제하세요. 살아 있는 FTP 계정은 그 자체로 공격 표면입니다.

솔직히 말하면, 워드프레스를 계속 운영할 생각이라면 SSH가 되는 호스팅으로 옮기는 게 장기적으로 훨씬 편합니다. rsync 한 줄이면 끝날 일을 FTP로 30분씩 씨름하는 건 낭비입니다.

자주 묻는 질문

FTP로 플러그인을 올렸는데 관리자 화면 플러그인 목록에 안 뜹니다

먼저 zip 파일 그대로 올려두지 않았는지 확인하세요. 압축을 풀어서 폴더째로 wp-content/plugins/ 아래에 있어야 합니다. 두 번째로 폴더 중첩을 확인하세요. plugins/플러그인명/플러그인명/파일.php 구조면 인식되지 않습니다. 세 번째로 퍼미션입니다. 폴더가 755가 아니면 웹서버가 그 안을 읽지 못합니다. 이 세 가지가 다 맞는데도 안 뜨면 플러그인 메인 PHP 파일 상단의 헤더 주석이 손상됐을 수 있으니 다시 내려받아 올려 보세요.

워드프레스 파일 퍼미션은 몇으로 해야 하나요? 777로 해도 되나요?

디렉터리 755, 파일 644가 기준입니다. wp-config.php는 640이나 600까지 조여도 대부분 정상 동작합니다. 777은 하지 마세요. 공유호스팅에서는 같은 서버의 다른 계정이 그 폴더에 파일을 심을 수 있고, 실제 해킹 경로로 자주 쓰입니다. 게다가 많은 호스팅사가 777 디렉터리에서 PHP 실행을 막아두기 때문에 오히려 500 에러가 나기도 합니다.

FTP로 이미지를 uploads 폴더에 넣으면 미디어 라이브러리에도 자동으로 보이나요?

아니요. 미디어 라이브러리는 DB의 첨부파일 레코드를 읽어서 보여줍니다. 파일만 올려서는 등록되지 않습니다. 라이브러리에 넣고 싶으면 “Add From Server” 같은 스캔 플러그인을 쓰거나, WP-CLI가 되는 환경이면 wp media import 명령을 씁니다. 다만 글 본문에 이미지 URL을 직접 넣어 쓰는 경우라면 라이브러리 등록 없이도 잘 표시됩니다.

접속은 되는데 파일 목록이 안 뜨고 멈춥니다

거의 확실히 능동/수동 모드 문제입니다. Retrieving directory listing... 에서 멈추고 Failed to retrieve directory listing으로 끝나면 수동(Passive) 모드로 바꿔 보세요. FileZilla는 편집 → 설정 → 연결 → FTP에서 바꿉니다. 그래도 안 되면 회사나 학교 네트워크에서 FTP 데이터 포트 범위를 막고 있을 수 있습니다. 휴대폰 테더링으로 붙어 보면 네트워크 문제인지 금방 판별됩니다.

FTP와 SFTP 중 무엇을 써야 하나요? 호스팅에서 SFTP를 지원 안 하면?

SFTP가 되면 무조건 SFTP입니다. 평문 전송을 피할 수 있고 별도 데이터 포트 문제도 없습니다. SFTP를 지원하지 않으면 FTPS(명시적 TLS)를 시도해 보세요. 21번 포트를 그대로 쓰면서 암호화만 추가하는 방식이라 지원하는 곳이 꽤 있습니다. 둘 다 안 되면 일반 FTP를 쓰되, 공용 와이파이에서는 접속하지 말고 FTP 비밀번호를 다른 서비스와 다르게 설정하세요.

wp-config.php를 FTP로 수정했더니 사이트가 백지가 됐습니다

가장 흔한 원인은 파일 맨 앞이나 맨 뒤의 여분 공백·줄바꿈입니다. <?php 앞에 공백이 하나라도 있으면 “headers already sent” 에러로 이어집니다. 파일 끝의 닫는 태그 ?>도 지우는 게 안전합니다. 두 번째 원인은 BOM(Byte Order Mark)입니다. 윈도우 메모장으로 저장하면 붙습니다. 편집은 VS Code나 Notepad++로 하고 인코딩을 “UTF-8 (BOM 없음)”으로 지정하세요. 백업본이 있다면 그걸 되올리는 게 가장 빠릅니다.

업로드 전후 체크리스트

지금까지 짚은 것들을 실제 작업 순서대로 다시 배열했습니다. 작업 전에 한 번 훑고 시작하세요.

올리기 전

[ ] 덮어쓸 파일·폴더의 백업본을 로컬에 저장했다
[ ] 접속 프로토콜과 포트를 확인했다 (SFTP 22 / FTPS·FTP 21)
[ ] 전송 모드를 바이너리로 설정했다
[ ] 목록 조회가 멈추면 수동 모드로 전환했다
[ ] 파일명에 한글·공백·괄호가 없다
[ ] zip은 압축을 풀었고, 폴더 중첩이 없다

올린 직후

[ ] 파일 크기가 0바이트인 게 없다
[ ] 경로가 wp-content/themes/, wp-content/plugins/, wp-content/uploads/ 아래가 맞다
[ ] uploads는 연/월 폴더 구조를 지켰다
[ ] 디렉터리 755 / 파일 644 적용 (재귀 적용은 디렉터리·파일 따로 두 번)
[ ] wp-config.php는 640 또는 600

확인

[ ] 관리자 화면 테마·플러그인 목록에 나타난다
[ ] 프론트 화면에서 이미지가 정상 로드된다
[ ] wp-content/debug.log에 새 에러가 없다
[ ] 브라우저 개발자도구 콘솔에 404가 없다

문제가 생겼을 때 되돌리는 순서

방금 올린 파일을 지우고 백업본으로 되돌립니다.
여전히 안 되면 FTP로 wp-content/plugins/문제플러그인/ 폴더 이름을 문제플러그인_off 로 바꿉니다. 워드프레스가 해당 폴더를 못 찾으면 플러그인을 자동으로 비활성화합니다. 관리자 화면에 다시 들어갈 수 있게 됩니다.
어떤 플러그인이 원인인지 모르겠으면 plugins 폴더 자체를 plugins_off로 바꿔 전부 끕니다. 관리자 화면에 들어가지면 이름을 되돌린 뒤 하나씩 켜면서 범인을 찾습니다.
테마가 원인 같으면 테마 폴더 이름을 바꿉니다. 워드프레스가 기본 테마(twentytwentyfour 등)로 자동 전환합니다. 기본 테마가 없으면 이 방법이 안 통하니 미리 하나 남겨 두세요.
그래도 백지면 WP_DEBUG_LOG를 켜고 wp-content/debug.log를 확인합니다.

FTP 작업은 되돌릴 방법을 미리 손에 쥐고 시작하는 게 전부입니다. 백업 하나만 제대로 있으면 대부분의 사고는 5분 안에 원복됩니다.