📍 컴포넌트
시스템의 구성 요소로 배포할 수 있는 가장 작은 단위
컴포넌트가 마지막으로 어떤 형태로 배포되든, 잘 설계된 컴포넌트라면 반드시 독립적으로 배포가 가능해야 하며 독립적으로 개발 가능한 능력을 갖춰야 한다.
📕 컴포넌트의 간략한 역사
- 소프트웨어 개발 초창기에는 메모리에서의 프로그램 위치와 레이아웃을 프로그래머가 직업 제어했다.
- 프로그램의 위치가 한번 결정되면 재배치 불가능
- 라이브러리 함수에 접근하려면 라이브러리 함수의 소스 코드를 애플리케이션 코드에 직접 포함 시켜서 단일 프로그램으로 컴파일 했다.
- 장치는 느리고, 메모리는 비쌌다.
- 컴파일 시간을 단축시키기 위해 함수 라이브러리를 개별적으로 컴파일 했다.
- 라이브러리를 로드한 다음 메모리 주소에 접근하는 방식으로 라이브러리를 사용했다.
- 점점 프로그램과 라이브러리의 크기가 커지면서 사용하는 메모리가 늘어나 단편화가 심해졌다. 따라서 이러한 방식은 지속 가능하지 않았다.
📗 재배치성
- 재배치가 가능한 바이너리(relocatable binary)였다.
: 지능적인 로더를 사용해서 메모리에 재배치할 수 있는 형태의 바이너리를 생성하도록 컴파일러를 수정하는 방법- 필요한 함수만 로드 가능하게 되었다.
- 프로그램이 라이브러리 함수를 호출한다면 컴파일러는 라이브러리 함수 이름을 외부 참조(external reference)로 생성했다.
- 라이브러리 함수를 정의하는 프로그램이라면 컴파일러는 해당 이름을 외부 정의(external definition)로 생성했다.
- 이렇게 함으로써 외부 정의를 로드할 위치가 정해지기만 하면 로더가 외부 참조를 외부 정의에 링크시킬 수 있다.
- 이렇게 링킹 로더(linking loader)가 탄생했다.
📙 링커
링킹 로더의 등장으로 프로그래머는 프로그램을 개별적으로 컴파일하고 로드할 수 있는 단위로 분할할 수 있게 되었다.
하지만 시간이 지나 프로그램 로드에 오랜 시간이 걸리자, 로드와 링크가 분리 되었다.
링크 과정을 링커가 실행하게 되었는데, 링커는 링크가 완료된 재배치 코드를 만들어 주었고, 그 결과 로더의 로딩 과정이 아주 빨라졌다.
그러나 1980년대, 고수준 언어를 사용하면서 코드가 수십만 라인을 넘어서며 결국 컴파일과 링커에서 걸리는 시간이 다시 늘어났다.
무어가 등장하면서 디스크 속도가 증가하고, 액티브X와 공유 라이브러리, jar 파일이 등장했으며,
다수의 .jar 또는 공유 라이브러리를 순식간에 서로 링크한 후, 링크가 끝난 프로그램을 실행할 수 있게 되었다.
이렇게 컴포넌트 플러그인 아키텍처(component plugin architecture)가 탄생했다.
📘 결론
과거에는 초인적인 노력을 들여야만 컴포넌트 플러그인 아키텍처를 적용할 수 있었지만, 지금은 기본으로 쉽게 사용할 수 있는 지점까지 다다랐다.
📚 Reference
- Clean Architecture : 소프트웨어 구조와 설계의 원칙
로그를 생활화