파이썬
SQLAlchemy 2.0 #7 Alembic과 실전 구성: 마이그레이션, 비동기, 팀 규약
시리즈 마지막 편으로 운영 단계의 주제를 정리합니다. create_all이 스키마 변경을 해결하지 못하는 이유와 Alembic 도입, autogenerate가 감지하는 것과 놓치는 것, 마이그레이션 파일 리뷰 원칙, create_async_engine과 AsyncSession으로 넘어가는 비동기 구성과 지연 로딩 제약, 모델·세션·설정을 배치하는 프로젝트 구조, 팀에서 지킬 규약까지 다룹니다.
SQLAlchemy 2.0 #6 쿼리 심화: 조인, 집계, 서브쿼리, 대량 처리
select() 하나로 실전 쿼리를 조립하는 법을 정리합니다. scalars와 execute의 반환 형태 차이, 여러 조건과 or_, 조인과 명시적 ON 절, group_by와 집계 함수에 라벨을 붙여 읽는 법, 서브쿼리와 EXISTS, LIMIT·OFFSET 페이지네이션과 그 한계, ORM 단위 작업을 우회하는 대량 INSERT·UPDATE까지, 2.0 스타일 쿼리의 실무 레퍼토리를 다룹니다.
SQLAlchemy 2.0 #5 관계 매핑: 1:N, N:M, 그리고 N+1 문제
ORM의 꽃이자 함정인 relationship을 정리합니다. 외래 키와 relationship의 역할 분담, back_populates로 양방향을 잇는 1:N 선언, secondary 테이블을 쓰는 N:M, 부모 삭제 시 자식 처리를 정하는 cascade와 delete-orphan, 지연 로딩이 만들어 내는 N+1 문제를 echo 로그로 확인하는 법, selectinload와 joinedload로 해결하는 기준까지 다룹니다.
SQLAlchemy 2.0 #4 세션: 변경 추적, flush와 commit, 객체의 네 가지 상태
ORM의 심장인 Session을 정리합니다. 세션이 단위 작업(Unit of Work)으로 변경을 모았다가 한 번에 SQL로 내보내는 원리, flush와 commit의 차이, transient·pending·persistent·detached라는 객체의 네 가지 상태, 같은 행은 같은 객체로 돌려주는 identity map, commit 후 속성 접근이 다시 쿼리를 날리는 이유, 웹 애플리케이션에서 요청당 세션 하나라는 스코프 원칙까지 다룹니다.
SQLAlchemy 2.0 #3 ORM 모델 정의: DeclarativeBase, Mapped, mapped_column
테이블을 파이썬 클래스로 선언하는 2.0 스타일 ORM 모델 정의를 정리합니다. DeclarativeBase를 상속하는 구조, Mapped 타입 힌트와 mapped_column의 역할 분담, 파이썬 타입이 DB 타입으로 매핑되는 규칙, Optional과 nullable의 연동, 기본값·유니크·인덱스 선언, 제약 조건 이름을 자동으로 붙이는 네이밍 컨벤션까지 다룹니다.
SQLAlchemy 2.0 #2 엔진과 트랜잭션: 커넥션 풀, commit의 두 가지 패턴
SQLAlchemy의 토대인 엔진과 트랜잭션을 정리합니다. 커넥션 풀이 왜 필요하고 어떻게 동작하는지, pool_size와 max_overflow가 실제로 제한하는 것, connect()와 begin()으로 갈리는 commit-as-you-go와 begin-once 패턴, 트랜잭션이 자동 커밋되지 않는 이유, MetaData와 Table로 테이블을 정의하고 Core 표현식으로 CRUD를 실행하는 것까지 다룹니다.
SQLAlchemy 2.0 #1 전체 그림: Core와 ORM, 그리고 2.0 스타일
파이썬 DB 라이브러리의 사실상 표준인 SQLAlchemy를 바닥부터 정리하는 시리즈의 첫 편입니다. Core와 ORM이라는 두 층의 구조, 1.x 시절 코드와 2.0 스타일이 다른 이유, select() 중심으로 통일된 쿼리 방식과 타입 힌트 지원, 설치와 첫 연결, text()로 SQL을 직접 실행하는 것까지 다룹니다.
파이썬 패키징 #7 팀 규약과 도구 선택: uv, poetry, pip
시리즈 마지막 편으로, 도구 선택과 팀 규약을 정리합니다. uv, poetry, pip+venv를 한 표에 놓고 가르는 기준, 마이그레이션의 실제 비용, CI에서 캐싱과 frozen 검증을 거는 법, 도커 이미지에서 uv를 쓰는 표준 패턴, 새 팀원이 와도 무너지지 않는 팀 규약 체크리스트까지 다루고 시리즈 전체를 회고합니다.
파이썬 패키징 #6 배포: wheel 빌드와 PyPI 업로드
받는 쪽에서 만드는 쪽으로 방향을 바꿔, 내 코드를 설치 가능한 패키지로 만들어 올리는 워크플로를 정리합니다. src 레이아웃과 빌드 백엔드의 역할, sdist와 wheel의 차이, uv build로 빌드하고 TestPyPI에서 리허설한 뒤 PyPI에 올리는 순서, GitHub Actions의 Trusted Publishing으로 토큰 없이 배포하는 현대 표준, 사내 전용 배포 대안까지 다룹니다.
파이썬 패키징 #5 의존성 잠금: lock 파일과 재현성
선언과 잠금이 왜 분리되는지에서 시작해 uv.lock의 내용을 직접 읽습니다. 전이 의존성까지 전부 고정하는 해석 결과, 해시 검증이 막는 공급망 위험, CI에서 --frozen으로 잠금 그대로 재현하는 법, 업그레이드를 일상 업무로 만드는 전략, 도구 간 이동을 여는 표준 pylock.toml(PEP 751)까지 다룹니다.
파이썬 패키징 #4 uv: 2026년 표준 워크플로
가상 환경, 의존성 설치, lock, 파이썬 버전 관리를 한 도구로 묶은 uv의 일상 워크플로를 정리합니다. init·add·sync·run 네 명령이 앞 편들의 수작업을 대체하는 과정, 파이썬 인터프리터까지 uv가 설치하는 구조, uvx와 uv tool로 전역 도구를 격리 설치하는 법, 기존 requirements.txt 프로젝트를 흡수하는 마이그레이션까지 다룹니다.
파이썬 패키징 #3 pyproject.toml: 프로젝트 설정의 표준
setup.py와 흩어진 설정 파일들의 시대가 pyproject.toml 한 파일로 수렴한 과정을 정리합니다. project 테이블의 메타데이터와 의존성 선언, extras와 dependency-groups로 선택 의존성과 개발 의존성을 가르는 법, build-system의 역할, ruff와 pytest 설정까지 tool 테이블로 모으는 실전 구성을 다룹니다.