푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 1371편 · 126 / 138 페이지)
-
Claude Code 의 SKILL.md — *하네스의 *5 축* 으로 본 *본질 — *반복*, *역할*, *원칙*, *금지*, *고정*
SKILL.md 는 마크다운 파일 이다. 그게 끝 이다. 48 줄짜리 텍스트가 어떻게 LLM 의 *행동을 *재현 가능하게 고정* 하는가? '’그냥 *프롬프트 잖아’’* 라고 단순화하는 순간, 왜 같은 LLM 이 *어떤 프롬프트는 *지키고 어떤 프롬프트는 *3 턴 뒤 잊는가’’* 라는 질문에 답을 못 한다.
Claude Code 의 하네스 (harness) 는 '’system prompt + tool 정의 + 컨텍스트 관리 + 메모리 시스템 + 슬래시 커맨드 + 훅’’ 의 결합 무대 다. SKILL.md 는 그 무대 위에서 *재사용 가능한 행동 패턴 을 외부 파일 로 분리한 것. ’‘Skill 을 호출하면 그 순간 그 텍스트가 *system prompt 처럼 *주입’’* 되는 런타임 메커니즘.
-
Spring Filter vs Interceptor — TCP 패킷이 Controller 에 도달하는 12 단계와 그 사이에 누가 끼어드는가
“Filter 랑 Interceptor 가 뭐가 달라요?” 라는 질문에 “Filter 는 서블릿 표준이고 Interceptor 는 Spring 거예요” 라고만 답하면 반쪽. 진짜 차이는 네트워크 패킷이 Controller 메서드에 도달하기까지의 12 단계 중 어디에서 동작하느냐 에 있다.
-
Harness Engineering ④ Deployment Harness — CI/CD + GitOps, 그리고 *외부 검증* 까지 가야 끝나는 이유
“Harness Engineering 의 4 가지 얼굴” 시리즈의 마지막 4 편. ① AI Agent / ② Test / ③ Software Engineering
-
Harness Engineering ③ Software Engineering Harness — 팀의 *toolchain* 이 코드 품질을 결정한다
“Harness Engineering 의 4 가지 얼굴” 시리즈의 3 편. ① AI Agent / ② Test / ④ Deployment
-
Elasticsearch 운영의 *3 축* — *Shard/Replica 설계*, *Index Lifecycle*, 그리고 *Vector Search 의 함정*
'’Elasticsearch 가 *느려졌어요’‘. 이 한 문장은 *원인이 *5 가지 이상* 있을 수 있다 — 샤드가 너무 잘게 쪼개졌거나, 세그먼트가 *수십 만 개 쌓였거나, *JVM 힙이 *터질 듯 차 있거나, *cold tier 가 *hot tier 처럼 쿼리 받거나, *벡터 차원 인덱싱이 *오프힙 을 다 먹었거나. *경험 없으면 *5 곳을 다 들여다보기 전엔 원인을 모른다.
이 글은 그 5 곳을 *체계적으로 짚는 Elasticsearch 운영의 *3 축 — (1) Shard/Replica 설계, (2) Index Lifecycle Management, (3) Vector Search 튜닝 을 현장에서 다친 흔적 위주로 정리한다.
-
Java 의 Reactive Streaming — *Netflix RxJava* 부터 *Spring WebFlux* 까지, 그리고 *Loom 가상스레드* 가 다시 그린 지형
'’비동기는 어렵다’’ — 자바 진영이 15 년 동안 그 문장을 *7 번 다시 쓰며 진화 했다. Future → CompletableFuture → RxJava → Reactor → Flow API → WebFlux → Virtual Threads. 그리고 Loom 의 가상 스레드 가 등장한 2023 년 이후 — '’Reactive 가 정말 필요한가’’ 라는 근본적 질문 이 다시 던져졌다. 답은 '’필요하지만 *전보다 좁은 영역에서’‘*.
-
Kafka vs Kinesis — *오픈소스의 왕* 과 *클라우드 네이티브의 답*, 12 개 축에서 *솔직히* 비교
2010 년 LinkedIn 에서 '’N×M connector 카오스’’ 를 풀기 위해 Kafka 가 태어났다. 3 년 뒤 2013 년, AWS 가 '’Kafka 운영이 *너무 어렵다’’* 는 시장의 비명을 듣고 Kinesis 를 발표했다. 그 후 13 년, 둘은 *서로 다른 진영 의 서로 다른 답 으로* 살아남았다.
'’Kafka 와 Kinesis 중 무엇이 더 좋은가’’ 는 틀린 질문 이다. ’‘내 상황에서* 어떤 게 더 맞는가’’* 가 맞는 질문 이고, 그 답은 처리량·운영 인력·비용 모델·기존 스택·보존 기간 의 5 가지 축 위에서 갈린다.
-
Harness Engineering ② Test Harness — JUnit/Mockito/Testcontainers, 그리고 *통합 테스트가 단위 테스트만큼 빨라지는* 비밀
“Harness Engineering 의 4 가지 얼굴” 시리즈의 2 편. ① AI Agent Harness / ③ Software Engineering Harness / ④ Deployment Harness
-
헥사고날과 클린 아키텍처 — *''도메인이 *프레임워크* 를 모른다''* 라는 한 문장
'’내 도메인이 *Spring 을 import 하고 있다’‘. 이 한 줄에서 *'’이 코드는 *프레임워크 종속 이다’’* 라는 진단이 시작된다. 5 년 뒤 Spring 4 → Spring 7 으로 이관하려고 보니 모든 도메인 클래스가 *프레임워크 메이저 버전에 묶여 있는 것 을 발견* — 이게 '’Big Ball of Mud’’ 가 만들어지는 전형적 시나리오 다.
Alistair Cockburn 의 헥사고날 아키텍처 (2005) 와 Robert C. Martin 의 클린 아키텍처 (2012) 는 같은 문제에 대한 두 가지 표현 이다. '’도메인은 *세상 을 모른다. 세상 이 도메인을 입양 한다’‘*.
-
Harness Engineering ① AI Agent 의 진짜 능력은 *모델* 이 아니라 *Harness* 가 결정한다 — Claude Code 해부
이 글은 “Harness Engineering 의 4 가지 얼굴” 시리즈의 1 편. 다른 편: ② Test Harness / ③ Software Engineering Harness / ④ Deployment Harness