Ruff 0.6, 노트북 린팅(linting) 안정화 및 새로운 SDK 출시

이번 주의 릴리스는 두 가지 테마로 깔끔하게 나뉩니다. 하나는 Python 툴링이 더 조용해지는 것(Ruff가 바로 작동하는 기본 설정을 출시함)이고, 다른 하나는 멀티모달(multimodal) 모델 환경이 더 시끄러워지는 것입니다(NVIDIA와 Microsoft가 같은 주에 모두 프로덕션 준비가 된 옴니모달(omnimodal) 시스템을 출시함). 여기에 Kotlin ADK, Swift 분산 워크플로우 SDK, 그리고 두 개의 도구 카테고리를 추가로 흡수한 Biome까지 더해지면, 지루한 인프라 업그레이드가 화려한 모델 출시만큼이나 중요한 한 주가 됩니다.

Ruff v0.6.0, 노트북 린팅(linting) 안정화 및 규칙 제거

Ruff 0.6은 Jupyter 노트북 린팅(linting)을 일급 기본 기능(first-class default)으로 만듭니다. 이전에는 extend-include = ["*.ipynb"]를 통해 직접 선택해야 했지만, 이제는 설정을 건드리지 않아도 노트북이 자동으로 린팅(linting)됩니다. 세 가지 규칙은 완전히 폐기(deprecated)되었으며, pylint에서 파생된 아홉 가지 규칙이 프리뷰(preview) 단계에서 안정(stable) 단계로 승격되었습니다.

가장 주의해야 할 부분은 pytest 데코레이터(decorator) 규칙인 PT001과 PT023입니다. 이제 이 규칙들은 공식 pytest 문서에서 권장하는 스타일을 강제하므로, 데코레이터 스타일이 혼재된 기존 코드베이스에서는 새로운 위반 사항이 나타날 수 있습니다. 해결 방법은 기계적입니다. ruff check . --fix --select=PT001 --select=PT023을 실행하고 차이점(diff)을 검토하세요. 또한 확인해 볼 가치가 있는 점은, src/ 레이아웃 프로젝트의 경우 이제 첫 번째 파티 임포트(first-party imports)를 해결할 때 해당 디렉토리를 기본적으로 검색하게 되며, 이는 isort 동작을 조용히 변경할 수 있습니다.

판결: 출시(Ship). 대부분의 프로젝트에 즉시 적용 가능한 업그레이드입니다. 먼저 PT001/PT023 수정 패스를 실행하고, isort 출력이 임포트 블록에서 변경되지 않았는지 확인한 다음 머지(merge)하세요.

Ruff v0.8.0, Python 3.9을 기본값으로 설정

Ruff 0.8은 암시적인 target-version을 py38에서 py39로 올립니다. 만약 pyproject.toml에 requires-python을 설정하지 않았거나 [tool.ruff]에 target-version을 설정하지 않았다면, 다음 실행 시 포맷팅(formatting) 및 린팅(linting) 변경 사항을 보게 될 것입니다. 괄호로 묶인 with 문, 재정렬된 임포트(import), 그리고 어제까지는 깨끗했던 코드에 대한 새로운 규칙 위반 사항 등이 나타날 수 있습니다.

이러한 변화는 CI(지속적 통합) 환경에서 예상치 못한 diff(차이점)로 나타나는 일종의 조용한 기본값 변경(silent default change)입니다. 해결 방법은 어느 쪽이든 한 줄이면 됩니다. 현재 동작을 유지하려면 [tool.ruff] 아래에 target-version = "py38"을 추가하거나, [project]에 requires-python = ">= 3.9"를 선언하여 새로운 포맷팅 기준을 수용하면 됩니다. 후자가 현재 대부분의 코드베이스에 있어 장기적으로 올바른 선택입니다.

판결: 출시하되, 업그레이드하기 전에 버전을 명시적으로 고정(pin)하세요. 이미 열려 있는 브랜치에 이 변경 사항이 반영되게 하지 마세요. 포맷팅 차이(delta)가 diff를 오염시킬 것입니다.

Biome v2.4, CSS 및 GraphQL 린팅(linting) 내장

Biome은 이제 experimentalEmbeddedSnippetsEnabled 플래그를 통해 CSS-in-JS 템플릿 리터럴(styled-components)과 GraphQL 태그를 네이티브 방식으로 포맷팅하고 린팅합니다. 이를 통해 다중 언어(polyglot) JS 파일이 통상적으로 요구하던 별도의 prettier-plugin-graphql 및 stylelint 단계를 제거할 수 있습니다. 이번 릴리스에는 HTML 접근성(a11y) 규칙과 개선된 Vue/Svelte 파서(parser) 정확도가 포함되어, 컴포넌트 중심의 리포지토리에서 발생하는 오탐(false positives)을 줄여줍니다.

마이그레이션 경로는 간단합니다. 2.4.0으로 업그레이드하고, biome migrate --write를 실행한 뒤, biome.json에 실험적 플래그를 추가하면 됩니다. 내장 스니펫(embedded snippets) 기능은 실험적(experimental) 단계로 표시되어 있지만, 기반이 되는 CSS 및 GraphQL 포맷터는 안정적입니다. 따라서 위험 범위는 좁습니다.

판결: CSS-in-JS 팀에게 출시를 권장합니다. 만약 styled-components나 graphql-tag 코드베이스를 유지 관리하며 현재 여러 개의 포맷터를 실행 중이라면, 지금 마이그레이션 비용을 들여 통합할 가치가 있습니다. HTML 지원은 실험적이므로 검토 단계로 취급하세요.

Temporal Swift SDK, 이제 분산 워크플로(distributed workflows) 처리 가능

Temporal Swift SDK는 네이티브 Swift 서비스에 내구성이 있는 워크플로 실행(durable workflow execution) 기능을 가져옵니다. 워크플로 로직을 일반적인 async/await Swift 함수로 정의하면, Temporal이 재시도(retries), 상태 지속성(state persistence), 그리고 부분적 실패로부터의 복구(recovery)를 자동으로 처리합니다. 직접 만든 재시도 루프, 외부 상태 머신(state machines), 또는 커스텀 체크포인트(checkpoint) 로직이 필요 없습니다.

여기서의 실질적인 목표는 결제 처리, 데이터 파이프라인 등 시퀀스 중간의 부분적 실패(partial failure)를 수동으로 디버깅하고 복구하는 데 비용이 많이 드는 프로덕션 백엔드 서비스(production backend services)입니다. SDK를 사용하려면 실행 중인 Temporal 서버(자체 호스팅 또는 Temporal Cloud)와 async/await에 대한 숙련도가 필요하지만, 이미 Swift 백엔드 서비스를 구축하고 있다면 이 두 가지 모두 높은 장벽은 아닙니다.

결론: 여러 단계의 작업(multi-step operations)을 수행하는 Swift 서버를 운영 중인지 평가하십시오. 이는 실제 아키텍처의 복잡성을 대체해 줍니다. 만약 아직 Temporal 인프라를 갖추고 있지 않다면, 그 설정 비용을 고려하십시오. 신규 서비스(greenfield service)에게는 사소한 일이 아니겠지만, 분산 조정(distributed coordination)이 반복적인 문제라면 그만한 가치가 있습니다.

NVIDIA Cosmos 3 및 Microsoft MAI 모델 출시

두 가지 서로 다른 멀티모달(multimodal) 전략이 같은 주에 출시되었습니다. NVIDIA의 Cosmos 3는 텍스트, 이미지, 비디오, 오디오 및 액션(actions)을 처리하는 단일 오픈 옴니모달(omnimodal) 모델입니다. 이는 별도의 추론 엔드포인트(inference endpoints)를 하나로 묶을 필요 없이 하나의 모델이 여러 모달리티(modalities)를 처리하기를 원하는 물리적 AI 시스템 및 로보틱스 파이프라인을 겨냥하고 있습니다. 반면 Microsoft의 MAI 모델은 정반대의 접근 방식을 취합니다. 모달리티별 특화된 프로덕션 모델(이미지 편집, 음성, 전사)로서 현재 Azure AI Foundry, Fireworks AI, Baseten, OpenRouter를 통해 배포되고 있습니다.

로보틱스 또는 시뮬레이션 파이프라인을 구축 중이고 오픈 소스 추론 비용을 감당할 수 있다면, Cosmos 3는 별도의 텍스트-이미지(text-to-image) 모델과 이미지-비디오(image-to-video) 모델 사이의 글루 코드(glue code)를 제거해 줍니다. 만약 기존 애플리케이션에 음성이나 비전을 추가하고 싶고, 알려진 SLA(Service Level Agreement)가 보장되는 관리형 배포를 원한다면, MAI 모델을 이미 사용 중일 가능성이 높은 인프라에서 바로 사용할 수 있습니다.

결론: 멀티모달이 로드맵에 있다면 즉시 두 가지를 모두 검토하십시오. 통합된 모달리티 처리와 추론 스택(inference stack)에 대한 제어권이 필요하다면 Cosmos 3가 적절한 선택입니다. 새로운 인프라를 구축하지 않고 프로덕션 가용성이 필요하다면 MAI가 적절한 선택입니다.

Kotlin용 ADK, 백엔드에 에이전틱 워크플로우(agentic workflows)를 가져오다

Google의 Kotlin용 Agent Development Kit (ADK) 0.1.0은 클라우드 Gemini 모델과 온디바이스(on-device) Gemini Nano 간의 라우팅을 추상화하는 LlmAgent 인터페이스를 제공하며, 컨텍스트 관리(context management)와 API 적응(API adaptation)을 투명하게 처리합니다. 순차적 에이전트(Sequential agents), 검색 에이전트(retrieval agents), 세션 상태(session state), 그리고 OpenTelemetry 인스트루멘테이션(instrumentation)이 모두 포함되어 있습니다. @Tool 어노테이션은 컴파일 타임에 KSP를 통해 보일러플레이트(boilerplate) 코드를 생성합니다.

가장 매력적인 사례는 하이브리드 클라우드-엣지(hybrid cloud-edge) 아키텍처로, 각 대상에 대해 별도의 에이전트 정의를 작성하지 않고도 민감한 데이터에 대해서는 로컬 추론(local inference)을, 복잡한 작업에 대해서는 클라우드 추론(cloud reasoning)을 사용하고자 할 때 유용합니다. Gradle 의존성(com.google.adk:google-adk-kotlin-core:0.1.0)과 KSP 프로세서를 추가하는 것이 전체 설정 비용입니다.

결론: 지금 바로 검토하십시오, 특히 Android와 인접한 백엔드 작업의 경우 더욱 그렇습니다. 현재 0.1.0 버전이므로 API 변경(churn)이 예상되지만, 기능 세트는 실제 시스템을 프로토타이핑하기에 충분할 만큼 완성되어 있습니다. 만약 현재 클라우드-투-디바이스(cloud-to-device) 추론 라우팅을 직접 구현(hand-rolling)하고 있다면, 이 도구가 해당 아키텍처를 대체할 것입니다.