---
id: moc-python
title: "Python — 학습 지도 (MOC)"
category: "MOC"
status: "active"
type: "map-of-content"
tags: ["MOC", "Python"]
updated_at: 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_