데이터이야기

DB 노하우, 데이터직무, 다양한 인터뷰를 만나보세요.

단무지 시즌 IV: 단무지의 운영 DB 이야기(6회) : 배움이 켜켜이 쌓여 이뤄지는 실력, 일일점검 실전(4)

데이터 이야기
작성자
dataonair
작성일
2017-01-23 00:00
조회
3398


단무지 시즌 IV: 단무지의 운영 DB 이야기(6회)

배움이 켜켜이 쌓여 이뤄지는 실력, 일일점검 실전(4)



[필자 소개] 서윤식은 외환신용카드에서 DBA 12년, 현대하이카다이렉트에서 DA로 10년을 일했다. 금융권 데이터 분야에서 22년간을 보내며, DBMS 운영 및 튜닝, SQL 튜닝, 데이터 모델링, 데이터 품질관리 영역 등 DB 전 영역을 고루 경험하였다. 이학사(전자계산학과), 경영학 석사를 거쳐 2015년 8월 IT 정책경영학과 박사과정을 수료하였다. 그리고 2016년 3월부터 데이터와사람들의 대표로 있으며, 한국데이터진흥원의 산업체 전문강사로서 데이터 모델링 및 SQL 튜닝 강의를 하고 있다. 또한 ‘데이터와사람들(http://cafe.naver.com/dbstudydapsqlp)’이라는 네이버 카페를 운영하면서 데이터 영역의 지식이 필요한 사람들과 다양한 방법으로 소통하고 있다.



단무지는 커다란 호랑이와 마주 보고 있다. 예전에는 호환마마가 가장 무서운 것이라 했던가 우리 어릴 때만해도 우는 어린아이에게는 ‘호랑이 왔다’라고 겁을 주면 아이의 울음이 뚝 그치곤 했다. 그만큼 무서운 존재가 호랑이였으나, 호랑이와 마주보고 서 있는 단무지는 전혀 무섭다는 생각이 들지 않았다. 호랑이는 그 늠름한 카리스마를 뽐내며, 단무지를 지긋이 바라보고 있다. 호랑이의 눈빛에선 왠지 단무지를 보호하고 있음을 읽을 수 있을 것만 같았다. 단무지는 왠지 올라타고 싶어졌다. 그 생각이 그치기도 전에 단무지는 몸을 솟구쳐 올라 호랑이의 등에 냉큼 올라탔다. 그러자 호랑이는 몸을 움직여 내 달리기 시작했다. 이상스럽게도 단무지의 몸은 전혀 흔들림이 없었다. 호랑이가 자신의 등에 올라탄 단무지를 보호하듯 조심스럽게 그리고 빠르게 달리고 있었다. 니가 떠나면 남겨진 내가, 눈물로 수없이 많은 밤을 지샐 거라~~ 난 괜찮아, 난 괜찮아~~ 멜로디와 함께 익숙한 노래 가사가 흘러 나온다. 호랑이의 달리는 리듬과도 같이 굉장히 빠른 속도의 노래가 경쾌하게 흘러 나온다. 단무지는 노래소리가 점점 크게 들려올수록 호랑이가 멀리 사라지는 것 같다. 그리고 이내 눈을 떴다. 참 신기한 꿈이다. 처음이다. 꿈에 호랑이가 나온 것도, 그 등에 올라 탄 것도 처음 있는 꿈이다. 아~~~차~~~ 오늘은 한지아를 만나기로 한 날이다. 토요일 여유 부리며 늦잠을 자고 있던 단무지로서는 시간이 다급했다. 부랴부랴 일어나 씻고 밖으로 나와 약속 장소로 차를 몰았다. 오늘은 서울 근교 강화도로 드라이브를 하기로 했다. 단무지와 한지아는 강화도로 가는 차에 앉아 있다. 한지아가 싸온 과일을 먹으며 이런 저런 이야기를 하고 있다. 한지아가 뜬금없이 DB와 관련된 질문을 했다.



한지아: 오빠, DA라고 했지단무지: 어. DA를 시작한지 7~8년 정도 됐지한지아: 그래 그럼 SQL 튜닝도 좀 해단무지: DA라면 당연히 SQL 튜닝은 기본이지한지아: 오~~~ 정말… 대단한데단무지: 하하~~~ 뭐 대단할 것 까지야… 직무가 그것이다 보니 하하.한지아: 그럼 오빠는 인덱스가 뭐라 생각해단무지: 정렬!!한지아: 그게 무슨 소리야단무지: 인덱스는 정렬이야. 인덱스라고 말 하기만 하면 정렬! 이렇게 정렬적으로 답해야 해.한지아: 그러니까 그게 무슨 소리냐고요단무지: 인덱스는 루트, 브랜치, 리프 노드로 되어 있고, 인덱스 키 값 순으로 리프 노드가 정렬되어 있어.
SQL은 정렬의 원리를 지켜주도록 작성하면 인덱스를 잘 사용할 수 있으고,
그 정렬의 원칙을 위배하는 순간 자신을 이용하지 못하도록 한단 말이지.한지아: 오~~~ 그래 왠지 멋있어 보이는데.단무지: 난 원래 멋져… 크크큭한지아: 오빠, 난 자바 개발자라 그런지 SQL이 굉장히 어려워.
그래서 말인데 SQL 튜닝을 좀 공부해 보고 싶은데, SQL 튜닝을 가장 빠르게 배울 수 있는 방법이 뭐가 있을까단무지: 훌륭한 스승을 만나는 거지.한지아: 그럼 오빠가 내 스승이 되어 줄 수 있어단무지: 공짜로한지아: 어~~ 나한테도 돈 받으려고단무지: 돈 받는 단 말 안 했다.한지아: 그럼 뭐단무지: 진도부터 나가자.한지아: 그래. 나 공부 가르쳐 주면서 진도 나가면… 응 으이구 이 웬수~~단무지: 뭔 생각하는 거야한지아: 아~~ 됐고! 뭐 좋은 책이라도 있어단무지: 있쥐.한지아: 먼데 단무지: [오라클 성능 고도화 원리와 해법] 1권부터 순서대로 2권까지 읽어. 그럼 돼한지아: 아~ 이냥반이!!! 누굴 호구로 아나단무지: 하하하… 알고 있었어한지아: 그 책 디따 어렵단 말야. 읽어도 뭔 소리인지 당최 알 수가 없어.단무지: 하하하… 그 책을 공부하는 방법을 몰라서 그래.
그 책은 1권의 1장이 가장 어려워. 그 책을 1권 1장부터 읽다가 포기한 영혼들이 엄청 많지. 하하한지아: 그니까. 어떻게 공부해야 되냐고요단무지: 공짜로한지아: 참눼… 알았다 알았어. 내가 뽀뽀 한번 해 줄게. 단무지: 내가 알려주는 정보의 가치가 더 고급인데.한지아: 아~~~ 싫으면 말든가.단무지: 아~~~ 아니야 싫기는 누가 싫데. 하하하



단무지는 이어서 계속 이야기 한다.



단무지: 그 책은 2권부터 읽을 것을 권한단 말이지. 1권은 DBA들이 읽을 수 있는 내용이며,
DBA들도 처음 읽을 때는 무슨 소리인지 알 수 없어. 특히나 개발자들은 더 알 수 없는 내용이지.
그러니 개발자들은 2권의 1장과 2장을 반복적으로 읽으면 좋아.
그리고 처음 읽을 때는 무슨 소리인지 알 수 없으니, 이해가 안 가도 그냥 넘어가.
그리고 다시 읽으면 조금씩 안개가 걷히듯 좋아질 거야.한지아: 그래도 너무 힘들 것 같은데.단무지: 그러니까 내가 훌륭한 스승이 필요하다 했잖아. 기본적인 것을 배우고 읽어야 재미가 있는 것이라니까.한지아: 그럼 나한테 좀 알려 줄 수 있어단무지: 당연하지. 니가 알려 달라고 하면 뭐든지 다할 수 있지, 나야.한지아: 그런데 공짜여야 한다. 알았지단무지: 하하 알았어.



호랑이의 답변

단무지가 월요일 아침 출근하기가 바쁘게 부장의 호출이 있었다. IT 기획팀과 인프라를 담당하는 운영팀 사무실은 5층이고, 개발팀 사무실은 6층이다. 부장은 기획팀과 운영팀이 있는 5층에 있기에, 단무지는 5층 사무실로 갔다. 부장 자리의 옆 소파에는 이미 IT 기획팀장과 운영팀장이 앉아 있었다.



IT 부장: 어~~ 어서 와, 단 팀장. 단무지: 네, 부장님.IT 부장: 어. 세 팀장이 다 모여 있으니 기쁜 소식을 빨리 이야기해야지.세 팀장: …IT 부장: 어. IT 기획팀장은 좀 알고 있겠지만, 회사에서는 그동안 우리 부서를 본부로
승격시키는 것을 검토하고 있었어. 그리고 지난주 금요일 내부적으로 결정이 났어.
우리 부서가 IT 본부로 승격을 하고, 여기 있는 3개의 팀이 모두 부서로 승격하는 것으로 말야.
그리고 3명의 팀장이 모두 부장으로 발령 받기로 했어. 기획팀장과 운영팀장은 차장에서
부장으로 승진 발령과 함께 부서장이 되기로 했어. 그리고 단 팀장은 아직 과장이라
많은 고민을 했는데. 차장 승진과 함께 부서장을 맡기기로 했어.
차장이 부서장 역할을 맡는 경우는 흔한 일은 아니긴 한데,
그래도 없던 일도 아니고 내가 보기에도 단 팀장이 적임자라고 생각해서 추천했어.
그리고 그대로 결정이 났고 말야.
오늘 저녁에 조직개편 및 인사발령이 날 거야. 그렇게 알 어떻게 나눌지 알려 줘.세 팀장: 넵, 알겠습니다. 축하드립니다. 본부장님.IT 부장: 하하, 자네들도 축하하네. 3명의 부장님들… 하하하.
그리고 오늘 저녁 인사발령이 나면 나랑 같이 저녁이나 하자고.
과장에서 바로 부장으로 호칭이 바뀌는 단 팀장이 오늘 더 많이 마셔야 할거야.단무지: 넵, 알겠습니다. 오늘 먹고 죽어보겠습니다.IT 부장: 하하하~~~ 그래. 오늘은 한번 달려 보자고. 하하아… 토요일 아침 호랑이 꿈을 꾸더니 오늘과 같이 좋은 일이 있으려 그랬던가 하하



RAC 각 노드별 적정 세션 연결 여부

단무지는 부장이 전해준 희소식을 뒤로하고, 또 다시 머나먼과 함께 머리를 맞대고 앉아 있었다.



머나먼: 팀장님. 오늘은 RAC 관련해서 설명해 주셔야 합니다.단무지: 그렇지. 일단 노드(Node)별 적정 세션 연결 여부를 말 하기 전에 먼저 RAC의 특징을 이해해야 해.
RAC는 서버 2대 이상이 동일한 디스크에 존재하는 데이터베이스를 서로 공유하여 서비스하고 있지.
데이터베이스에서 ‘공유’라는 이야기가 나오는 순간 생각해야 할 것은 ‘경합’을 떠올려야 해.
공유는 동시에 특정 자원에 변경을 막기 위해 직렬화 장치(Lock 또는 Latch)가 필요하며,
직렬화 장치에 의해 경합이 발생하는 것이거든. 따라서 그 경합을 방지하도록 설계하는 것이 중요하지. 특정 블록을 먼저 읽은 RAC 노드(서버)가 마스터 노드가 되는데, 오라클은 데이터 변경이
디스크가 아닌 메모리에서 발생하며, 상대편 노드에서 변경이 읽어 나려면 마스터 노드에
최신 본을 확인해야 하며, 이는 다양한 오라클 알고리즘에 의해 주기적으로 마스터와
슬레이브 노드 사이에 통신을 시도해야 하지. 이러한 통신을 Cache Fusion이라 하는데,
Cache Fusion이 많이 발생하면 할수록 DBMS는 스트레스를 받게 되어 있어.
심지어 Cache Fusion이 과도하게 발생하면, RAC Node간 Heart Beat
(서로 상대편 노드가 정상적인지 확인하기 위해 주기적으로 확인하는 신호) 체크에
문제가 발생하여, 두 노드가 모두 다운되는 Split Brain 현상이 발생하기까지 한다는 거야. 따라서 RAC를 설계할 때는 각 노드간 별도의 업무를 수행하도록 설계하는 것이 매우 중요해.
즉 2 Node RAC라고 가정해 보자고. 1번 노드에 A라는 업무 서비스를 하도록,
2번 노드는 B라는 업무를 서비스 하도록 설정하는 것이 일반적이야.
만약 2번 노드가 장애가 발생하여 서버 다운이 발생할 경우 1번 노드가 A와 B 업무 모두를
서비스하도록 하며, 1번 노드에 장애가 발생하면 반대의 경우로 서비스가 정상적으로 작동하도록 말이야.그래서 애플리케이션 서버는 자기에게 할당된 DB 서버에 접속을 해야 해.
예를 들면 A업무를 하는 애플리케이션 서버(주로 WAS 서버)는 RAC 1번 노드에 접속을 하고,
B업무를 하는 애플리케이션 서버는 RAC 2번 노드에 접속을 하도록 설정이 되었다고 가정하자고.
그런데 뭔가에서 잘못되어 A업무를 하는 서버가 RAC 2번 노드와 1번 노드에 분산되어 접속되었다면,
어떤 일이 발생할까 개발자와 사용자는 아무 문제가 없다고 판단할 거야.
서비스는 정상적으로 이루어 지고 있거든. 하지만 RAC 각 노드간에는 엄청난 문제가 발생하게 되는 거지.
A업무가 RAC 1번과 2번 노드에서 서로 동일한 데이터베이스 블록을 접근하면서
엄청난 Cache Fusion 현상을 일으키고 있을 것이거든.따라서 DBA는 애플리케이션 서버가 적정 RAC 노드에 접속되어 있는지 매일 점검을 해야 하는 거지.
점검하는 SQL은 다음과 같아.
select *
from (
select (select instance_name from v$instance) instance_name,
USERNAME, machine, program, count(*) cnt
from v$session
where username is not null
and username not in ('SYS', 'SYSTEM')
group by USERNAME, machine, program
UNION ALL
SELECT '1.5--------', '--------', '--------', '--------', NULL FROM DUAL
union all
select (select instance_name from v$instance) instance_name,
USERNAME, machine, program, count(*)
from v$session@상대편_노트의_DBLink명
where username is not null
and username not in ('SYS', 'SYSTEM')
group by USERNAME, machine, program
)
order by instance_name, cnt desc머나먼: 아~~~ 네, 팀장님. RAC 구성에 대한 부분과 Cache Fusion에 대해서도 이해를 했습니다.
WAS 서버에서 업무별로 적정 RAC Node로 접속하도록 설정이 돼 있을 텐데요.
WAS에서 기동되는 A라는 업무는 1번 RAC 노드, B라는 업무는 2번 RAC 노드로 접속될 수
있도록 말이죠. 그런데요, 팀장님. 그렇게 설정되어 있는데, 왜 자기의 노드가 아닌 다른 노드로 접속이 될까요
그게 좀 이해가 안 됩니다.단무지: 참 좋은 질문이야. 평상시에는 정상적으로 접속이 되겠지. 하지만 IT 시스템은
서버, 네트워크, 각종 SW 솔루션들로 매우 복잡 다양하게 연결된 시스템이야.
만약 RAC 1번 노드로 가는 네트워크가 아주 잠시 단절되었다고 생각해 보자고.
물론 네트워크의 장애로 말이야. 그렇다면 WAS 서버에서 RAC 1번 노드로 접속하려 했으나,
실패했으므로 2번 노드로 접속을 하겠지. 그리고 네트워크는 5분 이내로 정상 복구되었다고 가정하자고.
네트워크가 정상이 되었을 경우는 후속 세션들은 WAS에 설정되어 있는 정상적인 RAC 1번 노드로 접속하겠지만,
네트워크 장애 시 접속했던 RAC 2번 노드의 세션은 계속 살아 있게 되는 거야.
각 세션들이 동일한 데이터베이스 블록을 접속하려 할 때 Cache Fusion이 발생하겠지.
방금 이야기한 것은 아주 단적인 예일 뿐이고. 굉장히 복잡하고 다양한 사유로 다른 RAC 노드로
접속하는 경우가 종종 있어. 물론 자주 있는 것은 아니지. 그럼 이런 현상이 발생할 확률이 높을 때가 언제일까머나먼: 아~~~ 글쎄요. 제가 생각하기에는 평상시에는 그럴 일이 많이 있지는 않을 것 같습니다.
방금 팀장님이 말씀하셨던 장애가 아니고서야….단무지: 맞아. 평상시에는 거의 발생하지 않아. 하지만 방금 이야기했듯이 장애가 발생했을 경우,
그리고 필요에 의해 IT 장비 또는 SW에 어떤 작업을 하고 난 경우에 많이 발생해.
그러니 IT 관련 시스템에 작업이 진행되고 난다면 그 다음날은 꽤나 유심히 챙겨봐야 하지.
물론 일일점검 시에도 빠짐없이 봐야 할 항목이지만….



Snapshot 점검

머나먼: 아~~ 네. 알겠습니다, 팀장님. 그리고 오늘은 일일점검 항목 하나만 더 알려 주시죠.단무지: 참네… 오늘은 이정도로 마치려고 했더니만. 이거 배우는 사람이 더 적극적이니…
하하. 그래 다음에 봐야 할 항목이 뭐지머나먼: 넵, 팀장님. 다음은 snapshot 오브젝트에 대해 이야기해 주시면 됩니다.단무지: 그래. snapshot 기능은 특정 테이블을 복제할 때 왕왕 사용하는 기법인데 말야.
서로 다른 DBMS 간 데이터를 복제할 경우에 자주 사용하는 방식이야. snapshot 방식에 대해
이야기해 보자고. snapshot을 만들면 source 테이블에 “MLOG$_Source 테이블명” 이라는
테이블이 만들어지게 되어 있어. 그리고 Source 테이블에 변경이 일어나면 변경된 내용들이
신규로 만들어진 테이블에 저장되지. 그리고 Target이 되는 snapshot 테이블에 데이터를
저장하면 MLOG$ 테이블의 데이터가 삭제되는 방식이야. 다음의 스크립트를 보면 이해하기 쉬울 거야.
/* 기존 YOON.TEST 테이블에 SNAPSHOT LOG 생성 (MLOG$_원천테이블명 생성) */
CREATE SNAPSHOT LOG ON YOON.TEST_SRC;/* 복제 테이블인 YOON.TEST_REP 만들기 */
CREATE SNAPSHOT YOON.TEST_REP
TABLESPACE 테이블스페이스명 NOLOGGING
USING INDEX TABLESPACE 테이블스페이스명
REFRESH FAST START WITH SYSDATE NEXT SYSDATE + 1/24
AS
SELECT * FROM YOON.TEST_SRC ;
위의 예에서 복제 테이블인 YOON.TEST_REP는 READ ONLY 기능인 테이블이야.
마치 Materialized view와 비슷한 개념이야. 머나먼: 아~~ 상황에 따라 아주 유용하게 활용할 수 있을 것 같은 기능인데요.단무지: 그렇지. 하지만 유용하지만 관리상의 문제가 있을 수도 있어.
만약 소스 테이블인 TEST_SRC 테이블이 1000만 건의 데이터가 있고,
신규로 SNAPSHOT 테이블인 TEST_REP를 만든다고 가정해 보자고.
그렇다면 MLOG$_TEST_SRC 테이블에 기존 소스 테이블의 건수만큼(천만 건)의
데이터가 발생하고, TEST_REP 테이블이 만들어 지는 순간
MLOG$_TEST_SRC 테이블의 데이터는 모두 삭제가 될 거야.처음 만들 때 시간이 많이 소요되겠지. 그건 문제가 되지 않아.
문제는 MLOG$_TEST_SRC가 1000만 건의 데이터를 저장하기 위해 엄청난 크기로 늘어났다는 거지.
테이블의 특성상 한 번 할당 받은 Extent는 반환하지 않는데, MLOG$ 테이블도 마찬가지야.
그리고 원천 테이블에서 데이터가 변경되면 MLOG$ 테이블에 변경 분이 저장되며,
TEST_SRC 테이블은 변경된 데이터를 반영하기 위해 MLOG$ 테이블을
Full Table Scan을 하게 되는데, 엄청나게 커져 있는 MLOG$ 테이블을 전체를 읽게 되지.머나먼: 어 팀장님. 이해가 되지 않아요. 복제 주기만 적당하다면 원천테이블의
데이터 변경 분이 그렇게 많지 않을 것이며, 그렇다면 MLOG$ 테이블이
아무리 커도 실제 적은 데이터만 읽으면 되는 것 아닌가요단무지: 그렇지가 않아. FULL TABLE SCAN이란 테이블에 찍힌 High Water Mark 이하
전체를 읽는데, MLOG$ 테이블은 이미 1000만 건을 저장시키기 위해 커져 있기 때문에
High Water Mark가 엄청나게 높은 위치에 있다는 이야기야. 즉 적은 데이터를 읽기 위해
엄청나게 많은 빈 블록들도 같이 읽는 문제점이 생기지.머나먼: 음… 그렇다면 Snapshot 기능은 활용할 수 없는 기능일 것 같은데요.단무지: 하하~~~ 오라클 DBMS를 만든 사람들이 그렇게 바보들은 아니야.
그래서 처음 TEST_REP 테이블을 만들고 나서 MLOG$ 테이블을 truncate 해서 크기를 줄여 주는
작업을 반드시 진행해야 해. 그런데 말야. 그 작업을 위해서는 원천 테이블에 변경이 발생해서는 안 돼.
따라서 1) 원천 테이블에 LOCK을 걸고, 2) MLOG$ 테이블 백업, 3) MLOG$ TRUNCATE,
4) MLOG$ 테이블 복원 5) 원천 테이블에 LOCK 제거하는 방식으로 작업을 처리해야 해. 스크립트는 아래와 같아.
/* 1. 원천 테이블에 LOCK , TRUNCATE TABLE 하는 세션과 별도 세션에서 수행 */
LOCK TABLE YOON.TEST_SRC;/* 2. MLOG$ 테이블 백업, 신규 세션을 열어 수행 */
CREATE TABLE YOON.MLOG$_TEMP AS
SELECT * FROM YOON.MLOG$_TEST_SRC ;/* 3. MLOG$ 테이블 TRUNCATE */
TRUNCATE TABLE YOON. .MLOG$_TEST_SRC ;/* 4. MLOG$ 테이블 복원 */
INSERT INTO YOON. YOON.MLOG$_TEST_SRC
SELECT * FROM YOON.MLOG$_TEMP;/* 5. 원천 테이블에 LOC 해제. 1번 작업 진행 세션에서 수행 */
ROLLBACK;머나먼: 아 ~~ 그렇군요. 알겠습니다. 고맙습니다.단무지: 그리고 마지막으로 하나 더 챙겨야 하는 게 있어. 이 SNAPSHOT 테이블은 주기적으로
업데이트하는 것을 실행시키는 것은 오라클 스케줄러인 JOB에 등록시켜 진행하거든.
따라서 DBA_JOBS를 조회해서 꾸준히 잘 돌아가고 있는지 점검하는 것 잊지 말고.머나먼: 넵. 알겠습니다. 단무지: 오늘은 여기까지 하자고. 내일 또 이어서 진행하자고.



에필로그

실력은 깻잎과 같이 얇은 하루 하루의 노력이 켜켜이 쌓여 이루어 진다.

아~~ 오늘은 아침부터 해야 할 일이 너무 많다. 하루만 일일점검을 건너뛰면 어떨까 이러한 달콤한 유혹들에 DBA들은 빠지기 쉽습니다. 머피의 법칙이라 하나요 “꼭 일일점검을 하지 않은 날 장애가 난다” 머피의 법칙이라기보다는 말을 뒤집어 봅시다. 일일점검을 했더라면 사전 조치로 인해 발생하지 않았을 장애가 발생한 겁니다. 무장애란 이런 일일점검들이 쌓이고 또 쌓여 이루어 지는 것입니다. 일일점검 역시 그냥 무의식적으로 하지 말고, 그 안에 숨겨진 의미들을 이해하고 가슴에 새겨가며 진행해야 합니다. 또한 일상의 DBMS 모니터링 중 발생하는 데이터베이스의 현상들을 깊이 있게 이해하려는 시도와, 현상에 대한 원인을 파악하려 자세가 중요합니다. ‘이건 내가 모르지만, 지금 장애로 나타나지 않기 때문에 괜찮아’ 하고 넘어가는 순간 여러분들의 수준은 그 자리에 머물게 됩니다. DBMS의 현상을 이해하고, 왜 그렇게 동작하는 가에 대한 꾸준한 궁금증이 쌓이고 또 쌓여 여러분들이 실력이 성장하는 겁니다.

지식은 처음에 머리속에 들어오면 단위 정보로 머물러 있습니다. 하지만 그런 단위 단위 정보들이 쌓여 서로 연결되는 순간 여러분은 Quantum Jump를 경험하게 됩니다. 여러분들은 지금 단위 정보를 모으고 또 모아야 합니다. 그 단위 정보가 깻잎과도 같이 얇디 얇은 하루 하루의 노력입니다. (다음 회에 계속)



출처 : 한국데이터진흥원

제공 : 데이터 전문가 지식포털 DBguide.net