Life is Simple, Thinking is High

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


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