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


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

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

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

대규모 재사용을 지지하는 사람들은 대규모 재사용이 널리 퍼지지 못한 이유를 사람들의 무지, 혹은 다른사람의 작업을 인정하지 않는 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배 이상이라고 했을때는 문제는 전혀 달라지는 것이다.

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

굳이 메쉬업 프로그래밍을 하지 않더라도 하다보면 인터넷에서 자료를 쭉 긁어오고 싶을때가 있다.
이건 사실은 신문사 만화 사이트를 일일이 클릭해가면서 - 게다가 그 수많은 광고를 참으며 - 보느니
로컬에 그림만 다운로드 받아봐야지 하고 후다닥 만들었다-ㅅ-


이 작업을 하려면 먼저 bleujin Framework core의 jar 파일을 아래 포스팅에서 다운로드 받고..

위 3개의 jar가 추가적으로 필요하다. 예전에 작성할때 다운로드 받은거라 최근에는 버전업이 됐겠지만 그냥 쓴다-ㅅ-
아마 common-io랑 common-lang도 필요하겠지만 그건 그냥 apache 에서 다운로드 추천-ㅅ-
(오늘까지 방문자가 한명도 없으니 다소 무책임해도 상관없으리라.. 쿨럭)

Framework에는 html Parsing에 관련된 - jericho의 소스에 Facade 패턴을 사용해서 간단하게 만들 수 있었다. - 부분만 있어서 먼저 인터넷에 접속해서 InputStream을 받아오는 로직을 작성해야 한다.



public class Spider {

 private Logger log = LogBroker.getLogger(Spider.class) ;
 
 public Reader getPageContent(String httpURL) throws HttpException, IOException {
  String content = IOUtils.toString(getInputStream(httpURL), "EUC-KR") ;
  return new StringReader(content) ;
 }

 public InputStream getInputStream(String httpURL) throws HttpException, IOException {
  HttpClient httpclient = new HttpClient();
  GetMethod httpget = new GetMethod(httpURL);
  try {

   httpclient.executeMethod(httpget);
   log.info("recevied data : " + httpURL) ;
   
   InputStream input = httpget.getResponseBodyAsStream() ;
   InputStream result = new ByteArrayInputStream(IOUtils.toByteArray(input)) ;
   input.close() ;
   return result ;
   
  } catch (Exception ex) {
   log.warning(ex.getMessage()) ;
   throw new HttpException(ex.getMessage(), ex) ;
  } finally {
   httpget.releaseConnection() ;
  }
 }
}

EUC-KR의 상수 부분이 걸리긴 하지만 머 대충 만들고 넘어가자-ㅅ-(사실 사이트를 제대로 만들었다면 EUC-KR은 요즘의 국제화 시대에 맞지 않는 인코딩방법이다. )

사용은 대충 아래와 같이 한다.

 public void testSportChosun() throws Exception {
  String httpURL = "http://manhwa.sportschosun.com/enter/cartoon/juyu/cartoon_juyu2.asp?num=138&title=juyu&Direct=Next" ;
  Spider s = new Spider() ;
  Reader content = s.getPageContent(httpURL) ;
  HTag tag = HtmlParser.parse(content) ;
  
  HTag img = tag.findElementBy(IMG, "src", "http://manhwa.sportschosun.com/enter/cartoon/juyu/image_cartoons/20071119y_233.gif") ;
  System.out.println(img.toString());
  System.out.println(img.getPath());
  
  
  String imgPath = img.getAttributeValue("src") ;
  System.out.println(imgPath);
  
  content.close() ;
 }


 public void testSave() throws Exception {

  int current = 100 ;
  Spider s = new Spider() ;
  for (int i = 1; i <= current; i++) {
   String path = "http://manhwa.sportschosun.com/enter/cartoon/juyu/cartoon_juyu2.asp?num=" + i + "&title=juyu&Direct=Next" ;
   Reader content = s.getPageContent(path) ;
   HTag tag = HtmlParser.parse(content) ;
   HTag img = tag.getChild("body[0]/table[4]/tr[0]/td[2]/table[1]/tr[8]/td[0]/img[0]") ; // /html/body/table/tr/td/table/tr/td/img
   String imgSrc = img.getAttributeValue("src");
   
   FileOutputStream output = new FileOutputStream(new File("c:/temp/" + StringUtil.substringAfterLast(imgSrc, "/")));
   IOUtils.copy(s.getInputStream(imgSrc), output) ;
   output.close() ;
  }
 }


HTag가 클래스가 Facade 클래스인데 이런저런 다양한 파싱에 관련된 메소드들을 모두 가지고 있다.

이를테면 getChild("body/table[4]/tr[0]/td[2]/table[1]/tr[8]/td[0]/img[0]") 는
body안에 5번째 table 태그안에 첫번째 tr안에 3번재 td안에 2번째 table안에 9번째 tr안에 첫번째 td안에 첫번째 img Tag를 가져오라는 뜻이다 -ㅅ-;;


만화그림 다운로드 받는데 쓰다가.
나중에 네이버나 다음에 있는 상장된 기업정보 페이지를 모두 긁어서 데이타베이스 구축하는데도 사용했다.


야후는 일정시간에 많은 GET이 날라가면 자동으로 해당 아이피 Block을 시켜버린다=ㅅ=
외국 기업이라 그런지 그런 기본적인 것에 충실하다.

2007년 말쯤에 작성한.. 추천도서
그래서 2008년 이후에 발행된 도서는 목록에 없다 -ㅅ-

Javascript
- Javascript The definitive Guide(원서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200606220013
- Ajax Design Pattern(원서) - http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200605220008
- Ajax 인 액션, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200605180029

Database
- Beginning Oracle Programming(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200209130002
- 데이터베이스설계와 구축, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200501150004, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200209040010
- Inside SQL Server 2000(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200106190006
- 새로쓴 대용량 데이터베이스 솔류션 1, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200511220001
- 대용량 데이타베이스 솔류션 1, 2, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=199912220013, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200005220004
- 데이터 아키텍쳐 솔류션, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200310250001
- 이펙트브 오라클(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200407060007
- SQL Performance Tunning(원서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200306190012

 

Java
- Beginning Java Object, , http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200112140007
- Java를 지배하는 핵심원리, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200303180003
- Java 언어로 배우는 Design Pattern 입문(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200203130012
- Java 언어로 배우는 Desing Pattern 입문[멀티 쓰레디편](번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200303110010
- HedFirst Design Patterns(번역서),http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200508240010
- Effective Java(번역서), Bloch, 대웅미디어, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200305090002
- HeadFirst Servlets & JSP, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200504280002
- 유쾌한 자바 퍼즐러, Bloch, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200706110018
- 리팩토링(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200204020003
- 자바 퍼포먼스 튜닝(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200310060005
- 자바툴을 이용한 eXtreme Programming, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200302040004
- 패턴을 활용한 리패토링, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200607110007
- Concurrent Programming in Java(원서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=199912290002
- Expert one-to-one J2EE 설계와 개발(원서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200307310017

 

Language
- 프로젝트 자동화 빌드, 디플로이, 모니터링, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200503230004
- 단위 테스트 with JUnit http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200411020003
- UML 실전에서는 이것만 쓴다, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200312170001
- 알고리즘 트레이닝 북, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200407020006
- Code Complete 2(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200504110013
- 테스트 주도 개발, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200412020003

 

Architecture
- HeadFirst Object-Oriented Analysis & Design(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200705250001
- 소프트웨어 개발의 지혜 : 원칙, 디자인패턴, 실천방법(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200402020001
- 소프트웨어 아키텍쳐 이론과 실제(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200704260053
- 엔터프라이즈 애플리케이션 아키텍쳐 패턴(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200303210001
- Core J2EE 패턴(번역서), ,http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200405220006
- GoF Design Pattern(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200705300004
- 자바 엔터프라이즈 디자인 패턴(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200305090007
- Pattern-Orinted software architecture 1(POSA 1 - 번역서), , http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200801140004
- Pattern-Orinted software architecture 2(POSA 2 - 원서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200010210003

 

교양 1
- 실용주의 프로그래머, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200505180011
- 생각하는 프로그래밍, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200301140012
- 우리가 미처 알지 못하는 소프트웨어 공학의 사실과 오해, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200409230002
- 프로그래밍 심리학(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200712140017
- 맨먼쓰 미신(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200708020005
- 소프트웨어 장인정신, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200212120001
- 피플웨어, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200302150001
- 대체 뭐가 문제야, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200602100038
- 컨설팅의 비밀, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200406300004
- 소프트웨어 컨플릭트 2.0, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200612210002
- 소프트웨어 프로젝트에서의 리스크 관리, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200409040001
- Rapid Development(번역서), http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200307150010

교양 2
- 조엘 온 스프트웨어, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200503170001
- 뉴욕의 프로그래머, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200709030002
- 죽음의 행진, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200511180002
- 해커와 화가, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200509230033
- 누가 소프트웨어의 심장을 만들었는가, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200503110001
- Code Craft - 뛰어난 코드 작성을 위한 실전 지침, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200710120001
- 임백준의 소프트웨어 산책, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200505230005
- 세상을 움직인 컴퓨터 과학자 15인의 지식 오디세이, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200509100002
- 링크, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200311010002
- 프로페셔널 소프트웨어 개발, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200310140001
- 소프트웨어 프로젝트 생존 전략, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200307230015
- Art Of Unix Programming(번역서) http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200408050002
- 누워서 읽는 알고리즘, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200312010001
- Web 2.0 이노베이션, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200612010027
- 당신만이 할수 있는 일을 하라, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200501250072
- 데드라인, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200402190001
- 익스트림 프로그래밍, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200607040038
- 마음을 움직이는 프로젝트 관리, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200606210006
- XP installed, http://kangcom.com/common/bookinfo/bookinfo.asp?sku=200207220004

멘델의 유전법칙 제 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년 전과 변하지 않는다는 얘기는 이런데서 기인하지 않을까?

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

2003년에 처음 작성 아직까지 잘 쓰고 있는 Java로 작성된 System Framework..

개인적으로는 Apache 어느 오픈소스와 비교해도 설계사상과 코드품질에 대해서는 자신이 있는..
언젠가 이와 관련한 글을 올릴 수 있기를...


전체를 모두 올렸다가 잘 사용하지 않는 부분은 ext부분으로 따로 빼버리고

  - Configuration
  - Database
  - exception handling
  - logging
  - parse.html
  - schedule

만 따로 묶었다.


https://github.com/bleujin/ionframework  로 프로젝트 이동.

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

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

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

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

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

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

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



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

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

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

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

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