푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 505편 · 14 / 51 페이지)
-
외부 IP 없이 집 클러스터 를 공개 하기 — 홈랩 K3s 를 프로덕션 처럼 운영 한다는 것
집 에 있는 K3s 클러스터 가 실제 도메인 으로 서비스 를 공개 한다. 공인 IP 도 없고, 공유기 에 포트포워딩 도 안 한다. 그런데 어떻게 인터넷 에서 접속 이 될까. 이 글 은 그 “한 장 요약” 을 뜯어보며, 홈랩 을 프로덕션 처럼 운영 한다 는 게 구체적 으로 무슨 뜻 인지 를 정리 한다.
-
쿠버네티스 CI/CD 와 Private Registry — push 한 줄 이 배포 되기 까지
git push한 줄 이 어떻게 클러스터 의 파드 로 바뀌는가. 그 사이 에 CI(빌드·테스트) 와 CD(배포), 그리고 그 둘 을 잇는 Private Registry 가 있다. 이 글 은 온프레미스 K3s 에서 실제로 굴리는 파이프라인 — GitHub Actions → ghcr → ArgoCD Image Updater → K3s rollout → 외부 검증 — 을 흐름 대로 따라가며, 그 과정 에서 밟은 함정 들 을 정리 한다. (6노드 클러스터 운영 의 배포 층 에 해당 한다.) -
포트를 하나도 열지 않고 홈랩을 공개하기 — Cloudflare로 보는 실전 보안
집에 있는 K3s 클러스터를 인터넷에 공개하려면, 보통은 공유기에서 포트 포워딩을 열고 공인 IP를 DNS에 박는다. 그 순간부터 전 세계의 스캐너가 그 포트를 두드린다. 공인 IP가 유동이면 DDNS로 씨름해야 하고, origin IP가 노출되니 DDoS를 정면으로 맞는다.
-
쿠버네티스 보안 — 온프레미스 클러스터 를 지키는 7개 층
쿠버네티스 보안 은 “방화벽 하나 잘 치면 끝” 이 아니다. 공격 표면 이 층층 이 다 — API 서버, 노드 호스트, 시크릿, 네트워크, 이미지, 파드, 감사. 한 층 이 뚫려도 다음 층 이 막게 깊이(defense in depth) 로 쌓아야 한다. 6노드 온프레미스 K3s 를 굴리며 실제로 챙기는 순서 대로, 7개 층 을 정리 한다.
-
6노드 온프레미스 K3s 를 운영 한다는 것 — 노드 를 그림 으로 읽기
집 에 K3s 클러스터 를 6노드 로 굴린다. 노트북·데스크탑·2014년 맥미니 가 섞인 이기종 온프레미스 다. 클라우드 처럼 노드 가 균일 하지 않으니, 운영 의 핵심 은 “어느 워크로드 를 어느 노드 에 둘 것인가” 로 수렴 한다. 이 글 은 그 클러스터 를 노드별 한 장 씩 그림 으로 뜯어 보며, 온프레미스 K3s 운영 에서 실제로 부딪힌 것 들 을 정리 한다.
-
클라우드·데이터·AI — 세 장의 플랫폼 청사진과 그 위를 관통하는 신경계
엔터프라이즈에서 “플랫폼”을 그리면 결국 계층 다이어그램이 나온다. 아래에 인프라, 위로 갈수록 사람이 닿는 접점. 이 글은 서로 다른 세 장의 플랫폼 청사진 — 클라우드 관리 플랫폼 · AI/ML 플랫폼 · 데이터 거버넌스 플랫폼 — 을 나란히 놓고 그 구조를 읽는다. 세 장은 따로 그려졌지만, 겹쳐 보면 하나의 이야기가 된다.
-
Claude Code 서브에이전트 필드 16개 — .md 한 장 으로 에이전트 를 정의 하는 법
Claude Code 에서 서브에이전트 는 별도 프로그램 이 아니다.
.claude/agents/밑 에 .md 파일 한 장 — 상단 frontmatter 에 필드 몇 개, 본문 에 시스템 프롬프트. 그 필드 들 이 “이 에이전트 는 누구고, 무슨 도구 를 쥐고, 어떤 두뇌 로, 어떻게 실행 되는가” 를 통째로 정한다. 아래 16개 가 그 전부 다. -
Claude 모델 고르기: 추론 깊이 × 비용으로 Haiku·Sonnet·Opus 선택하기
Claude 모델 고르기: 추론 깊이 × 비용으로 Haiku·Sonnet·Opus 선택하기
-
장애는 어디서 새는가 — 관측·추적·진단으로 보는 장애대응과 성능분석
새벽 4시, 알림이 울린다. “502가 6분째 뜬다”는 걸 사용자가 나보다 먼저 발견했다면, 그건 관측(observability)이 실패한 것이다. 장애대응의 승부는 불이 난 뒤 얼마나 빨리 끄느냐가 아니라, 불씨를 얼마나 먼저 보느냐에서 갈린다.
-
Reflection과 Proxy 심화 — 스프링의 마법과 @Transactional이 조용히 안 먹는 이유
@Transactional한 줄 붙였는데 롤백이 안 된다.@Async붙였는데 그냥 동기로 돈다.@Cacheable인데 캐시를 씹는다. 스프링을 좀 써 본 사람이면 한 번쯤 당하는 이 “조용한 실패”의 정체는 버그가 아니라 스프링이 어떻게 만들어졌는지를 모르는 데서 온다.