푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 363편 · 1 / 37 페이지)
-
Claude Code 사용법 — 명령·플래그·슬래시 한 장 참조, 그리고 실전 조합
Claude Code 를 오래 쓰다 보면, 결국 손 에 남는 건 몇 개 의 명령 과 플래그 다. 세션 을 어떻게 시작 하고, 어제 대화 를 어떻게 이어가고, 권한 을 어디까지 열고, 어떤 도구 를 확인 없이 굴릴지 — 이 몇 가지 만 몸 에 붙으면 나머지 는 대화 로 흘러간다. 아래 한 장 은 그 골격 이다.
-
같은 로그, 같은 스냅샷 — 상태 머신 · 이벤트 소싱 · 결정론적 리플레이

-
프롬프팅 최고수 가 되는 길 — 9개 슬롯, 그리고 상위 0.1% 와 1% 의 차이
좋은 프롬프트 는 이렇게 생겼다 — 역할, 상황, 목적, 독자, 요구사항, 제한, 출력 형식, 답변 기준. 아홉 개 슬롯 을 채우는 빈칸 템플릿.
-
한 장 으로 본 나의 *지식·에이전트 운영체제* — 조각 이 아니라 시스템 이다
화이트보드 하나 를 오래 그렸다. 컨텍스트 전달, known-unknown, 정제 루프, 온톨로지, 제한된 합리성, 에이전트 실행 기법, 그리고 매주 앱 하나 배포 라는 목표 까지 — 언뜻 흩어진 조각 같지만, 뜯어보면 하나 의 운영체제 다. 어떻게 입력 하고, 무엇 을 모르는지 알고, 반복 해 다듬고, 공유 진실 로 수렴 하고, 완벽 대신 만족 을 택하고, 길게 실행 하되 멈출 줄 아는 — 생각 과 에이전트 를 굴리는 골격. 이 글 은 그 지도 를 한 줄 로 꿰어 읽는다.
-
아직은 Fable 5 도 고삐 를 잡아야 한다 — *벤치 점수* 의 허점 과 *harness* 라는 답
프론티어 모델 이 벤치 에서 최고점 을 찍었다. 그래서 안심 해도 되나? 아니다 — 점수 는 주장 이지 보증 이 아니다. 이 글 은 Fable 5 같은 최상위 모델 의 점수 를 날카롭게 의심 하는 법, 그리고 그 의심 을 실제 로 검증 하는 도구 인 harness 를 얘기 한다.
-
스스로 나아지는 에이전트 — *Registry · ACP · Harness* 세 기둥 과 되먹임 루프
에이전트 의 “자기 개선” 은 “모델 이 더 똑똑 해지는 것” 이 아니다. 에이전트 가 자기 능력 을 스스로 넓히고 고치는 것 — 툴 을 측정 하고, 개선 하고, 새로 만드는 루프 다. 그걸 가능 하게 하는 부품 은 딱 세 개다.
-
로그 수집 을 여러 각도 에서 — *어디서·어떻게·무엇을·얼마에* 모으나
“로그 를 수집 한다” 는 말 은 쌓는다 처럼 들리지만, 실제 로 는 여러 결정 의 집합 이다 — 어디서 뽑고, 어떻게 흘리고, 무슨 형태 로 담고, 얼마 를 태울지. 각 축 에서 잘못 고르면, 정작 장애 났을 때 검색 이 안 되거나 · 로그 가 없거나 · 청구서 가 폭발 한다.
-
Claude Code 하네스 를 직접 만들기 — *SKILL.md + hook* 기획 부터 시운전 까지
앞의 두 글 — 하네스 해부 와 Superpowers 구조 — 는 개념 이었다. 이번 엔 직접 하나 만든다. “회의록 을 1페이지 로 요약” 하는 하네스 를, Superpowers 패턴 그대로
.claude/폴더 에 SKILL.md 와 hook 으로 짓는 4단계 기획 이다. -
무엇 을·어떻게·어디까지 잠글까 — .md 하네스 를 설계 하는 4프레임
앞 글 마크다운 으로 쓰는 AI 행동강령 에서 행동 을
.md로 쓴다 는 발상 을 봤다. 그럼 실제 로 쓸 때 는 무엇 을 어떻게 정해야 하나? 나는 이걸 “잠그기(locking)” 라는 관점 으로 본다 — 에이전트 의 자유도 를 어디까지 고정 할지 를 정하는 일. -
Claude Code 플러그인 *Superpowers* 의 구조 — 규율 을 하네스 로 굳히다
