WordPress 파일 전송: SFTP로 사이트 파일 관리하기

사이트 파일을 고쳐야 하는데 전송 프로그램에 수십 개의 폴더가 보인다면, 첫 질문은 ‘지금 어디에 연결했는가’여야 합니다. WordPress 계정, 호스팅 제어판 계정, 파일 전송 계정은 서로 독립적일 수 있습니다. 관리자 화면 암호를 안다고 안전한 파일 관리 방법까지 확보한 것은 아닙니다.

작은 스튜디오 사이트의 유지보수를 맡아 자식 테마의 스타일 파일을 교체하면서 복구 가능성을 남기는 상황을 예로 듭니다. 아래는 공식 문서를 바탕으로 정리한 작업 제안입니다. 독자의 서버에 연결한 것이 아니며, 모든 호스팅 업체가 같은 경로나 권한을 쓴다고 가정하지도 않습니다.

호스팅 업체에서 완전한 연결 정보 받기

FTP는 전송 프로토콜이고 SFTP는 SSH로 연결을 암호화하며, FTPS는 TLS로 FTP를 보호합니다. 이름은 비슷하지만 연결 방식은 다릅니다. 호스트가 SFTP를 지원하면 우선 사용하세요. FTPS를 제공한다면 호스팅 문서에 따라 암호화 방식을 설정하고, 연결하기 위해 암호화하지 않은 FTP로 바꾸지는 마세요.

필요한 정보는 서버 주소, 포트, 사용자 이름, 인증 방식, 접근 가능한 폴더, 호스트 키 지문입니다. 포트는 제어판이 제공하는 번호를 사용하세요. 사이트 도메인이 CDN을 가리킬 수 있으므로 그대로 SFTP 호스트라고 간주해서는 안 됩니다. 운영 사이트와 테스트 사이트의 연결 이름도 구분해 잘못 연결할 가능성을 줄이세요.

키 인증을 사용한다면 서버에는 공개 키를 설정하고 개인 키는 보호된 컴퓨터에 둡니다. 개인 키나 전체 연결 설정을 여러 사람이 있는 그룹에 보내지 마세요. 외주 작업에는 호스팅 관리자에게 범위를 좁힌 개별 계정을 요청하고 종료 후 회수하는 방법을 상담할 수 있습니다. 최고 권한 계정을 장기간 공유하지 않도록 하세요.

사이트 관리자로 연결을 만들고 신원 확인하기

FileZilla를 예로 들면 파일 메뉴에서 사이트 관리자를 열고 새 사이트를 만든 다음 SFTP를 선택해 주소, 포트, 지정된 로그인 방식을 입력합니다. IP 주소만 적지 말고 ‘스튜디오 테스트 사이트’처럼 알아보기 쉬운 이름을 쓰세요. 처음 연결할 때 호스트 키 알림이 나오면 관리자에게 받은 지문과 먼저 비교합니다.

지문은 원격 서버의 신원을 확인하는 것이며 자신의 로그인용 공개 키가 아닙니다. 처음 표시된 값 자체가 신뢰성을 입증하지는 않습니다. 호스팅 제어판이나 신원이 확인된 관리자로부터 비교할 정보를 받아야 합니다. 사용하던 연결에서 지문이 바뀌었다는 알림이 갑자기 나오면 이전이나 서버 교체일 수도, 잘못된 호스트에 연결된 것일 수도 있습니다. 이유를 파악한 후 계속하세요.

1. 호스팅 제어판에서 계정이 어느 사이트에 속하는지 확인하고 문서 루트 경로를 기록합니다.
2. 사이트 관리자에서 프로토콜과 로그인 방식을 명확하게 선택하고 기본값에 결정을 맡기지 않습니다.
3. 호스트 키를 확인한 뒤 우선 폴더를 둘러보고, 아직 파일을 끌어 올리거나 전체 폴더를 동기화하지 않습니다.

사이트 루트를 찾고 파일과 데이터베이스 구분하기

로그인하면 보통 왼쪽은 로컬, 오른쪽은 원격입니다. public_html이나 www가 보인다고 반드시 대상 사이트인 것은 아닙니다. 호스팅 환경이 여러 도메인이나 분리된 폴더를 사용할 수 있습니다. 제어판에 지정된 경로와 대조하고 wp-admin, wp-includes, wp-content 같은 WordPress 폴더가 있는지 확인하세요. 의문이 있으면 변경부터 멈춥니다.

테마와 플러그인은 보통 wp-content의 해당 하위 폴더에 있고, 실제 미디어 파일은 uploads에 있는 경우가 많습니다. 글, 사용자, 여러 설정은 데이터베이스에 저장되므로 사이트 폴더를 다운로드한다고 데이터베이스가 자동으로 내보내지지는 않습니다. 사진을 uploads에 직접 넣어도 미디어 라이브러리에 완전한 첨부 파일 정보가 생기는 것은 아닙니다.

먼저 파일과 데이터베이스의 전체 백업을 준비한 뒤 이번에 바꿀 파일 하나도 따로 다운로드하세요. 백업은 보호된 로컬 위치에 두고 원래 경로와 날짜를 보관합니다. 암호가 있는 설정 파일을 .bak이나 텍스트 파일로 이름만 바꿔 공개 폴더에 남기면 사이트에서 다운로드될 수 있으므로 그렇게 하지 마세요.

한 번에 명확한 대상 하나만 수정하기

디자인을 조정한다면 수정할 위치가 자식 테마인지 먼저 확인하세요. 부모 테마나 플러그인의 원본 파일을 직접 바꾸면 업데이트로 덮어써질 수 있습니다. 관리자 화면 설정으로 가능한 변경은 프로그램 파일을 수정할 필요가 없습니다. 꼭 편집해야 한다면 로컬에서 적절한 일반 텍스트 편집기를 사용하고 원래 확장자와 인코딩을 유지하세요.

업로드 전에 파일 이름, 원격 전체 경로, 파일 크기, 원본 버전을 비교하세요. 로컬 사이트 전체를 운영 사이트 루트에 끌어다 놓거나 원격의 추가 파일을 무조건 삭제하는 동기화 모드를 선택하지 마세요. 사용 중인 미디어나 다른 사람이 방금 갱신한 파일이 삭제될 수 있습니다.

전송이 끝나면 대기열에 실패한 항목이 있는지 확인하세요. 큰 플러그인이나 여러 파일로 구성된 프로그램 업데이트를 절반만 올리면 사이트에 새 버전과 이전 버전이 섞일 수 있습니다. 이런 작업은 정식 업데이트 또는 배포 절차를 사용해야 합니다. 스타일 파일 하나의 변경은 테스트 사이트에서 먼저 검증한 뒤 합의한 시간에 적용할 수 있습니다.

권한이 부족하면 소유자와 호스팅 규칙부터 확인하기

흔한 Linux 구성에서는 폴더 755, 일반 파일 644를 출발점으로 사용하지만, 공식 문서도 호스팅 환경마다 사용자와 그룹 구성이 다름을 강조합니다. 숫자가 만능 복구 방법은 아니며 관리형 플랫폼이 일부 파일을 의도적으로 보호할 수도 있습니다. 쓰기가 거부되면 계정 범위, 파일 소유자, 디스크 할당량, 대상 경로부터 확인하세요.

사이트 전체를 777로 설정하거나 파일 하나의 문제 때문에 모든 폴더의 권한을 재귀적으로 바꾸지 마세요. wp-config.php 같은 설정 파일은 더 신중한 접근 관리가 필요하며 실제 값은 호스팅 실행 방식에 따라 정해야 합니다. 오류 시각과 민감한 정보를 가린 경로를 고객 지원에 제공하면 무작정 권한을 넓히는 것보다 문제를 빨리 찾을 수 있습니다.

FileZilla에 .htaccess처럼 점으로 시작하는 파일이 보이지 않으면 숨김 파일 표시 설정과 서버 제한부터 확인하세요. 목록에 없다는 이유로 같은 이름의 빈 파일을 만들어 덮어쓰지 마세요. 숨김 파일이 리디렉션이나 접근을 제어할 수 있으며, 누락되면 백업도 불완전해집니다.

복구할 수 있는 방식으로 작업 마무리하기

수정 후 공개 화면과 관리자 화면을 다시 열어 실제로 영향을 받은 페이지를 확인하세요. 스타일 변경은 모바일 너비에서도 검사하고 필요하면 관련 캐시를 지웁니다. 전송 성공 메시지만 보아서는 안 됩니다. 화면이 깨지거나 프로그램 오류가 나오면 다른 원인 모를 변경을 더하기 전에 원본 파일을 복원하고 검증하세요.

변경 기록에는 적어도 시각, 사이트, 파일 경로, 수정 목적, 검증 결과, 원본 위치를 적으세요. 파일을 복원하면 해당 파일 내용만 돌아오며 동시에 발생한 주문이나 데이터베이스 업데이트까지 자동으로 복구되지는 않습니다. 유지보수를 마친 뒤 연결을 닫고 임시 계정과 로컬 민감 파일이 인계 규칙에 맞게 관리되는지 확인하세요.

자세한 설명 보기

호스트 확인, 원본 다운로드, 제한된 범위의 업로드, 공개 화면 검증을 네 개 상자로 보여주는 도식.

파일과 데이터베이스 전체 백업 만들기

웹사이트 500 오류 점검 방법

• 튜토리얼
• 앱·소프트웨어
• 웹사이트·이커머스
• WordPress