컴포넌트

컴포넌트는 배포 단위다.

자바의 경우 .jar 파일이 컴포넌트가 되고, 루비의 경우 gem 파일이 컴포넌트가 된다.

 

개발 초창기에는 프로그래머가 메모리에서 프로그램이 어느 곳에 위치할지 정의해야 했다.

아래의 코드를 간단하게 보자.

	*200
        TLS
START,  CLA
	TAD BUFR

위에서 설명한대로 예전에는 프로그래머가 메모리에 어느 곳에 위치할지 적어줘야 하므로 Origin 이 필요했다.

프로그램 시작부의 *200 을 주목해보자.

 

과연 어떤 의미일까?

이는 메모리 주소 200에 로드할 코드를 생성하라고 알려주는 것이다. 

내 단순한 추측인데 메모리의 코드영역이 이 영역이 아닐까? 라는 생각이 들게 되었다.

 

여하튼 현재 우리는 이런 고민을 할 필요가 없었지만, 그 당시에는 아주 큰 고민이였다.

왜냐하면 그 당시엔 성능도 지금만큼 좋지 못했고, 가격은 더더욱 비쌌다. 그래서 효율적으로 사용하는 것이 매우 중요했다.

 

그래서 큰 라이브러리를 이용해야 하는 상황이면 직접 자신의 코드에 포함시켜 단일 프로그램으로 컴파일했다.

이런 방식은 문제를 야기하게 되는데 바로 모든 코드를 메모리에 상주시킬 수 없어 컴파일러가 느린장치를 이용해 코드를 여러번 읽어야만 했다. 그래서 이러한 방식은 컴파일 시간을 몇시간까지도 늘리곤 하였다.

 

이 문제를 해결하기 위해서 프로그래머들은 라이브러리 코드를 애플리케이션 코드로 부터 분리했다.

예를 들면 라이브러리에 대한 심벌 테이블을 생성한뒤, 이를 이용해 애플리케이션 코드를 컴파일했다. 

대략적인 모습은 아래와 같다.

이렇게 처리하는 방식이 괜찮아 보였으나 어플리케이션은 점점 커지고

1777 의 범위를 벗어나는 일들이 발생하게 되었다.

라이브러리 또한 추가될 수록 필요한 메모리가 증가하게 되고, 이런 문제는 단편적으로 지속될수 밖에 없었다.

그래서 이런 문제의 해결책이 필요하게 되었다. 과연 어떻게 처리해야할까?

재배치성

결국 우리가 가지고 있던 문제는 계속해서 위치를 알고있고 정의해줘야 한다는 문제때문에 발생한 것인데

이를 동적으로 알 수 있도록 해결하기 위해서 재배치가 가능한 바이너리를 해결책으로 삼게되었다.

그래서 지능적인 로더를 도입하게 되는데, 이 지능적인 로더는 재배치 코드가 자리할 정보를 입력할 수 있었다.

그래서 로더를 통해서 여러 정보를 입력하면 로더는 하나씩 차례로 메모리에 로드하며 재배치하는 작업을 수행했다.

 

또한 재배치 가능한 바이너리안의 함수를 메타데이터 형태로 생성하게 되었는데

이를 통해서 외부 라이브러리를 로더를 통해서 참조할 수 있게 연결지어 사용할 수 있게 되었다.

이 시절의 지능적인 로더(링킹로더) 는 링킹과 로더의 역할을 둘다 수행하고 있었다.

링커

이 시절 문제를 해결했다고 생각했으나 프로그램은 점점 커지고 링킹로더의 속도가 매우 느려지기 시작했다.

링킹로더는 수백개 수천개의 바이너리를 읽고 외부 참조를 해석해야만 했다.

그래서 프로그램을 로딩해오는데만 몇시간이 걸리기 시작했고, 또 다른 해결책이 필요했다.

 

이 시절 생각한 해결책은 로드와 링크 단계를 분리하는 것 이였다.

그래서 프로그래머가 링크 부분을 직접하게 되었는데, 보통 링커 어플리케이션을 사용해서 이 작업을 처리했다.

링커는 링크가 완료된 재배치 코드를 만들었고, 그 덕에 로더가 빨라지게 되었다.

고수준 언어의 발달

시간이 지날수록 프로그래밍 언어또한 높은 추상화 단계에 다다르기 시작했고

C 언어와 같은 고수준언어가 메인 스트림으로 자리잡기 시작했다.

프로그래머들은 좀 더 쉽게 코딩할 수 있게 되었고, 이와 같은 발전으로 인해 프로그램의 크기도 커졌다.

이제 프로그램의 코드가 수십만 라인에 육박하기 시작했다.

 

C 의 소스 모듈은 .c 에서 .o 로 컴파일 되고, 링커로 전달되는 형태였다.

각 모듈은 컴파일 과정은 빨랐지만 전체를 컴파일 하는 과정은 또 오래걸렸고 링킹과정또한 오래걸리게 되었다.

 

그래서 프로그래머 들은 딜레마에 빠졌다.

바로 컴파일 - 링크 구간의 병목현상을 어떻게 줄여나가는것이 가장 큰 목표였다.

하드웨어의 발달

하지만 이는 하드웨어의 발전속도가 해결해 주기 시작했다.

메모리는 점점 빨라지고 가격이 저렴해지기 시작했고, CPU 또한 마찬가지로 성능이 좋아지기 시작했다.

소규모 작업이라면 다시 링킹로더를 쓰는 것을 고려할 정도로 빨라지기 시작했다.

 

이렇게 하드웨어의 발달로 선택지가 많아졌으며

다수의 .jar 파일 또는 다수의 공유 라이브러리를 순식간에 서로 링크한 후 링크가 끝난 프로그램을 실행시킬 수 있었다.

하드웨어의 발전으로 인해 컴포넌트 플러그인 아키텍쳐를 쉽게 사용할 수 있게 되었다.

 

이제는 런타임에 배포가능한 컴포넌트들을 연동시키는데 문제를 겪지 않는다.

java 를 할때 mysql-connector.jar 를 쓴다고 해서 어려움을 겪은 적이 있는가?

과거에는 이런 문제들이 있었다.. 이제는 컴포넌트 플러그인 아키텍쳐가 쉽게 가능하다.