배포 · 호스팅
Deployment / Hosting
배포란?
- 배포=서버에 올려 가동
- 호스팅=24시간 띄우는 공간 임대
- 만든 걸 세상에 내보냄
코드를 배포하는 순간 결과물의 성격이 바뀝니다. 내 노트북에서 돌 때는 오류가 나도 보는 사람이 저 하나지만, 주소가 발급된 뒤로는 접속한 사람 전부가 그 오류를 봅니다. 배포는 기능의 완성이 아니라 책임의 시작입니다. 누가 접속할 수 있는지, 몇 명이 몰리면 느려지는지, 새벽에 서버가 멈추면 누가 알아채는지 — 이 질문들은 하나같이 배포 이후에야 생깁니다. 사내에서 '다 만들었습니다'라는 보고를 받았을 때 다음 질문이 '주소가 뭡니까'여야 하는 이유입니다.
호스팅은 무엇을 올리느냐에 따라 갈립니다. HTML·CSS·자바스크립트만으로 도는 정적 사이트는 넷리파이·버셀·깃허브 페이지의 무료 구간으로 충분하고, HTTPS 인증서와 도메인 연결도 클릭 몇 번이면 끝납니다. 반면 로그인·결제·데이터 저장이 붙는 순간 서버와 데이터베이스가 필요해 파이어베이스나 클라우드 런, AWS 쪽으로 넘어가고 쓴 만큼 요금이 붙는 구조로 바뀝니다. 또 하나, 실무에서는 운영 환경을 하나만 두지 않습니다. 테스트용(스테이징)과 실제 운영을 나눠 두고, 문제가 생기면 직전 버전으로 되돌리는 롤백 경로를 미리 확보해 둡니다.
현장에서 가장 자주 터지는 사고는 '링크를 모르면 못 들어온다'는 믿음입니다. 배포된 주소는 검색엔진이 알아서 수집해 가고, 프론트엔드 코드에 적어 둔 API 키는 브라우저 개발자도구에서 그대로 열립니다. 내부 데모라며 올린 거래처 단가표가 검색 결과에 잡히거나, 유출된 키로 남이 내 계정의 API를 호출해 요금이 쌓이는 일이 실제로 벌어집니다. 무료 요금제도 트래픽 한도를 넘기면 과금되므로, 배포 버튼을 누르기 전에 접근 제한과 키 분리, 사용량 알림부터 걸어 두어야 합니다.
소프트웨어를 사용자 환경에 올리는 '배포(deployment)'는 개발의 마지막 단계로 오래 존재했고, 클라우드·호스팅 서비스의 발전으로 자동화·간소화됐습니다.
가상의 사례로 살펴보겠습니다. 임직원 140명 규모의 자동차 부품 제조사 A사에서, 바이브 코딩 교육을 마친 생산관리팀 직원 6명이 '거래처 납기 조회' 웹앱을 만들었습니다. 그런데 3주가 지나도록 앱은 김 과장 노트북 안에서만 돌았고, 영업팀은 여전히 하루 40~50통씩 납기 문의 전화를 받고 있었습니다.
- 전산 담당 이 대리가 '그거 왜 아직 저희한테 안 넘어왔습니까' 하고 물으면서 일이 시작됐습니다. 김 과장이 공유한 것은 화면 녹화 영상 한 개뿐이었고, 접속할 주소는 아예 없었습니다.
- 이 대리가 코드를 열어 보니 사내 ERP 접속 키 3개와 공유 폴더 경로가 소스에 그대로 적혀 있었습니다. 이 키들을 환경변수로 빼내는 작업에만 이틀이 걸렸습니다.
- 조회 화면만 있는 정적 페이지라 별도 서버가 필요 없다고 판단해, 깃허브 저장소를 만들고 버셀 무료 구간에 연결했습니다. 첫 배포가 끝나 주소가 뜨기까지 실제로는 20분이 채 걸리지 않았습니다.
- '링크만 아는 사람끼리 쓰면 되지 않느냐'는 의견은 접었습니다. 납기와 단가가 함께 보이는 화면이라 사내 계정 로그인과 검색엔진 수집 차단을 붙이고, 월 트래픽 알림도 걸었습니다.
- 현장 공개 2주 뒤, 하루 40~50통이던 납기 문의 전화가 12통으로 줄었고 앱 접속은 하루 평균 180회를 기록했습니다. 영업팀 응대 시간이 주당 약 9시간 감소했다는 집계가 나왔습니다.