Figma 를 코드 없이 읽어 봤다: 호출은 3분의 1 이하로, 큰 화면 비용은 43% 줄었다
Figma 기획서를 get_design_context 대신 get_metadata 와 읽기용 템플릿(use_figma 로 실행)으로 읽고 프레임마다 3회씩 쟀다. Figma MCP 만 켠 조건에서 Figma 호출은 기존 방식의 3분의 1 이하 수준으로 줄었고, 큰 화면은 비용과 누적 토큰이 모두 43% 줄었다. 정답 충족에서는 차이를 보지 못했다.
Figma 기획서를 get_design_context 대신 get_metadata 와 읽기용 템플릿(use_figma 로 실행)으로 읽고 프레임마다 3회씩 쟀다. Figma MCP 만 켠 조건에서 Figma 호출은 기존 방식의 3분의 1 이하 수준으로 줄었고, 큰 화면은 비용과 누적 토큰이 모두 43% 줄었다. 정답 충족에서는 차이를 보지 못했다.
Orca 가 주는 에이전트 스킬을 먼저 소개하고, 내 하네스가 그 위에 얹은 세션 인수인계(orca-session-handoff)와 Orca 로 띄우는 opencode 일꾼(orca-worker)을 순서대로 설명한다. 일꾼은 Ollama 클라우드의 glm-5.3-flash 를 쓴다.
규칙 9개, 스킬 69개, 에이전트 20개, 훅 17개로 이루어진 내 하네스를 하네스·오케스트레이터·메타 하네스 지도 위에 올려 설명한다. 메인은 Sonnet 5.5, 설계·계획·작업 분할은 Opus 5.5, 구현은 Sonnet 5.5 가 맡는다.
「2026-09-05 삭제했다」, 「기존에는 X 였는데 Y 로 바꿨다」 같은 시간순 서사를 코드 주석과 규칙 문서에서 걷어내고, 이력은 CHANGELOG 표에 맡기는 방법. 찾는 명령, 고치기 전후, 옮기는 자리, 검증까지 내 하네스에서 한 순서대로 정리한다.
deny 규칙은 명령 문자열을 읽고, trust 창은 넓히는 설정만 붙잡고, sandbox는 shell 명령만 감싼다. 장치마다 경계가 달랐고, 공개 권고 35건은 대부분 그 경계에서 나왔다.
kc-admin 팀 하네스를 이루는 부품을 하나씩 연다. 구현·리뷰·수정을 갈라 놓은 서브에이전트 7종의 도구·모델 배정, 수동 호출 전용으로 잠근 스킬 6종, 그리고 765줄짜리 bash-guard를 포함해 시크릿·규칙 변조·MCP 쓰기·린트를 지키는 훅 6종. 문서 규칙과 기계 집행의 경계를 어디에 그었는지까지.
kc-admin 팀 하네스가 실제로 도는 경로를 따라간다. 문서 여러 개를 병렬 분석해 SSOT를 만들고 rubric으로 채점하는 /ssot-creator, 작업 티켓을 의존성 DAG로 스케줄링해 워크트리 병렬로 TDD·적대적 리뷰·자동 병합까지 끌고 가는 /ssot-driven-dev. 그리고 상태 파일 없이 중단·재개를 버티는 엔지니어링 기법들.
Confluence·Figma 기획 문서만으로 백엔드 기능을 개발하는 kc-admin 팀 하네스를 3주 동안 만들며 내린 결정들. SSOT 문서 한 방향 원칙, 추측 대신 질문을 제도화한 [OPEN] 게이트, 사람 게이트의 위치, 티켓 단위 워크트리 격리, 그리고 실측 사고가 바꾼 설계까지. 3부작의 첫 편.
Spring AI 2.0 은 ChatModel 안에 숨어 있던 툴 호출 루프를 어드바이저 체인 위로 끌어올렸습니다. ToolCallingAdvisor, ToolSearchToolCallingAdvisor, StructuredOutputValidationAdvisor 셋이 각각 무엇을 대신 해 주는지, 1.x 코드에서 무엇이 깨지는지를 주니어 입장에서 한 번
JDK 28 에 JEP 540 Simple JSON API 가 인큐베이터로 들어옵니다. Json 클래스와 sealed JsonValue 가 어떤 모양인지 보고, Amplitude·Braze 로 마케팅 이벤트를 쏠 때 쓰던 ObjectMapper 를 실제로 덜어낼 수 있는지 조건을 따져 본 메모입니다.
회의록 앱에 같은 목표를 열여섯 번 주고, 절반은 직접 쓴 한 줄로 절반은 모델이 생성한 프롬프트로 실행한 뒤 결과물을 blind 채점한 측정 기록.
아임웹의 제약에서 출발해 도메인과 앱 식별 설정만 바꾸면 재사용할 수 있는 Deferred Deep Link 웹·React Native 오픈소스를 만든 과정을 정리한다.
대시보드에 지표는 수십 개인데 장애가 나면 어디부터 봐야 할까요. 구글 SRE 북이 말하는 '딱 네 가지만 본다면 이것부터'를 원문 기준으로 정리하고, Kubernetes/Istio 환경에 연결해 봤습니다.
룰셋을 읽고 직접 해봤을 때와 설치해서 돌렸을 때의 차이가 생각보다 컸다. 그 차이를 뜯어보다가 이 도구를 계속 쓸 이유를 엉뚱한 데서 찾았다.
장애 알람이 오면 AI 에이전트가 여러 MCP를 순회하며 근본 원인을 조사하고, 사람이 승인 버튼을 누르면 그 조치만 실행하는 반자동 장애 대응 파이프라인을 구축한 기록입니다. 분석과 조치를 왜 두 번의 헤드리스 실행으로 나눴는지, 왜 훅이 아니라 이 구조를 택했는지, API Gateway·Lambda·Cognito를 왜 썼고 실행부를 왜 EC2로 분리했는
PARA Vault와 LLM Wiki 운영 원칙을 바탕으로, 30_Resources 지식을 Claude Code와 Codex에 출처와 함께 제공하는 로컬 RAG MCP의 구축과 품질 평가 기록이다.
'그래프 엔지니어링이 나왔다'는 말을 듣고 파 봤더니, 설치할 물건이 아니라 이미 반쯤 하고 있던 사고방식이었습니다. 개념과 프레임워크(LangGraph·Spring AI)를 가르고, 그게 내 하네스의 특수한 경우였다는 걸 확인한 뒤, 실제로 CLAUDE.md와 스킬에 그래프 두 장을 그려 넣기까지의 기록입니다.
'핑퐁 루프는 몇 번이 적정선인가'를 조사한 뒤, 그 결론을 실제 게이트 스킬로 앉혔습니다. 두 개의 관문, 세 라벨 강제, 편향을 줄이는 병렬 자체평가, 그리고 발산을 막는 '위험 0으로만 종료' 규칙까지 — 제가 만든 핑퐁 리뷰 게이트의 실제 설계를 공유합니다.
1편이 하네스의 부품 목록이었다면, 2편은 '왜 하필 그 모양인가' 입니다. 행동 원칙이 왜 네 줄인지, 스킬을 왜 쪼갰는지, 게이트와 사용자 허들을 어디에 둘지, 무엇을 막고 무엇을 자동화할지를 주니어 입장에서 되짚은 회고입니다.
AI 코딩 도구를 쓰면서 모델이 아니라 모델 주변(하네스)을 직접 손봤습니다. ~/.claude/ 아래에 하나씩 쌓아 올린 CLAUDE.md, 권한 설정, 훅, 자작 스킬, 에이전트가 각각 무엇인지를 주니어 입장에서 한 번 펼쳐 정리한 1편입니다.
부품과 설계 이유를 봤으니, 이제 실제 작업 한 건이 흘러가는 절차입니다. 세션이 열리는 순간부터 플랜·게이트·구현·검수·커밋, 그리고 세션이 닫히며 핸드오프를 남기기까지 — 제 하네스가 작업 한 사이클을 어떻게 끌고 가는지 따라가 본 3편입니다.
Gradle의 저장소 목록은 전역 하나가 아니라 해석 스코프별로 독립이다. 사내 Nexus 라우팅이 왜 한 곳의 설정으로 끝나지 않는지, 그리고 흩어진 설정과 patch를 init script 한 파일로 단일화한 과정을 정리한다.
Claude Code의 동적 워크플로우는 수백 개의 서브에이전트를 JavaScript 스크립트로 조율하는 기능이다. 계획이 Claude의 컨텍스트에서 코드로 이동하면 무엇이 달라지는지, pipeline과 parallel은 어떻게 골라야 하는지, 토큰 비용은 어떻게 관리하는지. 시니어 백엔드 개발자의 시선으로 뜯어본 기록.
security-guidance 플러그인은 Claude가 작성한 코드를 편집·턴 끝·커밋의 세 지점에서 서로 다른 깊이로 검토하고, 발견을 같은 세션에서 수정하게 만든다. 설치하면 자동으로 도는 이 3계층 구조를 뜯어보고, 우리 팀의 위협 모델을 어떻게 얹을지 정리했다.
컨텍스트/업무공유 레포 뼈대, 업무 인벤토리, 가드레일 훅 구현 — 그리고 그 과정에서 수정된 세 가지 결정.
혼자 잘 쓰는 것과 팀이 같이 쓰는 건 완전히 다른 문제였습니다. 소규모 DevOps 챕터의 AI 전환 — 왜 시작했고, 어떻게 하기로 했는지.
가장 비싼 모델은 지휘만, 실행은 역할에 맞는 모델에 맡긴다. Claude Fable 훅과 Codex GPT-5.6 역할 기반 오케스트레이션을 나란히 정리한 설정기.
같은 macOS 앱에 workflow로 아키텍처를 읽고 batch로 공개 API에 문서를 달아본 뒤, 두 병렬 기능의 진짜 차이를 실측과 함께 정리한 실행 기록.
Aijinet 기술연구소 팀블로그를 CMS가 아니라 엔지니어별 독립 블로그와 RSS 허브 구조로 설계한 이유와 구현 방식 정리
AWS와 NCP Kubernetes 클러스터의 메트릭, 로그, 트레이스를 하나의 Grafana에서 보기 위해 구성한 멀티클러스터 Observability 구조를 정리합니다.