전체 글 448

리눅스 cgroup v2 pids.max 기준

리눅스에서 서비스별 프로세스 수를 제한할 때 pids.max를 단순한 PID 번호 제한으로 이해하면 판단이 흐려집니다. cgroup v2의 pids controller는 특정 cgroup 안에서 새 task가 더 만들어지는 것을 제한합니다. 여기서 task는 커널이 세는 TID 단위라서 일반적인 프로세스뿐 아니라 스레드도 개별적으로 포함됩니다.결론부터 말하면, pids.max는 fork 폭주나 과도한 스레드 생성이 한 서비스 밖으로 번지는 것을 막는 하드 경계입니다. systemd를 쓰는 환경에서는 대개 TasksMax=와 EffectiveTasksMax=를 먼저 보고, 필요할 때 해당 cgroup의 pids.current, pids.peak, pids.events를 같이 확인하면 됩니다.pids.max..

interpolate-size 기준

interpolate-size는 CSS transition이나 animation에서 숫자 길이와 intrinsic size keyword 사이를 보간할 수 있게 하는 속성입니다. 예전에는 height: 0에서 height: auto로 자연스럽게 전환하려고 임시 최대 높이, JavaScript 측정, transform 효과 같은 우회가 자주 필요했습니다. 이 속성은 그런 상황 중 일부를 CSS 값 단계에서 더 직접적으로 표현하게 해 줍니다.결론부터 말하면, 접히는 패널이나 내용 길이가 달라지는 카드처럼 auto, max-content, fit-content 같은 내용 기반 크기로 열리는 UI에는 interpolate-size: allow-keywords를 검토할 수 있습니다. 다만 2026년 10월 3일 ..

Git attributes 기준

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.Git attributes는 저장소 안의 특정 경로나 파일 패턴에 Git 동작 규칙을 붙이는 기능이다. 대표적으로 줄바꿈 정규화, diff 표시 방식, merge driver, export 제외, binary 파일 처리처럼 "모든 파일에 같은 규칙을 적용하면 곤란한" 영역에서 쓰인다.2026년 10월 3일 확인 기준 Git 공식 문서는 gitattributes 파일이 pathname에 attribute를 부여하는 단순한 텍스트 파일이라고 설명한다. 핵심은 프로젝트마다 공유해야 하는 규칙은 저장소의 .gitattributes에 두고, 개인 환경 차이는 Git config나 $GIT_DIR/info/attributes로 분리..

Python Executor.map buffersize 기준

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.Python Executor.map()의 buffersize는 병렬 작업을 만들 때 입력 iterable을 어디까지 미리 제출할지 제한하는 인자입니다. concurrent.futures를 이용해 긴 목록이나 생성기를 처리할 때, 결과를 아직 소비하지 않았는데 작업만 너무 많이 쌓이는 상황을 줄이는 데 쓰입니다.기준은 단순합니다. 입력이 작고 메모리 부담이 없다면 기본 동작으로도 충분합니다. 반대로 입력이 매우 길거나, 각 작업 인자가 크거나, 결과 소비 속도가 작업 제출 속도보다 느릴 수 있다면 buffersize를 지정해 제출 대기열을 제한하는 편이 안전합니다.기본 map은 무엇이 문제일 수 있나Python 공식 문서 ..

Nginx proxy_next_upstream 기준

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.Nginx proxy_next_upstream은 프록시 요청이 한 업스트림 서버에서 실패했을 때 다른 서버로 넘겨 볼 조건을 정하는 지시어다. 단순한 장애 자동 복구 옵션처럼 보이지만, 실제 기준은 더 좁다. 어떤 실패를 재시도로 볼지, 응답을 이미 클라이언트에 보냈는지, 쓰기 요청을 다시 보내도 안전한지까지 함께 봐야 한다.핵심 기준은 세 가지다. 첫째, error와 timeout 같은 네트워크 성격의 실패와 HTTP 상태 코드 기반 실패를 구분한다. 둘째, 클라이언트로 응답이 이미 전송되기 시작한 뒤에는 다음 업스트림으로 복구할 수 없다는 제한을 이해한다. 셋째, proxy_next_upstream_tries와 pro..

HTTP 425 Too Early 기준

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.HTTP 425 Too Early는 서버가 재전송될 수 있는 요청을 처리하지 않겠다는 신호입니다. 주로 TLS 1.3의 early data, 흔히 0-RTT라고 부르는 흐름과 함께 봅니다. 클라이언트가 핸드셰이크 완료 전에 요청을 먼저 보내면 지연은 줄일 수 있지만, 같은 요청이 다시 재생될 가능성을 서버가 고려해야 합니다.실무 기준은 단순합니다. 안전한 조회 요청은 early data 후보가 될 수 있지만, 결제·주문·쓰기·상태 변경 요청은 early data로 처리하지 않는 편이 안전합니다. 서버가 재전송 위험을 감수할 수 없으면 425로 거절하고, 클라이언트는 핸드셰이크가 끝난 뒤 early data 없이 다시 보내..

systemd path unit 기준

systemd.path unit은 특정 파일이나 디렉터리 상태가 조건에 맞을 때 다른 unit을 활성화하는 기능이다. 주로 같은 이름의 .service를 깨워서 "파일이 생기면 처리한다", "디렉터리에 항목이 들어오면 작업한다", "설정 파일 변경 뒤 후속 작업을 실행한다" 같은 흐름을 만들 때 쓴다.핵심 기준은 이벤트 자체보다 활성화 모델이다. path unit은 파일 감시를 담당하고, 실제 작업은 service unit이 담당한다. 그래서 긴 작업, 권한, 로그, 재시작 정책, 실행 환경은 .service에서 관리하고, .path에는 무엇을 감시할지만 남기는 편이 운영 중 이해하기 쉽다.systemd path unit은 무엇을 하나?systemd 공식 문서 기준으로 .path로 끝나는 unit 파일은..

리눅스 cgroup v2 io.max 기준

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.리눅스 cgroup v2의 io.max는 특정 블록 장치에 대해 읽기·쓰기 대역폭이나 IOPS 상한을 거는 인터페이스입니다. 같은 서버에서 백업, 인덱싱, 배치 작업처럼 디스크를 많이 쓰는 작업이 서비스 응답 시간을 흔들 때 검토할 수 있습니다. 다만 모든 I/O 문제를 해결하는 만능 설정은 아니며, 우선순위 조정이 필요한지 절대 상한이 필요한지부터 구분해야 합니다.2026년 9월 30일 확인 기준 Linux kernel의 cgroup v2 문서는 io.weight를 상대 가중치, io.max를 BPS 또는 IOPS 기반 제한으로 설명합니다. systemd 환경에서는 IOWeight=, IOReadBandwidthMax=..

Web Locks API 기준

본문 중간의 쿠팡 추천 상품 구매시 쿠팡 파트너스에서 일정액의 수수료를 제공받습니다.Web Locks API는 같은 origin 안의 탭, 창, worker가 하나의 작업을 동시에 실행하지 않도록 조정하는 브라우저 API입니다. 여러 탭에서 IndexedDB 동기화, 캐시 갱신, 백그라운드 정리 작업을 동시에 시작하면 중복 요청이나 상태 충돌이 생길 수 있습니다. 이때 navigator.locks.request()로 이름 있는 잠금을 요청하면 브라우저가 보유자와 대기열을 관리합니다.2026년 9월 30일 확인 기준 MDN은 Web Locks API를 널리 사용 가능한 Baseline 기능으로 설명하며, secure context와 worker 지원도 함께 표시합니다. 다만 이 API는 네트워크 분산 락이..

PostgreSQL CTE materialization 기준

PostgreSQL의 WITH 절은 복잡한 SQL을 여러 조각으로 나누어 읽기 쉽게 만드는 도구다. 하지만 CTE(Common Table Expression)는 단순한 문법 정리 이상의 의미도 갖는다. PostgreSQL에서는 CTE가 부모 쿼리 안으로 접히기도 하고, 별도로 계산된 임시 결과처럼 materialize되기도 한다.기준은 명확하다. 한 번만 참조되는 부작용 없는 비재귀 SELECT CTE는 기본적으로 부모 쿼리와 함께 최적화될 수 있다. 반대로 여러 번 참조되는 CTE는 기본적으로 한 번 계산된 결과를 재사용하는 쪽으로 동작한다. 이 기본 판단을 바꾸고 싶을 때 MATERIALIZED와 NOT MATERIALIZED를 사용한다.CTE는 언제 최적화 경계가 될까?PostgreSQL 공식 문서..

페이스북으로 공유카카오톡으로 공유카카오스토리로 공유트위터로 공유URL 복사