이 레슨과 관련된 학습 키워드
컴퓨터 과학 & 프로그래밍 — 문제 해결의 도구 → Python 프로그래밍 — 첫 코드에서 실전까지 → Python 프로그래밍 — 첫 코드에서 실전까지 → 중급
import 시스템, 패키지, venv, pip, pyproject.toml, 프로젝트 구조, 순환 임포트, 배포
.py 파일. 함수, 클래스, 변수를 담는 독립 단위__init__.py가 패키지를 정의process_data라는 함수가 3개 → 마지막 정의만 살아남음config라는 변수를 정의 → 서로 덮어쓰기.py 파일이 독립된 네임스페이스를 제공 (van Rossum, 1991)import utils 한 줄로 어디서든 재사용main.py를 동시 편집 → Git 충돌 폭발math.sqrt와 cmath.sqrt가 공존 — 같은 이름, 다른 기능import로 무한 재사용. 테스트·유지보수 한 곳에서import문이 파일 상단에 모여 → 이 코드가 무엇에 의존하는지 한눈에 파악numpy.linalg, numpy.fft, numpy.random 등 기능별 하위 패키지django.db, django.http, django.views 등 웹 프레임워크의 각 계층이 독립 패키지import 시스템이 표준화된 인터페이스를 제공setup.py → pyproject.toml로 진화한 패키징 표준 (PEP 517, 2017)pip install 패키지명 한 줄로 설치·의존성 자동 해결오늘은 모듈과 패키지가 왜 필요한지 살펴보겠습니다.
그림 상단을 보시면 핵심 흐름이 한눈에 보입니다.
단일 파일의 한계, 모듈화 해결, 생태계 폭발 순서죠.
먼저 기본 개념부터 정리해볼게요.
모듈은 하나의 .py 파일로, 함수와 클래스를 담는 단위예요.
패키지는 여러 모듈을 디렉토리로 묶은 구조입니다.
비유하면 모듈은 책 한 권, 패키지는 책장이에요.
파이피아이는 오십만 개 이상의 패키지를 모은 도서관이죠.
그럼 단일 파일이 왜 문제인지 볼게요.
코드가 수천 줄로 불어나면 세 가지 재앙이 찾아옵니다.
그림 왼쪽을 보시면 첫 번째, 이름 충돌입니다.
같은 파일에 동일 이름 함수가 세 개면 마지막만 살아남아요.
팀원 A와 B가 같은 변수명을 쓰면 서로 덮어씁니다.
그림 가운데를 보시면 두 번째 재앙, 코드 재사용 불가입니다.
유틸리티 함수를 복사해서 쓰면 버그 수정이 악몽이 됩니다.
헌트와 토마스의 DRY 원칙을 위반하는 거죠.
세 번째는 그림 오른쪽의 팀 협업 불가 문제예요.
열 명이 하나의 파일을 동시에 편집하면 깃 충돌이 폭발합니다.
기능 경계도 불분명해져 누가 뭘 담당하는지 알 수 없게 되죠.
모듈화가 이 세 가지 문제를 깔끔하게 해결합니다.
네임스페이스를 분리해 이름 충돌을 방지하고요.
math.sqrt와 cmath.sqrt는 이름이 같아도 충돌하지 않습니다.
import 한 줄로 코드를 어디서든 재사용할 수 있어요.
의존성도 파일 상단 import문으로 한눈에 확인할 수 있죠.
그림 아래쪽을 보시면 실제 대형 프로젝트 사례가 나옵니다.
넘파이는 약 천육백 개 파일로 기능별 하위 패키지가 분리돼 있어요.
장고는 약 이천 개 파일로 각 웹 계층이 독립 패키지를 이룹니다.
FastAPI는 핵심 모듈 오십 개에 외부 패키지를 조합한 경량 설계죠.
파르나스의 1972년 원칙대로 낮은 결합도와 높은 응집도를 지켰습니다.
낮은 결합도는 한 모듈 변경이 다른 모듈에 영향을 주지 않는 거예요.
높은 응집도는 관련 기능끼리 한 모듈에 모으는 원칙이고요.
파이썬의 import 설계가 파이피아이 생태계 폭발의 기술적 토대가 됐습니다.