2What — 모듈과 패키지란?
3- 모듈(Module): 하나의 .py 파일. 함수, 클래스, 변수를 담는 독립 단위
4- 패키지(Package): 여러 모듈을 디렉토리로 묶은 구조. __init__.py가 패키지를 정의
5- PyPI: Python Package Index — 전 세계 개발자가 공유하는 패키지 저장소 (500,000+ 패키지)
6- 비유: 모듈은 한 권의 책, 패키지는 책장, PyPI는 도서관
7---
8Why — 단일 파일 스크립트의 세 가지 재앙
9코드가 수천 줄로 불어나면 세 가지 문제가 동시에 폭발한다:
101. 이름 충돌 (Name Collision)
11 - 같은 파일에 process_data라는 함수가 3개 → 마지막 정의만 살아남음
12 - 팀원 A와 B가 각각 config라는 변수를 정의 → 서로 덮어쓰기
13 - 모듈이 해결: 각 .py 파일이 독립된 네임스페이스를 제공 (van Rossum, 1991)
142. 코드 재사용 불가
15 - 유틸리티 함수를 복사-붙여넣기 → 버그 수정 시 모든 복사본을 찾아야 함
16 - DRY 원칙(Don't Repeat Yourself) 위반 (Hunt & Thomas, 1999)
17 - 모듈이 해결: import utils 한 줄로 어디서든 재사용
183. 팀 협업 불가
19 - 10명이 하나의 main.py를 동시 편집 → Git 충돌 폭발
20 - 누가 어떤 기능을 담당하는지 경계가 불분명
21 - 패키지가 해결: 기능별 디렉토리 분리 → 각자 독립 모듈 작업
22---
23Why — 모듈화가 해결하는 핵심 세 가지
24- 네임스페이스 분리: math.sqrt와 cmath.sqrt가 공존 — 같은 이름, 다른 기능
25- 코드 재사용: 한 번 작성 → import로 무한 재사용. 테스트·유지보수 한 곳에서
26- 의존성 명시: import문이 파일 상단에 모여 → 이 코드가 무엇에 의존하는지 한눈에 파악
27---
28How — 실제 대형 프로젝트의 모듈 구조
29- NumPy: ~1,600개 파일 — numpy.linalg, numpy.fft, numpy.random 등 기능별 하위 패키지
30- Django: ~2,000개 파일 — django.db, django.http, django.views 등 웹 프레임워크의 각 계층이 독립 패키지
31- FastAPI: 핵심 모듈 ~50개 + Starlette·Pydantic 의존 → 패키지 간 조합의 힘
32이들이 수백~수천 개 모듈로 나뉜 이유:
33- 한 모듈의 변경이 다른 모듈에 영향을 최소화 (낮은 결합도)
34- 관련 기능끼리 한 모듈에 모임 (높은 응집도)
35- Parnas의 모듈화 원칙: "정보 은닉을 통한 변경 용이성" (Parnas, 1972)
36---
37How — PyPI 500,000+ 패키지가 존재하는 이유
38- Python의 import 시스템이 표준화된 인터페이스를 제공
39- setup.py → pyproject.toml로 진화한 패키징 표준 (PEP 517, 2017)
40- pip install 패키지명 한 줄로 설치·의존성 자동 해결
41- 이 설계 철학: "Batteries included, but replaceable" — 기본 제공하되 교체 가능
42- 결과: 누구든 모듈을 만들고 공유할 수 있는 생태계 → 폭발적 성장
43---
44핵심 정리
45- 단일 파일의 한계: 이름 충돌 + 재사용 불가 + 협업 불가
46- 모듈 = 네임스페이스 + 재사용 단위 + 의존성 선언
47- 패키지 = 모듈의 계층적 조직 → 대규모 프로젝트의 필수 구조
48- Python의 모듈 시스템 설계가 PyPI 생태계 폭발의 기술적 토대