Git/libcurl에서 NTLM이 종료됩니다: Azure DevOps Server 팀은 실제 마이그레이션 계획이 필요합니다

Emiliano Montesdeoca — Mon, 20 Jul 2026 00:00:00 +0000

다가오는 libcurl의 NTLM 제거는 기술적으로 보이지만 실제로는 조직적인 변경 중 하나입니다. Azure DevOps Server로 가는 HTTPS 통한 Git 경로가 여전히 NTLM에 의존한다면, 문제는 툴링이 아니라 아이덴티티 부채입니다.

원문: https://devblogs.microsoft.com/devops/upcoming-change-ntlm-removal-in-git-libcurl-impact-to-azure-devops-server-customers/

Microsoft가 여기서 강력히 밀어붙이는 것은 옳습니다. NTLM은 알려진 암호화 취약점이 있으며 현대 엔터프라이즈 기본값이 되어서는 안 됩니다. 위험한 부분은 많은 환경이 Kerberos를 사용하고 있다고 믿지만 실제로는 NTLM으로의 무음 SPNEGO 폴백으로 유지되고 있다는 것입니다. 그 환상은 2026년 9월에 사라집니다.

내 의견: 이것을 “클라이언트 버전” 문제로 취급하지 마세요. NTLM 플래그를 다시 활성화하고, 이전 Git 빌드를 고정하거나, 폴백이 계속 가능하기를 바라는 것은 장기적 위험이 있는 단기 해결책입니다. 완화 전략이 다운그레이드 및 지연이라면, 운영 취약성을 적극적으로 증가시키는 것입니다.

실용적인 마이그레이션 순서는 직설적이고 측정 가능해야 합니다.

지금 현재 인증 동작을 확인하세요. 실제 개발자 및 빌드 에이전트 컨텍스트에서 도메인 외부 및 원격 네트워크 경로를 포함하여 트레이스 기반 검사와 티켓 캐시 검증을 실행하세요.
Kerberos를 종단간 수정하세요: SPN, DNS 별칭, 로드 밸런서 설정, 위임, 도메인 컨트롤러 연결성.
도메인에 가입되지 않았거나 작업 그룹 시나리오를 조기에 식별하고 Kerberos를 신뢰할 수 있게 만들 수 없는 곳에 SSH 레인을 설계하세요.

또한 소유권 명확성이 필요합니다. 보안 팀은 정책 기준을 정의해야 하지만, 플랫폼 엔지니어링이 구현 준비를 소유해야 합니다. 이것은 개별 리포지토리 관리자를 위한 사이드 태스크가 될 수 없습니다. IIS, AD, 네트워크 에지, CI 에이전트, 개발자 워크스테이션 지침 전반에 걸친 조정된 변경이 필요합니다.

한 가지 미묘한 위험은 자동화입니다. 빌드 에이전트와 서비스 계정은 인간 사용자가 괜찮을 때에도 Kerberos 티켓이 없거나 유효하지 않은 컨텍스트에서 자주 실행됩니다. 대화형 개발자 워크플로만 테스트하면 가장 중요한 중단점을 놓칠 것입니다.

이점은 실제입니다. Kerberos 또는 SSH로 깔끔하게 이동하면 중단을 피할 뿐만 아니라 공격 표면을 줄이고 아이덴티티 제어를 현대 규정 준수 기대치와 정렬합니다. 지금 이 전환을 시작하는 팀은 9월을 무사히 넘길 것입니다. 기다리는 팀은 릴리스 압박 아래 인증 오류를 디버깅하게 될 것입니다.

이것은 보관할 경고가 아닙니다. 실행해야 할 마감일입니다.

Visual Studio 안에서 pull request를 리뷰하는 것은 내가 좋아하는 종류의 friction reduction이다

Emiliano Montesdeoca — Sun, 21 Jun 2026 00:00:00 +0000

이 글은 자동 번역되었습니다. 원문은 여기에서 볼 수 있습니다.

브라우저가 code review workflow의 너무 많은 부분을 너무 오래 가져가고 있었습니다.

그래서 Visual Studio가 IDE 안에서 end-to-end pull request review 쪽으로 더 나아가는 모습을 보는 것이 정말 반갑습니다.

이건 큰 헤드라인을 만들지는 않을 수 있지만, 일상적인 development를 확실히 개선할 수 있는 기능입니다.

핵심 가치는 간단합니다: context switching이 줄어든다

review loop가 일부는 IDE에, 일부는 browser에 있을 때 friction은 쌓입니다.

다른 곳에서 PR을 연다
한 tool에서 변경 사항을 검사한다
더 깊게 조사하기 위해 solution으로 돌아간다
comment나 approve를 위해 다시 전환한다

치명적이지는 않습니다. 그냥 비효율적일 뿐입니다.

Visual Studio가 같은 working environment에서 PR을 열고, inspect하고, comment하고, approve하고, merge할 수 있게 해 준다면, 그것은 진짜 productivity win입니다.

“checkout 없이 review” 옵션은 특히 좋습니다

제가 특히 좋아하는 부분은 PR branch를 checkout하지 않고 review할 수 있다는 점입니다.

작아 보일 수 있지만, 다음과 같은 경우에 완벽합니다.

빠른 review pass
interrupt-driven feedback 요청
현재 branch와 local state를 그대로 유지

이게 바로 좋은 code review tool이 필요한 유연성입니다.

내 생각

이건 혁신적인 기능은 아닙니다.

그보다 더 좋은 것입니다: 실용적인 기능.

하루 대부분을 Visual Studio에서 보내는 팀에게 더 강한 PR review 지원은 workflow break를 줄이고 inspection에서 action까지의 경로를 더 부드럽게 만듭니다.

저는 이걸 충분히 가치 있는 개선이라고 봅니다.

원문: Visual Studio를 떠나지 않고 pull request 리뷰하기

Git | The .NET Blog

Git/libcurl에서 NTLM이 종료됩니다: Azure DevOps Server 팀은 실제 마이그레이션 계획이 필요합니다

Visual Studio 안에서 pull request를 리뷰하는 것은 내가 좋아하는 종류의 friction reduction이다

핵심 가치는 간단합니다: context switching이 줄어든다

“checkout 없이 review” 옵션은 특히 좋습니다

내 생각