대상 기간: 오늘 · 수집 항목: 4건 · 출처: Azure 공식 업데이트 RSS
오늘 Azure 쪽 흐름은 꽤 선명합니다. 현대화(Modernization)는 더 똑똑하게, 데이터는 더 적게 옮기고 더 직접 읽고 쓰게 만드는 방향이 눈에 띄네요. 특히 Azure Migrate와 GitHub Copilot Modernization의 결합, 그리고 Azure Databricks와 Microsoft OneLake의 연결 강화는 실무자가 아키텍처를 다시 그려보게 만드는 소식입니다.
· Application modernization — 포트폴리오 단위 평가와 코드 단위 분석이 연결되면 마이그레이션 우선순위가 훨씬 구체화됩니다.
· OneLake — 데이터 복사 없이 여러 엔진이 같은 데이터 계층을 활용하는 unified storage 개념을 이해해둘 만합니다.
· Unity Catalog — Databricks에서 데이터 접근 제어와 메타데이터 관리를 어떻게 통합하는지 살펴볼 포인트입니다.
· Delta tables — 관리형 Delta 테이블을 어디에 저장하느냐가 운영 복잡도와 거버넌스에 직접 연결됩니다.
· ICMP on NAT Gateway — 네트워크 운영에서 “ping이 되느냐” 같은 아주 기본적인 진단 경험도 서비스 기능 차이로 달라질 수 있습니다.
1 item
· Azure Migrate의 포트폴리오 수준 discovery/assessment와 GitHub Copilot Modernization의 context-aware code analysis를 결합한 기능입니다.
· 애플리케이션 현대화 검토 시, 단순 인프라 관점이 아니라 코드 수준 인사이트까지 확장할 수 있다는 점이 핵심입니다.
· “무엇을 먼저 옮길까?”를 정할 때 앱 목록만 보는 게 아니라, 코드 변경 난이도와 현대화 가능성까지 함께 판단하는 흐름으로 읽힙니다.
· 대규모 애플리케이션 포트폴리오를 가진 조직일수록 사전 진단 단계의 정밀도가 중요하니, 실무적 관심도가 높습니다.
무엇인가: Azure Migrate에 GitHub Copilot Modernization 통합이 추가되어, 대규모 코드 평가(at scale code assessments)를 지원하는 프리뷰 기능입니다. 기존의 자산 발견과 평가를 넘어 코드 문맥 기반 분석까지 연결하는 것이 새롭습니다.
왜 흥미로운가: 마이그레이션/현대화는 인프라 이관만으로 끝나지 않고 결국 코드 변경 비용이 승부를 가르는데, 이 기능은 그 간극을 줄이는 방향입니다. 엔지니어 입장에선 “이 앱은 리호스트할지, 리팩터링할지”를 더 근거 있게 판단하는 시야를 얻을 수 있습니다.
해보기: Azure Migrate의 평가 흐름을 먼저 훑어본 뒤, GitHub Copilot Modernization 관련 문맥과 함께 “포트폴리오 평가 → 코드 평가”가 어떻게 이어지는지 문서 기준으로 맵을 그려보세요.
원문 링크: https://azure.microsoft.com/updates?id=566145
2 items
· Azure Databricks가 Unity Catalog를 통해 Microsoft OneLake의 데이터를 네이티브로 읽을 수 있게 되었습니다.
· 핵심은 데이터를 이동하거나 복사하지 않고도(query without copy) OneLake 데이터를 질의·분석할 수 있다는 점입니다.
· 데이터 중복 저장을 줄이고, 분석 경로를 단순화하며, 더 빠른 액세스를 기대할 수 있습니다.
· Databricks와 Microsoft Fabric/OneLake를 함께 보는 조직이라면 특히 눈여겨볼 만한 연결점입니다.
무엇인가: Azure Databricks에서 OneLake에 저장된 데이터를 Unity Catalog 기반으로 직접 읽는 기능이 GA가 됐습니다. 기존처럼 별도 복제나 이동을 전제로 하지 않고, OneLake를 데이터 소스로 바로 활용하는 접근이 포인트입니다.
왜 흥미로운가: 데이터 플랫폼 설계에서 가장 피곤한 문제 중 하나가 “같은 데이터를 여러 저장소에 복사하는 것”인데, 이런 통합은 아키텍처를 훨씬 깔끔하게 만듭니다. 엔지니어는 Databricks와 Fabric 생태계를 대립적으로 보기보다, 공유 스토리지 계층 위의 다중 엔진 관점으로 이해할 수 있습니다.
해보기: OneLake와 Unity Catalog가 어떤 식으로 연결되는지 문서를 따라 읽으면서, “복사 기반 파이프라인”과 “직접 읽기 기반 분석”의 아키텍처 차이를 다이어그램으로 비교해보세요.
원문 링크: https://azure.microsoft.com/updates?id=565733
· 이번에는 읽기뿐 아니라, Azure Databricks가 managed Delta tables를 Microsoft OneLake에 네이티브로 저장할 수 있게 됐습니다.
· 즉, Databricks 워크로드의 저장 계층으로 OneLake를 활용할 수 있어 별도 스토리지 계정 관리 부담을 줄이는 방향입니다.
· OneLake를 통합 스토리지 레이어(unified storage layer) 로 삼으려는 그림이 더 분명해졌습니다.
· 읽기 GA와 쓰기 Preview가 같이 나온 셈이라, Databricks–OneLake 통합이 빠르게 확장되는 흐름으로 볼 수 있습니다.
무엇인가: Azure Databricks가 관리형 Delta 테이블을 OneLake에 직접 쓸 수 있도록 하는 프리뷰 기능입니다. 단순 연동이 아니라 Databricks 저장 위치 자체를 OneLake 중심으로 가져가는 선택지가 생겼다는 의미가 있습니다.
왜 흥미로운가: 데이터 엔지니어링에서 저장소 표준화는 운영 복잡도, 거버넌스, 비용 구조에 모두 영향을 줍니다. 이 기능을 이해하면 “Databricks는 컴퓨트/분석 엔진, OneLake는 공용 데이터 계층”이라는 식의 설계를 더 자연스럽게 떠올릴 수 있습니다.
해보기: managed Delta tables, Unity Catalog, OneLake가 각각 어떤 역할을 하는지 정리한 뒤, “Databricks 전용 저장소”와 “OneLake 통합 저장소”의 운영 차이를 표로 비교해보세요.
원문 링크: https://azure.microsoft.com/updates?id=565706
1 item
· Azure Standard V2 NAT Gateway가 outbound ICMP Echo Request / Echo Reply를 지원합니다.
· 이제 Standard V2 NAT Gateway 뒤의 워크로드에서 ping 같은 도구로 outbound connectivity를 빠르게 검증할 수 있습니다.
· 운영 관점에서는 네트워크 이슈 발생 시 가장 기본적인 진단 수단 하나가 추가된 셈입니다.
· 기능 자체는 작아 보여도, 실제 트러블슈팅에서는 체감 가치가 큽니다.
무엇인가: Standard V2 NAT Gateway에서 ICMP echo 트래픽 지원이 GA로 제공됩니다. 기존에는 NAT 뒤 워크로드의 연결성 확인에서 제약이 있었던 부분을 좀 더 직관적으로 다룰 수 있게 됐습니다.
왜 흥미로운가: 네트워크 기능은 거대한 신기능보다도 이런 “작지만 실용적인” 변화가 운영 생산성에 직접 영향을 줍니다. Azure 네트워크를 공부하는 입장에서는 NAT Gateway의 역할뿐 아니라, 어떤 프로토콜이 실제로 통과되는지까지 봐야 한다는 점을 다시 확인하게 됩니다.
해보기: Azure NAT Gateway 아키텍처를 복습하면서, Standard V2 NAT Gateway 뒤의 VM/워크로드에서 어떤 outbound 경로가 형성되는지 다이어그램으로 정리해보세요.
원문 링크: https://azure.microsoft.com/updates?id=565487
오늘 제공된 목록에는 별도 retirement 항목이 없습니다.