글

GCP 데이터베이스 선택 가이드 — Firestore·Cloud SQL·BigQuery 무엇을 쓸까

이미지
이 글은 「GCP 기초」 연재의 여섯 번째 글이다. 앞 편에서 파일 둘 곳을 만들었다면 이번에는 데이터 차례다. 그런데 콘솔의 데이터베이스 메뉴를 열면 이름이 열 개 넘게 쏟아진다. 그중 개인 프로젝트에서 실제로 고민하게 되는 건 Firestore, Cloud SQL, BigQuery 세 개다. 셋 다 데이터베이스라고 불리지만 성격도, 요금 매기는 방식도, 무료 한도 유무도 전부 다르다. 이 글을 다 읽으면 내 프로젝트에 무엇이 맞는지 를 세 번의 질문으로 정할 수 있다. 같은 이름으로 불리지만 다른 물건이다 Firestore 는 문서형 NoSQL이다. JSON 비슷한 문서 를 컬렉션에 담고, 문서 하나를 통째로 읽고 쓴다. 테이블도 스키마도 미리 정하지 않고, 앱이 데이터 변경을 실시간으로 받아 볼 수 있다. 모바일·웹 앱의 저장소로 만들어진 물건이다. Cloud SQL 은 우리가 아는 그 관계형 DB다. MySQL·PostgreSQL·SQL Server를 구글이 대신 운영해 준다. 테이블과 스키마가 있고 조인과 트랜잭션이 되며, 기존 SQL 지식이 그대로 통한다. 대신 서버 한 대를 빌리는 구조 라는 점이 뒤에서 요금을 가른다. BigQuery 는 데이터베이스라기보다 분석 창고 다. 수억 행을 통째로 훑어 집계하는 데 특화돼 있다. SQL로 질의하지만 안에서 하는 일이 완전히 달라서, 한 건을 찾아 꺼내는 작업에는 오히려 느리고 비싸다. 데이터베이스 메뉴. 이 글에서 다루는 셋 외에도 AlloyDB·Spanner·Bigtable·Memorystore가 함께 보인다 어떤 일에 무엇이 맞나 하려는 일 맞는 것 이유 앱 회원 정보·게시글 저장 Firestore 문서 단위 읽기·쓰기, 실시간 반영 주문·재고처럼 정합성이 중요 Cloud SQL 트랜잭션과 조인이 필요 로그·결제 내역 집계 리포트 BigQuery 대량 스캔 집계에 특화 이미지·동영상 파일 Cloud Storage 애초에 DB에 넣을 것이 아니다 요금 매기는 잣대가 서로 ...
댓글 쓰기
자세한 내용 보기

Cloud Storage 실전 — 버킷 만들기부터 공개 설정·수명 주기까지

이미지
이 글은 「GCP 기초」 연재의 다섯 번째 글이자 2단계의 첫 글이다. 1단계에서 계정·비용·권한이라는 바닥을 깔았으니 이제 그 위에 서비스를 올린다. 첫 순서를 Cloud Storage로 잡은 이유는 단순하다. 어떤 프로젝트든 파일 둘 곳이 필요하고, 초보자가 가장 크게 사고를 내는 자리도 여기다. 이 글을 다 읽으면 버킷을 만들고, 공개 범위를 의도한 만큼만 열고, 안 쓰는 파일을 자동으로 치울 수 있다. 버킷과 객체, 그리고 이름 전쟁 구조는 두 층뿐이다. 버킷 이 그릇이고 객체 가 그 안의 파일이다. 폴더처럼 보이는 images/2026/photo.jpg 도 사실은 폴더가 아니라 객체 이름 전체 다. 첫 관문은 이름이다. 버킷 이름은 내 프로젝트 안이 아니라 전 세계에서 유일 해야 한다. backup 같은 이름이 안 된다고 나오는 것은 지구 어딘가에서 누가 쓰고 있다는 뜻이다. 가장 편한 해법은 프로젝트 ID를 접두어로 붙이는 것이다. your-project-id-assets 같은 이름은 거의 비어 있다. 그리고 버킷 이름도 만든 뒤에는 못 바꾼다 . 버킷 만들기. 위치와 스토리지 클래스를 고르면 오른쪽에 GB당 단가가 바로 표시된다 리전과 클래스는 만들 때 정해진다 위치는 단일·이중·멀티 리전 중에 고른다. 실습이면 단일 리전 이다. 함정이 있는데, Cloud Storage의 상시 무료 5GB는 us-west1 · us-central1 · us-east1 세 리전에서만 적용된다. 서울 리전에 만들어 놓고 왜 요금이 붙느냐고 묻는 경우가 여기다. 무료 한도 전반은 GCP 무료로 어디까지 되나 — 무료 등급과 크레딧 활용법 에 정리해 두었다. 스토리지 클래스는 얼마나 자주 꺼내 볼 파일인가 로 고른다. 저장 단가는 아래로 갈수록 싸지지만 꺼낼 때 검색 요금이 붙고 최소 보관 기간 이 생긴다. 이 최소 기간이 가장 억울한 요금이다. Nearline에 올린 파일을 사흘 만에 지워도 30일치가 청구된다. 정리 주기가 한 달 미만이면 그...
댓글 쓰기
자세한 내용 보기

GCP IAM 기초 — 서비스 계정과 권한, 최소 권한 원칙

이미지
이 글은 「GCP 기초」 연재의 네 번째 글이자 1단계 마지막 글이다. IAM은 팀이 커진 다음에 배우는 것이라고 미루기 쉬운데, 혼자 쓸 때야말로 잘못 잡아 두기 쉬운 영역이다. 혼자니까 전부 소유자 권한으로 쓰고, 편하니까 키 파일을 받아서 코드 옆에 둔다. 앞 편에서 본 요금 사고의 셋째 갈래가 정확히 여기서 나온다. 이 글을 다 읽으면 IAM을 문장 하나로 읽을 수 있고, 키 파일을 받지 않고 인증하는 방법을 알게 된다. IAM은 문장 하나로 끝난다 IAM 화면. 역할별로 접으면 어떤 역할에 누가 붙어 있는지 한눈에 보인다 IAM(Identity and Access Management)은 세 가지의 조합이다. 주 구성원 에게 리소스 에 대한 역할 을 부여한다. 이 한 문장이 전부다. 주 구성원(principal) — 누가. 구글 계정, 그룹, 그리고 서비스 계정이 여기 들어간다. 역할(role) — 무엇을 할 수 있게. 권한들을 묶어 놓은 꾸러미다. 리소스(resource) — 어디에서. 프로젝트, 버킷, 특정 서비스 등이다. 여기서 자주 하는 착각이 하나 있다. 권한을 개별로 붙이는 게 아니라 역할 단위로만 붙는다는 점이다. 그래서 "이 권한 하나만 주고 싶다"는 요구는 그 권한이 들어 있는 역할을 찾거나, 맞춤 역할을 만들어서 해결한다. 또 하나, 앞서 본 리소스 계층 때문에 상위에 준 역할은 하위로 상속된다. 프로젝트에 편집자를 주면 그 안의 모든 리소스에 편집 권한이 간다는 뜻이다. 역할 세 종류, 무엇을 골라야 하나 액세스 권한 부여 화면. 역할 선택을 열면 기본·직무 기반과 서비스별 사전 정의 역할을 검색해 고를 수 있다 기본 역할 은 소유자·편집자·뷰어 세 개다. IAM이 생기기 전부터 있던 것으로, 하나에 수천 개의 권한이 묶여 있다. 공식 문서도 이 역할은 최후의 수단으로 쓰라고 안내한다. 사전 정의 역할 은 구글이 서비스별로 만들어 둔 것이다. 이름이 roles/run....
댓글 쓰기
자세한 내용 보기

GCP 요금 폭탄 막는 법 — 예산 알림·할당량·비용 통제

이미지
이 글은 「GCP 기초」 연재의 세 번째 글이다. 앞 편이 "얼마까지 공짜인가"였다면 이번은 반대편이다. 클라우드 요금 사고는 예산을 조금 넘기는 방식으로 오지 않는다. 잘 돌아가다가 하룻밤 사이에 자릿수가 바뀐다. 이 글에서는 사고가 나는 전형적인 경로를 먼저 보고, 예산 알림 → 할당량 → 자동 차단 세 겹을 실제로 거는 순서를 짚는다. 이미 나간 돈을 분석하는 이야기가 아니라, 나가기 전에 막는 이야기다. 요금 사고는 대개 이 세 갈래다 첫째는 반복 호출 이다. 재시도 로직이 잘못 걸린 코드나 무한 루프가 밤새 API를 두드린다. 요청 단가가 낮아도 횟수가 붙으면 금액은 금방 커진다. 둘째는 끄는 걸 잊은 리소스 다. 실습으로 띄운 VM, 붙여 둔 GPU, 만들어 놓고 안 지운 로드밸런서와 고정 외부 IP는 아무 일도 하지 않으면서 시간당 요금을 만든다. 셋째는 유출된 자격 증명 이다. 서비스 계정 키 파일이 공개 저장소에 올라가면 남이 내 프로젝트에서 자원을 쓴다. 이 경우는 앞의 둘보다 알아채기가 훨씬 어렵다. 세 경우의 공통점은 사람이 보고 있지 않은 시간에 진행되고, 청구서를 봐야 알게 된다는 것이다. 그래서 사후 분석보다 사전 차단 이 먼저다. 1차 방어선 — 예산 및 알림 예산 만들기 첫 단계. "알림만"과 "지출 한도 적용" 중 무엇을 고르느냐에 따라 이후 화면이 달라진다 콘솔의 결제 → 예산 및 알림 에서 만든다. 정의 → 범위 → 금액 → 작업 네 단계로 진행되는데, 첫 단계인 정의에서 성격이 완전히 다른 두 가지 중 하나를 고르게 된다. 알림만 — 모든 서비스에서 쓸 수 있다. 임계값을 넘으면 메일이 오지만 지출은 계속된다. 지출 한도 적용 — 일부 서비스에서만 쓸 수 있고 미리보기 단계다. 한도에 닿으면 지정한 서비스의 사용량이 실제로 일시 중지된다. 이 둘은 대체재가 아니다. 지출 한도는 대상 서비스가 제한적이라 이것만 믿을 수 없고, 알림만으로는 ...
댓글 쓰기
자세한 내용 보기

GCP 무료로 어디까지 되나 — 무료 등급과 크레딧 활용법

이미지
이 글은 「GCP 기초」 연재의 두 번째 글이다. 앞 글에서 계정과 프로젝트 구조를 잡았다면, 이제 궁금한 것은 하나다. 이걸 어디까지 공짜로 쓸 수 있나 . GCP의 무료 혜택은 성격이 완전히 다른 두 가지가 같은 이름으로 묶여 있어서 처음에는 반드시 헷갈린다. 이 글을 다 읽으면 크레딧과 무료 등급을 구분해서 말할 수 있고, 실습 내내 청구서를 0원으로 유지하는 기준선을 갖게 된다. 크레딧과 무료 등급은 다른 것이다 결제 → 크레딧. 300달러가 원화로 환산되어 들어오고, 남은 비율과 만료된 크레딧이 함께 보인다 신규 가입자에게 주는 것은 무료 체험 크레딧 이다. 공식 문서 기준으로 300 USD 상당의 크레딧을 가입일로부터 90일 동안 쓸 수 있다. 이것은 한 번 소진하면 끝나는 잔액이고, 기간이 지나면 남아 있어도 사라진다. 반면 상시 무료 등급 (Free Tier)은 종료일이 없다. 정해진 한도 안에서 쓰는 동안은 계속 0원이고, 한도는 매달 초기화된다. 크레딧이 다 떨어져도 이 등급은 그대로 남는다. 다만 이 등급을 쓰려면 결제 계정이 있어야 한다. "무료 등급이니까 카드 없이 된다"는 오해가 여기서 나온다. 한도는 남아도 다음 달로 이월되지 않는다는 점, 그리고 구글이 30일 전 고지 후 한도를 바꿀 수 있다는 점도 문서에 명시돼 있다. 개인 사용자가 실제로 닿는 한도 무료 등급 대상은 스무 개가 넘지만, 개인 프로젝트에서 실제로 부딪히는 것은 몇 개 안 된다. 위 표의 값은 2026년 8월 공식 문서 기준이며 리전과 과금 방식에 따라 달라질 수 있다. 여기서 놓치기 쉬운 조건이 리전 제약 이다. Compute Engine의 e2-micro 무료 한도와 Cloud Storage 5GB는 미국 일부 리전에서만 적용된다. 서울 리전에 만들어 놓고 "무료라던데 왜 돈이 나가지"라고 묻는 경우가 여기 해당한다. 응답 속도가 중요하지 않은 실습이라면 리전을 무료 대상으로 고정해 두는 편이 안전하...
댓글 쓰기
자세한 내용 보기

GCP 처음 시작하기 — 계정·프로젝트·결제 구조 이해하기

이미지
이 글은 「GCP 기초」 연재의 첫 번째 글이다. 구글 클라우드(Google Cloud Platform, 이하 GCP)에 처음 가입한 사람이 가장 먼저 막히는 지점은 서비스 사용법이 아니라 계정 구조다. 구글 계정과 GCP 계정이 같은 것인지, 프로젝트를 왜 굳이 만들어야 하는지, 등록한 카드가 어디에 붙는지가 정리되지 않으면 그다음 작업이 전부 불안해진다. 이 글에서는 GCP가 무엇인지부터 짚고, 콘솔에 접속해 계정·프로젝트·결제 계정 세 가지가 어떻게 맞물리는지까지 확인한다. 처음에만 정할 수 있고 나중에는 되돌릴 수 없는 항목도 함께 정리한다. GCP란 무엇인가 GCP는 구글이 자사 서비스를 돌리는 데 쓰는 서버·저장소·네트워크를 외부에 빌려주는 클라우드 플랫폼이다. 유튜브와 구글 검색이 올라가 있는 것과 같은 인프라 위에, 필요한 만큼만 빌려 쓰고 쓴 만큼 지불하는 방식이다. 직접 서버를 사서 두는 것과 비교하면 차이가 분명하다. 장비를 미리 구입할 필요가 없고, 트래픽이 늘면 용량을 늘렸다가 줄일 수 있으며, 쓰지 않는 시간에는 비용이 거의 발생하지 않는 서비스도 있다. 대신 요금 구조가 복잡하고, 설정을 잘못하면 예상치 못한 비용이 나온다는 점이 진입 장벽이다. 이 연재가 계정과 비용 이야기부터 시작하는 이유가 여기에 있다. 어떤 서비스가 있나 GCP의 서비스는 100개가 넘지만 처음에 알아야 할 것은 몇 개 되지 않는다. 성격별로 묶으면 이렇다. 분야 대표 서비스 무엇을 하나 컴퓨팅 Compute Engine, Cloud Run, Cloud Functions 코드나 서버를 실행한다 저장 Cloud Storage 파일·이미지·백업을 보관한다 데이터베이스 Firestore, Cloud SQL, BigQuery 데이터를 저장하고 질의한다 AI·머신러닝 Vertex AI AI 모델을 호출하거나 학습시킨다 관리·보안 IAM, Secret Manager, Cloud Logging 권한·비밀값·기록을 다룬다 AWS나 Azure를 써...
댓글 쓰기
자세한 내용 보기

AI 에이전트 비용 관리와 거버넌스 — 폭주를 막는 실전 설계

이미지
에이전트를 붙이고 나서 처음 놀라는 지점은 성능이 아니라 청구서다. 챗봇은 한 번 물으면 한 번 답하지만, 에이전트는 한 번의 요청으로 수십 번 모델을 호출한다. 단가는 그대로인데 호출 횟수가 두 자릿수로 곱해지는 구조다. 게다가 에이전트는 스스로 멈추지 않는다. 실패한 도구 호출을 계속 다시 부르고, 같은 파일을 몇 번이고 다시 읽는다. 이 글은 어디서 비용이 새는지, 무엇을 코드로 못 박아야 하는지, 그리고 에이전트에게 어디까지 권한을 줄 것인지를 정리한다. 비용이 새는 다섯 지점 무한 재시도 — 종료 조건 없이 도구 호출을 반복한다. 가장 흔하고 가장 비싸다. 컨텍스트 재전송 — 매 턴 전체 대화와 파일을 다시 첨부한다. 열 번째 턴은 첫 턴의 몇 배 비용이 든다. 도구 과다 노출 — 쓰지 않는 도구의 정의까지 매 호출마다 함께 전송된다. 연결한 서버가 늘수록 고정 비용이 커진다. 모델 획일화 — 로그 분류나 형식 변환처럼 쉬운 일까지 최상위 모델로 처리한다. 병렬 폭주 — 동시 실행 수를 정하지 않아 한 요청이 수십 개 호출로 번진다. 다섯 가지의 공통점은 단건 비용이 작다는 것이다. 한 번의 호출은 눈에 띄지 않고, 합계만 조용히 쌓인다. 그래서 대응도 사후 절감이 아니라 사전 상한이어야 한다. 가장 먼저 할 일 — 상한을 코드로 못 박는다 프롬프트에 "간결하게 처리하라"고 쓰는 것은 비용 통제가 아니다. 실행 루프 바깥에 물리적 한계를 두는 것이 통제다. class Budget: def __init__(self, max_steps=15, max_tokens=250_000, max_parallel=4): self.max_steps, self.max_tokens = max_steps, max_tokens self.max_parallel = max_parallel self.steps, self.tokens = 0, 0 def charge(self...
댓글 쓰기
자세한 내용 보기