자신의 서버에 배포한다는 것은 여러분이 비용을 지불하고 있고, 이미 다른 것들이 돌아가고 있을 수도 있는 박스에 에이전트에게 SSH에 준하는 접근 권한을 넘긴다는 뜻입니다. 이는 무료 서브도메인에 게시하는 것과는 다른 신뢰 수준이며, 설정 과정도 이를 반영합니다 — 몇 개의 필드를 한 번만 채우면, 그 이후의 모든 빌드는 버튼 하나로 끝납니다. 다음은 사람들이 이를 설정하기 전후로 실제로 묻는 질문들입니다.
대상을 만들려면 무엇이 필요한가요?
설정 → 배포에서 다섯 가지가 필요합니다:
- 나중에도 알아볼 수 있는 이름 — "prod-vps", "client-hostgator" 등 밤 11시에 드롭다운에서 봐도 알 수 있는 이름
- 호스트와 포트
- SFTP 자격 증명
- 웹루트 경로
API 토큰도 필요 없고, 서버에 설치할 CLI도 없고, 돌봐야 할 cron 작업도 없습니다. 호스팅 업체가 SFTP 접근을 제공한다면 — 거의 모든 공유 호스팅, VPS, 관리형 워드프레스 호스팅이 해당됩니다 — 약 2분이면 끝납니다.
비밀번호 아니면 키?
호스팅 업체가 지원한다면 키를 사용하세요. 비밀번호도 문제없이 작동하고 계정에 범위가 한정되어 저장되지만, 키를 쓰면 노출될 비밀 정보가 하나 줄어듭니다 — 나중에 문제가 생겼을 때 "키를 폐기하면 끝"인지, "그 비밀번호가 재사용된 모든 곳에서 재설정해야 하는지"의 차이죠. 저렴한 공유 호스팅의 SFTP 설정 중 상당수는 비밀번호 인증만 제공하는데, 그것도 괜찮습니다. 다만 그 비밀번호를 다른 곳에서 재사용하지만 마세요.
올바른 웹루트 경로는 어떻게 찾나요?
이것은 사람들이 처음에 자주 틀리는 항목입니다. 틀린 답도 그럴듯해 보이기 때문이죠. 홈 디렉터리가 아니고, /var/www 도 아니며 — 여러분의 웹서버가 서비스하도록 설정된 정확한 그 폴더입니다.
| 서버 | 일반적인 웹루트 |
|---|---|
| Apache / cPanel | public_html |
| Nginx | /var/www/mysite/html 혹은 3년 전 다른 개발자가 아무도 기억 못 할 이유로 이름 붙인 어떤 경로 |
확실하지 않다면, 어떤 SFTP 클라이언트로든 맞다고 생각되는 폴더에 테스트용 test.txt 파일을 넣어보고, 그것이 yoursite.com/test.txt에서 로드되는지 확인하세요. 이것을 잘못 설정해도 배포는 여전히 성공으로 표시됩니다 — 에이전트는 잘못된 폴더에 파일을 충실히 써넣고, 여러분은 변하지 않은 라이브 사이트를 바라보며 왜 그런지 의아해하게 됩니다.
하나의 대상이 여러 도메인을 처리할 수 있나요?
네, 그리고 첫 사이트를 넘어서면 진짜로 시간이 절약되는 부분이 바로 이겁니다. 대상은 하나의 서버와 하나의 자격 증명 세트이며, 단일 도메인에 묶여 있지 않습니다. 도메인 관리(Domain Management)에서 각 도메인을 저마다의 웹루트 재정의와 함께 대상에 연결합니다. Nginx 서버 블록을 사용해 하나의 VPS에서 세 개의 사이트를 운영하고 있나요?
site-a→/var/www/site-asite-b→/var/www/site-bsite-c→/var/www/site-c
대상 하나, 연결 세 개면 됩니다. SSH 비밀번호를 세 번 다시 입력할 필요도 없고, 키를 교체하다가 하나를 빠뜨려 점점 어긋나는 거의 동일한 대상 세 개를 관리할 필요도 없습니다. 세 도메인 중 아무거나 배포를 클릭하면 이미 어떤 서버와 어떤 폴더인지 알고 있습니다 — 배포 시점에 따로 선택할 필요가 없습니다.
연결될 때 에이전트는 실제로 무엇을 하나요?
먼저 둘러봅니다 — 읽기 전용이며, 아직 아무것도 쓰지 않습니다. 이 점검은 다음을 확인합니다:
- 빈 폴더
- 이 빌드의 이전 버전
- 오래된 워드프레스 설치
- 호스팅 업체가 기본적으로 넣어둔 "곧 오픈합니다" 플레이스홀더
이 판단에 따라 전략이 결정됩니다. 빈 웹루트는 단순 업로드로 처리됩니다. 이미 무언가가 있는 웹루트는 더 신중하게 다뤄지는데, 사라지면 안 되는 것들이 사이트와 함께 놓여 있는 실제 상황이 많기 때문입니다:
- A
.well-knownSSL 검증용 폴더 - 다음과 같은
uploads아무도 git에 넣지 않은 디렉터리 - A
wp-config.php아무도 손대고 싶어하지 않는
여기서 하는 작업은 "지우고 교체하기"라기보다 "무엇이 바뀌었는지 파악하고 조정하기"에 더 가깝습니다.
그런 다음, 단 한 바이트도 덮어쓰이기 전에 기존 webroot가 여러분 자신의 호스트에 버전으로 캡처됩니다. 데이터베이스 레코드가 아니고, 우리가 계산해서 맞기를 바라는 diff도 아닙니다 — 실제로 그곳에 있던 것의 진짜 스냅샷입니다. 이는 특정 대상에 대한 첫 배포에서 가장 중요한데, 그 배포는 언제나 무언가 위에 올라가기 때문입니다, 그 무언가가 아무것도 아니더라도 말이죠. 빈 폴더라면 빈 스냅샷이 됩니다. 아무도 만든 기억이 없는 5년 된 정적 사이트라면 — 손대기 전에 정확히 그대로, 무료로 보존됩니다. 그 첫 배포는 또한 여러분이 가장 확신이 없는 배포이기도 하므로, 바로 그때 이것이 가장 중요해집니다.
소스 코드를 업로드하나요, 아니면 빌드된 사이트를 업로드하나요?
언제나 빌드된 사이트입니다. 정적 사이트라면 생성된 페이지들이고, Next.js나 Vite 등 프레임워크 빌드라면 사이트 유형이 요구하는 컴파일된 결과물, 즉 dist 또는 build 폴더이지 소스 트리가 아닙니다. SSH로 접속해서 서버에 있는 것에 대해 npm run dev 을 실행할 수 없게 되더라도, 저는 이것이 옳은 선택이라고 생각합니다. 소스를 업로드하면 여러분의 프로덕션 webroot가 HTML을 서비스하기 위해 Node 런타임과 빌드 툴체인이 필요해지고, 빌드 파이프라인을 실행하도록 설계되지 않은 공유 호스팅 박스를 그런 용도로 바꿔버리며, 모든 배포가 "서버 메모리가 npm install을 끝낼 만큼 충분하기를 바라는" 일이 되어버립니다. 컴파일된 결과물만 배포하면 webroot는 정적 파일 서버가 기대하는 그대로 유지됩니다. 지루하죠. 새벽 2시에 뭔가 잘못되어 그 폴더를 바라보며 실제로 무엇이 서비스되고 있는지 알아내려 할 때, 지루한 게 바로 여러분이 원하는 것입니다.
배포가 실제로 성공했는지 어떻게 알 수 있나요?
업로드 후, 에이전트는 라이브 URL에 접속해서 정상적으로 로드되는지 확인합니다 — 500 오류도, 빈 페이지도 아닌지요. 무엇을 발견했든, 그리고 검사 중에 여러분의 의견이 필요하다고 판단한 것이 있다면("이 webroot에는 손대지 않은 wp-content 폴더가 있습니다, 예상된 것인지 확인해주세요"), 빌드의 채팅 스레드에 남습니다. 이것이 이 플랫폼 전체를 관통하는 패턴입니다: 조용한 성공도, 조용히 지원 티켓으로 이어지는 조용한 실패도 없습니다. 에이전트는 여러분이 빌드를 요청한 바로 그 스레드에서 무엇을 봤고 무엇을 결정했는지 알려줍니다.
버전 기록에는 실제로 무엇이 들어 있나요?
모든 배포는 버전을 추가합니다 — 첫 배포만이 아니라요. 따라서 기록은 여러분의 빌드를 추상적인 타임라인에 그려낸 것이 아니라, 그 웹루트에서 실제로 서비스된 내용의 순서 그대로의 기록입니다. 여러분이 등장하기 전 그곳에 있던 것부터 시작해서요. 버전 1은 언제나 그 플랫폼 이전 상태이며, 자동으로 캡처됩니다. 따로 신경 쓸 필요가 없습니다.
되돌리기(revert)는 실제로 무엇을 복원하나요?
이전에 서비스되던 버전 그대로 — 예전 빌드를 다시 실행하는 것도, 근사치도 아닙니다. 트래픽을 처리하고 있던 바로 그 파일입니다. 이는 제가 다른 곳에서 써본 대부분의 "롤백" 기능보다 훨씬 강력한 보장입니다. 그런 기능들은 보통 "오래된 커밋에서 다시 배포"를 의미하며, 여러분의 빌드 프로세스가 결정론적이고 환경이 그동안 변하지 않았다고 조용히 가정합니다. 여기서 되돌리기는 알려진 정상 상태의 스냅샷을 복원하는 것이므로, 위급한 상황에서도 안심하고 사용할 수 있습니다 — 롤백이 되돌리려는 대상과 다르게 동작할지 고민할 필요가 없습니다.
그리고 실제로 그게 필요한 순간은 결코 평온한 순간이 아닙니다. "새 빌드가 결제를 망가뜨렸고 지금 실시간 트래픽이 흐르고 있다" 같은 순간이죠.
클릭 한 번으로 이전 버전이 복원되면 끝입니다. 이를 부수적인 기능이 아니라 핵심 기능으로 다루는 이유는 두려움 없이 반복하기에서 다룹니다 — 필요해지기 전에 한 번은 읽어볼 가치가 있습니다. 이력과 복원 컨트롤 모두 빌드 카드와 대상의 자체 이력 보기에 있습니다.
이게 제 데이터베이스도 백업해주나요?
아니요, 이건 누군가 다르게 오해하도록 두느니 분명히 말씀드리는 게 낫겠습니다. 호스트의 버전 이력은 이 배포 파이프라인이 webroot에 넣은 것만 다룹니다. 사이트에 데이터베이스나 사용자 업로드, 또는 배포 밖에서 변경되는 다른 무언가가 있다면 그건 완전히 별개의 문제입니다 — 되돌리기는 그것을 건드리지 않으며, 그런 백업 전략으로 오해해서는 안 됩니다.
