테라폼 멀티 클라우드 IaC 전략: AWS, GCP 리소스 관리 실전

테라폼으로 AWS와 GCP에 걸친 멀티 클라우드 인프라를 효율적으로 관리하는 IaC 전략을 배우고, 실제 리소스 구축 및 운영 노하우를 친절하게 알려드립니다.

안녕하세요! 개발자 여러분, 그리고 클라우드 인프라에 관심 있는 모든 분들! 혹시 이런 고민 해보신 적 있으신가요? AWS에서 서비스 하나 돌리고 있는데, GCP의 특정 기능이 너무 매력적이라서 두 클라우드를 함께 쓰고 싶다거나, 아니면 온프레미스에서 클라우드로 옮겨가는 과정에서 여러 클라우드를 동시에 관리해야 하는 상황 말이에요.

클라우드 한 곳만 관리하는 것도 쉽지 않은데, 두 곳 이상을 동시에 관리하려니 머리가 지끈거릴 때가 많죠. 수많은 리소스를 일일이 손으로 만들고, 변경하고, 삭제하는 건 정말 비효율적이고 실수하기도 쉬운 일이잖아요? 게다가 클라우드마다 대시보드나 CLI 명령어 체계가 다르니 더욱 번거롭고요.

이럴 때 우리에게 구원투수처럼 등장하는 기술이 바로 인프라스트럭처 애즈 코드(Infrastructure as Code, IaC), 그리고 그 중심에 있는 테라폼(Terraform)입니다! 오늘은 테라폼을 활용해서 AWS와 GCP를 아우르는 멀티 클라우드 IaC 구축 전략에 대해 아주 자세하고 친근하게 이야기해보려고 해요. 실전 예시와 함께 어떻게 두 클라우드를 효율적으로 관리할 수 있는지 함께 파헤쳐 볼까요?

📑 목차

• 멀티 클라우드 IaC, 왜 필요하고 테라폼은 왜 강력할까요?
• 테라폼 기본 이해와 멀티 클라우드 아키텍처
• 테라폼의 핵심 구성 요소
• 멀티 클라우드 아키텍처 구성 전략
• AWS 리소스 관리를 위한 테라폼 실전
• AWS 프로바이더 설정
• 주요 AWS 리소스 정의 예시
• GCP 리소스 관리를 위한 테라폼 실전
• GCP 프로바이더 설정
• 주요 GCP 리소스 정의 예시
• 멀티 클라우드 통합 관리 전략
• 모노레포 vs. 멀티레포 전략
• 워크스페이스(Workspace)를 활용한 환경 분리
• 공통 모듈화 및 재사용
• 민감 정보 관리
• 테라폼 멀티 클라우드 IaC 구현 시 고려사항 및 베스트 프랙티스
• 안전한 상태 파일(State File) 관리
• CI/CD 파이프라인 통합
• 보안 및 컴플라이언스
• 리소스 명명 규칙 및 태깅 전략
• 마무리: 테라폼으로 여는 멀티 클라우드 IaC의 미래

Image by Schwoaze on Pixabay

멀티 클라우드 IaC, 왜 필요하고 테라폼은 왜 강력할까요?

먼저, 멀티 클라우드 환경에서 IaC가 왜 필수적인지부터 짚고 넘어갈게요. 클라우드 환경이 복잡해질수록 수동으로 인프라를 관리하는 건 여러 가지 문제점을 야기합니다. 예를 들어, 인프라 배포에 시간이 오래 걸리고, 환경 간의 일관성이 떨어지며, 휴먼 에러로 인한 장애 발생 가능성도 높아지죠. 또한, 인프라의 현재 상태를 정확히 파악하기 어렵다는 문제도 있어요.

IaC는 이런 문제들을 해결해줍니다. 인프라를 코드로 정의하고 관리함으로써 다음과 같은 장점들을 얻을 수 있거든요:

• 일관성(Consistency): 코드로 정의되므로 어떤 환경이든 동일한 인프라를 반복적으로 배포할 수 있어요. 개발, 스테이징, 프로덕션 환경이 서로 달라서 생기는 골치 아픈 문제들을 줄일 수 있죠.
• 속도(Speed): 수동 작업에 비해 훨씬 빠르게 인프라를 프로비저닝하고 변경할 수 있습니다. 새로운 서비스 배포나 스케일 업이 필요할 때 빛을 발하죠.
• 버전 관리(Version Control): 코드로 관리되기 때문에 Git과 같은 버전 관리 시스템을 활용할 수 있어요. 누가 언제 어떤 인프라를 변경했는지 추적할 수 있고, 문제가 생기면 이전 버전으로 롤백하는 것도 쉬워집니다.
• 협업(Collaboration): 팀원들과 함께 인프라 코드를 공유하고 검토하며 효율적으로 협업할 수 있어요.
• 비용 절감(Cost Savings): 불필요한 리소스 생성을 방지하고, 리소스 관리를 자동화하여 장기적으로 운영 비용을 절감할 수 있습니다.

그럼 IaC 도구 중에서도 왜 테라폼이 멀티 클라우드 환경에 특히 강력할까요? 바로 클라우드 벤더에 종속되지 않는(Cloud Agnostic) 특성 때문입니다. 테라폼은 다양한 클라우드 서비스 제공자(AWS, GCP, Azure 등)와 온프레미스 인프라를 하나의 코드 베이스로 관리할 수 있게 해줘요. 각 클라우드마다 다른 도구를 배울 필요 없이, 테라폼 하나만으로 통합적인 인프라 관리가 가능해지는 거죠. 정말 매력적이지 않나요?

테라폼 기본 이해와 멀티 클라우드 아키텍처

테라폼은 HashiCorp에서 개발한 오픈소스 IaC 도구입니다. 선언적 언어(Declarative Language)인 HCL(HashiCorp Configuration Language)을 사용해서 원하는 인프라의 최종 상태를 정의하면, 테라폼이 현재 상태와 비교하여 어떤 변경이 필요한지 파악하고 자동으로 인프라를 생성하거나 수정해줍니다.

테라폼의 핵심 구성 요소

• 프로바이더(Provider): 테라폼이 특정 클라우드(AWS, GCP 등)나 서비스와 상호작용할 수 있도록 해주는 플러그인입니다. 각 프로바이더는 해당 클라우드의 리소스들을 생성, 관리할 수 있는 기능을 제공하죠.
• 리소스(Resource): 클라우드에서 생성하고자 하는 실제 인프라 구성 요소들을 의미합니다. 예를 들어, AWS의 EC2 인스턴스, S3 버킷, GCP의 Compute Engine VM, Cloud Storage 버킷 등이 모두 리소스에 해당해요.
• 상태 파일(State File): 테라폼이 관리하는 인프라의 현재 상태를 기록하는 파일입니다. terraform.tfstate 파일이 대표적이며, 이 파일을 기반으로 테라폼은 코드와 실제 인프라 간의 차이를 감지하고 필요한 작업을 수행합니다. 멀티 클라우드 환경에서는 이 상태 파일을 안전하게 관리하는 것이 매우 중요해요.

멀티 클라우드 아키텍처 구성 전략

테라폼으로 멀티 클라우드를 구축할 때는 일반적으로 각 클라우드의 프로바이더를 개별적으로 설정하고, 필요한 리소스를 각 프로바이더에 맞춰 정의하게 됩니다. 예를 들어, AWS에는 웹 서버를, GCP에는 데이터베이스를 두는 식의 분산 아키텍처를 생각할 수 있겠죠.

기본적인 멀티 클라우드 테라폼 구성은 다음과 같은 형태를 띠게 됩니다.

# main.tf 예시

# AWS 프로바이더 설정
provider "aws" {
  region = "ap-northeast-2" # 서울 리전
}

# GCP 프로바이더 설정
provider "google" {
  project = "your-gcp-project-id"
  region  = "asia-northeast3" # 서울 리전
}

# AWS 리소스 정의 (예: S3 버킷)
resource "aws_s3_bucket" "my_aws_bucket" {
  bucket = "my-unique-aws-bucket-name"
  acl    = "private"
  tags = {
    Environment = "Dev"
    ManagedBy   = "Terraform"
  }
}

# GCP 리소스 정의 (예: Cloud Storage 버킷)
resource "google_storage_bucket" "my_gcp_bucket" {
  name          = "my-unique-gcp-bucket-name"
  location      = "ASIA-NORTHEAST3"
  force_destroy = true
  labels = {
    environment = "dev"
    managed_by  = "terraform"
  }
}

위 코드처럼 하나의 .tf 파일 안에 여러 프로바이더를 설정하고 각 클라우드의 리소스를 함께 정의할 수 있어요. 물론 실제 프로젝트에서는 파일을 분리해서 관리하는 것이 일반적이지만, 개념적으로는 이렇다는 점을 알아두시면 좋습니다.

AWS 리소스 관리를 위한 테라폼 실전

이제 AWS 리소스를 테라폼으로 어떻게 관리하는지 구체적인 예시와 함께 살펴볼게요. AWS 프로바이더는 수많은 AWS 서비스들을 지원하며, 각 서비스의 리소스들을 정의할 수 있는 방법을 제공합니다.

AWS 프로바이더 설정

먼저 providers.tf 파일에 AWS 프로바이더를 정의합니다. 인증 방법은 여러 가지가 있지만, 여기서는 AWS CLI를 통해 설정된 기본 프로필을 사용하는 것을 가정해볼게요.

# providers.tf
provider "aws" {
  region  = "ap-northeast-2" # 원하는 AWS 리전으로 설정
  profile = "default"        # AWS CLI 설정 파일의 프로필명 (선택 사항)
}

주요 AWS 리소스 정의 예시

AWS에서 자주 사용하는 리소스 몇 가지를 테라폼 코드로 어떻게 정의하는지 알아볼까요?

VPC(Virtual Private Cloud) 및 서브넷

클라우드 네트워크의 기본이죠. 안전하고 격리된 네트워크 환경을 구축합니다.

# network.tf
resource "aws_vpc" "main" {
  cidr_block = "10.0.0.0/16"
  tags = {
    Name = "my-terraform-vpc"
  }
}

resource "aws_subnet" "public" {
  vpc_id            = aws_vpc.main.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "ap-northeast-2a" # 가용 영역 지정
  tags = {
    Name = "my-terraform-public-subnet"
  }
}

EC2 인스턴스 (가상 서버)

가장 기본적인 컴퓨팅 리소스인 EC2 인스턴스입니다.

# compute.tf
resource "aws_instance" "web_server" {
  ami           = "ami-0abcdef1234567890" # 사용하려는 AMI ID로 변경 (예: Amazon Linux 2)
  instance_type = "t2.micro"
  subnet_id     = aws_subnet.public.id
  tags = {
    Name = "my-web-server-aws"
  }
}

S3 버킷 (객체 스토리지)

정적 파일 호스팅이나 데이터 백업에 많이 사용되는 S3 버킷입니다.

# storage.tf
resource "aws_s3_bucket" "data_storage" {
  bucket = "my-aws-data-storage-unique-name" # 전역적으로 고유해야 함
  acl    = "private"
  versioning {
    enabled = true
  }
  tags = {
    Name = "my-terraform-s3-bucket"
  }
}

테라폼은 이 외에도 IAM(Identity and Access Management), RDS(Relational Database Service), Lambda 등 수많은 AWS 서비스들을 코드로 정의하고 관리할 수 있도록 해줍니다. 각 리소스는 고유한 속성들을 가지며, 테라폼 문서에서 자세한 정보를 찾아볼 수 있습니다.

Image by onkelglocke on Pixabay

GCP 리소스 관리를 위한 테라폼 실전

다음으로 GCP 리소스를 테라폼으로 관리하는 방법을 알아보겠습니다. GCP 프로바이더 역시 AWS와 마찬가지로 다양한 GCP 서비스 리소스들을 지원합니다.

GCP 프로바이더 설정

GCP 프로바이더를 설정할 때는 프로젝트 ID와 리전을 필수로 지정해야 합니다. 인증 방식으로는 서비스 계정(Service Account) 키 파일을 사용하는 것이 일반적입니다.

# providers.tf
provider "google" {
  project = "your-gcp-project-id"           # 자신의 GCP 프로젝트 ID로 변경
  region  = "asia-northeast3"               # 원하는 GCP 리전으로 설정 (예: 서울)
  credentials = file("path/to/your/service-account-key.json") # 서비스 계정 키 파일 경로
}

서비스 계정 키 파일을 직접 코드에 포함하는 대신, 환경 변수(GOOGLE_APPLICATION_CREDENTIALS)를 사용하거나 Google Cloud SDK의 인증 정보를 활용하는 방법도 있습니다. 보안을 위해 후자의 방법을 권장합니다.

주요 GCP 리소스 정의 예시

GCP에서 자주 사용하는 리소스들을 테라폼 코드로 어떻게 정의하는지 살펴볼까요?

VPC 네트워크 및 서브넷

GCP의 네트워크는 VPC 네트워크와 서브넷으로 구성됩니다.

# network.tf
resource "google_compute_network" "main" {
  name                    = "my-terraform-network"
  auto_create_subnetworks = false # 서브넷을 수동으로 생성할 경우 false
}

resource "google_compute_subnetwork" "public" {
  name          = "my-terraform-public-subnet"
  ip_cidr_range = "10.10.0.0/24"
  region        = "asia-northeast3"
  network       = google_compute_network.main.id
}

Compute Engine VM 인스턴스

GCP의 가상 서버인 Compute Engine VM 인스턴스입니다.

# compute.tf
resource "google_compute_instance" "web_server" {
  name         = "my-web-server-gcp"
  machine_type = "e2-micro"
  zone         = "asia-northeast3-a" # 가용 영역 지정

  boot_disk {
    initialize_params {
      image = "debian-cloud/debian-11"
    }
  }

  network_interface {
    network = google_compute_network.main.id
    subnetwork = google_compute_subnetwork.public.id
    access_config {} # 외부 IP 할당
  }

  tags = ["web-server"]
}

Cloud Storage 버킷 (객체 스토리지)

GCP의 객체 스토리지인 Cloud Storage 버킷입니다.

# storage.tf
resource "google_storage_bucket" "data_storage" {
  name          = "my-gcp-data-storage-unique-name" # 전역적으로 고유해야 함
  location      = "ASIA-NORTHEAST3"
  storage_class = "STANDARD"
  force_destroy = true # 버킷 내 파일이 있어도 삭제 허용 (주의!)
  labels = {
    environment = "dev"
    managed_by  = "terraform"
  }
}

GCP 역시 IAM(Identity and Access Management), Cloud SQL, Cloud Functions 등 다양한 서비스들을 테라폼으로 관리할 수 있습니다. AWS와 마찬가지로, 각 리소스의 정의 방식은 테라폼 공식 문서를 참고하는 것이 가장 정확하고 좋습니다.

멀티 클라우드 통합 관리 전략

AWS와 GCP 리소스를 개별적으로 정의하는 방법을 알았으니, 이제 이들을 테라폼으로 어떻게 효과적으로 통합 관리할 수 있는지 전략을 세워볼 시간입니다.

모노레포 vs. 멀티레포 전략

테라폼 코드를 관리하는 방식에는 크게 두 가지가 있습니다.

구분	모노레포 (Monorepo)	멀티레포 (Multirepo)
설명	모든 테라폼 코드를 하나의 Git 저장소에 모아 관리합니다. AWS, GCP 리소스 코드를 한 곳에 두는 식이죠.	각 클라우드나 서비스별로 테라폼 코드를 별도의 Git 저장소에 분리하여 관리합니다.
장점	코드 재사용 용이, 변경 사항 추적 용이, 일관된 워크플로우.	각 팀/서비스의 독립성 보장, 작은 코드 베이스로 관리 용이, 빠른 배포.
단점	저장소가 커질수록 관리 복잡성 증가, 불필요한 변경으로 인한 영향도 확대 가능성.	코드 중복 발생 가능성, 의존성 관리 복잡성, 전체 인프라 파악 어려움.
적합한 경우	소규모 팀, 긴밀하게 연결된 멀티 클라우드 서비스, 중앙 집중식 인프라 관리.	대규모 조직, 독립적인 서비스 팀, 마이크로서비스 아키텍처.

어떤 전략이 더 좋다고 단정하기는 어렵고, 팀의 규모, 아키텍처, 관리 방식에 따라 적절한 선택을 하는 것이 중요합니다. 멀티 클라우드 환경에서는 공통 모듈을 공유하거나 핵심 네트워크 인프라는 모노레포로, 애플리케이션 관련 인프라는 멀티레포로 관리하는 하이브리드 접근 방식도 고려해볼 수 있습니다.

워크스페이스(Workspace)를 활용한 환경 분리

테라폼 워크스페이스는 동일한 테라폼 코드를 사용하되, 다른 상태 파일을 관리하여 여러 환경(개발, 스테이징, 프로덕션 등)을 분리하는 데 유용합니다.

# 개발 환경 워크스페이스 생성 및 전환
terraform workspace new dev
terraform workspace select dev

# 프로덕션 환경 워크스페이스 생성 및 전환
terraform workspace new prod
terraform workspace select prod

각 워크스페이스에서 terraform apply를 실행하면 해당 워크스페이스의 상태 파일에 기반하여 인프라가 관리됩니다. 이를 통해 AWS와 GCP에 각각 개발/운영 환경을 동일한 코드로 배포하고 관리할 수 있어요. 물론 변수(Variables)를 활용하여 환경별로 다른 값(예: 인스턴스 타입, 리전 등)을 적용하는 것이 일반적입니다.

공통 모듈화 및 재사용

테라폼 모듈(Module) 기능을 활용하면 반복되는 인프라 패턴을 캡슐화하고 재사용할 수 있습니다. 예를 들어, AWS의 웹 서버 스택이나 GCP의 데이터베이스 클러스터 같은 것을 모듈로 만들 수 있죠. 이렇게 하면 코드를 더 간결하게 유지하고, 실수를 줄이며, 표준화된 인프라를 빠르게 배포할 수 있습니다.

# modules/webserver/main.tf (예시)
# ... EC2 인스턴스, 보안 그룹 등을 정의

# main.tf 에서 모듈 사용
module "aws_web_app" {
  source = "./modules/webserver"
  # ... 필요한 변수 전달
}

멀티 클라우드 환경에서는 각 클라우드에 특화된 모듈을 만들거나, 심지어는 클라우드 간 공통 추상화를 제공하는 모듈을 만드는 것도 가능합니다. 다만, 클라우드별 차이가 커서 공통 모듈화가 오히려 복잡도를 높일 수도 있으니 신중하게 접근해야 합니다.

민감 정보 관리

API 키, 데이터베이스 비밀번호 등 민감한 정보는 테라폼 코드에 직접 하드코딩해서는 절대 안 됩니다. 테라폼은 민감 정보 관리를 위한 다양한 방법을 제공합니다.

• 환경 변수: CLI 실행 시 환경 변수로 값을 전달합니다.
• Terraform Cloud/Enterprise: 변수 세트(Variable Sets) 기능을 통해 안전하게 관리합니다.
• HashiCorp Vault: 전문적인 비밀 정보 관리 솔루션으로, 테라폼과 연동하여 사용합니다.
• 클라우드별 비밀 정보 관리 서비스: AWS Secrets Manager나 GCP Secret Manager를 사용하고, 테라폼에서 데이터 소스로 참조하여 가져오는 방식도 효과적입니다.

어떤 방법을 사용하든, 민감 정보는 항상 안전하게 분리하여 관리하는 것이 보안의 핵심입니다.

Image by Boskampi on Pixabay

테라폼 멀티 클라우드 IaC 구현 시 고려사항 및 베스트 프랙티스

멀티 클라우드 IaC를 테라폼으로 구현할 때 성공적인 결과를 얻기 위한 몇 가지 중요한 고려사항과 베스트 프랙티스를 알려드릴게요.

안전한 상태 파일(State File) 관리

테라폼 상태 파일은 인프라의 현재 상태를 담고 있는 매우 중요한 파일입니다. 이 파일이 손상되거나 유실되면 인프라 관리에 큰 문제가 발생할 수 있어요. 따라서 반드시 원격 백엔드(Remote Backend)를 사용해야 합니다. AWS S3, GCP Cloud Storage, Terraform Cloud 등이 대표적인 원격 백엔드로 활용될 수 있습니다.

# backend.tf (AWS S3 예시)
terraform {
  backend "s3" {
    bucket         = "my-terraform-state-bucket" # 고유한 S3 버킷 이름
    key            = "multi-cloud/terraform.tfstate"
    region         = "ap-northeast-2"
    encrypt        = true
    dynamodb_table = "terraform-lock" # 상태 파일 잠금 (동시성 제어)
  }
}

# backend.tf (GCP Cloud Storage 예시)
terraform {
  backend "gcs" {
    bucket = "my-terraform-state-bucket-gcp" # 고유한 GCS 버킷 이름
    prefix = "multi-cloud/terraform.tfstate"
  }
}

원격 백엔드를 사용하면 여러 명이 동시에 작업할 때 발생할 수 있는 상태 파일 충돌을 방지하기 위한 상태 잠금(State Locking) 기능도 활용할 수 있어 협업 환경에서 필수적입니다.

CI/CD 파이프라인 통합

테라폼 코드는 CI/CD(Continuous Integration/Continuous Deployment) 파이프라인에 통합될 때 진정한 가치를 발휘합니다. 코드 변경사항이 Git 저장소에 푸시되면 자동으로 terraform plan을 실행하여 변경될 내용을 검토하고, 승인 후 terraform apply를 통해 인프라를 배포하는 워크플로우를 구축할 수 있어요. Terraform Cloud, GitHub Actions, GitLab CI, Jenkins 등 다양한 도구들이 테라폼 CI/CD를 지원합니다.

CI/CD를 통해 인프라 변경 프로세스를 자동화하면 배포 속도가 향상되고, 오류를 줄이며, 더욱 안정적인 인프라 운영이 가능해집니다.

보안 및 컴플라이언스

멀티 클라우드 환경에서는 각 클라우드의 보안 정책과 컴플라이언스 요구사항을 모두 충족해야 합니다. 테라폼으로 인프라를 정의할 때 보안 그룹, 네트워크 ACL, IAM 정책 등을 세심하게 구성하여 최소 권한 원칙(Least Privilege Principle)을 준수해야 해요. 또한, 테라폼 코드가 클라우드 보안 기준에 맞는지 정적 분석 도구(Static Analysis Tools)(예: Checkov, Terrascan)를 활용하여 검사하는 것도 좋은 방법입니다.

리소스 명명 규칙 및 태깅 전략

멀티 클라우드 환경에서는 수많은 리소스가 생성되기 때문에 명명 규칙과 태깅(Tagging/Labeling) 전략을 잘 세우는 것이 중요합니다. 일관된 명명 규칙을 적용하고, Environment, ManagedBy, Owner 등 유용한 태그나 라벨을 모든 리소스에 적용하면 리소스 검색, 비용 분석, 관리 효율성을 크게 높일 수 있습니다.

예를 들어, AWS에서는 태그를, GCP에서는 라벨을 사용하므로, 두 클라우드 모두에서 의미를 가질 수 있는 공통된 키-값 쌍을 미리 정의해두는 것이 좋습니다.

마무리: 테라폼으로 여는 멀티 클라우드 IaC의 미래

오늘은 테라폼을 활용한 멀티 클라우드 IaC 구축 전략에 대해 깊이 있게 알아보았습니다. AWS와 GCP라는 두 개의 강력한 클라우드를 테라폼이라는 하나의 도구로 관리하는 것이 얼마나 효율적이고 강력한지 느끼셨으면 좋겠어요.

테라폼은 단순히 인프라를 코드로 만드는 것을 넘어, 멀티 클라우드 환경에서 발생할 수 있는 복잡성을 줄이고, 안정성과 확장성을 확보하며, 궁극적으로는 개발 및 운영 팀의 생산성을 극대화하는 데 크게 기여합니다. 처음에는 다소 어렵게 느껴질 수 있지만, 한번 익숙해지면 클라우드 인프라를 바라보는 시야가 완전히 달라질 거예요.

여러분도 테라폼과 함께 멀티 클라우드 IaC 여정을 시작해보는 건 어떨까요? 분명 후회하지 않으실 겁니다! 혹시 테라폼이나 멀티 클라우드에 대해 궁금한 점이 있으시다면 언제든지 댓글로 남겨주세요. 함께 이야기 나눠봐요!

📌 함께 읽으면 좋은 글

• [클라우드 인프라] 클라우드 비용, 더 이상 새는 돈은 없다! FinOps로 최적화하는 절감 전략
• [개발 도구] Postman 활용 API 개발 및 테스트 자동화: 컬렉션, 환경 변수, 스크립트 마스터 가이드
• [개발 도구] lazygit으로 Git 워크플로우 혁신: 터미널에서 빠르고 직관적인 Git 관리

이 글이 도움이 되셨다면 공감(♥)과 댓글로 응원해 주세요!
궁금한 점이나 다루었으면 하는 주제가 있다면 댓글로 남겨주세요.