푸른영혼의 별 | Tech Blog

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

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


Posts (총 505편 · 17 / 51 페이지)

  • 정산 시스템 에 적용한 QueryDSL — 헥사고날 · 커서 페이징 · 프로젝션 실전

    정산(settlement) 시스템 의 조회 계층 은 전부 QueryDSL 로 짰다. 단순 CRUD 면 Spring Data JPA 로 충분 하지만, 정산 은 동적 검색 · 대용량 페이징 · 집계 · 대사(reconciliation) 가 핵심 이라 — 문자열 JPQL 로는 감당 이 안 된다. 이 글 은 실제 코드 로 QueryDSL 을 어떻게 붙였는지 정리 한다.

  • 여러 프로젝트, 반복 되는 설계 — 내가 계속 고르는 6가지

    프로젝트 를 여러 개 굴리다 보면 알게 된다. 설계 에 정답 은 없지만, 내가 반복 해서 고르는 결정 은 있다. 정산 시스템 이든 청각 재활 훈련 이든 XR 신앙 앱 이든 — 도메인 은 전혀 다른데, 뼈대 를 세우는 방식 은 자꾸 같은 곳 으로 수렴 한다.

  • AI 에이전트 아키텍처는, 백엔드 개발자 가 이미 아는 것 이다

    AI 에이전트 를 공부 하다 보면 새 단어 가 쏟아진다 — Orchestrator, Guardrail, Memory, Tool, Human-in-the-loop… 처음 엔 완전히 새로운 세계 처럼 보인다. 그런데 하나씩 뜯어보면 백엔드 엔지니어 가 이미 10년 째 짓고 있던 것 들 이다. 이름 만 바뀌었을 뿐 이다.

  • Hermes Agent vs OpenClaw — 두 오픈소스 개인 AI 에이전트 비교 분석

    요즘 “내 메신저 에 사는 개인 AI 에이전트” 판 에서 가장 뜨거운 두 이름 — OpenClawHermes Agent. 나 는 홈랩 에서 텔레그램 기반 운영 봇 을 직접 굴리고 있고, Hermes 도 로컬 에 설치 해 만지는 중 이라 — 이 둘 을 구조 · 철학 · 실사용 관점 으로 비교 해 본다.

  • Loop Engineering — 2026년 7월, 지금 가장 뜨거운 개발 키워드 해부

    2026년 6월 7일, Steinberger 의 트윗 하나 가 조회수 8.5M 을 찍었다 — “코딩 에이전트 를 프롬프팅 하지 말고, 에이전트 를 프롬프팅 하는 루프 를 설계 하라.” 같은 날 Osmani 가 이 실천 에 loop engineering 이라는 이름 을 붙였고, Cherny 는 무대 에서 이렇게 말했다: “나는 더 이상 Claude 를 프롬프팅 하지 않는다. 루프 들 이 돌면서 Claude 를 프롬프팅 하고 뭘 할지 알아낸다. 내 일 은 루프 를 쓰는 것 이다.”

  • STT 와 TTS — 3.1초 짜리 "안녕" 을 알아듣기 까지

    새벽 에 텔레그램 으로 3.1초 짜리 영상 메시지 하나 가 왔다. 그리고 질문 — “이거 음성 으로 보낸 건데, 너 알아들을 수 있어?”

  • 멀티 에이전트, 실전 에서 — *에이전트 를 늘리는 것* 과 *일 이 되게 하는 것* 은 다르다

    “에이전트 하나 로 되는데 왜 여러 개 를 쓰나?” — 반대로 물어보자. 회사 는 왜 한 사람 이 아니라 팀 으로 일 하는가. 컨텍스트(기억) 의 한계, 관점 의 한계, 병렬성 의 필요. 멀티 에이전트 는 정확히 그 문제 를 푸는 구조 다. 다만 — 팀 이 늘 좋은 게 아니듯, 에이전트 도 늘린다고 좋아지지 않는다.

  • 멀티 에이전트 란 무엇 인가 — *한 명 의 만능* 대신 *쪼개고 · 동시에 · 서로 검증*

    AI 에이전트 얘기 가 나오면 요즘 꼭 따라붙는 말 이 멀티 에이전트(multi-agent) 다. 한 줄 로 정의 하면:

  • CPUThrottlingHigh 57.5% — CPU 사용률 이 아니다

    밤 에 홈랩 클러스터 에서 알림 이 하나 왔다.

  • 장애 하나 를 당기니 버그 다섯 이 딸려 나왔다 — K8s·Java 운영 하루 의 시니어 회고

    “정산 이 왜 안 되지?” — 이 한 문장 으로 시작 한 하루 가, 서로 다른 버그 다섯 개 를 꿰어 놓은 체인 이었다. 프로덕션 500, 시한폭탄 테스트, Docker Hub rate limit, 유틸 컨테이너 함정, Dockerfile 드리프트. 이 글 은 그 하루 를 10년차 백엔드 시니어 의 관점 으로 복기 한다 — 무엇 을 고쳤는지 보다, 어떤 순서 로 생각 했는지 를 남기기 위해.