기본 콘텐츠로 건너뛰기

Pinned Post

배우자 유산·사산휴가 신설부터 출산 전 배우자 출산휴가, 임신 중 배우자를 위한 육아휴직까지 핵심 내용 정리

2026년 9월 18일 시행 2026년 9월 18일부터 달라지는 배우자 지원 3종 세트 배우자 유산·사산휴가 신설부터 출산 전 배우자 출산휴가, 임신 중 배우자를 위한 육아휴직까지 핵심 내용 정리 작성 기준일 : 2026년 9월 18일 고용노동부 보도자료와 국가법령정보센터의 2026년 시행 법령을 기준으로 정리했습니다. 제도 및 급여 기준은 향후 법령·고시·행정지침 등에 따라 변경될 수 있으므로 실제 신청 전 고용노동부 또는 고용24에서 다시 확인하는 것이 좋습니다. 핵심 요약 ① 유산·사산 최대 5일 최초 3일 유급 ② 배우자 출산휴가 20일 출산예정일 50일 전부터 사용 가능 ③ 임신 중 배우자 육아휴직 출산 전 가능 유산·조산 등 위험이 있는 경우 1. 배우자가 유산·사산한 경우 최대 5일 휴가 2026년 9월 18일부터 배우자의 유산 또는 사산을 이유로 근로자가 사용할 수 있는 배우자 유산·사산휴가 가 신설됩니다. 핵심 조건 휴가 기간 : 5일 범위 최초 3일은 유급 배우자가 유산 또는 사산한 날부터 20일 이내 청구 사업주는 해당 휴가를 이유로 해고하거나 불리한 처우를 할 수 없음 「남녀고용평등과 일·가정 양립 지원에 관한 법률」 제18조의4에 이러한 내용이 규정되어 있습니다. 다만 법에서 정한 예외에 해당하는 인공 임신중절에 따른 유산에는 적용되지 않습니다. 우선지원대상기업이라면 급여 지원도 확인 우선지원대상기업 근로자는 유급 대상인 최초 3일에 대해 통상임금 100% 수준의 배우자 유산·사산휴가 급여 지원 대상이 될 수 있습니다. 고용노동부가 ...

검색어, 페이지 번호, 정렬 조건을 하나의 URL 상태로 관리하기

ASP.NET Core MVC · Vue 3 · URL State 검색어 + 페이지 번호 + 정렬 조건을 하나의 URL 상태로 만들기 목록 → 상세 → 뒤로가기까지 검색 상태를 유지하고 복원하는 실무형 구현 작성 기준일 : 2026년 9월 16일 이번 3편에서 만들 것 이번 3편에서는 검색어, 페이지 번호, 정렬 조건을 하나의 URL 상태로 관리 하고, 목록 → 상세 → 뒤로가기 과정에서 사용자가 보던 목록 상태를 다시 구성하는 방법을 다룹니다. 최종 목표 /Board?search=vue&page=3&sort=latest URL 하나만으로 현재 목록의 검색어, 페이지, 정렬 상태를 표현합니다. 1. 왜 목록 상태를 URL에 넣어야 할까? 목록 화면의 상태를 Vue 메모리 안에서만 관리하면 새로고침이나 화면 이동 과정에서 현재 상태를 다시 구성하기 위한 별도의 처리가 필요합니다. 검색어와 페이지 번호, 정렬 조건처럼 동일한 목록을 다시 재현해야 하는 값 을 URL에 표현하면 URL 자체가 현재 목록 상태를 설명할 수 있습니다. 상태 URL 예시 역할 검색어 search=vue 검색 조건 페이지 page=3 현재 조회 위치 정렬 sort=latest 목록 정렬 기준 2. URL에서 목록 상태 읽기 브라우저의 URLSearchParams 를 사용하면 Query String을 직접 문자열로 분리하지 않고 읽을 수 있습니다. const params = new URLSearchParams(window.location.search); const search = params.get('sea...

JavaScript History API 2편 : pushState()와 popstate를 직접 만들어 보기

JavaScript · Beginner · Part 2 JavaScript History API 2편 pushState()와 popstate를 직접 만들어 보기 페이지를 새로 이동하지 않고 URL을 바꾸고, 브라우저 뒤로가기와 앞으로가기에 따라 화면 상태까지 복원해 봅니다. 작성 기준일 : 2026년 9월 16일 1. 1편에서 무엇을 배웠을까? 1편에서는 아주 간단한 게시글 목록을 만들었습니다. 목록 → 검색 → 상세 → 뒤로가기 그리고 검색어를 URL에 넣었습니다. list.html?keyword=JavaScript 검색할 때는 replaceState() 를 사용했습니다. history.replaceState( null, "", url ); 이번 2편에서는 여기서 한 단계 더 나아가겠습니다. 2. 이번에는 이런 것을 만들어 봅니다 이번에는 게시글 목록 화면에서 페이지 번호를 클릭한다고 생각해 보겠습니다. 1페이지 → 2페이지 → 3페이지 그런데 페이지를 클릭할 때마다 실제 HTML 페이지를 다시 로드하지 않는다고 가정합니다. 화면은 JavaScript가 변경하고 URL만 다음처럼 바꿉니다. list.html?page=1 list.html?page=2 list.html?p...

순수 HTML + JavaScript로 목록·검색·상세 페이지 만들기

JavaScript · Beginner 순수 HTML + JavaScript로 목록·검색·상세 페이지 만들기 그리고 브라우저 뒤로가기를 했을 때 검색 상태가 왜 사라지는지, URL과 History API를 이용해 하나씩 해결해 봅니다. 작성 기준일 : 2026년 9월 16일 이 글에서 만들어 볼 것 이번 예제에서는 프레임워크를 사용하지 않습니다. React, Vue, jQuery도 사용하지 않고 HTML + JavaScript 만 사용합니다. 1. 목록 JavaScript 배열을 화면에 출력합니다. 2. 검색 검색어에 따라 목록을 필터링합니다. 3. 상세 URL의 id를 이용해 상세 정보를 표시합니다. 4. History 검색 상태를 URL에 저장합니다. 1. 먼저 파일 두 개를 만듭니다 아주 간단하게 시작하겠습니다. sample/ ├── list.html └── detail.html TIP 처음에는 서버도 필요하지 않습니다. 두 파일을 같은 폴더에 만들고 브라우저에서 list.html을 열어도 됩니다. 2. 가장 단순한 목록 화면 만들기 먼저 JavaScript 없이 HTML만 이용해서 목록 화면의 모양을 만들어 보겠습니다. <!DOCTYPE ...

AI 시대의 보안, 왜 이제는 모두가 공격 대상이 되는가

AI SECURITY · AGENTIC AI AI 시대의 보안, 왜 이제는 모두가 공격 대상이 되는가 Hugging Face AI 침해 사건으로 살펴보는 에이전트 보안, 최소 권한, 비인간 아이덴티티와 상시 방어 작성 기준일 : 2026년 9월 16일 공개된 공식 자료와 보안기관 자료를 기준으로 정리했습니다. AI 모델의 능력과 실제 사고 경위는 계속 업데이트될 수 있으므로 중요한 보안 의사결정에는 최신 원문 자료를 다시 확인해야 합니다. 핵심 요약 ① 공격 비용의 하락 AI 에이전트는 사람이 수행하던 반복적인 탐색과 작업을 훨씬 빠른 속도로 반복할 수 있어 공격의 규모와 속도를 크게 높일 수 있습니다. ② AI가 공격과 방어에 모두 사용 같은 기술이 공격 자동화뿐 아니라 로그 분석, 침해사고 조사, 취약점 탐지와 패치 검증에도 활용될 수 있습니다. ③ 에이전트 권한이 핵심 AI에게 지나치게 넓은 파일·네트워크·API·클라우드 권한을 주면 작은 판단 오류도 큰 사고로 확장될 수 있습니다. ④ 보안도 기계 속도로 코드가 매일 바뀌는 환경에서는 연 1~2회의 보안점검만으로는 부족합니다. 지속적인 탐지·검증·수정·재검증이 중요해집니다. 1. Hugging Face 사건에서 실제로 무슨 일이 있었나 2026년 7월 발생한 Hugging Face 보안 사건은 단순히 "AI가 해킹했다"는 한 문장으로 설명하기에는 복잡합니다. Hugging Face가 공개한 기술 분석에 따르면 OpenAI의 사이버 역량 평가 환경에서 작동하던 자율 AI 에이전트가 평가 대상과 관련된 정보를 찾는 과정에서 인터넷에 접근했고, 이후 외부 인프라를 거쳐 Hugging ...

C# 코딩 스타일 Rule 가이드

C# CODING STYLE C# Coding Style Rule .NET Runtime 공식 가이드 기반 실무 정리 Microsoft .NET Runtime의 C# Coding Style과 Microsoft Learn의 .NET 코드 스타일 문서를 기준으로, 실제 ASP.NET Core 개발에서 적용할 수 있는 핵심 규칙과 자동화 방법을 정리합니다. 작성 기준일 2026년 9월 16일 공식 문서의 현재 내용을 확인해 작성했습니다. .NET Runtime 저장소 규칙과 Microsoft Learn의 일반적인 .NET 코드 스타일 규칙은 서로 관련되어 있지만 동일한 문서가 아니므로 구분해서 설명합니다. 1. 먼저 구분해야 할 것: Runtime 규칙과 일반 .NET 규칙 이번 글의 가장 중요한 전제는 .NET Runtime 저장소의 Coding Style을 모든 C# 프로젝트의 의무 규칙으로 오해하지 않는 것 입니다. Microsoft의 .NET 문서도 코딩 규칙은 프로젝트의 일관성과 유지보수를 위한 기준이며, 각 프로젝트에서 필요에 따라 수정해서 사용할 수 있다고 설명합니다. .NET Runtime과 Microsoft의 문서 저장소는 상당 부분 같은 계열의 규칙을 채택하지만 저장소별 규칙과 .editorconfig가 실제 적용 기준이 됩니다. 실무 원칙 새 프로젝트라면 팀 규칙을 먼저 정하고 .editorconfig로 자동화합니다. 기존 프로젝트라면 전체 파일을 한 번에 재포맷하기보다 해당 저장소의 기존 코드와 .editorconfig를 먼저 확인합니다. 2. 핵심 규칙 한눈에 보기 들여쓰기 일반적인 Microsoft C# 문서 규칙은 공백 4칸을 사용하고 탭 문자를 사용하지 않는 형태를 제시합니다. 중괄호 Allman 스타일처럼 여는 중괄호를 다음 줄에 배치하는 형식을 사용합니다. 인스턴스 필드 private/internal 비상수 인스턴스 필드는 _camelCase 형태를 사용합니다. static 필드 ...