Google Cloud Well-Architected 스킬로 Terraform 리뷰 받아 보기 – 일부러 심은 문제 19개를 얼마나 찾을까

작성자 박 희찬 작성일 10월 14, 2026 조회수 24

안녕하세요. GS Neotek 박희찬 입니다.
지난 글에서 Google 공식 Agent Skills를 Claude Code에 설치해 로그 조회와 BigQuery 비용 점검을 맡겨 봤습니다.
이번에는 같은 저장소의 Google Cloud Well-Architected Framework 스킬로 Terraform 코드의 아키텍처 리뷰를 받아 봤습니다.

얼마 전 이 블로그에 AWS Well-Architected Agent 후기가 올라왔는데, AWS는 이 기능을 콘솔 서비스로 내놓았습니다.
Google은 같은 일을 에이전트가 읽는 스킬 파일로 제공합니다.
방식이 다른 만큼 실제로 얼마나 쓸 만한지, 일부러 문제를 심은 코드로 확인해 봤습니다.

한눈에 보기

1. Well-Architected 스킬 6종 살펴보기

저장소가 처음 공개될 때는 보안·안정성·비용 3개 기둥만 있었고, 지금은 운영 우수성·성능·지속 가능성까지 6개 기둥이 모두 들어 있습니다.
스킬 이름은 모두 google-cloud-waf-로 시작합니다.

여섯 스킬 모두 구조가 같습니다.
핵심 원칙과 근거 문서 링크, 관련 Google Cloud 제품, 워크로드 평가 질문, 점검 체크리스트 순서로 되어 있습니다.
작업 순서도 정해져 있는데, 먼저 사용자에게 질문해 맥락을 파악하고, 체크리스트로 빈틈을 찾은 뒤, 원칙에 맞춘 권장 사항을 우선순위와 함께 내도록 되어 있습니다.

지난 글의 BigQuery 스킬과 달리 실행 스크립트는 없습니다.
스킬은 “무엇을 어떤 순서로 봐야 하는지”만 알려 주고, 실제 판단은 에이전트의 AI 모델이 합니다.

2. 테스트 준비 – 일부러 문제를 심은 Terraform

사내 직원 300명이 쓰는 예약 관리 서비스를 가정했습니다.
피크 트래픽은 초당 10건 정도이고, API·관리자 화면·DB·첨부 파일·감사 로그 보관용 버킷으로 이루어진 흔한 구성입니다.
코드는 terraform validate까지만 통과시켰고 실제로 배포하지는 않았습니다.

# 사내 예약 관리 서비스 (운영 환경)
# - 사용자: 사내 직원 약 300명, 평일 업무 시간에 주로 사용 (피크 약 10 req/s)

resource "google_sql_database_instance" "main" {
  name                = "booking-db"
  region              = "us-central1"         # 앱은 서울(asia-northeast3)
  deletion_protection = false

  settings {
    tier              = "db-custom-16-65536"  # 16 vCPU / 64GB
    availability_type = "ZONAL"

    backup_configuration {
      enabled = false
    }
    ip_configuration {
      ipv4_enabled = true
      authorized_networks {
        name  = "anywhere"
        value = "0.0.0.0/0"
      }
    }
  }
}

코드 곳곳에 기둥별로 문제를 심었습니다.
실무에서 자주 보는 실수 위주로 골랐습니다.

3. 리뷰 방법

기둥마다 대화 기록이 없는 새 에이전트를 하나씩 띄웠습니다.
각 에이전트에게는 해당 스킬 파일과 Terraform 파일만 주고, 정답지는 보여 주지 않았습니다.

스킬은 먼저 사용자에게 질문하도록 되어 있지만, 이번에는 답해 줄 사람이 없다고 하고 “물어봤을 질문”과 “대신 세운 가정”을 적은 뒤 진행하게 했습니다.
보안 스킬이 남긴 질문은 실제 WAR 인터뷰에서 묻는 내용과 거의 같았습니다.

• 1. 신원·권한
  직원은 Google Workspace 계정으로 로그인하나요? 관리자 화면에는 누가 접근해야 하나요?
• 2. 네트워크 경계
  직원은 사내망·VPN에서만 접속하나요, 재택에서도 접속하나요?
• 3. 데이터 분류·규제
  예약 데이터와 첨부에 개인정보가 들어가나요? 국내 보관이 필요한가요?
• 4. 감사 로그 보관
  “법적 보관 1년”에 변경·삭제 불가(WORM) 요건까지 포함되나요?
• 5. 배포 파이프라인
  이미지 취약점 스캔이나 서명·승인 절차가 있나요?

4. 리뷰 결과 – 지적 71건

심어 둔 문제를 얼마나 찾았나

19개 모두 찾았습니다.
자기 기둥의 문제는 해당 스킬이 빠짐없이 짚었고, 여러 기둥에 걸친 문제는 여러 스킬이 함께 지적했습니다.

리전 불일치는 여섯 스킬이 모두 지적했는데, 이유는 기둥마다 달랐습니다.
성능 스킬은 왕복 지연(약 130~160ms)을, 비용 스킬은 리전 간 전송 비용을, 지속 가능성 스킬은 대륙 간 전송 에너지를 근거로 들었습니다.

정답지에 없던 지적

심지 않았는데 나온 지적 중에는 실무에서 바로 쓸 만한 것이 많았습니다.

• 1. 개인정보 국외 이전
  보안 스킬은 서울 서비스의 DB만 미국에 있는 점을 성능이 아니라 개인정보 국외 이전 문제로 짚었습니다.
• 2. 감사 로그 보존 잠금
  “법적 보관 1년”이면 수명 주기뿐 아니라 보존 정책(Bucket Lock)으로 삭제·변조를 막아야 한다는 지적이 나왔습니다.
• 3. Terraform state 안의 비밀번호
  원격 state 설정이 없고, 코드에 쓴 비밀번호가 state 파일에도 평문으로 남는다는 운영 관점의 지적이 있었습니다.
• 4. 헬스 체크·유지보수 창
  Cloud Run 시작·활성 검사(probe)가 없고, Cloud SQL 유지보수 시간을 지정하지 않아 업무 시간에 재시작될 수 있다는 지적도 있었습니다.

수정 코드까지 받아 보면

상위 지적에는 Terraform 수정 예시도 함께 나왔습니다.
보안 스킬은 공인 IP를 없애고, 비밀번호 대신 IAM DB 인증을 쓰도록 바꿨습니다.

# 보안 스킬이 제안한 수정 (발췌)
resource "google_sql_database_instance" "main" {
  region              = "asia-northeast3"   # 국내 리전으로
  deletion_protection = true

  settings {
    backup_configuration {
      enabled                        = true
      point_in_time_recovery_enabled = true
    }
    ip_configuration {
      ipv4_enabled    = false               # 공인 IP 제거
      private_network = google_compute_network.vpc.id
      ssl_mode        = "ENCRYPTED_ONLY"
    }
  }
}

# 비밀번호 대신 IAM DB 인증
resource "google_sql_user" "app" {
  name     = trimsuffix(google_service_account.api.email, ".gserviceaccount.com")
  instance = google_sql_database_instance.main.name
  type     = "CLOUD_IAM_SERVICE_ACCOUNT"
}

5. AWS Well-Architected Agent와 비교

AWS 후기와 나란히 놓고 보면 두 회사의 접근 방식 차이가 분명합니다.

AWS는 계정 스캔까지 포함한 완성형 서비스이고, Google 스킬은 지금 쓰는 에이전트 안에서 바로 돌릴 수 있는 가벼운 도구에 가깝습니다.

6. 써 보고 느낀 점

좋았던 점

• 1. 심어 둔 문제를 모두 찾았습니다.
  19개 중 놓친 것이 없었고, 리전 불일치처럼 여러 기둥에 걸친 문제는 기둥마다 다른 근거로 설명했습니다.
• 2. 정답지 밖의 실무 지적이 나왔습니다.
  개인정보 국외 이전, 감사 로그 보존 잠금, state 파일 속 비밀번호처럼 체크리스트만 봐서는 떠올리기 어려운 내용이 있었습니다.
• 3. 질문 목록이 그대로 인터뷰 질문지가 됩니다.
  스킬이 먼저 묻도록 정해 둔 질문은 WAR 인터뷰 준비에 바로 쓸 수 있었습니다.

아쉬웠던 점

• 1. 같은 문제가 기둥마다 반복됩니다.
  71건 중 상당수가 같은 문제를 다른 관점에서 다시 지적한 것이라, 보고서로 쓰려면 사람이 합치는 작업이 필요할 수 있습니다.
• 2. 결과의 질은 에이전트 모델에 달려 있습니다.
  스킬은 체크리스트와 순서만 제공하므로, 어떤 모델로 돌리느냐에 따라 결과가 달라질 수 있습니다.
• 3. 근거 문서를 실제로 열어 보지는 않았습니다.
  스킬에 근거 문서 링크가 있지만 이번 리뷰에서는 열지 않았고, 서울 리전의 무탄소 에너지 비율 같은 판단은 확인이 필요해 보입니다.
• 4. 코드 밖의 상황은 가정으로 채웁니다.
  코드에 없는 배치 VM을 “상시 운영 중”으로 가정한 지적처럼, 질문에 답하지 않으면 추측이 섞일 수 있습니다.

7. 정리

Google의 Well-Architected 스킬은 별도 서비스 가입 없이, 지금 쓰는 코딩 에이전트에서 Terraform 리뷰를 바로 받을 수 있다는 점이 가장 큰 장점이었습니다.
다만 실제 계정을 스캔하지는 않으므로, 운영 중인 환경 점검은 보안 점검 도구나 실측 데이터와 함께 써야 합니다.

Well-Architected 리뷰를 “배포 전에 코드에서 먼저 받는 리뷰”로 앞당길 수 있는 도구였습니다.