If Dev Then ?

파이썬 팀의 ‘업데이트 루틴’이 실력을 만든다: FastAPI/uv/pandas를 다루는 현실적인 방식 업데이트를 미루는 팀에는 공통 장면이 있다. 처음엔 다들 합리적이다. “지금 바쁜데요.” “이번 스프린트 끝나고요.” “장애 나면 책임이…” 그러다 어느 날, 미루던 게 한꺼번에 온다. 프레임워크가 올라가고, 패키지 매니저가 바뀌고, 데이터 작업은 계속 늘어난다. 그때부터 생산성 얘기가 “누가 더 빨리 코드를 짜냐”가 아니라 “누가 덜 자주 되돌리냐”가 된다. 요즘 파이썬 팀에서 실력 차이를 만드는 건 선택 그 자체보다 루틴이다. FastAPI 같은 프레임워크 업데이트를 어떤 간격으로, 어떤 절차로 받아들이는지 uv 같은 도구를 ‘설치’가 아니라 ‘정착’시키는지 pandas DataFrame을 다룰 때 같은 실수를 반복하지 않게 팀이 어떤 최소 습관을 갖는지 오늘 글은 “최신이 최고” 같은 얘기가 아니다. 업데이트를 ‘언젠가’가 아니라 ‘정해진 루틴’으로 돌리는 법에 대한 메모다. FastAPI 업데이트를 ‘기능’이 아니라 ‘리스크’로 읽는 법 FastAPI 업데이트를 논할 때 대화가 자주 어긋난다. 한쪽은 “새 기능/버그 픽스니까 올리자”라고 하고, 다른 쪽은 “올리면 뭔가 깨질 것 같다”라고 한다. 둘 다 맞다. 그래서 실전에서는 질문을 바꾼다. “이번 업데이트는 기능이 추가됐나?”가 아니라 “이번 업데이트를 지금 올려도 될 만큼, 우리가 리스크를 통제할 수 있나?” 이 관점으로 보면, 릴리스 노트는 ‘새로운 장난감 목록’이 아니라 ‘검증 항목 목록’이 된다. 그리고 검증 항목은 팀의 현실을 드러낸다. 우리는 요청/응답 경계를 테스트로 잡고 있나? 의존성(특히 Pydantic/Starlette 쪽) 업데이트가 같이 들어올 때, 어디까지 자동으로 확인하나? 문서/스키마(OpenAPI) 출력이 바뀌면, 그걸 소비하는 다른 팀(프론트/파트너/QA)은 어떻게 확인하나? 마이너/패치...