푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 133편 · 1 / 14 페이지)
-
SOLID 원칙 × 디자인 패턴 — *결제 처리 시스템* 으로 보는 *왜 그 패턴이 그 자리* 인지
“SOLID 5원칙 외웠고 GoF 23개 패턴도 안다. 근데 실전에서 어디에 써야 할지 모르겠다.” — 이게 교과서로만 배운 사람의 가장 흔한 막힘.
-
개발 프로세스 60년 — *변하는 것* 과 *변하지 않는 것*, 그리고 *좋은 문화* 를 넘어 *훌륭한 문화* 란 무엇인가
“우리 팀은 애자일 합니다” 라는 문장은 어떤 회사도 부정하지 않는다. 그런데 같은 팀에서 3개월에 한 번 배포하는 데가 있고 하루 50번 배포하는 데가 있다. 같은 Scrum 을 하는데 어떤 팀은 spec 한 줄에 일주일 토론하고 어떤 팀은 PRD 없이 직접 만든다.
-
Grafana 의 *3종 데이터소스* — Prometheus (메트릭) · Elasticsearch (로그) · Tempo (트레이스) 의 *제대로 된* 사용법
홈랩 K3s 의 Grafana 에 3종 데이터소스 가 붙어있다. Prometheus (메트릭), Elasticsearch (로그), Tempo (트레이스). 셋 다 3대 옵저버빌리티 기둥 으로 유명한데, Grafana 안에서 함께 쓸 때의 진짜 가치 는 각자가 답하는 질문 이 다르고, 셋이 연결될 때 1+1+1 > 5 가 된다는 거다.
-
ArgoCD · Grafana · Kibana — *실제로 봐야 하는* 화면은 어디인가 (운영자 관점 고찰)
K3s 홈랩에 세 대시보드 가 들어가 있다. ArgoCD 는 배포 상태, Grafana 는 메트릭, Kibana 는 로그. 셋 다 설치하면 멋있어 보이지만, 실제로는 3개월 뒤 에 한 번도 안 켜본 탭이 두 개 정도 생긴다. 왜 그렇게 되는지, 진짜 봐야 할 것 은 무엇인지 — 운영하면서 만들어진 판별 기준 을 적는다.
-
Java vs Kotlin — 코드량·기업 ROI·손익분기점 관점의 비교, 그리고 Claude Code 시대에 *어느 언어가 AI 와 더 시너지* 인가
Kotlin 이 Java 대비 코드 40% 짧다 는 말, 매우 자주 듣는다. 진짜인가? 그게 기업 ROI 로 환산하면 얼마인가? 그리고 *Claude Code 시대 에 AI 가 어느 언어를 더 잘 만들고, 우리는 어디에 시간 투자해야 하나?
-
Java · Spring · Hexagonal — *복잡 *도메인의 *정합성 + 확장성을 *책임지는 *팀 표준 *설계*
’‘우리 팀의 코드가 *3 년 후에도 *유지보수 가능 할까?’‘’‘. *시니어가 *팀 코드 *리뷰하다 *문득 *떠올리는 *이 *질문은 *’‘기술 표준의 부재’’ 의 증상 이다. 3 명 *팀이 *각자 *’‘자신의 베스트 *프랙티스’’ 로 짜면 *결과는 *3 가지 *서로 *다른 *구조. 6 개월 뒤 *합류한 *신입은 *’‘어느 게 맞는 거지?’’ 라며 또 *네 번째 *스타일을 *만든다.
’‘기술 표준’’* 은 ’‘독재’’* 가 아니다. ’‘팀이 같은 *문제에 *같은 *답을 *낼 수 있게 *만드는 *집단적 *어휘’’ 다. 이 글은 Java + Spring + Hexagonal Architecture 를 기반으로, 복잡 도메인의 *정합성과 *확장성을 *책임지는 *팀 표준 을 어떻게 *정의하고 *어떻게 *유지할 것인가 를 시니어 백엔드 *관점에서 *과거의 *교훈과 *미래의 *방향 으로 본다.
-
MSA · Kubernetes · ELK — *''*베스트 *프랙티스''* 가 *오버엔지니어링이 *되는 *손익분기점* 과 *대안 *분석*
’‘우리도 Netflix 처럼 *MSA 로 가야 합니다’‘. ’‘우리도 Google 처럼 *Kubernetes 로 *가야 합니다’‘. ’‘우리도 Uber 처럼 *ELK 로 *가야 합니다’‘. 2020 ~ 2025 한국 IT 업계의 *수많은 *기술 임원이 *반복한 *문장들 이다. 그리고 수많은 *팀이 *그 결정 *후 *6 개월 ~ 2 년 동안 *’‘기능을 전혀 추가하지 *못하고 *인프라만 *세팅’’ 하다가 *번아웃 했다.
이 글은 ’‘MSA / Kubernetes / ELK 는 나쁘다’’ 라고 말하지 *않는다. ’‘조건이 맞을 때’’ 는 압도적으로 *옳다. 다만 ’‘조건이 안 맞을 때 *얼마나 *비싸지는가’‘, ’‘그 조건의 손익분기점은 *어디인가’‘, ’‘그 전 단계에서 *어떤 *대안이 *충분한가’’ 를 수치 + 사례 + 권고 로 본다.
-
IntelliJ vs Eclipse, 그리고 도구를 초월하는 실력 — 알고리즘·자료구조의 본질과 유료 IDE 의 *손익분기점* 을 경영학적으로 분석
도구가 좋은 개발자를 만드는가, 좋은 개발자가 도구를 잘 쓰는가 — 이 질문은 오래된 미해결 논쟁. 한쪽 끝엔 “IntelliJ Ultimate 없이는 Java 못 짠다”, 다른 끝엔 “vim 만으로 다 한다”. 진실은 그 사이 어딘가, 그리고 각자의 임계점이 다르다.
-
이커머스 × Spring AI × Elasticsearch × MSA — *4 영역의 *교차점에서 *전문가는 *무엇을 *어떻게 *말하는가*
2026 년의 이커머스 백엔드 시니어 는 ’‘Spring Boot 잘 함’’* 한 줄로는 부족하다. ’‘상품 검색이 왜 *틀리는가’’ 라는 고객 *민원에 *답할 수 있어야 하고, ’‘RAG 가 언제 환각하는가’’ 를 PM 에게 *설명할 수 있어야 하고, ’‘Elasticsearch shard 가 왜 *느려졌나’’ 를 5 분 *안에 진단할 수 있어야 하고, ’‘MSA 경계가 우리 도메인에 *맞는가’’ 를 기술임원에게 *주장할 수 있어야 *한다.
이게 ’‘4 영역의 교차점’’ 이 만들어내는 2026 의 *시니어 *상. 각자 *깊이가 있는 *사람은 *많지만, *4 영역 *모두에서 *말할 수 있는 *사람은 *드물다. 그래서 연봉이 *비싸다.
-
K3s 의 한계 — 5 노드 홈랩을 1 년 운영하며 부딪힌 실전 함정과 *언제 RKE2/Talos/vanilla 로 갈아탈 것인가*
K3s 는 경이로운 도구다. 70MB 바이너리 한 개로 완전한 Kubernetes 가 1 분 내 돈다. 라즈베리 파이 / 노트북 / 작은 데스크탑에서도 production-grade 워크로드 운영 가능. 내 5 노드 홈랩 클러스터 (lemuel/ilwon/louise/david/solomon) 가 1 년 동안 settlement, lemuel-xr, academy, sparta-msa 등 수십 개 prod 워크로드 를 무사히 굴린 증거.