프로그래밍과 설계는 보는 관점에 차이가 있다.

프로세스는 그것을 구성하는 단위기능들의 조합이라 할 수 있는데 이런 로직구현을 보통 "프로그래밍 한다"라고 말한다.

로직구현

이 로직구현이라는게 설계와 다른 특징이 있다.

단위 기능들에 대한 요구사항(needs)이 주어지면 개발자는 이해하고 있는 정보의 범위 내에서 논리적 최단거리(최적화된 로직)를 구현한다.

개발자는 이렇게 각 단위기능의 요구사항마다 논리적 최단거리를 구현하기만 하면된다.

하지만 이렇게 구현된 모든 단위기능의 최단거리의 합이 전체 프로세스 관점에서 시작과 종료간의 최단거리로(최적화)구현 되었다고 단정할 수 없다.

그리고 설사 전체 프로세스의 관점에서 최단거리가 되지않았다 하더라도 해당 시스템을 사용하는데 문제가 되지 않는 특징이 있다.

설계

하지만 설계는 프로세스의 전체시각이 아닌 단위기능, 즉 Partial 정보로 할 수 없다.

최대공약수를 생각해보면 이해하기 쉽다.

최대공수약수는 주어진 수에서 1과 자기자신이 아닌 나눌 수 있는 수 중에서 가장 큰 약수를 의미하는데,

여기서

'주어진 수'는 단위기능을 구현하기 위한 요구사항(needs)이라 보면되고, 

'약수'는 각각의 단위기능을 구현하기 위해 로직 가공에 사용되는 논리적 단위로서 재사용성과 최소구현비용, 최소관리비용을 목적으로 도출되는

프로그래밍에서는 공통모듈 혹은 공통로직이라 할 수 있고,

데이터 관점에서는 정규화된 최소단위 데이터 덩어리라고 말할 수 있겠다.

예를 들어

단위기능을 구현하기위한 요구사항 18, 24, 36이 주어졌다 생각해보자.

위에서 주어진 모든 수를 나눌수 있는 최대약수는 6이다.

6이라는 논리적 단위가 도출만 된다면 18은 3배수, 24는 4배수, 36은 6배수로 만들수 있다.

이는 다르게 말하면 프로그램 관점에서는 로직상의 대칭성 찾은것이고, 재사용 가능한 모듈단위를 찾은 것이다. 

데이터 관점에서는 각각에 모듈 모두를 만족할 수 있는 최소 데이터 단위를 찾은 것이다.

이렇게 제대로 된 설계를 할려면 Partial 정보로 할 수 없고, 모든 경우의 수(모든 needs)를 도출한 후 분석해야만 가능하다.

모든 요구사항을 도출하지 않고 설계시 발생하는 문제

나중에 새로운 요구사항, 즉 새로운 수 42가 주어졌다고 생각해보자.

이렇게 되면 18, 24, 36, 42을 만족 시킬수 있는 약수는 3이 되어야 한다.

프로그래밍 관점에서는 모든 수를 만족하는 로직상의 대칭적위치가 바뀌기 때문에  

공통로직이 개입되어야 하는 방식이나 프로세스 상의 구현위치 조정이 발생할 수 밖에 없고,

데이터 관점에서는 취급되는 최소 정보단위가 바뀌어야 하니 정규화가 다시 되어야 한다.

게다가 기 구현된 로직을 다시 검증해야 하는 비용이 발생하는 것은 말할 것도 없다. 

전산문맥에 대한 이해가 부족한 이들은 이런 문제를 간과하고 있으며 설명을 해도 이해하지 못한다.

그리고 이런 새로운 요청사항을 주문할때 요청자가 자주하는 말이 있다.

"이게 되야 되는데.. 이게 안되면 다른게 의미가 없는데요?"

이런요청을 받을 때 마다 드는 생각은

이게 안되어서 다른게 의미 없을 정도로 중요한 needs였다면 가장 우선순위가 높은 요청사항으로 도출되었어야 했다는 것이다.

극단적 정규화의 문제

여기서 한가지 짚고 넘어가야 할것이 있는데, 1과 자기자신의 수를 사용할 수 없는 이유다.

1은 모든 요구사항을 재조립해 낼 수 있는 이상적 약수이긴 하나, 정보의 재조립 비용이 너무 크고,

정규화를 안하면

자기 자신의 수는 각자의 모듈에는 이상적일 수 있으나, 다른 모듈이나 단위기능간에 재사용성이 없고, 

데이터 관점에서는 정규화가 되지 않다보니 정보의 연결성을 가질수 없어 각 모듈(단위기능=주제영역)간 처리된 정보를

다양한 차원(dimension)에서 뷰를 제공 할 수 없는 치명적 문제가 있다.

설사 데이터를 가공을 한다하더라도 수치가 딱 맞아 떨어지지 않는다. 계속적인 보정작업을 유발하지만,

본질적으로 모든 needs를 재 조립할 수 있는 최소단위가 아니다보니 근사치로만 수렴되기만 할 뿐 정확히 맞아 떨어지는 데이터로 뷰를 제공할 수 없다.

이것이 설계를 할때는 모든 요청사항(혹은 모든 needs)을 도출한 후에 해야 하는 이유다.

Partial 정보만으로도 로직 구성이 가능한 프로그래밍과는 고려해야할 범위가 다르다.

제대로된 설계는 TCO의 최소증가의 핵심이다.

TCO증가를 최소화하기 위해서는 본질을 정확히 이해해야 한다.

현실에서 반바뀌 꼬아서 설계한것이 제대로 돌아가는 이유는 프로그램도 반바퀴 꼬아놨기에 가능했던 것이다.

이화식씨가  "대용량 데이터베이스 솔류션" 시리즈에 언급한 말이다. 

제대로 설계를 하지 못하여 반바퀴 꼬아놓고, 반바퀴 꼬인 설계로 제대로 돌아가는 프로그램을 만들려니 로직도 반바퀴 꼬이니,  TCO가 증가량이 크질 수 밖에 없다.

한번 잘못된 설계는 두고두고 부담이다.

고객의 요청은 항상 변화하기 때문에 TCO는 항상 +로 증가하는 것은 정상이지만 그 증가량은 최소화 되어야 한다. 

소프트웨어 리팩토링을 하지 않는이상 TCO증가를 -로 할 수는 없다.

사실 따지고 보면 소프트웨어 리팩토링 자체가 이미 발생한 TCO이기에 잘못된 설계는 개발당시 구축비용을 줄였는지 모르나 그 만큼 미래의 관리비용으로 전가시킨것이라고 봐야 한다.  

결국

최초 시스템 구축시에 얼마나 정밀하게 설계를 했느냐가 미래의 TCO증가 크기를 결정한다고 보면된다.

이렇게 보면 TCO는 증가만 있는 Entropy와 성격이 같다.