day-log

여름 방광염 예방 습관 7가지 — 땀 많이 흘리는 계절, 화장실은 참지 마세요

gfrog — Thu, 2 Jul 2026 18:16:13 +0900

여름은 방광에게 가장 힘든 계절입니다. 땀으로 수분이 빠져나가 소변이 진해지고, 더위에 물 대신 커피·맥주·아이스 아메리카노에 손이 가기 쉬우며, 물놀이·에어컨·습한 속옷까지 겹치면 요로 자극과 세균 증식이 동시에 늘어나기 때문이죠. 실제로 방광염(요로감염)은 6~9월에 병원 방문이 가장 많은 계절성 질환 중 하나로, 특히 여성 4명 중 1명은 평생 한 번 이상 경험한다고 알려져 있습니다. 오늘은 여름철 방광을 지키는 생활 습관 7가지를 정리했습니다.

_{Photo by Arnie Watkins on Pexels}

1. 하루 1.5~2L, '한 번에 벌컥' 대신 '자주 조금씩'

여름철 방광 건강의 절반은 물이 결정합니다. 성인은 하루 1.5~2L(체중 kg × 30ml)를 기준으로 잡되, 목이 마를 때 한 번에 500ml씩 마시기보다 200~250ml 컵으로 2시간 간격 나눠 마시는 편이 신장·방광 부담을 덜어줍니다. 소변 색이 옅은 밀짚 색을 넘어 진한 노랑·주황이면 이미 탈수 신호입니다.

2. 요의는 절대 참지 말 것 — 3시간 안엔 무조건 화장실

여름엔 회의·야외 활동·물놀이 중에 요의를 미루기 쉽습니다. 하지만 방광 안에 소변이 오래 머물수록 세균이 증식할 시간을 벌어주는 셈이에요. 요의를 느끼지 않아도 최소 3시간에 한 번은 화장실에 다녀오는 습관을 들이세요. 반대로 방광이 비어 있는데 자주 가는 것도 방광을 예민하게 만들 수 있으니 '자연스러운 신호를 놓치지 않기'가 핵심입니다.

3. 카페인·알코올·탄산은 방광 자극제, 물 한 잔 곁들이기

아이스 아메리카노 한 잔은 그 자체로 이뇨 효과가 있어 오히려 탈수와 방광 점막 자극을 유발합니다. 맥주·에너지 드링크·탄산음료도 마찬가지예요. 완전히 끊을 필요는 없지만, 카페인/알코올 한 잔당 물 한 잔을 함께 마시는 '1:1 규칙'을 지키면 자극을 상당 부분 상쇄할 수 있습니다.

4. 물놀이·수영 후엔 곧바로 젖은 옷 갈아입기

여름철 방광염의 상당수는 젖은 수영복·속옷을 오래 입고 있다가 시작됩니다. 습한 상태가 30분 이상 지속되면 회음부 온도와 습도가 올라가 세균이 번식하기 좋은 환경이 되죠. 물놀이가 끝나면 바로 미지근한 물로 샤워하고 통풍 잘 되는 면 속옷으로 갈아입어 주세요.

5. 화장실 뒤처리와 성관계 후 위생

여성의 경우 요도가 짧아 대장균이 항문에서 요도로 옮겨가는 경로가 방광염의 가장 흔한 원인입니다. 배변 후에는 반드시 '앞→뒤' 방향으로 닦고, 비데를 쓸 때도 방향과 수압을 확인하세요. 성관계 전후에는 물을 한 잔 마시고 소변을 봐 요도의 세균을 씻어내는 것이 도움이 됩니다.

_{Photo by Karola G. on Pexels}

6. 통풍이 되는 속옷·꽉 끼는 옷 피하기

레깅스·스키니진·합성섬유 속옷은 통풍을 막고 땀을 가둡니다. 여름철에는 통기성이 좋은 순면 속옷, 여유 있는 실루엣의 원피스·린넨 팬츠를 우선순위에 두세요. 특히 요가·필라테스처럼 땀을 많이 흘리는 운동 후에는 곧바로 옷을 갈아입어 회음부를 건조하게 유지하는 것이 좋습니다.

7. 이런 증상이면 미루지 말고 병원으로

다음 중 하나라도 해당된다면 방광염 초기일 가능성이 높으니 하루 이틀 자가 관리로 넘기지 말고 비뇨의학과·산부인과 진료를 받아보세요.

소변 볼 때 찌릿한 통증이나 화끈거림
하루 8회 넘게 화장실을 가는데 매번 소량만 나옴
잔뇨감(볼일을 봤는데도 시원하지 않은 느낌)
아랫배 묵직함 또는 옆구리·허리 통증
소변 색이 붉거나 뿌옇고 냄새가 강함
열이 나고 몸살 기운이 동반될 때(신우신염 가능성)

증상이 24시간 이상 이어지거나 열이 동반되면 신장까지 감염이 올라간 신우신염일 수 있어 빠른 진료가 필요합니다.

마무리

여름 방광 건강은 특별한 영양제나 시술이 아니라 물·화장실·속옷 세 단어로 요약됩니다. 오늘 하루 내 소변 색을 한 번만 확인해 보고, 카페인 한 잔에 물 한 잔을 곁들이는 것부터 시작해 보세요. 다만 이 글은 일반적인 생활 정보이며 개인의 병력·복약 상태에 따라 다를 수 있으므로, 반복적으로 증상이 나타난다면 반드시 의료 전문가와 상담하시기 바랍니다.

OpenTelemetry Collector, Agent와 Gateway 두 층으로 굴리기

gfrog — Thu, 2 Jul 2026 15:47:40 +0900

OTel Collector 배포할 때 처음에는 다들 하나만 띄우고 시작한다. 우리 팀도 그러다. Deployment 하나 만들어서 어플리케이션들이 다 거기로 OTLP 쏘게. 초기엔 잘 돌아간다. 그러다 트래픽 늘고, tail sampling 붙이고, k8s 노드 라벨을 span에 붙이기 시작하면 슬슬 얘가 무너진다.

이번 글은 그 다음 단계 — Agent(DaemonSet) + Gateway(Deployment) 두 층 구조로 가는 실전 셋업이다. 최근 릴리스 몇 개(현재 v0.154 기준)에서 바뀐 것들도 같이 정리한다.

왜 두 층인가

한 층으로 유지하다 보면 결국 이런 문제가 나온다.

첫째, 노드 로컬 정보를 붙이기 어렵다. Pod의 IP는 알지만 노드 이름, 커널 버전, 인스턴스 타입 같은 건 어디선가 리소스 attribute로 붙여줘야 한다. 어플리케이션이 다 알아서 붙이면 되지 않냐 싶은데, 우리 팀은 언어 4개 SDK를 쓴다. 언어마다 붙이는 attribute 규격이 미묘하게 다르다. 통일하려고 붙잡고 있느니 노드에 얹은 Agent가 처리하는 게 훨씬 낫다.

둘째, tail-based sampling을 하려면 하나의 trace에 속한 span들이 같은 인스턴스로 모여야 한다. 이걸 어플리케이션이 알 리가 없다. Gateway 층에서 loadbalancingexporter로 trace ID 라우팅을 걸어야 처리된다.

셋째, 배치·재시도·백프레셔가 Gateway에 집중되면 어플리케이션 SDK 쪽 큐 튜닝 걱정을 덜 수 있다. Agent가 얇게 받아서 Gateway에 위임하는 구조가 운영이 편하다.

구조 잡기

기본 흐름은 이렇다.

App SDK  →  Agent (DaemonSet, 노드마다 1)  →  Gateway (Deployment, N개)  →  백엔드

Agent는 노드에 하나. hostmetrics, kubeletstats 같은 노드 로컬 리시버가 여기서 돈다. 어플리케이션은 노드 IP(또는 hostPort/downward API로 주입받은 IP)로 OTLP를 쏜다. 이렇게 하면 네트워크 홉이 짧고, 노드 이슈 있을 때 데이터가 멀리 안 간다.

Gateway는 3~5대 Deployment. 여기서 tail sampling, redaction, 라우팅, 백엔드별 export가 다 일어난다. Agent와 Gateway 사이는 OTLP gRPC로 붙인다.

Agent 쪽 설정

DaemonSet으로 배포하고, hostmetrics·kubeletstats·otlp만 켠다. 어플리케이션에서 오는 OTLP는 그대로 받아서 최소 처리만 하고 gateway로 넘긴다.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318
  hostmetrics:
    collection_interval: 30s
    scrapers:
      cpu:
      memory:
      filesystem:
      network:
  kubeletstats:
    collection_interval: 20s
    auth_type: serviceAccount
    endpoint: ${env:K8S_NODE_NAME}:10250

processors:
  batch:
    timeout: 5s
    send_batch_size: 8192
  resource:
    attributes:
      - key: k8s.node.name
        value: ${env:K8S_NODE_NAME}
        action: insert
  k8sattributes:
    auth_type: serviceAccount
    passthrough: false
    filter:
      node_from_env_var: K8S_NODE_NAME

exporters:
  otlp/gateway:
    endpoint: otel-gateway.observability.svc.cluster.local:4317
    tls:
      insecure: true
    sending_queue:
      enabled: true
      queue_size: 5000
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [k8sattributes, resource, batch]
      exporters: [otlp/gateway]
    metrics:
      receivers: [otlp, hostmetrics, kubeletstats]
      processors: [k8sattributes, resource, batch]
      exporters: [otlp/gateway]
    logs:
      receivers: [otlp]
      processors: [k8sattributes, resource, batch]
      exporters: [otlp/gateway]

여기서 놓치기 쉬운 게 k8sattributes processor의 filter.node_from_env_var. 이걸 안 넣으면 Agent가 클러스터 전체 Pod 정보를 워치하려고 든다. 노드 수십 대 곱하기 클러스터 전체 Pod 수만큼 informer가 돌면 API 서버가 좋아할 리가 없다. 반드시 자기 노드로 필터링해라.

Gateway 쪽 설정

Gateway는 tail sampling과 라우팅이 주 임무다. 여기서 트래픽 튀는 걸 견뎌야 하니 HPA도 함께 붙인다.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
        max_recv_msg_size_mib: 32

processors:
  batch:
    timeout: 10s
    send_batch_size: 16384
  tail_sampling:
    decision_wait: 30s
    num_traces: 100000
    policies:
      - name: errors
        type: status_code
        status_code:
          status_codes: [ERROR]
      - name: slow
        type: latency
        latency:
          threshold_ms: 500
      - name: probabilistic
        type: probabilistic
        probabilistic:
          sampling_percentage: 5
  transform/redact:
    trace_statements:
      - context: span
        statements:
          - replace_pattern(attributes["http.url"], "token=[^&]+", "token=REDACTED")

exporters:
  otlphttp/backend:
    endpoint: https://otlp.your-backend.example.com
    headers:
      x-api-key: ${env:BACKEND_API_KEY}

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [transform/redact, tail_sampling, batch]
      exporters: [otlphttp/backend]

여기서 중요한 건 Agent → Gateway 구간에서 loadbalancingexporter를 쓰는 경우다. 실제로 tail sampling이 정확히 돌려면 같은 trace의 모든 span이 같은 Gateway 인스턴스로 가야 한다. 위 설정은 Agent → Gateway가 그냥 랜덤 로드밸런싱이라 tail sampling이 부정확해진다. 정확도가 필요하면 Agent의 exporter를 loadbalancing으로 바꾸고 resolver에 Gateway Service를 넣어라.

exporters:
  loadbalancing:
    protocol:
      otlp:
        tls:
          insecure: true
    resolver:
      k8s:
        service: otel-gateway.observability
        ports: [4317]

이렇게 하면 trace ID 해시로 라우팅해준다. 우리 팀은 처음에 이걸 몰라서 tail sampling 결과가 이상하게 나오는 걸 한참 헤맸다.

최근 릴리스에서 조심할 것들

한동안 안 봤다가 업그레이드하면 몇 개 이름이 바뀌어 있다. 최근 릴리스 노트 훑어보다 눈에 띈 것들:

k8snode detector가 deprecated 되고 k8s_api로 옮겨졌다. 2026년 12월에 완전히 제거 예정이라니 지금 미리 바꿔두는 게 낫다.
apachespark → apache_spark, envoyals → envoy_als 처럼 underscore로 통일되고 있다. 옛 이름은 alias로 남아있긴 한데 로그에 deprecation 경고가 쌓인다.
Kafka metrics receiver의 UseFranzGo feature gate가 stable로 승격되고 Sarama 기반 구현이 제거됐다. Kafka 붙여 쓰던 팀이면 config 검증해봐라.
OTLP protobuf 정의가 v1.10.0으로 올라갔다. 대부분 하위호환이지만 자체 exporter를 만든 팀은 벤더 백엔드 호환성을 한 번 봐야 한다.

리네임 대응은 간단하다. otelcol validate 걸어서 deprecation 경고 목록 뽑고, 하나씩 이름만 바꿔주면 된다. 큰 리스크는 없다.

언제 이 구조가 오버킬인가

솔직히 팀이 작고 서비스도 몇 개 없으면 Gateway 한 층만으로 충분하다. 두 층 가는 게 정당화되는 시점은 대충 이렇다.

노드 개수가 20대 이상이거나, tail sampling을 정말 쓰고 있거나, 백엔드가 두 곳 이상이라 라우팅이 필요하거나. 하나라도 해당되면 두 층으로 넘어가라. 아니면 그냥 Deployment 하나 잘 튜닝하는 게 낫다. 인프라 쪼갠 만큼 관측 대상도 늘어난다.

마무리

우리 팀은 최근 이 구조로 옮기고 나서 tail sampling 정확도가 정상화됐고, Gateway HPA로 트래픽 스파이크 대응도 훨씬 편해졌다. 다만 Agent DaemonSet의 리소스 요청/제한 튜닝은 노드 크기별로 다시 잡아야 했다. m5.large 노드용 requests가 m5.4xlarge에 그대로 붙으면 낭비다. 이 부분은 다음에 다시 정리해보려고 한다.

혹시 다르게 굴리는 분들 있으면 어떻게 하시는지 궁금하다.

여름 냉장고, 그냥 넣지 마세요 — 온도대별 자리와 신선도 유지 7가지 실전 팁

gfrog — Thu, 2 Jul 2026 12:14:37 +0900

기온이 30도를 넘나드는 7월이 되면, 냉장고 문 여닫는 횟수가 부쩍 늘어난다. 문제는 이 시기 냉장고가 가장 혹사당하는 계절이라는 점이다. 문을 자주 열수록 내부 온도가 오르고, 급식·간식·시원한 음료가 뒤죽박죽 섞이면서 정작 필요한 식재료는 안쪽에서 방치되다 상해버린다. 오늘은 여름철 냉장고를 "먹기 좋은 상태"로 유지하기 위한 7가지 실전 정리 팁을 정리했다.

_{Photo by Darrien Staton on Unsplash}

1. 냉장고 안의 "온도 지도"부터 이해하기

같은 냉장고라도 위치마다 실제 온도가 다르다. 일반적으로 문쪽 > 상단 > 중단 > 하단 > 야채칸 순으로 온도가 올라간다. 즉, 문쪽이 가장 따뜻하고 하단이 가장 차갑다는 뜻이다. 이 원칙 하나만 알아도 자리 배치의 절반은 끝난다.

문쪽(가장 따뜻): 소스류, 잼, 상온에 근접한 음료
상단: 곧 먹을 반찬, 유통기한 임박 식품
중단: 유제품, 계란, 조리된 음식
하단(가장 차가움): 생고기·생선 (교차오염 방지 목적으로도 필수)
야채칸: 채소·과일 (습도가 별도로 관리됨)

2. 생고기·생선은 무조건 "가장 아래, 별도 밀폐"

여름철 식중독의 대표 원인은 냉장고 내부에서 발생하는 교차오염이다. 생고기의 육즙이 아래로 흘러내리면서 다른 식재료를 오염시키는 케이스가 흔하다. 생고기와 생선은 반드시 냉장고 가장 아래 칸에, 밀폐용기에 담아 넣는 것이 원칙이다. 개봉한 팩째 눕혀두면 위험하다.

3. 채소는 "숨쉬는 방식"이 다르다

_{Photo by Onur Burak Akın on Unsplash}

잎채소(상추, 시금치, 쌈채소): 물기를 살짝 털어낸 뒤 키친타월로 감싸 밀폐용기에 세워 넣는다. 눕히면 무게에 눌려 물러진다.
뿌리채소(당근, 무): 흙을 완전히 털어내지 말고, 신문지에 싸서 야채칸에 둔다.
파, 대파: 뿌리를 살짝 남겨 물기 있는 키친타월에 감싸면 오래간다.
토마토·바나나·감자: 냉장 보관은 오히려 풍미를 떨어뜨린다. 상온이 낫다.

4. 과일과 채소는 따로 보관하기

사과, 바나나, 토마토 같은 과일은 에틸렌 가스를 뿜어낸다. 이 가스는 옆에 있는 잎채소를 빠르게 시들게 만든다. 야채칸이 두 개라면 과일칸과 채소칸을 분리하고, 하나뿐이라면 최소한 과일은 봉지나 밀폐용기로 격리하자.

5. "선입선출" 자리를 만들어라

여름철에는 상하기 전에 다 먹는 것이 관건이다. 냉장고 눈높이 상단에 "이번 주 안에 먹을 것" 자리를 지정해두면 유통기한 임박 식품이 안쪽에서 조용히 잊혀지는 사고를 줄일 수 있다. 방법은 간단하다.

투명한 트레이 하나를 상단에 놓는다
신선도 우선순위가 높은 반찬·개봉 식품을 여기에만 담는다
트레이만 비우고 채우면 자연스레 선입선출이 된다

6. 문을 자주 여닫는 여름, "밀도"를 낮춰라

냉장고가 꽉 차 있으면 냉기 순환이 안 돼서 안쪽 온도가 오히려 올라간다. 특히 여름은 문 개폐가 잦아 온도 편차가 커지는 시기라 약 70% 정도만 채우는 것이 이상적이라고 한국소비자원이 권장한다. 반대로 냉동실은 꽉 채우는 편이 냉기 유지에 유리하다 — 얼린 식재료 자체가 축열체 역할을 하기 때문이다.

7. 주 1회 "훑어보기", 월 1회 "닦아내기"

주 1회: 유통기한 스캔 + 야채칸 물기 제거. 5분이면 충분하다.
월 1회: 안쪽 선반과 서랍을 꺼내 미지근한 물+베이킹소다로 닦는다. 냉장고 냄새의 원인은 대부분 눈에 안 보이는 얼룩과 흘린 국물 자국이다.

청소할 때 콘센트를 뽑을 필요는 없다. 한 칸씩 비우고 닦으면 온도 변화가 최소화된다. 마지막에 원두 찌꺼기를 말려 소독지에 담아 두면 탈취 효과가 꽤 좋다.

마무리

여름 냉장고 정리의 핵심은 "어디에, 어떤 상태로, 얼마 동안" 이 세 가지를 의식하는 것이다. 오늘 저녁 한 번만 냉장고를 열고 위 원칙에 따라 자리를 다시 잡아보자. 며칠만 지나도 버리는 식재료가 줄고, 여는 시간이 짧아진다. 결과적으로 전기요금까지 살짝 줄어든다 — 여름 살림에서 이만한 가성비 정리는 흔하지 않다.

kube-apiserver가 429를 뱉을 때 - API Priority and Fairness 내부 살펴보기

gfrog — Thu, 2 Jul 2026 09:18:22 +0900

kubectl이 갑자기 Too Many Requests를 뱉기 시작하면 대부분 첫 반응은 비슷하다. "누가 또 apiserver 두들기고 있냐." 그리고 나서 metrics를 보면 특정 컨트롤러가 리스트 요청을 폭주하고 있거나, 새 오퍼레이터가 배포되면서 watch를 무한 재연결하고 있거나 그런 식이다.

근데 그때 이런 의문이 든다. 왜 kubelet의 상태 업데이트는 여전히 잘 되는데 내 kubectl은 막힐까? 왜 어떤 요청은 큐잉되고 어떤 요청은 즉시 429가 뜰까? 이 뒤에는 API Priority and Fairness — 줄여서 APF — 라는 녀석이 돌아가고 있다. 사실 v1.29에서 GA된 지 좀 됐는데, 실제로 이걸 튜닝하거나 내부를 뜯어본 사람은 생각보다 적다. 최근에 EKS 컨트롤 플레인 스케일링 이슈로 이걸 며칠 파고 들었는데, 정리해두면 좋을 것 같아서 써본다.

FlowSchema와 PriorityLevelConfiguration - 두 개의 축

APF는 두 리소스로 돌아간다. 요청이 오면 먼저 FlowSchema를 매칭한다. FlowSchema는 "누가 어떤 요청을 보냈는지"를 기반으로 분류하는 규칙이다. subjects에 kubelet, controller, 사용자 그룹 같은 걸 명시하고, resourceRules / nonResourceRules로 대상 리소스를 좁힌다.

FlowSchema에 걸리면 두 가지가 정해진다. 첫째, 어느 PriorityLevelConfiguration으로 보낼지. 둘째, 그 안에서 어떤 flow로 취급할지 (distinguisherMethod가 ByUser면 사용자별, ByNamespace면 네임스페이스별로 flow가 나뉜다).

PriorityLevelConfiguration은 실제로 동시성 상한과 큐를 정의한다. 기본으로 제공되는 것들이 재밌는데:

system - kubelet과 노드 컴포넌트용. 제일 넉넉하다.
leader-election - 리더 선출 요청 전용. 이게 막히면 컨트롤러가 죽으니까 별도로 뺐다.
workload-high / workload-low - 컨트롤러 매니저, 스케줄러 같은 시스템 컨트롤러
global-default - 나머지 다
exempt - 검사 자체를 스킵 (healthz 같은 것)
catch-all - flow schema에 안 걸린 것들의 마지막 방어선

여기서 핵심은 각 priority level이 독립적인 concurrency limit을 가진다는 거다. system이 아무리 폭주해도 leader-election이 굶지 않는다. 이게 "priority" 부분.

Seat이라는 추상화 - 왜 list 요청은 여러 자리를 먹는가

여기서부터 재밌어진다. APF는 요청이 얼마나 "무거운지"를 seat이라는 단위로 측정한다. 대부분의 요청은 seat 1개를 잡고 시작한다. 근데 list 요청은 다르다.

apiserver는 list가 들어오면 응답에 몇 개의 객체가 포함될지를 미리 추정한다. objectsPerSeat (기본 100) 로 나눠서 필요한 seat 수를 계산한다. 10만 개의 Pod을 리스트하는 요청은 seat을 1000개 (혹은 상한선까지) 잡는다. 그러면 다른 요청이 못 들어온다.

mutating 요청도 마찬가지다. 이 요청이 watch를 얼마나 트리거할지 — 즉 apiserver가 뒷단에서 얼마나 일해야 할지 — 를 계산해서 seat이 정해진다. watchesPerSeat 기본값이 있고 (구현체마다 조금씩 다르지만 대략 10 정도), 트리거될 watch가 많은 리소스일수록 무거워진다.

이 설계가 왜 중요하냐면, 예전 max-inflight 방식은 요청 수만 세었기 때문이다. --max-requests-inflight=400이면 400개 넘게 못 받는다. 그런데 그 중 하나가 100만 개짜리 list여도 그냥 1개로 취급했다. 그러니 apiserver 메모리는 터지는데 rate limit은 안 걸리는 이상한 상황이 났다. APF는 이걸 seat으로 정규화해서 해결한다.

큐와 shuffle sharding

concurrency limit에 도달하면 그 다음부터는 큐잉된다. 큐잉이 안 되는 priority level (queuingConfiguration이 없거나 exempt)은 즉시 429가 튀지만, 대부분은 큐잉을 쓴다.

여기서 흥미로운 게 shuffle sharding이다. 한 priority level에 여러 개의 큐가 있고, flow마다 그 중 몇 개의 큐에 요청을 뿌린다. 다시 말해 사용자 A의 요청은 항상 큐 3, 7, 12에 나눠 들어가고, 사용자 B는 큐 1, 5, 9에 들어간다. handSize로 조절한다.

왜 이렇게 하냐면 - 나쁜 flow 하나가 하나의 큐를 다 채워도 다른 flow에 미치는 영향을 확률적으로 최소화하기 위해서다. 큐 개수 (queues)와 handSize를 잘 조합하면 두 flow가 같은 큐 세트에 완전히 겹칠 확률이 매우 낮아진다. queues=64, handSize=8이면 두 flow가 완전히 겹칠 확률이 대략 1 / C(64, 8) 수준. 통계로 격리하는 셈이다.

큐에서 뽑을 때는 fair queuing 알고리즘 — 가상 시간 기반으로 어느 큐가 가장 적게 서비스받았는지 계산해서 다음 요청을 뽑는다. 이 부분은 Linux 트래픽 컨트롤의 SFQ 아이디어를 가져왔다.

Seat demand의 exponential smoothing

최근에 문서를 파다가 알게 된 건데, seat 수요 예측에 exponential smoothing이 들어간다. 계수가 0.977이라는 좀 이상한 숫자인데, 이건 5분 half-life를 만들기 위한 값이다. 즉, 5분 전의 부하는 절반 정도만 반영된다.

이게 왜 중요하냐면 - CA (Cluster Autoscaler) 같은 컴포넌트가 스파이크성으로 요청을 던지는데, 그때마다 seat 배정이 요동치면 다른 flow에 영향이 크다. 반대로 반응이 너무 느리면 정말 필요한 순간에 자원을 못 준다. 5분 정도의 완만한 이동평균이 실전에서 균형점이라고 판단한 듯하다.

이걸 안다는 게 실무에서 어떤 의미냐면 - APF 튜닝을 할 때 즉시 반영을 기대하면 안 된다. 설정을 바꾼 뒤 최소 10분 정도는 지켜봐야 실제 거동이 보인다.

실무에서 뭘 봐야 하나

APF 관련 메트릭이 apiserver에서 여러 개 나오는데 실전에서 봐야 할 건 이 정도:

apiserver_flowcontrol_rejected_requests_total{priority_level="...", flow_schema="...", reason="..."}
apiserver_flowcontrol_current_inqueue_requests{priority_level="..."}
apiserver_flowcontrol_request_wait_duration_seconds{...}
apiserver_flowcontrol_dispatched_requests_total{...}
apiserver_flowcontrol_priority_level_seat_utilization{...}

Grafana에서 seat_utilization이 지속적으로 1.0에 붙어 있으면 그 priority level은 포화 상태다. request_wait_duration의 P99가 몇 초씩 나오면 큐가 밀려 있다는 뜻. rejected_requests의 reason별 분포를 보면 큐가 가득 차서 (queue-full) 튕긴 건지, 시간 초과로 (time-out) 튕긴 건지, 아니면 큐잉 자체가 안 되는 priority여서 (concurrency-limit) 즉시 거부된 건지가 나온다.

우리 팀에서는 kube-controller-manager가 대량의 이벤트를 만들 때 workload-high가 포화되는 걸 자주 봤다. 근데 이걸 그냥 concurrency를 올리는 걸로 해결하면 안 된다. 컨트롤 플레인 노드 리소스가 한정된 상태에서 concurrency만 늘리면 CPU/메모리 파열이 온다. 오히려 어떤 컨트롤러가 왜 그렇게 많이 요청하는지를 봐야 한다 - 대부분은 informer 캐시 설정이 잘못됐거나, resync period가 짧거나, watch가 재연결을 반복하는 게 원인이다.

커스텀 FlowSchema를 만들 때 함정

내부 오퍼레이터를 위해 별도 FlowSchema를 만드는 건 나쁜 선택은 아니다. 근데 몇 가지 주의점이 있다.

첫째, matching precedence를 잘 정해야 한다. FlowSchema는 matchingPrecedence (숫자가 작을수록 먼저) 순으로 평가되는데, 여기서 실수가 흔하다. 기본 FlowSchema들은 대개 1000~9900 사이의 값을 쓰니까, 커스텀은 그보다 낮게 (더 우선하게) 두거나, 아니면 명확히 뒤로 밀어야 한다.

둘째, distinguisherMethod를 뭘로 할지. ByUser가 기본에 가깝지만, 오퍼레이터가 하나의 서비스 어카운트로 여러 워커에서 요청을 보내면 다 같은 flow로 묶여서 shuffle sharding의 이점을 못 본다. 이 경우 ByNamespace로 나눠주는 게 나을 수도 있다.

셋째, 큐 없는 (type: Reject) priority level을 쉽게 만들지 마라. 큐잉 없이 즉시 429 뱉는 게 필요한 경우도 있긴 한데 (예: probe 같은 시간 제약이 강한 요청), 잘못 쓰면 정상 트래픽도 즉시 튕겨나간다.

좀 더 파보고 싶다면

Kubernetes enhancements 리포의 KEP-1040 문서가 원본이다. 왜 이렇게 설계됐는지, 어떤 대안을 검토했는지가 다 나와 있다. 특히 shuffle sharding 파트의 확률 계산은 한번 읽어볼 만하다.

그리고 apiserver의 staging/src/k8s.io/apiserver/pkg/util/flowcontrol/ 아래 코드를 보면 실제 구현이 있다. fairqueuing 서브 패키지의 queueset.go에 큐 선택 로직이 다 들어 있어서, virtual time이 어떻게 갱신되는지, seat이 어떻게 계산되는지 코드로 확인할 수 있다. 문서만 봐서는 이해가 애매한 부분이 코드를 보면 명확해진다.

APF는 처음 접하면 개념이 많아 보이는데, 결국 "요청을 분류하고 (FlowSchema), 격리해서 자원을 배분하고 (PriorityLevel), 공평하게 서비스한다 (shuffle sharding + fair queuing)" 이 세 축으로 정리된다. 여기까지 이해하고 나면 apiserver가 왜 저런 결정을 내리는지 감이 잡힌다.

여름철 다리 붓기와 부종, 줄이는 실전 7가지 습관

gfrog — Thu, 2 Jul 2026 06:14:48 +0900

여름이 되면 다리가 유독 무겁고 저녁 무렵 발등이 두툼하게 부풀어 오르는 분들이 많습니다. 기온이 높아지면 말초 혈관이 확장되고, 오래 서 있거나 앉아 있을 때 정맥이 다리에서 심장으로 혈액을 밀어올리는 능력이 떨어져 체액이 조직 사이에 고이기 때문이에요. 짠 음식, 수분 부족, 꽉 끼는 옷도 여름철 붓기를 부추기는 요인입니다. 오늘은 병원 진료 없이도 오늘 저녁부터 바로 실천할 수 있는 다리 부종 완화 습관 7가지를 정리했습니다.

_{Photo by Lucrezia Carnelos on Unsplash}

1. 하루 5분, "심장보다 높게" 다리 올리기

가장 간단하면서도 효과가 즉각적인 방법입니다. 소파나 벽에 다리를 걸치고 15~20cm 정도 심장보다 높게 올려 5~10분간 유지하면, 다리에 몰려 있던 정맥혈이 자연스럽게 심장 쪽으로 이동합니다. 하루 두세 번, 특히 퇴근 후와 잠들기 전 루틴으로 넣어보세요. 무리한 각도로 오래 유지하기보다 짧게 자주 하는 것이 더 편안합니다.

2. 물은 하루 1.5~2L, 조금씩 자주

역설적이지만 수분이 부족하면 몸이 오히려 체액을 저장하려고 해서 부종이 심해집니다. 하루 총 1.5~2L 정도를 한 번에 몰아 마시지 말고, 200mL씩 8~10번으로 나눠 마시는 것을 권장합니다. 냉수보다는 미지근한 물이 위장 부담이 적고, 여름철 땀으로 손실되는 나트륨·칼륨 균형도 무너뜨리지 않습니다.

3. 나트륨 하루 5g 이하로 관리

라면, 국물, 젓갈, 배달음식은 여름철 붓기의 대표적인 원인입니다. 세계보건기구는 나트륨 1일 섭취량을 2g(소금 5g) 이하로 권고합니다. 국물은 반만 마시기, 김치·젓갈은 소량만 곁들이기, 배달음식은 소스를 절반만 붓기 같은 작은 습관만 지켜도 다음 날 아침 부종이 눈에 띄게 줄어드는 걸 느낄 수 있어요.

_{Photo by Rohit Tandon on Unsplash}

4. 종아리 근육 펌프 깨우기 — 발목 순환 운동

종아리는 "제2의 심장"으로 불릴 만큼 정맥 순환의 핵심입니다. 앉은 자세에서 발목을 위아래로 20회, 원을 그리듯 좌우로 20회씩 돌려주세요. 사무실에서 1시간마다 1분씩만 해도 하지 정체가 훨씬 줄어듭니다. 통근길 지하철에서도 발끝을 슬쩍 위아래로 움직이는 것만으로도 도움이 됩니다.

5. 오래 앉거나 서 있을 때는 "50분+10분" 규칙

같은 자세로 50분을 유지했다면, 10분은 걷거나 자세를 바꿔야 합니다. 특히 재택근무·장거리 운전·매장 근무처럼 자세가 고정되는 환경일수록 다리 붓기가 심해지는데요. 스마트폰 타이머를 활용해 강제로 자리에서 일어나는 습관을 만들어 보세요. 화장실을 조금 먼 곳으로 다녀오는 것도 좋은 방법입니다.

6. 미지근한 물로 발·종아리 마사지

너무 뜨거운 물은 오히려 혈관을 확장시켜 저녁 부종을 가중시킬 수 있습니다. 38~40℃ 정도의 미지근한 물에 발과 종아리를 10분 정도 담근 뒤, 발목에서 무릎 방향으로 손바닥 전체를 이용해 부드럽게 쓸어올리듯 마사지하세요. 강하게 주무르기보다 "아래에서 위로" 방향을 지키는 것이 핵심입니다.

_{Photo by Georg Auffarth on Unsplash}

7. 꽉 끼는 옷·양말은 잠시 접어두기

허벅지·종아리를 조이는 스키니진, 밴딩이 강한 양말, 딱 맞는 부츠는 정맥 흐름을 물리적으로 방해합니다. 여름철에는 통풍이 잘 되는 넉넉한 옷과 낮은 압력의 양말을 선택하고, 만약 종일 서 있는 직업이라면 의료용 압박스타킹(20~30mmHg)을 검토해 볼 수 있습니다. 단, 압박스타킹은 처음 착용 전 발등·발목 크기를 정확히 재고, 필요 시 전문가와 상의하세요.

이런 경우엔 병원 진료를 권장합니다

대부분의 여름철 다리 붓기는 위 습관만으로도 눈에 띄게 좋아집니다. 다만 아래 증상 중 하나라도 해당된다면 자가 관리를 넘어 심장·신장·정맥 관련 원인을 확인해야 하므로 병원 진료를 받아보시는 것이 좋습니다.

한쪽 다리만 갑자기 붓고, 종아리 통증·발열·붉어짐이 동반되는 경우
부종과 함께 호흡곤란, 가슴 답답함이 있는 경우
잠에서 깨어난 아침에도 부종이 사라지지 않고 지속되는 경우
임신 중 갑작스러운 다리·손·얼굴 부종이 발생한 경우

본 글은 일반적인 생활 정보이며, 개인의 건강 상태에 따라 필요한 처치가 다를 수 있습니다. 지속되는 증상이나 새로운 통증이 있다면 반드시 의사·약사 등 전문가와 상담해 주세요.

오늘 저녁 딱 3가지만 시작해 보세요

부종은 하루 이틀 노력으로 극적으로 사라지진 않지만, 작은 습관이 쌓이면 다리의 무거움과 저녁 종아리 통증이 확연히 줄어듭니다. 오늘 밤엔 ① 5분 다리 올리기 → ② 미지근한 물 300mL → ③ 발목 순환 운동 20회만 실천해 보세요. 내일 아침의 다리가 훨씬 가볍게 느껴지실 거예요.

Karpenter spot 노드가 새벽에 계속 죽었다

gfrog — Thu, 2 Jul 2026 03:14:06 +0900

지난주 화요일 새벽 4시쯤, 알림이 두 개 연달아 왔다. 하나는 pod pending 알림, 하나는 P99 레이턴시 알림. 눈이 번쩍 떠져서 노트북을 켰다.

우리 팀은 몇 달 전부터 Karpenter를 v1.x로 올려두고 spot-to-spot consolidation을 활성화해서 쓰고 있다. 비용은 확실히 줄었다. 근데 그 새벽에는 대가를 치렀다. 노드 12대 중 7대가 30분 사이에 인터럽트를 받으면서 순차적으로 죽었고, 그 와중에 Karpenter는 계속 새 spot을 붙였다 떼기를 반복하고 있었다.

처음에는 그냥 spot 인터럽트인 줄 알았다

AWS spot은 원래 죽는다. 그건 알고 시작한 거니까. 그래서 처음에는 "아 오늘 그 존이 좀 빡센가 보다" 하고 넘어갈 뻔했다. 근데 로그를 보니 이상했다.

karpenter  disrupting via consolidation replace, terminating 1 nodes
karpenter  disrupting via consolidation replace, terminating 1 nodes
karpenter  disrupting via consolidation replace, terminating 1 nodes

10분 사이에 consolidation 이벤트가 8번. spot 인터럽트가 아니라 Karpenter가 스스로 노드를 갈아치우고 있었던 거다. 그리고 새로 붙인 노드가 또 몇 분 뒤에 인터럽트를 받아서 죽었다.

이게 뭐지 싶어서 새로 프로비저닝된 인스턴스 타입을 봤더니, 특정 저가 타입 두어 개로 계속 몰리고 있었다. m5.large, m5a.large 이런 애들. 근데 그 시간대에 그 존에서 그 타입이 유독 자주 회수되고 있었던 것 같다.

PCO를 믿었는데 왜?

Karpenter는 spot 할당에 PriceCapacityOptimized (PCO) 전략을 쓴다. 무조건 최저가만 고르지 않고 가용성도 함께 본다는 얘기다. 그래서 처음 붙일 때는 나름 안정적인 인스턴스가 붙는다.

문제는 그 다음이다. consolidation이 돌면, Karpenter는 현재 노드보다 저렴한 조합이 있는지 계속 살핀다. 그러다 저가 spot이 잡히면 갈아탄다. 이게 반복되면 소위 말하는 race to the bottom, 결국 가장 싼(=가장 잘 죽는) 인스턴스로 수렴한다.

문서에는 이걸 막기 위해 single node spot-to-spot consolidation에는 최소 15개 인스턴스 타입 유연성이 필요하다고 못박아 놓았다. 우리는 그게 있는 줄 알았다. 실제로는 없었다.

NodePool 스펙을 다시 열어봤다.

requirements:
  - key: karpenter.k8s.aws/instance-family
    operator: In
    values: ["m5", "m5a", "m6i"]
  - key: karpenter.k8s.aws/instance-size
    operator: In
    values: ["large", "xlarge", "2xlarge"]
  - key: karpenter.sh/capacity-type
    operator: In
    values: ["spot"]

3 family × 3 size = 9 조합. 15개 안 된다. 그래서 Karpenter 입장에서는 single node consolidation을 판단할 때 이미 게이트가 안 열렸어야 하는데, 로그를 보면 계속 replace가 돌고 있었다. 이 부분은 아직 검증 중이다 — v1 마이너 버전 특정 릴리스에서 flexibility 체크가 우회되는 케이스가 있었다는 얘기가 팀 내부 논의에서 나왔고, 우리 클러스터가 그 케이스에 걸린 건지 아니면 우리가 뭘 잘못 세팅한 건지 아직 확답을 못 내렸다.

일단 급한 불부터 끄기

새벽 4시 반쯤. 정신을 좀 차리고 두 가지를 했다.

첫째, consolidation을 잠시 껐다. NodePool의 disruption 필드에 다음을 넣었다.

disruption:
  consolidationPolicy: WhenEmpty
  consolidateAfter: 5m

WhenUnderutilized를 껐다는 얘기다. 유휴 노드 청소만 남기고, 저가 spot을 쫓아가는 동작을 멈춘다. 이 상태에서 클러스터는 급격히 안정됐다.

둘째, spot interruption SQS가 진짜 붙어 있는지 다시 확인했다. 문서에서 강조하는 건데, SQS 큐가 안 붙어 있으면 인터럽트 경고가 와도 Karpenter가 못 잡아서 그냥 죽는다. 우리는 붙어 있었다. 다행이었다.

다음날 낮에 다시 정리

낮에 팀원들과 앉아서 몇 가지를 바꿨다.

instance-family를 늘렸다. m5, m5a, m5n, m6i, m6a, m7i, c5, c5a, c6i 이런 식으로. size도 조금 더 열었다. 그 결과 flexibility가 20 조합을 넘겼다. AWS 블로그 예제도 이 정도 폭을 기본으로 잡는다.

그다음 WhenUnderutilized를 다시 켜되, consolidateAfter를 15분으로 늘렸다. 5분 단위로 왔다갔다 하는 게 그 새벽에 상황을 악화시켰다고 봐서, 결정 주기를 좀 느긋하게 잡았다.

노드 disruption budget도 붙였다. 동시에 사라질 수 있는 노드 수에 상한을 두는 건데, 우리는 전체 노드의 10%로 잡았다. 12대면 최대 1~2대. 새벽에 7대가 한꺼번에 흔들린 상황이 재현되면 안 되니까.

disruption:
  consolidationPolicy: WhenEmptyOrUnderutilized
  consolidateAfter: 15m
  budgets:
    - nodes: "10%"

배운 것

Karpenter 쓸 때 "instance-family 몇 개 열었는지"를 그냥 취향 정도로 넘겼는데, 이게 spot-to-spot consolidation에서는 안전 장치 그 자체다. 15라는 숫자를 문서에서 봤을 때는 "왜 저렇게 많이?" 싶었는데, 그날 새벽 이후로는 "왜 저렇게 적게?"가 됐다.

그리고 비용 최적화 기능들은 대체로 조용히 이득을 준다. 대신 잘못 물리면 조용히 손해도 준다. consolidation이 얼마나 자주 도는지, 어떤 인스턴스로 옮겨가는지, 옮겨간 노드가 몇 분 만에 죽는지 — 이런 지표를 대시보드에 걸어두지 않은 게 뼈아팠다. 이번 주에 Prometheus rule 몇 개 추가하는 게 다음 작업이다.

혹시 spot-to-spot consolidation 쓰시는 분들, family 몇 개 여셨는지 궁금합니다. 15 근처면 안전한지, 아니면 더 많이 열어두시는지.

여름방학 아이 생활리듬, 방학 첫 주에 무너지지 않게 지키는 7가지 방법

gfrog — Thu, 2 Jul 2026 00:14:06 +0900

여름방학이 시작되면 부모 입장에서 가장 먼저 걱정되는 것은 아이의 생활리듬입니다. 어린이집·유치원·학교에서 잡아주던 기상, 식사, 낮잠, 취침 시간이 통째로 무너지면, 방학이 끝날 무렵 등원·등교 복귀가 훨씬 힘들어집니다. 미국소아과학회(AAP)와 국내 소아청소년과학회 모두 "휴가·방학 기간에도 취침 시각의 변동은 1시간 이내로 유지하는 것이 권장된다"고 안내합니다.

이 글은 만 3세~초등 저학년 아이를 둔 부모를 대상으로, 방학 첫 주에 리듬을 잡아두면 남은 여름 내내 훨씬 편한 7가지 방법을 정리했습니다.

_{Photo by MI PHAM on Unsplash}

1. 기상 시각은 학기 대비 최대 1시간까지만 늦추기

방학이라고 아침 10시, 11시까지 자게 두면 다시 원상 복구하는 데 2주 이상이 걸립니다. 학기 중 7시 기상이었다면 방학에는 8시까지, 최대 1시간 이내로만 늦춰주세요. 커튼을 살짝 열어 자연광이 방으로 들어오게 하면 멜라토닌 분비가 자연스럽게 줄어들어 아이가 덜 힘들게 일어납니다.

2. "오전에 하나, 오후에 하나" 앵커 활동 만들기

시간 감각이 아직 없는 아이에게는 시계보다 "활동"이 리듬의 기준이 됩니다. 오전에는 산책·물놀이·독서 같은 활동적인 것, 오후에는 낮잠·미술·블록놀이처럼 조용한 것을 하나씩 정해두면 하루가 자연스럽게 나뉩니다. 매일 완벽할 필요는 없고, 큰 두 개의 축만 지켜지면 충분합니다.

3. 아침 식사는 반드시 챙기기

방학 동안 아침을 건너뛰기 시작하면 오전 활동량이 줄고, 오후 간식·저녁 폭식으로 이어지면서 취침 시각이 늦어집니다. 시리얼+우유+과일, 토스트+계란+요거트처럼 5분 안에 준비되는 간단한 세트를 3~4개 정해두고 아이가 직접 고르게 하면 참여도가 올라갑니다.

_{Photo by Drew Perales on Unsplash}

4. 스크린 타임은 "시간"이 아니라 "구간"으로 관리

"하루 2시간"처럼 총량만 정하면 아이는 하루 종일 눈치를 보며 협상하려 듭니다. 그보다 "점심 후 30분, 저녁 식사 준비 30분"처럼 시간대를 못박아 두는 편이 훨씬 편합니다. 미국소아과학회는 만 6세 이상의 경우 총량보다 "일관된 규칙과 대체 활동"이 더 중요하다고 강조합니다.

5. 낮잠은 오후 3시 이전에 끝내기

유아기 낮잠은 필요하지만, 오후 3시 이후까지 자게 두면 저녁잠이 밀리면서 밤 10~11시가 되어야 잠드는 악순환이 시작됩니다. 낮잠은 30~60분, 늦어도 오후 3시에는 부드럽게 깨워주세요. 초등 저학년이라면 낮잠 대신 20분 정도의 조용한 독서·명상 시간을 두는 것이 좋습니다.

_{Photo by Vicko Mozara on Unsplash}

6. 저녁 루틴은 "순서"만 지키면 성공

목욕 → 잠옷 → 이 닦기 → 책 읽기 → 소등, 이 순서만 매일 같게 유지하면 시각이 다소 흔들려도 아이는 "잠잘 시간"으로 인식합니다. 여행지나 조부모 댁에서도 이 순서를 지키면 낯선 곳에서의 잠자리 거부가 눈에 띄게 줄어듭니다.

7. 방학 마지막 주는 "복귀 예행연습" 주간으로

방학 종료 일주일 전부터는 기상·취침 시각을 학기 시간에 맞춰 하루 15분씩 앞당깁니다. 등원·등교 첫날의 컨디션이 완전히 달라집니다. 이 시기에는 새 학기 준비물 사기, 학용품 이름 붙이기 같은 "학교 관련 이벤트"를 자연스럽게 배치해 아이도 심리적으로 준비할 수 있게 해주세요.

마무리

여름방학은 아이에게 쉬는 시간이지만, "쉼"은 무질서가 아니라 "느슨한 규칙"이 있을 때 진짜 회복이 됩니다. 완벽하게 지키지 못하더라도, 위 7가지 중 3~4개만 꾸준히 유지해도 개학 후 적응 속도가 크게 달라집니다. 아이의 개별 성향과 연령에 따라 조정이 필요하며, 수면 문제가 2주 이상 지속되거나 낮 활동에 지장이 있는 경우 소아청소년과 전문의 상담을 권장합니다.

2026년 7월 2일 (목) 12간지 오늘의 운세

gfrog — Thu, 2 Jul 2026 00:11:40 +0900

2026년 7월 2일 (목) 12간지 오늘의 운세

7월의 두 번째 목요일, 여름의 열기가 본격적으로 시작되는 하루입니다. 이번 주의 반환점에 서서 한 번 크게 심호흡을 해 볼 만한 날이에요. 오늘 하루 각자의 띠에 어울리는 흐름을 가볍게 훑어보고, 마음의 방향을 잡아보세요.

쥐띠 (1972, 1984, 1996, 2008, 2020)

전반적으로 리듬이 좋은 하루입니다. 아침에 세운 작은 계획들이 예상보다 술술 풀릴 수 있어요. 애정운은 담백하지만 안정적입니다. 오래 미뤄둔 연락 한 통이 관계를 다시 따뜻하게 만들 수 있으니 부담 없이 안부를 전해보세요.

소띠 (1973, 1985, 1997, 2009, 2021)

묵묵하게 쌓아온 노력이 조금씩 형태를 드러내는 시기입니다. 금전운은 큰 변동보다는 소소한 절약이 도움이 됩니다. 오늘은 충동구매보다 통장 잔고 확인이 훨씬 유쾌한 하루가 될 거예요. 건강은 어깨와 목 스트레칭에 신경 써 주세요.

Photo on Pexels

호랑이띠 (1974, 1986, 1998, 2010, 2022)

에너지가 넘치는 하루입니다. 다만 그 힘을 한꺼번에 쓰면 오후에 지칠 수 있으니 페이스 조절이 관건입니다. 애정운은 활발한 대화 속에서 유쾌한 인연이 스쳐 지나갈 수 있는 흐름이에요. 웃음을 아끼지 마세요.

토끼띠 (1975, 1987, 1999, 2011, 2023)

감성이 예민하게 반응하는 날입니다. 좋은 음악, 좋은 향, 좋은 문장에 마음이 쉽게 흔들리니 창의적인 활동에 유리한 하루예요. 금전운은 지출을 조금만 눌러도 오히려 여유가 생깁니다. 건강은 눈의 피로에 유의하세요.

용띠 (1976, 1988, 2000, 2012, 2024)

크게 움직이기보다 정리에 유리한 하루입니다. 그동안 쌓아둔 자료나 일정을 다듬으면 다음 주가 훨씬 가벼워질 거예요. 총운은 무난하며 예상 밖의 인정을 받을 가능성도 있습니다. 서두르지 말고 한 걸음씩 나아가세요.

뱀띠 (1977, 1989, 2001, 2013, 2025)

직감이 밝은 날입니다. 결정을 두고 오래 고민 중이었다면 오늘의 첫 느낌을 믿어보세요. 애정운은 은근한 배려가 큰 힘을 발휘합니다. 상대의 사소한 취향을 기억해 주는 것만으로도 관계가 한 단계 깊어질 수 있어요.

Photo on Pexels

말띠 (1978, 1990, 2002, 2014, 2026)

활동력이 좋은 하루입니다. 미뤄왔던 외부 일정을 소화하기에 적당한 흐름이에요. 금전운은 이동 중 소비에 주의하면 안정적입니다. 건강은 무리한 야식보다 이른 저녁이 훨씬 몸을 편하게 만들어 줄 거예요.

양띠 (1979, 1991, 2003, 2015)

부드러운 협력 운이 도는 날입니다. 혼자 끙끙대던 일이 있다면 주변의 조언을 편안하게 받아들여 보세요. 총운은 평온하며 대인관계에 특히 좋습니다. 오후에 마시는 따뜻한 음료 한 잔이 마음을 정돈해 줄 거예요.

원숭이띠 (1980, 1992, 2004, 2016)

기민한 판단력이 빛나는 하루입니다. 업무에서 아이디어가 잘 나오니 메모 습관이 큰 도움이 됩니다. 애정운은 유머러스한 태도가 통하는 하루예요. 진지함보다는 부드러운 농담 한마디가 분위기를 살려줄 수 있습니다.

닭띠 (1981, 1993, 2005, 2017)

체계적으로 정리하는 흐름이 유리합니다. 오늘은 계획표나 일정표를 다시 손보기에 좋은 날이에요. 금전운은 소비 계획을 세워두면 오히려 여유가 생깁니다. 건강은 수분 섭취를 조금 더 챙기는 것이 좋겠습니다.

개띠 (1982, 1994, 2006, 2018)

신뢰의 관계에서 힘을 얻는 하루입니다. 가까운 사람들과의 짧은 대화가 하루 전체의 분위기를 바꿀 수 있어요. 총운은 안정적이며 크게 흔들릴 일은 없습니다. 마음이 답답하다면 짧은 산책이 도움이 됩니다.

돼지띠 (1983, 1995, 2007, 2019)

풍성한 정서를 나누는 데 유리한 날입니다. 소중한 사람과 함께하는 식사, 대화, 작은 선물 모두 좋은 기운을 만들어 줄 거예요. 금전운은 큰 지출보다 소소한 선의의 지출이 마음을 따뜻하게 만들어 줍니다.

7월 초의 목요일은 하반기의 리듬을 잡아가는 중요한 시기입니다. 오늘 한 걸음의 작은 습관이 이번 여름 전체의 방향을 결정할 수도 있어요. 각자의 자리에서 편안하고 즐거운 하루 보내시길 바랍니다.

본 운세는 오락 목적이며 참고용입니다.

Docker BuildKit cache mount, 이거 모르면 CI에서 매번 손해 본다

gfrog — Wed, 1 Jul 2026 18:16:31 +0900

이거 모르는 분 꽤 많더라. RUN --mount=type=cache 한 줄로 npm/pip install 시간을 절반 이하로 줄일 수 있다. 그런데 실무에서 제대로 세팅한 걸 보기는 의외로 드물다.

뭐가 문제냐

기본 Dockerfile로 이미지 빌드하면, COPY package*.json ./ 다음에 RUN npm ci 하는 패턴을 쓸 거다. 여기서 lock 파일이 바뀌면 그 아래 레이어 캐시가 전부 무효화되고, npm ci가 처음부터 다시 돈다. 패키지 하나 추가했을 뿐인데 400개 다운로드를 다시 하는 셈이다.

우리 팀은 프론트 모노레포에 workspace 20개가 물려 있는데, 어떤 워크스페이스 하나만 라이브러리 하나 올려도 CI 이미지 빌드가 3분 넘게 걸렸다. 노드 하나 이슈면 그러려니 하는데 매번 그러니 좀 짜증이 났다.

이 한 줄이면 된다

Dockerfile 맨 위에 syntax 지시자 하나, RUN 라인 하나 바꿔주면 끝이다.

# syntax=docker/dockerfile:1.7
FROM node:20-alpine

WORKDIR /app
COPY package*.json ./

RUN --mount=type=cache,target=/root/.npm,sharing=locked \
    npm ci --prefer-offline --no-audit

COPY . .
RUN npm run build

핵심은 --mount=type=cache. /root/.npm은 npm이 다운로드한 tarball을 캐시하는 위치인데, 이 mount는 최종 이미지에는 포함되지 않고 빌드 사이에만 남는다. --prefer-offline 플래그를 붙여야 npm이 캐시를 최우선으로 쓴다.

pip도 똑같다.

RUN --mount=type=cache,target=/root/.cache/pip,sharing=locked \
    pip install -r requirements.txt

Go나 Rust는 target을 각각 /root/.cache/go-build, /usr/local/cargo/registry로 맞추면 된다.

CI에서 캐시가 날아가는 문제

이게 로컬에선 잘 도는데 CI에선 헛돌 때가 있다. 이유는 단순한데, ephemeral runner는 매번 새 컨테이너로 뜨니까 이전 빌드의 cache mount가 없다. 그래서 --mount=type=cache만 붙여놓고 "왜 안 빨라지지?" 하는 케이스가 많다.

해결은 buildx의 --cache-to/--cache-from으로 레지스트리에 별도 캐시를 export/import 하는 것. GitHub Actions면 이렇게:

- uses: docker/build-push-action@v5
  with:
    cache-from: type=registry,ref=myrepo/app:buildcache
    cache-to: type=registry,ref=myrepo/app:buildcache,mode=max

mode=max가 중요하다. 기본값 min은 최종 stage만 push하는데, cache mount 내용을 살리려면 max로 모든 중간 레이어를 export 해야 한다.

실제로 얼마나 빨라지나

우리 파이프라인 기준으로:

프론트 이미지 빌드: 3분 20초 → 1분 5초
Python 서비스 이미지: 45초 → 8초 (deps 변경 없을 때)
deps 변경 시에도 새 패키지만 다운로드해서 시간 차이 크게 안 남

--cache-to 세팅 안 되어 있으면 이런 효과 못 본다는 게 함정이다. 로컬 dev에서 반복 빌드할 때는 자동으로 이득이지만, CI 이득 보려면 registry cache 세팅까지 같이 가야 한다.

몇 가지 주의점

sharing=locked 옵션은 병렬 빌드 시 캐시 lock을 잡는 옵션이다. 기본값이 shared인데, 이 경우 두 빌드가 같은 캐시에 동시에 쓰면 깨질 수 있다. 안전하게 가려면 locked. 속도 조금 손해 보지만 재현성이 낫다.

그리고 # syntax=docker/dockerfile:1.7 이 지시자는 반드시 파일 첫 줄에 있어야 한다. 주석이라도 그 위에 있으면 파싱이 안 된다. 1.7 대신 그냥 1로 해도 최신 지원되는 버전을 알아서 잡는다.

혹시 Kaniko나 Buildah 같은 rootless 빌더 쓰는 분들, cache mount 지원 여부는 각 도구 문서 확인하시길. Kaniko는 최근에 지원 들어갔는데 syntax가 살짝 다르다.

--mount=type=cache 한 줄로 CI 파이프라인이 눈에 띄게 조용해진다. 아직 안 붙이신 분은 오늘 커밋 하나 만들어 두시길.

장마철 실내 습도 관리 & 곰팡이 예방 체크리스트 — 오늘 바로 실천하는 10가지

gfrog — Wed, 1 Jul 2026 18:14:22 +0900

7월이 시작되면서 한반도는 본격적인 장마철에 접어들었다. 창밖으로 종일 흩뿌리는 비도 좋지만, 문제는 실내다. 습도가 70~80%를 넘나들면 옷장 속 옷은 눅눅해지고, 벽지·실리콘 틈새·화장실 천장에서는 하루가 다르게 검은 곰팡이가 번진다. 곰팡이 포자는 알레르기성 비염·기침·아토피를 악화시키는 주범이라, 방치했다가는 여름 내내 건강이 발목을 잡힌다.

이 글에서는 특별한 장비 없이도 오늘 저녁부터 바로 실천할 수 있는 실내 습도 관리 & 곰팡이 예방 체크리스트 10가지를 정리했다.

Photo by

실내 적정 습도부터 다시 알기

세계보건기구(WHO)와 국내 건축·환경 가이드라인은 실내 상대습도를 40~60%로 유지할 것을 권장한다. 60%를 넘어가면 곰팡이·집먼지진드기가 폭발적으로 번식하고, 30% 이하로 떨어지면 안구·호흡기 점막이 마르기 시작한다. 장마철에는 저절로 60%를 넘기기 때문에 "말리는" 방향으로 관리 포인트를 잡아야 한다.

Photo by

오늘부터 실천하는 10가지 체크리스트

1. 습도계 하나는 반드시 두자

숫자를 봐야 실감이 난다. 5,000~1만 원대 디지털 습도계를 거실·침실·화장실 앞 3곳에 두면 관리 지점이 명확해진다.

2. 비 오는 날에도 하루 2번 5분 환기

"창문을 닫아야 습기가 안 들어오지 않을까?" 오해다. 밀폐된 실내는 사람 호흡·요리 수증기 때문에 오히려 습도가 올라간다. 짧고 강하게 맞바람을 만들어 주면 실내 공기 질이 훨씬 좋아진다.

3. 에어컨 "제습" 모드를 적극 활용

제습기가 없다면 에어컨 제습 모드로도 충분하다. 26~27℃로 1~2시간만 돌려도 상대습도가 10~15%p 떨어진다. 냉방보다 전기요금 부담도 상대적으로 적다.

4. 욕실은 사용 직후 물기 제거

샤워 후 스퀴지(물끌개)로 벽·유리·바닥의 물기를 훑어내고, 환풍기는 최소 30분 이상 돌린다. 이 한 가지로 욕실 곰팡이의 70%가 예방된다는 것이 청소업체들의 공통된 조언이다.

5. 옷장·신발장은 문을 자주 열어둔다

가장 흔한 곰팡이 발생 지점이 붙박이장 뒤쪽과 신발장 안쪽이다. 하루 1~2회는 활짝 열어 공기가 통하게 하고, 벽과 가구 사이는 최소 5cm 띄운다.

6. 침구·수건은 완전 건조 후 정리

장마철에는 세탁물이 "덜 마른 상태"로 개어지는 경우가 많다. 촉감으로는 마른 것 같아도 속은 축축하다. 건조기가 없다면 선풍기·에어컨 바람 앞에서 30분 추가로 말리자.

7. 신문지·숯·베이킹소다는 저비용 습기 흡수제

옷장 구석에 신문지 몇 장
신발 안에 신문지 뭉치
냉장고·화장실 구석에는 뚜껑 연 베이킹소다 통
다용도실·창고에는 숯 몇 조각

이 조합만으로도 습기·냄새가 눈에 띄게 줄어든다. 신문지는 1~2주에 한 번 교체한다.

8. 벽·창틀 결로 부위는 마른 걸레로 매일 닦기

결로가 반복되는 창틀·베란다 새시는 이미 곰팡이 온상이다. 매일 아침 마른 걸레로 3분만 훑어도 곰팡이 정착을 크게 늦춘다.

9. 냄새 신호를 무시하지 말자

"이 방에서 쿰쿰한 냄새가 난다"는 곰팡이가 이미 벽지 뒤·바닥재 아래에서 자라고 있다는 경고다. 벽지 들뜸·검은 반점이 보이면 방치하지 말고 초기에 방역을 의뢰하자.

10. 검은 곰팡이는 "긁어내지" 말자

칫솔로 문지르면 포자가 공기 중으로 날려 오히려 더 넓게 퍼진다. 마스크·장갑 착용 후 곰팡이 전용 스프레이(락스 계열)를 뿌리고 10~15분 방치 → 젖은 걸레로 한 방향으로 닦아낸다.

Photo by

어른·아이·반려동물 모두를 위해

곰팡이 포자는 성인보다 아이·노인·반려동물에게 훨씬 민감하게 작용한다. 특히 영유아 방·아이 옷장은 위에서 다룬 체크리스트를 두 번씩 점검한다는 마음으로 챙기는 것이 좋다. 심한 곰팡이가 반복적으로 발생하거나 알레르기 증상이 나타난다면, 자가 조치보다는 실내공기질 진단·전문 방역 서비스를 받아보는 것을 권한다.

장마는 짧으면 3주, 길면 6주 이상 이어진다. 매일 5~10분씩만 위 체크리스트를 지켜도 여름 후반이 훨씬 쾌적해진다. 오늘 저녁, 습도계부터 하나 주문해 보자.

※ 본 글은 일반적인 생활 정보이며, 심한 곰팡이 오염·호흡기 증상이 지속되는 경우 반드시 의료진 및 전문 청소·방역 업체와 상담하시길 권합니다.