웹사이트에 Storage Server 활용하기: 이미지, 다운로드, 아카이브
웹 서버의 저장 공간은 비싸고, Storage Server의 저장 공간은 그렇지 않습니다. 이 글에서는 무엇을 옮길 수 있는지, 웹 서버에서 어떤 프로토콜이 동작하는지, 그리고 파일이 방문자에게 안전하게 도착하는 방법을 정리했습니다.
웹 서버에서 가장 비싼 자원은 디스크 공간입니다. 데이터베이스와 PHP를 위해 만들어진 빠른 NVMe SSD 위에 놓여 있고, 기가바이트가 늘어날수록 비용이 뚜렷하게 올라갑니다. 그런데 바로 그곳에 그 속도를 전혀 필요로 하지 않는 것들이 놓여 있습니다. 원본 사진, 영상 파일, 다운로드 아카이브, 오래된 백업입니다.
Storage Server는 그 비용의 일부만 들면서 바로 그 부담을 덜어 줍니다. 이 글에서는 무엇을 옮기는 것이 합리적인지, 웹 서버에서 어떤 프로토콜이 동작하는지, 파일이 방문자에게 안전하게 도착하게 하는 방법, 그리고 한계가 어디에 있는지 살펴봅니다.
옮길 만한 것과 그대로 두어야 할 것
| 스토리지로 옮길 것 | 웹 서버에 남길 것 |
|---|---|
| 이미지와 영상의 원본 | 썸네일과 잘라 낸 버전 |
| 다운로드 아카이브, ISO 파일, PDF 모음 | CSS, JavaScript, 글꼴 |
| 원시 데이터, 내보낸 파일, 로그 아카이브 | 데이터베이스 |
| 웹사이트 백업 | 페이지를 열 때마다 필요한 모든 것 |
구분선은 간단합니다. 드물게 읽히고 한 번에 크게 전송되는 것은 스토리지로 갑니다. 페이지를 열 때마다 함께 불려 오는 것은 빠른 곳에 그대로 둡니다.
Storage Server란 무엇이고, 무엇이 아닌가
Storage Server는 사용자 계정이 있는 네트워크 스토리지입니다. 접속 정보로 연결해 파일을 읽거나 씁니다. 공개 주소를 가진 오브젝트 스토리지가 아니고, CDN도 아닙니다.
실제로는 이런 뜻입니다. 페이지에서 이미지를 스토리지로 바로 링크할 수 없습니다. 모든 접근에 인증이 필요하기 때문입니다. 웹 서버가 파일을 가져와 전달하거나, 유효 시간이 정해진 다운로드 링크를 직접 만들어야 합니다. 이것을 깔끔하게 하는 방법은 아래에 있습니다.
제약처럼 들리지만 장점도 하나 있습니다. 주소를 추측하거나 링크를 넘겨서 여러분의 파일을 가져가는 일이 불가능합니다. 접근은 언제나 여러분의 애플리케이션을 거치고, 따라서 여러분의 규칙을 따릅니다.
실무에서 통하는 방식
세 단계면 끝이고, 그 이상은 없습니다.
- 원본은 스토리지에 둡니다. 한 번 올린 뒤에는 좀처럼 건드리지 않습니다.
- 파생된 버전은 한 번 만들어 웹 서버에 둡니다. 썸네일, 잘라 낸 변형, 압축한 버전이 그렇습니다. 작고, 페이지를 열 때마다 필요합니다.
- 다운로드는 여러분의 애플리케이션을 거칩니다. 작은 스크립트가 권한을 확인하고, 스토리지에서 파일을 가져와 내보냅니다.
이를 거꾸로 해서 썸네일을 페이지를 열 때마다 스토리지에서 새로 가져오면 느린 웹사이트를 손수 만드는 셈입니다. 파일마다 붙는 네트워크 지연이 쌓이고, 이미지 마흔 장이 있는 갤러리는 마흔 번을 기다립니다.
어떤 경우에 어떤 프로토콜
| 프로토콜 | 포트 | 적합한 용도 | 필요 조건 |
|---|---|---|---|
| SMB / CIFS | 445 | 디렉터리로 마운트 | 서버의 root 권한 |
| SSHFS | 23 | 디렉터리로 마운트, 암호화됨 | 서버의 root 권한 |
| SFTP | 23 | PHP에서 접근, 스크립트, 전송 | 나가는 포트 23 |
| HTTPS를 통한 WebDAV | 443 | 공유 호스팅, 제한된 환경 | HTTPS만 |
| rsync | 23 | 큰 디렉터리 동기화 | 나가는 포트 23 |
| BorgBackup | 23 | 중복 제거가 되는 백업 | 나가는 포트 23 |
가장 중요한 결정은 취향이 아니라 여러분의 권한에 달려 있습니다. 자체 서버에서는 스토리지를 디렉터리로 마운트하고, 그러면 모든 애플리케이션이 그 사실을 알지 못한 채로 그것을 쓸 수 있습니다. 방법은 Storage Server를 네트워크 드라이브로 연결하기에 있습니다.
공유 호스팅에서는 root 권한이 없으므로 마운트가 불가능합니다. 그때는 애플리케이션 안에서 WebDAV나 SFTP를 쓰는 길이 남고, 대개 WebDAV가 저항이 더 적습니다. 포트 443은 사실상 막혀 있는 경우가 없기 때문입니다.
PHP에서 접근 설정하기
SFTP라면 순수 PHP 라이브러리 하나로 충분하고, 서버에 확장 모듈을 설치할 필요가 없습니다.
composer require phpseclib/phpseclib:~3.0
use phpseclib3\Net\SFTP;
$sftp = new SFTP('u123456.storage.kernelhost.net', 23);
if (!$sftp->login('u123456-sub1', $passwort)) {
throw new RuntimeException('로그인 실패');
}
// 파일 업로드
$sftp->put('/bilder/2026/original.jpg', '/tmp/upload.jpg', SFTP::SOURCE_LOCAL_FILE);
// 파일 읽기
$inhalt = $sftp->get('/bilder/2026/original.jpg');
WebDAV라면 기본으로 들어 있는 curl 확장만으로도 됩니다.
$ch = curl_init('https://u123456.storage.kernelhost.net/bilder/2026/original.jpg');
curl_setopt_array($ch, [
CURLOPT_RETURNTRANSFER => true,
CURLOPT_USERPWD => 'u123456-sub1:' . $passwort,
CURLOPT_TIMEOUT => 30,
]);
$inhalt = curl_exec($ch);
curl_close($ch);
두 예시 모두 기본 계정이 아니라 하위 계정을 씁니다. 그 이유는 다음 절에 있습니다.
용도마다 하위 계정 하나씩
모든 Storage Server는 하위 계정을 최대 100개까지 허용하며, 요금제와 상관없습니다. 각 계정은 다음을 받습니다.
- 벗어날 수 없는 고유한 시작 디렉터리,
- 고유한 비밀번호,
- 고유한 프로토콜 권한, 예를 들어 SFTP만 허용하고 Samba는 허용하지 않는 설정.
웹사이트라면 이런 뜻입니다. 웹 서버용으로는 SFTP만 쓸 수 있고 /web만 보이는 하위 계정을, 백업용으로는 /backup만 보이는 두 번째 계정을 둡니다. 웹 서버가 한 번 넘어가도 공격자는 백업에 닿지 못합니다. 그 계정은 백업의 존재조차 모르기 때문입니다.
한 가지 한계가 있습니다. 하위 계정은 자기 용량 한도를 받지 않습니다. 자기 디렉터리 안에 머물지만, 그 안에서 요금제의 전체 용량을 채울 수 있습니다. 개별 사용자를 정말로 제한하고 싶다면 그 일을 맡아 줄 애플리케이션을 앞에 두어야 합니다. Nextcloud를 Storage Server와 연결하기가 바로 이 구성을 보여 줍니다.
다운로드를 안전하게 내보내기
가장 흔한 실수는 접속 정보를 브라우저까지 흘려보내는 것이고, 사용자명과 비밀번호가 들어간 링크가 그런 경우입니다. 올바른 방법은 여러분의 서버가 연결을 맺고 파일을 그대로 전달하는 것입니다.
<?php
// 아무 일도 일어나기 전에 권한을 확인한다
if (!nutzer_darf_datei($_GET['id'])) {
http_response_code(403);
exit;
}
$sftp = neue_verbindung();
$datei = $sftp->get(pfad_zu($_GET['id']));
header('Content-Type: application/octet-stream');
header('Content-Disposition: attachment; filename="dokument.pdf"');
header('Content-Length: ' . strlen($datei));
echo $datei;
아주 큰 파일이라면 전체를 메모리에 올리지 말고 블록 단위로 읽는 편이 좋습니다. 그러지 않으면 PHP 메모리 한도에 걸립니다. 이를 위해 ob_end_flush()를 쓰고 파일을 조각으로 나누어 내보내세요.
동시 다운로드가 많을 것으로 예상된다면, 진행 중인 다운로드마다 PHP 프로세스 하나를 차지한다는 점도 함께 생각해야 합니다. 일정 규모를 넘어서면 그런 작업은 공유 호스팅이 아니라 자체 서버 뒤에 두어야 합니다.
웹사이트를 스토리지에 백업하기
가장 쉬운 시작이고, 효과가 바로 나타납니다. rsync를 쓰면 변경된 부분만 전송합니다.
rsync -az --delete -e "ssh -p 23" \
/var/www/example.com/ \
u123456-sub2@u123456.storage.kernelhost.net:/backup/web/
중복 제거와 암호화가 필요한 백업이라면 BorgBackup이 더 나은 선택이고, 스토리지에 기본으로 들어 있습니다. 여기에 스토리지 자체의 스냅샷이 두 번째 계층으로 더해집니다. 요금제에 따라 수동 스냅샷 10개, 20개, 30개 또는 40개이고, 매일·매주·매월 주기로 도는 자동 스냅샷도 같은 개수만큼 제공됩니다.
같은 서버에 백업하는 것과의 차이가 결정적입니다. 삭제되거나 암호화된 디스크는 로컬 백업을 함께 데려가지만, 분리된 스토리지에 있는 백업은 그렇지 않습니다.
시작하기 전에: 스위치 두 개
고객 포털의 Storage Server 페이지에서 “접근 설정” 버튼을 찾을 수 있습니다. 두 가지가 맞아야 합니다.
- 외부 접근 허용이 켜져 있어야 합니다. 그러지 않으면 웹 서버가 인터넷을 거쳐 스토리지에 닿지 못합니다.
- 원하는 프로토콜이 허용되어 있어야 합니다. SMB에는 Samba, SFTP와 rsync에는 SSH, HTTPS 경로에는 WebDAV입니다.
새로 주문한 서버에서는 이 모두가 켜져 있습니다. 보안을 이유로 쓰지 않는 것을 끄는 분이라면, 바로 그것이 나중에 “갑자기 안 된다”의 가장 흔한 원인이라는 점을 기억해 두세요.
어떤 요금제가 맞는지
| 요금제 | 용량 | 하위 계정 | 스냅샷 | 가격 |
|---|---|---|---|---|
| Storage-1 | 1 TB | 100 | 10개 및 자동 10개 | 9.99 EUR |
| Storage-2 | 5 TB | 100 | 20개 및 자동 20개 | 29.99 EUR |
| Storage-3 | 10 TB | 100 | 30개 및 자동 30개 | 39.99 EUR |
| Storage-4 | 20 TB | 100 | 40개 및 자동 40개 | 69.99 EUR |
모든 Storage Server는 독일에 있고, FTP, FTPS, SFTP, SCP, Samba, WebDAV, WebDAVs를 지원하며, rsync와 BorgBackup을 기본으로 갖추고 IPv4와 IPv6을 함께 가집니다. 설치 비용은 없고, 선불 방식으로 최소 계약 기간 없이 정산됩니다. 그래서 1 TB로 시작한 뒤 이전 작업 없이 나중에 키울 수 있습니다.
계산 예를 하나 들어 보겠습니다. 웹 서버에 1 TB를 더하는 비용은 사업자에 따라 월 9.99 EUR의 몇 배가 들고, 그렇게 늘린 공간은 웹사이트와 같은 기계 위에 놓입니다. 그 옆에 있는 스토리지는 더 저렴할 뿐 아니라, 분리되어 있습니다.
자주 묻는 질문
Storage Server에 있는 이미지를 웹사이트에 바로 삽입할 수 있나요?
웹 서버에서는 어떤 프로토콜을 쓰는 것이 좋나요?
Storage Server가 CDN을 대신할 수 있나요?
하위 계정은 몇 개까지 만들 수 있나요?
하위 계정마다 저장 용량을 따로 배정할 수 있나요?
접근 속도는 어떤가요?
접속 정보가 브라우저에 보이나요?
이것으로 웹사이트 백업도 할 수 있나요?
이것을 하려면 자체 서버가 필요한가요?
비용은 얼마인가요?
2026 KernelHost GmbH. 모든 권리를 보유합니다. 본 가이드는 저작권법의 보호를 받습니다. 전체든 일부든, 또는 수정된 형태이든 저희의 서면 동의 없이 다른 웹사이트에 게시할 수 없습니다. 출처를 밝히고 링크를 덧붙인 인용은 언제든지 환영합니다.

