2nd/10_Wiki/Topics/Coding/Python/_MOC.md

id, title, category, status, type, tags, updated_at

id	title	category	status	type	tags	updated_at
moc-python	Python — 학습 지도 (MOC)	MOC	active	map-of-content	MOC Python	2026-06-08

🗺️ Python — 학습 지도 (MOC)

이 클러스터의 200개 문서에 대한 진입점과 학습 순서. 자동 생성(moc_generator.mjs) — 재실행 시 갱신.

🚀 여기서 시작 (Start here)

• 기본값 인자의 함정 — 작은 편의가 큰 공유 상태 버그로 이어질 수 있다.
• 데코레이터 기초 — 데코레이터는 문법 트릭이 아니라 반복 관심사를 묶는 도구다.
• 모듈과 import 시스템 기초 — import 구조는 단순 편의가 아니라 아키텍처 경계의 일부다.
• 예외 처리 기초 — 예외 처리는 숨기기보다 실패를 구조화하는 도구여야 한다.
• 컨텍스트 매니저 입문 — 정리 코드를 흩뿌리기보다 생명주기를 구문 안에 묶는 것이 안전하다.
• 파일 I/O 기본 패턴 — I/O는 데이터보다 경계와 자원 수명이 더 중요하다.
• 프로파일링 기초 — 느리다는 감상 대신 어디가 느린지 측정하는 습관이 중요하다.
• ast 기반 코드 조작 기초 — 코드를 텍스트보다 구조로 다루면 자동화의 수준이 달라진다.
• asyncio 기본기 — 비동기는 문법보다 실행 모델을 이해해야 안전하게 쓸 수 있다.
• hashlib와 해시 기초 — 해시는 보안 만능키가 아니라 목적에 맞는 도구 선택이 중요하다.
• Pandas 데이터 처리 기본기 — 데이터프레임은 편하지만, 변형 흐름이 흐려지면 디버깅이 어려워진다.
• pip 기본기와 의존성 관리 — 패키지 설치는 시작일 뿐, 버전 전략이 더 중요하다.
• pytest 기본기 — 좋은 테스트 도구는 코드보다 사고 방식을 바꾼다.
• Python 보안 기본기 — Python 보안은 프레임워크보다 경계와 신뢰 모델에서 시작된다.
• Python 성능 튜닝 기본기 — 튜닝은 감이 아니라 가장 큰 병목부터 제거하는 작업이다.
• SQLAlchemy ORM 기초 — ORM는 SQL을 없애는 도구가 아니라 데이터 경계를 추상화하는 도구다.
• threading 기본과 GIL — GIL은 'thread 쓸모없음'이 아니라 CPU와 I/O 경계 이해 문제다.
• typing 기본기 — 타입 힌트는 주석이 아니라 설계 의사소통 도구다.

📚 전체 문서 (Topics)

⚠️ 문서가 많은 클러스터(182개) — 첫 글자별로 묶음. 하위 폴더로 재구성 검토 권장.

A

• ABC와 Protocol — 계약을 어떻게 표현하느냐가 결합도를 좌우한다.
• Airflow와 워크플로 오케스트레이션 — 워크플로 도구는 코드보다 운영 책임과 관측성 기준이 중요하다.
• argparse로 CLI 만들기 — 작은 자동화 도구일수록 CLI 품질이 생산성을 좌우한다.
• args와 kwargs 실전 — 유연성은 좋지만, 지나치면 API 경계가 흐려진다.
• assert 설계와 메시지 — 실패 메시지는 미래의 자신과 동료를 위한 문서다.
• async 웹 크롤링 패턴 — 크롤링은 속도보다 대상 서비스와의 관계를 먼저 생각해야 한다.
• async context manager — 비동기 자원도 정리 규칙이 명확해야 누수와 좀비 연결을 막을 수 있다.
• async generator와 streaming API — 스트리밍은 데이터 형식보다 전달 리듬 설계가 중요하다.
• asyncio와 blocking 코드 섞기 — 한 줄의 blocking 호출이 전체 이벤트 루프를 멈출 수 있다.
• attrs와 dataclass 비교 — 도구 비교는 기능표보다 실제 모델링 요구로 봐야 한다.

B

• backpressure 개념과 Python 구현 — 처리량보다 흐름 제어를 이해하는 순간 시스템 안정성이 올라간다.
• BeautifulSoup와 HTML 파싱 — 웹 문서는 구조가 더럽기 때문에 파서는 관용적이어야 한다.
• benchmarking과 pyperf — 성능 수치는 재현 가능한 측정 문맥과 함께 읽어야 한다.
• black과 코드 포맷팅 — 스타일 논쟁을 줄이면 더 중요한 설계 논의에 시간을 쓸 수 있다.
• bytes와 binary data 처리 — 텍스트와 바이너리를 분리해 생각하면 데이터 처리 사고가 훨씬 선명해진다.

C

• cancelation 설계 — 취소는 예외 상황이 아니라 기본 흐름으로 설계해야 한다.
• Celery와 작업 큐 — 비동기 업무 분리는 실행 모델과 장애 모델을 함께 설계해야 한다.
• CI에서 Python 테스트 실행 — 로컬에서만 통하는 파이프라인은 자동화가 아니라 착각이다.
• Click과 Typer로 CLI 앱 만들기 — 도구성 앱일수록 사용자 경험은 CLI 설계에 크게 좌우된다.
• collections 모듈 핵심 — 표준 라이브러리 작은 도구를 알면 코드가 훨씬 또렷해진다.
• concurrent.futures 실전 — 풀 기반 병렬 처리는 편하지만 작업 크기와 직렬화 비용을 봐야 한다.
• contextlib 고급 패턴 — 자원 생명주기 조합은 contextlib를 알수록 훨씬 안전해진다.
• copy와 deepcopy — 복사는 값 복제가 아니라 관계 복제 문제로 봐야 한다.
• coroutine과 await 의미론 — await 한 줄이 제어 흐름을 넘기는 지점이라는 감각이 중요하다.
• coverage 해석 — coverage는 지도이지 목적지가 아니다.
• csv와 구조적 텍스트 처리 — 간단한 표 형식도 경계 조건을 무시하면 쉽게 깨진다.

D

• dataclass 고급 옵션 — dataclass는 편의 기능이지만 도메인 모델 설계 의도를 먼저 세워야 한다.
• dataclass와 타입 힌트 조합 — 모델 정의는 간결하되 의미는 선명해야 한다.
• datetime과 시간대 처리 — 시간 문제는 항상 언젠가 터지므로 초기에 기준을 세워야 한다.
• decimal과 금융 계산 — 정확도 요구가 높은 도메인에서는 숫자 타입이 곧 설계다.
• deque와 queue 패턴 — list로 억지 구현하기보다 목적에 맞는 구조를 쓰는 것이 Python답다.
• descriptor protocol — Python 객체 모델의 핵심 마법은 descriptor를 이해할 때 비로소 열린다.
• dict 내부 모델과 해시 기반 사고 — dict를 잘 이해하면 Python 데이터 구조 전반이 더 선명해진다.
• Django의 강점과 한계 — 배터리 포함 프레임워크는 생산성과 제약을 함께 가져온다.
• Docker로 Python 앱 배포 — 이미지 크기보다 재현성과 시작 속도, 보안 경계를 함께 봐야 한다.
• doctest 활용 기준 — 예제 문서가 실제로 실행된다는 사실은 큰 신뢰 자산이 된다.
• dunder methods와 연산자 오버로딩 — 연산자 오버로딩은 멋짐보다 직관성과 기대 일치를 먼저 봐야 한다.

E

• editable install과 개발 편의 — 로컬 패키지 개발 경험을 잘 설계하면 리팩토링 비용이 줄어든다.
• Enum과 상수 모델링 — 매직 문자열을 줄이는 것만으로도 도메인 버그가 많이 줄어든다.
• enumerate, zip, unpacking — 반복 제어를 간결하게 만들수록 로직이 더 잘 보인다.

F

• FastAPI 구조 설계 — 프레임워크보다 라우팅, 서비스, 스키마 경계 설계가 더 중요하다.
• fixture 설계 — fixture는 편의 기능이 아니라 테스트 의존성 모델이다.
• flaky test 줄이기 — 신뢰할 수 없는 테스트는 없는 테스트만큼 위험하다.
• Flask와 마이크로 프레임워크 사고 — 작다고 단순한 것은 아니며, 선택한 만큼 구조 책임이 커진다.
• fractions와 유리수 표현 — 문제에 맞는 수 표현을 쓰면 복잡한 보정 코드를 줄일 수 있다.
• functools 실전 — 함수 유틸은 작지만 설계 감각을 크게 바꿀 수 있다.
• functools.wraps와 메타데이터 보존 — 작은 메타데이터 보존이 디버깅과 문서화를 크게 돕는다.

G

• generator 함수 설계 — 제너레이터는 메모리 절약뿐 아니라 처리 파이프라인 사고를 열어준다.
• Generic 타입 설계 — 제네릭은 재사용성을 높이지만 복잡도 비용도 함께 온다.
• glob와 파일 패턴 검색 — 파일 시스템 탐색도 표현 방식이 분명해야 버그가 줄어든다.

I

• if와 match 문 선택 기준 — 분기 구조가 복잡해질수록 표현 방식 자체가 설계 품질이 된다.
• introspection과 inspect 모듈 — 동적 언어의 힘은 introspection에서 오지만, 과용은 복잡도를 부른다.
• isort와 import 정렬 — 작은 일관성도 코드 리뷰 피로를 크게 낮춘다.
• iterator protocol 깊게 보기 — iterator protocol은 Python 컬렉션과 lazy 처리의 공통 뼈대다.
• itertools 사고법 — 반복 로직은 직접 구현보다 조합하는 쪽이 더 안전할 때가 많다.

J

• json 처리와 직렬화 기준 — 직렬화는 데이터 구조를 외부 세계와 약속하는 행위다.
• Jupyter 노트북 운영 규칙 — 탐색 도구와 생산 코드 경계를 명확히 해야 혼란이 줄어든다.

L

• list, tuple, set, dict 선택 기준 — 자료구조 선택 하나가 코드 성격을 바꿀 수 있다.
• Literal과 제한된 값 모델링 — 문자열 상수를 타입으로 끌어올리면 많은 실수를 미리 막을 수 있다.
• logging 기반 디버깅 — 디버깅은 출력이 아니라 질문을 남기는 로그에서 시작된다.
• logging 표준 패턴 — print에서 logging으로 넘어가는 순간 운영 관측성이 달라진다.

M

• mock와 monkeypatch — mock는 빠른 해결책이지만 설계 냄새를 감추는 도구가 되기 쉽다.
• multiprocessing와 프로세스 병렬 — CPU 병렬은 늘 이득이 아니라 데이터 이동 비용과의 싸움이다.
• mutation testing in Python — 테스트가 있는 것과 강한 것은 다르다.
• mypy 운영 전략 — 타입 도입은 기술 문제이자 팀 운영 문제다.

N

• namedtuple과 dataclass 비교 — 가벼운 구조체 선택도 변경 가능성 기준으로 봐야 한다.
• NewType로 도메인 경계 강화 — 숫자와 문자열이 같아 보여도 도메인 의미는 다를 수 있다.
• NumPy 배열 사고 — NumPy는 반복문을 없애는 기술이 아니라 데이터 형태를 바꾸는 사고다.

O

• operator 모듈 — 작은 표준 함수들이 key extraction과 조합 코드를 더 읽기 쉽게 만든다.
• Optional과 Union 판단 — None이 끼는 순간 API 경계가 더 중요한 설계 문제가 된다.

P

• parameterized tests — 반복 테스트는 복붙보다 데이터 구조로 표현할 때 더 읽기 쉽다.
• ParamSpec과 Callable 모델링 — 함수를 감싸는 순간 타입 정보 보존이 설계 품질이 된다.
• partial과 함수 조합 — 반복 인자를 고정하는 작은 추상화가 API 가독성을 크게 높인다.
• pathlib 깊게 쓰기 — 경로 연산을 문자열 덧붙이기로 처리하는 습관에서 빨리 벗어나는 게 좋다.
• pathlib 중심 파일 시스템 다루기 — 경로는 문자열이 아니라 경로 객체로 다룰 때 실수가 줄어든다.
• pdb와 디버거 사용법 — 멈춰서 보는 감각이 생기면 추측성 디버깅이 줄어든다.
• pickle 직렬화 위험과 활용 — 편리한 직렬화일수록 신뢰 경계를 엄격히 봐야 한다.
• pip-tools와 잠금 자동화 — 간단한 도구 하나로 업데이트 통제가 훨씬 쉬워질 수 있다.
• poetry와 uv 선택 기준 — 도구 전쟁보다 팀 속도와 재현성 요구를 먼저 봐야 한다.
• Polars와 현대 데이터프레임 — 도구 비교는 유행보다 데이터 크기와 팀 익숙함을 먼저 봐야 한다.
• pre-commit과 품질 게이트 — 작은 자동화가 코드베이스 일관성을 지켜준다.
• property-based testing with Hypothesis — 예시보다 규칙을 테스트하면 더 넓은 버그 공간을 만날 수 있다.
• property와 검증 로직 — 단순 getter/setter보다 도메인 규칙 노출 방식이 더 중요하다.
• Protocol 기반 구조적 타이핑 — 상속 없이도 계약을 표현할 수 있다는 점이 Python 타입 시스템의 큰 장점이다.
• Pydantic 모델 설계 — 검증 모델과 도메인 모델을 섞지 않는 감각이 중요하다.
• pyproject.toml 현대 표준 — 설정의 중심을 한곳에 두면 도구 통합과 재현성이 좋아진다.
• pyright와 타입 검사 도구 비교 — 도구 선택은 기능보다 팀 속도와 피드백 루프를 봐야 한다.
• Python 관측 가능성 — 운영 가능한 코드는 동작하는 코드보다 한 단계 더 멀리 간다.
• Python 데이터 파이프라인 설계 — 데이터 흐름은 코드보다 재현성과 실패 복구 전략이 중요하다.
• Python 머신러닝 스크립트 운영 — 모델보다 데이터 버전, 설정, 재현성이 더 큰 운영 문제를 만든다.
• Python 실행 모델과 인터프리터 이해 — 실행 모델을 알면 성능과 디버깅 판단이 훨씬 쉬워진다.
• Python 에이전트 도구 통합 — 에이전트 품질은 모델보다 도구 경계와 상태 관리에서 많이 갈린다.
• Python 자동화 스크립트 설계 — 짧은 스크립트일수록 예외 처리와 idempotency가 중요하다.
• Python 철학과 The Zen of Python — Python다운 코드는 문법 암기보다 철학 이해에서 시작된다.
• Python 캐싱 전략 — 캐시는 빠르게 만들지만, 무효화 설계 없이는 버그도 빠르게 만든다.
• Python 코딩 운영 체계 — Python 실력은 개별 문법보다 전체 워크플로우를 연결하는 능력에서 완성된다.
• Python 프로젝트 아키텍처 패턴 — Python 프로젝트의 혼란은 대개 경계보다 파일 수부터 늘릴 때 시작된다.
• Python 플러그인 시스템 — 확장성을 원한다면 코어와 플러그인의 계약을 먼저 설계해야 한다.
• Python API rate limiting — 부하 제어는 성능 기능이 아니라 신뢰성 기능이다.
• Python ETL 품질 기준 — ETL은 동작만 하면 되는 스크립트가 아니라 신뢰성이 필요한 시스템이다.
• Python monorepo 전략 — 저장소 구조는 협업 속도와 의존성 건강도를 함께 좌우한다.
• Python package as app 설계 — 앱은 사용자 경험과 운영 수명주기를 같이 설계해야 한다.
• Python package as library 설계 — 내부 코드와 공개 라이브러리는 수정 자유도의 철학이 다르다.
• Python RAG 파이프라인 구조 — RAG는 단순한 호출 체인이 아니라 데이터 품질 문제이기도 하다.
• Python과 메시지 큐 — 비동기 메시징은 느슨한 결합과 새로운 장애 모델을 동시에 가져온다.
• Python과 시스템 스크립팅 — 시스템 스크립트일수록 보수성과 안전장치가 더 중요하다.
• Python과 LLM 애플리케이션 — AI 앱에서도 결국 중요한 건 모델보다 경계, 비용, 검증 루프다.
• Python과 WebAssembly 가능성 — 새 배포 환경은 매력적이지만 실행 모델과 패키지 제약을 먼저 봐야 한다.
• Python에서 C 확장과 FFI — 성능 최적화는 언어를 바꾸는 결정을 포함할 때가 있다.
• Python에서 OpenTelemetry — 성능과 장애는 개별 서비스보다 호출 체인에서 봐야 한다.
• Pythonic 코드를 읽는 법 — Pythonic은 유행어가 아니라 의도와 가독성의 균형 감각이다.

Q

• Queue 기반 producer-consumer — 파이프라인은 순서보다 흐름과 압력 제어를 봐야 한다.

R

• random과 난수 제어 — 난수도 목적에 따라 테스트용, 시뮬레이션용, 보안용을 나눠야 한다.
• re와 정규표현식 실전 — regex는 강력하지만 읽기 비용을 관리해야 한다.
• requests와 httpx 비교 — 네트워크 호출은 문법보다 timeout, retry, observability가 중요하다.
• requirements.txt와 constraints.txt — 의존성 명세를 나누면 업데이트 리스크를 더 잘 통제할 수 있다.
• ruff modern linting — 도구가 빨라질수록 규칙은 더 일상적인 피드백 루프로 들어온다.

S

• secrets와 보안 난수 — 편한 난수와 안전한 난수는 다르다.
• Self 타입과 fluent API — 타입 시스템이 자기 반환 API를 이해하면 리팩토링이 쉬워진다.
• Semaphore와 동시성 제한 — 빠름보다 시스템을 무너뜨리지 않는 속도가 중요하다.
• set 활용 패턴 — set는 단순한 자료형이 아니라 의도를 드러내는 강한 표현이다.
• setuptools와 build backend — 패키징 도구 선택은 메타데이터, 빌드, 배포 흐름을 같이 봐야 한다.
• shutil과 파일 작업 — 표준 도구를 쓰면 운영체제 차이와 예외 처리 부담을 줄일 수 있다.
• signal 처리와 graceful shutdown — 종료 품질은 운영 시스템의 성숙도를 보여준다.
• singledispatch와 다형 함수 — 클래스 계층 없이도 함수 단위 확장성을 만들 수 있다.
• snapshot testing 신중하게 쓰기 — 빠른 회귀 방지가 곧 의미 있는 테스트는 아니다.
• staticmethod, classmethod, instance method — 메서드 종류는 문법이 아니라 책임 배치 문제다.
• statistics 모듈 — 작은 분석까지 무조건 pandas로 갈 필요는 없다.
• structlog와 구조적 로깅 — 운영 로그는 문자열보다 질의 가능한 이벤트에 가까워야 한다.
• subprocess 안전하게 쓰기 — 쉘 호출은 강력하지만 경계와 입력 신뢰도를 엄격히 봐야 한다.

T

• Task 생성과 관리 — 태스크는 만들기보다 수명과 실패 전파를 관리하는 것이 더 어렵다.
• tempfile과 안전한 임시 파일 — 임시 자원은 편하지만 수명과 정리 정책을 놓치기 쉽다.
• timeout과 경계 제어 — 무한 대기는 종종 가장 비싼 운영 버그다.
• tox와 nox 기반 테스트 매트릭스 — 환경 차이를 초기에 잡아야 배포 후 놀라지 않는다.
• trio와 anyio 관점 — API 차이보다 취소 모델과 구조적 동시성 철학이 더 중요하다.
• TypeAlias와 의미 있는 타입 이름 — 좋은 타입 이름 하나가 문서 여러 줄을 대신할 수 있다.
• TypedDict와 dict 스키마 — 느슨한 dict도 경계에서 스키마를 가지면 협업 비용이 크게 줄어든다.

U

• uuid와 식별자 생성 — 식별자는 데이터 모델과 운영 추적의 핵심 연결점이다.

V

• venv와 환경 격리 — 재현성 없는 Python 환경은 작은 프로젝트도 불안정하게 만든다.

W

• weakref와 객체 수명 — 객체를 오래 붙잡는 실수는 캐시와 이벤트 시스템에서 자주 생긴다.
• wheel과 sdist 이해 — 배포 포맷을 이해하면 설치 문제를 더 빠르게 진단할 수 있다.

Y

• yield from과 위임 — 반복 로직 합성은 작은 위임 문법 하나로 훨씬 깔끔해질 수 있다.

Z

• zoneinfo 현대적 사용법 — 로컬 시간과 UTC 경계를 모호하게 두면 데이터 일관성이 무너진다.

가나다

• 공개 API 타입 안정성 — 공개 API의 타입 품질은 사용자 경험의 일부다.
• 구조적 동시성 — 태스크를 던져놓기보다 수명을 구조화해야 예측 가능성이 생긴다.
• 람다와 작은 함수 선택 기준 — 짧음과 명확함은 다르며, lambda는 용도가 분명할 때만 강하다.
• 런타임 검증과 pydantic — 타입 힌트만으로 외부 입력을 믿으면 경계에서 깨진다.
• 리스트 컴프리헨션 — 짧다고 항상 좋은 것이 아니라, 의도가 선명할 때만 컴프리헨션이 빛난다.
• 메모리 프로파일링 — 속도보다 메모리로 먼저 무너지는 시스템도 많다.
• 메모리 효율적인 데이터 처리 — 큰 데이터를 다룰 때는 전체 로드보다 흐름 처리 사고가 중요하다.
• 메타클래스 언제 쓰는가 — 메타클래스는 마지막 수단에 가까우며, 목적이 분명해야 한다.
• 문서화와 타입의 관계 — 타입만으로 전달되지 않는 의도는 문서가 채워야 한다.
• 문자열 모델과 유니코드 — 문자열 버그는 문법보다 인코딩 경계에서 많이 터진다.
• 반복문과 순회 철학 — Python 루프는 카운터보다 iterable 중심 사고로 볼 때 더 강력하다.
• 배포 아티팩트와 릴리스 운영 — 패키지 배포는 파일 업로드가 아니라 변경 책임의 전달이다.
• 버전 관리와 semantic versioning — 버전은 숫자가 아니라 사용자와의 약속이다.
• 변수 바인딩과 이름 해석 — Python에서는 값보다 객체와 이름의 관계를 먼저 이해해야 한다.
• 불변과 가변 객체 — 상태 버그의 상당수는 가변성 경계를 흐리게 두는 데서 시작된다.
• 비교 연산과 truthiness — Python의 truthiness를 제대로 이해하면 조건문 버그를 많이 줄일 수 있다.
• 비동기 디버깅 — 비동기 버그는 코드보다 타이밍과 상태 전이를 봐야 잡힌다.
• 숫자 타입과 연산 규칙 — 숫자 타입 선택은 정확성과 성능, 도메인 요구를 함께 본다.
• 스코프와 LEGB 규칙 — 클로저와 전역 상태 문제는 LEGB를 선명히 이해하면 많이 줄어든다.
• 슬라이싱과 시퀀스 사고 — 슬라이싱은 편하지만 복사와 뷰의 차이를 모르면 비용을 놓치기 쉽다.
• 에러 재현 최소화 — 좋은 재현 케이스 하나가 긴 추측보다 훨씬 강하다.
• 웹소켓 서버의 비동기 패턴 — 실시간 서버는 연결 수명과 fan-out 비용을 항상 같이 봐야 한다.
• 의존성 잠금 전략 — 같은 requirements라도 잠금 전략이 없으면 같은 환경이 아니다.
• 재귀와 반복 선택 기준 — 우아함보다 종료 조건과 디버깅 가능성을 먼저 봐야 한다.
• 정렬과 key 함수 — 정렬 전략은 비교보다 key 추출로 단순화할 때 읽기 쉬워진다.
• 제너레이터 표현식 — 메모리 효율은 종종 eager보다 lazy 사고에서 나온다.
• 클래스 데코레이터 — 클래스 데코레이터는 메타클래스보다 가벼운 대안이 될 수 있다.
• 클로저와 nonlocal — 작은 상태 캡슐화는 클래스보다 클로저가 더 적합할 때가 있다.
• 타입 기반 리팩토링 — 좋은 타입은 변경을 막는 족쇄가 아니라 변경을 돕는 지도다.
• 타입 힌트 성능 오해 바로잡기 — 타입 힌트는 주로 개발 생산성 자산이지 성능 기능이 아니다.
• 테스트 데이터 전략 — 테스트 데이터가 지저분하면 테스트 설계도 흔들린다.
• 테스트 코드에도 타입을 붙일 것인가 — 모든 곳에 같은 엄격도를 강요하기보다 효율적인 범위를 정해야 한다.
• 통합 테스트 경계 설계 — 현실과 닿는 테스트가 있어야 자신감 있는 배포가 가능하다.
• 패키지 구조 설계 src layout — 패키지 구조는 테스트/배포 오류를 미리 예방하는 아키텍처 장치다.
• 함수 시그니처 설계 — 좋은 함수 시그니처는 문서 절반을 대신한다.
• 함수는 일급 객체다 — 함수가 값이라는 감각을 가지면 콜백, 데코레이터, 전략 패턴이 자연스러워진다.
• 환경 변수와 설정 관리 — 설정은 코드 바깥에 있지만 품질과 운영의 핵심이다.

기타

• [[__new__와 init 차이]] — 생성자 로직을 나눠 이해하면 불변 객체와 팩토리 설계가 쉬워진다.
• __slots__와 메모리 최적화 — 메모리 최적화는 측정 기반이어야 하고 가독성 비용과 같이 봐야 한다.

200 docs · 자동 생성 2026-06-08