__init__.py로 공개 API를 고정하는 법: 파이썬 코드리뷰에서 제일 먼저 합의할 한 가지 패키지가 커지면, 실력 좋은 팀도 똑같은 데서 늦어진다. 기능이 복잡해져서가 아니라, import가 길어지고, import가 길어지면 코드리뷰가 길어진다. 리뷰 화면에서 from app.domain.user.handlers.signup import do_the_thing 같은 줄을 볼 때마다, 나는 기능 구현보다 “이 이름이 밖에서 보이는 이름이 되어도 괜찮나?”를 먼저 떠올린다. 밖에서 보이는 이름이 늘면, 유지보수는 늘어난다. 심지어 좋은 리팩터링도 “다 깨질까 봐” 못 하게 된다. 그래서 이 글은 여러 규칙을 이야기하지 않는다. 한 가지만 이야기한다. 패키지의 공개 API를 __init__.py 에서 고정하자. 그걸로 끝이다. 나머지는 팀 취향이다. 왜 하필 __init__.py인가: import 동선을 “짧고 일정하게” 만들기 __init__.py 는 파이썬 패키지의 얼굴이다. 어떤 팀은 여기를 비워두고, 어떤 팀은 여기서 이것저것 다 한다. 둘 다 가능하다. 문제는 “가능하다”와 “지속 가능하다”가 다르다는 점이다. 패키지가 작을 때는 누가 어디서 무엇을 import하든 큰 문제가 없다. 파일 하나 옮기면 IDE가 알아서 고쳐주기도 하고, 깨져도 금방 고친다. 그런데 패키지가 커지고, 기능이 늘고, 사람이 바뀌면 import 동선이 팀의 습관이 된다. 동네 팀에서 자주 보이는 패턴이 이거다. 처음엔 “그냥 여기에서 가져오면 되겠지”로 깊은 경로를 import한다. 다음엔 비슷한 코드를 다른 디렉터리에 또 만든다. 어느 날 파일을 정리하려고 옮기면, 생각보다 많은 곳이 깨진다. 깨진 걸 고치면서 “그냥 옮기지 말자”가 팀의 결론이 된다. 이때부터 코드리뷰는 “좋은 구조로 정리하는 시간”이 아니라 “깨질까 봐 확인하는 시간”이 된다. __init__.py 로 공개 API를 고정하면, ...
Django 보안 릴리스가 뜬 날의 운영자 플레이북: 파이썬 팀이 덜 망가지는 업데이트 처리 그날은 알림이 먼저 울렸다. “Django security releases issued…” 아침에 커피 내리는 손으로 슬랙을 열었다가, 나는 바로 닫았다. 슬랙을 열면 사람의 말이 먼저 들어온다. “지금 배포 가능해요?” “오늘 일정 빡센데요.” “이거 진짜 위험한 건가요?” 보안 릴리스 날에는 감정이 먼저 움직인다. 그리고 감정이 먼저 움직이면, 결정은 흔들린다. 나는 운영자 모드로 스스로를 잠깐 고정한다. 이건 루틴 글을 쓰겠다는 얘기가 아니다. 그날은 루틴이 아니라 사건처럼 굴러간다. 보안 릴리스는 늘 “오늘의 변경”이 되어야 하고, 오늘의 변경은 누군가가 책임을 가져야 한다. 이 글은 그 하루를 어떻게 지나가는지, 내가 실제로 하는 순서(그리고 일부러 하지 않는 것들)를 기록한 플레이북이다. FastAPI나 uv, 새로운 런타임 실험 같은 이야기들은 그날의 배경으로만 짧게 스친다. 오늘 할 일과 섞이지 않게, 일부러 바깥에 둔다. 제일 먼저 하는 건 ‘패닉 방지’가 아니라 범위 고정 보안 릴리스가 뜨면 팀은 두 종류로 갈린다. “보안이면 무조건 당장 올리자” “그거 올렸다가 또 깨지면 누가 책임져요” 이 둘은 싸우는 게 아니라 서로 다른 위험을 보고 있는 거다. 전자는 ‘미적용 위험’을, 후자는 ‘적용 위험’을 본다. 그래서 제일 먼저 해야 할 일은 “우리가 오늘 무엇을 바꾸는지”를 아주 작게 고정하는 것이다. 그날의 범위는 이렇게 정한다. 애플리케이션 로직은 손대지 않는다. 의존성은 보안 릴리스가 요구하는 프레임워크 패치만 올린다. 테스트는 ‘핵심 사용 경로’만 확실히 돈다. 모든 걸 다 돌리는 날이 아니라, 오늘 살아남는 날이다. 이런 결정을 멋있게 포장하면 안 된다. 현실은 이렇다. 그날도 CI 러너가 묘하게 밀려서, “전체 테스트 한 번 돌리고 마음 편해지자”를 눌렀다가 10분을...