멀티 클라우드 비용 최적화 전략: 실전 인프라 운영 노하우

멀티 클라우드 환경에서 인프라 비용을 효율적으로 관리하는 실질적인 전략과 운영 노하우를 공유합니다. 직접 적용해 본 비용 절감 팁과 최적화 방안을 확인하세요.

안녕하세요! IT 인프라를 운영하면서 늘 마주하는 고민 중 하나가 바로 비용 효율성일 겁니다. 특히 여러 클라우드 벤더를 동시에 사용하는 멀티 클라우드 환경에서는 이 고민이 더욱 깊어지죠. 각 클라우드마다 다른 요금 체계와 서비스 종류, 그리고 복잡하게 얽힌 자원들 때문에 비용 관리가 쉽지 않다는 것을 직접 경험했습니다.

저희 팀도 처음에는 멀티 클라우드의 유연성과 특정 서비스의 강점을 활용하는 데 집중했습니다. 하지만 시간이 지날수록 예상치 못한 비용이 발생하고, 어디서 어떻게 절감해야 할지 막막했던 순간들이 많았습니다. 마치 여러 개의 수도꼭지에서 물이 콸콸 쏟아지는데, 어떤 수도꼭지가 새는지, 얼마나 잠가야 할지 모르는 상황과 같았습니다. 그래서 저희는 '이대로는 안 되겠다' 싶어 멀티 클라우드 비용 최적화 전략을 수립하고 실제로 적용해 보았습니다. 이 글에서는 저희가 직접 부딪히고 해결하며 얻은 실질적인 노하우와 팁들을 공유하고자 합니다.

여러분도 혹시 다음과 같은 고민을 하고 계신가요?

• 멀티 클라우드 비용이 매달 예상보다 많이 나와 당황스럽다.
• 어떤 클라우드 서비스에서 비용이 많이 발생하는지 정확히 파악하기 어렵다.
• 클라우드 자원을 제대로 활용하고 있는지 확신이 없다.
• 비용 절감을 위한 구체적인 액션 플랜을 세우기 어렵다.

이 글이 여러분의 멀티 클라우드 인프라 운영에 실질적인 도움이 되기를 바랍니다.

📑 목차

• 멀티 클라우드 환경, 왜 비용 관리가 어려울까?
• 벤더별 상이한 요금 모델과 서비스 구조
• 중앙화된 가시성 부족과 자원 스프롤
• 클라우드 비용 가시성 확보: FinOps의 첫걸음
• 통합 비용 모니터링 시스템 구축
• 효과적인 태깅 전략과 비용 할당
• 자원 최적화와 탄력적 운영으로 비용 절감하기
• Right-sizing: 적정 규모의 자원 사용
• Auto Scaling과 서버리스 아키텍처 활용
• 스토리지 최적화와 데이터 라이프사이클 관리
• 클라우드 할인 모델 적극 활용하기
• Reserved Instances(RI)와 Savings Plans(SP)
• Spot Instances 활용
• 멀티 클라우드 아키텍처 재설계: 비용 효율성 극대화
• 워크로드 배치 전략 수립
• 데이터 전송 비용(Egress 비용) 최소화
• 자동화와 거버넌스로 지속 가능한 비용 관리
• 자동화된 비용 관리 스크립트 및 툴
• 강력한 거버넌스와 FinOps 문화 정착
• 실제 적용 후기: 멀티 클라우드 비용 최적화, 그 결과는?

Image by MR-PANDA on Pixabay

멀티 클라우드 환경, 왜 비용 관리가 어려울까?

멀티 클라우드는 벤더 종속성을 줄이고, 특정 클라우드의 강점을 활용하며, 재해 복구(DR) 전략을 강화하는 등 다양한 이점을 제공합니다. 하지만 이러한 장점 뒤에는 복잡한 비용 관리라는 그림자가 항상 따라붙습니다. 저희가 겪었던 어려움들을 몇 가지 꼽아보자면 다음과 같습니다.

벤더별 상이한 요금 모델과 서비스 구조

AWS, Azure, GCP 등 주요 클라우드 벤더들은 각기 다른 방식으로 요금을 책정합니다. 컴퓨팅 자원의 시간당 요금, 스토리지 용량 및 접근 방식, 네트워크 트래픽 비용, 데이터베이스 라이선스 모델 등 모든 것이 다릅니다. 예를 들어, AWS의 EC2와 Azure의 VM, GCP의 Compute Engine은 겉보기엔 비슷해 보여도 세부적인 요금 계산 방식이나 할인 모델이 상이합니다. 이 때문에 여러 클라우드에 분산된 자원들의 총 비용을 통합적으로 비교하고 분석하는 것이 매우 어렵습니다.

중앙화된 가시성 부족과 자원 스프롤

각 클라우드 벤더는 자체적으로 강력한 비용 보고 도구를 제공하지만, 이 도구들은 오직 해당 벤더의 자원만을 보여줍니다. 저희는 멀티 클라우드 환경에서 전체 비용 흐름을 한눈에 파악하기가 어려웠습니다. 게다가 여러 팀이 각자의 필요에 따라 자유롭게 자원을 프로비저닝하면서 자원 스프롤(Resource Sprawl) 현상이 심화되었습니다. 사용하지 않는 인스턴스, 스냅샷, 로드밸런서 등이 방치되어 불필요한 비용이 계속 발생했지만, 이를 찾아내고 정리하는 데 많은 시간이 소요되었습니다.

클라우드 비용 가시성 확보: FinOps의 첫걸음

저희가 멀티 클라우드 비용 최적화를 시작하며 가장 먼저 집중했던 부분은 바로 가시성 확보였습니다. '비용을 알아야 절감할 수 있다'는 지극히 당연한 진리를 깨달았죠. 이를 위해 FinOps(Finance Operations) 철학을 도입하고, 다음 단계들을 밟아나갔습니다.

통합 비용 모니터링 시스템 구축

각 클라우드 벤더가 제공하는 기본 도구(AWS Cost Explorer, Azure Cost Management, GCP Billing Reports)는 분명 유용합니다. 하지만 멀티 클라우드 환경에서는 이들을 통합하여 볼 수 있는 솔루션이 필수적입니다. 저희는 초기에는 각 클라우드의 Billing API를 활용하여 데이터를 수집하고 자체 대시보드를 구축하는 방안을 고려했습니다. 하지만 빠른 시간 내에 효과를 보기 위해 CloudHealth와 같은 서드파티 FinOps 플랫폼을 도입했습니다. 이 솔루션들은 여러 클라우드의 비용 데이터를 한곳에 모아 보여주며, 다양한 필터링 및 분석 기능을 제공해 주어 비용 흐름을 명확하게 파악하는 데 큰 도움을 주었습니다.

예를 들어, CloudHealth 대시보드를 통해 특정 프로젝트나 팀에서 어떤 클라우드 서비스에 가장 많은 비용을 지출하고 있는지, 그리고 그 추세는 어떤지 직관적으로 확인할 수 있게 되었습니다. 이를 통해 '이번 달에는 데이터베이스 비용이 유난히 높네?', '개발 환경의 컴퓨팅 자원이 비정상적으로 많이 사용되고 있군'과 같은 인사이트를 빠르게 얻을 수 있었습니다.

효과적인 태깅 전략과 비용 할당

태깅(Tagging)은 클라우드 자원에 메타데이터를 부여하는 것으로, 비용 가시성 확보의 핵심입니다. 저희는 다음과 같은 태깅 정책을 수립하고 모든 자원에 강제 적용했습니다.

• 프로젝트 태그 (Project): 어떤 프로젝트에 속한 자원인지 명시 (예: Project:ServiceA)
• 환경 태그 (Environment): 개발, 스테이징, 프로덕션 등 환경 구분 (예: Env:Dev, Env:Prod)
• 소유자/팀 태그 (Owner): 해당 자원의 책임 팀 또는 개인 (예: Owner:TeamB)
• 청구 코드 태그 (CostCenter): 내부 비용 청구를 위한 코드 (예: CC:12345)

처음에는 태깅 규칙을 지키는 것이 번거롭다는 불평도 있었지만, 태깅이 잘 적용된 후에는 각 팀/프로젝트별로 정확한 비용을 할당하고, 불필요한 비용 발생 시 책임 소재를 명확히 할 수 있게 되었습니다. 예를 들어, 특정 개발 환경의 EC2 인스턴스가 밤새도록 실행되어 비용이 과도하게 나오는 경우, 태그를 통해 어떤 팀의 어떤 프로젝트 자원인지 즉시 파악하고 개선을 요청할 수 있었습니다. 이를 통해 저희는 비용 관리의 투명성을 획기적으로 높일 수 있었습니다.

자원 최적화와 탄력적 운영으로 비용 절감하기

가시성을 확보했다면, 이제는 실제 자원을 최적화하여 비용을 절감할 차례입니다. 저희는 다음과 같은 전략들을 통해 상당한 비용 절감 효과를 보았습니다.

Right-sizing: 적정 규모의 자원 사용

클라우드 환경에서 가장 흔하게 발생하는 낭비 중 하나는 과도한 자원 프로비저닝입니다. 처음 자원을 생성할 때 '혹시나 부족할까 봐' 넉넉하게 잡는 경향이 있는데, 이는 불필요한 비용으로 이어집니다. 저희는 모니터링 데이터를 기반으로 실제 자원 사용량을 분석하여 Right-sizing을 진행했습니다. 예를 들어, CPU 사용률이 평균 10% 미만인 EC2 인스턴스나 메모리 사용량이 극히 낮은 데이터베이스 인스턴스를 찾아내고, 더 작은 사양으로 다운그레이드하거나 통합했습니다.

실제로 저희는 개발/테스트 환경의 많은 EC2 인스턴스 중 상당수가 평균 CPU 사용률 5% 미만임을 확인했습니다. 이들 인스턴스를 더 작은 사양(예: t3.medium에서 t3.small)으로 변경하거나, 아예 서버리스(Serverless) 아키텍처로 전환하여 약 15%의 컴퓨팅 비용을 절감할 수 있었습니다. 이 과정에서 개발팀과의 긴밀한 협의를 통해 성능 저하 없이 최적화를 이뤄냈습니다.

Auto Scaling과 서버리스 아키텍처 활용

수요 변화에 따라 유연하게 자원을 확장하고 축소하는 Auto Scaling은 클라우드의 가장 큰 장점 중 하나입니다. 저희는 트래픽 패턴이 명확한 서비스에 Auto Scaling Group을 적용하여 피크 시간에는 자원을 늘리고, 비피크 시간에는 줄임으로써 비용 효율성을 극대화했습니다. 예를 들어, 야간 시간대나 주말에 트래픽이 현저히 줄어드는 배치 처리 시스템의 경우, Auto Scaling 설정을 통해 최소 인스턴스 수를 줄여 유휴 자원 비용을 최소화했습니다.

또한, 특정 이벤트 기반으로 실행되는 작업이나 간헐적인 배치 작업에는 AWS Lambda, Azure Functions, GCP Cloud Functions와 같은 서버리스 서비스를 적극적으로 도입했습니다. 서버리스는 사용한 만큼만 비용을 지불하므로, 항상 실행 중인 인스턴스를 유지하는 것보다 훨씬 비용 효율적이었습니다. 저희는 이메일 발송, 이미지 리사이징, 데이터 변환 등 다양한 유틸리티성 작업을 서버리스로 전환하여 인프라 관리 부담과 비용을 동시에 절감하는 효과를 보았습니다.

스토리지 최적화와 데이터 라이프사이클 관리

스토리지 비용 역시 간과하기 쉬운 부분입니다. 특히 오랜 기간 보관해야 하는 데이터나 백업의 경우, 적절한 스토리지 클래스를 선택하지 않으면 불필요한 비용이 발생할 수 있습니다. 저희는 다음과 같은 전략을 적용했습니다.

• 데이터 분류 및 스토리지 클래스 선택: 자주 접근하지 않는 로그나 아카이브 데이터는 AWS S3 Glacier Deep Archive, Azure Archive Storage, GCP Archive Storage와 같은 저렴한 스토리지 클래스로 이동시켰습니다.
• 라이프사이클 정책 설정: S3 라이프사이클 정책을 통해 일정 기간이 지나면 자동으로 데이터를 저렴한 스토리지 클래스로 전환하거나 삭제하도록 설정했습니다. 예를 들어, 30일이 지난 웹 액세스 로그는 S3 Standard-IA로, 90일이 지난 로그는 Glacier로 자동으로 전환되도록 설정했습니다.
• 중복 백업 제거: 불필요하게 여러 곳에 저장된 스냅샷이나 백업 이미지를 주기적으로 검토하고 삭제했습니다.

이러한 스토리지 최적화는 전체 스토리지 비용을 약 20% 이상 절감하는 데 기여했습니다.

Image by Firmbee on Pixabay

클라우드 할인 모델 적극 활용하기

클라우드 벤더들은 장기 계약이나 선결제를 통해 비용을 절감할 수 있는 다양한 할인 모델을 제공합니다. 저희는 이 모델들을 적극적으로 활용하여 고정적인 워크로드의 비용을 크게 줄일 수 있었습니다.

Reserved Instances(RI)와 Savings Plans(SP)

Reserved Instances (RI)와 Savings Plans (SP)는 특정 컴퓨팅 자원에 대해 1년 또는 3년 약정을 통해 온디맨드(On-Demand) 요금보다 훨씬 저렴한 가격으로 이용할 수 있는 할인 모델입니다. 이 둘의 차이점을 명확히 이해하고 저희 환경에 맞는 것을 선택하는 것이 중요했습니다.

항목	Reserved Instances (RI)	Savings Plans (SP)
적용 범위	특정 인스턴스 타입, 리전, OS에 고정	컴퓨팅 사용량(USD/시간) 약정, 유연성 높음
유연성	제한적 (Family, OS 변경 가능), 예약 용량 제공	높음 (인스턴스 타입, 리전, OS 변경 자유)
주요 장점	특정 고정 워크로드에 최대 할인율	워크로드 변화에 유연하게 대응 가능, 광범위한 서비스 할인
적합한 경우	매우 안정적인 장기 워크로드 (예: 코어 DB 서버)	다양한 컴퓨팅 자원을 사용하며 유연성이 필요한 경우
절감률	최대 75%	최대 72%

저희는 FinOps 도구를 통해 지난 6개월간의 컴퓨팅 자원 사용 패턴을 분석했습니다. 그 결과, 프로덕션 환경의 코어 서비스들은 꽤 오랫동안 일정한 사양의 인스턴스를 유지하고 있었고, 개발/테스트 환경의 인스턴스들은 변화가 잦았지만 총 사용량은 예측 가능했습니다. 이에 따라, 안정적인 코어 서비스에는 RI를, 유연성이 필요한 컴퓨팅 자원에는 SP를 조합하여 적용했습니다. 이 전략으로 컴퓨팅 비용에서 약 30%의 추가 절감 효과를 볼 수 있었습니다.

Spot Instances 활용

Spot Instances는 클라우드 벤더가 남는 컴퓨팅 용량을 할인된 가격으로 제공하는 모델입니다. 언제든지 중단될 수 있다는 단점이 있지만, 온디맨드 가격 대비 최대 90%까지 저렴하게 이용할 수 있습니다. 저희는 중단되어도 서비스에 큰 영향을 주지 않는 워크로드, 예를 들어 배치 처리, 데이터 분석, CI/CD 작업 등에 Spot Instances를 적극 활용했습니다. Spot Fleet이나 Spot Instance Pool을 구성하여 안정성을 높이고, 특정 가용 영역에서 Spot 가격이 급등할 경우 다른 영역으로 자동 전환되도록 설정했습니다. 이를 통해 특정 배치 작업의 컴퓨팅 비용을 약 60% 이상 절감할 수 있었습니다.

멀티 클라우드 아키텍처 재설계: 비용 효율성 극대화

단순히 자원을 최적화하는 것을 넘어, 전체 아키텍처 관점에서 비용 효율성을 고려하는 것도 중요합니다. 특히 멀티 클라우드 환경에서는 각 벤더의 강점과 비용 구조를 고려한 워크로드 배치 전략이 필수적입니다.

워크로드 배치 전략 수립

저희는 모든 워크로드를 특정 클라우드에만 두는 것이 아니라, 각 클라우드의 특징과 비용을 고려하여 최적의 위치에 배치하는 전략을 세웠습니다. 예를 들어,

• 데이터 분석 및 머신러닝 워크로드: GCP의 BigQuery, Vertex AI 등 데이터 및 AI 서비스가 강점인 클라우드를 활용했습니다. 특정 ML 모델 학습에는 GPU 자원 비용이 AWS나 Azure보다 저렴한 경우가 있어, 해당 워크로드를 GCP에 배치하여 비용을 절감했습니다.
• 기존 레거시 시스템: 온프레미스 환경과 연동이 중요하거나 특정 라이선스 요구사항이 있는 시스템은 비용을 고려하여 Azure나 AWS의 하이브리드 솔루션을 적극 검토했습니다.
• 범용 웹 서비스: AWS의 강력한 에코시스템과 폭넓은 사용자 기반을 활용하되, 특정 컴포넌트는 다른 클라우드의 저렴한 관리형 서비스로 대체하는 방안을 고려했습니다.

이러한 워크로드 배치 전략을 통해 각 클라우드의 장점을 최대한 활용하면서도 전체적인 비용을 최적화할 수 있었습니다.

데이터 전송 비용(Egress 비용) 최소화

멀티 클라우드 환경에서 의외로 큰 비중을 차지하는 것이 데이터 전송 비용(Egress 비용)입니다. 클라우드에서 외부로 데이터를 전송할 때 발생하는 비용으로, 클라우드 간 데이터 전송에도 발생합니다. 저희는 이를 최소화하기 위해 다음 방법들을 적용했습니다.

• CDN(Content Delivery Network) 활용: 정적 콘텐츠나 캐싱 가능한 데이터를 사용자에게 더 가까운 CDN 엣지 로케이션을 통해 전달하여 오리진 클라우드에서 나가는 데이터 양을 줄였습니다.
• 클라우드 간 데이터 전송 최소화: 가능한 한 데이터가 한 클라우드 내에서 처리되도록 아키텍처를 설계했습니다. 불가피하게 클라우드 간 데이터 전송이 필요한 경우, 전송량을 최소화하고 벤더 간 Private Link나 Direct Connect와 같은 저렴한 연결 방식을 검토했습니다.
• 압축 및 효율적인 데이터 포맷: 데이터 전송 전에 압축을 적용하거나 Parquet, ORC와 같은 효율적인 데이터 포맷을 사용하여 전송량을 줄였습니다.

데이터 전송 비용은 작은 단위로 발생하지만, 누적되면 상당한 금액이 될 수 있으므로 세심한 관리가 필요하다는 것을 깨달았습니다.

Image by Peggychoucair on Pixabay

자동화와 거버넌스로 지속 가능한 비용 관리

비용 최적화는 한 번의 작업으로 끝나는 것이 아니라, 지속적인 관심과 노력이 필요한 영역입니다. 저희는 자동화와 강력한 거버넌스 체계를 구축하여 비용 관리 활동을 일상적인 업무로 만들었습니다.

자동화된 비용 관리 스크립트 및 툴

수동으로 모든 자원을 관리하고 최적화하는 것은 불가능에 가깝습니다. 저희는 다음과 같은 자동화 스크립트와 툴을 개발하거나 도입했습니다.

• 유휴 자원 자동 종료/삭제: 특정 시간(예: 업무 시간 외)에 사용량이 거의 없는 개발/테스트 환경의 EC2/VM 인스턴스를 자동으로 중지하거나, 일정 기간 사용되지 않은 스냅샷을 자동으로 삭제하는 스크립트를 적용했습니다.
• 태그 미적용 자원 알림: 태그 정책에 맞지 않는 자원이 생성되면 자동으로 알림을 보내고, 일정 기간 내에 수정되지 않으면 해당 자원을 강제로 종료하는 정책을 구현했습니다.
• 비용 이상 감지 및 알림: 클라우드 벤더가 제공하는 예산 알림 기능이나 서드파티 FinOps 툴의 이상 감지 기능을 활용하여, 평소와 다른 비용 지출 패턴이 감지되면 즉시 담당자에게 알림을 보내도록 설정했습니다.

# 예시: 특정 태그가 없는 AWS EC2 인스턴스 중지 (의사 코드)
import boto3

def stop_untagged_ec2_instances():
    ec2_client = boto3.client('ec2', region_name='ap-northeast-2')
    instances = ec2_client.describe_instances(
        Filters=[
            {'Name': 'instance-state-name', 'Values': ['running']},
        ]
    )

    for reservation in instances['Reservations']:
        for instance in reservation['Instances']:
            instance_id = instance['InstanceId']
            tags = {tag['Key']: tag['Value'] for tag in instance.get('Tags', [])}

            # 'Project' 태그가 없거나 비어있는 인스턴스 찾기
            if 'Project' not in tags or not tags['Project']:
                print(f"Untagged instance found: {instance_id}. Stopping it.")
                # ec2_client.stop_instances(InstanceIds=[instance_id]) # 실제 운영 시 주석 해제

if __name__ == "__main__":
    stop_untagged_ec2_instances()

이러한 자동화는 수작업으로 인한 오류를 줄이고, 지속적인 비용 최적화 활동을 가능하게 했습니다. 저희는 이 자동화 시스템을 통해 매월 약 5%의 추가 비용 절감 효과를 얻었습니다.

강력한 거버넌스와 FinOps 문화 정착

아무리 좋은 도구와 자동화 시스템이 있어도, 결국 사람이 운영하는 것이기에 문화적인 변화가 중요합니다. 저희는 FinOps를 단순한 비용 절감 활동이 아닌, 개발팀, 운영팀, 재무팀 모두가 참여하는 협업 프로세스로 정의했습니다.

• 정기적인 비용 리뷰 미팅: 매월 각 팀의 클라우드 비용 사용 현황을 공유하고, 비용 초과 원인 분석 및 개선 방안을 논의하는 미팅을 진행했습니다.
• 비용 책임 할당: 각 팀이 자신들이 사용하는 자원의 비용에 대한 책임을 지고, 예산 범위 내에서 운영하도록 독려했습니다.
• 교육 및 가이드라인 제공: 신규 팀원들에게 클라우드 자원 프로비저닝 시 비용 효율적인 옵션 선택, 태깅 규칙 준수 등에 대한 교육과 가이드라인을 제공했습니다.

이러한 노력 덕분에 팀원들 사이에서 '클라우드 비용은 모두의 책임'이라는 인식이 확산되었고, 자연스럽게 비용 효율성을 고려하는 문화가 정착될 수 있었습니다.

실제 적용 후기: 멀티 클라우드 비용 최적화, 그 결과는?

저희가 멀티 클라우드 환경에서 위에서 언급한 비용 최적화 전략들을 수립하고 끈기 있게 적용해 본 결과는 매우 고무적이었습니다. 처음에는 막막했던 비용 관리가 이제는 예측 가능하고, 통제 가능한 영역이 되었습니다.

정확한 수치를 공개하기는 어렵지만, 모든 전략을 적용하기 시작한 시점부터 6개월 동안 전체 클라우드 인프라 비용을 약 25% 이상 절감할 수 있었습니다. 특히, 불필요한 자원 제거, Right-sizing, 할인 모델 활용, 그리고 자동화를 통한 지속적인 관리가 큰 효과를 보았습니다.

물론 이 과정이 쉽지만은 않았습니다. 새로운 도구를 도입하고, 태깅 정책을 정착시키며, 기존 아키텍처를 변경하는 과정에서 여러 팀과의 조율과 설득이 필요했습니다. 하지만 명확한 목표와 체계적인 접근 방식 덕분에 성공적인 결과를 얻을 수 있었습니다.

멀티 클라우드 환경에서의 비용 최적화는 단순히 돈을 아끼는 것을 넘어, 인프라의 효율성을 높이고, 자원 사용에 대한 투명성을 확보하며, 궁극적으로는 서비스의 안정성과 지속 가능성을 높이는 중요한 활동입니다. 여러분도 이 글에서 공유된 실질적인 노하우들을 바탕으로 각자의 환경에 맞는 최적화 전략을 수립하고 적용해 보시길 강력히 추천합니다.

혹시 멀티 클라우드 비용 최적화와 관련하여 궁금한 점이나 여러분만의 특별한 노하우가 있다면 댓글로 공유해 주세요! 함께 성장하는 개발 문화를 만들어 나갈 수 있으면 좋겠습니다. 감사합니다.

📌 함께 읽으면 좋은 글

• [기술 리뷰] Webpack과 Vite 비교 분석: 차세대 웹 개발 번들러 선택 가이드
• [클라우드 인프라] EKS, GKE, AKS 비교 분석: 클라우드 매니지드 쿠버네티스 서비스 선택 가이드
• [개발 도구] VS Code 고급 활용법: 개발 생산성을 극대화하는 확장 프로그램과 설정 팁

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