요약

  • 사이버안전검토위원회는 Microsoft의 최고경영자와 이사회에 구체적 일정을 담은 계획을 요구했다. 회사는 날짜가 붙은 보고서, 구간으로 표시된 목표, 이름이 적힌 임원, 보상 연동을 내놓았다. 그러나 이 문서들 어디에도 제3자가 게시된 백분율을 재계산할 수 있는 경로는 없다.
  • 릴리스 파이프라인 적용률은 2025년 11월 94%에서 2026년 7월 90%로 내려갔고, Microsoft는 이를 측정 범위 확대 때문이라고 설명한다. 분모와 함께 움직이는 숫자는 보증이 아니다. 그런데도 조달 서류에는 바로 그 형태로 들어간다.

2023년 여름 Exchange Online 침해 사건을 다룬 사이버안전검토위원회 보고서는, 열람한 사본의 표지 날짜가 2024년 3월 20일이며, 첫 번째 권고로 수렴한다. "The CEO and Board should develop, and share publicly, a plan with specific timelines to make fundamental, security-focused reforms" (CSRB 보고서, 인쇄면 19).

이 도구에는 세 가지 속성이 있고, 셋이 동시에 성립해야 한다. 회사 정점을 향한다는 것 — 엔지니어링 팀이 아니라. 현재 진행 중인 프로그램이 아니라 구체적 일정을 요구한다는 것. 그리고 눈으로 볼 수 있어야 한다는 것, 즉 판단할 수 있는 독자가 있어야 한다는 것. 셋 중 둘로는 부족하다.

2024년 5월 3일 Microsoft는 100% 목표 묶음으로 응답했다. 그중 하나는 이렇다. "100% of access to source code and engineering systems infrastructure is secured through Zero Trust and least-privilege access policies." (2024년 5월 3일 발표). 준수 여부는 목표와 핵심 결과로 측정하겠다고 했다. 그러나 공개된 페이지에서 이 목표들 가운데 자체적인 달력상 기한을 가진 것은 없고, 목표마다 단일 책임자를 지목한 것도 없다.

방법론은 2025년 4월 보고서에 군더더기 없이 적혀 있다. "We calculated progress by recording the completed percentage of standards and key results, those defined initially and any additions." (2025년 4월 보고서, 인쇄면 4). 운영 언어로 옮기면 이렇다. 회사가 일을 추가하면 분모가 커진다. 사기가 아니라 정의다. 그리고 바로 그 정의 때문에 이 숫자는 외부 독자에게 진척의 증거로 쓸 수 없다.

결과는 점이 아니라 구간으로 공개된다. 2025년 4월 목표 13은 9599% 구간, 목표 4와 5는 6694% 구간이었다. 2025년 11월 목표 2와 3은 9599%에 머물렀지만 목표 1, 4, 5는 6694%로 내려갔고, 회사는 재고 조사 범위가 넓어졌다고 설명했다 (2025년 11월 보고서). 2026년 7월에는 목표 1이 "closed"로 표시되고, 목표 2와 3은 9599%, 목표 4와 5는 66~94%다 (2026년 7월 보고서). 구간은 개수가 아니고, 완료 표시는 자산 비율이 아니다. 둘 다 재계산되지 않는다.

반면 적용률 수치는 날짜가 붙어 있고 비교 가능하다 — 각 보고서가 무엇을 측정하는지 존중한다는 조건에서. 2024년 9월, 상용 클라우드 프로덕션 빌드 파이프라인의 85%가 중앙 관리 템플릿을 쓴다 (2024년 9월 보고서). 2025년 4월, 빌드 파이프라인 92%, 릴리스 파이프라인 54%, 프로덕션 테넌트 ID로 제한된 코드 서명 접근 56%. 2025년 11월, 관리 템플릿을 쓰는 릴리스 파이프라인 94%, 네트워크 격리 89%. 2026년 7월, 중요·고가치 빌드 파이프라인 93%, 릴리스 파이프라인 90% (2026년 7월 Trust Center 요약).

릴리스 파이프라인 수치는 천천히 읽어야 한다. 54%, 그다음 94%, 그다음 90%. 마지막 움직임에 대해 Microsoft는 이렇게 적는다. "Recent metric variation reflects expanded measurement scope, with final attribution under review." (2026년 7월 PDF). 통제가 나빠졌는지, 좋아졌는지, 아니면 정의가 바뀐 것인지 알고 싶은 독자는 문서에서 답을 얻지 못한다. 회사 스스로 귀속 문제를 아직 검토 중이라고 밝히고 있다.

가장 많이 인용되는 숫자는 성격이 다르다. "achieving 99.5% detection and remediation of live secrets in code." (2025년 11월 10일 발표). 본문에는 분자도 분모도 표본 추출 방식도 없고, 적용 범위를 재는지 탐지 품질을 재는지 제거 완료율을 재는지도 적혀 있지 않다. 검증된 정확도가 아니라 회사가 스스로에 대해 한 진술이다.

2026년 7월에 공개된 물량 수치에도 같은 주의가 필요하다. 심각·고위험 오픈소스 취약점 사례 55만 건 이상이 해결됐고, 자동 컨테이너 패치는 월 약 300만 건의 취약점 사례를 처리한다 (2026년 7월 요약). 사례는 고유 취약점도 CVE도 아니며, 55만이라는 숫자에는 측정 기간이 표시되지 않는다. 월간 처리량은 누적 부채의 청산과 같지 않다. 읽는 틀을 잡아 주는 수치가 둘 더 있다. 감시 대상 파이프라인이 약 8만 개이고, 2025년 4월 기준으로 7대 보안 로그 범주 가운데 5개가 보존 기준을 충족했다 (2025년 4월 보고서). 게다가 보고 기간이 서로 다르다. 2025년 11월 보고서는 2025년 1월 이후 CVE를 세지만 버그 바운티 지급은 2024년 7월부터 2025년 6월까지를 포괄한다. 발행일은 결산일이 아니다.

회사도 한계를 인정한다. "We do not disclose the full body of work we are undertaking to advance an objective (such as standards and key results)" (2025년 11월 보고서). 정직한 문장이다. 그리고 외부 감사가 이 문서들만으로는 계산을 재현할 수 없는 기술적 이유이기도 하다.

가장 제재에 가까운 요소가 하나 남는다. 2024년 5월 Satya Nadella는 "part of the compensation of the senior leadership team on our progress towards meeting our security plans and milestones"를 기반으로 삼는다고 밝혔고 (2024년 5월 3일 공식 블로그), 2024년 9월에도 같은 내용이 반복된다. "Microsoft’s senior leadership team now has security performance directly linked to compensation." (2024년 9월 업데이트). 열람한 문서 중 어느 것도 가중치, 발동 임계값, 특정 이정표에 연동된 자동 감액을 공개하지 않는다. 척도 없는 보상 연동은 우선순위의 신호로 남고, 집행 가능한 조건이 되지 못한다.

거버넌스에도 이름이 붙어 있다. CISO Igor Tsyganskiy가 Deputy CISO로 구성된 Cybersecurity Governance Council을 이끌고, Deputy CISO와 엔지니어링 팀이 감독·위험관리·보고를 공동으로 맡으며, 경영진 검토는 주간, 이사회 보고는 분기, 보안 성과는 직원 평가에 반영된다. Joy Chik은 프로그램의 경영 후원자로 명시된다 (2024년 9월 발표). 이름이 붙은 감독은 지표마다 책임자와 기한을 지정한 대장이 아니다.

공정하게, 실제로 있는 것도 세어야 한다. 프로그램에는 적어도 하나의 달력상 기한이 있다. 중요 제품과 서비스를 2029년까지 포스트양자 암호(PQC)로 전환하겠다는 목표다 (2026년 7월 10일 발표). 전부 날짜가 없다고 쓰는 것은 사실이 아니다. 또 2025년 4월 보고서 부록은 CSRB 권고 1~4를 "complete"로 표시한다. 그것은 Microsoft가 자기 준수를 스스로 평가한 결과이지 독립된 검증이 아니다.

프로그램 페이지에 마지막으로 올라온 보고서는 2026년 7월이고, 그에 딸린 발표는 2026년 7월 10일자다 (Trust Center 허브). 주기는 달력이 아니라 약속이다. "We plan to keep ourselves accountable and provide the latest SFI news to customers, partners, and the security community through regular updates." 고정된 발행 주기는 페이지에 없고, 페이지 자체도 바뀔 수 있다.

모든 것을 결정하는 질문 — Microsoft 밖에서 누가 이 백분율을 확인하는가 — 에 대한 정직한 답은 좁다. 이 글을 위해 명시된 열람일에 읽은 열한 개 문서, 즉 CSRB 보고서, 상세 진행 보고서 네 개(2024년 9월, 2025년 4월, 2025년 11월, 2026년 7월), 날짜가 붙은 Microsoft 발표 네 개, 2026년 7월 Trust Center 요약 페이지와 프로그램 허브에서는 게시된 백분율에 대한 독립적 확인을 찾지 못했다. 내부 테스트, 표준 매핑, 위원회의 앞선 사건 분석은 이후 수치에 대한 독립적 보증이 아니다. 이 문서군에 없다는 사실이 다른 곳에도 없다는 증명은 아니다.

이 회사에 관한 우리의 이전 보도에 무엇을 더하는지도 분명히 해 둘 필요가 있다. 우리 기사 일곱 편은 이 회사를 제품·플랫폼·시장 참여자로 다뤘다. Copilot 통합(2026년 3월 19일), Microsoft–Amazon–OpenAI 사이의 움직임으로 보도된 사안(2026년 3월 19일), Stryker 침해 이후 Intune 관리자 통제와 관련된 CISA 권고(2026년 3월 19일), Microsoft 365 장애(2026년 1월 23일), G42와의 아랍에미리트 200MW 데이터센터 확장(2025년 11월 7일), 영국 경쟁시장청의 클라우드 시장 권고(2025년 8월 1일)다. 어느 것도 외부 검토 이후 강제 가능한 구제수단을 무엇이 대체했는지 확인하지 않았다. 사이버안전검토위원회의 구속력 없는 성격을 다룬 우리 브리핑은 이 글이 시작하는 지점에서 멈췄다 — 회사가 그 자리에 세운 도구다. BTW 디렉터리의 Microsoft Corporation 항목은 여기서 정체성의 기준점으로만 쓰이고, 운영상 사실의 출처가 아니다.

그래서 유용한 질문은 Microsoft가 진지하게 일하고 있는가가 아니다. 문서는 일의 양, 이름이 적힌 사람들, 수만 개의 계측된 파이프라인을 보여 준다. 질문은 자기 자신에 대해 발행한 백분율이 무엇을 강제하는가다. 조달 계약에서 완료율은 보증처럼 읽히고, 연차 보고서에서는 통제처럼, 보험 증권에서는 측정된 위험처럼 읽힌다. 세 경우 모두 독자는 판매자만이 산출할 수 있는 결론을 사들이고 있다. 측정 대상이 스스로 정의하고 계산하고 해설하는 척도는 검증이 아니다. 소수점이 붙은 자기평가다.