기획서의 배포란에는 한 줄이 적혀 있습니다. "Vercel". 만들면서 바로 올릴 수 있어 비개발자에게 가장 많이 권하는 방식입니다. 그런데 이 서비스는 지금 서버 한 대 위에서 돕니다. 언제 왜 바꿨는지는 기록에 남아 있지 않습니다.
서버에 올린다는 네 가지 일
| 순서 | 하는 일 | 쉽게 말하면 |
|---|---|---|
| 1 | 빌드 | 사람이 보기 좋은 코드를 기계가 읽을 형태로 바꿈 |
| 2 | 옮기기 | 빌드 결과를 서버로 보냄 |
| 3 | 켜 두기 | 서버에서 프로그램을 띄우고, 꺼지면 다시 켬 |
| 4 | 넘겨주기 | 바깥에서 들어온 요청을 그 프로그램에 전달 |
"서버에 올린다"는 말은 한 덩어리처럼 들리지만 실제로는 이 네 가지입니다. 어느 하나라도 빠지면 사이트는 안 열립니다.
관리형 서비스와 직접 운영
| 일 | 관리형 서비스 | 서버 직접 운영 |
|---|---|---|
| 빌드 | 저장소에 올리면 알아서 | 내 컴퓨터나 서버에서 직접 |
| 옮기기 | 알아서 | 직접 (복사 명령·스크립트) |
| 켜 두기·되살리기 | 알아서 | 프로세스 관리 프로그램을 따로 설치 |
| 넘겨주기·HTTPS | 알아서 | 웹 서버 설정·인증서를 직접 |
| 언제 무엇이 올라갔나 | 화면에 표로 남음 | 남기지 않으면 없음 |
| 서버에서 일어나는 일 | 대부분 안 보임 | 전부 보이고, 전부 내 책임 |
직접 운영을 택하면 네 가지가 모두 제 몫이 됩니다. 대신 그 서버에서 일어나는 일도 전부 제 것이 됩니다. 한 대를 빌려 두면 다음에 만드는 서비스도 같은 자리에 올릴 수 있다는 장점은 분명합니다.
요청 하나가 도착하기까지
| 단계 | 누가 | 하는 일 |
|---|---|---|
| 1 | DNS | 도메인을 서버 주소로 안내 (8편) |
| 2 | 웹 서버 (nginx) | 443번 자리에서 요청을 받아 안쪽 프로그램으로 넘김 |
| 3 | 프로세스 관리자 (pm2) | 서비스 프로그램을 켜 두고, 죽으면 되살림 |
| 4 | 서비스 프로그램 | 화면과 파일을 만들어 돌려줌 |
서비스 프로그램은 서버 안쪽 자리에서 돌고, 바깥에서는 직접 닿지 않습니다. 8편의 DNS가 도메인을 서버까지 데려왔다면, 여기서부터는 서버 안에서 방을 찾아 주는 셈입니다.
서버 코드는 어느 시점의 것인가
| 확인한 것 | 결과 |
|---|---|
| 서버의 서비스 폴더가 git 저장소인가 | 아님 |
| 서버만 보고 어느 커밋인지 알 수 있나 | 없음 |
| 서버와 내 컴퓨터의 소스 파일·줄 수 | 233개 · 35,938줄로 같음 |
오늘은 같았습니다. 하지만 "오늘은 같다"일 뿐입니다. 관리형 서비스라면 화면에 남았을 배포 이력을, 직접 운영에서는 제가 따로 적지 않는 한 아무도 남겨 주지 않습니다. 이 연재를 쓰면서 지난 일을 파일 날짜로 더듬고 있는 이유가 여기 있습니다.
배포할 때마다 남길 것
| 남길 것 | 왜 |
|---|---|
| 배포한 날짜·시각 | 문제가 생겼을 때 어느 배포 뒤인지 좁히려고 |
| 올린 코드의 커밋 | 서버 코드가 어느 시점인지 알려고 |
| 바꾼 이유 한 줄 | 몇 달 뒤의 나를 위해 |
| 로그의 시각 | 오류가 언제 몰렸는지 보려고 — 끄면 기간 자체를 모름 |
| 백업을 지울 날짜 | 백업은 만드는 것보다 지우는 걸 잊음 |
서버에 직접 올린다면
- 빌드 · 옮기기 · 켜 두기 · 넘겨주기 — 네 가지가 다 내 몫이라는 걸 알고 시작하기
- 로그에 시각부터 남기기
- 배포 기록을 한 줄씩이라도 남기기 — 언제, 무엇을, 왜
- 백업은 지우는 날짜까지 정해 두기
- 올린 뒤에는 바뀐 화면만 보지 말고 로그를 한 번 열어 보기
- 새 버전을 올리면 그 순간 화면을 보고 있던 사람의 버튼이 헛돌 수 있다는 것 알아 두기
다음 편 · 09-25 공개 예정EP.10 · HTTPS와 www 정리