[AI & Data] Database Architecture (데이터베이스 아키텍쳐)
포스트 난이도: HOO_Junior
# Database Architecture 란?
처음 Database architecture를 접했을 때의 느낌을 돌이켜보면 Database architecture는 그저 다가가기 어렵게 만드는 어려운 용어 중 하나일 뿐이었다. Database architecture 뿐만 아니라 다른 Computer science와 관련된 용어들과 마주치면 머리가 지끈지끈 아파올 수밖에 없다. 우리가 흔히 말하는 "용어"는 뜻을 살펴보고 한눈에 이해가 되어야 하는 게 아주 일반적인 상식이지만 사실상 개발자들이 사용하는 용어는 하나의 단어에 모든 개념과 사용 방법, 응용을 할 수 있는 이해력 등 하나의 단어의 의미를 나타내는 게 아니라 무한히 연결된 것 중의 한 요소이기 때문이다. 한마디로 Database architecture가 뭐야라고 했을 때 Database에 대한 전반적인 내용을 알아야 Database architecture를 제대로 이해할 수 있다는 것이다. 그래서 Database architecture는 DBMS를 근본적으로 구성하는 아케텍처를 의미한다.라는 용어의 뜻을 보더라도 "이게 무슨 그지 같은 소리야"라고 생각이 당연히 들 수밖에 없다. 결과적으로 내가 말하고 싶은 것은 Database architecture를 처음 배운다면 무서워하지 말라고 개발자 브로들에게 말해주고 싶었다.
Database architecture에서 데이터베이스와 아키텍쳐를 나눠서 생각해 보자. 아키텍처는 말 그대로 설계 또는 뼈대라고 생각해 보면 좋다. 음식을 만드는 데 있어서 주방 세팅이 먼저 되어야 하듯이 데이터베이스를 구성하는 데 있어서 아키텍처를 먼저 구성해 준다. 예를 들자면, 우리가 떡볶이를 만든다고 가정했을 때 부엌에 들어가서 우당탕당 거리며 떡볶이를 만드는데 필요한 도구와 주방 기구들을 살펴보면서 요리를 할 수는 있다. 안 써본 주방 기구를 쓰다가 음식이 타버리거나 어떻게 사용하는지 모르는 도구를 만지다가 다치면서 결과적으로 떡볶이를 만들 수 있긴 하다. 데이터베이스도 마찬가지이다. 처음 설계 없이 그냥 쿼리에 데이터를 넣어주고 DBMS에 로컬 서버인지 클라우드 서버인지 시도해 보다가 사용자가 누구인지 알아보고 다시 처음부터 만들고를 반복하다 보면 수십 년에 걸쳐서 아주 간단한 데이터베이스 짜잔 하고 만들어질지도 모른다.
한마디로 Database architecture는 데이터베이스를 실제로 하나하나 만들어나가기 전에 어떤 구조로 만들 것이고 어떤 요소들이 해당 데이터베이스에 필요한지를 "설계"하는 것이라고 생각하면 된다. 그 중에서도 하나하나 모든 설명이 들어간 가이드라인이라기보다는 큰 뼈대, 즉 요리로 비교하면 사용하는 주방 도구, 재료 등을 알려주는 "준비물 설명서"라고 생각할 수 있다.
# Type of Database Architecture
Database architecture는 크게 분산형과 집중형 아키텍쳐로 나눠서 살펴볼 수 있다. 아마 이에 대한 개념적 설명 Junior 브로들이기 때문에 어느 정도 알 것이라고 생각하고 생략하겠다. (개념을 잘 모르면 Chatgpt에게 물어보면 된다.) 여기서 중요한 건 두 아키텍처 타입의 개념적 설명이 아니라 실질적으로 어떻게 사용되는지에 대해서 잘 모르기에 개념만 알고 이해가 되지 않을 수 있다는 것이다.
우선 집중형은 말 그대로 하나의 데이터베이스에 모든 데이터를 저장하고 관리하는 방식이다. 아주 typical하고 traditional 한 방식으로 현재도 사실 많은 데이터베이스는 중앙집중식 관리가 이뤄진다.
분산형 데이터베이스는 여러 장소와 시스템에 데이터가 나눠서 저장이 되고 관리가 된다. 여기서 "여러 장소"는 물리적으로 다른 국가나 지역을 의미할 수 있지만 바로 옆에 있는 서버가 저장해도 분산형 데이터베이스일 수 있다. 이게 무슨 말이냐면 분산형을 할 때 여러 요인들 중에서 보완과 유지관리에 좋다는 장점이 있는데, 인간의 관점에서 다른 지역에 데이터베이스를 관리하는 게 해당 장점에 충족된다고 생각할 수 있다. 반면에 컴퓨터 관점에서 보면 사람이 생각하는 물리적 거리와 상관없이 바로 아래층에 있는 서버에 데이터를 분리해서 관리한다면 이 마저도 보완과 유지관리에 도움이 된다는 것이다.
따라서 Database architecture 타입을 이해하기 쉽게 집중형, 분산형 이렇게 나뉘어서 배우고 있지만 사실상 두개 타입을 각기 다르게 사용하기보다는 합쳐서 사용하는 방식을 많이 쓰고 있다. 예를 들어서 글로벌 기업의 경우 각 나라별로 데이터를 관리하는 서버를 두고 있으면서도 결과적으로 중앙에서 관리할 수 있는 서버를 별도로 두어 보완과 유지관리 효율성을 높이는 것이다.
한마디로 내가 말하고자 하는 바는 Database architecture 타입을 배울때 분산형과 집중형을 각기 다르게 생각하지는 말라는 것이다. 마치 영어단어에서 "go"가 "가다"라는 의미가 있다고 무조건 가다고만 억지로 끼어넣어서 해석하지 말라는 것이다.
# Database Layers or Tiers
Database architecture를 구성하는 중요한 이유 중 하나는 복잡한 데이터베이스 구조를 단순하게 살펴보고 적용하기 위해서라고 생각한다. 잠깐 옆길로 빠지자면, 데이터의 사용이 우리가 생각하는 것보다 많은 일상에 영향을 끼치고 작은 데이터 하나가 실제로 많은 결과의 차이를 발생시킨다. 우리가 흔히 "나비효과"라는 말이 있는데 데이터에 있어서는 그냥 말이 아니라 진짜 데이터의 하나가 모든 결과를 달리 만들 수 있다. 그렇기에 데이터 보안이나 신뢰에 대한 문제가 점차적으로 대두되고 있고 이에 따라 Database architecture는 보다 더 복잡해지고 여러 단계를 거치는 구성이 이뤄진다.
자 다시 본론으로 돌아와서 데이터베이스의 레이어 또는 티어라고 하면 각 단계별 어떤 연결 구조를 가지고 있는지를 나타낸다. 한마디로 데이터를 송수신하는데 있어서 데이터베이스까지의 경로를 어떻게 지정하고 관리할 것인지를 의미한다. 당연히 시퀀스로 나타내다 보니 상하관계처럼 보인다고 생각하면 이해하기가 훨씬 수월하다. 처음 배울 때 One-tier부터 Three-tier까지 배우지만 사실상 실제로 사용하는 건 Three-tier 이상의 레이어 또는 티어를 가지고 있다고 보면 된다. 여기서 티어나 레이어도 어렵게 생각하지 말고 데이터가 사용자로부터 서버까지 오는 데 있어서 들리는 정거장이라고 이해하면 된다.
# 쿼리는 코드인가요?
쿼리, SQL 등을 코드라고 오해할 수 있는데 코드가 아니라 그냥 텍스트라고 생각하면 된다. 구체적으로 말하자면 쿼리에 쓰는 텍스트는 데이터를 저장하고 관리하는데 있어서 구성을 어떻게 할 것인지를 개발자들이 보기 편하게 보여주는 데이터 구성에 대한 구조이자 실제 메타데이터들이 보관되어 있는 특정한 그룹 또는 묶음이라고 생각하면 된다.
SQL은 Strucutred Query Language의 줄임말로 쿼리를 어떻게 만들것인지를 컴퓨터에게 알려주기 위한 목적의 텍스트인 셈이다. 굳이 따지자면 SQL은 우리가 domain-specific language라고 부르면 일반적으로 말하는 "코드"에 해당하는 general-purpose programming language인 파이썬이나 자바 등과는 다르다.