재사용이라는 성배 2

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

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

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

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

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



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

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



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

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