푸른영혼의 별 | Tech Blog

Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.

주요 프로젝트: Settlement MSA · ASAT · GitHub


Posts (총 379편 · 1 / 38 페이지)

  • MCP와 Harness — 좋은 에이전트는 모델이 아니라 운영 구조에서 나온다

    에이전트 harness 설계 8구획 — Candidate Workflow / Outside / Inside / State & Checkpoints / Retry & Re-question / Output Contract / Capability Matrix(NEW) / Skill Bundle(NEW)

  • 무엇에도 종속되지 않기 — 이식 가능한 에이전트 하네스의 두 결합 끊기

    에이전트 시스템을 오래 굴리다 보면 한 가지 두려움이 생긴다. 종속. 특정 벤더의 런타임에 묶이고, 특정 세션 상태에 묶이면, 그 위에 쌓은 모든 게 그 결정과 함께 죽는다. 모델은 6개월마다 갈리고, CLI는 이름을 바꾸고, 가격 정책은 하루아침에 뒤집힌다.

  • 에이전트 와 하네스 — 흡수 되는 것 과 끝까지 남는 것

    1년 도 안 돼서, 우리 가 손 으로 짜던 하네스제품 기능 이 되기 시작 했다. 에이전트 생성, 병렬 실행, 범용 런타임 — 예전 엔 직접 조립 하던 걸 이제 플랫폼 이 버튼 하나 로 준다. 그럼 하네스 는 사라지는 걸까. 두 장 의 그림 이 이 질문 을 정면 으로 다룬다. 이 글 은 그 둘 을 겹쳐 읽으며, 무엇 이 흡수 되고 무엇 이 끝까지 사람 몫 으로 남는가 를 고찰 한다.

  • AI & K8s 데일리 브리핑: 2026-07-15

    AI & K8s 데일리 브리핑: 2026-07-15

  • 외부 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 플랫폼 · 데이터 거버넌스 플랫폼 — 을 나란히 놓고 그 구조를 읽는다. 세 장은 따로 그려졌지만, 겹쳐 보면 하나의 이야기가 된다.