IT 이야기2009. 1. 13. 13:45

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

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

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

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

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

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

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



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

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

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

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

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

'IT 이야기' 카테고리의 다른 글

재사용이라는 성배 2  (0) 2009.01.20
재사용이라는 성배  (0) 2009.01.20
멘델의 우열의 법칙  (0) 2009.01.15
타협할 수 있나요?  (0) 2009.01.09
미네르바의 구속을 보며  (0) 2009.01.09
Posted by bleujin
pds2009. 1. 12. 15:06

꽤 오래 울궈먹은 자료-ㅅ-

2005년도 쯤에 처음 작성.. 그후로 조금씩 수정하면서 여러번 써먹었...


- RDB 아키텍쳐의 구조
- 인덱스의 원리
- 조인의 원리

'pds' 카테고리의 다른 글

AL Ver 0.1  (0) 2009.07.24
AL의 첫 테스트 버전  (0) 2009.04.12
Framework - Source  (0) 2009.02.19
Bleujin Framework Jar  (0) 2009.01.15
UTF-8 발표자료  (0) 2009.01.12
Posted by bleujin
pds2009. 1. 12. 15:04


2006년쯤에던가.. 하여튼 그 쯤에 UTF-8 에 대해 발표한 자료..

사내 발표 자료였는데.. 어느 순간 인터넷에서 떠돌아 다니는걸 보고 깜짝 -ㅅ-

그때나 지금이나 그리고 조엘에 따르면 15년 전에도 UTF에 대해 알고 있는 개발자의 비율은 변치않고 있다. 


일반적인 UTF 얘기와 오라클에서의 UTF의 의미

  - Global Software ?
  - Example
  - Lenend of ASCII
  - Myth of Unicode
  - Oracle NLS
  - 참조

'pds' 카테고리의 다른 글

AL Ver 0.1  (0) 2009.07.24
AL의 첫 테스트 버전  (0) 2009.04.12
Framework - Source  (0) 2009.02.19
Bleujin Framework Jar  (0) 2009.01.15
Database 발표 자료  (0) 2009.01.12
Posted by bleujin