Postgres JSONB와 NoSQL 비교

현실은 데이터베이스가 융합되고 있으며, 지난 몇 년 동안 각 데이터스토어의 내부 작동 방식에 대한 깊은 이해 없이는 각 데이터스토어에 가장 적합한 시나리오를 가리키는 것이 더욱 어려워지고 있습니다. 

Postgres는 수년 동안 제가 가장 좋아하는 RDBMS였으며, JSONB 지원의 인기가 높아지고 있다는 사실에 매우 기쁩니다. 제 개인적인 생각으로는 개발자들이 평범한 기존 테이블 대신 JSON으로 데이터를 저장할 때의 모든 장점에 더 익숙해지는 데 도움이 될 것입니다.

그러나 많은 사람들이 실수로 Postgres 11을 "새로운 NoSQL"이라고 소개하거나, 필요하지 않다고 말하는 것을 보았습니다. NoSQL 데이터베이스 를 이미 사용하고 있기 때문입니다. 이 글에서는 주요 차이점과 사용 사례에 대해 설명하고자 합니다.

전체 기사를 읽을 시간이 없다면 결론에서 가장 중요한 조사 결과를 요약해 드리겠습니다.

데이터 모델링 RDBMS 및 문서 데이터베이스

우리는 모두 대규모 RDBMS에서 조인 작업의 비용에 대해 잘 알고 있습니다: 각각 10개의 기본 설정을 가진 백만 명의 사용자가 있는 경우, 이 사용자를 메모리로 가져오기 위해 ORM 프레임워크(객체 관계형 매핑), 1,000만 개의 행이 있는 USER_PREFERENCES 테이블로 조인을 만들어야 합니다. 

실제 시나리오에서는 사용자가 다른 많은 엔티티와 연관되어 있는 경우가 많기 때문에 이 시나리오는 더욱 악화되고 개발자는 어떤 관계를 게으르거나 열성적으로 관리해야 할지 결정해야 합니다. 오늘날의 모든 RDBMS에는 이미 위의 시나리오에 대한 많은 최적화 기능이 있지만, 지난 30년 동안 해왔던 방식으로 데이터를 모델링하는 것은 분명 최적이 아닙니다. 

RDBMS가 트랜잭션 처리에 능숙하게 된 이유 중 하나는 바로 데이터 모델의 한계 때문입니다: 상품이 없는데 주문을 저장하는 것이 의미가 있을까요? 그럼에도 불구하고 최소 두 개의 테이블에 분산된 이 '단일 통합'을 저장하기 위해 트랜잭션을 생성할 수밖에 없습니다: 주문 그리고 ORDER_ITEM.

좀 더 일반적인 시나리오, 즉 사용자가 문서 데이터베이스에 저장되는 경우와 RDBMS에 저장되는 경우를 살펴보겠습니다:

문서 데이터베이스에서 강력한 관계를 가진 엔티티는 일반적으로 단일 구조에 저장됩니다. 이 접근 방식에서는 환경 설정 및 사용 권한과 같은 항목을 로드하는 데 추가 비용이 거의 들지 않지만, 관계형 모델에서는 최소 2개의 조인이 필요합니다.

 이제 이 예시를 간단한 이커머스 사용 사례로 확장해 보겠습니다:

위의 예에서 문서 데이터베이스는 사용자와 제품을 나열하기 위해 조인이 필요하지 않습니다. 그러나 주문의 경우 한두 개가 필요할 수 있으며, 이는 충분히 허용됩니다. RDBMS의 동일한 모델에는 최소 ~12개의 테이블이 필요합니다:

위의 예제를 통해 JOIN이 RDBMS에서는 필수적인 반면, 문서 데이터베이스에서는 덜 자주 사용된다는 것을 알 수 있습니다. 대부분의 관련 엔티티가 단일 문서에 저장되므로 트랜잭션이나 캐스케이드 작업에도 동일하게 적용됩니다.

가장 유명한 NoSQL 데이터베이스 중 일부는 여전히 JOIN을 제대로 지원하지 않습니다. 다행히도 여기서는 그렇지 않습니다. Couchbase는 다음과 같은 기능도 지원합니다. ANSI 조인: 

RDBMS용 데이터 모델링과 NoSQL용 데이터 모델링에 대한 설명은 이미 보셨겠지만, 각 데이터베이스가 특정 데이터 모델에 최적화되어 있고 성능 테스트 중에 중요한 역할을 하기 때문에 다시 한 번 강조하고 싶습니다. 

사일로 신화

사용자와 제품 이름은 거의 변경되지 않으므로 주문 엔티티에 둘 다 저장하여 몇 번의 조인을 피할 수 있으며, 이는 다음과 같은 일반적인 전략입니다. NoSQL 데이터베이스로 설정되어 있지만 엄격하게 시행되지는 않습니다:

다른 엔티티에 데이터를 캐싱하면 대규모로 쿼리 성능을 크게 향상시킬 수 있지만 몇 가지 단점이 있습니다: 시스템의 여러 부분에 데이터를 캐싱해야 하는 경우 데이터가 변경될 때마다 '데이터 동기화 유지'를 위해 몇 가지 업데이트를 실행해야 합니다. 

저는 많은 숙련된 개발자들이 이를 문서 데이터베이스의 단점으로 사용하는 것을 보아왔으며, 항상 RDBMS에서도 똑같은 문제가 발생할 수 있다는 점을 상기시켜야 했습니다. 

Postgres JSONB 열 유형

Postgres에서 JSONB는 읽기에 최적화된 형식으로 JSON을 저장할 수 있는 특수한 종류의 열입니다:

이 문서에 명시된 바와 같이 비디오를 사용하면 JSONB 열에 데이터를 저장하는 동안 약간의 성능 저하가 발생하며, 데이터베이스는 JSON을 구문 분석하여 읽기에 최적화된 형식으로 저장해야 하므로 이는 공정한 절충안으로 보입니다.

참고: Postgres 문서에서도 일반적으로 JSON 열 유형보다 JSONB를 선택해야 한다고 명시하고 있으므로 지금은 Postgres의 JSON 열을 무시하겠습니다.

이론적으로는 중첩된 모든 엔티티에 대해 JSONB 열을 사용하여 Postgres에서 문서 데이터베이스를 에뮬레이션할 수도 있습니다:

데이터 조작

여기서부터 정말 흥미로운 일이 시작됩니다: 우선, Postgres는 정확하게 SQL:2016 표준 (ISO/IEC 9075:2016). 이 사양의 쿼리는 쉽게 상당히 커질 수 있으므로 반드시 나쁜 것은 아니지만, 여전히 염두에 두어야 할 사항입니다.

제가 항상 표준을 강조하는 이유는 NoSQL 데이터베이스가 이전에도 이 길을 걸어왔고, 오늘날에는 수십 가지 언어가 있으며 한 NoSQL에서 다른 NoSQL로 마이그레이션하려는 경우 리팩터링에 상당한 투자가 필요하기 때문입니다. 

바라건대, SQL++ SQL의 아버지라 불리는 돈 체임벌린이 구출에 나섰습니다, 그것에 관한 책을 썼습니다. 를 소개한 바 있습니다. 이 세션에서는 Couchbase에서 사용하는 쿼리 언어인 N1QL이라는 SQL++의 구현과 Postgress JSON 함수 및 연산자를 비교해 보겠습니다.

삽입

삽입은 예상할 수 있는 것으로, Postgres의 구문과 N1QL의 주요 차이점은 전자의 경우 행의 몇 열에만 JSON 인코딩된 문자열이 포함되지만 후자의 경우 문서 전체가 JSON이라는 점입니다:

Postgres:

카우치베이스:

업데이트

아주 간단한 업데이트부터 시작하겠습니다.

Postgres:

Postgres의 구문에서 문자열은 큰따옴표와 작은따옴표('"CA"') 안에 지정해야 하며 리터럴은 작은따옴표('false' 또는 '123') 안에 지정해야 합니다. 

카우치베이스:

카우치베이스에는 테이블과 유사한 개념이 없으므로 "유형" 속성을 사용해야 하며, 이 경우 "사용자". 나머지 모든 쿼리는 표준 SQL과 유사하거나 Java 세계에서 온 경우 JPA JPQL과 거의 동일한 구문입니다.

집에 새 출입구를 추가하고 우편 번호를 업데이트하고 대상 사용자로부터 ADMIN 역할을 제거하는 좀 더 복잡한 예제를 시도해 보겠습니다:

Postgres:

JSON을 조작해야 하는 경우 Postgres 쿼리가 지나치게 복잡해질 수 있습니다. 경우에 따라서는 함수를 만들어야 합니다. 를 실행하는 데만 몇 가지 기본적인 업데이트가 필요합니다. 저에게 이것은 쿼리 언어에 여전히 개선이 필요하다는 신호입니다. 

카우치베이스:

N1QL에 익숙하지 않더라도 위의 쿼리에서 무슨 일이 일어나고 있는지 명확하게 이해할 수 있습니다. 배열을 처리하기 위한 수십 가지 함수.

SELECT

데이터 선택은 광범위한 주제이므로 세션을 나누어 살펴보겠습니다:

간단한 데이터 쿼리

Postgres:

마법 같은 @> 연산자를 사용하면 키-값 쌍이나 JSON 내부의 객체를 쉽게 일치시킬 수 있습니다. 실제로 이 연산자를 사용하면 JSON에서 항목을 일치시키는 것이 더 쉬워지지만 몇 가지 유의해야 할 사항이 있습니다:

•  운영자 @> 평등 비교만 지원
• 두 번째 쿼리에서는 뒷마당 를 입력했지만 실제 배열은 다음과 같습니다:

따라서 속성(이 첫 번째 경우에는 우편번호)을 검색할 때 @> 연산자는 다음과 같이 동작합니다. 같음와 같은 연산자를 사용하여 배열에서 검색하면 "포함".

카우치베이스:

Postgres의  @> 연산자와 N1QL의 키워드를 사용합니다. 위의 쿼리에서는 동일한 작업을 수행하기 위해 서로 다른 전략을 사용합니다. 매우 간단한 쿼리의 경우 Postgres의 구문이 더 짧지만, 두세 개의 속성으로 필터링하면 N1QL의 쿼리는 거의 동일한 크기를 갖습니다. 이 경우 모든 종류의 비교 연산자를 사용할 수도 있습니다.

한 가지 장점이라고 생각하는 것은 SQL++ 구문을 사용하는 쿼리 "SQL처럼 보이게" 의 SQL보다 더 많이 사용됩니다. 

개체 탐색

Postgres:

Postgres는 ->> 연산자를 사용하여 엔티티를 탐색하고 -> 를 사용하여 속성을 텍스트로 변환할 수 있습니다. 그러나 속성이 정수인 경우 id를 다시 정수로 변환해야 합니다.

카우치베이스:

위의 경우 ".'를 입력하면 적절한 유형이 자동으로 추론됩니다.

누락된/존재하는 속성 처리

Postgres:

Postgres는 누락된 값을 의미상 잘못된 NULL로 간주합니다:

• null이 포함된 JSON"랜덤 속성 이름'' :

• 누락된 "랜덤 속성 이름'' :

지금 당장은 큰 문제가 아닐 수도 있지만, 이러한 차별화는 스키마에서 발생할 수 있는 문제를 해결하거나 JSON 자체의 구조를 업그레이드해야 할 때 도움이 됩니다.

그리고 ? 연산자는 존재 여부와 속성을 확인할 수 있지만, 최상위 키와 함께만 사용할 수 있습니다. 문서.

카우치베이스:

N1QL에는 이미 이 시나리오에 적합한 구문이 있습니다:

또한 속성이 존재하는지 확인하는 구문 설탕도 있습니다("is not missing"와 동일):

색인 

데이터를 JSON으로 저장할 수 있는 데이터베이스는 일반적으로 어떤 종류의 스키마도 강제하지 않지만 스키마 유연성 지원을 추가할 때 내재적인 문제가 있습니다: 기본적으로 어떤 문서에 쿼리하려는 속성이 있는지조차 미리 알 수 없다는 것입니다.

이 문제는 적절한 인덱스를 생성하면 스캔하는 문서 수를 크게 줄이고 어떤 식으로든 정렬하여 목표 값을 더 쉽게 찾을 수 있기 때문에 빠르게 해결할 수 있습니다. 그러나 JSON을 다루기 때문에 인덱스는 중첩된 엔티티와 배열도 처리해야 하므로 복잡성이 상당히 추가됩니다.

물론 쿼리에 적합한 인덱스를 만드는 것 역시 약간의 고민이 필요한 작업입니다. 실제로 Couchbase 포럼에 올라온 질문 중 약 15%가 바로 이에 관한 것입니다. Couchbase 6.5에는 주어진 쿼리에 따라 인덱스를 제안하는 인덱서 추천 기능도 함께 제공됩니다:

Postgres:

JSONB 데이터에 대한 인덱스는 Postgres의 최신 기능 중 하나로, 이전 버전에 비해 쿼리 성능이 크게 향상되기 때문에 개발자들은 이 기능에 대해 매우 기대하고 있습니다. 기본 문서에 따르면, Postgres는 두 가지 유형의 인덱스를 지원합니다. jsonb_path_ops:

기본값

이 인덱스를 사용하면 최상위 키 존재 연산자 ?, ?& 및 ?| 연산자와 경로/값 존재 연산자 @>를 사용하여 쿼리를 사용할 수 있습니다. 또한 특정 필드를 색인화할 수도 있습니다:

GIN 인덱스의 경우 단일 필드만 지정할 수 있습니다.

jsonb_path_ops

기본값이 아닌 GIN 연산자 클래스 jsonb_path_ops는 @> 연산자 인덱싱만 지원합니다. 일반적으로 더 빠르고 작은 인덱스를 생성합니다. 사용자는 여기에서 자세히 알아보세요..

문서 업데이트: 

이 글에 댓글을 달아주신 Mark와 트위터의 @postgresmen은 BTrees 또는 GIST를 사용하여 여러 필드가 있는 인덱스를 만들 수 있다고 강조했습니다:

그런 다음 위의 인덱스를 다음 쿼리와 함께 사용할 수 있습니다:

위의 구문과 함께 부분 인덱스를 사용할 수도 있습니다:

그리고 공식 문서에는 JSONB 필드를 인덱싱하는 방법에 대한 설명이 2페이지에 불과합니다, 를 통해 특정 유형의 인덱스를 만드는 방법을 알아낼 수 있었습니다. JSONB 인덱싱 를 가져와야 합니다. 다음 버전의 Postgres에서 흥미로운 업데이트.

카우치베이스:

인덱스는 사실 Couchbase의 핵심이며, 현재 7가지 유형을 지원합니다:

• 기본 – 문서 키로 전체 버킷을 인덱싱합니다.
• 보조 – 키-값을 사용하여 스칼라, 객체 또는 배열을 인덱싱합니다.
• 컴포지트/커버 – 인덱스에 저장된 여러 필드
• 기능적 – 단순한 키-값 대신 함수 표현식을 허용하는 보조 인덱스
• 배열 – 일반 스칼라 값부터 복잡한 배열 또는 배열의 더 깊은 곳에 중첩된 JSON 객체까지 다양한 배열 요소의 인덱스입니다.
• 적응형 – 미리 정의할 필요 없이 문서의 전체 또는 일부 필드에 대한 보조 배열 인덱스입니다.
• 부분 색인 - 부분 색인 데이터의 하위 집합만 색인할 수 있습니다.

보시다시피, 인덱스는 Couchbase에서 상당히 성숙한 기능이며 Postgres JSONB에서 지원하는 것보다 훨씬 더 유연합니다. 이 글은 이미 상당히 길기 때문에 더 자세히 설명하지 않고, 개인적으로 정말 멋지다고 생각하는 두 가지를 강조하고 싶습니다: 커버된 부분 인덱스와 집계 푸시다운

커버되는 부분 색인 

전체와 부분의 조합을 사용하면 관심 있는 데이터의 하위 집합에 대해서만 인덱스를 만들 수 있습니다. 

EX: 온라인 게임이 있고 국가별 순위표를 표시해야 하는데 비활성 사용자나 10점 미만인 사용자는 무시한다고 가정해 보겠습니다. 플레이어 수가 10배 더 많은 중국을 제외한 모든 국가에서 리더보드 실적이 정상입니다. 이 경우 쿼리 속도를 개선하기 위해 특정 인덱스를 만들 수 있습니다:

이미 포인트가 정렬되어 있으므로 다음과 같은 쿼리는 매우 빠르게 처리될 것입니다:

총 푸시다운 집계

집계는 컬럼형이 아닌 저장소에서는 항상 어려운 작업이지만, Couchbase에서는 인덱스를 생성하여 집계를 더 빠르게 할 수 있습니다. 다음 예제를 살펴보겠습니다:

이 쿼리는 실행하는 데 약 90ms가 걸렸으며, 쿼리 계획은 다음과 같습니다:

이제 다음 인덱스를 만들어 보겠습니다:

동일한 쿼리를 다시 실행하면 약 7ms 이내에 실행되며, 새 쿼리 계획에는 '그룹' 단계가 없다는 점에 유의하세요:

다음을 수행할 수 있습니다. 여기에서 Couchbase 인덱스에 대해 자세히 알아보세요. 

참고travel-sample은 Couchbase를 설치할 때 로드할 수 있는 데모 데이터베이스 중 하나입니다.

성능

두 데이터베이스 모두 CP(일관성/파티션 허용)로 간주되지만, Postgres는 전통적인 마스터/슬레이브 RDBMS인 반면 Couchbase는 대규모의 빠른 읽기/쓰기 및 다음에 대한 추가 지원에 최적화되어 있습니다. 단조로운 원자 뷰

안타깝게도 온라인에 게시된 JSONB 벤치마크는 몇 가지에 불과하며, 가장 최근의 벤치마크에서 Postgres는 단일 노드 인스턴스의 경우 몽고보다 빠른 것으로 보고되었습니다. (여기에도). 결과는 매우 인상적이지만, 이러한 비교의 대부분은 일반적으로 RDBMS에 유리한 시나리오인 한두 개의 노드에 대해 이루어졌다는 점을 강조할 필요가 있습니다. 

여기서 Couchbase의 아키텍처를 강조하고 싶지는 않지만, 메모리 우선 데이터베이스이므로 데이터베이스가 요청을 수신하는 즉시 애플리케이션이 쓰기 성공 승인을 받은 다음 문서가 비동기적으로 복제되어 디스크에 기록됩니다(예, 승인을 받는 시점을 변경할 수도 있습니다). 

여기에 마스터리스 아키텍처(애플리케이션이 쓰기/읽기를 올바른 서버로 직접 전송), 훨씬 더 나은 인덱싱 지원, 높은 확장성(+100개 노드로 단일 CB 클러스터를 실행하는 클라이언트가 있음)이 있다는 사실을 더하면 어느 것이 규모에 따라 더 나은 성능을 제공할지는 분명하며, 문제는 단지 "얼마나"일 뿐입니다.

아직 Postgres 대 Couchbase 벤치마크가 없으니, 보고 싶으시면 다음 주소로 트윗해 주세요. @deniswsrosa. 그 동안 다음을 사용하여 두 가지의 성능을 간접적으로 비교할 수 있습니다. 카우치베이스/몽고/카산드라 벤치마크

결론

개발자들이 데이터를 JSON으로 저장하는 것의 이점을 더 잘 알게 되고 결과적으로 문서 데이터베이스도 더 많이 사용하게 될 것이기 때문에 Postgres의 JSON 지원 확대가 정말 기대됩니다.

시장의 많은 도구와 프레임워크가 이미 JSON 데이터에 대한 지원을 제공하고 있으며, Postgres JSONB의 채택이 증가함에 따라 표준 기능이 될 것입니다. NoSQL 데이터베이스.

그러나 Postgres JSONB에 뛰어들기 전에 몇 가지 유의해야 할 사항이 있습니다:

• 복잡한 쿼리 언어: 현재 JSONB의 쿼리 언어는 직관적이지 않으며, 문서를 읽은 후에도 쿼리에서 무슨 일이 일어나고 있는지 이해하기에는 여전히 약간 복잡합니다. PG 12에서는 이러한 문제 중 일부를 해결할 수 있습니다. JSON 경로 언어를 사용할 수 있지만 여전히 다른 언어와 SQL이 혼합된 것처럼 보일 것입니다. 저는 오히려 Postgres가 SQL++에 대한 지원을 추가하는 것을 보고 싶습니다.
• 제한된 쿼리 언어: 쿼리 언어가 복잡할 뿐만 아니라 아직은 부족합니다. 예를 들어, JSON 데이터를 조작하는 함수가 누락되어 있어 기본적인 배열 조작을 하기 위해서는 몇 가지 해결 방법을 사용해야 합니다. 매우 동적인 JSON이 있고 여러 가지 방법으로 쿼리해야 하는 경우 상황이 정말 어려워질 수 있습니다. 지금까지는 JSON과 관계형 데이터 사이의 다리를 구축하는 데 중점을 두었던 것 같습니다.
• 인덱싱: 새로운 인덱스 유형을 사용하면 쿼리가 이전보다 훨씬 더 빠르게 실행됩니다. BTree와 Gist를 추가로 사용하여 GIN에서 지원하지 않는 케이스를 처리할 수 있습니다.
• 얕은 문서: JSONB에 대해 설명하는 문서는 6페이지 정도에 불과합니다. 이 글을 쓰면서 배운 대부분의 내용은 시행착오, StackOverflow 질문, 블로그 게시물, 유튜브 프레젠테이션을 기반으로 한 것입니다. 
• 툴링: 글에서 언급하지는 않았지만, 다소 새로운 기능이기 때문에 당연히 일부 프레임워크/SDK에서는 아직 완전한 지원을 추가하지 않았습니다. SpringData를 예로 들어보겠습니다. 커뮤니티 노력 를 이미 사용 중이지만 완전히 매끄러운 경험은 아닙니다. 도중에 약간의 딸꾹질이 예상될 수 있습니다.

위의 문제 중 일부는 이미 알려진 문제이며, 이 문서에 링크된 몇 가지 강연/기사에서도 언급되어 있습니다. 가장 중요한 문제들은 이미 다음 Postgres 릴리즈의 로드맵에 포함되어 있습니다.

제가 본 대부분의 인기 프레젠테이션과 달리, 데이터를 쿼리하고 조작하는 것이 쉽지 않기 때문에 아직은 매우 역동적인 모델에는 적합하지 않다고 생각합니다.

Postgres JSONB는 어디에 적합할까요?

제 관점에서 몇 가지 문제를 지적했지만 가치 있는 기능이라고 생각하며 반드시 사용을 고려해야 한다고 생각합니다. 다음은 이 기능이 적합하다고 생각되는 몇 가지 시나리오입니다:

• CQRS/이벤트 소싱 고도의 트랜잭션이 필요한 시스템
• 메타데이터
• 일부 관련 엔터티를 JSONB로 저장하여 불필요한 조인 방지
• JSON으로 인코딩된 문자열을 저장해야 하지만 데이터를 자주 조작하거나 쿼리할 필요가 없는 경우.

위의 경우, 대규모 배포에서도 Postgres가 잘 작동합니다. GIN을 사용하면 인덱스가 약간 커질 수 있지만 여전히 관리하기 쉽습니다.

카우치베이스는 어디에 적합할까요?

저는 이미 4년 넘게 문서 데이터베이스를 성공적으로 사용해 왔고, 이 시점에서 약간 편견이 있을 수도 있지만, RDBMS를 대체하여 사용할 수 있는 시나리오는 생각보다 훨씬 더 많다고 생각합니다. 가장 유명한 사용 사례는 다음과 같습니다:

• 사용자 프로필 저장소;
• 제품 카탈로그/쇼핑 카트;
• 병력(헬스케어의 경우);
• 계약서, 보험 정책;
• 소셜 미디어;
• 게임;
• 캐싱;
• …

사실, 대부분의 시스템에서는 강력한 직렬화 가능 트랜잭션 트랜잭션이 전혀 지원되지 않는다는 뜻이 아니라 데이터베이스의 확장성을 손상시키지 않는 보다 완화된 버전일 뿐이며, 특히 Couchbase 6.5에서는 더욱 그렇습니다!

Couchbase CE와 EE는 대규모의 성능이 필요할 때 정말 빛을 발합니다. 3,5,10,50,100개의 노드로 클러스터를 쉽게 생성하면서도 우수한 성능과 강력한 일관성을 유지할 수 있기 때문에 현재 미션 크리티컬 애플리케이션을 위한 주요 선택 중 하나입니다. 시간이 있으시다면 공공 사용 사례.

수년에 걸친 이러한 모든 중요한 사용 사례 덕분에 N1QL과 인덱싱은 매우 견고하고 빠르며 유연해졌습니다. 그렇기 때문에 개발자들에게 초기 구현과 지금까지의 최상의 JSON 지원 간의 차이를 보여주는 데는 유효하지만, Postgres JSONB의 현재 상태를 고려할 때 불공정한 비교라고 생각하기도 합니다.

질문이나 의견이 있으시거나 제 의견에 완전히 동의하지 않으시면 언제든지 다음 주소로 트윗해 주세요. @deniswsrosa