GCP AutoML로 이미지 분류 모델 만드는 방법 (Cloud Vision API 실습 기반 완전 가이드)

이 글은 머신러닝을 처음 접하는 클라우드 학습자를 위한 실습 기록입니다.
문제는 이미지 분류 모델을 만들려면 데이터를 어떻게 준비하고, 어디에 업로드하고, 어떤 순서로 학습시키고, 마지막에는 어떻게 예측까지 연결하는지 전체 흐름이 잘 보이지 않는다는 점입니다.
이 글을 통해 Cloud Storage에 이미지와 라벨 데이터를 업로드하고, Vertex AI AutoML로 이미지 분류 모델을 준비한 뒤, API를 통해 예측까지 수행하는 전체 과정을 이해할 수 있습니다.

이 글의 핵심 질문
GCP에서 AutoML을 활용해 이미지 분류 모델을 만들고 예측하려면 어떻게 해야 하는가?

---

실습 환경

• Cloud: Google Cloud Platform
• 서비스: Cloud Storage, Vertex AI (AutoML), Cloud Run Endpoint
• Region: us-central1
• 데이터 유형: 이미지 (구름 사진)
• 분류 대상: cirrus, cumulus, cumulonimbus
• 예측 방식: JSON 요청 → API 응답

---

아키텍처

이번 실습의 핵심 구조는 매우 명확합니다. 구름 이미지와 CSV 라벨 파일을 Cloud Storage에 저장하고, Vertex AI Dataset으로 불러온 뒤 AutoML로 학습 구조를 만들고, 마지막에는 배포된 예측 엔드포인트를 통해 결과를 반환받는 구조입니다.

 

Cloud Storage → Vertex AI Dataset → AutoML Training → Model Registry / Endpoint → Prediction API

---

전체 흐름

이번 실습은 크게 5단계로 진행됩니다.

1. Cloud Storage 버킷 생성
2. 학습용 이미지와 CSV 라벨 데이터 업로드
3. Vertex AI Dataset 생성 및 이미지 가져오기
4. AutoML 학습 설정
5. API 예측 요청 및 결과 확인

즉, 이 실습의 핵심은 단순히 이미지를 업로드하는 것이 아니라 데이터 → 모델 → API 서비스 구조를 처음부터 끝까지 이해하는 데 있습니다.

---

■ 강사 설명

실습은 세 종류의 구름 이미지를 분류하는 예제로 구성됩니다. 모델이 학습해야 하는 클래스는 cirrus, cumulus, cumulonimbus입니다. AutoML은 코드 없이 이미지 분류 모델을 만들 수 있도록 해주며, 이를 위해 먼저 라벨이 붙은 학습 이미지가 Cloud Storage에 있어야 합니다.

즉, 이번 실습은 “AI를 쓰는 법”보다 먼저 AI가 학습할 수 있는 데이터를 어떻게 준비하고 연결하는지를 익히는 과정이라고 보는 것이 더 정확합니다.

---

■ 내가 이해한 핵심

이번 실습의 본질은 아주 분명합니다.

머신러닝은 모델보다 데이터 구조가 먼저다

많은 초보자가 AutoML을 쓰면 버튼만 몇 번 누르면 끝난다고 생각합니다. 하지만 실제로는 버킷 생성, 이미지 업로드, CSV 라벨 정리, Dataset 연결, 예측 입력 형식까지 모두 제대로 맞아야 결과가 나옵니다.

즉, AutoML은 코드를 줄여주는 도구이지, 데이터 준비를 대신해주는 마법은 아닙니다.

---

■ 내가 실제로 겪은 문제

실습 중 예측 API를 호출했을 때 바로 성공하지 않았습니다. 가장 먼저 마주친 에러는 아래와 같은 형태였습니다.

{
  "error": {
    "code": 400,
    "message": "Empty instances.",
    "status": "INVALID_ARGUMENT"
  }
}

원인은 단순했습니다. 예측 요청은 보냈지만, 실제 입력 이미지 데이터(JSON)가 지정되지 않았기 때문입니다. 이 경험을 통해 분명해졌습니다. 예측 시스템은 모델만 있어서는 동작하지 않고, 입력 포맷까지 정확히 맞아야 한다는 점입니다.

---

실습 단계

1단계. Cloud Storage 버킷 생성

목적: 학습 이미지와 라벨 CSV 파일을 저장할 공간을 만드는 단계입니다.

먼저 Cloud Shell에서 아래 명령으로 버킷을 생성합니다.

gcloud storage buckets create gs://$GOOGLE_CLOUD_PROJECT-vcm \
 -c standard \
 -l us-central1

이 버킷은 이후 학습 이미지와 CSV 파일을 담는 저장소 역할을 합니다. 실습 문서도 가장 먼저 이 버킷을 만들고, 콘솔의 Cloud Storage 화면에서 실제로 생성되었는지 확인하라고 안내합니다.

이 단계가 중요한 이유는 Vertex AI가 학습 데이터를 직접 읽을 수 있는 위치가 필요하기 때문입니다. 즉, 로컬 PC 폴더가 아니라 클라우드 내부에서 일관되게 접근 가능한 저장소를 먼저 확보해야 합니다. 여기서부터 이미 “AI 실험”이 아니라 “클라우드 기반 ML 파이프라인”이 시작됩니다.

---

2단계. 학습 이미지 업로드

목적: 모델이 학습할 실제 이미지 데이터를 Cloud Storage에 넣는 단계입니다.

먼저 버킷 이름을 환경 변수로 저장합니다.

export BUCKET=$GOOGLE_CLOUD_PROJECT-vcm

그 다음 공개 버킷에 준비되어 있는 학습 이미지를 내 버킷으로 복사합니다.

gcloud storage cp -r gs://spls/gsp223/images/* gs://${BUCKET}

복사가 끝나면 Cloud Storage 브라우저에서 버킷을 새로고침하고 내부를 확인합니다. 실습 문서 기준으로 세 가지 구름 종류에 해당하는 폴더가 보입니다. 즉, 모델은 단순히 “이미지 모음”을 학습하는 것이 아니라 라벨별로 구분된 이미지 집합을 학습하게 됩니다. :contentReference[oaicite:0]{index=0}

이 단계에서 중요한 점은 이미지를 그냥 많이 넣는 것이 아니라, 분류 대상이 명확히 구분되어 있어야 한다는 것입니다. 폴더 구조와 라벨 정보가 뒤섞이면 이후 CSV 매핑 단계에서 바로 문제가 생깁니다.

---

3단계. CSV 라벨 파일 준비 및 업로드

목적: 이미지 파일과 라벨명을 연결하는 메타데이터를 만드는 단계입니다.

AutoML은 “이 이미지가 어떤 클래스인지”를 알아야 학습할 수 있습니다. 이를 위해 실습에서는 CSV 파일을 사용합니다. 먼저 준비된 data.csv를 Cloud Shell로 가져옵니다.

gcloud storage cp gs://spls/gsp223/data.csv .

그 다음 이 파일 안의 placeholder를 내 버킷명으로 치환합니다.

sed -i -e "s/placeholder/${BUCKET}/g" ./data.csv

이제 수정된 CSV를 다시 Cloud Storage 버킷에 업로드합니다.

gcloud storage cp ./data.csv gs://${BUCKET}

이 CSV는 매우 중요합니다. 이미지 자체는 “픽셀 데이터”일 뿐이고, CSV가 있어야 AutoML이 어떤 이미지가 cirrus인지, cumulus인지, cumulonimbus인지 이해할 수 있습니다. 실습 문서도 “각 행에 이미지 URL과 해당 라벨이 들어 있는 CSV”가 필요하다고 설명합니다. :contentReference[oaicite:1]{index=1}

즉, 이 단계는 파일 업로드가 아니라 학습 데이터셋의 정답표를 준비하는 단계라고 이해하는 것이 맞습니다.

---

4단계. Vertex AI Dataset 생성 및 Cloud Storage CSV 불러오기

목적: 이미지 + 라벨 데이터를 Vertex AI가 이해할 수 있는 Dataset으로 구조화하는 단계입니다.

이제 Vertex AI의 Dataset 화면으로 이동한 뒤, 상단의 + CREATE를 클릭합니다. Dataset 이름은 clouds로 설정하고, 유형은 Image classification (Single-label)을 선택합니다.

여기서 Single-label을 쓰는 이유는 한 장의 구름 사진이 세 클래스 중 하나에만 해당한다고 가정하기 때문입니다. 만약 한 이미지에 여러 라벨이 동시에 붙을 수 있다면 multi-label classification이 더 적합했을 것입니다. 실습 문서도 실제 프로젝트에서는 multi-class classification을 고려할 수 있다고 언급하지만, 이번 예제에서는 Single-label을 선택합니다. :contentReference[oaicite:2]{index=2}

생성 후에는 Select import files from Cloud Storage를 선택하고, 방금 업로드한 data.csv의 URI를 입력합니다. 이후 Continue를 누르면 이미지 import가 시작됩니다. 보통 2~5분 정도 지나면 모든 이미지가 Dataset 안으로 불러와지고, Browse 탭에서 확인할 수 있습니다. :contentReference[oaicite:3]{index=3}

이 단계에서 초보자가 자주 놓치는 점은 “이미지를 직접 업로드하는 것이 아니라 CSV를 통해 일괄 가져온다”는 것입니다. 이 방식이 훨씬 재현 가능하고, 대량 데이터 관리에도 유리합니다.

---

5단계. 가져온 이미지 검토 및 라벨 확인

목적: 학습 전에 데이터 품질을 눈으로 검증하는 단계입니다.

Import가 끝나면 Browse 탭으로 이동해 업로드된 이미지를 볼 수 있습니다. 왼쪽 필터 메뉴에서 cumulus, cirrus, cumulonimbus 같은 라벨을 클릭하면 해당 라벨 이미지들만 따로 볼 수 있습니다.

실습 문서는 여기서 중요한 주의점을 하나 줍니다. 데모에서는 라벨당 20장씩만 사용하지만, 실제 프로덕션 모델에서는 보통 라벨당 최소 100장 이상이 있어야 정확도가 더 좋아질 수 있다는 점입니다. 즉, 이번 실습은 개념 학습용이지, 실제 고정확도 프로덕션 모델 수준은 아니라는 뜻입니다. :contentReference[oaicite:4]{index=4}

또한 잘못 라벨링된 이미지가 있다면 수동으로 바꿀 수 있습니다. 이 단계가 중요한 이유는 모델 성능이 결국 데이터 품질에 의해 결정되기 때문입니다. AutoML이 모델을 자동으로 만들어줘도, 라벨이 틀리면 결과도 틀어집니다.

---

6단계. AutoML 학습 설정 이해하기

목적: 모델을 학습시키기 전에 어떤 옵션이 필요한지 이해하는 단계입니다.

Dataset 화면에서 TRAIN NEW MODEL을 누르면 학습 마법사가 시작됩니다. 실습에서는 Training method, Model details, Training options, Explainability를 차례로 Continue 하게 되어 있고, 마지막 Compute and pricing 탭에서 node hours를 8로 설정하라고 안내합니다. :contentReference[oaicite:5]{index=5}

다만 실습 문서는 실제로 Start Training까지는 진행하지 않고 Cancel 하라고 합니다. 이유는 학습이 최대 120분 정도 걸릴 수 있기 때문입니다. 대신 다음 단계에서 사전 배포된 모델을 사용해 예측 흐름을 확인합니다.

이 단계에서 중요한 개념은 node hours입니다. 이것은 단순 시간이 아니라 “컴퓨팅 예산”에 가깝습니다. 즉, AutoML은 무료 마법이 아니라 비용과 자원을 사용하는 학습 서비스입니다. 실무에서는 정확도와 예산을 함께 고려해야 합니다.

---

7단계. 예측용 이미지 다운로드와 Endpoint 확보

목적: 이미 준비된 모델에 실제 예측 요청을 보내기 위한 준비 단계입니다.

먼저 Cloud Shell에서 예측 테스트용 예제 파일을 다운로드합니다.

gcloud storage cp gs://spls/gsp223/examples/* .

이 파일들 안에는 Base64로 인코딩된 이미지가 들어 있습니다. 즉, API는 이미지 파일을 직접 보내는 것이 아니라 JSON 안에 인코딩된 콘텐츠를 담아 전송합니다.

그 다음 사전 배포된 AutoML 모델의 Endpoint 값을 환경 변수에 저장합니다.

ENDPOINT=$(gcloud run services describe automl-service --platform managed --region us-central1 --format 'value(status.url)')

이 단계는 매우 중요합니다. 모델이 있다고 곧바로 예측 가능한 것이 아니라, 예측 요청을 받을 API 엔드포인트가 있어야 외부 요청이 가능합니다. 즉, 모델과 서비스는 다르며, Endpoint는 그 둘을 연결하는 다리 역할을 합니다.

---

8단계. 예측 요청 실패를 통해 입력 구조 이해하기

목적: 예측 API가 어떤 입력을 필요로 하는지 이해하는 단계입니다.

이제 curl로 예측 요청을 보냅니다.

curl -X POST -H "Content-Type: application/json" $ENDPOINT/v1 -d "@${INPUT_DATA_FILE}" | jq

하지만 이 시점에는 아직 INPUT_DATA_FILE이 지정되지 않았기 때문에 요청이 실패합니다. 실습 문서는 이 상황에서 아래와 같은 400 에러가 나온다고 설명합니다.

{
  "error": {
    "code": 400,
    "message": "Empty instances.",
    "status": "INVALID_ARGUMENT"
  }
}

이 실패는 오히려 매우 교육적입니다. API 예측 시스템은 “모델 존재 여부”보다 “입력 포맷이 유효한가”에 훨씬 민감하다는 점을 보여주기 때문입니다. 즉, 머신러닝 서비스는 학습이 끝나도 입력 JSON 구조를 정확히 맞추지 못하면 작동하지 않습니다. :contentReference[oaicite:6]{index=6}

---

9단계. 실제 예측 요청 수행

목적: 입력 JSON을 지정한 뒤 모델이 실제로 구름 종류를 예측하는지 확인하는 단계입니다.

먼저 첫 번째 입력 파일을 지정합니다.

INPUT_DATA_FILE=CLOUD1-JSON

그 다음 같은 curl 명령으로 예측을 요청합니다.

curl -X POST -H "Content-Type: application/json" $ENDPOINT/v1 -d "@${INPUT_DATA_FILE}" | jq

실습 문서에 따르면 응답 결과에는 "displayNames": ["cirrus"]가 포함됩니다. 즉, 첫 번째 예제 이미지는 cirrus로 분류됩니다. 페이지 7의 구름 사진도 실제로 가늘고 얇은 선형 구름 형태를 보여주며, cirrus와 일치합니다. :contentReference[oaicite:7]{index=7}

이후 두 번째 입력 파일을 지정합니다.

INPUT_DATA_FILE=CLOUD2-JSON

다시 같은 요청을 보내면 결과는 "displayNames": ["cumulonimbus"]로 반환됩니다. 페이지 8 하단 이미지 역시 수직으로 크게 발달한 적란운 형태를 보여주며, cumulonimbus와 잘 맞습니다. :contentReference[oaicite:8]{index=8}

이 단계에서 얻는 핵심은 분명합니다. AutoML 모델은 학습으로 끝나는 것이 아니라, API를 통해 실제 입력을 받아 분류 결과를 반환할 때 비로소 서비스가 된다는 점입니다.

---

실습 증거

1. Cloud Storage와 data.csv 업로드

실습 문서는 버킷 생성 후 이미지 폴더와 data.csv를 Cloud Storage에 올리고, Vertex AI Dataset에서 그 CSV를 사용해 이미지를 import하도록 안내합니다. 이것이 학습 데이터 준비의 핵심 증거입니다. :contentReference[oaicite:9]{index=9}

2. Empty instances 에러

페이지 6~7은 INPUT_DATA_FILE 없이 예측 요청을 보내면 400 에러와 함께 Empty instances. 메시지가 나온다고 명시합니다. 이는 입력 JSON 구조가 예측 API에서 얼마나 중요한지 보여주는 직접 증거입니다. :contentReference[oaicite:10]{index=10}

3. 예측 결과 cirrus / cumulonimbus

페이지 8과 9는 CLOUD1-JSON 예측 결과가 cirrus, CLOUD2-JSON 결과가 cumulonimbus임을 보여줍니다. 이는 모델이 실제로 서로 다른 유형의 구름 이미지를 분류하고 있음을 보여주는 실습 증거입니다. :contentReference[oaicite:11]{index=11}

---

트러블슈팅

문제 증상:
예측 요청을 보냈는데 400 에러가 발생하고 결과가 반환되지 않는다.

원인 분석:
INPUT_DATA_FILE이 지정되지 않았거나, JSON 안의 instances 구조가 비어 있다.

확인 방법:
응답 메시지에 Empty instances.가 있는지 확인한다.

해결 방법:
INPUT_DATA_FILE=CLOUD1-JSON 또는 INPUT_DATA_FILE=CLOUD2-JSON처럼 예측용 입력 파일을 먼저 지정한 뒤 다시 요청한다.

재발 방지 방법:
예측 전에 Endpoint뿐 아니라 입력 JSON 파일 경로와 내부 구조까지 함께 점검한다.

---

문제 증상:
모델은 만들어졌지만 정확도가 기대만큼 높지 않을 수 있다.

원인 분석:
라벨당 이미지 수가 너무 적거나, 라벨 오류가 존재할 수 있다.

확인 방법:
Browse 탭에서 라벨별 이미지를 필터링해 품질을 직접 눈으로 검토한다.

해결 방법:
라벨당 이미지 수를 늘리고, 잘못 분류된 이미지를 수정한다.

재발 방지 방법:
프로덕션 모델에서는 라벨당 충분한 데이터(실습 문서 기준 최소 100장 수준 권장)를 확보한다.

---

실무 핵심 포인트

이번 실습의 가장 중요한 교훈은 아래 한 문장으로 정리됩니다.

AutoML은 모델을 쉽게 만들어주지만, 서비스 품질은 여전히 데이터 구조와 입력 설계가 결정한다

즉, Cloud Storage는 단순 저장소가 아니라 학습 데이터의 기준점이고, CSV는 단순 파일이 아니라 라벨 매핑 규칙이며, Endpoint는 단순 URL이 아니라 AI를 실제 서비스로 노출하는 인터페이스입니다. 이 세 가지를 연결해서 이해해야 비로소 실습이 아니라 서비스 구조가 보입니다.

---

결론

핵심 원칙
GCP AutoML 이미지 분류는 데이터 준비, 라벨 매핑, Dataset 생성, 학습 설정, API 예측까지 하나의 흐름으로 이해해야 한다.

실무 적용 시 주의점

• 이미지 자체보다 라벨 품질이 더 중요할 수 있음
• Cloud Storage URI와 CSV 경로를 정확히 맞춰야 함
• 예측 API는 입력 JSON 구조가 틀리면 즉시 실패함
• 프로덕션 정확도를 원한다면 라벨당 이미지 수를 충분히 확보해야 함
• node hours는 비용이므로 실험과 운영을 구분해서 설정해야 함

다음 학습 단계 제안
다음에는 이 예측 결과를 웹 애플리케이션에 연결하거나, BigQuery에 저장해 추세 분석을 하거나, Looker Studio로 예측 결과 리포트를 시각화해보면 좋습니다.