clean-architecture-book-thumbnail

컴포넌트 : 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위

  • 자바 → jar
  • 루비 → gem
  • 닷넷 → DLL
  • 컴파일형 언어 → 바이너리 파일의 결합체
  • 인터프리터형 언어 → 소스 파일의 결합체

컴포넌트가 마지막으로 어떤 형태로 배포되든, 잘 설계된 컴포넌트라면 반드시 독립적으로 배포가 가능해야 하며 독립적으로 개발 가능한 능력을 갖춰야 한다.

Table of Contents

컴포넌트의 간략한 역사

  • 소프트웨어 개발 초창기에는 프로그램이 로드될 주소를 직접 제어해야 했다.
  • 이러한 구시대에는 라이브러리 함수에 접근하려면 라이브러리 함수의 소스 코드를 애플리케이션 코드에 직접 포함 시켜서 단일 프로그램으로 컴파일 했다.

    • 컴파일 과정은 너무 오래 걸렸고 메모리는 너무 비싸 한정적이였다.
  • 컴파일 시간을 단축시키기 위해 함수 라이브러리를 개별적으로 컴파일 했다.
  • 그리고 라이브러리를 로드한 다음 메모리 주소에 접근하는 방식으로 라이브러리를 사용했다.
  • 하지만 점점 프로그램과 라이브러리의 크기가 커지면서 사용하는 메모리가 늘어나 단편화가 심해졌다. 따라서 이러한 방식은 지속 가능하지 않았다.

재배치성

해결책은 재배치가 가능한 바이너리(relocatable binary)였다. 즉, 지능적인 로더를 사용해서 메모리에 재배치할 수 있는 형태의 바이너리를 생성하도록 컴파일러를 수정하는 방법이다.

  • 프로그램이 라이브러리 함수를 호출한다면 컴파일러는 라이브러리 함수 이름을 외부 참조(external reference)로 생성했다.
  • 반면 라이브러리 함수를 정의하는 프로그램이라면 컴파일러는 해당 이름을 외부 정의(external definition)로 생성했다.
  • 이렇게 함으로써 외부 정의를 로드할 위치가 정해지기만 하면 로더가 외부 참조를 외부 정의에 링크시킬 수 있다.
  • 이렇게 링킹 로더(linking loader)가 탄생했다.

링커

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

  • 하지만 1960년대 말 프로그래머들은 더 큰 야심을 품었고, 프로그램은 훨씬 커졌다.

    • 결국 링킹 로더의 속도가 너무 느려져서 로드와 링크를 분리한다.
    • 프로그래머가 느린 부분인 링크 과정을 맡아 링커라는 별도의 애플리케이션으로 이 작업을 처리한다.
    • 링커는 링크가 완료된 재배치 코드를 만들어 주었고, 그 결과 로더의 로딩 과정이 아주 빨라졌다.
  • 그리고 1980년대, C나, 고수준 언어를 사용하면서 코드가 수십만 라인을 넘어서며 결국 컴파일과 링커에서 걸리는 시간이 다시 늘어났다.

    • 무어(Moore)가 등장해 이를 해결하자 디스크는 작아지기 시작했고, 놀랄 만큼 빨라졌다.
    • 컴퓨터 메모리는 말도 안 될 정도로 저렴해졌다.
    • 이렇게 액티브 X와 공유 라이브러리 시대가 열렸다.
  • 결국, 컴퓨터와 장치가 빨라져서 또다시 로드와 링크를 동시에 할 수 있게 되었다.
  • 다수의 .jar 파일 또는 다수의 공유 라이브러리를 순식간에 서로 링크한후, 링크가 끝난 프로그램을 실행할 수 있게 되었다.
  • 이렇게 컴포넌트 플러그인 아키텍처(component plugin architecture)가 탄생했다.

결론

  • 과거에는 초인적인 노력을 들여야만 컴포넌트 플러그인 아키텍처를 적용할 수 있엇다.
  • 하지만 지금은 기본으로 쉽게 사용할 수 있는 지점까지 다다랐다.

References

  • 모든 출처는 Clean Architecture 도서에 있습니다.