멀티파일 프로젝트 — 큰 프로그램 관리법

오늘은 멀티파일 프로젝트가 왜 필요한지 살펴보겠습니다.

학습용 C 프로그램은 보통 파일 하나에 수백 줄이죠.

하지만 실제 프로덕션 코드는 이야기가 완전히 다릅니다.

그림 왼쪽을 보세요.

리눅스 커널은 약 2,800만 줄에 .c 파일만 3만 개가 넘습니다.

이 프로젝트들이 단일 파일이었다면 개발 자체가 불가능했겠죠.

단일 파일에는 세 가지 핵심 한계가 있습니다.

첫 번째, 컴파일 시간 폭증 문제입니다.

C 컴파일러는 파일 단위로 동작합니다.

단일 파일이라면 한 글자 수정에도 전체를 재컴파일해야 하죠.

그림 가운데 비교표를 보시면, 단일 파일은 약 60초가 걸립니다.

멀티파일은 수정된 .c 파일만 재컴파일해서 약 8초면 됩니다.

무려 7~8배나 빌드 시간이 단축되는 겁니다.

대형 프로젝트에서 전체 빌드 30분이 재빌드 5초로 줄어들죠.

두 번째는 팀 협업 문제입니다.

그림 가운데 협업 섹션을 보시면, 개발자마다 담당 파일이 따로 있습니다.

단일 파일이라면 머지 충돌이 끊임없이 발생합니다.

리눅스 커널은 수천 명이 동시에 기여하는 프로젝트인데요.

파일 분리 없이는 절대 불가능한 협업 규모입니다.

세 번째는 재사용성 문제입니다.

오른쪽을 보시면 math_utils.c 하나가 여러 프로젝트에 연결되어 있습니다.

파일을 분리하면 특정 기능만 뽑아 다른 곳에 바로 재사용할 수 있죠.

이제 하단 분리 컴파일 흐름도를 살펴보겠습니다.

소스 .c 파일들이 각각 독립적으로 .o 파일로 컴파일됩니다.

utils.c만 수정되면, utils.o만 새로 만들고 나머지 .o는 재사용합니다.

이것이 인크리멘탈 빌드이고, make가 이를 자동으로 관리해 줍니다.

링커가 모든 .o 파일을 결합해 최종 실행 파일을 만들어냅니다.

하단 왼쪽 구조를 보면 src, include, tests, Makefile로 나뉩니다.

하단 오른쪽 캡슐화 예시도 꼭 봐 두세요.

network.h는 외부에 공개할 함수 선언만 담습니다.

network.c는 내부 구현을 static으로 숨겨 외부 접근을 막습니다.

이것이 C에서 인터페이스와 구현을 분리하는 캡슐화 방식입니다.