서비스 확장이 두려운 개발자를 위한 멀티테넌시 데이터베이스 설계 비밀

SaaS 애플리케이션을 위한 멀티테넌시 데이터베이스 설계의 모든 것! 초보 개발자도 쉽게 이해할 수 있도록 데이터 격리, 확장성 확보 전략과 실무 베스트 프랙티스를 알려드려요.

안녕하세요, 개발자 여러분! 여러분은 혹시 언젠가 자신만의 멋진 SaaS 애플리케이션을 만들어서 많은 사람들에게 서비스를 제공하는 꿈을 꾸고 계신가요? 마치 우리가 매일 쓰는 노션(Notion)이나 슬랙(Slack)처럼요!

그런데 말이죠, 이런 서비스를 만들다 보면 한 가지 큰 고민에 부딪히게 될 거예요. 바로 '데이터베이스' 문제인데요. 수많은 고객사(회사)들이 우리 서비스를 이용할 텐데, 이 고객사들의 데이터를 어떻게 안전하게, 그리고 효율적으로 관리할 수 있을까요? 한 고객사의 데이터가 다른 고객사에게 실수로 노출되면 큰일 나잖아요? 게다가 고객사가 100개, 1000개로 늘어나도 우리 서비스가 멈추지 않고 잘 돌아가야 하고요.

이런 고민을 해결해 줄 멋진 전략이 바로 멀티테넌시(Multi-tenancy) 데이터베이스 설계랍니다. 처음 들어보는 말이라 어렵게 느껴질 수도 있지만, 걱정 마세요! 이 글에서는 프로그래밍을 막 배우기 시작한 여러분의 눈높이에 맞춰 쉽고 친절하게 설명해 드릴게요. 마치 복잡한 미로를 하나씩 풀어나가듯이, 단계별로 차근차근 멀티테넌시의 세계로 안내해 드릴 테니 저와 함께 떠나보실까요?

📑 목차

• 시작하기 전에: 멀티테넌시, 왜 필요할까요?
• SaaS 앱 개발, 뭐가 다를까요?
• 데이터베이스에 고객사가 여럿? 궁금증 해결!
• 레벨 1: 가장 간단한 멀티테넌시, 단일 데이터베이스 & 단일 스키마 (Shared Everything)
• 어떻게 구현하나요? tenant_id 컬럼
• 장점과 단점은?
• 레벨 2: 한 단계 더 나아가기, 단일 데이터베이스 & 다중 스키마 (Schema per Tenant)
• 어떻게 구현하나요? 스키마 분리
• 장점과 단점은?
• 레벨 3: 완전한 격리를 위한 선택, 다중 데이터베이스 (Database per Tenant)
• 어떻게 구현하나요? DB 인스턴스 분리
• 장점과 단점은?
• 멀티테넌시 방식별 비교: 한눈에 알아보기
• 실무에서 만나는 고민들: 베스트 프랙티스와 고려사항
• 데이터베이스 선택, 신중해야죠!
• 보안과 규정 준수, 놓치지 마세요!
• 마이그레이션과 데이터 백업 전략
• 마무리하며: 우리 서비스에 맞는 멀티테넌시, 어떻게 고를까요?

Image by geralt on Pixabay

시작하기 전에: 멀티테넌시, 왜 필요할까요?

본격적인 설계 이야기를 시작하기 전에, 우리가 왜 멀티테넌시를 알아야 하는지 그 필요성부터 짚어보고 가는 게 좋겠죠?

SaaS 앱 개발, 뭐가 다를까요?

우리가 보통 만드는 개인 프로젝트나 특정 회사 내부에서만 쓰는 애플리케이션은 사용자가 정해져 있고, 데이터 관리도 비교적 단순한 편이에요. 하지만 SaaS(Software as a Service) 애플리케이션은 달라요. SaaS는 한 개의 소프트웨어(우리 서비스)를 개발해서 여러 회사나 단체(이들을 테넌트, Tenant라고 부른답니다)에 동시에 제공하는 방식이거든요. 예를 들어, 어도비(Adobe)의 포토샵이나 마이크로소프트(Microsoft)의 365 같은 서비스가 대표적인 SaaS라고 할 수 있죠.

이런 SaaS는 여러 고객사가 같은 소프트웨어를 공유하기 때문에, 우리 개발팀 입장에서는 개발 비용이나 관리 비용을 크게 아낄 수 있다는 장점이 있어요. 새로운 기능을 추가해도 한 번만 개발하면 모든 고객사가 동시에 혜택을 볼 수 있고요. 하지만 동시에, 데이터 관리가 훨씬 더 복잡해진다는 숙제가 생긴답니다. 각 고객사의 데이터는 독립적으로 관리되어야 하니까요!

데이터베이스에 고객사가 여럿? 궁금증 해결!

테넌트가 여러 명인데 왜 멀티테넌시가 필요하냐고요? 상상해보세요. 우리가 만든 서비스에 'A회사'와 'B회사'가 동시에 가입해서 쓰고 있어요. A회사는 자기네 직원 정보, 고객 정보 등을 우리 서비스에 저장하겠죠? B회사도 마찬가지고요. 이때 가장 중요한 건 뭘까요? 맞아요, A회사의 데이터가 B회사에 보여서는 절대 안 된다는 거예요. 이건 보안의 가장 기본 중의 기본이랍니다.

게다가 A회사가 갑자기 사용량이 폭증해서 서버에 부하가 걸리더라도, B회사의 서비스는 아무 문제 없이 잘 돌아가야 해요. 즉, 확장성도 중요하죠. 고객사가 100개, 1000개로 늘어나도 우리 서비스는 끄떡없어야 하니까요. 이런 문제들을 효과적으로 해결하기 위한 전략이 바로 멀티테넌시 데이터베이스 설계인 거죠. 이제 어떤 방법들이 있는지 하나씩 살펴볼까요?

레벨 1: 가장 간단한 멀티테넌시, 단일 데이터베이스 & 단일 스키마 (Shared Everything)

멀티테넌시를 시작하는 가장 쉽고 간단한 방법이에요. 마치 여러 가족이 한 아파트에 살지만, 각자의 방에 문패를 달아 구분하는 것과 비슷하다고 생각하시면 돼요. 즉, 모든 테넌트(고객사)가 하나의 데이터베이스를 공유하고, 심지어 테이블 구조(스키마)까지도 공유하는 방식이랍니다.

어떻게 구현하나요? tenant_id 컬럼

가장 핵심은 바로 tenant_id(테넌트 ID)라는 컬럼(열)을 모든 테이블에 추가하는 거예요. 이 tenant_id가 각 데이터 레코드(행)가 어떤 테넌트의 것인지를 구분하는 유일한 표식이 되는 거죠.

예를 들어, 우리 서비스에 '사용자' 정보를 저장하는 users라는 테이블이 있다고 해볼게요. 여기에 tenant_id 컬럼을 추가하면 이렇게 되는 거예요.

CREATE TABLE users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    tenant_id VARCHAR(255) NOT NULL, -- 어떤 고객사의 데이터인지 구분하는 ID
    username VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL,
    created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

INSERT INTO users (tenant_id, username, email) VALUES
('company_a', '김철수', 'chulsu@companya.com'),
('company_a', '이영희', 'younghee@companya.com'),
('company_b', '박민수', 'minsu@companyb.com');

이제 애플리케이션에서 A회사의 사용자 목록을 가져오고 싶으면, tenant_id = 'company_a'인 데이터만 조회하면 되는 거죠. 마치 이렇게요:

SELECT * FROM users WHERE tenant_id = 'company_a';

간단하죠? 모든 쿼리(데이터 조회/수정/삭제 요청)에 이 tenant_id를 항상 포함시켜야 해요.

장점과 단점은?

• 장점:
  • 개발 및 배포 단순: 가장 구현하기 쉽고, 초기 설정 비용이 적게 들어요.
  • 비용 효율적: 하나의 데이터베이스 인스턴스만 관리하면 되기 때문에 하드웨어 비용이나 운영 비용이 가장 저렴해요.
  • 유지보수 용이: 데이터베이스 스키마(구조)가 하나라서 변경이나 관리가 쉬워요.
• 단점:
  • 데이터 격리 약함: 모든 데이터가 한곳에 모여있기 때문에, 만약 개발자가 실수로 tenant_id 필터를 빠뜨리면 다른 테넌트의 데이터가 노출될 위험이 있어요. 보안상 가장 취약한 방식이죠.
  • 성능 문제: 특정 테넌트의 사용량이 갑자기 많아지면, 전체 데이터베이스에 부하가 걸려서 다른 테넌트의 서비스까지 느려질 수 있어요.
  • 데이터 백업/복구 어려움: 특정 테넌트의 데이터만 백업하거나 복구하는 것이 매우 까다로워요.
  • 규제 준수 어려움: 데이터가 물리적으로 분리되어 있지 않기 때문에, 특정 국가의 데이터만 해당 국가에 보관해야 하는 GDPR 같은 규제에 대응하기 어려울 수 있어요.

이 방식은 초기 스타트업이나 고객사가 많지 않을 때, 그리고 보안 요구사항이 아주 높지 않을 때 고려해 볼 수 있어요. 하지만 서비스가 성장하면서 한계를 느끼게 될 가능성이 높답니다.

레벨 2: 한 단계 더 나아가기, 단일 데이터베이스 & 다중 스키마 (Schema per Tenant)

레벨 1의 단점을 보완하면서도 너무 복잡해지지 않는, 중간 지점의 방법이에요. 여전히 하나의 데이터베이스를 사용하지만, 각 테넌트에게 독립적인 스키마(Schema)를 부여하는 방식이죠. 스키마는 데이터베이스 안에서 테이블, 뷰, 인덱스 등을 묶어놓는 논리적인 공간이라고 생각하시면 돼요. 마치 한 아파트 안에 여러 동이 있고, 각 동이 독립적인 공간처럼 사용되는 것과 비슷하죠.

어떻게 구현하나요? 스키마 분리

이 방식에서는 각 테넌트마다 고유한 스키마를 생성해요. 예를 들어 'A회사'를 위한 company_a_schema, 'B회사'를 위한 company_b_schema를 만드는 식이죠. 그리고 각 스키마 안에 users, products 같은 테이블들을 각각 생성하는 거예요.

-- A회사를 위한 스키마 생성
CREATE SCHEMA company_a_schema;

-- B회사를 위한 스키마 생성
CREATE SCHEMA company_b_schema;

-- A회사 스키마 안에 users 테이블 생성
CREATE TABLE company_a_schema.users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL
);

-- B회사 스키마 안에 users 테이블 생성
CREATE TABLE company_b_schema.users (
    id INT PRIMARY KEY AUTO_INCREMENT,
    username VARCHAR(255) NOT NULL,
    email VARCHAR(255) NOT NULL
);

이제 A회사의 사용자 정보를 조회하려면 company_a_schema.users 테이블을, B회사의 사용자 정보를 조회하려면 company_b_schema.users 테이블을 직접 지정해서 접근해야 해요. 애플리케이션은 사용자가 어떤 테넌트에 속하는지 확인한 후, 해당 테넌트의 스키마에 연결해서 쿼리를 실행하게 되죠.

장점과 단점은?

• 장점:
  • 향상된 데이터 격리: 레벨 1보다 훨씬 나은 논리적 격리를 제공해요. 개발자가 실수로 tenant_id를 빠뜨릴 걱정 없이, 아예 다른 스키마에 접근하는 것 자체가 어려워지죠.
  • 백업/복구 용이: 특정 스키마만 백업하거나 복구하는 것이 레벨 1보다 훨씬 쉬워져요.
  • 스키마 변경 유연성: 특정 테넌트의 요구사항에 따라 해당 스키마의 테이블 구조를 유연하게 변경할 수 있어요 (물론 복잡해질 수 있지만요).
• 단점:
  • 여전히 단일 DB 의존성: 결국 하나의 물리적인 데이터베이스 인스턴스를 공유하기 때문에, 특정 테넌트의 부하가 전체 DB 성능에 영향을 줄 수 있어요.
  • 관리 복잡성 증가: 테넌트 수가 많아질수록 관리해야 할 스키마의 수도 늘어나서, 운영이 조금 더 복잡해질 수 있어요. 모든 스키마에 동일한 업데이트를 적용하는 것도 번거로울 수 있고요.
  • 데이터 집계 어려움: 모든 테넌트의 데이터를 한눈에 보고 분석하기가 더 어려워져요.

이 방식은 레벨 1의 보안 및 격리 문제에 대한 우려가 커질 때, 그리고 테넌트별로 약간의 데이터 구조 유연성이 필요할 때 고려해볼 수 있는 좋은 대안이에요. 하지만 서비스가 정말 폭발적으로 성장하고, 최상위 수준의 격리와 확장성이 필요해진다면 다음 레벨을 고려해야 한답니다.

Image by geralt on Pixabay

레벨 3: 완전한 격리를 위한 선택, 다중 데이터베이스 (Database per Tenant)

이 방식은 각 테넌트(고객사)마다 완전히 독립적인 데이터베이스 인스턴스를 제공하는 가장 강력한 멀티테넌시 전략이에요. 마치 각 가족이 독립적인 주택에 사는 것과 같다고 생각하시면 돼요. 옆집이 아무리 시끄러워도 우리 집에 미치는 영향은 거의 없겠죠? 가장 높은 수준의 격리와 확장성을 제공하지만, 그만큼 비용과 관리의 복잡성도 가장 크답니다.

어떻게 구현하나요? DB 인스턴스 분리

이 방식에서는 'A회사'를 위한 데이터베이스 서버(또는 클라우드 DB 인스턴스) 하나, 'B회사'를 위한 데이터베이스 서버 하나... 이런 식으로 각 테넌트마다 전용 데이터베이스를 생성해요. 각 데이터베이스는 완전히 독립적이기 때문에, IP 주소, 사용자 계정, 비밀번호 등 별도의 연결 정보(Connection String)를 가지게 된답니다.

애플리케이션은 사용자가 로그인할 때 어떤 테넌트에 속하는지 확인한 후, 해당 테넌트의 데이터베이스에 맞는 연결 정보를 사용해서 데이터에 접근하게 돼요. 마치 로그인하면 해당 고객사의 전용 DB에 문이 열리는 것과 같죠.

클라우드 환경에서는 AWS RDS, Azure SQL Database, GCP Cloud SQL 같은 DBaaS(Database as a Service)를 활용하면 각 테넌트별로 쉽게 데이터베이스 인스턴스를 생성하고 관리할 수 있어요. 예를 들어, 100개 고객사가 있다면 100개의 데이터베이스 인스턴스를 생성하는 거죠.

장점과 단점은?

• 장점:
  • 최고의 데이터 격리 및 보안: 각 테넌트의 데이터가 물리적으로 완전히 분리되어 있기 때문에, 한 테넌트의 데이터가 다른 테넌트에게 노출될 위험이 거의 없어요. 보안 요구사항이 가장 높은 서비스에 적합하죠.
  • 뛰어난 확장성: 특정 테넌트의 사용량이 폭증해도 해당 테넌트의 데이터베이스만 확장하면 되기 때문에, 다른 테넌트의 서비스에는 전혀 영향을 주지 않아요. 성능 병목 현상에서 자유롭죠.
  • 백업/복구 용이: 특정 테넌트의 데이터베이스만 백업하거나 복구하는 것이 가장 쉽고 빠르며, 재해 복구(DR) 전략을 세우기도 용이해요.
  • 규제 준수 용이: 특정 국가의 테넌트 데이터를 해당 국가의 데이터센터에만 보관해야 하는 규제에 완벽하게 대응할 수 있어요.
• 단점:
  • 가장 높은 비용: 테넌트 수만큼 데이터베이스 인스턴스를 유지해야 하기 때문에, 비용이 가장 많이 들어요. 테넌트가 100개면 DB 인스턴스 100개!
  • 운영 및 관리 복잡성 급증: 수많은 데이터베이스 인스턴스를 관리하고 모니터링해야 하기 때문에 운영팀의 부담이 커져요. 모든 DB에 동일한 업데이트나 마이그레이션을 적용하는 것도 복잡하고요.
  • 데이터 집계/분석 어려움: 모든 테넌트의 데이터를 통합해서 분석하려면 별도의 데이터 웨어하우스(Data Warehouse) 구축 등 추가적인 노력이 필요해요.
  • 초기 설정 비용 높음: 각 테넌트별 DB 프로비저닝(준비) 자동화 시스템을 구축해야 하는 등 초기 개발 비용이 많이 들 수 있어요.

이 방식은 은행, 의료 서비스처럼 최고 수준의 보안과 규제 준수가 필수적이고, 각 테넌트의 성능이 완벽하게 보장되어야 하는 미션 크리티컬한 서비스에 주로 사용된답니다. 비용이나 관리 복잡성을 감당할 수 있는 대규모 SaaS 기업에 적합하다고 할 수 있어요.

멀티테넌시 방식별 비교: 한눈에 알아보기

지금까지 세 가지 멀티테넌시 방식을 살펴봤는데요, 어떤 방식이 우리 서비스에 가장 적합할지 한눈에 비교해볼 수 있도록 표로 정리해볼게요. 이 표를 보시면 각 방식의 장단점을 명확하게 파악할 수 있을 거예요!

기준	레벨 1: 단일 DB & 단일 스키마 (Shared Everything)	레벨 2: 단일 DB & 다중 스키마 (Schema per Tenant)	레벨 3: 다중 데이터베이스 (Database per Tenant)
데이터 격리 수준	낮음 (논리적, tenant_id 기반)	중간 (논리적, 스키마 기반)	높음 (물리적, 완전 분리)
구현 복잡성	가장 낮음	중간	가장 높음
비용 효율성	가장 높음 (낮은 비용)	중간	가장 낮음 (높은 비용)
확장성	낮음 (단일 DB 병목 가능성)	중간 (단일 DB 병목 가능성 여전)	가장 높음 (개별 테넌트 확장)
관리 용이성	가장 높음 (단일 DB 관리)	중간 (스키마 수에 비례)	가장 낮음 (DB 인스턴스 수에 비례)
보안 수준	기본적인 보안	향상된 논리적 보안	최고 수준의 물리적 보안

Image by geralt on Pixabay

실무에서 만나는 고민들: 베스트 프랙티스와 고려사항

이론적으로는 세 가지 방식이 명확하게 구분되지만, 실제 서비스를 운영하다 보면 여러 가지 현실적인 문제에 부딪히게 돼요. 마지막으로 멀티테넌시 설계 시 꼭 고려해야 할 실무적인 팁들을 알려드릴게요.

데이터베이스 선택, 신중해야죠!

어떤 데이터베이스를 사용할지도 중요한 결정인데요. 대부분의 멀티테넌시 서비스는 관계형 데이터베이스(RDBMS)를 많이 사용해요. PostgreSQL, MySQL 같은 데이터베이스가 대표적이죠. 이들은 트랜잭션(거래) 처리나 데이터 일관성 유지에 강점이 있어서, 고객사의 중요한 데이터를 다루기에 적합하거든요.

물론 NoSQL 데이터베이스(MongoDB, Cassandra 등)도 멀티테넌시에 사용될 수 있어요. 특히 대량의 비정형 데이터를 빠르게 처리해야 하거나, 유연한 스키마가 필요할 때 고려해볼 수 있죠. 하지만 데이터 격리나 트랜잭션 처리 면에서는 RDBMS보다 더 많은 주의와 설계 노력이 필요할 수 있답니다.

클라우드 환경에서 서비스를 한다면 AWS RDS, Azure SQL Database, GCP Cloud SQL 같은 DBaaS(Database as a Service)를 적극 활용하는 것을 추천해요. 데이터베이스를 직접 설치하고 관리하는 것보다 훨씬 편리하고, 확장성이나 안정성 면에서 큰 이점을 얻을 수 있거든요.

보안과 규정 준수, 놓치지 마세요!

멀티테넌시에서는 데이터 보안이 무엇보다 중요해요. 어떤 방식을 선택하든 다음 사항들을 꼭 염두에 두세요:

• 데이터 암호화: 저장된 데이터(Data at Rest)와 전송되는 데이터(Data in Transit) 모두 암호화해야 해요.
• 접근 제어: 데이터베이스에 접근할 수 있는 계정과 권한을 최소한으로 설정하고 철저히 관리해야 해요.
• 로그 및 감사: 누가 언제 어떤 데이터에 접근했는지 기록하고 주기적으로 감사해서 의심스러운 활동을 감지해야 합니다.

또한, 각 국가나 산업별로 데이터 규제(예: 유럽의 GDPR, 미국의 CCPA)가 있을 수 있어요. 특정 테넌트의 데이터는 반드시 특정 지역에만 저장해야 하는 등의 요구사항이 있다면, 레벨 3처럼 물리적으로 데이터베이스를 분리하는 방식이 유리할 수 있답니다. 우리 서비스의 고객들이 어떤 지역에 있는지, 어떤 데이터를 다루는지 미리 파악하는 것이 중요해요.

마이그레이션과 데이터 백업 전략

서비스를 운영하다 보면 데이터베이스 스키마를 변경하거나(마이그레이션), 데이터를 백업하고 복구해야 할 일이 빈번하게 생겨요.

• 스키마 마이그레이션: 레벨 1 방식은 모든 테넌트가 같은 스키마를 쓰기 때문에 한 번만 마이그레이션을 하면 되지만, 레벨 2나 레벨 3 방식은 여러 스키마나 데이터베이스에 동일한 변경 사항을 적용해야 하므로 자동화된 도구나 스크립트를 준비해두는 것이 좋아요.
• 데이터 백업 및 복구: 각 멀티테넌시 방식의 장단점에서 언급했듯이, 레벨 3 방식이 개별 테넌트의 백업/복구에는 가장 유리해요. 하지만 어떤 방식을 쓰든, 모든 데이터는 주기적으로 백업하고, 문제가 생겼을 때 빠르게 복구할 수 있는 비상 계획(Disaster Recovery Plan)을 반드시 세워두어야 한답니다.

마무리하며: 우리 서비스에 맞는 멀티테넌시, 어떻게 고를까요?

자, 이제 멀티테넌시 데이터베이스 설계에 대한 긴 여정을 마치게 되었네요! 어떠셨나요? 처음엔 어렵게만 느껴졌던 개념들이 조금은 친숙하게 다가오셨나요?

오늘 우리가 배운 세 가지 멀티테넌시 방식은 각각 장점과 단점이 명확했어요. 어떤 방식이 '정답'이라고 말할 수는 없답니다. 중요한 건 우리 서비스의 현재 상황과 미래 계획에 가장 적합한 방식을 선택하는 것이에요.

• 비용이 최우선이고, 초기 단계의 서비스라면: 레벨 1 (단일 DB & 단일 스키마)로 시작해서 빠르게 서비스를 출시하고 시장 반응을 보는 것이 현명할 수 있어요.
• 어느 정도 성장이 예상되고, 격리 수준을 높이고 싶다면: 레벨 2 (단일 DB & 다중 스키마)를 고려해보세요. 비용과 격리 사이에서 좋은 균형점을 찾을 수 있을 거예요.
• 보안, 규제 준수, 최고 수준의 성능과 확장성이 필수적이라면: 레벨 3 (다중 데이터베이스)가 궁극적인 목표가 될 수 있겠죠. 하지만 그만큼 많은 준비와 투자가 필요하다는 점을 잊지 마세요.

많은 개발자들이 처음에는 간단한 방식으로 시작했다가, 서비스가 성장하면서 더 높은 수준의 멀티테넌시 방식으로 마이그레이션(이전)하는 전략을 사용하기도 해요. 처음부터 가장 복잡한 방식을 선택하기보다는, 점진적으로 발전시켜 나가는 것도 좋은 방법이랍니다.

이 글이 여러분의 SaaS 데이터베이스 설계에 조금이나마 도움이 되었으면 좋겠어요. 복잡한 설계는 어려울 수 있지만, 이렇게 하나씩 알아가다 보면 어느새 멋진 아키텍처를 설계하는 실력 있는 개발자가 되어 있을 거예요! 혹시 이 외에 궁금한 점이나 여러분만의 팁이 있다면 댓글로 자유롭게 공유해주세요! 함께 성장해나가요!

📌 함께 읽으면 좋은 글

• [개발 책 리뷰] 실패 없는 DSL 도입을 위한 PM의 5가지 핵심 체크포인트
• [임베디드 IoT] STM32 I2C/SPI 통신, 마스터/슬레이브 펌웨어 개발 실전 가이드
• [임베디드 IoT] 임베디드 시스템 안정성 100배 향상 비결: FreeRTOS/Zephyr Task 스케줄링 문맥 전환 마스터 전략

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