Life is Simple, Thinking is High

추상화는 사람이 세상을 인지하는 기본적인 기술이고 모든 소프트웨어 개발의 필수적인 첫 단계이다.
사실 대부분의 사람에게 객체지향의 추상화보다는 추상회화가 더 익숙하다. 미술의 추상화는 대상을 극도로 간략화하고 순수감성을 절대시하는 회화 양식으로 자연형태 그대로를 묘사대상으로 하지 않고 기하학적인 색채평면 형태만을 묘사한다. 그러나 전산에서의 추상화는 조금 의미가 다르다.


추상화는 4가지 특징이 있는데

첫째 추상화를 통한 간략화

이러한 간략화의 대표적인 예가 지도이다. 지도는 주요 도로, 많이 알려진 건물, 강, 지하철 역 등 실제의 세계를 고도로 추상화하여 우리가 길을 쉽게 찾을 수 있도록 도와준다. 만약 지도에 모든 건물과 나무, 도로 블럭 하나 하나까지 모두 표시한다면 오히려 정보를 얻고 원하는 지역을 찾는 데 방해가 되기만 할 뿐이다.


둘째 추상화를 통한 강조(관점)

그러나 단순히 간략화가 추상화는 아니다. 앞의 지리적 지도는 사람이 위치를 쉽게 찾을 수 있게 되어 있는 추상화의 하나의 예이며 기상 지도, 인구 밀도 지도 등 실세계의 다른 특징들을 실제 사용자가 어떻게 사용하길 원하느냐의 의도와 문제를 보는 관점에 맞게 추상화시킬 수 있다. 강조란 관점을 가진다는 전제조건이 있다. 그리고 추상화 혹은 추상화시킨다는 것은 어느 특정 관점에서의~ 라는 말이 생략되어 있다고 생각해도 좋다. 이런 강조를 통해 복잡한 자료, 모듈, 시스템 등으로부터 핵심적인 부분을 간추려 볼 수 있게 된다.



셋째 추상화를 통한 일반화

수학은 순수한 일반화를 지향하는 학문이다. 그리고 우리가 하는 소프트웨어는 공학이긴 하지만 수학과 닮았다. 높은 산위에서 쳐다보면 개인 개인을 그 사람의 눈이 큰지 코가 오똑한지 등의 차이점이 아닌 사람이 가지는 기본적인 공통점을 통해 인식할 수 있게 된다. 추상화와 일반화는 다르지만 이렇게 추상화는 일반화를 사용한다.



네째 조직과 분리를 통한 추상 계층화

Brian Buchanan은『Theory of library classification = 문헌분류이론』(정필모, 오동근 공역(1998))의 한국어판 서문에서“아마도 패턴과 순서에 대한 관심은 우리 인간들이 타고 나는 모양이다. 이러한 의미에서 인간을 분류하는 동물(classifying animal)이라고 정의할 수 있을 것이다. 이것은 카오스(혼돈)에 대한 두려움을 바탕으로 하고 있고, 또한 통제할 수 없는 환경을 통제함으로서 불안정한 세계에서 안전하다는 망상을 갖고자 하는 욕망에서 생겨나는 듯하다.” 라고 말한바 있다.

우리는 이러한 추상화를 통해 공통점과 차이점을 찾아내고 차이점을 다시 더 큰 공통점으로 묶는 과정을 통해 사물을 트리 형태로 계층화 시킨다.

이전 글에서 객체지향 프로그래밍 십계에 대해 언급한 적이 있는데
(물론 모세처럼 신약을 받은건 아니고-ㅅ- 그렇다고 새로운 이론을 창조하는 것도 아니다. 굳이 말하자면 요구사항을 캐내듯이 - 수집이 아니라 - 별다섯개짜리 책들에서 캐낸 것이다.)

1계는 당연히 재사용 성배를 뜻한 DRY(Dont Repeat, yourself)이다.
3계는 앞서 말한대로 더 이상 분해가 불가능한 원자단위까지 쪼개서 하나의 Aspect관점으로 묶어라 이다.

마음대로 정한 2계는 SOC 즉 변화의 속도이다. (SOC는 Service-Orinted Programming같은게 아니라 Speed Of Change로 맘대로 지어낸 용어다 -ㅅ-) 객제 지향은 "Object는 관련 있는 변수와 메소드의 모음" 이라는 정의로 출발하는 관계 있는것끼리 묶자라는 시도이다.

좋아~ 그럼 관련 있는 것이란 무엇인가 ?

관계(혹은 관련)에 대한 화두는 이화식씨에게 RDBMS를 배우던 시절로 올라간다. 관계형 DB 모델링 과정에서 엔티티란 '... 어쩌고 저쩌고....  관계 있는 개체의 집합' 라고 정의했을때

"관계란 무엇인가? 저기 창문밑의 길가는 사람은 나와 관계 있는 건가? 아닌가?" 라는 질문을 던졌을때 당시의 나는 매우 당황스러웠지만 그 후 몇 년이 지난후에야 나름대로의 답을 찾게되었다.  RDBMS에서 모든 개체는 관련을 가지고 있다. 따라서 창문밑의 길가는 사람과 나는 관계가 있는 것이다. 다만 RDBMS에서는 직접적 관계와 간접적 관계를 구분한다. 그래서 모델링시 사원과 부서가 일차적 직접 관계를 가지느냐 이차적 이상의 간접적 관계를 가지느냐에 대한 판단을 하게 된다.

이러한 RDBMS에서의 관계의 의미와는 달리 객체지향에서 관계의 의미는 조금 다르다. 설계시 A라는 클래스와 B라는 클래스는 관계가 있느냐? 혹은 a라는 메소드와 b라는 메소드는 관계가 있느냐를 판단할때의 기준은 공간적 시간적 변화의 속도이다. 즉 어떤 클래스를 수정할때 다른 클래스도 마찬가지로 수정해야 된다면 이 두개의 클래스는 관련이 있으므로 묶어두어야 한다. - 클래스 통합이 될수도 있고 같은 패키지에 둘수도 있고 inner 클래스를 사용할수도 있겠다. - 이러한 공간적 관련성 말고도 시간적으로 어떤 부분의 변동과 다른 부분의 변동이 같이 일어난다면 이도 시간적 관계가 있다고 할 수 있다.

쉽게 말하면 객체지향의 디자인은 관련있는 것들은 그 관련정도에 따라 거리를 조절하는 것을 뜻한다. SOC가 아주 비슷하다면 그 거리도 가까워야 하고 SOC가 서로 관련이 없다면 가능한 서로 의존하지 말아야 한다. 달리 말하면 소프트웨어 공학에서 말하는 커플링(Loose cupling)과 코헨션(Tight cohesion)에 대한 얘기이다. 언뜻보면 모순으로 보이는 이 두 개념은 SOC에 따라 커플링이나 코현션이냐를 판단하게 되는 것이다.



객체지향 프로그래밍 제 2계
관련있는 것은 가능한 묶고 관련없는 것들은 가능한 떨어뜨려 놓는데 여기서의 관련이란 이 두개의 시간적 공간적 변화의 속도이다.

아래 글은 그러니까 한국이 월드컵 4강을 하던해인 -ㅅ- 2002년에 쓴 글이다.
인터넷에 글을 많이 올린건 아니지만 그렇다고 적게 올린것도 아닌데 - 세월이 세월이니만큼-ㅅ-
쓴 글중에 예외적으로 가끔씩 유령버전으로 떠돌아 다닌다.

글을 올렸을 당시에 말한대로 실제 아래의 금붕어 쿼리는 제목은 잊어버렸지만 모 프로그래밍 책에 실제 쓰여있었던 예제이다. 게다가 몇년전까지 꽤 이름이 알려져 있던 - 최근에는 모르겠다. 그쪽 업계에 무관심해져서 -ㅅ- 저자의 책이었다. 최근에 책을 쓴다는 것이 얼마나 어려운 일인가를 절감하고 있는 요즘 그의 노고를 바보같은 예제들이라고 무작정 깍아내릴수는 없는 일이다.

DB의 SQL의 형식을 빌렸지만 사실 아래의 문제는 데이타베이스라기보단 객체 지향의 문제에 더 가깝다. 초등학생 시절에 배듯한 순서도에 입각한 구조적 프로그래밍이 패러다임이 사라지지지 않는것이다. 물론 패러다임 자체의 문제라기 보다는 딱딱한 사고를 벗어나지 못하는 응용의 문제이긴 하지만 말이다.

아래의 문제가 여러사람에게 설득력이 있었던 이유는 지금 생각해 보면 그 배경지식이 매우 간단하기 때문이다. 그래서 답처럼 그 이유도 매우 명약관화 하다.

하지만 실제의 대부분의 문제는 이처럼 간단하지 않다. 답도 매우 복잡하고 그 과정 혹은 배경지식도 아주 복잡하거나 많은 배경지식을 필요로 한다. 그래서 A보다 B를 써야 하는 이유를 말하기 위해서는 먼저 B'에 대해 알아야 하는데 B'는 다시 B''에 대한 지식을 필요로 하고 여기서 B''는 다시 B'''의...... 무한 반복이 되어 버리는 것이다.

웃기는 얘기일지 모르지만 일반적인 상식과 달리 - common is not common 상식은 보편이 아니다 라는 말이 있는 것처럼 - 지식은 본래가 체계적이지 못하다. 연산자에 대한 정의를 필요로 하는 수학의 일부분을 제외하면 피라미드형의 단계적 지식보다는 여러 배경지식에 기초한 직관적 관점이 필요할 경우가 좀 더 많다. 때문에 글로서 지식을 말한다는 것은 항상 어렵다.




---------------
Since 2002.10월

일거리가 하나 떨어졌다. 

매일매일의 접속자 수를 알기위해 매일 첫번째의 사용자는
insert into 카운터테이블(일자 , 명수) values(@오늘일자,  1)
그리고 2명째부터는
update 카운터테이블 set 명수 = 명수 + 1 where 일자 = @오늘일자

를 하여 일자별 접속자수를 테이블에 저장하여야 한다..



금붕어는 다음과 같이 한다. 

select count(*) as @cnt from 카원터테이블 where 일자 = @오늘일자

if (@cnt > 0)
   update 카운터테이블 set 명수 = 명수 + 1 where 일자 = @오늘일자
else
   insert into 카운터테이블(일자 , 명수) values(@오늘일자,  1)





고양이는 생각이 좀 다르다..

오늘의 건수가 있느냐 없느냐가 중요하지 몇건인지는 중요하지 않기 때문에
금붕어처럼 모두 억세스할 필요없이 한건만 억세스 하면 될것 같다. (top 1)
그리고 쓸데없이 @cnt 변수를 쓴것 같다..

고양이는 다음과 같이 한다. 

if ( Exists(select top 1 "있음"  from 카원터테이블 where 일자 = @오늘일자) )
   update 카운터테이블 set 명수 = 명수 + 1 where 일자 = @오늘일자
else
   insert into 카운터테이블(일자 , 명수) values(@오늘일자,  1)



사람도 역시 생각이 다르다. 

생각해 보면 하루에 한번만 Insert 문이 실행되고 나머지는 모두 Update 문이다. 
그 한번을 위해서 매번 Select를 하는것도 낭비인것 같다. 

사람은 다음과 같이 한다. 

update 카운터테이블 set 명수 = 명수+ 1 where 일자 = @오늘일자

if (@@ROWCOUNT == 0)
　 insert into 카운터테이블 (일자,명수) values(@오늘일자, 1)

즉 매번 Select를 할 필요없이 일단 Update를 하고 
Update가 한건도 안되었을때만(즉 오늘일자에 대한 행이 없을때) Insert를 하였다. 

용산 등의 일련의 사태를 보면서 MB정부의 수습 방안을 요약하자면 형식적 법치주의 혹은 민주주의라고 말할수 있다. 법은 더 중요한 무언가를 지키기 위한 파생적 결과물이다. 법 자체가 존엄한건 아니기 때문에 마틴 루터 킹 목사가 '히틀러의 만행이 당시 합법이었다는 것을 잊지 말아야 합니다' 라고 말한 것은 이 형식적 법치의 문제점을 단적으로 지적한 것이다.

사실 세세한 법 그 자체만을 추구한다면 의회를 장악한 다수의 횡포나 대중을 선동하여 등장한 독재자의 전제를 전혀 견제할 수 없고 오히려 형식적 통치원리로서의 법치주의가 권력자의 통치권을 강화하는데 일조하는 역기능이 생긴다. 법은 해석하기에 따라 유리한대로 얼마든지 적용이 가능할 뿐더러 털어서 먼지 안나는 사람 없다는 말처럼 '내가하면 로맨스 남이하면 불륜'식의 선별적인 법적용이 얼마든지 가능하기 때문이다.

게다가 이러한 체제는 속성상 자가 증식을 한다. 법률의 예를 계속 들자면 사법고시를 준비하는 사람 말고는(심지어는 그런 사람들조차도) 대한민국 법률을 전부 아는 사람은 없을정도로 복잡하고 방대해진다. 이럴수록 체제의 기본적인 존립의미 - 개개인의 욕구를 조율해서 다수의 행복을 창출한다 - 는 퇴색되고, 체제를 기키기 위해 체제 자체가 존재하는 상황이 발생한다.
또한 체제에 대한 맹목적인 신념으로 인해 '체제'만' 준수한다면, 모든 것이 정당화된다'는 스스로에 대한 일종의 면제권을 부여하는 역효과도 생기게 된다.

그래서 그렇게 복잡하고 정교한 법체계가 엄연히 존재하지만,  정작 그 체제가 존중해야할 사람은 배제되고 체제만 남게 된다.

형식적 법치주의 만큼이나 IT업계에도 이런 일은 비일비재하다. 7-8년전쯤엔가 CMMI 라는 소프트웨어 성숙도라는 말이 유행한적이 있었다. (물론 그전에도 그 후에도 용어만 바뀌었을뿐 유행은 존재한다.) 그 의도는 순수했지만 그 결과는 결코 좋지 못했다. 요컨데 CMMI의 조직 성숙도는 성숙도가 높은 조직은 대부분 이러이러한 특징이 있으므로 이런것들을 보고 조직의 성숙도를 측정할수 있다는 얘기이다. 여기서의 특징은 측정되거나 산술될 수 있어야 한다. 

그러나 우리는 오랫동안 프로세스가 중요하다고 들어왔기 때문에, 프로세스는 중립적이라는 사실을 종종 잊는다. 좋은 프로세스 도구를 가진 바보도 역시 바보일 뿐이다. CMMI의 최고 성숙도를 가진 NASA가 프로젝트에 프로세스당 수만장의 문서를 만든다고 해서 어떤조직에서 수만장의 문서를 만든다고 NASA와 비견한 조직성숙도를 가졌서 좋은 품질의 소프트웨어를 만든다고 볼수 없다. 왜냐하면 여기서 수만장의 문서는 보다 더 추상적인 목적- 프로젝트의 성공 etc- 을 위해 어쩔수 없이 생겨난 과정으로서의 부산물일뿐 그것이 목적은 아니기 때문이다. 그러한 문저와 프로세스는 필요조건이었을뿐 충분조건은 아니다.
CMMI의 조직성숙도를 추구하는 조직은 높은 레벨의 성숙도를 가지기 위해서 NASA처럼 많은 문서작성을 하면 CMMI의 인증은 받을 수 있겠지만 실질적으로 그 만큼의 성숙도를 가졌는가는 다른 얘기이다.



흔한 얘기에 쓸데 없이 이야기가 길어졌는데 표층에 보이는 과정은 부산물 좀더 심하게 말하자면 이를테면 정제하고 남은 불순물 같은 존재이다. 그렇다고 추상적인 궁극의 무언가를 위해 아무것도 할 필요가 없다는 얘기는 아니다. 현실에서 법개정을 위해 싸우는 것처럼 목적은 과정을 통해 달성될 수 밖에 없다. 다만 그 과정을 하는 중에는 끊임없이 스스로에게 확인해야 한다. 내가 원래 달성하고자 했던 목적이 무었이었던가를..

좋은 프로그래밍의 기준은 많이 있지만 일반적으로 좋은 품질의 기준은
이식성(portability), 신뢰성(reliability), 효율(efficiency), 사용 편의성(usability), 테스트 용이성(testability), 이해 용이성(understandability), 수정 용이성(modifiability) 의 7개 정도의 속성으로 정의할 수 있다.

소프트웨어의 분야의 다양함 만큼이나 다양한 사람들이 조금씩 다른 기준을 제시하고 있기는 하지만 큰틀은 그리 변하지 않는 일반적 기준이라 할 수 있겠다.

위의 속성이 좋은 프로그래밍의 기준이라면..

개인적으로는 위대한 프로그래밍의 기준으로 전혀 다른 쌩뚱한 기준을 가지고 있다.

첫번째 기준은 진화이다.
보통의 프로그램은 분석-설계-코딩-테스트-유지보수의 단계를 가지고 있다. 이게 1싸이클이든 여러개의 싸이클이든 말이다. 이 중 맨 마지막 단계인 유지보수는 소프트웨어에서 가장 많은 비용을 발생시키는데 이는 대부분 피드백 전달체계에 있다. 패키지화된 소프트웨어를 일단 전달하면 땡인 수십년전의 소프트웨어와 달리 오늘날의 소프트웨어의 대부분은 항상 피드백을 받는다. (엄밀하게 말하자면 피드백의 기간이 줄었다고 볼 수 있다. 예전처럼 메이저 버전이 올라가는 업그레이드 보다 마이너 업그레이드의 비율이 늘어났고 생각할 수 있기 때문이다.) 고객이 소비자가 사용하는 패턴을 관찰한후 개발사에게 다시 추가 기능요구나 버그 수정을 요청하는 이러한 피드백 형태는 크게 2가지의 문제가 있다. 하나는 피드백과 반응의 시간이 매우 길다는 거고 두번째로 소비자 -> 고객 -> 개발사 -> 고객 으로 이동하면서 실제로 필요한것과 요구한 것과의 변질이 발생한다는 것이다.

그래서 훌륭한 소프트웨어는 진화라는 특성을 가져야 한다고 생각한다. 일종의 자동반응 체계라고 얘기할 수 있는데 소비자의 행동 피드백 그 자체에 반응하는 코드가 내재되어 있는 코드를 말한다. 소비자의 행동 피드백은 다양한 것으로부터 수집될 수 있다. 단순히 클릭와 접속시간뿐 아니라 스팸 신고 버튼과 같이 적극적인 피드백을 얻는 장치도 있다. 다만 현재의 대부분의 소프트웨어는 피드백을 수집하기만 할뿐 실제 해석은 거의 이루어지지 않거나 사람에 의해서 뒤늦게 인지된다. 기본적으로 학습하는 소프트웨어라고 할까.. 굳이 거창하게 AI까지 갈 필요는 없다. 이 분야의 가장 좋은 예는 아마 DB의 옵티마이저가 아닐까 싶다.

아래 예제로 든 스팸 처리 코드도 체인필터나 전략패턴같은 테크닉이 중요한게 아니라 얼마만큼 피드백에 자동화한 반응이 가능한가에 그 중요도가 달린다.



두번째 기준은 첫번째 진화 특성때문에 나온 유기적 독립성을 갖춘 소프트웨어이다. 앞서 옵티마이저가 현재 우리가 사용하는 소프트웨어중 가장 진화에 가까운 소프트웨어이긴 하지만 이는 제한적인 의미의 진화이다. 무슨말이냐면 옵티마이저의 피드백 반응은 옵티마이저 설계자의 손바닥 안에서의 반응에 불과하다. DB에 대한 최고 전문가가 설계한 그 공간안에서의 자유다. 이는 결국 뛰어봐야 부처님 손바닥같은 얘기다.

한때 유행어였던 집단지성(Collective Intelligence)과는 비슷하지만 조금 다르다. 피드백의 교환으로 인한 진화보다 돌연변이의 출현은 훨씬 극적이다. 종의 돌연변이가 아니라 개체의 돌연변이이므로 소프트웨어는 종으로서가 아니라 유기적인 개체단위의 합으로 존재해야 한다. 글로 의미를 전달하긴 좀 어렵지만 예컨데 분산화된 위키같은 구조이다. 각 사이트는 커다란 종으로서의 부분으로 존재함과 동시에 그 자체가 독립적인 서비스이기도 하다.


물론 개인적으로 아직 위대한 소프트웨어를 본적은 없다. 만들려고 한적은 있지만. -ㅅ-

앞서 말했듯이 라이브러리를 통한 소규모 재사용은 아주 성공적이었다.

만약 여러 프로젝트와 다양한 도메인 사이에 비슷한 문제가 충분히 많이 존재한다면 좀 더 큰 규모에서도 성공적일거라 낙관하였다. 그러나 많은 사람들이 의심- 앞서 말했듯이 규모의 증가는 전혀 다른 문제를 야기시킨다 - 하는 바와 같이, 소프트웨어의 다양성으로 인해 프로젝트와 도메인에 상관없이 공통되는 기능과 작업으로 일반화할수 있는 부분이 많지 않다면 소규모의 재사용과 대규모의 재사용은 다른 문제가 된다.

대규모 재사용을 지지하는 사람들은 대규모 재사용이 널리 퍼지지 못한 이유를 사람들의 무지, 혹은 다른사람의 작업을 인정하지 않는 NIH 신드롬 때문이라고 생각하곤 한다. 따라서 이들에게 대규모 재사용은 기술의 문제가 아니라 의지와 정책의 문제이며 경영진의 관리를 통해 이런 문제를 타개해야 한다고 생각한다. 

아무튼 사람들은 좀 더 큰 규모의 대규모 재사용을 시도하였다. 이러한 방식을 관계있는 여러 라이브러를 묶어서 컴포넌트화 하여 이들간의 조립으로 소프트웨어를 구축 할 수 있다는 개념을 컴포넌트 지향 프로그래밍(CBD)라고 한다. 그러나 이는 본래 의미부터 약점을 가지고 있다. 관계있는 여러 라이브러를 묶을때.. "관계 있는" 이라는 말은 어디까지나 주관적인 판단이며 그러한 판단은 아주 주관적인 상황에서 내려지게 된다. 즉 현재 자신의 도메인과 프로젝트를 초월한 "관계 있는" 이라는 것은 불가능 까지는 모르겠지만 아주아주 어렵다는 것을 뜻한다.

사실 대규모 재사용 낙관론파는 인정하지 않지만 모든 프로젝트와 도메인 혹은 대부분의 프로젝트와 도메인에 공통적인 무언가를 찾는 것은 아주 어렵고 그 비율도 생각보다 높지 않다. 이는 논리적으로는 불가능하지는 않지만 실제 프로그래밍을 하고 있는 사람은 대부분 인정하는 현실상의 문제이다.



어쟀든 소스의 재사용을 위해 초기 라이브러리가 탄생했고 그를 좀더 대규모로 확장하기 위해 CBD가 나타난 시기와 비슷한 시기에 재사용의 성배를 찾던 탐구자들은 새로운 의미의 재사용의 해석을 도입하게 된다. 대규모 재사용에서 도메인의 영향을 피할수 없다면 도메인에는 단순히 소스의 공통점뿐 아니라 다른 부분의 공통점도 찾을 수 있다. 즉 구조의 재사용의 문제이다. 예컨데 Web이라는 도메인에서 클라이언트가 request를 던지고 response를 받는 과정에 있어서 Web이라는 기술 도메인 하에서 많은 구조적 동일성을 발견할수 있다.

프레임워크가 프로그래머들에게 가장 일상적으로 들리기 시작한것은 이러한 웹 프레임워크를 통해서였다. 프레임워크는 CBD나 이전의 라이브러리와는 다르게 소스 자체의 재사용보다는 구조적 재사용을 추구하였고 이는 CBD보다는 훨씬 더 큰 반향을 불러 일으켰다. 개발자 구인 조건이 특정 프레임워크를 사용 가능하냐는 여부였으니 더 말해 무엇하랴. 그리고 이런 프레임워크에 대한 지나친 기대와 포장은 자신이 무엇을 개발하는지도 모른채 xml 파일의 바다에 헤매이게 만드는 단점을 나았다.



라이브러리 단위의 재사용이 규모가 커지면서 CBD와 Framework로 다른 길을 선택하였지만 성배 추구자들은 끊임없이 의미를 탐구하였고 좀더 다른 의미의 재사용을 꿈꾸었다. 이 결과로 나온게 서비스 레벨의 재사용 즉 SOA 이다. 소스레벨도 아니고 구조적 레벨도 아닌 더 큰단위인 서비스 레벨에서 재사용을 추구하는 SOA는 그자 체가 재사용의 성배 추구 과정에서 필연적인 결과이다.

그러나 SOA의 미래가 어두운 점은 서비스가 너무 많다는데 있다. MFC의 함수보다 많은 서비스 중에서 내가 원하는 서비스들을 골라내기란 - 게다가 MFC와는 달리 그 모든 서비스의 상당부분은 매우 저품질이다. - 수만 픽셀에서 필요한 1000픽셀만 찾아 조각맞추기 하는것만큼이나 어렵다.(매쉬업은 아직 유틸리티 성격이 강하니 제외하자) 결국 이전의 CBD처럼 관련있는 것들을 묶어주는 무언가가 필요하겠지만 이는 개별 서비스 주체들의 동의를 이끌어내야하는 비기술적인 문제에 봉착하게 된다.

"성배"는 단순히 종교의 문제를 벗어나 인디아나 존스나 트레져 헌터, 최근의 다빈치 코드에 이르기까지 영화나 소설에까지 흔히 소재로 체택되곤 한다. 성배는 예수가 최후의 만찬에 사용했다는 은으로 만든 잔을 뜻한다. 영화“다빈치 코드”의 저자는 성배는 인디아나 존스에서 나온것처럼 하나의 보물로서의 찻잔이 아니라 성배가 예수와 막달레나 사이에서 태어난 혈통을 가리킨다고 주장한다.

머 영화이야기를 하려는건 아니지만 IT업계에도 성배를 찾아헤매는 트레져 헌터처럼 끝없이 갈구하는 소재가 있다. 바로 "재사용"이다. 20년전의 객체지향 10년전의 패턴이나 CBD 그리고 그나마 최근인 프레임워크나 SOA에 이르기까지 주제에 상관없이 항상 그 논란의 핵심에는 "재사용"이라는 성배가 있었다.

사실 재사용이라는 개념은 소프트웨어라는 개념이 존재할때부터 파생된 오래된 말이다. 1950년 IBM 메인프레임 시대에 - 소프트웨어는 하드웨어에 딸려나오는 엑세서리 쯤으로 생각되던 그 시기에 이미 Share라는 공유 라이브러리를 제작하던 사용자 조직이 있었다.

갑자기 이 얘기를 왜 하냐면 오늘날의 재사용의 의미가 사실 매우 오래된 아이디어이며 현재의 재사용의 성공과 실패를 인식하는데 있어 아주 중요하기 때문이다.

앞서 말했듯 처음 재사용이라는 단어가 사용된건 1950년이며 이미 Ada라는 언어부터 구조적 프로그래밍이라는 패러다임이 이미 존재했다. 당시의 주류 언어이던 어셈블리어가 코드의 라인수가 점차 커짐에 따라 동일하거나 비슷한 코드를 함수와 라이브러리 단위로 묶어서 재사용의 시초라면 이후 SOA까지 재사용은 항상 그 중심에 있었다.

초기에 라이브러리 함수까지는 재사용에 있어서 그 찬란한 미래를 보장해 주는듯 했다. "바퀴를 재 발명할 필요는 없다"라는 구호를 가지고 객체지향이 나올때까지도 그 미래는 현실이 되는듯 했다. 하지만 CBD에서부터 먼가 삐걱거리는 조짐이 일어났다. 전병선씨가 그의 책에 상.상.한 CBD 미래는 10년전이나 지금이나 요원해 보인다.

작은 규모의 재사용이 아주 효과적이었다고 해서 대규모의 재사용도 충분히 효율적이라고 생각하는 것은 억지가 되버렸다. 규모의 문제는 무시해도 좋을만큼 단순한 문제가 아니었던 것이다. 어릴적에 난 과학 기술의 발전으로 40m의 크기가 된 울트라맨이나 마징기 제트 - 비록 그게 일본문화이더라도 - 만화를 보고 자랐다. 지금 보면 그 만화들은 만화라는 상상력을 벗기면 형편없는 오류를 저지르고 있다. 짧게 말하면 발의 평면은 2차원인데 부피가 3차원으로 자라면 ^2과 ^3의 차이만큼 발에는 추가적인 압력이 가해지고 어느 순간에는 그 차이가 견딜수 있는 수치를 넘어가게 된다. 예컨데 산양과 코끼리의 다리는 그 크기의 차이만큼이 아니라 그 부피만큼의 비율 이상이 유지되야 지상을 걸어다닐 수 있게된다. (발의 평면 크기가 ^2이 아니라 ^3으로 증가해야 되고 따라서 발의 부피는 ^3이 아니라 ^4가 되어야 한다.) 단순히 발의 크기뿐 아니라 들숨과 날숨의 문제로 인한 허파의 크기 등 수많은 문제가 있다.


이야기가 많이 빠졌지만 소규모 재사용과 대규모의 재사용은 전혀 비슷한 난이도가 아니었고 따라서 그 효율성도 달성하기 어렵다. 얼마나 어려운가 하면 O의 n승 만큼 어려워진다. 이는 단순히 가능 불가능의 문제가 아니라 효율성의 문제이기 때문이다. 일반적으로 공통 코드는 보통의 코드에 비해 3배의 노력이 든다는 것이 정설이다. 라이브러리 단위의 작은 코드일때는 이 정도도 효율적이라고 할 수 있지만 2배 정도의 긴 코드를 작성해야 할때 공통 코드는 단순히 6배가 아니라 9배 이상이라고 했을때는 문제는 전혀 달라지는 것이다.

전병선씨나 대규모 재사용의 지지자들은 이미 만들어 놓은 컴포넌트들을 조립하여 마치 레고블럭을 쌓는 방식이 프로그래밍의 미래라고 생각하지만 사실 그건 이룰수 없는 꿈과 같다고 생각한다.. 컴포넌트 지향의 성과가 없는 것은 아니지만 그보다 훨씬 더 빠르게 코드의 크기와 시간이 갈수록 다양해지는 소프트웨어의 요구사항들을 생각해 볼때 이는 자동차와 로켓의 속도 차이만큼 그 거리는 점점 멀어지고 있기 때문이다.

멘델의 유전법칙 제 1원칙은
우열의 법칙으로 잘 알려진 순종의 대립 형질을 교배했을 때, 잡종 제1대에서 어버이의 두 대립 열질 중 우성 형질만 나타나는 것을 말한다.

우성을 A라고 하고 열성을 a라고 했을때
AA와 aa의 의 자손은 AA, Aa, aA, aa이며 A가 우성이므로 자손의 우성형질이 나타나는 비율은 3:1이다.
중학교 수준의 과학이므로 이를 모르는 사람은 별로 없다.

다만 대부분의 사람이 모르고 있는 것은
그렇다면 시간이 가서 세대를 거듭할수록 우성의 확률이 높아지느냐? 에 대한 질문이다.

과연 세대를 거듭할수록 우성의 확률이 높아지면서 열성은 수가 점점 줄어 미미해질까 ?
... 라고 중학교 선생한테 배웠던 기억이 있다.
그렇다면 지금 열성인 것은 인간의 오랜 역사에도 불구하고 왜 아직 그 성질이 남아있는가?에 대한 의문을 가졌지만
아직 충분히 오랜 역사가 아니다 라고 넘어갔던 선생님에 대한 기억이 있다.

까맣게 잊고 있다가 오랜후에 나중에야 알게 된 일이지만.
사실 세대가 거듭해도 우성과 열성의 형질 비율은 3:1로 변하지 않는다.

멘델의 사후 수십년이 지난 후에 하디-바이베크로 법칙의 한장짜리 논문에서 증명한대로
우성 유전자(A)의 비율을 p, 열성 유전자(a) 비율을 q라고 했을때 제한없는 무작위 교배는
유전형 AA의 비율은 pp, Aa의 비율은 pq+pq=2pq, 그리고 aa의 비율은 qq가 된다.

이제 A와 a의 비율을 구해보면
A : 1*pp + 1/2*2pq + 0*qq = p(p+q) 이며
a : 0*pp + 1/2*2pq + 0*qq = q(p+q) 가 된다.

그런데 p + q = 1이기 때문에 (우성과 열성의 비율을 합하면 1이다.)
p(p+q) = p 이며 q(p+q)는 q 이므로 A의 비율은 p이며 a의 비율은 q로 변하지 않는다.


이화식씨가 얘기했던 DB의 아키텍쳐를 이해하는 프로그래머의 비율은
자신이 처음 교육을 시작했던 15년 전과 변하지 않는다는 얘기는 이런데서 기인하지 않을까?

그리고 그동안의 기술의 발전 무수한 교육시절의 확충에도 불구하고
나쁜 프로그램과 좋은 프로그램의 비율도 물론 변하지 않는 것처럼 보인다.

좋은 프로그래밍의 기준은 많이 있지만 일반적으로 좋은 품질의 기준은
이식성(portability), 신뢰성(reliability), 효율(efficiency), 사용 편의성(usability), 테스트 용이성(testability), 이해 용이성(understandability), 수정 용이성(modifiability) 의 7개 정도의 속성으로 정의할 수 있다.

소프트웨어의 분야의 다양함 만큼이나 다양한 사람들이 조금씩 다른 기준을 제시하고 있기는 하지만 큰틀은 그리 변하지 않는 일반적 기준이라 할 수 있겠다.

위의 속성이 좋은 프로그래밍의 기준이라면..

개인적으로는 위대한 프로그래밍의 기준으로 전혀 다른 쌩뚱한 기준을 가지고 있다.

첫번째 기준은 진화이다.
보통의 프로그램은 분석-설계-코딩-테스트-유지보수의 단계를 가지고 있다. 이게 1싸이클이든 여러개의 싸이클이든 말이다. 이 중 맨 마지막 단계인 유지보수는 소프트웨어에서 가장 많은 비용을 발생시키는데 이는 대부분 피드백 전달체계에 있다. 패키지화된 소프트웨어를 일단 전달하면 땡인 수십년전의 소프트웨어와 달리 오늘날의 소프트웨어의 대부분은 항상 피드백을 받는다. (엄밀하게 말하자면 피드백의 기간이 줄었다고 볼 수 있다. 예전처럼 메이저 버전이 올라가는 업그레이드 보다 마이너 업그레이드의 비율이 늘어났고 생각할 수 있기 때문이다.) 고객이 소비자가 사용하는 패턴을 관찰한후 개발사에게 다시 추가 기능요구나 버그 수정을 요청하는 이러한 피드백 형태는 크게 2가지의 문제가 있다. 하나는 피드백과 반응의 시간이 매우 길다는 거고 두번째로 소비자 -> 고객 -> 개발사 -> 고객 으로 이동하면서 실제로 필요한것과 요구한 것과의 변질이 발생한다는 것이다.

그래서 훌륭한 소프트웨어는 진화라는 특성을 가져야 한다고 생각한다. 일종의 자동반응 체계라고 얘기할 수 있는데 소비자의 행동 피드백 그 자체에 반응하는 코드가 내재되어 있는 코드를 말한다. 소비자의 행동 피드백은 다양한 것으로부터 수집될 수 있다. 단순히 클릭와 접속시간뿐 아니라 스팸 신고 버튼과 같이 적극적인 피드백을 얻는 장치도 있다. 다만 현재의 대부분의 소프트웨어는 피드백을 수집하기만 할뿐 실제 해석은 거의 이루어지지 않거나 사람에 의해서 뒤늦게 인지된다. 기본적으로 학습하는 소프트웨어라고 할까.. 굳이 거창하게 AI까지 갈 필요는 없다. 이 분야의 가장 좋은 예는 아마 DB의 옵티마이저가 아닐까 싶다.

아래 예제로 든 스팸 처리 코드도 체인필터나 전략패턴같은 테크닉이 중요한게 아니라 얼마만큼 피드백에 자동화한 반응이 가능한가에 그 중요도가 달린다.



두번째 기준은 첫번째 진화 특성때문에 나온 유기적 독립성을 갖춘 소프트웨어이다. 앞서 옵티마이저가 현재 우리가 사용하는 소프트웨어중 가장 진화에 가까운 소프트웨어이긴 하지만 이는 제한적인 의미의 진화이다. 무슨말이냐면 옵티마이저의 피드백 반응은 옵티마이저 설계자의 손바닥 안에서의 반응에 불과하다. DB에 대한 최고 전문가가 설계한 그 공간안에서의 자유다. 이는 결국 뛰어봐야 부처님 손바닥같은 얘기다.

한때 유행어였던 집단지성(Collective Intelligence)과는 비슷하지만 조금 다르다. 피드백의 교환으로 인한 진화보다 돌연변이의 출현은 훨씬 극적이다. 종의 돌연변이가 아니라 개체의 돌연변이이므로 소프트웨어는 종으로서가 아니라 유기적인 개체단위의 합으로 존재해야 한다. 글로 의미를 전달하긴 좀 어렵지만 예컨데 분산화된 위키같은 구조이다. 각 사이트는 커다란 종으로서의 부분으로 존재함과 동시에 그 자체가 독립적인 서비스이기도 하다.

최초의 객체지향 언어인 스몰토크를 만든 엘런케이는 생물학을 전공했기에 그는 각 세포들은 다른 세포들과 화학 물질들 전달하면서 통신하며 동작하는 시스템을 알고 있었다. 각 세포들은 다른 세포들의 내부 구조는 알 필요가 없었다. 단지 상대방이 인식하는 화학 물질들로서 대화를 할 수 있었다. 또한 이 세포들은 객체고, 화확 물질을 분배하여 통신하는 것은 객체 사이에서 메시지를 교환하며 동작하는 것과 같았다.

이러한 설계의 가장 기본적인 원리는 부분에게 전체와 같은 힘을 주는 것이다. 이를 객체지향이 아닌 전체 프로그램에 적용하면 하나의 프로그램이 모여서 군집의 프로그램을 이루게 된다. 즉 프로그램 하나가 유기적 독립체이기도 하지만 그 프로그램의 군집또한 하나의 거대한 프로그램이 된다.

물론 개인적으로 아직 위대한 소프트웨어를 본적은 없다. 만들려고 한적은 있지만. -ㅅ-

작년에 모기업 서류통과-필기시험-실기시험을 통과하고
마지막으로 인성면접때 면접관이 나에게 한 질문이다.

물론 질문은 나한테 한거지만
기본적으로 프로그래머들은 "고집불통에 독선적이고 까칠한 성격이라서 타협할 줄 모르고 자기 주장만을 하는 인.종."이라는 인식이 있다. (.. 라는 사실을 프로그래머들도 알고 있다. )

그냥 대충 상황에 따라 다르다 라고 말했지만(그리고 그 인성 면접에서 떨어졌다-ㅅ-)
속으로는 다른 생각을 하고 있었다.

개인적으로는 - 비록 다른 인종들은 그닥 동의하지 않지만 -
프로그래머들 이야말로 타협의 프로라고 생각한다.
프로그래머는 항상 타협을 한다.

요구사항때는 수많은 이해당사자와 타협을 하고
설계시 여러 프레임워크와 여러 아키텍쳐, 방법론들 사이에서 타협하고
코드를 짤때 시간의 효율과 공간의 효율 사이에서 타협을 한다.
그리고 현재의 코드와 미래 발생할지 모르는 유지보수 사항과도 타협을 해야 한다.

사실 프로그래머의 일상은 타협의 일상에 다름아니다.

그러함에도 프로그래머들이 타협을 할 줄 모르는 독단적인 캐릭으로 취급받는 이유는
프로그래머는 항상 타협을 할때 타협의 이유를 무의식으로 생각하기 때문이다.


"당신은 6개월의 일정을 예상했지만 나는 2개월을 예상합니다. 이제 4개월로 타협합시다"
라는걸 타협이라고 부른다면 계속 읽지 않아도 된다.


사람들이 자주 망각하는 것중 하나는 프로그래머라는 직업은 매우 지적인 활동이며 관리자들이 생각하는 것보다는 훨씬 더 프로그래머는 영리한 사람들이라는 것이다. 물론 프로젝트가 4개월 이내에 완성되지 않으면 안되는 이유가 있을 수도 있다. 그때까지 완료하여 자본회수가 안된다면 회사가 심각한 위기에 처해 도산한다든가 그때까지 완료되지 않으면 핵발전소가 폭팔한다던가 혜상이 지구와 충돌하는 아마게돈이 일어난다고 개발자에게 솔직이 말한다면 중요도에 따라 일부 기능을 삭제한다든가 "상황은 매우 안좋지만 분발해보죠"라는 도전의식을 가질지도 모른다.


하지만 사실은 이 계약을 따낼때 접대 술자리에서 4개월에 무조건 하기로 했다던가 사실 당신의 말보다는 파킨슨의 법칙을 더 신용하기 때문이라면 프로그래머들은 타협의 이유를 생각하게 된다. 팀원에게 육체적,정신적 건강과 인간관계를 희생하라고 할때 그 희생의 결과는 무엇일까. 사실 대부분의 프로그래머들은 이러한 문제 프로젝트들은 대부분 실패하고, 또 그 정도까지는 아니라도 다른 생활을 포기하면서까지 매달릴만한 가치가 없다는 사실을 그동안의 값진 경험을 통해 잘 알고 있다. 그리고 그 타.협.대로 진행되서 일주일에 100시간 근무를 했더라도 25% 확률의 수고했어 라는 한마디 말 정도의 보상밖에 없다는 것도 말이다.


그렇다고 나를 비롯한 프로그래머들이 이러한 프로젝트를 항상 거부하는 것은 아니다. 사실 대부분의 프로그래머들이 그러하듯이 컴퓨터에 열광하는 내성적이고 그닥 사람들과 어울리는 것에 크게 관심이 없고 관심을 끌만한 도전의식이 있는 과제라면 최저한의 보상이라도 이러한 프로젝트에 참여할 것이다.

등산가들이 산이 거기 있기때문에 라는 어처구니 없는 이유로 에베레스트를 오르듯이 멋진 무언가를 만들기위해서는 일주일데 2번 가는 희생따위는 아랑곳 하지 않는 비정상적인 사람들이 우글우글 몰려 있는곳이 IT 바닥이다. 하지만 변덕스러운 고객의 마음을 독심술을 동원하여 맞추는데만 3개월이고 사실은 그저그런 재미없는 새로울것도 없고 멋진것도 없는 어디 내놔도 부끄러운 것을 만들어야 한다면 의욕은 감퇴하기 마련이다. (그래서 보통은 기한을 이유로 기능을 줄이지 않고 품질을 희생시키는 것은 좋은 생각이 아니다.)


결국 프로그래머들이 타협을 할 줄 모르는게 아니다.
다만 타협의 이유를 아무도 알려주지 않거나 사실 타협의 이유 따윈 없기때문에 타협을 하지 않는 걸 오해받을 뿐이다.




"전에도 말했지만 나는 누구나 한번씩은 문제 프로젝트에 참가해 볼 필요가 있다고 생각합니다. 그 외에도 한번씩 해봐야 할 일로는 이런것들이 있어요
 - 감옥에서 하룻밤 보내기
 - 변기를 끌어안을 정도로 술 마시기
 - 어린아이 키우기
 - 창업하기
 - 후지산 등반하기 "
by Rick Zahniser