전문가칼럼

DBMS, DB 구축 절차, 빅데이터 기술 칼럼, 사례연구 및 세미나 자료를 소개합니다.

이병국의 개발자를 위한 DB 이야기(30회) : DB 엔지니어의 가볍게 읽는 세상 이야기

전문가칼럼
DBMS별 분류
DB일반
작성자
dataonair
작성일
2016-08-08 00:00
조회
9144




◎ 연재기사 ◎


물탱크 구조로 알아본 오라클의 블록 옵션 ‘PCTFREE와 PCTUSED’


이산가족 찾기 생방송을 통해 배우는 DB 원리


개발자에게 맞는 DB 공부방법 찾기: 물리적 분류와 논리적 분류 그리고 인덱스


데이터베이스 인덱스의 오해와 진실


쉬운 것이 올바른 것이다. ‘인덱스 끝장리뷰’ (상)


쉬운 것이 올바른 것이다. ‘인덱스 끝장리뷰’ (하)


누구도 알려주지 않았던 ‘오라클 인덱스 생성도’의 비밀


누구도 알려주지 않았던 ‘오라클 쿼리 작성의 비법’


퀴리 최적화 및 튜닝을 위한 오라클 공정쿼리 작성법


만능 쿼리와 한 방 쿼리


오라클 옵티마이저 ‘CBO와 RBO’ 이해하기


재미있는 DB 이야기 ‘60갑자와 쿼리’


그림으로 배우는 ‘오라클 조인의 방식’ 이야기


반드시 알아야 하는 오라클 힌트절 7가지


오라클 플랜을 보는 법


개발자들의 영원한 숙제 ‘NULL 이야기’


알면 유용한 오라클 기능 ‘GATHER_PLAN_STATISTICS’


알면 유용한 오라클 기능들


오라클 DICTIONARY를 활용한 DB툴 프로그램 ‘FreeSQL’


이제는 말할 수 있다: 주식 자동매매 프로그램(상)


이제는 말할 수 있다: 주식 자동매매 프로그램(하)


개발자들이 자주 접하는 오라클 에러 메세지


재미있는 DB 이야기 ‘사라진 날짜를 찾아라’


오라클 랜덤 함수와 사용자 정의 함수


그림으로 배우는 ‘공정쿼리와 인덱스 생성도’


이병국의 개발자를 위한 DB 이야기: 디폴트 세팅의 함정과 오라클 파라미터


재미있는 DB 이야기 ‘놀라운 마방진의 세계’


오라클 운반 최소 단위 BLOCK


이병국의 개발자를 위한 DB 이야기: 이세돌과 알파고의 세기의 대결


이병국의 개발자를 위한 DB 이야기(30회) : DB 엔지니어의 가볍게 읽는 세상 이야기


이병국의 개발자를 위한 DB 이야기: 튜닝(31회) : 개발자를 위한 DB 튜닝 실전(1편)


이병국의 개발자를 위한 DB 이야기: 튜닝(32회) : 개발자를 위한 튜닝 실전(2편)


이병국의 개발자를 위한 DB 이야기: 튜닝(33회) : 개발자를 위한 튜닝 실전(3편)


이병국의 개발자를 위한 DB 이야기: 튜닝(34회) : 개발자를 위한 DB 튜닝 실전(4편)


이병국의 개발자를 위한 DB 이야기: 튜닝(35회) : 개발자를 위한 튜닝 실전(5편)


이병국의 개발자를 위한 DB 이야기: 페이징 처리에 대한 이해 (36회)


보기 좋은 떡이 먹기도 좋다 - 좋은 쿼리 좋은 성능


테이블의 수직분할과 수평분할에 대한 이해


DB 성능 제고를 위한 채번의 이해와 방식별 장단점 비교


이병국의 개발자를 위한 DB 이야기: 마지막회 : ‘개발자를 위한 DB 이야기’ 연재를 마치며



이병국의 개발자를 위한 DB 이야기(30회)

DB 엔지니어의 가볍게 읽는 세상 이야기



성공과 실패의 경험을 나누자, 용기와 희망을 나누자

개발업무를 시작으로 IT계에 입문했던 필자가 10년 가까이 DB엔지니어로서 활동하면서 얻은 경험과 지식을 나누고자 한다. DB를 자주 접하는 SW 개발자뿐 아니라, DB 전문가를 꿈꾸는 대학생에서DB 분야에 입문한지 1~2년 된 기입문자가 쉽게 이해할 수 있도록 비유를 통해 쉽게 접근해볼 계획이다. 물론 전문가들이라도 다시 한번 개념을 정립하는 의미에서 필요한 내용이 될 수 있다.

전체적으로 DB의 기본 원리와 개념을 이해하고 테이블, 인덱스, 쿼리, 튜닝, 플랜 등 개발자들이 알아야 하는 DB 전분야에 대해 쉽게 이해하도록 설명하겠다. DB 기술서적이나 번역서보다는 조금 더 부드럽게 접근할 계획이다. 그렇다고 흔히 서점에서 만날 수 있는 개발자 위주의 SQL 소개서도 아니다. 이 연재는 시리즈로 나갈 것이다. 연재를 끝까지 읽는 독자라면 준전문가 수준의 DB 원리를 아는 것을 목표로 한다.



‘옥뮤다’ 택배 실종사건

버뮤다 삼각지대는 ‘마의 바다’라고 불리는 곳이다. 이곳은 버뮤다 제도와 플로리다와 푸에르토리코를 잇는 삼각형의 해역을 의미한다. 배와 비행기가 흔적도 없이 사라지는 바다다. 지금까지 수많은 배와 비행기가 사라졌다. 전 세계 미스터리 실종 사건 중에서 상당수가 이곳에서 발생하였다.

최근 미국의 해양 지질학자인 메키버 박사는 이러한 원인이 해저에 있는 메탄가스 때문이라고 주장한다. 깊은 바닷속에 있는 엄청난 양의 메탄가스가 갑자기 떠오르면 지나가는 배들이 부력을 잃고 갑자기 가라 앉기 때문이라고 한다. 또한 비행기의 통풍구로 흡입된 메탄가스가 폭발을 일으켜서 사라지게 만든다는 이야기다.

최근 우리나라에도 이러한 버뮤다 삼각지대가 있다는 주장을 하는 인터넷 커뮤니티가 있다. 택배 물건이 옥천 허브에 가기만 하면 빠져 나오지 못하는 것을 빗대어 ‘옥뮤다’에 갇혔다고 한다. 금방 도착할 물건도 배달이 늦어져서 찾아보면 옥천에 있다든지, 심지어 서울에서 서울로 부친 택배 물건도 옥천에서 대기 중이라는 것이다. 우스갯소리 같지만 실제로 필자도 이런 일을 여러 번 겪어봐서 충분히 공감이 간다.

그러면 이러한 일들은 왜 발생하는 것일까 바로 옥천이 지리적으로 우리나라의 중심에 있다는 이유 때문이다. 더군다나 토지 가격이 대도시에 비해 상대적으로 저렴하기 때문이다. 택배 회사 입장에서는 지리적인 이점에다가 비용적인 측면을 고려한다면 최고의 택배 물류지로 옥천만한 데가 없다. 우리나라의 택배 회사들은 대부분 이러한 ‘허브앤스포크(Hub & Spoke)’라는 택배 시스템을 구축하고 있다.

세계적으로 유명한 최고의 물류 회사인 ‘페덱스(FedEx)’가 이러한 물류 방식을 적용하였다. 페덱스 이전에는 주로 포인트 투 포인트(Point to Point) 방식으로 배달되었다. 이는 배송하려는 두 지역을 최대한 단거리로 이동하는 방식이었다. 페덱스는 이러한 포인트 투 포인트 배송 방식에서 허브, 즉 중심지의 개념을 도입했다.

column_img_2482.jpg

[그림 1] 허브앤스포크 방식의 배송

페덱스의 창업자인 프레드릭 스미스가 평소 즐겨 타던 자전거 바퀴에서 영감을 얻은 것으로 알려진 허브앤스포크 방식에서 허브는 자전거 바퀴를 의미하며, 스포크는 바퀴살을 의미한다. 이런 아이디어는 항공 화물운송이 대중화되지 않은 당시 매우 획기적인 것이었다. 하지만 기존의 운송 체계인 포인트 투 포인트 방식에 익숙해진 사람들은 허브앤스포크 방식을 선뜻 잘 이해하지 못했다. 인천에서 가까운 서울로 부치는 화물을 굳이 멀리 떨어져있는 옥천으로 보낸다면 여러분은 그것을 이해할 수 있을까 어느 누구라도 이해할 수 없을 것이다. 이러한 허브앤스포크 배송으로 인하여 옥뮤다라는 용어도 생겨났다.

인접한 스포크 간의 배송은 허브를 거치지 않는 것이 더 큰 이익이다. 허브앤스포크 운송 방식은 비록 이처럼 단점도 있지만 운송비 절감과 운송의 효율화가 분명하므로 현재 전세계적인 물류 방식으로 통용되고 있다. 지점에서 발생하는 물량들을 중심지(허브)로 집결시키고 다시 지점(스포크)으로 분류하여 배송시키는 허브앤스포크 방식에서 제일 중요한 것은 바로 물량이다. 물량이 대규모로 확보될수록 이 배송 방식의 장점은 커질 것이다. 반대로 대규모의 물량이 확보되지 않는다면 이러한 방식은 장점보다 단점이 많은 비효율적인 운송 방식이 될 것이다. 결국 관건은 물동량이 규모의 경제가 되느냐 마느냐이다.

현재 우리나라 택배 회사 가운데 압도적인 시장 점유율을 확보한 곳은 없다. 물량을 비슷하게 나누어 가졌기 때문에 물동량의 크기가 규모의 경제를 이룰 만큼 충분치 않다. 또한 대부분의 회사가 옥천과 같은 소규모 도시를 기반으로 하나의 허브에 여러 개의 스포크를 구성하였다. 국가차원에서 본다면 중복 투자로 인하여 비효율적인 운송 방식을 갖춘 것이다.

앞으로 옥뮤다라는 용어를 없애기 위해서는 물류 회사 간 전략적 제휴나 인수 합병을 통해 지역별 거점 허브를 구축하는 노력이 필요하지 싶다. 이러한 노력을 하지 않는 한 옥뮤다라는 용어는 결코 사라지지 않을 것이다. 그 불편함은 고스란히 고객에게 돌아 올 것이며 경제적인 손실은 택배 업에 종사하는 근로자에게 전가될 것이기 때문이다. 필자가 희망하는 허브앤스포크의 구성은 아래와 같다.

column_img_2483.jpg

[그림 2] 개선된 허브앤스포크 방식의 배송

아무리 좋은 배송 시스템도 규모의 경제가 이루어지지 않으면, 즉 물량이 많지 않으면 오히려 역효과를 낼 수도 있다. 이러한 경우는 DB에서도 많이 경험된다. 규모에 상관없이 모든 테이블에 반드시 인덱스가 있어야만 한다고 주장한다든지 혹은 테이블 Full scan이 발생하므로 반드시 튜닝을 해야 한다고 주장하는 경우가 그럴 수 있다. 이런 주장들은 어느 일정 수준 이상의 규모에서만 의미를 찾을 수 있다.



두 번째 버스를 타자

지금 사는 곳에서 회사에 가려면, 버스를 타고 양재역에 가서 지하철을 타야 한다. 매일 반복되는 왕복 3시간의 출퇴근 시간은 아무리 젊더라도 체력적인 부담이 없지 않을 것이다. 더군다나 나는 20~30대의 젊음을 가진 것도 아니고 체력도 강한 편이 아니다. 매번 버스에 앉아서 가면 좋겠지만 현실은 그렇지 않다. 운이 좋은 날은 앉아서 가기도 하지만 서서 가는 날이 더 많다. 이러한 상황에서 나만의 방법을 찾았다. 급한 날은 먼저 오는 버스를 타야지만, 급하지 않는 날은 두 번째 버스를 탔다. 두 번째 버스를 타는 날엔 대부분 편하게 앉을 수 있었다.

column_img_2484.jpg

[그림 3] 버스 운행 간격에 따른 좌석 확보의 용이성

[그림 3]에서 오랜 기다림 끝에 오는 첫 번째(1) 버스는 항상 많은 사람들로 붐빈다. 하지만 두 번째(2) 버스는 승객들이 그리 많지 않아서 편하게 이용할 수 있다. 이러한 정보들은 요즘 널리 사용되는 버스정보 앱을 이용하면 충분히 알 수 있다.

대부분의 버스 회사들은 배차 간격을 균등하게 두고 버스 간 간격을 일정 수준으로 유지하려 하지만 서울의 교통 상황상 쉽지 않는 것이 현실이다. 대부분 첫 번째 버스는 운전 경력이 별로 없는 초보 운전사일 가능성이 높다. 혹은 승객의 안전을 위해서 승하차 시간을 충분히 제공하는 꽤 괜찮은 운전사일 경우도 있다. 이러한 경우는 현실적인 경험이지만 필자는 DB 환경에서도 이와 유사한 경험을 종종 하기도 한다.

column_img_2485.jpg

[그림 4] 배치 수행 순서에 따른 수행 시간 차이

[그림 4]에서 배치1, 2, 3, 4, 5는 동일한 대용량 주문 테이블을 Full Scan하여 정보를 구성하는 배치 프로그램이라 하자. 이러한 경우 배치1번과 배치4번은 매우 느린 수행 결과를 보여주지만, 배치2번, 배치3번, 배치5번은 빠른 시간 내에 수행을 마칠 것이다. 이와 같은 이유는 무엇일까 선행 배치는 많은 I/O 부담을 안는 반면, 메모리에 적재한 데이터의 후행 배치는 I/O 부담 없이 활용만 하면 되기 때문이다. 만약 배치 개발자가 서로 다른 경우라면 여러분은 자기가 만든 배치가 어떤 순서에 있어야만 좋은지 판단할 수 있다. 그것이 관리자로부터 문책을 피할 수 있는 하나의 방법 이기도 하다(^^).



인간의 계산 방식 vs. 기계의 계산 방식

아래의 [문제 1]과 [문제 2]의 정답은 같을까, 다를까

[문제 1]: 1/2 + 1/3 + 1/4 + 1/5 + 1/6 + 1/7 + 1/8 + 1/9
[문제 2]: 1/9 + 1/8 + 1/7 + 1/6 + 1/5 + 1/4 + 1/3 +1/2

이러한 문제를 접했을 때 인간의 계산력은 상상을 초월한다. 초등학생이라도 수초 이내에 같다라는 답을 한다. 이것이 인간의 능력인지 자만인지 잘 모르겠다. 왜냐하면 위와 같은 문제를 실제로 풀어서 정답을 비교해 본 사람은 인류 역사에 단 한 명도 없기 때문이다. 나누어 떨어지는 숫자가 아니기 때문에 무한의 시간을 사용해도 결코 답을 구할 수 없는 문제다. 하지만 세상의 모든 인간들은 위 문제의 정답이 동일하다고 이야기할 것이다. 이것이 가능한 이유는 계산의 결과가 아니라 판단의 결과이기 때문이다.

그렇다면 인간이 아닌 기계가 이 문제를 푼다면 어떤 결과를 내 놓을까 현재 우리들이 사용중인 DB 혹은 프로그램 언어들은 위 문제의 정답은 ‘서로 다르다’고 결정할 가능성이 높다. 왜냐하면 기계는 사람과 달리 판단하지 않고 계산하기 때문이다. 여기서 우리는 인간과 기계의 계산 방식의 차이에 대해서 이해할 필요가 있다.

column_img_2486.jpg

[그림 5] 인간의 계산 방식과 기계의 계산 방식

인간의 계산 방식은 계산이라기보다는 전체적인 수식의 이해와 판단에 따른 것이다. 반면 기계의 계산 방식은 실제 계산에 의한 것으로서 수식의 순서가 매우 중요한 의미를 지닌다. 미리 정의된 규칙에 따라서 지정된 자릿수만큼만 계산하고, 그 자릿수를 초과하는 Overflow 부분은 Round 처리되므로 수식의 순서에 따라서 그 결과가 달라질 여지가 충분히 있을 수 있다.

이러한 일련의 과정을 이해해야만 오라클 DB나 프로그램의 계산식에서 다른 결과 값의 원인을 찾는 데 도움이 된다. 인간의 잣대로 기계의 계산 능력을 무시하여서도 안되지만 그렇다고 맹신하여서도 안 될 것이다.

이번 연재는 DB와는 약간은 동떨어진 이야기다. 그렇다고 전혀 무관한 내용도 아니다. 단지 가끔씩은 주제를 벗어나서 이야기하고 싶었으며, 여러분들도 부담 없이 읽었으면 좋겠다고 생각했다. 다음 연재부터는 수회에 걸쳐서 필자가 경험한 튜닝 사례들에 대해서 이야기할 것이다. 대부분의 튜닝 사례들은 반복된다. 필자만이 경험한 특별한 내용이 아니라, 여러분들도 언젠가는 충분히 경험할 내용이라고 판단되는 사례들로만 모아 소개해 볼 생각이다. (다음 회에 계속)



[지난 문제의 정답과 풀이]원리를 이해하고 논리로 풀어가는, 쉬어가는 DB 문제

지난 연재에 출제한 ‘원리를 이해하고 논리로 풀어가는, 쉬어가는 DB 문제’에 대한 정답과 해설은 아래와 같다. 문제를 풀면서 DB 원리를 하나씩 배우고 이해할 수 있다.



column_img_2487.jpg

[이번 호 문제]원리를 이해하고 논리로 풀어가는, 쉬어가는 DB 문제

각 연재의 말미에 간단하면서도 재미있고 생각해 보는 문제를 출제하려 한다. 모든 문제는 DB의 원리를 이해할 수 있는 문제로 출제할 예정이다. 문제를 풀면서 DB 원리를 하나씩 배우고 이해할 수 있다. 정답과 그에 대한 설명은 다음 연재에서 한다.

column_img_2488.jpg