EN-CORE

조인(JOIN)이란 ?

김동훈 — Tue, 15 May 2012 15:38:40 +0900

조인이란

LAST_NAME DEPT_ID NAME
-------------------- ------------ ----------------------
Velasquez 50 Administration
Ngao 41 Operations
Nagayama 31 Sales
Ropeburn 50 Administration
Urguhart 41 Operations
..

조인은 관계형 데이터 베이스에서 가장 기본적이고 가장 중요한 기능이다.
조인은 어떤 테이블을 기준으로 다른 테이블에 있는 Row를 찾아오는것이다.
관계형 데이터베이스에서는 서로 독립적인 데이터들간의 조인을 이용하여 필요시 원하는
다양한 정보를 연결할 수 있다.
위 예에서는 사원과 부서 테이블은 부서코드라는 연결고리를 이용하여 사원의 부서이름을
조인하여 데이터를 연결한 것이다.

예제

SQL> SELECT s_emp.last_name,s_emp.dept_id, s_dept.name
2 FROM s_emp, s_dept
3* WHERE s_emp.dept_id = s_dept.id

LAST_NAME DEPT_ID NAME
-------------------------- -------- ---------------------
Velasquez 50 Administration
Ngao 41 Operations
Nagayama 31 Sales
Quick-To-See 10 Finance
Ropeburn 50 Administration
………………………...

Top-N Query

encore2000 — Tue, 15 May 2012 15:33:21 +0900

PURPOSE

Oracle 8i부터 지원하는 Top-N Query에 대한 개념 습득을 통한 실전 활용

SCOPE & APPLICATION

적절한 Sql 사용을 통한 Application의 성능 향상

KEY IDEA

KEY WORD : Sort, Top-N Query, Order by Stopkey, Group by Stopkey, Sort Pushed Rank

SUPPOSITION

Oracle 8i 이상부터 지원 가능

DESCRIPTION

Oracle 8i부터 전체 Data에 대한 상위 몇개, 하위 몇개에 대한 Query를 구현하고자 Ton-N Query의 기능이

추가 되었다. Top-N Query의 기능은 기존에 사용 했던 Sort 방식의 확장된 개념으로 대용량의 Data를 Sort하기

위해 사용되었던 기존의 2 Phase Multiway Merge Sort의 방식을 그대로 사용하고 있으며, 단지 불필요한

Temp Segment에 대한 사용을 줄임으로서 성능의 향상을 얻을수 있는 기능이라 볼수 있다.

구체적인 예를 들어서 설명해 보도록 하겠다.

TABLE_NAME	NUM_ROWS	BLOCKS	EMPTY_BLOCKS	AVG_ROW_LEN
EMP	100000	1204	225	85

현재 근무하는 사원중에 급여를 많이 받은 사람순으로 50명만을 추출하는 sql

select *

from

(select *

from emp

order by sal desc

)

where rownum <= 50

8i 미만 8i 이상

-------------------------------------- ----------------------------------------

SELECT STATEMENT SELECT STATEMENT

COUNT (STOPKEY) COUNT (STOPKEY)

VIEW VIEW

SORT (ORDER BY ) SORT (ORDER BY STOPKEY)

TABLE ACCESS (FULL) OF EMP TABLE ACCESS (FULL) OF EMP

위의 Plan 에서 명시적으로 알 수 있듯이 두개의 Plan에는 ORDER BY STOPKEY라는 부분에서 차이가 존재할 뿐이며 상식적으로 생각해 봤을때 상위 50명을 가지고 오기 위해서 전체 직원에 대한 Sort 작업은 피할수 없는 작업으로 생각되어진다. 단지 Sort Area Size등의 Paramenter를 늘려줌으로 해서 Response Time의 향상을 가져오는 것 이외에는 별다른 방법이 없을 듯 하다.

그러나 동일한 시스템 환경에서 Test해본 Order by Stopkey의 성능은 기존방식과 비교해서 Response Time에서 10배 이상의 성능향상을 보여주고 있으며 전체 Data Set의 크기가 커지면 커질수록, Stopkey의 Range가 작으면 작을수록 그 이상의 성능향상을 가지고 오는 것을 볼 수 있었다.

	cpu	elapsed	disk	query	current
full sort (100000)	1.17	16.36	2644	1267	339
Rownum <=10	0.31	0.58	1205	1267	15
<=100	0.25	0.51	1205	1209	15
<=1000	0.46	0.59	1205	1267	15
<=5000	1.03	9.88	1981	1267	349
<=10000	1.26	12.05	2166	1267	345

이러한 성능의 향상은 Sort Operation에 대한 정확한 개념을 이해하고 있다면 쉽게 접근할수 있다.

대부분의 DBMS에서는 Sort작업의 대상집합이 Sort Area Size를 넘어서는 대용량 Data를 처리하기 위해

전체 Data를 Subset 단위로 나누어서 각각을 Sort하여 Temp Segment에 저장한 후 각각의 Subset을

Merge하여 전체적으로 Sort되어진 결과집합을 만들어 내게 된다.

Oracle에서는 이러한 Subset을 Run이라고 명명하고 사용하고 있으며 이러한 Temp Segment에서의

물리적인 Disk I/O작업은 Sort 작업에서 대부분의 Cost를 발생시키게 된다.

그러나 상위 몇개, 하위 몇개를 가지고 오는 Order By Stopkey의 경우 Sort할 대상 집합은 변하지 않지만

Sort되어진 결과 집합은 Stopkey의 Range 만큼만 필요하게 된다. 결과적으로 Sort되어진 전체 집합을

필요로 하지 않기 때문에 Temp Segment를 이용한 Merge작업이 줄어들게 되며 Stopkey의 Range가 Sort

Area를 넘지 않는다면 Temp 영역을 전혀 사용하지 않고 작업을 끝낼 수 있게 된다.

이러한 원리를 파악한다면 Temp Segment를 이용하여 작업하는 다른 Operation에도 적용 가능할 것이며

실제로 Group by Operation 과 Analytical Function 중 Rank 에도 사용할수 있음을 확인 할 수 있다.

Group by Stopkey는 Grouping Column의 Cardinality, Rank(Order Pushed Rank)는 Partition

Column의 Cardinality와 Stopkey의 Range에 영향을 받는 것을 알 수 있으며 이러한 특성을 이용하여 Temp를

사용하는 Operation의 Performance를 향상 시킬수 있다.

1. 파티션의 이해와 활용

encore2000 — Mon, 14 May 2012 15:29:34 +0900

Partition

1. Partition의 개념

2. Partition의 Execution Plan

3. Partitioned Index

4. 대용량 테이블 Managing전략 (Exchange, Parallel Processing, Program Parallel)

1. Partition의 개념

1-1. Partition의 개념

대용량의 Table이나 Index를 Partitioning 한다는 것은 하나의 Object가 여러 개의 Segment로 구성이 된다는 의미이다. 이는 하나의 Table이나 Index가 동일한 논리적 속성을 가진 여러 개의 단위(Partition)로 나누어져 각각이 별도의 물리적 속성(PCTFREE, PCTUSED, INITRANS, MAXTRANS, TABLESPACE 및 STORAGE PARAMETER등)을 가질 수 있게 되는 것이다. 관리하는 데이터가 대용량이 되면서 Performance와 Storage관점에서 문제가 생길 수 있는데, 이를 해결할 수 있는 방법이 Partitioning인 것이다. 따라서 다음과 같은 장점이 있을 수 있다.

l Data Access시 (특히 Full Scan시) Access의 범위를 줄여 Performance를 향상시킬 수 있다.

l 물리적으로 여러 영역으로 Partitioning하여 전체 데이터의 훼손 가능성이 감소하여 Data 가용성이 향상된다.

l 각 Partition별로 별도로 백업, 복구 작업을 할 수 있다.

l Disk I/O의 분산을 테이블의 Partition단위로 하여 I/O경합을 줄일 수 있다.

Oracle DBMS에서 제공하는 Partitioing 방식에는 Range Partitioning, Hash Partitioning, List Partitioning, Composite Partitioning(Range-Hash, Range-List) 가 있다.

1-2 Partition의 종류

1) Range Partitioning

Range Partition은 말 그대로 어떤 특정 Column Value의 정렬 값을 기준으로 분할하는 것이다. 주로 Historical Data를 관리하는 Table에 많이 적용되어 사용된다.

간단하게 예를 들어보면 “가입계약”이라는 Table이 있고 여기에는 몇 년 동안 데이터가 쌓여있을 때 우리는 이것을 5년간만 관리를 하고, 주로 Access되는 Data는 금년 및 전년도가 대부분일 때 이것을 년도 별로 또는 월별로 Partitioning하고 Data를 조회하는 Application의 SQL Access Path를 조정하여 전체 Data가 아닌 최근 정보를 가지고 있는 Partition만 Access하도록 하여 성능을 향상시킬 수 있는 전략을 세울 수 있다. 기존에는 월별 또는 년별로 테이블을 따로 만들어 (가입계약_1999, 가입계약_2000…….) 사용하기도 하지만, 이것은 사용상에 불편한 점이 많고, Access하는 SQL이 복잡해지는 단점이 있다. Range Partition을 만드는 DDL Script는 다음과 같다.

CREATE TABLE CONTRACT

( I_YYYYMMDD VARCHAR2(8),

I_CUSTOMER VARCHAR2(9),

………

)

TABLESPACE TBS1

STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0)

PARTITION BY RANGE (I_YYYYMMDD)

(

PARTITION PAR_200307 VALUES LESS THAN (‘20030801’),

PARTITION PAR_200308 VALUES LESS THAN (‘20030901’),

…………

)

l PARTITION BY RANGE (COLUMN_LIST) : 어느 Column을 기준으로 Partitioning할 것인

지를 정함

l VALUES LESS THAN (VALUE_LIST) : 해당 Partition이 어느 Range에 포함될 것인지 Upper Bound를 정함

PARTITION BY RANGE에 나타나는 COLUMN_LIST를 Partitioning Column이라 하고 이 값이 Partitioning Key를 형성하게 되며, 이 Partitioning Column은 결합인덱스처럼 최대 16개까지 지정할 수 있다.

VALUESS LESS THAN에 나타나는 VALUE_LIST는 Partitioning Column들의 Value에 해당하며, 여기에 나타낸 값은 Upper Limit으로 여기 지정된 값 보다 작은 값들을 저장하겠다는 의미가 된다.

위의 Script에서 지정한 물리적 속성들은 각 Partition들이 생성될 때 개별적으로 물리적 속성을 지정하지 않으면 각 Partition들은 위의 속성 값을 적용 받게 되는 것이다.

2) Hash Partitioning

Hash Partitioning은 어떤 특정 Column Value에 Hash Function을 적용하여 분할하는 방식으로 Data의 관리목적보다는 Performance향상의 목적으로 나온 개념이다.

Range Partitioning의 경우 각 범위에 따라 Data양이 일정치 않아 분포도가 일정하지 않게 되는 단점이 있으므로 일정한 분포를 가진 Partition으로 나누고 균등한 분포도를 이용한 Parallel Processing으로 Performance를 높이기 위한 것이다. 다시 말해 분포도를 정의하기 어려운 테이블을 Partitioning 하고자 할 때 많이 이용하게 되고, 2의 배수 개수로 Hash Partitioning을 한다.

Hash Partitioning의 경우 모든 Partition들은 동일한 논리,물리적 속성을 가지게 되고 Partition영역에 따로 지정할 수 있는 유일한 속성은 Tablespace뿐이다.

Hash Partition을 만드는 DDL Script이다.

CREATE TABLE CONTRACT

( SERIAL NUMBER,

CODE VARCHAR2(4),

………

)

TABLESPACE TBS1

STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0)

PARTITION BY HASH (SERIAL)

(

PARTITION PAR_HASH_1 TABLESPACE TBS2,

PARTITION PAR_HASH_2 TABLESPACE TBS3,

…………

)

Range Partition과는 다르게 각 Partition에 지정되는 Value들은 DBMS가 정하게 되므로 각 Partition에 어떤 값들이 들어가 있는지는 알 수가 없다. Hash Partitioning은 대용량의 분포도가 일정치 않은 Table을 Migration할 때 Program Parallel방식과 유용하게 쓰여질 수 있고 구체적인 사용예제는 뒷장에서 다루게 된다.

3) List Partitioning

List Partitioning은 어떤 특정 Column의 특정 Value로 Partitioning을 하겠다는 의미이다. 주로 Cardinality (distinct value)가 많지 않고 그 Distinct Value별로 분포도가 비슷하며, 많은 SQL의 Access Path에서 해당 Column의 조건이 많이 들어오는 경우 아주 유용하게 쓰일 수 있다. 간단한 예를 들어보면. ‘서비스 계약’이라는 테이블이 있을 때, 서비스를 최초 가입한 대리점을 ‘가입대리점’, 그 다음 계약의 변경사항을 처리한 대리점을 ‘처리대리점’ 이라고 명명할 경우 모든 서비스의 가입, 해지, 전환 등등의 처리는 이 두 대리점이 존재하게 된다. 다음은 이런 테이블의 구조이다.

CREATE TABLE SERVICE_CONTRACT

(I_YYYYMMDD VARCHAR2(8),

I_CUSTOMER VARCHAR2(6),

I_DLR_IND VARCHAR2(2),

I_DEALER VARCHAR2(6),

……………………………….)

즉, I_DLR_IND에 대리점 구분이라는 구분자가 존재하여 ‘A’일 때는 ‘가입대리점’ ‘S’일 때는 ‘처리대리점’이라고 할 때 대부분의 조회 Pattern은 각각의 가입대리점 또는 처리대리점에 해당하는 값이 들어오게 될 것이다. 이럴 때 I_DLR_IND로 List Partitioning을 한다면 큰 효과를 볼 수 있다. 즉, 집합의 Sub-Type을 분류시 List Partition은 유용하게 쓰일 수 있다. 이것은 하나의 예에 지나지 않으며 List Partitioning은 매우 강력하다. 또한 다음의 Composite Partition에서 Range Partition과 짝을 이루면 그 강력함이 배를 이룬다.

List Partition을 만드는 DDL Script이다.

CREATE TABLE SERVICE_CONTRACT

(I_YYYYMMDD VARCHAR2(8),

I_CUSTOMER VARCHAR2(6),

I_DLR_IND VARCHAR2(2),

I_DEALER VARCHAR2(6),

………………….)

TABLESPACE TBS1

STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0)

PARTITION BY LIST (I_DLR_IND)

(PARTITION PAR_A VALUES (‘A’),

PARTITION PAR_S VALUES (‘S’))

PARTITION BY LIST에 나타나는 COLUMN_LIST는 Partitioning Column으로 Partition Key에 해당하고 (단, 단일컬럼만 지정 가능하다.) VALUESS LESS THAN에 나타나는 VALUE_LIST는 Partitioning Column들의 Value에 해당하며, 여기에 나타낸 값에 해당하는 Row들을 저장하겠다는 의미가 된다.

4) Composite Partitioning (Range-Hash)

Range-Hash Composite Partitioning은 Range방식을 사용하여 데이터를 Partitioning하고 각각의 Partition내에서 Hash 방식을 이용하여 Sub-Partitioning을 하는 것으로 Sub-Partition이 독립된 Segment가 되는 것이다. 다음과 같은 이점이 있다.

l Range Partition의 장점을 그대로 수용한다. (관리, Performance의 이점)

l Hash Partition의 이점인 데이터 균등 배치와 병렬화

l Sub-Partition에 특정 Tablespace를 지정할 수 있다.

l Sub-Partition별로 Full Scan이 가능하여 Scan범위를 줄일 수 있다.

Range Partition에서 Base Table은 단지 논리적인 구조이며 실제 Data는 Partitioned Segment에 저장된 것과 같이 Composite Partition에서도 Base Table 및 Partitioned Table은 단지 Partitioning을 위한 논리적인 구조이며 Data는 가장 하위단인 Sub-Partition영역에 저장된다.

Range-Hash Composite Partition을 생성하는 DDL Script이다.

CREATE TABE TB_RANGE_HASH (

I_YYYYMMDD VARCHAR2(8),

I_SERIAL NUMBER,

SALE_PRICE NUMBER,

…………………………………………)

TABLESPACE TBS1

STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0)

PARTITION BY RANGE (I_YYYYMMDD)

SUBPARTITION BY HASH (I_SERIAL)

(PARTITION SALES_1997 VALUES LESS THAN (‘19980101’)

(SUBPARTITION SALES_1997_Q1 TABLESPACE TBS2,

SUBPARTITION SALES_1997_Q2 TABLESPACE TBS3),

………………………………………………………………

)

위에서 제시한 DDL Script는 PARTITION BY RANGE (I_YYYYMMDD)에 의해 RANGE로 PARTITION된 다음 SUBPARTITION BY HASH에 의해 SUB-PARTITIONING된 것이다.

5) Composite Partitioning (Range-List)

Range-List Composite Partitioning은 Range방식을 사용하여 데이터를 Partitioning하고 각각의 Partition내에서 List 방식을 이용하여 Sub-Partitioning을 하는 것으로 Sub-Partition이 독립된 Segment가 되는 것이다. 다음과 같은 이점이 있다.

l Range Partition의 장점을 그대로 수용한다. (관리, Performance의 이점)

l List Partition의 특징인 특정 Value에 의한 Partitioning이 가능하다.

l Sub-Partition에 특정 Tablespace를 지정할 수 있다.

l Sub-Partition별로 Full Scan이 가능하여 Scan범위를 줄일 수 있다.

Range-List Composite Partition은 Range-Hash Composite Partition과 특징은 비슷하며 단지 Sub-Partitioning이 List Partition이라는 차이점을 가지고 있다. 실제 업무에서 Range-Hash 보다 유용한 면이 많다.

Range-List Composite Partition을 생성하는 DDL Script이다.

CREATE TABLE TB_RANGE_LIST (

I_YYYYMMDD VARCHAR2(8),

I_AGR_IND VARCHAR2(2),

I_DELAER VARCHAR2(6),

………………………………………….

)

TABLESPACE TBS1

STORAGE (INITIAL 2M NEXT 2M PCTINCREASE 0 MAXEXTENTS UNLIMITED)

PARTITION BY RANGE (I_YYYYMMDD)

SUBPARTITION BY LIST (I_AGR_IND)

(

PARTITION PAR_1997 VALUES LESS THAN (‘19980101’)

(SUBPARTITION PAR_1997_A VALUES (‘A’),

SUBPARTITION PAR_1997_A VALUES (‘S’)

…………………………………………………………………)

2. Partition의 Execution Plan

2-1. Non-Composite Partition 일 때

Execution Plan은 내부적으로 Optimizer가 SQL을 어떻게 실행하겠다는 말 그대로 “실행계획”이다. 파티션 테이블과 인덱스를 Access할 때는 그 물리적 구조의 특이성 때문에 Execution Plan의 표현이 색다르다고 할 수 있다. Partition 테이블을 Access할 때 나오는 Execution Plan은 “ ‘PARTITION’ + Partition 의 종류 + Access 방법 “으로 나타나게 된다. Partition의 종류는 RANGE, HASH, LIST가 표현이 되고, Access방법은 EMPTY, SINGLE, ITERATOR, INLIST, ALL 등으로 표현이 된다. Execution Plan은 논리적으로 실행하는 방법을 표현한 것이므로 Partition의 종류 (Range, Hash, List)와 상관없이 Partition Table을 어떻게 Access 하겠느냐에 따라서 결정이 되므로 이 것을 잘 이해할 수 있으면 Partition Table을 Access할 때의 내부적인 Mechanism을 이해하는데 도움이 된다.

l “PARTITION RANGE(HASH, LIST) EMPTY”

SELECT * FROM STS_SERVICE_BONBU_DD x WHERE I_DLR_IND = 'X'
Operation	Object Name	Pstart	PStop
SELECT STATEMENT Hint=CHOOSE
PARTITION LIST EMPTY		INVALID	INVALID
TABLE ACCESS FULL	STS_SERVICE_BONBU_DD	INVALID	INVALID

“EMPTY” 는 조건에 해당하는 Partition이 존재하지 않을 경우를 의미하고 있다. PStart와 PStop의 경우도 “INVALID”로 나와 있는 것 처럼 SQL의 해당조건에 해당하는 Partition이 존재하지 않는 것이다. 위의 STS_SERVICE_BONBU_DD의 테이블은 LIST라는 Key word에 의해 List Partitioned Table임을 알 수 있다.

l “PARTITION RANGE(HASH, LIST) SINGLE”

SELECT * FROM TS_1 x WHERE I_YYYYMM = :A
Operation	Object Name	Pstart	PStop
SELECT STATEMENT Hint=CHOOSE
PARTITION RANGE SINGLE		KEY	KEY
TABLE ACCESS FULL	TS_1	KEY	KEY

“SINGLE”은 논리적으로 보면 하나의 Partition을 Access하겠다라는 의미이다. 그런데, Partition Key의 조건이 binding 변수가 “=”로 조건이 올 경우에만 “SINGLE”이라는 Key Word가 표현이 되면서 PStart, PStop에는 “KEY”라고 나타나게 되는 것이다. 만약, 실제 상수 조건이 “=”로 올 경우는 SINGLE이라는 Key Word는 나타나지 않는다. 즉, 다시 말해 Parameter Query를 쓸 경우는 실제로 Binding될 상수가 정해져 있지 않으므로 Access해야 할 Partition을 표현할 수가 없다. 따라서 PStart, PStop에는 “KEY”로 표현이 되면서 Access방법은 “SINGLE”로 나타나게 되는 것이다. 실제 Binding되는 상수 값에 의해 어떤 Partition을 Access할 수도, 하지 않을 수도 있다. 이는 Partitioned Table이 상수조건을 수용하는 쪽이 아닌 Inner 쪽일 때도 마찬가지로 성립이 된다.

l “PARTITION” Key Word가 나오지 않을 경우

SELECT * FROM TS_2 x WHERE I_YYYYMM = '200301'
Operation	Object Name	PStart	PStop
SELECT STATEMENT Hint=CHOOSE
TABLE ACCESS FULL	TS_2	13	13

이와 같이 Partition Key에 하나의 상수 값이 “=” 로 조건이 온다는 것은 특정 Partition 하나에 Access하겠다는 의미가 된다. 이런 경우는 상수조건이 실제의 값에 해당하므로 PStart, PStop에는 해당하는 하나의 (위의 경우 13번째 Partition) Partition이 표현되게 되고, Execution Plan에 ‘PARTITION RANGE SINGLE”과 같은 Partition관련 Key Word는 나타나지 않는다. 그렇다면, like, between, in 등을 이용해서 하나의 특정 Partition에 해당하는 조건을 주게 되면 어떻게 될까?

Execution Plan은 논리적으로 Optimizer가 실행하고자 하는 계획이므로 이 것 역시 PARTITION Key Word는 나타나지 않고 단지 PStart, PStop 에만 특정 Partition이 표현이 된다.

단, IN Operator의 경우는 좀 다르다. IN Operator의 경우는 IN 안에 하나의 Partition에 해당하는 상수조건을 부여해도 Access 방법이 “INLIST” 라고 나오게 된다. 이 것은 IN 절에 있는 상수의 개수만큼 ( IN (‘20030101’, ‘20030110’, ‘20030120’) 의 경우 3개) Partition에 접근시도를 하는 것으로 착각하기 쉽다. 즉, 한 Partition내의 상수조건을 여러 개 주었을 경우 그 상수조건의 개수만큼 동일한 Partition을 Access시도를 하는 것이 아니라 IN 절의 상수조건을 Sort하여 하나의 Partition안에 속해 있으면 한 번 Access하게 되는 것이다. 이는 Partitioned Table이 상수조건을 수용하는 쪽이 아닌 Inner 쪽일 때도 마찬가지로 성립이 된다.

만약, From 절에 특정 Partition을 지정하게 되는 경우는 어떻게 될까?

SELECT * FROM TS_2 x PARTITION (PAR_200301)
Operation	Object Name	PStart	PStop
SELECT STATEMENT Hint=CHOOSE
TABLE ACCESS FULL	TS_2	13	13

From 절의 Table에 특정 Partition을 지정한 것을 Extended Table명이라고 하는데 이처럼 Extended Table명을 붙일 경우에는 특정한 한 개의 Partition만 Access하고자 하는 경우이므로 이런 경우도 “PARTITION RANGE SINGLE” 과 같은 Partition관련 Key Word는 나타나지 않는다.

l “PARTITION RANGE(HASH, LIST) ITERATOR”

SELECT * FROM TS_3 WHERE I_YYYYMM BETWEEN '200307' AND '200308'
Operation	Object Name	PStart	PStop
SELECT STATEMENT Hint=CHOOSE
PARTITION RANGE ITERATOR		19	20
TABLE ACCESS FULL	TS_3	19	20

“ITERATOR”는 많은 경우의 Partition Execution Plan에서 나오는 형태로서 말 그대로 여러 개의 Partition을 순환하여 Access한다는 의미가 된다. 단, Access할 Partition의 범위를 Optimizer가 알고 있는 경우에 해당된다. Between 이나 like, 부등호등의 선분조건에 의해 연속된 여러 개의 Partition을 Access하고자 할 때 나타나게 된다. 이는 Partitioned Table이 상수조건을 수용하는 쪽이 아닌 Inner 쪽일 때도 마찬가지로 성립이 된다.

l “PARTITION RANGE(HASH, LIST) INLIST”

SELECT * FROM TB_5 WHERE I_DLR_IND IN ('A', 'S')
Operation	Object Name	PStart	PStop
SELECT STATEMENT Hint=CHOOSE
PARTITION LIST INLIST		KEY(I)	KEY(I)
TABLE ACCESS FULL	TB_5	KEY(I)	KEY(I)

“INLIST”는 Partition Key의 Operator가 “IN” 이 적용될 때 나타나게 된다. 단, IN Operator 다음에 오는 상수의 개수가 한 개일 때와 IN ( select ~~~) 처럼 집합으로 처리될 때는 나타나지 않는다. 이것은 Partition이 아닌 일반 Table일 때 IN Operator를 사용할 때의 Execution Plan과 비슷한 것이다. 앞서 설명한 데로 IN 다음에 오는 상수 값 들이 동일한 Partition내에 있어도 다른 Operator의 경우는 PARTITION관련 Key Word가 나타나지 않는 반면에 IN Operator의 경우는 “PARTITION LIST INLIST”와 같이 INLIST가 나타나게 된다.

2-2. Local Index가 있을 때

기본적으로 Index를 사용할 때는 그 Index가 속해 있는 Object를 먼저 결정하고, 그 이후에 조건들을 고려해서 사용할 Index를 결정하게 된다. Partitioned Table일 경우 이와 마찬가지로 Local Index를 이용할 때 Partition Key값에 해당하는 Partition을 먼저 결정한 이후 Local Index의 Searching작업을 하게 되는 것이다. 많은 개발자들이 오해하고 있는 부분 중에 하나가 Local Index에는 반드시 Partition Key가 포함되어 있어야 한다는 것이다. 물론, Unique Index를 만들 경우에는 논리적으로 Unique한 것과는 상관 없이 Unique Index에 Partition Key가 포함되어야 하지만, 일반적인 Local Index를 만들 때는 Partition Key와는 무관하다. 따라서, Local Index를 이용한 Execution Plan은 앞서 설명한 Non-Composite Partition일 경우의 Execution Plan에 INDEX RANGE SCAN -à TABLE ACCESS BY LOCAL INDEX ROWID 라는 Key Word가 추가될 뿐이다.

select * from kcf_cont_mm_1 x where i_ncn in ('206737665', '202226342') and i_yyyymm between '200307' and '200308'
Operation	Object Name	PStart	PStop
SELECT STATEMENT Hint=CHOOSE
PARTITION RANGE ITERATOR		19	20
INLIST ITERATOR
TABLE ACCESS BY LOCAL INDEX ROWID	KCF_CONT_MM_1	19	20
INDEX RANGE SCAN	KCF_CONT_MM_IDX1	19	20

이 것은 Partition Key 조건에 해당하는 Partition을 Pruning하여 각각의 Partition내에서 Local Index의 Searching작업을 하게 되는 것이다. 다음은 Global Index와 Local Index의 구조를 나타낸 그림이다. (이해를 위해 Global Index와 Local Index로 구분을 하였지만 실제로는 Partitioned Index와 Non-Partitioned Index의 그림이다.)

이 그림에서 보는 바와 같이 각각의 Partition별로 Local Index는 Root Node 부터 Leaf Node를 별도로 가지고 있다. 여러 개의 Partition을 “ITERATOR” 하면서 Local Index를 Range Scan할 경우는 그만큼 Access해야 할 Block이 많아지게 되는 것이다. 대용량 테이블의 경우 Index의 Depth또한 깊어지게 되는데 이런 경우 Local Index는 가능한 가볍게 만드는 것이 Performance향상에 도움이 된다. Local Index의 경우 인덱스를 무겁게 만들게 되면 그만큼 Depth가 깊어지게 되고 만약 Partition Key가 들어오지 않는 상태에서 Index만으로 Searching을 하게 될 경우 Global Index는 큰 영향이 없지만, Local Index는 전체 Partition에 대해서(Range ALL) 각각의 Partition에 대해 Root Node부터 Leaf Node까지의 Lookup을 반복하게 되는데, 이 때 Performance의 저하가 심각해 지는 상황을 저자는 여러 번 볼 수 있었다. 다음은 이에 관한 실제 사례이다.

예) 2-2-1

l KCF_SERVICE_DD

n 전체 건수 : 약 1억건

n PARTITION Key는 I_YYYYMMDD

n 월별 Range PARTITION으로 약 70개의 PARTITION으로 구성된 테이블

n ncn, package가 전 Partition에 걸쳐 존재

l INC_SERVICE_DD_VER2

n 전체 건수 : 약 4만건

SELECT /*+ ORDERED USE_NL(S T) PARALLEL(S 10) */

S.I_YYYYMMDD,

S.I_NCN,

S.I_CN,

S.I_PACKAGE,

T.I_EXPR

T_I_EXPR,

T.I_EXPR_TIME T_I_EXPR_TIME,

T.I_OPERATOR T_I_OPERATOR

FROM INC_SERVICE_DD_ver2 S, DW.KCF_SERVICE_DD T

WHERE S.I_NCN = T.I_NCN

AND S.I_PACKAGE = T.I_PACKAGE

AND S.I_EFFECT < '20030806'

AND T.I_EXPR = '99991231';

CREATE TABLE STATEMENT Hint=CHOOSE

LOAD AS SELECT

SORT UNIQUE

NESTED LOOPS

TABLE ACCESS FULL INC_SERVICE_DD_VER2

PARTITION RANGE ALL

PARTITION LIST ALL

TABLE ACCESS BY LOCAL INDEX ROWID KCF_SERVICE_DD

INDEX RANGE SCAN KCF_SERVICE_DD_IDX_1

l Elapsed Time 비교

n KCF_SERVICE_DD_IDX_1 : I_NCN + I_PACKAGE 일 때

☞ 약 10분

n KCF_SERVICE_DD_IDX_1 : I_NCN + I_PACKAGE + I_YYYYMMDD

+ I_EXPR + I_EXPR_TIME

☞ 약 40분

위 사례는 모 통신회사에서 쓰이는 파티션 테이블로서 업무에 대한 자세한 설명은 하지 않기로 하고 이 현상에 대해서만 설명을 하면, INC_SERVICE_DD_ver2테이블의 약 4만 건에 해당하는 Row중에서 I_NCN과 I_PACKAGE로만 KCF_SERVICE_DD에 Access하여 특정한 조건에 해당하는 집합을 골라내는 작업으로 결과 집합은 약 2000건 정도였다. 기존에 Access되던 Local Index가 I_NCN+I_PACAKGE일 때는 Elapsed Time이 약 10분 이었는데, 이 개발자는 더 빠르게 하고자 Local Index에 Partition Key인 I_YYYYMMDD를 추가하고 조건에 있는 I_EXPR등의 컬럼을 추가하자 Elapsed Time이 약 40분 정도로 늘어나게 되었다. 왜 그랬을까?

이유는 간단하다. 앞서 설명한 데로 테이블의 절대건수가 많으므로 컬럼을 추가한 순간 인덱스의 Depth가 늘어나 전체 Partition의 Local Index를 Lookup하는 시간이 길어졌기 때문이다. 현재 이 SQL은 Partition Key가 조건에 들어오지 않음에도 불구하고 인덱스에 Partition Key를 중간에 넣으므로 해서 비효율을 자초한 것이다.

그렇다면 해결책은 무엇이겠는가? 인덱스의 구조를 I_NCN+I_PACKAGE+I_EXPR로 만드는 것이다. 이렇게 인덱스를 만들었더니 Elapsed Time이 약 6분으로 빨라지게 되었다.

여기서 좀 더 생각을 해보자. 만약 이 인덱스를 Global Index로 만들게 되면 어떻게 될까? 위의 그림에서 볼 수 있듯이 Global Index는 전체 테이블에 대해 해당 컬럼으로 하나의 Root Node를 가지는 구조로 Partition별로 Leaf Node까지를 반복 Access할 필요가 없게 된다. 가능하면 KCF_SERVICE_DD Table을 I_NCN+I_PACAKGE+I_EXPR 컬럼 순으로 Sorting을 하여 Clustering Factor를 높인다면 극도의 Performance 효과를 노릴 수 있을 것이다. 테이블과 인덱스의 구조를 이런식으로 변경하니 Elapsed Time은 약 13초가 나오게 되었다.

위와 같은 사례는 대용량의 데이터를 다루는 환경에서 자주 볼 수 있는 현상으로 Partition과 Index전략이 매우 중요한 것임을 알 수 있고, 대용량의 데이터 환경에서는 Index의 컬럼 하나가 큰 영향을 끼칠 수 있음을 주의해야 한다.

2-3. Global Index가 있을 때 (Global Non-Partitioned Index일 경우)

Global Index는 Partitioned Table에서만 부르는 Index이지만, 사실 일반적인 Table (Non-Partitioed Table)에서 보통의 Index와 동일하다. 앞에 나타난 그림대로 전체 테이블에 대해서 하나의 Root Node를 가지고 있게 된다. 대용량의 테이블인 경우 Depth가 무척 깊어지게 된다.

select * from kcf_cont_mm_1 where i_ncn = '200185893' and i_yyyymm = '200305'
Operation	Object Name	PStart	PStop
SELECT STATEMENT Hint=CHOOSE
TABLE ACCESS BY GLOBAL INDEX ROWID	KCF_CONT_MM_1	17	17
INDEX RANGE SCAN	KCF_CONT_MM_1_IDX2

Global Index를 이용할 때는 Non-Partitioned Table에서 Index를 이용할 때의 Execution Plan과 거의 차이가 없다. 단지 Global Index를 이용한다는 표현인 “TABLE ACCESS BY GLOBAL INDEX ROWID”라는 부분이 다르다. 또한 Global Index를 이용하면서 Table Partition Key조건이 들어오는 경우와 Table Partition Key 조건이 들어오지 않는 경우가 있게 되는데, Global Index는 Partition을 먼저 지정해서 해당하는 Partition의 Index를 Search하는 것이 아니라 전체 테이블을 대상으로 해서 인덱스 Search결과를 가지고 그 인덱스의 Rowid로 Access하기 때문에 Partition Key조건이 들어오든 크게 상관이 없다. Local인덱스의 경우는 “INDEX RANGE SCAN” 부분에도 PStart, PStop에 파티션 Access 부분이 나오게 되지만, Global Index의 Range Scan은 “INDEX RANGE SCAN” 부분에는 그런 개념이 없고 단지 “TABLE ACCESS BY GLOBAL INDEX ROWID”의 PStart, PStop부분에 파티션 번호 또는 “ROWID”라는 Key Word가 표현된다.

2-4. Composite Partition일 때

Composite Partition의 경우도 앞서 설명한 2-1 ~ 2-3의 내용에 따른다. 하지만 Composite Partition은 Partition안에 Sub-Partition이 있기 때문에 Execution Plan의 형태는 다음과 같다.

select * from TB_RANGE_LIST where i_agr_ind between 'C' and 'D' and i_yyyymmdd between '19971203' and '19980110'
Operation	Object Name	PStart	PStop
SELECT STATEMENT Hint=CHOOSE
PARTITION RANGE ITERATOR		1	2
PARTITION LIST ITERATOR		3	4
TABLE ACCESS FULL	TB_RANGE_LIST	1	8

TB_RANGE_LIST라는 테이블은 I_YYYYMMDD로 Range Partition을 하고 그 하위에 I_AGR_IND로 List Sub-Partition을 한 Composite Partitioned Table이다. 위의 SQL에서 볼 수 있듯이 I_AGR_IND의 조건에 의해 “PARTITION LIST ITERATOR”가 나온 것이고 I_YYYYMMDD의 조건에 의해 “PARTITION RANGE ITERATOR”가 나오게 된 것이다. 만약, Sub-Partition이 특정한 하나의 Sub-Partition만 나오게 된다면 Sub-Partition의 내용은 Execution Plan에 나오지 않게 된다. Composite Partition의 Execution Plan은 Partitioning을 두 번 한 것이기 때문에 PARTITON 관련 Key Word가 두 번 나오는 것 외에는 Non-Composite PARTITION 의 경우와 동일하다.

2. 파티션의 이해와 활용

encore2000 — Mon, 14 May 2012 15:15:33 +0900

3. Partitioned Index

Partitioned Index라고 하면 대부분의 개발자들은 Local Index를 연상하게 된다. 또한 Partitioned Index는 Partitioned Table에서만 쓰는 것으로 생각을 하고 있다. 이것은 잘못된 생각으로 Partitioned Index는 Partitioned Table과 별개의 것이며 단지 많은 상호 연관을 가지고 있을 뿐이다.

Partitioned Index는 말 그대로 Index가 Partitioning된 것으로 Base Table이 Partitioned Table이든 Non-Partitioned Table이든 상관없이 Partitioned Index를 만들 수 있다.

간단한 예를 들자면, ‘EMP’ 테이블의 Size가 상당히 크고 Non-Partitioned Table(그냥 일반 Table)일 경우 Index를 Partitioned Index로 만들고자 한다면 다음과 같이 할 수 있다.

CREATE INDEX EMP_IDX1 ON EMP (DEPTNO)

GLOBAL

PARTITION BY RANGE (DEPTNO)

(PARTITION PAR_10 VALUES LESS THAN (‘20’) TABLESPACE TBS1,

PARTITION PAR_20 VALUES LESS THAN (‘30’) TABLESPACE TBS2,

PARTITION PAR_30 VALUES LESS THAN (‘40’) TABLESPACE TBS3,

PARTITION PAR_40 VALUES LESS THAN (‘50’) TABLESPACE TBS4,

PARTITION PAR_MAX VALUES LESS THAN (MAXVALUE) TABLESPACE TBS5)

이 Index를 ‘Global Prefixed Partitioned Index’라 부른다. 이렇게 인덱스를 만드는 이유는 Partitioned Table과 마찬가지로 대용량 데이터 환경에서 Performance의 향상과, Management의 편리성등을 위함이다.

Partitioned Index는 ‘1-1.Partition의 개념’에서 설명한 것처럼 하나의 Index를 여러 개의 독립적인 물리속성을 가진 Segments로 나누어 생성 관리하면서 많은 장점을 가질 수 있는 것이다.

Oracle DBMS에서 제공하는 Index는 Global/Local Index와 Prefixed/Non-Prefixed Index로 분류를 한다.

3-1. Partitioned Index와 Non-Partitioned Index

Partitioned Index와 Non-Partitioned Index의 차이점은 Partitioned Table과 Non-Partitioned Table의 차이점과 동일하다. Index의 경우 Indexed Column과 Rowid 순으로 Value가 Sorting이 되어 있는데, 이런 특성은 Partitioning과는 무관하다. 많은 개발자들이 Partitioned Index는 전체 Table에 대하여 Value의 Sorting이 보장되지 않는다라고 생각하고 있지만 이것은 사실과 다르며, Global Partitioned Index의 경우는 Value가 전체 Table에 대하여 Sorting이 보장 되어 있으며 Index에 대한 관리도 Partition별로 독립적으로 할 수 있다.(이것은 Base Table의 Partitioning과는 무관한 것이다.)

Non-Partitioned Index와 Partitioned Index의 구조는 다음과 같다.

위의 그림에서 볼 수 있듯이 Non-Partitioned Index는 하나의 Root Node에서 Leaf Node까지 전체적인 Balance를 유지하는 구조이고, Partitioned Index는 Partition별로 독립적인 Root Node와 Leaf Node를 가지고 각각의 Balance를 유지하는 구조이다. 따라서 대용량의 Table에서 Global Index의 Depth는 굉장히 깊어질 수 있다. Partitioned Index는 각각의 Partition별 Depth가 Non-Partitioned Index보다 얕아지고 Index의 관리도 Partition별로 할 수 있어 Parallel Processing에 의한 Index Management에 매우 효과적이다.

Partitioned Index의 경우 Index Partition Key가 해당 검색 조건에 들어올 때만이 해당 Index Partition을 Search하여 효과를 볼 수 있고 만약, Partitioned Index에 Index Partition Key가 해당 검색 조건에 들어오지 않으면 전체의 Partition에 대해서 Index를 Lookup할 수 밖에 없다.

따라서 Local Index의 경우는 Index Partition Key와 Base Table의 Partition Key가 동일하므로 검색 조건에 이 Index Partition Key가 들어오지 않으면 전체의 Partition에 대해서 반복적인 Lookup작업이 일어나게 되어 Performance 저하를 일으킬 수 있다. 이에 대한 예시는 앞서 2-2-1에 제시했다.

Global Partitioned Index의 경우는 Index의 첫 번째 컬럼(leading Column)이 Index Partition Key가 되는 Prefixed Index 즉, Global Prefixed Partitioned Index로만 생성이 되기 때문에 (그 이유는 밑에서 설명) 조회 검색 조건에 이 Index를 사용하려면 첫 번째 컬럼인 Index Partition Key가 들어오지 않을 수 없다. 따라서 해당 Index Partition을 지정해서 Index Search를 할 수 있는 것이다. 이것은 대용량 데이터 환경에서 Non-Partitioned Global Index의 Index Depth가 깊어진다는 점에서 Global Partitioned Index가 성능 면에서 우수할 수 있고 또한, 인덱스 Rebuild시에도 각각의 Partition별로 Parallel Processing을 할 수 있는 장점을 가지는 것이다.

3-2. Global Index와 Local Index

Global Index와 Local Index의 차이를 생각할 때 많은 개발자들이 ‘Partition되었는가? 아니면 Partition 되어있지 않은가?’ 와 같이 생각을 하고 있다. 이것은 잘못된 생각으로 앞서 설명한 것처럼 Global Index도 Partitioning을 할 수 있으며 Partition별로 관리를 할 수 있다. Global Index와 Local Index의 가장 근본적인 차이점은 ‘정렬’의 차이이다. 즉, Global Index는 테이블 전체에 대하여 Indexed Column과 Rowid 순으로 Sorting이 보장된 (Optimizer가 보장하는) Index이고, Local Index는 테이블 전체에 대하여 Indexed Column과 Rowid 순으로 Sorting이 보장되지 않는 대신, 각각의 해당 Partition 내에서만 Sorting이 보장된 Index이다. 이것이 Global Index와 Local Index의 차이점이다.

Local Index는 ‘Local’이라는 말에서 알 수 있듯이 지역적인 Index로 Default가 Base Table의 Partition Key로 Partitioning된 Index이다. 즉, 다시 말해 Index의 구성 컬럼에 Base Table의 Partition Key가 포함이 되는가의 여부에 상관없이 Local Index의 Partition Key는 Base Table의 Partition Key가 되는 Equipartitioning된 Index인 것이다. 많은 개발자들은 Local Index에 반드시 Partition Key가 포함 되어야만 검색조건에 Partition Key가 들어왔을 때 지정된 Partition을 이용하게 되는 줄 알고 있다. 그러나, Local Index에는 Partition Key가 포함이 되지 않아도 검색조건에 Partition Key가 들어오면 해당 Partition을 지정하게 된다. 다음의 예제를 보면.

select * from PACKAGE_DLR where i_package = 'AAA' and i_dlr_ind = 'C'
Operation	Object Name	PStart	PStop
SELECT STATEMENT Hint=CHOOSE
TABLE ACCESS BY LOCAL INDEX ROWID	PACKAGE_DLR	3	3
INDEX RANGE SCAN	PACKAGE_DLR_IDX1	3	3

l PACKAGE_DLR의 PARTITION KEY : I_DLR_IND (LIST PARTITION)

l PACKAGE_DLR_IDX1 : I_PACKAGE의 단일 컬럼으로 구성

PACKAGE_DLR_IDX1인덱스의 구성 컬럼에 Table Partition Key인 I_DLR_IND가 포함되지 않아도 해당검색조건 이용시 “I_DLR_IND = ‘C’” 라는 검색조건이 있어 해당 Partition의 Local Index만 Search하게 된다.

Global Index는 ‘Global’이라는 말에서 알 수 있듯이 전역적인 Index로 Default가 Non-Partitioned Index이다. 대부분의 개발자들은 Global Index를 Partitioning해서 사용을 할 생각이 없는 듯 하다. 대용량의 테이블에서 Index 관리의 효율성을 높이고 Index Search의 Performance를 향상시키기 위하여 Partitioning작업을 하면 효과를 볼 수 있다. Global Index는 Base Table의 Partition Key와는 무관하게 Partitioning을 하는 것이고 설사 Base Table의 Partition Key로 Global Index를 Partitioning 했다 하더라도 Local Index처럼 Equipartitioning이 된 개념이 아니므로 Table DDL시 전체의 Index를 Rebuild해야 한다.

그렇다면 Global Partitioned Index의 Indexed Column값이 전체 Table에 대하여 Sorting이 어떻게 보장 되겠는가?

5천만 건의 EMP Table(Non-Partitioned Table)을 부서번호에 의해 Partitioning을 했다고 가정하면.

위의 그림은 Global Prefixed Partitioned Index의 그림이다. “Prefixed”란 Index의 Partition Key (DEPTNO)가 Index 첫 번째 컬럼(DEPTNO)이 된다는 것이다. Global Index의 경우 모든 Indexed Value가 Sorting이 되어 있는데 이는 각각의 Index Partition의 Root Block에 들어가는 Value값들이 Index Partition에 따라 정렬됨을 의미한다. 그러면 자연적으로 Leaf Bock에 들어가는 모든 Value들은 정렬이 되기 때문이다. Global Non-Prefixed Partitioned Index는 개념상 Index Partition Key로 각 Index Partition의 Root Block을 만들지 않는 것이기 때문에 전체 데이터에 대해 Sorting을 보장 받을 수 없다. 따라서 현재 지원되지 않는다. Global Index를 Partitioning할 때는 Local Index와는 다르게 Range Partitioning밖에 지원 되지 않는다. 그 이유는 바로 ‘정렬’ 때문인 것이다. Range Partition은 Partitioning Key자체를 Sorting에 의해 생성하기 때문이고 다른 Partitioning은 정렬과 상관이 없는 Partitioning방법이기 때문이다.

3-3. Prefixed Index와 Non-Prefixed Index

Prefixed와 Non-Prefixed의 차이점은 Index Partitioning Key가 Index의 선두 컬럼으로 오는가 그렇지 않은가의 차이이다. Global Index의 경우는 앞에서 설명한 것과 같이 Partitioning Index를 만들 때 Non-Prefixed로 생성을 할 수 없다. 하지만 Local Index의 경우는 Default로 Base Table의 Partition Key가 Index의 Partition Key가 되기 때문에 Local Index생성시 Index 컬럼에 Base Table의 Partition Key가 포함될 필수 조건이 아니고, 또한 인덱스 컬럼의 전체데이터에 대한 Sorting이 보장된 것이 아니기 때문에 Index Partition Key가 Index의 첫번째 컬럼(Leading Column)이 될 필요가 없다. 따라서 Local Index의 경우는 Prefixed Index와 Non-Prefixed Index를 모두 지원한다.

Global Index의 경우는 Non-Partitioned Index이든 Partitioned Index이든 상관없이 인덱스를 이용하고자 할 때는 무조건 Index Partition Key가 조회 조건으로 제공된다. 따라서 Partition의 반복적인 Lookup에 의한 Performance 저하현상은 일어나지 않게 된다. Global Index는 개념상 “Prefixed Index”로만 존재하기 때문이다. 하지만, Local Index의 경우는 Indexed Column에 Partitioned Key가 포함되든 되지 않든 상관없이 조회 검색조건에 Partition Key가 들어올 수도 있고 들어오지 않을 수도 있는데, 들어오지 않을 경우는 Partition의 반복적인 Lookup에 의한 Performance 저하현상이 일어날 수 있다.

3-4. 대용량 데이터 환경에서의 Partitioned Index Strategy

Partitioned Index 전략은 Partitioned Table과 밀접하게 연관되어 세워져야 하지만 이번 장에서는 Partitioned Index를 위주로 이야기를 전개하고자 한다.

Partitioned Index를 고려하는 상황은 ‘대용량 데이터’ 환경임을 명심해야 한다. Index Size는 기본적으로 Table보다는 훨씬 작게 생성, 관리되어야 함이 원칙이어서 중,소용량의 데이터 환경에서는 Partitioned Index의 유용성을 따질 필요가 없다. 단, 중,소용량의 데이터 환경일 경우에도 Table이 Partitioning이 되어 있다면 Partitioned Index를 고려해야 한다.

그리고 Partitioned Index전략은 기본적으로 Non-Partitioned Index(일반 Index) 전략을 기본으로 하여 Table이 Partitioning된 경우와 Index가 Partitioning이 될 때 좋은 점등을 감안하면 되는 것이다.

1) Local Index전략

Table Partition Key가 항상 ‘=’ 로 들어오는 경우 또는 Partition Range가 크지 않은 경우에는 Local Index만큼 좋은 것이 없다. Indexed Column의 순서와 구성은 Access Path에 따라 생성하면 되지만, 최대한 가볍게 생성하는 것이 좋다. 그리고 Base Table의 Partition Key는 반드시 포함될 필요가 없으나, Table이 Range Partitioning일 때 한 Partition Range안에서 Partition Key의 분포도가 좋을 경우에는 포함하는 것을 고려해 본다.

각 Partition당 Index가 Non-Partition일 때 보다 무척 가벼워 지는 장점이 있고 또한 Data Migration시 Table Partition과 Index Partition이 동일하므로 Partition별 Management (Exchange, Rebuild, Add, Drop, Split등)가 용이하다.

2) Global Index전략

빠른 응답 시간을 요구하는 환경에서 대용량 Partitioned Table의 조회조건에 Partition Key가 들어오지 않을 수 있는 경우 Global Partitioned Index 생성을 고려해야 한다. 대용량 Non-Partitioned Table일 때 Table 생성 및 Rebuild를 Partition별 Parallel Processing에 의해 빠르게 할 수 있는 장점이 있다. 또한 Global Partitioned Index는 Global Non-Partitioned Index와는 다르게 Range Partition별로 Index가 가벼워지는 장점이 있고, Range Partition별로 인덱스 Split이 독립적이며 Rebuild또한 독립적으로 수행할 수 있다.

Column분포도에 따른 Partitioning을 할 수 있다는 장점도 있고, Critical한 상수 Range에 대해서는 Partition을 독립적으로 생성하여 Index Size를 줄임으로 해서 Index Search Time을 줄일 수 있다.

4. 대용량 테이블 Managing전략 (Exchange, Parallel Processing)

Exchange는 Partitioned Table의 특정 Partition과 일반 Non-Partitioned Table간의 구조를 서로 바꾸는 것으로 대용량의 Partitioned Table을 Managing하는데 상당한 효과가 있다.

위의 그림에서 보면 데이터가 없는 New Data Table과 데이터가 들어 있는 Partition2가 Exchange를 하게 되면 Partition2에 해당하는 Dictionary정보가 New Data로 바뀌게 되므로 New Data 테이블에는 데이터가 있게 되고, Partition2에는 데이터가 없게 된다. 이 것은 실제로 데이터가 이동하는 것이 아니라 데이터를 저장하는 Table의 정보만 Update되는 것으로 Tablespace를 옮겨야 하는등의 실제 물리적인 데이터 이동시에는 사용할 수가 없다.

주의 점은 Exchange하고자 하는 Partition과 Table의 구조가 같아야 하고 속성들의 특성들이 같아야 한다.

기본적인 Syntax는 다음과 같다.

Alter table Tb_Partition

Exchange partition par_200306

With table Tb_Exchange

(Without validation

Including indexes)

4-1. Split시

대용량의 Partitioned Table을 Split하게 되면 많은 시간이 걸리게 된다. 이럴 때 Exchange방법을 이용하면 빠르고 안전하게 할 수 있다.

위의 그림에서 알 수 있듯이 Split을 해야 하는 Partition을 Exchange에 의해 빈 공간으로 만든 다음 Split을 하고 다시 데이터를 채우기 위해 Split을 하는 것이다. 이렇게 하면 대용량의 데이터임에도 불구하고 아주 빠른 시간내에 Split작업을 할 수 있다.

4-2. 동일 Table생성시

대부분의 DBA들과 개발자들은 동일 Table을 생성할 때 Create Table ~ as select 구문을 이용하게 된다. 대용량의 데이터일 경우 Parallel 옵션을 주어 생성하기도 한다. 만약 1억건의 테이블을 그대로 생성한다고 할 때 어떤 방법이 있을까? 이렇게 대용량의 Partitioned Table을 생성시 Exchange, Program Parallel 방법을 쓰면 아주 안전하고 빠르게 생성할 수가 있다. 다음 그림을 살펴보자.

먼저 생성할 TB_PART_1 테이블을 빈 껍데기만 만들어 놓는다.

대용량의 Partitioned Table의 Partition각각을 Create table ~ as select 구문의 Parallel 옵션을 이용하여 각각의 Table로 생성한다. 그 이후 미리 생성해 놓은 TB_PART_1 테이블의 Partition과 만들어 놓은 테이블들을 Exchange하는 것이다. 이때 파티션별로 200105.sql, 200106.sql, 200107.sql……….. 이렇게 만들어 놓고 이 프로그램들을 동시에 돌리게 되면 (Program Parallel) 극적인 효과를 볼 수 있다. 이런 대용량의 작업시에는 시스템 자원(CPU, MEMORY)등을 모니터링 하면서 작업을 해야 안전하게 할 수 있다.

4-3. 데이터 Migration시 (리모트에서 데이터를 옮길 때)

데이터를 Remote에서 옮겨야 할 때 보통 Database Link를 이용하게 되는데, Network을 통한 데이터 이동시에는 Serial하게 데이터가 이동되므로 속도의 현저한 저하가 나타나게 된다. 이 경우 Source table을 Partitioning하고 해당 Partition을 Access하는 Program을 각각 띠워 Parallel Processing을 하게되면 놀라운 속도 향상을 볼 수 있다.

Source Table을 Partitioning할 수 있는 상황이라면 Table의 분포를 보고 Range, List등으로 Partitioning을 할 수 있고 일정한 분포가 존재 하지 않는 Table일 경우는 Hash Partiitoing을 하여 분포도를 고르게 나눈 다음 해당 Partition을 읽는 View를 Access하여 데이터를 옮긴다. 약 1000만건 정도의 데이터를 옮길 경우에도 장기간의 시간이 필요하게 된다. 다음은 2700만건의 회원 테이블을 옮기는 예제이다. (간단한 DDL Script예제임)

l Source Table Partitioning

create table t_cust_hash

storage (initial 5M next 5M pctincrease 0)

partition by hash(mem_no)

(

partition par_hash_1 TABLESPACE TS_DATA,

partition par_hash_2 TABLESPACE TS_DATA,

partition par_hash_3 TABLESPACE TS_DATA,

partition par_hash_4 TABLESPACE TS_DATA,

partition par_hash_6 TABLESPACE TS_DATA,

partition par_hash_7 TABLESPACE TS_DATA,

partition par_hash_8 TABLESPACE TS_DATA,

partition par_hash_9 TABLESPACE TS_DATA,

partition par_hash_10 TABLESPACE TS_DATA,

)

nologging

select /*+ parallel(x 10) */ * from t_cust x

l Source Table View 생성

create or replace view t_cust_1

select * from t_cust_hash partition (par_hash_1);

create or replace view t_cust_2

select * from t_cust_hash partition (par_hash_2);

create or replace view t_cust_3

select * from t_cust_hash partition (par_hash_3)

……………………………..

l Target 에서 Program Parallel 작업 (동시에 실행시킨다.)

Ø T_cust_1.sql

create table t_cust_1

storage (initial 5M next 5M pctincrease 0)

nologging

tablespace njh

select /*+ parallel(x 4) */ * from t_cust_1@remote x;

Ø T_cust_2.sql

create table t_cust_2

storage (initial 5M next 5M pctincrease 0)

nologging

tablespace njh

select /*+ parallel(x 4) */ * from t_cust_2@remote x;

이것은 하나의 예에 지나지 않으며 활용 포인트는 굉장히 많을 것으로 기대된다.

4-4. Partitioned Index의 생성과 Rebuild시

인덱스 생성은 전체 데이터에 대해서 해당 컬럼의 Value로 Sorting을 하기 때문에 대용량의 테이블인 경우 Create, Reuild시 많은 시간이 필요하게 된다. Partitioned Index를 만들게 되면 Index의 생성 및 관리를 보다 효율적으로 할 수 있게 된다.

l 인덱스의 생성 절차

Ø Partitioned 인덱스를 Unusable로 생성 (Local, Global Partitioned Index)

CREATE INDEX EMP_IDX1 ON EMP (DEPTNO)

GLOBAL

PARTITION BY RANGE (DEPTNO)

(PARTITION PAR_10 VALUES LESS THAN (‘20’) TABLESPACE TBS1,

PARTITION PAR_20 VALUES LESS THAN (‘30’) TABLESPACE TBS2,

PARTITION PAR_30 VALUES LESS THAN (‘40’) TABLESPACE TBS3,

PARTITION PAR_40 VALUES LESS THAN (‘50’) TABLESPACE TBS4,

PARTITION PAR_MAX VALUES LESS THAN (MAXVALUE) TABLESPACE TBS5)

UNUSABLE;

Ø Partition별 Parallel Rebuild (index1.sql, index2.sql ….을 독립적으로 수행)

ALTER INDEX EMP_IDX1 REBUILD PARTITION PAR_10 PARALLEL 4; ---à index1.sql

ALTER INDEX EMP_IDX1 REBUILD PARTITION PAR_20 PARALLEL 4; ---à index2.sql

ALTER INDEX EMP_IDX1 REBUILD PARTITION PAR_30 PARALLEL 4; ---à index3.sql

ALTER INDEX EMP_IDX1 REBUILD PARTITION PAR_40 PARALLEL 4; ---à index4.sql

ALTER INDEX EMP_IDX1 REBUILD PARTITION PAR_MAX PARALLEL 4; ---à index5.sql

DA의 활용 - 10. 데이터 아키텍처를 활용한 이종(異種) 시스템 통합

Lee화식 — Mon, 14 May 2012 14:53:03 +0900

10. 데이터 아키텍처를 활용한 이종(異種) 시스템 통합

산업이 발전함에 따라 시너지 효과를 노린 경쟁력 확보를 위해 인수 합병을 통한 기업통합이 매우 빈번하게 일어나고 있으며 갈수록 이런 현상은 더욱 거세질 전망이다. 기업이 통합된다는 것은 여러 가지의 많은 변화를 의미하지만 그 중에서 빼 놓을 수 없는 것은 기업의 핏줄이라고 할 수 있는 정보시스템의 통합이다. 사실 모든 면에서 기업이 통합되었더라도 정보시스템이 통합되어 있지 않았다면 그것은 진정한 하나의 기업이라고 할 수 없고, 당연히 본래 통합의 목적인 시너지 효과를 얻는 것도 거의 불가능 하다.

이처럼 정보시스템의 통합이 하루라도 빨리 이루어지는 것은 매우 중요하지만 그게 어디 말처럼 쉬운 일이 아니질 않는가? 마치 실핏줄까지 모두 정밀하게 연결해야 하는 접합 수술처럼 오랫동안 전혀 다른 구조로 관리되었던 시스템을 하나로 통합한다는 것이 결코 쉬울 수가 없다. 마치 처음부터 원래 하나였던 것처럼 두 개 시스템의 모든 과거 데이터까지 완벽하게 통합하여야 한다면 그건 정말 어려운 일이다.

사실 많은 업체들이 엄청난 대형 시스템을 무사히 통합했노라고 자랑하고 있지만 그들에게 몇 가지 묻고 싶은 것이 있다. 첫 번째 질문은 피인수 기업의 데이터를 과연 얼마나 제대로 살려왔느냐는 것이다. 다시 말해서 고객 관련 데이터처럼 반드시 살려와야 할 데이터만 가져오지 않았느냐는 것을 묻고 있는 것이다. 이것은 엄밀히 말해서 시스템을 통합한 것이 아니라 고객을 통합한 것에 불과하다. 다른 의미로 보면 갑자기 엄청난 수의 고객이 다른 곳에서부터 이월되어 온 것을 처리한 것이나 별반 다를 것이 없다는 것이다.

두 번째로 묻고 싶은 질문은 통합을 하면서 기존 시스템의 문제를 얼마나 해결하였느냐에 대한 것이다. 옛말에 ‘떡 본 김에 제사 지낸다’는 말이 있다. 어차피 수술을 해야 한다면 지금껏 꼭 하고는 싶었지만 여러 가지 사유로 인해 차마 손댈 수 없었던 것을 이번 기회에 같이 해결해야만 하지 않겠느냐는 것이다. 물론 근본적으로 개선된 차세대 시스템을 구축하는 일은 통합 후에 본격적으로 논의될 수도 있겠지만 사실 그것이 언제가 될지도 확실하지 않고, 현재의 문제를 그대로 방치한다면 계속해서 문제가 발생될 것이라면 통합 프로젝트를 수행하면서 최대한의 조치를 하도록 해야 할 것이 아니겠는가?

세 번째 질문은 시스템 통합에서 데이터 아키텍처를 제대로 수립하였느냐에 대한질문이다. 시스템 통합이란 일반적으로 대부분이 데이터 통합이라 할 수 있기 때문에 통합을 잘하기 위해서도 그러하고, 앞으로의 유지·보수에도 큰 보탬이 되며, 향후 차세대 시스템을 구축할 때에도 중요한 참조자료가 될 수 있는 데이터 아키텍처를 제대로 수립하였느냐는 정말 의미가 있다. 천신만고 끝에 엄청난 데이터를 통합하였는데 어찌 당연히 남아 있어야 할 데이터 아키텍처가 없다는 것인가! 그렇다면 상호 보유한 데이터 집합을 정확히 모르면서 도대체 무슨 재주로 통합을 했다는 말인가? 그럼에도 불구하고 과연 그 결과를 믿어도 좋겠는가?

필자는 얼마 전에 10테라바이트가 넘는 두 개의 통신회사 시스템을 통합하는 프로젝트에 직접 참여한 적이 있다. 한 쪽은 세계적으로 유명한 어떤 ERP패키지를 사용하고 있었고, 다른 한 쪽은 자체 개발한 시스템이었다. 물론 H/W, DBMS, 프로그래밍 언어까지 같은 것이라고는 하나도 없었으며, 단지 비슷한 상품을 취급한다는 것뿐이었다. 처음 양쪽 시스템을 파악해본 후 첫마디 소감은 “여기 두 대의 라디오가 있는데 하나는 트랜지스터 라디오이고, 다른 하나는 진공관 라디오였다. 둘 다 소리는 나지만 부품과 회로는 어디에도 닮은 곳이 전혀 없다”라고 표현했었다.

이 말은 마치 두 라디오에서 소리는 나는 것처럼 어쨌거나 각사의 업무는 처리되고 있었지만 각 시스템의 내부를 살펴보면 정말 닮은 곳을 전혀 찾아볼 수 없었다는 것이다. 어디나 똑 같은 모양으로 있어야 할 것으로 보이는 ‘고객’부터 전혀 달랐다. 한 쪽 시스템의 고객은 ‘가입의 주체’인 사람(법인 포함)만의 집합이었고, 다른 한 쪽은 분명히 명칭은 ‘CUSTOMER’로 되어 있지만 사람이나 법인과 같은 개체 집합이 아니라 청구계약을 맺을 때마다 개체가 생성되는 행위 집합이었던 것이다. 더욱 놀라운 것은 개발자들이 그 집합을 지금까지 행위의 주체가 되는 사람이나 법인의 집합으로 생각해 왔고, 그대로 CRM을 해 왔다는 것이다.

이 두 회사는 얼마 전까지는 서로 경쟁 관계에 있었기 때문에 각자 보유한 상품들에는 매우 독특한 것들이 많았다. 유사한 상품을 통합하려고 해도 아직 그 상품을 사용하고 있는 가입자들이 많이 남아 있기 때문에 설사 이제 더 이상 그 상품을 새롭게 판매는 하지 않더라도 무조건 버릴 수도 없었다. 통신회사의 상품이란 판매하면 그만인 것이 아니다. 기본료와 각종 서비스를 특별하게 묶은 것을 상품이라고 하므로 일단 판매하면 그 상품을 사용하는 가입자가 모두 탈퇴하거나 다른 상품으로 옮겨 가야만 없앨 수가 있다.

상품이 시스템에 완벽하게 반영되어야 한다는 것은 거기에 따르는 수 많은 관리들도 같이 감안되어야 한다는 것을 의미한다. 결국 이 말은 어느 한쪽을 무조건 다른 쪽에 맞추는 통합이 아니라 두 시스템을 혼합하여 제3의 시스템이 만들어져야 한다는 의미가 되는 매우 어려운 프로젝트였다. 물론 시스템의 전반적인 기반이나 기준은 인수를 하는 기업이 되었지만 두 시스템을 머지(merge)해야 한다는 것이 일을 매우 복잡하게 만들었다. 그것은 양쪽 모두를 명확히 알지 않으면 결코 머지를 할 수 없기 때문이었다.

집합적으로 본다면 ‘A’와 ‘B’의 합집합(union)을 구해야 한다는 것을 말한다. 합집합이란 단순히 집합이 결합된 것을 의미하는 것이 아니라 ‘최소공배수’ 집합을 의미한다. 즉, 단순 결합은 ‘UNION ALL’을 말하지만 이것을 다시 유일한(distinct) 개체 집합으로 만들어 낸 것이 바로 합집합이다. 이처럼 완전히 상이한 두 시스템의 데이터 집합으로 제3의 최소공배수 집합을 만들어야 한다는 것은 필연적으로 데이터 모델이 크게 영향을 받게 되었다는 것을 의미하며, 당연히 거기에 관련된 애플리케이션도 같이 영향을 받을 수 밖에 없었다는 것을 뜻한다.

어차피 제3의 데이터 모델이 만들어져야 한다면 기준이 되는 인수 기업이 가지고 있던 심각한 문제들을 도출하여 이번 기회에 같이 해결해야 하는 것이 옳다. 필자는 오히려 이 문제 때문에 ‘갑’과 충돌을 겪었다. ‘을’인 우리가 힘이 들더라도 이 시스템의 중대한 결함을 이번 기회에는 반드시 같이 고쳐야 한다고 의욕을 보이고 있는데, 오히려 ‘갑’이라는 사람들이 통합 프로젝트에 부담이 될 수 있으니 그냥 가자고 하는, 어쩌면 앞뒤가 뒤바뀐 설전을 벌렸다. 그러나 필자가 누구인가? 옳다고 생각하면 절대 양보를 하지 않는 사람이다. 후일담이지만 1년이 채 지나지도 않아 그렇게 수정하지 않았다면 큰 사단이 벌어질 수 있는 모종의 일을 겪고 난 그들은 자신들의 반대를 무릅쓰고서도 회사를 위해 정말 귀중한 역할을 해 주었다는 것에 깊은 감사를 보냈다.

데이터 모델은 시스템의 골격이기 때문에 함부로 수정될 수 없는 것이다. 새롭게 시스템을 구축하거나 이처럼 통합 프로젝트를 통해 대수술을 하는 경우에만 할 수 있는 – 즉, 쉽게 기회가 오지 않는 – 귀중한 기회이므로 이것을 그대로 날려 보낸다는 것은 결코 옳은 일이 아니다. 결국 통합 프로젝트의 최대의 관건은 데이터의 통합일 수 밖에 없으므로 이를 위해서 우리가 할 수 있는 가장 바람직한 일은 바로 두 시스템의 현행 데이터 모델을 정확히 분석하는 일이었다. 우리는 이를 위해서 매우 정밀한 현행 데이터 아키텍처를 수립하였다. 매우 방대한 시스템을 리버스해야 했기 때문에 가장 어려운 것은 기존의 자료가 지극히 부실하다는 것과 어느 정도 깊이 파고들었을 때 구체적인 대답을 해 줄 사람이 거의 존재하지 않았다는 것이었다.

우리는 이러한 현실적인 문제점들을 해결하기 위해 다양한 모델링 기법을 활용하였다. 여기서 사용한 ‘수사력을 극대할 시킬 수 있는 방법’은 앞으로 설명할 데이터 모델링 단계에서 아주 상세하게 언급하게 될 것이다. 특히 자료를 조사하거나 사람들과의 인터뷰에서는 도저히 확인할 수 없는 많은 것들은 데이터를 직접 분석해 봄으로써 많은 진실(?)을 캐 낼 수가 있었다. 물론 마치 모국어를 자유롭게 사용하는 ‘NATIVE SPEAKER’처럼 수백 라인의 애플리케이션으로 작성해야 할 처리를 단 십여 라인의 SQL로 데이터와 자유로운 대화(?)를 할 수 있는 능력을 가진 사람들이 있어 데이터 속을 헤집고 다녀보면 정말 우리에게 유익한 다양하고 많은 정보들을 얻을 수가 있다.

어쨌든 앞서 설명했던 현행 시스템을 리버스해서 두 시스템의 물리적 모델까지 만들어 보았더니, 두 시스템의 데이터 모델의 구조가 다른 것은 차치하고라도 각 엔터티의 집합적인 의미와 구성까지도 너무나 상이하다는 것을 알 수 있었다. 그러나 이렇게 다른 것을 그저 조사만 해 두는 것은 큰 의미가 없다. 이들을 이상적인 목표 데이터 모델이 되기 위해서는 어디를 어떻게 보완하고, 어떤 변화를 주어야 하는지 같이 평가해 두는 작업이 반드시 필요하다. 우리는 이 작업이 바로 앞서 여러 차례 소개했던 물리적 데이터 모델을 ‘논리화’하여 논리적 모델로 작성해 가는 과정이라는 것을 잘 알고 있다.

논리적 모델에는 ‘가상’의 엔터티, 릴레이션쉽, 속성을 만들 수 있기 때문에 얼마든지 현재의 물리적 형태와 이를 보완시킨 논리적 모델을 같이 표현할 수 있다. 우리는 논리화를 통해 의미를 재해석한 두 시스템의 논리적 모델을 작성함으로써 두 시스템의 진정한 내용 상의 차이를 분명히 규명하였다. 각각의 데이터 모델이 구체화 되었기 때문에 이들을 머지한 제3의 집합을 결정할 만반의 준비가 이루어졌다. 가장 먼저 실시한 작업은 기본이 될 인수기업 시스템의 논리적 모델을 대상으로 지금까지 밝혀지지 않았던 여러 가지 특징과 심각한 문제점, 보다 바람직한 구조에 대한 개념 전달하기 위한 특별 워크샾이었다.

통합될 시스템에 대해서도 유사한 워크샾을 가졌는데 주로 인수기업 시스템의 구조와 차이점을 비교하고 여기에 있는 데이터가 어떤 형태로 머지되고 전환되어야 하는지에 대해 설명하는 방향으로 전개되었다. 마치 자식을 가진 중년남녀가 재혼을 할 때 여자쪽 가족들이 대가족을 거느린 시가로 들어가야 할 때 자식들이 해야 할 처신을 설명하는 것과 비슷한 상황이었다고 이해할 수도 있겠다.

두 시스템의 현행 데이터 아키텍처를 수립하는 일이 완료되고, 이제 전체적인 통합 컨셉이 잡혔기 때문에 이제 본격적으로 목표 데이터 아키텍처를 수립하기 시작하였다. 두 시스템의 최소공배수 – 물론 인수기업을 보다 비중있게 처리한 형태이기는 하지만 – 를 만드는 작업은 단지 통합된 데이터 모델을 만든다는 것보다 보다 발전적인 형태의 데이터 모델을 만들어야 한다는 방향으로 진행되었다. 특히 이 회사는 현재의 시스템에 상당히 만족하고 있는 상태였기 때문에 앞으로 당분간은 새로운 차세대 시스템에 투자할 생각이 없었다. 이 말은 이번 기회에 최대한 숙원사업들을 해결해야 한다는 당위성을 의미하고 있기도 하다.

제3의 목표 데이터 모델을 결정해 갈 때의 가장 큰 어려움은 거의 대부분의 데이터 모델에 영향을 미치는, 마치 등뼈와 같은 위치에 있던 핵심 엔터티를 근본적으로 개념부터 바꾸어야 한다는 것을 관철시키는 것이었다. 사람에게도 중심이 되는 등뼈를 바꾸는 수술은 엄청난 대수술이라고 겁을 먹듯이 데이터 모델의 등뼈에 해당하는 엔터티부터 근본적으로 바꾸어야 한다고 했을 때 많은 사람들이 두려워하는 것은 어쩌면 당연한 일이었다. 특히 이 시스템의 모체는 유명 패키지였기 때문에 그 두려움은 더욱 컸다. 그러나 상식적으로 보아도 그 모델이 가지고 있는 엄청난 문제는 반드시 해결되어야 했기 때문에 설득은 가능했고, 이제 와서 그 판단이 옳았음에 행복해 하고 있다.

필자가 이 사례를 자세하게 설명하는 것은 시스템 통합을 위한 목표 데이터 아키텍처의 수립에서도 정말 필요한 교정이라면 그게 아무리 힘이 들고 어렵다고 하더라도 반드시 결행해야만 한다는 것을 강조하고자 함이다. 비록 참으로 어려운 과정을 거쳤지만 시스템의 근본인 데이터를 이렇게 구체화 함으로써 거의 모든 데이터를 과거의 이력까지 통합할 수 있었고, 그 와중에서 엄청난 오류 데이터를 정제하는 작업도 같이 병행하여 진정한 데이터 기반을 수립할 수 있었던 것이다.

과거에 발생한 거의 모든 데이터를 소급해서 모두 이행하기로 했기 때문에 이루 말로 형언할 수 없을 만큼의 어려움도 있었다. 두 시스템에는 고객에게 청구를 하고 납입이 되면, 어떤 청구 건들이 어떤 납입 건에 의해 수납되었는지를 나타내는 ‘수납내역’이 있었는데 그 관리방법에서 큰 차이가 있었다. 더구나 그 데이터는 6개월 분이 약5억 건을 상회하는 대용량의 테이블이기도 했다. 청구에는 매월 청구한 합계가 있고, 수십 가지로 나누어져 관리되는 청구항목별 금액이 있다. 패키지로 되어 있는 인수기업의 시스템은 수납내역을 청구항목별로 관리하고 있지만 합병된 기업에서는 월합계 별로 내역을 관리하고 있었다.

여러분도 잘 알고 있겠지만 상세한 소스 데이터를 이용해 집계를 하는 것은 어려울 것이 없지만, 집계된 소스 데이터를 가지고 거꾸로 세부내역을 만든다는 것은 매우 어려운 일이다. 마치 회계에서 원가를 배부하듯이 세부내역을 강제로 배부해서 만들어야 하는데 어떤 기준으로 배부할 것인가도 문제이고, 소수점 처리 때문에 가로를 맞추면 세로가 틀리게 된다는 것도 보통 문제가 아니었다. 더구나 이미 회계에 모두 반영되어 함부로 수정할 수도 없는 과거 데이터를 있지도 않은 세부내역을 역으로 다시 만들어낸다는 것은 참으로 어려운 일이 아닐 수 없다. 그러나 이런 데이터에 대해서 단1원까지도 틀리지 않게 과거의 모든 데이터를 통합하였다는 것은 매우 의미있는 일을 하였다고 믿는다.

이런 일은 오로지 데이터를 진정으로 사랑하는 사람들만이 할 수 있는 것이다. 필자는 ‘대용량 데이터베이스 솔루션’에서 가곡을 하는 사람들이 술자석에서 노래를 시키면 대중가요를 부르는 이유를 아느냐고 질문한 적이 있다. 그것은 바로 자신이 모든 것을 바치고 있는 가곡을 진정으로 사랑하기 때문이라고 하였다. 여러분이 진정 정보시스템에 평생을 바치고자 하는 사람이라면 진심으로 데이터를 사랑해야 한다. 사랑이 없으면서 혼을 넣어 매진할 수 없다. 정말 진정으로 데이터를 사랑할 자신이 없는 사람이라면 이 책을 더 이상 읽을 필요도 없을 것이라 생각한다.

전사적 아키텍처는 일관성이 없는 시스템 설계를 방지하고, 개발에 대한 근시안적인 결정과 성능이 최적화가 되지 않은 결과와 관련 비용의 낭비를 막을 수 있는 체계적인 방법이 될 것이다. 전사적 아키텍처가 미치는 영향은 조직간에 완전하고 일관된 정보를 공유하고, 변화에 효과적으로 대응할 수 있게 하는 능력이다.

특히 시스템의 근간이랄 수 있는 데이터를 제대로 설계하는 전사적 데이터 아키텍처가 없다면 시스템은 골격이 부실한 선천성 불구의 모습이 될 수 밖에 없을 것이다. 더구나 대부분의 경우 이런 문제의 해결을 위해서 자꾸만 복잡한 애플리케이션을 동원해서 막으려고 하기 때문에 갈수록 더욱 심각한 양상으로 나타나게 되리라는 것은 자명하다. 조직은 불완전한 정보로 인하여 본질적으로 잘못되고, 부적합하고, 값비싼 결정을 하게 되는 위험에 계속해서 직면하게 된다. 이로 인하여 조직은 언제나 완전한 만족을 얻지 못하게 되고, 부족한 품질과 불완전한 데이터에 익숙하게 길들여 진다. 결국 아키텍처가 없다면 조직은 변화에 대한 자극에 담당자가 국부적으로만 반응하는 형태로 나타나게 되고, 전체적으로는 계속해서 느리고 일관성이 없는 형태로 진행될 것이다.

혹 전사적 아키텍처는 허황된 생각이고, 시간과 노력을 낭비하는 것이라고 사람들이 생각할지도 모른다. 그러나 축적되고 자발적인 노력이 설명하듯이 조직의 정보화담당관(CIO)은 전사적 아키텍처를 생성하기 위해 사실적이고 재사용 가능한 접근 방법인 전사적 아키텍처 프레임워크를 정의해야 한다. 특히 기업의 정보시스템 구성에 직접적인 설계의 근간을 이룰 데이터 아키텍처를 전문적으로 수립, 관리할 조직부터 만들어 가는 것이 우선적으로 필요하다. 결국 이 모든 것들이 인간에 의해 좌우되고, 인간이 중심이 되어야만 가능한 일이기 때문이다. 만약 시기를 놓쳐 버린다면 그만큼 뒤로 미루어 지는 것이 아니라 만회하기 힘든 커다란 기회손실로 돌아 온다는 사실을 명심해야 할 것이다.

DA의 활용 - 9. 데이터 아키텍처를 이용한 데이터 이행(migration)

Lee화식 — Mon, 14 May 2012 14:52:43 +0900

9. 데이터 아키텍처를 이용한 데이터 이행(migration)

사실 데이터 아키텍처를 이용한 데이터 이행에 대해서는 이미 몇 번에 걸쳐 간단하게 언급을 했었다. 현행 데이터 아키텍처를 수립함으로써 현재의 매우 구체적인 데이터 정보가 리파지토리에 보관되어 있고, 목표 데이터 아키텍처를 수립하였다면 그것 또한 리파지토리에 관리되어 있으므로 이를 이용하여 명확한 매핑룰을 수립하는 것이 가장 이상적으로 데이터를 이행하는 방법이라 할 것이다.

데이터 이행 규칙이란 결국 데이터 집합 간의 변환·이동을 의미하는 것이므로 소스 집합을 알고, 결과 집합을 안다면 그리 어렵지 않게 데이터를 이행을 할 수 있다. 비슷한 내용을 앞서 데이터 아키텍처를 이용한 EDW의 ETL을 설명할 때에도 언급했었다. 그럼에도 불구하고 여기서 별도로 데이터 아키텍처를 이용한 데이터 이행에 대해 부연하고자 하는 이유는 자신의 소임이 시스템 전체를 설계하는 일이 아니라 데이터 이행만 맡은 사람들을 위함이다.

일반적으로 대다수의 프로젝트에서는 데이터 이행만을 전담하는 조직이 별도로 구성된다. 상식적으로 본다면 그들은 반드시 현행 데이터 구조와 목표 데이터 구조를 가장 정확하게 알아야 할 사람이어야 한다. 그러나 어디를 가 보더라도 데이터 모델링에 이들이 깊숙이 개입하는 경우를 찾아보기 힘들다. 도대체 데이터를 이행하려는 사람들이 데이터 구조를 모르고 어떻게 할 수 있는지 정말 이해하기 힘들지만 어쨌든 그렇게 해서라도 데이터는 이행이 되고 있는 것은 분명한 사실이다.

그러한 그들에게 엄청난 노하우가 있는 줄 알겠지만 사실은 데이터의 유형별 사례를 무수히 도출한 후에 애플리케이션에서 ‘CASE-BY-CASE’로 알고리듬을 작성하여 해결하고 있었던 것이다. 심지어 소스코드가 2만 라인이 넘는 것도 본 적이 있었고, 데이터 처리에 15일 동안이나 수행되는 애플리케이션을 본 적도 있다. 어떤 시스템은 차세대 시스템이 구축된지 2년 만에 EDW프로젝트를 하였는데 새 시스템이 가동된지 얼마 되지 않았기 때문에 데이터들이 깨끗할 것이라 생각했었다. 그러나 이런 예상은 크게 빗나갔고 어떻게 저런 데이터들이 쌓여 있는데도 시스템에 문제가 생기지 않는지 그저 놀라울 따름이었다.

데이터의 발생 형태가 조사된 것들은 매핑이 되었지만 그렇지 않은 경우는 애플리케이션의 기타조건(IF문의 ELSE 조건)에 의해 지정해둔 기본값(default value)이 들어가 있었다. 처음에는 어떤 일자 속성 왜 ’01-01-0001’로 되어 있는 데이터가 그렇게 많은지 이해할 수가 없었다. 물론 만약 현행과 목표 데이터 아키텍처가 대동소이하였다면 매핑이 단순해지는 것은 당연하다. 이런 경우라면 데이터 이행이 별로 어려울 것이 없다. 그러나 잘 생각해보자. 아마 어떤 시스템에서라도 지금 재구축 대상인 기존 시스템의 데이터 모델이 매우 우수했다고 하지는 못할 것이다.

엄청난 비용을 들여 재구축을 하고자 하는 시스템의 데이터 모델이 이와 유사하다는 것은 분명 목표 시스템의 데이터 아키텍처에 근본적인 문제가 있다고 밖에 해석할 수가 없다. 천문학적인 비용을 들여서 구축한 시스템의 골격이 과거와 유사했다는 것은 이미 데이터 이행의 문제가 아니지 않는가! 어찌 재건축하는 아파트의 설계도가 옛날 연탄 아궁이의 저층아파트 설계도와 유사할 수가 있다는 말인가! 자재만 새 것을 사용했다고 그걸 재건축 아파트라 할 수 있는가? 필자는 만약 데이터 이행이 이렇게 진행되고 있다는 것은 이미 그 프로젝트가 어떤 수준으로 진행되고 있는지를 충분히 가름할 수 있다고 생각한다.

결국 지금까지는 우리의 모델링 능력에 문제가 있었기 때문에 현행과 목표 시스템의 데이터 구조가 유사했고, 이로 인해 단순한 데이터 매핑이 가능했던 것이라고 결론을 내릴 수 밖에 없다. 이런 형태에서라면 집합의 개체 간의 매핑은 무시하고, 단지 속성값을 새롭게 변환하는 정도만 처리해도 충분할 수 있겠다. 그렇다면 사실 그것은 오히려 더욱 슬픈 일이라 하지 않을 수 없겠다.

일단 시스템 설계자와 데이터 이행팀이 조직부터 나누어져 있는 것이 영 마음에 들지 않는다. 당연히 현행 시스템의 데이터 아키텍처를 리버스하는 것부터 서로 힘을 합쳐야 한다. 먼저 시스템의 골격이 되는 데이터를 구체적으로 정의하는데 힘을 합쳐야 할 것이며, 나중에 개발 단계에 가서 각기 목표 시스템의 애플리케이션을 개발하거나 데이터 이행을 위한 애플리케이션을 개발하면 될 것이다. 데이터를 정제하는 일 또한 데이터 구조를 정확히 이해하는 것부터 출발되어야 한다. 무엇이 옳은 형태인지 조차 모르면서 어떤 것이 잘못된 데이터인지 어떻게 알 수 있겠는가?

데이터를 이행하는 애플리케이션에다 수 많은 예외 처리를 일일이 지정하려고 애쓰지 말고, 규칙을 벗어나는 데이터를 정제를 하여 규칙을 준수하도록 교정하고, 애플리케이션에서는 단지 규칙을 준수한 집합만을 처리하도록 하는 것이 가장 바람직한 처리 방법임을 명심하기 바란다. 관계형 데이터베이스를 사용한다면 SQL이 바로 집합을 처리하는 개념으로 되어 있기 때문에 길어도 몇 십 라인의 SQL로 모든 처리를 하도록 할 수도 있다.

얼마 전 금융권으로서는 드물게 오픈 시스템으로 다운사이징을 한다고 해서 관심의 초점이 되었던 어떤 프로젝트에서는 오픈일자가 가까워졌는데도 아직 한 번도 완전하게 모든 데이터를 이행해보지 못하였다. 특정 부분을 처리하는 데만 약 200시간이 넘게 걸렸기 때문에 결과의 이상유무 보다 그들을 더욱 조급하게 만든 것은 작업이 제 시간에 처리될 수 없다는 것이었다. 애플리케이션을 분석해 본 결과 앞서 지적한 유형 그대로작성되어 있었다. 이 애플리케이션들을 거의 SQL하나씩으로 대체하여 다시 작성함으로써 모든 작업을 5시간 이내에 종료될 수 있었다. 수만 라인에 해당 하는 애플리케이션 소스코드는 수십 라인의 SQL로 모두 바뀌었으니 그것이 그들에게는 참으로 놀라운 경험이었을 것이다.

이와 같이 데이터 이행은 수 많은 예외 경우를 처리하는 것이 아니라 데이터와 데이터 간의 매핑에 불과하다는 사실을 잊지 말기를 바란다. 이를 위해서는 현행과 목표 시스템의 데이터 아키텍처를 명확하게 수립하는 것 말고는 절대 더 좋은 대안이 없음을 명심하여야 할 것이다.

DA의 활용 - 8. 암초에 부딪힌 개발 프로젝트의 해결

Lee화식 — Mon, 14 May 2012 14:52:23 +0900

8. 암초에 부딪힌 개발 프로젝트의 해결

필자는 전문적으로 컨설팅을 하면서 특히 문제가 복잡하게 엉켜있어서 획기적인 해결사를 원하는 프로젝트를 주로 수행해 왔기 때문에 진행과정에서 방향을 잃고 표류하고 있는 프로젝트를 접할 기회가 아주 많이 있었다. 물론 운동선수에게 사용하는 ‘슬로우 스타터(slow starter)’라는 말이 있듯이 일정 시간이 지나야만 몸이 풀려 제기량을 발휘할 수 있는 경우도 있을 수 있기 때문에 진행 초기에 발생하는 약간의 불협화음은 마치 신혼초기의 부부가 미묘한 헤게모니 쟁탈전을 벌리듯이 얼마든지 있을 수 있는 일이라 하겠다.

다만 그것이 일정기간을 넘지 않는 조정기간이어야 함에도 불구하고 계속해서 합의점을 찾지 못하고 있다면 프로젝트는 불협화음을 넘어 감정싸움으로 번질 것이며, 이 프로젝트의 미래는 불을 보듯이 분명해진다. 여러 사람이 한 배를 타고 열심히 노를 젓고 있지만 서로 제각기 다른 방향으로 노를 젓고 있다면 힘만 들었지 배는 결코 앞으로 나가지 못한다. 그래서 우리 속담에도 ‘사공이 많으면 배가 산으로 올라 간다’라고 하지 않았는가! 물론 기술력을 바탕으로 강력한 카리스마를 가진 사람이 있었다면 설혹 약간의 불만이 수면 아래에서 일어나더라도 대세의 위력에 눌려 같은 방향으로 나갈 수 있겠지만, 도토리 키 재기를 하듯이 서로 자기 주장만 할 뿐이지 남을 꼼짝하지 못하게 설득할 수 있는 사람이 없다면 싸움만 커졌지 문제는 절대로 해결되지 않는다.

이런 상황에서 해결사로 투입되어 보면 이미 그들 간에는 같이 식사도 하러 가지 않는 서먹한 사이가 되어 있고, 서로 상대방 때문에 일이 꼬이게 되었다고 헐뜯고 있다. 필자는 최소한 ‘기술세계에서는 논쟁(argument)이란 없다’라고 생각하는 사람이다. 기술세계란 기분이나 감(感, feeling)으로 좌우되는 것이 아니라, 객관적이고 명백한 근거에 의해 좌우되기 때문에 동일한 ‘판단의 잣대’를 가지고 측정한다면 ‘결론’이라는 하나의 답이 있을 뿐 갑론을박할 일은 결코 있을 수 없다는 것이다.

바보가 아니라면 어느 결코 누구도 아니라고 할 수 없는 지극히 상식적이고 분명한 판단의 잣대를 어떻게 공유할 수 있느냐에 문제의 해답이 있다. 그것은 제각기 자기 주장만 하던 사람들이 ‘동일한 잣대’에 동의하는 순간부터 이제 같이 증거를 확인하여 결론을 내는 일만 남아 있기 때문이다. 이러한 잣대는 그 누구도 거역할 수 없는 상식적인 논리를 근거로 하여야만 공감을 얻을 수 있다. 상식을 부정하는 순간, 그 사람은 저절로 이미 바보가 되어 버리기 때문이다.

만약 시스템 설계과정에서 불협화음이 계속되고 있다면 그것은 분명히 데이터 모델링이 원인이었을 가능성이 크다. 물론 데이터 모델링과 프로세스 모델링이 아닌 제 삼의 문제라면 여기서는 생각해 볼 필요가 없을 것이다. 일반적으로 프로세스 모델링은 개발팀 별로 업무를 나누고, 개인별로 제각기 진행하면서 열심히 기록만 하고 있을 뿐이며 남들과 상호 연관성을 체계적으로 검증하지 않고 수행하기 때문에 설사 약간의 문제가 있다고 하더라도 그게 밖으로 쉽게 나타나지 않는다.

만약 데이터 모델에 문제가 없이 프로세스에만 문제가 있다면 개발 단계에 가서도 해당 애플리케이션 개발자 자신에게 국한될 뿐이기 때문에 큰 문제로 부각되지는 않는다. 반면 데이터 모델은 특정 개발자 혼자만 사용하는 것이 아니라 여러 애플리케이션에서 같이 사용하는 것이며, 애플리케이션의 처리방법에 직접적인 영향을 주는 뼈대이기 때문에 이것이 명확하지 않고, 자꾸만 흔들린다면 문제는 금방 크게 불거져 보이게 된다. 물론 약간의 조정만으로 쉽게 해결이 된다면 문제가 될 것도 없겠지만 만약 그렇지 않다면 상당히 심각한 문제로 발전될 가능성이 높다.

이러한 문제는 한 차원 높은 기술력을 가진 모델링 리더의 지휘 하에 체계적이고 구체적인 모델링을 실시하지 않는 한 개발이 진행되어 감에 따라 계속적으로 증가하게 될 것이다. 아직도 개발해야 할 것은 첩첩 산중으로 남아 있는데 자꾸만 수정해야 할 것들이 발목을 잡고 있으니 어찌 프로젝트가 표류하지 않을 수 있겠는가!

이것은 시스템의 본질인 데이터를 대충 설계해 놓고 애플리케이션만 가지고 어떻게 해결해 보려고 하기 때문에 받아야 하는 응분의 대가라고 보아야 한다. 데이터는 여려 곳에서 같이 사용하는 공유물이기 때문에 어느 한쪽을 위해 근시안적으로 함부로 수정했다가는 경우에 따라 일파만파 파장이 생겨날 수도 있다. 만약에 이런 상황이 되었다면 이제라도 그 근본적인 원인인 데이터를 제대로 해결해야 함에도 불구하고 지금까지 억지로라도 고쳐 놓은 애플리케이션을 또 다시 고치기가 싫고, 어쩌면 전체를 내다보고 합리적인 데이터 모델링을 할 자신도 없기 때문에 계속해서 애플리케이션을 뜯어 고치는 빈곤의 악순환이 계속되어 프로젝트는 끝없는 혼란에 빠져들고, 개발은 지연되며, 온 몸은 만신창이가 되어 있는 프로젝트로 발전하게 되는 것이다.

이런 프로젝트의 해결책을 찾기 위해서 필자는 반드시 데이터 모델을 우선적으로 검증한다. 하지만 데이터 모델을 피상적으로 검증해서는 아무 것도 얻어 낼 수가 없다. 여러분들이 만약 셜록홈즈와 같이 예리한 눈을 가지고 있다면 조금만 분석해 보아도 그러한 문제가 발생한 원인을 바로 찾아낼 수가 있다. 물론 앞서 설명했던 데이터 아키텍처를 단계적으로 수립해 가면 저절로 문제점과 해결책이 모두 도출된다.

개발 중인 시스템의 데이터 아키텍처를 수립하기 위해서는 기존의 설계자료를 최대한 활용함으로써 시간을 절약해야 한다. 체계적인 방법론을 가지고 구체적으로 접근해 가면 드디어 현재의 문제점이 보이기 시작한다. 이것을 어떻게 개선하여야 할 것인지를 결정해 가는 방법은 앞서 설명했던 데이터 모델의 ‘논리화’ 기법을 활용한다. 논리화를 표현하는 기법을 활용하면 물리적 모델(현재 설계되어 있는 데이터 모델, 즉 실선으로 그려진 모델)과 개선하고자 하는 논리적 형태(가상의 집합으로 표현되어 있는 모델)를 같이 그려 넣을 수가 있다고 했다. 이 두 가지 형태를 같이 표현하였다는 것은 이미 기존의 데이터 모델과 애플리케이션들이 어떻게 수정되어야 하는지를 보다 분명하게 나타내었다는 것을 의미하고 있다.

표류하고 있는 프로젝트를 이러한 방법을 적용하여 해결할 수 있다는 것을 여러분에게 보다 강하게 호소하고 싶어서 간단한 실사례를 한 가지 소개하기로 하겠다. 몇 년 전 금융권의 어떤 업체에서 대형 차세대 시스템을 구축하고 있었다. 초기에는 패키지 도입 검토를 위해 거의 1년여를 허송 세월을 보냈고, 뒤늦게 자체 개발로 가닥을 잡아 설계부터 다시 시작했으나 불협화음은 끊이지를 않았다. 이미 시간을 많이 소비했기 때문에 마음은 조급했고, 조금이라도 빨리 하기 위해 서두르다 보니 서브시스템 별로 잘게 나누어 각자 자기 일에만 열심이었다.

모름지기 세상에 있는 모든 것은 각자 독립적으로만 존재하는 것이 아니라 서로 간에 미묘한 역학관계를 가지고 있으며, 물리적 혹은 논리적 종속 관계를 가지고 있기도 하다. 다시 말해서 같이 먼저 결정해 두어야 할 것이 있고, 이를 바탕으로 각자가 알아서 할 일이 있음에도 불구하고 무조건 나누어서 제각기 설계를 했다면 제대로 진행될 수 없는 것은 지극히 당연한 일이다. 이 와중에서 프로젝트 매니저는 책임을 물어 교체되었고, 관리자들은 무조건 일정만 가지고 아우성을 하고 있었다. 물론 일정을 가지고 사람을 못살게 하니 시간이 되면 무언가 산출물이 나오기는 했다. 그러나 그 내용물의 품질이 어떠 했을지에 대해서는 굳이 말할 필요도 없겠다.

필자와 오랜 교분을 가지고 있던 새로 부임한 프로젝트 매니저의 간곡한 요청으로 잠시 프로젝트의 진행 상태와 산출물을 분석해 보고 크게 놀라지 않을 수 없었다. 사실 이 프로젝트에는 이미 개발업체 외에도 프로젝트 관리를 위해서 세계적인 대형 컨설팅 업체와 전문 프로젝트 관리조직(PMO, Project Management Officer)을 운영하고 있었다는 것이 더욱 놀라웠다. 방법론적으로는 체계적인 관리를 하고 있는 것이 분명했지만 그 내부의 설계 내용은 정말 기본조차 되어 있지 않았다. 그 이유는 바로 관리자들은 밖으로 드러나는 겉모양만 관리했을 뿐이지 그 속의 내용에 대해서는 모두 개발자들에게 맡겨 버렸기 때문이었다.

필자는 프로젝트 매니저에게 현재의 문제점은 데이터 모델에서부터 근본적으로 잘못되었기 때문이며, 지금까지 수행한 데이터 모델은 ‘이럴 수도 있다’는 정도의 추상적인 모습에 불과하다고 하였다. 만약 제대로 다시 모델링을 한다면 과거에는 애플리케이션에서 처리하였던 수 많은 규칙들까지 데이터로 도출하여 진정한 규칙기반으로 접근(Rule_based approach)을 하더라도 오히려 1/10로 엔터티 수를 줄일 수 있을 만큼 지금의 데이터 모델에 문제가 많다고 하였다. 만약 마음이 급하다고 해서 지금 이 데이터 모델로 프로세스를 설계하고, 개발까지 진행한다면 정말 엄청난 문제가 발생할 것이라 엄중히 경고하였다.

결국 필자의 의견을 받아들여 전면적으로 새롭게 데이터 모델링을 시작하게 되었다. 모델링의 상위 영역을 결정하기 위해서 초기에는 대부분의 설계 관련자들을 모두 참석시켜 같이 모델링을 진행하였다. 정말 놀라운 것은 어쨌든 나름대로 설계를 완료했다던 사람들이 모델링에 대한 기초적인 지식 조차 가지고 있지 않다는 것이었다. 초보자들을 훈련 시키듯이 모델링 교육을 시키고, 학습 효과를 높이기 위해 시험도 치렀다. 처음에는 불만을 가진 사람도 있었지만 워낙 강력한 카리스마를 가지고 리드해 갔기 때문에 모든 사람들이 한 방향으로 나아갈 수가 있었다. 모델링이 진행되면서 그 동안 결정하지 못하고 방치되었던 많은 사항들이 우선순위에 입각해서 결정되고, 이 결정이 다시 다음 결정에 ‘상수값’의 역할을 함으로써 수 없이 난무했던 ‘미지수’가 점차 없어지면서 모든 것이 뚜렷하게 가시화 되기 시작하였다.

짙게 드리웠던 검은 구름들이 걷히면서 많은 사람들은 이제 다시 서로 신뢰하게 되었고, 성공할 수 있다는 희망을 가지게 되었다. 단 4개월 만에 모든 데이터 설계가 완벽히 완료된 후 공식석상에서 프로젝트 매니저가 “난세에 영웅이 난다더니 그 어려웠던 시절에 혜성같이 나타나 우리를 구해 준 것에 정말 감사한다”는 말을 한 것을 잊을 수 없다. 특히 세계적인 컨설팅 업체의 기술책임자가 자신도 데이터에 대해서는 일가견을 가졌다고 생각했었는데 필자를 보고 “데이터에 관한 한 자신은 손톱이고 당신은 하늘이다”라고 자존심을 버리고 공개적으로 이야기 했던 것을 고맙게 생각한다.

얼핏 필자의 무용담을 이야기한 것 같아 약간은 쑥스럽기도 하지만 데이터 문제가 복잡하게 엉켜 있는 상태를 그대로 두고 일정에 쫓겨 무조건 불도저처럼 그저 앞으로 밀고 나가기만 한다는 것은 정말 무서운 일이라는 것을 좀더 피부로 느낄 수 있게 하기 위해 실제 경험담을 소개한 것이니 널리 이해하기 바란다.

DA의 활용 - 7. 데이터 아키텍처를 이용한 정보전략계획수립(ISP)

Lee화식 — Mon, 14 May 2012 14:50:32 +0900

7. 데이터 아키텍처를 이용한 정보전략계획수립(ISP)

이제는 누구도 정보기술이 기업의 경쟁력을 좌우한다는 것에 대해 이의를 제기하지 않을 것이다. 정보기술이 경영전략을 지원하고, 경우에 따라서는 경영전략을 창출하기도 한다. 또한 업무 프로세스를 획기적으로 개선하고 기업의 경쟁력을 높여 주는 중요한 역할도 하고 있다. 정보기술은 다른 분야 보다 발전 속도가 비할 수 없이 빠르다. 수 많은 개념들이 정신없이 등장하여 빨리 따라 오기를 강요하고 있다. 기업의 업무 전반에 걸쳐 어디 하나 정보기술이 빠져 있는 곳이 없고, 마치 살아 움직이는 생명체와 같이 제각기 변화를 갈망한다.

이런 과제들은 서로 밀점한 관련이 있고, 종속성을 가질 수도 있기 때문에 한 번 발을 잘못 들여 놓게 되면 계속해서 악수를 두어야 하는 경우가 비일비재하므로 섣불리 어느 하나를 함부로 손대기가 겁이 난다. 그렇기 때문에 정보전략은 매우 중요하다. 정보전략계획(ISP, Information Strategy Planning)은 앞으로 어떻게 정보화를 할 것인지 장기적인 방향을 세우는 것이다. 경영환경의 변화를 내다보고, 기업의 목표와 전략을 확인한 뒤에 어떤 정보기술을 어떤 방법으로 도입할 것인지를 결정하는 것이다. 그래서 기업의 정보전략은 기업의 경영환경과 경영전략을 검토하는 것에서부터 시작되어야 한다. 만약 경영환경이 급격히 변하고, 이에 따라 경영목표와 전략이 바뀌면 기업은 당연하게 정보전략을 새롭게 검토하여야 한다.

보다 경쟁력 있는 시스템이 되기 위해서는 전사적으로 통합된 체계로 개발되고 운영되어야 하는 것은 절대적 과제이다. 이를 위해 정보전략계획은 기업의 업무와 데이터를 경영전략과 전사적 관점에서 모델링하고 체계화함으로써 통합의 기반을 공고히 할 수 있어야 한다. 우리가 전사적으로 모델링 해야 할 객체를 든다면 ‘비즈니스, 조직, 데이터, 프로세스’가 될 것이다. 물론 가장 먼저 우선적으로 정의할 것은 비즈니스 객체와 조직 객체를 분석하는 일이다. 비즈니스 객체에는 회사의 사명(使命), 비전, 중장기 목표, 전략, 주요 성공요인, 실행계획, 정보요구, 성과지표가 포함된다. 조직에도 업무분장, 조직별 역할, 주요 업무, 주요 업무처리 흐름 자료도 필요하다.

우리는 이것을 바탕으로 정보기술적 객체인 데이터와 프로세스를 분석한다. 여기서 물론 데이터는 프로세스에 우선한다. 비록 지금까지는 데이터보다 프로세스에만 관심을 기울여 온 사람들이 훨씬 많다는 것은 사실이지만 이제부터라도 우리는 데이터가 더욱 중요한 본질이라는 것을 인정해야만 한다. 데이터라는 ‘뼈대’의 구조에 변혁이 일어난다면 여기에 붙어 있는 프로세스라는 ‘살’에는 근본적인 변화가 일어날 수 밖에 없기 때문이다. 이 책에서는 정보전략계획의 전반에 걸쳐 모두 설명할 수는 없으므로 데이터를 중심으로 설명하기로 한다. 다음 그림은 정보전략계획을 수립하는 절차이다.

[그림 5]

이 그림에 있는 ‘예비정보구조 정의’ 단계에서는 프로세스를 찾아내고 이를 분해해서 계층도를 그리며, 기능명세서와 프로세스 흐름도를 작성하는 전사적 프로세스 모델링과 전사적 데이터 모델링을 한다. 물론 데이터 아키텍처의 전(全) 단계를 실시하는 것이 아니라 개괄적 모델과 개념적 모델까지만 실시한다. 상황과 목적에 따라 개념적 모델링을 해야 할 대상의 폭을 좁힐 수도 있고 반대로 넓힐 수도 있다. 정보전략계획을 위한 데이터 아키텍처의 수립절차는 앞서 제시한 현행 시스템을 리버스 하는 절차를 그대로 따른다.

현행 시스템을 정확히 분석하려면 데이터 모델을 최대한으로 리버스하는 것이 가장 바람직하다. 그러나 실전에서는 현실을 전혀 인정하지 않을 수도 없기 때문에 정보전략계획 내의 데이터 모델링 작업은 반드시 해야만 하는 최소한의 것만 실시하고 있는 실정이다. 그렇지만 만약 여러분이 벌써 오래 전부터 현행 시스템의 데이터 아키텍처를 수립하여 운용해 오고 있었다면, 이러한 걱정은 전혀 하지 않아도 좋을 것이다. 게다가 애플리케이션 아키텍처까지 수립해 두었고, 데이터 아키텍처와의 연결 관계까지 시스템으로 관리하고 있다면 그야 말로 금상첨화라 하지 않을 수 없다.

좋은 정보전략계획을 수립하기 위해서는 먼저 현행시스템을 진단하여 제대로 평가하는 것이 반드시 필요하다. 이 과정에서 평가한 기존시스템의 현황을 기반으로 삼아앞으로 어떻게, 어떠한 시스템으로 가야 할지를 결정해야 한다. 현행 시스템의 평가는 지금의 데이터베이스를 검토하고, 시스템 보안, 시스템 감사, 시스템 장애 대책, 네트워크 구성 등을 검토하는 일이다. 만약 이 단계에서 기존의 물리적 모델을 전문가의 시각에서 재조명한 ‘논리화’를 해 본다면, 현행 시스템의 데이터 모델이 어디가 얼마나 잘못되었으며, 어떻게 되는 것이 가장 바람직한 형태라는 것까지도 명확히 찾아 낼 수가 있다.

위 그림의 정보전략계획의 ‘정의’ 영역에 있는 ‘정보구조 정의’ 단계에서는 현행 업무분석, 업무 정의, 데이터 정의, 조직간 정보흐름도를 작성한다. 여기서 말하는 ‘데이터 정의’를 목표 데이터 아키텍처를 수립하는 것으로 이해하면 된다. 현행 데이터 아키텍처를 이용하여 목표 데이터 아키텍처를 수립하는 절차는 이미 앞에서 언급하였기 때문에 자세한 설명은 생략하기로 한다. 정보전략계획에서는 목표 데이터 아키텍처의 작성 수준을 개괄적 모델과 개념적 모델 정도로만 작성하는 것이 일반적이다. 물론 개념적 모델의 레벨을 필요에 따라 조정할 수는 있을 것이다.

DA의 활용 - 6. 시스템 리모델링을 위한 데이터 아키텍처의 활용

Lee화식 — Mon, 14 May 2012 14:49:14 +0900

6. 시스템 리모델링을 위한 데이터 아키텍처의 활용

시스템을 리모델링 한다는 것은 데이터 ‘모델링(modeling)을 다시(re) 한다’는 의미가 아니라 건축에서 주로 사용하는 리모델링을 의미하는 말이다. 다시 말해서 어떤 건축물을 리모델링 한다는 것은 건축물을 뜯어내고 재건축(리스트럭처링, restructuring)하는 것이 아니라 ‘기존의 낡고 오래된 건축물을 현대감각에 맞게 최적의 구조로 바꾸어 주는 개보수 작업’을 말한다. 이 개념은 건축한지 오래된 건축물을 대상으로 실시하여, 재건축에 비해 훨씬 낮은 비용을 들이면서도 부동산가치를 극대화할 수 있는 건축기법으로써 ‘제2의 건축’이라고도 하며, 우리 말로 표현하자면 ‘전체 또는 부분개조’라고도 할 수가 있겠다.

건축물의 리모델링은 효율적인 공간확보와 생활동선을 편리하게 하기 위해 한정된 주거공간을 개보수하는 것으로서, 바뀐 생활문화 욕구를 충족할 수 있는 새로운 디자인과 좋은 건축마감자재로 개조함으로써 건물의 효과를 최대화할 수 있으며, 거의 재건축을 하는 것과 다름없는 효과를 보이고 있다. 시스템의 리모델링도 건축물의 리모델링과 개념, 목적, 효과가 매우 유사하다고 할 수 있다.

시스템 리모델링이란 구축된 지 오래된 시스템을 단지 수리하는 정도가 아니라 기존에 문제가 되었던 많은 개선요구 사항들을 보다 확실하게 반영하고, 앞으로 나타날 다양한 요구사항에 보다 쉽게 대응할 수 있도록 현재의 시스템을 ‘근본적으로 개조(改造)’하는 작업이다. 사실 ‘개조’라는 말에는 단순한 개선이나 수리를 하는 정도가 아니라 뭔가 근본적인 것을 바꾸어 버렸다는 상당히 강한 의미가 내포되어 있다. 시스템 리모델링은 단지 일부 애플리케이션을 통합하거나 기능을 개선하는 정도가 아니라 데이터 모델부터 근본적인 수술을 단행하는 것을 말한다.

‘뼈’에 해당하는 데이터 모델이 근본적으로 변경된다는 것은 이를 둘러 싸고 있는 ‘살’에 해당하는 애플리케이션에 많은 변화가 발생한다는 것을 의미하므로 이는 매우 큰 수술이라고 할 수 있겠다. 만약 우리 몸에 장애가 있을 때 그 원인을 치료할 수만 있다면 구태여 장애를 보조하는데 비용을 들이는 것보다는 근본적인 원인을 치료하는 것이 훨씬 현명하다. 이것은 단지 보다 나은 삶을 영위한다는 것뿐만 아니라 비용적인 측면에서 보더라도 장기적으로 볼 때는 오히려 절약될 것이 분명하다.

얼마 전에 한 TV에서 가난하고 불우한 사람들을 선정해서 그들의 집을 리모델링해 주는 ‘러브 하우스’라는 프로를 방영한 적이 있다. 혹시 기억하는 사람이 있다면 그때 리모델링을 하기 전에 촬영한 집의 모습과 리모델링을 한 후의 모습이 얼마나 놀랍게 변모되었던지 정말 깜짝 놀랐던 일이 생각날 것이다. 다음 그림은 이때 실제 방영한 자료를 옮겨 놓은 것이다.

[그림 3]

이 프로그램은 대부분 1주일 만에 리모델링을 완료하는 방식으로 실시되었다. 불쌍한 그들에게 꿈과 희망을 심어주고자 했기 때문에 가능한 모든 방법과 기발한 아이디어들이 도입되었다. 단 1주일에 불과한 짧은 기간과 재건축과는 비교도 할 수 없는 저렴한 비용으로도 모두가 깜짝 놀랄만한 획기적인 변신을 할 수 있다는 것을 시청자들에게 보여 주었고, 한 동안 리모델링 붐이 일어나게 하였다.

부족한 공간을 최대한 활용할 수 있도록 하기 위해 침대와 서랍장을 과감히 통합한다거나, 대부분의 가구를 간단한 조작과 이동만으로 다른 용도의 가구로 변신할 수 있도록 하여 활용도를 높였다. 가령, 장애자를 위해 모든 가구에 바퀴를 달고, 책상 밑과 같은 ‘죽은 공간’을 수납공간으로 이용하였다. 붙박이장은 유리로 마감해 충분한 수납공간을 만들었고 침대는 소파 겸용이다. 욕실의 한 쪽 벽면을 유리로 하는 등 과감한 디자인이 돋보이기도 했다.

이 모든 것이 현실에 대한 정확한 이해를 바탕으로 그들이 원하는 것, 그들에게 심어주고 싶은 것들을 정확히 도출해내어 이를 최적으로 반영한 결과이다. 다시 말해서 리모델링의 근본은 먼저 현재를 정확히 리버스 하는 것부터 시작되어야 한다는 것이다. 재건축처럼 모든 것을 새롭게 바꾸어 버릴 수는 없기 때문에 현실의 정확한 상태를 정밀하게 조사·분석하는 것이 반드시 필요하다.

이와 마찬가지로 시스템의 리모델링에서도 가장 먼저 해 야할 일은 바로 현행 시스템을 상세하게 리버스하는 일이다. 다음 그림은 시스템 리모델링의 개념을 간단한 그림으로 표현해본 것이다.

[그림 4]

건축물의 리모델링을 하기 위해서는 아주 다양한 경험과 기술, 창의력 등을 가지고 있는 우수한 디자이너가 필요하듯이 시스템 리모델링에서 또한 매우 탁월한 능력을 가진 설계자가 필요하다. 물론 어느 한 사람에 의해 모든 것이 이루어 질 수는 없기 때문에 여러 사람들이 체계적으로 접근할 수 있도록 하기 위한 공통적이고 체계적인 방법론이 먼저 기반이 되어야 한다. 뿐만 아니라 DBMS에 대한 탁월한 능력이 없다면 획기적인 개조를 할 수 있는 힘이 떨어지고, 그렇게 해서는 리모델링의 효과가 크게 살릴 수가 없기 때문에 DBMS활용 능력 또한 매우 중요한 요소라 하지 않을 수 없다.

생각해 보라! 내가 만일 데이터베이스에 있는 옵티마이저의 원리에 통달하여 남들이 수천 라인으로 작성해야 하는 배치처리 애플리케이션을 몇 십 라인으로 된 하나의 SQL로 바꾸어 1/10로 수행속도를 단축시킬 능력을 가지고 있다면 보다 획기적으로 개선된 리모델링이 가능하지 않겠는가? 리모델링을 위해서는 이 외에도 현실을 깊이 있게 분석할 수 있는 탁월한 분석력, 전체적인 시각에서 보다 근원적이고 체계적인 접근을 할 수 있는 종합력, 문제를 조리있게 찾아내고 핵심을 꿰뚫어 봄으로써 단순하면서 유연성 있는 솔루션을 도출할 수 있는 논리력, 새로운 요구나 미래에 발생할 수 있는 요구까지 감안하여 보다 근본적인 개선 형태를 구상해내는 창의력이 있어야 가능한 일이다.

시스템 리모델링은 시간과 비용을 크게 절약하면서도 재구축에 못지 않은 효과를 낼 수 있는 것은 분명하지만 그만큼 높은 기술력과 갖가지 탁월한 능력이 없다면 흉내조차 낼 수 없다는 점이 우리가 쉽게 접근할 수 없는 부담이라 하겠다. 만약 엉망으로 꼬여 버린 바둑판에 고수가 훈수를 둔다면 얼마 가지 않아 전세가 유리한 바둑으로 역전이 될 것이다. 이것은 어디까지나 이 바둑판에 바둑 고수가 있었기 때문에 가능한 일이다. 이 상황에서 바둑 고수가 해야 할 첫 번째 일은 당연히 현재 상황을 정확하게 파악하여 문제점을 찾는 것이며, 두 번째로 할 일은 자신의 기력(棋力), 분석력, 종합력, 창의력 등을 이용하여 최선의 수를 찾아 내는 것이다.

그림에 나타나 있듯이 먼저 현행 물리적 데이터 모델을 정확하게 리버스 한 후 이를 논리화하여 현행 논리적 데이터 모델을 만들어 가는 일 - 즉, 현행 데이터 아키텍처를 전체적으로 제대로 수립하는 일 - 은 우리가 가장 먼저 시작해야 할 일이다. 만약 여러분이 데이터 전문가라 불려질 만한 능력을 가지고 현행 물리적 모델을 본질적인 내용 중심의 논리적 모델로 제대로 바꾸어 본다면, 현 시스템의 데이터가 얼마나 방만하게 중복되어 있고, 이로 인하여 얼마나 많은 애플리케이션이 불필요하게 운용되고 있는지 놀라지 않을 수 없을 것이다.

데이터 모델을 정확하고 구체적으로 리버스 하였다면, 여기에 덧붙여서 현행 애플리케이션의 구조와 데이터의 사용 관계까지 같이 리버스해 두는 것은 매우 의미있는 일이다. 만약 현행 애플리케이션 아키텍처를 리버스해 줄 수 있는 도구가 있다면 보다 쉽게 이러한 정보를 만들 수 있겠지만 설사 그렇지 못하더라도 약간의 응용 애플리케이션을 작성하여 이러한 정보를 생성할 수 있다. 물론 워낙 애플리케이션 개발 도구가 다양하므로 조금씩 처리방법이 다르기야 하겠지만 결국 애플리케이션 소스코드도 일종의 파일이기 때문에 여러분의 실력이라면 충분히 이를 분석해서 데이터로 저장하는 애플리케이션을 작성할 수가 있을 것이다.

만약 현행 시스템이 관계형 데이터베이스로 구축되어 있다면 애플리케이션에서 데이터를 액세스하는 부분은 모두 SQL로 되어 있을 것이다. 이 SQL을 분석(parsing)할 수 있는 애플리케이션을 작성할 수만 있다면 어떤 데이터가 어떤 애플리케이션에서 어떤 목적으로 사용되고 있는지에 대한 정보를 만들어 내는 것은 그리 어려운 일이 아닐 것이다. 이 놀라운 정보는 우리가 개조하고자 하는 시스템에 있는 ‘개선의 맥점’을 보다 분명하고 수월하게 찾아낼 수 있도록 하는데 크게 기여하게 될 것이다.

이렇게 수집된 현행 시스템의 데이터와 애플리케이션의 분석정보는 전문가의 차원 높은 정밀진단을 통하여 획기적인 개선대책과 개선의 부위, 개선 후의 효과, 투입해야 할 일량 등이 구체적으로 제시될 수 있다. 다시 말해서 현행 시스템에 있는 불필요한 내용들을 제거해 버리거나, 더 좋은 것으로 대체, 혹은 과감한 통합을 통해 단순화 시키며, 필요하다면 일정 부분을 아예 다시 작성하는 방법을 통해 획기적인 개선안을 제시할 수 있다는 것이다. 물론 이러한 개선에 대한 처방은 현재의 현실요소 – 즉, 인적자원, 시간, 비용, 심각도 등 – 를 충분히 감안한 적용 스케줄을 수립함으로써 현실의 상황에 맞도록 개선해 갈 수가 있다. 이러한 장점은 재구축을 하는 방법에서는 도저히 얻을 수 없는 리모델링 만의 장점이라고 할 수 있겠다.

실전에서 이러한 리모델링 작업을 해보면 사실 ‘제거’해 버려도 괜찮은 것들이 무수히 있다. 제대로 변경이력을 관리하지 않았기 때문에 혹시 어떻게 될지 몰라서 버리지 못하고 있는 것들 뿐만 아니라, 특정 처리를 위해서 임시적으로 사용했던 것들이 생각보다 많이 널브러져 있다. 이처럼 더 이상 활동을 하지 않는 데이터나 애플리케이션을 찾아서 정리를 하는 것은 여러분의 책상 속에 오랫동안 묵어 있던 불필요한 자료를 처분하는 것처럼 개운한 일이다.

이 밖에도 만약 고급 SQL을 작성할 능력이 있다면 얼마든지 물리적인 중간집합을 가져가지 않을 수도 있는, 다시 말해서 액세스 능력만 키운다면 제거해도 좋을 데이터나 애플리케이션이 생각보다 매우 많다는 것이다. 만약 이 말에 동의할 생각이 없는 사람이라면 DBMS의 고급 활용만으로도 얼마만큼의 놀라운 효과를 볼 수 있는지 제대로 경험해 보지 못한 사람이라고 할 수 밖에 없다. 다른 말로 한다면 데이터베이스가 해야 할 일을 마치 자기에게 부여된 숙명인양 생각하여 쓸데없는 고생을 자초하는 불쌍한 사람이라는 것을 의미한다고도 할 수 있겠다.

리모델링 작업에서 가장 많은 비중을 차지하고 있는 것을 들라고 한다면 아마 바로 이 ‘논리적 대체’ 부분일 것이다. 논리적 대체란 결과는 변경시키지 않으면서 기존의 데이터나 애플리케이션의 전부 혹은 일부를 획기적으로 개선된 ‘다른 것으로 대체’시키는 것을 말한다. 가령, 수십 개의 테이블을 없애는 대신 단순해진 다른 하나를 만들어 대체한다거나, 처리 방법을 획기적으로 개선하는 것, 혹은 DBMS에게 대부분의 처리를 맡겨 버리는 방법을 활용함으로써 애플리케이션 모듈이나 알고리듬을 훨씬 짧고 효과적인 것으로 대체하는 것을 말한다.

이 모든 것들은 자신이 가진 능력 여하에 따라 엄청난 차이가 날 수 있는 것들이다. 특히 대용량의 데이터를 복잡하게 처리하는 배치 처리는 정말 놀라운 차이를 만들어 낼 수가 있다. 필자는 실전에서 수십 개의 애플리케이션을 몇 십 라인으로 된 하나의 SQL로 대체하여 20시간 소요되던 수행시간을 단 20분 이내로 바꾸어 준 경험들은 셀 수도 없이 많이 있다. 혹자는 “설마?” 라며 믿지 않을지도 모르겠지만 그간 ‘대용량 데이터베이스 솔루션’ 시리즈를 애독한 사람이라면 충분히 수긍하리라 확신한다.

앞서 진공관을 반도체칩으로 과감한 통합을 하지 않고서는 아무리 회로를 최적화 하더라도 결코 단순해질 수가 없다고 한 적이 있다. 정보시스템 또한 과감한 통합을 하지 않고서는 결코 리모델링의 효과를 얻을 수가 없다. 데이터의 통합이 선행되지 않은 채 애플리케이션만 최적화 한다고 해서 절대로 단순화를 달성할 수 없다는 것을 이제 우리는 잘 알고 있다. 물론 차이가 있겠지만 필자의 경험으로 본다면 대부분의 시스템에서는 데이터가 거의 5~10배 정도가 중복되어 있다고 판단된다. 이것은 그만큼 개선의 여지가 많고 거기에 따른 기대효과도 크다는 것을 의미한다.

모름지기 세상의 모든 것이 그러하듯이 적절한 통합은 많은 시너지 효과를 얻을 수 있지만 잘못된 만남은 ‘악화가 양화를 구축’하는 현상을 가져오게 한다. 그만큼 적절한 만남을 결정하는 것은 중요하고 어렵다는 것이다. 이러한 결정을 합리적으로 할 수 있도록 하기 위해서는 객관적이고 구체적인 ‘판단의 근거’가 필요하다. 이를 위해 앞으로 데이터 모델링에서는 엔터티의 통합, 릴레이션쉽의 통합, 속성의 통합 등에 대해 매우 상세하고, 구체적이며, 객관적이고, 상식적인 ‘판단의 근거(잣대)’들을 제시하게 될 것이다.

리모델링은 최대한 기존의 골격을 그대로 유지하는 것이 원칙이겠지만 경우에 따라서는 일정 부분을 새로 구축해 넣을 수도 있다. 일정 부분을 없애고 다른 것으로 새로 채워 넣는다는 면에서는 일견 논리적 대체와 비슷해 보이기도 한다. 그러나 논리적 대체는 데이터나 애플리케이션의 일부를 재구성 한다는, 약간은 소규모의 개조를 의미하지만 ‘특정 부분 재개발’이란 좀더 큰, 다시 말해서 거의 서브 시스템에 가까운 단위를 완전히 새로 재개발 하겠다는 것을 의미한다.

이 방법을 사용하는 경우는 리모델링 대상이 너무 심각한 문제를 안고 있어서 수리나 개조를 하는 것보다 무시하고 재구축을 하는 것이 오히려 훨씬 유리할 때 적용하는 방법이다. 이 방법은 재개발 대상의 업무규칙(what-to)은 파악하지만, 실로 복잡하기 그지없는 처리과정(how-to)에 대해서는 신경을 쓸 필요가 없다는 것에 매력이 있다. 기존의 방법을 따르지 않는다면 저토록 구구절절한 알고리듬이 아예 필요없을 텐데 괜히 골머리를 앓을 필요가 어디 있겠는가? 그렇다고 해서 너무 이 방법을 가까이(?) 해서 함부로 사용하는 것은 결코 좋지 않다.

사실 실전에서는 남이 작성한 애플리케이션이 자기 스타일이 아니어서 파악하기가 힘이 든다는 이유만으로 웬만하면 자신이 다시 개발하는 일이 너무 빈번하다는데 문제가 있다. 비록 이러한 문제가 특정 부분에 불과하더라도 자꾸만 재개발이 늘어난다면 리모델링 본래의 장점과 본질은 점차 희석되고 말 것이다.

필자가 알고 있는 대형 제조회사에는 놀랍게도 ‘생산, 자재’ 시스템만으로도 테이블 개수가 5,000개나 되었다. 애플리케이션이야 말할 나위도 없이 2만개가 훨씬 넘었다. 물론 300명이 넘는 사람들이 유지·보수를 하고 있었지만 날이 갈수록 쓰레기 산은 더욱 높아만 지고 있었다. 그렇다고 해서 원가를 제일로 여기는 제조회사에서 몇 백억의 비용을 들여 전체적으로 시스템을 재구축한다는 것은 엄두를 낼 수도 없는 형편이었다. 물론 ERP패키지를 검토해 보지 않은 것은 아니지만 이 또한 불발이었다. 워낙 회사가 크고, 특수한 업무를 하는 업체라서 여기에 딱 맞는 패키지가 존재할 수 없었기 때문이다.

항상 바쁘게 일하지만 너무나 비대해진 시스템이 발목을 잡고 있기 때문에 업무의 변화에 따른 유지·보수만 하기에도 언제나 쩔쩔 매야 했으니 근본적인 개선은 엄두도 낼 수가 없었고, 방치된 병은 갈수록 악화일로에 있었다. 결국 이들이 선택할 수 있는 길은 ‘은근과 끈기’로써 계속 버티어 볼 것인가, 아니면 리모델링을 하여 획기적인 개선을 할 것인가에 있었다. 물론 당장 시스템이 돌아가지 않는 것은 아니므로 나중에 하자는 보신주의자와 어차피 해야 할 일이라면 하루라도 빨리 해야 한다는 개혁주의자가 팽팽하게 맞서게 되었다.

천만 다행으로 개혁주의자가 대세를 장악하여 현행 시스템의 데이터 아키텍처부터 수립하게 되었고, 시스템이 거의 1/10로 감량되는 놀라운 결과를 얻을 수 있었다. 뿐만 아니라 리모델링을 하면서 튜닝도 같이 실시함으로써 수행속도가 현격하게 향상되었다. 모든 설계 자료가 리파지토리 내에 데이터로 저장되어 있음으로 해서 유지·보수가 한결 명확해졌고, 단순해졌다는 부상(副賞)도 같이 얻을 수 있었다. 더욱 커다란 소득은 유지·보수 요원들이 이 프로젝트를 직접 경험함으로써 데이터와 데이터베이스에 대한 능력이 과거와는 비교할 수 없는 차원 높은 접근이 가능해졌다는 것이었다. 옛말에 ‘고기를 잡아 주는 것보다 고기를 잡는 방법을 가르쳐 주라’고 했듯이 앞으로 수 많은 일을 계속해야 할 사람들의 기술력이 모두 한 단계씩 향상되었다는 것은 참으로 커다란 의미가 있다고 하지 않을 수 없다.

건축에서도 리모델링은 선진국의 경우 그 비중이 전체 건설시장의 30%를 웃돌고 있으며, 이웃 일본은 이미 70%에 육박한 것으로 알려져 있다. 한국에서도 지난 1990년대 초반부터 서울 강남의 저층아파트를 중심으로 유행, 재건축이 힘든 고층아파트나 단독주택으로까지 확산되었다. 어쩌면 우리가 ‘노무자’라면서 멸시(?)하던 건설현장에서 조차 이러할 진대 최첨단의 산업이라는 IT분야에서 리모델링 개념이 제대로 정립되어 있지 않다는 것은 참으로 안타까운 일이 아닐 수 없다.

아무리 우리가 새 집, 새 차를 좋아하는 민족이지만 이것은 정말 심각한 낭비벽이라 하지 않을 수 없다. 이제 훨씬 저비용에 높은 효과를 보이는 리모델링 시장이 성장해야 한다. 시장에는 오래된 시스템이 무척이나 많이 있다. 더구나 90년대 중반 이후에 오픈시스템, 클라이언트/서버의 붐을 타고 대거 개발되었던 시스템들이 이제 노후화 되어 있으므로 그 잠재적인 수요는 매우 많다고 할 수 있다. 더구나 날이 갈수록 DBMS버전의 성능은 놀랄 만큼 기능성이 향상되면서 이런 신기술을 이용한 시스템 개조가 훨씬 쉬워졌다. 게다가 가장 난이도가 높았던 데이터 영역에도 다양한 지원 도구들이 속속 등장하게 되어 리모델링 시장을 부추기는 결정적인 요인으로 작용하고 있다.

DA의 활용 - 5. 데이터 아키텍처를 이용한 EDW 구축

Lee화식 — Mon, 14 May 2012 14:46:47 +0900

5. 데이터 아키텍처를 이용한 EDW 구축

요즈음 어디를 가보더라도 웬만한 기업이라면 자신들은 데이터 웨어하우스를 구축하여 적용하고 있노라고 큰 소리를 치고 있다. 그러나 그 실속을 조금만 파고 들어가 보면 말이 데이터 웨어하우스일 뿐이지 단지 다량의 데이터 액세스해야 생성할 수 있는 분석자료를 OLTP 에서 처리하기에 부담이 되기 때문에 ‘다른 서버로 데이터를 옮겨 두었다’는 의미에 지나지 않는다는 것을 쉽게 알 수가 있다.

여기서 데이터 웨어하우스에 대해 너무 많은 것을 언급할 수는 없겠지만 데이터 웨어하우스라면 최소한 지켜야 하는 원칙을 한 번 생각해 보기로 하자. 우리가 어떤 경우에도 반드시 준수해야 할 기본 원칙은 바로 ‘통합, 단순, 장기(long term)’의 세 가지라고 하겠다. OLTP는 자신들만이 가져야 하는 눈물겨운(?) 사연이 있고, 이미 자신의 코가 석자이기 때문에 사실 다른 목적들까지도 모두 감안해 줄 여력이 없는 형편이다. 결국 ‘목마른 사람이 샘을 판다’는 속담처럼 정보의 분석이 목적인 쪽에서는 자신의 입맛에 맡도록 남(트랜젝션 처리 시스템)이 변해 주기를 기다렸다가는 그야말로 아무 것도 할 수 없으므로 스스로 자신이 원하는 것을 찾아내어야만 한다.

즉, 정보의 분석을 위해 필요한 원료(소스, 데이터)를 얼마나 체계적이고 효율적으로 관리할 수 있느냐에 대한 문제는 전적으로 데이터 웨어하우스가 아쉬워할 부분일 뿐이다. 그러나 다량의 정보 소스는 OLTP에 너무나 넓게 흩어져 있고, 그들간의 오묘한 관계는 깊이 숨어 잘 드러나지 않기 때문에 이를 명확하게 재조명한다는 것은 그리 쉬운 일이 아니다. 그럼에도 불구하고 대용량의 데이터를 처리해야만 한다는 점과 툴이나 DBMS에게 많은 것을 맡겨야 하는 데이터 웨어하우스의 메커니즘적인 특수성 때문에 최대한 단순·명료해야 한다는 것이 바로 우리에게 주어진 쉽지 않은 해결 과제일 것이다.

사실 실전에서는 전사적인 OLTP를 모두 분석하여야 하며, 미래를 감안한 종합적인 데이터 인프라(Infra)가 되도록 해야 한다는 것이 너무 어려운 과제이다 보니 대부분의 업체에서는 위의 세 가지 원칙이 잘 지켜지지 않고 있다. 종합적인 분석을 해서 미래를 내다보는 전략적인 결정을 할 자신이 없다 보니 일단 OLTP의 모든 트랜젝션을 자신의 스테이징(Staging) 영역에 임시로 보관해 둔다. 여기서 현재 사용자가 보고자 하는 일부의 정보들만으로 목적DB를 만들어 일단 급한 불(사용자들의 기본적인 욕구)부터 꺼보자는 정도로 데이터 웨어하우스를 구현해 두고 있는 실정이다. 물론 기존에 감안되지 않았던 새로운 요구사항이 들어 오면 덮어 놓았던 스테이징 영역에서 데이터를 꺼내어 가공해 오는 일을 추가한다. 스테이징 영역에는 모든 데이터가 어딘가에는 흩어져 있으니 별로 문제가 되지 않는 것처럼 보일 수도 있다.

그러나 이러한 방식으로 구현한 것은 엄격하게 말한다면 전사적 데이터 웨어하우스(EDW)가 아니라 데이터 마트에 불과하다. 잠시 머물렀다가 사라져 버리는 저 스테이징 영역이 우리의 데이터 인프라인 것은 더 더욱 아니다. 이러한 접근 방법은 필요한 것만 선별하여 만들었기 때문에 첫 번째 원칙인 전체적인 ‘통합’의 원칙을 무시했고, 날이 갈수록 새로운 요구를 반영하느라 자꾸만 중복된 집합이 생성되기 때문에 ‘단순’의 원칙을 지키지 못했으며, 장기간 숙성시켜야 할 데이터들이 증발되어 버리고 있기 때문에 ‘장기’의 원칙도 무시하였다. 물론 당장에야 사용자들이 원하는 것들을 보다 어렵지 않게 제공할 수가 있으니 걱정할 것이 없는 것처럼 보이지만 나중에 가서는 반드시 몇 배로 그 대가를 지불해야 한다는 것을 분명히 알아야 할 것이다.

데이터는 물이 강을 흘러 바다로 들어가는 것처럼 한 번 흘러가면 다시 주워 담기가 어렵다. 오랜 기간 숙성이 되어야 값비싼 양주가 될 수 있듯이 진정한 고급 정보는 장기간의 데이터를 활용해야만 얻을 수가 있다. 지금까지 우리가 보았던 분석정보는 앞으로 나타날 논리적으로 존재할 수 있는 모든 의미있는 정보에 비한다면 극히 일부분에 지나지 않는다. 이 말은 곧 사용자들의 견물생심은 날이 갈수록 크게 증가하게 될 것임을 의미한다. 산업이 발전하여 생활에 여유가 늘어날수록 더욱 고상한 문화를 찾게 되는 것처럼 앞으로는 더욱 종합적이고, 고난이도의 분석정보를 원하게 될 것은 자명한 일이다.

그때 가서야 이를 위한 소스정보가 제대로 유지되지 않고 있었다는 것을 알게 된다면 그것은 이미 너무 늦었다. 오래 전에 이미 사과나무를 심어 두었어야 지금 사과를 따 먹을 수가 있다. 사과가 먹고 싶다고 이제 와서 사과나무를 심으려 한다면 앞으로 몇 년을 기다려야 하므로 이미 귀중한 기회는 날아가 버린 후일 것이다. 이렇게 하고서도 경쟁에서 승리할 수 있다고 생각한다면 그것은 너무나 안이한 생각이라 하지 않을 수 없지 않겠는가!

데이터 웨어하우스는 누가 뭐래도 데이터가 생명이다. 그 데이터는 하늘에서 저절로 떨어지는 것이 아니므로 결국 OLTP를 젖줄로 해서 태어날 수 밖에 없다. 그렇다면 여러분들은 과연 원천이 되는 OLTP를 완벽하게 알지 못하고 만들어진 데이터 웨어하우스가 정상적인 모습을 할 수 있다고 생각하는가?

이런 생각을 한 번 해보자. 필자의 가난했던 어린 시절, 시골에서는 어디 돈을 주고 사서 먹는다는 것은 생각할 수도 없었기 때문에 입맛이 없을 때는 지천에 흩어져 있는 산나물을 캐다 먹었다. 사실 다량의 나물이 필요한 것도, 별도로 키울 필요도 없었기 때문에 어디에 가면 어떤 산나물을 찾을 수 있다는 것만 알고 있는 것만으로도 충분했다. 만약 필요하다면 약간의 수고만 하면 원하는 것을 얻을 수 있었기 때문에 그때 형편에서는 그런대로 큰 불만없이 지낼 수 있었다. 그러나 이제는 농촌도 많이 현대화가 되어 지금까지 단지 자신들만이 자급자족했던 것에서 벗어나 비닐 하우스에 다양한 산나물을 재배하여 대량으로 출하시킴으로써 소득향상에 큰 보탬이 되고 있다.

과거처럼 산과 들에서 산나물들이 저절로 자랄 때에는 ‘어디 가면 많이 있다’는 정보만 있으면 충분했으므로 자신이 어디에 얼마를 자라게 해야 할 것인지에 대한 전략적 고민은 할 필요가 없었다. 단지 겨울에도 먹을 수 있기 위해 미리 상당량을 채취하여 별도로 저장해 두는 정도로만 관리하였을 뿐이다. 그러나 이제는 단지 먹고 사는 문제가 아니라 본격적인 매출을 올리기 위해 재배를 하는 경우라면 어떤 것들을, 어디에, 얼마나 재배할 것이며, 작물의 특수성을 세밀하게 감안하지 않는다면 필시 농사를 망치게 될 수도 있을 것이다.

어떻게 생각하면 조금은 엉뚱한 예를 든 것 같기는 하지만, 산과 들에 자생적으로 자라고 있는 산나물을 OLTP의 데이터라고 생각하고, 본격적인 재배에 들어간 비닐 하우스를 데이터 웨어하우스로 생각해 본다면 여기서 우리가 명심해야 할 것들이 분명히 있다는 것을 알 수 있다. 자급자족을 하는 정도에 만족하려는 입장이라면 비닐 하우스에 재배를 하는 것은 시간과 비용이 많이 든다. 그들은 그저 현재 필요한 정도를 얻는 것에 문제만 없다면 지금은 만족할 것이다. 그렇다고 해서 앞으로도 언제까지나 그렇게 구차하게 살아야 할 것인가? 미래에 욕심이 없는 사람이라면 지천에 산나물이 어떻게 자라고 있는지 소상하게 파악할 필요도 없고, 지금까지 먹어보지 못했던 나물에 대해서는 그 더욱 고민할 필요가 없다.

이처럼 현재의 사용자 요구를 수용할 정도만 OLTP나 혹은 스테이징 영역에 가서 데이터를 수집해 온다면, 당장의 요구는 해소할 수 있으므로 별반 문제가 없는 것처럼 보일 수도 있다, 물론 마치 이렇게 살아도 만족한 인생을 살 수 있는 구도(求道)를 하는 사람들처럼 더 이상의 발전에 대한 욕심이 없다면 이것을 나쁘다고만 할 수는 없다. 그러나 우리가 수행하는 프로젝트는 어디까지나 영리를 목적으로 하는 사업체이므로 결코 그렇게 할 수는 없는 노릇이다. 비닐 하우스라는 개념이 없었던 시절에는 비록 채취를 해서 먹었지만 이제는 전략적으로 잘 구성된 비닐 하우스에서 차원이 다른 접근을 해야 할 시점이 분명히 온 것이다.

이제 우리가 직접 재배를 해야 한다면 과거에 비해 훨씬 구체적이고, 체계적인 전략을 가지고 접근해야만 한다. 설사 내가 먹을 것이 아니더라도, 지금 당장 먹을 것이 아니더라도 미리 재배해 두어야 한다. 작물을 잘 선택해야 하고, 파종할 시기와 재배할 양과 판로에도 신경을 써야 한다. 다시 말해서 관련된 많은 사항에 대해서 구체적인 파악을 하고 있어야 한다는 것이다. 농사꾼의 비닐 하우스에서 조차 이러할 진대, 최첨단의 컴퓨터를 기반으로 한 정보시스템이 주먹구구식일 수는 없다. 데이터 웨어하우스는 자신의 형태를 결정하기 전에 무엇보다도 먼저 자신의 기반이 되는 OLTP의 데이터부터 정확히 파악하는 것이 순서이다. 어떤 재료가 있는지도 모르면서 함부로 가공될 자신의 모습을 결정하여 들지 말라!

데이터 소스의 중요성에 대해 너무 강조한다고 해서 데이터 웨어하우스를 활용하는 사용자의 요건정의를 무시해도 좋다는 것은 결코 아니다. 다만 여기서 강조하자는 것은 현재의 요건정의만 가지고, 마치 들에 가서 필요한 만큼만 산나물을 캐어 오는 것처럼 데이터 웨어하우스를 만들어서는 안 된다는 것을 강조하자는 것이다. 사용자 요건은 반드시 필요하다. 마치 비닐 하우스를 짓는 사람들처럼 자신이 재배한 작물이 누가, 얼마만큼, 언제 필요한 지를 조사하고 여기에 따른 전략적인 고민을 해야 한다는 것은 당연한 일이다.

사용자 층이나 그들의 요건은 시간이 지남에 따라 변하기 때문에 우리가 여기에 일희일비를 하지 않으려면 보다 근본적인 대책을 강구해 두어야 한다. 그 대책은 다름아닌 정보의 재료가 되는 데이터를 전략적으로 보존해 두는 것이다. 물론 이를 위해 우리가 해야 할 가장 중요한 일은 데이터의 근본이 되는 OLTP를 정확히 파악하는 것이다. 이런 의미에서 제대로 된 데이터 웨어하우스를 구축하기 위해서는 OLTP의 데이터를 반드시 정확하고 구체적으로 아키텍팅할 필요가 있다는 것이다. 앞서 만약 여러분이 OLTP의 데이터 아키텍처를 정확히 수립하였고, 그것이 논리화를 거친 논리적 모델이라면 이미 70% 가량 우리의 EDW모델에 가까이 근접해 있다고 했었다. 이 논리적 모델을 바탕으로 데이터 웨어하우스의 원칙인 ‘통합, 단순, 장기’의 개념을 최대로 승화시킨 모델을 구현해 가는 것이 가장 이상적인 방법이라는 것은 틀림없는 사실이다.

만약 여러분들이 EDW데이터 모델을 확정해 가는 단계에서 참고를 해도 좋을 만큼 수준 높은 참조데이터모델(Reference data model)을 확보했다면, 이를 활용하는 것도 좋은 모델을 만들어 나가는 바람직한 방법이 될 수 있을 것이다. EDW가 크게 확산되면서 최근에는 업종별로 이러한 참조모델을 전문적인 제품으로 제공하는 업체가 늘어나고 있다. 다만 한 가지 걱정되는 것은 이들의 참조모델을 확신한 나머지 여기에 단지 곁가지 정도만 보완한다면 완전한 우리의 EDW 데이터 모델이 될 수 있다고 믿게 할지도 모른다는 것이다.

이름하여 ‘템플릿(Template)을 이용한 EDW구축’이라고 하는 이런 형식으로 접근하는 경우가 종종 있는데 필자는 경우에 따라 이것을 좀 심하게 표현해서 ‘사기꾼들이나 하는 접근 방법’, 혹은 ‘모조품을 만드는 방법’이라고 매도(?)하기를 주저하지 않는다. 이 세상의 어떤 기업도 유사업체와 완전히 동일할 수는 없다. 업의 본질은 거의 유사할 수도 있겠지만 결코 그 기업의 환경, 문화, 비전까지도 모두 동일할 수는 없을 것이다. 물론 우리가 아무 것도 전혀 없는 상태에서 완벽한 것을 고안해 낸다는 것은 너무 어렵기 때문에 유사한 어떤 것을 참조하면서 자신의 것을 결정해 가는 방법은 충분히 고려해 볼 수 있는 좋은 접근 방법임에는 틀림이 없다.

그렇지만 이처럼 자신의 것을 찾기 위해 필요한 만큼만 참조를 하는 것과 이미 만들어진 것을 몇 군데 손질하여 만들자는 것은 절대 같은 것이라 할 수 없다. 물론 이처럼 유사품을 수리해서 만드는 방법은 적은 시간, 낮은 비용을 들이고서도 어느 정도의 효과는 볼 수 있다. 분명히 그럴 수 있다. 하지만 이것이 바로 모조품이 가지는 일반적인 특징일 뿐이다. 자신이 매우 가난하고, 천민이기 때문에 모조품을 사용해서라도 어느 정도 흉내를 내겠다는 사람이라면 더 이상 논쟁할 필요도 없다. 그러나 적어도 진품과 명품의 가치를 인정하는 사람이라면 왜 이런 주장을 하고 있는지에 대해 충분히 이해하리라 믿는다.

만약 데이터 웨어하우스의 기반이 되는 OLTP의 모든 데이터에 대해 매우 상세한 아키텍처를 수립하였고, 이를 바탕으로 모델링한 EDW데이터 아키텍처 또한 상세하게 수립되어 있다면 이들 간에는 ‘집합 대 집합’ 간의 매핑룰(mapping rule)이 존재하게 된다. 이 매핑룰이 바로 ETL(Extraction, Transformation and Loading; 추출, 변환, 탑재)의 알고리듬이 된다. OLTP도 데이터의 집합이고, EDW 또한 데이터의 집합이므로 이들간의 전환은 결국 ‘집합 간의 매핑’으로 볼 수 있다. 이것을 지금까지 DB이행(migration)을 할 때 적용해 왔던 방식처럼 일일이 사례별(case-by-case)로 다루어 알고리듬을 생성한다면 엄청난 경우의 수가 발생함은 물론, 오류나 누락이 증가할 뿐만 아니라, OLTP의 설계에 변화가 발생했을 때 유지·보수를 하는 일도 매우 어려워질 것이다.

데이터 웨어하우스에서 가장 우리를 괴롭히는 것 중의 하나는 상상을 초월하게 발생되어 있는 소스 데이터의 오류를 어떻게 말끔하게 정제(Cleansing)할 수 있는가에 대한 문제이다. OLTP시스템의 잘못으로 인해 앞으로도 계속 생길 수 있는 문제를 미리 찾아내어 원인을 봉쇄하는 것도 커다란 걱정거리라 하겠지만 과거에 무원칙하게 발생되었던 – 특 히 개발자가 특정 목적을 위해 함부로 데이터를 훼손시켰던 – 것들까지도 제대로 복원하려는 것은 거의 불가능에 가깝다고 할 만큼 어려운 일이다.

물론 오류 데이터를 어떤 기준으로 보정할 것인지를 결정하는 것도 어려운 일이겠지만 도대체 어떤 유형의 오류 데이터가 존재하고 있는지를 찾는 것은 더욱 쉬운 일이 아니다. 옳은 것을 찾아내는 것도 힘에 겨운데 잘못된 것을 찾는다는 것은 훨씬 힘이 들 수 밖에 없다. 논리적으로 생각해 보더라도 맞는 것은 한 가지이지만 잘못된 것은 수 없이 많이 존재할 수 있다. 더구나 집합에 대한 명확한 정의, 즉 데이터 모델의 상세한 정의가 되어 있지 않다면 무엇이 오류인지 조차 판단할 수가 없다.

여기서 말하는 오류 데이터란 단지 어떤 속성에 들어 있는 값이 규칙을 지키지 않았다는 정도만을 의미하는 것이 아니다. 자기 엔터티 내의 각종 업무규칙을 준수하는 것은 물론이고, 연결된 상하의 다른 엔터티와의 상호 간에 준수되어야 할 복합적인 업무규칙을 모두 의미한다. 실전 프로젝트에서 개발자들이 오류 데이터 유형을 충분히 도출했고, 이것을 거의 정제했다고 자신하고 있는 것들을 필자가 다시 복합적으로 분석해 보았더니 참으로 놀랄만한 오류들이 드러나고 있었던 적이 대부분이었다. 그들이 이러한 오류를 미처 발견할 수 없었던 이유는 단지 속성 값을 체크하는 정도에만 목표를 가졌고, 데이터 모델의 진정한 의미를 모르기 때문에 무엇을 체크해 봐야 하는지를 정확히 알지 못했기 때문이라고 생각된다.

이런 이유로 인해 수 많은 데이터 웨어하우스가 구축되어 있기는 하지만 진정 장기간의 데이터를 제대로 깨끗이 정제하여 탑재해 둔 곳을 찾기란 매우 어렵다. 그저 몇 개월, 길어야 1~2년 정도의 데이터를 탑재했을 뿐이다. 당장의 보고자료에 영향을 미치지 않는데도 불구하고 데이터의 고급화를 위해 겉으로 드러나지 않는 선행(?)을 하는 사람이 과연 얼마나 있겠는가! 그러나 만약 그들이 데이터 모델에 대한 정의를 명확히 하여 무엇이 잘못되었고, 얼마나 많은 것이 잘못되었는지를 알고 있었다면 귀중한 데이터가 저 모양이 되도록 방치를 했겠는가? 제 아무리 양심이 고운 사람이라 하더라도 잘못된 것이 무엇인지 조차 모른다면 올바른 조치를 할 리가 없다. 명확한 데이터 아키텍처를 수립하는 일은 이렇듯 데이터의 품질을 높여 주는 일에도 큰 몫을 할 수가 있다.

이제 많은 노력을 기울여 체계적인 모습으로 잘 정비된 데이터 웨어하우스는 이 데이터를 소스로 하여 생성하는 다양한 목적 시스템(데이터 마트, 각종 전문가 시스템 등)으로 데이터를 공급한다. 일반적으로 이런 유형의 시스템은 매우 다양하게 존재하고, 앞으로도 계속적으로 증가하는 특성을 가지고 있다. 물론 이러한 시스템을 통해 많은 활용을 하도록 하는 것이 바로 데이터 웨어하우스가 존재해야 하는 본래의 목적인 만큼 날이 갈수록 확대되어야 하는 것은 지극히 당연하다.

이렇게 확장되는 목적 시스템은 그 데이터 기반이 데이터 웨어하우스이므로 이들 간에도 결국 ‘집합 대 집합’ 간의 매핑으로 연결할 수 있다는 뜻이 된다. 만약 우리가 목적 시스템의 데이터 아키텍처까지도 제대로 수립하고 있었다면, 이들 간의 데이터 인터페이스 또한 매우 명확하고 쉽게 정의할 수 있었을 것이며, 단순한 유지·보수가 가능했을 것이다. 이처럼 데이터 웨어하우스 뿐만 아니라 그 뒷단의 목적 시스템에 대해서도 데이터 아키텍처를 정확하게 수립한다면, 이것이 바로 가장 높은 품질의 시스템을 가장 단순·명확하게 관리할 수 있는 유일한 방법이라 할 수 있다.

거듭 강조하거니와 데이터 웨어하우스는 결국 데이터를 다루고자 하는 시스템이므로 OLTP와는 달리 소수의 유능한 데이터 전문인력 위주로 구축하고, 관리하는 것이 바람직하다. 대용량의 데이터를 다양하고 복잡한 가공을 통해 높은 가치의 정보를 생성해야 하기 때문에 양식 있는 관리자라면 데이터와 데이터베이스에 일가견이 있는 전문인력을 육성하거나 확보하는 것을 가장 우선적인 과제로 삼는 것이 필요할 것이라 믿는다.

DA의 활용 - 4. ERP 도입시 데이터 아키텍처의 활용

Lee화식 — Mon, 14 May 2012 14:46:26 +0900

4. ERP 도입 시 데이터 아키텍처의 활용

그리 오래지 않은 시절까지도 대부분의 사람들은 양복점에 가서 직접 옷을 맞추어 입었다. 하지만 요즈음 사람들은 백화점에 가서 자기 마음에 드는 기성양복을 골라 약간의 수선을 해서 입는다. 사람들이 보다 풍요로워져 과거에 비해 훨씬 더 까다로워졌음에도 불구하고 기성양복을 찾는 사람이 늘어나는 가장 큰 이유는 그만큼 품질이 좋아졌고, 종류가 다양해졌기 때문일 것이다. 이와 유사하게 과거에는 거의 대부분의 시스템을 자체(In-house) 개발하여 사용했지만, 요즈음은 ERP 패키지를 도입하여 자기업무에 맞도록 수선(Customizing)하여 적용하려는 구축 형태가 지속적으로 증가하고 있다.

하지만 이러한 프로젝트의 면면을 깊숙이 살펴보면 예상 외로 많은 곳에서 악전고투를 하고 있다는 것을 발견할 수가 있다. 거의 다 만들어져 있는 것을 가져다가 사용하기만 하면 될 줄 알았는데 막상 시작해보면 그리 간단한 일이 아니라는 것을 알게 된다. 심하게는 시간과 비용만 들이고 결국에는 ‘도입불가’로 결정난 프로젝트가 어디 한 둘이겠는가! 물론 ERP도입을 성공하기 위해 필요한 핵심적인 요소는 다양하게 있다고 하겠지만 여기서는 데이터 입장에서 바라 본 문제점과 해결 방법을 제시하고자 한다. 여러분의 이해를 돕기 위해 한 가지 비유를 들어보자.

[그림 1]

이 그림은 서로 형태와 용도가 다른 두 대의 차량을 기능의 존재 유무나 역할에 대해서만 서로 비교해본 것을 표현한 것이다. 만약 우리가 이 두 차량을 모두 분해하여 부품들을 일일이 비교해 본다면 거의 동일한 부품이 하나도 없을 만큼 다르겠지만 기능의 존재 유무만을 따져보면 마치 양쪽은 매우 유사한 것처럼 보인다. 사실 각 기능이 수행하는 역할까지도 매우 비슷하지 않은가? 마찬가지로 이것을 우리 조직의 업무와 ERP패키지로 비유하여 기능의 존재유무나 역할만을 비교해본다면 일견 매우 유사해 보인다.

실전에서는 현실적으로 ERP패키지의 내부를 상세하게 분석하기가 어렵기 때문에 패키지 도입을 검토할 때 대부분의 경우 이처럼 기능의 존재유무와 역할만 비교하는 방법으로 진행하고 있다. 물론 우리가 원하는 기능과 역할이 분명히 존재하고, 차이가 있는 부분을 커스터마이징하거나 우리의 업무를 바꾸어서라도 완전한 ‘우리의 것’으로 쉽게 만들 수 있다면 문제가 없겠지만, 그렇지 못할 때는 매우 심각한 문제가 발생한다. 그렇게 될 수 밖에 없는 이유를 차량의 구조변경이나 정비에 대해 비유를 해놓은 다음 그림을 통해 알아 보자.

[그림 2]

우측 그림을 보면 차량에 옵션으로 부착할 수 있는 장비들이나 소모품, 또는 치장용품들을 추가하거나 교체하는 정도는 정비소나 대리점에서도 충분히 해결할 수가 있다. 그러나 그림의 좌측에서와 같이 차체, 엔진, 구동장치, 전기장치 등을 단지 수리나 정비를 하는 것이 아니라 다른 형태로 대체하여야 한다면 자동차 생산업체나 특수 전문업체가 아니면 가능한 일이 아니다. 이것을 정보시스템에 대비시켜 보자. 가령, 화면의 구조를 변경하거나 프로그램의 추가·보완, 처리할 프로세스의 변경, 또는 개발 S/W가 변경되는 것처럼 ERP패키지의 데이터 모델 구조를 변경하지 않고서도 가능한 일이라면 SI업체나 패키지 컨설팅 업체, 혹은 자체적으로도 커스터마이징을 하여 자신의 시스템으로 만들 수 있다.

그러나 업무의 본질에 분명한 차이가 있어서 데이터 모델의 주요 골격을 일부라도 변경해야만 한다면 설사 매우 유연한 아키텍처를 가진 패키지라 할지라도 패키지 개발업체나 데이터 모델 전문 컨설팅 업체가 있어야만 가능하다. 그 이유는 조금만 생각해 보아도 분명하게 드러난다. 우리가 어떤 전자제품, 자동차 등을 구입할 때 제조업체는 고객에게 기능 설명서나 기본적인 매뉴얼 정도는 제공하지만 결코 구체적인 설계도를 우리에게 제공하지는 않는다. 마찬가지 이유로 인해 어떤 패키지를 도입했을 때 그들이 결코 완전한 설계도를 우리에게 제공할 리는 만무하다.

설사 그 대상이 패키지를 전문적으로 컨설팅을 대행하고 있는 업체라 해도 그들에게조차 내부의 상세한 설계도를 넘겨주지는 않을 것이다. 이 말은 결국 패키지 전문 컨설팅 업체라 해도 기들 또한 기능 위주로 패키지를 파악하고 있을 뿐이지 데이터 모델까지 완벽하게 이해하고 있지 않는 것이 확실하다는 의미가 된다. 어쩌면 천문학적인 비용의 유명 패키지가 사실은 우리가 원하는 수준의 상세한 데이터 모델을 아예 보유하고 있지 않고 있기 때문이라고 하는 것이 옳을 지도 모른다. 일반적인 자체 개발 시스템이 완벽한 데이터 모델을 가지지 않고서도 어떻게든 시스템이 구축되어 운용되고 있는 것처럼 지금까지 우리가 매우 우수하다고 믿고 있는 유명 패키지 또한 이런 수준을 넘지 못하고 있다는 것을 여러분은 알고나 있는가?

대단한(?) 패키지에서조차 제대로 구비된 설계도가 없는 데는 나름대로 사연이 있다. 대부분의 패키지의 탄생 내력을 살펴보면 그 속에 이에 대한 해답이 들어있다. 대부분의 패키지는 처음부터 종합적인 패키지를 만들려는 목적을 가지고 먼저 완벽한 데이터 아키텍처를 수립하여 구축된 것이 아니다. 처음에는 특정 업체를 위해 천신만고 끝에 개발한 시스템을 기반으로 하여 이를 ‘보강하는 방법’으로 탄생되었기 때문에 그렇다고 한다면 충분히 이해가 될 것이다. 필자는 세계적으로 명성을 날리고 있는 유명 패키지들의 대부분을 전부 혹은 일부분을 상세하게 리버스해 보았는데 거의 예외 없이 그렇다는 것을 확신할 수 있었다.

심지어 어떤 패키지에서는 논리적으로는 분명히 릴레이션쉽이 있어야 하는데도 불구하고 정상적인 방법으로는 연결이 불가능한 경우가 많이 나타나고 있었다. 이처럼 데이터 모델에 대한 기본적인 지식조차 제대로 갖추지 못한 무지한 설계자에게서나 찾아볼 수 있는 비정형 릴레이션쉽이 많이 나타나고 있다는 것만 보더라도 필시 이 패키지는 원래 VSAM으로 되어 있던 것을 단지 RDBMS로 컨버전한 것에 불과하다는 것을 한 눈에 알아볼 수 있다. 이러다 보니 패키지 개발업체 조차 제대로 보유하고 있지 못한 상세한 데이터 모델을 SI업체나 패키지 컨설팅 업체가 꿰뚫고 있을 리가 없다.

자동차를 생산하는 업체(패키지 개발업체)가 있고, 판매와 서비스를 담당하는 업체(SI업체, 패키지 컨설팅 업체)가 있다. 가령, 우리가 잘 알고 있는 국내 최고의 승용차 생산업체인 ‘OO자동차’가 있고, 판매 서비스 업체인 ‘OO자동차서비스’란 회사가 있다. ‘OO자동차서비스’에는 자동차 설계도면과 설계생산라인을 가지고 있지 않는 것처럼 SI업체, 패키지 컨설팅 업체는 상세한 데이터 모델을 가지고 않다.

만약 정말 다행스럽게도 데이터 모델의 골격에 거의 영향을 받지 않고서도 커스터마이징이 가능하다면 이 프로젝트는 어떻게 해서든지 성공할 수가 있다. 반면 데이터 모델에 구조적 변경이 필요하다면 매우 심각한 문제가 발생할 수 밖에 없다. 물론 이런 경우에도 현 패키지의 데이터 모델을 상세하게 리버스 할 수 있다면 어디를 어떻게 보정해야 할지 정확하게 판단해 낼 수가 있겠지만, 만약 그렇게 할 수 없다면 전혀 손도 댈 수 없는 상황이 되어 버릴 수도 있다.

필자가 알고 있는 어떤 업체는 이런 경우를 당하여 대단한(?) 일을 저질렀다가 프로젝트 실패의 길을 걷게 되었다. 처음에 도입 검토를 할 때는 차이분석을 통해 애플리케이션 모듈 단위의 역할과 기능이 패키지와 유사하다고 판단하였고, 덧붙여 선진 시스템을 도입한다는 명분으로 프로젝트가 추진되었다. 그러나 얼마 되지 않아 기능의 차이를 극복하기 위해서는 데이터 모델을 변경시켜야 한다는 것을 깨닫게 되었지만 그들로서는 패키지의 데이터 모델을 파악할 수 없었기 때문에 어디를, 어떻게 손을 대어야 할지 알 수가 없었다.

이를 위해 그들이 선택한 방법은 패키지의 기능은 그대로 사용하지만 그 속에 있는 데이터 모델은 지금까지 자신들이 사용해 오던 현행 시스템의 데이터 모델을 그대로 옮겨 둔다는 믿기 어려운, 정말 놀라운 결정을 하게 되었다. 알다시피 애플리케이션의 상당 부분은 데이터를 처리하는 영역이며, 이것은 반드시 데이터 모델에 영향을 받게 된다. 이들은 결국 데이터를 처리하는 소스코드를 전부 자신들이 직접 다시 구현해야 했기 때문에 거의 대부분의 애플리케이션에서 상당한 양의 커스터마이징이 일어나게 되는 참으로 어려운 – 도저히 이해할 수 없는 – 프로젝트가 되어 버렸다.

이것은 무늬만 패키지일 뿐이지, 그 내부에는 현행 시스템이 들어가 있는 정말 웃지 못할 이상한 모습이 되어 버렸고, 이 후에도 여러 차례 파행을 겪다가 결국에는 프로젝트가 전면 중단되는 사태로 까지 발전하였으며, 당연히 수 많은 매니저들이 옷을 벗어야 하는 안타까운 일까지 일어나게 되었다. 이러한 사례는 약간의 형태가 다를 뿐 생각보다 많은 프로젝트에서 – 특히 대형 프로젝트에서 – 많이 발생하고 있다는 사실을 우리는 결코 남의 일로만 생각해서는 안 된다. 그 동안의 시간, 인적, 물적 자원의 소비와 허공으로 날려버린 기회비용까지 생각해 본다면 참으로 엄청난 과실이라 아니할 수 없다.

요즈음 한창 각광을 받고 있는 CRM패키지를 놓고 한 가지만 더 생각해 보기로 하자. 일반적으로 CRM패키지는 업종에 관계없이 적용할 수 있도록 크게 통합되어 있다. 이것은 곧 그들이 만든 데이터 모델이 매우 포괄적으로 정의되어 있다는 것을 의미한다. 이것을 다른 말로 표현한다면 ‘이어령 비어령’이라고도 할 수 있다. 즉, 업무를 어떻게 해석하느냐에 따라 대응시킬 엔터티가 달라질 수 있다는 것이다. 이 말을 얼핏 생각하면 아무렇게나 정의해도 괜찮다는 의미로 들릴 수도 있겠다. 그렇지만 반대로 얼마나 적절하게 정의하였느냐에 따라 그 효율성에는 매우 크게 차이가 발생할 수 있다는 것도 같이 내포하고 있음을 절대 간과해서는 안 된다.

그렇다면 우리가 합리적인 판단을 할 수 있는 유일한 길은 이미 만들어져 있는 패키지의 데이터 모델이 갖는 고유의 구체적 의미를 명확히 알고, 여기에 적용시킬 우리의 업무를 명확히 알아야 ‘지피지기(知彼知己)’가 될 수 있음은 주지의 사실이다. 그럼에도 불구하고 필자가 이 프로젝트에서 패키지의 모델을 정확히 알기 위해 데이터 모델의 리버스를 해야 한다고 주장을 하자 그들은 도저히 이해할 수 없다는 표정이었다. 더욱 놀라운 것은 분명 그들이 패키지를 컨설팅하는 업체가 분명하거늘 데이터 모델의 리버스가 조금만 깊이 들어가게 되자 밑천(?)이 드러나 전혀 아무런 도움이 되는 답변을 하지 못하더라는 것이다.

더욱 재미있는 사실은 금번 리버스를 통해 지금까지 자신들이 잘 모르고 있었던 패키지의 데이터 모델이 명확해지자 지금까지 자신들이 수행한 프로젝트에서 잘못 결정했던 판단들이 이제서야 눈에 보이기 시작하고, 그것을 크게 후회하고 있더라는 사실이다. 만약 패키지의 데이터 모델을 변경하기는 하지만 집합의 구조나 정의에 변화가 일어나는 것이 아니라 단지 새로운 속성을 추가하거나 엔터티를 추가로 보충하는 정도라면 그리 어렵지 않게 적용할 수 있으므로 이 정도의 변경만으로도 문제를 해결할 수 있다면 정말 다행한 일이라 하겠다. 그러나 만에 하나 그렇지 않은 경우에 발생할 위험요소가 너무 크기 때문에 패키지의 도입 검토는 반드시 데이터 아키텍처를 통해 데이터적인 분석이 병행되어야 한다고 강력하게 주장하는 바이다.

만약 여러분이 패키지의 도입을 검토하고자 한다면 다음과 같은 절차로 진행하는 것이 바람직할 것이다.

먼저 현행 시스템을 리버스 하여 체계적인 현행 데이터 아키텍처를 수립한다. 물론 가능하다면 현행 개괄적 모델에서부터 현행 개념적 모델, 현행 물리적 모델을 작성하고 이를 논리화하여 현행 논리적 모델까지 수립하는 것이 가장 좋다. 그러나 현실적으로 곤란하다면 주요 골격 모델이 있는 현행 개념적 모델까지는 최소한 작성하여야 한다.

여러분이 보다 적극적이고 미래지향적이라면 현행 개념적 모델에서 그치지 말고 현재의 문제점이나 발전방향을 가미한 목표 개념적 모델까지는 수립할 것을 강력히 추천한다. 목표 개념적 모델을 충실하게 작성했다면 개념적으로나마 향후의 우리 시스템이 어떤 모양이 되어야 하는지를 분명히 한 것이므로 이것은 앞으로 패키지의 모델을 우리에게 어떻게 맞추어야 할지를 결정하는 중요한 기준이 될 것이다. 개념적 모델은 전체 대상의 일부에 불과하므로 마음만 먹는다면 충분히 가능한 일이라고 생각한다.

이제 ‘나’를 알았으면, 검토해야 할 ‘남’을 알아야 한다. 원래 패키지는 다양한 업무에 적용할 수 있도록 하는 것이 생명이기 때문에 항상 최소공배수의 집합으로 구성되기 마련이다. 이 말은 패키지에는 우리가 필요로 하는 것보다 훨씬 많은 것이 정의되어 있고, 다양한 경우에도 적용이 가능해야 하므로 의미 또한 구체적이라기 보다는 – 약간은 애매해 보이기까지 하는 – 포괄적으로 정의되어 있기 때문에 정확한 리버스를 한다는 것은 결코 쉽지 않다. 이런 문제를 최소화 시키기 위해서는 일단 필수 불가결한 것으로 보이는 것들만 골라낸 최소한의 대상에 대해서만 먼저 리버스를 시도하는 것이다. 아직 패키지를 구입하겠다는 낛싯밥(?)을 물지 않은 상태이므로 벤더 측에 여러 가지 자료(가령, 개념요약 자료, 매뉴얼, 테이블이나 기능 설계자료 등)를 요구해 볼 수 있다. 수단만 좋다면 데모 시스템을 설치하도록 할 수도 있을 것이며, 요즈음은 대부분 매뉴얼을 파일로 제작하기 때문에 예상 외로 상세한 자료를 쉽게 입수할 가능성도 있다.

이렇게 입수한 자료의 다과(多寡)나 벤더 측의 협조 정도, 또한 여러분의 분석능력에 따라 좌우되겠지만 가능하다면 최대한의 리버스를 실시하는 것이 좋다. 물론 어떤 경우에도 최소한 개념적 모델까지는 반드시 리버스를 하여야 한다. 여기서 말하는 개념적 모델에는 앞으로 우리의 판단에 크게 영향을 미칠 것으로 보이는 스키마들이 대부분 망라되어야 있어야 함은 물론이다. 만약 필요하다면 벤더나 패키지 컨설팅 업체, 혹은 데이터 아키텍처 전문업체의 도움을 받는 것이 현명할 것이다. 이러한 목적으로 진행되는 프로젝트를 이름하여 ‘PLANNING PROJECT’라 하자. 이 프로젝트에서는 패키지 도입을 검토하여 선정하는 것은 물론이고, 합리적인 시스템 구축전략 수립, 프로젝트의 규모 산정, 최소 비용전략 수립, 핵심 성공 전략(CSF)을 수립하게 될 것이다. 이 프로젝트는 마치 학창시절에 단체 산행을 갈 때 선발대가 먼저 도착하여 본대를 위해 미리 여러 가지를 준비하려는 것과 유사한 목적을 가지고 있다. 비록 이 프로젝트는 소규모, 짧은 기간, 낮은 비용으로 수행되어야 하지만 그 중요성은 매우 크다고 하겠다.

이러한 절차를 거쳐 다행히 특정 패키지를 도입을 하는 것이 적절한 솔루션이라고 결정되었다면 본(main) 프로젝트에서는 보다 많은 제공 자료를 이용해 상세한 데이터 아키텍처를 수립하여야 한다. 패키지란 그들이 정의한 데이터 모델을 근간으로 이미 수 많은 애플리케이션이 작성되어 있다. 이 말에는 여러분의 업무를 그들이 정의해 놓은 데이터 모델의 본래의 의미에 얼마만큼 적절하게 매핑하였느냐에 따라 애플리케이션을 커스터마이징해야 하는 양이 결정되어진다는 의미가 내포되어 있다. 즉, 패키지 도입의 결정뿐만 아니라 적용에 있어서도 데이터 모델이 기능(프로세스)보다 더 우선적인 요인이 된다는 것을 분명히 알아야 한다. 그러나 패키지를 구체적으로 리버스 모델링을 하는 일은 매우 어려운 기술을 요구하므로 접근하기가 그리 쉽지만은 않다. 그렇다고 해서 패키지 도입 검토를 단지 기능만 비교하여 결정한다는 것은 더욱 문제의 소지가 있다. 결국 패키지 도입의 확실한 성공을 위해서는 여러분이 데이터 전문가가 되든지 전문가의 도움을 받는 것이 중요한 성공의 열쇠가 될 수 있음을 명심하여야 할 것이다.

DA의 활용 - 3. 차세대 시스템 구축의 교도보로 활용

Lee화식 — Mon, 14 May 2012 14:43:53 +0900

3. 차세대 시스템 구축의 교두보로 활용

현행 시스템의 데이터 아키텍처가 제대로 수립되어 있다면 이를 이용해 차세대(목표) 시스템의 데이터 아키텍처를 수월하게 구축할 수 있다는 것은 앞서 ‘목표 데이터 아키텍처 수립 절차’에서 설명하였기 때문에 여기서는 실행 절차에 대해서는 더 이상 설명을 하지 않기로 하겠다. 다만 현행 시스템의 데이터 아키텍처가 차세대 시스템의 데이터 아키텍처 수립에 얼마나 커다란 의미가 가지고 있는지를 되새겨 봄으로써 데이터 아키텍처 수립의 당위성을 강조하고자 한다.

손자병법에 ‘지피지기이면 백전불태’라고 했듯이 먼저 현재의 시스템을 정확히 알고 난 후, 거기에 차세대 시스템의 요구사항을 적절히 반영하는 것이 다른 어떤 방법을 적용하는 것보다 가장 효과적이라는 것에 대해 이의를 제기할 사람은 거의 없으리라 생각한다. 현행 데이터 아키텍처의 수립 절차를 설명할 때 이미 언급했었듯이 현행 시스템은 비록 그 상태에 문제가 많아 더 이상의 존재가치가 없어졌다고 하더라도 그 속에는 엄연히 현재의 온갖 업무규칙(Business rule)이 대부분 녹아 있다는 것은 분명하다.

이처럼 단지 그 모습이 비효율적이고 체계적이지 못하다는 것일 뿐 원래의 업무내용은 어디엔가 구현되어 있다는 점을 결코 무시할 수 없다. 그럼에도 불구하고 만약 여러분이 현행 시스템에서 상세한 정보를 끌어 내는 것(리버스)을 포기하고 현업 사용자에게서 일일이 이를 도출하려고 한다면 훨씬 많은 시간이 필요할 것이며, 아무리 우수한 분석가에 의해 수행되었더라도 필시 많은 정보가 누락되고 결과에 대한 오류가 포함될 수 밖에 없을 것이다. 또한 여러분에게는 이미 현업의 모든 담당자와 인터뷰하여 필요한 모든 정보를 도출할 수 있는 기회가 원천적으로 박탈되어 있다는 점을 무시해서는 안 된다.

물론 여러분과 인터뷰한 그들이 다방면에서 해박한 업무지식을 가지고 있을 수도 있겠지만 결코 모든 업무에 대해 완벽하게 정통할 수는 없을 것이다. 그들은 자기과시나 때로는 자신의 무지를 감추기 위해서 가끔은 분명하지 않은 정보를 마치 확실한 것인 양 제공할 수도 있다는 것을 절대 간과해서는 안 된다. 지나친 말인지는 모르겠지만 절대로 사람을 믿어서는 안 된다. 좀더 정확하게 표현한다면 ‘사람만을 믿어서는 곤란하다’라고 하는 것이 보다 적절한 표현일 것 같다.

실제로 필자는 실전에서 모델링을 하면서 가능하다면 현재의 데이터를 자주 참조해 보기도 한다. 이것은 어쩌면 만일에 있을 그들의 오류로 인해 나 자신이 혼란의 소용돌이에 빠지지 않기 위한 자구책일지도 모른다. 재미있는 사실은 이러한 경우 대부분은 그들이 제공한 정보에 실제로 오류가 있었다는 것이다. 혹자는 이를 두고 ‘동물적인 감각’을 가지고 있는 것이 아니냐고 농담을 하기도 하지만 이것은 분명한 사실이다. 그만큼 그들이 우리에게 생각보다 많은 오류 정보를 주고 있다는 것을 엄연한 현실로 받아 들여야 한다는 것이다. 그들이야 나중에 잘못이 드러나면 단지 “미안, 미안, 내가 착각했어”라고 하면 그만이겠지만, 돌을 맞아야 하는 우리 같은 개구리들에게는 때로는 상당한 치명타가 될 수도 있다.

굳이 일부러 현업 담당자들을 비하할 생각은 없지만 사실 그들이 대단한 전문지식을 가졌다고 생각하지는 않는다. 이 말은 그들이 무식하다는 의미가 아니라 우리가 분석력만 가지고 있다면 어렵지 않게 파악할 수 있는 정도의 지식일 뿐 결코 도저히 넘을 수 없는 수준은 아니라는 것이다. 오히려 그들은 우리처럼 구조적이고 체계적인 접근을 하려고 하지 않기 때문에 상당부분 경험적으로 판단한 것이어서 조금만 체계적으로 파고들면 금방 밑천(?)이 드러나게 되는 경우가 대부분이다.

현행 시스템의 아키텍처를 리버스할 때 얻을 수 있는 또 한가지의 커다란 의미는 바로 현재 애로사항을 겪고 있는 숙원사업(?)이 무엇인지를 분명히 할 수 있다는 것이다. 다시 말해서 현 시스템의 문제가 무엇인지, 어디가 비효율적인지, 왜 그러한 문제가 발생했는지 등을 찾을 수 있다는 것이다. 과거를 바로 알지 못하고서는 결코 올바른 미래를 만들 수 없다고 했다. 우리는 논어(論語)에서 공자가 말한 ‘온고지신(溫故知新)’이란 말의 의미를 잘 알고 있다. 이 말은 ‘옛 것을 앎으로서 그것을 통하여 새로운 것을 알게 된다’는 뜻이다.

생각해 보라! 현행 시스템에 있는 테이블이나 컬럼 중에는 개발 후 몇 년 만에 탄생된 것도 있을 것이 아니겠는가! 수 년 동안 수 많은 밤을 새워 유지·보수한 내용들이 고스란히 현행 시스템의 어디엔가는 박혀 있을 게 아니겠는가! 물론 버리고, 잊어도 좋을 것들이야 없으랴마는 그 귀한 땀방울이 거쳐간 수 많은 내용들을 모두 생매장 할 수는 없지 않겠는가? 이러한 이유 때문에 차세대 시스템을 구축을 하고자 할 때 이미 현행 시스템의 데이터 아키텍처가 제대로 수립되어 있다는 것은 참으로 커다란 의미를 가지고 있다고 하겠다.

혹자는 이런 방법을 사용하면 물론 좋기야 하겠지만 너무 많은 시간을 소비할 것이 분명하므로 현실적으로는 선택할 수 없는 방법이라고 할지도 모른다. 그러나 그것은 하나는 알고 둘은 모르는 생각이다. 어차피 파악해야만 할 것이라면 오히려 조금이라도 먼저 실시하는 것이 훨씬 유리하리라는 것은 설명할 필요도 없다. 만약 어떤 결정을 할 때 필요한 요소들의 일부만 가지고 판단했다면 오류가 발생할 수 있음은 너무나 당연하고, 뒤 늦게 새로운 결정인자가 나타나면 자꾸만 결정은 번복되게 마련이다. 이러한 번복이 자신만 변경시킨다면 다행이겠지만 종속성을 가진 주변이 같이 변경되고, 다시 그 주변에 종속된 것들이 연쇄반응을 일으키게 된다면 일파만파의 파장을 몰고 올 것이 분명하다.

마치 마음이 급하다고 해서 신발도 제대로 신지 않고 뛰어가는 것은 우선은 빨리 가는 것처럼 보일지도 모른다. 마찬가지로 현행 시스템을 체계적으로 분석하는 것을 포기하고, 목표 시스템부터 설계하는 방법은 일단 진행이 빠른 것처럼 보일 수도 있다. 그러나 ‘먼 길을 갈 때일수록 신발끈을 제대로 매어라’는 격언처럼 프로젝트란 어차피 ‘먼 길’이기 때문에 신발끈을 제대로 매지 않으면 결국에 가서는 수 많은 시행착오에 빠져 ‘갑이 인정하는 최소 품질’이 목표가 되었음에도 불구하고 일정도 지키지 못하고, 사람들은 극도로 지쳐 있으며, 개발비용 또한 한참이나 초과되어 버린 ‘고생만 하고 얻은 게 없는 프로젝트’가 되기 십상이다.

물론 머지 않아 없어질 현행 시스템을 무조건 최대한 상세하게 리버스를 하라는 것은 결코 아니다. 너무 고지식하게 받아들여 모든 내용을 완벽하게 분석하려 든다면 너무 많은 시간을 들여야 하기 때문에 현실을 적절하게 감안하여 지혜롭게 접근할 필요가 있다. 앞서 설명한 적이 있었지만 시스템에는 ‘무엇을 하고자 하는가?(what-to)’와 ‘어떻게 해야 하는가?(how-to)’에 대한 내용으로 나눌 수 있다고 했다. 여기서 우리가 취해야 할 것은 ‘WHAT-TO’일 뿐이지 ‘HOW-TO’가 아니라는 것이다. 어쩌면 여러분이 작성한 애플리케이션의 소스코드의 70~80%는 바로 이 ‘HOW-TO’에 관한 내용일 것이다. 이것까지 분석하려 든다면 끝없는 미궁 속으로 빠져 들 수도 있다.

만약 여러분이 전문가적인 능력을 가져서 ‘봐야 할 것과 보지 말아야 할 것’을 확실히 구분할 수 있고, ‘먼저 봐야 할 것과 나중에 볼 것’을 정확히 가려 낼 수 있다면, 현행 시스템을 먼저 구체적으로 분석하고 이를 바탕으로 차세대 시스템을 구축해 가는 방법이 오히려 시간과 비용을 최대로 절약할 수 있는 유일무이한 방법이라는 것을 이해하게 될 것이다.

한 가지 분명한 것은 분석한 현행 시스템의 자료가 단순히 ‘수집된 정보’ 수준이어서는 아무런 의미가 없다는 것이다. 정보를 단순하게 수집하고 그것을 열거해 두는 수준이 아니라 분명한 의미를 파악하여 본질을 찾아내고 그것을 독립적인 객체로 정리해 둘 수 있어야 한다. 뿐만 아니라 이러한 정보를 보다 합리적인 잣대로 평가할 수 있어야 리버스의 진가를 얻을 수 있다. 이러한 기반이 없는 상태에서 현행 시스템을 분석한다는 것은 마치 글자의 뜻도 모르면서 소리나는 대로 읽기만 하여 아무리 읽어도 그 의미를 알지 못하는 것과 다를 바 없다.

여러분들이 리버스 모델링을 통해 정말 체계적인 현행 시스템 분석을 하고자 한다면 먼저 이 책의 전체에서 설명하고 있는 데이터 모델링에 대해 보다 확실한 내공(?)을 쌓아야 한다. 이를 바탕으로 체계적인 분석을 한다면 분명 소기의 목적을 쉽게 달성할 수 있을 것이다.

DA의 활용 - 2. 시스템 유지보수 생산성의 향상에 활용

Lee화식 — Mon, 14 May 2012 14:43:35 +0900

2. 시스템 유지·보수 생산성의 향상에 활용

현행 데이터 아키텍처는 현 시스템의 데이터 구조를 매우 구체적이고 체계적으로 보유하고 있으므로 이를 이용하여 시스템의 유지·보수에 다양하게 활용할 수 있다는 것은 너무나 당연하다. 시스템이란 결국 ‘애플리케이션이 데이터를 조작하는 것’이라 할 수 있다. 이는 마치 ‘근육이 뼈대를 움직이는 것’과 유사하다고도 할 수 있다. 이 말을 다른 말로 바꾸어 보면 본질이 되는 데이터의 형태가 변경이 되면 애플리케이션은 필연적으로 변경될 수 밖에 없지만 설사 애플리케이션이 변경되더라도 데이터 형태에는 변화가 발생하지 않는 경우가 많이 있을 수 있다는 것을 의미한다.

또 다른 의미로는, 단위 애플리케이션의 변화는 상대적으로 주변에 미치는 영향이 덜 하지만 데이터 구조가 변경이 되면 영향을 받을 수 있는 것들이 매우 많을 수 밖에 없다는 의미도 내포하고 있다. 이런 이유 때문에 대부분의 사람들은 현실에서 발생할 수 밖에 없는 업무의 변경을 소화하기 위해서 데이터 구조를 최적화하는 것은 최대한 피하고, 어떻게 해서라도 애플리케이션을 변경하여 해결하려고 하는 경향이 강하게 나타나고 있다. 만약 현행 시스템의 데이터 구조가 효율적이지 못하고 더구나 그것이 투명하게 관리되고 있지 않다면 필연적으로 이러한 데이터를 기반으로 작성된 애플리케이션은 매우 복잡한 형태로 나타날 수 밖에 없다.

이러한 애플리케이션은 많은 문제를 안고 있기 때문에 개발이 완료된 후에도 오랜 시일을 거쳐 수없이 보완되고서야 겨우 안정화 단계에 도달할 수 있었을 것이다. 이처럼 천신만고 끝에 이룩한 안정화를 누가 감히 깨어버릴 엄두라도 낼 수 있겠는가! 물론 업무변경으로 인한 유지보수가 일부 애플리케이션을 보완하는 것만으로도 충분하다면 문제될 것이 없겠지만 데이터 구조의 변화가 필요한 정도라면 여러분은 중차대한 갈림길에 서 있다고 할 수 있다. 다시 말해서 시스템이 점차적으로 개선되는 쪽으로 가느냐, 아니면 갈수록 썩어 들어가느냐에 대한 기로에 서 있다는 것이다. 비록 지금의 데이터 구조에 심각한 문제가 있다손 치더라도 ‘떡본 김에 제사 지낸다’는 속담처럼 이왕 수정해야 할 상황이 되었으니 이제라도 잘못된 것을 확실하게 바로 잡겠다는 생각을 했다면 분명히 시스템은 날이 갈수록 개선이 되어 갈 것이 틀림이 없다.

그러나 시스템의 데이터 구조를 건드렸을 때 이제서야 겨우 안정화되기 시작한 기존의 애플리케이션이 다시 잘못될 수도 있다는 공포감 때문에 근본적인 문제를 개선하는 쪽으로 갈 수 없도록 한다. 사실 이러한 일이 발생하는 이유는 단지 수정할 내용이 너무 많아지기 때문이라고 하기 보다는 데이터 구조가 투명하게 관리되고 있지 못하고 있기 때문에 함부로 건드렸다가는 어떤 일이 발생할지도 모른다는 불안 때문이라고 하는 것이 보다 정확한 표현일 것이다. 이런 이유로 인해 기존의 시스템에 오너쉽을 가지고 있는 쪽에서는 ‘데이터 구조 변경은 절대 불가하다’고 배수의 진을 치게 된다.

이처럼 기득권(?) 세력들의 워낙 완강한 저항에 부딪혀 개선을 하겠다는 개혁파들은 어쩔 수 없이 눈물을 머금고 작전상 후퇴를 하지 않을 수 없다. 여기서 작전상 후퇴란 바로 기존의 테이블을 그대로 두고 이와 유사한 새로운 테이블을 생성하는 것을 말한다. 새로운 데이터가 생겨 난다는 것은 대개의 경우 새로운 애플리케이션이 필요해진다는 것을 의미한다. 이러한 현상으로 인해 데이터 모델이 추가되는 속도보다 훨씬 빠른 속도로 애플리케이션이 증가하는 심각한 문제를 불러오게 된다. 물론 이와 같은 방법으로 문제를 해결하는 것이 당장은 현재의 문제를 손쉽게 해결할 수 있을지 모르겠지만 이는 곧 시스템이 계속해서 썩어 들어가고 있다는 것을 의미하고 있다는 것을 반드시 명심해야 할 것이다.

데이터 모델이 계속 늘어나고 거기에 따라서 애플리케이션이 증가하게 되면 당연히 데이터의 일관성은 나빠진다. 이런 문제를 해결하기 위해 오차(gap)을 메우기 위한 애플리케이션이 다시 등장하게 된다. 이러한 악순환은 시스템에 지속적으로 악성종양을 증가시키며, 결코 저절로 어느 날부터는 감소 추세로 돌아 설 확률은 전혀 없다. 복잡도가 덜할 때에도 근본적인 문제를 해결하지 못했는데 이미 곳곳이 곪아 있는 상태에서라면 더더욱 근본적인 해결은 꿈도 꿀 수 없다. 이제 시스템은 중병이 들어 많은 유지·보수 인력의 각고의 보살핌에 의해 근근이 버티다가 생명주기(life_cycle)를 제대로 채우지도 못하고 재개발의 전철을 밟게 될 것이다. 이것은 누구도 부인할 수 없는 엄연한 현실의 모습이다.

결국 모든 문제의 갈림길은 데이터 구조를 투명하게 관리하고 있느냐에 대한 문제와 데이터 구조의 문제를 애플리케이션으로 막지 않도록 하기 위해 더 늦기 전에 올바른 노력을 기울여 왔느냐에 있다고 할 수 있겠다. 이 말은 데이터 구조가 투명하고 구체적으로 관리되고 있어야 한다는 것과 프로그래머가 함부로 애플리케이션만 수정하고자 하는 미봉책을 쓰지 않도록 적극적인 통제 조직의 역할이 필요하다는 것을 분명히 하고 있다. 이것은 곧 시스템을 썩지 않고 오래도록 유지하기 위해서는 반드시 데이터 아키텍처가 수립되어 있어야 한다는 당위성과 데이터를 관리하는 전문 조직이 반드시 필요하다는 것을 뜻하고 있다.

이 두 가지의 요건 사이에는 매우 필연적인 종속 관계를 가지고 있다. 비록 아무리 완벽한 데이터 아키텍처가 수립되어 있다고 하더라도 이를 이용해 제대로 된 통제를 할 수 있는 조직이 없다면 유명무실해 질 수 밖에 없으며, 아무리 우수한 조직이 준비되어 있더라도 그들에게 정확한 현황정보를 제공할 수 없다면 아무 것도 할 수 없다는 것은 지극히 자명하다. 물론 아직은 어디에도 완벽한 데이터 아키텍처가 수립되어 있지도, 이를 적극 활용할 조직이 제대로 준비되어 있지도 않지만 세상은 반드시 ‘발전하는 방향으로 진화해 갈 것’이 분명하므로 머지 않아 이러한 세상에 오리라고 믿어 의심치 않는다.

데이터 아키텍처가 보다 분명한 시스템 유지·보수 수단이라는 것을 확실히 하기 위해서 필자가 경험한 어느 프로젝트의 예를 들어 보겠다. 이 프로젝트는 수백 억의 비용이 소요된 대형 프로젝트였지만, 시작 초기부터 여러 가지 잡음이 끊이질 않았다. 약 2년이 넘게 프로젝트가 진행되어 오면서 ‘갑’과 ‘을’이 모두 다른 회사로 합병되는 우여곡절도 겪었다. 그 와중에서 천신만고 끝에 개발한 시스템을 몇 번에 걸쳐 오픈을 시도해 보았지만 번번히 실패로 끝나고야 말았다. 급기야 대부분의 개발자들은 극도로 지쳤고 의욕도 상실된 상태에서 혜성(?)같이 나타난 컨설팅 업체의 도움을 받아 극적으로 성공적인 오픈을 할 수 있었다.

그러나 이 프로젝트는 현재로서는 일단 정상적인 오픈을 하는 것이 최대의 과제였기 때문에 눈앞에 보이는 문제를 해결하기 위해 급격하게 이루어진 많은 변경사항들을 제대로 관리할 수가 없었다. 결국 천신만고 끝에 오픈을 하였지만 이제부터 그들에게 남겨진 과제는 정상적인 유지·보수 활동을 수행해야 한다는 것이었다. 불행히도 개발에 참여한 모든 사람이 그대로 유지·보수를 담당할 수는 없었다. 개발자들은 SI업체 요원이었기 때문에 유지·보수는 응당 시스템을 인수받은 ‘갑’의 몫이 될 수 밖에 없었기 때문이었다. 지금까지 ‘갑’들은 단지 프로젝트 결과만 체크해왔지 내용에 대해서는 깊게 관여하지 않았기 때문에 ‘을’이 제공한 산출물의 품질을 정확하게 검증할 수가 없음은 당연한 일이었다.

애플리케이션이야 물론 어느 정도의 수준에 도달한 프로그래머라면 얼마 동안 운영해 보면 파악이 가능할 것이다. 그러나 데이터 모델은 구체적인 자료가 없다면 웬만해서는 깊이 있는 파악이 불가능하므로 시스템의 본질인 데이터 구조를 정확히 인식하지 못한 채 유지·보수가 실시되었다. 데이터 모델은 다수의 애플리케이션에서 사용되기 때문에 데이터 구조를 정확히 알지 못한 채 실시되는 유지·보수는 필연적으로 크고 작은 많은 시스템 사고를 겪을 수 밖에 없었다. 결국 이런 문제를 해결하기 위해 데이터 아키텍처를 수립하게 되었고, 애플리케이션 아키텍처와 연결하여 어떤 데이터가 어떠한 애플리케이션에 어떤 목적으로 사용되었는지 까지도 관리할 수 있음으로 해서 과거에 비해 훨씬 소수의 인력으로 보다 양질의 유지·보수를 할 수 있게 되었다.

DA의 활용 - 1. 전사적 아키텍처 수립의 기반으로 활용

Lee화식 — Mon, 14 May 2012 14:43:13 +0900

데이터 아키텍처의 활용

우리는 지금까지는 데이터 아키텍처의 개념과 그 접근 방법에 대해서 알아 보았다. 사실 이에 못지 않게 우리에게 중요하고 관심이 있는 사항은 데이터 아키텍처를 어디에, 어떻게, 왜 활용해야 하는지를 좀더 명확히 정의해 보는 것이리라 생각된다. 아키텍처를 해야 하는 가장 큰 이유는 구체적이고 합리적인 설계과정을 보다 체계적이고 구조적으로 접근하자는 것이다. 물론 이러한 접근은 비록 처음에는 그 과정이 다소 어렵게 느껴지더라도 당연히 우리에게 많은 장점들을 제공해 줄 것이 틀림없다.

다음에 제시할 데이터 아키텍처의 활용 형태를 살펴보면 아마 여러분이 당면한 상황에 따라 눈이 번쩍 뜨이게 관심을 끄는 형태가 몇 가지는 있으리라 자신한다.

1. 전사적 아키텍처 수립의 기반으로 활용

데이터 아키텍처를 수립하는 가장 대표적인 경우를 들라고 하면 아무래도 전사적 아키텍처를 수립할 때 적용하는 경우라고 할 수 있겠다. 물론 아직은 전사적인 아키텍처를 수립할 엄두를 못 내고 있는 곳이 대부분이겠지만 머지 않아 대다수가 이를 채택할 것이 틀림없다. 여러분은 앞서 쟈크만 프레임워크에서 제일 좌측에 있는 ‘WHAT’에 해당하는 것이 바로 ‘데이터’였으며, 이것은 바로 데이터야 말로 아키텍처의 가장 근본적인 구성요소임을 나타내는 것이라 했던 것을 기억하고 있을 것이다.

데이터 아키텍처는 다른 어떤 아키텍처보다 논리적이고 구체적이어야 하며, 전문가의 도움을 받지 않고서는 제대로 된 아키텍처를 수립하기란 정말 쉽지 않다. 물론 겉모양을 대충 흉내만 내는 방법도 있을 수는 있겠지만 진정한 데이터 아키텍처는 앞서 여러 번 강조해 왔듯이 매우 구체적이고 상세하게 정의되어야 하므로 전문가의 도움 없이는 개략적이고 추상적인 결과밖에 얻을 수 없다. 여러분은 아마 앞으로 설명할 이 책에 있는 내용들을 읽어 보면서 때로는 ‘나도 할 수 있다’는 자신감을 느끼게 되고, 때로는 명확한 개념이나 판단 기준에 탄성을 지르고, 또 때로는 ‘과연 내가 저만큼 구체적이고 객관적으로 정의할 수 있을까?’ 라는 생각에 오히려 자신감을 잃을지도 모른다.

전사적인 모든 데이터 집합들을 도출해서 이를 모두 포함하는 전사적인 개괄적 모델을 구성하는 것은 마음만 먹으면 충분히 할 수 있다. 그러나 중요한 엔터티들을 발췌하여 집합을 명확히 하고, 과감한 통합이나 분리를 하는 것부터는 그리 쉽지 않은 단계임이 분명하다. 더구나 모든 데이터들을 본질에 충실하도록 구체적이고 상세하게 정의한 완벽한 논리적 모델을 작성하는 것은 결코 쉬운 일이 아니다.

단지 간호사가 조사해준 자료를 그대로를 그려두는 정도가 아니라 의사의 눈으로 다시 분석하고 종합적으로 진단한 수준높은 결과가 들어가 있는 처방전이 되어야 한다. 물리적 모델 역시 단지 데이터 딕셔너리가 표현되어 있는 정도가 아니라 상세한 업무규칙과 데이터베이스적인 정의사항(각종 제약조건, 트리거 등)이 상세하게 정의되어 있어야 한다.

물론 이러한 모든 정보는 문서적인 표현이 아니라 시스템(CASE 툴)에 의한 데이터로써 표현되어야 한다. 아무리 엄격한 통제를 하더라도 사람에 의해서 문서적으로 관리되는 방법은 결코 오래 유지되지 못한다. 세월이 흐르면 결국은 문서와 실제는 일관성이 깨어질 것이 틀림없기 때문이다. 그렇다면 우리는 이러한 모든 것을 시스템적으로 관리할 수 있는 도구를 활용하지 않으면 안 된다. 문제는 여기에 적용되는 유사한 도구들을 찾을 수는 있겠지만 단지 최종 결과, 그것도 개략적인 내용만 관리하는 도구라면 오히려 문서적으로 관리하는 것보다 나을 것이 없다는 것을 명심해야 한다.

전사적인 아키텍처를 수립하는데 데이터 아키텍처가 누락되어 있었다고 가정해 보자. 물론 아키텍처의 목표를 단지 개괄적인 단계만 수립하는 정도에 두었다면 굳이 데이터 아키텍처가 없더라도 크게 문제될 것이 없겠지만, 그 보다 상세한 아키텍처를 수립하겠다면 시스템의 본질에 해당하는 데이터를 무시하고서는 결코 진정한 아키텍처를 수립했다고 말할 수 없을 것이다. 만약 현업 사용자처럼 자신의 요구만 내어 놓으면 누군가 시스템을 구축해 줄 것이므로 시스템 구축과 관련된 고민을 할 필요가 없다면 구체적인 설계도 따위는 필요치 않을 것이다.

그러나 우리는 분명히 시스템 구축과 유지보수의 직접 인력이다. 우리마저 시스템의 본질을 무시하고 구체적인 설계도를 포기한다면 누가 있어 점 하나만 틀려도 문제가 발생하는 정보시스템을 지켜 줄 것인가! 머지 않아 지금까지의 주먹구구식이 아닌 올바른 아키텍처의 기반 하에 시스템이 구축되고 운영되는 세상은 분명히 온다. 비록 어려운 작업이기는 하지만 그 근간(골격)이 되는 데이터 아키텍처를 단단히 관리해 두는 것은 우리 정보시스템의 수준을 한 단계 높이는 유일한 방법이 될 것이라 믿어 의심치 않는다.

정보기술 아키텍처를 통한 해결

Lee화식 — Mon, 14 May 2012 14:42:42 +0900

PURPOSE

정보기술 아키텍처의 해결

SCOPE & APPLICATION

KEY IDEA

(KEY WORD : 데이터화, 전문화, 시스템화, 구조적, 구체적, 단계적 접근)

DESCRIPTION

정보기술 아키텍처를 통한 해결

지금 대두되고 있는 문제의 핵심이자 해결의 키 포인트는 어떻게 전사적인 영역을 ‘구조적’으로 접근하여 매우 ‘구체적’인 전략을 문서화가 아닌 ‘데이터화’로 할 수 있느냐에 있다고 하겠다. 이를 위해서 필연적으로 뒤 따라야 하는 것이 바로 ‘시스템화’와 ‘전문화’라고 할 수 있다. 결국 이 다섯 가지 키워드를 어떻게 완벽하게 만족하도록 할 것이냐에 문제 해결의 대안을 찾아야 할 것이다.

‘구조적’으로 접근해야 한다는 것은 단계적으로 접근해가야 한다는 것과 유사한 의미이다. 세상의 어떠한 일이라도 한번에 바로 상세한 단계가 결정될 수는 없을 것이다. 설사 그것이 가능하다 하더라도 전체적인 전략을 기반으로 하지 않고서는 결코 오래 유지될 수 없을 것이 분명하다. 어떤 목적으로 어떤 건물을 지어야 할지도 결정되지 않았는데 창문이나 도어록을 들먹여서는 안 된다. 상위로 올라갈수록 내용은 단순해지지만 중요성은 크게 증가한다. 수 많은 자재의 위치를 결정하는 것에 비해 어떤 건물을 지어야 할 것인지를 결정하는 것은 매우 단순한 작업이지만 그 중요성은 비교할 바가 못 된다.

그러나 정말 놀랍게도 최첨단의 영역이라고 자타가 공인하는 정보시스템 구축에서 나무만 보지 숲을 보지 못하는 일이 비일비재하게 일어나고 있다. 그것은 ‘왜 해야 하는가?’와 ‘무엇을 해야 하는가?’를 생각해 보는 것보다 ‘어떻게 해야 하는가?’에 대해서만 집착하는 잘못된 접근 방법 때문이다. 왜 해야 하는 지가 결정되지 않은 상태에서 무엇을 할 것인지를 결정할 수 없으며, 무엇을 해야 할지도 모르면서 어떻게 할 것인지를 고민한다는 것 자체가 도저히 이해할 수 없는 일이다.

이런 문제를 해결하기 위해 정보기술 아키텍처는 최상위 단계에서부터 최하위 단계에 이르기까지 규정된 매우 뚜렷한 단계에 따라 접근해 가기를 강요하고 있다. 물론 방법론에 따라 단계의 정의에는 차이가 있지만 이러한 단계적 접근은 반드시 준수되어야 하며, 각 단계별 정보는 반드시 서로 긴밀하게 연결되어 있어야 한다는 것에는 이견의 여지가 없다. 각 단계를 적절하게 분할하는 것은 각 단계마다 고유한 목적이 있고 소유자도 다르며, 상위 단계의 결정이 하위 단계에 적용되어 상세화 되어 지고, 하위 단계의 변화로 인해 상위 단계가 영향을 받지 않도록 하는 등의 효과가 있기 때문이다.

‘구체적’이 되어야 한다는 것은 두 가지 측면에서 강조된다. 한 가지는 결정된 결과뿐만 아니라 진행되어 가는 과정까지 구체적이어야 한다는 것이며, 다른 한 가지는 이차원적이 아닌 다차원적인 표현이 되어 있어야 한다는 것이다. 건물의 도면에는 복덕방에서 볼 수 있는 평면도가 있고 공사현장에서 사용하는 청사진이 있다. 복덕방 평면도에는 개략적인 형태만 나타나 있지만 청사진에는 매우 구체적인 내용이 기술되어 있다. 아키텍처가 지나치게 개념적인 선에서 끝나 버리면 단순한 지침이나 안내서에 지나지 않는다. 이것은 앞으로 적용자들의 작위적인 판단에 의한 전횡(?)을 예고하는 것이기도 하다.

우리가 비록 아키텍처의 접근 방법을 여러 단계로 나누었다고 하더라도 과정 없이 바로 결론을 얻을 수는 없다. 과정을 무시하면 결과 또한 제대로 유지되지 않는다. 과정을 아키텍처적으로 진행해 간다면 논리적으로 볼 때 결과는 과정의 한 형태에 불과하므로 당연히 아키텍처적으로 나타나게 된다. 만약 여러분이 과정을 아키텍처적인 접근을 하지 않고 결과만 아키텍처로 나타내려고 한다면, 아키텍처를 도입한 것이 단지 흉내만 내는 겉치레를 하고 있을 뿐이라는 것을 명심해야 할 것이다. 이런 의미에서 우리는 앞으로 데이터 아키텍처 수립에 있어서 과정을 지원하기 위한 많은 구체적인 접근 방법과 판단의 기준들을 제시할 것이다.

내용이 매우 구체적이어야 한다는 것에는 대략적으로 정의해 두는 것은 단지 요식행위에 지나지 않는다는 것과 아키텍처를 부실하게 하여 품질을 떨어뜨리고 일과성에 그치게 하여 존재가치 자체를 부정하게 하는 절대적인 의미를 가지고 있다. 세상만사 이치가 그러하다. 귀하고 가치 있는 것은 결코 함부로 취급하지 않는다. 부실하게 만들어진 것은 귀한 대접을 받을 수 없으며, 부실하게 만들었다는 것은 이미 귀하게 여기고 있지 않다는 것이며, 오래 동안 더불어 함께할 생각이 없음을 예고하고 있다. 이처럼 구체적이지 못한 아키텍처는 부실할 수 밖에 없으며 단지 흉내만 내기 위해 만든 것에 오래 관심을 기울일 리가 없음은 너무나 분명하다.

여러분이 진정 의미 있는 아키텍처를 수립하겠다면 구체적인 내용을 정의하기 위해 많은 고심을 하여야 할 것이다. 조금씩의 진척이 있을 때마다 그 중간 과정이 관리되어 다음 결정을 위한 상수로써 제공되어야 한다는 것은 매우 중요하다. 그 결정들이 매우 구체적이어야 하고, 그 내용들이 매우 상세하게 유지되어야 비로서 본래의 의미를 살릴 수가 있다.

그렇지만 이렇게 구체적인 내용들을 서술적으로만 기술한다면 심각한 문제에 봉착하게 될 것이 확실하다. 서술적인 문장은 반드시 사람이 눈을 통하여 읽고 뇌를 이용하여 그 의미를 해석하여야 비로소 정보로서 의미를 가진다. 이와 같이 사람이 일일이 개념적인 인지를 통해서만 의미가 전달된다는 것은 문서가 비록 전자화되어 있기는 하지만 데이터적인 분석이나 활용이 곤란하므로 시스템적이라고 말할 수는 없다. 뿐만 아니라 기술한 사람의 문장력이나 습성, 개인차에 따라 매우 다양한 차이가 나타날 수 밖에 없으므로 문서 단위로는 관리할 수 있겠지만 그 속의 내용을 확인하거나 관리는 할 수는 없다는 치명적인 단점을 가지고 있다.

이런 문제의 해결을 위해서 반드시 필요한 것은 바로 ‘데이터화’를 해야 한다는 것이다. 데이터화를 한다는 것은 아키텍처의 상세 내용이 리파지토리(repository)에 모두 관리될 수 있어야 함을 의미한다. 이 말은 아키텍처가 반드시 시스템적으로 접근해야만 한다는 것을 분명히 나타내고 있다. 서술적인 방법을 사용한다면 굳이 시스템화를 하지 않더라도 각종 문서 관리 툴을 활용하는 정도로서도 충분하겠지만 데이터적으로 접근하는 순간 더 이상은 워드 프로세서를 활용하는 것만으로는 불가능하기 때문이다.

그렇다면 과연 구체적인 과정을 나타낼 수 있고, 이러한 모든 과정을 결정해 가는데 진정으로 도움을 줄 수 있는 아키텍처용 전문 툴이 제공되고 있는가에 대한 문제는 좀더 생각을 해보아야 할 것으로 보인다. 사실 툴을 만드는 사람 입장에서는 본다면 요구(needs)를 가진 사람이 많이 있어야 툴을 제작하여 판매를 할 생각을 하게 될 것이다. 그러나 불행하게도 이제껏 그런 요구를 하는 사람이 거의 없었기 때문에 아직도 우리가 원하는 수준의 툴이 제대로 제공되지 못하고 있다. 방법론과 그것을 적용하는 사람, 그리고 그들이 사용할 도구는 서로 밀접한 관계를 가지고 있다. 이것들 간에는 서로 주고 받는 미묘한 역학 관계가 존재하며 서로 더불어 진화해 가는 특성을 가지고 있다. 이들이 발전하면서 서로 간에 영향을 미치며 다른 것을 변모시키며, 이렇게 상호 순환되는 힘이 동력으로 발전하여 세상의 패러다임을 바꾸어 나간다. 이 문제는 간단하게 취급될 것이 아니기 보다 발전적인 진화를 위해 우리가 해야 할 일들을 뒤에서 별도로 언급하기로 하겠다.

마지막 다섯 번째 키워드인 ‘전문화’는 어쩌면 문제 해결의 가장 핵심이라 할 수도 있다. 무릇 새로운 것을 시도하기 위해서는 먼저 그것을 담당하는 사람이나 조직부터 생겨나야 한다. 모든 일은 결국 사람이 하는 것이기 때문에 그것을 담당하는 사람의 역할과 능력이 가장 영향력을 가질 수 밖에 없다. 문명이 발전되지 않았던 때일수록 이것 저것 모두 섭렵하는 자급자족의 시대였지만 발전된 세상일수록 점점 더 좁고 깊게 접근하는 전문화의 형태로 나타난다.

전문화는 또한 그 힘의 결집을 위해서 합병.통합(consolidation) 형태로 나타나고 있다. 전문 상가가 아닌 지역에서 유사한 상점이 들어서면 피나는 경쟁 체제가 되지만 동종업체가 모여 있는 전문 상가에는 오히려 손님들의 발길이 끊이지 않는다. 이것이 바로 발전된 사회의 모습이다. 최첨단 산업이라고 남들이(?) 알고 있는 IT사업에 그것도 인간의 두뇌를 활용하는 S/W 산업에 내면은 어떤 모습이라고 생각하는가? 물론 100% 자급자족은 아니겠지만 상당 부분은 자급자족 형태인 것만은 분명하다. 자신이 설계하고 자신이 프로그래밍하고 자신이 관리한다. 6개월된 신입사원도 테이블을 생성하고 6년된 경력사원도 그렇게 한다. 자신이 담당한 서브 시스템의 설계에 다른 곳에서 시시비비를 걸어 오는 사람도 없다.

거의 대부분의 일들이 우리 서브 시스템 내에서 자급자족으로 이루어 진다. 전체적으로 이루어지는 것은 ‘공통’이라고 명명된 일부 테이블이나 일부 모듈에 그치고 있다. DBA는 업무적인 것에는 관심이 없고 문외한일 뿐이며, 단지 시스템이나 DBMS버전을 업그래이드(upgrade)하거나 백업, 각종 오브젝트를 관리하는 정도의 일만 하는 단순 기술자에 불과하다. 이것을 과연 전문화되어 있는 형태라고 말할 수 있겠는가? 세상의 패러다임이 올바른 모습으로 변해가기 위해서는 먼저 그 일을 맡을 사람부터 전문화 되어야 하며, 이를 위해서는 그 역할을 담당할 전문조직(직책)이 무엇보다 우선되어야 한다.

특히 어떤 조직에서든 프로세스를 담당하는 사람이나 조직들은 항상 존재하므로 무엇보다도 시급한 것은 데이터를 전문적으로 취급하는 조직이 필요하다고 할 수 있다. 사실 근자에 들어와서 여러 곳에서 데이터분석가(DA, data Analyst), DA팀, 데이터통제실(DCC, data control center), 데이터 아키텍트, 데이터모델러, 컨설턴트 등의 직함을 가진 사람이나 조직들의 등장이 점차 붐을 일으키고 있다. 이들이 기존의 DBA와 근본적으로 다른 것은 역할을 ‘데이터베이스’에 국한하지 않고 보다 큰 영역인 ‘데이터’에 까지 확장하였다는 것을 들 수 있겠다.

특히 시대의 흐름에 선도적인 대기업에서는 정보기술 아키텍처의 도입에 대한 압력의 영향에 편승하여 자의 반 타의 반으로 이러한 조직들이 생겨나고 있다. 그러나 문제는 그리 간단해 보이지 않는다. 팀장이 존재하지만 분명히 그는 데이터 전문가라고 할 수 있는 수준이 아니다. 그 아래 과장급들이 여럿 있지만 그들 또한 전문가라고 하기에는 많이 부족해 보이는 것이 현실이다. 그러나 첫 술밥에 배가 부르랴! 처음으로 진정한 니즈(needs)를 가진 조직이 탄생되었다면 미래는 희망적이다. ‘필요가 발명을 낳는다’는 말처럼 필요성이 증대되면 이에 대한 해결책은 반드시 나타나게 되어 있기 때문이다.

이제 명백해졌다. 여러분이 보다 발전된 모습의 정보시스템을 꾸려 나가기를 원한다면 지금 당장 자급자족에서 벗어나야 한다. 물론 쉽지는 않겠지만 그래도 가장 빨리 전문화된 형태로 가기 위해서는 그 역할을 담당할 조직부터 만들어야 할 것이다. 설사 지금 보유하고 있는 내공이 턱없이 부족하더라도 그들은 필시 어떤 방법을 동원해서라도 반드시 자구책을 찾게 될 것이며, 분명 머지 않아 확실히 변모된 모습으로 기존의 패러다임을 바꾸는 중추적인 역할을 하게 될 것이 틀림없다.