공유와 배포로 프로토타입을 서비스화하기
공유는 피드백용, 배포는 운영용이다
AI Studio에서 만든 결과물은 빠르게 보여주기 좋다. 프롬프트, 모델 설정, 멀티모달 입력, 간단한 앱 UI를 브라우저 안에서 바로 실험하고 확인할 수 있기 때문이다. 그래서 링크 공유는 동료에게 아이디어를 보여주고, 사용성을 묻고, 데모 반응을 수집하는 단계에 적합하다.
하지만 링크를 보냈다고 서비스가 된 것은 아니다. 실제 서비스는 누가 접근할 수 있는지, 비용이 얼마나 발생하는지, 오류가 났을 때 어떻게 복구할지, API 키가 안전한지까지 책임져야 한다. AI Studio의 Share 기능은 앱을 빠르게 공유하는 데 유용하지만, 운영 수준의 인증, 비용 통제, 장애 대응, SLA를 대신 보장하지 않는다. AI Studio의 Build 화면에서도 프로젝트 다운로드, 공유, Cloud Run 배포 같은 선택지가 제공될 수 있지만 각각의 목적은 다르다.1
공유 전에 확인할 네 가지
공유 버튼을 누르기 전에는 다음 네 가지를 확인한다.
첫째, 누가 접근할 수 있는가. 내부 팀원만 보는 데모인지, 외부 고객에게 여는 페이지인지 구분해야 한다. 둘째, API 키나 프로젝트 정보가 노출되지 않는가. 프론트엔드 코드에 키를 넣은 채 공개 저장소나 웹페이지로 배포하면 누구나 키를 가져갈 수 있다. 셋째, 사용량 증가 비용은 누가 부담하는가. AI 호출은 트래픽이 늘수록 비용이 커질 수 있다. 넷째, 실험용 UI가 남아도 괜찮은가. AI Studio의 공유 화면이나 프로토타입 형태는 피드백 수집에는 충분하지만, 고객용 서비스에는 별도의 브랜드·권한·오류 처리가 필요할 수 있다.
따라서 화면 공유나 프로젝트 링크 공유는 "검토용"으로 이해하는 편이 안전하다. 외부 사용자에게 반복적으로 쓰게 할 목적이라면 코드를 분리해 배포해야 한다.
GitHub와 Vercel로 공개 페이지 만들기
가장 쉬운 서비스화 흐름은 AI Studio에서 검증한 앱을 코드로 가져와 GitHub에 올리고, Vercel 같은 프론트엔드 배포 서비스에 연결하는 방식이다.
기본 순서는 단순하다.
AI Studio에서 Build 또는 Get Code로 앱 코드를 가져온다.
로컬에서 실행해 화면과 모델 호출이 정상인지 확인한다.
API 키를 코드에서 제거하고
.env같은 환경 변수로 분리한다.GitHub 저장소에 커밋한다.
Vercel, Firebase Hosting, Netlify 같은 서비스와 저장소를 연결한다.
배포 URL에서 다시 테스트한다.
Vercel류 서비스는 GitHub 저장소와 연결하면 커밋할 때마다 자동으로 새 버전을 배포한다. 이를 CI/CD라고 부른다. 쉽게 말해 "코드를 저장하면 빌드와 배포가 자동으로 이어지는 흐름"이다. 포트폴리오, 내부 도구, 랜딩 페이지, 간단한 AI 데모에는 이 방식이 빠르다.
단, Gemini API를 브라우저에서 직접 호출하는 구조는 피하는 것이 좋다. 외부 사용자가 있는 앱에서는 서버나 서버리스 함수가 API를 대신 호출해야 한다. 그래야 키를 숨기고, 사용자별 요청 횟수 제한, 입력 검증, 에러 처리, 악용 방지를 넣을 수 있다. 정적 호스팅을 쓰더라도 Gemini 호출 부분만큼은 /api/generate, /api/summary 같은 서버 측 엔드포인트로 분리하는 편이 안전하다.2
Cloud Run은 운영 배포의 출발점이다
Google Cloud 기반으로 운영하려면 Cloud Run을 고려할 수 있다. AI Studio에서 만든 앱을 Cloud Run에 배포하는 흐름을 활용할 수 있으며, Google Cloud 프로젝트와 결제 설정이 필요하다.3 배포가 끝나면 고정된 HTTPS URL을 받고, 앱은 서버리스 환경에서 실행된다. 서버리스란 서버를 직접 관리하지 않아도 요청이 들어올 때 필요한 만큼 실행되는 방식을 말한다.
운영 배포 전에는 다음을 준비한다.
결제 계정과 예산 알림
IAM 권한: 누가 배포하고 설정을 바꿀 수 있는지 정하는 권한 체계
Secret Manager: API 키 같은 비밀 값을 안전하게 저장하는 서비스
로그와 모니터링: 오류, 응답 시간, 호출량 확인
요청 제한과 장애 대응: 과도한 사용이나 실패 응답 처리
조직 규모가 커지고 권한 관리, 모델 관리, 감사 로그, 관측성이 더 중요해지면 Vertex AI 쪽으로 확장할 수 있다. AI Studio는 빠른 실험에 강하고, Google Cloud와 Vertex AI는 운영 통제에 강하다.
공개 수준을 먼저 정하라
배포 방식은 기술 선택이 아니라 책임 범위 선택이다.
빠른 공유 링크나 실험용 데모는 피드백을 얻는 데 좋다. GitHub와 Vercel로 공개한 포트폴리오는 독립 URL을 갖고 보여주기 좋다. 독립 도메인, 로그인, 모니터링, 비용 알림, 약관, 개인정보 처리 기준까지 갖춘 서비스는 책임 범위가 훨씬 넓다.
따라서 배포 전 한 문장으로 목적을 정한다.
"이 앱은 누구에게, 어느 기간 동안, 어느 수준의 안정성으로 공개할 것인가?"
이 질문에 답할 수 있으면 공유로 충분한지, Vercel 배포가 맞는지, Cloud Run과 Google Cloud 운영 체계가 필요한지 자연스럽게 결정된다. 프로토타입은 빨리 보여주는 것이 중요하지만, 서비스는 오래 안전하게 작동하는 것이 중요하다.
참고
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.