푸른영혼의 별 | Tech Blog
Java Backend Engineer의 기술 블로그입니다.
Spring Boot, MSA, JPA, Kafka, Kubernetes 등 실무 경험을 공유합니다.
주요 프로젝트: Settlement MSA · ASAT · GitHub
Posts (총 352편 · 1 / 36 페이지)
-
마크다운 으로 쓰는 AI 행동강령 — obra/superpowers 스킬 해부
AI 에이전트 에게 “이렇게 일 해라” 를 가르치는 방법 은 보통 프롬프트 다. 그런데 obra(Jesse Vincent) 가 만든 superpowers 는 다른 길 을 간다 — 에이전트 의 행동강령 을
.md파일 로 쓴다. 코드 도, 파인튜닝 도 아니고, 사람 이 읽을 수 있는 마크다운 한 장 이 에이전트 의 규율 이 된다. -
하네스 엔지니어링 — SKILL.md 를 *매번 같게* 만드는 6 기둥
AI 에게 같은 일 을 시켰는데 어제 는 되고 오늘 은 안 되는 경험, 다들 있을 거다. 원인 은 대개 모델 이 아니라 — 지시서(SKILL.md) 에 빈칸 이 있었기 때문 이다. 빈칸 이 있으면 그 자리 에서 AI 가 추측 한다. 추측 은 매번 다르다. 그래서 결과 가 흔들린다.
-
하네스 엔지니어링 — 그림 한 장 으로 읽는 *Claude Code 의 해부*
-
Codex 플러그인 — 에이전트 에게 *능력 을 끼우는* 법 (핸즈온 + 조합)
OpenAI 의 AX 인재전쟁 같은 자리 에서 반복 되는 화두 는 하나다 — “AI 로 우리 회사 의 진짜 문제 를 풀 수 있는가.” 그 답 의 실체 중 하나 가 Codex 플러그인 이다. 범용 코딩 에이전트(Codex) 에 우리 도메인 의 능력 을 끼워 넣는 방법. 이 글 은 Codex 플러그인 이 무엇 이고, 어떻게 만들고 조합 하는지 를 핸즈온 으로 정리 한다.
-
6 기둥 으로 다시 읽는 superpowers — *SKILL.md* 는 어떻게 규칙 을 강제 하는가
Jesse Vincent 의 obra/superpowers 는 문서형 하네스 를 실제 로 운영 중 인 보기 드문 오픈소스 사례 다. 마크다운(
SKILL.md) 로 에이전트 의 행동 규칙 을 정의 하고, 그걸 훅 으로 강제 한다. 이 글 은 그 SKILL.md 들 을 6 기둥 — ROLE · GOAL · FORBID · OUTPUT · EXAMPLE · CHECK 에 매핑 해 읽고, 마크다운 밖 의hooks/가 어떻게 한 겹 더 잠그는지 를 본다. -
하네스 엔지니어링 — *매주 앱 하나* 를 찍어내는 스킬 파이프라인 설계
“AI 가 앱 을 만들 수 있다” 는 건 이제 놀랍지 않다. 진짜 문제 는 그 다음이다 — 한 번 이 아니라, 매주 신뢰 가능하게 반복 할 수 있는가. 일회성 마법 을 지속 생산 으로 바꾸는 것, 그게 하네스 엔지니어링 이다. 아래 그림 은 그 하네스 를 한 장 에 담은 설계다.
-
내 프로젝트 들 을 관통 하는 설계 — *도메인 은 다른데, 원칙 은 같았다*
정산, 청각 재활, 이커머스 검색, 물류, 자동매매, 성경 XR… 만든 것 들 의 도메인 은 제각각 이다. 그런데 코드 를 열어 보면 같은 설계 원칙 이 반복 된다. 이 글 은 프로젝트 를 하나씩 소개 하는 대신, 여러 프로젝트 를 관통 하는 설계 결정 다섯 가지 를 정리 한다 — 도메인 이 달라도 변하지 않았던 것들.
-
정산 시스템 에 적용한 QueryDSL — 헥사고날 · 커서 페이징 · 프로젝션 실전
정산(settlement) 시스템 의 조회 계층 은 전부 QueryDSL 로 짰다. 단순 CRUD 면 Spring Data JPA 로 충분 하지만, 정산 은 동적 검색 · 대용량 페이징 · 집계 · 대사(reconciliation) 가 핵심 이라 — 문자열 JPQL 로는 감당 이 안 된다. 이 글 은 실제 코드 로 QueryDSL 을 어떻게 붙였는지 정리 한다.
-
여러 프로젝트, 반복 되는 설계 — 내가 계속 고르는 6가지
프로젝트 를 여러 개 굴리다 보면 알게 된다. 설계 에 정답 은 없지만, 내가 반복 해서 고르는 결정 은 있다. 정산 시스템 이든 청각 재활 훈련 이든 XR 신앙 앱 이든 — 도메인 은 전혀 다른데, 뼈대 를 세우는 방식 은 자꾸 같은 곳 으로 수렴 한다.
-
AI 에이전트 아키텍처는, 백엔드 개발자 가 이미 아는 것 이다
AI 에이전트 를 공부 하다 보면 새 단어 가 쏟아진다 — Orchestrator, Guardrail, Memory, Tool, Human-in-the-loop… 처음 엔 완전히 새로운 세계 처럼 보인다. 그런데 하나씩 뜯어보면 백엔드 엔지니어 가 이미 10년 째 짓고 있던 것 들 이다. 이름 만 바뀌었을 뿐 이다.