day-log

2026년 5월 16일 (토) 12간지 오늘의 운세

gfrog — Sat, 16 May 2026 00:16:35 +0900

_{Photo by Diogo Miranda on Pexels}

토요일 아침, 잔잔한 바람과 함께 따뜻한 햇살이 마음을 어루만져 주는 하루입니다. 주말의 여유 속에서 12간지별로 어떤 흐름이 펼쳐질지 가볍게 살펴보겠습니다.

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

총운이 부드럽게 흐르는 날입니다. 미뤄두었던 일을 정리하면 의외의 보람을 느낄 수 있겠어요. 가까운 친구나 가족과의 짧은 대화에서 따뜻한 위로를 얻을 수 있는 시간입니다. 금전운은 무리하지 않는 선에서 안정적이며, 충동적인 소비만 자제한다면 평온한 하루가 될 것입니다.

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

오늘은 천천히 걸어가는 것이 빠른 길입니다. 서두르면 놓치는 것이 생길 수 있으니 평소보다 한 박자 느리게 움직여 보세요. 애정운은 잔잔하지만 깊은 대화가 관계를 더욱 단단하게 만들어 줍니다. 가벼운 산책이 머리를 맑게 해 줄 거예요.

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

기운이 넘쳐 활동적인 하루를 보내기 좋은 날입니다. 다만 의욕이 앞서면 주변과의 의견 차이가 생길 수 있으니 한 번 더 듣는 자세가 필요합니다. 금전운은 무난하며, 작은 지출이라도 메모해 두면 한 달이 한결 가벼워집니다. 운동이나 야외 활동도 좋아요.

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

감수성이 풍부해지는 날입니다. 좋아하는 음악이나 책 한 권이 큰 위로가 되어 주겠어요. 애정운이 살랑살랑 좋게 흐르니, 평소 마음에 담아두었던 말을 가볍게 표현해 보세요. 다만 결정을 서두를 필요는 없습니다. 천천히 음미하는 하루가 어울려요.

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

새로운 아이디어가 떠오르기 쉬운 날입니다. 메모장이나 휴대폰에 적어 두면 며칠 안에 실제로 쓸모 있는 계획으로 발전할 수 있어요. 인간관계에서는 작은 도움을 청하거나 받는 것이 자연스럽게 이어집니다. 컨디션 관리는 충분한 수분 섭취부터 시작하세요.

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

직관이 빛나는 하루입니다. 평소라면 망설였을 결정도 오늘은 비교적 분명하게 다가옵니다. 다만 너무 단정 짓기보다, 한 번쯤 다른 사람의 의견을 들어보면 더욱 안정적입니다. 금전운은 큰 변동이 없으니 평정심을 유지하는 것이 좋습니다.

_{Photo by Soumojit Basu on Pexels}

말띠 (1978, 1990, 2002, 2014)

활기찬 에너지가 도는 날이에요. 가벼운 외출이나 모임에서 좋은 자극을 얻을 수 있겠습니다. 애정운도 산뜻하게 흐르니 평소보다 더 환하게 웃어 보세요. 건강 면에서는 무리한 스케줄은 피하고, 식사 시간만큼은 챙겨 드시는 것이 좋습니다.

양띠 (1979, 1991, 2003, 2015)

마음이 차분해지는 하루입니다. 주말의 여유를 활용해 방 정리나 가벼운 살림에 시간을 써 보면 만족감이 큽니다. 금전운은 큰 흐름은 없지만 소소한 발견이 있을 수 있어요. 오랜만에 가족이나 친구에게 안부 인사를 건네면 따뜻한 응답이 돌아옵니다.

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

재치와 유머가 빛나는 날입니다. 모임 자리에서 분위기를 부드럽게 만드는 사람이 바로 당신이에요. 다만 농담이 지나치면 오해를 부를 수 있으니 상대의 표정을 살피는 센스가 필요합니다. 금전운은 무난하고, 작은 선물을 받게 될 가능성도 있어요.

닭띠 (1981, 1993, 2005, 2017)

계획적인 하루가 잘 어울리는 날입니다. 주말의 한가운데, 다음 한 주의 일정을 가볍게 정리해 두면 시작이 한결 수월합니다. 애정운은 평온하며, 사소한 배려가 큰 호감으로 이어집니다. 건강은 눈의 피로에 주의하고, 화면에서 잠시 떨어져 쉬는 시간을 가져 보세요.

개띠 (1982, 1994, 2006, 2018)

신뢰가 강조되는 하루입니다. 약속과 시간을 잘 지키는 모습이 주변에 좋은 인상을 남깁니다. 금전운은 안정적이며, 충동구매보다는 미리 적어둔 리스트를 따르는 것이 만족도가 높아요. 가족과 함께하는 짧은 시간이 따뜻한 위로가 될 수 있습니다.

_{Photo on Pexels}

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

푸근한 기운이 감도는 날입니다. 사람들과의 어울림에서 즐거움을 얻기 쉬우며, 평소 챙기지 못했던 가까운 사람에게 먼저 다가가 보면 좋아요. 금전운은 평탄하지만 작은 행운이 깃든 소식이 들려올 수 있습니다. 따뜻한 한 끼 식사가 하루의 만족을 더해 줄 거예요.

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

오늘 하루도 작은 행운들이 곳곳에 숨어 있길 바랍니다. 따뜻한 토요일 보내세요.

AWS NLB로 gRPC 라우팅, ALPN 정책 한 줄을 안 넣으면 어떻게 깨지나

gfrog — Fri, 15 May 2026 21:43:03 +0900

ALB의 gRPC 지원은 꽤 알려져 있다. Target group protocol version을 GRPC로 바꾸고, health check 경로를 /grpc.health.v1.Health/Check로 잡으면 끝. 근데 사내에서 ALB를 안 쓰고 NLB로 가야 하는 상황이 생긴다. 클라이언트가 mTLS를 끝단까지 가져가야 하거나, ALB로는 못 받는 별난 트래픽이 섞여 있거나, 비용 문제거나.

이 글은 그 NLB + gRPC 조합에서 우리 팀이 며칠 헤맨 얘기를 정리한 거다. 결론부터 말하면 ALPN 정책 한 줄이 빠지면 TLS handshake는 되는데 gRPC만 안 된다. 로그도 별 게 안 남는다.

NLB가 gRPC를 "지원"한다는 말의 의미

NLB는 L4다. HTTP/2 프레임을 해석하지 않는다. 그래서 "gRPC를 지원한다"는 표현이 좀 헷갈리는데, 정확히는 TLS handshake에서 ALPN으로 h2를 협상해주고, 그 위로는 그대로 통과시킨다는 뜻이다. ALB처럼 메서드 단위로 라우팅하거나 status code 기반 health check를 해주지는 않는다.

그래서 NLB 앞단에서 gRPC가 동작하려면 두 가지가 같이 맞아야 한다.

NLB listener의 ALPN policy가 h2를 협상하도록 설정돼 있을 것
백엔드(보통 envoy, nginx, 혹은 애플리케이션 자체)가 h2(또는 h2c)로 받을 준비가 돼 있을 것

둘 중 하나만 빠지면 증상이 미묘하게 다르게 나온다.

우리가 만난 증상

처음에 EKS에 올린 gRPC 서비스를 AWS Load Balancer Controller로 NLB에 연결했다. Service annotation은 이렇게:

service.beta.kubernetes.io/aws-load-balancer-type: external
service.beta.kubernetes.io/aws-load-balancer-nlb-target-type: ip
service.beta.kubernetes.io/aws-load-balancer-scheme: internet-facing
service.beta.kubernetes.io/aws-load-balancer-listener-ssl-negotiation-policy: ELBSecurityPolicy-TLS13-1-2-2021-06

grpcurl로 외부에서 호출해봤다. TLS handshake는 성공. 그런데 RPC 호출은:

Failed to dial target host "api.example.com:443": context deadline exceeded

이게 묘한 게, curl로 HTTPS를 때리면 응답이 온다(백엔드가 h2c를 받게 돼 있어서 일반 HTTPS는 안 받지만 connection은 되는 식). 즉 L4까지는 멀쩡한데 gRPC client만 막힌다.

원인은 ALPN. 위 annotation에는 ALPN policy가 없다. 기본값은 None이다. NLB가 ALPN 협상을 안 해주면 클라이언트는 h2가 합의됐는지 확신할 수 없고, gRPC client(grpc-go, grpc-java 등)는 보통 h2 협상이 명시적으로 안 되면 INTERNAL: connection error로 떨어진다.

고친 방법

annotation 한 줄 추가:

service.beta.kubernetes.io/aws-load-balancer-alpn-policy: HTTP2Preferred

값은 HTTP2Preferred 또는 HTTP2Only를 쓴다. 차이는 이렇다.

HTTP2Preferred: 클라이언트가 h2를 제시하면 h2로, 아니면 http/1.1로 fallback. 같은 NLB로 HTTPS와 gRPC를 둘 다 받을 때 유용.
HTTP2Only: 무조건 h2. 클라이언트가 h2를 안 제시하면 handshake가 깨진다. gRPC 전용 NLB라면 이걸로.

우리는 gRPC 외에 다른 HTTPS 트래픽도 같은 NLB로 받고 있어서 HTTP2Preferred로 갔다. 이거 하나 넣고 다시 배포하니 grpcurl이 바로 떨어졌다.

Health check, 이게 또 별개

NLB는 L4라서 ALB처럼 /grpc.health.v1.Health/Check를 HTTP로 호출해주지 못한다. 옵션은 두 가지다.

# 옵션 1: TCP health check (기본)
service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080"

TCP는 단순히 포트가 열려있는지만 본다. 빠르고 안전한데, 애플리케이션이 살아있는지 정확히 알 수 없다.

# 옵션 2: HTTPS health check를 별도 경로로
service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: HTTPS
service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: /healthz
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: "8080"

이건 백엔드에 별도 HTTP/HTTPS health endpoint가 있어야 한다. gRPC만 노출하는 서비스라면 envoy를 사이드카로 띄워서 admin 포트의 /ready를 쓰거나, 애플리케이션에 healthz 핸들러를 같이 박는 식으로 풀었다.

우리 팀은 결국 옵션 2로 갔다. TCP health check는 프로세스가 좀비처럼 listen만 하고 실제 요청을 못 받는 상태를 못 잡았기 때문이다. 한 번 데였다.

트러블슈팅에 도움 됐던 명령들

ALPN 협상이 실제로 일어났는지는 openssl로 확인할 수 있다.

echo | openssl s_client -alpn h2 -connect api.example.com:443 2>/dev/null \
  | grep -i "ALPN"

ALPN policy가 None이면 No ALPN negotiated가 떨어진다. 정상이면 ALPN protocol: h2가 보인다.

gRPC 자체는 grpcurl로 확인.

grpcurl -insecure api.example.com:443 list
grpcurl -insecure api.example.com:443 grpc.health.v1.Health/Check

정리

NLB로 gRPC 받을 때 빼먹기 쉬운 거 세 가지를 다시 적자면:

첫째, ALPN policy. 이걸 안 넣으면 gRPC client만 골라서 깨진다. HTTP2Preferred가 무난하다.

둘째, health check 종류. TCP면 빠르지만 정확하지 않고, HTTPS면 정확하지만 endpoint를 따로 둬야 한다. 운영 환경에서는 HTTPS 쪽이 결국 마음 편하다.

셋째, 백엔드가 h2를 받게 돼 있는지. 애플리케이션 직결이면 보통 잘 맞는데, envoy/nginx 같은 프록시를 통하면 upstream protocol을 h2로 명시했는지 다시 확인할 것.

근데 한 가지 더 - 이렇게 NLB로 gRPC 풀어놓으면 메서드 단위로 라우팅하거나 weighted target으로 카나리하는 건 어려워진다. 그게 필요하면 결국 ALB로 돌아가거나, NLB 뒤에 envoy를 두는 패턴으로 간다. 우리는 후자로 가고 있는데, 이건 다음 글에서 정리해보려고 한다.

5월에 시작하는 베란다 텃밭, 초보도 키우기 쉬운 채소 7가지

gfrog — Fri, 15 May 2026 18:14:41 +0900

_{Photo by Artur Aleksanian on Unsplash}

5월 중순은 베란다 텃밭을 시작하기 가장 좋은 시점입니다. 평균 기온이 18~24도까지 오르고 일조량이 풍부해서 모종이 빠르게 자리잡고, 본격적인 여름이 오기 전에 첫 수확까지 노려볼 수 있는 시기죠. 흙도 가벼워지고 물 빠짐도 좋아져서 초보자가 시작하기에 부담이 적습니다. 오늘은 화분 한두 개로 시작할 수 있는 베란다 텃밭 가이드를 정리해 봤어요.

시작 전, 우리 집 베란다 환경 체크

먼저 베란다 방향을 확인하세요. 채소를 키우기 가장 좋은 방향은 남향과 남동향입니다. 하루 4~6시간 이상 직사광선이 들어와야 잎채소도 튼튼하게 자랍니다. 동향은 잎채소 위주, 서향은 더위에 강한 작물 위주로, 북향은 허브와 그늘에 강한 작물 위주로 계획을 잡으면 실패가 적어요.

확인할 항목은 다음과 같습니다.

일조 시간: 오전·오후 각각 햇살이 몇 시간 들어오는지
통풍: 환기창을 열었을 때 바람이 통하는지 (장마철 곰팡이·진딧물 예방)
배수: 화분 받침에 물이 고이지 않도록 받침 높이 확보
무게: 큰 화분 여러 개를 둔다면 베란다 하중도 고려

5월에 키우기 쉬운 채소 7가지

_{Photo by Tom Jur on Unsplash}

1. 상추

가장 무난한 첫 작물입니다. 모종을 사서 20cm 화분에 옮겨 심으면 2~3주 뒤부터 겉잎부터 따 먹을 수 있어요. 한 번 심으면 한두 달은 계속 수확할 수 있어 가성비가 좋습니다.

2. 방울토마토

5월에 모종을 심어 6월 하순부터 7~8월까지 따 먹을 수 있는 대표 작물입니다. 화분은 깊이 25cm 이상, 햇살이 좋은 자리가 필수. 지지대를 같이 세워주면 가지가 처지지 않아요.

3. 바질

이탈리아 요리에 빠질 수 없는 허브. 따뜻해야 잘 자라서 5월 이후가 적기입니다. 손가락으로 위쪽 순을 가볍게 잘라주면 옆가지가 풍성해집니다.

4. 깻잎

한국 사람이 좋아하는 베란다 단골 작물. 한 번 자리잡으면 계속 자라기 때문에 가족 수에 따라 2~3포기면 충분합니다. 진딧물이 잘 붙으니 잎 뒷면을 자주 살펴주세요.

5. 청경채

40~50일이면 수확이 가능한 빠른 작물. 잎채소 중에서도 비교적 더위에 잘 견디고 볶음·국 어디든 활용도가 높습니다.

6. 쪽파

화분이 작아도 무리 없이 자라고, 뿌리째 잘라서 쓰면 다시 자라기 때문에 한 번 심어두면 두고두고 활용 가능해요.

7. 루꼴라

샐러드용으로 인기. 25일 전후로 빠르게 자라서 성취감이 큽니다. 한여름엔 쓴맛이 강해지니 5~6월에 집중적으로 먹는 게 좋아요.

초보가 자주 하는 실수 3가지

_{Photo by Vaida Krau on Unsplash}

1. 매일 물 주기
물은 매일이 아니라 흙 표면이 마르면 주는 것이 기본입니다. 손가락으로 흙을 2cm 정도 눌렀을 때 건조하면 그때 주세요. 과습은 뿌리를 썩게 만드는 가장 흔한 실패 원인입니다.

2. 너무 작은 화분에 욕심내기
방울토마토를 12cm 화분에 심으면 한 달도 못 가서 시듭니다. 작물별 최소 화분 크기는 모종 라벨에 적힌 권장 사이즈를 따르세요. 일반적으로 잎채소는 15cm 이상, 열매채소는 25cm 이상이 안전합니다.

3. 비료 한 번에 듬뿍
"많이 주면 잘 자라겠지"는 가장 흔한 함정. 액체비료는 권장 희석 비율을 지키고, 일주일에 1회 정도가 적당합니다. 한꺼번에 많이 주면 잎이 타거나 뿌리가 상합니다.

모종 사기 vs 씨앗부터 시작

5월에 시작한다면 모종 구입을 추천합니다. 화원·시장·온라인에서 1,000~3,000원이면 한 포기를 구할 수 있고, 이미 자라 있는 상태라서 실패율이 훨씬 낮습니다. 씨앗은 가을이나 다음 봄에 한두 작물부터 도전해 보세요.

마무리

베란다 텃밭의 진짜 매력은 풍성한 수확보다는 매일 자라는 모습을 들여다보는 시간 자체에 있습니다. 아침에 잎이 어제보다 한 장 더 펴 있는 걸 발견할 때의 작은 기쁨, 직접 키운 상추로 쌈을 싸 먹는 순간은 화분 한두 개의 노력으로 누릴 수 있는 일상의 사치예요. 이번 주말, 동네 화원에 들러 모종 두 포기와 흙 한 봉지로 가볍게 시작해 보시기 바랍니다.

CronJob 실패 로그가 증발한 사건

gfrog — Fri, 15 May 2026 15:43:11 +0900

지난주 새벽의 작은 사고

지난주에 작은 사고가 있었다. 큰 장애는 아니었는데, 디버깅하면서 내가 너무 기본값을 신뢰하고 있었다는 걸 깨달았다. CronJob failedJobsHistoryLimit 얘기다.

상황은 이랬다. 데이터 동기화용 CronJob이 매 5분마다 도는데, 모니터링 대시보드에서 어느 새벽부터 실패 카운트가 슬슬 올라가고 있었다. 한 시간쯤 지나서 PagerDuty가 울렸고, 출근 전이라 자느라 못 봤다. 아침에 일어나서 보니 한 시간 동안 12번 실패한 상태였다.

로그를 보러 갔는데

당연히 kubectl logs부터 쳤다. Pod가 이미 사라진 상태. 그렇지, CronJob은 Job을 만들고, Job이 Pod를 만든다. Pod는 사라져도 Job 객체는 남아있어야 하니까 그쪽을 보자.

$ kubectl get jobs -n data-sync | grep sync-orders
sync-orders-29183455   0/1   2m   2m

딱 하나. 가장 최근에 실패한 거 하나만 남아있었다. 그 전 11번은? 다 지워졌다.

왜 그랬을까

CronJob 스펙을 다시 봤다.

apiVersion: batch/v1
kind: CronJob
metadata:
  name: sync-orders
spec:
  schedule: "*/5 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: sync
            image: our-registry/sync:v2.3.1

failedJobsHistoryLimit을 명시 안 했다. 기본값이 뭔지 알고는 있었다 — 1. 근데 그게 실제로 뭘 의미하는지는 깊게 생각 안 해봤던 거다.

쿠버네티스는 새 Job이 끝날 때마다 정리 로직을 돈다. 실패한 Job이 limit를 넘으면 가장 오래된 것부터 삭제. 5분마다 새 Job이 만들어지고 모두 실패하니까, 5분 간격으로 직전 실패 Job이 깔끔하게 증발한 거다. 한 시간 동안 도는 동안 그 어떤 흔적도 남지 않았다.

사실 가장 화나는 건

실패 원인 자체는 별거 아니었다. 외부 API 키가 만료됐던 거. 그 자체는 5분이면 찾을 일이었는데, 첫 번째 실패 시점이 언제인지, 그때부터 뭐가 바뀌었는지를 추적하는 데 한 시간을 더 썼다. Argo Workflows나 Tekton이었으면 이력이 다 남았을 텐데, 가벼운 CronJob이니까 굳이 그럴 거 없다고 판단했던 게 부메랑이 됐다.

무엇을 바꿨나

일단 운영 중인 CronJob 전부에 다음을 적용했다.

spec:
  successfulJobsHistoryLimit: 3
  failedJobsHistoryLimit: 7

성공은 굳이 많이 안 남겨도 된다. 디버깅에 필요한 건 실패 쪽이니까. 7로 한 건 우리 환경에서 가장 짧은 주기 CronJob이 5분이고, 30분 정도는 이력을 보고 싶어서 잡은 숫자. 더 짧은 주기를 쓴다면 더 늘려야 한다.

추가로 OpenSearch 쪽 로그 파이프라인을 점검했다. Pod가 사라져도 로그는 어쨌든 인덱스에 남아야 정상인데, 우리 환경은 Pod 종료가 너무 빠를 때 일부 로그가 누락되는 케이스가 있었다. 이쪽도 별도 이슈로 트래킹 중이다.

깨달은 것

기본값을 모르고 쓰는 것보다 무서운 건, 기본값을 안다고 착각하고 쓰는 거다. failedJobsHistoryLimit: 1이라는 숫자는 알고 있었지만, 그게 "주기적으로 실패하는 작업이라면 직전 실패 하나만 본다"는 의미라는 걸 사고 나서야 체감했다. 문서를 한 번 더 읽었으면 알 수 있었는데, "기본값이면 알아서 합리적으로 동작하겠지" 라는 안이함이 있었다.

비슷한 함정이 있는 필드들도 한 번씩 다시 봐야겠다. ttlSecondsAfterFinished, concurrencyPolicy, startingDeadlineSeconds. 다 자주 안 만지지만 한 번 잘못 설정하면 며칠 후에 후회한다.

혹시 비슷한 경험 있는 분 있으면 어떻게 운영하는지 궁금하다. 우리 팀에서는 이번 일을 계기로 모든 새 CronJob 매니페스트는 history limit를 명시하도록 PR 템플릿에 항목을 추가했다.

환절기 유아 면역력, 부모표 5가지 생활 습관으로 단단하게

gfrog — Fri, 15 May 2026 12:15:35 +0900

5월은 낮과 밤의 일교차가 10도 이상 벌어지는 대표적인 환절기예요. 어른도 콧물·기침이 시작되는 시기인데, 면역 체계가 아직 미숙한 영유아(만 1~6세)에게는 더 부담스러운 계절이죠. 어린이집·유치원에서 단체 생활을 시작한 아이라면 감기·장염이 끊이지 않아 부모 마음도 무거워집니다. 약이나 영양제에 의지하기 전에, 하루 일과 속에서 면역의 토대를 만드는 5가지 생활 습관을 먼저 점검해 보세요.

_{Photo by RDNE Stock project on Pexels}

1. 잠 시간은 면역의 1순위, "양보다 일관성"

미국수면재단(NSF) 가이드라인에 따르면 1~2세는 11~14시간, 3~5세는 10~13시간의 수면이 권장돼요. 단순히 총 시간만 채우는 것보다 매일 같은 시각에 잠들고 일어나는 리듬이 면역세포 회복에 더 중요합니다. 자기 1시간 전에는 조명을 노란빛으로 낮추고, 태블릿·TV는 끄고, 잠옷으로 갈아입는 작은 루틴만 정해도 입면 시간이 눈에 띄게 짧아져요.

_{Photo by Ron Lach on Pexels}

2. 식탁 위 "오색" — 컬러 다양성이 곧 영양 다양성

특정 영양제 한 알보다, 식탁 위에 빨강·노랑·초록·하양·보라 5가지 색의 음식이 골고루 오르는 것이 훨씬 효과적이에요. 빨강(토마토·딸기)의 라이코펜, 주황(당근·고구마)의 베타카로틴, 초록(브로콜리·시금치)의 엽산, 하양(양파·마늘)의 알리신, 보라(블루베리·가지)의 안토시아닌은 서로 다른 항산화 경로로 작용해 시너지를 냅니다.

_{Photo by Jill Wellington on Pexels}

편식이 심한 아이라면 강요하지 말고, "한 입만 도전" 규칙으로 노출 횟수를 늘리세요. 연구상 새 음식은 8~15회 반복 노출되어야 거부감이 줄어듭니다.

3. 하루 30분 햇볕, 비타민 D와 활동량을 동시에

비타민 D는 면역세포가 병원체를 인식하는 데 핵심적인 역할을 해요. 5월 햇볕에 손등·얼굴을 15~20분 노출시키는 것만으로도 권장량의 상당 부분을 채울 수 있습니다. 자외선이 강한 11~14시 사이는 피하고, 오전 9~10시나 오후 4~5시에 산책·자전거·놀이터 시간을 만들어 주세요. 신체 활동량 자체도 호흡기 점막의 면역 단백질(분비형 IgA)을 늘려 줍니다.

4. 손씻기 30초 — 가장 저렴한 백신

질병관리청 자료에서도 손씻기는 호흡기·장 감염 예방에 가장 효과적인 단일 습관으로 꼽혀요. 핵심은 횟수보다 시간입니다.

손바닥 → 손등 → 손가락 사이 → 엄지 → 손톱 끝까지 30초
아이가 좋아하는 동요(생일 축하 노래 두 번 ≒ 30초)로 함께
외출 후 / 식사 전 / 화장실 다녀온 후, 3개 타이밍은 절대 사수

5. 실내 환경 — 온도 22도, 습도 50%의 마법

환절기 코감기·인후염의 원인은 바이러스 자체보다 건조한 실내 공기인 경우가 많아요. 보일러를 너무 세게 켜면 실내가 건조해져 점막 방어막이 깨집니다. 거실 온도는 21~23도, 습도는 40~60%가 적정선이에요. 가습기가 없다면 빨래 실내 건조, 욕실 문 열어두기, 화분 두기로도 습도 조절이 가능합니다. 아침저녁 5~10분 환기는 필수입니다.

면역력은 한두 가지 슈퍼푸드나 영양제로 만들어지지 않습니다. 잠·식사·햇볕·위생·환경의 5가지 축이 며칠씩 꾸준히 쌓일 때 비로소 환절기 잔병치레가 줄어듭니다.

아이가 이미 발열·기침·구토 등 증상을 보이는 경우라면 가정 대처를 미루지 말고 소아청소년과 전문의 진료를 우선 받아 보세요. 부모의 작은 루틴이 아이의 1년 건강을 좌우합니다.

Kubernetes graceful node shutdown, 안에서 도는 것들

gfrog — Fri, 15 May 2026 09:14:36 +0900

스팟 인스턴스를 자주 쓰다 보면 kubelet이 노드 종료 시점에 어떻게 행동하는지가 늘 신경 쓰인다. 사실 nodelifecycle 컨트롤러가 Pod를 옮겨주기는 하지만, 그건 노드가 NotReady가 되고도 한참 뒤의 이야기다. 그 사이에 노드 위에 있던 Pod이 어떻게 끝나느냐는 전적으로 kubelet의 graceful node shutdown 동작에 달려 있다. 이 기능은 1.21에서 알파, 1.28에서 GA가 됐고, 1.24부터는 Pod priority별로 단계화도 가능해졌다. 그런데 막상 운영해보면 "켜 놨는데 안 도는 것 같다"는 케이스가 꽤 있다. 어디서 끊기는지 한번 따라가본다.

systemd-inhibitor라는 비밀번호

kubelet이 노드 종료를 감지하는 방식은 의외로 단순하다. 부팅 후 kubelet은 systemd-logind에 D-Bus로 inhibitor lock을 건다. lock 종류는 shutdown:delay. 이름 그대로 "종료를 잠깐 늦춰달라"는 부탁이다.

$ systemd-inhibit --list
   Who: kubelet (UID 0/root, PID 1234/kubelet)
   What: shutdown
   Why: Kubelet needs time for node shutdown
   Mode: delay

리눅스가 종료 신호(systemctl poweroff 등)를 받으면, systemd-logind는 모든 delay inhibitor 보유자에게 PrepareForShutdown(true) 시그널을 D-Bus로 쏘고, 최대 InhibitDelayMaxSec만큼 기다린다. 이 값의 기본은 5초. 그래서 노드 설정에서 보통 /etc/systemd/logind.conf.d/에 별도 drop-in을 두고 늘려둔다.

# /etc/systemd/logind.conf.d/kubelet.conf
[Login]
InhibitDelayMaxSec=180

여기서 첫 함정. InhibitDelayMaxSec가 kubelet config의 shutdownGracePeriod보다 작으면 의미가 없다. 5초만 기다려주는 logind가 60초 grace period를 약속한 kubelet을 잘라낸다. journal을 보면 Lock acquired, but inhibit timed out before kubelet released라는 메시지가 잡힌다. 처음 도입했을 때 우리도 이 부분에서 한참 헤맸다.

두 단계로 끝나는 grace period

kubelet은 시그널을 받고 나서 두 페이즈로 Pod을 정리한다.

# /var/lib/kubelet/config.yaml
shutdownGracePeriod: 120s
shutdownGracePeriodCriticalPods: 30s

먼저 일반 Pod에게 shutdownGracePeriod - shutdownGracePeriodCriticalPods 만큼 시간이 주어진다. 위 예시면 90초. 이 동안 kubelet은 각 Pod에 SIGTERM을 보내고 PodSpec의 terminationGracePeriodSeconds를 그대로 존중한다. 만약 어떤 Pod이 terminationGracePeriodSeconds: 60이라면 60초까지 살 수 있는 거고, 90초를 다 쓰는 게 아니다.

그 다음 critical Pod 페이즈가 30초 동안 돈다. 여기서 말하는 critical은 PodSpec에 priorityClassName: system-cluster-critical 또는 system-node-critical이 붙은 것들이다. CNI, kube-proxy, csi-node 같은 컴포넌트들. 일반 Pod이 다 정리되어야 이 단계로 넘어가도록 설계된 이유는 명확하다. 데이터 평면을 먼저 끄면 일반 Pod의 graceful shutdown 핸들러가 외부와 통신을 못 하니까.

여기까지가 1.21~1.23의 모델이다. 단점이 보인다. priority가 3단계 이상이면? 1.24부터는 단계화가 가능하다.

1.24+ — priority 기반 다단 종료

shutdownGracePeriodByPodPriority가 들어왔다. 위 두 옵션 대신 이걸 쓴다.

shutdownGracePeriodByPodPriority:
  - priority: 0
    shutdownGracePeriodSeconds: 60
  - priority: 10000
    shutdownGracePeriodSeconds: 60
  - priority: 2000000000   # system-cluster-critical
    shutdownGracePeriodSeconds: 30
  - priority: 2000001000   # system-node-critical
    shutdownGracePeriodSeconds: 10

priority 값을 기준으로 buckets를 만들고, 낮은 priority bucket이 끝나야 다음 bucket이 시작된다. 위 설정이면 총 160초가 잡힌다. logind의 InhibitDelayMaxSec는 이 합보다 커야 한다는 점은 동일.

bucket의 priority 매칭은 "이 값 이하"가 아니라 "이 값에 가장 가까운 작거나 같은 bucket"으로 떨어진다. 그래서 priority 5000인 Pod은 위 예에서 10000 bucket에 들어간다. 0과 10000이 60초로 같은 이유는 일반 워크로드 안에서도 비지니스 우선순위(예: 결제 vs 백그라운드 ETL)를 나눌 여지를 두고 싶었기 때문이다. 우리 팀은 결제 라인을 10000으로 올려 두고, 그 라인이 먼저 끝난 뒤에야 ETL이 정리되도록 잡았다.

디버깅 — 진짜 돌고 있는 게 맞나

"설정해뒀으니 알아서 잘 되겠지"가 가장 위험하다. 다음 세 가지를 확인한다.

첫째, inhibitor가 실제로 잡혀있는지. systemd-inhibit --list 또는 busctl call org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager ListInhibitors. 잡혀있지 않다면 kubelet이 logind와 D-Bus로 통신 못 하는 거다. Bottlerocket이나 Talos 같은 immutable OS 중 일부는 logind를 안 띄운다. 이때는 kubelet이 이 기능을 자동으로 비활성화하고 시작한다. 로그에는 Cannot connect to logind, graceful shutdown disabled가 찍힌다.

둘째, 실제 종료가 일어났을 때 journal 추적. 노드를 일부러 systemctl poweroff로 꺼본다.

$ journalctl -u kubelet -t kubelet --since "1 minute ago" | grep -i shutdown
kubelet[1234]: I0515 00:02:13 nodeshutdown_manager: Shutdown manager detected new shutdown event
kubelet[1234]: I0515 00:02:13 nodeshutdown_manager: Processing shutdown, killing pods (priority 0) with grace period 60s
kubelet[1234]: I0515 00:03:13 nodeshutdown_manager: Processing shutdown, killing pods (priority 2000000000) with grace period 30s

nodeshutdown_manager가 핵심 키워드다.

셋째, 종료 사유가 Pod 객체에 남는지. kubelet은 노드가 꺼지기 직전 Pod status에 Reason: Terminated와 Message: Pod was terminated in response to imminent node shutdown.를 박는다. 1.30부터는 더 명확해져서 nodeShutdown 필드도 들어간다. API 서버까지 PATCH가 도달해야 다른 컴포넌트(예: argo-rollouts, KEDA)가 이 신호를 받아서 후속 행동을 할 수 있다. 노드 종료가 너무 급박해서 PATCH 전에 죽으면 kube-controller-manager의 pod-gc가 한참 뒤에야 정리해주는데, 그 사이 Service 엔드포인트는 stale이다.

Karpenter/Spot과 엮였을 때

여기가 의외로 골치 아프다. AWS Spot interruption 알림은 ~120초 전에 온다. Karpenter는 이 알림을 받자마자 노드를 cordon하고 drain을 시작한다. 그런데 kubelet의 graceful shutdown은 OS가 실제로 종료를 시작해야만 트리거된다. drain이 끝나고 kubelet이 한가해진 다음, OS가 종료에 들어갔을 때부터 inhibitor 시계가 도는 셈이다.

결과적으로 우리 팀에서는 다음처럼 시간을 잡아뒀다.

Spot interruption notice: T-120s
Karpenter cordon + drain 시작: T-119s 부근
drain이 60~90초 내에 끝나도록 PDB와 terminationGracePeriod 조정
그 후 OS 종료 시작, kubelet graceful shutdown: 남은 30초 안에 critical Pod 마무리
shutdownGracePeriodByPodPriority 합계는 30초 이하로 잡음

shutdownGracePeriod 총합을 너무 크게 잡지 말 것. drain이 길어지면 정작 shutdown grace는 inhibitor timeout에 잘려나간다. 한 번 인시던트 때, shutdownGracePeriod=300s로 잡아둔 노드에서 critical Pod이 SIGKILL로 끊긴 적이 있다. drain이 길게 걸리는 동안 EC2가 진짜로 회수 시점을 맞추는 게 우선이고, kubelet의 grace는 정해진 예산 안에서만 의미 있다는 걸 그때 알았다.

사실 더 파고들 게 있다

이 글에서는 systemd-logind 경로만 다뤘다. Windows 노드는 별도 메커니즘이고, cgroup v2 환경에서는 kubelet이 cgroup freeze로 일관된 종료 순서를 보장하려는 시도가 1.32 알파에 들어가 있다. CRI 쪽 변화(containerd 2.0의 sandbox API 개편)와 맞물려서 또 한 번 그림이 바뀔 가능성이 있는데, 그건 좀 더 운영해보고 따로 쓰려고 한다.

당장 점검할 거리는 세 줄로 줄여둔다. logind의 InhibitDelayMaxSec, kubelet config의 shutdownGracePeriod 합계, 그리고 spot interruption 시간 예산. 이 셋이 어긋나면 graceful shutdown은 이름만 graceful이다.

5월 초여름, 모기와 해충을 미리 차단하는 7가지 생활 팁

gfrog — Fri, 15 May 2026 06:14:23 +0900

낮 기온이 25℃를 넘기기 시작하면 모기와 작은 날벌레가 슬그머니 집 안에 보이기 시작합니다. 본격적인 여름이 오기 전, 5월에 미리 손을 써두면 6~8월 내내 잠자리를 지킬 수 있어요. 오늘은 큰돈 들이지 않고 지금 당장 실천할 수 있는 초여름 방충 루틴 7가지를 정리해 봤습니다.

_{Photo by Ioann-Mark Kuznietsov on Unsplash}

1. 방충망부터 점검하기

겨울 동안 방충망은 의외로 상합니다. 햇빛에 삭아 가장자리에 미세한 구멍이 생기거나, 새시 틈이 1~2mm 벌어지는 일이 흔해요. 형광등 또는 스마트폰 손전등을 켜고 방충망 뒤에서 비춰 보면 구멍이 한눈에 보입니다. 작은 구멍은 투명 방충망 보수 테이프로 즉시 막고, 새시 틈은 방풍·방충 모헤어 테이프로 메워 주세요. 5천 원 안팎이면 한 시즌이 든든해집니다.

2. 베란다 배수구는 모기의 산란실

집 안 모기 대부분은 베란다와 하수구를 타고 들어옵니다. 특히 봉수(트랩) 물이 마른 배수구는 모기가 가장 좋아하는 출입구예요. 일주일에 한 번 물을 한 컵 부어 봉수를 채우고, 그 위에 배수구 트랩 캡 또는 손바닥만 한 망사 거름망을 올려두면 막힘 없이 차단됩니다.

3. 화분 받침에 고인 물은 즉시 비우기

베란다 화분 받침에 며칠 동안 고인 물은 모기 유충(장구벌레)이 자라기 가장 좋은 환경입니다. 화분에 물을 준 직후 받침의 남은 물을 바로 비우는 습관만 들여도 단지 안 모기 개체수가 눈에 띄게 줄어요. 빈 화분, 안 쓰는 화병, 베란다 양동이도 같이 점검해 주세요.

4. 라벤더·시트로넬라 같은 천연 기피 식물 활용

라벤더, 시트로넬라(레몬그라스), 페퍼민트, 로즈마리 같은 허브의 향은 모기가 싫어하는 것으로 알려져 있습니다. 베란다나 창가에 한두 화분만 두어도 인테리어와 방충을 동시에 챙길 수 있어요. 다만 단독으로 모기를 100% 차단하지는 못하므로, 방충망·기피제와 함께 보조 수단으로 활용하는 것이 현실적입니다.

_{Photo by Peter Fazekas on Pexels}

5. 환기는 '해 진 직후'를 피하자

모기는 일출 직전과 일몰 직후 가장 활발하게 움직입니다. 같은 1시간을 환기해도 이른 오전(7~9시)이나 늦은 밤(22시 이후)에 창을 여는 것이 훨씬 안전합니다. 해 질 무렵 통풍이 꼭 필요하다면, 방충망을 한 번 더 확인하고 거실 조명을 잠시 낮춰 빛에 끌려오는 곤충을 줄이는 것도 도움이 됩니다.

6. 현관 출입 시 1초의 습관

택배를 받거나 분리수거를 다녀올 때 문이 활짝 열린 채 머무는 시간이 길면 한 번에 여러 마리가 들어옵니다. 현관문을 살짝 닫고 들어오기, 현관 안쪽에 모기 트랩 등 한 장 켜두기 같은 작은 습관이 의외로 큰 차이를 만들어요. 공동 현관에 모기 유인 등이 설치된 아파트라면, 그쪽에서 한 번 걸러지므로 굳이 추가 장비가 필요 없을 수도 있습니다.

7. 침실에는 '한 겹의 안전망'을 두기

아무리 막아도 한두 마리는 결국 침실까지 들어옵니다. 잠자리 가까이에서 직접 약품을 뿌리는 것보다는, 모기장 텐트, USB형 무향 모기 퇴치기, 저소음 액체 전자 모기향(취침 1~2시간 전 켜고 잘 때 끄기) 등 하나만 더 두면 수면의 질이 완전히 달라집니다. 영유아·반려동물이 있다면 살충 성분 표기를 반드시 확인하고, 환기 가능한 환경에서 사용하세요.

_{Photo by Ioann-Mark Kuznietsov on Unsplash}

오늘 당장 할 수 있는 3가지만 추린다면

방충망 구멍·새시 틈 손전등으로 한 번 비춰 점검
베란다 배수구·화분 받침의 고인 물 비우기
침실에 모기장이나 저소음 모기 퇴치기 하나 마련

5월의 30분 투자가 7~8월의 잠 못 드는 새벽을 막아 줍니다. 만약 모기에 물린 자리가 비정상적으로 크게 부풀거나 열이 동반된다면, 단순 가려움증을 넘어선 알레르기 반응이거나 매개 감염일 수 있으니 반드시 의료기관 상담을 받으시기 바랍니다. 올여름도 시원하고 평화로운 밤 보내세요.

Renovate vs Dependabot vs ArgoCD Image Updater — 1년 굴려본 솔직 비교

gfrog — Fri, 15 May 2026 00:47:39 +0900

Renovate vs Dependabot vs ArgoCD Image Updater — 1년 굴려본 솔직 비교

작년 봄에 회사 표준 의존성 업데이트 도구를 정하자는 얘기가 나왔다. 그때 우리 팀에서 굴리던 게 셋이었다. 일부 레포는 Dependabot, 인프라 모듈 레포는 Renovate, 그리고 멀티클러스터 ArgoCD가 관리하는 매니페스트 레포는 ArgoCD Image Updater. 세 개가 동시에 PR을 쏴대니까 리뷰어들이 짜증을 내기 시작했다. "이거 좀 정리하자"가 출발이었다.

결과부터 말하면 셋 다 남겼다. 다만 역할을 잘랐다. 어떤 기준으로 잘랐는지, 1년 돌려본 입장에서 솔직하게 적어본다.

세 도구가 보는 세계가 다르다

처음에 했던 큰 착각이, 이 셋을 같은 카테고리로 묶을 수 있다고 생각한 거였다. 사실 이건 비교가 좀 무리다. 보는 대상이 다르다.

Dependabot은 GitHub에 박혀 있다. 코드 레포의 manifest(package.json, go.mod, requirements.txt 등)를 읽고, 새 버전이 나오면 PR을 쏜다. 보안 advisory에 대한 자동 대응이 강점이다. 우리 케이스로는, Critical CVE가 npm에 떴을 때 새벽에 알아서 PR이 올라와 있는 경험을 몇 번 했다. 진짜로 자고 일어났더니 풀려 있었던 적도 있고.

Renovate는 좀 더 만물상이다. 같은 manifest를 보긴 하는데, 거기서 끝이 아니라 Helm chart, Terraform module, Docker base image, Kustomize image tag, GitHub Actions 워크플로의 uses: 등등 거의 모든 형태의 버전 문자열을 잡아낸다. 설정 자유도가 높고, presets가 많다. 단점은 한 번 설정을 잘못 잡으면 PR이 폭주한다는 것.

ArgoCD Image Updater는 아예 다른 종이다. 얘는 manifest를 읽는 게 아니라, 컨테이너 레지스트리를 폴링한다. 새 이미지 태그가 올라오면 Application의 image 필드를 업데이트하고, 그 변경을 Git에 write-back한다. CI 파이프라인이 이미지를 빌드해서 푸시까지만 하고 손을 떼는 GitOps 패턴에 딱 맞는다.

이걸 한 줄로 정리하면 이렇게 된다. Dependabot은 "코드 의존성", Renovate는 "리포지토리 안의 모든 버전 문자열", ArgoCD Image Updater는 "런타임 이미지". 겹치는 영역은 있지만, 강점이 명확히 다르다.

Dependabot — 기본기는 단단한데 확장이 약하다

장점부터. 설정이 거의 필요 없다. .github/dependabot.yml에 ecosystem 몇 줄 적으면 끝. GitHub Security Advisory와 직접 연동되니까 CVE 대응 측면에서 가장 빠르다. 그리고 "Dependabot이 보낸 PR"이라는 신뢰감 같은 게 있어서 리뷰어들이 일단 한 번은 본다.

단점도 명확하다. 그루핑이 약하다. 작년 가을쯤에 그루핑 기능이 GA로 풀리긴 했는데 (groups 키), Renovate의 packageRules에 비하면 표현력이 부족하다. 예를 들어 "react 관련 패키지는 묶고, 그 외 minor 업데이트도 묶고, major는 따로" 이런 식의 다층 그루핑이 깔끔하지 않다.

그리고 비-GitHub ecosystem에 대한 지원이 약하다. Terraform AWS provider 정도는 잡지만, Helm chart의 dependencies, Kustomize image, ArgoCD ApplicationSet의 image reference 같은 건 못 본다. 인프라 레포에서 쓰기엔 한계가 분명하다.

또 하나 짚자면, rate limit이 은근히 거슬린다. 큰 모노레포에서 ecosystem 여러 개 켜놓으면 GitHub API 한도에 밀려서 PR 생성이 늦어지는 경우가 있었다. 우리는 Node 패키지 100개짜리 레포 하나에서 이걸 만났는데, 해결법은 결국 그룹을 잘게 쪼개는 것뿐이었다.

Renovate — 강력하지만 학습 곡선이 있다

Renovate의 강점은 한마디로 "다 본다"이다. Helm subchart 버전, Terraform module의 ref 태그, GitHub Actions의 third-party action 버전, Kustomize의 newTag, 심지어 Dockerfile 안의 FROM 이미지 태그까지. 인프라 매니페스트 레포에서 쓰면 그동안 손으로 따라다니던 버전들이 한꺼번에 흐름을 갖기 시작한다.

packageRules의 표현력이 압도적이다. 예를 들면:

{
  "packageRules": [
    {
      "matchManagers": ["helm-values", "kubernetes"],
      "matchUpdateTypes": ["minor", "patch"],
      "groupName": "k8s manifests minor/patch"
    },
    {
      "matchPackagePatterns": ["^aws/"],
      "matchUpdateTypes": ["major"],
      "dependencyDashboardApproval": true
    }
  ]
}

이런 룰 한 줄이면 마이너/패치는 자동으로 묶이고, AWS 관련 major는 대시보드에서 수동 승인 후에만 PR이 열린다. 그리고 작년에 들어온 "merge confidence" 기능이 의외로 쓸만했다. 새 버전이 얼마나 많은 다른 레포에서 머지되고 있는지를 신호로 주는 건데, 적어도 "이 버전 우리만 쓰고 있는 거 아닌가" 하는 불안을 줄여준다.

단점. 첫 설정에 시간이 걸린다. preset을 그대로 갖다 쓰면 PR이 100개씩 쏟아진다. 처음 한 주 정도는 dependency dashboard 보면서 룰을 다듬는 시간이 반드시 필요하다. 우리 팀에서는 도입 첫 주에 누군가 self-hosted Renovate runner 메모리가 OOM으로 죽는 사건도 있었다. 큰 monorepo에서 Renovate를 GitHub App이 아닌 self-hosted로 돌릴 때 주의해야 한다.

또 하나, API rate limit은 여기도 적용된다. GitHub App으로 쓰면 그래도 한도가 넉넉한데, GitLab/Bitbucket에서 self-hosted로 돌릴 때는 hostRules로 토큰을 분산시켜야 했다.

ArgoCD Image Updater — GitOps에 끼울 때만 빛난다

Image Updater는 처음 봤을 땐 "이거 굳이 필요한가" 싶었다. CI에서 이미지 빌드한 다음에 그냥 매니페스트 레포에 sed로 태그 바꿔서 PR 열면 되는 거 아닌가. 근데 실제로 해보면 그 sed 스크립트가 점점 더러워진다. 환경별로 분기되고, semver 정렬 처리 들어가고, regex 처리 들어가고. 그러다 보면 결국 Image Updater 같은 게 필요해진다.

장점은 레지스트리 기반이라는 것. Manifest 레포가 아니라 컨테이너 레지스트리를 폴링하니까, 개발팀이 CI에서 이미지를 푸시하기만 하면 그게 운영 클러스터까지 흘러간다. write-back을 git으로 하느냐 ArgoCD에 직접 하느냐 선택할 수 있는데, 우리는 git write-back 모드만 쓴다. 그래야 변경 이력이 남고 ArgoCD가 죽었을 때도 진실의 원천이 git에 있다.

metadata:
  annotations:
    argocd-image-updater.argoproj.io/image-list: app=registry.example.com/myapp
    argocd-image-updater.argoproj.io/app.update-strategy: semver
    argocd-image-updater.argoproj.io/app.allow-tags: regexp:^v\d+\.\d+\.\d+$
    argocd-image-updater.argoproj.io/write-back-method: git
    argocd-image-updater.argoproj.io/write-back-target: kustomization

update-strategy로 semver, latest, digest, newest-build을 줄 수 있다. 우리는 prod에서는 semver, dev에서는 newest-build로 잡았다. 빠른 피드백이 필요한 dev 환경에서는 빌드 즉시 반영되도록.

단점. 레지스트리 폴링 주기가 짧지 않다. 기본 2분, 더 짧게 가능하지만 레지스트리 부하가 올라간다. 그리고 kustomize override나 Helm parameter를 만지는 방식이 좀 거칠다. 매니페스트 구조가 복잡하면 write-back-target을 신경 써야 한다. 처음에 우리 팀은 Helm 차트 안에 image.tag를 직접 박는 구조를 쓰고 있어서, Image Updater가 values 파일을 안 만지고 ConfigMap 같은 데에 override를 쌓아두는 이상한 상태가 됐던 적이 있다. write-back-target을 명시적으로 잡고 나서야 해결됐다.

그래서 우리 팀은 어떻게 잘랐나

1년 굴리고 정리한 결론은 이렇다.

Dependabot은 애플리케이션 코드 레포에만. Node/Go/Python 같은 언어 의존성, 그리고 GitHub Security Advisory 대응. 그 외에는 끈다. 보안 이슈가 떴을 때 가장 빨리 PR을 쏘는 게 얘라서 이 역할만큼은 못 뺀다.

Renovate는 인프라/매니페스트 레포 전담. Helm chart, Terraform module, GitHub Actions, Dockerfile base image. 이쪽은 Dependabot이 잡지 못하는 영역이라 분쟁이 없다.

ArgoCD Image Updater는 매니페스트 레포 안에서 런타임 이미지 태그만. Renovate가 manifest 안의 모든 걸 보긴 하지만, "CI에서 방금 빌드된 이미지의 다음 태그"만큼은 레지스트리를 폴링하는 게 더 깔끔하다. 그래서 Renovate에는 argocd-image-updater가 보는 패턴은 제외하는 ignorePaths를 걸어뒀다.

이 분리 이후로 한 레포에서 두 봇이 같은 줄에 PR 쏘는 충돌이 사라졌다. 리뷰어들 불평도 줄었고. 처음부터 이렇게 잘랐으면 좋았을 거란 생각이 든다.

마무리

솔직히, 처음에는 "셋 다 같은 일을 한다"고 생각했다. 그래서 하나로 통일하려 했고, 그 시도는 실패했다. 각각이 보는 세계가 달라서 한 도구로 다 못 잡는다. 통일이 아니라 분담이 답이었다.

혹시 의존성 봇 도입을 고민 중이시면, 먼저 "내가 잡고 싶은 게 코드 의존성이냐, manifest 안의 모든 버전이냐, 런타임 이미지냐"부터 물어보시면 좋을 것 같다. 그 답이 도구를 골라준다.

다른 팀에서는 어떻게 분담하시는지 궁금하다. 혹시 우리랑 다르게 잘라놓으신 분 있으면 댓글 부탁드립니다.

유아 떼쓰기, 화내지 않고 끝내는 부모의 5단계 대처법

gfrog — Fri, 15 May 2026 00:15:43 +0900

마트 한복판에서 갑자기 바닥에 드러눕는 아이, 잠자리에 들기 직전에 폭발하는 울음. 떼쓰기(분노 발작, temper tantrum)는 만 1세 후반부터 4세 사이 아이들에게 흔히 나타나는 정상적인 발달 과정입니다. 하지만 알면서도 그 순간이 되면 부모도 함께 무너지기 쉽죠. 오늘은 떼쓰기가 폭발하는 그 짧고도 긴 시간을 조금 더 차분하게 넘기는 5단계 대처법을 정리했습니다.

1단계 — 내 호흡부터 가다듬기

아이가 폭발하는 순간, 부모의 심박수와 목소리부터 올라갑니다. 그 상태에서는 어떤 좋은 말도 잘 전달되지 않습니다. 짧게 코로 3초 들이쉬고 입으로 5초 내뱉는 호흡을 두세 번만 해보세요. "지금 내 아이가 나를 화나게 하려는 게 아니라, 자기 감정을 다루지 못하고 있는 거다"라는 사실을 한 번 떠올리는 것만으로도 톤이 달라집니다.

2단계 — 안전부터 확보하기

발길질, 물건 던지기, 머리 박기처럼 본인이나 주변을 다치게 할 수 있는 행동이 보이면 우선 위험 요소를 치우고, 필요하면 아이를 부드럽게 안아 안전한 공간(거실 매트, 차 안 카시트 등)으로 옮기세요. 이때 훈육의 말은 잠시 미뤄도 됩니다. 안전 확보가 먼저입니다.

_{Photo by Barbara Olsen on Pexels}

3단계 — 감정에 이름 붙여주기

아이가 자기 감정을 폭발 외의 방법으로 표현하지 못하는 이유는, 그 감정에 아직 이름이 없기 때문인 경우가 많습니다. "지금 정말 화가 났구나", "그 장난감을 너무 갖고 싶었구나", "엄마(아빠)랑 더 놀고 싶었는데 끝나서 속상하구나"처럼 상황 + 감정 단어 형식으로 짚어주세요. 행동을 허락하는 게 아니라 감정을 인정해주는 단계입니다.

이때 흔히 하는 실수는 "그게 뭐가 그렇게 화날 일이야"라며 감정을 축소하는 말입니다. 어른 기준으로는 사소해 보여도, 아이에게는 세상 전부일 수 있습니다.

4단계 — 규칙은 짧고 일관되게

감정을 받아준다는 것이 모든 행동을 허용한다는 뜻은 아닙니다. 위험하거나 타인에게 피해를 주는 행동에 대해서는 짧고, 부드럽고, 일관된 말 한 문장으로 선을 그어주세요. "사람을 때릴 수는 없어", "장난감은 던지지 않는 거야" 정도면 충분합니다. 길게 설명하거나 매번 기준이 달라지면 아이는 오히려 혼란스러워합니다.

5단계 — 폭풍이 지나간 뒤 다시 연결하기

분노 발작은 보통 5~20분 안에 가라앉습니다. 아이가 진정되기 시작했다면 등을 천천히 쓸어주거나, 물 한 잔을 건네거나, 같이 깊은 숨을 쉬어보세요. 이후에 짧게 한두 문장으로 정리해주면 좋습니다. "아까 정말 속상했지. 다음에 또 화나면 엄마(아빠)한테 '도와줘'라고 말해줘." 비난이 아니라 다음에 쓸 수 있는 대안을 가르쳐주는 것이 핵심입니다.

_{Photo by Pixabay on Pexels}

떼쓰기를 줄이는 평소 습관

수면과 식사 리듬 유지: 잠이 부족하거나 배가 고프면 감정 폭발 빈도가 눈에 띄게 올라갑니다.
선택권 주기: "이거 할래, 저거 할래?"처럼 작은 선택지를 주면 자율감이 채워져 갈등이 줄어듭니다.
예고하기: "5분 뒤에 놀이 끝내고 정리할 거야"처럼 미리 알려주면 전환 스트레스가 줄어듭니다.
부모의 감정 모델링: 부모가 평소 "지금 좀 피곤해서 잠깐 쉬어야겠어"처럼 자기 감정을 말로 표현하는 모습을 보여주면, 아이도 자연스럽게 따라합니다.

마무리

떼쓰기는 "내 아이가 잘못 자라고 있다"는 신호가 아니라 "아직 감정을 다루는 법을 배우는 중이다"라는 신호입니다. 매번 완벽하게 대처하지 않아도 괜찮습니다. 다섯 번 중 한두 번만이라도 위 단계대로 해보면, 아이도 부모도 함께 자라는 게 느껴질 거예요. 만약 분노 발작이 만 5세 이후에도 매우 자주 반복되거나, 자해·타해 강도가 강하다면 소아청소년과 또는 아동상담 전문가와 상담을 받아보시길 권합니다.

오늘 하루도 수고 많으셨습니다.

2026년 5월 15일 (금) 12간지 오늘의 운세

gfrog — Fri, 15 May 2026 00:10:11 +0900

Photo by Naro K on Pexels

안녕하세요. 5월의 중턱, 2026년 5월 15일 금요일입니다. 한 주의 마무리이자 새로운 주말의 시작을 앞둔 오늘, 12간지별로 가볍게 즐기는 운세를 준비했습니다. 따뜻한 차 한 잔과 함께 가볍게 읽어주세요.

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

오늘은 새로운 만남이 활력을 주는 하루입니다. 미뤄두었던 연락을 가볍게 이어보세요. 금전운은 무난한 흐름이지만 충동구매는 잠시 미뤄두는 것이 좋습니다. 건강은 어깨와 목 스트레칭으로 가볍게 풀어주세요.

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

차분히 일에 집중하면 좋은 결과가 따라오는 날입니다. 동료와의 협업에서 작은 칭찬이 들려올 수 있어요. 애정운은 안정적이며, 오래된 인연일수록 따뜻한 한마디가 효과적입니다. 점심은 든든하게 챙겨드세요.

Photo by eberhard grossgasteiger on Pexels

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

추진력이 살아나는 하루입니다. 미뤄두었던 결정을 가볍게 매듭지어 보세요. 다만 너무 강하게 밀어붙이면 주변과의 마찰이 생길 수 있으니 한 박자 쉬어가는 여유도 필요합니다. 금전운은 작지만 기분 좋은 수입이 기대됩니다.

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

감수성이 풍부해지는 날입니다. 좋아하는 음악이나 향이 마음을 한층 가볍게 해줄 거예요. 애정운은 상대의 작은 변화를 알아채면 분위기가 한결 부드러워집니다. 건강은 충분한 수분 섭취가 키워드입니다.

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

큰 그림을 그리기 좋은 하루입니다. 단기 성과보다 중장기적인 계획을 점검해 보세요. 금전운은 무리한 투자보다 자산 정리가 어울리는 시점입니다. 가벼운 산책으로 머리를 비우면 좋은 아이디어가 떠오릅니다.

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

직관이 빛나는 날입니다. 망설였던 선택지가 있다면 마음의 소리에 귀를 기울여 보세요. 다만 중요한 계약이나 서명은 한 번 더 검토하는 것이 안전합니다. 애정운은 진심 어린 대화가 관계의 깊이를 더해줍니다.

말띠 (1978, 1990, 2002, 2014)

활동량이 높아지는 하루입니다. 야외 일정이 즐거움으로 다가올 수 있어요. 금전운은 외출이 잦은 만큼 지출 관리에 신경 써 주세요. 건강은 무리한 운동보다 가벼운 스트레칭이 더 어울립니다.

양띠 (1979, 1991, 2003, 2015)

마음의 여유가 행운을 부르는 날입니다. 주변 사람에게 작은 친절을 베풀면 예상치 못한 좋은 소식이 돌아올 수 있어요. 애정운은 솔직한 표현이 분위기를 살립니다. 금전운은 안정적인 흐름이 이어집니다.

Photo by Dương Nhân on Pexels

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

재치와 유머가 빛을 발하는 하루입니다. 모임이나 회의에서 분위기 메이커 역할을 하게 될 수 있어요. 금전운은 정보가 곧 자산입니다. 새로 들려오는 이야기에 가볍게 귀를 열어두세요. 건강은 눈의 피로에 주의하세요.

닭띠 (1981, 1993, 2005, 2017)

꼼꼼함이 빛나는 날입니다. 평소 놓치기 쉬운 디테일을 한 번 더 확인해 보세요. 작은 발견이 큰 차이를 만듭니다. 애정운은 표현보다 행동이 더 와닿는 시기이며, 건강은 규칙적인 식사가 컨디션을 좌우합니다.

개띠 (1982, 1994, 2006, 2018)

신뢰의 가치가 돋보이는 하루입니다. 주변에서 도움을 청해올 수 있으니 가능한 선에서 따뜻하게 응답해 보세요. 금전운은 무난하며, 오랜 친구와의 식사가 좋은 기운을 가져다줍니다. 건강은 가벼운 산책을 추천합니다.

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

여유로운 마음이 좋은 흐름을 만드는 날입니다. 너무 서두르기보다 천천히 호흡을 가다듬어 보세요. 애정운은 따뜻한 분위기, 금전운은 작은 정돈이 행운을 부릅니다. 건강은 충분한 휴식이 필요한 시점입니다.

오늘의 행운 키워드: 여유, 따뜻함, 정돈

본 운세는 오락 목적이며 참고용입니다. 즐거운 5월 15일 금요일 보내세요!