애플리케이션을
Google Cloud에 배포하다

GenAI 애플리케이션의 설계와 개발에서 먼 길을 걸어왔다. 이제 그 결정적인 다음 걸음 — 배포의 시간이다. 진정한 프로덕션급 배포에는 CI/CD 파이프라인, 확장성 고려, 관측 가능성(observability), 비용 최적화, 보안 강화 같은 다양한 복잡성이 얽히지만, 이 장은 Google Cloud Run을 이용한 클라우드 배포의 기초적이고 실습적인 입문을 주도록 설계되었다. Google Cloud의 Cloud Run은 인프라를 관리하지 않고 컨테이너화된 애플리케이션을 배포하는, 강력하면서도 개발자 친화적인 길을 제공한다. 빠른 프로토타이핑과 소규모 프로덕션 용례에 이상적이다.

배포 단계와 서비스는 AWS나 Microsoft Azure 같은 다른 클라우드 플랫폼에서 조금씩 다를 수 있지만, 간결함을 위해 Google Cloud에 집중한다. 다만 여기의 핵심 개념에 익숙해지고 나면, 클라우드 배포 전문성을 넓히도록 다른 제공자에서 유사한 워크플로를 실험해 보기를 권한다.

우리는 5장에서 지은 Haystack 챗봇을 Google Cloud 위의 서버리스 애플리케이션으로 배포하는 과정을 함께 걷는다. Spring AI를 쓰는 지능형 추천 시스템의 배포 과정은 장의 뒷부분에서, 단계를 따라갈 자료 링크와 함께 언급된다. 이 장의 끝에 이르면 클라우드에 살아 있는 챗봇과, 이 토대 위에 더 고급의 배포를 쌓아 올릴 자신감을 갖게 된다.

Google Cloud Run으로 Haystack 챗봇을 배포하려면 다음이 필요하다.

애플리케이션을 Google Cloud에 배포한다. 여기서 이야기할 접근은 배포의 관점에서 모든 대중적 클라우드 환경에 비슷하게 적용된다. docker compose를 빌드해 클라우드에서 실행하는 방식을 볼 것이다. Google Cloud를 고른 것은 기술적 우위가 있어서라기보다 편의 때문이다. Google Cloud에 배포·실행하고 나면, 같은 docker compose를 다른 클라우드에 배포하는 공식 문서 링크를 제공한다. 그 단계들을 책에서 되풀이하는 일은 별 차이를 만들지 못할 것이기 때문이다.

컨테이너화와 배포에 뛰어들기 전에, Haystack 챗봇 코드가 서버리스 배포와 호환되는 방식으로 정돈되어 있는지 확인하는 일이 중요하다. 이 절에서는 코드베이스를 적절히 구조화하고, Google Cloud Run 배포에 필요한 필수 구성 파일들을 준비한다.

5장의 작동하는 검색 챗봇을 재사용한다. 메인 스크립트(search_chatbot.py)의 사본을 만들어 app.py로 이름을 바꾸고 — 많은 클라우드 서비스가 Python 웹 애플리케이션을 서빙할 때 기대하는 기본 진입점이 이것이다 — 컨테이너화 준비가 된 단순한 폴더에 놓는다. 챗봇 논리는 이미 동작하므로 로컬 테스트는 건너뛰고 곧바로 패키징과 클라우드 배포로 나아간다.

다음으로, 챗봇 실행에 필요한 모든 Python 의존성을 나열한 requirements.txt 파일을 준비한다. 이 파일이 있어야 빌드 과정에서 컨테이너가 필요한 패키지를 설치할 수 있다. 내용은 이런 모습이다.

민감한 자격 증명과 환경별 구성을 안전하게 관리하려면 .env 파일의 사용이 권장된다. GitHub 저장소의 ch12 디렉터리에 템플릿 역할을 하는 example.env 파일이 있다. OpenAI API 키와 Neo4j 데이터베이스 자격 증명 같은 핵심 변수들의 자리 표시자가 들어 있다. 이 파일의 사본을 만들어 .env로 이름을 바꾸고 실제 값으로 채우면 된다. 애플리케이션은 python-dotenv 라이브러리를 지렛대 삼아 이 변수들을 런타임에 적재한다. 비밀을 코드베이스 밖에 두면서도 애플리케이션이 접근할 수 있게 유지하는 것이다.

이 시점에서 배포에 필요한 핵심 구성 요소들 — 애플리케이션 스크립트, 의존성, 환경 변수 — 이 갖춰졌다. 컨테이너화와 배포를 위해 모든 것이 올바르게 정돈되도록, 프로젝트 디렉터리는 이제 이 구조를 따라야 한다.

example.env 파일은 사용자가 유효한 자격 증명과 구성 값을 담은 자신만의 .env를 만들도록 돕는 참조 역할을 한다. 애플리케이션 스크립트, 의존성, 환경 설정을 포함한 모든 핵심 구성 요소가 자리 잡았으니, 이제 배포를 위해 애플리케이션을 컨테이너화할 준비가 되었다.

Haystack 챗봇을 Google Cloud Run에 배포하기 전에, 애플리케이션을 Docker 컨테이너로 패키징해야 한다. 컨테이너화는 코드, 의존성, 환경을 하나의 이동 가능한 단위로 묶어 — 클라우드를 포함한 — 서로 다른 시스템에서 일관되게 실행되도록 해 준다. 이 절에서는 챗봇의 Docker 이미지를 빌드하는 데 필요한 단계들을 정의하는 Dockerfile을 만든다. 이 이미지가 서버리스 웹 서비스로서 Cloud Run에 배포될 것이다.

각 줄이 하는 일을 뜯어 보자.

Dockerfile이 자리 잡으면, 클라우드 배포 준비가 끝난 완전히 컨테이너화된 Haystack 챗봇을 갖게 된다. 다음 단계는 컨테이너를 밀어 올리고 Cloud Run으로 실행할 수 있도록 Google Cloud 환경을 구성하는 일이다.

Google Cloud는 GenAI 기반 해법을 포함한 현대적 애플리케이션의 배포를 위한 견고하고 개발자 친화적인 플랫폼을 제공한다. Cloud Run, Artifact Registry, Cloud Build 같은 도구와 함께라면, 최소한의 운영 오버헤드로 코드에서 확장 가능한 서버리스 배포까지 갈 수 있다. Haystack 챗봇이 언어 처리에 OpenAI를 쓰긴 하지만, Google Cloud는 애플리케이션 호스팅, 컨테이너 빌드 관리, Docker 이미지의 안전한 저장에서 결정적 역할을 맡는다. 이 절에서는 Google Cloud 프로젝트를 구성하고, 필요한 서비스만(Cloud Run, Cloud Build, Artifact Registry 등) 활성화하고, 배포를 위한 환경을 준비한다. 이 절의 끝에 이르면, 서버리스 인프라로 챗봇을 배포하는 데 필요한 모든 서비스와 권한이 갖춰진 클라우드 준비 상태의 프로젝트를 갖게 된다.

프로젝트 생성 — Google Cloud 콘솔의 프로젝트 선택 페이지에서 Google Cloud 프로젝트를 선택하거나 생성한다. 클라우드 프로젝트에 과금이 활성화되어 있는지 반드시 확인한다.

Google Cloud Shell 실행 — 설정을 단순화하고 로컬 도구 설치를 피하기 위해, Docker·gcloud CLI·Git이 미리 설치된 Google Cloud Shell을 쓴다. 시작은 이렇다. Google Cloud 콘솔로 가서, 내비게이션 바 오른쪽 위의 Cloud Shell 아이콘(터미널 아이콘)을 클릭한다. 화면 아래에 터미널 창이 열린다. Google Cloud 프로젝트와 서비스에 접근할 수 있는 완전한 기능의 셸이다.

올바른 Google Cloud 프로젝트에서 작업하고 있는지 확인한다. 새로 만들거나 기존 것을 써도 된다. 다음으로 설정하고 검증한다.

이제 컨테이너 배포에 필요한 Google Cloud 서비스들을 활성화한다.

앞의 gcloud 명령 대신 콘솔에서 각 제품을 검색하는 방법도 있다. 빠뜨린 API가 있다면 구현 중에 활성화할 수 있다. gcloud 명령과 사용법은 공식 문서를 참고한다.

배포 단계로 나아가기 전에, Haystack 챗봇 파일들이 Google Cloud Shell 환경에서 사용 가능한지 확인한다. 두 가지 길이 있다. 첫째, 기존 파일 업로드 — 앞선 장들의 일부로 로컬에서 개발해 왔다면, Cloud Shell 편집기의 Upload 옵션으로 작업 디렉터리를 올릴 수 있다. Open Editor 버튼(연필 아이콘)을 클릭한 뒤 File | Upload Files를 쓰거나 폴더를 편집기에 곧장 끌어다 놓는다. 둘째, GitHub에서 클론(깨끗한 설정에 권장) — 공식 책 저장소에서 12장 코드를 곧장 클론한다.

ch12 폴더 안에 들어가면 필요한 모든 파일 — app.py, requirements.txt, Dockerfile, example.env — 이 있다. 저장소를 클론하기로 했다면, 앞서 언급한 단계를 따라 .env 파일을 반드시 생성한다. 프로젝트 파일들이 Cloud Shell 안에 자리 잡고 준비되었으니, 마지막 무대 — Haystack 챗봇의 Google Cloud Run 배포 — 로 나아갈 시간이다.

이 절에서는 전체 배포 워크플로를 함께 걷는다 — 환경 변수 설정과 Artifact Registry 구성부터, 컨테이너 빌드와 Cloud Run을 통한 라이브 배포까지. 단계별로 뜯어 보자.

완료되면 Google Cloud Run이 챗봇이 살아서 웹으로 접근 가능한 URL을 돌려준다. 축하한다 — Haystack 챗봇이 이제 Google Cloud 위의 서버리스 애플리케이션으로 성공적으로 배포되어 돌고 있다! 마지막 단계로 넘어가자. 모든 것이 기대대로 작동하는지 확인하는 배포의 테스트와 검증이다.

배포가 완료되면 Google Cloud Run은 통상 다음 형식의 공개 서비스 URL을 돌려준다.

이 URL을 브라우저에서 연다. Gradio가 구동하는 챗봇 인터페이스가 웹에 살아 있는 모습을 보게 될 것이다 — 로컬 버전과 기능이 동일하다. 이제 이전처럼 챗봇과 상호작용하고 질의를 제출하고 영화 추천을 받을 수 있다. 다만 이번에는 완전히 클라우드에서 돌아간다. 무언가 기대대로 작동하지 않는다면, 문제 해결을 위해 다음 체크리스트를 준비해 둔다.

이 가시성이 배포 이후의 애플리케이션 추적과 관리를 쉽게 만든다. 챗봇이 이제 살아서, 확장 가능한 서버리스 플랫폼에 배포되어, 공개적으로 접근 가능하니, 배포의 여정을 성공적으로 완주한 것이다. GenAI가 구동하는 영화 추천 챗봇이 이제 쓰이고 공유되고 한층 더 강화될 준비를 마쳤다.

서두에서 언급했듯, docker compose가 준비되면 제공되는 안내를 따라 같은 애플리케이션을 다른 클라우드에 배포할 수 있다 — Azure 배포는 Azure Container Apps 배포 안내를, AWS 배포는 Docker가 docker compose 파일의 AWS 배포를 명료하게 안내하는 Docker Compose에서 Amazon ECS로를 따른다. 이 링크들의 안내를 따라가 보면, 애플리케이션을 컨테이너화하기로 했을 때의 배포 접근과의 유사성이 보일 것이다.

Spring Boot 애플리케이션의 클라우드 배포에 관한 정보는 각 클라우드의 공식 문서에 많다. 9장과 10장에서 만든 애플리케이션을 돌리고 싶다면, 여러 클라우드 벤더가 제공하는 문서의 단계를 따를 수 있다.

이 글들은 우리 GenAI 애플리케이션의 배포를 안내하기에 충분하다. 심장부에서 그것은 증강만을 — 그것도 배치 과정으로 — 수행하는, 그 자체로는 확장이 필요 없는 단순한 애플리케이션이기 때문이다. 이 애플리케이션들의 프로덕션 배포는 데이터베이스, 모니터링 등 다양한 지원 요소에 집중해야 하는 더 복잡한 절차다. 전체 배포의 논의는 이 책의 범위를 벗어나지만, 다음 절에서 프로덕션 배포의 아키텍처와 핵심 고려사항을 짚는다.

이 절에서는 지능형 애플리케이션의 전형적 배포 아키텍처를 본다. 프로덕션으로 옮겨 갈 때 유념할 다른 측면도 많다. 단순화를 위해 9장과 10장에서 지은 증강 애플리케이션을 참조한다. 데이터 적재부터 결과 검토까지 우리가 한 모든 과업을 돌아보자. 첫째, 데이터를 그래프에 적재했다. 둘째, 그래프를 계절 관계로 강화했고, 증강 애플리케이션으로 품목과 고객 행동 측면을 증강했다. 셋째, KNN 유사도와 커뮤니티 탐지 알고리즘을 활용해 그래프를 강화하고 이 접근이 더 나은 결과를 주는 방식을 검토했다.

프로덕션 배포에서는 이 모든 측면이 자동화되어 개별 애플리케이션으로 배포되어야 할 수 있다. 챙겨야 할 이 측면들을 짧게 훑어보자. 지능형 애플리케이션을 프로덕션에 배포할 때는 데이터 수집(ingestion), 데이터 소비(consumption), 그래프를 증강하는 LLM/ML 파이프라인, 그리고 규모를 위한 그래프 데이터베이스 배포 아키텍처를 반드시 챙겨야 한다. 먼저 그림 12.1의 배포 아키텍처를 보자.

여기 서로 다른 두 Neo4j 데이터베이스가 보인다. 일반 상호작용을 위한 Neo4j에는 READ와 WRITE 능력을 모두 수행할 수 있는 Primary가 있다. 분석, Graph Data Science(GDS), 그리고 여타 용도로는 READ 능력만 제공하는 Secondary를 쓴다. 고가용성을 위해 Primary를 둘 이상, 수평 확장성을 위해 Secondary를 둘 이상 둘 수 있다. 도해에서 보듯 데이터 수집과 소비를 포함한 모든 일반 상호작용은 Primary가 다루고, 그래프를 증강하는 분석 워크로드는 Secondary가 다룬다.

이런 배포 아키텍처는 시스템의 유지와 모니터링도 쉽게 만든다. Neo4j 데이터베이스는 Neo4j 서버의 배포·모니터링을 위한 Neo4j Ops Manager를 함께 내놓는다. 시스템의 현재 건강을 모니터링하는 대시보드와, 오류 시 통지받도록 알림을 설정하는 기능을 제공한다. 다른 애플리케이션들에도 유사한 모니터링이 필요하다. 특히 데이터 수집과 증강 애플리케이션이 그렇다. 중간에 실패하면 실패한 곳에서 재시작할 수 있어야 한다. 증강 애플리케이션은 데이터를 그렇게 다루도록 지어져 있다.

수집 파이프라인을 지을 때는 이 측면들을 유념해야 한다 — 초기 데이터 크기는 얼마인가? 일상적 변경(증분 데이터 변경)과 그 크기는? 증분 데이터는 어떻게 오는가? 준실시간으로 오는가, 정기 간격의 배치로 오는가, 하루의 끝에 큰 배치로 오는가, 아니면 최종 사용자가 UI로 만드는 상호작용적 변경인가? 이 시나리오들의 모범 사례를 살펴본다.

다른 데이터 소스나 데이터베이스에서 이주하는 경우라면 처음으로 데이터를 Neo4j로 옮겨야 할 수 있다. 이 데이터 크기에 따라, 트랜잭션 접근으로 적재할지 neo4j-admin import라 불리는 오프라인 데이터 임포트 접근을 지렛대 삼을지 결정해야 한다.

9장에서 우리는 트랜잭션 접근으로 데이터를 적재했다. 적재할 데이터가 수백만 건 이하 — 이를테면 1억 건 — 라면 합리적인 시간 안에 적재할 수 있다. 트랜잭션으로 적재할 때 Neo4j 데이터베이스는 데이터를 커밋하는 일과 별개로 인덱스를 갱신하고 트랜잭션 로그를 유지해야 한다. 과정에 상당한 오버헤드가 더해지는 것이다. 그러나 이 접근은 더 큰 유연성과, 증분 데이터 적재에 쓸 재사용 가능한 코드를 준다. 클러스터에 적재한다면 이 접근으로 데이터가 클러스터 전체에 가용하도록 만들 수 있다. Neo4j 데이터베이스 서버가 변경의 클러스터 복제를 보장하기 때문이다. 우리는 LOAD CSV 옵션으로 데이터를 적재했다.

데이터 크기가 더 크다면 Neo4j Admin Import 과정을 쓰는 편이 최선이다. 이를 위해 노드와 관계의 CSV 파일을 특정 형식으로 준비하고 neo4j-admin 도구로 데이터베이스를 마련해야 한다. CSV 파일 형식과 예제는 운영 매뉴얼에서 더 읽을 수 있다.

증분 데이터 적재의 접근은 적재에 쓸 프레임워크에 달렸다. 스트리밍 데이터가 많다면 Apache Kafka 같은 프레임워크의 활용이 좋은 생각일 수 있다. Java, JavaScript, .NET, Python 같은 언어 프레임워크로 데이터베이스와 상호작용해 데이터를 수집하는 애플리케이션을 짓는 일도 수월하다. Neo4j 클라이언트 애플리케이션 구축은 공식 문서에서 읽을 수 있다.

유념할 것 하나 — 관리형 트랜잭션 함수(managed transactional functions)를 지렛대 삼아야 한다. 네트워크 장애나 서버 장애로 클러스터 토폴로지가 바뀔 때 드라이버가 필요에 따라 트랜잭션을 재시도할 수 있게 하기 위함이다. Java 매뉴얼의 트랜잭션 문서에서 더 읽을 수 있다. Java 사용법을 가리키는 링크지만 같은 기능이 지원되는 모든 언어 프레임워크에서 가용하다.

품목 증강과 고객 증강을 Spring Boot 애플리케이션으로 지었지만, 자동화를 들여다보지 않은 다른 측면들이 있다. 고객의 지정된 계절에 대한 임베딩을 생성한 뒤, 우리는 KNN 유사도와 커뮤니티 탐지 같은 ML 측면을 개별 명령으로 실행했다. 이 측면들도 자동화해야 할 수 있다. 새 데이터가 그래프에 수집될 때마다, 적재된 새 데이터에 적응하는 임베딩을 생성하도록 증강 애플리케이션을 촉발하고, 그것이 완료된 뒤 GDS 알고리즘을 촉발해야 할 수 있는 것이다. 우리가 본 ML 파이프라인은 KNN 유사도와 커뮤니티 탐지의 단순한 사슬이지만, 필요에 따라 훨씬 복잡해질 수 있다. Neo4j와 함께하는 ML 파이프라인은 GDS 문서에서 더 읽는다.

우리는 분석과 검증의 일부로 추천을 Cypher 질의로 보는 방법을 탐구했다. 질의에 만족하고 나면, 필요할 때 요청에 따라(on demand) 추천을 제공하는 애플리케이션을 지어야 할 수 있다. 우리는 애플리케이션을 Spring Framework 위에 지었다. 배포와 모니터링을 쉽게 만드는 프로덕션급 애플리케이션 구축의 다양한 능력과 옵션을 제공하는 프레임워크다. 프로덕션 배포를 위한 Spring 애플리케이션 패키징은 패키징 문서에서, 애플리케이션 모니터링을 돕는 프로덕션 수준 기능은 Actuator 문서에서 더 읽을 수 있다.

이것이 배포의 핵심 원칙과 고려사항이다. 프로덕션 배포에는 적절한 배포 아키텍처와 애플리케이션 개발을 포함한 여러 측면이 함께 고려되어야 한다. 데이터와 트래픽이 자라면서 애플리케이션이 사용량에 맞춰 확장되도록, 모니터링과 성능 평가를 위한 여러 과정이 배포되어야 한다.