Azure 신뢰를 무너뜨린 결정들 – 전직 Azure Core 엔지니어의 기록
(isolveproblems.substack.com)- Microsoft Azure Core 내부의 비현실적 의사결정이 누적되며 기술적 혼란과 신뢰 붕괴로 이어진 과정을 전직 엔지니어가 상세히 서술
- 하드웨어 제약을 무시한 Windows 기능 포팅 계획과 173개의 관리 에이전트 난립이 대표적 문제로 지적됨
- 이러한 복잡한 구조가 OpenAI, Anthropic, 정부 클라우드 등 핵심 워크로드를 지탱하고 있어 단일 오류가 전 세계적 장애로 확산될 위험 존재
- 경영진의 무응답 속에 OpenAI와의 관계 악화, 미국 정부의 신뢰 상실, 기능 출시 지연 등 후속 사태가 발생
- 결과적으로 1조 달러 규모의 시장가치 증발로 이어졌으며, 클라우드 인프라 운영에서 기술적 현실 인식과 단순성 유지의 중요성이 강조됨
Azure 신뢰 붕괴의 내부 기록
- Microsoft Azure Core 팀 내부의 비현실적 결정 과정과 그로 인한 기술적·조직적 혼란을 다룬 전직 엔지니어의 회고
- Overlake R&D 팀에 합류한 첫날부터, 하드웨어 제약을 무시한 Windows 기능 포팅 계획이 논의되는 장면을 목격
- 173개의 관리 에이전트가 존재하지만, 그 기능과 필요성을 아는 사람이 없을 정도로 복잡성과 불투명성이 심각
- 이러한 구조가 OpenAI, Anthropic, 정부 클라우드 등 핵심 워크로드를 지탱하고 있어 단일 오류가 전 세계적 장애로 이어질 위험
- 결과적으로 OpenAI 신뢰 상실, 미 국방부의 공개적 불신, 시장가치 1조 달러 증발로 이어졌다고 서술
Azure Core 입사와 초기 상황
- 2023년 5월 1일, Azure Boost 오프로딩 카드와 네트워크 가속기를 담당하는 Overlake R&D 팀에 시니어 엔지니어로 합류
- 이전에는 Windows 팀과 Core OS 팀에서 커널 개선 및 컨테이너 플랫폼 개발에 참여, Docker·AKS·App Services·Windows Sandbox 등 핵심 기술에 기여
- Overlake 카드 초기 설계(2020~2021)에도 참여해 호스트 OS와 가속기 카드 간 통신 프로토콜을 제안한 경험 보유
- Azure 플랫폼을 10년 이상 직접 운영·개발해온 전문가로 복귀
첫 회의에서 목격한 비현실적 계획
- 입사 첫날, 팀의 월간 계획 회의에서 Windows 구성요소를 Overlake 카드로 포팅하려는 계획을 확인
- Overlake 카드의 RAM 용량과 전력 예산이 극도로 제한적임에도, 팀은 Windows 기능을 이식하려는 시도를 논의
- 하드웨어 사양상 불가능한 계획이었으며, “주니어 개발자 몇 명에게 맡겨보자”는 발언까지 나옴
- 조직은 Windows를 Linux로 포팅해 VM 관리 에이전트를 유지하려는 방향을 진지하게 검토 중이었음
- 저자는 이를 “현실과 동떨어진 계획”으로 인식하고, 조직 전체가 불가능한 목표를 향한 행진에 들어섰다고 판단
기술적 한계와 구조적 문제
- 당시 스택은 400W Xeon CPU에서 수십 개 VM만 처리 가능, 하이퍼바이저의 1,024 VM 한계와 큰 차이
- 과도한 리소스 사용으로 고객 VM에서 지터(jitter) 가 발생하는 등 성능 저하 문제 존재
- 이러한 비효율적 스택을 작은 ARM SoC로 이식해 확장하려는 계획은 기술적으로 불가능
- 저자는 “새 기술을 배우는 것보다, 조직 전체를 현실로 되돌리는 것이 더 시급한 과제”였다고 표현
Azure Linux 및 Overlake 관련 내부 대화
- Linux System Group 책임자와의 90분 대화에서, Overlake 카드용으로 173개의 에이전트를 포팅 후보로 지정했음을 확인
- 조사 결과, Microsoft 내부 누구도 이 173개 에이전트의 역할·상호작용·존재 이유를 명확히 설명하지 못함
- Azure의 핵심은 VM·네트워킹·스토리지이며, 나머지 서비스는 이 위에 구축됨에도 불필요한 복잡성이 누적
- 이러한 통제 불가능한 구성요소 집합이 OpenAI·Anthropic·정부 클라우드 등 주요 워크로드를 관리하고 있음
신뢰 상실과 후속 사태
- 이 복잡한 구조는 국가 안보 및 비즈니스 연속성에 심각한 위험을 초래할 수 있는 상태
- 이후 CEO, 이사회, Cloud+AI 부문 EVP에게 보낸 서한은 모두 무응답으로 끝남
- 결과적으로 OpenAI와의 관계 악화, 미국 정부의 신뢰 붕괴(국방장관의 공개 발언), 엔지니어링 낭비와 Rust 전환 명령, 기능 출시 지연 등이 발생
- 저자는 이를 “1조 달러의 시장가치가 증발한 사건”으로 표현하며, Azure를 사용하는 기업들에게 생산 환경 의존의 위험성을 경고
결론
- Azure 내부의 기술적 복잡성, 관리 부실, 비현실적 의사결정이 누적되어 신뢰를 잃은 과정이 드러남
- 핵심 인프라를 담당하는 조직이 현실 감각을 상실한 채 구조적 실패로 향한 행진을 이어간 사례
- 클라우드 인프라의 안정성과 단순성, 그리고 조직 내 기술적 판단력 유지의 중요성이 강조됨
Hacker News 의견들
-
매일 Azure를 사용하는 입장에서, 이번 폭로가 사실이라면 정말 많은 게 설명되는 느낌임
UI는 엉성하고 문서는 AI가 쓴 듯 부정확하며, 서비스 종류가 너무 많아 어떤 걸 써야 할지조차 감이 안 옴
컨설턴트 도움 없이 설정하기 어렵고, 설정 후에도 제대로 작동하는지 확신이 없음
솔직히 이게 아직도 돌아간다는 게 신기함- 예전엔 Azure 문서에 감탄했지만, 일주일간 구현 후 테스트 환경에서 GraphAPI가 문서와 다르게 작동하지 않아 완전히 실패했음
그 이후로는 문서를 믿지 않음 - Azure 컨설턴트들과 일했는데, 그들도 Azure를 싫어함
- 경영진이 크레딧이 많다고 해서 AKS로 이전했는데, pod가 랜덤하게 크래시되고 DB 노드의 디스크 지연이 급등함
GCP에서 안정적으로 돌던 서비스가 예측 불가능해졌음
- 예전엔 Azure 문서에 감탄했지만, 일주일간 구현 후 테스트 환경에서 GraphAPI가 문서와 다르게 작동하지 않아 완전히 실패했음
-
Azure OpenAI가 부하가 걸릴 때 다른 고객의 프롬프트 응답을 유출하는 걸 봤음
관련 트윗도 있음
그런데 아무도 신경 쓰지 않는 분위기임- “Azure OpenAI”가 정확히 뭘 의미하는지 궁금함 — GitHub Copilot, Microsoft Copilot, OpenAI API, 아니면 Azure에서 호스팅된 LLM 중 하나인지?
완전 와일드 웨스트 같은 상황임
- “Azure OpenAI”가 정확히 뭘 의미하는지 궁금함 — GitHub Copilot, Microsoft Copilot, OpenAI API, 아니면 Azure에서 호스팅된 LLM 중 하나인지?
-
이 글의 주장이 너무 구체적이라 놀라움
내부 고발자인지, 단순히 불만 있는 전 직원인지 궁금함
CEO와 이사회에 직접 보고했다는 부분이 특히 인상적임
미국 기업 문화에서 이런 절차가 ‘관례적’ 이라는 게 낯설음
Azure가 정말 이렇게 불안정한지, 실제 사용자 경험이 궁금함- 실제로 SRE로 AWS, Azure, GCP를 모두 운영 중인데, 장애의 80~90%는 Azure에서 발생함
Azure는 문제를 인지하지 못하고, 원인도 모르며, 심지어 관심도 없어 보임
팀 전체가 Azure를 싫어함 - Azure는 일관성 문제와 레이스 컨디션이 너무 많음
AWS Bedrock에서 OpenAI 모델을 쓸 수 있게 되어 Azure를 피할 수 있다는 점이 반가웠음
신뢰성은 여전히 심각한 문제임 - 대기업은 단기 지표를 위해 품질을 희생하는 결정을 자주 내림
“빨리 출시하고 나중에 고치자”는 전략이 결국 이런 결과를 낳음 - 예전에 Azure 컨테이너에서 탈출해 관리 컨트롤러의 취약점을 발견한 보안 보고서를 본 적 있음
그때부터 신뢰하지 않게 됨 - 무료 크레딧을 줘도 AWS나 GCP를 유료로 쓰는 게 낫다고 생각함
- 실제로 SRE로 AWS, Azure, GCP를 모두 운영 중인데, 장애의 80~90%는 Azure에서 발생함
-
글이 다소 감정적으로 과장되어 있어서 본래 의도가 흐려진 느낌임
Azure 내부 직급 체계나 Sev2 수준의 이슈는 그리 특별한 게 아님
Azure에 문제는 있지만 규모가 크니 거친 부분은 당연함
진짜 성숙함은 시스템 안에서 개선하려는 태도라고 생각함- 이사회에 직접 편지를 보낸 건 조직 내에서 절대 잘 풀리지 않을 행동임
Azure가 엉망일 수도 있지만, 글쓴이의 접근 방식도 문제였을 가능성이 있음 - AWS와 GCP는 UX/DX가 훨씬 낫고, Azure는 왜 안 되는지조차 알려주지 않음
Azure에 대한 인상은 전적으로 부정적임 - Microsoft는 정부 기관의 기본 솔루션이지만, 전면 리라이트 제안은 현실적이지 않음
글쓴이의 접근이 오히려 신뢰를 떨어뜨림 - 글쓴이가 언급한 직급이 낮은 사람들에게 핵심 시스템을 맡긴 구조가 놀라움
- “모든 게 망가졌다고 외치는 사람들”이 많지만, 그게 조직의 타성화된 문제일 수도 있음
새로운 직원이 “wtf/day”를 외치는 빈도가 조직의 건강 지표 같음
Azure는 외부에서 봐도 품질이 바닥임
AWS를 따라잡으려 급하게 기능을 던지다 보니 거대한 기술 부채의 늪에 빠짐
IPv6, azcopy, VM 업그레이드 등 기본 기능조차 여전히 불안정함
- 이사회에 직접 편지를 보낸 건 조직 내에서 절대 잘 풀리지 않을 행동임
-
예전 동료가 Azure를 매일 쓰는데, 그들의 불만 폭발을 들을 때마다 이번 글의 내용이 이해됨
12년 전 클라우드 전문화를 선택할 때 Azure를 잠깐 써보고 느리며 깨진 플랫폼이라 느꼈는데, 이번 글이 그 판단을 확인시켜줌 -
글의 후반부에서 Microsoft가 2025년에 15,000명 감원했다는 부분이 인상적임
AI 붐 뒤의 현실을 보여주는 사례 같음- 하지만 그 부분은 글의 약한 주장이라 생각함
OpenAI 계약은 GPU 용량 문제였고, 감원은 별개임
진짜 문제는 엔지니어 순환과 책임 부재임
프로젝트마다 새 인력이 투입되고, 소유 의식이 사라짐
- 하지만 그 부분은 글의 약한 주장이라 생각함
-
호스트가 뚫리면 모든 VM 메모리에 접근 가능하다는 부분이 매우 위험하게 들림
- 그런 아키텍처를 좋은 아이디어라고 생각한 환경이 상상조차 안 됨
- 글쓴이가 뭘 기대했는지 모르겠음
-
Satya Nadella의 연봉이 9,650만 달러로 22% 상승했다는 CNBC 인용과,
Artemis II 우주비행사가 “Outlook 두 개가 다 안 된다”고 한 말을 나란히 본 게 아이러니함- “Outlook 두 개”라니, 이미 하나도 많음
-
글의 내용이 과장된 듯하지만, 나도 비슷한 시스템을 운영해본 입장에서 안정성을 지키기 위해 끊임없이 싸워야 했던 기억이 있음
다른 회사에서도 비슷한 문제를 봤지만, Azure 규모의 심각도는 아니었음
이런 구조는 결국 자기파괴 루프로 이어질 것 같음 -
2018년에 Azure를 써봤는데, 느리고 비싼데 품질은 형편없음
GitHub 포럼에서 다른 사용자들과 함께 기본 기능조차 안 되는 문제를 해결하려 애썼음
이번 글이 그때의 의문을 풀어줌
개인적으로는 Google Cloud가 가장 잘 설계된 플랫폼이라 느꼈지만, AWS보다 인간 지원이 부족한 점이 아쉬움- GCP의 지원은 정말 형편없음
담당자가 석 달 사이 세 번 바뀌었고, 쿼터 요청이나 시스템 제한 문의가 무시되는 경우도 많음
- GCP의 지원은 정말 형편없음