2What — 단일 파일 프로그램의 현실
3- 학습용 C 프로그램은 보통 1개 .c 파일, 수십~수백 줄
4- 실제 프로덕션 코드는 이야기가 완전히 다르다:
5 • Linux 커널: 약 2,800만 줄, .c 파일만 약 30,000개 이상 (Corbet, 2020)
6 • SQLite: 약 15만 줄, 하지만 "amalgamation" 빌드 외에는 수십 개 파일로 분리
7 • OpenSSL: 약 50만 줄, 수백 개 소스 파일로 구성
8- 이 프로젝트들이 단일 파일이라면? → 개발 자체가 불가능
9Why — 단일 파일의 3대 한계
101. 컴파일 시간 폭증
11 - C 컴파일러는 파일 단위로 동작한다
12 - 단일 파일 100만 줄 → 한 글자 수정에도 전체 재컴파일
13 - 예: GCC로 10만 줄 단일 파일 컴파일 \approx 수십 초 ~ 수 분
14 - 멀티파일 → 변경된 .c 파일만 재컴파일 (incremental build)
15 - 대형 프로젝트에서 전체 빌드 30분 vs 수정 후 재빌드 5초의 차이
162. 팀 협업 불가
17 - 10명이 같은 파일을 동시에 수정 → 머지 충돌(merge conflict) 지옥
18 - 파일을 분리하면 각자 담당 모듈만 수정 → 충돌 최소화
19 - Linux 커널은 수천 명의 개발자가 동시 기여 — 파일 분리 없이는 불가능 (Kroah-Hartman, 2006)
203. 재사용성 제로
21 - 단일 파일에 모든 코드 → 특정 기능만 다른 프로젝트에서 쓸 수 없음
22 - 파일 분리 → math_utils.c, network.c 등 모듈별로 독립 재사용
23 - 표준 라이브러리(libc)가 좋은 예: 수백 개 .c 파일로 분리되어 어디서든 링크 가능
24How — 분리 컴파일의 핵심 원리
25- C의 빌드 과정: 소스(.c) → 컴파일 → 오브젝트(.o) → 링크 → 실행파일
26- 각 .c 파일은 독립적으로 .o로 컴파일된다
27- 핵심 가치: 변경된 파일만 재컴파일
28 • main.c 수정 → main.o만 다시 생성 → 나머지 .o는 그대로 재사용
29 • 이것을 자동화하는 도구가 make (Feldman, 1979)
30- 빌드 비교 (10개 파일, 각 1만 줄 기준):
31 • 단일 파일: 매번 10만 줄 전체 컴파일 → ~60초
32 • 멀티파일: 수정된 1만 줄만 컴파일 + 링크 → ~8초
33 • 빌드 시간 약 7~8배 단축
34실무 프로젝트 구조 예시
35- 일반적인 C 프로젝트 디렉토리:
36 • src/ — 소스 파일 (.c)
37 • include/ — 헤더 파일 (.h) — 인터페이스 선언
38 • lib/ — 외부 라이브러리
39 • tests/ — 테스트 코드
40 • Makefile — 빌드 규칙 정의
41- 이 구조가 주는 이점:
42 • 관심사 분리(Separation of Concerns) — 각 파일이 하나의 책임
43 • 캡슐화 — 구현 세부사항은 .c에 숨기고, 인터페이스만 .h로 공개
44 • 테스트 용이성 — 개별 모듈을 독립적으로 테스트 가능