전문가칼럼

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

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

전문가칼럼
DBMS별 분류
Oracle
작성자
dataonair
작성일
2014-08-06 00:00
조회
19519




◎ 연재기사 ◎


물탱크 구조로 알아본 오라클의 블록 옵션 ‘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 이야기: 워밍업 (2회)

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



이병국 andongcn@dreamwiz.com 프리랜서 DB 엔지니어로서 동아제약 전산실에서 SW 개발 업무를 시작으로 프리랜서 개발자로 독립해 활동하던 중 우연한 기회에 DB와 인연을 맺게 됐다. 현재 삼성생명 전산 운영팀에서 쿼리 성능을 개선하는 DB 튜닝과 IOA 업무를 맡고 있다. 개발자 출신의 DB 엔지니어로 활동하면서 개발자에게 DB 관련 지식이 꼭 필요함을 절감했다. ‘정보의 불균형이 시장 왜곡을 가져온다’는 ‘레몬시장이론’은 중고차 거래에서 흔히 나타나기 쉽다. 좋은 차와 나쁜 차를 아는 중개인과 모르는 구매자 사이에는 정보의 비대칭 때문에 구매자가 손해를 볼 수 있다. 구매자도 차에 대해 기본적인 지식을 알고 있어야, 정보의 균형이 맞으므로 서로 손해를 보지 않고 합리적인 가격에 차를 거래할 수 있다. 마찬가지로 개발자들도 DB에 대해 기본적인 지식을 습득하여 정보의 균형을 맞추면, DB 엔지니어와 협업이 더 쉬워지고 한 단계 더 발전한 자신의 모습을 발견할 것이다.



성공과 실패의 경험을 나누자, 용기와 희망을 나누자
개발업무를 시작으로 IT계에 입문했던 필자가 10년 가까이 DB 엔지니어로서 활동하면서
얻은 경험과 지식을 나누고자 한다.
DB를 자주 접하는 SW 개발자뿐 아니라, DB 전문가를 꿈꾸는 대학생에서 DB 분야에 입문한 지
1~2년 된 기 입문자가 쉽게 이해할 수 있도록 비유를 통해 쉽게 접근해볼 계획이다.
물론 전문가들이라도 다시 한번 개념을 정립하는 의미에서 필요한 내용이 될 수 있다.
전체적으로 DB의 기본 원리와 개념을 이해하고 테이블, 인덱스, 쿼리, 튜닝, 플랜 등
개발자들이 알아야 하는 DB 전분야에 대해 쉽게 이해하도록 설명하겠다.
DB 기술서적이나 번역서보다는 조금 더 부드럽게 접근할 계획이다.
그렇다고 흔히 서점에서 만날 수 있는 개발자 위주의 SQL 소개서도 아니다.
이 연재는 시리즈로 나갈 것이다. 연재를 끝까지 읽는 독자라면,
준전문가만큼 DB의 원리를 아는 것을 목표로 한다.

이번 회에 소개할 내용은 분류에 관한 것이다. 일상 생활에서의 분류의 의미를 이해하고 이후 DB의 많은 부분에서 활용되고 있는 분류에 대해서 설명할 것이다.



KBS 이산가족 찾기 생방송

40대 전후의 세대라면, 지난 1983년 6월 30일부터 11월 14일까지 136일간 온 국민을 울렸던 KBS ‘이산가족 찾기’ 생방송을 기억할 것이다. 한국전쟁, 그 민족상잔의 와중에 헤어졌던 부모, 형제, 친척을 찾는 사람들의 안타까운 사연은 전국민을 TV 앞에 끌어들이며 78%라는 최고 시청률을 기록하기도 하였다. 벽보는 빗물에 젖고 사연은 눈물에 젖고 이산 33년 뜨거운 재회의 감격에 국민 모두가 눈물을 닦았다.

여의도광장에는 수많은 이산가족들이 모여 들었다. 가족을 찾는 벽보는 KBS 본관 주변을 뒤덮고 여의도광장으로 펼쳐져 나갔다. 사연을 적은 종이를 들고 온종일 광장을 헤매며 돌아 다녔고 밤을 지새웠다. 결국 1만여 명의 이산가족이 상봉의 기쁨을 누렸다.

당시 중학교 2학년이었던 필자는 약간 슬프다는 느낌, 딱 그 정도였다. 그러면서 그때 생각했던 것은 여의도광장이 엄청 넓고 사람도 매우 많은데 사람 찾기가 엄청 힘들겠구나! 이산가족을 출신 지역별로 구역을 나누면 좀 더 쉽게 찾지 않을까! 하는 생각을 했다.

column_img_1325.jpg

그림 1. 구역 미지정에 따른 여의도광장의 혼잡성

<그림 1>처럼 구역이 나눠지지 않은 상태의 여의도광장에서 수만 명의 사람들이 헤어진 가족을 서로 찾는다면 얼마나 힘든지 미루어 짐작할 수 있다. 하지만 출신 지역별로 구역을 나눠서 찾는다면, 자신의 고향 구역에서만 찾으면 되므로 좀더 수월해질 것이다. 물론 행정 구역을 시군 단위로 더 세분화하면 찾기는 더욱 쉬워진다.

column_img_1326.jpg

그림 2. 구역을 지정해 여의도광장의 세분화한 후 모습

당시 여의도는 <그림 1>의 상황이었는지 <그림 2>의 상황이었는지는 필자로서는 알 수 없다. 여기서 말하려는 내용은 분류가 얼마나 중요한가이다. 설사 <그림 1>의 상황이었어도 분류 전문가가 없었던 그때의 시대 상황을 탓하고 싶지는 않다. 여의도광장에 모이게 한 그 자체만으로도 최소한의 분류는 된 상태였으므로. 그렇지 않았다면 이산가족들은 전국을 헤매고 다니면서 찾아야만 했을 것이다.



대형 할인매장의 상술

물건이나 대상의 분류는 특별한 상황이나 특정한 곳에서만 이뤄지는 것은 아니다. 우리 생활 대부분에 분류가 있다. 대형 할인매장을 예로 들어 보자. 대부분의 대형 할인매장은 가전제품, 생활용품, 식품류 등 큰 구역으로 나누어져 있다. 식품 구역에 가면 식품 종류에 따라 다시 소구역으로 나누어져 있다. 우유제품 소구역에 가면, 브랜드별로 더 작은 구역으로 나누어져 있다. 그럼 여기서 분류는 끝일까 아니다. 동일한 회사의 우유제품이라도 유통기한이 며칠 남지 않은 우유는 앞쪽에 진열되어 있을 것이고, 유통기한이 많이 남은 우유는 뒤쪽에 진열되어 있을 것이다.

유통기한이 짧게 남은 우유가 앞에 진열돼 있다는 것을 아는 주부들은 뒤쪽의 우유를 고를 것이다. 분류 마지막 단계에서 대형 할인매장의 상술()이 작용하며 잘못된 분류가 발생했으나 현명한 주부들은 분류의 마지막을 잘 마무리 한다.

column_img_1327.jpg

그림 3. 대형 할인매장의 매장 분류

<그림 3>처럼 분류가 잘된 대형 할인점에는 전체적인 구역을 총괄하는 분류 관리자가 있을 것이고, 구역별 분류를 담당하는 중간관리자가 있을 것이다. 거기다 우유 제품만을 분류하는 직원도 있을 것이다. 이에 따른 인력 운용비도 적지 않을 것이다.

그럼 왜 상품 분류에 이처럼 많은 인력을 투입할까 만약 대형 할인점에 있는 모든 제품이 분류되지 않은 채 뒤죽박죽으로 진열돼 있다면 어떻게 될까 아마 수많은 고객들의 방문으로 인하여 혼란스러워질 것이다. 원하는 물건을 찾지 못하여 고객들이 매장에 머무르는 시간이 늘어나면서 주차장도 혼란스러워질 것이며, 더 나아가 주변 도로교통까지 영향을 미칠 것이다. 결국 고객 불만으로 이어지면서 줄어드는 매출은 분류에 따른 인건비를 뛰어넘을 것이다.

분류는 무엇인가 분류는 동일한 속성들로 묶는 것이다. 한 가지 속성만으로 분류할 수도 있고, 여러 속성(대분류, 중분류, 소분류)으로 분류할 수도 있다. 분류는 왜 하는가 빨리 찾기 위해서다. 헤어졌던 가족을 빨리 찾을 수 있고, 상품도 빨리 찾을 수 있다.

빨리 찾는 이유는 효율, 즉 비용을 줄이기 위해서다. 비용을 줄인다는 의미는 시간을 줄였고, 경비를 줄였고, 노동을 줄였다는 의미와 같다. 결국 시간과 경비와 노동을 줄였으니 이익인 것이다. 분류는 우리에게 이익을 가져다 준다. 손해 보는 분류는 없다.



도둑은 분류를 좋아한다

우리의 생활에는 늘 분류가 있다. 군대에서는 군인들의 분류가 있고, 시골 조그마한 가게에는 가게 할머니의 분류가 있고, 들판에는 농부들의 분류가들은 퇴근하고 집에 가면 잘 분류된 주부의 분류를 볼 것이다. 서재에는 책들이 있고, 냉장고에는 음식이 있고, 장롱에는 옷과 이불이 있고, 패물함에는 보석이 있다.

잠깐 쓰레기 분리수거 하고 왔을 뿐인데 순식간에 도둑을 맞는 경우가 있다고 한다. 분류를 너무 잘해 놓아서 도둑이 보석함만 들고 간 것이다. 어떤 주부들은 보석을 냉장고에 보관해서 도둑 맞지 않음을 자랑하는 경우도 있다. 분류는 빨리 찾기 위함인데 오히려 분류를 하지 않아서 도둑이 보석을 못 찾은 경우다. 그렇다고 분류를 하지 않아도 된다는 말은 아니다. 분류를 하지 않으므로 해서 도둑을 예방할 것이 아니라, 자물쇠를 하나 더 달아서 예방하거나 잠깐 자리 비우더라도 문을 잠그는 습관으로 해결해야 할 것이다.



동물 세계 개미에게도 분류는 있다

분류는 인간 세계에만 있지 않다. 동물 세계에서도 얼마든지 분류의 예를 찾을 수 있다. 너구리는 자기만의 화장실을 가지고 있어서 아무데나 배설하지 않는다고 한다. <그림 4>처럼 개미에게도 분류는 있다. 개미는 여왕개미방, 먹이방, 번데기방, 알방 등 많은 방으로 분류해 관리한다. 심지어 동료 개미의 시체를 보관하는 시체방도 있다고 한다.

column_img_1328.jpg

그림 4. 개미집 구조

분류는 과거에도 있었고 미래에도 있을 것이다. 분류는 인류 역사와 함께 늘 존재했다. 중요한 곳에도 분류가 있고, 아무리 하찮은 곳에도 분류는 있다. 심지어 쓰레기도 분리해 재활용한다.

지금까지 분류에 대해 몇 페이지를 할애해 설명하였다. 그 이유는 DB에 분류가 있기 때문이다. 독자 여러분은 분류에 대해 얼마만큼 중요하게 생각할지 모르지만, 필자는 ‘세상의 시작이요 끝’이라고 생각한다. 결국 분류란 DB의 시작이며, 끝이고, 부분이며 전체다. 분류는 DB의 많은 부분에서 활용되고 있다. 그럼 DB의 어떤 부분에서 분류가 사용되고 있을까

용기를 갖자

오라클 DB뿐 아니라 대부분의 DB 구성 알고리즘은 어느 날 ‘하늘에서 뚝 떨어져 새로 만들어진 것’이 아니라 실생활에서 이용되는 혹은 이미 상식 수준에서 인지되는 그런 보편적인 원리를 바탕으로 만들어졌으므로 쉽게 접근하고 이해할 수 있다. 서두에서 말했듯이 ‘레몬시장이론’을 상기하며 DB를 지레짐작으로 어려워하지 말고 용기를 내고 하나씩 터득해 나가기를 바란다.
이 글은 DB 전문가 수준의 이해를 요구하지는 않는다. 단지 DB에 대해서 더 친숙하고 더 쉽게 이해하고 접근하길 바랄 뿐이다. 이 글을 읽으면서 궁금하거나 의문 나는 점이 있으면, 댓글을 달아주실 것을 적극 바란다. 아무리 어렵고 힘든 일이더라고 ‘관계’와 ‘소통’으로 풀어나갈 수 있음을 다시 한 번 믿으며…. (다음 회에 계속)