사이드 프로젝트 인프라 비용 80% 절감: 최소 자원으로 최대 성능을 내는 아키텍처 튜닝 전략

사이드 프로젝트 인프라 비용 때문에 고민인가요? 5년차 이상 시니어 개발자를 위한 최소 자원으로 최대 성능을 내는 아키텍처 튜닝 전략과 실용적인 비용 최적화 기법을 심층 분석합니다.

다년간의 개발 경험을 통해 탄탄한 실력을 쌓아온 시니어 개발자에게 사이드 프로젝트는 단순한 취미를 넘어 새로운 기술 스택을 탐색하고 아이디어를 현실로 구현하는 중요한 발판이 된다. 그러나 야심 찬 아이디어를 현실화하는 과정에서 예상치 못한 복병을 만나게 되는데, 바로 인프라 비용 문제이다. 초기 단계에서는 무료 티어 등으로 부담 없이 시작할 수 있으나, 프로젝트의 규모가 커지고 트래픽이 증가할수록 매달 지출되는 클라우드 비용은 개발자의 지갑을 위협하는 현실적인 장벽으로 다가온다. 이러한 비용 문제는 때로는 프로젝트의 지속 가능성을 저해하고, 새로운 시도를 주저하게 만드는 요인으로 작용한다.

본 글에서는 5년차 이상 시니어 개발자의 눈높이에 맞춰, 최소한의 자원으로 최대한의 성능을 이끌어내면서 인프라 비용을 획기적으로 절감할 수 있는 아키텍처 튜닝 전략을 심층적으로 다룬다. 단순히 비용을 줄이는 것을 넘어, 성능 저하 없이 효율성을 극대화하는 방안들을 다양한 클라우드 서비스와 기법을 통해 제시한다. 하나의 문제 상황에서 출발하여 여러 해결 방법을 단계적으로 비교하고 적용하는 과정을 통해, 독자 여러분의 사이드 프로젝트가 비용 부담 없이 지속적으로 성장할 수 있는 기반을 마련하는 데 기여하고자 한다.

과연 우리는 어떻게 제한된 예산 안에서 최고 수준의 성능과 안정성을 확보할 수 있을까? 다음 섹션부터 구체적인 아키텍처 튜닝 기법들을 탐색해 보도록 한다.

📑 목차

• 1. 서버리스 및 FaaS(Function as a Service) 활용 극대화: 온디맨드 비용 효율성
• 1.1. AWS Lambda, Google Cloud Functions를 통한 비용 절감
• 1.2. API Gateway, S3를 활용한 정적 콘텐츠 호스팅
• 2. 데이터베이스 비용 최적화 전략: 효율적인 저장 및 접근
• 2.1. NoSQL vs. RDBMS 선택과 운용 전략
• 2.2. 캐싱(Redis, Memcached) 도입을 통한 DB 부하 감소
• 3. 컨테이너 오케스트레이션 효율화: Spot Instance 및 오토스케일링
• 3.1. Spot Instance, Fargate Spot을 활용한 비용 절감
• 3.2. 오토스케일링 그룹 및 리소스 할당 최적화
• 4. CDN(Content Delivery Network) 및 엣지 컴퓨팅 활용: 글로벌 성능과 보안
• 4.1. 정적 자산 배포 및 Latency 감소
• 4.2. WAF, Shield를 통한 보안 및 비용 효율성
• 5. 모니터링 및 비용 가시성 확보: 지속적인 최적화의 기반
• 5.1. 클라우드 비용 모니터링 도구 활용
• 5.2. 로그 및 지표 분석을 통한 성능 병목 식별
• 결론: 효율적 아키텍처 튜닝으로 사이드 프로젝트의 지속 가능성 확보

Image by Tama66 on Pixabay

1. 서버리스 및 FaaS(Function as a Service) 활용 극대화: 온디맨드 비용 효율성

사이드 프로젝트의 인프라 비용을 절감하는 가장 효과적인 방법 중 하나는 서버리스 아키텍처, 특히 FaaS(Function as a Service)를 적극적으로 활용하는 것이다. 전통적인 서버 방식은 항상 인스턴스를 유지해야 하므로 유휴 시간에도 비용이 발생하지만, FaaS는 실제 코드가 실행되는 동안에만 비용을 지불하는 온디맨드(On-demand) 과금 모델을 채택하고 있어 간헐적인 트래픽이나 예측 불가능한 워크로드에 매우 유리하다. 이는 사이드 프로젝트의 특성상 초기 트래픽이 적거나 불규칙할 때 막대한 비용 절감 효과를 가져올 수 있다.

1.1. AWS Lambda, Google Cloud Functions를 통한 비용 절감

AWS Lambda나 Google Cloud Functions와 같은 FaaS 서비스는 특정 이벤트(예: HTTP 요청, 데이터베이스 변경, 파일 업로드)에 반응하여 코드를 실행한다. 이는 개발자가 서버 관리의 부담에서 벗어나 비즈니스 로직 구현에만 집중할 수 있게 하며, 동시에 사용량에 비례하는 과금 체계를 통해 비용을 최적화한다.

예를 들어, 간단한 API 서버나 백그라운드 작업을 Lambda 함수로 구현할 경우, 월 수십만 건의 호출에도 불구하고 매우 적은 비용으로 운영이 가능하다. 특히, Lambda의 경우 무료 티어가 상당한 수준의 사용량을 제공하므로, 소규모 사이드 프로젝트는 사실상 인프라 비용 없이 운영될 수도 있다.

// 예시: AWS Lambda를 이용한 간단한 Node.js API
exports.handler = async (event) => {
    const response = {
        statusCode: 200,
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ message: "Hello from Lambda!" }),
    };
    return response;
};

이러한 FaaS 환경에서는 콜드 스타트(Cold Start) 문제를 고려해야 하지만, 대부분의 사이드 프로젝트에서는 허용 가능한 수준이거나, 프로비저닝된 동시성(Provisioned Concurrency)과 같은 기능을 통해 완화할 수 있다. 중요한 것은 FaaS의 이벤트 기반 아키텍처를 이해하고, 각 기능을 독립적인 함수로 설계하여 재사용성과 확장성을 높이는 것이다.

1.2. API Gateway, S3를 활용한 정적 콘텐츠 호스팅

프론트엔드 애플리케이션이나 정적인 웹사이트를 호스팅하는 데는 서버리스 서비스인 Amazon S3와 CloudFront (CDN) 조합이 가장 비용 효율적이다. S3에 정적 파일을 저장하고 CloudFront를 통해 전 세계 엣지 로케이션에서 콘텐츠를 캐싱하여 제공함으로써, 사용자에게 빠른 응답 속도를 제공하고 S3의 데이터 전송 비용을 절감할 수 있다.

동적인 API 요청은 API Gateway를 통해 Lambda 함수로 라우팅하는 방식을 채택한다. API Gateway는 요청 라우팅, 인증/인가, 스로틀링, 캐싱 등 다양한 기능을 제공하며, 사용량에 따라 과금되므로 초기 비용 부담이 적다. 이 조합은 전체 애플리케이션 스택을 서버리스 형태로 구축하여 인프라 관리 부담과 비용을 최소화하는 데 매우 강력한 전략이다.

다음 표는 일반적인 웹 서비스 아키텍처와 서버리스 아키텍처의 비용 및 관리 측면 비교이다.

항목	일반적인 EC2/VM 기반	서버리스 (Lambda, API Gateway, S3)
비용 모델	시간당 고정 비용 (인스턴스 유형에 따라)	실제 사용량 기반 (요청 수, 실행 시간, 메모리)
관리 오버헤드	서버 프로비저닝, OS 패치, 보안 업데이트, 스케일링 등 상당	서버 관리 없음, 코드만 배포
스케일링	오토스케일링 그룹 설정 필요, 스케일 업/다운 시간 소요	자동 스케일링, 즉각적이고 탄력적
시작 비용	인스턴스 최소 비용 발생	무료 티어 활용 시 초기 비용 거의 없음
주요 트레이드오프	높은 제어권, 예측 가능한 성능	콜드 스타트, 제한된 런타임/메모리, 벤더 종속성

2. 데이터베이스 비용 최적화 전략: 효율적인 저장 및 접근

데이터베이스는 사이드 프로젝트에서 인프라 비용의 상당 부분을 차지할 수 있는 영역이다. 특히 RDBMS의 경우, 스토리지를 넘어 IOPS(Input/Output Operations Per Second), 컴퓨팅 리소스(CPU, RAM) 등 다양한 요소가 비용에 영향을 미치므로 신중한 접근이 필요하다. 올바른 데이터베이스 선택과 튜닝은 비용 절감과 성능 향상에 결정적인 역할을 한다.

2.1. NoSQL vs. RDBMS 선택과 운용 전략

프로젝트의 데이터 모델과 접근 패턴에 따라 NoSQL과 RDBMS 중 적절한 데이터베이스를 선택하는 것이 중요하다. 관계형 데이터베이스(예: PostgreSQL, MySQL)는 데이터의 일관성과 복잡한 쿼리에 강점을 보이지만, 스케일링이 상대적으로 어렵고 비용이 높을 수 있다. 반면, NoSQL 데이터베이스(예: DynamoDB, MongoDB, Firestore)는 유연한 스키마, 수평적 확장성, 낮은 레이턴시를 제공하며, 특정 워크로드에서는 RDBMS보다 훨씬 비용 효율적일 수 있다.

예를 들어, 사용자 프로필, 세션 정보, 로그 데이터 등 비정형적이거나 대량의 데이터를 저장하고 빠르게 읽고 쓰는 작업이 주를 이룬다면 DynamoDB(AWS), Firestore(GCP)와 같은 NoSQL 데이터베이스가 유리하다. 이들 서비스는 종량제(Pay-per-use) 모델을 제공하며, 온디맨드 용량 모드를 통해 사용량에 따라 자동으로 스케일링되므로 예측 불가능한 트래픽에 대한 비용 부담을 줄일 수 있다. 특히 DynamoDB의 무료 티어는 월 25GB의 스토리지와 2천만 건의 읽기/쓰기 요청을 제공하여 사이드 프로젝트에 매우 매력적이다.

만약 복잡한 조인 쿼리나 트랜잭션의 일관성이 매우 중요하다면 RDBMS를 선택해야 하지만, 이 경우에도 비용 최적화를 위한 전략이 필요하다. AWS RDS나 Google Cloud SQL의 저사양 인스턴스를 활용하거나, 필요할 때만 인스턴스를 활성화하는 Aurora Serverless와 같은 옵션을 고려할 수 있다. 데이터베이스 연결 풀(Connection Pool)을 최적화하여 불필요한 연결 생성을 줄이고, 쿼리 튜닝을 통해 데이터베이스 부하를 최소화하는 것도 중요한 기법이다.

// 예시: Node.js에서 데이터베이스 연결 풀 설정 (PostgreSQL)
const { Pool } = require('pg');
const pool = new Pool({
    user: 'your_user',
    host: 'your_host',
    database: 'your_database',
    password: 'your_password',
    port: 5432,
    max: 10, // 최대 연결 수 설정 (트래픽에 따라 조절)
    idleTimeoutMillis: 30000, // 유휴 연결 종료 시간 (ms)
    connectionTimeoutMillis: 2000, // 연결 시도 타임아웃 (ms)
});

// 쿼리 실행 예시
async function fetchData() {
    const client = await pool.connect();
    try {
        const res = await client.query('SELECT * FROM users WHERE status = $1', ['active']);
        return res.rows;
    } finally {
        client.release(); // 연결 반환
    }
}

2.2. 캐싱(Redis, Memcached) 도입을 통한 DB 부하 감소

데이터베이스의 부하를 줄이고 성능을 향상시키는 동시에 비용을 절감하는 핵심 전략은 캐싱(Caching)이다. 자주 접근되는 데이터나 컴퓨팅 비용이 높은 쿼리 결과를 캐시에 저장하면, 데이터베이스에 직접 접근하는 횟수를 크게 줄일 수 있다. 이는 데이터베이스의 CPU, 메모리, IOPS 사용량을 감소시켜 더 작은 인스턴스로도 동일한 성능을 유지하거나, 인스턴스 업그레이드 없이도 높은 트래픽을 처리할 수 있게 한다.

Redis나 Memcached와 같은 인메모리 캐시 솔루션은 읽기 중심의 워크로드에 매우 효과적이다. AWS의 ElastiCache, Google Cloud의 Memorystore와 같은 관리형 서비스는 캐시 인프라 관리를 간소화하면서도 뛰어난 성능을 제공한다. 사이드 프로젝트의 경우, 무료 티어가 제공되거나 저렴한 개발자용 인스턴스를 활용하여 캐싱 레이어를 도입할 수 있다.

캐싱 전략 수립 시에는 캐시 무효화(Cache Invalidation) 전략, 캐시 히트율(Cache Hit Ratio) 최적화, 그리고 캐시 데이터의 TTL(Time-To-Live) 설정 등을 신중하게 고려해야 한다.

3. 컨테이너 오케스트레이션 효율화: Spot Instance 및 오토스케일링

사이드 프로젝트가 일정 수준 이상의 복잡성을 가지거나, 다양한 마이크로서비스로 구성될 경우 컨테이너 오케스트레이션(예: Kubernetes, ECS, EKS)을 고려하게 된다. 컨테이너는 환경 일관성을 제공하고 배포를 용이하게 하지만, 그 자체로 비용 절감을 보장하지는 않는다. 효율적인 오케스트레이션과 자원 관리가 필수적이다.

3.1. Spot Instance, Fargate Spot을 활용한 비용 절감

AWS Spot Instance나 Google Cloud Spot VM은 온디맨드 인스턴스 대비 최대 90%까지 저렴한 비용으로 컴퓨팅 자원을 사용할 수 있는 강력한 비용 절감 수단이다. 이는 클라우드 공급자가 미사용 중인 예비 용량을 할인된 가격으로 제공하는 것으로, 언제든 회수될 수 있다는 특징을 가진다. 따라서 일시적인 중단에도 강인한 무상태(Stateless) 애플리케이션이나 배치 작업, 개발/테스트 환경 등에 매우 적합하다.

컨테이너 환경에서는 Kubernetes의 노드 그룹에 Spot Instance를 포함하거나, AWS의 ECS Fargate Spot을 활용하여 컨테이너 워크로드를 저렴하게 실행할 수 있다. Fargate Spot은 Fargate의 서버리스 컨테이너 장점과 Spot Instance의 비용 절감 효과를 결합한 것으로, 개발자가 서버를 관리할 필요 없이 컨테이너를 실행하면서도 상당한 비용을 절약할 수 있게 한다.

Spot Instance/Fargate Spot 활용 시에는 작업의 내결함성(Fault Tolerance)을 확보하는 것이 중요하다. 작업 중단 시 재시작 메커니즘을 갖추고, 중요한 데이터는 영구 스토리지(예: S3, EFS)에 저장하며, 분산 처리 시스템을 설계하여 단일 장애 지점을 회피하는 방식으로 안정성을 확보해야 한다.

3.2. 오토스케일링 그룹 및 리소스 할당 최적화

컨테이너 환경에서 오토스케일링(Autoscaling)은 트래픽 변화에 따라 자동으로 자원을 조절하여 비용 효율성을 극대화하는 핵심 기법이다. Kubernetes HPA(Horizontal Pod Autoscaler)나 클라우드 제공자의 오토스케일링 그룹을 활용하여 CPU 사용률, 메모리 사용량, 네트워크 I/O 등의 지표에 따라 Pod나 EC2 인스턴스의 수를 자동으로 늘리거나 줄일 수 있다.

또한, 컨테이너의 리소스 할당(Resource Allocation)을 최적화하는 것은 낭비되는 자원을 줄이는 데 필수적이다. 컨테이너 런타임 환경에서 각 컨테이너에 필요한 CPU 및 메모리 Request(요청)와 Limit(제한) 값을 정확하게 설정해야 한다. 너무 높은 Request 값은 스케줄러가 자원을 과도하게 예약하게 하여 비용을 증가시키고, 너무 낮은 Limit 값은 OOM(Out Of Memory) 등으로 컨테이너가 강제 종료될 위험을 높인다. 적절한 모니터링을 통해 실제 사용량을 파악하고, 이를 기반으로 리소스 할당을 지속적으로 튜닝하는 과정이 요구된다.

# 예시: Kubernetes Pod의 리소스 요청 및 제한 설정
apiVersion: v1
kind: Pod
metadata:
  name: my-app
spec:
  containers:
  - name: my-container
    image: my-image:latest
    resources:
      requests:
        memory: "128Mi" # 최소 128MB 메모리 요청
        cpu: "250m"    # 최소 0.25 vCPU 요청
      limits:
        memory: "256Mi" # 최대 256MB 메모리 제한
        cpu: "500m"    # 최대 0.5 vCPU 제한

Image by pixexid on Pixabay

4. CDN(Content Delivery Network) 및 엣지 컴퓨팅 활용: 글로벌 성능과 보안

클라우드 환경에서 트래픽 비용은 예상보다 큰 부분을 차지할 수 있다. 특히 외부로 나가는 데이터 전송 비용(Egress Traffic)은 클라우드 공급자마다 다르게 책정되지만, 일반적으로 상당한 비용이 발생한다. CDN(Content Delivery Network)과 엣지 컴퓨팅(Edge Computing)을 활용하면 이러한 트래픽 비용을 절감하고, 동시에 최종 사용자에게 더 나은 성능과 보안을 제공할 수 있다.

4.1. 정적 자산 배포 및 Latency 감소

웹 애플리케이션의 이미지, CSS, JavaScript 파일과 같은 정적 자산은 CDN을 통해 배포하는 것이 비용과 성능 면에서 모두 이득이다. AWS CloudFront나 Google Cloud CDN과 같은 서비스는 전 세계 곳곳에 분산된 엣지 로케이션(Edge Location)에 콘텐츠를 캐싱하여, 사용자가 가장 가까운 엣지에서 데이터를 받아볼 수 있게 한다. 이는 콘텐츠 로딩 속도를 획기적으로 향상시켜 사용자 경험을 개선하고, 원본 서버(Origin Server)로의 직접적인 요청을 줄여 데이터 전송 비용을 절감한다.

예를 들어, S3에 저장된 웹사이트의 정적 파일을 CloudFront를 통해 서비스하면, S3에서 발생하는 트래픽 비용보다 CloudFront를 통한 트래픽 비용이 훨씬 저렴하며, 무료 티어 제공량도 크다. 또한, CloudFront는 HTTP/2, Brotli 압축 등 최신 웹 표준을 지원하여 추가적인 성능 최적화를 제공한다.

4.2. WAF, Shield를 통한 보안 및 비용 효율성

CDN은 단순한 콘텐츠 전송을 넘어, 웹 방화벽(WAF) 및 DDoS 방어(Shield)와 같은 보안 기능을 통합하여 제공하는 경우가 많다. AWS WAF를 CloudFront와 연동하면 SQL Injection, XSS(Cross-Site Scripting) 등 일반적인 웹 공격으로부터 애플리케이션을 보호할 수 있으며, 악성 봇이나 불필요한 트래픽을 차단하여 원본 서버의 부하를 줄이고 비용을 절감하는 효과도 얻을 수 있다.

또한, 클라우드 제공자의 기본 DDoS 방어 서비스(예: AWS Shield Standard)는 추가 비용 없이 제공되어 기본적인 네트워크 계층 DDoS 공격으로부터 보호한다. 이는 사이드 프로젝트의 안정성을 높이고 잠재적인 서비스 중단으로 인한 손실을 방지하는 데 기여한다.

Image by dnovac on Pixabay

5. 모니터링 및 비용 가시성 확보: 지속적인 최적화의 기반

아키텍처를 아무리 잘 설계했더라도, 실제 운영 환경에서의 성능과 비용 효율성을 지속적으로 유지하기 위해서는 정확한 모니터링과 비용 가시성 확보가 필수적이다. 사이드 프로젝트라고 해서 이 부분을 간과해서는 안 된다. 오히려 제한된 자원 안에서 최대 효율을 내야 하므로 더욱 중요하다.

5.1. 클라우드 비용 모니터링 도구 활용

클라우드 비용은 예측하기 어려운 경우가 많으며, 불필요한 리소스가 할당되어 있거나 비효율적인 아키텍처로 인해 낭비될 수 있다. AWS Cost Explorer, Google Cloud Billing Reports와 같은 클라우드 제공자의 기본 비용 관리 도구를 적극적으로 활용해야 한다. 이들 도구는 현재 지출 내역을 상세하게 보여줄 뿐만 아니라, 미래 비용을 예측하고 비용 이상 징후를 감지하는 기능을 제공한다.

또한, 비용 태깅(Cost Tagging) 전략을 도입하여 각 리소스에 프로젝트, 환경(개발/운영), 소유자 등의 태그를 지정하면, 어떤 리소스가 얼마나 비용을 발생시키는지 명확하게 파악할 수 있다. 이는 비용 최적화 대상을 식별하고, 특정 서비스나 프로젝트의 비용을 분석하는 데 매우 유용하다. 불필요하게 가동 중인 리소스(예: 사용되지 않는 개발용 인스턴스, 오래된 스냅샷)를 주기적으로 식별하고 정리하는 습관을 들이는 것이 중요하다.

5.2. 로그 및 지표 분석을 통한 성능 병목 식별

애플리케이션의 성능 병목 지점은 종종 불필요한 자원 소모와 비용 증가로 이어진다. AWS CloudWatch, Google Cloud Monitoring과 같은 관리형 모니터링 서비스를 통해 CPU 사용률, 메모리 사용량, 네트워크 I/O, 데이터베이스 쿼리 시간, 에러율 등 핵심 지표들을 수집하고 분석해야 한다. 이러한 지표들은 애플리케이션의 현재 상태를 파악하고, 성능 저하가 발생했을 때 그 원인을 신속하게 진단하는 데 도움을 준다.

로그 분석도 중요한 부분이다. AWS CloudWatch Logs, Google Cloud Logging을 통해 애플리케이션 로그를 중앙 집중화하고, 특정 패턴이나 에러 메시지를 기반으로 알림을 설정할 수 있다. 예를 들어, 특정 API의 응답 시간이 갑자기 길어지거나 데이터베이스 연결 오류가 증가하는 경우, 즉각적인 알림을 통해 문제를 인지하고 대응할 수 있다. 이는 사전에 문제를 해결하여 서비스 품질을 유지하고, 더 큰 비용 문제로 이어지는 것을 방지한다.

지속적인 모니터링과 분석을 통해 리소스 사용 패턴을 이해하고, 이를 바탕으로 인스턴스 유형 변경, 스케일링 정책 조정, 데이터베이스 인덱스 추가 등 선제적인 최적화 작업을 수행하는 것이 비용 절감과 성능 향상을 위한 핵심이다.

결론: 효율적 아키텍처 튜닝으로 사이드 프로젝트의 지속 가능성 확보

사이드 프로젝트의 인프라 비용 최적화는 단순히 지출을 줄이는 행위를 넘어, 최소 자원으로 최대 성능을 이끌어내어 프로젝트의 지속 가능성을 확보하는 중요한 전략이다. 서버리스 아키텍처의 활용, 데이터베이스 선택과 캐싱 전략, 컨테이너 오케스트레이션의 효율화, CDN을 통한 트래픽 비용 절감, 그리고 철저한 모니터링과 비용 가시성 확보는 시니어 개발자가 자신의 아이디어를 현실로 구현하는 데 있어 필수적인 고려 사항이다.

본 글에서 다룬 다양한 기법들은 각기 다른 워크로드와 요구사항에 따라 유연하게 조합될 수 있다. 중요한 것은 프로젝트의 특성과 예산을 명확히 이해하고, 각 기술 스택의 트레이드오프를 면밀히 분석하여 최적의 아키텍처를 설계하는 것이다. 초기 단계부터 이러한 비용 효율적인 아키텍처 튜닝 전략을 염두에 둔다면, 사이드 프로젝트는 비용 부담 없이 더욱 빠르게 성장하고 발전할 수 있을 것이다.

여러분은 사이드 프로젝트의 인프라 비용을 최적화하기 위해 어떤 전략들을 적용하고 계신가요? 혹은 특정 기술 스택에서 겪었던 비용 문제와 그 해결 경험이 있으신가요? 댓글을 통해 여러분의 소중한 경험과 인사이트를 공유해 주시면 감사하겠습니다.

📌 함께 읽으면 좋은 글

• [커리어 취업] 개발자 연봉 협상 성공 전략: 시장 가치 파악부터 오퍼 수락까지
• [커리어 취업] 합격률 높이는 개발자 이력서 작성 전략: 포트폴리오 연동과 핵심 경험 어필
• [게임 개발] 멀티플레이어 게임 개발, TCP와 UDP 선택 기준과 숨겨진 트레이드오프 깊이 파고들기

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