SQL 이해해보기 #01 - 데이터베이스와 테이블 이해하기

앞에서 데이터베이스에 대해서는 최대한 얘기 안 하고 쿼리에만 집중하겠다고 했었지만, 막상 데이터베이스에서 시작을 안 하면 쿼리에 대해 설명을 하긴 어려울 듯 해서 데이터베이스 부터 우선 언급을 하려 한다. 

데이터베이스라는 것은 기술적으로 접근하면 꽤 실체를 만나기 어려운 뒷 부분에 존재 한다고 볼 수도 있지만, 혹시나 자영업 또는 알바 경험을 통해서 무언가를 팔거나 빌려주는 일을 해보았다면 외부에서도 쉽게 만나 볼 수도 있을 형태의 흔한 개념일 수도 있다고 생각한다. 

꽤 오래전의 일이긴 하지만, 요즘은 많이 없어진 한 때 붐이였던 책 대여점 알바를 한 적이 있었다. 아는 사람을 돕는 일이 여서 처음 대여점을 차리는 것부터 시작해서 얼마간 운영했던 기억이 있다. 아마 더 옛날이라면 만화방(요즘의 만화 카페)에서 책을 빌려줄 때 장부에 항목을 적어서 빌려 주고, 반납하면 해당 항목을 줄을 그어 지우는 가게들도 많이 있었다(요즘도 만화 카페 운영 프로그램에서 따로 지원하지 않는 이상 아직도 그렇게 아날로그로 운영 하는 경우도 있을 거라고 본다). 

책 대여점의 경우는 주 업무가 사람이 와서 보는 만화 카페와는 다르게 책을 빌려주고 받아서 수익을 내는 부분이기 때문에 아무래도 장부에 적어서 해당 일을 하기에는 몇 천권이 되는 책을 빌려주고 돌려받기엔 효율이 나오기 힘들었다. 게다가 미 반납 시의 연체료 등 세세한 것까지 종이 장부에 적어가면서 운영했다면 아마 해당 대여점 체인들이 그렇게 발달하지 못했을 것이다(그래서 가끔은 어떤 분야는 기술이 꼭 뒷 받침을 해줘야 비로서 꽃을 피우는 것 같다).

때마침 컴퓨터 하드웨어 가격도 가게에서 살 수 있을 만큼 어느 정도 보급형으로 가격이 내려온 상태라서, 책 대여점을 차리는 사람을 타겟으로 책 대여 프로그램을 만들어 파는 사람이나 업체들이 생기게 되었다. 우리나라에 ISBN 코드가 도입이 막 되던 시점 이였기 때문에 지금같이 공공 API를 지원하지는 않았을 것 같고(게다가 그 때는 거의 인터넷이 없이 돌아가는 프로그램 들이라서 아마 공공 API를 호출해 정보를 업데이트 한다는 것을 생각도 못했을 때였을 거 같다), 만화책의 경우 해당 ISBN이 없는 해적 판도 종종 있는 상황이였기 때문에 자동화를 향한 과정은 꽤 힘든 일이였다. 

우선 프로그램 회사에서 준 바코드를 책에 붙이고 스캔 하면, 해당 바코드를 키로 가진 책 정보 등록 메뉴가 나오는데, 거기에 제목부터 종류, 대여 가격 등 필요한 정보들을 새로운 책이 생길 때마다 반복해 작업 해야 했다. 또한 새로운 고객이 오면 회원 정보 메뉴를 열어서 이름, 전화번호 등 주요한 정보들을 등록해야 했고 말이다(이 번거로움은 지금도 거의 비슷해 보이고, 그래서 명시적인 형태를 줄인 카카오톡 인증을 통한 가입 같은 게 생겼을 테고 말이다). 뭐 지금 바라보면 아까운 시간이라고 생각되겠지만, 그 시절을 미화하자면 지금 시대의 데이터 라벨링이나 업무 정보를 데이터화 하는 작업과 비슷하게, 효율적인 자동화 인프라 구축을 위한 필수적인 일이였다고 볼 수 있다.

이후 해당 고객이 방문하게 되면, 이름을 물어 회원을 찾고, 이후 대여 버튼을 누르고, 바코드를 스캔을 하면 해당 손님이 대여한 책으로 등록 되고, 반납할 때도 비슷하게 진행 했다. 예전에 종이 장부에서 일일이 오래된 날짜를 찾아서 전화를 걸어 독촉하고 연체료를 찾는 일도, 알아서 연체된 책들을 보여주고 연체료도 계산해 주는 기능도 있었다. 

위의 얘기를 듣게 되면 데이터베이스를 경험해보고 사용해 본 사람들은 데이터베이스 내에 있는 관련 테이블들이 그려지고, 책 정보를 입력을 하거나 수정하는 부분, 삭제하는 부분, 전체 회원 목록을 보는 부분, 해당 회원이 대여한 책들을 표시하는 부분, 연체가 된 책들을 보여주고 연체료를 계산 하는 부분 등이 머리 속에 대충 그려 질 것이다. 위의 책 대여 프로그램이 어찌보면 현대의 데이터베이스의 초기 모형을 이용해 만들어진 데이터베이스 기반의 프로그램이라고 볼 수 있다. 

물론 요즘 이런 프로그램을 만든다면 데이터를 어떻게 효율적이게 저장할 지에 대해 스스로 코드를 짤 일은 아마 없을 거고, 상황에 따라 파일 또는 서버 형태의 오픈소스 데이터베이스를 하나 살짝 넣어서 호출하는 프로그램만 개발해서 제공할 것이다. 실상 현실의 많은 상용 솔루션들도 도입 비용 등을 낮추는 등 여러 목적을 위해서 여러 오픈소스 데이터베이스를 기반으로 구현하는 경우도 많은 편이다(물론 상용 데이터베이스도 같이 지원하거나 성능이나 폐쇄적 보안 등의 특수한 이유로 자체 데이터베이스를 구현하거나 오픈소스를 기반으로 수정 개발해 사용하는 경우도 있다).

---

그럼 (관계형) 데이터베이스는 앞에 얘기했던 책이나 회원, 대여 상황, 대여 금액 등에 대한 정보들을 어디에 저장하게 될까? 그 장소가 데이터베이스 책을 처음 펴게 되면 아마 맨 처음에 나오게 될 테이블(Table)이라고 보면 된다. 영어를 쓰는 서구권 사람들 입장에서는 많은 기술적인 언어들이 영어로 이루어진 단어나 문법을 기반으로 일반 문장과 비슷한 흐름을 가지도록 만들어져 있다. 그래서 하나 하나의 용어를 무작정 외우는 것 보다는 이유가 있는 네이밍을 한 경우도 많을 것이므로 해당 추상적인 부분을 상상하게 익히는 것도 나쁘진 않아 보인다. 

데이터베이스에서 쓰는 테이블이라는 개념은 우리가 일상에서 자주 보는 무언가를 올려 놓는 물리적인 개념의 테이블은 아니고, 가상의 데이터를 올려놓는 "Time Table(시간표)" 같은 표현에서 쓰는 "표" 라는 의미를 가지고 있다. 현재 비즈니스 쪽에서도 많이 사용하는 데이터 시각화 도구인 태블로(Tableau)도 이 계열 뜻을 표현한다고 볼 수 있다.



한번 컴퓨터가 없을 때 우리가 앞에서 얘기한 일들을 어떻게 수행 했을지 상상해 보자. 아까 장부 얘기가 나왔지만 장부는 일종의 데이터 요소들을 정리해 한눈에 정리해 보고 상황을 파악하고 업데이트 하기 위한 표의 일종이라고 볼 수 있다. Table 의 어원을 찾아보면 평평한 상 위에 체크 무늬 천을 깔고 거기에 물건을 구분하여 넣어서 계산을 해서 표의 의미도 가지게 되었다고 한다. 

어찌 보면 시각화 된 추상화라고도 볼 수 있는데 우리가 또 흔히 볼 수 있는 컴퓨터 내의 프로그램과 비교해 본다면 컬럼(column)과 로우(row)로 이루어진 작은 칸으로 가득 찬 사각형의 엑셀과 비슷하다. 엑셀도 장부처럼 생긴 네모난 테이블이 하나의 시트를 이루어 여러 개의 시트로 구성되어 있기 때문에, 데이터베이스와 모양이 비슷하다. 물론 기능의 완전한 대체라든지, 사용의 효율성에 대해서는 별개의 문제이긴 하지만, 두 개 다 기본적으로는 데이터를 표 형태로 효율적으로 다루고자 하는 서로 다른 방향의 시도인 것은 맞긴 하다. 또한 엑셀은 항상 눈으로 보면서 계산 및 시각화를 하는 데에 강력한 장점을 가져서 시각 적으로 보며 추상화를 하며 비교적 친숙하게 쓸 수 있지만, 데이터베이스는 직접 조회해 샘플 데이터를 보거나, 테이블의 구조를 살펴 보기 전에는 안의 모양을 알 수 없기 때문에 좀 더 추상적인 접근이 필요 할 수 있다.

다만 머리 꼬리를 떼고 생각한다면, 여러 개의 데이터를 분류해 담는데 필요한 테이블 들(RDB 에서는 아래 그림과 다르게 사각형이긴 하다)을 그리고, 각 테이블 들을 독립적이거나 또는 서로 연결하면서 의미 있는 정보 구조를 추출해서 사용하는 것이 관계형 데이터베이스의 전부라고 봐도 될 듯 싶다. 나머지는 그걸 잘 하게 만들어 주는 여러가지 도움 기능이라고 보자. 

[시간표 만들기]

데이터베이스의 테이블 들은 자꾸 살펴 보다 보면 머리 속에 대충 관계가 정리가 되어 그려지게 되지만, 현실에서의 문제는 저런 테이블이 작은 회사의 경우는 수 백 개부터, 큰 회사의 경우는 수천, 수 만개 까지 늘어날 수 있게 된다는 부분이다. 회사의 대부분의 비즈니스 정보가 저 안에 들어가기 때문에, 회사 내의 데이터 전체를 유기적으로 이해할 수 있는 사람은 보통 손에 꼽을 정도라고 생각한다. 

게다가 저 부분을 잘 이해하려면 데이터베이스 안의 테이블들 만을 이해해야 하는 게 아니라, 그 데이터를 넣어주는 프로그램 로직이 왜 그런 형태로 데이터를 넣는 지를 이해해야 하는 경우도 많기 때문에, 데이터베이스의 테이블과 컬럼(뭐 물론 프로시저나 함수, 뷰 등의 다른 이해에 필요한 요소들도 많겠지만 일단 이렇게 단순화 하자)및 그 연관 관계를 모두 이해했다는 것은 회사의 비즈니스의 흐름을 이해했다는 것과 비슷하게 되기 때문이다. 그래서 비즈니스와 어플리케이션의 로직을 이해 못한 채 데이터베이스 만을 보게 된다면 데이터 자체는 볼 수 있지만 그 의미를 알지 못하는 난감한 상황도 생길 수 있다(이게 개발자들이 어느 정도 데이터베이스를 이해하면 좋듯이, 데이터베이스를 다루는 사람이 어느 정도 해당 데이터베이스를 사용하는 프로그램 측면을 이해하면 좋은 하나의 이유라고 생각한다. 데이터베이스에 쌓이는 데이터는 두 개의 오케스트레이션의 결과 같은 거라고 보기 때문이다.).

그래서 우리가 살펴 보려는 SQL 은 저 수많은 데이터들을 테이블을 이용해 구조적으로 담고 종횡무진 연결하면서 우리의 비즈니스에 필요한 여러 값들을 적절하게 조회해 와서 사람이나 프로그램들이 사용하게 해준다. 그러다 보니 상황에 따라 엄청 복잡해 보이고 이해하기 힘든 쿼리 들을 보는 일도 있게 되겠지만, 개인적으로는 테이블들의 역할 및 관계만 잘 이해하고 있다면 엄청 암호와 같이 복잡한 엑셀 셀의 셀 번호와 함수들이 섞인 정의를 보는 것보다는 해석하기 쉽다고 생각한다. 그래서 작은 규모의 테이블들과 연관된 쿼리부터 하나하나 이해해 가다 보면 어느새 꽤 익숙해진 자신의 모습을 발견할 수 있게 될 것이다. 또한 일반적인 프로그래밍 언어 보다는 자유도가 많이 작기 때문에, 그렇게 광활한 세상에서 헤맬 필요도 없다(SQL 만 보는 목표로 한다는 가정을 하면 오픈 월드 게임과 일반적인 게임의 차이 정도라고 본다).

그럼 데이터베이스가 어떤 것이고, 데이터를 담는 테이블이 왜 필요한 지에 대해서 공감이 갔기를 바라며 다음 글에서는 좀 더 실제 적인 얘기를 해보려 한다.

- Fin -