JH's Engineering Notes

안녕하세요.
|
백엔드 개발자 김정현입니다.

SigNoz MCP로 로컬 세션에 운영 모니터링 스킬을 붙이고 다듬은 기록New

요즘 운영 로그와 트레이스는 대시보드 대신 로컬의 Claude Code 세션에서 본다. SigNoz MCP 서버를 붙여두고, 조사 순서를 정해둔 스킬로 배포 전후 모니터링을 맡긴다. 처음에는 도구만 붙여두고 그때그때 물어봤다. 그러다 에이전트가 MCP 도구의 사용 방법을 잘못 짚거나 의도와 다르게 쓰는 일을 겪으면서, 조사 순서를 저장소 안에 스킬로 정해뒀다. 지금도 모니터링 중 발견한 문제를 반영하며 계속 고치고 있다. 그렇게 쌓인 규칙 중에는 MCP 도구의 한계를 메우기 위한 우회책도 섞여 있었다. 이 글은 그 스킬을 만들고 유지해온 기록이다. 스킬에 무엇을 담았는지, MCP 버전이 바뀔 때 스킬이 어떻게 흔들렸는지, 그리고 우회책을 계속 쌓는 대신 원인이 있는 업스트림을 고치기 시작한 이야기를 남긴다. 사내 서비스는 self-hosted SigNoz로 로그와 트레이스를 모으고 있다. SigNoz는 공식 MCP …

5 min0 2026.10.13

SigNoz MCP로 로컬 세션에 운영 모니터링 스킬을 붙이고 다듬은 기록

좋은 이슈 리포트는 어떻게 만들어지는가

지난 “조용히 비어버린 값 하나에서 시작한 ORM 메이저 업그레이드 검증 전략” 포스팅을 이렇게 맺었다. 같은 사례의 업스트림 이슈는 찾지 못했다. 재현 조건을 좁히고 “버그”로 볼지 “진단 메시지 개선 요청”으로 볼지 스스로 먼저 결론을 낸 뒤, 최소 재현 저장소와 함께 제보해볼 생각이다. 어제 그 이슈를 올렸다. 09-21 13:51 — 이슈 등록 (mikro-orm#8292) 09-21 14:12 — 다른 컨트리뷰터가 PR 등록 (mikro-orm#8293), 이슈로부터 21분 09-22 02:25 — 메인테이너 머지, 이슈 종료 정작 내가 쓴 코드는 한 줄도 없다. 고친 것은 다른 사람이고, 나는 재현과 이슈 본문만 썼다. 이 글은 사내에서 우회로 덮어둔 문제를 업스트림 이슈로 옮기기까지의 기록이다. 그리고 왜 이 이슈가 21분 만에 PR로 이어졌는지, 그 이유라고 생각하는 것들을 남긴다. 문제 자체는 지난 글에서 정리했다…

Backend

5 min0 2026.09.22

조용히 비어버린 값 하나에서 시작한 ORM 메이저 업그레이드 검증 전략

최근 사내 패키지 업데이트와 더불어 NestJS 12+ / MikroORM v7+ 로 버전 업데이트를 진행했다. 대부분은 타입 에러를 지우고 변경된 API를 따라가는, 예상 범위 안의 작업이었다. 그 과정에서 유독 오래 붙잡고 있었던 문제가 하나 있었다. MikroORM 업데이트 중, 임베디드 값 객체(Value Object)로 매핑한 필드가 특정 조회 경로에서만 조용히 비어버리는 현상이었다. 에러도 불분명했고, 타입 에러조차 나지 않았다. 컴파일은 통과하고 런타임에서만 값이 사라지는 형태라, e2e 시나리오가 아니었다면 아마 조용히 배포되어 운영에서 마주쳤을 문제였다. 이와 더불어 자연스럽게 따라온 질문이 있었다. 다른 지점에서도 같은 성격의 이슈가 더 있지 않을까? 그래서 e2e 시나리오의 검증 축을 옮겼다. 단순히 “응답이 같은가”를 확인하는 것에 더불어, “발행되는 쿼리가 같은가” 에 포커스를 맞추는 방향으로. 이번 포스팅은 그 판단의 과정과, 그래서 만…

Backend

6 min0 2026.09.18

53분짜리 크론 하나에서 시작한 배포 종료 설계

한동안 배포할 때 사람이 기다리는 시간이 있었다. (한.. 오전 09:00 ~ 10:00 사이쯤?) 이메일을 보내는 크론 하나가 한 회차에 53분 걸렸기 때문이다. 그게 도는 중에 배포하면 발송이 중간에서 끊길 것 같아, 끝나기를 기다렸다가 배포한 적이 있다. 서비스는 Kubernetes 위에서 돌고 ArgoCD 가 롤링 업데이트로 배포한다. 새 파드가 준비되면 구 파드는 정해진 유예 시간 안에 사라진다. 53분짜리 작업이 그 안에 끝날 수는 없으니, 기다리는 쪽을 사람이 맡고 있었던 셈이다. 처음엔 이걸 성능 문제로 봤다. 크론이 느리니 빠르게 만들면 되는 일이라고. 그런데 실행 시간을 분해해보니 대부분이 의도적으로 넣은 대기 였다. 메일 서버의 rate limit 에 걸려 발송이 거부되는 것을 막기 위해 한 건과 다음 건 사이에 간격을 두고 있었다. 성능을 위해 줄여도 되는 값이 아니라, 발송이 성립하기 위한 조건이었다. 이 크론은 v1 서비스에서 v2 로 …

Backend

6 min0 2026.09.08