혠의 기술블로그

[스프링으로 배우는 안티패턴] Spring Security 6.3 부터는 왜 직렬화 버전(SERIAL_VERSION_UID)를 삭제했을까?

devhyen — Thu, 14 May 2026 16:25:59 +0900

https://spring.io/blog/2024/01/19/spring-security-6-3-adds-passive-jdk-serialization-deserialization-for

serialVersionUID 란?

자바 직렬화(Serialization)은 객체를 파일이나 네트워크로 보내기 위해서 바이트 배열로 변환하는 과정입니다.

이때 자바는 내가 지금 저장하려는 객체와 나중에 다시 읽어들일 객체가 같은 클래스를 가지고 있는가를 확인해야합니다.

이때 사용하는 것이 serialVersionUID 입니다.

저장 할 때 UID와 읽을 때의 UID가 같다면 같은 클래스라고 생각하여 데이터를 복원합니다.
값이 다르다면 InvalidClassException로 데이터를 복원하기를 거부합니다.

Spring Security에서 SERIAL_VERSION_UID

사용한 이유

초기 설계 시, 서로 다른 버전 간의 직렬화 호환성을 보장하지 않겠다는 의도적인 결정을 했습니다.

당시 RMI(Remote Method Invocation)환경을 고려하여, 서버와 클라이언트가 반드시 동일한 버전의 시큐리티 라이브러리를 사용하도록 강제하기 위함이었습니다. 이를 위해 모든 시큐리티 클래스가 공통의 SpringSecurityCoreVersion.SERIAL_VERSION_UID 를 바라보게 설계했습니다.

RMI란 ? 자바 객체를 네트워크를 통해 다른 서버로 보내고, 그 쪽 서버에서 그 객체의 메서드를 원격으로 실행하는 기술

강제한 이유

RMI는 통신과정에서 자바의 기본 직렬화를 사용합니다. 자바의 기본 직렬화는 엄격하기 때문에 역 직렬화 에러가 발생할 수 있습니다.
시큐리티는 보안 프레임워크이기 때문에 양쪽이 서로 다른 버전의 보안 로직을 가지고 있다면, 보안 검증 과정에서 예상치 못한 허점이 생기거나, 혹은 검증 방식 자체의 충돌이 발생할 수 있습니다.

사용자가 호출하는 경우

개발자가 직접 구현한 UserDetails나 OAuth2 관련 커스텀 클래스에서 보안 프레임워크의 UID를 참조하여 자신의 serialVersionUID를 할당하는 방식으로 사용했습니다.

private static final long serialVersionUID = SpringSecurityCoreVersion.SERIAL_VERSION_UID;

SERIAL_VERSION_UID 가 안티패턴인 이유

직렬화의 목적 위배

serialVersionUID는 클래스의 '구조'가 변했을 때 바뀌어야 합니다. 하지만 스프링은 릴리즈 버전에 종속시켰습니다.

운영 데이터와 프레임워크 버전의 강제 결합

프레임워크를 업데이트 하는 것은 운영자의 결정이지만, 세션 데이터는 프레임워크보다 오래 살아남아야 합니다. 데이터를 프레임워크의 릴리즈 주기에 가두어 버린 것은 가장 큰 설계적 과오였습니다.

분산 시스템과 세션 영속성이 일상이 된 현대의 웹 환경에서, 그 '강제'는 곧 장애

개선 방법

독립적 선언
하위 호환성 유지
JSON 직렬화 권장

더이상 전역 상수를 참조하지 않고, 직렬화가 필요한 클래스는 각자 고유하고 불변한 serialVersionUID를 직접 명시해야합니다.

기존의 시스템을 업그레이드 할 때는 기존버전의 UID로 하드코딩하여 이전 데이터들을 그대로 읽어올 수 있도록 해줘야 합니다.

JDK 기본 직렬화는 취약점과 호환성 문제가 많으므로 가급적 Jackson등을 활용한 JSON 기반 직렬화로 전환하는 것이 권장됩니다.

"그렇다면 버전이 다를 때 발생하는 보안상의 위험은 어떻게 해결했을까?"

과거에는 데이터의 직렬화 버전만 틀어막으면 보안이 해결될 것이라 믿었지만, 이는 운영 환경의 장애라는 더 큰 비용을 치러야 했습니다. 스프링 시큐리티 6.3부터는 '데이터(세션)'와 '보안 로직(코드)'을 분리했습니다.

이제 프레임워크는 직렬화 호환성을 최대한 보장하여 세션 데이터를 살려내되, 그 데이터를 처리하는 보안 검증 로직은 항상 최신 버전의 코드가 엄격하게 수행하도록 설계되었습니다. 즉, 데이터 호환성은 '테스트'가 보장하고, 보안 무결성은 '최신 코드'가 책임지는 구조로 진화한 것입니다.

교훈

보안과 개발 편의성도 중요하지만, 오히려 안전한 라이브러리를 위해서는 하위 호환성을 고려한 점진적 진화 혹은

데이터 영속성과 라이브러리 배포 주기를 분리하는 전략이 필요하다.

[Elasticsearch] Low Level Client 6.x에서 Java API Client 9.x 마이그레이션 트러블슈팅

devhyen — Fri, 8 May 2026 16:28:09 +0900

마이그레이션 하게된 배경

Elasticsearch 6.x 버전은 공식 지원 종료 (EOL) 된지 오래 되었습니다.
더이상 보안 패치나 버그 수정을 기대할 수 없기 때문에 실제로 발견된 CVE 취약점들에 무방비로 노출될 위험이 있었습니다.
서비스의 지속 가능성과 보안 안정성을 위해 최신 버전인 9.x 로의 마이그레이션을 진행하게 되었습니다.

이미 돌아가는 코드를 고치게 되다 .. 왜 ? ?

6.x 에서 9.x 버전의 차이는 3세대간의 차이라서 호환성이 단절되어있었습니다.

기존 코드로는 호환이 되지 않아서 트러블 슈팅을 하며 마이그레이션을 진행하게 되었습니다.

또한, 새로운 Java API Client 9.x 는 최소 Java 17 이상이 필요하기 때문에 Java 버전도 올려야했습니다.
java 버전을 올리는 것 만으로도 많은 코드 수정과 변화가 있었지만, 이 글에서는 ES 를 올리며 마주한 큰 트러블 슈팅 2가지를 다루려고 합니다.

1. _id 필드에 대한 메모리 로딩 기본적 차단 이슈
문제 현상

"co.elastic.clients.elasticsearch._types.ElasticsearchException: [es/search] failed: [search_phase_execution_exception] all shards failed"

기존 6.x 환경에서 _id 필드를 기준으로 정렬(Sort)하거나 집계(Aggregation)를 수행하던 쿼리들이 9.x 환경에서는 위 메세지를 보이며 에러가 발생하고 있었습니다. 즉, 최신 버전의 Elasticsearch가 시스템 안정성을 위해 _id 필드를 메모리에 직접 올려 정렬이나 집계에 사용하는 행위를 원천 차단하고 있었던 것입니다.

6.x 시절에는 딥 페이징을 위해 _id 를 타이브레이커로 사용하는 것이 표준이었으나

ES는 성능최적화를 위해 가상 필드인 _shard_doc을 도입했습니다.

해결 방법 : _id에서 _shard_doc으로의 전환

시스템 안정성을 해치며 _id의 fielddata 설정을 강제로 풀기보다는 9.x 정식 지원하며 성능적으로 우수한 _shard_doc을 타이브레이커로 사용하기로 결정했습니다.

_shard_doc 은 정수 기반의 물리적 위치값이라 메모리 사용량이 매우 적고 정렬 속도도 빨랐기 때문입니다.

또한, 안정성을 위해 구현할 때 아래를 주의하며 진행했습니다.

1. 동적 정렬 값 추출

서비스의 로직들은 검색응답의 sort [1] 값을 추출하여 다음 search_after 요청에 사용하는 구조였습니다.

정렬 필드를 _id 에서 _shard_doc 으로 변경하면 추출되는 값 자체가 자동으로 숫자형으로 바뀌므로 로직의 큰 틀은 유지할 수 있었습니다.

2. JSON 직렬화 타입 불일치 해결

기존코드는 _id 가 문자열이었기때문에 g.writeString(searchAfter) 와 같이 처리하고 있었습니다.

shard_doc은 숫자 타입입니다. 이를 문자열로 보낼 경우 타입 물일치 에러를 던지기 때문에 정렬값의 타입에 따라 writeNumber와 writeString 을 분기 처리하여 JSON 타입을 정확히 맞추도록 수정했습니다.

3. 기존 오프셋 호환성

배치가 중단된 지점부터 재시작 하기 위해 저장해 둔 오프셋 파일에는 여전히 문자열 _id 값이 남아있습니다.

따라서 마이그레이션 시점에 기존 오프셋 파일을 초기화하거나 첫 실행 시 타입을 체크하여 안전하게 전이할 수 있는 보완 처리를 진행했습니다.

2. typed_keys 이슈

문제 현상

마이그레이션 후, 기존 잘 작동하던 집계 리포트 기능들이 응답 데이터를 파싱하는 과정에서 에러를 보였습니다. 로그 확인 결과, 응답 JSON의 집계 키 이름이 date_terms이 아닌 range#date_terms 나 sterms#type_terms 와 같이 {type}#{name} 형태로 나오고 있었습니다. 이로인해 기존 파서가 키를 찾지 못해 NullPointerException이나 IllegalStateException이 발생했습니다.

원인 분석

범인은 typed_keys 매개변수 입니다.

typed_keys=true 옵션이 켜지면, ES 서버는 집계 응답의 키 앞에 해당 집계의 타입(range, sterms, sum 등)을 접두어로 붙여줍니다. 이는 클라이언트가 응답을 역직렬화(Deserialization)할 때, 각 데이터를 어떤 Java 객체(RangeAggregate, TermsAggregate 등)로 변환할지 정확히 판단하기 위한 정보로 사용됩니다.

이 기능은 6.x 부터 있던 기능이지만, 9.x 는 타입안전성을 지향하기 때문에 내부적으로 typed_keys=true를 기본값으로 강제하여 요청합니다.

해결 방법

수십 개에 달하는 각 리포트 파서의 로직을 일일이 수정(예: # 앞을 잘라내는 로직 추가)하는 것은 비효율적일 뿐만 아니라 휴먼 에러의 위험이 컸습니다. 따라서 응답을 JSON으로 변환하는 중앙 통로를 수정하여 기존 형식을 유지하기로 결정했습니다.

모든 ES 요청과 응답 직렬화가 집중되는 코드부분만 수정하기로 했습니다.

// ESClientQueryExecutor.java 내 헬퍼 메소드 추가
private static JsonpMapper createEsJsonpMapper() {
    return new JacksonJsonpMapper()
        .withAttribute(JsonpMapperFeatures.SERIALIZE_TYPED_KEYS, false);
}

Java API Client가 응답 객체를 JSON으로 바꿀 때 사용하는 JacksonJsonpMapper에 직렬화 속성을 제어하는 기능을 적용했습니다. SERIALIZE_TYPED_KEYS 기능을 비활성화(false)하도록 설정했습니다.

일반적인 검색 요청 처리를 담당하는 restClientInit()과 특정 호스트에 직접 요청을 보내는 일회성 execute() 메소드 양쪽 모두에 커스텀 매퍼를 적용했습니다.

기존: new Rest5ClientTransport(restClient, new JacksonJsonpMapper())
변경: new Rest5ClientTransport(restClient, createEsJsonpMapper())

이 설정을 통해 ES 서버로부터는 typed_keys가 포함된 응답을 받되, 애플리케이션 내부에서 파싱을 위해 다시 JSON으로 변환할 때는 접두어가 제거된 기존 형식(date_terms)으로 출력되게 되었습니다.

느낀점

마이그레이션에 무조건적인 정답은 없다는 것을 다시금 느꼈습니다. 최신 라이브러리의 표준을 무작정 따르는 것보다, 결국 우리 프로젝트의 구조를 얼마나 깊이 이해하고 있느냐가 해결의 핵심이었습니다. 덕분에 수많은 코드를 일일이 수정하며 사이드 이펙트를 키우기보다, 프로젝트의 맥락에 맞춰 영향을 최소화할 수 있는 적절한 해결책을 찾아낼 수 있었습니다.

또한, 이번 과정을 통해 EOL(공식 지원 종료)을 놓치지 않고 제때 버전 업을 관리하는 것이 얼마나 중요한지도 절감했습니다. 기술 부채가 쌓이기 전에 미리 대응하는 것이 결국 시스템의 안정성과 개발자의 생산성을 지키는 길임을 배우게 된 값진 경험이었습니다.

AI 시대의 사이버보안, Anthropic의 ‘Project Glasswing’가 의미하는 것

devhyen — Thu, 9 Apr 2026 13:59:07 +0900

이 글은 Anthropic의 공식 발표인 Project Glasswing 내용을 바탕으로 정리했습니다.

[Anthropic] Project Glasswing

Anthropic이 새로운 사이버보안 프로젝트 ‘Project Glasswing’를 발표했습니다. 이번 프로젝트에는 AWS, Apple, Cisco, Google, Microsoft, NVIDIA, CrowdStrike, JPMorganChase, Linux Foundation, Palo Alto Networks 등 글로벌 기업과 기관들이 함께 참여합니다.

목표는 분명합니다.

AI의 급격한 발전으로 커지고 있는 사이버 위협에 대응하기 위해, 최첨단 AI를 공격이 아니라 방어에 먼저 활용하자는 것입니다.

이번 발표의 핵심에는 아직 공개되지 않은 AI 모델 Claude Mythos Preview가 있습니다. Anthropic은 이 모델이 소프트웨어 취약점을 찾아내고 이를 악용하는 방법을 고안하는 능력에서, 극소수의 최고 수준 인간 전문가를 제외한 대부분을 능가할 정도의 성능을 보여주고 있다고 설명했습니다. 쉽게 말해, AI가 이제 단순히 코드를 작성하는 수준을 넘어, 코드의 약점을 스스로 찾아내고 실제 공격 경로까지 설계할 수 있는 단계에 접어들었다는 의미입니다.

왜 지금 사이버보안이 더 중요해졌을까

우리가 매일 사용하는 소프트웨어에는 크고 작은 버그가 존재합니다. 대부분은 별문제가 없지만, 일부는 심각한 보안 취약점으로 이어질 수 있습니다. 이런 취약점이 공격자에게 발견되면 시스템이 장악되거나, 서비스가 중단되거나, 민감한 정보가 유출될 수 있습니다.

실제로 사이버공격은 이미 기업 네트워크, 병원, 에너지 시설, 교통 인프라, 정부 기관 등 사회 핵심 영역에 큰 피해를 주고 있습니다. 국가 차원의 공격도 점점 더 빈번해지고 있고, 병원이나 학교 같은 개별 기관을 노린 공격조차 큰 경제적 피해와 안전 문제를 초래할 수 있습니다.

문제는 이제 AI가 이런 공격의 문턱을 빠르게 낮추고 있다는 점입니다. 원래 소프트웨어 취약점을 찾고 악용하려면 높은 수준의 전문성과 많은 시간이 필요했습니다. 하지만 최신 AI 모델은 코드를 읽고 이해하며, 취약점을 추론하고, 악용 가능한 경로를 찾는 데 점점 더 뛰어난 성능을 보이고 있습니다. 즉, 공격 역량이 소수 전문가의 영역에서 더 넓은 범위로 확산될 가능성이 커진 것입니다.

Claude Mythos Preview가 보여준 것

Anthropic에 따르면, Claude Mythos Preview는 지난 몇 주 동안 수천 건의 제로데이 취약점을 찾아냈습니다. 제로데이란 소프트웨어 개발자도 모르고 있던 미공개 취약점을 뜻합니다. 특히 주요 운영체제와 웹 브라우저, 리눅스 커널 같은 핵심 소프트웨어에서도 심각한 취약점을 발견했다고 밝혔습니다.

대표 사례도 공개됐습니다.

OpenBSD에서 27년간 남아 있던 취약점을 발견했습니다. 이 취약점은 원격에서 시스템을 다운시킬 수 있는 수준이었다고 합니다.
FFmpeg에서 16년 된 취약점도 찾아냈습니다. 이 코드는 자동화 테스트 도구가 500만 번이나 실행했지만 문제를 잡아내지 못한 부분이었다고 합니다.
리눅스 커널의 여러 취약점을 연결해, 일반 사용자 권한에서 시스템 완전 장악 권한으로 올라갈 수 있는 공격 경로도 스스로 찾아냈다고 합니다.

Anthropic은 이런 취약점 대부분을 사람의 별도 개입 없이 모델이 자율적으로 발견했고, 관련 유지관리자들에게 제보해 현재는 패치가 완료됐다고 설명했습니다.

왜 이 발표가 중요한가

이번 발표가 중요한 이유는 단순히 “AI가 취약점을 잘 찾는다”는 사실 때문만은 아닙니다. 더 중요한 메시지는 이것입니다.

앞으로는 AI가 공격자와 방어자 모두에게 강력한 도구가 될 가능성이 매우 크다.
그리고 지금 필요한 것은, 이 능력이 무분별하게 확산되기 전에 방어 체계를 먼저 강화하는 것입니다.

Anthropic은 바로 이 지점을 강조하며 Project Glasswing을 시작했다고 설명합니다. 참여 기업들은 Mythos Preview를 활용해 자사의 핵심 시스템과 오픈소스 인프라를 점검하고, 취약점을 더 빨리 찾고 수정하는 데 집중하게 됩니다. 또 Anthropic은 이 과정에서 얻은 교훈을 산업 전반과 공유하겠다고 밝혔습니다.

즉, 이 프로젝트는 특정 회사만의 기술 시연이 아니라, AI 시대에 맞는 새로운 보안 협력 모델을 실험하는 시도로 볼 수 있습니다.

참여 기업들이 본 현실

Project Glasswing에 참여한 여러 기업들의 반응도 인상적입니다.
Cisco는 AI 역량이 이제 핵심 인프라 보호의 긴급성을 완전히 바꿔놓았다고 평가했습니다.
AWS는 자사 보안 운영에 Mythos Preview를 시험 적용한 결과, 핵심 코드 보안 강화에 이미 도움을 주고 있다고 밝혔습니다.
Microsoft는 사이버보안이 더 이상 순수하게 인간 역량에만 의존하는 시대가 아니라고 진단했습니다.
CrowdStrike는 취약점이 발견된 뒤 공격에 활용되기까지의 시간이 “몇 달에서 몇 분” 수준으로 줄어들 수 있다고 경고했습니다.
Linux Foundation은 특히 오픈소스 유지관리자들에게 이런 AI 도구가 큰 힘이 될 수 있다고 강조했습니다.

이 메시지들을 종합하면 분명합니다. AI가 사이버보안의 속도와 규모를 바꾸고 있으며, 기존 방식만으로는 대응이 어려워지고 있다는 것입니다.

Anthropic의 계획

Anthropic은 Project Glasswing를 위해 최대 1억 달러 규모의 모델 사용 크레딧을 제공하겠다고 밝혔습니다. 여기에 더해 오픈소스 보안 단체를 위해 총 400만 달러의 기부금도 지원합니다.

프로젝트 참여자들은 Claude Mythos Preview를 활용해 다음과 같은 작업을 수행하게 됩니다.

취약점 탐지
바이너리 블랙박스 테스트
엔드포인트 보안 강화
침투 테스트
핵심 시스템의 약점 분석

Anthropic은 이 프로젝트가 앞으로 수개월 이상 이어질 것이며, 90일 이내에 공개 가능한 결과와 배운 점을 공유하겠다고 했습니다. 또한 AI 시대에 맞는 새로운 보안 관행, 예를 들어 취약점 공개 절차, 공급망 보안, 패치 자동화, secure-by-design 원칙 등에 대한 실질적인 권고안도 마련할 계획이라고 밝혔습니다.

하지만 일반 공개는 하지 않는다

흥미로운 점은 Anthropic이 Claude Mythos Preview를 일반에 공개할 계획은 없다고 선을 그었다는 점입니다. 그 이유도 분명합니다. 이 모델이 가진 사이버 역량이 너무 강력해, 충분한 안전장치 없이 널리 배포될 경우 위험이 크다고 판단한 것입니다.

대신 Anthropic은 앞으로 더 정교한 보호 장치를 개발해, 향후에는 이런 수준의 모델을 더 안전하게 활용할 수 있는 기반을 마련하겠다고 설명했습니다. 다시 말해, 능력을 키우는 것만큼이나 통제 장치를 만드는 것이 중요하다는 메시지입니다.

결국 이 발표가 우리에게 말하는 것

Project Glasswing은 단순한 제품 발표가 아닙니다.
이 발표는 AI가 이제 사이버보안에서 질적으로 다른 국면을 만들고 있다는 신호에 가깝습니다.

앞으로는 취약점을 찾는 일도, 이를 막는 일도, 패치를 적용하는 일도 점점 더 AI 중심으로 재편될 가능성이 높습니다. 공격자 역시 AI를 활용하게 될 것이기 때문에, 방어자들이 뒤처지지 않으려면 지금부터 새로운 도구와 협력 체계를 준비해야 합니다.

결국 핵심은 하나입니다.
AI는 사이버보안을 더 위험하게 만들 수도 있지만, 동시에 더 안전하게 만들 수 있는 가장 강력한 도구이기도 하다.
Project Glasswing은 그 힘을 먼저 방어에 쓰기 위한 시도이며, 앞으로 AI와 보안의 관계가 어떻게 재정의될지를 보여주는 중요한 출발점이라고 할 수 있습니다.

한줄 정리

Anthropic의 Project Glasswing은 초강력 AI의 취약점 탐지 능력을 방어 목적으로 먼저 활용해, AI 시대의 새로운 사이버보안 표준을 만들려는 시도입니다.

Windows 에서 특정 포트가 안 죽는 것처럼 보일 때 (netstat PID가 죽지 않는 이유)

devhyen — Thu, 29 Jan 2026 16:00:59 +0900

파이썬 웹서버를 띄우다 보면 가끔 일어나는 일인데 제대로 정리된 블로그 글을 찾기 힘들어서

직접 작성했습니다.

상황

로컬에서 API서버 (python fastAPI)을 돌리다가 재실행 하려고 하는데 8000포트가 계속 점유된 것 처럼 보였다.

netstat으로 확인하면 분명 LISTENING 이 있는데, taskkill은 "프로세스를 찾을 수 없습니다" 라고 뜨는 상황

netstat -abno | findstr /i ":8000"
TCP  0.0.0.0:8000  0.0.0.0:0  LISTENING  42424
taskkill /F /T /PID 42424
오류: 프로세스 "42424"을(를) 찾을 수 없습니다.
Get-Process -Id 42424
프로세스를 찾을 수 없습니다.

하지만 해당 8000번 포트는 계속 살아있는 상태이고,

서버를 재시동 하기 어려운 상황이었다.

해결방법

Get-Process python
# python PID = 22736
taskkill /F /T /PID 22736
성공: PID 22736인 프로세스(PID 42424인 자식 프로세스)가 종료되었습니다.

파이썬의 pid를 확인해서

taskkill을 시키니 포트가 정상 해제 되었다.

왜 이런일이 생기는가

netstat이 보여주는 PID는 그 순간의 스냅샷이다.
개발 서버(특히 --reload 켠 uvicorn 같은 것)는 부모 프로세스 + 자식 워커 프로세스 구조로 뜨는 경우가 많다.
그래서 포트를 잡던 “자식 PID(42424)”가 이미 종료됐거나 바뀌었는데, 내가 그 PID로 죽이려 하면 이미 없는 프로세스라 “찾을 수 없음”이 뜰 수 있다.
실제로 서버를 유지하고 다시 워커를 띄우는 “부모 python(22736)”이 남아있으면, 포트 점유가 계속되는 것처럼 느껴진다.

즉, “포트가 안 죽는 게 아니라”내가 죽이려던 PID가 이미 죽었고, 진짜 주범은 다른 PID(부모 python)였던 것.

TIME_WAIT

netstat에 TIME_WAIT가 보이면 포트가 살아있다고 생각할 수 있는데, TIME_WAIT는

서버가 리슨중이라서 점유하는 상태가 아니라

종료된 TCP 연결이 정리되는 과정이라서

보통 기다리면 사라진다.

결론

개발 서버에서 이런 일이 잦다면, 그냥 python 프로세스 목록을 보고 “내가 띄운 서버”의 커맨드라인을 확인한 뒤 종료하는 게 제일 빠르다.

Windows 11 KB5074109(2026-01-13) 정리

devhyen — Thu, 15 Jan 2026 10:55:18 +0900

https://support.microsoft.com/ko-kr/topic/2026%EB%85%84-1%EC%9B%94-13%EC%9D%BC-kb5074109-os-%EB%B9%8C%EB%93%9C-26200-7623-%EB%B0%8F-26100-7623-3ec427dd-6fc4-4c32-a471-83504dd081cb

2026년 1월 13일 — KB5074109(OS 빌드 26200.7623 및 26100.7623) - Microsoft 지원

2026년 1월 보안 업데이트부터 Windows Server 2025에는 자체 KB 식별자와 빌드 번호가 있습니다. 이 변경 내용은 Windows Server 2025에만 적용됩니다. Windows 11, 버전 24H2 또는 Windows 11 버전 25H2에 대한 업데이

support.microsoft.com

- WSL 네트워킹(미러링) 실패, VPN 연결 후 회사 리소스 접근 문제, Azure Virtual Desktop RemoteApp 연결 실패 같은 네트워크 이슈 수정이 포함됩니다.
- NPU 탑재 기기에서 유휴 상태 전력 소모 증가 이슈를 개선합니다(전력/배터리 체감 가능).
- 특정 레거시 모뎀 드라이버가 제거되어, 해당 하드웨어는 더 이상 동작하지 않을 수 있음(특수 케이스 주의).

업데이트 체감 가능 변경점

(1) WSL 네트워킹(미러링) 문제 수정

공식 문서에 따르면 WSL에서 미러링 네트워킹이 실패하면서
호스트에 대한 경로가 없습니다 류의 오류가 발생할 수 있는 문제를 수정합니다.

WSL을 개발 환경으로 쓰는 경우(로컬 ↔ 컨테이너/리눅스 툴체인), 네트워크가 꼬이면 체감이 큽니다.
“갑자기 WSL에서 외부 접근/사내 접근이 안 된다” 유형이면 이번 수정의 직접 수혜일 가능성이 있습니다.

(2) VPN 연결 후 회사 리소스 접근 불가 문제 수정

VPN은 “연결은 되는데 사내 리소스(예: Git, 사내 DNS, 프록시, 파일 서버)가 안 붙는” 경우가 흔한데, 문서에 이 케이스가 명시돼 있습니다.

원격근무/사내망 개발환경(사내 패키지 레지스트리, 내부 도메인)을 쓰는 사람에게는 중요 포인트입니다.

(3) Azure Virtual Desktop(AVD) RemoteApp 연결 실패 수정

AVD/RemoteApp을 업무용으로 쓰는 조직에서는 “업데이트 후 갑자기 RemoteApp이 안 뜸”이 가장 위험한 유형인데, 이번에 그 이슈가 수정 항목으로 들어가 있습니다.

(4) 전력/배터리: NPU 장치 유휴 전력 이슈 개선

Copilot+ PC 같은 NPU 탑재 기기군에서 유휴 상태 전력 소모가 커질 수 있는 문제를 해결한다고 안내합니다.
→ 노트북 사용자라면 배터리/발열/팬 동작이 완화될 여지가 있습니다.

CORS를 제대로 이해하고 안전하게 설정하기

devhyen — Mon, 12 Jan 2026 18:44:29 +0900

CORS?

서버 보안 기능이 아니라 브라우저 정책!

CORS(Cross-Origin Resource Sharing)의 본질은 브라우저의 동일 출처 정책(Same-Origin Policy SOP)을 예외적으로 완화하기 위한 규칙입니다.

보통 개발자는 "프론트에서 API호출이 실패했다"라고 이해하고, console창에 "blocked by CORS policy"라고 뜨기 때문에, 서버가 막았다고 생각할 수 있습니다.

실제로는 브라우저가 응답을 JS에 전달하지 않은 것인데, 실패 지점이 백엔드처럼 보입니다.

또한, 해당 에러는 Access-Control-Allow-Origin 같은 헤더를 추가하면 문제가 해결되기 때문에 오해할 수 있습니다.

즉 CORS는 서버가 막는게 아니라 브라우저가 막는 것이고, 서버는 이 Origin에게는 읽을 수 있게 해도 된다는 허가증(헤더)를 발급할 뿐이고, 그 허가증을 확인해서 통과시킬지 말지 결정하는 문지기는 브라우저입니다.

그렇다면, SOP은 왜 있는걸까?

서로 다른 사이트들이 한 브라우저 안에서 같이 돌아가는 환경이기 때문입니다.

기본적으로 다른 사이트에서 사용자가 로그인해둔 사이트의 권한을 가로채지 못하게 격리하기 위해서입니다.

웹은 기본적으로 악성사이트를 방문할 수 있다는 위협 모델이 있습니다. 사용자는 여러 사이트에 로그인한 상태로 웹 서핑을 합니다. 이 때 사용자가 하나라도 악성사이트를 방문하게 되면 그 페이지의 JS가 사용자의 브라우저에서 실행됩니다.

SOP가 없다면, 악성사이트의 JS가 사용자의 쿠키/세션이 실린 요청을 보내고 응답내용을 자기의 서버로 빼돌릴 수 있습니다.

즉, 다른 출처의 응답을 스크립트가 마음대로 읽지 못하게 해서 데이터의 탈취를 막습니다.
브라우저는 자동 첨부 권한인 쿠키/세션으로 인해 편의성이 있지만, 격리가 없다면 권한위임/탈취의 문제가 됩니다. SOP은 자동권한에 있어서도 안전장치를 제공할 수 있습니다.

웹은 광고/위/서드파티스크립트/여러탭/여러도메인 링크로 자유롭게 이동하는 구조이기 때문에 기본적으로 격리되어야합니다. SOP이 웹 보안의 기본 격리 모델입니다.

그렇지만, 요즘의 웹앱은 프론트와 API가 나뉘는 경우가 많습니다. 그래서 SOP의 예외 규칙이 필요합니다. 여기서 CORS가 예외규칙입니다.

Origin 판단 기준

- schema : http/https

- host : example.com

- port : 80/443/3000 등

3가지 모두 같은지로 판단 됩니다.

내 요청은 왜 두 번 날아갈까? (Preflight와 Simple Request)

개발을 하다 보면 네트워크 탭에 분명 API를 한 번 호출했는데, 요청이 두 번 잡히는 경우를 볼 수 있습니다. 자세히 보면 첫 번째 요청의 메서드가 GET이나 POST가 아니라 OPTIONS로 되어 있죠.

이것이 바로 Preflight(예비 요청)입니다.

브라우저는 요청을 크게 두 가지로 나눕니다.

1) 단순 요청 (Simple Request) 브라우저가 보기에 "이 정도는 안전하다"고 판단하는 요청입니다.

메서드가 GET, POST, HEAD 중 하나이고,
Content-Type이 application/x-www-form-urlencoded, multipart/form-data, text/plain 같은 기본적인 것들일 때입니다.
커스텀 헤더가 없어야 합니다.
이때는 예비 검사 없이 서버에 바로 요청을 보냅니다. (물론 SOP 위반 시 응답은 브라우저가 가립니다.)

2) 예비 요청이 필요한 경우 (Preflight) 하지만 요즘 우리는 대부분 JSON(application/json)으로 통신하거나, Authorization 헤더에 토큰을 실어 보냅니다. 브라우저 입장에서 이건 "단순하지 않은, 서버 데이터에 부작용을 일으킬 수 있는 요청"입니다.

그래서 본 요청을 보내기 전에 OPTIONS 메서드로 서버를 먼저 찔러봅니다.

브라우저: "나 application/json 데이터 보낼 건데, 받아줄래?" (OPTIONS 요청)
서버: "어, 그 출처(Origin)라면 허용해. POST 메서드 써도 돼." (200 OK)
브라우저: "확인했어. 이제 진짜 데이터 보낼게." (본 요청 POST)

CORS 에러는 주로 이 예비 요청 단계에서 서버가 허가증(헤더)을 제대로 주지 않아 발생합니다. 네트워크 탭에서 OPTIONS 요청이 빨간색으로 실패했다면, 서버 설정을 먼저 확인해야 합니다.

로그인이 왜 안될까(쿠키가 안넘어감)

CORS 설정을 다 했는데 쿠키가 안넘어갈 수 있는데, 이것도 SOP의 목적과 관련있습니다.

기본적으로 브라우저는 다른 출처로 요청을 보낼 때, 쿠키/인증헤더 같은 민감한 정보는 함부로 담지 않습니다.

이를 해결하기 위해서는 클라이언트와 서버 양쪽에 명시해야합니다.

1) 클라이언트 (프론트) : 요청을 보낼 때 인증정보도 함께 보낸다고 명시해야합니다.

axios의 경우: withCredentials: true 옵션 필수
fetch의 경우: credentials: 'include' 옵션 필수

2) 서버 (백엔드) : 응답 헤더에 인증정보를 받아도 된다고 허락해야합니다.

Access-Control-Allow-Credentials: true

참고) Credentials를 true로 설정하는 순간,
Access-Control-Allow-Origin 헤더에는 절대로 와일드카드(*)를 쓸 수 없습니다.
이 경우 와일드카드(*) 대신 정확한 출처(Origin)를 명시해서 내려줘야 합니다.

Access-Control-Allow-Origin: * (모든 곳 허용)

퍼블릭 API 라면 상관없지만, 민감한 정보를 다루는 서비스라면 매우 위험합니다.

SOP라는 방어막을 서버가 스스로 무력화 시킬 수 있습니다.

서버간 통신이 유리한 이유

지금까지 CORS의 원리와 안전하게 설정하는 법을 알아봤습니다.

하지만, 보안 관점에서 "꼭 브라우저에서 그 API를 직접 호출해야만 할까요?"

서버끼리는 SOP가 없습니다.

SOP은 브라우저의 보안 정책입니다. 즉, api 서버 -> api 서버를 호출할때는 CORS 검사가 아예 발생하지 않습니다. preflight (두번 호출) 로 인한 네트워크 낭비도 없습니다.

가장 중요한 이유는 보안 입니다.
만약 프론트엔드에서 직접 타사 API를 호출한다면 필연적으로 API key나 인증 토큰이 브라우저에 노출됩니다. 개발자 도구만 열어도 누구나 그 키를 볼 수 있습니다.

하지만 proxy 방식을 사용하면

1. 프론트엔드 : 같은 도메인에 요청을 보냅니다.

2. 백엔드 : 숨겨진 비밀 키를 사용해 API 서버와 통신합니다.

3. response : 받은 데이터만 프론트에 전달합니다.

Admin API나 결제 API처럼 민감한 권한이 필요한경우

API key가 외부에 절대 노출되면 안되는경우

CORS설정 권한이 없는 외부 서버와 통신해야할 때 는 서버간 통신(proxy)를 권장합니다.

그럼에도 불구하고 CORS를 써야하는 경우

클라이언트가 직접 CDN이나 퍼블릭 API 데이터를 가져와야할 때

서버를 거치지 않고 빠른 속도로 대용량 파일을 다운로드/업로드 할 때

결국 CORS는 브라우저의 보안을 잠시 꺼주는 예외 규칙일 뿐입니다. 보안이 중요한 기능이라면 억지로 CORS를 뚫으려고 하기 보다는 백엔드에서 처리하는 서버간 통신을 우선 고려하는 것이 좋습니다.

왜 FastAPI는 http로 리다이렉트 될까? Nginx 프록시 환경에서 발생하는 Redirect 문제

devhyen — Wed, 17 Dec 2025 15:12:42 +0900

FastAPI + Nginx 조합으로 서비스를 배포할 때 가장 자주 겪는 문제 중 하나가 있다.

HTTPS 로 접속했는데 왜 HTTP로 리다이렉트 된다.
"/"로 끝나는 경로만 리다이렉트가 발생한다.

이 문제는 단순히 서버 한 곳의 문제가 아니라,

FastAPI의 URL 정책, Nginx의 프록시 동작, Uvicorn의 proxy 설정 문제가 서로 엇갈리면서 발생하는 현상이다.

전체구조 - Nginx는 HTTPS 종료 지점 이다.

우리가 사용하는 구조는 대부분 아래와 같다.

클라이언트는 HTTPS로 접속하지만, FastAPI는 내부적으로 HTTP로 톧신한다.

즉, Nginx가 SSL을 종료하고 내부 FastAPI로 요청을 넘겨주는 구조다.

FastAPI는 원래 요청이 HTTPS였는지 알 수 없다.
Nginx가 Forwarded 헤더들을 제대로 전달하지 않으면 FastAPI는
HTTP로 들어왔다고 판단한다.

이것이 잘못된 redirect를 만드는 첫번째 원인이다.

Nginx의 proxy_pass

location /mm/ {
    proxy_pass http://backend:4000/mm/;
}

위 설정은 다음과 같이 동작한다.

클라이언트 요청
https://example.com/mm/users/list

Nginx가 백엔드로 전달하는 요청
http://backend:4000/mm/users/list

여기까지는 문제없다.

하지만, FastAPI가 리다이렉트를 발생시키기 시작하면 상황이 달라진다.

FastAPI는 왜 redirect를 만드는가

FastAPI(Starlette)는 URL 끝 슬래시(/) 를 엄청 중요하게 본다.

예를들어 라우트를 이렇게 정의했다면

@app.get("/mm/user/list/")

클라이언트는 이렇게 요청하면

/mm/user/list

FastAPI는 바로 이렇게 판단한다.

슬래시가 빠졌네, 원래 URL은 /list/ 다
➡️ 307 Temporary Redirect 발생

반대 케이스도 마찬가지이다.

즉, FastAPI는 라우트의 슬래시와 요청 슬래시가 다르면 무조건 redirect를 발생시킨다.

참고용 프레임워크 기본 동작 리다이렉트 여부

프레임 워크	기본 동작
FastAPI	자동 리다이렉트
Django	자동 리다이렉트
Spring Boot	리다이렉트 안 함
NestJS	설정에 따라 다름
Express.js	리다이렉트 안 함
Flask	리다이렉트 안 함
ASP.NET Core	리다이렉트 안 함

리다이렉트를 안하는 경우에는 정확히 일치하는 경로만 매칭되고, 그렇지 않으면 404를 반환한다.

따라서 슬래시 정책이 맞지 않으면 redirect는 무조건 한 번 발생한다.

문제는 그 redirect URL이 엉망이 될 수 있다는 점이다.

FastAPI가 redirect URL을 HTTPS ➡️ HTTP 로 잘못되게 만드는 이유

FastAPI는 redirect Location을 만들 때 다음 값을 참고한다.

Host
Scheme(http/https)
Port

하지만 Nginx가 이것을 제대로 전달하지 않으면 https를 http로 redirectLocation이 만들어진다.

이게 브라우저로 그대로 전달되면

Mixed Content 정책 위배 ! !

Mixed Content: The page at 'https://example.com' was loaded over HTTPS, 
but requested an insecure resource 'http://example.com/api'. 
This request has been blocked; the content must be served over HTTPS.

가 된다...

uvicorn에서 --proxy-headers 옵션

Nginx는 원래 요청 정보를 FastAPI에 알려주려고 이런 헤더를 넣는다.

X-Forwarded-Proto: https
X-Forwarded-Host: example.com
X-Forwarded-Port: 443

하지만, 문제는

Uvicorn은 기본적으로 이 헤더들을 신뢰하지 않는다.

보안 때문인데, 해커가 헤더를 조작할 수도 있기 때문이다.

그래서 FastAPI에게 믿어도 된다는 옵션을 줘야한다.

그 옵션이

--proxy-headers

이다.

해결방법

1. 슬래시(/) 정책 통일

라우트와 프론트 호출 URL을 둘 다 /path 또는 둘 다 /path/ 로 맞추기
- 일반적으로 REST API 관례 상 '/path' 트레일링 슬래시 (Trailing Slash) 없음 으로 진행해야합니다.
- 예외
1. 디렉토리/컬렉션을 명시적으로 표현할 때: `/static/images/`, `/api/users/` (컬렉션)
2. 루트 경로: `/` (HTTP 요청에서 경로 부분이 비어있거나 `/`인 경우)

2. Nginx에서 헤더 정확히 넘기기

proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Port $server_port;

3. uvicorn에서 proxy headers 활성화

uvicorn main:app --host 0.0.0.0 --port 4000 --proxy-headers

FastAPI + Nginx 환경에서 HTTPS 가 HTTP로 튀는 문제는

결국 FastAPI의 슬래시 redirect + Nginx의 헤더 처리 + uvicorn proxy 설정이 서로 맞지 않아 발생하는 현상이다.

이 세 가지를 올바르게 잡아주면 redirect 문제는 해결된다.

Ai가 브라우저 보는 눈 : Cursor에서 Browser Tools MCP 사용하는 방법 (윈도우 + WSL)

devhyen — Fri, 24 Oct 2025 09:04:25 +0900

Browser tools mcp 는 AI가 실제 브라우저와 연결되어 웹 페이지의 행동 데이터를 직접 수집 이해할 수 있게 해주는 도구입니다.

장점

1. 콘솔로그 네트워크 요청 스크린샷 등을 자동으로 캡쳐해서 디버깅이나 테스트에 활용 가능

2. AI가 실제 브라우저 동작을 관찰하므로, 코드만이 아니라 실행 결과까지 분석 가능

3. 웹 페이지 UI변화나 오류를 시각적으로 파악할 수 있어 QA, 프론트엔드 디버깅에 유용.

4. 로컬 테스트 자동화에 적합.

5. AI가 웹을 직접 보는 눈 을 갖게 되어 코드와 화면을 함께 이해하는 개발 지원 가능.

사용방법

브라우저 툴 MCP를 cursor AI에서 사용하기 위해서는
1. 크롬 익스텐션
2. 커서 연동
3. 서버 실행
의 단계가 필요합니다.

크롬 익스텐션 설정

1. https://github.com/AgentDeskAI/browser-tools-mcp 에서 git clone을 받습니다.

git clone https://github.com/AgentDeskAI/browser-tools-mcp.git

2. chrome://extensions/

크롬 익스텐션 설정 페이지에서 개발자 모드를 키고,

압축해제된 확장 프로그램 로드를 눌러서 방금 받은 chrome-extension 폴더를 선택합니다.

3(선택).

보안을 위해 세부정보 > 사이트 액세스 > 로컬호스트만 추가합니다.

커서 연동

커서 우측 상단에 있는 톱니바퀴 아이콘 클릭하면 설정창입니다.

Tools&MCP > New MCP Server를 누르면 mcp.json이 뜨는데 아래 코드를 작성합니다.

{
  "mcpServers": {
    "browser-tools": {
      "command": "npx.cmd",
      "args": ["-y", "@agentdeskai/browser-tools-mcp@latest"]
    }
  }
}

WSL(Ubuntu)환경에서의 MCP 설정

윈도우에서는 위 설정으로 잘 되었지만, wsl ubuntu에서는 cursor가 mcp를 인식하지 못했습니다.

방법을 찾아서 했더니 성공했고 공유합니다.

WSL 내부의 Node.js 경로를 Cursor가 직접 인식 못하는 경우가 있습니다. 이럴 땐 mcp.json에서 절대경로로 Node 실행 경로를 지정해야합니다.

{
  "mcpServers": {
    "browser-tools": {
      "command": "/home/hyen/.nvm/versions/node/v22.21.0/bin/npx",
      "args": ["-y", "@agentdeskai/browser-tools-mcp@latest"]
    }
  }
}

* 경로는 본인의 wsl 에서 which npx 를 통해 알라낸 경로로 수정해야 합니다.

Node를 nvm으로 설치한 경우, 경로는 /home/사용자명/.nvm/versions/node/... 형태로 설정됩니다.

mcp 서버 실행

npx @agentdeskai/browser-tools-server@latest

이 과정을 거치면

크롬 개발자모드 (F12)에서 BrowserToolsMCP가 잘 연결되어 있음을 볼 수 있습니다.

사내 개발 스터디 : 첫 세미나 발표 회고

devhyen — Tue, 5 Aug 2025 22:31:49 +0900

2025.07.04 - [회고] - 사내 개발 스터디를 만들었습니다

사내 개발 스터디를 만들었습니다

회사에서 개발자들과 기술 이야기를 나누는 방법 크래프톤정글과 팀메이트 활동을 하며 서로 다른 회사를 다니고, 서로 다른 분야의 개발을 하는 사람들이지만개발자들과 기술 이야기를 나눌

devhyen.tistory.com

사내 개발 스터디를 만든 후

첫 세미나 발표를 끝냈다.

기획

모두의 퇴근 후 시간이 소중하기에, 6시부터 7시까지 한 시간으로 짧고 굵게 준비했다.

세미나는 매달 말 진행하기로 했고, 이번엔 동호회 창립 후 첫 세미나였기에, 서로의 일정을 조율하다 보니 7월 세미나가 8월 초에 진행되었다.

앞으로 날짜를 고정으로 진행하게 될 듯 하다.

월간 세미나에서는 3명의 발표자를 자원받는다.

다행히 첫 세미나지만 3명(나포함)이 자원했고,

한 시간이라는 제한된 시간 때문에 발표 시간이 다소 타이트하게 배분되었다.

발표가 끝난 후

빠른 투표와 시상식을 한 후 기념하기위한 단체 사진 촬영을하고 마무리하기로 했다.

canva로 예쁘게 포스터와 타임테이블도 만들었다.

세미나 준비

운영진들은 미리 모여 포스터도 붙이고, 화면에 자료를 띄우는 등 준비를 했다.

동호회를 처음 만들 때, 운영진을 아무도 지원하지 않을까봐 걱정했는데,

감사하게도 부회장님, 기획님, 총무님 같은 분들이 자발적으로 나서주셔서 감사했다.

공주들이 준비중인 우리를 사진도 찍어줬다.

발표

첫번째 발표는 내가 했다.

간단하게 토이프로젝트를 만드는 방법에 대해서 설명했다.

부담갖지 않고 웹 사이트를 만들기 위해서 next.js + vercel + firebase로 쉽게 만들수 있음을 설명드렸고

모두가 경청해주셔서 감사한 마음이었다.

두번째 발표는

회사에 비개발직군이신 분이신데 놀랍게도 퇴근후 밤에는 VR게임을 개발하시는 분의 이야기이다.

바이브 코딩을 잘 하는 법에 대해 설명해주셨는데, 실무에 바로 활용할 수 있게끔 설명을 잘 해주셔서 큰 도움이 되었다.

또한, VR게임에 대해 잘 몰랐는데 어떤식으로 개발해야하는지를 이야기해주셔서 흥미로웠다.

세번째 발표는

도커와 쿠버네티스의 기초이야기였다.

백엔드개발을 하다보면 도커를 필연적으로 사용하게 된다. 특히 현재 회사의 서비스들은 각각 도커에 올라가는 구조라서 쿠버네티스와 도커를 사용하고 있는데, 역시 데브옵스팀이셔서 전문가가 설명해주시는건 정말 도움이 되었다.

다음에 또 기회가 되면 그 다음 과정으로 해주시면 좋을 것 같다.

최고 최고

아쉬운점

시간이 정말 촉박했다.

각자 15~20분정도 시간분배는 발표하기엔 너무 짧은 시간임을 깨달았다.

다음부터는 발표 시간을 20~30분으로 넉넉하게 잡고, 총 진행 시간을 2시간으로 늘려서 Q&A와 가벼운 네트워킹 시간을 더 여유롭게 가졌으면 좋겠다.

추후에 운영진회의를 통해 좀 더 좋은 세미나를 기획해보려고 한다!

배가 너무 고팠다.

퇴근 후 저녁 시간이라는 점을 간과했다.

다음엔 회비로 간식도 좀 구비하면 좋겠다는 생각이 들었다.

그 외에 모든 건 좋았던 세미나였다.

다음에는 시간도 넉넉하게 짜고,

모두의 소중한 시간을 더 값진 시간을 보낼 수 있게 기획해야겠다.

PKCE란? OAuth2 인증을 안전하게 만드는 핵심 보안 메커니즘

devhyen — Tue, 22 Jul 2025 14:05:38 +0900

PKCE란?

proof key for code exchange

OAuth2에서 Authorization code flow 를 더 안전하게 만들기 위해 고안된 보안 메커니즘

Authorization Code Flow 의 문제점

Authorization Code Flow는

앱이 사용자에게 로그인 페이지를 열고
로그인 후 code를 redirect로 전달받고
그 code를 가지고 서버에서 토큰을 받아오는 구조

→ 이 과정에서

code가 노출되면 해커가 가로채서 토큰을 받아갈 수 있음
모바일 앱이나 SPA는 client_secret을 숨기기 어려움
브라우저 히스토리, 네트워크 로그 등에서 탈취 가능

어떻게 PKCE가 해결 할까?

앱이 인증 요청할 때 "나는 이 인증 코드를 요청한 진짜 앱이다" 라는 증명(Proof)를 같이 보낸다.

code_verifier	앱이 만든 랜덤 문자열 (증명본 원본)
code_challenge	code_verifier를 SHA256으로 해시한 값 (서버로 전달)

위 도식은 PKCE (Proof Key for Code Exchange)를 사용하는 OAuth2 Authorization Code Flow의 전체 과정을 정리한 것입니다.

모바일 앱이나 SPA 같은 공개 클라이언트 환경에서는 client_secret을 안전하게 보관하기 어렵기 때문에, PKCE를 통해 code를 요청한 주체가 토큰 요청도 같은 주체라는 것을 증명하게 됩니다.

클라이언트는 먼저 code_verifier를 생성하고, 이를 기반으로 code_challenge를 계산해 Authorization Server(Hydra)에 인증 요청을 보냅니다.
Authorization Server는 사용자가 로그인하지 않은 경우, 로그인 UI를 제공하는 Identity Provider(예: Ory Kratos)로 redirect합니다.
사용자가 로그인하면, Hydra는 code를 발급하고 클라이언트의 redirect_uri로 전달합니다.
클라이언트는 받은 code와 함께 code_verifier를 사용해 토큰을 요청하며, 서버는 이 값을 검증하여 access token 또는 ID token을 발급합니다.

이 과정에서 state 파라미터는 CSRF 공격을 방지하기 위해 사용되며, 클라이언트가 임의의 값을 설정하여 요청마다 다르게 유지하는 것이 권장됩니다.

PKCE는 별도의 client secret 없이도 안전하게 인증 흐름을 구성할 수 있게 해 주며, 특히 모바일/SPA 환경에서는 사실상 필수적인 보안 구성입니다.

PKCE 구현 시 주의할 점

code_challenge_method는 반드시 `S256`(SHA256)을 쓰는 게 보안상 안전하며, 대부분의 Authorization Server는 이 방법만 지원합니다.
code_verifier는 클라이언트가 임의로 만든 값이며, 길이는 43~128자 사이의 랜덤 문자열이 좋습니다.
redirect_uri는 사전에 Authorization Server에 등록된 값과 정확히 일치해야 합니다. 특히 모바일 앱의 딥링크는 scheme까지 포함해 등록해야 합니다.
CSRF 방지를 위해 항상 state 파라미터를 설정하고, 응답 시 값이 일치하는지 확인해야 합니다.
토큰 요청 시 client_secret은 사용하지 않습니다 (token_endpoint_auth_method=none).

혠의 기술블로그

[스프링으로 배우는 안티패턴] Spring Security 6.3 부터는 왜 직렬화 버전(SERIAL_VERSION_UID)를 삭제했을까?

serialVersionUID 란?

Spring Security에서 SERIAL_VERSION_UID

SERIAL_VERSION_UID 가 안티패턴인 이유

개선 방법

교훈

[Elasticsearch] Low Level Client 6.x에서 Java API Client 9.x 마이그레이션 트러블슈팅

마이그레이션 하게된 배경

이미 돌아가는 코드를 고치게 되다 .. 왜 ? ?

1. _id 필드에 대한 메모리 로딩 기본적 차단 이슈 문제 현상

해결 방법 : _id에서 _shard_doc으로의 전환

2. typed_keys 이슈

문제 현상

원인 분석

해결 방법

느낀점

AI 시대의 사이버보안, Anthropic의 ‘Project Glasswing’가 의미하는 것

왜 지금 사이버보안이 더 중요해졌을까

Claude Mythos Preview가 보여준 것

왜 이 발표가 중요한가

참여 기업들이 본 현실

Anthropic의 계획

하지만 일반 공개는 하지 않는다

결국 이 발표가 우리에게 말하는 것

한줄 정리

Windows 에서 특정 포트가 안 죽는 것처럼 보일 때 (netstat PID가 죽지 않는 이유)

상황

해결방법

왜 이런일이 생기는가

TIME_WAIT

Windows 11 KB5074109(2026-01-13) 정리

업데이트 체감 가능 변경점

(1) WSL 네트워킹(미러링) 문제 수정

(2) VPN 연결 후 회사 리소스 접근 불가 문제 수정

(3) Azure Virtual Desktop(AVD) RemoteApp 연결 실패 수정

(4) 전력/배터리: NPU 장치 유휴 전력 이슈 개선

CORS를 제대로 이해하고 안전하게 설정하기

CORS?

그렇다면, SOP은 왜 있는걸까?

Origin 판단 기준

내 요청은 왜 두 번 날아갈까? (Preflight와 Simple Request)

Access-Control-Allow-Origin: * (모든 곳 허용)

서버간 통신이 유리한 이유

그럼에도 불구하고 CORS를 써야하는 경우

왜 FastAPI는 http로 리다이렉트 될까? Nginx 프록시 환경에서 발생하는 Redirect 문제

전체구조 - Nginx는 HTTPS 종료 지점 이다.

Nginx의 proxy_pass

FastAPI는 왜 redirect를 만드는가

FastAPI가 redirect URL을 HTTPS ➡️ HTTP 로 잘못되게 만드는 이유

uvicorn에서 --proxy-headers 옵션

해결방법

1. 슬래시(/) 정책 통일

2. Nginx에서 헤더 정확히 넘기기

3. uvicorn에서 proxy headers 활성화

Ai가 브라우저 보는 눈 : Cursor에서 Browser Tools MCP 사용하는 방법 (윈도우 + WSL)

장점

사용방법

크롬 익스텐션 설정

커서 연동

mcp 서버 실행

사내 개발 스터디 : 첫 세미나 발표 회고

기획

세미나 준비

발표

아쉬운점

PKCE란? OAuth2 인증을 안전하게 만드는 핵심 보안 메커니즘

PKCE란?

Authorization Code Flow 의 문제점

어떻게 PKCE가 해결 할까?

PKCE 구현 시 주의할 점

1. _id 필드에 대한 메모리 로딩 기본적 차단 이슈
문제 현상