내 컴퓨터에서 잘 돌아가는 것과 실제 사용자가 쓰는 서비스는 다릅니다. localhost는 개발자 한 명을 위한 환경이고, 배포된 서비스는 여러 사용자가 다양한 브라우저와 네트워크에서 접근하는 환경입니다.
오늘은 "코드를 어떻게 짜는가"보다, 만든 코드를 어떻게 서비스로 내보내고 운영하는지 큰 그림을 봅니다.
React/Vite/Next 같은 도구는 개발 중에는 빠른 피드백을 위해 dev server를 띄웁니다. 하지만 실제 배포 전에는 코드를 압축하고, 번들을 나누고, 정적 파일을 만들고, 최적화하는 빌드 과정이 필요합니다.
빌드가 깨지는 코드는 배포할 수 없습니다. 그래서 팀에서는 PR을 머지하기 전에 lint, test, build를 CI에서 확인하는 경우가 많습니다.
로컬, 개발 서버, 운영 서버는 API 주소나 외부 서비스 키가 다를 수 있습니다. 이런 값은 코드에 직접 박지 않고 환경변수로 관리합니다.
단, 프론트엔드 번들에 들어가는 환경변수는 사용자가 볼 수 있습니다. 브라우저에 전달되는 값과 서버에서만 쓰는 값을 구분해야 합니다.
요즘 프론트엔드 배포는 GitHub와 연결되는 경우가 많습니다. main 브랜치에 머지하면 자동으로 빌드되고 배포됩니다. PR마다 미리보기 URL이 생기기도 합니다.
이 흐름이 중요한 이유는, 배포가 개발자의 수동 작업이 아니라 팀의 협업 흐름 안에 들어오기 때문입니다.
pnpm build
VITE_API_BASE_URL=https://api.example.com
branch 작업 → PR 생성 → preview 배포 → 리뷰 → main 머지 → production 배포
서비스를 배포하면 주소가 필요합니다. 도메인을 연결하고, HTTPS 인증서를 적용하고, 정적 파일 캐싱을 설정합니다. 사용자는 이 과정을 모르지만, 이 설정들이 서비스 신뢰도와 성능에 영향을 줍니다.
특히 캐싱은 조심해야 합니다. 너무 약하면 매번 느리고, 너무 강하면 새로 배포한 파일이 사용자에게 바로 반영되지 않을 수 있습니다.
배포는 끝이 아니라 시작입니다. 실제 사용자가 쓰기 시작하면 예외가 생깁니다. 특정 브라우저에서만 깨지고, 특정 API가 느리고, 예상하지 못한 입력이 들어오고, 배포 직후 에러가 늘어날 수 있습니다.
Sentry 같은 에러 모니터링 도구, Vercel Analytics, 서버 로그, 브라우저 Performance 지표는 운영에서 중요합니다. 사용자가 "안 돼요"라고 말하기 전에 개발자가 먼저 문제를 발견할 수 있어야 합니다.
프론트엔드 개발자도 이제 배포 후 지표를 볼 줄 알아야 합니다. 페이지가 느린지, 에러가 어디서 나는지, 사용자가 어떤 브라우저에서 많이 실패하는지 알아야 제품을 개선할 수 있습니다.
이번 학기에는 HTML/CSS/JS/React의 기본 사용법을 비대면에서 배우고, 대면에서는 브라우저 렌더링, AI 시대 개발 방식, 프로젝트 구조, API 계약, 웹 보안, 팀 협업, 배포와 운영까지 큰 그림을 봤습니다.
프론트엔드 개발은 단순히 화면을 만드는 일이 아닙니다. 사용자가 보는 화면을 중심으로 디자인, 백엔드, 제품, 배포 환경을 연결하는 일입니다. 앞으로 프로젝트를 할 때도 이 관점을 계속 가져가면 좋겠습니다.