컴포넌트(Component)
개발하면서 컴포넌트라는 말은 여러가지 의미로 엄청 많이 사용하는 것 같다.
클라이언트 언어에서 컴포넌트, 아키텍처에서 컴포넌트, 또는 그냥 요소라는 의미에서 컴포넌트, 어쩌면 비슷한 의미이면서 정확하게 구분하면 다른 의미.
클린 아키텍처를 읽고 아키텍처에서 컴포넌트가 의미하는 바는 무엇일까
컴포넌트는 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위이다.
자바에서는 jar 파일, 루비에서는 gem, .net에서는 DLL을 컴포넌트로 취급한다.
컴파일형 언어에서는 컴포넌트가 바이너리 파일의 집합체이고, 인터프리터형 언어에서는 소스 파일의 결합체이다.
컴포넌트는 서로 링크해 실행 가능한 단일 파일로, 묶어서 .war 파일과 같은 단일 아카이브로, 각각을 .jar나 DLL 같이 동적으로 로드할 수 있는 플러그인이나 .exe파일로 만들어 독립적으로 배포할 수 있다.
어떤 형태로든 컴포넌트는 독립적으로 배포/개발될 수 있는 형태로 설계되어야 한다.
컴포넌트의 역사
소프트웨어 개발 초창기
소프트웨어 개발 초창기에는 프로그래머가 직접 메모리에서의 프로그램 위치, 레이아웃을 제어해야 했고, 한번 결정된 프로그램의 위치는 재배치가 불가능했다.
라이브러리 함수에 접근하기 위해서는 프로그래머가 라이브러리 함수의 소스 코드를 애플리케이션 코드에 포함시켜 단일 프로그램으로 컴파일했고, 라이브러리는 바이너리가 아닌 소스 코드 형태로 유지되었다.
따라서 컴파일러는 소스 코드 전체를 여러번에 걸쳐서 읽어야 했지만, 메모리는 너무 작고 소스 코드 전체를 메모리에 상주시킬 수 없어 느린 장치에 의존해 소스 코드를 읽어들였다.
애플리케이션과 라이브러리 함수의 분리
컴파일 시간을 단축시키기 위해 프로그래머는 함수 라이브러리의 소스코드와 애플리케이션의 소스 코드를 분리했다.
함수 라이브러리를 컴파일한 바이너리를 메모리에 로드하고, 심벌 테이블을 통해 애플리케이션 코드를 컴파일 했고, 함수 라이브러리를 로드한 다음, 애플리케이션을 로드해서 애플리케이션을 실행할 수 있었다.
하지만 어플리케이션이 점점 커짐에 따라 프로그래머는 애플리케이션을 두 개 이상의 주소 세그먼트로 분리해 동작하도록 배치하였고, 단편화가 발생하기 시작했다.
재배치 가능한 바이너리(Relocatable Binary) - 링킹 로더의 탄생
애플리케이션이 계속해서 커짐에따라 세그먼트를 나누고 이에 수반되는 단편화를 해결할 수 있는 방법은 재배치 가능한 바이너리였다.
지능적인 로더를 사용해 메모리에 재배치할 수 있는 형태의 바이너리를 생성하도록 컴파일러를 수정하는 것이다.
프로그래머는 함수 라이브러리와 애플리케이션을 로드할 위치를 로더에게 지시하고, 로더는 여러 개의 바이너리를 입력받은 후, 차례로 메모리로 로드하면서 재배치하는 작업을 수행했다.
또한, 컴파일러는 재배치 가능한 바이너리 안의 함수 이름을 메타 데이터로 생성하도록 수정되었고, 라이브러리 함수를 호출할 때는 외부 참조(external reference)로, 정의하는 프로그램에서는 외부 정의(external definition)로 생성되었다.
이로인해 로더는 외부 정의를 로드할 위치만 정해지면 외부 참조를 링크시킬 수 있게 된다.
링커(Linker)
프로그램이 점점 커짐에 따라 링킹 로더 또한 솔루션이 되지 못했고, 링커와 로더를 분리하게 되었다.
링커가 링크가 완료된 재배치 코드를 만드는 느린 작업을 맡아 처리해 로더의 처리 속도는 매우 빨려졌다.
링커가 실행 파일을 만드는 작업 속도는 느렸지만, 한번 만들어둔 실행 파일은 언제라도 빠르게 로드할 수 있게 되었다.
C와 같은 고수준 언어를 사용하면서 소스 모듈은 소스코드 파일에서 오브젝트 파일로 컴파일된 후, 링커로 전달되어 빠르게 로드될 수 있는 실행 파일로 만들어졌다.
하지만 이러한 노력에도 불구하고 프로그램은 계속해서 커져갔고, 컴파일-링크 시간의 병목 구간은 해결할 수 없었다.
무어의 법칙(Moore's Law)
인텔의 창업자 고든 무어(Gordon Moore)는 "반도체 칩에 집적할 수 있는 트랜지스터의 숫자가 적어도 매 18개월마다 두 배씩 증가한다"라는 법칙을 선언했고, 이후 컴퓨터 리소스와 퍼포먼스는 프로그램의 성장 속도를 압도하기 시작한다.
컴포넌트 플로그인 아키텍처(Component Plugin Architecture)
빠른 컴퓨터 리소스와 퍼포먼스의 발달로 ActiveX와 공유 라이브러리 시대가 열렸고, jar 파일도 등장한다.
다수의 jar 파일 또는 공유 라이브러리를 서로 링크한 후, 프로그램을 실행할 수 있게 된다.
이로 인해, 컴포넌트 플러그인 아키텍처(Component Plugin Architecture)가 탄생하게 된다.
서적 : http://www.yes24.com/Product/Goods/77283734
'Architecture' 카테고리의 다른 글
[Clean Architecture 정리] 14장. 컴포넌트 결합 (1) (0) | 2022.07.27 |
---|---|
[Clean Architecture 정리] 13장. 컴포넌트 응집도 (0) | 2022.07.25 |
[Clean Architecture 정리] 11장. DIP (0) | 2022.07.23 |
[Clean Architecture 정리] 10장. ISP (0) | 2022.07.23 |
[Clean Architecture 정리] 9장. LSP (0) | 2022.07.20 |
댓글