전반적으로 가장 와닿는 장이였다 , 코드 컴파일의 역사를 알아보는 시간이였다.
컴포넌트는 배포 단위 이다. 시스템의 구성 요소로 배포할 수 있는 가장 작은 단위이다.
모든 언어에서 컴포넌트는 배포할 수 있는 단위이다.
컴포넌트가 마지막에 어떤 형태로 배포되든 , 잘 설계된 컴포넌트라면 반드시 독립적으로 배포 가능한 , 따라서 독립적으로 개발 가능한 능력을 갖춰야 한다.
소프트웨어 개발 초창기에는 메모리에서의 프로그램의 위치와 레이아웃을 프로그래머가 직접 제어했었다.
하지만 오늘날의 프로그래머는 프로그램을 메모리의 어느 위치에 로드할지 고민할 필요가 없다. 하지만 초창기에는 프로그램을 로드할 메모리의 위치를 정하는 일이 프로그래머가 가장 먼저 결정해야 하는 일 중 하나였다.
프로그래머가 라이브러리 함수의 소스 코드를 애플리케이션 코드에 직접 포함시켜 단일 프로그램으로 컴파일했다.
( ㅎㄷㄷ 직접.. 그걸… 존경스럽다 정말 )
즉 라이브러리는 바이너리가 아니라 , 소스 코드 형태로 유지된 셈이다. 그래서 그랬던 시대의 장치는 느리고 메모리는 비싸서 자원이 한정적이었기에 , 위 같은 방식은 문제가 있었다. 컴파일러는 소스 코드 전체를 여러번에 걸쳐서 읽어야 했지만 , 메모리가 너무 작아서 소스 코드 전체를 메모리에 상주시킬 수가 없었다.
그래서 그 느린 속도로 소스 코드를 여러 차례 읽어야만했으며 , 이 과정은 매우 오래 걸렸고 함수 라이브러리가 크면 클수록 컴파일은 더 오래걸렸다. 정말 몇 시간이 걸렸다고 한다..
( 와.. 컴파일시키고 밥 먹거나 자고 왔겠다 그때는.. )
그래서 해당 컴퍼일 시간을 단축시키기 위해 프로그래머는 함수 라이브러리의 소스 코드를 애플리케이션 코드로부터 분리를 시켰다. 함수 라이브러리를 개별적으로 컴파일하고 , 컴파일된 바이너리를 메모리의 특정 위치에 로드했다.
해당 방식은 잘 작동했다. 하지만 애플리케이션은 점점 더 커졌고 , 결국 할당된 공간을 넘어서게 된다. 그래서 애플리케이션을 두 개의 주소 세그먼트로 분리해서 함수 라이브러리 공간을 사이에 두고 오가며 동작하게 배치해야 했다고 한다.