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