서비스 운영
웹 애플리케이션은 공개한 뒤부터 실제 운영이 시작됩니다. 출시 전 테스트와 관리자 페이지 준비부터 매달 드는 비용, 사용자 행동과 오류를 확인해 다음 개선점을 찾는 방법까지 서비스를 안정적으로 굴리는 데 필요한 글을 모았습니다.
GitHub Actions로 운영 DB 마이그레이션 자동화하기
개발용과 운영용 데이터베이스를 나눈 뒤에는 검토한 마이그레이션 파일을 운영 DB에도 적용해야 해요. Drizzle과 GitHub Actions를 예로 들어 secret 등록부터 main push 후 자동 실행까지 설명합니다.
바이브코딩 보안 체크리스트: 만든 서비스를 공개하기 전에 확인할 12가지
AI가 보안 점검을 마쳤다고 말해도 실제 서비스가 안전하다는 뜻은 아니에요. 공개 전에는 비밀 키, 로그인과 권한, XSS·CSRF·SSRF, 파일과 외부 URL, 의존성, 보안 로그를 실제 배포 환경에서 확인해야 합니다.
바이브코딩으로 만든 앱, 한 달 운영비는 얼마나 들까요?
작은 웹 애플리케이션은 무료 구간에서 실험할 수 있지만, 첫 상용 서비스는 Vercel Pro와 Supabase Pro만으로도 2026년 7월 기준 약 $45의 월 고정비가 생길 수 있습니다. 여기에 도메인·결제 수수료·AI와 초과 사용량을 따로 계산해야 합니다.
바이브코딩으로 만든 웹앱, 공개하기 전에 무엇을 테스트해야 할까요?
웹앱 공개 전에는 성공 화면 한 번이 아니라 사용자의 시작부터 데이터 저장과 운영 확인까지 전체 흐름을 테스트해야 해요. 정상·잘못된 입력·중복 요청·실패·권한·새로고침·모바일을 실제 배포 환경에서 확인하고 출시 뒤 문제를 찾을 로그도 준비하세요.
관리자 페이지는 왜 필요할까요? 처음 만들 때 넣어야 할 기능
관리자 페이지는 운영자가 고객·주문·문의와 콘텐츠를 서비스 규칙 안에서 안전하게 처리하는 업무 화면이에요. 처음에는 매일 반복하는 목록·검색·상세·상태 변경부터 만들고 관리자 권한, 변경 이력과 위험 작업의 복구 수단을 함께 준비하세요.
서비스를 출시한 다음에는 무엇을 확인해야 할까요?
서비스 출시 뒤에는 방문자 수보다 사용자가 약속한 결과를 얻는 성공 행동을 먼저 정하세요. 유입부터 활성화·전환·유지까지 흐름을 보고 오류·최종 DB 결과·고객 피드백을 연결하면 다음에 고칠 한 지점을 선택할 수 있습니다.
AI가 버그를 계속 못 고친다면? 로그를 찍어보세요
AI가 같은 버그를 추측으로 계속 수정한다면 실행 흐름의 경계마다 로그를 남겨 처음 끊긴 지점을 찾으세요. 브라우저 Console, 로컬 서버 터미널과 배포 서비스 로그를 구분해 실제 기록을 AI에게 전달하면 원인 범위를 줄일 수 있습니다.
로그가 뭐예요? 왜 필요한가요?
로그는 앱에서 일어난 일을 시간순으로 남긴 기록이고 로깅은 그 기록을 남기는 일이에요. 서버 오류는 Vercel 같은 배포 로그에서, 사용자 행동은 PostHog 같은 분석 도구에서 확인해 화면만으로 보이지 않는 문제의 조건과 원인을 찾을 수 있습니다.
내 컴퓨터에서는 되는데 배포하면 안 된다면? 무엇부터 확인해야 할까요?
localhost에서는 되는데 배포한 사이트에서 안 된다면 코드를 바로 고치기 전에 같은 버전인지부터 확인하세요. 로컬 변경·commit·push·배포가 사용한 commit·실제 운영 주소·환경변수 순서로 따라가면 배포 오류를 빠르게 좁힐 수 있습니다.
배포할 때 .env를 그대로 넣어도 될까요? 개발·운영 데이터베이스를 나눠야 하는 이유
로컬과 배포 환경이 같은 데이터베이스를 사용하면 테스트·삭제·스키마 변경이 실제 고객 데이터에 영향을 줄 수 있어요. 개발용과 운영용 DB를 나누고 같은 환경변수 이름에 환경별 다른 값을 설정해 운영 데이터는 보호해야 합니다.
배포했는데 왜 느릴까요? 서버·데이터베이스 Region 이해하기
첫 화면은 빠른데 로그인·예약·검색만 느리다면 서버와 데이터베이스가 서로 먼 Region에서 실행되는지 확인하세요. 요청 경로와 구간별 시간을 측정한 뒤 사용자의 위치, 데이터베이스와 외부 서비스까지 고려해 가까이 둘 대상을 정해야 합니다.
