푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 302편 · 1 / 31 페이지)
-
-
-
Outbox 패턴 에서 JPA · MyBatis · QueryDSL 의 *경계* — 하나 로 모두 하려 하지 말라
“JPA 를 쓰는 팀 은 *모든 것 을 JPA 로 하려 함. MyBatis 팀 은 모든 것 을 MyBatis 로”* — 이 함정 이 Outbox 패턴 의 *진짜 실패 원인. Outbox 는 4 가지 성격 이 다른 데이터 접근 을 요구 — 하나 의 도구 로 강제 하면 *성능 / 유지보수 / 안전 성 이 모두 손상.
-
Spring AI vs Python AI — 생태계·TCO·RAG·Agent·2026 outlook 통합 심층 비교
3 일 전 sparta-msa 관점 의 Spring AI vs Python 비교 글 을 썼다. 그러나 조직 규모 / 팀 stack / 사용 케이스 에 따라 답 이 완전 히 달라짐 — 더 넓은 각도 의 통합 비교 필요. 이 글은 생태계·인력 / TCO / RAG / Agent / 2026-2027 outlook 의 6 부 + 24 가지 조합 결정 매트릭스.
-
IntelliJ 실행 (데스크탑) 과 Telegram 실행 (모바일) — CPU / Memory / SSD / Ethernet 의 *실 과정 추적*
“IntelliJ 를 더블 클릭 하면 *무엇 이 일어나는가?” — 프론트/백엔드 개발자가 매일 반복 하지만 실제 로 *무엇 이 벌어지는지 는 잘 모름. 이 글은 데스크탑 (IntelliJ) + 모바일 (Telegram) 의 실행 순간 을 하드웨어 (CPU / Memory / SSD / Wi-Fi/이더넷) 관점 에서 시간 축 으로 추적.
-
Node.js · Python · Kotlin · Go — 백엔드 4 언어 의 *기본기* 비교
내 sparta 의 Spring Boot 4, lemuel-xr 의 Spring + WebGL, LabNote ELN 의 Node.js MSA, settlement 의 Python 분석 사이드카 — 14 개월 운영 하면서 4 언어 를 *제각각 의 자리 에서 사용. 어느 언어 도 유일 한 답 이 아니다. 각자 의 *철학 과 *trade-off 의 이해 가 현실 의 *합리적 선택.
-
*CS 기초* 와 *백엔드 구조* — *4 기둥 + 4 기둥* 의 *지도* 와 *둘의 연결* — *신입 부터 시니어 까지 의 평생 기본기***
“백엔드 개발자 가 알아야 할 게 *너무 많다” 라는 흔한 푸념.
진짜다. 그러나 *4 + 4 = 8 개 의 기둥 으로 정리 하면 — 기본기 의 지도 가 손 안 에 들어온다. 각 기둥 의 *5 가지 핵심 만 깊이 체득 하면 — 나머지 는 *그 위 의 *조합 의 응용.
이 글은 그 *지도 의 큰 그림 이다.
-
*클라우드 (AWS) + 데이터베이스 (RDBMS / NoSQL)* — *2026 백엔드 의 *2 가지 기반* 의 *기본 의 정리* 와 *선택 의 판단 틀**
백엔드 개발자 의 *입사 1 일차 — 팀 의 *온콜 슬랙 에서 EC2 의 *t3.medium 이 *AZ ap-northeast-2c 에서 *재기동 됐고 RDS 의 *Multi-AZ failover 가 *15 초 의 *connection drop 을 *유발 했다는 얘기 가 오간다. 옆 의 *시니어 가 *“DynamoDB 의 *partition key 의 *hot partition 도 *같이 봐” 라고 덧 붙인다.
처음 의 *주니어 — *각 단어 가 *외계어. 6 개월 뒤 — *대충 의미 가 *잡힘. 3 년 뒤 — *왜 그 결정 들 이 그렇게 되었는지 의 원리 가 *보인다. 9 년 뒤 — *내 가 *그 결정 의 *주인. 그 사이 의 *학습 의 *대부분 이 *2 가지 영역 의 *기본 의 *밑바닥. 클라우드 + 데이터베이스.
이 글은 그 *2 가지 의 *기본 을 9 년차 시각 으로 *외우는 것 이 아니라 *선택 의 판단 틀 로 정리 한 주니어 → 미들 의 *지도.
-
*AI 기반 *추천 / 예측 / 분류* 의 *백엔드 설계* — *모델 학습* 은 *알아서* 한다고 *치고*, *서빙 / 피처 / 지연 예산 / 피드백 루프* 가 *진짜 *백엔드 의 *일* 이다
“AI 기능 = 모델 학습” 이라고 말하는 사람과 *“AI 기능 = *모델 은 *데이터 사이언티스트 가 만들고, 내가 할 일 은 *피처 / 서빙 / 지연 예산 / 피드백 루프 / A/B 테스트 다”* 라고 말하는 사람은 *PR 의 *변경 면적 이 완전히 다르다.
추천 / 예측 / 분류 는 서로 다른 *문제 지만 백엔드 입장 에서는 동일한 5 가지 *공통 결정 이 재 등장 한다. 어디서 *추론 하는가 (인라인 / 비동기 / 사전계산 / 모델 서버), *피처를 *어디서 *읽는가 (DB / Redis / Feature Store), 지연 예산 은 *얼마인가 (50ms vs 500ms), 모델 실패 시 *무엇 으로 *떨어지는가 (fallback), 결과 가 *맞았는지를 *어떻게 *기록 하는가 (feedback). 모델 자체 의 *정확도 는 그 후 의 질문.
이 글은 Spring Boot 백엔드 입장 에서 AI 기능 을 *집어 넣을 때 *반드시 *결정 해야 하는 *것 들을 체계화 한다. 모델 학습 의 *디테일 은 생략 — 백엔드 개발자 가 *프로덕션 에 *AI 기능 을 *얹기 위해 *알아야 하는 것 만 남긴다.
-
낙관적 락 실패 를 *어떻게 막을 것인가* — 14 개월 운영 으로 정리한 방어 코드
낙관적 락 은 충돌 이 드물 다 는 가정 의 동시성 전략. 그러나 production 의 *현실 — 동시 요청 의 *몇 % 가 *반드시 *충돌. 그 때 코드 가 어떻게 반응 하는지 가 시스템 의 *진짜 품질. 기능 구현 의 반대 편 — 실패 의 *우아 한 처리.