12장 - 컴포넌트

SOLID와 컴포넌트

SOLID가 벽과 벽돌의 어떻게 배치하는지 알려준다면 컴포넌트는 빌딩에 어떻게 방을 배치하는지 설명합니다.

 

컴포넌트란?

시스템의 구성 요소로 배포할 수 있는 가장 작은 단위입니다.

자바의 경우 jar파일이 컴포넌트입니다.

 

또한 여러 컴포넌트를 서로 링크하여 실행 가능한 단일 파일로 생성할 수 있습니다.

잘 설계된 컴포넌트는 독립적으로 배포 가능하고 개발 가능한 능력을 갖추어야 합니다.

 

역사

소프트웨어 개발 초장기에는 프로그램의 시작부에 프로그램이 로드될 주소를 선언하는 구문이 필요했습니다.

한번 위치가 결정되면 재배치가 불가능했습니다.

 

이런 구시대에 라이브러리 함수에 접근하기 위해서는 소스 코드를 애플리케이션 코드에 직접 포함시켜 단일 프로그램으로 컴파일했습니다.

 

이 시대의 장치는 느리고 메모리는 비싸 자원이 한정적이었습니다.

따라서 컴파일러는 소스 코드를 여러 번 걸쳐 읽어야 했지만, 메모리가 너무 작아 소스 코드 전체를 메모리에 상주시킬 수 없었습니다.

 

따라서 소스 코드를 여러 번 읽어야 했고 함수 라이브러리가 크면 클수록 컴파일은 더 오래 걸렸습니다.

 

추후에 라이브러리를 개별 컴파일하고 컴파일된 바이너리를 메모리의 특정 위치에 로드했습니다.

하지만 애플리케이션이 점점 더 커져갔으며 할당된 공간을 넘어서게 되었습니다.

 

이제 애플리케이션은 두 개의 주소 세그먼트로 분리해야 했습니다.

하지만 함수 라이브러리에 더 많은 함수가 추가되면서 이 역시 할당된 메모리 주소를 넘어가게 되고 단편화는 계속될 수밖에 없었습니다.

 

해결책 : 재배치가 가능한 바이너리

위의 문제를 해결하기 위해서 지능적인 로더를 사용하여 메모리에 재배치할 수 있는 형태의 바이너리를 생성하도록 컴파일러를 수정하였습니다.

 

실제 로더는 여러 개의 바이너리를 입력받은 후, 차례로 메모리로 로드하면서 재배치하는 작업을 처리합니다.

이를 통해 프로그래머는 필요한 함수만을 로드할 수 있습니다.

 

또한 컴파일러는 재배치 가능한 바이너리 안의 함수 이름을 메타데이터 형태로 생성하도록 수정되었습니다.

 

프로그램이 라이브러리 함수를 호출하면 함수 이름을 외부 참조로 생성하지만 라이브러리 함수를 정의하는 프로그램이라면 컴파일러는 이를 외부 정의로 생성했습니다.

 

이제 외부 정의를 로드할 위치가 정해지면 로더가 외부 참조를 외부 정의에  링크시킬 수 있게 됩니다.

이렇게 링킹 로더가 탄생합니다.

 

링커

링킹 로더의 등장으로 프로그래머는 프로그램을 개별적으로 컴파일하고 로드할 수 있는 단위로 분할할 수 있게 됩니다.

 

하지만 프로그램을 점점 더 덩치가 커지고 링킹 로더는 너무나도 느렸습니다.

수십, 수백 개의 바이너리 라이브러리를 읽고 외부 참조를 해석해야 했습니다.

이로써 프로그램 하나를 로드하는데만 한 시간 이상이 걸리게 되었습니다.

 

로드와 링크 분리

이제 로드와 링크로 두 단계가 분리되었습니다.

프로그래머가 느린 부분인 링크 과정을 맡았습니다.

 

링커라는 별도의 애플리케이션으로 이 작업을 처리하도록 만들었습니다.

링커는 링크가 완료된 재배치 코드를 만들어 주고, 이 덕분에 로더의 로딩 과정이 아주 빨라졌습니다.

 

 

흔해진 수십만 라인의 프로그램

이런 노력에도 점점 더 프로그램을 커져만 갔고 링커에서 많은 시간이 소요되었습니다.

 

하지만 "우리가 흔히 아는 무어의 법칙"이 등장하게 되었고 메모리는 엄청나게 저렴해져 디스크의 많은 데이터를 모두 램에 캐싱할 정도가 되었습니다.

 

이제는 프로그램이 커지는 속도보다는 링크 시간이 줄어드는 속도가 더 빨라지기 시작했으며 많은 링크 시간은 초단위 수준으로 감소했습니다.

 

이제 다시 로드와 링크를 동시에 할 수 있게 되었고 다수의 .jar 파일 또는 다수의 공유 라이브러리를 순식간에 서로 링크한 후, 링크가 끝난 프로그램을 실행할 수 있게 되었습니다.

 

이렇게 컴포넌트 플러그인 아키텍처가 탄생했습니다.

 

이런 아키텍처를 쉽게 사용할 수 있는 지점까지 50년이 걸렸습니다.